Hi all,
I finally got our tyan s2891 to boot LinuxBIOS (the ck804 chipset can't emulate SATA disks as IDE, so you need linux-as-a-bootloader + kexec to make it boot), but it turns out there are some issues with SATA.
This machine has 4 sata ports, to three of which a drive is connected. All drives are identical.
I'm testing using a stock 2.6.22.6, 64 bit, no special boot parameters.
When booted into the proprietary BIOS, all three drives are properly and swiftly detected during boot.
There is a bit of confusion: the Linux kernel sees sata controller 1 as the second controller, and sata controller 2 as the first.
The drives are physically connected to sata controller 1 (drive 1,2) and sata controller 2 (drive 3). Position 4 on sata controller 2 is empty.
The kernel sees the drives as controller 1 position 2, and controller 2 position 3,4.
When booting with LinuxBIOS, only one of the drives is detected. (as it so happens, drive 3 on sata controller 2). The drive in position 4 on controller 2 is half detected as you'll see in the logs - the drive type is read out, but detection times out.
The drive at position 2 on controller 1 is not detected at all.
I have saved boot logs, lspci -vvvnx, lspci, lshw and x86info -mp output, all of which you can find here:
http://ward.vandewege.net/s2891/
The linuxbios boot log is somewhat complicated - you'll see the machine boots a stripped-down 2.6.22.2 first (from rom, LAB), and then kexecs into a full-fledged 2.6.22.6.
The system does boot eventually, but only because those 3 drives happen to be configured as software raid-1. It also takes a long time for the system to come up, because the sata detection on the drive in position 4 times out for both kernels.
Any thoughts?
Thanks, Ward.
On 09/24/2007 03:41 PM, Ward Vandewege wrote:
Any thoughts?
I have s2892 and Sun Ultra40, which have ck804 too. Linux can only detect one hard drive per SATA controller. The second drive is either undetected or times out. On s2892, some HD types, presumably all SATA-II, (Hitachi HDS7280SA for instance), are detected at boot time, but miserably fail later, with lots of log messages from the kernel driver. I compared the PCI configuration registers (other than BARs, MSI, etc.) left by LinuxBIOS and the factory BIOS: they were different.
Roman
On 9/24/07, Roman Kononov kononov@dls.net wrote:
On 09/24/2007 03:41 PM, Ward Vandewege wrote:
Any thoughts?
I have s2892 and Sun Ultra40, which have ck804 too. Linux can only detect one hard drive per SATA controller. The second drive is either undetected or times out. On s2892, some HD types, presumably all SATA-II, (Hitachi HDS7280SA for instance), are detected at boot time, but miserably fail later, with lots of log messages from the kernel driver. I compared the PCI configuration registers (other than BARs, MSI, etc.) left by LinuxBIOS and the factory BIOS: they were different.
It is possible that the changed BIOS settings are a bug fix we don't know about. Can we get a list of differences?
ron
On 09/24/2007 07:42 PM, ron minnich wrote:
On 9/24/07, Roman Kononov kononov@dls.net wrote:
I have s2892 and Sun Ultra40, which have ck804 too. Linux can only detect one hard drive per SATA controller. The second drive is either undetected or times out. On s2892, some HD types, presumably all SATA-II, (Hitachi HDS7280SA for instance), are detected at boot time, but miserably fail later, with lots of log messages from the kernel driver. I compared the PCI configuration registers (other than BARs, MSI, etc.) left by LinuxBIOS and the factory BIOS: they were different.
I just recalled that the Hitachi drives, which failed later, were indeed connected to the channel 0 on s2892. On Sun Ultra40, only the second controller detected a channel 0 Hitachi drive. The first controller was dead. The channel 1 never worked with any drives on either MB. Western Digital drives have been fine in any channel 0. The phy is misconfigured.
It is possible that the changed BIOS settings are a bug fix we don't know about. Can we get a list of differences?
Attached.
Roman
On Mon, Sep 24, 2007 at 05:42:02PM -0700, ron minnich wrote:
On 9/24/07, Roman Kononov kononov@dls.net wrote:
On 09/24/2007 03:41 PM, Ward Vandewege wrote:
Any thoughts?
I have s2892 and Sun Ultra40, which have ck804 too. Linux can only detect one hard drive per SATA controller. The second drive is either undetected or times out. On s2892, some HD types, presumably all SATA-II, (Hitachi HDS7280SA for instance), are detected at boot time, but miserably fail later, with lots of log messages from the kernel driver. I compared the PCI configuration registers (other than BARs, MSI, etc.) left by LinuxBIOS and the factory BIOS: they were different.
It is possible that the changed BIOS settings are a bug fix we don't know about. Can we get a list of differences?
The tyan s2891 lspci's etc I made yesterday are here:
http://ward.vandewege.net/s2891/
This is the proprietary BIOS (sata channel 0):
0000:00:07.0 0101: 10de:0054 (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: 10f1:2891 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin A routed to IRQ 23 Region 0: I/O ports at 1440 [size=8] Region 1: I/O ports at 1434 [size=4] Region 2: I/O ports at 1438 [size=8] Region 3: I/O ports at 1430 [size=4] Region 4: I/O ports at 1410 [size=16] Region 5: Memory at dd002000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: de 10 54 00 07 00 b0 00 f3 85 01 01 00 00 00 00 10: 41 14 00 00 35 14 00 00 39 14 00 00 31 14 00 00 20: 11 14 00 00 00 20 00 dd 00 00 00 00 f1 10 91 28 30: 00 00 00 00 44 00 00 00 00 00 00 00 0b 01 03 01
0000:00:08.0 0101: 10de:0055 (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: 10f1:2891 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin A routed to IRQ 22 Region 0: I/O ports at 1458 [size=8] Region 1: I/O ports at 144c [size=4] Region 2: I/O ports at 1450 [size=8] Region 3: I/O ports at 1448 [size=4] Region 4: I/O ports at 1420 [size=16] Region 5: Memory at dd003000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: de 10 55 00 07 00 b0 00 f3 85 01 01 00 00 00 00 10: 59 14 00 00 4d 14 00 00 51 14 00 00 49 14 00 00 20: 21 14 00 00 00 30 00 dd 00 00 00 00 f1 10 91 28 30: 00 00 00 00 44 00 00 00 00 00 00 00 0a 01 03 01
And this is linuxBIOS (note how the detected revision is different!):
0000:00:07.0 0101: 10de:0054 (rev a3) (prog-if 85 [Master SecO PriO]) Subsystem: 10f1:2891 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin A routed to IRQ 23 Region 0: I/O ports at 3050 [size=8] Region 1: I/O ports at 3090 [size=4] Region 2: I/O ports at 3060 [size=8] Region 3: I/O ports at 30a0 [size=4] Region 4: I/O ports at 3030 [size=16] Region 5: Memory at fd102000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [b0] Message Signalled Interrupts: 64bit+ Queue=0/2 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [cc] #08 [a802] 00: de 10 54 00 07 00 b0 00 a3 85 01 01 00 00 00 00 10: 51 30 00 00 91 30 00 00 61 30 00 00 a1 30 00 00 20: 31 30 00 00 00 20 10 fd 00 00 00 00 f1 10 91 28 30: 00 00 00 00 44 00 00 00 00 00 00 00 00 01 03 01
0000:00:08.0 0101: 10de:0055 (rev a3) (prog-if 85 [Master SecO PriO]) Subsystem: 10f1:2891 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin A routed to IRQ 22 Region 0: I/O ports at 3070 [size=8] Region 1: I/O ports at 30b0 [size=4] Region 2: I/O ports at 3080 [size=8] Region 3: I/O ports at 30c0 [size=4] Region 4: I/O ports at 3040 [size=16] Region 5: Memory at fd103000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: de 10 55 00 07 00 b0 00 a3 85 01 01 00 00 00 00 10: 71 30 00 00 b1 30 00 00 81 30 00 00 c1 30 00 00 20: 41 30 00 00 00 30 10 fd 00 00 00 00 f1 10 91 28 30: 00 00 00 00 44 00 00 00 00 00 00 00 00 01 03 01
Thanks, Ward.
On Mon, Sep 24, 2007 at 07:38:10PM -0500, Roman Kononov wrote:
On 09/24/2007 03:41 PM, Ward Vandewege wrote:
Any thoughts?
I have s2892 and Sun Ultra40, which have ck804 too. Linux can only detect one hard drive per SATA controller. The second drive is either undetected or times out. On s2892, some HD types, presumably all SATA-II, (Hitachi HDS7280SA for instance), are detected at boot time, but miserably fail later, with lots of log messages from the kernel driver. I compared the PCI configuration registers (other than BARs, MSI, etc.) left by LinuxBIOS and the factory BIOS: they were different.
That sounds pretty much exactly like what I'm seeing (barring the failing later on after boot - but that could be drive dependent).
I'm testing with Seagate 750G drives.
Did you also see the pci device revision of the SATA controllers change after going to LinuxBIOS?
Thanks, Ward.
this is a known problem...
Someone found that on Tyan S488X.
YH
On Tue, Sep 25, 2007 at 12:28:48PM -0700, yhlu wrote:
this is a known problem...
Someone found that on Tyan S488X.
Is there also a solution? Or who should we talk to for a solution?
Thanks, Ward.
On 9/25/07, Ward Vandewege ward@gnu.org wrote:
On Tue, Sep 25, 2007 at 12:28:48PM -0700, yhlu wrote:
this is a known problem...
Someone found that on Tyan S488X.
Is there also a solution? Or who should we talk to for a solution?
some bits in ck804_early_setup_car.c...
YH
On 9/25/07, yhlu yinghailu@gmail.com wrote:
this is a known problem...
Someone found that on Tyan S488X.
and solved it? Or just discovered it? I don't understand.
ron
On 9/25/07, ron minnich rminnich@gmail.com wrote:
On 9/25/07, yhlu yinghailu@gmail.com wrote:
this is a known problem...
Someone found that on Tyan S488X.
and solved it? Or just discovered it? I don't understand.
I was supposed to fix that problem..but doesn't have time to compare these bits...
but it seems after i'm done with ck804 support, it was working with all ports...
YH
On Tue, Sep 25, 2007 at 12:35:44PM -0700, yhlu wrote:
On 9/25/07, Ward Vandewege ward@gnu.org wrote:
On Tue, Sep 25, 2007 at 12:28:48PM -0700, yhlu wrote:
this is a known problem...
Someone found that on Tyan S488X.
Is there also a solution? Or who should we talk to for a solution?
some bits in ck804_early_setup_car.c...
So... do you or someone else have access to the CK804 datasheets (assuming they are NDA'd) to figure out which bits?
Thanks, Ward.
-
Roman Kononov -
ron minnich -
Ward Vandewege -
yhlu