Bugs in 2.6.12-rc kernels

Bugs in 2.6.12-rc kernels

[Wakko Warner]

1) This bug existed in 2.6.10, 2.6.11.x (x >= 0) and 2.6.12-rcx (x >= 2)
The kernel OOPSes when attempting to unload ide-scsi.  At this moment, I do
not have a system using ide-scsi that doesn't load proprietary modules,
however, I don't believe that matters.

2) One key on a PC/AT keyboard port does not function. under 2.6.12-rc
kernels (rc1 not tested).  These keys work when using a 2.6.11 series kernel
or a USB keyboard.

The key, at the console shows it's code as as 0xe0 0x5c (press) 0xe0 0xdc
(release) when used on 2.6.11 or earlier.  Under 2.6.12-rc2 or newer, no key
press is ever reported (using showkey -s.  when using showkey, I see keycode
126)

3) I put together a boot kernel/initrd using 2.6.12-rc2 (also tested
2.6.12-rc4) which seems to work, except that pcmcia does not function
properly.  When pcmcia.ko gets loaded, it is unable to register it's char
dev.  I'm not sure why this is.  2.6.11.8 worked fine with no modifications
to the system.  This is a system designed to boot from floppy minimally,
search for a device which has some files that populates a tmpfs filesystem
which becomes the root filesystem.  This module is loaded from the tmpfs
filesystem.  Module-init-tools version is 3.2-pre (Not sure if this makes a
difference).  I tested this on a notebook that I have.  I also have this
same kernel version installed which works fine.  It could be a different
version of module-init-tools, but I'm unsure at this point (I do not have
access to the notebook at this time.

---
I will have access to the machines above tomorrow (provided I have time for
testing).

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Bugs in 2.6.12-rc kernels

[Wakko Warner]

Wakko Warner wrote:
> 3) I put together a boot kernel/initrd using 2.6.12-rc2 (also tested
> 2.6.12-rc4) which seems to work, except that pcmcia does not function
> properly.  When pcmcia.ko gets loaded, it is unable to register it's char
> dev.  I'm not sure why this is.  2.6.11.8 worked fine with no modifications
> to the system.  This is a system designed to boot from floppy minimally,
> search for a device which has some files that populates a tmpfs filesystem
> which becomes the root filesystem.  This module is loaded from the tmpfs
> filesystem.  Module-init-tools version is 3.2-pre (Not sure if this makes a
> difference).  I tested this on a notebook that I have.  I also have this
> same kernel version installed which works fine.  It could be a different
> version of module-init-tools, but I'm unsure at this point (I do not have
> access to the notebook at this time.

I tested this again today with a few changes.  It appears that if pcmcia.ko
(or rather the .c files that make it up) are compiled with -Os, it will fail
to register a character device.  Being that one of my goals for this was to
fit everything on a floppy, I had to use -Os when building the kernel. 
(pcmcia was not one of the modules that belongs on the floppy, however I
did not want to have to compile the kernel and then again for the modules
w/o -Os)

I believe that pcmcia.ko is the only module I am using that  uses a dynamic
major.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

[PATCH] pcmcia/ds: handle any error code

[randy_dunlap]

On Thu, 12 May 2005 19:02:06 -0400 Wakko Warner wrote:

| Wakko Warner wrote:
| > 3) I put together a boot kernel/initrd using 2.6.12-rc2 (also tested
| > 2.6.12-rc4) which seems to work, except that pcmcia does not function
| > properly.  When pcmcia.ko gets loaded, it is unable to register it's char
| > dev.  I'm not sure why this is.  2.6.11.8 worked fine with no modifications
| > to the system.  This is a system designed to boot from floppy minimally,
| > search for a device which has some files that populates a tmpfs filesystem
| > which becomes the root filesystem.  This module is loaded from the tmpfs
| > filesystem.  Module-init-tools version is 3.2-pre (Not sure if this makes a
| > difference).  I tested this on a notebook that I have.  I also have this
| > same kernel version installed which works fine.  It could be a different
| > version of module-init-tools, but I'm unsure at this point (I do not have
| > access to the notebook at this time.
| 
| I tested this again today with a few changes.  It appears that if pcmcia.ko
| (or rather the .c files that make it up) are compiled with -Os, it will fail
| to register a character device.  Being that one of my goals for this was to
| fit everything on a floppy, I had to use -Os when building the kernel. 
| (pcmcia was not one of the modules that belongs on the floppy, however I
| did not want to have to compile the kernel and then again for the modules
| w/o -Os)
| 
| I believe that pcmcia.ko is the only module I am using that  uses a dynamic
| major.

There is some small difference in locking in fs/char_dev.c between
2.6.12-rc4 and 2.6.11.8, but I don't yet see why it would cause a
failure in register_chrdev().

Oh, there's a big difference in drivers/pcmcia/ds.c, lots of probe
changes.  This is where to look further (but not tonight).
The question then becomes is this a real regression?

Do you suspect a problem with -Os code generation?

Looks to me like ds.c needs at least this small fix...

---

register_chrdev() can return errors (negative) other then -EBUSY,
so check for any negative error code.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>

diffstat:=
 drivers/pcmcia/ds.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -Naurp ./drivers/pcmcia/ds.c~ds_check_major ./drivers/pcmcia/ds.c
--- ./drivers/pcmcia/ds.c~ds_check_major	2005-05-12 13:16:41.000000000 -0700
+++ ./drivers/pcmcia/ds.c	2005-05-12 19:45:36.000000000 -0700
@@ -1592,9 +1592,9 @@ static int __init init_pcmcia_bus(void)
 
 	/* Set up character device for user mode clients */
 	i = register_chrdev(0, "pcmcia", &ds_fops);
-	if (i == -EBUSY)
+	if (i < 0)
 		printk(KERN_NOTICE "unable to find a free device # for "
-		       "Driver Services\n");
+		       "Driver Services (error=%d)\n", i);
 	else
 		major_dev = i;
 

Re: [PATCH] pcmcia/ds: handle any error code

[Wakko Warner]

randy_dunlap wrote:
> | Wakko Warner wrote:
> | > 3) I put together a boot kernel/initrd using 2.6.12-rc2 (also tested
> | > 2.6.12-rc4) which seems to work, except that pcmcia does not function
> | > properly.  When pcmcia.ko gets loaded, it is unable to register it's char
> | > dev.  I'm not sure why this is.  2.6.11.8 worked fine with no modifications
> | 
> | I tested this again today with a few changes.  It appears that if pcmcia.ko
> | (or rather the .c files that make it up) are compiled with -Os, it will fail
> | to register a character device.  Being that one of my goals for this was to
> | fit everything on a floppy, I had to use -Os when building the kernel. 
> | (pcmcia was not one of the modules that belongs on the floppy, however I
> | did not want to have to compile the kernel and then again for the modules
> | w/o -Os)
> | 
> | I believe that pcmcia.ko is the only module I am using that  uses a dynamic
> | major.
> 
> There is some small difference in locking in fs/char_dev.c between
> 2.6.12-rc4 and 2.6.11.8, but I don't yet see why it would cause a
> failure in register_chrdev().
> 
> Oh, there's a big difference in drivers/pcmcia/ds.c, lots of probe
> changes.  This is where to look further (but not tonight).
> The question then becomes is this a real regression?
> 
> Do you suspect a problem with -Os code generation?

Definately.  Here's what I did.  The laptop I was testing has 2.6.12-rc2
installed (it's a multi boot).  This kernel was compiled specifically for
the laptop since it's one that I use for work.  The kernel I compiled with
-Os is a generic and this laptop was the only one I had to test this with. 
So basically, you could say this laptop currently has 2 linux installations
on it.  The generic one I'm trying to get partially on a floppy and it's
normal one.

I was first booting from floppy to test.  The kernel on the floppy is
compield with -Os and the kernel itself is compressed with upx-ucl-beta to
make it smaller.  Then it has a gzipped initrd with busybox and some
modules.  I call this stage1.  stage2 which has the pcmcia module comes from
either a cdrom or a usb stick (I have stage 1 on the laptop hdd, but stage 2
still comes from usb).  Figuring there might have been a problem with upx, I
decided to through the stage1 on my laptop's hdd (since it can't boot from
usb).  This time, I recompiled the kernel (make clean, remove optimize for
size, make bzImage modules, install modules to the usb stick and select ones
for the initrd).  Once I did this, pcmcia worked.  The configuration was the
same, all that changed was not using -Os.

> Looks to me like ds.c needs at least this small fix...

I'll forward this diff to myself at work and test it.  Thanks.  I'll let you
know what happens.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: [PATCH] pcmcia/ds: handle any error code

[Wakko Warner]

randy_dunlap wrote:
> On Thu, 12 May 2005 19:02:06 -0400 Wakko Warner wrote:
> There is some small difference in locking in fs/char_dev.c between
> 2.6.12-rc4 and 2.6.11.8, but I don't yet see why it would cause a
> failure in register_chrdev().
> 
> Oh, there's a big difference in drivers/pcmcia/ds.c, lots of probe
> changes.  This is where to look further (but not tonight).
> The question then becomes is this a real regression?
> 
> Do you suspect a problem with -Os code generation?

I just tried it, it doesn't give me any errors.  This is strange considering
that I a) use a pristine tree for each kernel (only coping the .config) and
b) the patch doesn't do anything except report the error.  I made my boot
floppy (the scripts I use pull from the kernel tree I specify and make the
image I need) and booted from it.  I placed the modules on my stage2 disk
that was made and it works.

I don't have the time this week to try again from scratch.  I'll see if I
can do it next week.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: [PATCH] pcmcia/ds: handle any error code

[randy_dunlap]

On Fri, 13 May 2005 15:45:49 -0400 Wakko Warner wrote:

| randy_dunlap wrote:
| > On Thu, 12 May 2005 19:02:06 -0400 Wakko Warner wrote:
| > There is some small difference in locking in fs/char_dev.c between
| > 2.6.12-rc4 and 2.6.11.8, but I don't yet see why it would cause a
| > failure in register_chrdev().
| > 
| > Oh, there's a big difference in drivers/pcmcia/ds.c, lots of probe
| > changes.  This is where to look further (but not tonight).
| > The question then becomes is this a real regression?
| > 
| > Do you suspect a problem with -Os code generation?
| 
| I just tried it, it doesn't give me any errors.  This is strange considering
| that I a) use a pristine tree for each kernel (only coping the .config) and
| b) the patch doesn't do anything except report the error.  I made my boot
| floppy (the scripts I use pull from the kernel tree I specify and make the
| image I need) and booted from it.  I placed the modules on my stage2 disk
| that was made and it works.
| 
| I don't have the time this week to try again from scratch.  I'll see if I
| can do it next week.

I'm currently running a kernel built with -Os.  I can successfully
load pcmcia_core.ko and pcmcia.ko.  I added debug printk's in
drivers/pcmcia/ds.c and it allocates the dynamic major dev
successfully:
[4294809.055000] register_chrdev: returning 254
[4294809.060000] pcmcia major device = 254


What gcc version are you using?  (gcc 4.0 has a few known issues.)

---
~Randy

Re: [PATCH] pcmcia/ds: handle any error code

[Wakko Warner]

randy_dunlap wrote:
> On Fri, 13 May 2005 15:45:49 -0400 Wakko Warner wrote:
> | I just tried it, it doesn't give me any errors.  This is strange considering
> | that I a) use a pristine tree for each kernel (only coping the .config) and
> | b) the patch doesn't do anything except report the error.  I made my boot
> | floppy (the scripts I use pull from the kernel tree I specify and make the
> | image I need) and booted from it.  I placed the modules on my stage2 disk
> | that was made and it works.
> | 
> | I don't have the time this week to try again from scratch.  I'll see if I
> | can do it next week.
> 
> I'm currently running a kernel built with -Os.  I can successfully
> load pcmcia_core.ko and pcmcia.ko.  I added debug printk's in
> drivers/pcmcia/ds.c and it allocates the dynamic major dev
> successfully:

I noticed this too.  I can't figure out why it wasn't working before.  I
don't believe the method of loading the kernel (hdd, usb, floppy) would
cause this.  Next week when I get a chance to work more on this project,
I'll wipe out my entire kernel tree (saving the .config) and try again (I
keep pristine sources in /usr/src/linux/dist/<kernel vers>)

> What gcc version are you using?  (gcc 4.0 has a few known issues.)

gcc (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)

I have gcc-3.3 also installed.  Should I use it instead?

I follow the list somewhat (only interesting sujects =) and I have noticed
that 4.0 has some problems.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: [PATCH] pcmcia/ds: handle any error code

[randy_dunlap]

On Sat, 14 May 2005 13:26:19 -0400 Wakko Warner wrote:

| randy_dunlap wrote:
| > On Fri, 13 May 2005 15:45:49 -0400 Wakko Warner wrote:
| > | I just tried it, it doesn't give me any errors.  This is strange considering
| > | that I a) use a pristine tree for each kernel (only coping the .config) and
| > | b) the patch doesn't do anything except report the error.  I made my boot
| > | floppy (the scripts I use pull from the kernel tree I specify and make the
| > | image I need) and booted from it.  I placed the modules on my stage2 disk
| > | that was made and it works.
| > | 
| > | I don't have the time this week to try again from scratch.  I'll see if I
| > | can do it next week.
| > 
| > I'm currently running a kernel built with -Os.  I can successfully
| > load pcmcia_core.ko and pcmcia.ko.  I added debug printk's in
| > drivers/pcmcia/ds.c and it allocates the dynamic major dev
| > successfully:
| 
| I noticed this too.  I can't figure out why it wasn't working before.  I
| don't believe the method of loading the kernel (hdd, usb, floppy) would
| cause this.  Next week when I get a chance to work more on this project,
| I'll wipe out my entire kernel tree (saving the .config) and try again (I
| keep pristine sources in /usr/src/linux/dist/<kernel vers>)
| 
| > What gcc version are you using?  (gcc 4.0 has a few known issues.)
| 
| gcc (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)
| 
| I have gcc-3.3 also installed.  Should I use it instead?

I guess it's worth a try, although suspecting code generation is really
low on my list.  (I used gcc 3.3.3.)

| I follow the list somewhat (only interesting sujects =) and I have noticed
| that 4.0 has some problems.


---
~Randy

Re: [PATCH] pcmcia/ds: handle any error code

[Wakko Warner]

randy_dunlap wrote:
> On Sat, 14 May 2005 13:26:19 -0400 Wakko Warner wrote:
> | > I'm currently running a kernel built with -Os.  I can successfully
> | > load pcmcia_core.ko and pcmcia.ko.  I added debug printk's in
> | > drivers/pcmcia/ds.c and it allocates the dynamic major dev
> | > successfully:
> | 
> | I noticed this too.  I can't figure out why it wasn't working before.  I
> | don't believe the method of loading the kernel (hdd, usb, floppy) would
> | cause this.  Next week when I get a chance to work more on this project,
> | I'll wipe out my entire kernel tree (saving the .config) and try again (I
> | keep pristine sources in /usr/src/linux/dist/<kernel vers>)
> | 
> | > What gcc version are you using?  (gcc 4.0 has a few known issues.)
> | 
> | gcc (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)
> | 
> | I have gcc-3.3 also installed.  Should I use it instead?
> 
> I guess it's worth a try, although suspecting code generation is really
> low on my list.  (I used gcc 3.3.3.)

Sorry for taking so long.  I had time today to do something.  I did try this
version, I didn't have any problems.  I also didn't have any problems with
rc5.  I'll be trying rc6 when I get a chance.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals