Re: 2.6.20-mm1: PTRACE=y, PROC_FS=n compile error
On Wed, Feb 21, 2007 at 02:15:10AM -0800, Roland McGrath wrote: > > This causes the following compile error with CONFIG_PTRACE=y, > > CONFIG_PROC_FS=n: > > Bah. I moved ptrace_may_attach to fs/proc/base.c so that CONFIG_PTRACE=n > could just omit kernel/ptrace.c entirely and still get the function for > fs/proc/base.c to use (and because that uses it many more times than ptrace > does). I'd forgotten that procfs could be disabled, since noone ever does. > > What do people suggest? It's not a very big function. Put it into some other place in kernel/ that's always build, e.g. kernel/sys.c and while you;re at it please give it a name that doesn't include the word ptrace. I remember mentioning that in my long utrace review mail.. :) - 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.20-mm1: PTRACE=y, PROC_FS=n compile error
> This causes the following compile error with CONFIG_PTRACE=y, > CONFIG_PROC_FS=n: Bah. I moved ptrace_may_attach to fs/proc/base.c so that CONFIG_PTRACE=n could just omit kernel/ptrace.c entirely and still get the function for fs/proc/base.c to use (and because that uses it many more times than ptrace does). I'd forgotten that procfs could be disabled, since noone ever does. What do people suggest? It's not a very big function. Thanks, Roland - 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.20-mm1: PTRACE=y, PROC_FS=n compile error
This causes the following compile error with CONFIG_PTRACE=y, CONFIG_PROC_FS=n: Bah. I moved ptrace_may_attach to fs/proc/base.c so that CONFIG_PTRACE=n could just omit kernel/ptrace.c entirely and still get the function for fs/proc/base.c to use (and because that uses it many more times than ptrace does). I'd forgotten that procfs could be disabled, since noone ever does. What do people suggest? It's not a very big function. Thanks, Roland - 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.20-mm1: PTRACE=y, PROC_FS=n compile error
On Wed, Feb 21, 2007 at 02:15:10AM -0800, Roland McGrath wrote: This causes the following compile error with CONFIG_PTRACE=y, CONFIG_PROC_FS=n: Bah. I moved ptrace_may_attach to fs/proc/base.c so that CONFIG_PTRACE=n could just omit kernel/ptrace.c entirely and still get the function for fs/proc/base.c to use (and because that uses it many more times than ptrace does). I'd forgotten that procfs could be disabled, since noone ever does. What do people suggest? It's not a very big function. Put it into some other place in kernel/ that's always build, e.g. kernel/sys.c and while you;re at it please give it a name that doesn't include the word ptrace. I remember mentioning that in my long utrace review mail.. :) - 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/
2.6.20-mm1: PTRACE=y, PROC_FS=n compile error
On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote: >... > Changes since 2.6.20-rc6-mm3: >... > +utrace-utrace-ptrace-compat.patch >... > utrace tree >... This causes the following compile error with CONFIG_PTRACE=y, CONFIG_PROC_FS=n: <-- snip --> ... LD .tmp_vmlinux1 kernel/built-in.o: In function `sys_ptrace': (.text+0x2a3c2): undefined reference to `ptrace_may_attach' make[1]: *** [.tmp_vmlinux1] Error 1 <-- snip --> cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.20-mm1
On Fri, 2007-02-16 at 08:55 -0800, Randy Dunlap wrote: > On Fri, 16 Feb 2007 10:37:12 -0600 Steve Fox wrote: > > > bl6-13, an x86_64 box listed on test.kernel.org, tripped on this during > > an LTP run, even with > > unify-queue_delayed_work-and-queue_delayed_work_on-fix.patch applied. > > > > I'm not sure why the LTP results aren't copied over to TKO, but here's > > the details anyway. > > > > If someone can give me an idea where to look, I can start a bi-sect if > > it would help. > > > > kernel BUG at mm/swap.c:469! > > invalid opcode: [1] SMP > > last sysfs file: /devices/system/node/node0/cpumap > > > Try this patch? http://lkml.org/lkml/2007/2/16/220 That fixed it. Thanks. -- Steve Fox IBM Linux Technology Center - 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.20-mm1
On Fri, 2007-02-16 at 08:55 -0800, Randy Dunlap wrote: On Fri, 16 Feb 2007 10:37:12 -0600 Steve Fox wrote: bl6-13, an x86_64 box listed on test.kernel.org, tripped on this during an LTP run, even with unify-queue_delayed_work-and-queue_delayed_work_on-fix.patch applied. I'm not sure why the LTP results aren't copied over to TKO, but here's the details anyway. If someone can give me an idea where to look, I can start a bi-sect if it would help. kernel BUG at mm/swap.c:469! invalid opcode: [1] SMP last sysfs file: /devices/system/node/node0/cpumap Try this patch? http://lkml.org/lkml/2007/2/16/220 That fixed it. Thanks. -- Steve Fox IBM Linux Technology Center - 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/
2.6.20-mm1: PTRACE=y, PROC_FS=n compile error
On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote: ... Changes since 2.6.20-rc6-mm3: ... +utrace-utrace-ptrace-compat.patch ... utrace tree ... This causes the following compile error with CONFIG_PTRACE=y, CONFIG_PROC_FS=n: -- snip -- ... LD .tmp_vmlinux1 kernel/built-in.o: In function `sys_ptrace': (.text+0x2a3c2): undefined reference to `ptrace_may_attach' make[1]: *** [.tmp_vmlinux1] Error 1 -- snip -- cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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.20-mm1 - Oops using Minix 3 file system
2007/2/17, Cédric Augonnet <[EMAIL PROTECTED]>: 2007/2/17, Bill Davidsen <[EMAIL PROTECTED]>: > Cédric Augonnet wrote: That is my all point actually, i am not telling i have a valid partition. I'm just describing the fact that the minix fs driver is making too many assumptions on the partition it is given. For sure there must be something nasty about this image, as you told this is the duty of the kernel not to mount such a partition if it is not a partition. Here I was only giving an example of the way we could trick the driver. This is as important as having the driver working correctly on valid partitions i suppose. Eventually the problem got solved by Andries Bouwer : http://marc.theaimsgroup.com/?l=linux-mm-commits=117176125510900=2 Now i can issue a df command on this partition or whatever it may be, and i obtain a consistent result wiythout any oops. Regards, Cédric - 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.20-mm1 - Oops using Minix 3 file system
2007/2/17, Cédric Augonnet [EMAIL PROTECTED]: 2007/2/17, Bill Davidsen [EMAIL PROTECTED]: Cédric Augonnet wrote: That is my all point actually, i am not telling i have a valid partition. I'm just describing the fact that the minix fs driver is making too many assumptions on the partition it is given. For sure there must be something nasty about this image, as you told this is the duty of the kernel not to mount such a partition if it is not a partition. Here I was only giving an example of the way we could trick the driver. This is as important as having the driver working correctly on valid partitions i suppose. Eventually the problem got solved by Andries Bouwer : http://marc.theaimsgroup.com/?l=linux-mm-commitsm=117176125510900w=2 Now i can issue a df command on this partition or whatever it may be, and i obtain a consistent result wiythout any oops. Regards, Cédric - 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.20-mm1 - Oops using Minix 3 file system
2007/2/17, Bill Davidsen <[EMAIL PROTECTED]>: Cédric Augonnet wrote: > > Hi Daniel, > > On 2.6.20-rc6-mm3 and 2.6.20-mm1, i get an OOPS when using the minix 3 > file system. I enclose the dmesg and the .config to that mail. > > Here are the steps to reproduce this oops (they involve using qemu to > run Minix 3) > - First create a 2GB image using > qemu-img create minix.img 2G > (Please note that this seem to be producing an eroneous image) > - Then launch Minix inside qemu to make a minix partition on this > image using mkfs on the corresponding device. That's two steps, right? First you make a partition on the "disk" qemu provides, then you put a filesystem on the partition? Or did you put a filesystem on the raw device? Yes, i first create a RAW image of a disk. Then, i use this image file as an image given to qemu. Inside qemu, running Minix i issue mkfs /dev/c0d1 (this is corresponding to this image). > - Mount the image on loopback using > mount -t minix -o loop minix.img /mnt/qemu/ Does mount know to use Minux3 with this command line? Well at least it is yet allowing to do so. And most things work like hell. > - issue a "df" command on /mnt/qemu > > This oops occurs everytime i use df on this directory. However, this > does not occur if the image was for a 1MB partition. And it does not > occur if the partition on which we created minix.img was the same as > the partition on which qemu stands. Sounds like qemu has an issue and > creates an erroneous partition which linux does not handle correctly. > > Regards, and thanks for your patch by the way ! Having been burned a few times by the fact that qemu provides disk images which then (normally) get partitions, I'm not sure you aren't having the same problem. None of which justifies the OOPS, of course, nice kernels don't go down. That is my all point actually, i am not telling i have a valid partition. I'm just describing the fact that the minix fs driver is making too many assumptions on the partition it is given. For sure there must be something nasty about this image, as you told this is the duty of the kernel not to mount such a partition if it is not a partition. Here I was only giving an example of the way we could trick the driver. This is as important as having the driver working correctly on valid partitions i suppose. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot Regards, Cédric - 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.20-mm1 - Oops using Minix 3 file system
Cédric Augonnet wrote: 2007/2/15, Andrew Morton <[EMAIL PROTECTED]>: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm1/ Will appear later at Changes since 2.6.20-rc6-mm3: -minix-v3-support.patch Hi Daniel, On 2.6.20-rc6-mm3 and 2.6.20-mm1, i get an OOPS when using the minix 3 file system. I enclose the dmesg and the .config to that mail. Here are the steps to reproduce this oops (they involve using qemu to run Minix 3) - First create a 2GB image using qemu-img create minix.img 2G (Please note that this seem to be producing an eroneous image) - Then launch Minix inside qemu to make a minix partition on this image using mkfs on the corresponding device. That's two steps, right? First you make a partition on the "disk" qemu provides, then you put a filesystem on the partition? Or did you put a filesystem on the raw device? - Mount the image on loopback using mount -t minix -o loop minix.img /mnt/qemu/ Does mount know to use Minux3 with this command line? - issue a "df" command on /mnt/qemu This oops occurs everytime i use df on this directory. However, this does not occur if the image was for a 1MB partition. And it does not occur if the partition on which we created minix.img was the same as the partition on which qemu stands. Sounds like qemu has an issue and creates an erroneous partition which linux does not handle correctly. Regards, and thanks for your patch by the way ! Having been burned a few times by the fact that qemu provides disk images which then (normally) get partitions, I'm not sure you aren't having the same problem. None of which justifies the OOPS, of course, nice kernels don't go down. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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.20-mm1 - Oops using Minix 3 file system
On 2/17/07, Cédric Augonnet <[EMAIL PROTECTED]> wrote: Well i actually do access to this partition, i can edit it and use it, this on Linux. Sorry if this is not clear. Here is the point, I think. I'm afraid that you don't really access any *real* partition. If it were so, that partition would have an identifying *device* name. You access something within an image for an emulating program that you interpret as a partition but not the kernel. So it cannot access the superblock of it in its buffer and recover bh->b_size to go on properly. It recovers something else. And this triggers the oops. Regards, Daniel - 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.20-mm1 - Oops using Minix 3 file system
2007/2/17, Daniel Aragonés <[EMAIL PROTECTED]>: On 2/17/07, Cédric Augonnet <[EMAIL PROTECTED]> wrote: > It appears that the trouble is in the count_free of file > fs/minix/bitmap.c . This procedure is actually called twice when we > issue a df command. > The point where things start to get strange is > i = ((numbits - (numblocks-1) * bh->b_size * 8) / 16) * 2; at line 36 > > In the first call to that procedure i have >i = 3506 >bh->b_data = 0xd4e79000 > > Whereas in the second call i have something much different : >i = 536838736 >bh->b_data = d4e78000 > More precisely, i traced how we call the count_free procedure : it is once called by minix_count_free_blocks (and succeeds) and then by minix_count_free_inodes and fails. For the first call, which does not fail : minix_count_free_blocks(0xd4105240) sbi->s_zmap_blocks = 0x0010 sbi->s_nzones = 0x0008 sbi->s_firstdatazone = 0x1266 (sbi->s_nzones - sbi->s_firstdatazone + 1) = 0x0007ed9b count_free( , 0x0010, 0x0007ed9b) unsigned numblocks = 0x0010 = 16 __u32 numbits =0x0007ed9b = 519579 bh->b_size = 0x1000 = 4096 == > i = 3506 This is consistent with the formula For the second call minix_count_free_inodes(0xd4105240) sbi->s_imap_blocks = 0x000a sbi->s_ninodes = 0x9280 count_free(..., 0x000a, 0x9281) unsigned numblocks = 0x000a = 10 __u32 numbits = 0x9281 = 37505 bh->b_size =0x1000 = 4096 ==> i = 536838736 (gdb) p/x (( 0x9281 - (0x00a-1) * 0x1000 * 8) / 16) * 2 $20 = 0x8252 $21 = -32174 (Very sorry for than mess !) Well, that line is modified by my patch. The original one is: i = ((numbits-(numblocks-1)*BLOCK_SIZE*8)/16)*2; As you see, the constant is substituted by a variable. As you are running under emulation, the true value of that variable ( 4096 in standard minix3 releases, instead of the constant 1024 in minix1 and minix2), is probably found where it should not be found, or not found at all. And the result is what you show. Minix 3 provides for a variable size of the blocks. Try to find what block size you are emulating. Also, though your dmesg shows a mounted loop partition, the minix subpartition in it is not stated. So it cannot be accessed. Well i actually do access to this partition, i can edit it and use it, this on Linux. Sorry if this is not clear. By the way, you don't need to support minix on your Linux box to run it through an emulator, do you? Actually i am running a full Minix OS in the qemu emulator and all Linux does is providing me some disk images. To make it more clear, i created a disk image file on Linux. I created a FS on that partition in Minix using mkfs inside qemu running Minix. And then i just want to mount this partition to have access to this filesystem on my Linux. This is ugly for sure, but it should still not be oopsing. Regards Daniel I thought you could be interested in having the actual image doing all these nasty things : http://perso.ens-lyon.fr/cedric.augonnet/Linux/br.tar tar -xvf br.tar should produce some br.img file that you can mount using mount -o loop -t minix br.img /mnt/foo df -h should there be issuing the oops. Please remark that all the files inside this image were created with Linux, not Minix, the _only_ thing done with minix and qemu was to create the file system on the image. Hoping this will be a bit useful, Regards, Cédric - 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.20-mm1 - Oops using Minix 3 file system
On 2/17/07, Cédric Augonnet <[EMAIL PROTECTED]> wrote: It appears that the trouble is in the count_free of file fs/minix/bitmap.c . This procedure is actually called twice when we issue a df command. The point where things start to get strange is i = ((numbits - (numblocks-1) * bh->b_size * 8) / 16) * 2; at line 36 In the first call to that procedure i have i = 3506 bh->b_data = 0xd4e79000 Whereas in the second call i have something much different : i = 536838736 bh->b_data = d4e78000 Well, that line is modified by my patch. The original one is: i = ((numbits-(numblocks-1)*BLOCK_SIZE*8)/16)*2; As you see, the constant is substituted by a variable. As you are running under emulation, the true value of that variable ( 4096 in standard minix3 releases, instead of the constant 1024 in minix1 and minix2), is probably found where it should not be found, or not found at all. And the result is what you show. Minix 3 provides for a variable size of the blocks. Try to find what block size you are emulating. Also, though your dmesg shows a mounted loop partition, the minix subpartition in it is not stated. So it cannot be accessed. By the way, you don't need to support minix on your Linux box to run it through an emulator, do you? Regards Daniel - 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.20-mm1 - Oops using Minix 3 file system
2007/2/17, Daniel Aragonés <[EMAIL PROTECTED]>: Well, a glance at your dmesg doesn' show that a minix partition was recognized. Otherwise it would sow it. So you have not such a partition within your drives. You are using an emulator to run minix. You will have the same problem if you run minix2 or minix3 through an emulator and not from a real minix2 or minix3 partition. Regards, Daniel Indeed the only line of dmesg showing i mounted the partition is loop: loaded (max 8 devices) Still I actually mount an image : i can add files, edit and so on. If i use the emulator and mount the partition, this partition works perfectly and even the df commands works. Now i tried to understand what is going on and traced the program : It appears that the trouble is in the count_free of file fs/minix/bitmap.c . This procedure is actually called twice when we issue a df command. The point where things start to get strange is i = ((numbits - (numblocks-1) * bh->b_size * 8) / 16) * 2; at line 36 In the first call to that procedure i have i = 3506 bh->b_data = 0xd4e79000 Whereas in the second call i have something much different : i = 536838736 bh->b_data = d4e78000 Tt really seems to me that this value should not be so large. Unfortunately, i cannot get any deeper in tracing the problem since even if i tried to read the code, it not documented, so i can't be sure I understand everything you're doing in count_free ... Regards, Cédric - 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.20-mm1 - Oops using Minix 3 file system
On 2/17/07, Cédric Augonnet <[EMAIL PROTECTED]> wrote: ... Hi Daniel, On 2.6.20-rc6-mm3 and 2.6.20-mm1, i get an OOPS when using the minix 3 file system. I enclose the dmesg and the .config to that mail. Here are the steps to reproduce this oops (they involve using qemu to run Minix 3) - First create a 2GB image using qemu-img create minix.img 2G (Please note that this seem to be producing an eroneous image) - Then launch Minix inside qemu to make a minix partition on this image using mkfs on the corresponding device. - Mount the image on loopback using mount -t minix -o loop minix.img /mnt/qemu/ - issue a "df" command on /mnt/qemu ... Well, a glance at your dmesg doesn' show that a minix partition was recognized. Otherwise it would sow it. So you have not such a partition within your drives. You are using an emulator to run minix. You will have the same problem if you run minix2 or minix3 through an emulator and not from a real minix2 or minix3 partition. Regards, Daniel - 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.20-mm1 USB-related OOPS
On Fri, Feb 16, 2007 at 06:17:54PM -0700, Berck E. Nash wrote: > I get the following OOPS on boot, presumably connected with USB driver > loading. I've attached the entire log. Please CC on replies as I'm not > subscribed. > > Loading kernel module nvidia. > [ 149.135709] nvidia: module license 'NVIDIA' taints kernel. Hi, Could you try booting without loading the nvidia module? Oopses related to it have been reported for 2.6.20-mm1. See http://lkml.org/lkml/2007/2/16/428 Regards, Frederik - 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.20-mm1 USB-related OOPS
On Fri, Feb 16, 2007 at 06:17:54PM -0700, Berck E. Nash wrote: I get the following OOPS on boot, presumably connected with USB driver loading. I've attached the entire log. Please CC on replies as I'm not subscribed. Loading kernel module nvidia. [ 149.135709] nvidia: module license 'NVIDIA' taints kernel. Hi, Could you try booting without loading the nvidia module? Oopses related to it have been reported for 2.6.20-mm1. See http://lkml.org/lkml/2007/2/16/428 Regards, Frederik - 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.20-mm1 - Oops using Minix 3 file system
On 2/17/07, Cédric Augonnet [EMAIL PROTECTED] wrote: ... Hi Daniel, On 2.6.20-rc6-mm3 and 2.6.20-mm1, i get an OOPS when using the minix 3 file system. I enclose the dmesg and the .config to that mail. Here are the steps to reproduce this oops (they involve using qemu to run Minix 3) - First create a 2GB image using qemu-img create minix.img 2G (Please note that this seem to be producing an eroneous image) - Then launch Minix inside qemu to make a minix partition on this image using mkfs on the corresponding device. - Mount the image on loopback using mount -t minix -o loop minix.img /mnt/qemu/ - issue a df command on /mnt/qemu ... Well, a glance at your dmesg doesn' show that a minix partition was recognized. Otherwise it would sow it. So you have not such a partition within your drives. You are using an emulator to run minix. You will have the same problem if you run minix2 or minix3 through an emulator and not from a real minix2 or minix3 partition. Regards, Daniel - 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.20-mm1 - Oops using Minix 3 file system
2007/2/17, Daniel Aragonés [EMAIL PROTECTED]: Well, a glance at your dmesg doesn' show that a minix partition was recognized. Otherwise it would sow it. So you have not such a partition within your drives. You are using an emulator to run minix. You will have the same problem if you run minix2 or minix3 through an emulator and not from a real minix2 or minix3 partition. Regards, Daniel Indeed the only line of dmesg showing i mounted the partition is loop: loaded (max 8 devices) Still I actually mount an image : i can add files, edit and so on. If i use the emulator and mount the partition, this partition works perfectly and even the df commands works. Now i tried to understand what is going on and traced the program : It appears that the trouble is in the count_free of file fs/minix/bitmap.c . This procedure is actually called twice when we issue a df command. The point where things start to get strange is i = ((numbits - (numblocks-1) * bh-b_size * 8) / 16) * 2; at line 36 In the first call to that procedure i have i = 3506 bh-b_data = 0xd4e79000 Whereas in the second call i have something much different : i = 536838736 bh-b_data = d4e78000 Tt really seems to me that this value should not be so large. Unfortunately, i cannot get any deeper in tracing the problem since even if i tried to read the code, it not documented, so i can't be sure I understand everything you're doing in count_free ... Regards, Cédric - 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.20-mm1 - Oops using Minix 3 file system
On 2/17/07, Cédric Augonnet [EMAIL PROTECTED] wrote: It appears that the trouble is in the count_free of file fs/minix/bitmap.c . This procedure is actually called twice when we issue a df command. The point where things start to get strange is i = ((numbits - (numblocks-1) * bh-b_size * 8) / 16) * 2; at line 36 In the first call to that procedure i have i = 3506 bh-b_data = 0xd4e79000 Whereas in the second call i have something much different : i = 536838736 bh-b_data = d4e78000 Well, that line is modified by my patch. The original one is: i = ((numbits-(numblocks-1)*BLOCK_SIZE*8)/16)*2; As you see, the constant is substituted by a variable. As you are running under emulation, the true value of that variable ( 4096 in standard minix3 releases, instead of the constant 1024 in minix1 and minix2), is probably found where it should not be found, or not found at all. And the result is what you show. Minix 3 provides for a variable size of the blocks. Try to find what block size you are emulating. Also, though your dmesg shows a mounted loop partition, the minix subpartition in it is not stated. So it cannot be accessed. By the way, you don't need to support minix on your Linux box to run it through an emulator, do you? Regards Daniel - 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.20-mm1 - Oops using Minix 3 file system
2007/2/17, Daniel Aragonés [EMAIL PROTECTED]: On 2/17/07, Cédric Augonnet [EMAIL PROTECTED] wrote: It appears that the trouble is in the count_free of file fs/minix/bitmap.c . This procedure is actually called twice when we issue a df command. The point where things start to get strange is i = ((numbits - (numblocks-1) * bh-b_size * 8) / 16) * 2; at line 36 In the first call to that procedure i have i = 3506 bh-b_data = 0xd4e79000 Whereas in the second call i have something much different : i = 536838736 bh-b_data = d4e78000 More precisely, i traced how we call the count_free procedure : it is once called by minix_count_free_blocks (and succeeds) and then by minix_count_free_inodes and fails. For the first call, which does not fail : minix_count_free_blocks(0xd4105240) sbi-s_zmap_blocks = 0x0010 sbi-s_nzones = 0x0008 sbi-s_firstdatazone = 0x1266 (sbi-s_nzones - sbi-s_firstdatazone + 1) = 0x0007ed9b count_free( , 0x0010, 0x0007ed9b) unsigned numblocks = 0x0010 = 16 __u32 numbits =0x0007ed9b = 519579 bh-b_size = 0x1000 = 4096 == i = 3506 This is consistent with the formula For the second call minix_count_free_inodes(0xd4105240) sbi-s_imap_blocks = 0x000a sbi-s_ninodes = 0x9280 count_free(..., 0x000a, 0x9281) unsigned numblocks = 0x000a = 10 __u32 numbits = 0x9281 = 37505 bh-b_size =0x1000 = 4096 == i = 536838736 (gdb) p/x (( 0x9281 - (0x00a-1) * 0x1000 * 8) / 16) * 2 $20 = 0x8252 $21 = -32174 (Very sorry for than mess !) Well, that line is modified by my patch. The original one is: i = ((numbits-(numblocks-1)*BLOCK_SIZE*8)/16)*2; As you see, the constant is substituted by a variable. As you are running under emulation, the true value of that variable ( 4096 in standard minix3 releases, instead of the constant 1024 in minix1 and minix2), is probably found where it should not be found, or not found at all. And the result is what you show. Minix 3 provides for a variable size of the blocks. Try to find what block size you are emulating. Also, though your dmesg shows a mounted loop partition, the minix subpartition in it is not stated. So it cannot be accessed. Well i actually do access to this partition, i can edit it and use it, this on Linux. Sorry if this is not clear. By the way, you don't need to support minix on your Linux box to run it through an emulator, do you? Actually i am running a full Minix OS in the qemu emulator and all Linux does is providing me some disk images. To make it more clear, i created a disk image file on Linux. I created a FS on that partition in Minix using mkfs inside qemu running Minix. And then i just want to mount this partition to have access to this filesystem on my Linux. This is ugly for sure, but it should still not be oopsing. Regards Daniel I thought you could be interested in having the actual image doing all these nasty things : http://perso.ens-lyon.fr/cedric.augonnet/Linux/br.tar tar -xvf br.tar should produce some br.img file that you can mount using mount -o loop -t minix br.img /mnt/foo df -h should there be issuing the oops. Please remark that all the files inside this image were created with Linux, not Minix, the _only_ thing done with minix and qemu was to create the file system on the image. Hoping this will be a bit useful, Regards, Cédric - 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.20-mm1 - Oops using Minix 3 file system
On 2/17/07, Cédric Augonnet [EMAIL PROTECTED] wrote: Well i actually do access to this partition, i can edit it and use it, this on Linux. Sorry if this is not clear. Here is the point, I think. I'm afraid that you don't really access any *real* partition. If it were so, that partition would have an identifying *device* name. You access something within an image for an emulating program that you interpret as a partition but not the kernel. So it cannot access the superblock of it in its buffer and recover bh-b_size to go on properly. It recovers something else. And this triggers the oops. Regards, Daniel - 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.20-mm1 - Oops using Minix 3 file system
Cédric Augonnet wrote: 2007/2/15, Andrew Morton [EMAIL PROTECTED]: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm1/ Will appear later at Changes since 2.6.20-rc6-mm3: -minix-v3-support.patch Hi Daniel, On 2.6.20-rc6-mm3 and 2.6.20-mm1, i get an OOPS when using the minix 3 file system. I enclose the dmesg and the .config to that mail. Here are the steps to reproduce this oops (they involve using qemu to run Minix 3) - First create a 2GB image using qemu-img create minix.img 2G (Please note that this seem to be producing an eroneous image) - Then launch Minix inside qemu to make a minix partition on this image using mkfs on the corresponding device. That's two steps, right? First you make a partition on the disk qemu provides, then you put a filesystem on the partition? Or did you put a filesystem on the raw device? - Mount the image on loopback using mount -t minix -o loop minix.img /mnt/qemu/ Does mount know to use Minux3 with this command line? - issue a df command on /mnt/qemu This oops occurs everytime i use df on this directory. However, this does not occur if the image was for a 1MB partition. And it does not occur if the partition on which we created minix.img was the same as the partition on which qemu stands. Sounds like qemu has an issue and creates an erroneous partition which linux does not handle correctly. Regards, and thanks for your patch by the way ! Having been burned a few times by the fact that qemu provides disk images which then (normally) get partitions, I'm not sure you aren't having the same problem. None of which justifies the OOPS, of course, nice kernels don't go down. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - 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.20-mm1 - Oops using Minix 3 file system
2007/2/17, Bill Davidsen [EMAIL PROTECTED]: Cédric Augonnet wrote: Hi Daniel, On 2.6.20-rc6-mm3 and 2.6.20-mm1, i get an OOPS when using the minix 3 file system. I enclose the dmesg and the .config to that mail. Here are the steps to reproduce this oops (they involve using qemu to run Minix 3) - First create a 2GB image using qemu-img create minix.img 2G (Please note that this seem to be producing an eroneous image) - Then launch Minix inside qemu to make a minix partition on this image using mkfs on the corresponding device. That's two steps, right? First you make a partition on the disk qemu provides, then you put a filesystem on the partition? Or did you put a filesystem on the raw device? Yes, i first create a RAW image of a disk. Then, i use this image file as an image given to qemu. Inside qemu, running Minix i issue mkfs /dev/c0d1 (this is corresponding to this image). - Mount the image on loopback using mount -t minix -o loop minix.img /mnt/qemu/ Does mount know to use Minux3 with this command line? Well at least it is yet allowing to do so. And most things work like hell. - issue a df command on /mnt/qemu This oops occurs everytime i use df on this directory. However, this does not occur if the image was for a 1MB partition. And it does not occur if the partition on which we created minix.img was the same as the partition on which qemu stands. Sounds like qemu has an issue and creates an erroneous partition which linux does not handle correctly. Regards, and thanks for your patch by the way ! Having been burned a few times by the fact that qemu provides disk images which then (normally) get partitions, I'm not sure you aren't having the same problem. None of which justifies the OOPS, of course, nice kernels don't go down. That is my all point actually, i am not telling i have a valid partition. I'm just describing the fact that the minix fs driver is making too many assumptions on the partition it is given. For sure there must be something nasty about this image, as you told this is the duty of the kernel not to mount such a partition if it is not a partition. Here I was only giving an example of the way we could trick the driver. This is as important as having the driver working correctly on valid partitions i suppose. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot Regards, Cédric - 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/
2.6.20-mm1 USB-related OOPS
I get the following OOPS on boot, presumably connected with USB driver loading. I've attached the entire log. Please CC on replies as I'm not subscribed. [ 149.525742] Unable to handle kernel NULL pointer dereference at 0008 RIP: [ 149.531302] [] :cdc_acm:acm_probe+0x1dd/0x741 [ 149.539958] PGD 3d248067 PUD 3d23c067 PMD 0 [ 149.544431] Oops: [1] PREEMPT SMP [ 149.548475] last sysfs file: /class/net/lo/operstate [ 149.553510] CPU 0 [ 149.555618] Modules linked in: cdc_acm snd_rtctimer w83627ehf eeprom i2c_isa nvidia(P) usb_storage usbhid 8139cp snd_hda_intel snd_hda_codec snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_timer snd_seq_device snd 8139too uhci_hcd mii soundcore snd_page_alloc i2c_i801 evdev usbcore i2c_core floppy [ 149.587337] Pid: 1620, comm: modprobe Tainted: P 2.6.20-mm1 #3 [ 149.593785] RIP: 0010:[] [] :cdc_acm:acm_probe+0x1dd/0x741 [ 149.602650] RSP: 0018:81003df29c98 EFLAGS: 00010246 [ 149.608045] RAX: 81003eb14800 RBX: 81003eb14820 RCX: 81003eb21008 [ 149.615278] RDX: 81003eb14800 RSI: RDI: [ 149.622507] RBP: R08: 0001 R09: 0d80 [ 149.629730] R10: R11: c219a7f8 R12: 0d80 [ 149.636960] R13: 81003f555800 R14: R15: 81003eb14800 [ 149.644183] FS: 2abc668716d0() GS:80544000() knlGS: [ 149.652393] CS: 0010 DS: ES: CR0: 8005003b [ 149.658217] CR2: 0008 CR3: 3d25d000 CR4: 06e0 [ 149.665458] Process modprobe (pid: 1620, threadinfo 81003df28000, task 81003eeb0950) [ 149.674014] Stack: 81003d21af20 81003eb14800 81003edf3418 81003d21af20 [ 149.682317] fff4 81003d4e3820 00ff804db922 0001 [ 149.689981] 00100db0 81003d21af20 8801cbe5 81003eb14820 [ 149.697455] Call Trace: [ 149.700194] [] :usbcore:usb_match_one_id+0x26/0x84 [ 149.706742] [] :usbcore:usb_probe_interface+0x7d/0xa5 [ 149.713544] [] driver_probe_device+0xf6/0x17f [ 149.719654] [] __driver_attach+0x0/0x93 [ 149.725230] [] __driver_attach+0x5a/0x93 [ 149.730893] [] bus_for_each_dev+0x43/0x6e [ 149.736644] [] bus_add_driver+0x6b/0x18d [ 149.742310] [] :usbcore:usb_register_driver+0x85/0xeb [ 149.749113] [] :cdc_acm:acm_init+0xcc/0x105 [ 149.755037] [] sys_init_module+0x1572/0x16d2 [ 149.761058] [] system_call+0x7e/0x83 [ 149.766361] [ 149.767898] [ 149.767898] Code: 49 8b 46 08 80 78 05 0a 74 17 49 8b 47 08 80 78 05 0a 0f 85 [ 149.777661] RIP [] :cdc_acm:acm_probe+0x1dd/0x741 [ 149.784146] RSP [ 149.787694] CR2: 0008 [0.00] Linux version 2.6.20-mm1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #3 SMP PREEMPT Fri Feb 16 17:31:24 MST 2007 [0.00] Command line: root=/dev/sdc1 ro console=tty0 console=ttyS0,115200n8 BOOT_IMAGE=vmlinuz [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e4000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3ff8 (usable) [0.00] BIOS-e820: 3ff8 - 3ff8e000 (ACPI data) [0.00] BIOS-e820: 3ff8e000 - 3ffe (ACPI NVS) [0.00] BIOS-e820: 3ffe - 4000 (reserved) [0.00] BIOS-e820: ffb0 - 0001 (reserved) [0.00] end_pfn_map = 1048576 [0.00] DMI 2.4 present. [0.00] ACPI: RSDP 000FAF20, 0024 (r2 ACPIAM) [0.00] ACPI: XSDT 3FF80100, 0064 (r1 NEC 1000724 MSFT 97) [0.00] ACPI: FACP 3FF80290, 00F4 (r3 A_M_I_ OEMFACP 1000724 MSFT 97) [0.00] ACPI: DSDT 3FF80590, 9560 (r1 A0543 A05430000 INTL 20060113) [0.00] ACPI: FACS 3FF8E000, 0040 [0.00] ACPI: APIC 3FF80390, 0080 (r1 A_M_I_ OEMAPIC 1000724 MSFT 97) [0.00] ACPI: SLIC 3FF80410, 0176 (r1 NEC 1000724 MSFT 97) [0.00] ACPI: OEMB 3FF8E040, 0066 (r1 A_M_I_ AMI_OEM 1000724 MSFT 97) [0.00] ACPI: HPET 3FF89AF0, 0038 (r1 A_M_I_ OEMHPET 1000724 MSFT 97) [0.00] ACPI: MCFG 3FF89B30, 003C (r1 A_M_I_ OEMMCFG 1000724 MSFT 97) [0.00] ACPI: SSDT 3FF8E0B0, 01C6 (r1AMI CPU1PM1 INTL 20060113) [0.00] ACPI: SSDT 3FF8E280, 013A (r1AMI CPU2PM1 INTL 20060113) [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [
Re: 2.6.20-mm1
On Thu, 15 Feb 2007 21:30:06 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Nope, can't reproduce (the bug, that is). > > Actually, the oops you have there is the fourth one, so we might be seeing > downstream effects of oops #1. Can you please capture the first oops > trace? Increasing the log buffer size or using netconsole might help. Well, forget it. Booting without the nVidia driver makes the oopses go away. I looks like nvidia is doing something strange with the i2c interface. D**d closed source drivers... -- 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.19-jam07 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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.20-mm1 [kernel BUG at mm/swap.c:442]
On Fri, 16 Feb 2007, Christoph Lameter wrote: > Andrew already has this fix which cures it for me. PG_mlocked pages can > be freed in some situations and thus we need the correct handling in the > page allocator: Works for me. - James -- James Morris <[EMAIL PROTECTED]> - 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.20-mm1 - undefined reference to `delete_module' on x86
On Fri, 16 Feb 2007 11:14:17 -0600 Steve Fox <[EMAIL PROTECTED]> wrote: > Full log at > http://test.kernel.org/abat/71719/debug/test.log.0 > Config at > http://test.kernel.org/abat/71719/build/dotconfig > > CHK include/linux/compile.h > UPD include/linux/compile.h > CC init/version.o > LD init/built-in.o > LD .tmp_vmlinux1 > kernel/built-in.o(.text+0x1426a): In function `store_mod_unload': > kernel/kmod.c:168: undefined reference to `delete_module' > make: *** [.tmp_vmlinux1] Error 1 > Yes, sorry. I believe Greg now has a replacement patch which fixes that up. I think the workaround is CONFIG_MODULE_UNLOAD=y (or CONFIG_MODULE_FORCE_UNLOAD=y). - 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.20-mm1 - undefined reference to `delete_module' on x86
Full log at http://test.kernel.org/abat/71719/debug/test.log.0 Config at http://test.kernel.org/abat/71719/build/dotconfig CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 kernel/built-in.o(.text+0x1426a): In function `store_mod_unload': kernel/kmod.c:168: undefined reference to `delete_module' make: *** [.tmp_vmlinux1] Error 1 -- Steve Fox IBM Linux Technology Center - 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.20-mm1
On Fri, 16 Feb 2007 10:37:12 -0600 Steve Fox wrote: > bl6-13, an x86_64 box listed on test.kernel.org, tripped on this during > an LTP run, even with > unify-queue_delayed_work-and-queue_delayed_work_on-fix.patch applied. > > I'm not sure why the LTP results aren't copied over to TKO, but here's > the details anyway. > > If someone can give me an idea where to look, I can start a bi-sect if > it would help. > > kernel BUG at mm/swap.c:469! > invalid opcode: [1] SMP > last sysfs file: /devices/system/node/node0/cpumap Try this patch? http://lkml.org/lkml/2007/2/16/220 --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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.20-mm1
bl6-13, an x86_64 box listed on test.kernel.org, tripped on this during an LTP run, even with unify-queue_delayed_work-and-queue_delayed_work_on-fix.patch applied. I'm not sure why the LTP results aren't copied over to TKO, but here's the details anyway. If someone can give me an idea where to look, I can start a bi-sect if it would help. kernel BUG at mm/swap.c:469! invalid opcode: [1] SMP last sysfs file: /devices/system/node/node0/cpumap CPU 1 Modules linked in: hidp rfcomm l2cap bluetooth sunrpc ipv6 video button battery asus_acpi ac lp parport_pc parport nvram pcspkr amd_rng rng_core i2c_amd756 i2c_core Pid: 19380, comm: mlockall01 Not tainted 2.6.20-mm1-autokern1 #1 RIP: 0010:[] [] __pagevec_lru_add_mlock+0x6f/0x108 RSP: 0018:810022d0fdd8 EFLAGS: 00010002 RAX: 0011006c RBX: 81003ff41000 RCX: 81003ff40dc0 RDX: RSI: 810026df36b8 RDI: 8100c480 RBP: 8100bb00 R08: 8100212f0e40 R09: 81003ee13d84 R10: 0286 R11: 0246 R12: 81000502aae0 R13: R14: 81000501fd20 R15: 0036d491a000 FS: 2b212329b1e0() GS:81003ee13cc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2b2123283000 CR3: 23fba000 CR4: 06e0 Process mlockall01 (pid: 19380, threadinfo 810022d0e000, task 81002ccdc080) Stack: 8100212f0e40 81003ff7a1c0 3eb47020 0036d490e000 810031d31870 8027387a 810022d0fed8 810026df36b8 810022d0fee0 Call Trace: [] unmap_vmas+0x43c/0x760 [] exit_mmap+0x78/0xed [] mmput+0x45/0xb8 [] do_exit+0x23d/0x811 [] sys_exit_group+0x0/0xe [] system_call+0x7e/0x83 Code: 0f 0b eb fe f0 0f ba 2b 05 f0 0f ba 33 14 f0 0f ba 2b 06 be RIP [] __pagevec_lru_add_mlock+0x6f/0x108 RSP Fixing recursive fault but reboot is needed! BUG: spinlock lockup on CPU#3, syslogd/19381, 8100c480 Call Trace: [] _raw_spin_lock+0xcf/0xf6 [] __pagevec_lru_add_active+0x60/0xe3 [] do_wp_page+0x3d8/0x485 [] __handle_mm_fault+0x96d/0x9e2 [] do_page_fault+0x42b/0x7b1 [] lock_hrtimer_base+0x1b/0x3c [] _spin_unlock_irq+0x9/0xc [] do_sigaction+0x16b/0x17f [] do_setitimer+0x18e/0x336 [] error_exit+0x0/0x84 -- 0:conmux-control -- time-stamp -- Feb/16/07 4:13:11 -- -- 0:conmux-control -- time-stamp -- Feb/16/07 5:22:45 -- BUG: spinlock lockup on CPU#0, portmap/1699, 8100c480 Call Trace: [] _raw_spin_lock+0xcf/0xf6 [] __pagevec_lru_add+0x61/0xe0 [] __lru_add_drain+0x24/0x7e [] unmap_region+0x41/0x12c [] do_munmap+0x1f9/0x276 [] __down_write_nested+0x34/0x9e [] sys_munmap+0x40/0x5a [] system_call+0x7e/0x83 -- Steve Fox IBM Linux Technology Center - 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.20-mm1 [kernel BUG at mm/swap.c:442]
On Fri, 16 Feb 2007, James Morris wrote:
> Then, I get this reliably as ntpd starts up:
> [ 92.905514] [] lru_add_drain+0x57/0x8d
> [ 92.905519] [] free_pages_and_swap_cache+0x12/0x85
> [ 92.905526] [] unmap_region+0xfd/0x129
> [ 92.905530] [] do_munmap+0x153/0x1b4
> [ 92.905534] [] sys_munmap+0x25/0x34
> [ 92.905538] [] syscall_call+0x7/0xb
> [ 92.905542] ===
> [ 92.905544] Code: 74 1a 85 d2 74 0b 8d 82 80 05 00 00 e8 6a 3a 1a 00 8d 86
> 80 05 00 00 e8 7c 36 1a 00 8b 03 a9 00 00 10 00 74
> 3f 8b 03 a8 20 74 04 <0f> 0b eb fe f0 0f ba 2b 05 f0 0f ba 33 14 f0 0f ba 2b
> 06 ba 03
Andrew already has this fix which cures it for me. PG_mlocked pages can
be freed in some situations and thus we need the correct handling in the
page allocator:
Index: linux-2.6.20/include/linux/page-flags.h
===
--- linux-2.6.20.orig/include/linux/page-flags.h2007-02-15
20:42:42.0 -0800
+++ linux-2.6.20/include/linux/page-flags.h 2007-02-15 20:43:33.0
-0800
@@ -261,6 +261,7 @@ static inline void SetPageUptodate(struc
#define PageMlocked(page) test_bit(PG_mlocked, &(page)->flags)
#define SetPageMlocked(page) set_bit(PG_mlocked, &(page)->flags)
#define ClearPageMlocked(page) clear_bit(PG_mlocked, &(page)->flags)
+#define __ClearPageMlocked(page) __clear_bit(PG_mlocked, &(page)->flags)
struct page; /* forward declaration */
Index: linux-2.6.20/mm/page_alloc.c
===
--- linux-2.6.20.orig/mm/page_alloc.c 2007-02-15 20:42:42.0 -0800
+++ linux-2.6.20/mm/page_alloc.c2007-02-15 20:55:23.0 -0800
@@ -203,6 +203,7 @@ static void bad_page(struct page *page)
1 << PG_slab|
1 << PG_swapcache |
1 << PG_writeback |
+ 1 << PG_mlocked |
1 << PG_buddy );
set_page_count(page, 0);
reset_page_mapcount(page);
@@ -442,6 +443,11 @@ static inline int free_pages_check(struc
bad_page(page);
if (PageDirty(page))
__ClearPageDirty(page);
+ if (PageMlocked(page)) {
+ /* Page is unused so no need to take the lru lock */
+ __ClearPageMlocked(page);
+ dec_zone_page_state(page, NR_MLOCK);
+ }
/*
* For now, we report if PG_reserved was found set, but do not
* clear it, and do not free the page. But we shall soon need
@@ -588,6 +594,7 @@ static int prep_new_page(struct page *pa
1 << PG_swapcache |
1 << PG_writeback |
1 << PG_reserved |
+ 1 << PG_mlocked |
1 << PG_buddy
bad_page(page);
-
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.20-mm1 [kernel BUG at mm/swap.c:442]
On Thu, 15 Feb 2007, Andrew Morton wrote: > That's > > VM_BUG_ON(PageMlocked(page)); > > Setting CONFIG_DEBUG_VM=n will shut it up. > Then, I get this reliably as ntpd starts up: [ 92.725346] [ cut here ] [ 92.741162] kernel BUG at mm/swap.c:469! [ 92.755867] invalid opcode: [#1] [ 92.769975] PREEMPT SMP [ 92.783289] last sysfs file: /devices/pnp0/00:00/id [ 92.798654] Modules linked in: sg pcspkr e1000 [ 92.813994] CPU:2 [ 92.813995] EIP:0060:[]Not tainted VLI [ 92.813997] EFLAGS: 00010002 (2.6.20-mm1 #4) [ 92.856416] EIP is at __pagevec_lru_add_mlock+0x5e/0xcf [ 92.871671] eax: 8011006c ebx: c1c057f8 ecx: c1fe063c edx: 0001 [ 92.888445] esi: c03d3500 edi: c1c5e7c0 ebp: f6037f14 esp: f6037f04 [ 92.905436] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 92.905443] Process ntpd (pid: 1582, ti=f6036000 task=c1fe00f0 task.ti=f6036000) [ 92.905446] Stack: 0002 f606acb8 0007 f6037f20 c014e7ff c1c5cf30 f6037f40 [ 92.905456]c015a03f b7ce9000 f606acb8 f6037f40 c1c5cf20 f606acb8 f7ef2f00 f6037f70 [ 92.905466]c0155acb b7cf f6037f5c f7316420 c1fd2180 c1c5cf20 [ 92.905475] Call Trace: [ 92.905478] [] show_trace_log_lvl+0x1a/0x2f [ 92.905485] [] show_stack_log_lvl+0x9b/0xaa [ 92.905492] [] show_registers+0x1e6/0x325 [ 92.905497] [] die+0x11d/0x21c [ 92.905500] [] do_trap+0x79/0x91 [ 92.905504] [] do_invalid_op+0x97/0xa1 [ 92.905509] [] error_code+0x7c/0x84 [ 92.905514] [] lru_add_drain+0x57/0x8d [ 92.905519] [] free_pages_and_swap_cache+0x12/0x85 [ 92.905526] [] unmap_region+0xfd/0x129 [ 92.905530] [] do_munmap+0x153/0x1b4 [ 92.905534] [] sys_munmap+0x25/0x34 [ 92.905538] [] syscall_call+0x7/0xb [ 92.905542] === [ 92.905544] Code: 74 1a 85 d2 74 0b 8d 82 80 05 00 00 e8 6a 3a 1a 00 8d 86 80 05 00 00 e8 7c 36 1a 00 8b 03 a9 00 00 10 00 74 3f 8b 03 a8 20 74 04 <0f> 0b eb fe f0 0f ba 2b 05 f0 0f ba 33 14 f0 0f ba 2b 06 ba 03 -- James Morris <[EMAIL PROTECTED]> - 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.20-mm1 [kernel BUG at mm/swap.c:442]
On Thu, 15 Feb 2007, Christoph Lameter wrote: > On Thu, 15 Feb 2007, Andrew Morton wrote: > > > I don't immediately see why that code isn't racy: the page can remain > > in the pagevec for arbitrary amounts of time and someone can come along > > and mlock it again. But given the ease with which you're hitting this, > > it may not be a race. > > As long as the page is on the pagevec it should be off the LRU. > Marking a page PageMlocked requires the page to be on the LRU. So a page > cannot be marked PageMlocked as long as it is on the regular pagevecs. > > Somehow a page off the LRU was marked PageMlocked. Or a new anonymous page > was allocated and marked PageMlocked and then some later processing put it > onto the LRU? > > Maybe try_to_set_mlocked does work some havoc here. > > Could you see if this patch fixes it? This just disabled an optimization > to set PageMlocked early. Nope, doesn't fix the problem. > Index: linux-2.6.20-mm1/mm/memory.c > ======= > --- linux-2.6.20-mm1.orig/mm/memory.c 2007-02-15 14:35:41.0 -0800 > +++ linux-2.6.20-mm1/mm/memory.c 2007-02-15 14:35:54.0 -0800 > @@ -930,6 +930,8 @@ static void try_to_set_mlocked(struct pa > struct zone *zone; > unsigned long flags; > > + return; > + > if (!PageLRU(page) || PageMlocked(page)) > return; > > -- James Morris <[EMAIL PROTECTED]> - 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.20-mm1 [kernel BUG at mm/swap.c:442]
On Thu, 15 Feb 2007, Christoph Lameter wrote: On Thu, 15 Feb 2007, Andrew Morton wrote: I don't immediately see why that code isn't racy: the page can remain in the pagevec for arbitrary amounts of time and someone can come along and mlock it again. But given the ease with which you're hitting this, it may not be a race. As long as the page is on the pagevec it should be off the LRU. Marking a page PageMlocked requires the page to be on the LRU. So a page cannot be marked PageMlocked as long as it is on the regular pagevecs. Somehow a page off the LRU was marked PageMlocked. Or a new anonymous page was allocated and marked PageMlocked and then some later processing put it onto the LRU? Maybe try_to_set_mlocked does work some havoc here. Could you see if this patch fixes it? This just disabled an optimization to set PageMlocked early. Nope, doesn't fix the problem. Index: linux-2.6.20-mm1/mm/memory.c === --- linux-2.6.20-mm1.orig/mm/memory.c 2007-02-15 14:35:41.0 -0800 +++ linux-2.6.20-mm1/mm/memory.c 2007-02-15 14:35:54.0 -0800 @@ -930,6 +930,8 @@ static void try_to_set_mlocked(struct pa struct zone *zone; unsigned long flags; + return; + if (!PageLRU(page) || PageMlocked(page)) return; -- James Morris [EMAIL PROTECTED] - 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.20-mm1 [kernel BUG at mm/swap.c:442]
On Thu, 15 Feb 2007, Andrew Morton wrote: That's VM_BUG_ON(PageMlocked(page)); Setting CONFIG_DEBUG_VM=n will shut it up. Then, I get this reliably as ntpd starts up: [ 92.725346] [ cut here ] [ 92.741162] kernel BUG at mm/swap.c:469! [ 92.755867] invalid opcode: [#1] [ 92.769975] PREEMPT SMP [ 92.783289] last sysfs file: /devices/pnp0/00:00/id [ 92.798654] Modules linked in: sg pcspkr e1000 [ 92.813994] CPU:2 [ 92.813995] EIP:0060:[c014e548]Not tainted VLI [ 92.813997] EFLAGS: 00010002 (2.6.20-mm1 #4) [ 92.856416] EIP is at __pagevec_lru_add_mlock+0x5e/0xcf [ 92.871671] eax: 8011006c ebx: c1c057f8 ecx: c1fe063c edx: 0001 [ 92.888445] esi: c03d3500 edi: c1c5e7c0 ebp: f6037f14 esp: f6037f04 [ 92.905436] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 92.905443] Process ntpd (pid: 1582, ti=f6036000 task=c1fe00f0 task.ti=f6036000) [ 92.905446] Stack: 0002 f606acb8 0007 f6037f20 c014e7ff c1c5cf30 f6037f40 [ 92.905456]c015a03f b7ce9000 f606acb8 f6037f40 c1c5cf20 f606acb8 f7ef2f00 f6037f70 [ 92.905466]c0155acb b7cf f6037f5c f7316420 c1fd2180 c1c5cf20 [ 92.905475] Call Trace: [ 92.905478] [c010389a] show_trace_log_lvl+0x1a/0x2f [ 92.905485] [c010394a] show_stack_log_lvl+0x9b/0xaa [ 92.905492] [c0103b3f] show_registers+0x1e6/0x325 [ 92.905497] [c0103d9b] die+0x11d/0x21c [ 92.905500] [c0103f13] do_trap+0x79/0x91 [ 92.905504] [c01047d9] do_invalid_op+0x97/0xa1 [ 92.905509] [c02f223c] error_code+0x7c/0x84 [ 92.905514] [c014e7ff] lru_add_drain+0x57/0x8d [ 92.905519] [c015a03f] free_pages_and_swap_cache+0x12/0x85 [ 92.905526] [c0155acb] unmap_region+0xfd/0x129 [ 92.905530] [c0156404] do_munmap+0x153/0x1b4 [ 92.905534] [c015648a] sys_munmap+0x25/0x34 [ 92.905538] [c01028fc] syscall_call+0x7/0xb [ 92.905542] === [ 92.905544] Code: 74 1a 85 d2 74 0b 8d 82 80 05 00 00 e8 6a 3a 1a 00 8d 86 80 05 00 00 e8 7c 36 1a 00 8b 03 a9 00 00 10 00 74 3f 8b 03 a8 20 74 04 0f 0b eb fe f0 0f ba 2b 05 f0 0f ba 33 14 f0 0f ba 2b 06 ba 03 -- James Morris [EMAIL PROTECTED] - 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.20-mm1
bl6-13, an x86_64 box listed on test.kernel.org, tripped on this during an LTP run, even with unify-queue_delayed_work-and-queue_delayed_work_on-fix.patch applied. I'm not sure why the LTP results aren't copied over to TKO, but here's the details anyway. If someone can give me an idea where to look, I can start a bi-sect if it would help. kernel BUG at mm/swap.c:469! invalid opcode: [1] SMP last sysfs file: /devices/system/node/node0/cpumap CPU 1 Modules linked in: hidp rfcomm l2cap bluetooth sunrpc ipv6 video button battery asus_acpi ac lp parport_pc parport nvram pcspkr amd_rng rng_core i2c_amd756 i2c_core Pid: 19380, comm: mlockall01 Not tainted 2.6.20-mm1-autokern1 #1 RIP: 0010:[8026e007] [8026e007] __pagevec_lru_add_mlock+0x6f/0x108 RSP: 0018:810022d0fdd8 EFLAGS: 00010002 RAX: 0011006c RBX: 81003ff41000 RCX: 81003ff40dc0 RDX: RSI: 810026df36b8 RDI: 8100c480 RBP: 8100bb00 R08: 8100212f0e40 R09: 81003ee13d84 R10: 0286 R11: 0246 R12: 81000502aae0 R13: R14: 81000501fd20 R15: 0036d491a000 FS: 2b212329b1e0() GS:81003ee13cc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2b2123283000 CR3: 23fba000 CR4: 06e0 Process mlockall01 (pid: 19380, threadinfo 810022d0e000, task 81002ccdc080) Stack: 8100212f0e40 81003ff7a1c0 3eb47020 0036d490e000 810031d31870 8027387a 810022d0fed8 810026df36b8 810022d0fee0 Call Trace: [8027387a] unmap_vmas+0x43c/0x760 [802774fc] exit_mmap+0x78/0xed [80230ca3] mmput+0x45/0xb8 [80235ee7] do_exit+0x23d/0x811 [80236537] sys_exit_group+0x0/0xe [80209b6e] system_call+0x7e/0x83 Code: 0f 0b eb fe f0 0f ba 2b 05 f0 0f ba 33 14 f0 0f ba 2b 06 be RIP [8026e007] __pagevec_lru_add_mlock+0x6f/0x108 RSP 810022d0fdd8 Fixing recursive fault but reboot is needed! BUG: spinlock lockup on CPU#3, syslogd/19381, 8100c480 Call Trace: [80330047] _raw_spin_lock+0xcf/0xf6 [8026e100] __pagevec_lru_add_active+0x60/0xe3 [8027312f] do_wp_page+0x3d8/0x485 [80274a5d] __handle_mm_fault+0x96d/0x9e2 [804d1876] do_page_fault+0x42b/0x7b1 [80246af3] lock_hrtimer_base+0x1b/0x3c [804cf801] _spin_unlock_irq+0x9/0xc [8023c175] do_sigaction+0x16b/0x17f [80236c29] do_setitimer+0x18e/0x336 [804cfc2d] error_exit+0x0/0x84 -- 0:conmux-control -- time-stamp -- Feb/16/07 4:13:11 -- -- 0:conmux-control -- time-stamp -- Feb/16/07 5:22:45 -- BUG: spinlock lockup on CPU#0, portmap/1699, 8100c480 Call Trace: [80330047] _raw_spin_lock+0xcf/0xf6 [8026e1e4] __pagevec_lru_add+0x61/0xe0 [8026e3aa] __lru_add_drain+0x24/0x7e [80277324] unmap_region+0x41/0x12c [8027808d] do_munmap+0x1f9/0x276 [804cf1e0] __down_write_nested+0x34/0x9e [8027814a] sys_munmap+0x40/0x5a [80209b6e] system_call+0x7e/0x83 -- Steve Fox IBM Linux Technology Center - 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.20-mm1
On Fri, 16 Feb 2007 10:37:12 -0600 Steve Fox wrote: bl6-13, an x86_64 box listed on test.kernel.org, tripped on this during an LTP run, even with unify-queue_delayed_work-and-queue_delayed_work_on-fix.patch applied. I'm not sure why the LTP results aren't copied over to TKO, but here's the details anyway. If someone can give me an idea where to look, I can start a bi-sect if it would help. kernel BUG at mm/swap.c:469! invalid opcode: [1] SMP last sysfs file: /devices/system/node/node0/cpumap Try this patch? http://lkml.org/lkml/2007/2/16/220 --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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.20-mm1 - undefined reference to `delete_module' on x86
Full log at http://test.kernel.org/abat/71719/debug/test.log.0 Config at http://test.kernel.org/abat/71719/build/dotconfig CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 kernel/built-in.o(.text+0x1426a): In function `store_mod_unload': kernel/kmod.c:168: undefined reference to `delete_module' make: *** [.tmp_vmlinux1] Error 1 -- Steve Fox IBM Linux Technology Center - 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.20-mm1 - undefined reference to `delete_module' on x86
On Fri, 16 Feb 2007 11:14:17 -0600 Steve Fox [EMAIL PROTECTED] wrote: Full log at http://test.kernel.org/abat/71719/debug/test.log.0 Config at http://test.kernel.org/abat/71719/build/dotconfig CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 kernel/built-in.o(.text+0x1426a): In function `store_mod_unload': kernel/kmod.c:168: undefined reference to `delete_module' make: *** [.tmp_vmlinux1] Error 1 Yes, sorry. I believe Greg now has a replacement patch which fixes that up. I think the workaround is CONFIG_MODULE_UNLOAD=y (or CONFIG_MODULE_FORCE_UNLOAD=y). - 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.20-mm1 [kernel BUG at mm/swap.c:442]
On Fri, 16 Feb 2007, Christoph Lameter wrote: Andrew already has this fix which cures it for me. PG_mlocked pages can be freed in some situations and thus we need the correct handling in the page allocator: Works for me. - James -- James Morris [EMAIL PROTECTED] - 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.20-mm1
On Thu, 15 Feb 2007 21:30:06 -0800, Andrew Morton [EMAIL PROTECTED] wrote: Nope, can't reproduce (the bug, that is). Actually, the oops you have there is the fourth one, so we might be seeing downstream effects of oops #1. Can you please capture the first oops trace? Increasing the log buffer size or using netconsole might help. Well, forget it. Booting without the nVidia driver makes the oopses go away. I looks like nvidia is doing something strange with the i2c interface. D**d closed source drivers... -- 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.19-jam07 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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/
2.6.20-mm1 USB-related OOPS
I get the following OOPS on boot, presumably connected with USB driver loading. I've attached the entire log. Please CC on replies as I'm not subscribed. [ 149.525742] Unable to handle kernel NULL pointer dereference at 0008 RIP: [ 149.531302] [8887eec3] :cdc_acm:acm_probe+0x1dd/0x741 [ 149.539958] PGD 3d248067 PUD 3d23c067 PMD 0 [ 149.544431] Oops: [1] PREEMPT SMP [ 149.548475] last sysfs file: /class/net/lo/operstate [ 149.553510] CPU 0 [ 149.555618] Modules linked in: cdc_acm snd_rtctimer w83627ehf eeprom i2c_isa nvidia(P) usb_storage usbhid 8139cp snd_hda_intel snd_hda_codec snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_timer snd_seq_device snd 8139too uhci_hcd mii soundcore snd_page_alloc i2c_i801 evdev usbcore i2c_core floppy [ 149.587337] Pid: 1620, comm: modprobe Tainted: P 2.6.20-mm1 #3 [ 149.593785] RIP: 0010:[8887eec3] [8887eec3] :cdc_acm:acm_probe+0x1dd/0x741 [ 149.602650] RSP: 0018:81003df29c98 EFLAGS: 00010246 [ 149.608045] RAX: 81003eb14800 RBX: 81003eb14820 RCX: 81003eb21008 [ 149.615278] RDX: 81003eb14800 RSI: RDI: [ 149.622507] RBP: R08: 0001 R09: 0d80 [ 149.629730] R10: R11: c219a7f8 R12: 0d80 [ 149.636960] R13: 81003f555800 R14: R15: 81003eb14800 [ 149.644183] FS: 2abc668716d0() GS:80544000() knlGS: [ 149.652393] CS: 0010 DS: ES: CR0: 8005003b [ 149.658217] CR2: 0008 CR3: 3d25d000 CR4: 06e0 [ 149.665458] Process modprobe (pid: 1620, threadinfo 81003df28000, task 81003eeb0950) [ 149.674014] Stack: 81003d21af20 81003eb14800 81003edf3418 81003d21af20 [ 149.682317] fff4 81003d4e3820 00ff804db922 0001 [ 149.689981] 00100db0 81003d21af20 8801cbe5 81003eb14820 [ 149.697455] Call Trace: [ 149.700194] [8801cbe5] :usbcore:usb_match_one_id+0x26/0x84 [ 149.706742] [8801d78e] :usbcore:usb_probe_interface+0x7d/0xa5 [ 149.713544] [8039ac88] driver_probe_device+0xf6/0x17f [ 149.719654] [8039ad94] __driver_attach+0x0/0x93 [ 149.725230] [8039adee] __driver_attach+0x5a/0x93 [ 149.730893] [8039a14e] bus_for_each_dev+0x43/0x6e [ 149.736644] [8039a48e] bus_add_driver+0x6b/0x18d [ 149.742310] [8801d2b0] :usbcore:usb_register_driver+0x85/0xeb [ 149.749113] [880560cc] :cdc_acm:acm_init+0xcc/0x105 [ 149.755037] [8028dd0b] sys_init_module+0x1572/0x16d2 [ 149.761058] [802561ce] system_call+0x7e/0x83 [ 149.766361] [ 149.767898] [ 149.767898] Code: 49 8b 46 08 80 78 05 0a 74 17 49 8b 47 08 80 78 05 0a 0f 85 [ 149.777661] RIP [8887eec3] :cdc_acm:acm_probe+0x1dd/0x741 [ 149.784146] RSP 81003df29c98 [ 149.787694] CR2: 0008 [0.00] Linux version 2.6.20-mm1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #3 SMP PREEMPT Fri Feb 16 17:31:24 MST 2007 [0.00] Command line: root=/dev/sdc1 ro console=tty0 console=ttyS0,115200n8 BOOT_IMAGE=vmlinuz [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e4000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3ff8 (usable) [0.00] BIOS-e820: 3ff8 - 3ff8e000 (ACPI data) [0.00] BIOS-e820: 3ff8e000 - 3ffe (ACPI NVS) [0.00] BIOS-e820: 3ffe - 4000 (reserved) [0.00] BIOS-e820: ffb0 - 0001 (reserved) [0.00] end_pfn_map = 1048576 [0.00] DMI 2.4 present. [0.00] ACPI: RSDP 000FAF20, 0024 (r2 ACPIAM) [0.00] ACPI: XSDT 3FF80100, 0064 (r1 NEC 1000724 MSFT 97) [0.00] ACPI: FACP 3FF80290, 00F4 (r3 A_M_I_ OEMFACP 1000724 MSFT 97) [0.00] ACPI: DSDT 3FF80590, 9560 (r1 A0543 A05430000 INTL 20060113) [0.00] ACPI: FACS 3FF8E000, 0040 [0.00] ACPI: APIC 3FF80390, 0080 (r1 A_M_I_ OEMAPIC 1000724 MSFT 97) [0.00] ACPI: SLIC 3FF80410, 0176 (r1 NEC 1000724 MSFT 97) [0.00] ACPI: OEMB 3FF8E040, 0066 (r1 A_M_I_ AMI_OEM 1000724 MSFT 97) [0.00] ACPI: HPET 3FF89AF0, 0038 (r1 A_M_I_ OEMHPET 1000724 MSFT 97) [0.00] ACPI: MCFG 3FF89B30, 003C (r1 A_M_I_ OEMMCFG 1000724 MSFT 97) [0.00] ACPI: SSDT 3FF8E0B0, 01C6 (r1AMI CPU1PM1 INTL 20060113) [0.00] ACPI: SSDT 3FF8E280, 013A (r1AMI CPU2PM1 INTL 20060113) [0.00] Zone PFN
Re: 2.6.20-mm1
On Fri, 16 Feb 2007 00:39:12 +0100 "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > > > ee1394 usblp evdev > > > CPU:1 > > > EIP:0060:[]Tainted: P VLI > > > EFLAGS: 00010246 (2.6.20-jam01 #1) > > > EIP is at sysfs_lookup+0x5b/0x20a > > > eax: f6707118 ebx: f6b33e5c ecx: f6917d38 edx: 0004 > > > esi: edi: f670717c ebp: f6b33e24 esp: f6997db4 > > > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > > > Process udevd (pid: 3899, ti=f6996000 task=f7e34540 task.ti=f6996000) > > > Stack: f66e1800 f6707118 c016da12 f66e1800 f6707118 c02f75c0 f6707118 > > > f6997f04 > > >f6997e38 c0164238 f6997e44 c210d8c0 f6b39340 f6b393b4 f7a7d025 > > > f6997e38 > > >27692f8b f6997f04 c0165a6a f7a7d01d 000200d2 c037ddac > > > 0286 > > > Call Trace: > > > [] d_alloc+0x140/0x198 > > > [] do_lookup+0x128/0x165 > > > [] __link_path_walk+0x7e2/0xc9b > > > [] link_path_walk+0x45/0xbf > > > [] do_path_lookup+0x88/0x1cc > > > [] getname+0x90/0xad > > > [] __user_walk_fd+0x2f/0x47 > > > [] vfs_lstat_fd+0x16/0x3d > > > [] sys_lstat64+0xf/0x23 > > > [] do_page_fault+0x326/0x5e2 > > > [] do_page_fault+0x0/0x5e2 > > > [] sysenter_past_esp+0x5f/0x85 > > > [] wait_for_completion_interruptible+0xdf/0xee > > > > > > Oh dear. Any one of about 700 developers might have caused this. > > > > bisection-search will find this. Can you upload the .config please? > > > > Here it goes: > > http://belly.cps.unizar.es/~magallon/oops/config-2.6.20-jam01 Nope, can't reproduce (the bug, that is). Actually, the oops you have there is the fourth one, so we might be seeing downstream effects of oops #1. Can you please capture the first oops trace? Increasing the log buffer size or using netconsole might help. - 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: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)
On Thu, 15 Feb 2007 19:37:39 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > > For what reason was that change made? > > > > It was made so that we can use the markers in C code without actually > including marker.h everywhere. I am sure someone has a better way to do > it : I would be happy to use this-nice-build-system-feature-I-missed to > have marker.h included. Oh. One could whack it in kernel.h: pretty much everything includes that. But it'd be better to simply require that the clients of this infrastructure include the appropriate header file. We do that for everything else and markers aren't special in this regard. - 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: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)
* Andrew Morton ([EMAIL PROTECTED]) wrote: > On Thu, 15 Feb 2007 17:46:56 -0500 > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > > > > Me too. It's due to the linux-kernel-markers patches. Mathieu, can you > > > take a look please? > > > > I will give a deeper look in sparse, but I should say up front that I > > add this to the root build tree Makefile : > > > > LINUXINCLUDE:= -Iinclude \ > >$(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \ > >-include include/linux/autoconf.h \ > >-include linux/marker.h > > > > I guess sparse is maybe not using this Makefile or variable ? > > ow, that's going to hurt - this stuff is complex and fragile. > Sorry, I will remember to do more explicit changelogs. > For what reason was that change made? > It was made so that we can use the markers in C code without actually including marker.h everywhere. I am sure someone has a better way to do it : I would be happy to use this-nice-build-system-feature-I-missed to have marker.h included. > Pleeze, tricky things like this should be changelogged - we shouldn't need > to ask. I missed it. > > -- Mathieu Desnoyers Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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.20-mm1
On Fri, 16 Feb 2007 00:24:35 +0100
Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Andrew Morton napisa__(a):
> > On Thu, 15 Feb 2007 15:37:20 +0100
> > Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> >
> >> Andrew Morton napisa__(a):
> >>> Temporarily at
> >>>
> >>> http://userweb.kernel.org/~akpm/2.6.20-mm1/
> >>>
> >>> Will appear later at
> >>>
> >>>
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/
> >>>
> >>>
> >> BUG: sleeping function called from invalid context at
> >> /mnt/md0/devel/linux-mm/mm/slab.c:3043
> >> in_atomic():1, irqs_disabled():0
> >> 1 lock held by artsd/3819:
> >> #0: (>lock){--..}, at: [] ipc_lock+0x35/0x4f
> >> [] show_trace_log_lvl+0x1a/0x2f
> >> [] show_trace+0x12/0x14
> >> [] dump_stack+0x16/0x18
> >> [] __might_sleep+0xc9/0xcf
> >> [] kmem_cache_zalloc+0x28/0xe5
> >> [] do_shmat+0x111/0x372
> >> [] sys_ipc+0x148/0x1b5
> >> [] syscall_call+0x7/0xb
> >
> > That's shm-make-sysv-ipc-shared-memory-use-stacked-files.patch, brought to
> > us by Eric-who-hasnt-read-Documentation/SubmitChecklist.
> >
> > Like this, I guess:
> >
> > diff -puN ipc/shm.c~shm-make-sysv-ipc-shared-memory-use-stacked-files-fix
> > ipc/shm.c
>
> I might be drunk...
>
> This patch still doesn't solve the problem.
>
> BUG: sleeping function called from invalid context at
> /mnt/md0/devel/linux-mm/mm/slab.c:3043
> in_atomic():1, irqs_disabled():0
> 1 lock held by Xorg/2885:
> #0: (>lock){--..}, at: [] ipc_lock+0x35/0x4f
> [] show_trace_log_lvl+0x1a/0x2f
> [] show_trace+0x12/0x14
> [] dump_stack+0x16/0x18
> [] __might_sleep+0xc9/0xcf
> [] kmem_cache_alloc+0x28/0xbf
> [] get_empty_filp+0x6a/0x173
> [] do_shmat+0x136/0x390
> [] sys_ipc+0x148/0x1b5
> [] syscall_call+0x7/0xb
yes, that's the other one, which Eric will be looking at.
> ===
> BUG: MAX_LOCK_DEPTH too low!
> turning off the locking correctness validator.
> do_IRQ: stack overflow: -52
> [] show_trace_log_lvl+0x1a/0x2f
> [] show_trace+0x12/0x14
> [] dump_stack+0x16/0x18
> [] do_IRQ+0x95/0xc1
> BUG: unable to handle kernel paging request at virtual address 0e200034
> printing eip:
> c01052e2
> *pde =
> Oops: [#1]
> PREEMPT SMP
> last sysfs file:
> /devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/vendor
> Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd
> nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT
> nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter
> ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram
> snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss
> snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss evdev snd_mixer_oss
> snd_pcm snd_timer skge snd 8139too intel_agp sk98lin agpgart soundcore mii
> i2c_i801 snd_page_alloc ide_cd cdrom rtc unix
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00013046 (2.6.20-mm1 #16)
> EIP is at dump_trace+0x88/0x9e
> eax: ebx: f412c01c ecx: c0429344 edx: c03cf8fa
> BUG: unable to handle kernel paging request at virtual address 8d17ca6c
> printing eip:
> c011d927
> *pde =
> esi: 0e20 edi: c03daed2 ebp: f412bfd0 esp: f412bfc0
> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
> Process Xorg (pid: 2885, ti=f412a000 task=f4a58aa0 task.ti=f412c000)
> Stack: c7422ac0 c03daed2 0011 f412bfe4 c0105312 c0429344 c03daed2
>0004 f412bff0 c0105a25 c03daed2 f412bffc c0105ae7 f412c008 f412c01c
> Call Trace:
> [] show_trace_log_lvl+0x1a/0x2f
> [] show_stack_log_lvl+0x9d/0xac
> [] show_registers+0x1ed/0x34c
> [] die+0x11d/0x234
> [] do_page_fault+0x47c/0x55b
> [] error_code+0x7c/0x84
> [] show_trace_log_lvl+0x1a/0x2f
> [] show_trace+0x12/0x14
> [] dump_stack+0x16/0x18
> [] do_IRQ+0x95/0xc1
> BUG: unable to handle kernel paging request at virtual address 0e200034
ooh, we broke lockdep.
-
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: [-mm patch] pci_iomap_regions error handling fix (was Re: 2.6.20-mm1)
On Fri, 16 Feb 2007 16:41:59 +
Frederik Deweerdt <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote:
> >
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-mm1/
> >
> Hi,
>
> It appears that the pcim_iomap_regions() function doesn't get the error
> handling right. It BUGs early at boot with a backtrace along the lines of:
>
> ahci_init
> pci_register_driver
> driver_register
> [...]
> ahci_init_one
> pcim_iomap_region
> pcim_iounmap
>
> The following patch allows me to boot. Only the if(mask..) continue;
> part fixes the problem actually, the gotos where changed so that we
> don't try to unmap something we couldn't map anyway.
>
> Regards,
> Frederik
>
> Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
>
>
> diff --git a/lib/devres.c b/lib/devres.c
> index 2a668dd..eb38849 100644
> --- a/lib/devres.c
> +++ b/lib/devres.c
> @@ -274,21 +274,21 @@ int pcim_iomap_regions(struct pci_dev *pdev, u16 mask,
> const char *name)
>
> rc = pci_request_region(pdev, i, name);
> if (rc)
> - goto err_region;
> + goto err_inval;
>
> rc = -ENOMEM;
> if (!pcim_iomap(pdev, i, 0))
> - goto err_iomap;
> + goto err_region;
> }
>
> return 0;
>
> - err_iomap:
> - pcim_iounmap(pdev, iomap[i]);
> err_region:
> pci_release_region(pdev, i);
> err_inval:
> while (--i >= 0) {
> + if (!(mask & (1 << i)))
> + continue;
> pcim_iounmap(pdev, iomap[i]);
> pci_release_region(pdev, i);
> }
yep, the fix looks good and is needed in mainline, 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: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)
On Thu, 15 Feb 2007 17:46:56 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > > Me too. It's due to the linux-kernel-markers patches. Mathieu, can you > > take a look please? > > I will give a deeper look in sparse, but I should say up front that I > add this to the root build tree Makefile : > > LINUXINCLUDE:= -Iinclude \ >$(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \ >-include include/linux/autoconf.h \ >-include linux/marker.h > > I guess sparse is maybe not using this Makefile or variable ? ow, that's going to hurt - this stuff is complex and fragile. For what reason was that change made? Pleeze, tricky things like this should be changelogged - we shouldn't need to ask. I missed it. - 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.20-mm1
On Thu, 15 Feb 2007 15:31:42 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 15 Feb 2007 22:30:17 +0100 > "J.A. Magall__n" <[EMAIL PROTECTED]> wrote: > > > On Thu, 15 Feb 2007 05:14:08 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > > Temporarily at > > > > > > http://userweb.kernel.org/~akpm/2.6.20-mm1/ > > > > > > Will appear later at > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/ > > > > > > > > > > Oops plague for me :(. > > > > A lot like this: > > > > ee1394 usblp evdev > > CPU:1 > > EIP:0060:[]Tainted: P VLI > > EFLAGS: 00010246 (2.6.20-jam01 #1) > > EIP is at sysfs_lookup+0x5b/0x20a > > eax: f6707118 ebx: f6b33e5c ecx: f6917d38 edx: 0004 > > esi: edi: f670717c ebp: f6b33e24 esp: f6997db4 > > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > > Process udevd (pid: 3899, ti=f6996000 task=f7e34540 task.ti=f6996000) > > Stack: f66e1800 f6707118 c016da12 f66e1800 f6707118 c02f75c0 f6707118 > > f6997f04 > >f6997e38 c0164238 f6997e44 c210d8c0 f6b39340 f6b393b4 f7a7d025 > > f6997e38 > >27692f8b f6997f04 c0165a6a f7a7d01d 000200d2 c037ddac > > 0286 > > Call Trace: > > [] d_alloc+0x140/0x198 > > [] do_lookup+0x128/0x165 > > [] __link_path_walk+0x7e2/0xc9b > > [] link_path_walk+0x45/0xbf > > [] do_path_lookup+0x88/0x1cc > > [] getname+0x90/0xad > > [] __user_walk_fd+0x2f/0x47 > > [] vfs_lstat_fd+0x16/0x3d > > [] sys_lstat64+0xf/0x23 > > [] do_page_fault+0x326/0x5e2 > > [] do_page_fault+0x0/0x5e2 > > [] sysenter_past_esp+0x5f/0x85 > > [] wait_for_completion_interruptible+0xdf/0xee > > > Oh dear. Any one of about 700 developers might have caused this. > > bisection-search will find this. Can you upload the .config please? > Here it goes: http://belly.cps.unizar.es/~magallon/oops/config-2.6.20-jam01 copied from previous and answered missing CONFIG_'s. Just 2.6.20-m11 + 11-pci-iomap-regions posted in LKML + patch to make HDIO_OBSOLETE_IDENTITY work on sata (also from LKML). > > > > Full dmesg at: > > > > http://belly.cps.unizar.es/~magallon/oops/oops.txt > > > > And another one on reboot. Picture here: > > > > http://belly.cps.unizar.es/~magallon/oops/IMG_1448.JPG > > > > (sorry, no tripod available ;), just the back of my soft chair). > > > > And yes, before nobody says anything, nvidia.ko is loaded. > > If you really want, I can try without it. > > It would be appreciated if you could do that, thanks. Probably tomorrow. -- 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.19-jam07 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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.20-mm1
On Thu, 15 Feb 2007 22:30:17 +0100 "J.A. Magall__n" <[EMAIL PROTECTED]> wrote: > On Thu, 15 Feb 2007 05:14:08 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.20-mm1/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/ > > > > > > Oops plague for me :(. > > A lot like this: > > ee1394 usblp evdev > CPU:1 > EIP:0060:[]Tainted: P VLI > EFLAGS: 00010246 (2.6.20-jam01 #1) > EIP is at sysfs_lookup+0x5b/0x20a > eax: f6707118 ebx: f6b33e5c ecx: f6917d38 edx: 0004 > esi: edi: f670717c ebp: f6b33e24 esp: f6997db4 > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process udevd (pid: 3899, ti=f6996000 task=f7e34540 task.ti=f6996000) > Stack: f66e1800 f6707118 c016da12 f66e1800 f6707118 c02f75c0 f6707118 > f6997f04 >f6997e38 c0164238 f6997e44 c210d8c0 f6b39340 f6b393b4 f7a7d025 > f6997e38 >27692f8b f6997f04 c0165a6a f7a7d01d 000200d2 c037ddac > 0286 > Call Trace: > [] d_alloc+0x140/0x198 > [] do_lookup+0x128/0x165 > [] __link_path_walk+0x7e2/0xc9b > [] link_path_walk+0x45/0xbf > [] do_path_lookup+0x88/0x1cc > [] getname+0x90/0xad > [] __user_walk_fd+0x2f/0x47 > [] vfs_lstat_fd+0x16/0x3d > [] sys_lstat64+0xf/0x23 > [] do_page_fault+0x326/0x5e2 > [] do_page_fault+0x0/0x5e2 > [] sysenter_past_esp+0x5f/0x85 > [] wait_for_completion_interruptible+0xdf/0xee Oh dear. Any one of about 700 developers might have caused this. bisection-search will find this. Can you upload the .config please? > > Full dmesg at: > > http://belly.cps.unizar.es/~magallon/oops/oops.txt > > And another one on reboot. Picture here: > > http://belly.cps.unizar.es/~magallon/oops/IMG_1448.JPG > > (sorry, no tripod available ;), just the back of my soft chair). > > And yes, before nobody says anything, nvidia.ko is loaded. > If you really want, I can try without it. It would be appreciated if you could do that, 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.20-mm1
Andrew Morton napisał(a):
> On Thu, 15 Feb 2007 15:37:20 +0100
> Michal Piotrowski <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton napisa__(a):
>>> Temporarily at
>>>
>>> http://userweb.kernel.org/~akpm/2.6.20-mm1/
>>>
>>> Will appear later at
>>>
>>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/
>>>
>>>
>> BUG: sleeping function called from invalid context at
>> /mnt/md0/devel/linux-mm/mm/slab.c:3043
>> in_atomic():1, irqs_disabled():0
>> 1 lock held by artsd/3819:
>> #0: (>lock){--..}, at: [] ipc_lock+0x35/0x4f
>> [] show_trace_log_lvl+0x1a/0x2f
>> [] show_trace+0x12/0x14
>> [] dump_stack+0x16/0x18
>> [] __might_sleep+0xc9/0xcf
>> [] kmem_cache_zalloc+0x28/0xe5
>> [] do_shmat+0x111/0x372
>> [] sys_ipc+0x148/0x1b5
>> [] syscall_call+0x7/0xb
>
> That's shm-make-sysv-ipc-shared-memory-use-stacked-files.patch, brought to
> us by Eric-who-hasnt-read-Documentation/SubmitChecklist.
>
> Like this, I guess:
>
> diff -puN ipc/shm.c~shm-make-sysv-ipc-shared-memory-use-stacked-files-fix
> ipc/shm.c
I might be drunk...
This patch still doesn't solve the problem.
BUG: sleeping function called from invalid context at
/mnt/md0/devel/linux-mm/mm/slab.c:3043
in_atomic():1, irqs_disabled():0
1 lock held by Xorg/2885:
#0: (>lock){--..}, at: [] ipc_lock+0x35/0x4f
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] __might_sleep+0xc9/0xcf
[] kmem_cache_alloc+0x28/0xbf
[] get_empty_filp+0x6a/0x173
[] do_shmat+0x136/0x390
[] sys_ipc+0x148/0x1b5
[] syscall_call+0x7/0xb
===
BUG: MAX_LOCK_DEPTH too low!
turning off the locking correctness validator.
do_IRQ: stack overflow: -52
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] do_IRQ+0x95/0xc1
BUG: unable to handle kernel paging request at virtual address 0e200034
printing eip:
c01052e2
*pde =
Oops: [#1]
PREEMPT SMP
last sysfs file:
/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/vendor
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd
nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT
nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter
ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss evdev snd_mixer_oss
snd_pcm snd_timer skge snd 8139too intel_agp sk98lin agpgart soundcore mii
i2c_i801 snd_page_alloc ide_cd cdrom rtc unix
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00013046 (2.6.20-mm1 #16)
EIP is at dump_trace+0x88/0x9e
eax: ebx: f412c01c ecx: c0429344 edx: c03cf8fa
BUG: unable to handle kernel paging request at virtual address 8d17ca6c
printing eip:
c011d927
*pde =
esi: 0e20 edi: c03daed2 ebp: f412bfd0 esp: f412bfc0
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process Xorg (pid: 2885, ti=f412a000 task=f4a58aa0 task.ti=f412c000)
Stack: c7422ac0 c03daed2 0011 f412bfe4 c0105312 c0429344 c03daed2
0004 f412bff0 c0105a25 c03daed2 f412bffc c0105ae7 f412c008 f412c01c
Call Trace:
[] show_trace_log_lvl+0x1a/0x2f
[] show_stack_log_lvl+0x9d/0xac
[] show_registers+0x1ed/0x34c
[] die+0x11d/0x234
[] do_page_fault+0x47c/0x55b
[] error_code+0x7c/0x84
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] do_IRQ+0x95/0xc1
BUG: unable to handle kernel paging request at virtual address 0e200034
printing eip:
c01052e2
*pde =
Oops: [#2]
PREEMPT SMP
last sysfs file:
/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/vendor
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd
nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT
nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter
ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss evdev snd_mixer_oss
snd_pcm snd_timer skge snd 8139too intel_agp sk98lin agpgart soundcore mii
i2c_i801 snd_page_alloc ide_cd cdrom rtc unix
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00013046 (2.6.20-mm1 #16)
EIP is at dump_trace+0x88/0x9e
eax: ebx: f412c01c ecx: c0429344 edx: c03cf8fa
esi: 0e20 edi: c03cfa80 ebp: f412be5c esp: f412be4c
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process Xorg (pid: 2885, ti=f412a000 task=f4a58aa0 task.ti=f412c000)
Stack: f412be64 c03cfa80 0010 f412be70 c0105312 c0429344 c03cfa80
f412c003 f412be94 c01053c4 c03cfa80 c03cfa80 f412bf88
Re: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Thu, 15 Feb 2007 17:01:27 +0100
> Tilman Schmidt <[EMAIL PROTECTED]> wrote:
>
> > Trying to build 2.6.20-mm1 on i386 with C=1, sparse 0.2 chokes
> > on arch/i386/kernel/i8253.c:
> >
> > CHECK arch/i386/kernel/i8253.c
> > linux/marker.h: No such file or directory
> > include/linux/jiffies.h:18:5: warning: undefined preprocessor identifier
> > 'CONFIG_HZ'
> > include/linux/jiffies.h:20:7: warning: undefined preprocessor identifier
> > 'CONFIG_HZ'
> > include/linux/jiffies.h:22:7: warning: undefined preprocessor identifier
> > 'CONFIG_HZ'
> > include/linux/jiffies.h:24:7: warning: undefined preprocessor identifier
> > 'CONFIG_HZ'
> > include/linux/jiffies.h:26:7: warning: undefined preprocessor identifier
> > 'CONFIG_HZ'
> > include/linux/jiffies.h:28:7: warning: undefined preprocessor identifier
> > 'CONFIG_HZ'
> > include/linux/jiffies.h:30:7: warning: undefined preprocessor identifier
> > 'CONFIG_HZ'
> > include/linux/jiffies.h:33:3: error: You lose.
> > include/linux/jiffies.h:225:5: error: bad constant expression
> > include/asm/module.h:64:2: error: unknown processor family
> > include/asm/processor.h:82:30: error: undefined identifier
> > 'CONFIG_X86_L1_CACHE_SHIFT'
> > include/asm/processor.h:82:30: error: bad constant expression type
> > arch/i386/kernel/i8253.c:120:16: error: Expected ; at end of declaration
> > arch/i386/kernel/i8253.c:120:16: error: got pit_read
> > arch/i386/kernel/i8253.c:128:2: error: Trying to use reserved word 'do' as
> > identifier
> > arch/i386/kernel/i8253.c:128:2: error: Expected ; at end of declaration
> > arch/i386/kernel/i8253.c:128:2: error: got {
> > [loads of similar messages omitted ...]
> > arch/i386/kernel/i8253.c:195:2: error: undefined identifier
> > 'clocksource_pit'
> > arch/i386/kernel/i8253.c:196:9: error: undefined identifier
> > 'clocksource_register'
> > arch/i386/kernel/i8253.c:41:7: error: Expected constant expression in case
> > statement
> > arch/i386/kernel/i8253.c:50:7: error: Expected constant expression in case
> > statement
>
> Me too. It's due to the linux-kernel-markers patches. Mathieu, can you
> take a look please?
I will give a deeper look in sparse, but I should say up front that I
add this to the root build tree Makefile :
LINUXINCLUDE:= -Iinclude \
$(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
-include include/linux/autoconf.h \
-include linux/marker.h
I guess sparse is maybe not using this Makefile or variable ?
--
Mathieu Desnoyers
Computer Engineering Ph.D. Candidate, École Polytechnique de Montréal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
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.20-mm1
On Thursday 15 February 2007 14:14, Andrew Morton wrote: > - The IDE tree got dropped due to various linkage problems Doh, I guess this is what one gets for not testing modular IDE driver support properly. :( All linkage problems should be fixed now, sorry for that. Bart - 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: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)
On Thu, 15 Feb 2007 17:01:27 +0100
Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> Trying to build 2.6.20-mm1 on i386 with C=1, sparse 0.2 chokes
> on arch/i386/kernel/i8253.c:
>
> CHECK arch/i386/kernel/i8253.c
> linux/marker.h: No such file or directory
> include/linux/jiffies.h:18:5: warning: undefined preprocessor identifier
> 'CONFIG_HZ'
> include/linux/jiffies.h:20:7: warning: undefined preprocessor identifier
> 'CONFIG_HZ'
> include/linux/jiffies.h:22:7: warning: undefined preprocessor identifier
> 'CONFIG_HZ'
> include/linux/jiffies.h:24:7: warning: undefined preprocessor identifier
> 'CONFIG_HZ'
> include/linux/jiffies.h:26:7: warning: undefined preprocessor identifier
> 'CONFIG_HZ'
> include/linux/jiffies.h:28:7: warning: undefined preprocessor identifier
> 'CONFIG_HZ'
> include/linux/jiffies.h:30:7: warning: undefined preprocessor identifier
> 'CONFIG_HZ'
> include/linux/jiffies.h:33:3: error: You lose.
> include/linux/jiffies.h:225:5: error: bad constant expression
> include/asm/module.h:64:2: error: unknown processor family
> include/asm/processor.h:82:30: error: undefined identifier
> 'CONFIG_X86_L1_CACHE_SHIFT'
> include/asm/processor.h:82:30: error: bad constant expression type
> arch/i386/kernel/i8253.c:120:16: error: Expected ; at end of declaration
> arch/i386/kernel/i8253.c:120:16: error: got pit_read
> arch/i386/kernel/i8253.c:128:2: error: Trying to use reserved word 'do' as
> identifier
> arch/i386/kernel/i8253.c:128:2: error: Expected ; at end of declaration
> arch/i386/kernel/i8253.c:128:2: error: got {
> [loads of similar messages omitted ...]
> arch/i386/kernel/i8253.c:195:2: error: undefined identifier 'clocksource_pit'
> arch/i386/kernel/i8253.c:196:9: error: undefined identifier
> 'clocksource_register'
> arch/i386/kernel/i8253.c:41:7: error: Expected constant expression in case
> statement
> arch/i386/kernel/i8253.c:50:7: error: Expected constant expression in case
> statement
Me too. It's due to the linux-kernel-markers patches. Mathieu, can you
take a look please?
-
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.20-mm1
Andrew Morton <[EMAIL PROTECTED]> writes: > That's shm-make-sysv-ipc-shared-memory-use-stacked-files.patch, brought to > us by Eric-who-hasnt-read-Documentation/SubmitChecklist. Sorry I thought I had all of the interesting debugging enabled in my kernel build. It must of fallen out someplace. I think I must have figured shm_lock was a semaphore or mutex. > Like this, I guess: Nope. get_empty_filp can sleep as well, unless I'm totally mistaken. It looks like the logic change is going to be a little more than a one liner. I will get back to you in a couple of hours Eric - 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.20-mm1 [kernel BUG at mm/swap.c:442]
On Thu, 15 Feb 2007, Andrew Morton wrote: > I don't immediately see why that code isn't racy: the page can remain > in the pagevec for arbitrary amounts of time and someone can come along > and mlock it again. But given the ease with which you're hitting this, > it may not be a race. As long as the page is on the pagevec it should be off the LRU. Marking a page PageMlocked requires the page to be on the LRU. So a page cannot be marked PageMlocked as long as it is on the regular pagevecs. Somehow a page off the LRU was marked PageMlocked. Or a new anonymous page was allocated and marked PageMlocked and then some later processing put it onto the LRU? Maybe try_to_set_mlocked does work some havoc here. Could you see if this patch fixes it? This just disabled an optimization to set PageMlocked early. Index: linux-2.6.20-mm1/mm/memory.c === --- linux-2.6.20-mm1.orig/mm/memory.c 2007-02-15 14:35:41.0 -0800 +++ linux-2.6.20-mm1/mm/memory.c2007-02-15 14:35:54.0 -0800 @@ -930,6 +930,8 @@ static void try_to_set_mlocked(struct pa struct zone *zone; unsigned long flags; + return; + if (!PageLRU(page) || PageMlocked(page)) return; - 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.20-mm1
On Thu, 15 Feb 2007 15:37:20 +0100
Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Andrew Morton napisa__(a):
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-mm1/
> >
> > Will appear later at
> >
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/
> >
> >
>
> BUG: sleeping function called from invalid context at
> /mnt/md0/devel/linux-mm/mm/slab.c:3043
> in_atomic():1, irqs_disabled():0
> 1 lock held by artsd/3819:
> #0: (>lock){--..}, at: [] ipc_lock+0x35/0x4f
> [] show_trace_log_lvl+0x1a/0x2f
> [] show_trace+0x12/0x14
> [] dump_stack+0x16/0x18
> [] __might_sleep+0xc9/0xcf
> [] kmem_cache_zalloc+0x28/0xe5
> [] do_shmat+0x111/0x372
> [] sys_ipc+0x148/0x1b5
> [] syscall_call+0x7/0xb
That's shm-make-sysv-ipc-shared-memory-use-stacked-files.patch, brought to
us by Eric-who-hasnt-read-Documentation/SubmitChecklist.
Like this, I guess:
diff -puN ipc/shm.c~shm-make-sysv-ipc-shared-memory-use-stacked-files-fix
ipc/shm.c
--- a/ipc/shm.c~shm-make-sysv-ipc-shared-memory-use-stacked-files-fix
+++ a/ipc/shm.c
@@ -818,7 +818,7 @@ long do_shmat(int shmid, char __user *sh
int acc_mode;
void *user_addr;
struct ipc_namespace *ns;
- struct shm_file_data *sfd;
+ struct shm_file_data *sfd = NULL;
mode_t f_mode;
if (shmid < 0) {
@@ -856,6 +856,8 @@ long do_shmat(int shmid, char __user *sh
acc_mode |= S_IXUGO;
}
+ sfd = kzalloc(sizeof(*sfd), GFP_KERNEL);
+
/*
* We cannot rely on the fs check since SYSV IPC does have an
* additional creator id...
@@ -879,13 +881,12 @@ long do_shmat(int shmid, char __user *sh
goto out_unlock;
err = -ENOMEM;
- sfd = kzalloc(sizeof(*sfd), GFP_KERNEL);
if (!sfd)
goto out_unlock;
file = get_empty_filp();
if (!file)
- goto out_free;
+ goto out_unlock;
file->f_op = _file_operations;
file->private_data = sfd;
@@ -939,9 +940,8 @@ invalid:
if (IS_ERR(user_addr))
err = PTR_ERR(user_addr);
out:
- return err;
-out_free:
kfree(sfd);
+ return err;
out_unlock:
shm_unlock(shp);
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.20-mm1 [kernel BUG at mm/swap.c:442]
On Thu, 15 Feb 2007 09:28:23 -0500 (EST) James Morris <[EMAIL PROTECTED]> wrote: > Hit a BUG() via lvm: > > > Scanning logical volumes > Reading all physical volumes. This may take a while... > Found volume group "VolGroup00" using metadata type lvm2 > Activating logical volumes > [ 75.215078] [ cut here ] > [ 75.230165] kernel BUG at mm/swap.c:442! > [ 75.244589] invalid opcode: [#1] > [ 75.258693] PREEMPT SMP > [ 75.271894] last sysfs file: /block/ram0/dev > [ 75.286734] Modules linked in: > [ 75.300193] CPU:0 > [ 75.300195] EIP:0060:[] Not tainted VLI > [ 75.300197] EFLAGS: 00210006 (2.6.20-mm1 #1) > [ 75.341750] EIP is at __pagevec_lru_add_active+0x76/0xcc > [ 75.356722] eax: 80100060 ebx: c1bf9c48 ecx: c1e345bc edx: 0001 > [ 75.373139] esi: c03dc680 edi: c1c4e780 ebp: f7ce3f34 esp: f7ce3f24 > [ 75.389642] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > [ 75.405199] Process lvm (pid: 415, ti=f7ce2000 task=c1e34070 > task.ti=f7ce2000) > [ 75.421908] Stack: c1e25548 f7d58ea0 f7ce3f40 c01504fc > c1e25548 f7ce3f70 > [ 75.451375]c0157b22 c0579820 f7ce5478 f7d58420 f7d58f00 > > [ 75.481458]c1e25548 f7d58420 f7d58420 f7ce3fa0 c0158539 b7fa1000 > b7fa2000 b7fa1000 > [ 75.512233] Call Trace: > [ 75.536111] [] show_trace_log_lvl+0x1a/0x2f > [ 75.552228] [] show_stack_log_lvl+0x9b/0xaa > [ 75.568329] [] show_registers+0x1e6/0x325 > [ 75.584336] [] die+0x126/0x225 > [ 75.599300] [] do_trap+0x79/0x91 > [ 75.614358] [] do_invalid_op+0x97/0xa1 > [ 75.629892] [] error_code+0x7c/0x84 > [ 75.645097] [] lru_add_drain+0x41/0x8d > [ 75.660599] [] unmap_region+0x2a/0x129 > [ 75.676116] [] do_munmap+0x153/0x1b4 > [ 75.691497] [] sys_munmap+0x25/0x34 > [ 75.706737] [] syscall_call+0x7/0xb That's VM_BUG_ON(PageMlocked(page)); Setting CONFIG_DEBUG_VM=n will shut it up. I don't immediately see why that code isn't racy: the page can remain in the pagevec for arbitrary amounts of time and someone can come along and mlock it again. But given the ease with which you're hitting this, it may not be a race. - 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.20-mm1
On Thu, 15 Feb 2007 05:14:08 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.20-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/ > > Oops plague for me :(. A lot like this: ee1394 usblp evdev CPU:1 EIP:0060:[]Tainted: P VLI EFLAGS: 00010246 (2.6.20-jam01 #1) EIP is at sysfs_lookup+0x5b/0x20a eax: f6707118 ebx: f6b33e5c ecx: f6917d38 edx: 0004 esi: edi: f670717c ebp: f6b33e24 esp: f6997db4 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process udevd (pid: 3899, ti=f6996000 task=f7e34540 task.ti=f6996000) Stack: f66e1800 f6707118 c016da12 f66e1800 f6707118 c02f75c0 f6707118 f6997f04 f6997e38 c0164238 f6997e44 c210d8c0 f6b39340 f6b393b4 f7a7d025 f6997e38 27692f8b f6997f04 c0165a6a f7a7d01d 000200d2 c037ddac 0286 Call Trace: [] d_alloc+0x140/0x198 [] do_lookup+0x128/0x165 [] __link_path_walk+0x7e2/0xc9b [] link_path_walk+0x45/0xbf [] do_path_lookup+0x88/0x1cc [] getname+0x90/0xad [] __user_walk_fd+0x2f/0x47 [] vfs_lstat_fd+0x16/0x3d [] sys_lstat64+0xf/0x23 [] do_page_fault+0x326/0x5e2 [] do_page_fault+0x0/0x5e2 [] sysenter_past_esp+0x5f/0x85 [] wait_for_completion_interruptible+0xdf/0xee === Code: 83 ed 04 8b 45 04 0f 18 00 90 8d 45 04 39 d8 0f 84 bc 00 00 00 f6 45 18 2c 74 e2 89 e8 e8 ed e4 ff ff 89 c6 8b 44 24 10 8b 78 28 ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 be 8b EIP: [] sysfs_lookup+0x5b/0x20a SS:ESP 0068:f6997db4 BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: c01963ff *pde = Oops: [#5] PREEMPT SMP last sysfs file: /devices/pci:00/:00:00.0/resource Modules linked in: nfsd exportfs lockd nfs_acl sunrpc w83627hf hwmon_vid hwmon i2c_isa i2c_i801 i2c_dev microcode snd_intel8x0 snd_ens1371 gameport snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd nvidia(P) loop intel_agp agpgart udf e1000 3c59x ohci1394 ieee1394 usblp evdev CPU:1 EIP:0060:[]Tainted: P VLI EFLAGS: 00010246 (2.6.20-jam01 #1) EIP is at sysfs_follow_link+0x109/0x254 eax: ebx: 0001 ecx: edx: esi: edi: ebp: 0003 esp: f70fdea4 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process udevd (pid: 3900, ti=f70fc000 task=c21f5070 task.ti=f70fc000) Stack: f6917cd8 f70fdedc f670b000 f7321c88 f6917cd8 ffea c02f76a0 f6707aa8 0200 bfa2c2fc c0163e50 b7fc9ff4 f70fc000 f70fdfb8 f7f732f4 c21f5070 f7f732c0 f70fdfb8 c011d757 f6cfbe68 f70fdf44 Call Trace: [] generic_readlink+0x27/0x6e [] timespec_trunc+0x18/0x57 [] current_fs_time+0x4d/0x66 [] touch_atime+0x6e/0xee [] sys_readlinkat+0x61/0x7a [] do_page_fault+0x326/0x5e2 [] sys_readlink+0x27/0x2b [] sysenter_past_esp+0x5f/0x85 [] wait_for_completion_interruptible+0xdf/0xee === Full dmesg at: http://belly.cps.unizar.es/~magallon/oops/oops.txt And another one on reboot. Picture here: http://belly.cps.unizar.es/~magallon/oops/IMG_1448.JPG (sorry, no tripod available ;), just the back of my soft chair). And yes, before nobody says anything, nvidia.ko is loaded. If you really want, I can try without it. -- 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.19-jam07 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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.20-mm1
On Thu, 2007-02-15 at 20:29 +0100, Mattia Dongili wrote:
> On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote:
> [...]
> > - The sony-laptop driver has been disabled due to disagreement between
> > the git-acpi and git-backlight trees
>
> Snigh... I though Richard had something to fix sony-laptop.
>
> Am I wrong?
No, it just didn't make it into -mm. I've included what should be the
fix below.
Fix up the sony-laptop driver in git-acpi to work with the recent
changes in the git-backlight tree.
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
---
drivers/misc/sony-laptop.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Index: linux/drivers/misc/sony-laptop.c
===
--- linux.orig/drivers/misc/sony-laptop.c 2007-02-11 00:59:47.0
+
+++ linux/drivers/misc/sony-laptop.c2007-02-11 01:02:51.0 +
@@ -341,7 +341,7 @@ static void sony_snc_pf_remove(void)
static int sony_backlight_update_status(struct backlight_device *bd)
{
return acpi_callsetfunc(sony_acpi_handle, "SBRT",
- bd->props->brightness + 1, NULL);
+ bd->props.brightness + 1, NULL);
}
static int sony_backlight_get_brightness(struct backlight_device *bd)
@@ -355,11 +355,9 @@ static int sony_backlight_get_brightness
}
static struct backlight_device *sony_backlight_device;
-static struct backlight_properties sony_backlight_properties = {
- .owner = THIS_MODULE,
+static struct backlight_ops sony_backlight_ops = {
.update_status = sony_backlight_update_status,
.get_brightness = sony_backlight_get_brightness,
- .max_brightness = SONY_MAX_BRIGHTNESS - 1,
};
/*
@@ -441,15 +439,17 @@ static int sony_acpi_add(struct acpi_dev
if (ACPI_SUCCESS(acpi_get_handle(sony_acpi_handle, "GBRT", ))) {
sony_backlight_device = backlight_device_register("sony", NULL,
NULL,
-
_backlight_properties);
+
_backlight_ops);
if (IS_ERR(sony_backlight_device)) {
printk(LOG_PFX "unable to register backlight device\n");
sony_backlight_device = NULL;
- } else
- sony_backlight_properties.brightness =
- sony_backlight_get_brightness
- (sony_backlight_device);
+ } else {
+ sony_backlight_device->props.brightness =
+
sony_backlight_get_brightness(sony_backlight_device);
+ sony_backlight_device->props.max_brightness =
+ SONY_MAX_BRIGHTNESS - 1;
+ }
}
if (sony_snc_pf_add())
-
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.20-mm1
On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote: [...] > - The sony-laptop driver has been disabled due to disagreement between > the git-acpi and git-backlight trees Snigh... I though Richard had something to fix sony-laptop. Am I wrong? -- mattia :wq! - 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.20-mm1
On Thu, 2007-02-15 at 19:00 +0100, Marcin Juszkiewicz wrote: > Dnia czwartek, 15 lutego 2007, [EMAIL PROTECTED] napisał: > > On Thu, 15 Feb 2007 05:14:08 PST, Andrew Morton said: > > > git-backlight.patch contains this: > > > > +config BACKLIGHT_PROGEAR > > + tristate "Frontpath ProGear Backlight Driver" > > + depends on BACKLIGHT_CLASS_DEVICE && PCI && X86 > > + default y > > + help > > + If you have a Frontpath ProGear say Y to enable the > > + backlight driver. > > > > Should that be a default N or M, given that relatively few people have > > that device? > > "default n" as this is rather rare used today device. Should I send > a patch or can it be changed without it? Its probably easiest if I just fix that. Cheers, Richard - 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.20-mm1
Dnia czwartek, 15 lutego 2007, [EMAIL PROTECTED] napisał: > On Thu, 15 Feb 2007 05:14:08 PST, Andrew Morton said: > git-backlight.patch contains this: > > +config BACKLIGHT_PROGEAR > + tristate "Frontpath ProGear Backlight Driver" > + depends on BACKLIGHT_CLASS_DEVICE && PCI && X86 > + default y > + help > + If you have a Frontpath ProGear say Y to enable the > + backlight driver. > > Should that be a default N or M, given that relatively few people have > that device? "default n" as this is rather rare used today device. Should I send a patch or can it be changed without it? -- JID: hrw-jabber.org OpenEmbedded developer/consultant Great minds discuss ideas; average minds discuss events; small minds discuss people. - 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.20-mm1
On Thu, 15 Feb 2007 05:14:08 PST, Andrew Morton said: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.20-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/ git-backlight.patch contains this: +config BACKLIGHT_PROGEAR + tristate "Frontpath ProGear Backlight Driver" + depends on BACKLIGHT_CLASS_DEVICE && PCI && X86 + default y + help + If you have a Frontpath ProGear say Y to enable the + backlight driver. Should that be a default N or M, given that relatively few people have that device? pgpxReMTDCCAa.pgp Description: PGP signature
[-mm patch] pci_iomap_regions error handling fix (was Re: 2.6.20-mm1)
On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote:
>
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.20-mm1/
>
Hi,
It appears that the pcim_iomap_regions() function doesn't get the error
handling right. It BUGs early at boot with a backtrace along the lines of:
ahci_init
pci_register_driver
driver_register
[...]
ahci_init_one
pcim_iomap_region
pcim_iounmap
The following patch allows me to boot. Only the if(mask..) continue;
part fixes the problem actually, the gotos where changed so that we
don't try to unmap something we couldn't map anyway.
Regards,
Frederik
Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
diff --git a/lib/devres.c b/lib/devres.c
index 2a668dd..eb38849 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -274,21 +274,21 @@ int pcim_iomap_regions(struct pci_dev *pdev, u16 mask,
const char *name)
rc = pci_request_region(pdev, i, name);
if (rc)
- goto err_region;
+ goto err_inval;
rc = -ENOMEM;
if (!pcim_iomap(pdev, i, 0))
- goto err_iomap;
+ goto err_region;
}
return 0;
- err_iomap:
- pcim_iounmap(pdev, iomap[i]);
err_region:
pci_release_region(pdev, i);
err_inval:
while (--i >= 0) {
+ if (!(mask & (1 << i)))
+ continue;
pcim_iounmap(pdev, iomap[i]);
pci_release_region(pdev, i);
}
-
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.20-mm1
Andrew Morton wrote: - The UBI tree got dropped due to probable lack of a git sync with mainline (ie: it's a 13.5MB diff whcih doesn't apply very well) Andrew, I apologize for this. Now it is fixed. It somehow got screwed when I re-based it from mtd-2.6.git to linu-2.6.git. Please, do not drop it. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) - 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/
sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)
Trying to build 2.6.20-mm1 on i386 with C=1, sparse 0.2 chokes
on arch/i386/kernel/i8253.c:
CHECK arch/i386/kernel/i8253.c
linux/marker.h: No such file or directory
include/linux/jiffies.h:18:5: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:20:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:22:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:24:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:26:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:28:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:30:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:33:3: error: You lose.
include/linux/jiffies.h:225:5: error: bad constant expression
include/asm/module.h:64:2: error: unknown processor family
include/asm/processor.h:82:30: error: undefined identifier
'CONFIG_X86_L1_CACHE_SHIFT'
include/asm/processor.h:82:30: error: bad constant expression type
arch/i386/kernel/i8253.c:120:16: error: Expected ; at end of declaration
arch/i386/kernel/i8253.c:120:16: error: got pit_read
arch/i386/kernel/i8253.c:128:2: error: Trying to use reserved word 'do' as
identifier
arch/i386/kernel/i8253.c:128:2: error: Expected ; at end of declaration
arch/i386/kernel/i8253.c:128:2: error: got {
[loads of similar messages omitted ...]
arch/i386/kernel/i8253.c:195:2: error: undefined identifier 'clocksource_pit'
arch/i386/kernel/i8253.c:196:9: error: undefined identifier
'clocksource_register'
arch/i386/kernel/i8253.c:41:7: error: Expected constant expression in case
statement
arch/i386/kernel/i8253.c:50:7: error: Expected constant expression in case
statement
arch/i386/kernel/i8253.c:51:7: error: Expected constant expression in case
statement
arch/i386/kernel/i8253.c:52:7: error: Expected constant expression in case
statement
/bin/sh: line 1: 18990 Speicherzugriffsfehler
/home/ts/kernel/sparse-0.2/sparse -D__linux__ -Dlinux -D__STDC__ -Dunix
-D__unix__ -Wbitwise -D__i386__ -nostd
inc -isystem /usr/lib/gcc/i586-suse-linux/4.0.2/include
-Wp,-MD,arch/i386/kernel/.i8253.o.d -nostdinc -isystem
/usr/lib/gcc/i586-suse-linux/4.0.2/include -D_
_KERNEL__ -Iinclude -include include/linux/autoconf.h -include linux/marker.h
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-comm
on -Os -pipe -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686
-mtune=pentium3 -ffreestanding -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -I
include/asm-i386/mach-default -fno-omit-frame-pointer
-fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign
-D"KBUILD_STR(s)=#s" -D"
KBUILD_BASENAME=KBUILD_STR(i8253)" -D"KBUILD_MODNAME=KBUILD_STR(i8253)"
arch/i386/kernel/i8253.c
make[1]: *** [arch/i386/kernel/i8253.o] Fehler 139
make: *** [arch/i386/kernel] Fehler 2
gcc compiles it without a single complaint, though.
HTH
--
Tilman SchmidtE-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
signature.asc
Description: OpenPGP digital signature
Re: 2.6.20-mm1
Andrew Morton napisał(a):
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.20-mm1/
>
> Will appear later at
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/
>
>
BUG: sleeping function called from invalid context at
/mnt/md0/devel/linux-mm/mm/slab.c:3043
in_atomic():1, irqs_disabled():0
1 lock held by artsd/3819:
#0: (>lock){--..}, at: [] ipc_lock+0x35/0x4f
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] __might_sleep+0xc9/0xcf
[] kmem_cache_zalloc+0x28/0xe5
[] do_shmat+0x111/0x372
[] sys_ipc+0x148/0x1b5
[] syscall_call+0x7/0xb
===
0xc01d5b7c is in ipc_lock (/mnt/md0/devel/linux-mm/ipc/util.c:684).
679 spin_lock(>lock);
680
681 /* ipc_rmid() may have already freed the ID while ipc_lock
682 * was spinning: here verify that the structure is still valid
683 */
684 if (out->deleted) {
685 spin_unlock(>lock);
686 rcu_read_unlock();
687 return NULL;
688 }
http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-mm1/mm-dmesg
http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-mm1/mm-config
[EMAIL PROTECTED] linux-work3]$ quilt patches mm/slab.c
patches/origin.patch
patches/slab-reduce-size-of-alien-cache-to-cover-only-possible-nodes.patch
patches/slab-use-cpu_lock_.patch
patches/slab-shutdown-cache_reaper-when-cpu-goes-down.patch
[EMAIL PROTECTED] linux-work3]$ quilt patches ipc/util.c
patches/origin.patch
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
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.20-mm1 [kernel BUG at mm/swap.c:442]
On Thu, 15 Feb 2007, James Morris wrote: > Hit a BUG() via lvm: Also, I just disabled paravirt ops and saw the same bug, so it's not that stuff. -- James Morris <[EMAIL PROTECTED]> - 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.20-mm1 [kernel BUG at mm/swap.c:442]
Hit a BUG() via lvm:
Scanning logical volumes
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
Activating logical volumes
[ 75.215078] [ cut here ]
[ 75.230165] kernel BUG at mm/swap.c:442!
[ 75.244589] invalid opcode: [#1]
[ 75.258693] PREEMPT SMP
[ 75.271894] last sysfs file: /block/ram0/dev
[ 75.286734] Modules linked in:
[ 75.300193] CPU:0
[ 75.300195] EIP:0060:[]Not tainted VLI
[ 75.300197] EFLAGS: 00210006 (2.6.20-mm1 #1)
[ 75.341750] EIP is at __pagevec_lru_add_active+0x76/0xcc
[ 75.356722] eax: 80100060 ebx: c1bf9c48 ecx: c1e345bc edx: 0001
[ 75.373139] esi: c03dc680 edi: c1c4e780 ebp: f7ce3f34 esp: f7ce3f24
[ 75.389642] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
[ 75.405199] Process lvm (pid: 415, ti=f7ce2000 task=c1e34070
task.ti=f7ce2000)
[ 75.421908] Stack: c1e25548 f7d58ea0 f7ce3f40 c01504fc
c1e25548 f7ce3f70
[ 75.451375]c0157b22 c0579820 f7ce5478 f7d58420 f7d58f00
[ 75.481458]c1e25548 f7d58420 f7d58420 f7ce3fa0 c0158539 b7fa1000
b7fa2000 b7fa1000
[ 75.512233] Call Trace:
[ 75.536111] [] show_trace_log_lvl+0x1a/0x2f
[ 75.552228] [] show_stack_log_lvl+0x9b/0xaa
[ 75.568329] [] show_registers+0x1e6/0x325
[ 75.584336] [] die+0x126/0x225
[ 75.599300] [] do_trap+0x79/0x91
[ 75.614358] [] do_invalid_op+0x97/0xa1
[ 75.629892] [] error_code+0x7c/0x84
[ 75.645097] [] lru_add_drain+0x41/0x8d
[ 75.660599] [] unmap_region+0x2a/0x129
[ 75.676116] [] do_munmap+0x153/0x1b4
[ 75.691497] [] sys_munmap+0x25/0x34
[ 75.706737] [] syscall_call+0x7/0xb
[ 75.721913] ===
[ 75.736054] Code: 54 80 1a 00 8b 03 a8 20 74 04 0f 0b eb fe f0 0f ba 2b 05
8b 03 a8 40 74 04 0f 0b eb fe f0 0f ba 2b 06 8b 03 a9 00 00 10 00 74 04 <0f> 0b
eb fe 8d 96 a0 05 00 00 8d 43 30 e8 24 eb 08 00 ba 02 00
[ 75.799343] EIP: [] __pagevec_lru_add_active+0x76/0xcc SS:ESP
0068:f7ce3f24
[ 75.831928] note: lvm[415] exited with preempt_count 2
[ 75.849402] BUG: sleeping function called from invalid context at
kernel/rwsem.c:20
[ 75.881617] in_atomic():1, irqs_disabled():1
[ 75.898063] 2 locks held by lvm/415:
[ 75.913388] #0: (>mmap_sem){}, at: []
sys_munmap+0x18/0x34
[ 75.944378] #1: (>lru_lock){}, at: []
__pagevec_lru_add_active+0x4f/0xcc
[ 75.976490] irq event stamp: 69326
[ 75.990962] hardirqs last enabled at (69325): []
syscall_exit_work+0x11/0x30
[ 76.022168] hardirqs last disabled at (69326): []
_spin_lock_irq+0x18/0x51
[ 76.054169] softirqs last enabled at (57904): []
__do_softirq+0xfa/0x100
[ 76.087195] softirqs last disabled at (57889): []
do_softirq+0x4a/0x7a
[ 76.121170] [] show_trace_log_lvl+0x1a/0x2f
[ 76.139835] [] show_trace+0x12/0x14
[ 76.157721] [] dump_stack+0x16/0x18
[ 76.175743] [] __might_sleep+0xe5/0xeb
[ 76.194139] [] down_read+0x18/0x4c
[ 76.212190] [] exit_mm+0x27/0xd1
[ 76.230203] [] do_exit+0x1e1/0x6f6
[ 76.247845] [] die+0x1ff/0x225
[ 76.264934] [] do_trap+0x79/0x91
[ 76.281212] [] do_invalid_op+0x97/0xa1
[ 76.297820] [] error_code+0x7c/0x84
[ 76.313929] [] lru_add_drain+0x41/0x8d
[ 76.330202] [] unmap_region+0x2a/0x129
[ 76.346230] [] do_munmap+0x153/0x1b4
[ 76.361722] [] sys_munmap+0x25/0x34
[ 76.377115] [] syscall_call+0x7/0xb
[ 76.392529] ===
[ 76.406713] BUG: scheduling while atomic: lvm/0x0002/415
[ 76.422805] 2 locks held by lvm/415:
[ 76.436571] #0: (>mmap_sem){}, at: []
sys_munmap+0x18/0x34
[ 76.465007] #1: (>lru_lock){}, at: []
__pagevec_lru_add_active+0x4f/0xcc
[ 76.494996] [] show_trace_log_lvl+0x1a/0x2f
[ 76.510283] [] show_trace+0x12/0x14
[ 76.524538] [] dump_stack+0x16/0x18
[ 76.538603] [] __sched_text_start+0x76/0x98c
[ 76.553174] [] rwsem_down_failed_common+0x16e/0x18d
[ 76.568176] [] rwsem_down_read_failed+0x1d/0x26
[ 76.582508] [] call_rwsem_down_read_failed+0x7/0xc
[ 76.597197] [] exit_mm+0x27/0xd1
[ 76.610369] [] do_exit+0x1e1/0x6f6
[ 76.623618] [] die+0x1ff/0x225
[ 76.636419] [] do_trap+0x79/0x91
[ 76.649413] [] do_invalid_op+0x97/0xa1
[ 76.662859] [] error_code+0x7c/0x84
[ 76.676016] [] lru_add_drain+0x41/0x8d
[ 76.689487] [] unmap_region+0x2a/0x129
[ 76.702979] [] do_munmap+0x153/0x1b4
[ 76.716310] [] sys_munmap+0x25/0x34
[ 76.729566] [] syscall_call+0x7/0xb
[ 76.742688] ===
-
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.20-mm1 [kernel BUG at mm/swap.c:442]
Hit a BUG() via lvm:
Scanning logical volumes
Reading all physical volumes. This may take a while...
Found volume group VolGroup00 using metadata type lvm2
Activating logical volumes
[ 75.215078] [ cut here ]
[ 75.230165] kernel BUG at mm/swap.c:442!
[ 75.244589] invalid opcode: [#1]
[ 75.258693] PREEMPT SMP
[ 75.271894] last sysfs file: /block/ram0/dev
[ 75.286734] Modules linked in:
[ 75.300193] CPU:0
[ 75.300195] EIP:0060:[c0150303]Not tainted VLI
[ 75.300197] EFLAGS: 00210006 (2.6.20-mm1 #1)
[ 75.341750] EIP is at __pagevec_lru_add_active+0x76/0xcc
[ 75.356722] eax: 80100060 ebx: c1bf9c48 ecx: c1e345bc edx: 0001
[ 75.373139] esi: c03dc680 edi: c1c4e780 ebp: f7ce3f34 esp: f7ce3f24
[ 75.389642] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
[ 75.405199] Process lvm (pid: 415, ti=f7ce2000 task=c1e34070
task.ti=f7ce2000)
[ 75.421908] Stack: c1e25548 f7d58ea0 f7ce3f40 c01504fc
c1e25548 f7ce3f70
[ 75.451375]c0157b22 c0579820 f7ce5478 f7d58420 f7d58f00
[ 75.481458]c1e25548 f7d58420 f7d58420 f7ce3fa0 c0158539 b7fa1000
b7fa2000 b7fa1000
[ 75.512233] Call Trace:
[ 75.536111] [c01039ca] show_trace_log_lvl+0x1a/0x2f
[ 75.552228] [c0103a7a] show_stack_log_lvl+0x9b/0xaa
[ 75.568329] [c0103c6f] show_registers+0x1e6/0x325
[ 75.584336] [c0103ed4] die+0x126/0x225
[ 75.599300] [c010404c] do_trap+0x79/0x91
[ 75.614358] [c0104951] do_invalid_op+0x97/0xa1
[ 75.629892] [c02f8a4c] error_code+0x7c/0x84
[ 75.645097] [c01504fc] lru_add_drain+0x41/0x8d
[ 75.660599] [c0157b22] unmap_region+0x2a/0x129
[ 75.676116] [c0158539] do_munmap+0x153/0x1b4
[ 75.691497] [c01585bf] sys_munmap+0x25/0x34
[ 75.706737] [c01029c0] syscall_call+0x7/0xb
[ 75.721913] ===
[ 75.736054] Code: 54 80 1a 00 8b 03 a8 20 74 04 0f 0b eb fe f0 0f ba 2b 05
8b 03 a8 40 74 04 0f 0b eb fe f0 0f ba 2b 06 8b 03 a9 00 00 10 00 74 04 0f 0b
eb fe 8d 96 a0 05 00 00 8d 43 30 e8 24 eb 08 00 ba 02 00
[ 75.799343] EIP: [c0150303] __pagevec_lru_add_active+0x76/0xcc SS:ESP
0068:f7ce3f24
[ 75.831928] note: lvm[415] exited with preempt_count 2
[ 75.849402] BUG: sleeping function called from invalid context at
kernel/rwsem.c:20
[ 75.881617] in_atomic():1, irqs_disabled():1
[ 75.898063] 2 locks held by lvm/415:
[ 75.913388] #0: (mm-mmap_sem){}, at: [c01585b2]
sys_munmap+0x18/0x34
[ 75.944378] #1: (zone-lru_lock){}, at: [c01502dc]
__pagevec_lru_add_active+0x4f/0xcc
[ 75.976490] irq event stamp: 69326
[ 75.990962] hardirqs last enabled at (69325): [c0102b09]
syscall_exit_work+0x11/0x30
[ 76.022168] hardirqs last disabled at (69326): [c02f8348]
_spin_lock_irq+0x18/0x51
[ 76.054169] softirqs last enabled at (57904): [c011ff6f]
__do_softirq+0xfa/0x100
[ 76.087195] softirqs last disabled at (57889): [c011ffbf]
do_softirq+0x4a/0x7a
[ 76.121170] [c01039ca] show_trace_log_lvl+0x1a/0x2f
[ 76.139835] [c01040a5] show_trace+0x12/0x14
[ 76.157721] [c0104157] dump_stack+0x16/0x18
[ 76.175743] [c01155f7] __might_sleep+0xe5/0xeb
[ 76.194139] [c012e9e6] down_read+0x18/0x4c
[ 76.212190] [c011d1e0] exit_mm+0x27/0xd1
[ 76.230203] [c011e4a8] do_exit+0x1e1/0x6f6
[ 76.247845] [c0103fad] die+0x1ff/0x225
[ 76.264934] [c010404c] do_trap+0x79/0x91
[ 76.281212] [c0104951] do_invalid_op+0x97/0xa1
[ 76.297820] [c02f8a4c] error_code+0x7c/0x84
[ 76.313929] [c01504fc] lru_add_drain+0x41/0x8d
[ 76.330202] [c0157b22] unmap_region+0x2a/0x129
[ 76.346230] [c0158539] do_munmap+0x153/0x1b4
[ 76.361722] [c01585bf] sys_munmap+0x25/0x34
[ 76.377115] [c01029c0] syscall_call+0x7/0xb
[ 76.392529] ===
[ 76.406713] BUG: scheduling while atomic: lvm/0x0002/415
[ 76.422805] 2 locks held by lvm/415:
[ 76.436571] #0: (mm-mmap_sem){}, at: [c01585b2]
sys_munmap+0x18/0x34
[ 76.465007] #1: (zone-lru_lock){}, at: [c01502dc]
__pagevec_lru_add_active+0x4f/0xcc
[ 76.494996] [c01039ca] show_trace_log_lvl+0x1a/0x2f
[ 76.510283] [c01040a5] show_trace+0x12/0x14
[ 76.524538] [c0104157] dump_stack+0x16/0x18
[ 76.538603] [c02f5346] __sched_text_start+0x76/0x98c
[ 76.553174] [c01d029f] rwsem_down_failed_common+0x16e/0x18d
[ 76.568176] [c02f7cef] rwsem_down_read_failed+0x1d/0x26
[ 76.582508] [c02f7d73] call_rwsem_down_read_failed+0x7/0xc
[ 76.597197] [c011d1e0] exit_mm+0x27/0xd1
[ 76.610369] [c011e4a8] do_exit+0x1e1/0x6f6
[ 76.623618] [c0103fad] die+0x1ff/0x225
[ 76.636419] [c010404c] do_trap+0x79/0x91
[ 76.649413] [c0104951] do_invalid_op+0x97/0xa1
[ 76.662859] [c02f8a4c] error_code+0x7c/0x84
[ 76.676016] [c01504fc] lru_add_drain+0x41/0x8d
[ 76.689487] [c0157b22] unmap_region+0x2a/0x129
[ 76.702979] [c0158539] do_munmap+0x153/0x1b4
[ 76.716310] [c01585bf] sys_munmap+0x25/0x34
[ 76.729566] [c01029c0] syscall_call+0x7
Re: 2.6.20-mm1 [kernel BUG at mm/swap.c:442]
On Thu, 15 Feb 2007, James Morris wrote: Hit a BUG() via lvm: Also, I just disabled paravirt ops and saw the same bug, so it's not that stuff. -- James Morris [EMAIL PROTECTED] - 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.20-mm1
Andrew Morton napisał(a):
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/
BUG: sleeping function called from invalid context at
/mnt/md0/devel/linux-mm/mm/slab.c:3043
in_atomic():1, irqs_disabled():0
1 lock held by artsd/3819:
#0: (new-lock){--..}, at: [c01d5b7c] ipc_lock+0x35/0x4f
[c0105312] show_trace_log_lvl+0x1a/0x2f
[c0105a25] show_trace+0x12/0x14
[c0105ae7] dump_stack+0x16/0x18
[c011db4a] __might_sleep+0xc9/0xcf
[c017c37a] kmem_cache_zalloc+0x28/0xe5
[c01d8c7d] do_shmat+0x111/0x372
[c0109151] sys_ipc+0x148/0x1b5
[c010432c] syscall_call+0x7/0xb
===
0xc01d5b7c is in ipc_lock (/mnt/md0/devel/linux-mm/ipc/util.c:684).
679 spin_lock(out-lock);
680
681 /* ipc_rmid() may have already freed the ID while ipc_lock
682 * was spinning: here verify that the structure is still valid
683 */
684 if (out-deleted) {
685 spin_unlock(out-lock);
686 rcu_read_unlock();
687 return NULL;
688 }
http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-mm1/mm-dmesg
http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-mm1/mm-config
[EMAIL PROTECTED] linux-work3]$ quilt patches mm/slab.c
patches/origin.patch
patches/slab-reduce-size-of-alien-cache-to-cover-only-possible-nodes.patch
patches/slab-use-cpu_lock_.patch
patches/slab-shutdown-cache_reaper-when-cpu-goes-down.patch
[EMAIL PROTECTED] linux-work3]$ quilt patches ipc/util.c
patches/origin.patch
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
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/
sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)
Trying to build 2.6.20-mm1 on i386 with C=1, sparse 0.2 chokes
on arch/i386/kernel/i8253.c:
CHECK arch/i386/kernel/i8253.c
linux/marker.h: No such file or directory
include/linux/jiffies.h:18:5: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:20:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:22:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:24:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:26:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:28:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:30:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:33:3: error: You lose.
include/linux/jiffies.h:225:5: error: bad constant expression
include/asm/module.h:64:2: error: unknown processor family
include/asm/processor.h:82:30: error: undefined identifier
'CONFIG_X86_L1_CACHE_SHIFT'
include/asm/processor.h:82:30: error: bad constant expression type
arch/i386/kernel/i8253.c:120:16: error: Expected ; at end of declaration
arch/i386/kernel/i8253.c:120:16: error: got pit_read
arch/i386/kernel/i8253.c:128:2: error: Trying to use reserved word 'do' as
identifier
arch/i386/kernel/i8253.c:128:2: error: Expected ; at end of declaration
arch/i386/kernel/i8253.c:128:2: error: got {
[loads of similar messages omitted ...]
arch/i386/kernel/i8253.c:195:2: error: undefined identifier 'clocksource_pit'
arch/i386/kernel/i8253.c:196:9: error: undefined identifier
'clocksource_register'
arch/i386/kernel/i8253.c:41:7: error: Expected constant expression in case
statement
arch/i386/kernel/i8253.c:50:7: error: Expected constant expression in case
statement
arch/i386/kernel/i8253.c:51:7: error: Expected constant expression in case
statement
arch/i386/kernel/i8253.c:52:7: error: Expected constant expression in case
statement
/bin/sh: line 1: 18990 Speicherzugriffsfehler
/home/ts/kernel/sparse-0.2/sparse -D__linux__ -Dlinux -D__STDC__ -Dunix
-D__unix__ -Wbitwise -D__i386__ -nostd
inc -isystem /usr/lib/gcc/i586-suse-linux/4.0.2/include
-Wp,-MD,arch/i386/kernel/.i8253.o.d -nostdinc -isystem
/usr/lib/gcc/i586-suse-linux/4.0.2/include -D_
_KERNEL__ -Iinclude -include include/linux/autoconf.h -include linux/marker.h
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-comm
on -Os -pipe -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686
-mtune=pentium3 -ffreestanding -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -I
include/asm-i386/mach-default -fno-omit-frame-pointer
-fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign
-DKBUILD_STR(s)=#s -D
KBUILD_BASENAME=KBUILD_STR(i8253) -DKBUILD_MODNAME=KBUILD_STR(i8253)
arch/i386/kernel/i8253.c
make[1]: *** [arch/i386/kernel/i8253.o] Fehler 139
make: *** [arch/i386/kernel] Fehler 2
gcc compiles it without a single complaint, though.
HTH
--
Tilman SchmidtE-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
signature.asc
Description: OpenPGP digital signature
Re: 2.6.20-mm1
Andrew Morton wrote: - The UBI tree got dropped due to probable lack of a git sync with mainline (ie: it's a 13.5MB diff whcih doesn't apply very well) Andrew, I apologize for this. Now it is fixed. It somehow got screwed when I re-based it from mtd-2.6.git to linu-2.6.git. Please, do not drop it. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) - 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/
[-mm patch] pci_iomap_regions error handling fix (was Re: 2.6.20-mm1)
On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm1/
Hi,
It appears that the pcim_iomap_regions() function doesn't get the error
handling right. It BUGs early at boot with a backtrace along the lines of:
ahci_init
pci_register_driver
driver_register
[...]
ahci_init_one
pcim_iomap_region
pcim_iounmap
The following patch allows me to boot. Only the if(mask..) continue;
part fixes the problem actually, the gotos where changed so that we
don't try to unmap something we couldn't map anyway.
Regards,
Frederik
Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]
diff --git a/lib/devres.c b/lib/devres.c
index 2a668dd..eb38849 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -274,21 +274,21 @@ int pcim_iomap_regions(struct pci_dev *pdev, u16 mask,
const char *name)
rc = pci_request_region(pdev, i, name);
if (rc)
- goto err_region;
+ goto err_inval;
rc = -ENOMEM;
if (!pcim_iomap(pdev, i, 0))
- goto err_iomap;
+ goto err_region;
}
return 0;
- err_iomap:
- pcim_iounmap(pdev, iomap[i]);
err_region:
pci_release_region(pdev, i);
err_inval:
while (--i = 0) {
+ if (!(mask (1 i)))
+ continue;
pcim_iounmap(pdev, iomap[i]);
pci_release_region(pdev, i);
}
-
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.20-mm1
On Thu, 15 Feb 2007 05:14:08 PST, Andrew Morton said: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/ git-backlight.patch contains this: +config BACKLIGHT_PROGEAR + tristate Frontpath ProGear Backlight Driver + depends on BACKLIGHT_CLASS_DEVICE PCI X86 + default y + help + If you have a Frontpath ProGear say Y to enable the + backlight driver. Should that be a default N or M, given that relatively few people have that device? pgpxReMTDCCAa.pgp Description: PGP signature
Re: 2.6.20-mm1
Dnia czwartek, 15 lutego 2007, [EMAIL PROTECTED] napisał: On Thu, 15 Feb 2007 05:14:08 PST, Andrew Morton said: git-backlight.patch contains this: +config BACKLIGHT_PROGEAR + tristate Frontpath ProGear Backlight Driver + depends on BACKLIGHT_CLASS_DEVICE PCI X86 + default y + help + If you have a Frontpath ProGear say Y to enable the + backlight driver. Should that be a default N or M, given that relatively few people have that device? default n as this is rather rare used today device. Should I send a patch or can it be changed without it? -- JID: hrw-jabber.org OpenEmbedded developer/consultant Great minds discuss ideas; average minds discuss events; small minds discuss people. - 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.20-mm1
On Thu, 2007-02-15 at 19:00 +0100, Marcin Juszkiewicz wrote: Dnia czwartek, 15 lutego 2007, [EMAIL PROTECTED] napisał: On Thu, 15 Feb 2007 05:14:08 PST, Andrew Morton said: git-backlight.patch contains this: +config BACKLIGHT_PROGEAR + tristate Frontpath ProGear Backlight Driver + depends on BACKLIGHT_CLASS_DEVICE PCI X86 + default y + help + If you have a Frontpath ProGear say Y to enable the + backlight driver. Should that be a default N or M, given that relatively few people have that device? default n as this is rather rare used today device. Should I send a patch or can it be changed without it? Its probably easiest if I just fix that. Cheers, Richard - 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.20-mm1
On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote: [...] - The sony-laptop driver has been disabled due to disagreement between the git-acpi and git-backlight trees Snigh... I though Richard had something to fix sony-laptop. Am I wrong? -- mattia :wq! - 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.20-mm1
On Thu, 2007-02-15 at 20:29 +0100, Mattia Dongili wrote:
On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote:
[...]
- The sony-laptop driver has been disabled due to disagreement between
the git-acpi and git-backlight trees
Snigh... I though Richard had something to fix sony-laptop.
Am I wrong?
No, it just didn't make it into -mm. I've included what should be the
fix below.
Fix up the sony-laptop driver in git-acpi to work with the recent
changes in the git-backlight tree.
Signed-off-by: Richard Purdie [EMAIL PROTECTED]
---
drivers/misc/sony-laptop.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Index: linux/drivers/misc/sony-laptop.c
===
--- linux.orig/drivers/misc/sony-laptop.c 2007-02-11 00:59:47.0
+
+++ linux/drivers/misc/sony-laptop.c2007-02-11 01:02:51.0 +
@@ -341,7 +341,7 @@ static void sony_snc_pf_remove(void)
static int sony_backlight_update_status(struct backlight_device *bd)
{
return acpi_callsetfunc(sony_acpi_handle, SBRT,
- bd-props-brightness + 1, NULL);
+ bd-props.brightness + 1, NULL);
}
static int sony_backlight_get_brightness(struct backlight_device *bd)
@@ -355,11 +355,9 @@ static int sony_backlight_get_brightness
}
static struct backlight_device *sony_backlight_device;
-static struct backlight_properties sony_backlight_properties = {
- .owner = THIS_MODULE,
+static struct backlight_ops sony_backlight_ops = {
.update_status = sony_backlight_update_status,
.get_brightness = sony_backlight_get_brightness,
- .max_brightness = SONY_MAX_BRIGHTNESS - 1,
};
/*
@@ -441,15 +439,17 @@ static int sony_acpi_add(struct acpi_dev
if (ACPI_SUCCESS(acpi_get_handle(sony_acpi_handle, GBRT, handle))) {
sony_backlight_device = backlight_device_register(sony, NULL,
NULL,
-
sony_backlight_properties);
+
sony_backlight_ops);
if (IS_ERR(sony_backlight_device)) {
printk(LOG_PFX unable to register backlight device\n);
sony_backlight_device = NULL;
- } else
- sony_backlight_properties.brightness =
- sony_backlight_get_brightness
- (sony_backlight_device);
+ } else {
+ sony_backlight_device-props.brightness =
+
sony_backlight_get_brightness(sony_backlight_device);
+ sony_backlight_device-props.max_brightness =
+ SONY_MAX_BRIGHTNESS - 1;
+ }
}
if (sony_snc_pf_add())
-
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.20-mm1
On Thu, 15 Feb 2007 05:14:08 -0800, Andrew Morton [EMAIL PROTECTED] wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/ Oops plague for me :(. A lot like this: ee1394 usblp evdev CPU:1 EIP:0060:[c0195f12]Tainted: P VLI EFLAGS: 00010246 (2.6.20-jam01 #1) EIP is at sysfs_lookup+0x5b/0x20a eax: f6707118 ebx: f6b33e5c ecx: f6917d38 edx: 0004 esi: edi: f670717c ebp: f6b33e24 esp: f6997db4 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process udevd (pid: 3899, ti=f6996000 task=f7e34540 task.ti=f6996000) Stack: f66e1800 f6707118 c016da12 f66e1800 f6707118 c02f75c0 f6707118 f6997f04 f6997e38 c0164238 f6997e44 c210d8c0 f6b39340 f6b393b4 f7a7d025 f6997e38 27692f8b f6997f04 c0165a6a f7a7d01d 000200d2 c037ddac 0286 Call Trace: [c016da12] d_alloc+0x140/0x198 [c0164238] do_lookup+0x128/0x165 [c0165a6a] __link_path_walk+0x7e2/0xc9b [c0165f68] link_path_walk+0x45/0xbf [c01661b6] do_path_lookup+0x88/0x1cc [c0165125] getname+0x90/0xad [c0166aa4] __user_walk_fd+0x2f/0x47 [c01607c4] vfs_lstat_fd+0x16/0x3d [c0160830] sys_lstat64+0xf/0x23 [c0111904] do_page_fault+0x326/0x5e2 [c01115de] do_page_fault+0x0/0x5e2 [c010288e] sysenter_past_esp+0x5f/0x85 [c02f] wait_for_completion_interruptible+0xdf/0xee === Code: 83 ed 04 8b 45 04 0f 18 00 90 8d 45 04 39 d8 0f 84 bc 00 00 00 f6 45 18 2c 74 e2 89 e8 e8 ed e4 ff ff 89 c6 8b 44 24 10 8b 78 28 ac ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 be 8b EIP: [c0195f12] sysfs_lookup+0x5b/0x20a SS:ESP 0068:f6997db4 BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: c01963ff *pde = Oops: [#5] PREEMPT SMP last sysfs file: /devices/pci:00/:00:00.0/resource Modules linked in: nfsd exportfs lockd nfs_acl sunrpc w83627hf hwmon_vid hwmon i2c_isa i2c_i801 i2c_dev microcode snd_intel8x0 snd_ens1371 gameport snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd nvidia(P) loop intel_agp agpgart udf e1000 3c59x ohci1394 ieee1394 usblp evdev CPU:1 EIP:0060:[c01963ff]Tainted: P VLI EFLAGS: 00010246 (2.6.20-jam01 #1) EIP is at sysfs_follow_link+0x109/0x254 eax: ebx: 0001 ecx: edx: esi: edi: ebp: 0003 esp: f70fdea4 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process udevd (pid: 3900, ti=f70fc000 task=c21f5070 task.ti=f70fc000) Stack: f6917cd8 f70fdedc f670b000 f7321c88 f6917cd8 ffea c02f76a0 f6707aa8 0200 bfa2c2fc c0163e50 b7fc9ff4 f70fc000 f70fdfb8 f7f732f4 c21f5070 f7f732c0 f70fdfb8 c011d757 f6cfbe68 f70fdf44 Call Trace: [c0163e50] generic_readlink+0x27/0x6e [c011d757] timespec_trunc+0x18/0x57 [c011dd47] current_fs_time+0x4d/0x66 [c016f990] touch_atime+0x6e/0xee [c016076a] sys_readlinkat+0x61/0x7a [c0111904] do_page_fault+0x326/0x5e2 [c01607aa] sys_readlink+0x27/0x2b [c010288e] sysenter_past_esp+0x5f/0x85 [c02f] wait_for_completion_interruptible+0xdf/0xee === Full dmesg at: http://belly.cps.unizar.es/~magallon/oops/oops.txt And another one on reboot. Picture here: http://belly.cps.unizar.es/~magallon/oops/IMG_1448.JPG (sorry, no tripod available ;), just the back of my soft chair). And yes, before nobody says anything, nvidia.ko is loaded. If you really want, I can try without it. -- 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.19-jam07 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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.20-mm1 [kernel BUG at mm/swap.c:442]
On Thu, 15 Feb 2007 09:28:23 -0500 (EST) James Morris [EMAIL PROTECTED] wrote: Hit a BUG() via lvm: Scanning logical volumes Reading all physical volumes. This may take a while... Found volume group VolGroup00 using metadata type lvm2 Activating logical volumes [ 75.215078] [ cut here ] [ 75.230165] kernel BUG at mm/swap.c:442! [ 75.244589] invalid opcode: [#1] [ 75.258693] PREEMPT SMP [ 75.271894] last sysfs file: /block/ram0/dev [ 75.286734] Modules linked in: [ 75.300193] CPU:0 [ 75.300195] EIP:0060:[c0150303]Not tainted VLI [ 75.300197] EFLAGS: 00210006 (2.6.20-mm1 #1) [ 75.341750] EIP is at __pagevec_lru_add_active+0x76/0xcc [ 75.356722] eax: 80100060 ebx: c1bf9c48 ecx: c1e345bc edx: 0001 [ 75.373139] esi: c03dc680 edi: c1c4e780 ebp: f7ce3f34 esp: f7ce3f24 [ 75.389642] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 75.405199] Process lvm (pid: 415, ti=f7ce2000 task=c1e34070 task.ti=f7ce2000) [ 75.421908] Stack: c1e25548 f7d58ea0 f7ce3f40 c01504fc c1e25548 f7ce3f70 [ 75.451375]c0157b22 c0579820 f7ce5478 f7d58420 f7d58f00 [ 75.481458]c1e25548 f7d58420 f7d58420 f7ce3fa0 c0158539 b7fa1000 b7fa2000 b7fa1000 [ 75.512233] Call Trace: [ 75.536111] [c01039ca] show_trace_log_lvl+0x1a/0x2f [ 75.552228] [c0103a7a] show_stack_log_lvl+0x9b/0xaa [ 75.568329] [c0103c6f] show_registers+0x1e6/0x325 [ 75.584336] [c0103ed4] die+0x126/0x225 [ 75.599300] [c010404c] do_trap+0x79/0x91 [ 75.614358] [c0104951] do_invalid_op+0x97/0xa1 [ 75.629892] [c02f8a4c] error_code+0x7c/0x84 [ 75.645097] [c01504fc] lru_add_drain+0x41/0x8d [ 75.660599] [c0157b22] unmap_region+0x2a/0x129 [ 75.676116] [c0158539] do_munmap+0x153/0x1b4 [ 75.691497] [c01585bf] sys_munmap+0x25/0x34 [ 75.706737] [c01029c0] syscall_call+0x7/0xb That's VM_BUG_ON(PageMlocked(page)); Setting CONFIG_DEBUG_VM=n will shut it up. I don't immediately see why that code isn't racy: the page can remain in the pagevec for arbitrary amounts of time and someone can come along and mlock it again. But given the ease with which you're hitting this, it may not be a race. - 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.20-mm1
On Thu, 15 Feb 2007 15:37:20 +0100
Michal Piotrowski [EMAIL PROTECTED] wrote:
Andrew Morton napisa__(a):
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/
BUG: sleeping function called from invalid context at
/mnt/md0/devel/linux-mm/mm/slab.c:3043
in_atomic():1, irqs_disabled():0
1 lock held by artsd/3819:
#0: (new-lock){--..}, at: [c01d5b7c] ipc_lock+0x35/0x4f
[c0105312] show_trace_log_lvl+0x1a/0x2f
[c0105a25] show_trace+0x12/0x14
[c0105ae7] dump_stack+0x16/0x18
[c011db4a] __might_sleep+0xc9/0xcf
[c017c37a] kmem_cache_zalloc+0x28/0xe5
[c01d8c7d] do_shmat+0x111/0x372
[c0109151] sys_ipc+0x148/0x1b5
[c010432c] syscall_call+0x7/0xb
That's shm-make-sysv-ipc-shared-memory-use-stacked-files.patch, brought to
us by Eric-who-hasnt-read-Documentation/SubmitChecklist.
Like this, I guess:
diff -puN ipc/shm.c~shm-make-sysv-ipc-shared-memory-use-stacked-files-fix
ipc/shm.c
--- a/ipc/shm.c~shm-make-sysv-ipc-shared-memory-use-stacked-files-fix
+++ a/ipc/shm.c
@@ -818,7 +818,7 @@ long do_shmat(int shmid, char __user *sh
int acc_mode;
void *user_addr;
struct ipc_namespace *ns;
- struct shm_file_data *sfd;
+ struct shm_file_data *sfd = NULL;
mode_t f_mode;
if (shmid 0) {
@@ -856,6 +856,8 @@ long do_shmat(int shmid, char __user *sh
acc_mode |= S_IXUGO;
}
+ sfd = kzalloc(sizeof(*sfd), GFP_KERNEL);
+
/*
* We cannot rely on the fs check since SYSV IPC does have an
* additional creator id...
@@ -879,13 +881,12 @@ long do_shmat(int shmid, char __user *sh
goto out_unlock;
err = -ENOMEM;
- sfd = kzalloc(sizeof(*sfd), GFP_KERNEL);
if (!sfd)
goto out_unlock;
file = get_empty_filp();
if (!file)
- goto out_free;
+ goto out_unlock;
file-f_op = shm_file_operations;
file-private_data = sfd;
@@ -939,9 +940,8 @@ invalid:
if (IS_ERR(user_addr))
err = PTR_ERR(user_addr);
out:
- return err;
-out_free:
kfree(sfd);
+ return err;
out_unlock:
shm_unlock(shp);
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.20-mm1
Andrew Morton [EMAIL PROTECTED] writes: That's shm-make-sysv-ipc-shared-memory-use-stacked-files.patch, brought to us by Eric-who-hasnt-read-Documentation/SubmitChecklist. Sorry I thought I had all of the interesting debugging enabled in my kernel build. It must of fallen out someplace. I think I must have figured shm_lock was a semaphore or mutex. Like this, I guess: Nope. get_empty_filp can sleep as well, unless I'm totally mistaken. It looks like the logic change is going to be a little more than a one liner. I will get back to you in a couple of hours Eric - 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.20-mm1 [kernel BUG at mm/swap.c:442]
On Thu, 15 Feb 2007, Andrew Morton wrote: I don't immediately see why that code isn't racy: the page can remain in the pagevec for arbitrary amounts of time and someone can come along and mlock it again. But given the ease with which you're hitting this, it may not be a race. As long as the page is on the pagevec it should be off the LRU. Marking a page PageMlocked requires the page to be on the LRU. So a page cannot be marked PageMlocked as long as it is on the regular pagevecs. Somehow a page off the LRU was marked PageMlocked. Or a new anonymous page was allocated and marked PageMlocked and then some later processing put it onto the LRU? Maybe try_to_set_mlocked does work some havoc here. Could you see if this patch fixes it? This just disabled an optimization to set PageMlocked early. Index: linux-2.6.20-mm1/mm/memory.c === --- linux-2.6.20-mm1.orig/mm/memory.c 2007-02-15 14:35:41.0 -0800 +++ linux-2.6.20-mm1/mm/memory.c2007-02-15 14:35:54.0 -0800 @@ -930,6 +930,8 @@ static void try_to_set_mlocked(struct pa struct zone *zone; unsigned long flags; + return; + if (!PageLRU(page) || PageMlocked(page)) return; - 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: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)
On Thu, 15 Feb 2007 17:01:27 +0100
Tilman Schmidt [EMAIL PROTECTED] wrote:
Trying to build 2.6.20-mm1 on i386 with C=1, sparse 0.2 chokes
on arch/i386/kernel/i8253.c:
CHECK arch/i386/kernel/i8253.c
linux/marker.h: No such file or directory
include/linux/jiffies.h:18:5: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:20:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:22:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:24:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:26:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:28:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:30:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:33:3: error: You lose.
include/linux/jiffies.h:225:5: error: bad constant expression
include/asm/module.h:64:2: error: unknown processor family
include/asm/processor.h:82:30: error: undefined identifier
'CONFIG_X86_L1_CACHE_SHIFT'
include/asm/processor.h:82:30: error: bad constant expression type
arch/i386/kernel/i8253.c:120:16: error: Expected ; at end of declaration
arch/i386/kernel/i8253.c:120:16: error: got pit_read
arch/i386/kernel/i8253.c:128:2: error: Trying to use reserved word 'do' as
identifier
arch/i386/kernel/i8253.c:128:2: error: Expected ; at end of declaration
arch/i386/kernel/i8253.c:128:2: error: got {
[loads of similar messages omitted ...]
arch/i386/kernel/i8253.c:195:2: error: undefined identifier 'clocksource_pit'
arch/i386/kernel/i8253.c:196:9: error: undefined identifier
'clocksource_register'
arch/i386/kernel/i8253.c:41:7: error: Expected constant expression in case
statement
arch/i386/kernel/i8253.c:50:7: error: Expected constant expression in case
statement
Me too. It's due to the linux-kernel-markers patches. Mathieu, can you
take a look please?
-
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.20-mm1
On Thursday 15 February 2007 14:14, Andrew Morton wrote: - The IDE tree got dropped due to various linkage problems Doh, I guess this is what one gets for not testing modular IDE driver support properly. :( All linkage problems should be fixed now, sorry for that. Bart - 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: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)
* Andrew Morton ([EMAIL PROTECTED]) wrote:
On Thu, 15 Feb 2007 17:01:27 +0100
Tilman Schmidt [EMAIL PROTECTED] wrote:
Trying to build 2.6.20-mm1 on i386 with C=1, sparse 0.2 chokes
on arch/i386/kernel/i8253.c:
CHECK arch/i386/kernel/i8253.c
linux/marker.h: No such file or directory
include/linux/jiffies.h:18:5: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:20:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:22:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:24:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:26:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:28:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:30:7: warning: undefined preprocessor identifier
'CONFIG_HZ'
include/linux/jiffies.h:33:3: error: You lose.
include/linux/jiffies.h:225:5: error: bad constant expression
include/asm/module.h:64:2: error: unknown processor family
include/asm/processor.h:82:30: error: undefined identifier
'CONFIG_X86_L1_CACHE_SHIFT'
include/asm/processor.h:82:30: error: bad constant expression type
arch/i386/kernel/i8253.c:120:16: error: Expected ; at end of declaration
arch/i386/kernel/i8253.c:120:16: error: got pit_read
arch/i386/kernel/i8253.c:128:2: error: Trying to use reserved word 'do' as
identifier
arch/i386/kernel/i8253.c:128:2: error: Expected ; at end of declaration
arch/i386/kernel/i8253.c:128:2: error: got {
[loads of similar messages omitted ...]
arch/i386/kernel/i8253.c:195:2: error: undefined identifier
'clocksource_pit'
arch/i386/kernel/i8253.c:196:9: error: undefined identifier
'clocksource_register'
arch/i386/kernel/i8253.c:41:7: error: Expected constant expression in case
statement
arch/i386/kernel/i8253.c:50:7: error: Expected constant expression in case
statement
Me too. It's due to the linux-kernel-markers patches. Mathieu, can you
take a look please?
I will give a deeper look in sparse, but I should say up front that I
add this to the root build tree Makefile :
LINUXINCLUDE:= -Iinclude \
$(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
-include include/linux/autoconf.h \
-include linux/marker.h
I guess sparse is maybe not using this Makefile or variable ?
--
Mathieu Desnoyers
Computer Engineering Ph.D. Candidate, École Polytechnique de Montréal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
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.20-mm1
Andrew Morton napisał(a):
On Thu, 15 Feb 2007 15:37:20 +0100
Michal Piotrowski [EMAIL PROTECTED] wrote:
Andrew Morton napisa__(a):
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/
BUG: sleeping function called from invalid context at
/mnt/md0/devel/linux-mm/mm/slab.c:3043
in_atomic():1, irqs_disabled():0
1 lock held by artsd/3819:
#0: (new-lock){--..}, at: [c01d5b7c] ipc_lock+0x35/0x4f
[c0105312] show_trace_log_lvl+0x1a/0x2f
[c0105a25] show_trace+0x12/0x14
[c0105ae7] dump_stack+0x16/0x18
[c011db4a] __might_sleep+0xc9/0xcf
[c017c37a] kmem_cache_zalloc+0x28/0xe5
[c01d8c7d] do_shmat+0x111/0x372
[c0109151] sys_ipc+0x148/0x1b5
[c010432c] syscall_call+0x7/0xb
That's shm-make-sysv-ipc-shared-memory-use-stacked-files.patch, brought to
us by Eric-who-hasnt-read-Documentation/SubmitChecklist.
Like this, I guess:
diff -puN ipc/shm.c~shm-make-sysv-ipc-shared-memory-use-stacked-files-fix
ipc/shm.c
I might be drunk...
This patch still doesn't solve the problem.
BUG: sleeping function called from invalid context at
/mnt/md0/devel/linux-mm/mm/slab.c:3043
in_atomic():1, irqs_disabled():0
1 lock held by Xorg/2885:
#0: (new-lock){--..}, at: [c01d5b7c] ipc_lock+0x35/0x4f
[c0105312] show_trace_log_lvl+0x1a/0x2f
[c0105a25] show_trace+0x12/0x14
[c0105ae7] dump_stack+0x16/0x18
[c011db4a] __might_sleep+0xc9/0xcf
[c017c45f] kmem_cache_alloc+0x28/0xbf
[c01814c3] get_empty_filp+0x6a/0x173
[c01d8ca2] do_shmat+0x136/0x390
[c0109151] sys_ipc+0x148/0x1b5
[c010432c] syscall_call+0x7/0xb
===
BUG: MAX_LOCK_DEPTH too low!
turning off the locking correctness validator.
do_IRQ: stack overflow: -52
[c0105312] show_trace_log_lvl+0x1a/0x2f
[c0105a25] show_trace+0x12/0x14
[c0105ae7] dump_stack+0x16/0x18
[c0106cc0] do_IRQ+0x95/0xc1
BUG: unable to handle kernel paging request at virtual address 0e200034
printing eip:
c01052e2
*pde =
Oops: [#1]
PREEMPT SMP
last sysfs file:
/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/vendor
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd
nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT
nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter
ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss evdev snd_mixer_oss
snd_pcm snd_timer skge snd 8139too intel_agp sk98lin agpgart soundcore mii
i2c_i801 snd_page_alloc ide_cd cdrom rtc unix
CPU:0
EIP:0060:[c01052e2]Not tainted VLI
EFLAGS: 00013046 (2.6.20-mm1 #16)
EIP is at dump_trace+0x88/0x9e
eax: ebx: f412c01c ecx: c0429344 edx: c03cf8fa
BUG: unable to handle kernel paging request at virtual address 8d17ca6c
printing eip:
c011d927
*pde =
esi: 0e20 edi: c03daed2 ebp: f412bfd0 esp: f412bfc0
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process Xorg (pid: 2885, ti=f412a000 task=f4a58aa0 task.ti=f412c000)
Stack: c7422ac0 c03daed2 0011 f412bfe4 c0105312 c0429344 c03daed2
0004 f412bff0 c0105a25 c03daed2 f412bffc c0105ae7 f412c008 f412c01c
Call Trace:
[c0105312] show_trace_log_lvl+0x1a/0x2f
[c01053c4] show_stack_log_lvl+0x9d/0xac
[c01055c0] show_registers+0x1ed/0x34c
[c010583c] die+0x11d/0x234
[c011b8d1] do_page_fault+0x47c/0x55b
[c033aaac] error_code+0x7c/0x84
[c0105312] show_trace_log_lvl+0x1a/0x2f
[c0105a25] show_trace+0x12/0x14
[c0105ae7] dump_stack+0x16/0x18
[c0106cc0] do_IRQ+0x95/0xc1
BUG: unable to handle kernel paging request at virtual address 0e200034
printing eip:
c01052e2
*pde =
Oops: [#2]
PREEMPT SMP
last sysfs file:
/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/vendor
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd
nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT
nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter
ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss evdev snd_mixer_oss
snd_pcm snd_timer skge snd 8139too intel_agp sk98lin agpgart soundcore mii
i2c_i801 snd_page_alloc ide_cd cdrom rtc unix
CPU:0
EIP:0060:[c01052e2]Not tainted VLI
EFLAGS: 00013046 (2.6.20-mm1 #16)
EIP is at dump_trace+0x88/0x9e
eax: ebx: f412c01c ecx: c0429344 edx: c03cf8fa
esi: 0e20 edi: c03cfa80 ebp: f412be5c esp: f412be4c
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process Xorg (pid: 2885, ti=f412a000 task=f4a58aa0 task.ti=f412c000)
Stack: f412be64 c03cfa80 0010 f412be70 c0105312 c0429344 c03cfa80
f412c003 f412be94 c01053c4 c03cfa80 c03cfa80 f412bf88 f412bfc0
Re: 2.6.20-mm1
On Thu, 15 Feb 2007 22:30:17 +0100 J.A. Magall__n [EMAIL PROTECTED] wrote: On Thu, 15 Feb 2007 05:14:08 -0800, Andrew Morton [EMAIL PROTECTED] wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/ Oops plague for me :(. A lot like this: ee1394 usblp evdev CPU:1 EIP:0060:[c0195f12]Tainted: P VLI EFLAGS: 00010246 (2.6.20-jam01 #1) EIP is at sysfs_lookup+0x5b/0x20a eax: f6707118 ebx: f6b33e5c ecx: f6917d38 edx: 0004 esi: edi: f670717c ebp: f6b33e24 esp: f6997db4 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process udevd (pid: 3899, ti=f6996000 task=f7e34540 task.ti=f6996000) Stack: f66e1800 f6707118 c016da12 f66e1800 f6707118 c02f75c0 f6707118 f6997f04 f6997e38 c0164238 f6997e44 c210d8c0 f6b39340 f6b393b4 f7a7d025 f6997e38 27692f8b f6997f04 c0165a6a f7a7d01d 000200d2 c037ddac 0286 Call Trace: [c016da12] d_alloc+0x140/0x198 [c0164238] do_lookup+0x128/0x165 [c0165a6a] __link_path_walk+0x7e2/0xc9b [c0165f68] link_path_walk+0x45/0xbf [c01661b6] do_path_lookup+0x88/0x1cc [c0165125] getname+0x90/0xad [c0166aa4] __user_walk_fd+0x2f/0x47 [c01607c4] vfs_lstat_fd+0x16/0x3d [c0160830] sys_lstat64+0xf/0x23 [c0111904] do_page_fault+0x326/0x5e2 [c01115de] do_page_fault+0x0/0x5e2 [c010288e] sysenter_past_esp+0x5f/0x85 [c02f] wait_for_completion_interruptible+0xdf/0xee Oh dear. Any one of about 700 developers might have caused this. bisection-search will find this. Can you upload the .config please? Full dmesg at: http://belly.cps.unizar.es/~magallon/oops/oops.txt And another one on reboot. Picture here: http://belly.cps.unizar.es/~magallon/oops/IMG_1448.JPG (sorry, no tripod available ;), just the back of my soft chair). And yes, before nobody says anything, nvidia.ko is loaded. If you really want, I can try without it. It would be appreciated if you could do that, 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.20-mm1
On Thu, 15 Feb 2007 15:31:42 -0800, Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 15 Feb 2007 22:30:17 +0100 J.A. Magall__n [EMAIL PROTECTED] wrote: On Thu, 15 Feb 2007 05:14:08 -0800, Andrew Morton [EMAIL PROTECTED] wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/ Oops plague for me :(. A lot like this: ee1394 usblp evdev CPU:1 EIP:0060:[c0195f12]Tainted: P VLI EFLAGS: 00010246 (2.6.20-jam01 #1) EIP is at sysfs_lookup+0x5b/0x20a eax: f6707118 ebx: f6b33e5c ecx: f6917d38 edx: 0004 esi: edi: f670717c ebp: f6b33e24 esp: f6997db4 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process udevd (pid: 3899, ti=f6996000 task=f7e34540 task.ti=f6996000) Stack: f66e1800 f6707118 c016da12 f66e1800 f6707118 c02f75c0 f6707118 f6997f04 f6997e38 c0164238 f6997e44 c210d8c0 f6b39340 f6b393b4 f7a7d025 f6997e38 27692f8b f6997f04 c0165a6a f7a7d01d 000200d2 c037ddac 0286 Call Trace: [c016da12] d_alloc+0x140/0x198 [c0164238] do_lookup+0x128/0x165 [c0165a6a] __link_path_walk+0x7e2/0xc9b [c0165f68] link_path_walk+0x45/0xbf [c01661b6] do_path_lookup+0x88/0x1cc [c0165125] getname+0x90/0xad [c0166aa4] __user_walk_fd+0x2f/0x47 [c01607c4] vfs_lstat_fd+0x16/0x3d [c0160830] sys_lstat64+0xf/0x23 [c0111904] do_page_fault+0x326/0x5e2 [c01115de] do_page_fault+0x0/0x5e2 [c010288e] sysenter_past_esp+0x5f/0x85 [c02f] wait_for_completion_interruptible+0xdf/0xee Oh dear. Any one of about 700 developers might have caused this. bisection-search will find this. Can you upload the .config please? Here it goes: http://belly.cps.unizar.es/~magallon/oops/config-2.6.20-jam01 copied from previous and answered missing CONFIG_'s. Just 2.6.20-m11 + 11-pci-iomap-regions posted in LKML + patch to make HDIO_OBSOLETE_IDENTITY work on sata (also from LKML). Full dmesg at: http://belly.cps.unizar.es/~magallon/oops/oops.txt And another one on reboot. Picture here: http://belly.cps.unizar.es/~magallon/oops/IMG_1448.JPG (sorry, no tripod available ;), just the back of my soft chair). And yes, before nobody says anything, nvidia.ko is loaded. If you really want, I can try without it. It would be appreciated if you could do that, thanks. Probably tomorrow. -- 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.19-jam07 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)
On Thu, 15 Feb 2007 17:46:56 -0500 Mathieu Desnoyers [EMAIL PROTECTED] wrote: Me too. It's due to the linux-kernel-markers patches. Mathieu, can you take a look please? I will give a deeper look in sparse, but I should say up front that I add this to the root build tree Makefile : LINUXINCLUDE:= -Iinclude \ $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \ -include include/linux/autoconf.h \ -include linux/marker.h I guess sparse is maybe not using this Makefile or variable ? ow, that's going to hurt - this stuff is complex and fragile. For what reason was that change made? Pleeze, tricky things like this should be changelogged - we shouldn't need to ask. I missed it. - 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: [-mm patch] pci_iomap_regions error handling fix (was Re: 2.6.20-mm1)
On Fri, 16 Feb 2007 16:41:59 +
Frederik Deweerdt [EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm1/
Hi,
It appears that the pcim_iomap_regions() function doesn't get the error
handling right. It BUGs early at boot with a backtrace along the lines of:
ahci_init
pci_register_driver
driver_register
[...]
ahci_init_one
pcim_iomap_region
pcim_iounmap
The following patch allows me to boot. Only the if(mask..) continue;
part fixes the problem actually, the gotos where changed so that we
don't try to unmap something we couldn't map anyway.
Regards,
Frederik
Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]
diff --git a/lib/devres.c b/lib/devres.c
index 2a668dd..eb38849 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -274,21 +274,21 @@ int pcim_iomap_regions(struct pci_dev *pdev, u16 mask,
const char *name)
rc = pci_request_region(pdev, i, name);
if (rc)
- goto err_region;
+ goto err_inval;
rc = -ENOMEM;
if (!pcim_iomap(pdev, i, 0))
- goto err_iomap;
+ goto err_region;
}
return 0;
- err_iomap:
- pcim_iounmap(pdev, iomap[i]);
err_region:
pci_release_region(pdev, i);
err_inval:
while (--i = 0) {
+ if (!(mask (1 i)))
+ continue;
pcim_iounmap(pdev, iomap[i]);
pci_release_region(pdev, i);
}
yep, the fix looks good and is needed in mainline, 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.20-mm1
On Fri, 16 Feb 2007 00:24:35 +0100
Michal Piotrowski [EMAIL PROTECTED] wrote:
Andrew Morton napisa__(a):
On Thu, 15 Feb 2007 15:37:20 +0100
Michal Piotrowski [EMAIL PROTECTED] wrote:
Andrew Morton napisa__(a):
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/
BUG: sleeping function called from invalid context at
/mnt/md0/devel/linux-mm/mm/slab.c:3043
in_atomic():1, irqs_disabled():0
1 lock held by artsd/3819:
#0: (new-lock){--..}, at: [c01d5b7c] ipc_lock+0x35/0x4f
[c0105312] show_trace_log_lvl+0x1a/0x2f
[c0105a25] show_trace+0x12/0x14
[c0105ae7] dump_stack+0x16/0x18
[c011db4a] __might_sleep+0xc9/0xcf
[c017c37a] kmem_cache_zalloc+0x28/0xe5
[c01d8c7d] do_shmat+0x111/0x372
[c0109151] sys_ipc+0x148/0x1b5
[c010432c] syscall_call+0x7/0xb
That's shm-make-sysv-ipc-shared-memory-use-stacked-files.patch, brought to
us by Eric-who-hasnt-read-Documentation/SubmitChecklist.
Like this, I guess:
diff -puN ipc/shm.c~shm-make-sysv-ipc-shared-memory-use-stacked-files-fix
ipc/shm.c
I might be drunk...
This patch still doesn't solve the problem.
BUG: sleeping function called from invalid context at
/mnt/md0/devel/linux-mm/mm/slab.c:3043
in_atomic():1, irqs_disabled():0
1 lock held by Xorg/2885:
#0: (new-lock){--..}, at: [c01d5b7c] ipc_lock+0x35/0x4f
[c0105312] show_trace_log_lvl+0x1a/0x2f
[c0105a25] show_trace+0x12/0x14
[c0105ae7] dump_stack+0x16/0x18
[c011db4a] __might_sleep+0xc9/0xcf
[c017c45f] kmem_cache_alloc+0x28/0xbf
[c01814c3] get_empty_filp+0x6a/0x173
[c01d8ca2] do_shmat+0x136/0x390
[c0109151] sys_ipc+0x148/0x1b5
[c010432c] syscall_call+0x7/0xb
yes, that's the other one, which Eric will be looking at.
===
BUG: MAX_LOCK_DEPTH too low!
turning off the locking correctness validator.
do_IRQ: stack overflow: -52
[c0105312] show_trace_log_lvl+0x1a/0x2f
[c0105a25] show_trace+0x12/0x14
[c0105ae7] dump_stack+0x16/0x18
[c0106cc0] do_IRQ+0x95/0xc1
BUG: unable to handle kernel paging request at virtual address 0e200034
printing eip:
c01052e2
*pde =
Oops: [#1]
PREEMPT SMP
last sysfs file:
/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/vendor
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd
nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT
nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter
ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss evdev snd_mixer_oss
snd_pcm snd_timer skge snd 8139too intel_agp sk98lin agpgart soundcore mii
i2c_i801 snd_page_alloc ide_cd cdrom rtc unix
CPU:0
EIP:0060:[c01052e2]Not tainted VLI
EFLAGS: 00013046 (2.6.20-mm1 #16)
EIP is at dump_trace+0x88/0x9e
eax: ebx: f412c01c ecx: c0429344 edx: c03cf8fa
BUG: unable to handle kernel paging request at virtual address 8d17ca6c
printing eip:
c011d927
*pde =
esi: 0e20 edi: c03daed2 ebp: f412bfd0 esp: f412bfc0
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process Xorg (pid: 2885, ti=f412a000 task=f4a58aa0 task.ti=f412c000)
Stack: c7422ac0 c03daed2 0011 f412bfe4 c0105312 c0429344 c03daed2
0004 f412bff0 c0105a25 c03daed2 f412bffc c0105ae7 f412c008 f412c01c
Call Trace:
[c0105312] show_trace_log_lvl+0x1a/0x2f
[c01053c4] show_stack_log_lvl+0x9d/0xac
[c01055c0] show_registers+0x1ed/0x34c
[c010583c] die+0x11d/0x234
[c011b8d1] do_page_fault+0x47c/0x55b
[c033aaac] error_code+0x7c/0x84
[c0105312] show_trace_log_lvl+0x1a/0x2f
[c0105a25] show_trace+0x12/0x14
[c0105ae7] dump_stack+0x16/0x18
[c0106cc0] do_IRQ+0x95/0xc1
BUG: unable to handle kernel paging request at virtual address 0e200034
ooh, we broke lockdep.
-
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: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)
* Andrew Morton ([EMAIL PROTECTED]) wrote: On Thu, 15 Feb 2007 17:46:56 -0500 Mathieu Desnoyers [EMAIL PROTECTED] wrote: Me too. It's due to the linux-kernel-markers patches. Mathieu, can you take a look please? I will give a deeper look in sparse, but I should say up front that I add this to the root build tree Makefile : LINUXINCLUDE:= -Iinclude \ $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \ -include include/linux/autoconf.h \ -include linux/marker.h I guess sparse is maybe not using this Makefile or variable ? ow, that's going to hurt - this stuff is complex and fragile. Sorry, I will remember to do more explicit changelogs. For what reason was that change made? It was made so that we can use the markers in C code without actually including marker.h everywhere. I am sure someone has a better way to do it : I would be happy to use this-nice-build-system-feature-I-missed to have marker.h included. Pleeze, tricky things like this should be changelogged - we shouldn't need to ask. I missed it. -- Mathieu Desnoyers Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)
On Thu, 15 Feb 2007 19:37:39 -0500 Mathieu Desnoyers [EMAIL PROTECTED] wrote: For what reason was that change made? It was made so that we can use the markers in C code without actually including marker.h everywhere. I am sure someone has a better way to do it : I would be happy to use this-nice-build-system-feature-I-missed to have marker.h included. Oh. One could whack it in kernel.h: pretty much everything includes that. But it'd be better to simply require that the clients of this infrastructure include the appropriate header file. We do that for everything else and markers aren't special in this regard. - 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/
