Bug 12083

Created attachment 18972 [details]
Boot logs

Created attachment 18973 [details]
System lspci

Hmmm, JMB ahci controller is reporting PHY online but is not responding to init sequence.  Is anything connected to JMB ports?  If not, does connecting a device there make any difference?

PATA is controlled by the jmicron ship and there is one pata disk in the system. But I don't think the pata bit depends on the same kernel driver (however that does mean I can't disable this ship to workaround the problem)

Gigabyte has done weird stuff with it's sata bios, I wouldn't connect anything I care about there and right now I don't have any spare to test with :( Somehow windows does not complain about it

Please note that while there in nothing on the jmicron-controlled sata ports, they are really Sil5723 ports with the jmicron ship acting as a sort of bridge

Yeah, those JMB SATA ports are causing trouble.  What did they do to it?  We might need to put the board under blacklist or something.

Okay, they put two 5723's there.  5723s are really nice when they're in native Port Multiplier mode but it seems they have fixed it to some pseudo device mode.  Can you diddle with the smart backup BIOS options and whether changing it makes the ahci driver act any differently?  If the device is in PMP mode, the driver will be able to discover both downstream ports (ie. four ports in total) connected to the JMB ahci.

"The ICH10R Southbridge controls six of the SATA ports with a Gigabyte SATA2 controller onboard to support the other four SATA ports. The Gigabyte SATA2 chip controls the IDE connector and has two Sil5723 chips to support the Smart Backup feature of this motherboard. Smart Backup sets up a RAID1 mirror with the primary hard drive partition when another HDD is plugged into one of the four GS ports. Smart Backup works independently of the primary RAID partition."

"GIGABYTE’s Smart Backup allows users to connect up to 4 Serial ATA devices for effortless RAID data protection. Dual onboard RAID controller chips automatically configure RAID setup without user intervention, making it easier than ever for users to enjoy enhanced data transfer performance, low CPU utilization, real-time backup on-the-fly and protection against HDD failure."

seems some kind of firmware-controlled mad auto-raid for non-tech people

(In reply to comment #6)
> Can you diddle with the smart backup BIOS options and whether changing
> it makes the ahci driver act any differently?

There are two smart backup settings in the bios:
1. Smart Backup Function
2. Smart Backup Initial

They were both disabled

The first one is the backup logic, the second one is to force a 5723 mode change when new disks has been plugged in (after which the system reboots and resets the setting to "disabled").

I set Smart Backup Function to "all ports" (you can activate only half the ports if you want) and Smart Backup Initial to "enabled"

Won 10s more of bios init time

Didn't change a thing for Linux

Created attachment 18992 [details]
Boot logs

Just in case, the boot logs with "Smart Backup Function" set to "All ports" after a "Smart Backup Initial"

Didn't notice any big change

Aiee... I'll contact SIMG and try to reproduce the problem with the reference 5723 I have around.  Thanks.

Any news here?

SIMG hasn't replied yet.  I'll ping them again.

SIMG responded and I tried to reproduce the problem with my My 5744's (mostly similar but it has USB connection too) but no matter which configuration they are in or whether disks are attached or not, they behave correctly.

Can you please try to connect harddrives to the affected ports and see whether anything changes?

I've been trying to reproduce the problem without much success yet.  SIMG says it could be dependent on the firmware version.  I'll report when I know more.

Unfortunately, my hardware is not really adapted to this kind of test.

I have 2 sata disks. There are 4 gigabyte sata ports. Even if I bought new disks the 400W PSU would probably not support 7 disks. And then there is only place for three disks in the enclosure in the first place (the third one is an old PATA windows disk I don't use very often). Plus it's a compact enclosure where you always risk cutting fingers or breaking hardware when trying to change the hardware setup.

If I plug the existing sata disks in the gigabyte sata ports it's likely to activate the stupid auto-backup feature, resulting in data loss.

I'm pretty sure plugging one disk in the gigabyte sata port does not work, I tested it when assembling the case and IIRC there were some boot problems (with hindsight, I was lucky the firmware crap didn't try to change the disk content)

I should have backups. To make them I need to restore the dvd writer to functionality (it does not work with the new board, and I haven't have the time to find out if it's a userspace, kernelspace, or hardware-side failure, and I've exhausted my store of blank disks trying to test it).

So, to make things short, it's not so easy to do what you ask with this hardware. If it really helps I may try to do it sometime next week,

In the meanwhile it seems Gigabyte is using the same ship in all its current boards.

I have the same problem, same hardware, and sent a mail to gigabyte pointing to this kernel bug, they might be able to provide some informations.

Seems fixed in 2.6.30 rc kernels

It's back starting with kernel-0:2.6.30-1.fc12.x86_64 at least. So now I will fill it as regression

Can you please attach the output dmidecode?

Created attachment 22142 [details]
dmidecode output

as requested

There's a dup bug and I attached a test patch there.  I'm marking this one as duplicate.  Can you please add yourself to bko#13551 and test the patch attached there?  Thanks.

*** This bug has been marked as a duplicate of bug 13551 ***