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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
