Re: Installation report HP-715/64 (HIL)
Frans Pop wrote:
> On Wednesday 24 December 2008, Moritz Muehlenhoff wrote:
>>> Is it possible that someone from the debian-installer teams add this
>>> "modprobe hilkbd" somewhere to the bootup process? ...
>> Can that be considered for rc2?
>
> Theoretically that would still be possible, but it is extremely late in
> the day for such a change, especially without any detailed info about how
> *exactly* this should be implemented.
Sure.
> Questions that come to mind are:
> - why doesn't the kernel/udev autoload this module?
Probably yes, but as we discussed last time, this needs to be
implemented. I already looked into implementing it, but sadly it isn't
that easy to understand all the flow between kernel and userspace and
how to handle it then. So, it's still on my plan to do it, but there
were some other kernel crashes which needed to be fixed before (e.g. bug
478717).
Anyway, adding the needed stuff to udev will probably be too late for
lenny anyway.
> - is there any way to recognize whether the module should be loaded or
> not (most hppa installs are headless)?
> - if it's decided to load the module unconditionally for the installer,
> it may still be possible to only do so when needed for the installed
> system; can this be recognized somehow?
I started up my system to find a way to detect if the hilkbd module
should be loaded or not. Sadly I didn't find a clean way via sysfs or
procfs. The only ugly solution I found is to grep the dmesg for the
string "HIL", as the HIL controller is then printed while doing the
inventory scan:
: Searching for devices...
: Found devices:
: 1. Mirage Jr GSC Builtin Graphics at 0xf8000000 [1] ...
: ...
: 13. Mirage Jr Wax HIL at 0xf0201000 [5/0/1]
: ...
But even if this module is loaded on a system which does not has HIL
this wouldn't hurt in any way, as the driver
(drivers/input/keyboard/hilkbd.c) is constructed that way that it only
gets initialized if it finds the HIL controller itself. This means that
the linux kernel only calls the initialization function hil_init_chip()
if the system has the HIL controller and it has been sucessfully matched
against the contents of hil_tbl[].
So, modprobing for hilkbd will never break any non-HIL systems.
I know you added some unconditional modprobes for some specifc modules
for parisc (I forgot which ones, I think SCSI and such) in the past.
My proposal would be to just add the modprobe for hilkbd there blindly
as well.
> - is loading the module for the installed system needed for the initrd
> too (would be my guess), or just for the final system?
Both.
> We have repeatedly indicated in the debian-hppa list that the D-I team
> needs porter support and this is *exactly* the kind of issue for which
> knowledgable porter support is needed. I even had a long discussion with
> Helge himself about that.
Yes, I know and I've not forgotten that.
http://www.archivum.info/linux.debian.ports.hppa/2008-06/msg00038.html
http://lists.debian.org/debian-hppa/2008/05/msg00037.html
> As this issue has been known for ages my first reaction is that it is too
> late for RC2 and for Lenny. However, *if* porters work with the D-I team
> to get the questions above answered the change could be implemented early
> for squeeze and, after testing, it could then be considered for
> backporting for a stable update release.
I fully can understand your reaction here.
Of course it would be sad if machines with HIL keyboards are _only_
installable via serial console then, but since they are quite old I
don't assume there will be so many people trying lenny on parisc with
HIL at all.
On the other side, if you would add this modprobe I would try the lenny
installer at once on 4 very different machines to rule out any problems
due to the modprobe:
- 715/64 with HIL only
- B160L, no HIL, PS/2 keyboard/mouse
- C3000 (32 and 64bit kernel), no HIL, USB keyboard/mouse only
- Tadpole parisc laptop, PS/2 keyboard/mouse only
Best regards,
Helge
Reply to: