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

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



Hi Simon,

On Monday 30 June 2008, Simon McVittie wrote:
> Comments/Problems:
> PALO isn't very intuitive, but I eventually got the machine netbooted
> using the serial console and the built-in Tulip network interface.

> 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.

> A normal network boot stopped with this error:
>
> tg3.c:v3.86 (November 9, 2007)
> tg3: (0000:30:00.0) phy probe failed, err -19
> tg3: Problem fetching invariants of chip, aborting.
>
> followed by a system alert from the HP's firmware.
>
> Anyway, inserting "tg3.blacklist=true" into the command line avoids the
> tg3 failure, after which the machine works fine. Presumably this is
> because the tg3's firmware is non-free and therefore missing. It'd be
> nice if the kernel wouldn't even try to load a module that will cause
> an abort, though.

Hmm. netboots using NICs that require firmware are probably always going 
to be problematic. 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. And you say that 
the actual complaint is from the HP's firware, i.e. from the hardware...

How did you do the installation? I guess using the NIC from DEC (tulip 
driver). Lucky that was available...

Not sure what to do with this report. I'd say it was a successful install 
as D-I offers all workarounds/alternatives needed to succeed.

The tg3 issue is clearly kernel related, but given that this is hppa I 
doubt reassigning to Debian kernel packages is very useful.
Reporting the issue upstream (netdev and parisc kernel lists) and 
following up there would probably be the most effective.

Cheers,
FJP



Reply to: