From: Sergey Vlasov <vsu@altlinux.ru>
To: linux-ide@vger.kernel.org
Subject: Re: Opteron SATA machine check exception (32bit)
Date: Wed, 10 Mar 2004 14:54:02 +0300 [thread overview]
Message-ID: <20040310145402.78223378.vsu@altlinux.ru> (raw)
In-Reply-To: 200403100006.36405.andres.meyer@computer.org
[-- Attachment #1: Type: text/plain, Size: 3653 bytes --]
On Wed, 10 Mar 2004 00:06:36 +0100 Andres Meyer wrote:
> I am trying to get an 2x Opteron system to work. As long as I use the 80GB
> Maxtor installed on the integrated IDE controller, everything works fine. As
> soon as I try to use the SATA disks, I get a machine check exception and the
> system reboots, with the hw clock reset to some silly date.
We had similar problems with our Opteron system with the 2.4.22 kernel
and libata patches:
CPU0: Machine Check Exception: 0000000000000004
CPU1: Machine Check Exception: 0000000000000004
Bank4: b200000000070f0f
Kernel panic: CPU context corrupt
In interrupt handler - not syncing
This was observed on sata_promise with this controller:
Promise Technology|PDC20319 FastTrak SATA150 TX4 Controller [STORAGE_RAID] (vendor:105a device:3319 subv:105a subd:6629)
libata version 0.81 loaded.
sata_promise version 0.87
ata1: SATA max UDMA/133 cmd 0xF8835200 ctl 0xF8835238 bmdma 0x0 irq 25
ata2: SATA max UDMA/133 cmd 0xF8835280 ctl 0xF88352B8 bmdma 0x0 irq 25
ata3: SATA max UDMA/133 cmd 0xF8835300 ctl 0xF8835338 bmdma 0x0 irq 25
ata4: SATA max UDMA/133 cmd 0xF8835380 ctl 0xF88353B8 bmdma 0x0 irq 25
ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f
ata1: dev 0 ATA, max UDMA/133, 312581808 sectors (lba48)
ata1: dev 0 configured for UDMA/133
ata2: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f
ata2: dev 0 ATA, max UDMA/133, 312581808 sectors (lba48)
ata2: dev 0 configured for UDMA/133
ata3: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f
ata3: dev 0 ATA, max UDMA/133, 312581808 sectors (lba48)
ata3: dev 0 configured for UDMA/133
ata4: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f
ata4: dev 0 ATA, max UDMA/133, 312581808 sectors (lba48)
ata4: dev 0 configured for UDMA/133
scsi0 : sata_promise
scsi1 : sata_promise
scsi2 : sata_promise
scsi3 : sata_promise
Vendor: ATA Model: ST3160023AS Rev: 0.81
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST3160023AS Rev: 0.81
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST3160023AS Rev: 0.81
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST3160023AS Rev: 0.81
Type: Direct-Access ANSI SCSI revision: 05
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
Attached scsi disk sdc at scsi2, channel 0, id 0, lun 0
Attached scsi disk sdd at scsi3, channel 0, id 0, lun 0
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
Partition check:
sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 >
SCSI device sdb: 312581808 512-byte hdwr sectors (160042 MB)
sdb: sdb1
SCSI device sdc: 312581808 512-byte hdwr sectors (160042 MB)
sdc: sdc1
SCSI device sdd: 312581808 512-byte hdwr sectors (160042 MB)
sdd: sdd1
> This one here happened within ca. 7s when trying to write some zeros
> (cat /dev/zero > test.file) to the first 160GB disk. On the disk, after
> reboot, there was a very small test.file.
In our case the problem did not appear so fast - the machine crashed
while copying about 20 GB from /dev/sda to /dev/sdc, from /dev/sdd to
/dev/sdc and from /dev/sdc to /dev/sda.
The problem disappeared after replacing the Promise controller with a
Silicon Image one:
01:05.0 RAID bus controller: CMD Technology Inc Silicon Image SiI 3112 SATARaid Controller (rev 02)
However, it might be just because the siimage driver is much slower
due to the Seagate workaround...
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2004-03-10 12:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-09 23:06 Opteron SATA machine check exception (32bit) Andres Meyer
2004-03-10 7:22 ` Jeff Garzik
2004-03-10 7:31 ` Andres Meyer
2004-03-10 7:37 ` Jeff Garzik
2004-03-11 21:58 ` Andres Meyer
2004-03-20 11:34 ` Jeff Garzik
2004-03-21 21:44 ` Andres Meyer
2004-03-10 11:54 ` Sergey Vlasov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040310145402.78223378.vsu@altlinux.ru \
--to=vsu@altlinux.ru \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).