Re: kmalloc() of 4MB causes "kernel BUG at slab.c:1542!"
On Wed, 17 Jan 2001, Rick Richardson wrote: > Problem: kmalloc() of 4M causes kernel message "kernel BUG at slab.c:1542" This BUG() has been been removed in the later -ac patches as it was meant to be a temporary debugging help during the -test3 slab.c changes. This does not however remove the constraint that kmalloc can only allocate a maximum of 128KB. How you solve this will depend what you want to use the memory for. -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kmalloc() of 4MB causes kernel BUG at slab.c:1542!
On Wed, 17 Jan 2001, Rick Richardson wrote: Problem: kmalloc() of 4M causes kernel message "kernel BUG at slab.c:1542" This BUG() has been been removed in the later -ac patches as it was meant to be a temporary debugging help during the -test3 slab.c changes. This does not however remove the constraint that kmalloc can only allocate a maximum of 128KB. How you solve this will depend what you want to use the memory for. -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PRoblem with pcnet32 under 2.4.0 , was :Drivers under 2.4
On Fri, 12 Jan 2001, Danny ter Haar wrote: > According to Hans Grobler: > > If you're willing, would you please follow "REPORTING-BUGS" and send some > > more info. Also cat /proc/interrupts. This one's intriging... Thanks for the report (still studying it). > lspci -vx output: > > 00:0f.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] ( What about the other devices? > irq 0: 16840 timer irq 9: 0 acpi, PCnet/FAST III Ok, this may not mean much, but have you tried compiling without acpi? Just to remove some variables... -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PRoblem with pcnet32 under 2.4.0 , was :Drivers under 2.4
On Fri, 12 Jan 2001, Danny ter Haar wrote: According to Hans Grobler: If you're willing, would you please follow "REPORTING-BUGS" and send some more info. Also cat /proc/interrupts. This one's intriging... Thanks for the report (still studying it). lspci -vx output: 00:0f.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] ( What about the other devices? irq 0: 16840 timer irq 9: 0 acpi, PCnet/FAST III Ok, this may not mean much, but have you tried compiling without acpi? Just to remove some variables... -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers under 2.4
Hi Danny, If you're willing, would you please follow "REPORTING-BUGS" and send some more info. Also cat /proc/interrupts. This one's intriging... -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-ac6: drivers/net/rcpci45.c typo
On Thu, 11 Jan 2001, Karsten Hopp (Red Hat) wrote:
> --- ./drivers/net/rcpci45.c.origThu Jan 11 12:49:19 2001
> +++ ./drivers/net/rcpci45.c Thu Jan 11 12:47:04 2001
> @@ -120,7 +120,7 @@
> { RC_PCI45_VENDOR_ID, RC_PCI45_DEVICE_ID, PCI_ANY_ID,
> PCI_ANY_ID, },
> { }
> };
> -MODULE_DEVICE_TABLE(pci, rcpci_pci_table);
> +MODULE_DEVICE_TABLE(pci, rcpci45_pci_table);
>
> static void __exit rcpci45_remove_one(struct pci_dev *pdev)
> {
Yes we know about this one. This is a bug that was killed, and then came
back to life. We're still trying to figure out how... :)
-- Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0: Small observation in /proc/sys/net/unix/
On Thu, 11 Jan 2001, Darryl Miles wrote: > # ls -il /proc/sys/net/unix/ > total 24 >4446 -rw--- 1 root root0 Jan 11 11:06 > max_dgram_qlen >4446 -rw--- 1 root root0 Jan 11 11:06 > max_dgram_qlen > > Identical filenames, nothing bad appears to be happening it just looks > weird. This has been fixed in Alan's patches. -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0: Small observation in /proc/sys/net/unix/
On Thu, 11 Jan 2001, Darryl Miles wrote: # ls -il /proc/sys/net/unix/ total 24 4446 -rw--- 1 root root0 Jan 11 11:06 max_dgram_qlen 4446 -rw--- 1 root root0 Jan 11 11:06 max_dgram_qlen Identical filenames, nothing bad appears to be happening it just looks weird. This has been fixed in Alan's patches. -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-ac6: drivers/net/rcpci45.c typo
On Thu, 11 Jan 2001, Karsten Hopp (Red Hat) wrote:
--- ./drivers/net/rcpci45.c.origThu Jan 11 12:49:19 2001
+++ ./drivers/net/rcpci45.c Thu Jan 11 12:47:04 2001
@@ -120,7 +120,7 @@
{ RC_PCI45_VENDOR_ID, RC_PCI45_DEVICE_ID, PCI_ANY_ID,
PCI_ANY_ID, },
{ }
};
-MODULE_DEVICE_TABLE(pci, rcpci_pci_table);
+MODULE_DEVICE_TABLE(pci, rcpci45_pci_table);
static void __exit rcpci45_remove_one(struct pci_dev *pdev)
{
Yes we know about this one. This is a bug that was killed, and then came
back to life. We're still trying to figure out how... :)
-- Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers under 2.4
Hi Danny, If you're willing, would you please follow "REPORTING-BUGS" and send some more info. Also cat /proc/interrupts. This one's intriging... -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers under 2.4
On Wed, 10 Jan 2001, Andi Kleen wrote: > On Wed, Jan 10, 2001 at 04:37:06PM -0500, Dennis wrote: > > > > Aren't you supposed to design the spec BEFORE you implement it? > > Try http://www.firstfloor.org/~andi/softnet (minor details outdated) The softnet changes are most likely the primary source of breakage (for network drivers). You should also read the kernel-* docs under Documentation/DocBook (see Documentation/kernel-doc-nano-HOWTO.txt). -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.4.0-ac5
On Wed, 10 Jan 2001, Nathan Walp wrote: > Here it is... I opted to cut out the 1200-odd warnings, which from the > look of them were all because i'm running it under 2.4.0-ac4 (which > boots fine). Thanks! My local mirror does not have -ac5 yet so I can't help immediately. From the -ac5 log & the oops it looks as if Ingo's change isn't quite complete yet... o Uniprocessor APIC support/NMI wdog etc (Ingo Molnar) Until then, what about disabling APIC support and trying again. This will help confirm it... although it looks pretty definite. -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.4.0-ac5
On Wed, 10 Jan 2001, Nathan Walp wrote: > First post to the list, hope I get this right... Could you please run this through ksymoops on your machine. Depending on which distribution you're using, this can be as simple as: ksymoops < oops.txt Remember to set the System.map to the correct one, if you did not compile in /usr/src/linux. Thanks, -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers under 2.4
On Wed, 10 Jan 2001, Dennis wrote: > At 02:57 PM 01/09/2001, Dennis wrote: > >Where might one find the definitive document on porting device drivers to > >2.4 kernels? > > should I assume that there are none? I don't think anyone has had the time yet. I'm sure someone will get around to this soon. If you ask specific questions here, the answers may well form the basis for such a document. -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers under 2.4
On Wed, 10 Jan 2001, Dennis wrote: At 02:57 PM 01/09/2001, Dennis wrote: Where might one find the definitive document on porting device drivers to 2.4 kernels? should I assume that there are none? I don't think anyone has had the time yet. I'm sure someone will get around to this soon. If you ask specific questions here, the answers may well form the basis for such a document. -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.4.0-ac5
On Wed, 10 Jan 2001, Nathan Walp wrote: First post to the list, hope I get this right... Could you please run this through ksymoops on your machine. Depending on which distribution you're using, this can be as simple as: ksymoops oops.txt Remember to set the System.map to the correct one, if you did not compile in /usr/src/linux. Thanks, -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.4.0-ac5
On Wed, 10 Jan 2001, Nathan Walp wrote: Here it is... I opted to cut out the 1200-odd warnings, which from the look of them were all because i'm running it under 2.4.0-ac4 (which boots fine). Thanks! My local mirror does not have -ac5 yet so I can't help immediately. From the -ac5 log the oops it looks as if Ingo's change isn't quite complete yet... o Uniprocessor APIC support/NMI wdog etc (Ingo Molnar) Until then, what about disabling APIC support and trying again. This will help confirm it... although it looks pretty definite. -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers under 2.4
On Wed, 10 Jan 2001, Andi Kleen wrote: On Wed, Jan 10, 2001 at 04:37:06PM -0500, Dennis wrote: Aren't you supposed to design the spec BEFORE you implement it? Try http://www.firstfloor.org/~andi/softnet (minor details outdated) The softnet changes are most likely the primary source of breakage (for network drivers). You should also read the kernel-* docs under Documentation/DocBook (see Documentation/kernel-doc-nano-HOWTO.txt). -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: SCSI hangs with aic7xxx in 2.4.0 SMP
On Sat, 6 Jan 2001, mull wrote: > On Sat, Jan 06, 2001 at 09:26:55PM -, Craig Freeze wrote: > > [1.] One line summary of the problem: > > SCSI hangs with aic7xxx in 2.4.0 SMP > > > > [2.] Full description of the problem/report: > > SCSI device errors and bus resets observed in 2.4.0 that do not occur in > > 2.2.13. Sysrq keys have no effect (ie hard reset required to recover) > > > I've noticed pretty much the same situation on my uniproc box, aic7xxx driver, > adaptec 2940uw card since going to 2.4.0-prerelease. haven't had to hard > reset, but have seen a LOT of scsi timeout errors. i did not notice this > on 2.4.0-test12 or test13pre2. when i'm at home i'll see if i can find > any pattern or more info, and also test with 2.4.0 final. > mullein I have not seen any such problems, even under very high loads. Would you please submit a detailed bug report (such as the previous poster) using the guidelines in REPORTING-BUGS. Thanks, -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: SCSI hangs with aic7xxx in 2.4.0 SMP
On Sat, 6 Jan 2001, mull wrote: On Sat, Jan 06, 2001 at 09:26:55PM -, Craig Freeze wrote: [1.] One line summary of the problem: SCSI hangs with aic7xxx in 2.4.0 SMP [2.] Full description of the problem/report: SCSI device errors and bus resets observed in 2.4.0 that do not occur in 2.2.13. Sysrq keys have no effect (ie hard reset required to recover) I've noticed pretty much the same situation on my uniproc box, aic7xxx driver, adaptec 2940uw card since going to 2.4.0-prerelease. haven't had to hard reset, but have seen a LOT of scsi timeout errors. i did not notice this on 2.4.0-test12 or test13pre2. when i'm at home i'll see if i can find any pattern or more info, and also test with 2.4.0 final. mullein I have not seen any such problems, even under very high loads. Would you please submit a detailed bug report (such as the previous poster) using the guidelines in REPORTING-BUGS. Thanks, -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-prerelease, AX25 problems
Hi Jean-Luc, On Mon, 1 Jan 2001, f5ibh wrote: > You wrote : > > Is the "previous test version" you talk about 2.4.0-test13-pre7? There > > weren't any changes since then that could explain this, except maybe: > Yes, I mean test13-pre[12134567] and other older versions too. > I've already had the problem some time ago with an older 2.4.0-testxx kernel. > I don't think it is directly related to the ax25 stuff but maybe (?) a timer > modified elsewhere ? Ok, so the problem lies deeper. Could you take a guess at the version that worked (say 2.2.17?) and the first one that stopped working (say 2.4.0-test1?)... Once we have a rough range, I'll see if I can find anything. Also: I assume you have PROC_FS compiled. What does /proc/net/z8530drv contain before and after the failed packet TX attempt? And: Can you receive any packets? -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-prerelease, AX25 problems
On Mon, 1 Jan 2001, f5ibh wrote: > I've just compiled and tested 2.4.0-prerelease. My AX25 (hamradio) system does > not work with this new release. There is a timing problem. When a fram is sent > on the air, the frame is VERY long (switched off by the watchdog of my drsi > card) and contains no data. On this point of vue, the previous test version was > right. Is the "previous test version" you talk about 2.4.0-test13-pre7? There weren't any changes since then that could explain this, except maybe: > Gnu C 2.95.2 The minimum required gcc for 2.4 is now 2.91.66. However, AFAIK 2.95.5 was considered suspect at one point. -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-prerelease, AX25 problems
On Mon, 1 Jan 2001, f5ibh wrote: I've just compiled and tested 2.4.0-prerelease. My AX25 (hamradio) system does not work with this new release. There is a timing problem. When a fram is sent on the air, the frame is VERY long (switched off by the watchdog of my drsi card) and contains no data. On this point of vue, the previous test version was right. Is the "previous test version" you talk about 2.4.0-test13-pre7? There weren't any changes since then that could explain this, except maybe: Gnu C 2.95.2 The minimum required gcc for 2.4 is now 2.91.66. However, AFAIK 2.95.5 was considered suspect at one point. -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-prerelease, AX25 problems
Hi Jean-Luc, On Mon, 1 Jan 2001, f5ibh wrote: You wrote : Is the "previous test version" you talk about 2.4.0-test13-pre7? There weren't any changes since then that could explain this, except maybe: Yes, I mean test13-pre[12134567] and other older versions too. I've already had the problem some time ago with an older 2.4.0-testxx kernel. I don't think it is directly related to the ax25 stuff but maybe (?) a timer modified elsewhere ? Ok, so the problem lies deeper. Could you take a guess at the version that worked (say 2.2.17?) and the first one that stopped working (say 2.4.0-test1?)... Once we have a rough range, I'll see if I can find anything. Also: I assume you have PROC_FS compiled. What does /proc/net/z8530drv contain before and after the failed packet TX attempt? And: Can you receive any packets? -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-prerelease compile error in (maybe) mkiss
On 1 Jan 2001, Pierfrancesco Caci wrote: > Hi there... first compilation error of 2001 (at least in my timezone :-) > > ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext >arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ > --start-group \ > arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o >ipc/ipc.o \ > drivers/block/block.o drivers/char/char.o drivers/misc/misc.o >drivers/net/net.o drivers/media/media.o drivers/char/drm/drm.o drivers/isdn/isdn.a >drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o >drivers/pci/driver.o drivers/video/video.o drivers/net/hamradio/hamradio.o >drivers/acpi/acpi.o drivers/md/mddev.o \ > net/network.o \ > /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a >/usr/src/linux/arch/i386/lib/lib.a \ > --end-group \ > -o vmlinux > drivers/net/net.o: In function `network_ldisc_init': > drivers/net/net.o(.text.init+0x135): undefined reference to `mkiss_init_ctrl_dev' > make: *** [vmlinux] Error 1 Yes, this is a known problem (the patch below got lost). MKISS still has a few other pending issues to resolve for 2.4 so I would recommend you use it with care. Working on fixing it... -- Hans diff -u4Nr -X dontdiff linux-2.4.0-prerelease.orig/drivers/net/setup.c linux-2.4.0-prerelease/drivers/net/setup.c --- linux-2.4.0-prerelease.orig/drivers/net/setup.c Mon Dec 11 21:38:29 2000 +++ linux-2.4.0-prerelease/drivers/net/setup.c Mon Jan 1 07:21:15 2001 @@ -8,9 +8,8 @@ #include #include #include -extern int mkiss_init_ctrl_dev(void); extern int slip_init_ctrl_dev(void); extern int strip_init_ctrl_dev(void); extern int x25_asy_init_ctrl_dev(void); @@ -147,11 +146,8 @@ slip_init_ctrl_dev(); #endif #if defined(CONFIG_X25_ASY) x25_asy_init_ctrl_dev(); -#endif -#if defined(CONFIG_MKISS) - mkiss_init_ctrl_dev(); #endif #if defined(CONFIG_STRIP) strip_init_ctrl_dev(); #endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-prerelease compile error in (maybe) mkiss
On 1 Jan 2001, Pierfrancesco Caci wrote: Hi there... first compilation error of 2001 (at least in my timezone :-) ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/drm/drm.o drivers/isdn/isdn.a drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o drivers/net/hamradio/hamradio.o drivers/acpi/acpi.o drivers/md/mddev.o \ net/network.o \ /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a /usr/src/linux/arch/i386/lib/lib.a \ --end-group \ -o vmlinux drivers/net/net.o: In function `network_ldisc_init': drivers/net/net.o(.text.init+0x135): undefined reference to `mkiss_init_ctrl_dev' make: *** [vmlinux] Error 1 Yes, this is a known problem (the patch below got lost). MKISS still has a few other pending issues to resolve for 2.4 so I would recommend you use it with care. Working on fixing it... -- Hans diff -u4Nr -X dontdiff linux-2.4.0-prerelease.orig/drivers/net/setup.c linux-2.4.0-prerelease/drivers/net/setup.c --- linux-2.4.0-prerelease.orig/drivers/net/setup.c Mon Dec 11 21:38:29 2000 +++ linux-2.4.0-prerelease/drivers/net/setup.c Mon Jan 1 07:21:15 2001 @@ -8,9 +8,8 @@ #include linux/errno.h #include linux/init.h #include linux/netlink.h -extern int mkiss_init_ctrl_dev(void); extern int slip_init_ctrl_dev(void); extern int strip_init_ctrl_dev(void); extern int x25_asy_init_ctrl_dev(void); @@ -147,11 +146,8 @@ slip_init_ctrl_dev(); #endif #if defined(CONFIG_X25_ASY) x25_asy_init_ctrl_dev(); -#endif -#if defined(CONFIG_MKISS) - mkiss_init_ctrl_dev(); #endif #if defined(CONFIG_STRIP) strip_init_ctrl_dev(); #endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test12pre3ac4
On Fri, 22 Dec 2000, Alan Cox wrote:
> o Quota fixes/updates (Jan Kara)
This patch (?) to breaks compiling without quota's...
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.13pre3/mm/vmscan.c linux.ac/mm/vmscan.c
--- linux.13pre3/mm/vmscan.cTue Dec 19 13:30:29 2000
+++ linux.ac/mm/vmscan.cThu Dec 21 21:21:00 2000
@@ -943,6 +943,7 @@
*/
shrink_dcache_memory(priority, gfp_mask);
shrink_icache_memory(priority, gfp_mask);
+ shrink_dqcache_memory(priority, gfp_mask);
/*
* Then, try to page stuff out..
@@ -1004,6 +1005,7 @@
if (free_shortage() || inactive_shortage()) {
shrink_dcache_memory(6, gfp_mask);
shrink_icache_memory(6, gfp_mask);
+ shrink_dqcache_memory(6, gfp_mask);
ret += refill_inactive(gfp_mask, user);
} else {
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0test12pre3ac4
On Fri, 22 Dec 2000, Alan Cox wrote:
o Quota fixes/updates (Jan Kara)
This patch (?) to breaks compiling without quota's...
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.13pre3/mm/vmscan.c linux.ac/mm/vmscan.c
--- linux.13pre3/mm/vmscan.cTue Dec 19 13:30:29 2000
+++ linux.ac/mm/vmscan.cThu Dec 21 21:21:00 2000
@@ -943,6 +943,7 @@
*/
shrink_dcache_memory(priority, gfp_mask);
shrink_icache_memory(priority, gfp_mask);
+ shrink_dqcache_memory(priority, gfp_mask);
/*
* Then, try to page stuff out..
@@ -1004,6 +1005,7 @@
if (free_shortage() || inactive_shortage()) {
shrink_dcache_memory(6, gfp_mask);
shrink_icache_memory(6, gfp_mask);
+ shrink_dqcache_memory(6, gfp_mask);
ret += refill_inactive(gfp_mask, user);
} else {
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Hard lockup using emu10k1-based sound card
On Wed, 15 Nov 2000, Jonathan Corbet wrote: > Just as another data point, I, too, had trouble with lockups with the > emu10k1 (with the 2.4.0-test driver and ALSA both). I noticed that it was > sharing an interrupt with ACPI. As soon as I rebuilt the kernel with the > ACPI Interpreter option turned off, the problem went away. In my case, the emu10k1 has an IRQ all to itself... (and I don't have ACPI enabled). Been running the kernel emu10k1 on test11-pre5 since this morning. I've only had one lockup (older testX emu10k1's locked up more frequently). So there still appears to be a problem with (or triggered by) test11-pre5 emu10k1. As I was under X at that stage (XMMS & two xterms), I did not see any panic()'s or BUG()'s. Next I'm going to compile with serial console & see if I can see any panic() or BUG()s. -- Hans. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Hard lockup using emu10k1-based sound card
On Wed, 15 Nov 2000, Jonathan Corbet wrote: Just as another data point, I, too, had trouble with lockups with the emu10k1 (with the 2.4.0-test driver and ALSA both). I noticed that it was sharing an interrupt with ACPI. As soon as I rebuilt the kernel with the ACPI Interpreter option turned off, the problem went away. In my case, the emu10k1 has an IRQ all to itself... (and I don't have ACPI enabled). Been running the kernel emu10k1 on test11-pre5 since this morning. I've only had one lockup (older testX emu10k1's locked up more frequently). So there still appears to be a problem with (or triggered by) test11-pre5 emu10k1. As I was under X at that stage (XMMS two xterms), I did not see any panic()'s or BUG()'s. Next I'm going to compile with serial console see if I can see any panic() or BUG()s. -- Hans. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Hard lockup using emu10k1-based sound card
On Tue, 14 Nov 2000, Rui Sousa wrote: > Which was the latest kernel you tried? A (easy to trigger) deadlock was > fixed around 2.4.0-test... It was around test7... I think. I remember seeing changes to emu10k1 in the patch and I tried that version. It still crashed. I work almost exclusively command line and saw no kernel error messages. The system simply locked up and did not respond to SysRq etc. I'll try test11-pre5 today. -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Hard lockup using emu10k1-based sound card
On Tue, 14 Nov 2000, Rui Sousa wrote: Which was the latest kernel you tried? A (easy to trigger) deadlock was fixed around 2.4.0-test... It was around test7... I think. I remember seeing changes to emu10k1 in the patch and I tried that version. It still crashed. I work almost exclusively command line and saw no kernel error messages. The system simply locked up and did not respond to SysRq etc. I'll try test11-pre5 today. -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Hard lockup using emu10k1-based sound card
On Mon, 13 Nov 2000, Willis L. Sarka wrote: > I get a hard lockup when trying to play a mp3 with XMMS; > Sound Blaster Live card. The first second loops, and I lose all > connectivity to the machine; I can't ping it, can't to a an Alt-Sysq, > nothing. Just for reference, I've been use the ALSA drivers for most of the 2.4.0-testX kernels without any problems (provided you use the driver version that matches the kernel version). Even under high memory preasure, swapping, NFS traffic, etc. the worst that happens is sporadic skipping. XMMS and mpg123 in use. I've tried the kernel emu10k1 a few times but also got similar lockup's. I haven't tried the kernel emu10k1 since the NMI watchdog was added. This should show something? ... but I guess you can't see anything because you're in X. I wonder if you'd see anything if you were using mpg123 and working on the console? My system: RedHat 7.0 kernel 2.4.0-test11pre3 SMP (soundcore as modules) ALSA drivers 0.5.9d Gigabyte 440BX SMP (Dual Pentium II 450), 256MB, Intel Ethernet Pro 100, Adaptec AIC-7895 Ultra SCSI -- Hans Grobler <[EMAIL PROTECTED]> Department Electronic & Electrical Engineering University of Stellenbosch, South Africa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Hard lockup using emu10k1-based sound card
On Mon, 13 Nov 2000, Willis L. Sarka wrote: I get a hard lockup when trying to play a mp3 with XMMS; Sound Blaster Live card. The first second loops, and I lose all connectivity to the machine; I can't ping it, can't to a an Alt-Sysq, nothing. Just for reference, I've been use the ALSA drivers for most of the 2.4.0-testX kernels without any problems (provided you use the driver version that matches the kernel version). Even under high memory preasure, swapping, NFS traffic, etc. the worst that happens is sporadic skipping. XMMS and mpg123 in use. I've tried the kernel emu10k1 a few times but also got similar lockup's. I haven't tried the kernel emu10k1 since the NMI watchdog was added. This should show something? ... but I guess you can't see anything because you're in X. I wonder if you'd see anything if you were using mpg123 and working on the console? My system: RedHat 7.0 kernel 2.4.0-test11pre3 SMP (soundcore as modules) ALSA drivers 0.5.9d Gigabyte 440BX SMP (Dual Pentium II 450), 256MB, Intel Ethernet Pro 100, Adaptec AIC-7895 Ultra SCSI -- Hans Grobler [EMAIL PROTECTED] Department Electronic Electrical Engineering University of Stellenbosch, South Africa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test11pre3: MD module compile fail, sysctl.h again
make -C md modules make[2]: Entering directory `/usr/src/linux-2.4.0-test11-pre3/drivers/md' kgcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11-pre3/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.0-test11-pre3/include/linux/modversions.h -DEXPORT_SYMTAB -c md.c In file included from md.c:33: /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:35: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:35: warning: no semicolon at end of struct or union /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:37: parse error before `newlen' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:37: warning: type defaults to `int' in declaration of `newlen' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:37: warning: data definition has no type or storage class /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:39: parse error before `}' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:598: syntax error before `long' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:604: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:606: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:609: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:609: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:609: warning: its scope is only this definition or declaration, /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:609: warning: which is probably not what you want. /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:609: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:612: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:612: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:612: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:614: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:614: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:614: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:616: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:616: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:616: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:618: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:618: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:618: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:620: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:620: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:620: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:622: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:622: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:622: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:624: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:624: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:624: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:627: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:628: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:632: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:633: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:684: parse error before `mode_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:684: warning: no semicolon at end of struct or union /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:686: `proc_handler' redeclared as different kind of symbol /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:609: previous declaration of `proc_handler' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:691: parse error before `}' md.c:83: elements of array `raid_table' have
test11pre3: MD module compile fail, sysctl.h again
make -C md modules make[2]: Entering directory `/usr/src/linux-2.4.0-test11-pre3/drivers/md' kgcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11-pre3/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.0-test11-pre3/include/linux/modversions.h -DEXPORT_SYMTAB -c md.c In file included from md.c:33: /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:35: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:35: warning: no semicolon at end of struct or union /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:37: parse error before `newlen' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:37: warning: type defaults to `int' in declaration of `newlen' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:37: warning: data definition has no type or storage class /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:39: parse error before `}' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:598: syntax error before `long' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:604: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:606: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:609: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:609: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:609: warning: its scope is only this definition or declaration, /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:609: warning: which is probably not what you want. /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:609: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:612: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:612: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:612: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:614: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:614: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:614: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:616: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:616: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:616: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:618: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:618: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:618: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:620: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:620: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:620: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:622: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:622: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:622: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:624: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:624: warning: `struct file' declared inside parameter list /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:624: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:627: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:628: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:632: parse error before `size_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:633: warning: function declaration isn't a prototype /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:684: parse error before `mode_t' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:684: warning: no semicolon at end of struct or union /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:686: `proc_handler' redeclared as different kind of symbol /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:609: previous declaration of `proc_handler' /usr/src/linux-2.4.0-test11-pre3/include/linux/sysctl.h:691: parse error before `}' md.c:83: elements of array `raid_table' have
Re: Request for net guru help: waitqueue oops
On Wed, 4 Oct 2000, Petko Manolov wrote: > > The timer routines (there are 4) are used to switch hardware states and > > must therefore be mutually exclusive with respect to the interrupt handler. > > There are no bottom halves used in this driver. Andrew Morton suggested > > that the problem could be in my use of the skb pointers, which seems > > a likely candidate. I'll check that. > > It might be, but it might not. Be careful about locking and calling > procedures which can sleep from interrupt context. > > Sorry if i am not enough specific, i haven't seen the code ;-) I have found another driver in the standard kernel that also causes this oops and have posted to linux-net (as this appears to be networking related). Thanks -- Hans. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Request for net guru help: waitqueue oops
On Wed, 4 Oct 2000, Petko Manolov wrote: The timer routines (there are 4) are used to switch hardware states and must therefore be mutually exclusive with respect to the interrupt handler. There are no bottom halves used in this driver. Andrew Morton suggested that the problem could be in my use of the skb pointers, which seems a likely candidate. I'll check that. It might be, but it might not. Be careful about locking and calling procedures which can sleep from interrupt context. Sorry if i am not enough specific, i haven't seen the code ;-) I have found another driver in the standard kernel that also causes this oops and have posted to linux-net (as this appears to be networking related). Thanks -- Hans. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Request for net guru help: waitqueue oops
On Tue, 3 Oct 2000, Petko Manolov wrote: > None of these can sleep. netif_*_queue routines are quite simple. > They are all atomic so there is no need to protect them with locks. Ok. I originally had them outside locks as they appeared to be atomic. I moved them in incase they were the cause of the problem. > It is not clear from the example above if it is needed to lock in > the timer routine and what is locked inside. Anyway be careful > about locking regions shared between interrupts/bottom halves and > user context as this happens often. The timer routines (there are 4) are used to switch hardware states and must therefore be mutually exclusive with respect to the interrupt handler. There are no bottom halves used in this driver. Andrew Morton suggested that the problem could be in my use of the skb pointers, which seems a likely candidate. I'll check that. Thanks -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Request for net guru help: waitqueue oops
Hi Petkan,
Thanks for your comment.
On Tue, 3 Oct 2000, Petko Manolov wrote:
> > A driver I'm working on seems to be doing/triggering something related
> > to waitqueues. This causes a perfectly reproducable oops (small mercies!).
> > Since the oops is not happening in my driver, I'm having a hard time
> > figuring out whats going wrong. I suspect a networking guru will take
> > one look and know what I'm doing wrong. Any suggestions please?
>
>
> It seems you're trying to sleep without process context (most likely in
> net_tx_action). It would be more clear if you send that part of the
> code.
Since I don't explictly sleep anywhere, I'm not sure which code fragment
would be useful... (net_tx_action is part of the networking layers). Which
network functions can sleep (netif_rx, netif_stop_queue, netif_wake_queue,
...) ?
After reading the softnet HOWTO, and some of the network drivers, I
was unsure about the netif_stop_queue and netif_wake_queue functions. The
howto indicated that these two should be protected from concurrent
execution by a private lock. Not all the drivers seem to do this. In my
case (although I'm running UP at the moment), I've used a driver global
spinlock, for example:
spinlock_t driver_lock = SPIN_LOCK_UNLOCKED;
int scc72_hard_xmit (struct sk_buff *skb, struct net_device *dev)
{
unsigned long flags;
/* ... */
spin_lock_irqsave (_lock, flags);
netif_stop_queue (dev);
spin_unlock_irqrestore (_lock, flags);
/* ... */
}
/* Example timer callback, to wake the queue */
void scc72_interframewait (unsigned long channel)
{
unsigned long flags;
struct scc72_channel *scc = (struct scc72_channel *) channel;
/* ... */
spin_lock_irqsave (_lock, flags);
/* ... */
if (netif_queue_stopped (scc->dev))
netif_wake_queue (scc->dev);
spin_unlock_irqrestore (_lock, flags);
}
I've just checked my driver, and below is the list of all the external
functions called. Any idea which of these could be trying to sleep?
dev_kfree_skb_any (called from both hard IRQ and non IRQ context)
dev_alloc_skb (called from both hard IRQ and non IRQ context)
del_timer (called from both hard IRQ and non IRQ context)
add_timer (called from both hard IRQ and non IRQ context)
netif_rx (called from IRQ context)
netif_start_queue (called from non hard IRQ context, ex: dev_open)
netif_stop_queue (called from non hard IRQ context, ex: hard_start_xmit)
netif_wake_queue (called from non hard IRQ context, ex: timer callbacks)
netif_queue_stopped (called from non hard IRQ context, ex: timer callbacks)
skb_queue_tail(called from non hard IRQ context, ex: hard_start_xmit)
skb_dequeue (called from both hard IRQ and non IRQ context)
skb_queue_head_init (called from non hard IRQ context, ex: dev_open)
and the standard functions dev_init_buffers, register_netdevice,
copy_from_user, unregister_netdev, etc. called in the standard places.
skb_queue_tail, skb_dequeue and skb_queue_head_init are used to manage
an internal queue of outgoing skb's.
Thanks.
-- Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Request for net guru help: waitqueue oops
Hi all, A driver I'm working on seems to be doing/triggering something related to waitqueues. This causes a perfectly reproducable oops (small mercies!). Since the oops is not happening in my driver, I'm having a hard time figuring out whats going wrong. I suspect a networking guru will take one look and know what I'm doing wrong. Any suggestions please? Initially, I was getting the first oops below. After browsing the waitqueue code, I found and enabled the WAITQUEUE_DEBUG define. Now I'm getting the second oops. The values 8729, 8731 in eax ebx ecx (first oops) and in the magic & creator field (second oops) look very weird... something incrementing... In my driver I have all pointers protected by magic numbers. These are validated before every use (will do a BUG() on invalid pointer). TIA -- Hans. ---[ OOPS1 ]-- ksymoops 2.3.4 on i686 2.4.0-test9. Options used -v /usr/src/linux/vmlinux (specified) -k ./ksyms (specified) -l ./modules (specified) -o /lib/modules/2.4.0-test9 (specified) -m /usr/src/linux/System.map (specified) Unable to handle kernel paging request at virtual address 8731 c0113a70 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010003 eax: 8729 ebx: 8731 ecx: 8731 edx: 0021 esi: edi: 000d ebp: c0231f40 esp: c0231f1c ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0231000) Stack: c3fc59a0 c3fa8800 000d 0110 8731 c17aec6c 0246 0001 0021 c0231fa4 c01a5155 c3fc59a0 c01a4a53 c3fc59a0 c01a55d0 c3fa8800 000d c010a00d c01a7129 c3fa8800 0001 c0269c08 000d Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 1b 89 5d ec 8b 48 04 8b 11 89 d0 24 df 85 45 fc 0f 84 79 >>EIP; c0113a70 <__wake_up+50/144> <= Trace; c01a5155 Trace; c01a4a53 Trace; c01a55d0 <__kfree_skb+7c/11c> Trace; c010a00d Trace; c01a7129 Trace; c01192ee Trace; c010a1a8 Trace; c0107160 Trace; c0107160 Trace; c0108df0 Trace; c0107160 Trace; c0107160 Trace; c0100018 Trace; c0107183 Trace; c01071e4 Trace; c0105000 Trace; c0100192 Code; c0113a70 <__wake_up+50/144> <_EIP>: Code; c0113a70 <__wake_up+50/144> <= 0: 8b 1b mov(%ebx),%ebx <= Code; c0113a72 <__wake_up+52/144> 2: 89 5d ec mov%ebx,0xffec(%ebp) Code; c0113a75 <__wake_up+55/144> 5: 8b 48 04 mov0x4(%eax),%ecx Code; c0113a78 <__wake_up+58/144> 8: 8b 11 mov(%ecx),%edx Code; c0113a7a <__wake_up+5a/144> a: 89 d0 mov%edx,%eax Code; c0113a7c <__wake_up+5c/144> c: 24 df and$0xdf,%al Code; c0113a7e <__wake_up+5e/144> e: 85 45 fc test %eax,0xfffc(%ebp) Code; c0113a81 <__wake_up+61/144> 11: 0f 84 79 00 00 00 je 90 <_EIP+0x90> c0113b00 <__wake_up+e0/144> Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! ---[ OOPS2 ]-- ksymoops 2.3.4 on i686 2.4.0-test9. Options used -v /usr/src/linux/vmlinux (specified) -k ./ksyms (specified) -l ./modules (specified) -o /lib/modules/2.4.0-test9 (specified) -m /usr/src/linux/System.map (specified) bad magic 8722 (should be c2dfbbd4, creator 8723), wq bug, forcing oops. kernel BUG at /usr/src/linux/include/linux/wait.h:155! invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010296 eax: 0037 ebx: c2dfbbc8 ecx: c0240b48 edx: esi: c3bbe060 edi: 000d ebp: c0253fa4 esp: c0253f34 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0253000) Stack: c02291e4 c02291c0 009b c3bbe060 c3f87260 c01b2ea7 c3bbe060 c01b3bc0 c3f87260 000d c01b582a c3f87260 0001 c028bc08 000d c0253fa4 c011b1ae c028bc08 00a0 c02839a0 0005 c010a4a5 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 8d b6 00 00 00 00 8d 43 04 39 43 04 74 0d 8b >>EIP; c01b3715<= Trace; c02291e4 Trace; c02291c0 Trace; c01b2ea7 Trace; c01b3bc0 <__kfree_skb+7c/11c> Trace; c01b582a Trace; c011b1ae Trace; c010a4a5 Trace; c0107160 Trace; c0107160 Trace; c010902c Trace; c0107160 Trace; c0107160 Trace; c0100018 Trace; c0107183 Trace; c01071e4 Trace; c0105000 Trace; c0100192 Code; c01b3715 <_EIP>: Code; c01b3715<= 0: 0f 0b ud2a <= Code; c01b3717 2: 83 c4 0c add$0xc,%esp Code; c01b371a 5: 8d b6 00 00 00 00 lea0x0(%esi),%esi Code; c01b3720 b: 8d 43 04 lea0x4(%ebx),%eax
Request for net guru help: waitqueue oops
Hi all, A driver I'm working on seems to be doing/triggering something related to waitqueues. This causes a perfectly reproducable oops (small mercies!). Since the oops is not happening in my driver, I'm having a hard time figuring out whats going wrong. I suspect a networking guru will take one look and know what I'm doing wrong. Any suggestions please? Initially, I was getting the first oops below. After browsing the waitqueue code, I found and enabled the WAITQUEUE_DEBUG define. Now I'm getting the second oops. The values 8729, 8731 in eax ebx ecx (first oops) and in the magic creator field (second oops) look very weird... something incrementing... In my driver I have all pointers protected by magic numbers. These are validated before every use (will do a BUG() on invalid pointer). TIA -- Hans. ---[ OOPS1 ]-- ksymoops 2.3.4 on i686 2.4.0-test9. Options used -v /usr/src/linux/vmlinux (specified) -k ./ksyms (specified) -l ./modules (specified) -o /lib/modules/2.4.0-test9 (specified) -m /usr/src/linux/System.map (specified) Unable to handle kernel paging request at virtual address 8731 c0113a70 *pde = Oops: CPU:0 EIP:0010:[c0113a70] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010003 eax: 8729 ebx: 8731 ecx: 8731 edx: 0021 esi: edi: 000d ebp: c0231f40 esp: c0231f1c ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0231000) Stack: c3fc59a0 c3fa8800 000d 0110 8731 c17aec6c 0246 0001 0021 c0231fa4 c01a5155 c3fc59a0 c01a4a53 c3fc59a0 c01a55d0 c3fa8800 000d c010a00d c01a7129 c3fa8800 0001 c0269c08 000d Call Trace: [c01a5155] [c01a4a53] [c01a55d0] [c010a00d] [c01a7129] [c01192ee] [c010a1a8] [c0107160] [c0107160] [c0108df0] [c0107160] [c0107160] [c0100018] [c0107183] [c01071e4] [c0105000] [c0100192] Code: 8b 1b 89 5d ec 8b 48 04 8b 11 89 d0 24 df 85 45 fc 0f 84 79 EIP; c0113a70 __wake_up+50/144 = Trace; c01a5155 sock_def_write_space+2d/74 Trace; c01a4a53 sock_wfree+17/30 Trace; c01a55d0 __kfree_skb+7c/11c Trace; c010a00d handle_IRQ_event+31/5c Trace; c01a7129 net_tx_action+45/a0 Trace; c01192ee do_softirq+4e/74 Trace; c010a1a8 do_IRQ+9c/ac Trace; c0107160 default_idle+0/28 Trace; c0107160 default_idle+0/28 Trace; c0108df0 ret_from_intr+0/20 Trace; c0107160 default_idle+0/28 Trace; c0107160 default_idle+0/28 Trace; c0100018 startup_32+18/13a Trace; c0107183 default_idle+23/28 Trace; c01071e4 cpu_idle+3c/50 Trace; c0105000 empty_bad_page+0/1000 Trace; c0100192 L6+0/2 Code; c0113a70 __wake_up+50/144 _EIP: Code; c0113a70 __wake_up+50/144 = 0: 8b 1b mov(%ebx),%ebx = Code; c0113a72 __wake_up+52/144 2: 89 5d ec mov%ebx,0xffec(%ebp) Code; c0113a75 __wake_up+55/144 5: 8b 48 04 mov0x4(%eax),%ecx Code; c0113a78 __wake_up+58/144 8: 8b 11 mov(%ecx),%edx Code; c0113a7a __wake_up+5a/144 a: 89 d0 mov%edx,%eax Code; c0113a7c __wake_up+5c/144 c: 24 df and$0xdf,%al Code; c0113a7e __wake_up+5e/144 e: 85 45 fc test %eax,0xfffc(%ebp) Code; c0113a81 __wake_up+61/144 11: 0f 84 79 00 00 00 je 90 _EIP+0x90 c0113b00 __wake_up+e0/144 Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! ---[ OOPS2 ]-- ksymoops 2.3.4 on i686 2.4.0-test9. Options used -v /usr/src/linux/vmlinux (specified) -k ./ksyms (specified) -l ./modules (specified) -o /lib/modules/2.4.0-test9 (specified) -m /usr/src/linux/System.map (specified) bad magic 8722 (should be c2dfbbd4, creator 8723), wq bug, forcing oops. kernel BUG at /usr/src/linux/include/linux/wait.h:155! invalid operand: CPU:0 EIP:0010:[c01b3715] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010296 eax: 0037 ebx: c2dfbbc8 ecx: c0240b48 edx: esi: c3bbe060 edi: 000d ebp: c0253fa4 esp: c0253f34 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0253000) Stack: c02291e4 c02291c0 009b c3bbe060 c3f87260 c01b2ea7 c3bbe060 c01b3bc0 c3f87260 000d c01b582a c3f87260 0001 c028bc08 000d c0253fa4 c011b1ae c028bc08 00a0 c02839a0 0005 c010a4a5 Call Trace: [c02291e4] [c02291c0] [c01b2ea7] [c01b3bc0] [c01b582a] [c011b1ae] [c010a4a5] [c0107160] [c0107160] [c010902c] [c0107160] [c0107160] [c0100018] [c0107183] [c01071e4] [c0105000] [c0100192] Code: 0f 0b 83 c4 0c 8d b6 00 00 00 00 8d 43 04 39 43 04 74 0d 8b EIP; c01b3715 sock_def_write_space+5d/c4 = Trace; c02291e4 RCSid+6ee4/9360 Trace; c02291c0 RCSid+6ec0/9360 Trace; c01b2ea7
Re: Request for net guru help: waitqueue oops
Hi Petkan,
Thanks for your comment.
On Tue, 3 Oct 2000, Petko Manolov wrote:
A driver I'm working on seems to be doing/triggering something related
to waitqueues. This causes a perfectly reproducable oops (small mercies!).
Since the oops is not happening in my driver, I'm having a hard time
figuring out whats going wrong. I suspect a networking guru will take
one look and know what I'm doing wrong. Any suggestions please?
It seems you're trying to sleep without process context (most likely in
net_tx_action). It would be more clear if you send that part of the
code.
Since I don't explictly sleep anywhere, I'm not sure which code fragment
would be useful... (net_tx_action is part of the networking layers). Which
network functions can sleep (netif_rx, netif_stop_queue, netif_wake_queue,
...) ?
After reading the softnet HOWTO, and some of the network drivers, I
was unsure about the netif_stop_queue and netif_wake_queue functions. The
howto indicated that these two should be protected from concurrent
execution by a private lock. Not all the drivers seem to do this. In my
case (although I'm running UP at the moment), I've used a driver global
spinlock, for example:
spinlock_t driver_lock = SPIN_LOCK_UNLOCKED;
int scc72_hard_xmit (struct sk_buff *skb, struct net_device *dev)
{
unsigned long flags;
/* ... */
spin_lock_irqsave (driver_lock, flags);
netif_stop_queue (dev);
spin_unlock_irqrestore (driver_lock, flags);
/* ... */
}
/* Example timer callback, to wake the queue */
void scc72_interframewait (unsigned long channel)
{
unsigned long flags;
struct scc72_channel *scc = (struct scc72_channel *) channel;
/* ... */
spin_lock_irqsave (driver_lock, flags);
/* ... */
if (netif_queue_stopped (scc-dev))
netif_wake_queue (scc-dev);
spin_unlock_irqrestore (driver_lock, flags);
}
I've just checked my driver, and below is the list of all the external
functions called. Any idea which of these could be trying to sleep?
dev_kfree_skb_any (called from both hard IRQ and non IRQ context)
dev_alloc_skb (called from both hard IRQ and non IRQ context)
del_timer (called from both hard IRQ and non IRQ context)
add_timer (called from both hard IRQ and non IRQ context)
netif_rx (called from IRQ context)
netif_start_queue (called from non hard IRQ context, ex: dev_open)
netif_stop_queue (called from non hard IRQ context, ex: hard_start_xmit)
netif_wake_queue (called from non hard IRQ context, ex: timer callbacks)
netif_queue_stopped (called from non hard IRQ context, ex: timer callbacks)
skb_queue_tail(called from non hard IRQ context, ex: hard_start_xmit)
skb_dequeue (called from both hard IRQ and non IRQ context)
skb_queue_head_init (called from non hard IRQ context, ex: dev_open)
and the standard functions dev_init_buffers, register_netdevice,
copy_from_user, unregister_netdev, etc. called in the standard places.
skb_queue_tail, skb_dequeue and skb_queue_head_init are used to manage
an internal queue of outgoing skb's.
Thanks.
-- Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Request for net guru help: waitqueue oops
On Tue, 3 Oct 2000, Petko Manolov wrote: None of these can sleep. netif_*_queue routines are quite simple. They are all atomic so there is no need to protect them with locks. Ok. I originally had them outside locks as they appeared to be atomic. I moved them in incase they were the cause of the problem. It is not clear from the example above if it is needed to lock in the timer routine and what is locked inside. Anyway be careful about locking regions shared between interrupts/bottom halves and user context as this happens often. The timer routines (there are 4) are used to switch hardware states and must therefore be mutually exclusive with respect to the interrupt handler. There are no bottom halves used in this driver. Andrew Morton suggested that the problem could be in my use of the skb pointers, which seems a likely candidate. I'll check that. Thanks -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Q] net_device methods and disable_irq interaction (SMP)
On Fri, 29 Sep 2000, Alan Cox wrote: > > Can spin_lock_irqsave and the disable_irq & spin_lock combinations be > > safely mixed, particularly with regards to the networking layer? This does > > not seem to be done anywhere in the kernel so I suspect that I'm trying > > to do something wrong/bogus ... > > We do it on the 8390 and 3c509. Thanks for the references Alan... just what I was looking for. Looks like my 'grep' skills need some work :) -- Hans. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Q] net_device methods and disable_irq interaction (SMPUP)
On Fri, 29 Sep 2000, Alan Cox wrote: Can spin_lock_irqsave and the disable_irq spin_lock combinations be safely mixed, particularly with regards to the networking layer? This does not seem to be done anywhere in the kernel so I suspect that I'm trying to do something wrong/bogus ... We do it on the 8390 and 3c509. Thanks for the references Alan... just what I was looking for. Looks like my 'grep' skills need some work :) -- Hans. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[Q] net_device methods and disable_irq interaction (SMP)
Can spin_lock_irqsave and the disable_irq & spin_lock combinations be safely mixed, particularly with regards to the networking layer? This does not seem to be done anywhere in the kernel so I suspect that I'm trying to do something wrong/bogus ... More specifically, I have a card that requires lengthy reconfiguration sequences during its normal operation. This card is an old, very slow ISA card. For most of the driver I'd like to use spin_*lock_irq*. During the long reconfiguration sequences I'd like to do (allowing servicing of other interrupts, particularly on UP): disable_irq(driver_irq); spin_lock(_lock); /* ... hardware reconfig (critical section) ... */ spin_unlock(_lock); enable_irq(driver_irq); where the following is used elsewhere: unsigned long flags; spin_lock_irqsave (_lock, flags); /* ... hardware stuff (critical section) ... */ spin_unlock_irqrestore (_lock, flags); Since this driver is a network driver, the spin_lock in the first fragment would be to prevent unsafe interaction with the network layer (via the net_device methods). Would this work or have I missed something? What would be the best why to handle this situation (i.e. very slow ISA card, long port access sequences, 2.4.x, SMP & UP)? Thanks -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[Q] net_device methods and disable_irq interaction (SMPUP)
Can spin_lock_irqsave and the disable_irq spin_lock combinations be safely mixed, particularly with regards to the networking layer? This does not seem to be done anywhere in the kernel so I suspect that I'm trying to do something wrong/bogus ... More specifically, I have a card that requires lengthy reconfiguration sequences during its normal operation. This card is an old, very slow ISA card. For most of the driver I'd like to use spin_*lock_irq*. During the long reconfiguration sequences I'd like to do (allowing servicing of other interrupts, particularly on UP): disable_irq(driver_irq); spin_lock(driver_lock); /* ... hardware reconfig (critical section) ... */ spin_unlock(driver_lock); enable_irq(driver_irq); where the following is used elsewhere: unsigned long flags; spin_lock_irqsave (driver_lock, flags); /* ... hardware stuff (critical section) ... */ spin_unlock_irqrestore (driver_lock, flags); Since this driver is a network driver, the spin_lock in the first fragment would be to prevent unsafe interaction with the network layer (via the net_device methods). Would this work or have I missed something? What would be the best why to handle this situation (i.e. very slow ISA card, long port access sequences, 2.4.x, SMP UP)? Thanks -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch rfc] Tags generation to include local headers
Would anyone object to the inclusion of local header files (not under include/*) in the tags generation target? -- Hans Grobler --- linux.orig/Makefile Thu Aug 24 03:36:46 2000 +++ linux/Makefile Mon Sep 11 14:48:55 2000 @@ -286,14 +286,14 @@ TAGS: dummy etags `find include/asm-$(ARCH) -name '*.h'` find include -type d \( -name "asm-*" -o -name config \) -prune -o -name '*.h' -print | xargs etags -a - find $(SUBDIRS) init -name '*.c' | xargs etags -a + find $(SUBDIRS) init \( -name '*.c' -o -name '*.h' \) | xargs etags -a # Exuberant ctags works better with -I tags: dummy CTAGSF=`ctags --version | grep -i exuberant >/dev/null && echo "-I __initdata,__initlocaldata,__exitdata,EXPORT_SYMBOL,EXPORT_SYMBOL_NOVERS"`; \ ctags $$CTAGSF `find include/asm-$(ARCH) -name '*.h'` && \ find include -type d \( -name "asm-*" -o -name config \) -prune -o -name '*.h' -print | xargs ctags $$CTAGSF -a && \ - find $(SUBDIRS) init -name '*.c' | xargs ctags $$CTAGSF -a + find $(SUBDIRS) init \( -name '*.c' -o -name '*.h' \) | xargs ctags $$CTAGSF -a ifdef CONFIG_MODULES ifdef CONFIG_MODVERSIONS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch rfc] Tags generation to include local headers
Would anyone object to the inclusion of local header files (not under include/*) in the tags generation target? -- Hans Grobler --- linux.orig/Makefile Thu Aug 24 03:36:46 2000 +++ linux/Makefile Mon Sep 11 14:48:55 2000 @@ -286,14 +286,14 @@ TAGS: dummy etags `find include/asm-$(ARCH) -name '*.h'` find include -type d \( -name "asm-*" -o -name config \) -prune -o -name '*.h' -print | xargs etags -a - find $(SUBDIRS) init -name '*.c' | xargs etags -a + find $(SUBDIRS) init \( -name '*.c' -o -name '*.h' \) | xargs etags -a # Exuberant ctags works better with -I tags: dummy CTAGSF=`ctags --version | grep -i exuberant /dev/null echo "-I __initdata,__initlocaldata,__exitdata,EXPORT_SYMBOL,EXPORT_SYMBOL_NOVERS"`; \ ctags $$CTAGSF `find include/asm-$(ARCH) -name '*.h'` \ find include -type d \( -name "asm-*" -o -name config \) -prune -o -name '*.h' -print | xargs ctags $$CTAGSF -a \ - find $(SUBDIRS) init -name '*.c' | xargs ctags $$CTAGSF -a + find $(SUBDIRS) init \( -name '*.c' -o -name '*.h' \) | xargs ctags $$CTAGSF -a ifdef CONFIG_MODULES ifdef CONFIG_MODVERSIONS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
