Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results
in **MASSIVE** file-system destruction. I have (had) all SCSI
disks, using the BusLogic controller.
There is something **MAJOR** going on BAD, BAD, BAD, even disks
that were not mounted got trashed.
This is (was) a 400MHz SMP machine with 256 Mb of RAM. I don't
know what else to say, since I have nothing to mount. I can
"get back" but it will take several days. I have to install a
minimum system then restore everything from tapes.
I -- S T R O N G L Y -- suggest that nobody use this kernel with
a BusLogic SCSI controller until this problem is fixed.
This is being sent from another machine, not on the list (actually
from home where I am trying to see what happened -- I brought all
4 of my disks home). It looks like some kind of a loop. I have
a pattern written throughout one of the disks.
Cheers,
Dick Johnson
"Richard B. Johnson" wrote:
>
> Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results
...
> I -- S T R O N G L Y -- suggest that nobody use this kernel with
> a BusLogic SCSI controller until this problem is fixed.
>
> This is being sent from another machine, not on the list (actually
> from home where I am trying to see what happened -- I brought all
> 4 of my disks home). It looks like some kind of a loop. I have
> a pattern written throughout one of the disks.
>
Have you been able to recover any kernel messages or oops?
On Mon, 5 Mar 2001, Richard B. Johnson wrote:
>
> Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results
> in **MASSIVE** file-system destruction. I have (had) all SCSI
> disks, using the BusLogic controller.
>
> There is something **MAJOR** going on BAD, BAD, BAD, even disks
> that were not mounted got trashed.
<snip>
>
> I -- S T R O N G L Y -- suggest that nobody use this kernel with
> a BusLogic SCSI controller until this problem is fixed.
>
> This is being sent from another machine, not on the list (actually
> from home where I am trying to see what happened -- I brought all
> 4 of my disks home). It looks like some kind of a loop. I have
> a pattern written throughout one of the disks.
>
> Cheers,
>
> Dick Johnson
It may not be related, but out of five boot attempts, only one got past
the IDE driver stage(ie, below from 2.4.2 :
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
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 vt82c596b (rev 23) IDE UDMA66 controller on pci00:07.1
ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA)
I've had 2.4.2 running great for the past 10 days. Need any more info?
Scott Hoffman
[email protected]
In article <[email protected]>,
Richard B. Johnson <[email protected]> wrote:
>
>I -- S T R O N G L Y -- suggest that nobody use this kernel with
>a BusLogic SCSI controller until this problem is fixed.
Ho humm..
Anybody who has any ideas or input, please holler. There are no actual
BusLogic controller changes in the current 2.4.3-pre kernels at all, so
there's something else going on.
There's a new aic7xxx driver there - did you enable support for that? I
wonder if there could be some inter-action: the aic7xxx driver tries to
probe every PCI SCSI controller because they are basically hard to ID
any other way (no single vendor/id combination, or even a simple
pattern). But it has some rather careful internal logic to filter out
all non-aic7xxx controllers, so this really doesn't look likely.
If you didn't compile aic7xxx in, the only other SCSI change (apart from
a lot of spelling fixes in comments etc) is some trivial error handling,
like changing scsi_test_unit_ready to not have a result buffer (because
it doesn't have a result except for the regular sense buffer). Which
again certainly shouldn't be able to matter at all.
Ideas?
Linus
In article <Pine.LNX.4.32.0103052121180.1029-100000@nic-31-c31-100.mn.mediaone.net>,
Scott M. Hoffman <[email protected]> wrote:
>
> It may not be related, but out of five boot attempts, only one got past
>the IDE driver stage(ie, below from 2.4.2 :
> VP_IDE: IDE controller on PCI bus 00 dev 39
> VP_IDE: chipset revision 16
> 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 vt82c596b (rev 23) IDE UDMA66 controller on pci00:07.1
> ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
> ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA)
>
> I've had 2.4.2 running great for the past 10 days. Need any more info?
I'd love to hear anything you can come up with. What's the next step in
your boot process, ie what's the part that normally shows up but doesn't
with 2.4.2-ac12? Is this using IDE-SCSI, for example?
One thing that both 2.4.3-pre3 and -ac12 do is to not have allocate a
result buffer for TEST_UNIT_READY. I don't see why that should matter,
but can you try un-doing the patch to "scsi_error.c" and see if that
makes a difference. I'm worried about this report, and the buslogic
corruption thing..
Justin: there's another "2.4.3-pre2 corrupts all disks on a buslogic
controller" report. The interesting part is that 2.4.3-pre2 doesn't
actually contain any buslogic changes. The only generic-scsi changes
were yours. Ideas?
Linus
On Mon, 5 Mar 2001, Scott M. Hoffman wrote:
> On Mon, 5 Mar 2001, Richard B. Johnson wrote:
> >
> > I -- S T R O N G L Y -- suggest that nobody use this kernel with
> > a BusLogic SCSI controller until this problem is fixed.
> >
> > Dick Johnson
>
> It may not be related, but out of five boot attempts, only one got past
> the IDE driver stage(ie, below from 2.4.2 :
> VP_IDE: IDE controller on PCI bus 00 dev 39
> VP_IDE: chipset revision 16
> 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 vt82c596b (rev 23) IDE UDMA66 controller on pci00:07.1
> ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
> ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA)
> I've had 2.4.2 running great for the past 10 days. Need any more info?
heh... I had (probably still do), the same problem. Took me a few boots
before it would get passed the drives (this was right after upgrading to
2.4.2).
PIIX4: IDE controller on PCI bus 00 dev 21
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
hda: QUANTUM FIREBALL CX6.4A, ATA DISK drive
hdb: ST33210A, ATA DISK drive
hdc: WDC AC2340F, ATA DISK drive
hdd: ATAPI CD-ROM DRIVE 40X MAXIMUM, ATAPI CD/DVD-ROM drive
Other then the fact that as I look down at the drive activity light on the
case, it's lit ... things from a IO standpoint seem to be ok .. (and I
hope it stays that way) ...
btw, for the curious:
# iostat
Linux 2.4.2 (scotch) 03/06/2001
tty: tin tout avg-cpu: %user %nice %sys %idle %iowait
0 0 1.09 0.00 0.69 0.00 98.22
Disks: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
hdisk0 0.00 0.00 0.00 0 0
hdisk1 0.00 0.00 0.00 0 0
hdisk2 0.00 0.00 0.00 0 0
# hdparm -I /dev/hdd
hdd: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdd: drive_cmd: error=0x04
/dev/hdd:
hdd: drive_cmd: status=0x58 { DriveReady SeekComplete DataRequest }
HDIO_DRIVE_CMD(identify) failed: Input/output error
Doesn't matter what I have hdparm do to the drive, after running a
function the drive / bus activity light turns off ...
Thoughts?
On Tue, 6 Mar 2001, God wrote:
> On Mon, 5 Mar 2001, Scott M. Hoffman wrote:
>
> > On Mon, 5 Mar 2001, Richard B. Johnson wrote:
> > >
> > > I -- S T R O N G L Y -- suggest that nobody use this kernel with
> > > a BusLogic SCSI controller until this problem is fixed.
> > >
> > > Dick Johnson
> >
> > It may not be related, but out of five boot attempts, only one got past
> > the IDE driver stage(ie, below from 2.4.2 :
> > VP_IDE: IDE controller on PCI bus 00 dev 39
> > VP_IDE: chipset revision 16
> > 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 vt82c596b (rev 23) IDE UDMA66 controller on pci00:07.1
> > ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
> > ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA)
> > I've had 2.4.2 running great for the past 10 days. Need any more info?
>
> heh... I had (probably still do), the same problem. Took me a few boots
> before it would get passed the drives (this was right after upgrading to
> 2.4.2).
>
> PIIX4: IDE controller on PCI bus 00 dev 21
> PIIX4: chipset revision 1
> PIIX4: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
> ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
> hda: QUANTUM FIREBALL CX6.4A, ATA DISK drive
> hdb: ST33210A, ATA DISK drive
> hdc: WDC AC2340F, ATA DISK drive
> hdd: ATAPI CD-ROM DRIVE 40X MAXIMUM, ATAPI CD/DVD-ROM drive
>
>
> Other then the fact that as I look down at the drive activity light on the
> case, it's lit ... things from a IO standpoint seem to be ok .. (and I
> hope it stays that way) ...
>
> btw, for the curious:
>
>
> # iostat
> Linux 2.4.2 (scotch) 03/06/2001
>
> tty: tin tout avg-cpu: %user %nice %sys %idle %iowait
> 0 0 1.09 0.00 0.69 0.00 98.22
> Disks: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
> hdisk0 0.00 0.00 0.00 0 0
> hdisk1 0.00 0.00 0.00 0 0
> hdisk2 0.00 0.00 0.00 0 0
>
> # hdparm -I /dev/hdd
> hdd: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
> hdd: drive_cmd: error=0x04
>
> /dev/hdd:
> hdd: drive_cmd: status=0x58 { DriveReady SeekComplete DataRequest }
> HDIO_DRIVE_CMD(identify) failed: Input/output error
>
>
> Doesn't matter what I have hdparm do to the drive, after running a
> function the drive / bus activity light turns off ...
>
>
> Thoughts?
I have not had problems with 2.4.2, just tried 2.4.2-ac12. About the IDE
stage it just reboots.
As for your iostat output, which version do you have? The stock one with
RH7 needs to be upgraded to work with 2.4 kernels. I'm using 3.3.5 now,
which seems to work.
> I have not had problems with 2.4.2, just tried 2.4.2-ac12. About the IDE
> stage it just reboots.
Does ac11 also reboot like that. -ac is currently testing versions of the new
VIA IDE driver so knowing if the latest update did that would be very
useful
On Tue, 6 Mar 2001, Alan Cox wrote:
> > I have not had problems with 2.4.2, just tried 2.4.2-ac12. About the IDE
> > stage it just reboots.
>
> Does ac11 also reboot like that. -ac is currently testing versions of the new
> VIA IDE driver so knowing if the latest update did that would be very
> useful
>
I won't be able to try ac11 until late tonight as that is my home PC that
has the VIA chips. I'll let you know
Also, these patches should be applied to 2.4.2, right? I'm using a 2.4.1
tree patched to 2.4.2, then applied ac12.
Scott Hoffman
> I won't be able to try ac11 until late tonight as that is my home PC that
> has the VIA chips. I'll let you know
> Also, these patches should be applied to 2.4.2, right? I'm using a 2.4.1
> tree patched to 2.4.2, then applied ac12.
Yep you applied it right by the sounds of it.
In mailing-lists.linux-kernel, you wrote:
> -ac is currently testing versions of the new VIA IDE driver
What is the relationship between the version 3.21 in -ac12 and the
version 4.3 that was distributed on this list a week or two ago?
Cheers, Wayne
On Tue, 6 Mar 2001, Alan Cox wrote:
> > I have not had problems with 2.4.2, just tried 2.4.2-ac12. About the IDE
> > stage it just reboots.
>
> Does ac11 also reboot like that. -ac is currently testing versions of the new
> VIA IDE driver so knowing if the latest update did that would be very
> useful
>
Okay, I was able to get home early and tried ac11. Thought it was
working, until it got to about starting GPM mouse services, and rebooted.
Tried it again at run level s, and it got about 40% through fsck before
rebooting again.
I attached my .config from ac11, which did not change from the ac12
compile.
Scott
On Tue, 6 Mar 2001, Scott M. Hoffman wrote:
> On Tue, 6 Mar 2001, God wrote:
>
> > # iostat
> > Linux 2.4.2 (scotch) 03/06/2001
>
> I have not had problems with 2.4.2, just tried 2.4.2-ac12. About the IDE
> stage it just reboots.
Same chipset/mb?
> As for your iostat output, which version do you have? The stock one with
> RH7 needs to be upgraded to work with 2.4 kernels. I'm using 3.3.5 now,
> which seems to work.
Version of?
On Tue, 6 Mar 2001, Alan Cox wrote:
> > I have not had problems with 2.4.2, just tried 2.4.2-ac12. About the IDE
> > stage it just reboots.
>
> Does ac11 also reboot like that. -ac is currently testing versions of the new
> VIA IDE driver so knowing if the latest update did that would be very
> useful
>
Stock 2.4.2 kernel. It (so far), hasn't happened again .. the drive led
is still screwed though. It's weird, the other drives seem to seek at
odd times too (like when they aren't even mounted).
"Richard B. Johnson" <[email protected]> writes:
> Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results
> in **MASSIVE** file-system destruction. I have (had) all SCSI
> disks, using the BusLogic controller.
>
> There is something **MAJOR** going on BAD, BAD, BAD, even disks
> that were not mounted got trashed.
What gcc version did you use to compile it?
--
Krzysztof Halasa
Network Administrator
On Mon, Mar 05, 2001 at 09:35:30PM -0500, Richard B. Johnson wrote:
>
> Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results
> in **MASSIVE** file-system destruction. I have (had) all SCSI
> disks, using the BusLogic controller.
>
> There is something **MAJOR** going on BAD, BAD, BAD, even disks
> that were not mounted got trashed.
>
> This is (was) a 400MHz SMP machine with 256 Mb of RAM. I don't
> know what else to say, since I have nothing to mount. I can
> "get back" but it will take several days. I have to install a
> minimum system then restore everything from tapes.
>
> I -- S T R O N G L Y -- suggest that nobody use this kernel with
> a BusLogic SCSI controller until this problem is fixed.
>
> This is being sent from another machine, not on the list (actually
> from home where I am trying to see what happened -- I brought all
> 4 of my disks home). It looks like some kind of a loop. I have
> a pattern written throughout one of the disks.
Anything new on this? It sounds rather strange considering your
unmounted disks got trashed too, so either it's a problem with the
SCSI subsystem (or the driver; it might be a bug that got triggered
by something else) or some sort of hardware failure.
What kind of pattern was repeated on the disk, by the way? Maybe this
could shed some light unto what happened.
/David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
On Thu, 8 Mar 2001, David Weinehall wrote:
> On Mon, Mar 05, 2001 at 09:35:30PM -0500, Richard B. Johnson wrote:
> >
> > Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results
> > in **MASSIVE** file-system destruction. I have (had) all SCSI
> > disks, using the BusLogic controller.
> >
> > There is something **MAJOR** going on BAD, BAD, BAD, even disks
> > that were not mounted got trashed.
> >
> > This is (was) a 400MHz SMP machine with 256 Mb of RAM. I don't
> > know what else to say, since I have nothing to mount. I can
> > "get back" but it will take several days. I have to install a
> > minimum system then restore everything from tapes.
> >
> > I -- S T R O N G L Y -- suggest that nobody use this kernel with
> > a BusLogic SCSI controller until this problem is fixed.
> >
> > This is being sent from another machine, not on the list (actually
> > from home where I am trying to see what happened -- I brought all
> > 4 of my disks home). It looks like some kind of a loop. I have
> > a pattern written throughout one of the disks.
>
> Anything new on this? It sounds rather strange considering your
> unmounted disks got trashed too, so either it's a problem with the
> SCSI subsystem (or the driver; it might be a bug that got triggered
> by something else) or some sort of hardware failure.
>
> What kind of pattern was repeated on the disk, by the way? Maybe this
> could shed some light unto what happened.
>
Here is the pattern: Repeated at 0x1000 intervals. It looks like
the first page of the kernel, matched here at 0x00100000.
The "Unknown interrupt" text was a dead giveaway.
00100000 FC B8 18 00 00 00 8E D8 8E C0 8E E0 8E E8 66 09 ..............f.
00100010 DB 74 17 83 3D AC 53 25 00 00 74 26 0F 20 E0 0B .t..=.S%..t&. ..
00100020 05 AC 53 25 00 0F 22 E0 EB 18 BF 00 20 10 00 B8 ..S%.."..... ...
00100030 07 00 00 00 AB 05 00 10 00 00 81 FF 00 40 10 00 .............@..
00100040 75 F2 B8 00 10 10 00 0F 22 D8 0F 20 C0 0D 00 00 u.......".. ....
00100050 00 80 0F 22 C0 EB 00 B8 5E 00 10 C0 FF E0 0F B2 ..."....^.......
00100060 25 30 02 10 C0 66 09 DB 74 05 6A 00 9D EB 5C 31 %0...f..t.j...\1
00100070 C0 BF F0 E8 23 C0 B9 50 76 27 C0 29 F9 F3 AA E8 ....#..Pv'.)....
00100080 76 01 00 00 6A 00 9D BF 00 40 10 C0 B9 00 02 00 v...j....@......
00100090 00 FC F3 A5 31 C0 B9 00 02 00 00 F3 AB 8B 35 28 ....1.........5(
001000A0 42 10 C0 21 F6 75 18 66 81 3D 20 00 09 00 3F A3 B..!.u.f.= ...?.
001000B0 75 19 0F B7 35 22 00 09 00 81 C6 00 00 09 00 BF u...5"..........
001000C0 00 48 10 C0 B9 00 02 00 00 F3 A5 C7 05 88 2C 21 .H............,!
001000D0 C0 FF FF FF FF C7 05 80 2C 21 C0 03 00 00 00 9C ........,!......
001000E0 58 89 C1 35 00 00 04 00 50 9D 9C 58 31 C8 25 00 X..5....P..X1.%.
001000F0 00 04 00 74 79 C7 05 80 2C 21 C0 04 00 00 00 89 ...ty...,!......
00100100 C8 35 00 00 20 00 50 9D 9C 58 31 C8 51 9D 25 00 .5.. .P..X1.Q.%.
00100110 00 20 00 74 4A 31 C0 0F A2 A3 88 2C 21 C0 89 1D . .tJ1.....,!...
00100120 90 2C 21 C0 89 15 94 2C 21 C0 89 0D 98 2C 21 C0 .,!....,!....,!.
00100130 09 C0 74 2B B8 01 00 00 00 0F A2 88 C1 80 E4 0F ..t+............
00100140 88 25 80 2C 21 C0 24 F0 C0 E8 04 A2 82 2C 21 C0 .%.,!.$......,!.
00100150 80 E1 0F 88 0D 83 2C 21 C0 89 15 8C 2C 21 C0 0F ......,!....,!..
00100160 20 C0 25 11 00 00 80 0D 22 00 05 00 EB 0D 51 9D .%.....".....Q.
00100170 0F 20 C0 25 11 00 00 80 83 C8 02 0F 22 C0 E8 4F . .%........"..O
00100180 00 00 00 FE 05 D1 01 10 C0 0F 01 15 7A 02 10 C0 ............z...
00100190 0F 01 1D 72 02 10 C0 EA 9E 01 10 C0 10 00 B8 18 ...r............
001001A0 00 00 00 8E D8 8E C0 8E E0 8E E8 B8 18 00 00 00 ................
001001B0 8E D0 31 C0 0F 00 D0 FC 8A 0D D1 01 10 C0 80 F9 ..1.............
001001C0 01 74 07 E8 78 B7 12 00 EB 05 E8 11 66 12 00 EB .t..x.......f...
001001D0 FE 02 C6 05 86 2C 21 C0 00 0F 06 DB E3 9B DF E0 .....,!.........
001001E0 3C 00 74 0C 0F 20 C0 83 F0 04 0F 22 C0 C3 89 F6 <.t.. ....."....
001001F0 C6 05 86 2C 21 C0 01 DB E4 C3 8D 15 50 02 10 C0 ...,!.......P...
00100200 B8 00 00 10 00 66 89 D0 66 BA 00 8E 8D 3D 00 A0 .....f..f....=..
00100210 23 C0 B9 00 01 00 00 89 07 89 57 04 83 C7 08 49 #.........W....I
00100220 75 F5 C3 8D B6 00 00 00 00 8D BC 27 00 00 00 00 u..........'....
00100230 00 54 FF D3 18 00 00 00 55 6E 6B 6E 6F 77 6E 20 .T......Unknown
00100240 69 6E 74 65 72 72 75 70 74 0A 00 90 8D 74 26 00 interrupt....t&.
00100250 FC 50 51 52 06 1E B8 18 00 00 00 8E D8 8E C0 68 .PQR...........h
00100260 38 02 10 C0 E8 B7 67 01 00 58 1F 07 5A 59 58 CF 8.....g..X..ZYX.
00100270 00 00 FF 07 00 A0 23 C0 00 00 5F 04 80 11 21 C0 ......#..._...!.
00100280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00100290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
001002A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
001002B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
001002C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
001002D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
001002E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
001002F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
This get triggered if:
(1) The machine is booted via initrd.
(2) An attempt is made to use the RAM disk after it's booted.
(3) A BusLogic controller.
Now, if I use /dev/ram1, instead of /dev/ram0 (1:1 instead of 1:0), the
problem doesn't show up. It appears as though change_root() leaves
something dangling so that a write to what used to be the root file-
system, results in some pointer/code/whatever corruption. Ultimately
this leads to unexpected SCSI writes.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.