Hello!
After upgrading from 2.4.10 to 2.4.11, I can no longer
mount one particular reiserfs; everything else works fine.
The reiserfs in question uses the 3.6 disk format.
I get the following messages in syslog:
kernel: hdb6: bad access: block=128, count=2
kernel: end_request: I/O error, dev 03:46 (hdb), sector 128
kernel: read_super_block: bread failed (dev 03:46, block 64, size 1024)
kernel: hdb6: bad access: block=16, count=2
kernel: end_request: I/O error, dev 03:46 (hdb), sector 16
kernel: read_super_block: bread failed (dev 03:46, block 8, size 1024)
With 2.4.10, there is no problem, neither before nor after
2.4.11 failed.
fstab:
/dev/sda2 / reiserfs defaults 1 1
/dev/sda3 /usr reiserfs defaults 1 2
/dev/sda5 /opt reiserfs defaults 1 2
/dev/hda6 /boot ext2 defaults 1 2
/dev/sda7 /var reiserfs defaults 1 2
/dev/sdb1 /home reiserfs defaults 1 2
/dev/hdb6 /home/chris/dmp3e reiserfs defaults 1 2
reiserfs is built as a module, loaded from initrd. IDE is built in.
More dmesg output (from 2.4.10, this is the first boot after
2.4.11):
Unknown bridge resource 0: assuming transparent
PCI: Using IRQ router VIA [1106/0686] at 00:04.0
PCI: Found IRQ 10 for device 00:0b.0
PCI: Sharing IRQ 10 with 00:11.0
Applying VIA southbridge workaround.
[...]
VP_IDE: IDE controller on PCI bus 00 dev 21
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:04.1
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio
[...]
hdb: FUJITSU MPG3409AT E, ATA DISK drive
[...]
hdb: 80063424 sectors (40992 MB) w/2048KiB Cache, CHS=79428/16/63, UDMA(100)
hdb: hdb1 hdb2 < hdb5 hdb6 > hdb3
[...]
reiserfs: checking transaction log (device 03:46) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
---------------------------------------------------------------
Please send replies to linux-kernel to me as well, I'm not
currently subscribed. I am on reiserfs-list, though.
--
Christian Ullrich Registrierter Linux-User #125183
"Sie k?nnen nach R'ed'mond fliegen -- aber Sie werden sterben"
Hi
Christian Ullrich wrote:
> Hello!
>
> After upgrading from 2.4.10 to 2.4.11, I can no longer
> mount one particular reiserfs; everything else works fine.
> The reiserfs in question uses the 3.6 disk format.
>
> I get the following messages in syslog:
>
> kernel: hdb6: bad access: block=128, count=2
> kernel: end_request: I/O error, dev 03:46 (hdb), sector 128
> kernel: read_super_block: bread failed (dev 03:46, block 64, size 1024)
> kernel: hdb6: bad access: block=16, count=2
> kernel: end_request: I/O error, dev 03:46 (hdb), sector 16
> kernel: read_super_block: bread failed (dev 03:46, block 8, size 1024)
>
> With 2.4.10, there is no problem, neither before nor after
> 2.4.11 failed.
>
http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.11 says that pre1 and
pre2 got some block device changes. Although I am not sure they made block
device driver less persistent.
Have you tried to run badblocks under 2.4.10 and 2.4.11?
Anyway, I would not trust to this hard drive too much.
Thanks,
vs
> fstab:
>
> /dev/sda2 / reiserfs defaults 1 1
> /dev/sda3 /usr reiserfs defaults 1 2
> /dev/sda5 /opt reiserfs defaults 1 2
> /dev/hda6 /boot ext2 defaults 1 2
> /dev/sda7 /var reiserfs defaults 1 2
> /dev/sdb1 /home reiserfs defaults 1 2
> /dev/hdb6 /home/chris/dmp3e reiserfs defaults 1 2
>
> reiserfs is built as a module, loaded from initrd. IDE is built in.
>
> More dmesg output (from 2.4.10, this is the first boot after
> 2.4.11):
>
> Unknown bridge resource 0: assuming transparent
> PCI: Using IRQ router VIA [1106/0686] at 00:04.0
> PCI: Found IRQ 10 for device 00:0b.0
> PCI: Sharing IRQ 10 with 00:11.0
> Applying VIA southbridge workaround.
>
> [...]
>
> VP_IDE: IDE controller on PCI bus 00 dev 21
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:04.1
> ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
> ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio
>
> [...]
>
> hdb: FUJITSU MPG3409AT E, ATA DISK drive
>
> [...]
>
> hdb: 80063424 sectors (40992 MB) w/2048KiB Cache, CHS=79428/16/63, UDMA(100)
> hdb: hdb1 hdb2 < hdb5 hdb6 > hdb3
>
> [...]
>
> reiserfs: checking transaction log (device 03:46) ...
> Using r5 hash to sort names
> ReiserFS version 3.6.25
>
> ---------------------------------------------------------------
>
> Please send replies to linux-kernel to me as well, I'm not
> currently subscribed. I am on reiserfs-list, though.
>
> --
> Christian Ullrich Registrierter Linux-User #125183
>
> "Sie k?nnen nach R'ed'mond fliegen -- aber Sie werden sterben"
* Vladimir V. Saveliev wrote on Thursday, 2001-10-11:
> Christian Ullrich wrote:
> > After upgrading from 2.4.10 to 2.4.11, I can no longer
> > mount one particular reiserfs; everything else works fine.
> > The reiserfs in question uses the 3.6 disk format.
> >
> > I get the following messages in syslog:
> >
> > kernel: hdb6: bad access: block=128, count=2
> > kernel: end_request: I/O error, dev 03:46 (hdb), sector 128
> > kernel: read_super_block: bread failed (dev 03:46, block 64, size 1024)
> > kernel: hdb6: bad access: block=16, count=2
> > kernel: end_request: I/O error, dev 03:46 (hdb), sector 16
> > kernel: read_super_block: bread failed (dev 03:46, block 8, size 1024)
> >
> > With 2.4.10, there is no problem, neither before nor after
> > 2.4.11 failed.
> http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.11 says that pre1 and
> pre2 got some block device changes. Although I am not sure they made block
> device driver less persistent.
> Have you tried to run badblocks under 2.4.10 and 2.4.11?
I just did under 2.4.10. No trouble at all.
> Anyway, I would not trust to this hard drive too much.
I tend to trust it. It is not even six months old and has worked
flawlessly until now. And with kernel 2.4.10, it continues to work
flawlessly.
Sure, the messages look a lot like hardware failures. But I think
earlier kernel versions would tell me about hardware read errors
as well, even if they can correct them.
--
Christian Ullrich Registrierter Linux-User #125183
"Sie k?nnen nach R'ed'mond fliegen -- aber Sie werden sterben"
On Thu, 11 Oct 2001, Christian Ullrich wrote:
> > > kernel: read_super_block: bread failed (dev 03:46, block 64, size 1024)
> > > kernel: hdb6: bad access: block=16, count=2
fdisk output, please.
* Alexander Viro wrote on Thursday, 2001-10-11:
> fdisk output, please.
The disk contains the one Linux reiserfs partition, one
swap partition and a Windows 2000 installation, which works
as fine as it can be expected to work.
While writing this mail, I found that the swap partition
had somehow acquired partition type 83. I changed it to
82, but the behaviour of 2.4.11 didn't change.
I haven't yet gotten to test 2.4.12. I will do that asap
and report the results.
fdisk output:
christian:~ # fdisk -l /dev/hdb
Disk /dev/hdb: 16 heads, 63 sectors, 79428 cylinders
Units = cylinders of 1008 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 * 1 9921 5000152+ 7 HPFS/NTFS
/dev/hdb2 9922 77444 34031592 f Win95 Ext'd (LBA)
/dev/hdb3 77445 79428 999936 82 Linux swap
/dev/hdb5 9922 30728 10486444+ 7 HPFS/NTFS
/dev/hdb6 47683 77444 15000016+ 83 Linux
christian:~ # fdisk -ul /dev/hdb
Disk /dev/hdb: 16 heads, 63 sectors, 79428 cylinders
Units = sectors of 1 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 * 63 10000367 5000152+ 7 HPFS/NTFS
/dev/hdb2 10000368 78063551 34031592 f Win95 Ext'd (LBA)
/dev/hdb3 78063552 80063423 999936 82 Linux swap
/dev/hdb5 10000431 30973319 10486444+ 7 HPFS/NTFS
/dev/hdb6 48063519 78063551 15000016+ 83 Linux
Expert command (m for help): p
Disk /dev/hdb: 16 heads, 63 sectors, 79428 cylinders
Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 80 1 1 0 15 63 1023 63 10000305 07
2 00 15 63 1023 15 63 1023 10000368 68063184 0f
3 00 15 63 1023 15 63 1023 78063552 1999872 82
4 00 0 0 0 0 0 0 0 0 00
5 00 15 63 1023 15 63 1023 63 20972889 07
6 00 15 63 1023 15 63 1023 63 30000033 83
--
Christian Ullrich Registrierter Linux-User #125183
"Sie k?nnen nach R'ed'mond fliegen -- aber Sie werden sterben"
* Christian Ullrich wrote on Thursday, 2001-10-11:
> * Vladimir V. Saveliev wrote on Thursday, 2001-10-11:
> > Have you tried to run badblocks under 2.4.10 and 2.4.11?
> I just did under 2.4.10. No trouble at all.
With 2.4.11, it says "bad blocks range 0-0" and doesn't
test anything else, that is, it takes no time at all.
I just found that my earlier "trouble-free" badblocks run
under 2.4.10 wasn't as trouble-free as I thought:
christian kernel: __alloc_pages: 0-order allocation failed (gfp=0x70/0) from c01292d6
christian kernel: __alloc_pages: 0-order allocation failed (gfp=0x20/0) from c01292d6
christian kernel: __alloc_pages: 0-order allocation failed (gfp=0x70/0) from c01292d6
christian last message repeated 2 times
christian last message repeated 3 times
christian kernel: __alloc_pages: 0-order allocation failed (gfp=0x70/0) from c01292d6
christian kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0) from c01292d6
christian kernel: __alloc_pages: 0-order allocation failed (gfp=0x70/0) from c01292d6
christian last message repeated 2 times
christian kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0) from c01292d6
christian kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0) from c01292d6
christian kernel: __alloc_pages: 0-order allocation failed (gfp=0x70/0) from c01292d6
christian kernel: __alloc_pages: 0-order allocation failed (gfp=0x70/0) from c01292d6
christian kernel: __alloc_pages: 0-order allocation failed (gfp=0x70/0) from c01292d6
christian last message repeated 2 times
christian kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0) from c01292d6
christian kernel: __alloc_pages: 5-order allocation failed (gfp=0x1f0/0) from c01292d6
christian last message repeated 2 times
>From System.map:
c01292c0 T _alloc_pages
c01292e0 t balance_classzone
Thank you very much for your help.
--
Christian Ullrich Registrierter Linux-User #125183
"Sie k?nnen nach R'ed'mond fliegen -- aber Sie werden sterben"
On Thu, 11 Oct 2001, Christian Ullrich wrote:
> I haven't yet gotten to test 2.4.12. I will do that asap
> and report the results.
2.4.12 shouldn't have changed anything in that area.
> Device Boot Start End Blocks Id System
> /dev/hdb1 * 63 10000367 5000152+ 7 HPFS/NTFS
> /dev/hdb2 10000368 78063551 34031592 f Win95 Ext'd (LBA)
> /dev/hdb3 78063552 80063423 999936 82 Linux swap
> /dev/hdb5 10000431 30973319 10486444+ 7 HPFS/NTFS
> /dev/hdb6 48063519 78063551 15000016+ 83 Linux
>
> Expert command (m for help): p
>
> Disk /dev/hdb: 16 heads, 63 sectors, 79428 cylinders
>
> Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
> 1 80 1 1 0 15 63 1023 63 10000305 07
> 2 00 15 63 1023 15 63 1023 10000368 68063184 0f
> 3 00 15 63 1023 15 63 1023 78063552 1999872 82
> 4 00 0 0 0 0 0 0 0 0 00
> 5 00 15 63 1023 15 63 1023 63 20972889 07
> 6 00 15 63 1023 15 63 1023 63 30000033 83
Umhm... Could you dd the sectors 0, 10000368 and 48063456 and mail them?
Another thing to do - take the patch I've sent and add
printk("[%d %d]\n", start, size);
in the beginning of fs/partitions/check.c::add_gd_partition()
Then we should at least see what kernel thinks about the sizes and starting
sectors of your partitions. It looks like they are screwed of hda6 (if
they are not, we can safely forget about partition-related reasons in your
case - then you really getting a block number out of range and we should look
in fs code; however, considering other bug reports I'd like to check the
partition-related problems first).
* Alexander Viro wrote on Thursday, 2001-10-11:
> Umhm... Could you dd the sectors 0, 10000368 and 48063456 and mail them?
Here you are. I did the following (in 2.4.10, tell me if
you need them from another kernel):
# dd if=/dev/hdb of=hdb-sect0 bs=512 count=1
# dd if=/dev/hdb of=hdb-sect10000368 bs=512 count=1 skip=10000368
# dd if=/dev/hdb of=hdb-sect48063456 bs=512 count=1 skip=48063456
> Another thing to do - take the patch I've sent and add
>
> printk("[%d %d]\n", start, size);
>
> in the beginning of fs/partitions/check.c::add_gd_partition()
I patched both into 2.4.12, the patch went in without any problems.
The kernel (both vanilla and patched) didn't build with the .config I
used with the other kernels, it failed somewhere called IEEE1284.
dmesg output for 2.4.10+line:
SCSI device sda: 17916240 512-byte hdwr sectors (9173 MB)
Partition check:
sda:[63 16002]
sda1[16065 401625]
sda2[417690 8401995]
sda3[8819685 9092790]
sda4 <[8819748 5253192]
sda5[14073003 273042]
sda6[14346108 995967]
sda7[15342138 2570337]
sda8 >
SCSI device sdb: 17916240 512-byte hdwr sectors (9173 MB)
sdb:[63 10490382]
sdb1[10490445 7164990]
sdb2[17655435 257040]
sdb4
hda: 39876480 sectors (20417 MB) w/418KiB Cache, CHS=39560/16/63, UDMA(100)
hdb: 80063424 sectors (40992 MB) w/2048KiB Cache, CHS=79428/16/63, UDMA(100)
hda:[63 2104452]
hda1[2104515 37768815]
hda2 <[2104578 20980827]
hda5[23085468 48132]
hda6[23133663 16739667]
hda7 >
hdb:[63 10000305]
hdb1[10000368 68063184]
hdb2 <[10000431 20972889]
hdb5[48063519 30000033]
hdb6 >[78063552 1999872]
hdb3
------------------------------------------------------------------
dmesg output for 2.4.12+patch+line:
SCSI device sda: 17916240 512-byte hdwr sectors (9173 MB)
Partition check:
sda:[63 16002]
sda1[16065 401625]
sda2[417690 8401995]
sda3[8819685 9092790]
sda4 <[8819748 5253192]
sda5[14073003 273042]
sda6[14346108 995967]
sda7[15342138 2570337]
sda8 >
SCSI device sdb: 17916240 512-byte hdwr sectors (9173 MB)
sdb:[63 10490382]
sdb1[10490445 7164990]
sdb2[17655435 257040]
sdb4
hda: 39876480 sectors (20417 MB) w/418KiB Cache, CHS=39560/16/63, UDMA(100)
hdb: 80063424 sectors (40992 MB) w/2048KiB Cache, CHS=79428/16/63, UDMA(100)
hda:[63 2104452]
hda1[2104515 37768815]
hda2 <[2104578 20980827]
hda5[23085468 48132]
hda6[23133663 16739667]
hda7 >
hdb:[63 10000305]
hdb1[10000368 68063184]
hdb2 < >[78063552 1999872]
hdb3
[...]
ReiserFS version 3.6.25
hdb6: bad access: block=128, count=2
end_request: I/O error, dev 03:46 (hdb), sector 128
read_super_block: bread failed (dev 03:46, block 64, size 1024)
hdb6: bad access: block=16, count=2
end_request: I/O error, dev 03:46 (hdb), sector 16
---------------------------------------------------------------
--
Christian Ullrich Registrierter Linux-User #125183
"Sie k?nnen nach R'ed'mond fliegen -- aber Sie werden sterben"