Re[2]: Sata Sil3512 bug?

Re[2]: Sata Sil3512 bug?

[MisterE]

Hello Tejun,

I've tried with 2 sata cables. Cables which don't give problems with
the Asus motherboard.
I also now use a new decent power supply (corsair vx450) for the
intel. Before it, i used an Fortron supply. But it had no sata
connectors so i used converter adapters. But replacing the supply
did'nt solve it.

btw. If i copy/delete from the Western Digital to my Windows pc (via winscp
or samba) i don't get error messages. Only when i write to it.
The data itself seems to get corrupted; tested with par2. uploaded
with winscp (windows) to the western digital (sda1). Uploaded the same data
to hda1. Tested the data on both drives with par2verify. Most files on
sda1 are corrupted (2 to 4 blocks missing). Copying that data back to
Windows and it give the same results in Quickpar. So reading does not
have problems. The data written to hda1 is correct.


I now inserted a videocard, instead of using the onboard card. And at
first hand it looked solved, but some (much less) errors still happens.
I did not change anything in the bios. The card:
02:00.0 VGA compatible controller: nVidia Corporation NV10 [GeForce 256 SDR] (rev 10)
How can a videocard influence this?

I wanted to build a fileserver, using the intel motherboard. Bacause
of the fact that it has a onboard videocard. I can use the asus if i
have to. But if it is a bug it can better be solved :)

I have some other similar motherboards like the intel laying around.
With and without onboard videocard. I also have a second D815EEA
(probably still has an older BIOS, i have updated the current one because
when i inserted my second 128MB memory it did not gave any picture on
the onboard video card). So i can do some experiments if i have to.

Hope, this helps...

Friday, September 28, 2007, 2:25:05 PM, you wrote:

> Hello,

> MisterE wrote:
>> I've tried the controller in another motherboard, the ASUS CUSL2 (with similar specs)
>> and i don't have any problems. Can you help? I've included some logs
>> with may be of use.

> Did you use the same cable on both machines?  Also, does the problem go
> away if you power the hard drive from the power supply of the other machine?




-- 
Best regards,
 MisterE                            mailto:MisterE2002@zonnet.nl

Re[2]: Sata Sil3512 bug?

[MisterE]

Hello Tejun,

I build another setup with almost the same hardware.
This motherboard had already the latest bios.
I notice that the computer does almost never find the hard drive
although the controller is found every time (with lspci). So i get no
drive (sda) assigned. I don't always see the "bios" screen from the
controller at startup. And in the past it showed the hard drive.
So i could not experiment with this motherboard.

After that i installed Windows XP and used the orginal (sweex)
drivers with the first motherboard. This also makes the data corrupt.
So it seems not to be an linux problem. So there is something wrong with
the motherboard or the 3512 controller.

After that i plugged both hard drives (ide with windows and sata disk)
to the Asus board. No data corruption. So the hard disks are'nt the
problem either.

I'm thinking of replacing both 3512 controllers with a Promise SATA300
TX4. Do you know if there are problems with this device?


Friday, September 28, 2007, 6:55:47 PM, you wrote:

> Alan Cox wrote:
>>> sda1 are corrupted (2 to 4 blocks missing). Copying that data back to
>>> Windows and it give the same results in Quickpar. So reading does not
>>> have problems. The data written to hda1 is correct.
>> 
>> We've got a whole pile of reports like this with the 3512 and almost
>> always Nvidia chipset, plus reports of BIOS updates fixing it. That you
>> see something similar on intel boards is a bit worrying.

> Multiple sil3112/3512 + nvidia chipset problem doesn't usually involve
> device errors or timeouts.  It usually corrupts data silently.  And,
> yeah, data corruption on intel board is really disturbing.

> MisterE, do you have any processor powersaving mechanism enabled?  If
> so, can you disable all and see whether that changes anything?




-- 
Best regards,
 MisterE                            mailto:MisterE2002@zonnet.nl

Re: Re[2]: Sata Sil3512 bug?

[Mikael Pettersson]

On Tue, 2 Oct 2007 21:20:23 +0200, MisterE wrote:
> I build another setup with almost the same hardware.
> This motherboard had already the latest bios.
> I notice that the computer does almost never find the hard drive
> although the controller is found every time (with lspci). So i get no
> drive (sda) assigned. I don't always see the "bios" screen from the
> controller at startup. And in the past it showed the hard drive.
> So i could not experiment with this motherboard.
> 
> After that i installed Windows XP and used the orginal (sweex)
> drivers with the first motherboard. This also makes the data corrupt.
> So it seems not to be an linux problem. So there is something wrong with
> the motherboard or the 3512 controller.
> 
> After that i plugged both hard drives (ide with windows and sata disk)
> to the Asus board. No data corruption. So the hard disks are'nt the
> problem either.
> 
> I'm thinking of replacing both 3512 controllers with a Promise SATA300
> TX4. Do you know if there are problems with this device?

(please don't top-post)

There are no known data-corruption issues with Promise SATA cards.
However, some of them, especially the 2nd generation SATA300 TX4,
are known to trigger intermittent error interrupts (that are dealt
with but may cause a speed reduction) in some systems. We're still
scratching our heads on that issue.

/Mikael

> Friday, September 28, 2007, 6:55:47 PM, you wrote:
> 
> > Alan Cox wrote:
> >>> sda1 are corrupted (2 to 4 blocks missing). Copying that data back to
> >>> Windows and it give the same results in Quickpar. So reading does not
> >>> have problems. The data written to hda1 is correct.
> >> 
> >> We've got a whole pile of reports like this with the 3512 and almost
> >> always Nvidia chipset, plus reports of BIOS updates fixing it. That you
> >> see something similar on intel boards is a bit worrying.
> 
> > Multiple sil3112/3512 + nvidia chipset problem doesn't usually involve
> > device errors or timeouts.  It usually corrupts data silently.  And,
> > yeah, data corruption on intel board is really disturbing.
> 
> > MisterE, do you have any processor powersaving mechanism enabled?  If
> > so, can you disable all and see whether that changes anything?

Re: Sata Sil3512 bug?

[Alexander Sabourenkov]

Mikael Pettersson wrote:

>>
>> I'm thinking of replacing both 3512 controllers with a Promise SATA300
>> TX4. Do you know if there are problems with this device?
> 
> (please don't top-post)
> 
> There are no known data-corruption issues with Promise SATA cards.
> However, some of them, especially the 2nd generation SATA300 TX4,
> are known to trigger intermittent error interrupts (that are dealt
> with but may cause a speed reduction) in some systems. We're still
> scratching our heads on that issue.
> 

But see this thread:

http://marc.info/?l=linux-ide&m=119122463403033&w=2
http://www.spinics.net/lists/linux-ide/msg14868.html

Personally I would not recommend Promise SATA300 TX4 at the moment.

-- 

./lxnt

Re[2]: Sata Sil3512 bug?

[MisterE]

Hello Alexander,

Wednesday, October 3, 2007, 10:31:17 AM, you wrote:

> Mikael Pettersson wrote:

>>>
>>> I'm thinking of replacing both 3512 controllers with a Promise SATA300
>>> TX4. Do you know if there are problems with this device?
>> 
>> (please don't top-post)
>> 
>> There are no known data-corruption issues with Promise SATA cards.
>> However, some of them, especially the 2nd generation SATA300 TX4,
>> are known to trigger intermittent error interrupts (that are dealt
>> with but may cause a speed reduction) in some systems. We're still
>> scratching our heads on that issue.
>> 

> But see this thread:

> http://marc.info/?l=linux-ide&m=119122463403033&w=2
> http://www.spinics.net/lists/linux-ide/msg14868.html

> Personally I would not recommend Promise SATA300 TX4 at the moment.


That is not hopefull. Highpoint does not have sata controllers (Except
softraid controllers). Other (real raid controllers) brands are too
expensive or/and does not have a PCI interface.
Maybe i should keep those 3512 cards? How are the user experiences
with these controllers (except nvidia boards)? Because i don't really
trust the intel boards so using the Asus would be an option.


-- 
Best regards,
 MisterE                            mailto:MisterE2002@zonnet.nl

Re: Sata Sil3512 bug?

[Alan Cox]

> That is not hopefull. Highpoint does not have sata controllers (Except
> softraid controllers). Other (real raid controllers) brands are too

There are pretty much no "real" RAID controllers in the ATA world except
the very high end pricy ones.

Re[2]: Sata Sil3512 bug?

[MisterE]

[-- Attachment #1: Type: text/plain, Size: 3086 bytes --]

Hello Tejun,

I made some new logs. Probably to many :)
The number corresponded with the directory in the archive.

1:
Much errors. I aborted the transfer after a while.

2:
First i copied a movie (multiple archives) with winscp. After a while i got a time-out and
the transfer stopped. And winscp crashed. After that i did some
concurrent transfers; 3 movies at the same time with samba.

4:
I had tried slot changing and insertion of videocard before. Now it
looks to work. Don't know why it now works, probably a bios setting i
changed in combination with the right slot.
After it recognized the sda i did test for corruption. It looks if it gives
more errors than the other board (when the videocard is also
inserted). Probably amount of errors comparable with intel 1 withhout
videocard.



According to lshw is motherboard 1 vAAA10378-405 and motherboard 2
vAAA10378-402. I must say that i also had sometimes problems with the first intel not
finding the hard drive. So, i really don't trust the motherboard
anymore. And i had it with those boards.... :(

Tomorrow i will stress-test the 2 sata controllers with the Asus
board with 4 wd's sata drives connected. If it gives any corruption i
will let you know...

I would like to thank you all for helping me... :)


Thursday, October 4, 2007, 3:27:18 AM, you wrote:

> Hello,

> MisterE wrote:
>> I build another setup with almost the same hardware.
>> This motherboard had already the latest bios.
>> I notice that the computer does almost never find the hard drive
>> although the controller is found every time (with lspci).

> What do you mean by "almost never"?  Does it find the harddisk
> sometimes?  Also, please post kernel boot log after disk detection
> failure.  lspci result just indicates only that the PCI device is present.

>> So i get no
>> drive (sda) assigned. I don't always see the "bios" screen from the
>> controller at startup. And in the past it showed the hard drive.
>> So i could not experiment with this motherboard.

> Can you re-seat the controller or move it to another slot and see
> whether things change?

>> After that i installed Windows XP and used the orginal (sweex)
>> drivers with the first motherboard. This also makes the data corrupt.
>> So it seems not to be an linux problem. So there is something wrong with
>> the motherboard or the 3512 controller.
>> 
>> After that i plugged both hard drives (ide with windows and sata disk)
>> to the Asus board. No data corruption. So the hard disks are'nt the
>> problem either.

> Hmmm... It's relieving to know that the problem isn't caused by sata_sil
> but I don't have much idea than it seems like something goes wrong on
> the PCI bus.  :-(

>> I'm thinking of replacing both 3512 controllers with a Promise SATA300
>> TX4. Do you know if there are problems with this device?

> I see occasional bug reports on sata_promise but AFAIK there haven't
> been any data corruption report.  Mikael knows much better about promise
> controllers.

> Thanks.




-- 
Best regards,
 MisterE                            mailto:MisterE2002@zonnet.nl

[-- Attachment #2: LOGS.rar --]
[-- Type: APPLICATION/OCTET-STREAM, Size: 264822 bytes --]

Re[2]: Sata Sil3512 bug?

[MisterE]

[-- Attachment #1: Type: text/plain, Size: 4559 bytes --]

Hello Tejun,

unfortunately. I today tried to build the array (4x500GB, so it is still building) and i got again a error:

Oct 13 12:17:56 fileserver kernel: raid5: device sdc1 operational as raid disk 2
Oct 13 12:17:56 fileserver kernel: raid5: device sdb1 operational as raid disk 1
Oct 13 12:17:56 fileserver kernel: raid5: device sda1 operational as raid disk 0
Oct 13 12:17:56 fileserver kernel: raid5: allocated 4204kB for md0
Oct 13 12:17:56 fileserver kernel: raid5: raid level 5 set md0 active with 3 out of 4 devices, algorithm 2
Oct 13 12:17:56 fileserver kernel: RAID5 conf printout:
Oct 13 12:17:56 fileserver kernel:  --- rd:4 wd:3
Oct 13 12:17:56 fileserver kernel:  disk 0, o:1, dev:sda1
Oct 13 12:17:56 fileserver kernel:  disk 1, o:1, dev:sdb1
Oct 13 12:17:56 fileserver kernel:  disk 2, o:1, dev:sdc1
Oct 13 12:18:24 fileserver kernel: RAID5 conf printout:
Oct 13 12:18:24 fileserver kernel:  --- rd:4 wd:3
Oct 13 12:18:24 fileserver kernel:  disk 0, o:1, dev:sda1
Oct 13 12:18:24 fileserver kernel:  disk 1, o:1, dev:sdb1
Oct 13 12:18:24 fileserver kernel:  disk 2, o:1, dev:sdc1
Oct 13 12:18:24 fileserver kernel:  disk 3, o:1, dev:sdd1
Oct 13 12:18:24 fileserver kernel: md: recovery of RAID array md0
Oct 13 12:18:24 fileserver kernel: md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Oct 13 12:18:24 fileserver kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
Oct 13 12:18:24 fileserver kernel: md: using 128k window, over a total of 488383936 blocks.
Oct 13 13:01:26 fileserver kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x2400000 action 0x0
Oct 13 13:01:26 fileserver kernel: ata4.00: (BMDMA2 stat 0x650001)
Oct 13 13:01:26 fileserver kernel: ata4.00: cmd ca/00:f8:47:e1:5e/00:00:00:00:00/e4 tag 0 cdb 0x0 data 126976 out
Oct 13 13:01:26 fileserver kernel:          res 51/04:98:a7:e1:5e/00:00:00:00:00/e4 Emask 0x1 (device error)
Oct 13 13:01:26 fileserver kernel: ata4.00: configured for UDMA/100
Oct 13 13:01:26 fileserver kernel: ata4: EH complete
Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Write Protect is off
Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA


I'm not sure if it will result in corrupt data? But i don't trust it
anymore.
You people advise me to not buy the Promise SATA300 TX4 controller and
this Sweex PU102 (3512) seems to have problems. Not much choices left
except the really expensive solutions.

Is it really so hard to build a controller without problems?!? :(


Thursday, October 4, 2007, 3:27:18 AM, you wrote:

> Hello,

> MisterE wrote:
>> I build another setup with almost the same hardware.
>> This motherboard had already the latest bios.
>> I notice that the computer does almost never find the hard drive
>> although the controller is found every time (with lspci).

> What do you mean by "almost never"?  Does it find the harddisk
> sometimes?  Also, please post kernel boot log after disk detection
> failure.  lspci result just indicates only that the PCI device is present.

>> So i get no
>> drive (sda) assigned. I don't always see the "bios" screen from the
>> controller at startup. And in the past it showed the hard drive.
>> So i could not experiment with this motherboard.

> Can you re-seat the controller or move it to another slot and see
> whether things change?

>> After that i installed Windows XP and used the orginal (sweex)
>> drivers with the first motherboard. This also makes the data corrupt.
>> So it seems not to be an linux problem. So there is something wrong with
>> the motherboard or the 3512 controller.
>> 
>> After that i plugged both hard drives (ide with windows and sata disk)
>> to the Asus board. No data corruption. So the hard disks are'nt the
>> problem either.

> Hmmm... It's relieving to know that the problem isn't caused by sata_sil
> but I don't have much idea than it seems like something goes wrong on
> the PCI bus.  :-(

>> I'm thinking of replacing both 3512 controllers with a Promise SATA300
>> TX4. Do you know if there are problems with this device?

> I see occasional bug reports on sata_promise but AFAIK there haven't
> been any data corruption report.  Mikael knows much better about promise
> controllers.

> Thanks.




-- 
Best regards,
 MisterE                            mailto:MisterE2002@zonnet.nl

[-- Attachment #2: kern.log --]
[-- Type: APPLICATION/OCTET-STREAM, Size: 36137 bytes --]

Oct 13 12:05:45 fileserver kernel: Kernel logging (proc) stopped.
Oct 13 12:05:45 fileserver kernel: Kernel log daemon terminating.
Oct 13 12:06:56 fileserver kernel: klogd 1.5.0#1, log source = /proc/kmsg started.
Oct 13 12:06:56 fileserver kernel: Linux version 2.6.22-2-686 (Debian 2.6.22-4) (waldi@debian.org) (gcc version 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)) #1 SMP Fri Aug 31 00:24:01 UTC 2007
Oct 13 12:06:56 fileserver kernel: BIOS-provided physical RAM map:
Oct 13 12:06:56 fileserver kernel:  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
Oct 13 12:06:56 fileserver kernel:  BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
Oct 13 12:06:56 fileserver kernel:  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
Oct 13 12:06:56 fileserver kernel:  BIOS-e820: 0000000000100000 - 000000000ffeb000 (usable)
Oct 13 12:06:56 fileserver kernel:  BIOS-e820: 000000000ffeb000 - 000000000ffef000 (ACPI data)
Oct 13 12:06:56 fileserver kernel:  BIOS-e820: 000000000ffef000 - 000000000ffff000 (reserved)
Oct 13 12:06:56 fileserver kernel:  BIOS-e820: 000000000ffff000 - 0000000010000000 (ACPI NVS)
Oct 13 12:06:56 fileserver kernel:  BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
Oct 13 12:06:56 fileserver kernel: 0MB HIGHMEM available.
Oct 13 12:06:56 fileserver kernel: 255MB LOWMEM available.
Oct 13 12:06:56 fileserver kernel: Entering add_active_range(0, 0, 65515) 0 entries of 256 used
Oct 13 12:06:56 fileserver kernel: Zone PFN ranges:
Oct 13 12:06:56 fileserver kernel:   DMA             0 ->     4096
Oct 13 12:06:56 fileserver kernel:   Normal       4096 ->    65515
Oct 13 12:06:56 fileserver kernel:   HighMem     65515 ->    65515
Oct 13 12:06:56 fileserver kernel: early_node_map[1] active PFN ranges
Oct 13 12:06:56 fileserver kernel:     0:        0 ->    65515
Oct 13 12:06:56 fileserver kernel: On node 0 totalpages: 65515
Oct 13 12:06:56 fileserver kernel:   DMA zone: 32 pages used for memmap
Oct 13 12:06:56 fileserver kernel:   DMA zone: 0 pages reserved
Oct 13 12:06:56 fileserver kernel:   DMA zone: 4064 pages, LIFO batch:0
Oct 13 12:06:56 fileserver kernel:   Normal zone: 479 pages used for memmap
Oct 13 12:06:56 fileserver kernel:   Normal zone: 60940 pages, LIFO batch:15
Oct 13 12:06:56 fileserver kernel:   HighMem zone: 0 pages used for memmap
Oct 13 12:06:56 fileserver kernel: DMI 2.3 present.
Oct 13 12:06:56 fileserver kernel: ACPI: RSDP 000F7880, 0014 (r0 ASUS  )
Oct 13 12:06:56 fileserver kernel: ACPI: RSDT 0FFEB000, 002C (r1 ASUS   CUSL2-C  30303031 MSFT 31313031)
Oct 13 12:06:56 fileserver kernel: ACPI: FACP 0FFEB080, 0074 (r1 ASUS   CUSL2-C  30303031 MSFT 31313031)
Oct 13 12:06:56 fileserver kernel: ACPI: DSDT 0FFEB100, 34D4 (r1   ASUS CUSL2-C      1000 MSFT  100000B)
Oct 13 12:06:56 fileserver kernel: ACPI: FACS 0FFFF000, 0040
Oct 13 12:06:56 fileserver kernel: ACPI: BOOT 0FFEB040, 0028 (r1 ASUS   CUSL2-C  30303031 MSFT 31313031)
Oct 13 12:06:56 fileserver kernel: ACPI: PM-Timer IO Port: 0xe408
Oct 13 12:06:56 fileserver kernel: Allocating PCI resources starting at 20000000 (gap: 10000000:eff80000)
Oct 13 12:06:56 fileserver kernel: Built 1 zonelists.  Total pages: 65004
Oct 13 12:06:56 fileserver kernel: Kernel command line: root=/dev/hda1 ro 
Oct 13 12:06:56 fileserver kernel: Local APIC disabled by BIOS -- you can enable it with "lapic"
Oct 13 12:06:56 fileserver kernel: mapped APIC to ffffd000 (0120b000)
Oct 13 12:06:56 fileserver kernel: Enabling fast FPU save and restore... done.
Oct 13 12:06:56 fileserver kernel: Enabling unmasked SIMD FPU exception support... done.
Oct 13 12:06:56 fileserver kernel: Initializing CPU#0
Oct 13 12:06:56 fileserver kernel: PID hash table entries: 1024 (order: 10, 4096 bytes)
Oct 13 12:06:56 fileserver kernel: Detected 1005.056 MHz processor.
Oct 13 12:06:56 fileserver kernel: Console: colour VGA+ 80x25
Oct 13 12:06:56 fileserver kernel: Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Oct 13 12:06:56 fileserver kernel: Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Oct 13 12:06:56 fileserver kernel: Memory: 250756k/262060k available (1688k kernel code, 10776k reserved, 653k data, 244k init, 0k highmem)
Oct 13 12:06:56 fileserver kernel: virtual kernel memory layout:
Oct 13 12:06:56 fileserver kernel:     fixmap  : 0xfff4e000 - 0xfffff000   ( 708 kB)
Oct 13 12:06:56 fileserver kernel:     pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
Oct 13 12:06:56 fileserver kernel:     vmalloc : 0xd0800000 - 0xff7fe000   ( 751 MB)
Oct 13 12:06:56 fileserver kernel:     lowmem  : 0xc0000000 - 0xcffeb000   ( 255 MB)
Oct 13 12:06:56 fileserver kernel:       .init : 0xc034f000 - 0xc038c000   ( 244 kB)
Oct 13 12:06:56 fileserver kernel:       .data : 0xc02a62bf - 0xc03497e4   ( 653 kB)
Oct 13 12:06:56 fileserver kernel:       .text : 0xc0100000 - 0xc02a62bf   (1688 kB)
Oct 13 12:06:56 fileserver kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok.
Oct 13 12:06:56 fileserver kernel: Calibrating delay using timer specific routine.. 2011.66 BogoMIPS (lpj=4023321)
Oct 13 12:06:56 fileserver kernel: Security Framework v1.0.0 initialized
Oct 13 12:06:56 fileserver kernel: SELinux:  Disabled at boot.
Oct 13 12:06:56 fileserver kernel: Capability LSM initialized
Oct 13 12:06:56 fileserver kernel: Mount-cache hash table entries: 512
Oct 13 12:06:56 fileserver kernel: CPU: After generic identify, caps: 0383f9ff 00000000 00000000 00000000 00000000 00000000 00000000
Oct 13 12:06:56 fileserver kernel: CPU: L1 I cache: 16K, L1 D cache: 16K
Oct 13 12:06:56 fileserver kernel: CPU: L2 cache: 256K
Oct 13 12:06:56 fileserver kernel: CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040 00000000 00000000 00000000
Oct 13 12:06:56 fileserver kernel: Intel machine check architecture supported.
Oct 13 12:06:56 fileserver kernel: Intel machine check reporting enabled on CPU#0.
Oct 13 12:06:56 fileserver kernel: Compat vDSO mapped to ffffe000.
Oct 13 12:06:56 fileserver kernel: Checking 'hlt' instruction... OK.
Oct 13 12:06:56 fileserver kernel: SMP alternatives: switching to UP code
Oct 13 12:06:56 fileserver kernel: Freeing SMP alternatives: 11k freed
Oct 13 12:06:56 fileserver kernel: ACPI: Core revision 20070126
Oct 13 12:06:56 fileserver kernel: ACPI: setting ELCR to 0200 (from 0e20)
Oct 13 12:06:56 fileserver kernel: CPU0: Intel Pentium III (Coppermine) stepping 0a
Oct 13 12:06:56 fileserver kernel: SMP motherboard not detected.
Oct 13 12:06:56 fileserver kernel: Local APIC not detected. Using dummy APIC emulation.
Oct 13 12:06:56 fileserver kernel: Brought up 1 CPUs
Oct 13 12:06:56 fileserver kernel: Booting paravirtualized kernel on bare hardware
Oct 13 12:06:56 fileserver kernel: NET: Registered protocol family 16
Oct 13 12:06:56 fileserver kernel: ACPI: bus type pci registered
Oct 13 12:06:56 fileserver kernel: PCI: PCI BIOS revision 2.10 entry at 0xf0df0, last bus=2
Oct 13 12:06:56 fileserver kernel: PCI: Using configuration type 1
Oct 13 12:06:56 fileserver kernel: Setting up standard PCI resources
Oct 13 12:06:56 fileserver kernel: ACPI: Interpreter enabled
Oct 13 12:06:56 fileserver kernel: ACPI: (supports S0 S1 S4 S5)
Oct 13 12:06:56 fileserver kernel: ACPI: Using PIC for interrupt routing
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Root Bridge [PCI0] (0000:00)
Oct 13 12:06:56 fileserver kernel: PCI: Probing PCI hardware (bus 00)
Oct 13 12:06:56 fileserver kernel: PCI quirk: region e400-e47f claimed by ICH4 ACPI/GPIO/TCO
Oct 13 12:06:56 fileserver kernel: PCI quirk: region ec00-ec3f claimed by ICH4 GPIO
Oct 13 12:06:56 fileserver kernel: PCI: Transparent bridge - 0000:00:1e.0
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
Oct 13 12:06:56 fileserver kernel: Linux Plug and Play Support v0.97 (c) Adam Belay
Oct 13 12:06:56 fileserver kernel: pnp: PnP ACPI init
Oct 13 12:06:56 fileserver kernel: ACPI: bus type pnp registered
Oct 13 12:06:56 fileserver kernel: pnp: PnP ACPI: found 14 devices
Oct 13 12:06:56 fileserver kernel: ACPI: ACPI bus type pnp unregistered
Oct 13 12:06:56 fileserver kernel: PnPBIOS: Disabled by ACPI PNP
Oct 13 12:06:56 fileserver kernel: PCI: Using ACPI for IRQ routing
Oct 13 12:06:56 fileserver kernel: PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
Oct 13 12:06:56 fileserver kernel: NET: Registered protocol family 8
Oct 13 12:06:56 fileserver kernel: NET: Registered protocol family 20
Oct 13 12:06:56 fileserver kernel: ACPI: RTC can wake from S4
Oct 13 12:06:56 fileserver kernel: pnp: 00:00: iomem range 0x0-0x9ffff could not be reserved
Oct 13 12:06:56 fileserver kernel: pnp: 00:00: iomem range 0xf0000-0xfffff could not be reserved
Oct 13 12:06:56 fileserver kernel: pnp: 00:00: iomem range 0x100000-0xfffffff could not be reserved
Oct 13 12:06:56 fileserver kernel: pnp: 00:00: iomem range 0xffb80000-0xffbfffff has been reserved
Oct 13 12:06:56 fileserver kernel: pnp: 00:03: ioport range 0xe400-0xe47f has been reserved
Oct 13 12:06:56 fileserver kernel: pnp: 00:03: ioport range 0xec00-0xec3f has been reserved
Oct 13 12:06:56 fileserver kernel: Time: tsc clocksource has been installed.
Oct 13 12:06:56 fileserver kernel: PCI: Bridge: 0000:00:01.0
Oct 13 12:06:56 fileserver kernel:   IO window: d000-dfff
Oct 13 12:06:56 fileserver kernel:   MEM window: f6000000-f6cfffff
Oct 13 12:06:56 fileserver kernel:   PREFETCH window: f6f00000-f7ffffff
Oct 13 12:06:56 fileserver kernel: PCI: Bridge: 0000:00:1e.0
Oct 13 12:06:56 fileserver kernel:   IO window: 8000-bfff
Oct 13 12:06:56 fileserver kernel:   MEM window: f4800000-f5ffffff
Oct 13 12:06:56 fileserver kernel:   PREFETCH window: f6d00000-f6efffff
Oct 13 12:06:56 fileserver kernel: PCI: Setting latency timer of device 0000:00:01.0 to 64
Oct 13 12:06:56 fileserver kernel: PCI: Setting latency timer of device 0000:00:1e.0 to 64
Oct 13 12:06:56 fileserver kernel: NET: Registered protocol family 2
Oct 13 12:06:56 fileserver kernel: IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
Oct 13 12:06:56 fileserver kernel: TCP established hash table entries: 8192 (order: 4, 98304 bytes)
Oct 13 12:06:56 fileserver kernel: TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
Oct 13 12:06:56 fileserver kernel: TCP: Hash tables configured (established 8192 bind 8192)
Oct 13 12:06:56 fileserver kernel: TCP reno registered
Oct 13 12:06:56 fileserver kernel: checking if image is initramfs...<6>Switched to high resolution mode on CPU 0
Oct 13 12:06:56 fileserver kernel:  it is
Oct 13 12:06:56 fileserver kernel: Freeing initrd memory: 5543k freed
Oct 13 12:06:56 fileserver kernel: Simple Boot Flag at 0x3a set to 0x1
Oct 13 12:06:56 fileserver kernel: audit: initializing netlink socket (disabled)
Oct 13 12:06:56 fileserver kernel: audit(1192291588.204:1): initialized
Oct 13 12:06:56 fileserver kernel: VFS: Disk quotas dquot_6.5.1
Oct 13 12:06:56 fileserver kernel: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Oct 13 12:06:56 fileserver kernel: io scheduler noop registered
Oct 13 12:06:56 fileserver kernel: io scheduler anticipatory registered
Oct 13 12:06:56 fileserver kernel: io scheduler deadline registered
Oct 13 12:06:56 fileserver kernel: io scheduler cfq registered (default)
Oct 13 12:06:56 fileserver kernel: Boot video device is 0000:01:00.0
Oct 13 12:06:56 fileserver kernel: isapnp: Scanning for PnP cards...
Oct 13 12:06:56 fileserver kernel: isapnp: No Plug & Play device found
Oct 13 12:06:56 fileserver kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
Oct 13 12:06:56 fileserver kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Oct 13 12:06:56 fileserver kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Oct 13 12:06:56 fileserver kernel: 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Oct 13 12:06:56 fileserver kernel: 00:0b: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Oct 13 12:06:56 fileserver kernel: RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Oct 13 12:06:56 fileserver kernel: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
Oct 13 12:06:56 fileserver kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Oct 13 12:06:56 fileserver kernel: serio: i8042 AUX port at 0x60,0x64 irq 12
Oct 13 12:06:56 fileserver kernel: mice: PS/2 mouse device common for all mice
Oct 13 12:06:56 fileserver kernel: TCP bic registered
Oct 13 12:06:56 fileserver kernel: NET: Registered protocol family 1
Oct 13 12:06:56 fileserver kernel: NET: Registered protocol family 17
Oct 13 12:06:56 fileserver kernel: Using IPI No-Shortcut mode
Oct 13 12:06:56 fileserver kernel: Freeing unused kernel memory: 244k freed
Oct 13 12:06:56 fileserver kernel: input: AT Translated Set 2 keyboard as /class/input/input0
Oct 13 12:06:56 fileserver kernel: ACPI: Invalid PBLK length [5]
Oct 13 12:06:56 fileserver kernel: SCSI subsystem initialized
Oct 13 12:06:56 fileserver kernel: libata version 2.21 loaded.
Oct 13 12:06:56 fileserver kernel: usbcore: registered new interface driver usbfs
Oct 13 12:06:56 fileserver kernel: usbcore: registered new interface driver hub
Oct 13 12:06:56 fileserver kernel: usbcore: registered new device driver usb
Oct 13 12:06:56 fileserver kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
Oct 13 12:06:56 fileserver kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Oct 13 12:06:56 fileserver kernel: ICH2: IDE controller at PCI slot 0000:00:1f.1
Oct 13 12:06:56 fileserver kernel: ICH2: chipset revision 2
Oct 13 12:06:56 fileserver kernel: ICH2: not 100% native mode: will probe irqs later
Oct 13 12:06:56 fileserver kernel:     ide0: BM-DMA at 0x7800-0x7807, BIOS settings: hda:DMA, hdb:DMA
Oct 13 12:06:56 fileserver kernel:     ide1: BM-DMA at 0x7808-0x780f, BIOS settings: hdc:pio, hdd:pio
Oct 13 12:06:56 fileserver kernel: Probing IDE interface ide0...
Oct 13 12:06:56 fileserver kernel: USB Universal Host Controller Interface driver v3.0
Oct 13 12:06:56 fileserver kernel: hda: WDC AC36400L, ATA DISK drive
Oct 13 12:06:56 fileserver kernel: Floppy drive(s): fd0 is 1.44M
Oct 13 12:06:56 fileserver kernel: FDC 0 is a post-1991 82077
Oct 13 12:06:56 fileserver kernel: hdb: _NEC DVD_RW ND-3500AG, ATAPI CD/DVD-ROM drive
Oct 13 12:06:56 fileserver kernel: hda: selected mode 0x42
Oct 13 12:06:56 fileserver kernel: hdb: selected mode 0x42
Oct 13 12:06:56 fileserver kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Oct 13 12:06:56 fileserver kernel: Probing IDE interface ide1...
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
Oct 13 12:06:56 fileserver kernel: PCI: setting IRQ 5 as level-triggered
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt 0000:00:1f.2[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
Oct 13 12:06:56 fileserver kernel: PCI: Setting latency timer of device 0000:00:1f.2 to 64
Oct 13 12:06:56 fileserver kernel: uhci_hcd 0000:00:1f.2: UHCI Host Controller
Oct 13 12:06:56 fileserver kernel: uhci_hcd 0000:00:1f.2: new USB bus registered, assigned bus number 1
Oct 13 12:06:56 fileserver kernel: uhci_hcd 0000:00:1f.2: irq 5, io base 0x00007400
Oct 13 12:06:56 fileserver kernel: usb usb1: configuration #1 chosen from 1 choice
Oct 13 12:06:56 fileserver kernel: hub 1-0:1.0: USB hub found
Oct 13 12:06:56 fileserver kernel: hub 1-0:1.0: 2 ports detected
Oct 13 12:06:56 fileserver kernel: hda: max request size: 128KiB
Oct 13 12:06:56 fileserver kernel: hda: 12594960 sectors (6448 MB) w/256KiB Cache, CHS=13328/15/63, UDMA(33)
Oct 13 12:06:56 fileserver kernel: hda: cache flushes not supported
Oct 13 12:06:56 fileserver kernel:  hda: hda1 hda2 <ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 9
Oct 13 12:06:56 fileserver kernel: PCI: setting IRQ 9 as level-triggered
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt 0000:00:1f.4[C] -> Link [LNKH] -> GSI 9 (level, low) -> IRQ 9
Oct 13 12:06:56 fileserver kernel: PCI: Setting latency timer of device 0000:00:1f.4 to 64
Oct 13 12:06:56 fileserver kernel: uhci_hcd 0000:00:1f.4: UHCI Host Controller
Oct 13 12:06:56 fileserver kernel: uhci_hcd 0000:00:1f.4: new USB bus registered, assigned bus number 2
Oct 13 12:06:56 fileserver kernel: uhci_hcd 0000:00:1f.4: irq 9, io base 0x00007000
Oct 13 12:06:56 fileserver kernel: usb usb2: configuration #1 chosen from 1 choice
Oct 13 12:06:56 fileserver kernel: hub 2-0:1.0: USB hub found
Oct 13 12:06:56 fileserver kernel: hub 2-0:1.0: 2 ports detected
Oct 13 12:06:56 fileserver kernel:  hda5 >
Oct 13 12:06:56 fileserver kernel: hdb: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
Oct 13 12:06:56 fileserver kernel: Uniform CD-ROM driver Revision: 3.20
Oct 13 12:06:56 fileserver kernel: sata_sil 0000:02:0a.0: version 2.2
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 9
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt 0000:02:0a.0[A] -> Link [LNKG] -> GSI 9 (level, low) -> IRQ 9
Oct 13 12:06:56 fileserver kernel: scsi0 : sata_sil
Oct 13 12:06:56 fileserver kernel: scsi1 : sata_sil
Oct 13 12:06:56 fileserver kernel: ata1: SATA max UDMA/100 cmd 0xd081a080 ctl 0xd081a08a bmdma 0xd081a000 irq 9
Oct 13 12:06:56 fileserver kernel: ata2: SATA max UDMA/100 cmd 0xd081a0c0 ctl 0xd081a0ca bmdma 0xd081a008 irq 9
Oct 13 12:06:56 fileserver kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Oct 13 12:06:56 fileserver kernel: ata1.00: ATA-7: WDC WD5000AAKS-00TMA0, 12.01C01, max UDMA/133
Oct 13 12:06:56 fileserver kernel: ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
Oct 13 12:06:56 fileserver kernel: ata1.00: configured for UDMA/100
Oct 13 12:06:56 fileserver kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Oct 13 12:06:56 fileserver kernel: ata2.00: ATA-7: WDC WD5000AAKS-00TMA0, 12.01C01, max UDMA/133
Oct 13 12:06:56 fileserver kernel: ata2.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
Oct 13 12:06:56 fileserver kernel: ata2.00: configured for UDMA/100
Oct 13 12:06:56 fileserver kernel: scsi 0:0:0:0: Direct-Access     ATA      WDC WD5000AAKS-0 12.0 PQ: 0 ANSI: 5
Oct 13 12:06:56 fileserver kernel: scsi 1:0:0:0: Direct-Access     ATA      WDC WD5000AAKS-0 12.0 PQ: 0 ANSI: 5
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt 0000:02:0b.0[A] -> Link [LNKH] -> GSI 9 (level, low) -> IRQ 9
Oct 13 12:06:56 fileserver kernel: scsi2 : sata_sil
Oct 13 12:06:56 fileserver kernel: scsi3 : sata_sil
Oct 13 12:06:56 fileserver kernel: ata3: SATA max UDMA/100 cmd 0xd0834080 ctl 0xd083408a bmdma 0xd0834000 irq 9
Oct 13 12:06:56 fileserver kernel: ata4: SATA max UDMA/100 cmd 0xd08340c0 ctl 0xd08340ca bmdma 0xd0834008 irq 9
Oct 13 12:06:56 fileserver kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Oct 13 12:06:56 fileserver kernel: ata3.00: ATA-7: WDC WD5000AAKS-00TMA0, 12.01C01, max UDMA/133
Oct 13 12:06:56 fileserver kernel: ata3.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
Oct 13 12:06:56 fileserver kernel: ata3.00: configured for UDMA/100
Oct 13 12:06:56 fileserver kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Oct 13 12:06:56 fileserver kernel: ata4.00: ATA-7: WDC WD5000AAKS-00TMA0, 12.01C01, max UDMA/133
Oct 13 12:06:56 fileserver kernel: ata4.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
Oct 13 12:06:56 fileserver kernel: ata4.00: configured for UDMA/100
Oct 13 12:06:56 fileserver kernel: scsi 2:0:0:0: Direct-Access     ATA      WDC WD5000AAKS-0 12.0 PQ: 0 ANSI: 5
Oct 13 12:06:56 fileserver kernel: scsi 3:0:0:0: Direct-Access     ATA      WDC WD5000AAKS-0 12.0 PQ: 0 ANSI: 5
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 9
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt 0000:02:0d.0[A] -> Link [LNKF] -> GSI 9 (level, low) -> IRQ 9
Oct 13 12:06:56 fileserver kernel: 3c59x: Donald Becker and others.
Oct 13 12:06:56 fileserver kernel: 0000:02:0d.0: 3Com PCI 3c905C Tornado at d0836000.
Oct 13 12:06:56 fileserver kernel: sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:06:56 fileserver kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 13 12:06:56 fileserver kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 13 12:06:56 fileserver kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:06:56 fileserver kernel: sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:06:56 fileserver kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 13 12:06:56 fileserver kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 13 12:06:56 fileserver kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:06:56 fileserver kernel:  sda: sda1
Oct 13 12:06:56 fileserver kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Oct 13 12:06:56 fileserver kernel: sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:06:56 fileserver kernel: sd 1:0:0:0: [sdb] Write Protect is off
Oct 13 12:06:56 fileserver kernel: sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Oct 13 12:06:56 fileserver kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:06:56 fileserver kernel: sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:06:56 fileserver kernel: sd 1:0:0:0: [sdb] Write Protect is off
Oct 13 12:06:56 fileserver kernel: sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Oct 13 12:06:56 fileserver kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:06:56 fileserver kernel:  sdb: sdb1
Oct 13 12:06:56 fileserver kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
Oct 13 12:06:56 fileserver kernel: sd 2:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:06:56 fileserver kernel: sd 2:0:0:0: [sdc] Write Protect is off
Oct 13 12:06:56 fileserver kernel: sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
Oct 13 12:06:56 fileserver kernel: sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:06:56 fileserver kernel: sd 2:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:06:56 fileserver kernel: sd 2:0:0:0: [sdc] Write Protect is off
Oct 13 12:06:56 fileserver kernel: sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
Oct 13 12:06:56 fileserver kernel: sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:06:56 fileserver kernel:  sdc: sdc1
Oct 13 12:06:56 fileserver kernel: sd 2:0:0:0: [sdc] Attached SCSI disk
Oct 13 12:06:56 fileserver kernel: sd 3:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:06:56 fileserver kernel: sd 3:0:0:0: [sdd] Write Protect is off
Oct 13 12:06:56 fileserver kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Oct 13 12:06:56 fileserver kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:06:56 fileserver kernel: sd 3:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:06:56 fileserver kernel: sd 3:0:0:0: [sdd] Write Protect is off
Oct 13 12:06:56 fileserver kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Oct 13 12:06:56 fileserver kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:06:56 fileserver kernel:  sdd: sdd1
Oct 13 12:06:56 fileserver kernel: sd 3:0:0:0: [sdd] Attached SCSI disk
Oct 13 12:06:56 fileserver kernel: raid5: automatically using best checksumming function: pIII_sse
Oct 13 12:06:56 fileserver kernel:    pIII_sse  :  1990.000 MB/sec
Oct 13 12:06:56 fileserver kernel: raid5: using function: pIII_sse (1990.000 MB/sec)
Oct 13 12:06:56 fileserver kernel: raid6: int32x1    308 MB/s
Oct 13 12:06:56 fileserver kernel: raid6: int32x2    359 MB/s
Oct 13 12:06:56 fileserver kernel: raid6: int32x4    286 MB/s
Oct 13 12:06:56 fileserver kernel: raid6: int32x8    254 MB/s
Oct 13 12:06:56 fileserver kernel: raid6: mmxx1      923 MB/s
Oct 13 12:06:56 fileserver kernel: raid6: mmxx2     1152 MB/s
Oct 13 12:06:56 fileserver kernel: raid6: sse1x1     833 MB/s
Oct 13 12:06:56 fileserver kernel: raid6: sse1x2    1150 MB/s
Oct 13 12:06:56 fileserver kernel: raid6: using algorithm sse1x2 (1150 MB/s)
Oct 13 12:06:56 fileserver kernel: md: raid6 personality registered for level 6
Oct 13 12:06:56 fileserver kernel: md: raid5 personality registered for level 5
Oct 13 12:06:56 fileserver kernel: md: raid4 personality registered for level 4
Oct 13 12:06:56 fileserver kernel: md: md0 stopped.
Oct 13 12:06:56 fileserver kernel: md: bind<sdb1>
Oct 13 12:06:56 fileserver kernel: md: bind<sdc1>
Oct 13 12:06:56 fileserver kernel: md: bind<sdd1>
Oct 13 12:06:56 fileserver kernel: md: bind<sda1>
Oct 13 12:06:56 fileserver kernel: raid5: device sda1 operational as raid disk 0
Oct 13 12:06:56 fileserver kernel: raid5: device sdd1 operational as raid disk 3
Oct 13 12:06:56 fileserver kernel: raid5: device sdc1 operational as raid disk 2
Oct 13 12:06:56 fileserver kernel: raid5: device sdb1 operational as raid disk 1
Oct 13 12:06:56 fileserver kernel: raid5: allocated 4204kB for md0
Oct 13 12:06:56 fileserver kernel: raid5: raid level 5 set md0 active with 4 out of 4 devices, algorithm 2
Oct 13 12:06:56 fileserver kernel: RAID5 conf printout:
Oct 13 12:06:56 fileserver kernel:  --- rd:4 wd:4
Oct 13 12:06:56 fileserver kernel:  disk 0, o:1, dev:sda1
Oct 13 12:06:56 fileserver kernel:  disk 1, o:1, dev:sdb1
Oct 13 12:06:56 fileserver kernel:  disk 2, o:1, dev:sdc1
Oct 13 12:06:56 fileserver kernel:  disk 3, o:1, dev:sdd1
Oct 13 12:06:56 fileserver kernel: Attempting manual resume
Oct 13 12:06:56 fileserver kernel: kjournald starting.  Commit interval 5 seconds
Oct 13 12:06:56 fileserver kernel: EXT3-fs: mounted filesystem with ordered data mode.
Oct 13 12:06:56 fileserver kernel: udev: renamed network interface eth0 to eth1
Oct 13 12:06:56 fileserver kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Oct 13 12:06:56 fileserver kernel: shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
Oct 13 12:06:56 fileserver kernel: intel_rng: FWH not detected
Oct 13 12:06:56 fileserver kernel: Linux agpgart interface v0.102 (c) Dave Jones
Oct 13 12:06:56 fileserver kernel: agpgart: Detected an Intel i815 Chipset.
Oct 13 12:06:56 fileserver kernel: agpgart: AGP aperture is 64M @ 0xf8000000
Oct 13 12:06:56 fileserver kernel: iTCO_wdt: Intel TCO WatchDog Timer Driver v1.01 (21-Jan-2007)
Oct 13 12:06:56 fileserver kernel: iTCO_wdt: Found a ICH2 TCO device (Version=1, TCOBASE=0xe460)
Oct 13 12:06:56 fileserver kernel: iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
Oct 13 12:06:56 fileserver kernel: Real Time Clock Driver v1.12ac
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
Oct 13 12:06:56 fileserver kernel: PCI: setting IRQ 10 as level-triggered
Oct 13 12:06:56 fileserver kernel: ACPI: PCI Interrupt 0000:00:1f.3[B] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
Oct 13 12:06:56 fileserver kernel: input: PC Speaker as /class/input/input1
Oct 13 12:06:56 fileserver kernel: input: ImPS/2 Generic Wheel Mouse as /class/input/input2
Oct 13 12:06:56 fileserver kernel: parport_pc 00:09: reported by Plug and Play ACPI
Oct 13 12:06:56 fileserver kernel: parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
Oct 13 12:06:56 fileserver kernel: Adding 329292k swap on /dev/hda5.  Priority:-1 extents:1 across:329292k
Oct 13 12:06:56 fileserver kernel: EXT3 FS on hda1, internal journal
Oct 13 12:06:56 fileserver kernel: loop: module loaded
Oct 13 12:06:56 fileserver kernel: device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
Oct 13 12:06:56 fileserver kernel: eth1:  setting full-duplex.
Oct 13 12:06:57 fileserver kernel: NET: Registered protocol family 10
Oct 13 12:06:57 fileserver kernel: lo: Disabled Privacy Extensions
Oct 13 12:06:58 fileserver kernel: input: Power Button (FF) as /class/input/input3
Oct 13 12:06:58 fileserver kernel: ACPI: Power Button (FF) [PWRF]
Oct 13 12:06:58 fileserver kernel: input: Power Button (CM) as /class/input/input4
Oct 13 12:06:58 fileserver kernel: ACPI: Power Button (CM) [PWRB]
Oct 13 12:07:07 fileserver kernel: eth1: no IPv6 routers present
Oct 13 12:10:37 fileserver kernel: md: md0 stopped.
Oct 13 12:10:37 fileserver kernel: md: unbind<sda1>
Oct 13 12:10:37 fileserver kernel: md: export_rdev(sda1)
Oct 13 12:10:37 fileserver kernel: md: unbind<sdd1>
Oct 13 12:10:37 fileserver kernel: md: export_rdev(sdd1)
Oct 13 12:10:37 fileserver kernel: md: unbind<sdc1>
Oct 13 12:10:37 fileserver kernel: md: export_rdev(sdc1)
Oct 13 12:10:37 fileserver kernel: md: unbind<sdb1>
Oct 13 12:10:37 fileserver kernel: md: export_rdev(sdb1)
Oct 13 12:13:08 fileserver kernel: sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:13:08 fileserver kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 13 12:13:08 fileserver kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 13 12:13:08 fileserver kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:13:08 fileserver kernel:  sda: sda1
Oct 13 12:13:10 fileserver kernel: sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:13:10 fileserver kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 13 12:13:10 fileserver kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 13 12:13:10 fileserver kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:13:10 fileserver kernel:  sda: sda1
Oct 13 12:13:33 fileserver kernel: sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:13:33 fileserver kernel: sd 1:0:0:0: [sdb] Write Protect is off
Oct 13 12:13:33 fileserver kernel: sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Oct 13 12:13:33 fileserver kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:13:33 fileserver kernel:  sdb: sdb1
Oct 13 12:13:35 fileserver kernel: sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:13:35 fileserver kernel: sd 1:0:0:0: [sdb] Write Protect is off
Oct 13 12:13:35 fileserver kernel: sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Oct 13 12:13:35 fileserver kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:13:35 fileserver kernel:  sdb: sdb1
Oct 13 12:13:52 fileserver kernel: sd 2:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:13:52 fileserver kernel: sd 2:0:0:0: [sdc] Write Protect is off
Oct 13 12:13:52 fileserver kernel: sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
Oct 13 12:13:52 fileserver kernel: sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:13:52 fileserver kernel:  sdc: sdc1
Oct 13 12:13:54 fileserver kernel: sd 2:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:13:54 fileserver kernel: sd 2:0:0:0: [sdc] Write Protect is off
Oct 13 12:13:54 fileserver kernel: sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
Oct 13 12:13:54 fileserver kernel: sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:13:55 fileserver kernel:  sdc: sdc1
Oct 13 12:14:12 fileserver kernel: sd 3:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:14:12 fileserver kernel: sd 3:0:0:0: [sdd] Write Protect is off
Oct 13 12:14:12 fileserver kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Oct 13 12:14:12 fileserver kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:14:12 fileserver kernel:  sdd: sdd1
Oct 13 12:14:14 fileserver kernel: sd 3:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 12:14:14 fileserver kernel: sd 3:0:0:0: [sdd] Write Protect is off
Oct 13 12:14:14 fileserver kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Oct 13 12:14:14 fileserver kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 12:14:14 fileserver kernel:  sdd: sdd1
Oct 13 12:17:34 fileserver kernel: md: md0 stopped.
Oct 13 12:17:56 fileserver kernel: md: bind<sda1>
Oct 13 12:17:56 fileserver kernel: md: bind<sdb1>
Oct 13 12:17:56 fileserver kernel: md: bind<sdc1>
Oct 13 12:17:56 fileserver kernel: md: bind<sdd1>
Oct 13 12:17:56 fileserver kernel: raid5: device sdc1 operational as raid disk 2
Oct 13 12:17:56 fileserver kernel: raid5: device sdb1 operational as raid disk 1
Oct 13 12:17:56 fileserver kernel: raid5: device sda1 operational as raid disk 0
Oct 13 12:17:56 fileserver kernel: raid5: allocated 4204kB for md0
Oct 13 12:17:56 fileserver kernel: raid5: raid level 5 set md0 active with 3 out of 4 devices, algorithm 2
Oct 13 12:17:56 fileserver kernel: RAID5 conf printout:
Oct 13 12:17:56 fileserver kernel:  --- rd:4 wd:3
Oct 13 12:17:56 fileserver kernel:  disk 0, o:1, dev:sda1
Oct 13 12:17:56 fileserver kernel:  disk 1, o:1, dev:sdb1
Oct 13 12:17:56 fileserver kernel:  disk 2, o:1, dev:sdc1
Oct 13 12:18:24 fileserver kernel: RAID5 conf printout:
Oct 13 12:18:24 fileserver kernel:  --- rd:4 wd:3
Oct 13 12:18:24 fileserver kernel:  disk 0, o:1, dev:sda1
Oct 13 12:18:24 fileserver kernel:  disk 1, o:1, dev:sdb1
Oct 13 12:18:24 fileserver kernel:  disk 2, o:1, dev:sdc1
Oct 13 12:18:24 fileserver kernel:  disk 3, o:1, dev:sdd1
Oct 13 12:18:24 fileserver kernel: md: recovery of RAID array md0
Oct 13 12:18:24 fileserver kernel: md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Oct 13 12:18:24 fileserver kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
Oct 13 12:18:24 fileserver kernel: md: using 128k window, over a total of 488383936 blocks.
Oct 13 13:01:26 fileserver kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x2400000 action 0x0
Oct 13 13:01:26 fileserver kernel: ata4.00: (BMDMA2 stat 0x650001)
Oct 13 13:01:26 fileserver kernel: ata4.00: cmd ca/00:f8:47:e1:5e/00:00:00:00:00/e4 tag 0 cdb 0x0 data 126976 out
Oct 13 13:01:26 fileserver kernel:          res 51/04:98:a7:e1:5e/00:00:00:00:00/e4 Emask 0x1 (device error)
Oct 13 13:01:26 fileserver kernel: ata4.00: configured for UDMA/100
Oct 13 13:01:26 fileserver kernel: ata4: EH complete
Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB)
Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Write Protect is off
Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Re[2]: Sata Sil3512 bug?

[MisterE]

Hello,

Alexander, does these problems with the Promise SATA300 TX4 happen to
everyone?

The only alternatives are
using soft-raid products as normal controllers. Does anyone have experiences
with the following products?
* Highpoint RocketRAID 1640 (150 MB/s)
* Highpoint RocketRAID 1740 (300 MB/s)
* Adaptec 1210SA


Wednesday, October 3, 2007, 10:31:17 AM, you wrote:

> Mikael Pettersson wrote:

>>>
>>> I'm thinking of replacing both 3512 controllers with a Promise SATA300
>>> TX4. Do you know if there are problems with this device?
>> 
>> (please don't top-post)
>> 
>> There are no known data-corruption issues with Promise SATA cards.
>> However, some of them, especially the 2nd generation SATA300 TX4,
>> are known to trigger intermittent error interrupts (that are dealt
>> with but may cause a speed reduction) in some systems. We're still
>> scratching our heads on that issue.
>> 

> But see this thread:

> http://marc.info/?l=linux-ide&m=119122463403033&w=2
> http://www.spinics.net/lists/linux-ide/msg14868.html

> Personally I would not recommend Promise SATA300 TX4 at the moment.




-- 
Best regards,
 MisterE                            mailto:MisterE2002@zonnet.nl

Re: Sata Sil3512 bug?

[Alexander Sabourenkov]

MisterE wrote:
> Hello,
> 
> Alexander, does these problems with the Promise SATA300 TX4 happen to
> everyone?
> 

Most probably not, as I think it would have been fixed much faster then.

I was waiting for a) release of 2.6.23, and b) me completing the move to 
another flat
to retest all the latest developments in mainline and libata-dev.

With a) done and b) almost done, I'll retest and report any issues quite 
soon.

Besides, there is a report of TX4 and 2.6.23 not showing problems that 
were there with 2.6.22,
( see "Bug is fixed in 2.6.23.1: sata_promise: port is slow to respond, 
reset failed" thread).


> The only alternatives are
> using soft-raid products as normal controllers. Does anyone have experiences
> with the following products?
> * Highpoint RocketRAID 1640 (150 MB/s)
> * Highpoint RocketRAID 1740 (300 MB/s)
> * Adaptec 1210SA
> 

For any kind of non-hobby task I'd skip trying to build a disk array to 
buying a SATA-SCSI/SATA-iSCSI box.
While I had many mind-boggling issues with various combinations of SATA 
HDDs, onboard and standalone
controllers, Promise and Infortrend disk arrays worked quite reliably.

-- 

./lxnt

Re[2]: Sata Sil3512 bug?; Promise SATA300 TX4

[MisterE]

Hello,

Wednesday, October 3, 2007, 10:31:17 AM, you wrote:

> Mikael Pettersson wrote:

>>>
>>> I'm thinking of replacing both 3512 controllers with a Promise SATA300
>>> TX4. Do you know if there are problems with this device?
>> 
>> (please don't top-post)
>> 
>> There are no known data-corruption issues with Promise SATA cards.
>> However, some of them, especially the 2nd generation SATA300 TX4,
>> are known to trigger intermittent error interrupts (that are dealt
>> with but may cause a speed reduction) in some systems. We're still
>> scratching our heads on that issue.
>> 

> But see this thread:

> http://marc.info/?l=linux-ide&m=119122463403033&w=2
> http://www.spinics.net/lists/linux-ide/msg14868.html

> Personally I would not recommend Promise SATA300 TX4 at the moment.


After all the problems i had with the sweex 3512 cards i returned them
to the shop and decided to buy a Sata300 TX4 (because the shop nearby
had one. Unfortunately the shops in the region don't have Highpoints)

Things looked promising when i inserted the card in both Intel D815EEA
motherboards. No problems detecting the hard drives (unlike with the 3512 cards).
With the 3512 i had LOTS of error messages and corrupt data when writing to it.
Using a separate videocard, instead of the onboard one, seemed to reduce the amount of errors.

But after some heavy reading/writing with the promise i got 2 errors. (see log file).
But i did'nt find any corrupt files. I can not reproduce the error.
I'm not sure if these are the "intermittent error interrupts" Mikael
Pettersson mentioned?

ps: as you can i see i got at the boot some errors from the boot disk
(hda). I not sure what is wrong with it. Sometimes it produce these
errors. Used a non-destructive read-write test with badblocks but no
bad sectors found. I don't know if this could influence the sata controller.

Alexander Sabourenkov can you please tell me where i can find the
"Bug is fixed in 2.6.23.1: sata_promise: port is slow to respond,
reset failed" thread you mentioned?

I also see that the driver is now at version 2.10. Is there something
really critical changed? I've tried testing with Debian stable
(2.6.18-4-686; sata_promise: 1.04) and with Debian Unstable
(2.6.22-2-686; sata_promise: 2.07). 2.6.23 is not in the repositories
yet.

So basically the question is this. Can i trust the SATA300 TX4 or
should i buy a Highpoint RocketRAID 1640/1740?. I can order such device
online but i need to be sure that it works correctly :(


-- 
Best regards,
 MisterE                            mailto:MisterE2002@zonnet.nl

Re: Sata Sil3512 bug?; Promise SATA300 TX4

[Alexander Sabourenkov]

MisterE wrote:
  > But after some heavy reading/writing with the promise i got 2 
errors. (see log file).

Log file got lost. Please post relevant parts inline.


> Alexander Sabourenkov can you please tell me where i can find the
> "Bug is fixed in 2.6.23.1: sata_promise: port is slow to respond,
> reset failed" thread you mentioned?

That would be this one:
(got split into two parts)
http://www.spinics.net/lists/linux-ide/msg14069.html
http://www.spinics.net/lists/linux-ide/msg15299.html


> 
> So basically the question is this. Can i trust the SATA300 TX4 or
> should i buy a Highpoint RocketRAID 1640/1740?. I can order such device
> online but i need to be sure that it works correctly :(
> 

Since you have the hardware, do the tests and decide for yourself.

I'd try copying one (big, preferably over 160G ) disk onto another (with 
dd) for a start,
while waiting for answers on mailing lists.


-- 

./lxnt

Re[2]: Sata Sil3512 bug?; Promise SATA300 TX4

[MisterE]

Hello Alexander,

Wednesday, October 17, 2007, 2:54:25 PM, you wrote:

> Log file got lost. Please post relevant parts inline.

Sorry, i totally forgot to include them.
I can not reproduce the errors. Last times hda did not give errors. So i'm
not sure if it is related to each other. (in the thread you mentioned
that you can't explain the fixing of problem from Peter Favrholdt, so
maybe it has indeed something to do with the libata)

ct 16 14:10:59 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Oct 16 14:10:59 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Oct 16 14:10:59 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:12:49 fileserver kernel: kjournald starting.  Commit interval 5 seconds
Oct 16 14:12:49 fileserver kernel: EXT3 FS on sda1, internal journal
Oct 16 14:12:49 fileserver kernel: EXT3-fs: mounted filesystem with ordered data mode.
Oct 16 14:13:34 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Oct 16 14:13:34 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Oct 16 14:13:34 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hdb: DMA disabled
Oct 16 14:17:21 fileserver kernel: ide0: reset: success
Oct 16 14:32:51 fileserver kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
Oct 16 14:32:51 fileserver kernel: ata1.00: (port_status 0x20080000)
Oct 16 14:32:51 fileserver kernel: ata1.00: cmd c8/00:00:77:f6:6c/00:00:00:00:00/e4 tag 0 cdb 0x0 data 131072 in
Oct 16 14:32:51 fileserver kernel:          res 50/00:00:76:f7:6c/00:00:00:00:00/e4 Emask 0x2 (HSM violation)
Oct 16 14:32:51 fileserver kernel: ata1: soft resetting port
Oct 16 14:32:51 fileserver kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Oct 16 14:32:51 fileserver kernel: ata1.00: configured for UDMA/133
Oct 16 14:32:51 fileserver kernel: ata1: EH complete
Oct 16 14:32:51 fileserver kernel: sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
Oct 16 14:32:51 fileserver kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 16 14:32:51 fileserver kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 16 14:32:51 fileserver kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 16 14:44:09 fileserver kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 16 14:48:48 fileserver kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
Oct 16 14:48:48 fileserver kernel: ata1.00: (port_status 0x20080000)
Oct 16 14:48:48 fileserver kernel: ata1.00: cmd 25/00:00:3f:d0:26/00:01:23:00:00/e0 tag 0 cdb 0x0 data 131072 in
Oct 16 14:48:48 fileserver kernel:          res 50/00:00:3e:d1:26/00:00:23:00:00/e0 Emask 0x2 (HSM violation)
Oct 16 14:48:48 fileserver kernel: ata1: soft resetting port
Oct 16 14:48:49 fileserver kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Oct 16 14:48:49 fileserver kernel: ata1.00: configured for UDMA/133
Oct 16 14:48:49 fileserver kernel: ata1: EH complete
Oct 16 14:48:49 fileserver kernel: sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
Oct 16 14:48:49 fileserver kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 16 14:48:49 fileserver kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 16 14:48:49 fileserver kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA



> Since you have the hardware, do the tests and decide for yourself.

> I'd try copying one (big, preferably over 160G ) disk onto another (with
> dd) for a start,
> while waiting for answers on mailing lists.


I can order that 1740 online, but returning something is always more
difficult. So need to be quite sure that there are'nt problems with
this highpoint.

Tonight i will try the Asus motherboard with 1 drive and much I/O. And
i will create a new array which takes 7 hours. But how often/hours do
you need to try something to prove it does not fail :P

-- 
Best regards,
 MisterE                            mailto:MisterE2002@zonnet.nl

Re: Sata Sil3512 bug?; Promise SATA300 TX4

[Peter Favrholdt]

Hi,

MisterE wrote:
> Tonight i will try the Asus motherboard with 1 drive and much I/O. And
> i will create a new array which takes 7 hours. But how often/hours do
> you need to try something to prove it does not fail :P

On one box I had problems with the SATA300 TX4 using 2.6.21 through 
2.6.22 (different versions). I have 4x500GB Seagate ES SATA drives 
connected. The system would run fine, but when put to a stress - i.e. 
loaded on all sata ports one or two ports would fail - one after the 
other. I have _always_ been able to make it fail doing:

dd if=/dev/sda of=/dev/null bs=1M &
dd if=/dev/sdb of=/dev/null bs=1M &
dd if=/dev/sdc of=/dev/null bs=1M &
dd if=/dev/sdd of=/dev/null bs=1M &

The ports would freeze before running long - e.g. in less than an hour.

This can be done without even starting the array (mdadm). Therefore no 
data corruption will happen.

The above issue was fixed by updating to vanilla 2.6.23.1.

Until then I have been running with 2.6.21-rc2 with a Mikael Petterson 
patch to force the SATA to 1.5Gbps (this could possibly be accomplished 
by jumpers on the drives as well - but I didn't try that).

I have another system (Dell PE1800 = different from the above) running 
24x7 using vanilla linux 2.6.19.5. This system has been running without 
hickups for more than a year (current uptime 135 days).


Hope this helps,

Best regards,

Peter

Re: Sata Sil3512 bug?; Promise SATA300 TX4

[Alexander Sabourenkov]

Hello.


I have done some quick tests with 2.6.23/amd64 and unfortunately, the
very same problem persists.

By the way, 8 in (port_status 0x20080000) stands for
        PDC_OVERRUN_ERR         = (1 << 19), /* S/G byte count larger
than HD requires */


Does by any chance 'S/G' here somehow relate to 'sg in the 'sg-chaining
work' there is so much talk about on the -kernel mailing list?



In a somewhat parallel development, write errors caused my (other) md
RAID-1 to lose one drive while copying data under 2.6.22
from TX4-attached drives to onboard-VIA-attached ones.

Device: VIA VT6420
00:0f.0 0104: 1106:3149 (rev 80)

Boot:

Oct 17 21:28:25 host sata_via 0000:00:0f.0: version 2.2
Oct 17 21:28:25 host ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20
(level, low) -> IRQ 17
Oct 17 21:28:25 host sata_via 0000:00:0f.0: routed to hard irq line 10
Oct 17 21:28:25 host scsi4 : sata_via
Oct 17 21:28:25 host scsi5 : sata_via

Oct 17 21:28:25 host ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Oct 17 21:28:25 host ata6.00: ATA-7: ST3200827AS, 3.AAH, max UDMA/133
Oct 17 21:28:25 host ata6.00: 390721968 sectors, multi 0: LBA48 NCQ
(depth 0/32)
Oct 17 21:28:25 host ata6.00: configured for UDMA/133

... the first two port resets:

Oct 17 23:10:50 host ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0
action 0x2
Oct 17 23:10:50 host ata6.00: (BMDMA stat 0x4)
Oct 17 23:10:50 host ata6.00: cmd ca/00:08:e7:30:00/00:00:00:00:00/e0
tag 0 cdb 0x0 data 4096 out
Oct 17 23:10:50 host res 51/84:08:e7:30:00/00:00:00:00:00/e0 Emask 0x10
(ATA bus error)
Oct 17 23:10:50 host ata6: soft resetting port
Oct 17 23:10:50 host ata6.00: configured for UDMA/133
Oct 17 23:10:50 host ata6: EH complete
Oct 17 23:10:50 host sd 5:0:0:0: [sdd] 390721968 512-byte hardware
sectors (200050 MB)
Oct 17 23:10:50 host sd 5:0:0:0: [sdd] Write Protect is off
Oct 17 23:10:50 host sd 5:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Oct 17 23:10:50 host sd 5:0:0:0: [sdd] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
Oct 17 23:10:50 host ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0
action 0x2
Oct 17 23:10:50 host ata6.00: (BMDMA stat 0x5)
Oct 17 23:10:50 host ata6.00: cmd ca/00:f8:4f:31:00/00:00:00:00:00/e0
tag 0 cdb 0x0 data 126976 out
Oct 17 23:10:50 host res 51/84:f8:4f:31:00/00:00:00:00:00/e0 Emask 0x10
(ATA bus error)
Oct 17 23:10:50 host ata6: soft resetting port
Oct 17 23:10:50 host ata6.00: configured for UDMA/133
Oct 17 23:10:50 host ata6: EH complete
Oct 17 23:10:50 host sd 5:0:0:0: [sdd] 390721968 512-byte hardware
sectors (200050 MB)
Oct 17 23:10:50 host sd 5:0:0:0: [sdd] Write Protect is off
Oct 17 23:10:50 host sd 5:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Oct 17 23:10:50 host sd 5:0:0:0: [sdd] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA

... and multiple unsuccessful port resets follow:

Oct 17 23:11:57 host ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0
action 0x2 frozen
Oct 17 23:11:57 host ata6.00: cmd 25/00:08:7f:bf:28/00:00:16:00:00/e0
tag 0 cdb 0x0 data 4096 in
Oct 17 23:11:57 host res 40/00:f8:4f:31:00/00:00:00:00:00/e0 Emask 0x4
(timeout)
Oct 17 23:12:02 host ata6: port is slow to respond, please be patient
(Status 0xd0)
Oct 17 23:12:07 host ata6: soft resetting port
Oct 17 23:12:37 host ata6.00: qc timeout (cmd 0xec)
Oct 17 23:12:37 host ata6.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Oct 17 23:12:37 host ata6.00: revalidation failed (errno=-5)
Oct 17 23:12:37 host ata6: failed to recover some devices, retrying in 5
secs
Oct 17 23:12:47 host ata6: port is slow to respond, please be patient
(Status 0xd0)
Oct 17 23:12:52 host ata6: soft resetting port
Oct 17 23:13:22 host ata6.00: qc timeout (cmd 0xec)
Oct 17 23:13:22 host ata6.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Oct 17 23:13:22 host ata6.00: revalidation failed (errno=-5)
Oct 17 23:13:22 host ata6.00: limiting speed to UDMA/133:PIO3
Oct 17 23:13:22 host ata6: failed to recover some devices, retrying in 5
secs
Oct 17 23:13:32 host ata6: port is slow to respond, please be patient
(Status 0xd0)
Oct 17 23:13:37 host ata6: soft resetting port
Oct 17 23:14:08 host ata6.00: qc timeout (cmd 0xec)
Oct 17 23:14:08 host ata6.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Oct 17 23:14:08 host ata6.00: revalidation failed (errno=-5)
Oct 17 23:14:08 host ata6.00: disabled
Oct 17 23:14:08 host ata6: EH complete
Oct 17 23:14:08 host sd 5:0:0:0: [sdd] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
Oct 17 23:14:08 host end_request: I/O error, dev sdd, sector 371769215
Oct 17 23:14:08 host raid1: sdd1: rescheduling sector 371769152
Oct 17 23:14:08 host sd 5:0:0:0: [sdd] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
Oct 17 23:14:08 host end_request: I/O error, dev sdd, sector 390379327
Oct 17 23:14:08 host md: super_written gets error=-5, uptodate=0
Oct 17 23:14:08 host raid1: Disk failure on sdd1, disabling device.

I'm unable to reproduce this on 2.6.23, so this is of historic interest
only.

-- 

./lxnt

Re: Sata Sil3512 bug?; Promise SATA300 TX4

[Tejun Heo]

Hello,

Alexander Sabourenkov wrote:
> In a somewhat parallel development, write errors caused my (other) md
> RAID-1 to lose one drive while copying data under 2.6.22
> from TX4-attached drives to onboard-VIA-attached ones.
 >
> ... the first two port resets:
> 
> Oct 17 23:10:50 host ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0
> action 0x2
> Oct 17 23:10:50 host ata6.00: (BMDMA stat 0x4)
> Oct 17 23:10:50 host ata6.00: cmd ca/00:08:e7:30:00/00:00:00:00:00/e0
> tag 0 cdb 0x0 data 4096 out
> Oct 17 23:10:50 host res 51/84:08:e7:30:00/00:00:00:00:00/e0 Emask 0x10
> (ATA bus error)
> Oct 17 23:10:50 host ata6: soft resetting port
> Oct 17 23:10:50 host ata6.00: configured for UDMA/133
> Oct 17 23:10:50 host ata6: EH complete
[--snip--]
> Oct 17 23:13:37 host ata6: soft resetting port
> Oct 17 23:14:08 host ata6.00: qc timeout (cmd 0xec)
> Oct 17 23:14:08 host ata6.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> Oct 17 23:14:08 host ata6.00: revalidation failed (errno=-5)
> Oct 17 23:14:08 host ata6.00: disabled
> Oct 17 23:14:08 host ata6: EH complete
> Oct 17 23:14:08 host sd 5:0:0:0: [sdd] Result: hostbyte=DID_BAD_TARGET
> driverbyte=DRIVER_OK,SUGGEST_OK
> Oct 17 23:14:08 host end_request: I/O error, dev sdd, sector 371769215
> Oct 17 23:14:08 host raid1: sdd1: rescheduling sector 371769152
> Oct 17 23:14:08 host sd 5:0:0:0: [sdd] Result: hostbyte=DID_BAD_TARGET
> driverbyte=DRIVER_OK,SUGGEST_OK
> Oct 17 23:14:08 host end_request: I/O error, dev sdd, sector 390379327
> Oct 17 23:14:08 host md: super_written gets error=-5, uptodate=0
> Oct 17 23:14:08 host raid1: Disk failure on sdd1, disabling device.
> 
> I'm unable to reproduce this on 2.6.23, so this is of historic interest
> only.

It might not have anything to do with the os and driver.  Some SATA 
controllers and/or drives aren't very reliable and they just fail from 
time to time.  My previous desktop was using sata_nv w/ seagate sata 
drives and was up 24/7.  I used it for like two years and during that 
time, there was single transfer error and it brought the drive down 
completely and I had to reboot and rebuild my RAID 1 array.  ISTR what's 
dead was the controller port.  IIRC, powering off and on the drive 
didn't help.

Another interesting case was first gen SATA harddrives from certain 
vendor.  After any transfer error, those drives went completely deaf. 
The only way to recover them was removing power, waiting a bit and 
reapplying it.

So, my bet for your second report is your hardware went through 
something similar as above.

Thanks.

-- 
tejun

Re[2]: Sata Sil3512 bug?; Promise SATA300 TX4

[MisterE]

Hello Peter,

Wednesday, October 17, 2007, 9:21:28 PM, you wrote:


> On one box I had problems with the SATA300 TX4 using 2.6.21 through 
> 2.6.22 (different versions). I have 4x500GB Seagate ES SATA drives 
> connected. The system would run fine, but when put to a stress - i.e. 
> loaded on all sata ports one or two ports would fail - one after the 
> other. I have _always_ been able to make it fail doing:

> dd if=/dev/sda of=/dev/null bs=1M &
> dd if=/dev/sdb of=/dev/null bs=1M &
> dd if=/dev/sdc of=/dev/null bs=1M &
> dd if=/dev/sdd of=/dev/null bs=1M &

> The ports would freeze before running long - e.g. in less than an hour.

I followed your advice and tested it. I have 4x500GB drives (western
digital Caviar SE16 WD5000AAKS). I tested it with and without jumpers
(300 and 150Gb mode). All test are done with the Asus CUSL2-C


1 :: The first run; debian 2.6.18-4-686 (stable); 300Gb [3 hours in total]:
Oct 17 18:06:12 debian kernel: ata1: no sense translation for status: 0x50
Oct 17 18:06:12 debian kernel: ata1: translated ATA stat/err 0x50/00 to SCSI SK/ASC/ASCQ 0xb/00/00
Oct 17 18:06:12 debian kernel: ata1: status=0x50 { DriveReady SeekComplete }
Oct 17 19:37:15 debian kernel: ata1: no sense translation for status: 0x50
Oct 17 19:37:15 debian kernel: ata1: translated ATA stat/err 0x50/00 to SCSI SK/ASC/ASCQ 0xb/00/00
Oct 17 19:37:15 debian kernel: ata1: status=0x50 { DriveReady SeekComplete }
Oct 17 19:42:11 debian kernel: ata3: no sense translation for status: 0x50
Oct 17 19:42:12 debian kernel: ata3: translated ATA stat/err 0x50/00 to SCSI SK/ASC/ASCQ 0xb/00/00
Oct 17 19:42:12 debian kernel: ata3: status=0x50 { DriveReady SeekComplete }
Oct 17 20:23:38 debian kernel: ata1: no sense translation for status: 0x50
Oct 17 20:23:39 debian kernel: ata1: translated ATA stat/err 0x50/00 to SCSI SK/ASC/ASCQ 0xb/00/00
Oct 17 20:23:39 debian kernel: ata1: status=0x50 { DriveReady SeekComplete }
Oct 17 20:31:38 debian kernel: ata2: no sense translation for status: 0x50
Oct 17 20:31:38 debian kernel: ata2: translated ATA stat/err 0x50/00 to SCSI SK/ASC/ASCQ 0xb/00/00
Oct 17 20:31:38 debian kernel: ata2: status=0x50 { DriveReady SeekComplete }
Oct 17 20:44:56 debian kernel: ata3: no sense translation for status: 0x50
Oct 17 20:44:56 debian kernel: ata3: translated ATA stat/err 0x50/00 to SCSI SK/ASC/ASCQ 0xb/00/00
Oct 17 20:44:56 debian kernel: ata3: status=0x50 { DriveReady SeekComplete }

2 :: Second run (1 hour); same settings:
Oct 18 09:27:47 debian kernel: ata4: no sense translation for status: 0x50
Oct 18 09:27:47 debian kernel: ata4: translated ATA stat/err 0x50/00 to SCSI SK/ASC/ASCQ 0xb/00/00
Oct 18 09:27:47 debian kernel: ata4: status=0x50 { DriveReady SeekComplete }
Oct 18 09:38:18 debian kernel: ata3: no sense translation for status: 0x50
Oct 18 09:38:18 debian kernel: ata3: translated ATA stat/err 0x50/00 to SCSI SK/ASC/ASCQ 0xb/00/00
Oct 18 09:38:18 debian kernel: ata3: status=0x50 { DriveReady SeekComplete }


3 :: After that 3 a 5 hours with the drives jumpered. No problems.


4 :: 17:15 - 18:28; 2.6.22-2-686; 300Gb

Oct 18 13:45:25 fileserver kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
Oct 18 13:45:25 fileserver kernel: ata1.00: (port_status 0x20080000)
Oct 18 13:45:25 fileserver kernel: ata1.00: cmd c8/00:08:00:e6:cb/00:00:00:00:00/e2 tag 0 cdb 0x0 data 4096 in
Oct 18 13:45:25 fileserver kernel:          res 50/00:00:07:e6:cb/00:00:00:00:00/e2 Emask 0x2 (HSM violation)
Oct 18 13:45:26 fileserver kernel: ata1: soft resetting port
Oct 18 13:45:26 fileserver kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Oct 18 13:45:26 fileserver kernel: ata1.00: configured for UDMA/133
Oct 18 13:45:26 fileserver kernel: ata1: EH complete
Oct 18 13:45:26 fileserver kernel: sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
Oct 18 13:45:26 fileserver kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 18 13:45:26 fileserver kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 18 13:45:26 fileserver kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 18 13:57:19 fileserver kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
Oct 18 13:57:19 fileserver kernel: ata2.00: (port_status 0x20080000)
Oct 18 13:57:19 fileserver kernel: ata2.00: cmd c8/00:08:00:e6:92/00:00:00:00:00/e4 tag 0 cdb 0x0 data 4096 in
Oct 18 13:57:19 fileserver kernel:          res 50/00:00:07:e6:92/00:00:00:00:00/e4 Emask 0x2 (HSM violation)
Oct 18 13:57:19 fileserver kernel: ata2: soft resetting port
Oct 18 13:57:20 fileserver kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Oct 18 13:57:20 fileserver kernel: ata2.00: configured for UDMA/133
Oct 18 13:57:20 fileserver kernel: ata2: EH complete
Oct 18 13:57:20 fileserver kernel: sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
Oct 18 13:57:20 fileserver kernel: sd 1:0:0:0: [sdb] Write Protect is off
Oct 18 13:57:20 fileserver kernel: sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Oct 18 13:57:20 fileserver kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 18 14:09:44 fileserver kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
Oct 18 14:09:44 fileserver kernel: ata1.00: (port_status 0x20080000)
Oct 18 14:09:44 fileserver kernel: ata1.00: cmd c8/00:e0:20:8d:3b/00:00:00:00:00/e6 tag 0 cdb 0x0 data 114688 in
Oct 18 14:09:44 fileserver kernel:          res 50/00:00:ff:8d:3b/00:00:00:00:00/e6 Emask 0x2 (HSM violation)
Oct 18 14:09:44 fileserver kernel: ata1: soft resetting port
Oct 18 14:09:44 fileserver kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Oct 18 14:09:44 fileserver kernel: ata1.00: configured for UDMA/133
Oct 18 14:09:44 fileserver kernel: ata1: EH complete
Oct 18 14:09:44 fileserver kernel: sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
Oct 18 14:09:44 fileserver kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 18 14:09:44 fileserver kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 18 14:09:44 fileserver kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 18 14:15:37 fileserver kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
Oct 18 14:15:37 fileserver kernel: ata3.00: (port_status 0x20080000)
Oct 18 14:15:37 fileserver kernel: ata3.00: cmd c8/00:08:00:4a:27/00:00:00:00:00/e7 tag 0 cdb 0x0 data 4096 in
Oct 18 14:15:37 fileserver kernel:          res 50/00:00:07:4a:27/00:00:00:00:00/e7 Emask 0x2 (HSM violation)
Oct 18 14:15:37 fileserver kernel: ata3: soft resetting port
Oct 18 14:15:38 fileserver kernel: ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Oct 18 14:15:38 fileserver kernel: ata3.00: configured for UDMA/133
Oct 18 14:15:38 fileserver kernel: ata3: EH complete
Oct 18 14:15:38 fileserver kernel: sd 2:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB)
Oct 18 14:15:38 fileserver kernel: sd 2:0:0:0: [sdc] Write Protect is off
Oct 18 14:15:38 fileserver kernel: sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
Oct 18 14:15:38 fileserver kernel: sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA


5 :: 2.6.22-2-686 - 2 hours with the drives jumpered. No problems.


> The above issue was fixed by updating to vanilla 2.6.23.1.

So, when running in the 150Gb mode there are no problems.

I'm going to try the same with .23(.1). I'm not really familiar with
updating the kernel. Tried it before with: http://www.debianhelp.co.uk/kernel2.6.htm
but not much success. But, i'm going to try...
I will post the results later.



-- 
Best regards,
 MisterE                            mailto:MisterE2002@zonnet.nl

Re: Sata Sil3512 bug?; Promise SATA300 TX4

[Alexander Sabourenkov]

Hello.

> 
> So, my bet for your second report is your hardware went through
> something similar as above.
> 

Thanks for the insight. Let's dismiss it then.

Back to the TX4, I tried libata-dev.git cloned at about 20:00 UTC 19.10,
  no perceived difference - parallel read from two drives causes a lot
of  errors.

dmesgs  with boot and errors are at http://lxnt.info/linux/libata-dev/

I don't know what to try next. Any ideas?

-- 

./lxnt

Re[2]: Sata Sil3512 bug?; Promise SATA300 TX4

[MisterE]

Hello Alexander,

Friday, October 19, 2007, 11:06:02 PM, you wrote:


> I don't know what to try next. Any ideas?

I'm no kernel hacker, so i'll take a shot.
I assume you have done most already...

* hardware (Tested/without/or used another: motherboard, videocard, memory,
hard drives, power supply, all other hardware)

* tried a more n00b-proof distribution. As far as i know you have all
those flags with gentoo. A mistake is easily made.

* Tested with the latest official drivers (redhat) from the Promise site. And
installing that OS on a disk. I assume they made working drivers, so
it should work with it...

* Does it work correctly with Windows?

This would be the steps i would take to determine the cause of the
problem.

Finally, my 2.6.23 kernel is done. I'm going try to install it now.
Tomorrow the results :)


-- 
Best regards,
 MisterE                            mailto:MisterE2002@zonnet.nl

Re: Sata Sil3512 bug?; Promise SATA300 TX4

[Tejun Heo]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

Alexander Sabourenkov wrote:
> Hello.
> 
>> So, my bet for your second report is your hardware went through
>> something similar as above.
>>
> 
> Thanks for the insight. Let's dismiss it then.
> 
> Back to the TX4, I tried libata-dev.git cloned at about 20:00 UTC 19.10,
>   no perceived difference - parallel read from two drives causes a lot
> of  errors.
> 
> dmesgs  with boot and errors are at http://lxnt.info/linux/libata-dev/
> 
> I don't know what to try next. Any ideas?
> 

Does the attached patch help?

-- 
tejun

[-- Attachment #2: limit-PHY-to-1.5Gbps.patch --]
[-- Type: text/plain, Size: 402 bytes --]

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 68699b3..4c93fee 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6435,6 +6435,7 @@ int sata_link_init_spd(struct ata_link *link)
 	spd = (scontrol >> 4) & 0xf;
 	if (spd)
 		link->hw_sata_spd_limit &= (1 << spd) - 1;
+	link->hw_sata_spd_limit = 1;
 
 	link->sata_spd_limit = link->hw_sata_spd_limit;
 

Re: Sata Sil3512 bug?; Promise SATA300 TX4

[Alexander Sabourenkov]

Hello.

Tejun Heo wrote:
> 
> Does the attached patch help?
> 

It does somehow force 1.5GB/s mode, and it does change the pattern of
'configured for UDMAxxx' messages that come along with errors, and it
causes the following error:

ata3: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xb t4
ata3: hotplug_status 0x10
ata3: soft resetting link
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata3.00: configured for UDMA/133
ata3: EH complete

for both drives on TX4 on startup, but read errors are still there.

dmesgs at http://lxnt.info/linux/libata-dev/patch0/

READY
[]


-- 

./lxnt

[PATCH-RFC] (was: Re: Sata Sil3512 bug?; Promise SATA300 TX4)

[Alexander Sabourenkov]

Hello.

There appears to be a hardware bug in that it chokes on scatterlist
if the last item is larger than 164 bytes.

The patch that follows fixes my problem on 2.6.22.

I can't think of a way to avoid second pass over scatterlist without
duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).


--- a/drivers/ata/sata_promise.c	2007-07-09 03:32:17.000000000 +0400
+++ b/drivers/ata/sata_promise.c	2007-10-27 17:20:03.000000000 +0400
@@ -531,6 +531,80 @@
 	memcpy(buf+31, cdb, cdb_len);
 }

+/**
+ *	pdc_qc_prep - Fill PCI IDE PRD table
+ *	@qc: Metadata associated with taskfile to be transferred
+ *
+ *	Fill PCI IDE PRD (scatter-gather) table with segments
+ *	associated with the current disk command.
+ *	Make sure hardware does not choke on it.
+ *
+ *	LOCKING:
+ *	spin_lock_irqsave(host lock)
+ *
+ */
+static void pdc_qc_prep(struct ata_queued_cmd *qc)
+{
+	struct ata_port *ap = qc->ap;
+	struct scatterlist *sg;
+	unsigned int idx;
+	const u32 SG_COUNT_ASIC_BUG = 41*4;
+
+	if (!(qc->flags & ATA_QCFLAG_DMAMAP))
+		return;
+	
+	WARN_ON(qc->__sg == NULL);
+	WARN_ON(qc->n_elem == 0 && qc->pad_len == 0);
+
+	idx = 0;
+	ata_for_each_sg(sg, qc) {
+		u32 addr, offset;
+		u32 sg_len, len;
+
+		/* determine if physical DMA addr spans 64K boundary.
+		 * Note h/w doesn't support 64-bit, so we unconditionally
+		 * truncate dma_addr_t to u32.
+		 */
+		addr = (u32) sg_dma_address(sg);
+		sg_len = sg_dma_len(sg);
+
+		while (sg_len) {
+			offset = addr & 0xffff;
+			len = sg_len;
+			if ((offset + sg_len) > 0x10000)
+				len = 0x10000 - offset;
+
+			ap->prd[idx].addr = cpu_to_le32(addr);
+			ap->prd[idx].flags_len = cpu_to_le32(len & 0xffff);
+			VPRINTK("PRD[%u] = (0x%X, 0x%X)\n", idx, addr, len);
+
+			idx++;
+			sg_len -= len;
+			addr += len;
+		}
+	}
+
+	if (idx) {
+		u32 len = ap->prd[idx - 1].flags_len;
+		if (len > SG_COUNT_ASIC_BUG) {
+			u32 addr, len;
+
+			VPRINTK("Last PRD split\n");
+			
+			len = le32_to_cpu(ap->prd[idx - 1].flags_len) - SG_COUNT_ASIC_BUG;
+			addr = le32_to_cpu(ap->prd[idx - 1].addr);
+			ap->prd[idx - 1].flags_len = cpu_to_le32(len);
+			VPRINTK("PRD[%u] = (0x%X, 0x%X)\n", idx, addr, len);
+			
+			ap->prd[idx].flags_len = cpu_to_le32(SG_COUNT_ASIC_BUG);
+			ap->prd[idx].addr = cpu_to_le32(addr + len);
+			idx++;
+			VPRINTK("PRD[%u] = (0x%X, 0x%X)\n", idx, addr + len, SG_COUNT_ASIC_BUG);
+		}
+		ap->prd[idx - 1].flags_len |= cpu_to_le32(ATA_PRD_EOT);
+	}
+}
+
 static void pdc_qc_prep(struct ata_queued_cmd *qc)
 {
 	struct pdc_port_priv *pp = qc->ap->private_data;
@@ -540,7 +614,7 @@

 	switch (qc->tf.protocol) {
 	case ATA_PROT_DMA:
-		ata_qc_prep(qc);
+		pdc_qc_prep(qc);
 		/* fall through */

 	case ATA_PROT_NODATA:

Re: [PATCH-RFC]

[Alexander Sabourenkov]

Alexander Sabourenkov wrote:
> Hello.
> 
> There appears to be a hardware bug in that it chokes on scatterlist
> if the last item is larger than 164 bytes.
> 
> The patch that follows fixes my problem on 2.6.22.
> 
> I can't think of a way to avoid second pass over scatterlist without
> duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).
> 
> 

Sorry, this was wrong patch :(. Two days looking at vendor code must
have driven me insane. Will send the correct one asap.

-- 

./lxnt

Re[2]: [PATCH-RFC]

[MisterE]

Hello Alexander,

Saturday, October 27, 2007, 3:44:51 PM, you wrote:


>> There appears to be a hardware bug in that it chokes on scatterlist
>> if the last item is larger than 164 bytes.

Can you confirm that this only will happen when running at 300Gb mode?
I have the drives jumpered and have no errors. I tested the "copy to
null" method several times with several kernel versions. I'm now in
the fase of copying all my data to the fileserver.

I'm willing to try your patch but i'm not a experienced linux guru ;)
Once i patched the kernel source (2.6.23 to 2.6.23.1) but i was stuck how
to install the updated driver....

-- 
Best regards,
 MisterE                            mailto:MisterE2002@zonnet.nl

Re: [PATCH-RFC]

[Alexander Sabourenkov]

MisterE wrote:
> 
> Can you confirm that this only will happen when running at 300Gb mode?

I confirm that without this patch errors happen on both 150 and 300
modes, on both jumpered and unjumpered drives. It seems that errors are
highly hardware/configuration dependent.

> I'm willing to try your patch but i'm not a experienced linux guru ;)

I would not advise trying this patch now if you do not experience
problems, and certainly not with any valuable data behind the controller.

-- 

./lxnt

[PATCH-RFC] Promise TX4 implement hw-bug workaround

[Alexander Sabourenkov]

Hello.
Once again,

There appears to be a hardware bug in that it chokes on scatterlist
if the last item is larger than 164 bytes. This was discovered by
reading the code of vendor-supplied driver.

The patch that follows fixes my problem on 2.6.22.

I can't think of a way to avoid second pass over scatterlist without
duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).





--- a/drivers/ata/sata_promise.c	2007-07-09 03:32:17.000000000 +0400
+++ b/drivers/ata/sata_promise.c	2007-10-27 19:12:46.000000000 +0400
@@ -531,6 +531,87 @@
 	memcpy(buf+31, cdb, cdb_len);
 }

+/**
+ *	pdc_fill_sg - Fill PCI IDE PRD table
+ *	@qc: Metadata associated with taskfile to be transferred
+ *
+ *	Fill PCI IDE PRD (scatter-gather) table with segments
+ *	associated with the current disk command.
+ *	Make sure hardware does not choke on it.
+ *
+ *	LOCKING:
+ *	spin_lock_irqsave(host lock)
+ *
+ */
+static void pdc_fill_sg(struct ata_queued_cmd *qc)
+{
+	struct ata_port *ap = qc->ap;
+	struct scatterlist *sg;
+	unsigned int idx;
+	const u32 SG_COUNT_ASIC_BUG = 41*4;
+
+	if (!(qc->flags & ATA_QCFLAG_DMAMAP))
+		return;
+	
+	WARN_ON(qc->__sg == NULL);
+	WARN_ON(qc->n_elem == 0 && qc->pad_len == 0);
+
+	idx = 0;
+	ata_for_each_sg(sg, qc) {
+		u32 addr, offset;
+		u32 sg_len, len;
+
+		/* determine if physical DMA addr spans 64K boundary.
+		 * Note h/w doesn't support 64-bit, so we unconditionally
+		 * truncate dma_addr_t to u32.
+		 */
+		addr = (u32) sg_dma_address(sg);
+		sg_len = sg_dma_len(sg);
+
+		while (sg_len) {
+			offset = addr & 0xffff;
+			len = sg_len;
+			if ((offset + sg_len) > 0x10000)
+				len = 0x10000 - offset;
+
+			ap->prd[idx].addr = cpu_to_le32(addr);
+			ap->prd[idx].flags_len = cpu_to_le32(len & 0xffff);
+			VPRINTK("PRD[%u] = (0x%X, 0x%X)\n", idx, addr, len);
+
+			idx++;
+			sg_len -= len;
+			addr += len;
+		}
+	}
+
+	if (idx) {
+		u32 len = le32_to_cpu(ap->prd[idx - 1].flags_len);
+
+		if (len > SG_COUNT_ASIC_BUG) {
+			u32 addr;
+			/* if len < 2*SG_COUNT_ASIC_BUG then last
+			   segment will be larger than next-to-last.
+			   Somewhat ugly :(
+			*/
+
+			VPRINTK("Splitting last PRD.\n");
+
+			ap->prd[idx - 1].flags_len -= cpu_to_le32(SG_COUNT_ASIC_BUG);
+			VPRINTK("PRD[%u] = (0x%X, 0x%X)\n", idx - 1, addr, SG_COUNT_ASIC_BUG);
+			
+			addr = le32_to_cpu(ap->prd[idx - 1].addr) + len - SG_COUNT_ASIC_BUG;
+			len  = SG_COUNT_ASIC_BUG;
+			ap->prd[idx].addr = cpu_to_le32(addr);
+			ap->prd[idx].flags_len = cpu_to_le32(len);
+			VPRINTK("PRD[%u] = (0x%X, 0x%X)\n", idx, addr, len);
+
+			idx++;
+		}
+
+		ap->prd[idx - 1].flags_len |= cpu_to_le32(ATA_PRD_EOT);
+	}
+}
+
 static void pdc_qc_prep(struct ata_queued_cmd *qc)
 {
 	struct pdc_port_priv *pp = qc->ap->private_data;
@@ -540,7 +621,7 @@

 	switch (qc->tf.protocol) {
 	case ATA_PROT_DMA:
-		ata_qc_prep(qc);
+		pdc_fill_sg(qc);
 		/* fall through */

 	case ATA_PROT_NODATA:
@@ -556,11 +637,11 @@
 		break;

 	case ATA_PROT_ATAPI:
-		ata_qc_prep(qc);
+		pdc_fill_sg(qc);
 		break;

 	case ATA_PROT_ATAPI_DMA:
-		ata_qc_prep(qc);
+		pdc_fill_sg(qc);
 		/*FALLTHROUGH*/
 	case ATA_PROT_ATAPI_NODATA:
 		pdc_atapi_pkt(qc);

Re: [PATCH-RFC] Promise TX4 implement hw-bug workaround

[Alan Cox]

> I can't think of a way to avoid second pass over scatterlist without
> duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).

This appears to be incomplete:

> +			VPRINTK("Splitting last PRD.\n");
> +
> +			ap->prd[idx - 1].flags_len -= cpu_to_le32(SG_COUNT_ASIC_BUG);
> +			VPRINTK("PRD[%u] = (0x%X, 0x%X)\n", idx - 1, addr, SG_COUNT_ASIC_BUG);
> +			
> +			addr = le32_to_cpu(ap->prd[idx - 1].addr) + len - SG_COUNT_ASIC_BUG;
> +			len  = SG_COUNT_ASIC_BUG;
> +			ap->prd[idx].addr = cpu_to_le32(addr);
> +			ap->prd[idx].flags_len = cpu_to_le32(len);
> +			VPRINTK("PRD[%u] = (0x%X, 0x%X)\n", idx, addr, len);
> +
> +			idx++;

What guarantees you have enough PRD entries to do this without changing
the limit in the structures ?

Otherwise looks good

Re: [PATCH-RFC] Promise TX4 implement hw-bug workaround

[Alexander Sabourenkov]

Alan Cox wrote:
>> I can't think of a way to avoid second pass over scatterlist without
>> duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).
> 
> This appears to be incomplete:
> 

[...]

> 
> What guarantees you have enough PRD entries to do this without changing
> the limit in the structures ?
> 
> Otherwise looks good

PRD entries count is 256
include/linux/ata.h:
	ATA_MAX_PRD		= 256,
	ATA_PRD_TBL_SZ          = (ATA_MAX_PRD * ATA_PRD_SZ),

drivers/ata/libata-core.c:
 ap->prd = dmam_alloc_coherent(dev, ATA_PRD_TBL_SZ, &ap->prd_dma,

sata_promise Scsi_Host declares support for half of that:

include/linux/libata.h:
LIBATA_MAX_PRD		= ATA_MAX_PRD / 2,

drivers/ata/sata_promise.c
    .sg_tablesize           = LIBATA_MAX_PRD,


PS: Vendor code has this limit at 32.

-- 

./lxnt

Re: [PATCH-RFC] Promise TX4 implement hw-bug workaround

[Alexander Sabourenkov]

Alexander Sabourenkov wrote:
> Alan Cox wrote:
>>> I can't think of a way to avoid second pass over scatterlist without
>>> duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).
>> This appears to be incomplete:
>>
> 
> [...]
> 
>> What guarantees you have enough PRD entries to do this without changing
>> the limit in the structures ?
>>
>> Otherwise looks good
> 
> PRD entries count is 256
> include/linux/ata.h:
> 	ATA_MAX_PRD		= 256,
> 	ATA_PRD_TBL_SZ          = (ATA_MAX_PRD * ATA_PRD_SZ),
> 
> drivers/ata/libata-core.c:
>  ap->prd = dmam_alloc_coherent(dev, ATA_PRD_TBL_SZ, &ap->prd_dma,
> 
> sata_promise Scsi_Host declares support for half of that:
> 
> include/linux/libata.h:
> LIBATA_MAX_PRD		= ATA_MAX_PRD / 2,
> 
> drivers/ata/sata_promise.c
>     .sg_tablesize           = LIBATA_MAX_PRD,
> 
> 
> PS: Vendor code has this limit at 32.
> 

That's an interesting question of itself. I don't know what limits PRD
count, but if it's hardware, then the driver should somehow make sure
that it gets no more than hw can handle minus one for this errata.

Right now driver declares that any hardware it supports can handle 128
PRD entries. If this is not true for any possibly existing specimen,
we're welcoming trouble.

-- 

./lxnt

Re: [PATCH-RFC] Promise TX4 implement hw-bug workaround

[Jeff Garzik]

Alexander Sabourenkov wrote:
> Alan Cox wrote:
>>> I can't think of a way to avoid second pass over scatterlist without
>>> duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).
>> This appears to be incomplete:
>>
> 
> [...]
> 
>> What guarantees you have enough PRD entries to do this without changing
>> the limit in the structures ?
>>
>> Otherwise looks good
> 
> PRD entries count is 256
> include/linux/ata.h:
> 	ATA_MAX_PRD		= 256,
> 	ATA_PRD_TBL_SZ          = (ATA_MAX_PRD * ATA_PRD_SZ),
> 
> drivers/ata/libata-core.c:
>  ap->prd = dmam_alloc_coherent(dev, ATA_PRD_TBL_SZ, &ap->prd_dma,
> 
> sata_promise Scsi_Host declares support for half of that:
> 
> include/linux/libata.h:
> LIBATA_MAX_PRD		= ATA_MAX_PRD / 2,
> 
> drivers/ata/sata_promise.c
>     .sg_tablesize           = LIBATA_MAX_PRD,

Alan's point was that the existing code will give you up to 
LIBATA_MAX_PRD entries.  After the post-virtual-merge splitting code in 
ata_fill_sg() executes, the worst case result is ATA_MAX_PRD entries.

Thus, since your code has the potential to increase the number of s/g 
entries above that, it can potentially corrupt memory, lock up the 
machine, all the wonderful things that can happen when you run off the 
end of the s/g list.

The fix is to decrease .sg_tablesize (LIBATA_MAX_PRD - 2 perhaps?) so 
that you guarantee this worst case never occurs, by guaranteeing that 
the system never sends you enough s/g entries to cause your code to go 
out of bounds.

	Jeff

Re: [PATCH-RFC] Promise TX4 implement hw-bug workaround

[Jeff Garzik]

BTW, looking at the Promise code I see

> cam_con.h:
> /* for ASIC bug, limit the last element of SG byteCount must < 32 Dword */
> #define SG_COUNT_ASIC_BUG       32
> //#define SG_COUNT_ASIC_BUG     128

	and in the code itself

> /* check PRD table, last element <= (32 Dword), fix ASIC bug */

(though the code obviously uses SG_COUNT_ASIC_BUG==32, as the first 
paste indicates)

so it seems like Promise first used 128 (32 dwords), but then backed 
down to 32 (8 dwords).

Either way, we definitely have an ASIC bug to work around, it seems...

	Jeff

Re: [PATCH-RFC] Promise TX4 implement hw-bug workaround

[Jeff Garzik]

Alexander Sabourenkov wrote:
> Jeff Garzik wrote:
>> BTW, looking at the Promise code I see
>>
>>> cam_con.h:
>>> /* for ASIC bug, limit the last element of SG byteCount must < 32
>>> Dword */
>>> #define SG_COUNT_ASIC_BUG       32
>>> //#define SG_COUNT_ASIC_BUG     128
>>     and in the code itself
>>
>>> /* check PRD table, last element <= (32 Dword), fix ASIC bug */
>> (though the code obviously uses SG_COUNT_ASIC_BUG==32, as the first
>> paste indicates)
>>
>> so it seems like Promise first used 128 (32 dwords), but then backed
>> down to 32 (8 dwords).
>>
> 
> Which version is this define from?
> 
> Both versions that are available now from their website define it at 41*4:

Mikael Pettersson wrote:
> You're looking at the old pdc-ultra2 driver. The newer unified
> sataii150-300 driver (v1.01.0.23) upped the value to 41*4.


I was looking at pdc-ulsata2_1.00.0.15.tgz, which was the latest driver 
that Promise's website gave me to when I listed "SATA300 TX4" as my product.

Sounds like that is outdated information, thanks for the correction!

	Jeff

Re: [PATCH-RFC] Promise TX4 implement hw-bug workaround

[Alexander Sabourenkov]

Jeff Garzik wrote:
> BTW, looking at the Promise code I see
> 
>> cam_con.h:
>> /* for ASIC bug, limit the last element of SG byteCount must < 32
>> Dword */
>> #define SG_COUNT_ASIC_BUG       32
>> //#define SG_COUNT_ASIC_BUG     128
> 
>     and in the code itself
> 
>> /* check PRD table, last element <= (32 Dword), fix ASIC bug */
> 
> (though the code obviously uses SG_COUNT_ASIC_BUG==32, as the first
> paste indicates)
> 
> so it seems like Promise first used 128 (32 dwords), but then backed
> down to 32 (8 dwords).
> 

Which version is this define from?

Both versions that are available now from their website define it at 41*4:


/* for ASIC bug, limit the last element of SG byteCount must <= 41 Dword */
#define SG_COUNT_ASIC_BUG       41*4
//#define SG_COUNT_ASIC_BUG     32
//#define SG_COUNT_ASIC_BUG     128


-- 

./lxnt

Re: [PATCH-RFC] Promise TX4 implement hw-bug workaround

[Alexander Sabourenkov]

Jeff Garzik wrote:
> 
> Alan's point was that the existing code will give you up to
> LIBATA_MAX_PRD entries.  After the post-virtual-merge splitting code in
> ata_fill_sg() executes, the worst case result is ATA_MAX_PRD entries.
> 
> Thus, since your code has the potential to increase the number of s/g
> entries above that, it can potentially corrupt memory, lock up the
> machine, all the wonderful things that can happen when you run off the
> end of the s/g list.
> 
> The fix is to decrease .sg_tablesize (LIBATA_MAX_PRD - 2 perhaps?) so
> that you guarantee this worst case never occurs, by guaranteeing that
> the system never sends you enough s/g entries to cause your code to go
> out of bounds.
> 

Ah, now I understand. Thanks for the explanation.

I take it something guarantees that s/g entry size can not exceed 128K.


-- 

./lxnt