[SATA] sata-via : bug?
I have a brand new Western Digital sata drive, VIA KT600 based ECS motherboard on which I am trying to install various distros (with installers based on 2.4.26, 2.6.7, 2.6.8, 2.6.11 etc) all of them fail to detect the HD (and bomb out) because sata-via is ignoring it . I have only one disk, I am not interested in raid. lspci which tells me it is VIA 6420 and should be supported based on sata-via.c. Following are syslog snippets that show more. I would appreciate your help in resolving this. Thanks, Jay ## 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: a000-afff Memory behind bridge: e000-e1ff Prefetchable memory behind bridge: d800-dfff Capabilities: [80] Power Management version 2 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) Subsystem: Elitegroup Computer Systems: Unknown device 1884 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at b000 [size=8] I/O ports at b400 [size=4] I/O ports at b800 [size=8] I/O ports at bc00 [size=4] I/O ports at c000 [size=16] I/O ports at c400 [size=256] Capabilities: [c0] Power Management version 2 ##Dmesg when I connect the disk on channel 1 libata version 1.10 loaded. sata_via version 1.1 ACPI: PCI interrupt :00:0f.0[B] -> GSI 11 (level, low) -> IRQ 11 sata_via(:00:0f.0): routed to hard irq line 11 ata1: SATA max UDMA/133 cmd 0xB000 ctl 0xB402 bmdma 0xC000 irq 11 ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xBC02 bmdma 0xC008 irq 11 ata1: dev 0 cfg 49:3030 82:0078 83:0078 84: 85: 86:3fff 87:0010 88:000f ata1: no dma/lba ata1: dev 0 not supported, ignoring scsi0 : sata_via ata2: no device found (phy stat ) scsi1 : sata_via ##with disk on second channel following ata1: no device found (phy stat ) scsi0 : sata_via ata2: dev 0 cfg 49:3030 82:0078 83:0078 84:0078 85: 86: 87: 88: ata2: no dma/lba ata2: dev 0 not supported, ignoring scsi1 : sata_via ## I took this disk and sata cable on a different (ICH5 based) motherboard and ## knoppix detected the disk ok and associated sda with 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/
[SATA] sata-via : bug?
I have a brand new Western Digital sata drive, VIA KT600 based ECS motherboard on which I am trying to install various distros (with installers based on 2.4.26, 2.6.7, 2.6.8, 2.6.11 etc) all of them fail to detect the HD (and bomb out) because sata-via is ignoring it . I have only one disk, I am not interested in raid. lspci which tells me it is VIA 6420 and should be supported based on sata-via.c. Following are syslog snippets that show more. I would appreciate your help in resolving this. Thanks, Jay ## 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: a000-afff Memory behind bridge: e000-e1ff Prefetchable memory behind bridge: d800-dfff Capabilities: [80] Power Management version 2 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) Subsystem: Elitegroup Computer Systems: Unknown device 1884 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at b000 [size=8] I/O ports at b400 [size=4] I/O ports at b800 [size=8] I/O ports at bc00 [size=4] I/O ports at c000 [size=16] I/O ports at c400 [size=256] Capabilities: [c0] Power Management version 2 ##Dmesg when I connect the disk on channel 1 libata version 1.10 loaded. sata_via version 1.1 ACPI: PCI interrupt :00:0f.0[B] - GSI 11 (level, low) - IRQ 11 sata_via(:00:0f.0): routed to hard irq line 11 ata1: SATA max UDMA/133 cmd 0xB000 ctl 0xB402 bmdma 0xC000 irq 11 ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xBC02 bmdma 0xC008 irq 11 ata1: dev 0 cfg 49:3030 82:0078 83:0078 84: 85: 86:3fff 87:0010 88:000f ata1: no dma/lba ata1: dev 0 not supported, ignoring scsi0 : sata_via ata2: no device found (phy stat ) scsi1 : sata_via ##with disk on second channel following ata1: no device found (phy stat ) scsi0 : sata_via ata2: dev 0 cfg 49:3030 82:0078 83:0078 84:0078 85: 86: 87: 88: ata2: no dma/lba ata2: dev 0 not supported, ignoring scsi1 : sata_via ## I took this disk and sata cable on a different (ICH5 based) motherboard and ## knoppix detected the disk ok and associated sda with 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/
SATA VIA8237 Problems (Install)
I have a KT600 based motherboard & I am planning to set up my new system using
that. It has onboard via 8237 sata {raid, cough cough} controller. I am
planning to use a single sata disk (I am not interested in raid). The
various distro installers are having tough time noticing a brand new western
digital disk. Following is the dmesg from the installer :
##
libata version 1.10 loaded.
sata_via version 1.1
ACPI: PCI interrupt :00:0f.0[B] -> GSI 11 (level, low) -> IRQ 11
sata_via(:00:0f.0): routed to hard irq line 11
ata1: SATA max UDMA/133 cmd 0xB000 ctl 0xB402 bmdma 0xC000 irq 11
ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xBC02 bmdma 0xC008 irq 11
ata1: dev 0 cfg 49:3030 82:0078 83:0078 84: 85: 86:3fff 87:0010
88:000f
ata1: no dma/lba
ata1: dev 0 not supported, ignoring
scsi0 : sata_via
ata2: no device found (phy stat )
scsi1 : sata_via
###
Is the line "ata1: dev 0 not supported, ignoring" expected?Is there
something basic I am missing. I would appreciate any help.
I have tried to digest info on Jeff Garzik's linux.yyz.us/sata/ and also
www.linuxmafia.com/faq/Hardware/sata.html but its quite possible I might
have misinterpreted it. FWIW, the installer is 2.6.11-1 based and
following modules are present in the system. Thanks,
Jay
odule Size Used byNot tainted
parport_pc 28805 0 - Live 0xd0a1c000
parport 39689 1 parport_pc, Live 0xd09d5000
dm_snapshot 17797 0 - Live 0xd097a000
dm_mirror 25389 0 - Live 0xd0998000
dm_zero 2497 0 - Live 0xd081b000
dm_mod 61013 3 dm_snapshot,dm_mirror,dm_zero, Live 0xd0a25000
xfs 586897 0 - Live 0xd0c0f000
exportfs 8513 1 xfs, Live 0xd0902000
jfs 203897 0 - Live 0xd0ae9000
reiserfs 267317 0 - Live 0xd0aa6000
ext3 133065 0 - Live 0xd0a39000
jbd 79065 1 ext3, Live 0xd09fc000
msdos 8641 0 - Live 0xd0906000
raid6 107345 0 - Live 0xd09e
raid5 28737 0 - Live 0xd098f000
xor 15305 2 raid6,raid5, Live 0xd0939000
raid1 21441 0 - Live 0xd08ab000
raid0 8513 0 - Live 0xd08fe000
sata_via 8389 0 - Live 0xd08d
libata 47429 1 sata_via, Live 0xd0982000
via_rhine 27209 0 - Live 0xd0931000
mii 4929 1 via_rhine, Live 0xd0894000
uhci_hcd 33497 0 - Live 0xd090a000
ehci_hcd 39245 0 - Live 0xd0926000
sr_mod 19173 0 - Live 0xd08ca000
sd_mod 19137 0 - Live 0xd08b2000
scsi_mod 138665 3 libata,sr_mod,sd_mod, Live 0xd09a
edd 9889 0 - Live 0xd089
floppy 63729 0 - Live 0xd0915000
-
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/
SATA VIA8237 Problems (Install)
I have a KT600 based motherboard I am planning to set up my new system using
that. It has onboard via 8237 sata {raid, cough cough} controller. I am
planning to use a single sata disk (I am not interested in raid). The
various distro installers are having tough time noticing a brand new western
digital disk. Following is the dmesg from the installer :
##
libata version 1.10 loaded.
sata_via version 1.1
ACPI: PCI interrupt :00:0f.0[B] - GSI 11 (level, low) - IRQ 11
sata_via(:00:0f.0): routed to hard irq line 11
ata1: SATA max UDMA/133 cmd 0xB000 ctl 0xB402 bmdma 0xC000 irq 11
ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xBC02 bmdma 0xC008 irq 11
ata1: dev 0 cfg 49:3030 82:0078 83:0078 84: 85: 86:3fff 87:0010
88:000f
ata1: no dma/lba
ata1: dev 0 not supported, ignoring
scsi0 : sata_via
ata2: no device found (phy stat )
scsi1 : sata_via
###
Is the line ata1: dev 0 not supported, ignoring expected?Is there
something basic I am missing. I would appreciate any help.
I have tried to digest info on Jeff Garzik's linux.yyz.us/sata/ and also
www.linuxmafia.com/faq/Hardware/sata.html but its quite possible I might
have misinterpreted it. FWIW, the installer is 2.6.11-1 based and
following modules are present in the system. Thanks,
Jay
odule Size Used byNot tainted
parport_pc 28805 0 - Live 0xd0a1c000
parport 39689 1 parport_pc, Live 0xd09d5000
dm_snapshot 17797 0 - Live 0xd097a000
dm_mirror 25389 0 - Live 0xd0998000
dm_zero 2497 0 - Live 0xd081b000
dm_mod 61013 3 dm_snapshot,dm_mirror,dm_zero, Live 0xd0a25000
xfs 586897 0 - Live 0xd0c0f000
exportfs 8513 1 xfs, Live 0xd0902000
jfs 203897 0 - Live 0xd0ae9000
reiserfs 267317 0 - Live 0xd0aa6000
ext3 133065 0 - Live 0xd0a39000
jbd 79065 1 ext3, Live 0xd09fc000
msdos 8641 0 - Live 0xd0906000
raid6 107345 0 - Live 0xd09e
raid5 28737 0 - Live 0xd098f000
xor 15305 2 raid6,raid5, Live 0xd0939000
raid1 21441 0 - Live 0xd08ab000
raid0 8513 0 - Live 0xd08fe000
sata_via 8389 0 - Live 0xd08d
libata 47429 1 sata_via, Live 0xd0982000
via_rhine 27209 0 - Live 0xd0931000
mii 4929 1 via_rhine, Live 0xd0894000
uhci_hcd 33497 0 - Live 0xd090a000
ehci_hcd 39245 0 - Live 0xd0926000
sr_mod 19173 0 - Live 0xd08ca000
sd_mod 19137 0 - Live 0xd08b2000
scsi_mod 138665 3 libata,sr_mod,sd_mod, Live 0xd09a
edd 9889 0 - Live 0xd089
floppy 63729 0 - Live 0xd0915000
-
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/
Bad page state at prep_new_page
I have been getting this error off and on with vendor kernel 2.6.8, I have
posted about it on lkml 3/4 times before. Actually I had offered to provide a
summary of similar reports from the web with no takers, I can still provide
that to somebody if it is useful.
I had run memtest overnight with no errors, I use DRM etc.. The reason to
post this is that very first line in the syslog entries related to this
error seems to be different than before. {It is typically is kernel BUG at
mm/rmap.c or sth similar}. Thanks,
Jay
P.S. I am getting this error once in 3 days on an average (based on grep of
moths worth syslog) so I might have dubious distinction of being more
repeatable. May be it confirms Hugh's suspicion of hardware misbehaving but
I am not ready to accept it yet :-)
Feb 26 09:37:03 localhost kernel: mm/memory.c:110: bad pmd 0500.
Feb 26 09:39:58 localhost kernel: Bad page state at prep_new_page (in process
'X', page c12678e0)
Feb 26 09:39:58 localhost kernel: flags:0x2004 mapping:f700 mapcount:0
count:0
Feb 26 09:39:58 localhost kernel: Backtrace:
Feb 26 09:39:58 localhost kernel: [dump_stack+30/32] dump_stack+0x1e/0x20
Feb 26 09:39:58 localhost kernel: [] dump_stack+0x1e/0x20
Feb 26 09:39:58 localhost kernel: [bad_page+108/160] bad_page+0x6c/0xa0
Feb 26 09:39:58 localhost kernel: [] bad_page+0x6c/0xa0
Feb 26 09:39:58 localhost kernel: [prep_new_page+40/112]
prep_new_page+0x28/0x70
Feb 26 09:39:58 localhost kernel: [] prep_new_page+0x28/0x70
Feb 26 09:39:58 localhost kernel: [buffered_rmqueue+216/384]
buffered_rmqueue+0xd8/0x180
Feb 26 09:39:58 localhost kernel: [] buffered_rmqueue+0xd8/0x180
Feb 26 09:39:58 localhost kernel: [__alloc_pages+161/752]
__alloc_pages+0xa1/0x2f0
Feb 26 09:39:58 localhost kernel: [] __alloc_pages+0xa1/0x2f0
Feb 26 09:39:58 localhost kernel: [do_anonymous_page+102/368]
do_anonymous_page+0x66/0x170
Feb 26 09:39:58 localhost kernel: [] do_anonymous_page+0x66/0x170
Feb 26 09:39:58 localhost kernel: [do_no_page+95/816] do_no_page+0x5f/0x330
Feb 26 09:39:58 localhost kernel: [] do_no_page+0x5f/0x330
Feb 26 09:39:58 localhost kernel: [handle_mm_fault+341/416]
handle_mm_fault+0x155/0x1a0
Feb 26 09:39:58 localhost kernel: [] handle_mm_fault+0x155/0x1a0
Feb 26 09:39:58 localhost kernel: [do_page_fault+396/1456]
do_page_fault+0x18c/0x5b0
Feb 26 09:39:58 localhost kernel: [] do_page_fault+0x18c/0x5b0
Feb 26 09:39:58 localhost kernel: [error_code+45/56] error_code+0x2d/0x38
Feb 26 09:39:58 localhost kernel: [] error_code+0x2d/0x38
Feb 26 09:39:58 localhost kernel: Trying to fix it up, but a reboot is needed
-
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/
Bad page state at prep_new_page
I have been getting this error off and on with vendor kernel 2.6.8, I have
posted about it on lkml 3/4 times before. Actually I had offered to provide a
summary of similar reports from the web with no takers, I can still provide
that to somebody if it is useful.
I had run memtest overnight with no errors, I use DRM etc.. The reason to
post this is that very first line in the syslog entries related to this
error seems to be different than before. {It is typically is kernel BUG at
mm/rmap.c or sth similar}. Thanks,
Jay
P.S. I am getting this error once in 3 days on an average (based on grep of
moths worth syslog) so I might have dubious distinction of being more
repeatable. May be it confirms Hugh's suspicion of hardware misbehaving but
I am not ready to accept it yet :-)
Feb 26 09:37:03 localhost kernel: mm/memory.c:110: bad pmd 0500.
Feb 26 09:39:58 localhost kernel: Bad page state at prep_new_page (in process
'X', page c12678e0)
Feb 26 09:39:58 localhost kernel: flags:0x2004 mapping:f700 mapcount:0
count:0
Feb 26 09:39:58 localhost kernel: Backtrace:
Feb 26 09:39:58 localhost kernel: [dump_stack+30/32] dump_stack+0x1e/0x20
Feb 26 09:39:58 localhost kernel: [c0107bfe] dump_stack+0x1e/0x20
Feb 26 09:39:58 localhost kernel: [bad_page+108/160] bad_page+0x6c/0xa0
Feb 26 09:39:58 localhost kernel: [c013d63c] bad_page+0x6c/0xa0
Feb 26 09:39:58 localhost kernel: [prep_new_page+40/112]
prep_new_page+0x28/0x70
Feb 26 09:39:58 localhost kernel: [c013d968] prep_new_page+0x28/0x70
Feb 26 09:39:58 localhost kernel: [buffered_rmqueue+216/384]
buffered_rmqueue+0xd8/0x180
Feb 26 09:39:58 localhost kernel: [c013de58] buffered_rmqueue+0xd8/0x180
Feb 26 09:39:58 localhost kernel: [__alloc_pages+161/752]
__alloc_pages+0xa1/0x2f0
Feb 26 09:39:58 localhost kernel: [c013dfa1] __alloc_pages+0xa1/0x2f0
Feb 26 09:39:58 localhost kernel: [do_anonymous_page+102/368]
do_anonymous_page+0x66/0x170
Feb 26 09:39:58 localhost kernel: [c0148796] do_anonymous_page+0x66/0x170
Feb 26 09:39:58 localhost kernel: [do_no_page+95/816] do_no_page+0x5f/0x330
Feb 26 09:39:58 localhost kernel: [c01488ff] do_no_page+0x5f/0x330
Feb 26 09:39:58 localhost kernel: [handle_mm_fault+341/416]
handle_mm_fault+0x155/0x1a0
Feb 26 09:39:58 localhost kernel: [c0148e15] handle_mm_fault+0x155/0x1a0
Feb 26 09:39:58 localhost kernel: [do_page_fault+396/1456]
do_page_fault+0x18c/0x5b0
Feb 26 09:39:58 localhost kernel: [c01198ec] do_page_fault+0x18c/0x5b0
Feb 26 09:39:58 localhost kernel: [error_code+45/56] error_code+0x2d/0x38
Feb 26 09:39:58 localhost kernel: [c0107849] error_code+0x2d/0x38
Feb 26 09:39:58 localhost kernel: Trying to fix it up, but a reboot is needed
-
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/
Executive Summary: Bad page state at prep_new_page
This might or might not be useful to anybody but I googled with the above error and tried to track down how many of these errors had actually been resolved. [It is possible that people don't come back to summarize once the problem is resolved]. I only tracked once that did not get reported on lkml. And I tried to drill down to get as much info as I can. there were 12 in total that I tracked down starting 04/04/04 till 01/26/05 None had a good resolution reported 4 out of 12 had extensive memtest runs without any errors. 12/12 were for 2.6.7-rc3 onwards. 4/12 had mapping all zeroes [rest did not report or had non-zero mapping] I might be barking up the wrong tree here without much knowledge, but I have a summary gnumeric spreadsheet [which I won't even think of attaching here] if it is going to be useful to anyone I would be glad to email personally. It also has html links to the original reports. Thanks, Jay - 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/
Executive Summary: Bad page state at prep_new_page
This might or might not be useful to anybody but I googled with the above error and tried to track down how many of these errors had actually been resolved. [It is possible that people don't come back to summarize once the problem is resolved]. I only tracked once that did not get reported on lkml. And I tried to drill down to get as much info as I can. there were 12 in total that I tracked down starting 04/04/04 till 01/26/05 None had a good resolution reported 4 out of 12 had extensive memtest runs without any errors. 12/12 were for 2.6.7-rc3 onwards. 4/12 had mapping all zeroes [rest did not report or had non-zero mapping] I might be barking up the wrong tree here without much knowledge, but I have a summary gnumeric spreadsheet [which I won't even think of attaching here] if it is going to be useful to anyone I would be glad to email personally. It also has html links to the original reports. Thanks, Jay - 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: Kernel bug: mm/rmap.c:483 and related {now 2.6.8}
>Thanks for giving that a thorough run, memory seems exonerated... yet I
>don't trust this machine at all: have you tried manufacturer diagnostics?
Ouch, that hurts. This is a machine I built myself over three years ago. Ran
very stably with 2.4.*. may be it is the age of the machine. The recent
hardware changes are additions of a dvd writer, a hdd and a pci wireless
card. Which seem to work ok until recently. What other diagnostics would
make sense?
>> Jan 29 08:25:02 Bad page state at prep_new_page ('X', page c1251ae0)
>> Jan 29 08:25:02 flags:0x2004 mapping:6a00 mapcount:0 count:0
>Again, something I've not seen reported before: mapping:6a00, when
>mapping should be NULL (or at least a pointer into kernel memory). You
>say message reappeared twice with identical addresses: was that mapping
>the same each time?
Hmm, it is different one time, as shown below.. I guess should have looked
carefully. Although it means nothing to me.. FWIW, please note that in all
these cases ndiswrapper (windows driver loader) is being used. Thanks, Jay
Jan 29 08:27:03 localhost kernel: Bad page state at prep_new_page (in process
'X', page c1253a60)
Jan 29 08:27:03 localhost kernel: flags:0x2004 mapping:6a00 mapcount:0
count:0
Jan 29 08:27:08 localhost kernel: Bad page state at prep_new_page (in process
'X', page c12965e0)
Jan 29 08:27:08 localhost kernel: flags:0x2004 mapping:6600 mapcount:0
count:0
-
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: Kernel bug: mm/rmap.c:483 and related {now 2.6.8}
Thanks for giving that a thorough run, memory seems exonerated... yet I
don't trust this machine at all: have you tried manufacturer diagnostics?
Ouch, that hurts. This is a machine I built myself over three years ago. Ran
very stably with 2.4.*. may be it is the age of the machine. The recent
hardware changes are additions of a dvd writer, a hdd and a pci wireless
card. Which seem to work ok until recently. What other diagnostics would
make sense?
Jan 29 08:25:02 Bad page state at prep_new_page ('X', page c1251ae0)
Jan 29 08:25:02 flags:0x2004 mapping:6a00 mapcount:0 count:0
Again, something I've not seen reported before: mapping:6a00, when
mapping should be NULL (or at least a pointer into kernel memory). You
say message reappeared twice with identical addresses: was that mapping
the same each time?
Hmm, it is different one time, as shown below.. I guess should have looked
carefully. Although it means nothing to me.. FWIW, please note that in all
these cases ndiswrapper (windows driver loader) is being used. Thanks, Jay
Jan 29 08:27:03 localhost kernel: Bad page state at prep_new_page (in process
'X', page c1253a60)
Jan 29 08:27:03 localhost kernel: flags:0x2004 mapping:6a00 mapcount:0
count:0
Jan 29 08:27:08 localhost kernel: Bad page state at prep_new_page (in process
'X', page c12965e0)
Jan 29 08:27:08 localhost kernel: flags:0x2004 mapping:6600 mapcount:0
count:0
-
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: Kernel bug: mm/rmap.c:483
I am not sure this is a fixed problem in 2.6.11-rc2 based on my read of the changelog, hence this email. Here is the summary: 1. I started with vanilla 2.6.10 where I replaced ieee1394 drivers from trunk rev 1251 patched in. My kernel is tainted due to ndiswrapper that loads windows drivers for my wireless PCI card. One out of 4 times I actually booted 2.6.10 and manually brought up wlan0 I got 'reboot needed etc messages' . Please note that using similar approach in 2.6.8 does not cause this issue. Following is the error in /var/log/messages ( I did not paste everything to be brief): Jan 22 08:26:58 localhost kernel: Bad page state at prep_new_page (in process 'net_applet', page c1323a00) Jan 22 08:26:58 localhost kernel: flags:0x2004 mapping: mapcount:1 count:1 Jan 22 08:26:58 localhost kernel: Backtrace: Jan 22 08:26:58 localhost kernel: [dump_stack+30/32] dump_stack+0x1e/0x20 Jan 22 08:26:58 localhost kernel: [] dump_stack+0x1e/0x20 Jan 22 08:26:58 localhost kernel: [bad_page+117/176] bad_page+0x75/0xb0 Jan 22 08:26:58 localhost kernel: [] bad_page+0x75/0xb0 Jan 22 08:26:58 localhost kernel: [prep_new_page+40/112] prep_new_page+0x28/0x70 Jan 22 08:26:58 localhost kernel: [] prep_new_page+0x28/0x70 # Jan 22 08:26:58 localhost kernel: [ cut here ] Jan 22 08:26:58 localhost kernel: kernel BUG at mm/rmap.c:483! Jan 22 08:26:58 localhost kernel: invalid operand: [#1] Jan 22 08:26:58 localhost kernel: Modules linked in: mga md5 ipv6 snd_pcm_oss snd_mixer_oss snd_via82xx snd_ac97_codec snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore af_packet fealnx mii eth1394 ide_cd cdrom ohci1394 ieee1394 loop ntfs nls_iso8859_1 nls_cp437 vfat fat ndiswrapper via_agp agpgart uhci_hcd usbcore genrtc ext3 jbd Jan 22 08:26:58 localhost kernel: CPU:0 Jan 22 08:26:58 localhost kernel: EIP:0060:[page_remove_rmap+53/64] Tainted: PB VLI Jan 22 08:26:58 localhost kernel: EIP:0060:[]Tainted: PB VLI Jan 22 08:26:58 localhost kernel: EFLAGS: 00010286 (2.6.10jry) Jan 22 08:26:58 localhost kernel: EIP is at page_remove_rmap+0x35/0x40 Jan 22 08:26:58 localhost kernel: eax: ebx: 00389000 ecx: c0399d54 edx: c1323a00 Jan 22 08:26:58 localhost kernel: esi: d3b06f44 edi: 003b8000 ebp: d39ebd2c esp: d39ebd2c Jan 22 08:26:58 localhost kernel: ds: 007b es: 007b ss: 0068 Jan 22 08:26:58 localhost kernel: Process net_applet (pid: 9326, threadinfo=d39ea000 task=d6a8d060) Jan 22 08:26:58 localhost kernel: Stack: d39ebd58 c0145a67 c1323a00 c0139256 dffccabc d5a1af08 191d0045 c1323a00 Jan 22 08:26:58 localhost kernel:08848000 d3b5b088 0880 d39ebd88 c0145c10 c0399d54 d3b5b084 08448000 2. I patched in Hugh's patch to 2.6.10 and recompiled. At reboot I ran memtest86 v 1.26, 3 times without any error. Then rebooting in 2.6.10 and doing ifup wlan0 gave me system freeze and unfortunately nothing in the log. Since then I have not seen the same error again after 3 reboots and 2-3 cold boots followed by ifup. I also tried cycles of ifdown and ifup without any errors. 3. I am not sure if I should post my whole config here hence I just pasting DRM related entries here in reference to your original email to Jose`. I have VIA motherboard and a matrox agp card, [FWIW most of the config is same as for 2.6.8 kernel that did not show the rmap sympton] CONFIG_AGP_VIA=m CONFIG_DRM=y CONFIG_DRM_MGA=m I will be glad to provide any other info needed. You may bcc to my email if this is better discussed off the list. [Although I will anxiously check lkml.org everyday or use RSS feed]. I am not subsribed as We are not worthy :-) Thanks, Jay - 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: Kernel bug: mm/rmap.c:483
I am not sure this is a fixed problem in 2.6.11-rc2 based on my read of the changelog, hence this email. Here is the summary: 1. I started with vanilla 2.6.10 where I replaced ieee1394 drivers from trunk rev 1251 patched in. My kernel is tainted due to ndiswrapper that loads windows drivers for my wireless PCI card. One out of 4 times I actually booted 2.6.10 and manually brought up wlan0 I got 'reboot needed etc messages' . Please note that using similar approach in 2.6.8 does not cause this issue. Following is the error in /var/log/messages ( I did not paste everything to be brief): Jan 22 08:26:58 localhost kernel: Bad page state at prep_new_page (in process 'net_applet', page c1323a00) Jan 22 08:26:58 localhost kernel: flags:0x2004 mapping: mapcount:1 count:1 Jan 22 08:26:58 localhost kernel: Backtrace: Jan 22 08:26:58 localhost kernel: [dump_stack+30/32] dump_stack+0x1e/0x20 Jan 22 08:26:58 localhost kernel: [c0103cde] dump_stack+0x1e/0x20 Jan 22 08:26:58 localhost kernel: [bad_page+117/176] bad_page+0x75/0xb0 Jan 22 08:26:58 localhost kernel: [c013c1b5] bad_page+0x75/0xb0 Jan 22 08:26:58 localhost kernel: [prep_new_page+40/112] prep_new_page+0x28/0x70 Jan 22 08:26:58 localhost kernel: [c013c4d8] prep_new_page+0x28/0x70 # Jan 22 08:26:58 localhost kernel: [ cut here ] Jan 22 08:26:58 localhost kernel: kernel BUG at mm/rmap.c:483! Jan 22 08:26:58 localhost kernel: invalid operand: [#1] Jan 22 08:26:58 localhost kernel: Modules linked in: mga md5 ipv6 snd_pcm_oss snd_mixer_oss snd_via82xx snd_ac97_codec snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore af_packet fealnx mii eth1394 ide_cd cdrom ohci1394 ieee1394 loop ntfs nls_iso8859_1 nls_cp437 vfat fat ndiswrapper via_agp agpgart uhci_hcd usbcore genrtc ext3 jbd Jan 22 08:26:58 localhost kernel: CPU:0 Jan 22 08:26:58 localhost kernel: EIP:0060:[page_remove_rmap+53/64] Tainted: PB VLI Jan 22 08:26:58 localhost kernel: EIP:0060:[c014bec5]Tainted: PB VLI Jan 22 08:26:58 localhost kernel: EFLAGS: 00010286 (2.6.10jry) Jan 22 08:26:58 localhost kernel: EIP is at page_remove_rmap+0x35/0x40 Jan 22 08:26:58 localhost kernel: eax: ebx: 00389000 ecx: c0399d54 edx: c1323a00 Jan 22 08:26:58 localhost kernel: esi: d3b06f44 edi: 003b8000 ebp: d39ebd2c esp: d39ebd2c Jan 22 08:26:58 localhost kernel: ds: 007b es: 007b ss: 0068 Jan 22 08:26:58 localhost kernel: Process net_applet (pid: 9326, threadinfo=d39ea000 task=d6a8d060) Jan 22 08:26:58 localhost kernel: Stack: d39ebd58 c0145a67 c1323a00 c0139256 dffccabc d5a1af08 191d0045 c1323a00 Jan 22 08:26:58 localhost kernel:08848000 d3b5b088 0880 d39ebd88 c0145c10 c0399d54 d3b5b084 08448000 2. I patched in Hugh's patch to 2.6.10 and recompiled. At reboot I ran memtest86 v 1.26, 3 times without any error. Then rebooting in 2.6.10 and doing ifup wlan0 gave me system freeze and unfortunately nothing in the log. Since then I have not seen the same error again after 3 reboots and 2-3 cold boots followed by ifup. I also tried cycles of ifdown and ifup without any errors. 3. I am not sure if I should post my whole config here hence I just pasting DRM related entries here in reference to your original email to Jose`. I have VIA motherboard and a matrox agp card, [FWIW most of the config is same as for 2.6.8 kernel that did not show the rmap sympton] CONFIG_AGP_VIA=m CONFIG_DRM=y CONFIG_DRM_MGA=m I will be glad to provide any other info needed. You may bcc to my email if this is better discussed off the list. [Although I will anxiously check lkml.org everyday or use RSS feed]. I am not subsribed as We are not worthy :-) Thanks, Jay - 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/
