[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#488590: [hppa] blacklisting tg3 was needed to avoid kernel failure



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 30 Jun 2008 at 02:15:23 +0200, Frans Pop wrote:
> On Monday 30 June 2008, Simon McVittie wrote:
> > PALO reports that the boot image contains 0/vmlinux32, 0/vmlinux64 and
> > 0/ramdisk, but that it will try to boot 0/linux - however, it turns out
> > that editing the command line to start with 0/vmlinux64 causes failure,
> > and leaving it as 0/linux succeeds. No idea why this is the case.
> 
> That seems simple: 0/linux is a symlink (or similar) to 0/vmlinux32, so 
> apparently this system supports 32-bit kernels, but not 64-bit kernels.

It's a 64-bit machine and I'm fairly sure I saw a PALO message about "image
does not end with 32 or 64, guessing 64-bit" during the successful boot.
It certainly ended up with a 64-bit kernel installed after d-i finished:

smcv@club:~$ uname -a
Linux club 2.6.24-1-parisc64-smp #2 SMP Sat May 10 21:58:37 UTC 2008 parisc64 GNU/Linux

I may have just been misunderstanding the PALO prompts. 0/linux is
selected by default, and the PALO boot would have worked without any alteration
if I hadn't also needed to blacklist the tg3 driver.

It occurs to me that the fact that tg3 sometimes needs firmware might even be
a red herring - we don't know for sure that that was the reason. The error
code reported is -19 (19 is ENODEV if that's any help).

> Hmm. netboots using NICs that require firmware are probably always going 
> to be problematic.

I wasn't. The machine has 3 NICs: a built-in Tulip and a pair of PCI
tg3s. The Tulip is the one that the firmware uses to netboot, so
that's what I was using for the whole install. The tg3s are still
inoperative, in fact - I haven't researched whether they can
be made to work (the machine doesn't particularly need them).

> And in this case it's not even clear who's at fault. 
> AFAIK the kernel will normally survive not being able to load firmware: 
> the module will be loaded, but the device not enabled.

Not in this case, apparently!

I suppose if these tg3 cards are compatible with other architectures, moving
one or both to an i386 would provide an interesting data point... are
PCI cards usually expected to be portable between architectures?

Regards,
    Simon
-----BEGIN PGP SIGNATURE-----

iD8DBQFIaDknWSc8zVUw7HYRAmiYAJ4pYUIimNarb5laj772OhdCUJWRJwCghgmP
LPWSHAxCqiF6p2kgCGYQjGw=
=8r5m
-----END PGP SIGNATURE-----



Reply to: