Bug#488590: [hppa] blacklisting tg3 was needed to avoid kernel failure
On Monday 30 June 2008, Simon McVittie wrote:
> 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.
Right. So palo (or the firmware) is smarter than just plain symlink.
Strange that explicitly setting 0/vmlinux64 did not work then.
My own hppa supports both 32-bit and 64-bit kernels and will use 32-bit by
default if I leave 0/linux. But if I change it to 0/vmlinux64 it will
boot the 64-bit kernel correctly.
Are you sure there wasn't a typo?
If you want to persue this, asking on debian-hppa is probably more
effective than the debian-boot list.
> 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).
Right. That's why I was reluctant to reassign based on available info.
If anything it is a kernel issue. But kernel issues, especially for
"weird" arches are in practice better discussed directly with upstream
kernel developers than reassigned to Debian kernel packages.
> > 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.
Yes, obviously if you have an alternative you can work around that.
Another interesting data point could be if you blacklist the module, then
copy the firmware onto the machine later and then try to manually
modprobe the module.
Cheers,
FJP
Reply to: