Re: 2.6.21-rc4-mm1 and rc5-mm2 - problem with cpuidle routine
On 3/29/07, Ed Sweetman <[EMAIL PROTECTED]> wrote: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 1.0-9746 Fri Dec 15 10:19:35 PST 2006 PCI: Setting latency timer of device :01:00.0 to 64 NVRM: loading NVIDIA UNIX x86_64 Kernel Module 1.0-9746 Fri Dec 15 10:19:35 PST 2006 **WARNING** I2C adapter driver [NVIDIA i2c adapter ] forgot to specify physical Please try to reproduce with an untainted kernel. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1 and rc5-mm2 - problem with cpuidle routine
On 3/29/07, Ed Sweetman [EMAIL PROTECTED] wrote: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 1.0-9746 Fri Dec 15 10:19:35 PST 2006 PCI: Setting latency timer of device :01:00.0 to 64 NVRM: loading NVIDIA UNIX x86_64 Kernel Module 1.0-9746 Fri Dec 15 10:19:35 PST 2006 **WARNING** I2C adapter driver [NVIDIA i2c adapter ] forgot to specify physical Please try to reproduce with an untainted kernel. Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Wed, 28 Mar 2007 03:26:35 +0200, Eric Rannaud <[EMAIL PROTECTED]> wrote: > The reason for that original patch was that it is actually possible for the > uevent functions to return -ENOMEM, the uevent buffer being statically > allocated to BUFFER_SIZE (2048). So maybe -ENOMEM should still be propagated? We just don't want to fail device_add because of it. > It used to be 1024 but that was not > always enough and it was doubled a while ago [1]. Using add_uevent_var() > makes this less of a problem as such an overflow should be catched > cleanly [2]. Reminds me that I need to look into ccw_uevent :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Wed, 28 Mar 2007 03:26:35 +0200, Eric Rannaud [EMAIL PROTECTED] wrote: The reason for that original patch was that it is actually possible for the uevent functions to return -ENOMEM, the uevent buffer being statically allocated to BUFFER_SIZE (2048). So maybe -ENOMEM should still be propagated? We just don't want to fail device_add because of it. It used to be 1024 but that was not always enough and it was doubled a while ago [1]. Using add_uevent_var() makes this less of a problem as such an overflow should be catched cleanly [2]. Reminds me that I need to look into ccw_uevent :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Tue, Mar 27, 2007 at 07:17:49PM +0200, Cornelia Huck wrote: > On Tue, 27 Mar 2007 11:25:57 +0200, > "Kay Sievers" <[EMAIL PROTECTED]> wrote: > > Checking the uevent return value, will not prevent any malfunction, > > usually this kind of "error handling" just prevents bringing up a > > whole subsystem, or booting-up a box, because the needed device does > > not exist at all. > > OK, if we consider uevents to be non-vital to a functioning device. The reason for that original patch was that it is actually possible for the uevent functions to return -ENOMEM, the uevent buffer being statically allocated to BUFFER_SIZE (2048). It used to be 1024 but that was not always enough and it was doubled a while ago [1]. Using add_uevent_var() makes this less of a problem as such an overflow should be catched cleanly [2]. > OTOH, I think using something like uevent_suppress (maybe via > dev_uevent_filter?) is a saner way to suppress a uevent than to return > an error code in the uevent function. That makes sense, I guess. I will try that. Thanks. [1] http://marc.info/?t=11379736122=1=2 [2] uevent-use-add_uevent_var-instead-of-open-coding-it.patch in rc4-mm1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Tue, 27 Mar 2007 11:25:57 +0200, "Kay Sievers" <[EMAIL PROTECTED]> wrote: > I don't see any point in deregistering a kernel device, if the event > to userspace goes wrong, or a subsytem returns a non-zero value in the > filter. But if we filter the event, we just return 0? > Checking the uevent return value, will not prevent any malfunction, > usually this kind of "error handling" just prevents bringing up a > whole subsystem, or booting-up a box, because the needed device does > not exist at all. OK, if we consider uevents to be non-vital to a functioning device. OTOH, I think using something like uevent_suppress (maybe via dev_uevent_filter?) is a saner way to suppress a uevent than to return an error code in the uevent function. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On 3/26/07, Eric Rannaud <[EMAIL PROTECTED]> wrote: On Mon, Mar 26, 2007 at 01:22:32AM -0800, Andrew Morton wrote: > On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck <[EMAIL PROTECTED]> wrote: > > > If so, do you think I should labour on with > > > uevent-improve-error-checking-and-handling.patch plus your fix, or should I > > > drop the lot? (I'm inclined toward the latter, but I'm still not > > > sure which patch(es) need to be dropped). > > > > This depends on what semantics uevent returning an error code should > > have. The firmware code was using it to suppress uevents, but > > uevent_suppress is a better idea now. So if we want uevent returning != > > 0 to imply "something really bad happened", all uevent functions have > > to be audited and those that work like firmware_uevent have to be > > converted to uevent_suppress. This would be cleaner, but I'm not sure > > it's worth the work. > > We're generally struggling to stay alive amongst all the bugs at present - > I'll drop all those patches. My mistake, I wrote the guilty patch uevent-improve-error-checking-and-handling.patch assuming it was safe to treat the return value as an error code, since several uevent functions returns things like -ENOMEM. Should I rework the patch as Cornelia suggests and resubmit later, when things have settled down a little? I don't see any point in deregistering a kernel device, if the event to userspace goes wrong, or a subsytem returns a non-zero value in the filter. Checking the uevent return value, will not prevent any malfunction, usually this kind of "error handling" just prevents bringing up a whole subsystem, or booting-up a box, because the needed device does not exist at all. Thanks, Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On 3/26/07, Eric Rannaud [EMAIL PROTECTED] wrote: On Mon, Mar 26, 2007 at 01:22:32AM -0800, Andrew Morton wrote: On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck [EMAIL PROTECTED] wrote: If so, do you think I should labour on with uevent-improve-error-checking-and-handling.patch plus your fix, or should I drop the lot? (I'm inclined toward the latter, but I'm still not sure which patch(es) need to be dropped). This depends on what semantics uevent returning an error code should have. The firmware code was using it to suppress uevents, but uevent_suppress is a better idea now. So if we want uevent returning != 0 to imply something really bad happened, all uevent functions have to be audited and those that work like firmware_uevent have to be converted to uevent_suppress. This would be cleaner, but I'm not sure it's worth the work. We're generally struggling to stay alive amongst all the bugs at present - I'll drop all those patches. My mistake, I wrote the guilty patch uevent-improve-error-checking-and-handling.patch assuming it was safe to treat the return value as an error code, since several uevent functions returns things like -ENOMEM. Should I rework the patch as Cornelia suggests and resubmit later, when things have settled down a little? I don't see any point in deregistering a kernel device, if the event to userspace goes wrong, or a subsytem returns a non-zero value in the filter. Checking the uevent return value, will not prevent any malfunction, usually this kind of error handling just prevents bringing up a whole subsystem, or booting-up a box, because the needed device does not exist at all. Thanks, Kay - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Tue, 27 Mar 2007 11:25:57 +0200, Kay Sievers [EMAIL PROTECTED] wrote: I don't see any point in deregistering a kernel device, if the event to userspace goes wrong, or a subsytem returns a non-zero value in the filter. But if we filter the event, we just return 0? Checking the uevent return value, will not prevent any malfunction, usually this kind of error handling just prevents bringing up a whole subsystem, or booting-up a box, because the needed device does not exist at all. OK, if we consider uevents to be non-vital to a functioning device. OTOH, I think using something like uevent_suppress (maybe via dev_uevent_filter?) is a saner way to suppress a uevent than to return an error code in the uevent function. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Tue, Mar 27, 2007 at 07:17:49PM +0200, Cornelia Huck wrote: On Tue, 27 Mar 2007 11:25:57 +0200, Kay Sievers [EMAIL PROTECTED] wrote: Checking the uevent return value, will not prevent any malfunction, usually this kind of error handling just prevents bringing up a whole subsystem, or booting-up a box, because the needed device does not exist at all. OK, if we consider uevents to be non-vital to a functioning device. The reason for that original patch was that it is actually possible for the uevent functions to return -ENOMEM, the uevent buffer being statically allocated to BUFFER_SIZE (2048). It used to be 1024 but that was not always enough and it was doubled a while ago [1]. Using add_uevent_var() makes this less of a problem as such an overflow should be catched cleanly [2]. OTOH, I think using something like uevent_suppress (maybe via dev_uevent_filter?) is a saner way to suppress a uevent than to return an error code in the uevent function. That makes sense, I guess. I will try that. Thanks. [1] http://marc.info/?t=11379736122r=1w=2 [2] uevent-use-add_uevent_var-instead-of-open-coding-it.patch in rc4-mm1 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Badari Pulavarty writes: > Patch causing the problem in -mm: > ibmebus-uevent-support.patch > > I don't see where $,1rx(Bof_device_uevent$,1ry(B is defined :( That patch depends on another one from Sylvain Munaut that I haven't yet managed to get Ben H. to express an opinion on, and which isn't in -mm. I thought I mentioned that to Andrew, but maybe I only intended to... Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, Mar 26, 2007 at 09:35:48PM +0200, Jean Delvare wrote: > > Greg, please update your copy with this version of the patch. The only > change is that sound/ppc/beep.c is removed from the patch. Done. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 2007-03-26 at 15:22 -0700, Andrew Morton wrote:
..
> > Unable to handle kernel NULL pointer dereference at 0020
> > RIP:
> > [] __sched_text_start+0x460/0x889
> > PGD 1c1898067 PUD 1c1897067 PMD 0
> > Oops: [1] SMP
> > last sysfs file: block/hda/range
> > CPU 3
> > Modules linked in:
> > Pid: 900, comm: boot Not tainted 2.6.21-rc4-mm1 #1
> > RIP: 0010:[] [] __sched_text_start
>
> This is a very popular oops, caused by the rsdl scheduler. I don't _think_
> we yet know exactly why it is happening. Con, did you get to the bottom
> of this?
>
> We don't know why it confused kallsyms either.
>
> I'll try to shove rc5-mm1 out the door this evening, minus rsdl. And
> -mm2, with rsdl.
Okay, my ppc64 box hangs on boot. It could be different. I will wait
till rc5-mm1 for debugging that one.
Thanks,
Badari
...
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
ReiserFS: sda2: found reiserfs format "3.6" with standard journal
ReiserFS: sda2: using ordered data mode
ReiserFS: sda2: journal params: device sda2, size 8192, journal first
block 18, max trans len 1024, max batch 900, max commit age 30, max
trans age 30
ReiserFS: sda2: checking transaction log (sda2)
ReiserFS: sda2: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 272k freed
Warning: unable to open an initial console.
ioctl32(showconsole:1020): Unknown cmd fd(0) cmd(40045432){00} arg
(ffecdb48) on /dev/tty0
ioctl32(showconsole:1048): Unknown cmd fd(0) cmd(40045432){00} arg
(ffb4aad8) on /dev/tty0
PDC20275: IDE controller at PCI slot 0002:d0:01.0
PDC20275: chipset revision 1
PDC20275: PLL input clock is 32814 kHz
PDC20275: 100% native mode on irq 119
ide2: BM-DMA at 0x2eec00-0x2eec07, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0x2eec08-0x2eec0f, BIOS settings: hdg:pio, hdh:pio
scsi 0:0:15:0: Attached scsi generic sg0 type 13
scsi 0:255:255:255: Attached scsi generic sg1 type 31
sd 1:0:4:0: Attached scsi generic sg2 type 0
sd 1:0:5:0: Attached scsi generic sg3 type 0
scsi 1:0:15:0: Attached scsi generic sg4 type 13
scsi 1:255:255:255: Attached scsi generic sg5 type 31
hde: IBM DROM00205, ATAPI CD/DVD-ROM drive
ide2 at 0x2ee400-0x2ee407,0x2edc02 on irq 119
hde: ATAPI 24X DVD-ROM drive, 256kB Cache
Uniform CD-ROM driver Revision: 3.20
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-
[EMAIL PROTECTED]
ioctl32(showconsole:1918): Unknown cmd fd(0) cmd(40045432){00} arg
(fff00ad8) on /dev/tty0
loop: loaded (max 8 devices)
ioctl32(showconsole:2091): Unknown cmd fd(0) cmd(40045432){00} arg
(fff71ae8) on /dev/tty0
Adding 1050616k swap on /dev/sdb2. Priority:-1 extents:1
across:1050616k
ioctl32(showconsole:2137): Unknown cmd fd(0) cmd(40045432){00} arg
(ffdd7b28) on /dev/tty0
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX
audit(1174945021.442:2): audit_pid=2735 old=0 by auid=4294967295
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 26 Mar 2007 13:57:57 -0800 Badari Pulavarty <[EMAIL PROTECTED]> wrote: > On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > > > > > Panics my x86-64 box. 2.6.21-rc4 works fine. > Ideas on where to start ? Bisect ? > > Thanks, > Badari > > .. > ReiserFS: hda2: found reiserfs format "3.6" with standard journal > ReiserFS: hda2: using ordered data mode > ReiserFS: hda2: journal params: device hda2, size 8192, journal first > block 18, max trans len 1024, max batch 900, max commit age 30, max > trans age 30 > ReiserFS: hda2: checking transaction log (hda2) > ReiserFS: hda2: Using r5 hash to sort names > VFS: Mounted root (reiserfs filesystem) readonly. > Freeing unused kernel memory: 376k freed > INIT: version 2.86 booting > Unable to handle kernel NULL pointer dereference at 0020 > RIP: > [] __sched_text_start+0x460/0x889 > PGD 1c1898067 PUD 1c1897067 PMD 0 > Oops: [1] SMP > last sysfs file: block/hda/range > CPU 3 > Modules linked in: > Pid: 900, comm: boot Not tainted 2.6.21-rc4-mm1 #1 > RIP: 0010:[] [] __sched_text_start This is a very popular oops, caused by the rsdl scheduler. I don't _think_ we yet know exactly why it is happening. Con, did you get to the bottom of this? We don't know why it confused kallsyms either. I'll try to shove rc5-mm1 out the door this evening, minus rsdl. And -mm2, with rsdl. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > Panics my x86-64 box. 2.6.21-rc4 works fine. Ideas on where to start ? Bisect ? Thanks, Badari .. ReiserFS: hda2: found reiserfs format "3.6" with standard journal ReiserFS: hda2: using ordered data mode ReiserFS: hda2: journal params: device hda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda2: checking transaction log (hda2) ReiserFS: hda2: Using r5 hash to sort names VFS: Mounted root (reiserfs filesystem) readonly. Freeing unused kernel memory: 376k freed INIT: version 2.86 booting Unable to handle kernel NULL pointer dereference at 0020 RIP: [] __sched_text_start+0x460/0x889 PGD 1c1898067 PUD 1c1897067 PMD 0 Oops: [1] SMP last sysfs file: block/hda/range CPU 3 Modules linked in: Pid: 900, comm: boot Not tainted 2.6.21-rc4-mm1 #1 RIP: 0010:[] [] __sched_text_start +0x460/0x889 RSP: 0018:8101014dfee0 EFLAGS: 00010086 RAX: 0001 RBX: 8101c0010218 RCX: RDX: 8101c0010ae8 RSI: RDI: ffd0 RBP: 8101014dff70 R08: 008c R09: 8101c0010ad8 R10: 001c R11: 802099be R12: 8101c000f780 R13: 0001 R14: 000a7bcffd6e R15: 0003 FS: 2b9ef1d40ae0() GS:8101c07b6e40() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0020 CR3: 000100f8d000 CR4: 06e0 Process boot (pid: 900, threadinfo 8101014de000, task 8101014dd490) Stack: 038c802848cf 8101014dfef8 80238d82 8101014dd490 ffd0 8101014dd630 7fffb955ff80 7fffb9560090 802099be 8101014dff48 Call Trace: [] recalc_sigpending+0x12/0x20 [] system_call+0x7e/0x83 [] sys_clone+0x23/0x30 [] sysret_careful+0xd/0x10 Code: 48 39 47 50 74 38 48 c7 47 40 00 00 00 00 48 63 56 f4 49 8b RIP [] __sched_text_start+0x460/0x889 RSP CR2: 0020 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Fri, 23 Mar 2007 00:27:09 +0100, "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > > > > Is anybody having problems with optical drives and this kernel ? > I can't get my dvdrw to spit any events to udevmonitor. If I mount it > manually everything works fine. > > Perhaps the problem is in hal/g-v-m or anything else, but I suppose that > udevmonitor receives events directly from kernel, isn't it ? > Finally, this was a userspace problem (hal): http://lists.freedesktop.org/archives/hal/2007-March/007545.html What I don't understand is this: I supposed that udev (and so udevmonitor) is independent of hal, more or less hal monitors udev events and does things, like looking the disc label and so on. But I do not get any events in udevmonitor if I'm not logged in gnome. How's this ? TIA -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong IDE cable detection in libata [Re: 2.6.21-rc4-mm1]
On Mon, 26 Mar 2007 20:01:52 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > J.A. Magallón wrote: > > Libata seems to misdetect my cable. > > I have double-checked and the cable is 80 pin... > > Does the following patch fix your problem? > > http://article.gmane.org/gmane.linux.ide/17444 > > (You can get the raw message by appending /raw to the URL). > Yes it works !! Disk is back at nice speed of 50 Mb/s. dmesg: ata_piix :00:1f.1: version 2.10ac1 ACPI: PCI Interrupt :00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18 PCI: Setting latency timer of device :00:1f.1 to 64 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 scsi0 : ata_piix ata1.00: ATAPI, max UDMA/33 ata1.01: ATAPI, max MWDMA0, CDB intr ata1.00: configured for UDMA/33 ata1.01: configured for PIO3 scsi1 : ata_piix ata2.00: ATA-6: ST3120022A, 3.06, max UDMA/100 ata2.00: 234441648 sectors, multi 16: LBA48 ata2.01: ATAPI, max UDMA/33 ata2.00: configured for UDMA/100<= ata2.01: configured for UDMA/33 <= Thanks !! -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Hi Badari, On Mon, 26 Mar 2007 12:05:56 -0800, Badari Pulavarty wrote: > On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > > # make -j8 modules > CHK include/linux/version.h > CHK include/linux/utsrelease.h > LD [M] sound/soundcore.o > CC [M] sound/ppc/beep.o > sound/ppc/beep.c: In function ‘snd_pmac_attach_beep’: > sound/ppc/beep.c:224: error: dereferencing pointer to incomplete type > sound/ppc/beep.c:242: error: dereferencing pointer to incomplete type > sound/ppc/beep.c:265: error: dereferencing pointer to incomplete type > sound/ppc/beep.c: In function ‘snd_pmac_detach_beep’: > sound/ppc/beep.c:275: error: dereferencing pointer to incomplete type > make[2]: *** [sound/ppc/beep.o] Error 1 > make[1]: *** [sound/ppc] Error 2 > make: *** [sound] Error 2 > make: *** Waiting for unfinished jobs > > > Patch that is causing the problem in -mm: > gregkh-pci-pci-cleanup-the-includes-of-linux-pcih.patch > > sound/ppc/beep.c needs to include Good catch, thanks for reporting. I expected a few false positives to be left in my patch, but couldn't test everything. Greg, please update your copy with this version of the patch. The only change is that sound/ppc/beep.c is removed from the patch. * * * * * I noticed that many source files include while they do not appear to need it. Here is an attempt to clean it all up. In order to find all possibly affected files, I searched for all files including but without any other occurence of "pci" or "PCI". I removed the include statement from all of these, then I compiled an allmodconfig kernel on both i386 and x86_64 and fixed the false positives manually. My tests covered 66% of the affected files, so there could be false positives remaining. Untested files are: arch/alpha/kernel/err_common.c arch/alpha/kernel/err_ev6.c arch/alpha/kernel/err_ev7.c arch/ia64/sn/kernel/huberror.c arch/ia64/sn/kernel/xpnet.c arch/m68knommu/kernel/dma.c arch/mips/lib/iomap.c arch/powerpc/platforms/pseries/ras.c arch/ppc/8260_io/enet.c arch/ppc/8260_io/fcc_enet.c arch/ppc/8xx_io/enet.c arch/ppc/syslib/ppc4xx_sgdma.c arch/sh64/mach-cayman/iomap.c arch/xtensa/kernel/xtensa_ksyms.c arch/xtensa/platform-iss/setup.c drivers/i2c/busses/i2c-at91.c drivers/i2c/busses/i2c-mpc.c drivers/media/video/saa711x.c drivers/misc/hdpuftrs/hdpu_cpustate.c drivers/misc/hdpuftrs/hdpu_nexus.c drivers/net/au1000_eth.c drivers/net/fec_8xx/fec_main.c drivers/net/fec_8xx/fec_mii.c drivers/net/fs_enet/fs_enet-main.c drivers/net/fs_enet/mac-fcc.c drivers/net/fs_enet/mac-fec.c drivers/net/fs_enet/mac-scc.c drivers/net/fs_enet/mii-bitbang.c drivers/net/fs_enet/mii-fec.c drivers/net/ibm_emac/ibm_emac_core.c drivers/net/lasi_82596.c drivers/parisc/hppb.c drivers/sbus/sbus.c drivers/video/g364fb.c drivers/video/platinumfb.c drivers/video/stifb.c drivers/video/valkyriefb.c include/asm-arm/arch-ixp4xx/dma.h sound/oss/au1550_ac97.c I would welcome test reports for these files. I am fine with removing the untested files from the patch if the general opinion is that these changes aren't safe. The tested part would still be nice to have. Note that this patch depends on another header fixup patch I submitted to LKML yesterday: [PATCH] scatterlist.h needs types.h http://lkml.org/lkml/2007/3/01/141 Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> --- arch/alpha/kernel/err_common.c |1 - arch/alpha/kernel/err_ev6.c |1 - arch/alpha/kernel/err_ev7.c |1 - arch/i386/kernel/cpu/cpufreq/speedstep-lib.c |1 - arch/i386/kernel/cpu/cpufreq/speedstep-smi.c |2 +- arch/ia64/sn/kernel/huberror.c |1 - arch/ia64/sn/kernel/xpnet.c |1 - arch/m68knommu/kernel/dma.c |1 - arch/mips/lib/iomap.c|1 - arch/powerpc/platforms/pseries/ras.c |1 - arch/ppc/8260_io/enet.c |1 - arch/ppc/8260_io/fcc_enet.c |1 - arch/ppc/8xx_io/enet.c |1 - arch/ppc/syslib/ppc4xx_sgdma.c |1 - arch/sh64/mach-cayman/iomap.c|1 - arch/xtensa/kernel/xtensa_ksyms.c|1 - arch/xtensa/platform-iss/setup.c |1 - drivers/ata/pata_winbond.c |1 - drivers/atm/adummy.c |1 - drivers/char/hw_random/via-rng.c |1 - drivers/char/pcmcia/synclink_cs.c|1 - drivers/char/tpm/tpm.h |1 - drivers/char/watchdog/sc1200wdt.c|1 - drivers/char/watchdog/scx200_wdt.c |2 +- drivers/i2c/busses/i2c-at91.c|1 - drivers/i2c/busses/i2c-mpc.c |1 -
Re: 2.6.21-rc4-mm1
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ # make -j8 modules CHK include/linux/version.h CHK include/linux/utsrelease.h LD [M] sound/soundcore.o CC [M] sound/ppc/beep.o sound/ppc/beep.c: In function ‘snd_pmac_attach_beep’: sound/ppc/beep.c:224: error: dereferencing pointer to incomplete type sound/ppc/beep.c:242: error: dereferencing pointer to incomplete type sound/ppc/beep.c:265: error: dereferencing pointer to incomplete type sound/ppc/beep.c: In function ‘snd_pmac_detach_beep’: sound/ppc/beep.c:275: error: dereferencing pointer to incomplete type make[2]: *** [sound/ppc/beep.o] Error 1 make[1]: *** [sound/ppc] Error 2 make: *** [sound] Error 2 make: *** Waiting for unfinished jobs Patch that is causing the problem in -mm: gregkh-pci-pci-cleanup-the-includes-of-linux-pcih.patch sound/ppc/beep.c needs to include Thanks, Badari - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > CC arch/powerpc/kernel/ibmebus.o arch/powerpc/kernel/ibmebus.c:463: error: ‘of_device_uevent’ undeclared here (not in a function) make[1]: *** [arch/powerpc/kernel/ibmebus.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 Patch causing the problem in -mm: ibmebus-uevent-support.patch I don't see where ‘of_device_uevent’ is defined :( Thanks, Badari - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong IDE cable detection in libata [Re: 2.6.21-rc4-mm1]
J.A. Magallón wrote: > Libata seems to misdetect my cable. > I have double-checked and the cable is 80 pin... Does the following patch fix your problem? http://article.gmane.org/gmane.linux.ide/17444 (You can get the raw message by appending /raw to the URL). -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 26 Mar 2007 12:34:33 +0200 Eric Rannaud <[EMAIL PROTECTED]> wrote: > On Mon, Mar 26, 2007 at 01:22:32AM -0800, Andrew Morton wrote: > > On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck <[EMAIL PROTECTED]> wrote: > > > > If so, do you think I should labour on with > > > > uevent-improve-error-checking-and-handling.patch plus your fix, or > > > > should I > > > > drop the lot? (I'm inclined toward the latter, but I'm still not > > > > sure which patch(es) need to be dropped). > > > > > > This depends on what semantics uevent returning an error code should > > > have. The firmware code was using it to suppress uevents, but > > > uevent_suppress is a better idea now. So if we want uevent returning != > > > 0 to imply "something really bad happened", all uevent functions have > > > to be audited and those that work like firmware_uevent have to be > > > converted to uevent_suppress. This would be cleaner, but I'm not sure > > > it's worth the work. > > > > We're generally struggling to stay alive amongst all the bugs at present - > > I'll drop all those patches. > > My mistake, I wrote the guilty patch > uevent-improve-error-checking-and-handling.patch assuming it was safe to > treat the return value as an error code, since several uevent functions > returns things like -ENOMEM. > > Should I rework the patch as Cornelia suggests and resubmit later, when > things have settled down a little? Sure, when we've fixed all the bugs ;) I think we now know what to test for - firmware loading simply collapsed all over the place with these changes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, Mar 26, 2007 at 01:22:32AM -0800, Andrew Morton wrote: > On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck <[EMAIL PROTECTED]> wrote: > > > If so, do you think I should labour on with > > > uevent-improve-error-checking-and-handling.patch plus your fix, or should > > > I > > > drop the lot? (I'm inclined toward the latter, but I'm still not > > > sure which patch(es) need to be dropped). > > > > This depends on what semantics uevent returning an error code should > > have. The firmware code was using it to suppress uevents, but > > uevent_suppress is a better idea now. So if we want uevent returning != > > 0 to imply "something really bad happened", all uevent functions have > > to be audited and those that work like firmware_uevent have to be > > converted to uevent_suppress. This would be cleaner, but I'm not sure > > it's worth the work. > > We're generally struggling to stay alive amongst all the bugs at present - > I'll drop all those patches. My mistake, I wrote the guilty patch uevent-improve-error-checking-and-handling.patch assuming it was safe to treat the return value as an error code, since several uevent functions returns things like -ENOMEM. Should I rework the patch as Cornelia suggests and resubmit later, when things have settled down a little? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck <[EMAIL PROTECTED]> wrote: > On Fri, 23 Mar 2007 21:06:18 -0800, > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Would I be right in guessing that this was all triggered by > > uevent-improve-error-checking-and-handling.patch? > > Looks like it, since it passed the uevent failures to the upper layer. OK, thanks. > > If so, do you think I should labour on with > > uevent-improve-error-checking-and-handling.patch plus your fix, or should I > > drop the lot? (I'm inclined toward the latter, but I'm still not > > sure which patch(es) need to be dropped). > > This depends on what semantics uevent returning an error code should > have. The firmware code was using it to suppress uevents, but > uevent_suppress is a better idea now. So if we want uevent returning != > 0 to imply "something really bad happened", all uevent functions have > to be audited and those that work like firmware_uevent have to be > converted to uevent_suppress. This would be cleaner, but I'm not sure > it's worth the work. We're generally struggling to stay alive amongst all the bugs at present - I'll drop all those patches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Fri, 23 Mar 2007 21:06:18 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > Would I be right in guessing that this was all triggered by > uevent-improve-error-checking-and-handling.patch? Looks like it, since it passed the uevent failures to the upper layer. > If so, do you think I should labour on with > uevent-improve-error-checking-and-handling.patch plus your fix, or should I > drop the lot? (I'm inclined toward the latter, but I'm still not > sure which patch(es) need to be dropped). This depends on what semantics uevent returning an error code should have. The firmware code was using it to suppress uevents, but uevent_suppress is a better idea now. So if we want uevent returning != 0 to imply "something really bad happened", all uevent functions have to be audited and those that work like firmware_uevent have to be converted to uevent_suppress. This would be cleaner, but I'm not sure it's worth the work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Fri, 23 Mar 2007 21:06:18 -0800, Andrew Morton [EMAIL PROTECTED] wrote: Would I be right in guessing that this was all triggered by uevent-improve-error-checking-and-handling.patch? Looks like it, since it passed the uevent failures to the upper layer. If so, do you think I should labour on with uevent-improve-error-checking-and-handling.patch plus your fix, or should I drop the lot? (I'm inclined toward the latter, but I'm still not sure which patch(es) need to be dropped). This depends on what semantics uevent returning an error code should have. The firmware code was using it to suppress uevents, but uevent_suppress is a better idea now. So if we want uevent returning != 0 to imply something really bad happened, all uevent functions have to be audited and those that work like firmware_uevent have to be converted to uevent_suppress. This would be cleaner, but I'm not sure it's worth the work. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck [EMAIL PROTECTED] wrote: On Fri, 23 Mar 2007 21:06:18 -0800, Andrew Morton [EMAIL PROTECTED] wrote: Would I be right in guessing that this was all triggered by uevent-improve-error-checking-and-handling.patch? Looks like it, since it passed the uevent failures to the upper layer. OK, thanks. If so, do you think I should labour on with uevent-improve-error-checking-and-handling.patch plus your fix, or should I drop the lot? (I'm inclined toward the latter, but I'm still not sure which patch(es) need to be dropped). This depends on what semantics uevent returning an error code should have. The firmware code was using it to suppress uevents, but uevent_suppress is a better idea now. So if we want uevent returning != 0 to imply something really bad happened, all uevent functions have to be audited and those that work like firmware_uevent have to be converted to uevent_suppress. This would be cleaner, but I'm not sure it's worth the work. We're generally struggling to stay alive amongst all the bugs at present - I'll drop all those patches. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, Mar 26, 2007 at 01:22:32AM -0800, Andrew Morton wrote: On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck [EMAIL PROTECTED] wrote: If so, do you think I should labour on with uevent-improve-error-checking-and-handling.patch plus your fix, or should I drop the lot? (I'm inclined toward the latter, but I'm still not sure which patch(es) need to be dropped). This depends on what semantics uevent returning an error code should have. The firmware code was using it to suppress uevents, but uevent_suppress is a better idea now. So if we want uevent returning != 0 to imply something really bad happened, all uevent functions have to be audited and those that work like firmware_uevent have to be converted to uevent_suppress. This would be cleaner, but I'm not sure it's worth the work. We're generally struggling to stay alive amongst all the bugs at present - I'll drop all those patches. My mistake, I wrote the guilty patch uevent-improve-error-checking-and-handling.patch assuming it was safe to treat the return value as an error code, since several uevent functions returns things like -ENOMEM. Should I rework the patch as Cornelia suggests and resubmit later, when things have settled down a little? Thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 26 Mar 2007 12:34:33 +0200 Eric Rannaud [EMAIL PROTECTED] wrote: On Mon, Mar 26, 2007 at 01:22:32AM -0800, Andrew Morton wrote: On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck [EMAIL PROTECTED] wrote: If so, do you think I should labour on with uevent-improve-error-checking-and-handling.patch plus your fix, or should I drop the lot? (I'm inclined toward the latter, but I'm still not sure which patch(es) need to be dropped). This depends on what semantics uevent returning an error code should have. The firmware code was using it to suppress uevents, but uevent_suppress is a better idea now. So if we want uevent returning != 0 to imply something really bad happened, all uevent functions have to be audited and those that work like firmware_uevent have to be converted to uevent_suppress. This would be cleaner, but I'm not sure it's worth the work. We're generally struggling to stay alive amongst all the bugs at present - I'll drop all those patches. My mistake, I wrote the guilty patch uevent-improve-error-checking-and-handling.patch assuming it was safe to treat the return value as an error code, since several uevent functions returns things like -ENOMEM. Should I rework the patch as Cornelia suggests and resubmit later, when things have settled down a little? Sure, when we've fixed all the bugs ;) I think we now know what to test for - firmware loading simply collapsed all over the place with these changes. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong IDE cable detection in libata [Re: 2.6.21-rc4-mm1]
J.A. Magallón wrote: Libata seems to misdetect my cable. I have double-checked and the cable is 80 pin... Does the following patch fix your problem? http://article.gmane.org/gmane.linux.ide/17444 (You can get the raw message by appending /raw to the URL). -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ CC arch/powerpc/kernel/ibmebus.o arch/powerpc/kernel/ibmebus.c:463: error: ‘of_device_uevent’ undeclared here (not in a function) make[1]: *** [arch/powerpc/kernel/ibmebus.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 Patch causing the problem in -mm: ibmebus-uevent-support.patch I don't see where ‘of_device_uevent’ is defined :( Thanks, Badari - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ # make -j8 modules CHK include/linux/version.h CHK include/linux/utsrelease.h LD [M] sound/soundcore.o CC [M] sound/ppc/beep.o sound/ppc/beep.c: In function ‘snd_pmac_attach_beep’: sound/ppc/beep.c:224: error: dereferencing pointer to incomplete type sound/ppc/beep.c:242: error: dereferencing pointer to incomplete type sound/ppc/beep.c:265: error: dereferencing pointer to incomplete type sound/ppc/beep.c: In function ‘snd_pmac_detach_beep’: sound/ppc/beep.c:275: error: dereferencing pointer to incomplete type make[2]: *** [sound/ppc/beep.o] Error 1 make[1]: *** [sound/ppc] Error 2 make: *** [sound] Error 2 make: *** Waiting for unfinished jobs Patch that is causing the problem in -mm: gregkh-pci-pci-cleanup-the-includes-of-linux-pcih.patch sound/ppc/beep.c needs to include linux/pci.h Thanks, Badari - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Hi Badari, On Mon, 26 Mar 2007 12:05:56 -0800, Badari Pulavarty wrote: On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ # make -j8 modules CHK include/linux/version.h CHK include/linux/utsrelease.h LD [M] sound/soundcore.o CC [M] sound/ppc/beep.o sound/ppc/beep.c: In function ‘snd_pmac_attach_beep’: sound/ppc/beep.c:224: error: dereferencing pointer to incomplete type sound/ppc/beep.c:242: error: dereferencing pointer to incomplete type sound/ppc/beep.c:265: error: dereferencing pointer to incomplete type sound/ppc/beep.c: In function ‘snd_pmac_detach_beep’: sound/ppc/beep.c:275: error: dereferencing pointer to incomplete type make[2]: *** [sound/ppc/beep.o] Error 1 make[1]: *** [sound/ppc] Error 2 make: *** [sound] Error 2 make: *** Waiting for unfinished jobs Patch that is causing the problem in -mm: gregkh-pci-pci-cleanup-the-includes-of-linux-pcih.patch sound/ppc/beep.c needs to include linux/pci.h Good catch, thanks for reporting. I expected a few false positives to be left in my patch, but couldn't test everything. Greg, please update your copy with this version of the patch. The only change is that sound/ppc/beep.c is removed from the patch. * * * * * I noticed that many source files include linux/pci.h while they do not appear to need it. Here is an attempt to clean it all up. In order to find all possibly affected files, I searched for all files including linux/pci.h but without any other occurence of pci or PCI. I removed the include statement from all of these, then I compiled an allmodconfig kernel on both i386 and x86_64 and fixed the false positives manually. My tests covered 66% of the affected files, so there could be false positives remaining. Untested files are: arch/alpha/kernel/err_common.c arch/alpha/kernel/err_ev6.c arch/alpha/kernel/err_ev7.c arch/ia64/sn/kernel/huberror.c arch/ia64/sn/kernel/xpnet.c arch/m68knommu/kernel/dma.c arch/mips/lib/iomap.c arch/powerpc/platforms/pseries/ras.c arch/ppc/8260_io/enet.c arch/ppc/8260_io/fcc_enet.c arch/ppc/8xx_io/enet.c arch/ppc/syslib/ppc4xx_sgdma.c arch/sh64/mach-cayman/iomap.c arch/xtensa/kernel/xtensa_ksyms.c arch/xtensa/platform-iss/setup.c drivers/i2c/busses/i2c-at91.c drivers/i2c/busses/i2c-mpc.c drivers/media/video/saa711x.c drivers/misc/hdpuftrs/hdpu_cpustate.c drivers/misc/hdpuftrs/hdpu_nexus.c drivers/net/au1000_eth.c drivers/net/fec_8xx/fec_main.c drivers/net/fec_8xx/fec_mii.c drivers/net/fs_enet/fs_enet-main.c drivers/net/fs_enet/mac-fcc.c drivers/net/fs_enet/mac-fec.c drivers/net/fs_enet/mac-scc.c drivers/net/fs_enet/mii-bitbang.c drivers/net/fs_enet/mii-fec.c drivers/net/ibm_emac/ibm_emac_core.c drivers/net/lasi_82596.c drivers/parisc/hppb.c drivers/sbus/sbus.c drivers/video/g364fb.c drivers/video/platinumfb.c drivers/video/stifb.c drivers/video/valkyriefb.c include/asm-arm/arch-ixp4xx/dma.h sound/oss/au1550_ac97.c I would welcome test reports for these files. I am fine with removing the untested files from the patch if the general opinion is that these changes aren't safe. The tested part would still be nice to have. Note that this patch depends on another header fixup patch I submitted to LKML yesterday: [PATCH] scatterlist.h needs types.h http://lkml.org/lkml/2007/3/01/141 Signed-off-by: Jean Delvare [EMAIL PROTECTED] --- arch/alpha/kernel/err_common.c |1 - arch/alpha/kernel/err_ev6.c |1 - arch/alpha/kernel/err_ev7.c |1 - arch/i386/kernel/cpu/cpufreq/speedstep-lib.c |1 - arch/i386/kernel/cpu/cpufreq/speedstep-smi.c |2 +- arch/ia64/sn/kernel/huberror.c |1 - arch/ia64/sn/kernel/xpnet.c |1 - arch/m68knommu/kernel/dma.c |1 - arch/mips/lib/iomap.c|1 - arch/powerpc/platforms/pseries/ras.c |1 - arch/ppc/8260_io/enet.c |1 - arch/ppc/8260_io/fcc_enet.c |1 - arch/ppc/8xx_io/enet.c |1 - arch/ppc/syslib/ppc4xx_sgdma.c |1 - arch/sh64/mach-cayman/iomap.c|1 - arch/xtensa/kernel/xtensa_ksyms.c|1 - arch/xtensa/platform-iss/setup.c |1 - drivers/ata/pata_winbond.c |1 - drivers/atm/adummy.c |1 - drivers/char/hw_random/via-rng.c |1 - drivers/char/pcmcia/synclink_cs.c|1 - drivers/char/tpm/tpm.h |1 - drivers/char/watchdog/sc1200wdt.c|1 - drivers/char/watchdog/scx200_wdt.c |2 +- drivers/i2c/busses/i2c-at91.c|1 - drivers/i2c/busses/i2c-mpc.c |1 - drivers/i2c/busses/i2c-pca-isa.c
Re: 2.6.21-rc4-mm1
On Fri, 23 Mar 2007 00:27:09 +0100, J.A. Magallón [EMAIL PROTECTED] wrote: On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton [EMAIL PROTECTED] wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ Is anybody having problems with optical drives and this kernel ? I can't get my dvdrw to spit any events to udevmonitor. If I mount it manually everything works fine. Perhaps the problem is in hal/g-v-m or anything else, but I suppose that udevmonitor receives events directly from kernel, isn't it ? Finally, this was a userspace problem (hal): http://lists.freedesktop.org/archives/hal/2007-March/007545.html What I don't understand is this: I supposed that udev (and so udevmonitor) is independent of hal, more or less hal monitors udev events and does things, like looking the disc label and so on. But I do not get any events in udevmonitor if I'm not logged in gnome. How's this ? TIA -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ Panics my x86-64 box. 2.6.21-rc4 works fine. Ideas on where to start ? Bisect ? Thanks, Badari .. ReiserFS: hda2: found reiserfs format 3.6 with standard journal ReiserFS: hda2: using ordered data mode ReiserFS: hda2: journal params: device hda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda2: checking transaction log (hda2) ReiserFS: hda2: Using r5 hash to sort names VFS: Mounted root (reiserfs filesystem) readonly. Freeing unused kernel memory: 376k freed INIT: version 2.86 booting Unable to handle kernel NULL pointer dereference at 0020 RIP: [804ec090] __sched_text_start+0x460/0x889 PGD 1c1898067 PUD 1c1897067 PMD 0 Oops: [1] SMP last sysfs file: block/hda/range CPU 3 Modules linked in: Pid: 900, comm: boot Not tainted 2.6.21-rc4-mm1 #1 RIP: 0010:[804ec090] [804ec090] __sched_text_start +0x460/0x889 RSP: 0018:8101014dfee0 EFLAGS: 00010086 RAX: 0001 RBX: 8101c0010218 RCX: RDX: 8101c0010ae8 RSI: RDI: ffd0 RBP: 8101014dff70 R08: 008c R09: 8101c0010ad8 R10: 001c R11: 802099be R12: 8101c000f780 R13: 0001 R14: 000a7bcffd6e R15: 0003 FS: 2b9ef1d40ae0() GS:8101c07b6e40() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0020 CR3: 000100f8d000 CR4: 06e0 Process boot (pid: 900, threadinfo 8101014de000, task 8101014dd490) Stack: 038c802848cf 8101014dfef8 80238d82 8101014dd490 ffd0 8101014dd630 7fffb955ff80 7fffb9560090 802099be 8101014dff48 Call Trace: [80238d82] recalc_sigpending+0x12/0x20 [802099be] system_call+0x7e/0x83 [80207ef3] sys_clone+0x23/0x30 [80209a28] sysret_careful+0xd/0x10 Code: 48 39 47 50 74 38 48 c7 47 40 00 00 00 00 48 63 56 f4 49 8b RIP [804ec090] __sched_text_start+0x460/0x889 RSP 8101014dfee0 CR2: 0020 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong IDE cable detection in libata [Re: 2.6.21-rc4-mm1]
On Mon, 26 Mar 2007 20:01:52 +0900, Tejun Heo [EMAIL PROTECTED] wrote: J.A. Magallón wrote: Libata seems to misdetect my cable. I have double-checked and the cable is 80 pin... Does the following patch fix your problem? http://article.gmane.org/gmane.linux.ide/17444 (You can get the raw message by appending /raw to the URL). Yes it works !! Disk is back at nice speed of 50 Mb/s. dmesg: ata_piix :00:1f.1: version 2.10ac1 ACPI: PCI Interrupt :00:1f.1[A] - GSI 18 (level, low) - IRQ 18 PCI: Setting latency timer of device :00:1f.1 to 64 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 scsi0 : ata_piix ata1.00: ATAPI, max UDMA/33 ata1.01: ATAPI, max MWDMA0, CDB intr ata1.00: configured for UDMA/33 ata1.01: configured for PIO3 scsi1 : ata_piix ata2.00: ATA-6: ST3120022A, 3.06, max UDMA/100 ata2.00: 234441648 sectors, multi 16: LBA48 ata2.01: ATAPI, max UDMA/33 ata2.00: configured for UDMA/100= ata2.01: configured for UDMA/33 = Thanks !! -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 26 Mar 2007 13:57:57 -0800 Badari Pulavarty [EMAIL PROTECTED] wrote: On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ Panics my x86-64 box. 2.6.21-rc4 works fine. Ideas on where to start ? Bisect ? Thanks, Badari .. ReiserFS: hda2: found reiserfs format 3.6 with standard journal ReiserFS: hda2: using ordered data mode ReiserFS: hda2: journal params: device hda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda2: checking transaction log (hda2) ReiserFS: hda2: Using r5 hash to sort names VFS: Mounted root (reiserfs filesystem) readonly. Freeing unused kernel memory: 376k freed INIT: version 2.86 booting Unable to handle kernel NULL pointer dereference at 0020 RIP: [804ec090] __sched_text_start+0x460/0x889 PGD 1c1898067 PUD 1c1897067 PMD 0 Oops: [1] SMP last sysfs file: block/hda/range CPU 3 Modules linked in: Pid: 900, comm: boot Not tainted 2.6.21-rc4-mm1 #1 RIP: 0010:[804ec090] [804ec090] __sched_text_start This is a very popular oops, caused by the rsdl scheduler. I don't _think_ we yet know exactly why it is happening. Con, did you get to the bottom of this? We don't know why it confused kallsyms either. I'll try to shove rc5-mm1 out the door this evening, minus rsdl. And -mm2, with rsdl. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 2007-03-26 at 15:22 -0700, Andrew Morton wrote:
..
Unable to handle kernel NULL pointer dereference at 0020
RIP:
[804ec090] __sched_text_start+0x460/0x889
PGD 1c1898067 PUD 1c1897067 PMD 0
Oops: [1] SMP
last sysfs file: block/hda/range
CPU 3
Modules linked in:
Pid: 900, comm: boot Not tainted 2.6.21-rc4-mm1 #1
RIP: 0010:[804ec090] [804ec090] __sched_text_start
This is a very popular oops, caused by the rsdl scheduler. I don't _think_
we yet know exactly why it is happening. Con, did you get to the bottom
of this?
We don't know why it confused kallsyms either.
I'll try to shove rc5-mm1 out the door this evening, minus rsdl. And
-mm2, with rsdl.
Okay, my ppc64 box hangs on boot. It could be different. I will wait
till rc5-mm1 for debugging that one.
Thanks,
Badari
...
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
ReiserFS: sda2: found reiserfs format 3.6 with standard journal
ReiserFS: sda2: using ordered data mode
ReiserFS: sda2: journal params: device sda2, size 8192, journal first
block 18, max trans len 1024, max batch 900, max commit age 30, max
trans age 30
ReiserFS: sda2: checking transaction log (sda2)
ReiserFS: sda2: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 272k freed
Warning: unable to open an initial console.
ioctl32(showconsole:1020): Unknown cmd fd(0) cmd(40045432){00} arg
(ffecdb48) on /dev/tty0
ioctl32(showconsole:1048): Unknown cmd fd(0) cmd(40045432){00} arg
(ffb4aad8) on /dev/tty0
PDC20275: IDE controller at PCI slot 0002:d0:01.0
PDC20275: chipset revision 1
PDC20275: PLL input clock is 32814 kHz
PDC20275: 100% native mode on irq 119
ide2: BM-DMA at 0x2eec00-0x2eec07, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0x2eec08-0x2eec0f, BIOS settings: hdg:pio, hdh:pio
scsi 0:0:15:0: Attached scsi generic sg0 type 13
scsi 0:255:255:255: Attached scsi generic sg1 type 31
sd 1:0:4:0: Attached scsi generic sg2 type 0
sd 1:0:5:0: Attached scsi generic sg3 type 0
scsi 1:0:15:0: Attached scsi generic sg4 type 13
scsi 1:255:255:255: Attached scsi generic sg5 type 31
hde: IBM DROM00205, ATAPI CD/DVD-ROM drive
ide2 at 0x2ee400-0x2ee407,0x2edc02 on irq 119
hde: ATAPI 24X DVD-ROM drive, 256kB Cache
Uniform CD-ROM driver Revision: 3.20
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-
[EMAIL PROTECTED]
ioctl32(showconsole:1918): Unknown cmd fd(0) cmd(40045432){00} arg
(fff00ad8) on /dev/tty0
loop: loaded (max 8 devices)
ioctl32(showconsole:2091): Unknown cmd fd(0) cmd(40045432){00} arg
(fff71ae8) on /dev/tty0
Adding 1050616k swap on /dev/sdb2. Priority:-1 extents:1
across:1050616k
ioctl32(showconsole:2137): Unknown cmd fd(0) cmd(40045432){00} arg
(ffdd7b28) on /dev/tty0
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX
audit(1174945021.442:2): audit_pid=2735 old=0 by auid=4294967295
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, Mar 26, 2007 at 09:35:48PM +0200, Jean Delvare wrote: Greg, please update your copy with this version of the patch. The only change is that sound/ppc/beep.c is removed from the patch. Done. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Badari Pulavarty writes: Patch causing the problem in -mm: ibmebus-uevent-support.patch I don't see where $,1rx(Bof_device_uevent$,1ry(B is defined :( That patch depends on another one from Sylvain Munaut that I haven't yet managed to get Ben H. to express an opinion on, and which isn't in -mm. I thought I mentioned that to Andrew, but maybe I only intended to... Paul. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Wrong IDE cable detection in libata [Re: 2.6.21-rc4-mm1]
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > Libata seems to misdetect my cable. I have double-checked and the cable is 80 pin... ata1 is PATA ICH5 bus 1 with DVD-RW + ZIP and 40 pin cable ata2 is PATA ICH5 bus 2 with extra HD + DVD and 80 pin cable ata3 is real SATA ICH5 with boot HD (mm, I chaged bios settings to get the box booting from the SATA disk) werewolf:~# lsscsi [0:0:0:0]cd/dvd HL-DT-ST DVDRAM GSA-H10N JL12 /dev/.tmp-11-0 [0:0:1:0]diskIOMEGA ZIP 250 51.G /dev/sda [1:0:0:0]diskATA ST3120022A 3.06 /dev/sdb [1:0:1:0]cd/dvd TOSHIBA DVD-ROM SD-M1712 1004 /dev/sr1 [2:0:0:0]diskATA ST3200822AS 3.01 /dev/sdc ata_piix :00:1f.1: version 2.10ac1 ACPI: PCI Interrupt :00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18 PCI: Setting latency timer of device :00:1f.1 to 64 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 scsi0 : ata_piix ata1.00: ATAPI, max UDMA/33 ata1.01: ATAPI, max MWDMA0, CDB intr ata1.00: configured for UDMA/33 ata1.01: configured for PIO3 scsi1 : ata_piix ata2.00: ATA-6: ST3120022A, 3.06, max UDMA/100 ata2.00: 234441648 sectors, multi 16: LBA48 ata2.01: ATAPI, max UDMA/33 ata2.00: limited to UDMA/33 due to 40-wire cable<=== ata2.00: configured for UDMA/33 ata2.01: configured for UDMA/33 scsi 0:0:0:0: CD-ROMHL-DT-ST DVDRAM GSA-H10N JL12 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 0:0:0:0: Attached scsi CD-ROM sr0 scsi 0:0:1:0: Direct-Access IOMEGA ZIP 250 51.G PQ: 0 ANSI: 5 sd 0:0:1:0: [sda] Attached SCSI removable disk scsi 1:0:0:0: Direct-Access ATA ST3120022A 3.06 PQ: 0 ANSI: 5 sd 1:0:0:0: [sdb] 234441648 512-byte hardware sectors (120034 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:0: [sdb] 234441648 512-byte hardware sectors (120034 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 1:0:0:0: [sdb] Attached SCSI disk scsi 1:0:1:0: CD-ROMTOSHIBA DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5 sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray sr 1:0:1:0: Attached scsi CD-ROM sr1 Any ideas ? -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Wrong IDE cable detection in libata [Re: 2.6.21-rc4-mm1]
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton [EMAIL PROTECTED] wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Libata seems to misdetect my cable. I have double-checked and the cable is 80 pin... ata1 is PATA ICH5 bus 1 with DVD-RW + ZIP and 40 pin cable ata2 is PATA ICH5 bus 2 with extra HD + DVD and 80 pin cable ata3 is real SATA ICH5 with boot HD (mm, I chaged bios settings to get the box booting from the SATA disk) werewolf:~# lsscsi [0:0:0:0]cd/dvd HL-DT-ST DVDRAM GSA-H10N JL12 /dev/.tmp-11-0 [0:0:1:0]diskIOMEGA ZIP 250 51.G /dev/sda [1:0:0:0]diskATA ST3120022A 3.06 /dev/sdb [1:0:1:0]cd/dvd TOSHIBA DVD-ROM SD-M1712 1004 /dev/sr1 [2:0:0:0]diskATA ST3200822AS 3.01 /dev/sdc ata_piix :00:1f.1: version 2.10ac1 ACPI: PCI Interrupt :00:1f.1[A] - GSI 18 (level, low) - IRQ 18 PCI: Setting latency timer of device :00:1f.1 to 64 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 scsi0 : ata_piix ata1.00: ATAPI, max UDMA/33 ata1.01: ATAPI, max MWDMA0, CDB intr ata1.00: configured for UDMA/33 ata1.01: configured for PIO3 scsi1 : ata_piix ata2.00: ATA-6: ST3120022A, 3.06, max UDMA/100 ata2.00: 234441648 sectors, multi 16: LBA48 ata2.01: ATAPI, max UDMA/33 ata2.00: limited to UDMA/33 due to 40-wire cable=== ata2.00: configured for UDMA/33 ata2.01: configured for UDMA/33 scsi 0:0:0:0: CD-ROMHL-DT-ST DVDRAM GSA-H10N JL12 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 0:0:0:0: Attached scsi CD-ROM sr0 scsi 0:0:1:0: Direct-Access IOMEGA ZIP 250 51.G PQ: 0 ANSI: 5 sd 0:0:1:0: [sda] Attached SCSI removable disk scsi 1:0:0:0: Direct-Access ATA ST3120022A 3.06 PQ: 0 ANSI: 5 sd 1:0:0:0: [sdb] 234441648 512-byte hardware sectors (120034 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:0: [sdb] 234441648 512-byte hardware sectors (120034 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 1:0:0:0: [sdb] Attached SCSI disk scsi 1:0:1:0: CD-ROMTOSHIBA DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5 sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray sr 1:0:1:0: Attached scsi CD-ROM sr1 Any ideas ? -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Wed, Mar 21, 2007 at 11:39:17PM -0800, Andrew Morton wrote: > On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote: > > > With the latest -mm, I'm now getting this: > > > > Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless > > 2200BG Network Connection > > Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected > > value (0) > > Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw > > request_firmware failed: > > Reason -2 > > Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2 > > Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network > > device > > The firmware loading bug is caused by > driver-core-handles-kobject_uevent-failure-while-device_add.patch > > I've uploaded a revert patch to > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/hot-fixes/ For the record, with the following patches: # hotfixes mm-debug-check-for-the-fault-vs-invalidate-race.patch mm-fix-fault-vs-invalidate-race-for-linear-mappings-fix-2.patch mm-fix-fault-vs-invalidate-race-for-linear-mappings-fix.patch revert-driver-core-handles-kobject_uevent-failure-while-device_add.patch tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch ...I just had a boot where firmware loading failed again. rmmod+insmod fixed it. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Wed, Mar 21, 2007 at 11:39:17PM -0800, Andrew Morton wrote: On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall [EMAIL PROTECTED] wrote: With the latest -mm, I'm now getting this: Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected value (0) Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw request_firmware failed: Reason -2 Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2 Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network device The firmware loading bug is caused by driver-core-handles-kobject_uevent-failure-while-device_add.patch I've uploaded a revert patch to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/hot-fixes/ For the record, with the following patches: # hotfixes mm-debug-check-for-the-fault-vs-invalidate-race.patch mm-fix-fault-vs-invalidate-race-for-linear-mappings-fix-2.patch mm-fix-fault-vs-invalidate-race-for-linear-mappings-fix.patch revert-driver-core-handles-kobject_uevent-failure-while-device_add.patch tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch ...I just had a boot where firmware loading failed again. rmmod+insmod fixed it. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Fri, 23 Mar 2007 11:10:29 +0100 Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Thu, 22 Mar 2007 13:55:51 -0500,
> Larry Finger <[EMAIL PROTECTED]> wrote:
>
> > Cornelia Huck wrote:
> > > On Thu, 22 Mar 2007 07:23:06 -0500,
> > >
> > > This would indicate that dev_uevent had been called. But how could
> > > kobject_uevent then return an error without moaning about an uevent()
> > > error code? Maybe the following debug patch could shed some light on
> > > this (all moaning is prefixed with kobject_uevent_env, so it should be
> > > easy to spot)...
> >
> > I applied the debug patch, but I don't see any error codes being returned.
> > This time I also got the
> > General Protection Faults. An excerpt of the log is attached.
>
> Hm, I think I have an idea about what happened.
>
> The firmware class tried to suppress the first KOBJ_ADD uevent by
> returning -ENODEV in firmware_uevent if FW_STATUS_READY was not set.
> This only worked as long as the return code of kobject_uevent was not
> checked in device_add. hack-to-make-wireless-work.patch made that first
> uevent return successfully, but this possible triggered some udev rule
> too early, leading to firmware load failures.
>
> The following (completely untested) patch uses uevent_suppress to stop
> the uevent from being generated during device_add. Does this work for
> you?
>
> ---
> drivers/base/firmware_class.c |2 ++
> 1 file changed, 2 insertions(+)
>
> --- linux-2.6.orig/drivers/base/firmware_class.c
> +++ linux-2.6/drivers/base/firmware_class.c
> @@ -333,6 +333,7 @@ static int fw_register_device(struct dev
> f_dev->parent = device;
> f_dev->class = _class;
> dev_set_drvdata(f_dev, fw_priv);
> + f_dev->uevent_suppress = 1;
> retval = device_register(f_dev);
> if (retval) {
> printk(KERN_ERR "%s: device_register failed\n",
> @@ -385,6 +386,7 @@ static int fw_setup_device(struct firmwa
> set_bit(FW_STATUS_READY, _priv->status);
> else
> set_bit(FW_STATUS_READY_NOHOTPLUG, _priv->status);
> + f_dev->uevent_suppress = 0;
> *dev_p = f_dev;
> goto out;
hm.
Would I be right in guessing that this was all triggered by
uevent-improve-error-checking-and-handling.patch?
If so, do you think I should labour on with
uevent-improve-error-checking-and-handling.patch plus your fix, or should I
drop the lot? (I'm inclined toward the latter, but I'm still not
sure which patch(es) need to be dropped).
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Zan Lynx wrote: > > It may have partly been a problem of having half of softmac and half > devicescape. I'm not entirely sure what udev did. > > I tried a patch for the Sonic Silicon that was posted and I turned off > all the configuration for the softmac driver. > > It isn't crashing right now but 802.11 isn't working either. I may get > a chance this weekend to try some things with it, and some different > firmware sets. That is my experience with a 4311. It does the open authentication and associates, but the WPA authentication step times out and I never get connected. > If the new bcm43xx drivers do not support 802.11b at all and never will, > I missed the documentation. Someone should add that to Kconfig. Yes it should. Until bcm43xx-mac80211 got picked up by -mm, it was only used within the bcm43xx group and that was understood in that circle. It has just been decided that the softmac version of the driver will be renamed bcm4301 and be converted to use mac80211. When bcm43xx-mac80211 goes mainline, bcm4301 will be restricted to 802.11b-only cards. That is the way we will support the older cards. The reason for a separate driver is that the bcm4301 and bcm4303 do not have sufficient memory to run the latest firmware (V4), and bcm43xx-mac80211 only uses that firmware; whereas bcm4301 will use the older V3 firmware. Larry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Friday 23 March 2007 23:28, Andy Whitcroft wrote:
> Andy Whitcroft wrote:
> > Con Kolivas wrote:
> >> On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
> >>> Ok, I have yet a third x86_64 machine is is blowing up with the latest
> >>> 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
> >>> 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels
> >>> so I have just fired off a set of tests across the affected machines on
> >>> that latest hotfix stack plus the RSDL backout and the results should
> >>> be in in the next hour or two.
> >>>
> >>> I think there is a strong correlation between RSDL and these hangs.
> >>> Any suggestions as to the next step.
> >>
> >> Found a nasty in requeue_task
> >> + if (list_empty(old_array->queue + old_prio))
> >> + __clear_bit(old_prio, p->array->prio_bitmap);
> >>
> >> see anything wrong there? I do :P
> >>
> >> I'll queue that up with the other changes pending and hopefully that
> >> will fix your bug.
> >
> > Tests queued with your rdsl-0.33 patch (I am assuming its in there).
> > Will let you know how it looks.
>
> Hmmm, this is good for the original machine (as was 0.32) but not for
> either of the other two. I am seeing panics as below on those two.
This machine seems most sensitive to it (first column):
elm3b6
amd64
newisys
4cpu
config: amd64
Can you throw this debugging patch at it please? The console output might be
very helpful. On top of sched-rsdl-0.33 thanks!
---
kernel/sched.c | 39 +++
1 file changed, 39 insertions(+)
Index: linux-2.6.21-rc4-mm1/kernel/sched.c
===
--- linux-2.6.21-rc4-mm1.orig/kernel/sched.c2007-03-24 08:32:19.0
+1100
+++ linux-2.6.21-rc4-mm1/kernel/sched.c 2007-03-24 08:42:04.0 +1100
@@ -659,6 +659,25 @@ static inline void set_task_entitlement(
p->time_slice = p->quota;
}
+static int debug_rqbitmap(struct rq *rq)
+{
+ struct list_head *queue;
+ int idx = 0, error = 0;
+ struct prio_array *array = rq->active;
+
+ for (idx = 0; idx < MAX_PRIO; idx++) {
+ queue = array->queue + idx;
+ if (!list_empty(queue)) {
+ if (!test_bit(idx, rq->dyn_bitmap)) {
+ __set_bit(idx, rq->dyn_bitmap);
+ error = 1;
+ printk(KERN_ERR "MISSING DYNAMIC BIT %d\n",
idx);
+ }
+ }
+ }
+ return error;
+}
+
/*
* There is no specific hard accounting. The dynamic bits can have
* false positives. rt_tasks can only be on the active queue.
@@ -679,6 +698,7 @@ static void dequeue_task(struct task_str
list_del_init(>run_list);
if (list_empty(p->array->queue + p->prio))
__clear_bit(p->prio, p->array->prio_bitmap);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -797,12 +817,14 @@ static void enqueue_task(struct task_str
{
__enqueue_task(p, rq);
list_add_tail(>run_list, p->array->queue + p->prio);
+ WARN_ON(debug_rqbitmap(rq));
}
static inline void enqueue_task_head(struct task_struct *p, struct rq *rq)
{
__enqueue_task(p, rq);
list_add(>run_list, p->array->queue + p->prio);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -820,6 +842,7 @@ static void requeue_task(struct task_str
__clear_bit(old_prio, old_array->prio_bitmap);
set_dynamic_bit(p, rq);
}
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -906,6 +929,7 @@ static inline void __activate_task(struc
{
enqueue_task(p, rq);
inc_nr_running(p, rq);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -1006,6 +1030,7 @@ static void deactivate_task(struct task_
{
dec_nr_running(p, rq);
dequeue_task(p, rq);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -1718,9 +1743,11 @@ void fastcall wake_up_new_task(struct ta
* Parent and child are on different CPUs, now get the
* parent runqueue to update the parent's ->flags:
*/
+ WARN_ON(debug_rqbitmap(rq));
task_rq_unlock(rq, );
this_rq = task_rq_lock(current, );
}
+ WARN_ON(debug_rqbitmap(this_rq));
task_rq_unlock(this_rq, );
}
@@ -3357,6 +3384,7 @@ static inline void major_prio_rotation(s
rq->dyn_bitmap = rq->active->prio_bitmap;
rq->best_static_prio = MAX_PRIO - 1;
rq->prio_rotation++;
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -3399,6 +3427,8 @@ static inline void rotate_runqueue_prior
}
memset(rq->prio_quota, 0, ARRAY_SIZE(rq->prio_quota));
major_prio_rotation(rq);
+ WARN_ON(debug_rqbitmap(rq));
+
} else {
/* Minor rotation */
new_prio_level = rq->prio_level + 1;
@@ -3409,6 +3439,7 @@ static
Re: 2.6.21-rc4-mm1
On Wed, 2007-03-21 at 11:13 -0500, Larry Finger wrote: > Andrew Morton wrote: > > On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx <[EMAIL PROTECTED]> wrote: > >> First impressions: > >> Several of the same bugs as rc3-mm*: > >> * Freezes immediately if I touch the wlan0 device after loading > >> the new Broadcom wireless driver. > > --snip-- > > >> 02:02.0 Network controller: Broadcom Corporation BCM4303 802.11b Wireless > >> LAN Controller (rev 02) > > I'm a little confused. The bcm43xx-mac80211 driver does not handle 802.11b > devices, and the > bcm43xx-softmac driver should not freeze. Which one was configured here? It may have partly been a problem of having half of softmac and half devicescape. I'm not entirely sure what udev did. I tried a patch for the Sonic Silicon that was posted and I turned off all the configuration for the softmac driver. It isn't crashing right now but 802.11 isn't working either. I may get a chance this weekend to try some things with it, and some different firmware sets. If the new bcm43xx drivers do not support 802.11b at all and never will, I missed the documentation. Someone should add that to Kconfig. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.21-rc4-mm1 + 3 hot-fixes -- WARNING: could not find versions for .tmp_versions/built-in.mod
On Fri, Mar 23, 2007 at 09:54:29PM +0900, Yasunori Goto wrote: > Hello. > > > > WARNING: mm/built-in.o - Section mismatch: reference to > > > .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at > > > offset 0x15c8f) and '__section_nr' > > I took a look at this one. > > You have SPARSEMEM enabled in your config. > > And then I see that in sparse.c we call alloc_bootmem_node() > > from a function I thought should be marked __devinit (it > > is used by memory_hotplug.c). > > But I am not familiar enough to judge if __alloc_bootmen_node > > are marked correct with __init or __devinit (to say > > this is used in the HOTPLUG case) is more correct. > > Anyone? > > > > > WARNING: mm/built-in.o - Section mismatch: reference to > > > .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at > > > offset 0x15d02) and '__section_nr' > > Same as above > > Memory hotplug code has __meminit for its purpose. > But, I suspect that many other places of memory hotplug code may have > same issue. I will chase them. Thanks! > > BTW, does -mm code checks more strict than stock kernel? I can't see > these warnings in 2.6.21-rc4. Yes it does. The included kbuild changes enables proper check of symbols in vmlinux. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.21-rc4-mm1
> > Andy Whitcroft wrote: > > Con Kolivas wrote: > >> On Friday 23 March 2007 05:17, Andy Whitcroft wrote: > >>> Ok, I have yet a third x86_64 machine is is blowing up with the > >>> latest > >>> 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with > >>> 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix > >>> levels so I have just fired off a set of tests across the affected > >>> machines on that latest hotfix stack plus the RSDL backout and the > >>> results should be in in the next hour or two. > >>> > >>> I think there is a strong correlation between RSDL and these hangs. > >>> Any suggestions as to the next step. > >> Found a nasty in requeue_task > >> + if (list_empty(old_array->queue + old_prio)) > >> + __clear_bit(old_prio, p->array->prio_bitmap); > >> > >> see anything wrong there? I do :P > >> > >> I'll queue that up with the other changes pending and hopefully that > >> will fix your bug. > > > > Tests queued with your rdsl-0.33 patch (I am assuming its in there). > > Will let you know how it looks. > > Hmmm, this is good for the original machine (as was 0.32) but > not for either of the other two. I am seeing panics as below > on those two. > > -apw > I don't know if this might help out or even if it is related but I get a "similar" crash every time using my backported rsdl patch on a 2.6.19.7 kernel. "Maybie" this type of BUG might be easier to trigger under that specific kernel? Here is a picture of the output: http://linux-dev.qc.ec.gc.ca/kernel/debian/etch/x86_64/2.6.19/bug-2.6.19 .7-rsdl-033.jpg. - vin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Cornelia Huck wrote: > On Thu, 22 Mar 2007 13:55:51 -0500, > Larry Finger <[EMAIL PROTECTED]> wrote: >> I applied the debug patch, but I don't see any error codes being returned. >> This time I also got the >> General Protection Faults. An excerpt of the log is attached. > > Hm, I think I have an idea about what happened. > > The firmware class tried to suppress the first KOBJ_ADD uevent by > returning -ENODEV in firmware_uevent if FW_STATUS_READY was not set. > This only worked as long as the return code of kobject_uevent was not > checked in device_add. hack-to-make-wireless-work.patch made that first > uevent return successfully, but this possible triggered some udev rule > too early, leading to firmware load failures. > > The following (completely untested) patch uses uevent_suppress to stop > the uevent from being generated during device_add. Does this work for > you? Yes it does. Good job. On my first reboot with the new code, the startup of X hung with the black screen and the big X cursor, but that seems to have been a single occurrence. With the patch, the bcm43xx firmware is loaded and the device is working. Thanks, Larry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1 + 3 hot-fixes -- WARNING: could not find versions for .tmp_versions/built-in.mod
Hello. > > WARNING: mm/built-in.o - Section mismatch: reference to > > .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at > > offset 0x15c8f) and '__section_nr' > I took a look at this one. > You have SPARSEMEM enabled in your config. > And then I see that in sparse.c we call alloc_bootmem_node() > from a function I thought should be marked __devinit (it > is used by memory_hotplug.c). > But I am not familiar enough to judge if __alloc_bootmen_node > are marked correct with __init or __devinit (to say > this is used in the HOTPLUG case) is more correct. > Anyone? > > > WARNING: mm/built-in.o - Section mismatch: reference to > > .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at > > offset 0x15d02) and '__section_nr' > Same as above Memory hotplug code has __meminit for its purpose. But, I suspect that many other places of memory hotplug code may have same issue. I will chase them. BTW, does -mm code checks more strict than stock kernel? I can't see these warnings in 2.6.21-rc4. Bye. -- Yasunori Goto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Andy Whitcroft wrote: > Con Kolivas wrote: >> On Friday 23 March 2007 05:17, Andy Whitcroft wrote: >>> Ok, I have yet a third x86_64 machine is is blowing up with the latest >>> 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with >>> 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels >>> so I have just fired off a set of tests across the affected machines on >>> that latest hotfix stack plus the RSDL backout and the results should be >>> in in the next hour or two. >>> >>> I think there is a strong correlation between RSDL and these hangs. Any >>> suggestions as to the next step. >> Found a nasty in requeue_task >> +if (list_empty(old_array->queue + old_prio)) >> +__clear_bit(old_prio, p->array->prio_bitmap); >> >> see anything wrong there? I do :P >> >> I'll queue that up with the other changes pending and hopefully that will >> fix >> your bug. > > Tests queued with your rdsl-0.33 patch (I am assuming its in there). > Will let you know how it looks. Hmmm, this is good for the original machine (as was 0.32) but not for either of the other two. I am seeing panics as below on those two. -apw elm3b245: NULL pointer dereference at 0020 RIP: [] __sched_text_start+0x424/0x8a5 PGD 0 Oops: [1] SMP last sysfs file: block/ram0/uevent CPU 0 Modules linked in: Pid: 1038, comm: udevd Not tainted 2.6.21-rc4-mm1-autokern1 #1 RIP: 0010:[] [] __sched_text_start+0x424/0x8a5 RSP: 0018:81000316de68 EFLAGS: 00010017 RAX: 06c6 RBX: 0001 RCX: RDX: RSI: 008c RDI: ffd0 RBP: 81000316def8 R08: 0064 R09: 0024 R10: 810001014ad8 R11: 0286 R12: 810001014218 R13: 810001013780 R14: 810001769450 R15: FS: 2b75d89c66d0() GS:805aa000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0020 CR3: 00201000 CR4: 06e0 Process udevd (pid: 1038, threadinfo 81000316c000, task 8100031cebb0) Stack: 0001 8100031cebb0 ffd0 0036e28ef568 8100031ced48 0292 81000316def8 0246 81000316def8 8022af3d Call Trace: [] put_files_struct+0xbd/0xc9 [] do_exit+0x7d2/0x7d6 [] sys_exit_group+0x0/0x14 [] sys_exit_group+0x12/0x14 [] system_call+0x7e/0x83 Code: 48 39 47 50 74 51 48 c7 47 40 00 00 00 00 8b 52 f4 48 b9 40 RIP [] __sched_text_start+0x424/0x8a5 RSP CR2: 0020 Fixing recursive fault but reboot is needed! elm3b6: Unable to handle kernel paging request at fb6c RIP: [] convert_rip_to_linear+0x53/0x91 PGD 180780067 PUD 182242067 PMD 0 Oops: [1] SMP last sysfs file: devices/pci:00/:00:0a.0/:02:04.0/host0/target0:0:6/0:0:6:0/type CPU 0 Modules linked in: Pid: 2442, comm: autorun Not tainted 2.6.21-rc4-mm1-autokern1 #1 RIP: 0010:[] [] convert_rip_to_linear+0x53/0x91 RSP: :810181a53cf8 EFLAGS: 00010002 RAX: fb68 RBX: 810181a53e28 RCX: 8101823d6930 RDX: 8049fb6d RSI: 810182342180 RDI: 810182342440 RBP: 810181a53cf8 R08: 80209bb9 R09: 008c R10: R11: 01200011 R12: R13: 810182342180 R14: 810181a53e28 R15: FS: () GS:805b2000(0063) knlGS:f7f1cb80 CS: 0010 DS: 002b ES: 002b CR0: 8005003b CR2: fb6c CR3: 000181a5b000 CR4: 06e0 Process autorun (pid: 2442, threadinfo 810181a52000, task 8101823d6930) Stack: 810181a53d18 80219075 8101823d84a8 0020 810181a53e18 80219ab4 8101fff654d8 810181a53d48 80264291 8101823d6930 810181a53e28 0046 Call Trace: [] is_prefetch+0x29/0x217 [] do_page_fault+0x608/0x7f0 [] page_dup_rmap+0x1d/0x24 [] search_module_extables+0x83/0x8f [] oops_enter+0xe/0x10 [] oops_begin+0x3c/0x70 [] do_page_fault+0x685/0x7f0 [] task_running_tick+0xad/0x290 [] error_exit+0x0/0x84 [] error_exit+0x0/0x84 [] thread_return+0x22/0xd3 [] int_careful+0xd/0x11 Code: 8b 48 04 0f b7 50 02 0f b6 c1 c1 e0 10 09 c2 89 c8 25 00 00 RIP [] convert_rip_to_linear+0x53/0x91 RSP CR2: fb6c - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Thu, 22 Mar 2007 13:55:51 -0500,
Larry Finger <[EMAIL PROTECTED]> wrote:
> Cornelia Huck wrote:
> > On Thu, 22 Mar 2007 07:23:06 -0500,
> >
> > This would indicate that dev_uevent had been called. But how could
> > kobject_uevent then return an error without moaning about an uevent()
> > error code? Maybe the following debug patch could shed some light on
> > this (all moaning is prefixed with kobject_uevent_env, so it should be
> > easy to spot)...
>
> I applied the debug patch, but I don't see any error codes being returned.
> This time I also got the
> General Protection Faults. An excerpt of the log is attached.
Hm, I think I have an idea about what happened.
The firmware class tried to suppress the first KOBJ_ADD uevent by
returning -ENODEV in firmware_uevent if FW_STATUS_READY was not set.
This only worked as long as the return code of kobject_uevent was not
checked in device_add. hack-to-make-wireless-work.patch made that first
uevent return successfully, but this possible triggered some udev rule
too early, leading to firmware load failures.
The following (completely untested) patch uses uevent_suppress to stop
the uevent from being generated during device_add. Does this work for
you?
---
drivers/base/firmware_class.c |2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.orig/drivers/base/firmware_class.c
+++ linux-2.6/drivers/base/firmware_class.c
@@ -333,6 +333,7 @@ static int fw_register_device(struct dev
f_dev->parent = device;
f_dev->class = _class;
dev_set_drvdata(f_dev, fw_priv);
+ f_dev->uevent_suppress = 1;
retval = device_register(f_dev);
if (retval) {
printk(KERN_ERR "%s: device_register failed\n",
@@ -385,6 +386,7 @@ static int fw_setup_device(struct firmwa
set_bit(FW_STATUS_READY, _priv->status);
else
set_bit(FW_STATUS_READY_NOHOTPLUG, _priv->status);
+ f_dev->uevent_suppress = 0;
*dev_p = f_dev;
goto out;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Con Kolivas wrote: > On Friday 23 March 2007 05:17, Andy Whitcroft wrote: >> Ok, I have yet a third x86_64 machine is is blowing up with the latest >> 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with >> 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels >> so I have just fired off a set of tests across the affected machines on >> that latest hotfix stack plus the RSDL backout and the results should be >> in in the next hour or two. >> >> I think there is a strong correlation between RSDL and these hangs. Any >> suggestions as to the next step. > > Found a nasty in requeue_task > + if (list_empty(old_array->queue + old_prio)) > + __clear_bit(old_prio, p->array->prio_bitmap); > > see anything wrong there? I do :P > > I'll queue that up with the other changes pending and hopefully that will fix > your bug. Tests queued with your rdsl-0.33 patch (I am assuming its in there). Will let you know how it looks. -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Con Kolivas wrote: On Friday 23 March 2007 05:17, Andy Whitcroft wrote: Ok, I have yet a third x86_64 machine is is blowing up with the latest 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels so I have just fired off a set of tests across the affected machines on that latest hotfix stack plus the RSDL backout and the results should be in in the next hour or two. I think there is a strong correlation between RSDL and these hangs. Any suggestions as to the next step. Found a nasty in requeue_task + if (list_empty(old_array-queue + old_prio)) + __clear_bit(old_prio, p-array-prio_bitmap); see anything wrong there? I do :P I'll queue that up with the other changes pending and hopefully that will fix your bug. Tests queued with your rdsl-0.33 patch (I am assuming its in there). Will let you know how it looks. -apw - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Thu, 22 Mar 2007 13:55:51 -0500,
Larry Finger [EMAIL PROTECTED] wrote:
Cornelia Huck wrote:
On Thu, 22 Mar 2007 07:23:06 -0500,
This would indicate that dev_uevent had been called. But how could
kobject_uevent then return an error without moaning about an uevent()
error code? Maybe the following debug patch could shed some light on
this (all moaning is prefixed with kobject_uevent_env, so it should be
easy to spot)...
I applied the debug patch, but I don't see any error codes being returned.
This time I also got the
General Protection Faults. An excerpt of the log is attached.
Hm, I think I have an idea about what happened.
The firmware class tried to suppress the first KOBJ_ADD uevent by
returning -ENODEV in firmware_uevent if FW_STATUS_READY was not set.
This only worked as long as the return code of kobject_uevent was not
checked in device_add. hack-to-make-wireless-work.patch made that first
uevent return successfully, but this possible triggered some udev rule
too early, leading to firmware load failures.
The following (completely untested) patch uses uevent_suppress to stop
the uevent from being generated during device_add. Does this work for
you?
---
drivers/base/firmware_class.c |2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.orig/drivers/base/firmware_class.c
+++ linux-2.6/drivers/base/firmware_class.c
@@ -333,6 +333,7 @@ static int fw_register_device(struct dev
f_dev-parent = device;
f_dev-class = firmware_class;
dev_set_drvdata(f_dev, fw_priv);
+ f_dev-uevent_suppress = 1;
retval = device_register(f_dev);
if (retval) {
printk(KERN_ERR %s: device_register failed\n,
@@ -385,6 +386,7 @@ static int fw_setup_device(struct firmwa
set_bit(FW_STATUS_READY, fw_priv-status);
else
set_bit(FW_STATUS_READY_NOHOTPLUG, fw_priv-status);
+ f_dev-uevent_suppress = 0;
*dev_p = f_dev;
goto out;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Andy Whitcroft wrote: Con Kolivas wrote: On Friday 23 March 2007 05:17, Andy Whitcroft wrote: Ok, I have yet a third x86_64 machine is is blowing up with the latest 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels so I have just fired off a set of tests across the affected machines on that latest hotfix stack plus the RSDL backout and the results should be in in the next hour or two. I think there is a strong correlation between RSDL and these hangs. Any suggestions as to the next step. Found a nasty in requeue_task +if (list_empty(old_array-queue + old_prio)) +__clear_bit(old_prio, p-array-prio_bitmap); see anything wrong there? I do :P I'll queue that up with the other changes pending and hopefully that will fix your bug. Tests queued with your rdsl-0.33 patch (I am assuming its in there). Will let you know how it looks. Hmmm, this is good for the original machine (as was 0.32) but not for either of the other two. I am seeing panics as below on those two. -apw elm3b245: NULL pointer dereference at 0020 RIP: [80497d94] __sched_text_start+0x424/0x8a5 PGD 0 Oops: [1] SMP last sysfs file: block/ram0/uevent CPU 0 Modules linked in: Pid: 1038, comm: udevd Not tainted 2.6.21-rc4-mm1-autokern1 #1 RIP: 0010:[80497d94] [80497d94] __sched_text_start+0x424/0x8a5 RSP: 0018:81000316de68 EFLAGS: 00010017 RAX: 06c6 RBX: 0001 RCX: RDX: RSI: 008c RDI: ffd0 RBP: 81000316def8 R08: 0064 R09: 0024 R10: 810001014ad8 R11: 0286 R12: 810001014218 R13: 810001013780 R14: 810001769450 R15: FS: 2b75d89c66d0() GS:805aa000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0020 CR3: 00201000 CR4: 06e0 Process udevd (pid: 1038, threadinfo 81000316c000, task 8100031cebb0) Stack: 0001 8100031cebb0 ffd0 0036e28ef568 8100031ced48 0292 81000316def8 0246 81000316def8 8022af3d Call Trace: [8022af3d] put_files_struct+0xbd/0xc9 [8022c773] do_exit+0x7d2/0x7d6 [8022c801] sys_exit_group+0x0/0x14 [8022c813] sys_exit_group+0x12/0x14 [8020968e] system_call+0x7e/0x83 Code: 48 39 47 50 74 51 48 c7 47 40 00 00 00 00 8b 52 f4 48 b9 40 RIP [80497d94] __sched_text_start+0x424/0x8a5 RSP 81000316de68 CR2: 0020 Fixing recursive fault but reboot is needed! elm3b6: Unable to handle kernel paging request at fb6c RIP: [8020c573] convert_rip_to_linear+0x53/0x91 PGD 180780067 PUD 182242067 PMD 0 Oops: [1] SMP last sysfs file: devices/pci:00/:00:0a.0/:02:04.0/host0/target0:0:6/0:0:6:0/type CPU 0 Modules linked in: Pid: 2442, comm: autorun Not tainted 2.6.21-rc4-mm1-autokern1 #1 RIP: 0010:[8020c573] [8020c573] convert_rip_to_linear+0x53/0x91 RSP: :810181a53cf8 EFLAGS: 00010002 RAX: fb68 RBX: 810181a53e28 RCX: 8101823d6930 RDX: 8049fb6d RSI: 810182342180 RDI: 810182342440 RBP: 810181a53cf8 R08: 80209bb9 R09: 008c R10: R11: 01200011 R12: R13: 810182342180 R14: 810181a53e28 R15: FS: () GS:805b2000(0063) knlGS:f7f1cb80 CS: 0010 DS: 002b ES: 002b CR0: 8005003b CR2: fb6c CR3: 000181a5b000 CR4: 06e0 Process autorun (pid: 2442, threadinfo 810181a52000, task 8101823d6930) Stack: 810181a53d18 80219075 8101823d84a8 0020 810181a53e18 80219ab4 8101fff654d8 810181a53d48 80264291 8101823d6930 810181a53e28 0046 Call Trace: [80219075] is_prefetch+0x29/0x217 [80219ab4] do_page_fault+0x608/0x7f0 [80264291] page_dup_rmap+0x1d/0x24 [8024567c] search_module_extables+0x83/0x8f [80229b43] oops_enter+0xe/0x10 [8020ae62] oops_begin+0x3c/0x70 [80219b31] do_page_fault+0x685/0x7f0 [8022404d] task_running_tick+0xad/0x290 [8049fb6d] error_exit+0x0/0x84 [8049fb6d] error_exit+0x0/0x84 [8049dc11] thread_return+0x22/0xd3 [80209802] int_careful+0xd/0x11 Code: 8b 48 04 0f b7 50 02 0f b6 c1 c1 e0 10 09 c2 89 c8 25 00 00 RIP [8020c573] convert_rip_to_linear+0x53/0x91 RSP 810181a53cf8 CR2: fb6c - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1 + 3 hot-fixes -- WARNING: could not find versions for .tmp_versions/built-in.mod
Hello. WARNING: mm/built-in.o - Section mismatch: reference to .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at offset 0x15c8f) and '__section_nr' I took a look at this one. You have SPARSEMEM enabled in your config. And then I see that in sparse.c we call alloc_bootmem_node() from a function I thought should be marked __devinit (it is used by memory_hotplug.c). But I am not familiar enough to judge if __alloc_bootmen_node are marked correct with __init or __devinit (to say this is used in the HOTPLUG case) is more correct. Anyone? WARNING: mm/built-in.o - Section mismatch: reference to .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at offset 0x15d02) and '__section_nr' Same as above Memory hotplug code has __meminit for its purpose. But, I suspect that many other places of memory hotplug code may have same issue. I will chase them. BTW, does -mm code checks more strict than stock kernel? I can't see these warnings in 2.6.21-rc4. Bye. -- Yasunori Goto - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Cornelia Huck wrote: On Thu, 22 Mar 2007 13:55:51 -0500, Larry Finger [EMAIL PROTECTED] wrote: I applied the debug patch, but I don't see any error codes being returned. This time I also got the General Protection Faults. An excerpt of the log is attached. Hm, I think I have an idea about what happened. The firmware class tried to suppress the first KOBJ_ADD uevent by returning -ENODEV in firmware_uevent if FW_STATUS_READY was not set. This only worked as long as the return code of kobject_uevent was not checked in device_add. hack-to-make-wireless-work.patch made that first uevent return successfully, but this possible triggered some udev rule too early, leading to firmware load failures. The following (completely untested) patch uses uevent_suppress to stop the uevent from being generated during device_add. Does this work for you? Yes it does. Good job. On my first reboot with the new code, the startup of X hung with the black screen and the big X cursor, but that seems to have been a single occurrence. With the patch, the bcm43xx firmware is loaded and the device is working. Thanks, Larry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.21-rc4-mm1
Andy Whitcroft wrote: Con Kolivas wrote: On Friday 23 March 2007 05:17, Andy Whitcroft wrote: Ok, I have yet a third x86_64 machine is is blowing up with the latest 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels so I have just fired off a set of tests across the affected machines on that latest hotfix stack plus the RSDL backout and the results should be in in the next hour or two. I think there is a strong correlation between RSDL and these hangs. Any suggestions as to the next step. Found a nasty in requeue_task + if (list_empty(old_array-queue + old_prio)) + __clear_bit(old_prio, p-array-prio_bitmap); see anything wrong there? I do :P I'll queue that up with the other changes pending and hopefully that will fix your bug. Tests queued with your rdsl-0.33 patch (I am assuming its in there). Will let you know how it looks. Hmmm, this is good for the original machine (as was 0.32) but not for either of the other two. I am seeing panics as below on those two. -apw I don't know if this might help out or even if it is related but I get a similar crash every time using my backported rsdl patch on a 2.6.19.7 kernel. Maybie this type of BUG might be easier to trigger under that specific kernel? Here is a picture of the output: http://linux-dev.qc.ec.gc.ca/kernel/debian/etch/x86_64/2.6.19/bug-2.6.19 .7-rsdl-033.jpg. - vin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1 + 3 hot-fixes -- WARNING: could not find versions for .tmp_versions/built-in.mod
On Fri, Mar 23, 2007 at 09:54:29PM +0900, Yasunori Goto wrote: Hello. WARNING: mm/built-in.o - Section mismatch: reference to .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at offset 0x15c8f) and '__section_nr' I took a look at this one. You have SPARSEMEM enabled in your config. And then I see that in sparse.c we call alloc_bootmem_node() from a function I thought should be marked __devinit (it is used by memory_hotplug.c). But I am not familiar enough to judge if __alloc_bootmen_node are marked correct with __init or __devinit (to say this is used in the HOTPLUG case) is more correct. Anyone? WARNING: mm/built-in.o - Section mismatch: reference to .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at offset 0x15d02) and '__section_nr' Same as above Memory hotplug code has __meminit for its purpose. But, I suspect that many other places of memory hotplug code may have same issue. I will chase them. Thanks! BTW, does -mm code checks more strict than stock kernel? I can't see these warnings in 2.6.21-rc4. Yes it does. The included kbuild changes enables proper check of symbols in vmlinux. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Wed, 2007-03-21 at 11:13 -0500, Larry Finger wrote: Andrew Morton wrote: On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx [EMAIL PROTECTED] wrote: First impressions: Several of the same bugs as rc3-mm*: * Freezes immediately if I touch the wlan0 device after loading the new Broadcom wireless driver. --snip-- 02:02.0 Network controller: Broadcom Corporation BCM4303 802.11b Wireless LAN Controller (rev 02) I'm a little confused. The bcm43xx-mac80211 driver does not handle 802.11b devices, and the bcm43xx-softmac driver should not freeze. Which one was configured here? It may have partly been a problem of having half of softmac and half devicescape. I'm not entirely sure what udev did. I tried a patch for the Sonic Silicon that was posted and I turned off all the configuration for the softmac driver. It isn't crashing right now but 802.11 isn't working either. I may get a chance this weekend to try some things with it, and some different firmware sets. If the new bcm43xx drivers do not support 802.11b at all and never will, I missed the documentation. Someone should add that to Kconfig. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.21-rc4-mm1
On Friday 23 March 2007 23:28, Andy Whitcroft wrote:
Andy Whitcroft wrote:
Con Kolivas wrote:
On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
Ok, I have yet a third x86_64 machine is is blowing up with the latest
2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels
so I have just fired off a set of tests across the affected machines on
that latest hotfix stack plus the RSDL backout and the results should
be in in the next hour or two.
I think there is a strong correlation between RSDL and these hangs.
Any suggestions as to the next step.
Found a nasty in requeue_task
+ if (list_empty(old_array-queue + old_prio))
+ __clear_bit(old_prio, p-array-prio_bitmap);
see anything wrong there? I do :P
I'll queue that up with the other changes pending and hopefully that
will fix your bug.
Tests queued with your rdsl-0.33 patch (I am assuming its in there).
Will let you know how it looks.
Hmmm, this is good for the original machine (as was 0.32) but not for
either of the other two. I am seeing panics as below on those two.
This machine seems most sensitive to it (first column):
elm3b6
amd64
newisys
4cpu
config: amd64
Can you throw this debugging patch at it please? The console output might be
very helpful. On top of sched-rsdl-0.33 thanks!
---
kernel/sched.c | 39 +++
1 file changed, 39 insertions(+)
Index: linux-2.6.21-rc4-mm1/kernel/sched.c
===
--- linux-2.6.21-rc4-mm1.orig/kernel/sched.c2007-03-24 08:32:19.0
+1100
+++ linux-2.6.21-rc4-mm1/kernel/sched.c 2007-03-24 08:42:04.0 +1100
@@ -659,6 +659,25 @@ static inline void set_task_entitlement(
p-time_slice = p-quota;
}
+static int debug_rqbitmap(struct rq *rq)
+{
+ struct list_head *queue;
+ int idx = 0, error = 0;
+ struct prio_array *array = rq-active;
+
+ for (idx = 0; idx MAX_PRIO; idx++) {
+ queue = array-queue + idx;
+ if (!list_empty(queue)) {
+ if (!test_bit(idx, rq-dyn_bitmap)) {
+ __set_bit(idx, rq-dyn_bitmap);
+ error = 1;
+ printk(KERN_ERR MISSING DYNAMIC BIT %d\n,
idx);
+ }
+ }
+ }
+ return error;
+}
+
/*
* There is no specific hard accounting. The dynamic bits can have
* false positives. rt_tasks can only be on the active queue.
@@ -679,6 +698,7 @@ static void dequeue_task(struct task_str
list_del_init(p-run_list);
if (list_empty(p-array-queue + p-prio))
__clear_bit(p-prio, p-array-prio_bitmap);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -797,12 +817,14 @@ static void enqueue_task(struct task_str
{
__enqueue_task(p, rq);
list_add_tail(p-run_list, p-array-queue + p-prio);
+ WARN_ON(debug_rqbitmap(rq));
}
static inline void enqueue_task_head(struct task_struct *p, struct rq *rq)
{
__enqueue_task(p, rq);
list_add(p-run_list, p-array-queue + p-prio);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -820,6 +842,7 @@ static void requeue_task(struct task_str
__clear_bit(old_prio, old_array-prio_bitmap);
set_dynamic_bit(p, rq);
}
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -906,6 +929,7 @@ static inline void __activate_task(struc
{
enqueue_task(p, rq);
inc_nr_running(p, rq);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -1006,6 +1030,7 @@ static void deactivate_task(struct task_
{
dec_nr_running(p, rq);
dequeue_task(p, rq);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -1718,9 +1743,11 @@ void fastcall wake_up_new_task(struct ta
* Parent and child are on different CPUs, now get the
* parent runqueue to update the parent's -flags:
*/
+ WARN_ON(debug_rqbitmap(rq));
task_rq_unlock(rq, flags);
this_rq = task_rq_lock(current, flags);
}
+ WARN_ON(debug_rqbitmap(this_rq));
task_rq_unlock(this_rq, flags);
}
@@ -3357,6 +3384,7 @@ static inline void major_prio_rotation(s
rq-dyn_bitmap = rq-active-prio_bitmap;
rq-best_static_prio = MAX_PRIO - 1;
rq-prio_rotation++;
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -3399,6 +3427,8 @@ static inline void rotate_runqueue_prior
}
memset(rq-prio_quota, 0, ARRAY_SIZE(rq-prio_quota));
major_prio_rotation(rq);
+ WARN_ON(debug_rqbitmap(rq));
+
} else {
/* Minor rotation */
new_prio_level = rq-prio_level + 1;
@@ -3409,6 +3439,7 @@ static inline void rotate_runqueue_prior
__set_bit(new_prio_level,
Re: 2.6.21-rc4-mm1
Zan Lynx wrote: It may have partly been a problem of having half of softmac and half devicescape. I'm not entirely sure what udev did. I tried a patch for the Sonic Silicon that was posted and I turned off all the configuration for the softmac driver. It isn't crashing right now but 802.11 isn't working either. I may get a chance this weekend to try some things with it, and some different firmware sets. That is my experience with a 4311. It does the open authentication and associates, but the WPA authentication step times out and I never get connected. If the new bcm43xx drivers do not support 802.11b at all and never will, I missed the documentation. Someone should add that to Kconfig. Yes it should. Until bcm43xx-mac80211 got picked up by -mm, it was only used within the bcm43xx group and that was understood in that circle. It has just been decided that the softmac version of the driver will be renamed bcm4301 and be converted to use mac80211. When bcm43xx-mac80211 goes mainline, bcm4301 will be restricted to 802.11b-only cards. That is the way we will support the older cards. The reason for a separate driver is that the bcm4301 and bcm4303 do not have sufficient memory to run the latest firmware (V4), and bcm43xx-mac80211 only uses that firmware; whereas bcm4301 will use the older V3 firmware. Larry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Fri, 23 Mar 2007 11:10:29 +0100 Cornelia Huck [EMAIL PROTECTED] wrote:
On Thu, 22 Mar 2007 13:55:51 -0500,
Larry Finger [EMAIL PROTECTED] wrote:
Cornelia Huck wrote:
On Thu, 22 Mar 2007 07:23:06 -0500,
This would indicate that dev_uevent had been called. But how could
kobject_uevent then return an error without moaning about an uevent()
error code? Maybe the following debug patch could shed some light on
this (all moaning is prefixed with kobject_uevent_env, so it should be
easy to spot)...
I applied the debug patch, but I don't see any error codes being returned.
This time I also got the
General Protection Faults. An excerpt of the log is attached.
Hm, I think I have an idea about what happened.
The firmware class tried to suppress the first KOBJ_ADD uevent by
returning -ENODEV in firmware_uevent if FW_STATUS_READY was not set.
This only worked as long as the return code of kobject_uevent was not
checked in device_add. hack-to-make-wireless-work.patch made that first
uevent return successfully, but this possible triggered some udev rule
too early, leading to firmware load failures.
The following (completely untested) patch uses uevent_suppress to stop
the uevent from being generated during device_add. Does this work for
you?
---
drivers/base/firmware_class.c |2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.orig/drivers/base/firmware_class.c
+++ linux-2.6/drivers/base/firmware_class.c
@@ -333,6 +333,7 @@ static int fw_register_device(struct dev
f_dev-parent = device;
f_dev-class = firmware_class;
dev_set_drvdata(f_dev, fw_priv);
+ f_dev-uevent_suppress = 1;
retval = device_register(f_dev);
if (retval) {
printk(KERN_ERR %s: device_register failed\n,
@@ -385,6 +386,7 @@ static int fw_setup_device(struct firmwa
set_bit(FW_STATUS_READY, fw_priv-status);
else
set_bit(FW_STATUS_READY_NOHOTPLUG, fw_priv-status);
+ f_dev-uevent_suppress = 0;
*dev_p = f_dev;
goto out;
hm.
Would I be right in guessing that this was all triggered by
uevent-improve-error-checking-and-handling.patch?
If so, do you think I should labour on with
uevent-improve-error-checking-and-handling.patch plus your fix, or should I
drop the lot? (I'm inclined toward the latter, but I'm still not
sure which patch(es) need to be dropped).
Thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Friday 23 March 2007 05:17, Andy Whitcroft wrote: > Ok, I have yet a third x86_64 machine is is blowing up with the latest > 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with > 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels > so I have just fired off a set of tests across the affected machines on > that latest hotfix stack plus the RSDL backout and the results should be > in in the next hour or two. > > I think there is a strong correlation between RSDL and these hangs. Any > suggestions as to the next step. Found a nasty in requeue_task + if (list_empty(old_array->queue + old_prio)) + __clear_bit(old_prio, p->array->prio_bitmap); see anything wrong there? I do :P I'll queue that up with the other changes pending and hopefully that will fix your bug. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Please always do reply-to-all. On Fri, 23 Mar 2007 00:27:09 +0100 "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > > > > Is anybody having problems with optical drives and this kernel ? > I can't get my dvdrw to spit any events to udevmonitor. If I mount it > manually everything works fine. Yes, I think one person reported something similar. > Perhaps the problem is in hal/g-v-m or anything else, but I suppose that > udevmonitor receives events directly from kernel, isn't it ? Probably related to the not-yet-completely-solved firmware loader failures. It would be good if someone could do a bisection search on this. I face a fun evening hunting down a horrendous ext3 performance regression which is now in mainline. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > Is anybody having problems with optical drives and this kernel ? I can't get my dvdrw to spit any events to udevmonitor. If I mount it manually everything works fine. Perhaps the problem is in hal/g-v-m or anything else, but I suppose that udevmonitor receives events directly from kernel, isn't it ? TIA -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Friday 23 March 2007 05:17, Andy Whitcroft wrote: > Andy Whitcroft wrote: > > Con Kolivas wrote: > >> On Thursday 22 March 2007 20:48, Andy Whitcroft wrote: > >>> Andy Whitcroft wrote: > Andy Whitcroft wrote: > > Andrew Morton wrote: > >> Temporarily at > >> > >> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > >> > >> Will appear later at > >> > >> > >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21 > >>-rc 4/2.6.21-rc4-mm1/ > > > > [All of the below is from the pre hot-fix runs. The very few results > > which are in for the hot-fix runs seem worse if anything. :( All > > results should be out on TKO.] > > > >> - Restored the RSDL CPU scheduler (a new version thereof) > > > > Unsure if the above is the culprit but there seems to be a smattering > > of BUG's in kernbench from the schedular on several systems, and > > panics which do not fully dump out. > > > > elm3b239 is about 2/4 kernbench being the test in progress when we > > blammo in both failed tests, elm3b234 doesn't boot at all. > > Well I have one result through for backing RSDL out on elm3b239 and > that does indeed seem to give us a successful boot and test. peterz > has pointed me to an incremental patch from Con which I'll push > through testing and see if that sorts it out. > >>> > >>> Ok, tested the patch below on top of 2.6.21-rc4-mm1 and this seems to > >>> fix the problem: > >>> > >>> http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc4-mm1-rsdl-0. > >>>32.p atch > >>> > >>> Hard to tell from that patch whether it will be fixed in the changes > >>> already committed to the next -mm. > >>> > >>> Its possible that it may be fixed by the following patch: > >>> > >>> sched-rsdl-improvements.patch > >>> > >>> Which has the following slipped in at the end of the changelog: > >>> > >>> A tiny change checking for MAX_PRIO in normal_prio() > >>> may prevent oopses on bootup on large SMP due to > >>> forking off the idle task. > >>> > >>> Con, are all the changes in the 0.32 patch above with akpm? > >> > >> Yes he's queued everything in that patch you tested for the next -mm. > >> Thanks very much for testing it. > > > > No worries. I've just got through the results on the other machine in > > the mix. That machine seems to be fixed by backing out RSDL and not by > > the fixup 0.32 patch ... > > > > This second machine seems to had hard very soon after user space starts > > executing but without a panic. I can't say that the symptoms are very > > definitive, but I do have a good result from that machine without RSDL > > and not with rsdl-0.32. > > > > The machine is a dual-core x86_64 machine: Dual Core AMD Opteron(tm) > > Processor 275. > > > > I'll let you know if I find out anything else. Shout if you want any > > information or have anything you want poked or tested. > > Ok, I have yet a third x86_64 machine is is blowing up with the latest > 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with > 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels > so I have just fired off a set of tests across the affected machines on > that latest hotfix stack plus the RSDL backout and the results should be > in in the next hour or two. > > I think there is a strong correlation between RSDL and these hangs. Any > suggestions as to the next step. If it's hitting the bug_on that I put in sched.c which you say it is then it is most certainly my fault. It implies a task has been queued without a corresponding bit being anywhere in the priority bitmaps. Somehow you only seem to be hitting it on big(ger) smp which is why I haven't seen it. It implies some complication occuring at sched or idle init/fork off these accounting not working. If I could reproduce it on qemu I'd step through the kernel init checking where each task is being queued and see if the bitmaps are being set. This is obviously time consuming and laborious so I don't expect you to do it. The next best thing is if you can send me the config of one of the machines that's oopsing I can try that on qemu but qemu is only good at debugging i386. If any of the machines that were oopsing were i386 that would be very helpful, otherwise x86_64 is the next best. Then I need to make a creative debugging patch for you to try which checks every queued/dequeued task and dumps all that information. I don't have that patch just yet so I need to find enough accumulated short stints at the pc to do that (still hurts a lot and worsens my condition). Thanks! -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Cornelia Huck wrote: > On Thu, 22 Mar 2007 07:23:06 -0500, > > This would indicate that dev_uevent had been called. But how could > kobject_uevent then return an error without moaning about an uevent() > error code? Maybe the following debug patch could shed some light on > this (all moaning is prefixed with kobject_uevent_env, so it should be > easy to spot)... I applied the debug patch, but I don't see any error codes being returned. This time I also got the General Protection Faults. An excerpt of the log is attached. Thanks, Larry Mar 22 13:01:21 larrylap2 kernel: kobject :01:00.0: registering. parent: firmware, set: devices Mar 22 13:01:21 larrylap2 kernel: kobject_uevent_env: :01:00.0 Mar 22 13:01:21 larrylap2 kernel: fill_kobj_path: path = '/class/firmware/:01:00.0' Mar 22 13:01:21 larrylap2 kernel: fill_kobj_path: path = '/devices/pci:00/:00:02.0/:01:00.0' Mar 22 13:01:21 larrylap2 kernel: kobject_uevent_env: returning 0 Mar 22 13:01:21 larrylap2 kernel: kobject_uevent_env: :01:00.0 Mar 22 13:01:21 larrylap2 kernel: fill_kobj_path: path = '/class/firmware/:01:00.0' Mar 22 13:01:21 larrylap2 kernel: fill_kobj_path: path = '/devices/pci:00/:00:02.0/:01:00.0' Mar 22 13:01:21 larrylap2 kernel: kobject_uevent_env: returning 0 Mar 22 13:01:21 larrylap2 kernel: firmware_loading_store: unexpected value (0) Mar 22 13:01:21 larrylap2 kernel: kobject_uevent_env: :01:00.0 Mar 22 13:01:21 larrylap2 kernel: fill_kobj_path: path = '/class/firmware/:01:00.0' Mar 22 13:01:21 larrylap2 kernel: fill_kobj_path: path = '/devices/pci:00/:00:02.0/:01:00.0' Mar 22 13:01:21 larrylap2 kernel: kobject_uevent_env: returning 0 Mar 22 13:01:21 larrylap2 kernel: kobject :01:00.0: cleaning up Mar 22 13:01:21 larrylap2 kernel: bcm43xx: Error: PCM "bcm43xx_pcm5.fw" not available or load failed. Mar 22 13:01:21 larrylap2 kernel: bcm43xx: core_up for active 802.11 core failed (-2) Mar 22 13:01:45 larrylap2 kernel: kobject :01:00.0: registering. parent: firmware, set: devices Mar 22 13:01:45 larrylap2 kernel: kobject_uevent_env: :01:00.0 Mar 22 13:01:45 larrylap2 kernel: fill_kobj_path: path = '/class/firmware/:01:00.0' Mar 22 13:01:45 larrylap2 kernel: fill_kobj_path: path = '/devices/pci:00/:00:02.0/:01:00.0' Mar 22 13:01:45 larrylap2 kernel: kobject_uevent_env: returning 0 Mar 22 13:01:45 larrylap2 kernel: kobject_uevent_env: :01:00.0 Mar 22 13:01:45 larrylap2 kernel: fill_kobj_path: path = '/class/firmware/:01:00.0' Mar 22 13:01:45 larrylap2 kernel: fill_kobj_path: path = '/devices/pci:00/:00:02.0/:01:00.0' Mar 22 13:01:45 larrylap2 kernel: kobject_uevent_env: returning 0 Mar 22 13:01:46 larrylap2 kernel: kobject_uevent_env: :01:00.0 Mar 22 13:01:46 larrylap2 kernel: fill_kobj_path: path = '/class/firmware/:01:00.0' Mar 22 13:01:46 larrylap2 kernel: fill_kobj_path: path = '/devices/pci:00/:00:02.0/:01:00.0' Mar 22 13:01:46 larrylap2 kernel: kobject_uevent_env: returning 0 Mar 22 13:01:46 larrylap2 kernel: kobject :01:00.0: registering. parent: firmware, set: devices Mar 22 13:01:46 larrylap2 kernel: firmware_loading_store: unexpected value (0) Mar 22 13:01:46 larrylap2 kernel: kobject :01:00.0: cleaning up Mar 22 13:01:46 larrylap2 kernel: kobject_uevent_env: :01:00.0 Mar 22 13:01:46 larrylap2 kernel: fill_kobj_path: path = '/class/firmware/:01:00.0' Mar 22 13:01:46 larrylap2 kernel: fill_kobj_path: path = '/devices/pci:00/:00:02.0/:01:00.0' Mar 22 13:01:46 larrylap2 kernel: kobject_uevent_env: returning 0 Mar 22 13:01:46 larrylap2 kernel: kobject_uevent_env: :01:00.0 Mar 22 13:01:46 larrylap2 kernel: fill_kobj_path: path = '/class/firmware/:01:00.0' Mar 22 13:01:46 larrylap2 kernel: fill_kobj_path: path = '/devices/pci:00/:00:02.0/:01:00.0' Mar 22 13:01:46 larrylap2 kernel: kobject_uevent_env: returning 0 Mar 22 13:01:46 larrylap2 kernel: kobject_uevent_env: :01:00.0 Mar 22 13:01:46 larrylap2 kernel: fill_kobj_path: path = '/class/firmware/:01:00.0' Mar 22 13:01:46 larrylap2 kernel: fill_kobj_path: path = '/devices/pci:00/:00:02.0/:01:00.0' Mar 22 13:01:46 larrylap2 kernel: kobject_uevent_env: returning 0 Mar 22 13:01:46 larrylap2 kernel: kobject :01:00.0: cleaning up Mar 22 13:01:46 larrylap2 kernel: bcm43xx: Error: PCM "bcm43xx_pcm5.fw" not available or load failed. Mar 22 13:01:46 larrylap2 kernel: bcm43xx: core_up for active 802.11 core failed (-2) Mar 22 13:02:10 larrylap2 kernel: kobject :01:00.0: registering. parent: firmware, set: devices Mar 22 13:02:10 larrylap2 kernel: kobject_uevent_env: :01:00.0 Mar 22 13:02:10 larrylap2 kernel: fill_kobj_path: path = '/class/firmware/:01:00.0' Mar 22 13:02:10 larrylap2 kernel: fill_kobj_path: path = '/devices/pci:00/:00:02.0/:01:00.0' Mar 22 13:02:10 larrylap2 kernel: kobject_uevent_env: returning 0 Mar 22 13:02:10 larrylap2
Re: 2.6.21-rc4-mm1
Andy Whitcroft wrote: > Con Kolivas wrote: >> On Thursday 22 March 2007 20:48, Andy Whitcroft wrote: >>> Andy Whitcroft wrote: Andy Whitcroft wrote: > Andrew Morton wrote: >> Temporarily at >> >> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ >> >> Will appear later at >> >> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc >> 4/2.6.21-rc4-mm1/ > [All of the below is from the pre hot-fix runs. The very few results > which are in for the hot-fix runs seem worse if anything. :( All > results should be out on TKO.] > >> - Restored the RSDL CPU scheduler (a new version thereof) > Unsure if the above is the culprit but there seems to be a smattering of > BUG's in kernbench from the schedular on several systems, and panics > which do not fully dump out. > > elm3b239 is about 2/4 kernbench being the test in progress when we > blammo in both failed tests, elm3b234 doesn't boot at all. Well I have one result through for backing RSDL out on elm3b239 and that does indeed seem to give us a successful boot and test. peterz has pointed me to an incremental patch from Con which I'll push through testing and see if that sorts it out. >>> Ok, tested the patch below on top of 2.6.21-rc4-mm1 and this seems to >>> fix the problem: >>> >>> http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc4-mm1-rsdl-0.32.p >>> atch >>> >>> Hard to tell from that patch whether it will be fixed in the changes >>> already committed to the next -mm. >>> >>> Its possible that it may be fixed by the following patch: >>> >>> sched-rsdl-improvements.patch >>> >>> Which has the following slipped in at the end of the changelog: >>> >>> A tiny change checking for MAX_PRIO in normal_prio() >>> may prevent oopses on bootup on large SMP due to >>> forking off the idle task. >>> >>> Con, are all the changes in the 0.32 patch above with akpm? >> Yes he's queued everything in that patch you tested for the next -mm. Thanks >> very much for testing it. > > No worries. I've just got through the results on the other machine in > the mix. That machine seems to be fixed by backing out RSDL and not by > the fixup 0.32 patch ... > > This second machine seems to had hard very soon after user space starts > executing but without a panic. I can't say that the symptoms are very > definitive, but I do have a good result from that machine without RSDL > and not with rsdl-0.32. > > The machine is a dual-core x86_64 machine: Dual Core AMD Opteron(tm) > Processor 275. > > I'll let you know if I find out anything else. Shout if you want any > information or have anything you want poked or tested. Ok, I have yet a third x86_64 machine is is blowing up with the latest 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels so I have just fired off a set of tests across the affected machines on that latest hotfix stack plus the RSDL backout and the results should be in in the next hour or two. I think there is a strong correlation between RSDL and these hangs. Any suggestions as to the next step. -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Con Kolivas wrote: > On Thursday 22 March 2007 20:48, Andy Whitcroft wrote: >> Andy Whitcroft wrote: >>> Andy Whitcroft wrote: Andrew Morton wrote: > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc > 4/2.6.21-rc4-mm1/ [All of the below is from the pre hot-fix runs. The very few results which are in for the hot-fix runs seem worse if anything. :( All results should be out on TKO.] > - Restored the RSDL CPU scheduler (a new version thereof) Unsure if the above is the culprit but there seems to be a smattering of BUG's in kernbench from the schedular on several systems, and panics which do not fully dump out. elm3b239 is about 2/4 kernbench being the test in progress when we blammo in both failed tests, elm3b234 doesn't boot at all. >>> Well I have one result through for backing RSDL out on elm3b239 and that >>> does indeed seem to give us a successful boot and test. peterz has >>> pointed me to an incremental patch from Con which I'll push through >>> testing and see if that sorts it out. >> Ok, tested the patch below on top of 2.6.21-rc4-mm1 and this seems to >> fix the problem: >> >> http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc4-mm1-rsdl-0.32.p >> atch >> >> Hard to tell from that patch whether it will be fixed in the changes >> already committed to the next -mm. >> >> Its possible that it may be fixed by the following patch: >> >> sched-rsdl-improvements.patch >> >> Which has the following slipped in at the end of the changelog: >> >> A tiny change checking for MAX_PRIO in normal_prio() >> may prevent oopses on bootup on large SMP due to >> forking off the idle task. >> >> Con, are all the changes in the 0.32 patch above with akpm? > > Yes he's queued everything in that patch you tested for the next -mm. Thanks > very much for testing it. No worries. I've just got through the results on the other machine in the mix. That machine seems to be fixed by backing out RSDL and not by the fixup 0.32 patch ... This second machine seems to had hard very soon after user space starts executing but without a panic. I can't say that the symptoms are very definitive, but I do have a good result from that machine without RSDL and not with rsdl-0.32. The machine is a dual-core x86_64 machine: Dual Core AMD Opteron(tm) Processor 275. I'll let you know if I find out anything else. Shout if you want any information or have anything you want poked or tested. -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Thu, 22 Mar 2007 07:23:06 -0500,
Larry Finger <[EMAIL PROTECTED]> wrote:
> Cornelia Huck wrote:
> > On Wed, 21 Mar 2007 23:39:17 -0800,
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> >> On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote:
> >>
> >>> With the latest -mm, I'm now getting this:
> >>>
> >>> Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
> >>> 2200BG Network Connection
> >>> Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected
> >>> value (0)
> >>> Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw
> >>> request_firmware failed:
> >>> Reason -2
> >>> Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2
> >>> Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network
> >>> device
> >> The firmware loading bug is caused by
> >> driver-core-handles-kobject_uevent-failure-while-device_add.patch
> >
> > Hm, this patch looks sane. It might be a good idea to enable
> > CONFIG_DEBUG_KOBJECT and find out why kobject_uevent() actually fails
> > in this case...
>
> Attached is the appropriate portion of /var/log/messages with Kobject
> debugging enabled.
> Mar 22 07:01:42 larrylap2 kernel: kobject :01:00.0: registering. parent:
> firmware, set: devices
> Mar 22 07:01:42 larrylap2 kernel: kobject_uevent_env
> Mar 22 07:01:42 larrylap2 kernel: fill_kobj_path: path =
> '/class/firmware/:01:00.0'
> Mar 22 07:01:42 larrylap2 kernel: fill_kobj_path: path =
> '/devices/pci:00/:00:02.0/:01:00.0'
> Mar 22 07:01:42 larrylap2 kernel: kobject_uevent_env
> Mar 22 07:01:42 larrylap2 ntpd[3434]: frequency initialized -31.513 PPM from
> /var/lib/ntp/drift/ntp.drift
> Mar 22 07:01:43 larrylap2 kernel: fill_kobj_path: path =
> '/class/firmware/:01:00.0'
> Mar 22 07:01:43 larrylap2 kernel: fill_kobj_path: path =
> '/devices/pci:00/:00:02.0/:01:00.0'
> Mar 22 07:01:43 larrylap2 kernel: firmware_loading_store: unexpected value (0)
> Mar 22 07:01:43 larrylap2 kernel: kobject_uevent_env
> Mar 22 07:01:43 larrylap2 kernel: fill_kobj_path: path =
> '/class/firmware/:01:00.0'
> Mar 22 07:01:43 larrylap2 kernel: fill_kobj_path: path =
> '/devices/pci:00/:00:02.0/:01:00.0'
> Mar 22 07:01:43 larrylap2 kernel: kobject :01:00.0: cleaning up
(Repeating several times)
This would indicate that dev_uevent had been called. But how could
kobject_uevent then return an error without moaning about an uevent()
error code? Maybe the following debug patch could shed some light on
this (all moaning is prefixed with kobject_uevent_env, so it should be
easy to spot)...
---
lib/kobject_uevent.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
--- linux-2.6.orig/lib/kobject_uevent.c
+++ linux-2.6/lib/kobject_uevent.c
@@ -85,11 +85,11 @@ int kobject_uevent_env(struct kobject *k
int retval = 0;
int j;
- pr_debug("%s\n", __FUNCTION__);
+ pr_debug("%s: %s\n", __FUNCTION__, kobject_name(kobj));
action_string = action_to_string(action);
if (!action_string) {
- pr_debug("kobject attempted to send uevent without
action_string!\n");
+ pr_debug("%s: kobject attempted to send uevent without
action_string!\n", __FUNCTION__);
return -EINVAL;
}
@@ -101,7 +101,7 @@ int kobject_uevent_env(struct kobject *k
} while (!top_kobj->kset && top_kobj->parent);
}
if (!top_kobj->kset) {
- pr_debug("kobject attempted to send uevent without kset!\n");
+ pr_debug("%s: kobject attempted to send uevent without
kset!\n", __FUNCTION__);
return -EINVAL;
}
@@ -111,7 +111,7 @@ int kobject_uevent_env(struct kobject *k
/* skip the event, if the filter returns zero. */
if (uevent_ops && uevent_ops->filter)
if (!uevent_ops->filter(kset, kobj)) {
- pr_debug("kobject filter function caused the event to
drop!\n");
+ pr_debug("%s: kobject filter function caused the event
to drop!\n", __FUNCTION__);
return 0;
}
@@ -121,18 +121,20 @@ int kobject_uevent_env(struct kobject *k
else
subsystem = kobject_name(>kobj);
if (!subsystem) {
- pr_debug("unset subsytem caused the event to drop!\n");
+ pr_debug("%s: unset subsytem caused the event to drop!\n",
__FUNCTION__);
return 0;
}
/* environment index */
envp = kzalloc(NUM_ENVP * sizeof (char *), GFP_KERNEL);
- if (!envp)
+ if (!envp) {
+ pr_debug("%s: couldn't alloc envp\n", __FUNCTION__);
return -ENOMEM;
-
+ }
/* environment values */
buffer = kmalloc(BUFFER_SIZE, GFP_KERNEL);
if (!buffer) {
+ pr_debug("%s: couldn't alloc buffer\n", __FUNCTION__);
retval =
Re: 2.6.21-rc4-mm1
On Thu, Mar 22, 2007 at 04:25:53PM +, David Woodhouse wrote: > On Thu, 2007-03-22 at 12:41 +0100, Sam Ravnborg wrote: > > Yep - realized this when I took a closer look. > > One thing striked my mind. It is correct that new things gets added > > to i386 first these days? > > Personally I tend to do PowerPC first, but most others seem to do i386, > yes. There are still system calls being added to i386 and not x86_64... > > init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not > implemented > init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not > implemented > init/missing_syscalls.h:953:3: warning: #warning syscall lutimesat not > implemented > init/missing_syscalls.h:956:3: warning: #warning syscall revokeat not > implemented > init/missing_syscalls.h:959:3: warning: #warning syscall frevoke not > implemented > > > To me it looks like x86_64 is growing larger than i386 among the > > developers these days so using asm-x86_64/unistd.h could be a better > > choice? > > Or perhaps the union of i386, x86_64 and powerpc. But I think i386 is > good enough for now. I kept i386 as default so all is good. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Thu, 2007-03-22 at 12:41 +0100, Sam Ravnborg wrote: > Yep - realized this when I took a closer look. > One thing striked my mind. It is correct that new things gets added > to i386 first these days? Personally I tend to do PowerPC first, but most others seem to do i386, yes. There are still system calls being added to i386 and not x86_64... init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented init/missing_syscalls.h:953:3: warning: #warning syscall lutimesat not implemented init/missing_syscalls.h:956:3: warning: #warning syscall revokeat not implemented init/missing_syscalls.h:959:3: warning: #warning syscall frevoke not implemented > To me it looks like x86_64 is growing larger than i386 among the > developers these days so using asm-x86_64/unistd.h could be a better > choice? Or perhaps the union of i386, x86_64 and powerpc. But I think i386 is good enough for now. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1 + 4 hotfixes -- BUG: unable to handle kernel paging request at virtual address 6b6b6ceb -- EIP is at module_put+0x7/0x1f
I cannot reproduce the BUG with your ml.bz2 patch applied. I am seeing this with both 2.6.21-rc4-mm1 + hotfixes, and with 2.6.21-rc4 + ml.bz2: Mar 22 09:10:35 FractalPath kernel: ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) Mar 22 09:10:35 FractalPath kernel: The kobject at, or inside per_cpu__cpuidle_devices+0x40/0x558 is not dynamically allocated. Mar 22 09:10:35 FractalPath kernel: The kobject at, or inside per_cpu__cpuidle_devices+0xd4/0x558 is not dynamically allocated. Mar 22 09:10:35 FractalPath kernel: The kobject at, or inside per_cpu__cpuidle_devices+0x168/0x558 is not dynamically allocated. Mar 22 09:10:35 FractalPath kernel: cpuidle: using driver acpi_idle Not sure if this is a problem. Also, the first time I booted the ml.bz2 build, it hung. I don't have netconsole or a serial debugging system set up, so I have no idea what the problem was. The second boot, ipw2200 loaded with no errors, but NetworkManager wouldn't connect until I removed and reinserted the module. All the best, Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Thu, Mar 22, 2007 at 09:17:00AM +, David Woodhouse wrote: > On Wed, 2007-03-21 at 12:59 +0100, Sam Ravnborg wrote: > > I will give it a shot tonight. > > Thanks. I'll delete the syscalls-2.6.git tree now that you have it. > > > One issue I have with current approach is that the ARCH specific > > things are in a single .h file. > > Que? There aren't really any arch-specific things, except for a list of > syscalls to be ignored which are i386-specific. That's because we're > pulling in the 'master' system call list from asm-i386/unistd.h, and we > need to exclude some of those which we don't really need on other > architectures. Yep - realized this when I took a closer look. One thing striked my mind. It is correct that new things gets added to i386 first these days? To me it looks like x86_64 is growing larger than i386 among the developers these days so using asm-x86_64/unistd.h could be a better choice? Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Wed, 21 Mar 2007 23:39:17 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote: > > > With the latest -mm, I'm now getting this: > > > > Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless > > 2200BG Network Connection > > Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected > > value (0) > > Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw > > request_firmware failed: > > Reason -2 > > Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2 > > Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network > > device > > The firmware loading bug is caused by > driver-core-handles-kobject_uevent-failure-while-device_add.patch Hm, this patch looks sane. It might be a good idea to enable CONFIG_DEBUG_KOBJECT and find out why kobject_uevent() actually fails in this case... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Thursday 22 March 2007 20:48, Andy Whitcroft wrote: > Andy Whitcroft wrote: > > Andy Whitcroft wrote: > >> Andrew Morton wrote: > >>> Temporarily at > >>> > >>> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > >>> > >>> Will appear later at > >>> > >>> > >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc > >>>4/2.6.21-rc4-mm1/ > >> > >> [All of the below is from the pre hot-fix runs. The very few results > >> which are in for the hot-fix runs seem worse if anything. :( All > >> results should be out on TKO.] > >> > >>> - Restored the RSDL CPU scheduler (a new version thereof) > >> > >> Unsure if the above is the culprit but there seems to be a smattering of > >> BUG's in kernbench from the schedular on several systems, and panics > >> which do not fully dump out. > >> > >> elm3b239 is about 2/4 kernbench being the test in progress when we > >> blammo in both failed tests, elm3b234 doesn't boot at all. > > > > Well I have one result through for backing RSDL out on elm3b239 and that > > does indeed seem to give us a successful boot and test. peterz has > > pointed me to an incremental patch from Con which I'll push through > > testing and see if that sorts it out. > > Ok, tested the patch below on top of 2.6.21-rc4-mm1 and this seems to > fix the problem: > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc4-mm1-rsdl-0.32.p >atch > > Hard to tell from that patch whether it will be fixed in the changes > already committed to the next -mm. > > Its possible that it may be fixed by the following patch: > > sched-rsdl-improvements.patch > > Which has the following slipped in at the end of the changelog: > > A tiny change checking for MAX_PRIO in normal_prio() > may prevent oopses on bootup on large SMP due to > forking off the idle task. > > Con, are all the changes in the 0.32 patch above with akpm? Yes he's queued everything in that patch you tested for the next -mm. Thanks very much for testing it. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Andy Whitcroft wrote: > Andy Whitcroft wrote: >> Andrew Morton wrote: >>> Temporarily at >>> >>> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ >>> >>> Will appear later at >>> >>> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ >>> >>> >>> >> [All of the below is from the pre hot-fix runs. The very few results >> which are in for the hot-fix runs seem worse if anything. :( All >> results should be out on TKO.] >> >>> - Restored the RSDL CPU scheduler (a new version thereof) >> Unsure if the above is the culprit but there seems to be a smattering of >> BUG's in kernbench from the schedular on several systems, and panics >> which do not fully dump out. >> >> elm3b239 is about 2/4 kernbench being the test in progress when we >> blammo in both failed tests, elm3b234 doesn't boot at all. > > Well I have one result through for backing RSDL out on elm3b239 and that > does indeed seem to give us a successful boot and test. peterz has > pointed me to an incremental patch from Con which I'll push through > testing and see if that sorts it out. Ok, tested the patch below on top of 2.6.21-rc4-mm1 and this seems to fix the problem: http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc4-mm1-rsdl-0.32.patch Hard to tell from that patch whether it will be fixed in the changes already committed to the next -mm. Its possible that it may be fixed by the following patch: sched-rsdl-improvements.patch Which has the following slipped in at the end of the changelog: A tiny change checking for MAX_PRIO in normal_prio() may prevent oopses on bootup on large SMP due to forking off the idle task. Con, are all the changes in the 0.32 patch above with akpm? -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1 + 4 hotfixes -- BUG: unable to handle kernel paging request at virtual address 6b6b6ceb -- EIP is at module_put+0x7/0x1f
On Thu, 22 Mar 2007 01:14:41 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > I still encounter the BUG with the reverted patch. In these two > builds hitting the BUG, more stuff is built as a module, so perhaps > that is why I am triggering this. I am appending my .config file. > > I hope this helps, > Miles > > kobject drivers: registering. parent: ipw2200, set: > kobject_uevent_env > kobject filter function caused the event to drop! > kobject :01:06.0: cleaning up > kobject firmware: cleaning up > BUG: unable to handle kernel paging request at virtual address 6b6b6ceb > printing eip: > c0137c22 > *pde = > Oops: 0002 [#1] > last sysfs file: > devices/pci:00/:00:1e.0/:01:06.0/firmware/:01:06.0/loading > Modules linked in: snd_pcm snd_seq_dummy sdhci snd_seq_oss rng_core > ipw2200 snd_seq_midi_event snd_seq snd_timer snd_s > eq_device mmc_core tifm_7xx1 tifm_core fw_ohci fw_core ieee80211 > ieee80211_crypt yenta_socket rsrc_nonstatic pcmcia_co > re snd soundcore shpchp iTCO_wdt snd_page_alloc pci_hotplug psmouse > rtc iTCO_vendor_support intel_agp agpgart evdev ex > t3 jbd mbcache sg sr_mod cdrom sd_mod pata_acpi ata_piix ohci1394 > ieee1394 8139too mii libata scsi_mod ehci_hcd uhci_h > cd usbcore thermal processor fan > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010202 (2.6.21-rc4-mm1 #5) > EIP is at module_put+0x7/0x1f > eax: 6b6b6b6b ebx: c354d628 ecx: c01618d2 edx: 0001 > esi: c39f5000 edi: c1e47d4c ebp: c1fa3f38 esp: c1fa3f38 > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process firmware_helper (pid: 1888, ti=c1fa2000 task=c1cab570 > task.ti=c1fa2000) > Stack: c1fa3f48 c019db66 0008 c3548038 c1fa3f70 c0165eee >c39aea18 c1c12118 c3548038 c1e47d4c c1e13b14 c1fa3f80 c0166036 >c1e47d4c c1e47d4c c1fa3f98 c0163ac6 c1e13b38 0003 c1e13b14 c1e13b38 > Call Trace: > [] show_trace_log_lvl+0x1a/0x2f > [] show_stack_log_lvl+0x9b/0xaa > [] show_registers+0x1b6/0x288 > [] die+0xf4/0x209 > [] do_page_fault+0x45d/0x529 > [] error_code+0x74/0x7c > [] release+0x2a/0x37 > [] __fput+0xbe/0x168 > [] fput+0x31/0x35 > [] filp_close+0x54/0x5c > [] sys_close+0x6f/0xa7 > [] sysenter_past_esp+0x5d/0x99 > === > Code: fe ff 8b 86 c4 00 00 00 e8 42 e4 08 00 89 f8 e8 22 e4 08 00 89 > f8 e8 d4 e2 08 00 59 89 d8 5b 5b 5e 5f 5d c3 55 8 > 5 c0 89 e5 74 16 88 80 01 00 00 83 38 02 75 0b 8b 80 08 02 00 00 > e8 9c ee fd > EIP: [] module_put+0x7/0x1f SS:ESP 0068:c1fa3f38 > kobject pcmcia: registering. parent: , set: module > kobject holders: registering. parent: pcmcia, set: > kobject_uevent_env > Marvellous. I cannot reproduce it with my current lineup. Maybe someone fixed it in one of the subsystem trees. If you have time, could you please test http://userweb.kernel.org/~akpm/ml.bz2 (against 2.6.21-rc4). It surprises me that ipw2200 does this: [ 104.284000] kobject 'ipw2200' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Wed, 2007-03-21 at 12:59 +0100, Sam Ravnborg wrote: > I will give it a shot tonight. Thanks. I'll delete the syscalls-2.6.git tree now that you have it. > One issue I have with current approach is that the ARCH specific > things are in a single .h file. Que? There aren't really any arch-specific things, except for a list of syscalls to be ignored which are i386-specific. That's because we're pulling in the 'master' system call list from asm-i386/unistd.h, and we need to exclude some of those which we don't really need on other architectures. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Wed, Mar 21, 2007 at 04:01:11PM -0700, Andrew Morton wrote: > On Wed, 21 Mar 2007 23:19:05 +0100 > Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > > On Tue, Mar 20, 2007 at 09:47:14PM -0800, Andrew Morton wrote: > > > On Tue, 20 Mar 2007 12:20:16 -0700 Kees Cook <[EMAIL PROTECTED]> wrote: > > > > > > > I can't > > > > get 2.6.21-rc4-mm1 to compile (with or without this fix): > > > > > > > > GEN .version > > > > init/.missing_syscalls.h.cmd:2: *** missing separator. Stop. > > > > make: *** [.tmp_vmlinux1] Error 2 > > > > > > How'd you manage that? > > > > > > Sam, I think this is a you-thing rather than a dwmw2-thing? > > Took a look. Things looked pretty OK but an updated patch > > applied to kbuild.git. > > Corrected a few things in the Makefile and combined the > > patch from dwmw2 and Stephane. > > > > kbuild.git pused out and patches follows. > > > > David has set up a git tree with this stuff, so you presumably > have an out-of-date copy. > > git://git.infradead.org/~dwmw2/syscalls-2.6.git > > I don't know what's changed in there. One never does, with git > trees :( I pulled that one and last patch in my serie was from that tree. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Andy Whitcroft wrote: > Andrew Morton wrote: >> Temporarily at >> >> http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ >> >> Will appear later at >> >> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ >> >> >> > > [All of the below is from the pre hot-fix runs. The very few results > which are in for the hot-fix runs seem worse if anything. :( All > results should be out on TKO.] > >> - Restored the RSDL CPU scheduler (a new version thereof) > > Unsure if the above is the culprit but there seems to be a smattering of > BUG's in kernbench from the schedular on several systems, and panics > which do not fully dump out. > > elm3b239 is about 2/4 kernbench being the test in progress when we > blammo in both failed tests, elm3b234 doesn't boot at all. Well I have one result through for backing RSDL out on elm3b239 and that does indeed seem to give us a successful boot and test. peterz has pointed me to an incremental patch from Con which I'll push through testing and see if that sorts it out. -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1 + 4 hotfixes -- BUG: unable to handle kernel paging request at virtual address 6b6b6ceb -- EIP is at module_put+0x7/0x1f
On Thu, 22 Mar 2007 00:29:54 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > kobject :01:06.0: cleaning up > kobject firmware: cleaning up > BUG: unable to handle kernel paging request at virtual address 6b6b6ceb > printing eip: > c0137c22 > *pde = > Oops: 0002 [#1] > last sysfs file: > devices/pci:00/:00:1e.0/:01:06.0/firmware/:01:06.0/loading > Modules linked in: intel_rng rng_core ac97_bus snd_pcm_oss > snd_mixer_oss mmc_core ipw2200 snd_pcm snd_seq_dummy snd_seq_oss > fw_ohci fw_core yenta_socket rsrc_nonstatic pcmcia_core ieee80211 > ieee80211_crypt snd_seq_midi_event snd_seq snd_timer snd_seq_device > iTCO_wdt tifm_7xx1 tifm_core snd psmouse iTCO_vendor_support intel_agp > agpgart rtc soundcore shpchp pci_hotplug evdev snd_page_alloc ext3 jbd > mbcache sg sr_mod cdrom sd_mod pata_acpi ata_piix ohci1394 ieee1394 > 8139too mii libata scsi_mod ehci_hcd uhci_hcd usbcore thermal > processor fan > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010202 (2.6.21-rc4-mm1 #4) > EIP is at module_put+0x7/0x1f > eax: 6b6b6b6b ebx: c34bea98 ecx: c01618d2 edx: 0001 > esi: c358 edi: c34ba2fc ebp: c3597f38 esp: c3597f38 > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process firmware_helper (pid: 1895, ti=c3596000 task=c35a40b0 > task.ti=c3596000) > Stack: c3597f48 c019db66 0008 c3569548 c3597f70 c0165eee >c39bc5f8 c1c12118 c3569548 c34ba2fc c3590310 c3597f80 c0166036 >c34ba2fc c34ba2fc c3597f98 c0163ac6 c3590334 0003 c3590310 c3590334 > Call Trace: > [] show_trace_log_lvl+0x1a/0x2f > [] show_stack_log_lvl+0x9b/0xaa > [] show_registers+0x1b6/0x288 > [] die+0xf4/0x209 > [] do_page_fault+0x45d/0x529 > [] error_code+0x74/0x7c > [] release+0x2a/0x37 > [] __fput+0xbe/0x168 > [] fput+0x31/0x35 > [] filp_close+0x54/0x5c > [] sys_close+0x6f/0xa7 > [] sysenter_past_esp+0x5d/0x99 > === yeah, please try ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/hot-fixes/revert-driver-core-handles-kobject_uevent-failure-while-device_add.patch That might make things happier, but I don't see why the original patch would cause an oops. So if revert-driver-core-handles-kobject_uevent-failure-while-device_add.patch fixes the oops then we probably have another bug in there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote: > With the latest -mm, I'm now getting this: > > Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless > 2200BG Network Connection > Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected > value (0) > Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw > request_firmware failed: > Reason -2 > Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2 > Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network > device The firmware loading bug is caused by driver-core-handles-kobject_uevent-failure-while-device_add.patch I've uploaded a revert patch to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/hot-fixes/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall [EMAIL PROTECTED] wrote: With the latest -mm, I'm now getting this: Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected value (0) Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw request_firmware failed: Reason -2 Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2 Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network device The firmware loading bug is caused by driver-core-handles-kobject_uevent-failure-while-device_add.patch I've uploaded a revert patch to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/hot-fixes/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1 + 4 hotfixes -- BUG: unable to handle kernel paging request at virtual address 6b6b6ceb -- EIP is at module_put+0x7/0x1f
On Thu, 22 Mar 2007 00:29:54 -0700 Miles Lane [EMAIL PROTECTED] wrote: kobject :01:06.0: cleaning up kobject firmware: cleaning up BUG: unable to handle kernel paging request at virtual address 6b6b6ceb printing eip: c0137c22 *pde = Oops: 0002 [#1] last sysfs file: devices/pci:00/:00:1e.0/:01:06.0/firmware/:01:06.0/loading Modules linked in: intel_rng rng_core ac97_bus snd_pcm_oss snd_mixer_oss mmc_core ipw2200 snd_pcm snd_seq_dummy snd_seq_oss fw_ohci fw_core yenta_socket rsrc_nonstatic pcmcia_core ieee80211 ieee80211_crypt snd_seq_midi_event snd_seq snd_timer snd_seq_device iTCO_wdt tifm_7xx1 tifm_core snd psmouse iTCO_vendor_support intel_agp agpgart rtc soundcore shpchp pci_hotplug evdev snd_page_alloc ext3 jbd mbcache sg sr_mod cdrom sd_mod pata_acpi ata_piix ohci1394 ieee1394 8139too mii libata scsi_mod ehci_hcd uhci_hcd usbcore thermal processor fan CPU:0 EIP:0060:[c0137c22]Not tainted VLI EFLAGS: 00010202 (2.6.21-rc4-mm1 #4) EIP is at module_put+0x7/0x1f eax: 6b6b6b6b ebx: c34bea98 ecx: c01618d2 edx: 0001 esi: c358 edi: c34ba2fc ebp: c3597f38 esp: c3597f38 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process firmware_helper (pid: 1895, ti=c3596000 task=c35a40b0 task.ti=c3596000) Stack: c3597f48 c019db66 0008 c3569548 c3597f70 c0165eee c39bc5f8 c1c12118 c3569548 c34ba2fc c3590310 c3597f80 c0166036 c34ba2fc c34ba2fc c3597f98 c0163ac6 c3590334 0003 c3590310 c3590334 Call Trace: [c0104c22] show_trace_log_lvl+0x1a/0x2f [c0104cd2] show_stack_log_lvl+0x9b/0xaa [c0104e97] show_registers+0x1b6/0x288 [c010505d] die+0xf4/0x209 [c0114b20] do_page_fault+0x45d/0x529 [c028a10c] error_code+0x74/0x7c [c019db66] release+0x2a/0x37 [c0165eee] __fput+0xbe/0x168 [c0166036] fput+0x31/0x35 [c0163ac6] filp_close+0x54/0x5c [c0164a97] sys_close+0x6f/0xa7 [c0103c94] sysenter_past_esp+0x5d/0x99 === yeah, please try ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/hot-fixes/revert-driver-core-handles-kobject_uevent-failure-while-device_add.patch That might make things happier, but I don't see why the original patch would cause an oops. So if revert-driver-core-handles-kobject_uevent-failure-while-device_add.patch fixes the oops then we probably have another bug in there. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Andy Whitcroft wrote: Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ [All of the below is from the pre hot-fix runs. The very few results which are in for the hot-fix runs seem worse if anything. :( All results should be out on TKO.] - Restored the RSDL CPU scheduler (a new version thereof) Unsure if the above is the culprit but there seems to be a smattering of BUG's in kernbench from the schedular on several systems, and panics which do not fully dump out. elm3b239 is about 2/4 kernbench being the test in progress when we blammo in both failed tests, elm3b234 doesn't boot at all. Well I have one result through for backing RSDL out on elm3b239 and that does indeed seem to give us a successful boot and test. peterz has pointed me to an incremental patch from Con which I'll push through testing and see if that sorts it out. -apw - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Wed, Mar 21, 2007 at 04:01:11PM -0700, Andrew Morton wrote: On Wed, 21 Mar 2007 23:19:05 +0100 Sam Ravnborg [EMAIL PROTECTED] wrote: On Tue, Mar 20, 2007 at 09:47:14PM -0800, Andrew Morton wrote: On Tue, 20 Mar 2007 12:20:16 -0700 Kees Cook [EMAIL PROTECTED] wrote: I can't get 2.6.21-rc4-mm1 to compile (with or without this fix): GEN .version init/.missing_syscalls.h.cmd:2: *** missing separator. Stop. make: *** [.tmp_vmlinux1] Error 2 How'd you manage that? Sam, I think this is a you-thing rather than a dwmw2-thing? Took a look. Things looked pretty OK but an updated patch applied to kbuild.git. Corrected a few things in the Makefile and combined the patch from dwmw2 and Stephane. kbuild.git pused out and patches follows. David has set up a git tree with this stuff, so you presumably have an out-of-date copy. git://git.infradead.org/~dwmw2/syscalls-2.6.git I don't know what's changed in there. One never does, with git trees :( I pulled that one and last patch in my serie was from that tree. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Wed, 2007-03-21 at 12:59 +0100, Sam Ravnborg wrote: I will give it a shot tonight. Thanks. I'll delete the syscalls-2.6.git tree now that you have it. One issue I have with current approach is that the ARCH specific things are in a single .h file. Que? There aren't really any arch-specific things, except for a list of syscalls to be ignored which are i386-specific. That's because we're pulling in the 'master' system call list from asm-i386/unistd.h, and we need to exclude some of those which we don't really need on other architectures. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1 + 4 hotfixes -- BUG: unable to handle kernel paging request at virtual address 6b6b6ceb -- EIP is at module_put+0x7/0x1f
On Thu, 22 Mar 2007 01:14:41 -0700 Miles Lane [EMAIL PROTECTED] wrote: I still encounter the BUG with the reverted patch. In these two builds hitting the BUG, more stuff is built as a module, so perhaps that is why I am triggering this. I am appending my .config file. I hope this helps, Miles kobject drivers: registering. parent: ipw2200, set: NULL kobject_uevent_env kobject filter function caused the event to drop! kobject :01:06.0: cleaning up kobject firmware: cleaning up BUG: unable to handle kernel paging request at virtual address 6b6b6ceb printing eip: c0137c22 *pde = Oops: 0002 [#1] last sysfs file: devices/pci:00/:00:1e.0/:01:06.0/firmware/:01:06.0/loading Modules linked in: snd_pcm snd_seq_dummy sdhci snd_seq_oss rng_core ipw2200 snd_seq_midi_event snd_seq snd_timer snd_s eq_device mmc_core tifm_7xx1 tifm_core fw_ohci fw_core ieee80211 ieee80211_crypt yenta_socket rsrc_nonstatic pcmcia_co re snd soundcore shpchp iTCO_wdt snd_page_alloc pci_hotplug psmouse rtc iTCO_vendor_support intel_agp agpgart evdev ex t3 jbd mbcache sg sr_mod cdrom sd_mod pata_acpi ata_piix ohci1394 ieee1394 8139too mii libata scsi_mod ehci_hcd uhci_h cd usbcore thermal processor fan CPU:0 EIP:0060:[c0137c22]Not tainted VLI EFLAGS: 00010202 (2.6.21-rc4-mm1 #5) EIP is at module_put+0x7/0x1f eax: 6b6b6b6b ebx: c354d628 ecx: c01618d2 edx: 0001 esi: c39f5000 edi: c1e47d4c ebp: c1fa3f38 esp: c1fa3f38 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process firmware_helper (pid: 1888, ti=c1fa2000 task=c1cab570 task.ti=c1fa2000) Stack: c1fa3f48 c019db66 0008 c3548038 c1fa3f70 c0165eee c39aea18 c1c12118 c3548038 c1e47d4c c1e13b14 c1fa3f80 c0166036 c1e47d4c c1e47d4c c1fa3f98 c0163ac6 c1e13b38 0003 c1e13b14 c1e13b38 Call Trace: [c0104c22] show_trace_log_lvl+0x1a/0x2f [c0104cd2] show_stack_log_lvl+0x9b/0xaa [c0104e97] show_registers+0x1b6/0x288 [c010505d] die+0xf4/0x209 [c0114b20] do_page_fault+0x45d/0x529 [c028a0fc] error_code+0x74/0x7c [c019db66] release+0x2a/0x37 [c0165eee] __fput+0xbe/0x168 [c0166036] fput+0x31/0x35 [c0163ac6] filp_close+0x54/0x5c [c0164a97] sys_close+0x6f/0xa7 [c0103c94] sysenter_past_esp+0x5d/0x99 === Code: fe ff 8b 86 c4 00 00 00 e8 42 e4 08 00 89 f8 e8 22 e4 08 00 89 f8 e8 d4 e2 08 00 59 89 d8 5b 5b 5e 5f 5d c3 55 8 5 c0 89 e5 74 16 ff 88 80 01 00 00 83 38 02 75 0b 8b 80 08 02 00 00 e8 9c ee fd EIP: [c0137c22] module_put+0x7/0x1f SS:ESP 0068:c1fa3f38 kobject pcmcia: registering. parent: NULL, set: module kobject holders: registering. parent: pcmcia, set: NULL kobject_uevent_env Marvellous. I cannot reproduce it with my current lineup. Maybe someone fixed it in one of the subsystem trees. If you have time, could you please test http://userweb.kernel.org/~akpm/ml.bz2 (against 2.6.21-rc4). It surprises me that ipw2200 does this: [ 104.284000] kobject 'ipw2200' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Andy Whitcroft wrote: Andy Whitcroft wrote: Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ [All of the below is from the pre hot-fix runs. The very few results which are in for the hot-fix runs seem worse if anything. :( All results should be out on TKO.] - Restored the RSDL CPU scheduler (a new version thereof) Unsure if the above is the culprit but there seems to be a smattering of BUG's in kernbench from the schedular on several systems, and panics which do not fully dump out. elm3b239 is about 2/4 kernbench being the test in progress when we blammo in both failed tests, elm3b234 doesn't boot at all. Well I have one result through for backing RSDL out on elm3b239 and that does indeed seem to give us a successful boot and test. peterz has pointed me to an incremental patch from Con which I'll push through testing and see if that sorts it out. Ok, tested the patch below on top of 2.6.21-rc4-mm1 and this seems to fix the problem: http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc4-mm1-rsdl-0.32.patch Hard to tell from that patch whether it will be fixed in the changes already committed to the next -mm. Its possible that it may be fixed by the following patch: sched-rsdl-improvements.patch Which has the following slipped in at the end of the changelog: A tiny change checking for MAX_PRIO in normal_prio() may prevent oopses on bootup on large SMP due to forking off the idle task. Con, are all the changes in the 0.32 patch above with akpm? -apw - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Thursday 22 March 2007 20:48, Andy Whitcroft wrote: Andy Whitcroft wrote: Andy Whitcroft wrote: Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc 4/2.6.21-rc4-mm1/ [All of the below is from the pre hot-fix runs. The very few results which are in for the hot-fix runs seem worse if anything. :( All results should be out on TKO.] - Restored the RSDL CPU scheduler (a new version thereof) Unsure if the above is the culprit but there seems to be a smattering of BUG's in kernbench from the schedular on several systems, and panics which do not fully dump out. elm3b239 is about 2/4 kernbench being the test in progress when we blammo in both failed tests, elm3b234 doesn't boot at all. Well I have one result through for backing RSDL out on elm3b239 and that does indeed seem to give us a successful boot and test. peterz has pointed me to an incremental patch from Con which I'll push through testing and see if that sorts it out. Ok, tested the patch below on top of 2.6.21-rc4-mm1 and this seems to fix the problem: http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc4-mm1-rsdl-0.32.p atch Hard to tell from that patch whether it will be fixed in the changes already committed to the next -mm. Its possible that it may be fixed by the following patch: sched-rsdl-improvements.patch Which has the following slipped in at the end of the changelog: A tiny change checking for MAX_PRIO in normal_prio() may prevent oopses on bootup on large SMP due to forking off the idle task. Con, are all the changes in the 0.32 patch above with akpm? Yes he's queued everything in that patch you tested for the next -mm. Thanks very much for testing it. -- -ck - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Wed, 21 Mar 2007 23:39:17 -0800, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall [EMAIL PROTECTED] wrote: With the latest -mm, I'm now getting this: Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected value (0) Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw request_firmware failed: Reason -2 Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2 Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network device The firmware loading bug is caused by driver-core-handles-kobject_uevent-failure-while-device_add.patch Hm, this patch looks sane. It might be a good idea to enable CONFIG_DEBUG_KOBJECT and find out why kobject_uevent() actually fails in this case... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Thu, Mar 22, 2007 at 09:17:00AM +, David Woodhouse wrote: On Wed, 2007-03-21 at 12:59 +0100, Sam Ravnborg wrote: I will give it a shot tonight. Thanks. I'll delete the syscalls-2.6.git tree now that you have it. One issue I have with current approach is that the ARCH specific things are in a single .h file. Que? There aren't really any arch-specific things, except for a list of syscalls to be ignored which are i386-specific. That's because we're pulling in the 'master' system call list from asm-i386/unistd.h, and we need to exclude some of those which we don't really need on other architectures. Yep - realized this when I took a closer look. One thing striked my mind. It is correct that new things gets added to i386 first these days? To me it looks like x86_64 is growing larger than i386 among the developers these days so using asm-x86_64/unistd.h could be a better choice? Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1 + 4 hotfixes -- BUG: unable to handle kernel paging request at virtual address 6b6b6ceb -- EIP is at module_put+0x7/0x1f
I cannot reproduce the BUG with your ml.bz2 patch applied. I am seeing this with both 2.6.21-rc4-mm1 + hotfixes, and with 2.6.21-rc4 + ml.bz2: Mar 22 09:10:35 FractalPath kernel: ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) Mar 22 09:10:35 FractalPath kernel: The kobject at, or inside per_cpu__cpuidle_devices+0x40/0x558 is not dynamically allocated. Mar 22 09:10:35 FractalPath kernel: The kobject at, or inside per_cpu__cpuidle_devices+0xd4/0x558 is not dynamically allocated. Mar 22 09:10:35 FractalPath kernel: The kobject at, or inside per_cpu__cpuidle_devices+0x168/0x558 is not dynamically allocated. Mar 22 09:10:35 FractalPath kernel: cpuidle: using driver acpi_idle Not sure if this is a problem. Also, the first time I booted the ml.bz2 build, it hung. I don't have netconsole or a serial debugging system set up, so I have no idea what the problem was. The second boot, ipw2200 loaded with no errors, but NetworkManager wouldn't connect until I removed and reinserted the module. All the best, Miles - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Thu, 2007-03-22 at 12:41 +0100, Sam Ravnborg wrote: Yep - realized this when I took a closer look. One thing striked my mind. It is correct that new things gets added to i386 first these days? Personally I tend to do PowerPC first, but most others seem to do i386, yes. There are still system calls being added to i386 and not x86_64... init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented init/missing_syscalls.h:953:3: warning: #warning syscall lutimesat not implemented init/missing_syscalls.h:956:3: warning: #warning syscall revokeat not implemented init/missing_syscalls.h:959:3: warning: #warning syscall frevoke not implemented To me it looks like x86_64 is growing larger than i386 among the developers these days so using asm-x86_64/unistd.h could be a better choice? Or perhaps the union of i386, x86_64 and powerpc. But I think i386 is good enough for now. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Thu, Mar 22, 2007 at 04:25:53PM +, David Woodhouse wrote: On Thu, 2007-03-22 at 12:41 +0100, Sam Ravnborg wrote: Yep - realized this when I took a closer look. One thing striked my mind. It is correct that new things gets added to i386 first these days? Personally I tend to do PowerPC first, but most others seem to do i386, yes. There are still system calls being added to i386 and not x86_64... init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented init/missing_syscalls.h:953:3: warning: #warning syscall lutimesat not implemented init/missing_syscalls.h:956:3: warning: #warning syscall revokeat not implemented init/missing_syscalls.h:959:3: warning: #warning syscall frevoke not implemented To me it looks like x86_64 is growing larger than i386 among the developers these days so using asm-x86_64/unistd.h could be a better choice? Or perhaps the union of i386, x86_64 and powerpc. But I think i386 is good enough for now. I kept i386 as default so all is good. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
