Bug 406636

Created attachment 226147 [details]
Console 1 booting with standard installation kernel

Created attachment 226148 [details]
Console 4 booting with standard installation kernel

Created attachment 226149 [details]
Console 1 booting with no ACPI or safe settings

Created attachment 226150 [details]
Console 4 booting with no ACPI or safe settings

In the meantime I replaced my Mainboard by a MSI K9N Neo-F V3 with NForce 560 chipset, latestBIOS version 2.6. Originally the behavoiur was the same.

After playing with BIOS settings I found out that enabling HPET in the BIOS makes it safely boot into the installation system if all USB devices are disconnected.

so it works properly if you enable HPET?

If you later plug a USB device in after boot, what happens?

> so it works properly if you enable HPET?
Yes, I can boot into the installation system and everything appears to work fine until it enters the partitioning/formatting step. This consistently always crashes. Since I need to install the 64bit system on a free 11GB partition of my running system I could not try "green field" partitioning.
So unfortunately I am still not able to install.

> If you later plug a USB device in after boot, what happens?
I plugged a webcam into the running installation system. <Alt>F4 console shows that it was recognized. However, I get a warning "cannot enumerate device at hub...". This warning seems to be the last message before abort when I try to boot into the installation system with webcam plugged in.

The attachment from comment #2 has a crash in the libata code. Assigning to Tejun.

This is super strange.  Here's the offending function upto the crashing point.

int ata_std_softreset(struct ata_link *link, unsigned int *classes,
		      unsigned long deadline)
{
	struct ata_port *ap = link->ap;
	unsigned int slave_possible = ap->flags & ATA_FLAG_SLAVE_POSS;
	unsigned int devmask = 0;
	int rc;
	u8 err;

	DPRINTK("ENTER\n");

	if (ata_link_offline(link)) {
		classes[0] = ATA_DEV_NONE;
		goto out;
	}

	/* determine if device 0/1 are present */
	if (ata_devchk(ap, 0))
		devmask |= (1 << 0);
	if (slave_possible && ata_devchk(ap, 1))
		devmask |= (1 << 1);

	/* select device 0 again */
	ap->ops->dev_select(ap, 0);
        ^^^^^^^
Kernel dies while trying to dereference ops from ap.

  48 8b 43 08             mov    0x8(%rbx),%rax

%rbx contains the address of ap and the offset of ->ops is 8.  According to the register dump, %rbx is seemingly legit 0xffff81012e67800 far away from the faulted address 0xd9814f5a.  %ebx is also dereferenced earlier in the function to determine slave_possible (offset 24), so it's highly doubtful the above code is the actual offender.

The interesting thing is that none of the GPRs contains anything near the fault address and even if the reported EIP is incorrect for some mysterious reason, I can't find any instruction which can cause dereference of the faulted address nearby.

Combined with the reported random behavior on SL103 and other weirdness including the fact that the OOPS goes away in safe setting, I don't think it's much lower level problem.  Maybe things like dirty SMM trick gone wrong?

Aieee... s/I don't think/I think/ in the last paragraph.

I gave up with this computer and Linux and sold it to my brother in law who tried to install Windows Vista on it - installation always terminated with a blue screen. Finally we removed two of the 4 memory modules and installation worked. We got the two modules replaced by our computer dealer, installed them and it still worked. Also openSUSE 11.1 beta 5 life system 64 bit boots and runs without any problem on this system now.

As reported previously (bug 358386) I ran memtest86 over night for 16 hours (12 passes) with this memory without any indication of memory problems.

From my point of view this bug can be closed.

Thanks a lot for the update.  Resolving as INVALID.