Bug#787794: lifimage fails to successfully boot on hppa
In this case you could try to add to the kernel command line (at the IPL prompt) one (or both) of: hp_sdc.blacklist=yes hp_sdc.no_hpsdc=1 Awesome! hp_sdc.no_hpsdc=1 does the trick. Thanks much for the great help! Great, but I still think blacklisting the machine in the driver is the better way :-) Helge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Hi Alex, Anyway, please let me know if you're going to make no_hpsdc=1 parameter work some way. The debian installer allows you to set such values on the kernel command line: modulename.blacklist=yesor modulename.parametername=value In this case you could try to add to the kernel command line (at the IPL prompt) one (or both) of: hp_sdc.blacklist=yes hp_sdc.no_hpsdc=1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Helge Deller del...@gmx.de: Hi Alex, Hi Helge Anyway, please let me know if you're going to make no_hpsdc=1 parameter work some way. The debian installer allows you to set such values on the kernel command line: modulename.blacklist=yesor modulename.parametername=value In this case you could try to add to the kernel command line (at the IPL prompt) one (or both) of: hp_sdc.blacklist=yes hp_sdc.no_hpsdc=1 Awesome! hp_sdc.no_hpsdc=1 does the trick. Thanks much for the great help! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Helge Deller del...@gmx.de: Hi Lausgans, (is that your real name? :-)) Hi Helge! No, I'm Alexander :-) Can you please check this image next? It does not includes the driver so we should be able to see if it's really HP SDC driver related: ftp://ftp.debian-ports.org/debian-cd/hppa/debian-8.0/lifimage_mini_without_hpsdc Thank you! This one boots just fine. The installer screen shows on as expected. Great! So, HP SDC is the culprit! The other reason could be, that the driver isn't automatically included when the new kernel initrd is generated when you install a new debian kernel. You're right. I've unpacked generated initrd, and hp_sdc.ko is not there while it is in the /lib/modules... Which is actually a bug, because for machines which need HP SDC (for HIL keyboards/mice) it's now missing :-( Wondering why no_hpsdc=1 doesn't disable it. I think I need to recheck that coding later when we know more... Would be much appreciated, as it looks like it is whats needed in my rare case :-) Maybe the easiest way is to simply blacklist the 712 in the driver itself? Looking at the pictures of the back of a 712 (e.g. http://eintr.net/systems/hp/hp712-100/) it seems it doesn't has a HIL port anyway, so the driver could just refuse to load. Can you confirm that your 712 has no HIL port at the rear or front? It has no HIL ports (backplane has only PS/2 ports and looks same to other 712 backside images on the Internet). But please don't blacklist! Openpa.net mentions that 712s have no HIL bus. I don't know the history of this particular machine, maybe it's an engineering sample or like that. I also don't see an error reports of HP SDC driver failing on any machine like on mine (in infinite loop). Looking at how HP SDC fails on mine it maybe that the HIL bus is not terminated / grounded / whatever else. So I don't think there is a sense in blacklisting some ID. Plus some other user may have some machine with same HIL chip, but actually working and having HIL periphery attached to it. So could you please just ensure that no_hpsdc=1 parameter works instead? This will help me a lot. It will also help anyone having some fatal issue with SDC driver to successfully boot without invasive touches. If yes, I'll try to come up with a kernel patch for you to test. Helge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Maybe the easiest way is to simply blacklist the 712 in the driver itself?
But please don't blacklist!
Openpa.net mentions that 712s have no HIL bus. I don't know the
history of this particular machine, maybe it's an engineering sample
or like that. I also don't see an error reports of HP SDC driver
failing on any machine like on mine (in infinite loop).
Looking at how HP SDC fails on mine it maybe that the HIL bus is not
terminated / grounded / whatever else.
So I don't think there is a sense in blacklisting some ID. Plus some
other user may have some machine with same HIL chip, but actually
working and having HIL periphery attached to it.
None of the 712 machines has a functional HIL.
Just look at your latest dmesg:
[1.34] Found devices:
[1.376000] 1. Gecko 100 GSC Core Graphics at 0xf800 [1] { 10, 0x0,
0x01d, 0x00085 }
[1.48] 2. Gecko 100 Core BA at 0xf010 [2] { 11, 0x0, 0x01d, 0x00081
}
[1.572000] 3. Gecko 100 Core SCSI at 0xf0106000 [2/0/1] { 10, 0x0, 0x01d,
0x00082 }
[1.668000] 4. Gecko 100 Core LAN (802.3) at 0xf0107000 [2/0/2] { 10, 0x0,
0x01d, 0x0008a }
[1.776000] 5. Gecko 100 Core RS-232 at 0xf0105000 [2/0/4] { 10, 0x0, 0x01d,
0x0008c }
[1.876000] 6. Gecko 100 Core Centronics at 0xf0102000 [2/0/6] { 10, 0x0,
0x01d, 0x00074 }
[1.98] 7. Gecko 100 Audio at 0xf0104000 [2/0/8] { 10, 0x0, 0x01d,
0x0007b }
[2.072000] 8. Gecko 100 Core PC Floppy at 0xf010a000 [2/0/10] { 10, 0x0,
0x01d, 0x00083 }
[2.176000] 9. Gecko 100 Core PS/2 Port at 0xf0108000 [2/0/11] { 10, 0x0,
0x01d, 0x00084 }
[2.28] 10. Gecko 100 Core PS/2 Port at 0xf0108100 [2/0/12] { 10, 0x0,
0x01d, 0x00084 }
[2.384000] 11. Gecko 100 Core BA at 0xf050 [6] { 11, 0x0, 0x01d,
0x00081 }
[2.484000] 12. Gecko 100 (712/100) at 0xfffbe000 [8] { 0, 0x0, 0x602,
0x4 }
[2.844000] 13. Memory at 0xfffbf000 [9] { 1, 0x0, 0x039, 0x9 }
No HIL in here.
Nevertheless, the driver was written that it will detect HP SDC chips
independent of the
inventory. I assume HP planned once to integrate HIL into 712, but just stayed
with PS/2
ports instead. Parts of the hardware was still left in the machine though, but
simply
does not show up in the inventory and as such HP-UX will probably not try to
load the driver.
And, I don't think there is any other HP 712 user beside you out there nowadays.
So, I still think the only clean and simple way is to just blacklist HIL on 712 machines.
So could you please just ensure that no_hpsdc=1 parameter works
instead? This will help me a lot. It will also help anyone having some
fatal issue with SDC driver to successfully boot without invasive
touches.
That's not an easy task. The problem is, that the HP SDC driver is a module and
no_hpsdc=1 is a module parameter. At bootup udev will automatically load the
hp_sdc
driver and I see no way to hand over a kernel parameter to it for this driver.
And, such an old machine doesn't justify for modifications in the debian
installer
just to make it somehow work.
So, the only way I see is to blacklist it. But for that I need the IDs...
Helge
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Thanks much for your help! I think I will take some faster hppa machine from our warehouse instead. 712 was a fine choice just of its size, but I don't want to deal with some shady example, however If I'll find another 712, I will try go with it. I see there is another recent 712 user: https://lists.debian.org/debian-hppa/2015/05/msg3.html and suppose he used stock kernel without problems. At least he doesn't mention any issue. Anyway, please let me know if you're going to make no_hpsdc=1 parameter work some way. I see there are other parameters processed by a kernel, so maybe compiling hp_sdc in as non-modular with a bit of changes in code might work... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
On 10.06.2015 19:35, wrote: Here's the boot failure log taken from serial console using the latest lifimage. By some reason HP SDC got enabled even with lifimage_mini (i.e. equally same messages at the end) where you set no_hpsdc=1 as the default boot parameter. Yes, it still loads the HP SDC driver. I just checked the mini image again, and the HP SDC driver was still included. Anyway, I've now two mini images on debian-ports, one with and the another without the driver. Can you please check this image next? It does not includes the driver so we should be able to see if it's really HP SDC driver related: ftp://ftp.debian-ports.org/debian-cd/hppa/debian-8.0/lifimage_mini_without_hpsdc When using lifimage.old or kernel on /boot partition, HP SDC is not activated (or at least there are no messages from the driver). That's strange. I assume it's not blacklisted or such in your /etc/modules.conf or /etc/modules.d/* files? The other reason could be, that the driver isn't automatically included when the new kernel initrd is generated when you install a new debian kernel. Wondering why no_hpsdc=1 doesn't disable it. I think I need to recheck that coding later when we know more... Helge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Helge Deller del...@gmx.de: On 10.06.2015 19:35, wrote: Here's the boot failure log taken from serial console using the latest lifimage. By some reason HP SDC got enabled even with lifimage_mini (i.e. equally same messages at the end) where you set no_hpsdc=1 as the default boot parameter. Yes, it still loads the HP SDC driver. I just checked the mini image again, and the HP SDC driver was still included. Anyway, I've now two mini images on debian-ports, one with and the another without the driver. Can you please check this image next? It does not includes the driver so we should be able to see if it's really HP SDC driver related: ftp://ftp.debian-ports.org/debian-cd/hppa/debian-8.0/lifimage_mini_without_hpsdc Thank you! This one boots just fine. The installer screen shows on as expected. When using lifimage.old or kernel on /boot partition, HP SDC is not activated (or at least there are no messages from the driver). That's strange. I assume it's not blacklisted or such in your /etc/modules.conf or /etc/modules.d/* files? No, I did not touch these. There is only /etc/modules exists and its empty. /etc/modprobe.d/ has just fbdev-blacklist.conf and modesetting.conf. The other reason could be, that the driver isn't automatically included when the new kernel initrd is generated when you install a new debian kernel. You're right. I've unpacked generated initrd, and hp_sdc.ko is not there while it is in the /lib/modules... Wondering why no_hpsdc=1 doesn't disable it. I think I need to recheck that coding later when we know more... Would be much appreciated, as it looks like it is whats needed in my rare case :-) Helge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Can you please check this image next? It does not includes the driver so we should be able to see if it's really HP SDC driver related: ftp://ftp.debian-ports.org/debian-cd/hppa/debian-8.0/lifimage_mini_without_hpsdc Thank you! This one boots just fine. The installer screen shows on as expected. Great! So, HP SDC is the culprit! The other reason could be, that the driver isn't automatically included when the new kernel initrd is generated when you install a new debian kernel. You're right. I've unpacked generated initrd, and hp_sdc.ko is not there while it is in the /lib/modules... Which is actually a bug, because for machines which need HP SDC (for HIL keyboards/mice) it's now missing :-( Wondering why no_hpsdc=1 doesn't disable it. I think I need to recheck that coding later when we know more... Would be much appreciated, as it looks like it is whats needed in my rare case :-) Maybe the easiest way is to simply blacklist the 712 in the driver itself? Looking at the pictures of the back of a 712 (e.g. http://eintr.net/systems/hp/hp712-100/) it seems it doesn't has a HIL port anyway, so the driver could just refuse to load. Can you confirm that your 712 has no HIL port at the rear or front? If yes, I'll try to come up with a kernel patch for you to test. Helge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Here's the boot failure log taken from serial console using the latest lifimage. By some reason HP SDC got enabled even with lifimage_mini (i.e. equally same messages at the end) where you set no_hpsdc=1 as the default boot parameter. When using lifimage.old or kernel on /boot partition, HP SDC is not activated (or at least there are no messages from the driver). Perhaps some false triggering? Wondering why no_hpsdc=1 doesn't disable it. BOOT_ADMIN b lan Attempting to boot. Loading Initial Program Loader IPL successfully loaded Booting palo ipl 1.95 root@mkhppa3 Thu Apr 17 20:15:17 UTC 2014 Boot image contains: 0/vmlinux32 3356006(7871684) bytes @ 0xb800 0/vmlinux64 4311361(11930248) bytes @ 0x33f000 0/ramdisk 6757315 bytes @ 0x75c000 Information: No console specified on kernel command line. This is normal. PALO will choose the console currently used by firmware (serial). Command line for kernel: ' panic_timeout=60 panic=-1 mirror/protocol=http preseed/url=http://backup.parisc-linux.org/debian/preseed.cfg mirror/http/proxy__=http://proxy:8080 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux' Selected kernel: /vmlinux from partition 0 Selected ramdisk: /initrd.gz from partition 0 Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing 32-bit kerneluncompressing Linux kernel. ELF32 executable Entry 0010 first 0010 n 2 Segment 0 load 0010 size 158648 mediaptr 0x1000 Segment 1 load 00127000 size 6045124 mediaptr 0x28000 Loading ramdisk 6757315 bytes @ 0657d000... Branching to kernel entry point 0x0010. If this is the last message you see, you may need to switch your console. This is a common symptom -- search the FAQ and mailing list at parisc-linux.org [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.16.0-4-parisc (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 Debian 3.16.7-ckt4-1 (2015-01-16) [0.00] unwind_init: start = 0x105e1a48, end = 0x106218b8, entries = 16359 [0.00] FP[0] enabled: Rev 1 Model 13 [0.00] The 32-bit Kernel has started... [0.00] Default page size is 4KB. [0.00] bootconsole [ttyB0] enabled [0.00] Initialized PDC Console for debugging. [0.00] Determining PDC firmware type: Snake. [0.00] model 6020 0481 77c2ca12 0004 0072 0072 [0.00] vers 000c [0.00] model 9000/712 [0.00] Total Memory: 128 MB [0.00] initrd: 1657d000-16beebc3 [0.00] initrd: reserving 0657d000-06beebc3 (mem_max 0800) [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [0.00] Kernel command line: panic_timeout=60 panic=-1 mirror/protocol=http preseed/url=http://backup.parisc-linux.org/debian/preseed.cfg mirror/http/proxy__=http://proxy:8080 console=ttyS0 TERM=vt102 palo_kernel=0/vmlinux [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Sorting __ex_table... [0.00] Memory: 117064K/131072K available (3892K kernel code, 695K rwdata, 850K rodata, 256K init, 363K bss, 14008K reserved) [0.00] virtual kernel memory layout: 0.00] vmalloc : 0x0081 - 0x0f00 ( 231 MB) 0.00] memory : 0x1000 - 0x1800 ( 128 MB) 0.00] .init : 0x1010 - 0x1014 ( 256 kB) 0.00] .data : 0x1050d000 - 0x1068f9a0 (1546 kB) 0.00] .text : 0x1014 - 0x1050d000 (3892 kB) [0.00] NR_IRQS:96 [0.00] Console: colour dummy device 160x64 [0.06] Calibrating delay loop... 99.53 BogoMIPS (lpj=497664) [0.176000] pid_max: default: 32768 minimum: 301 [0.236000] Security Framework initialized [0.288000] AppArmor: AppArmor disabled by boot time parameter [0.364000] Yama: disabled by default; enable with sysctl kernel.yama.* [0.444000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.528000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.624000] Initializing cgroup subsys memory [0.68] Initializing cgroup subsys devices [0.736000] Initializing cgroup subsys freezer [0.792000] Initializing cgroup subsys net_cls [0.848000] Initializing cgroup subsys blkio [0.904000] Initializing cgroup subsys perf_event [0.964000] Initializing cgroup subsys net_prio [1.036000] devtmpfs: initialized [1.092000] NET: Registered
Bug#787794: lifimage fails to successfully boot on hppa
the message 'seekread() returned 2048 expected 8192' on gzipped kernel. That seekread-message is not critical. I think I fixed it in a newer palo version. You attached the dmesg from latest debian kernel (4.0.0) - so it's booting fine with latest kernels. But could you try to boot (and attach the dmesg of it of) the kernel from the lifimage as well, e.g. by using this debian package: ftp://ftp.debian-ports.org/debian/obsolete/2015-04-14/linux-image-3.16.0-4-parisc_3.16.7-ckt9-1_hppa.deb I quite don't understand yet, why it fails to start the installer on your machine. It might be the old kernel, or some stuff in the initrd which allocates too much memory. Helge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Helge Deller del...@gmx.de:
On 08.06.2015 16:07, wrote:
Anyway, since I have an installed working Debian 8 sid on this
machine, should I gzip the kernel and try to boot it to see whether
this issue occurs in non-netboot case too?
Yes, please.
And send the dmesg log of the sucessful boot.
Tried few times, boots fine, though always the message 'seekread()
returned 2048 expected 8192' on gzipped kernel.
Attached the dmesg.
Thanks.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.0.0-2-parisc (debian-ker...@lists.debian.org)
(gcc version 4.9.2 (Debian 4.9.2-18) ) #1 Debian 4.0.4-1 (2015-05-27)
[0.00] unwind_init: start = 0x105fdfe8, end = 0x10640008, entries =
16898
[0.00] FP[0] enabled: Rev 1 Model 13
[0.00] The 32-bit Kernel has started...
[0.00] Default page size is 4KB.
[0.00] bootconsole [ttyB0] enabled
[0.00] Initialized PDC Console for debugging.
[0.00] Determining PDC firmware type: Snake.
[0.00] model 6020 0481 77c2ca12
0004 0072 0072
[0.00] vers 000c
[0.00] model 9000/712
[0.00] Total Memory: 128 MB
[0.00] initrd: 15d2a000-16bee022
[0.00] initrd: reserving 05d2a000-06bee022 (mem_max 0800)
[0.00] On node 0 totalpages: 32768
[0.00] free_area_init_node: node 0, pgdat 10683f60, node_mem_map
1072
[0.00] Normal zone: 288 pages used for memmap
[0.00] Normal zone: 0 pages reserved
[0.00] Normal zone: 32768 pages, LIFO batch:7
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 32480
[0.00] Kernel command line: HOME=/ TERM=linux root=/dev/sda5
rootfstype=ext3 console=tty0 sti=1 sti_font=VGA8x16 palo_kernel=2/vmlinuz
[0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Sorting __ex_table...
[0.00] Memory: 108204K/131072K available (4028K kernel code, 766K
rwdata, 827K rodata, 256K init, 384K bss, 22868K reserved, 0K cma-reserved)
[0.00] virtual kernel memory layout:
vmalloc : 0x0081 - 0x0f00 ( 231 MB)
memory : 0x1000 - 0x1800 ( 128 MB)
.init : 0x1010 - 0x1014 ( 256 kB)
.data : 0x1052f000 - 0x106bdb20 (1594 kB)
.text : 0x1014 - 0x1052f000 (4028 kB)
[0.00] NR_IRQS:96
[0.004000] Console: colour dummy device 160x64
[0.036000] console [tty0] enabled
[0.068000] bootconsole [ttyB0] disabled
[0.10] Calibrating delay loop... 99.53 BogoMIPS (lpj=497664)
[0.148000] pid_max: default: 32768 minimum: 301
[0.148000] Security Framework initialized
[0.148000] AppArmor: AppArmor disabled by boot time parameter
[0.148000] Yama: disabled by default; enable with sysctl kernel.yama.*
[0.148000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.148000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.156000] Initializing cgroup subsys blkio
[0.156000] Initializing cgroup subsys memory
[0.156000] Initializing cgroup subsys devices
[0.156000] Initializing cgroup subsys freezer
[0.156000] Initializing cgroup subsys net_cls
[0.156000] Initializing cgroup subsys perf_event
[0.156000] Initializing cgroup subsys net_prio
[0.176000] devtmpfs: initialized
[0.196000] NET: Registered protocol family 16
[0.20] EISA bus registered
[0.204000] Searching for devices...
[0.304000] Found devices:
[0.304000] 1. Gecko 100 GSC Core Graphics at 0xf800 [1] { 10, 0x0,
0x01d, 0x00085 }
[0.304000] 2. Gecko 100 Core BA at 0xf010 [2] { 11, 0x0, 0x01d, 0x00081
}
[0.304000] 3. Gecko 100 Core SCSI at 0xf0106000 [2/0/1] { 10, 0x0, 0x01d,
0x00082 }
[0.304000] 4. Gecko 100 Core LAN (802.3) at 0xf0107000 [2/0/2] { 10, 0x0,
0x01d, 0x0008a }
[0.304000] 5. Gecko 100 Core RS-232 at 0xf0105000 [2/0/4] { 10, 0x0, 0x01d,
0x0008c }
[0.304000] 6. Gecko 100 Core Centronics at 0xf0102000 [2/0/6] { 10, 0x0,
0x01d, 0x00074 }
[0.304000] 7. Gecko 100 Audio at 0xf0104000 [2/0/8] { 10, 0x0, 0x01d,
0x0007b }
[0.304000] 8. Gecko 100 Core PC Floppy at 0xf010a000 [2/0/10] { 10, 0x0,
0x01d, 0x00083 }
[0.304000] 9. Gecko 100 Core PS/2 Port at 0xf0108000 [2/0/11] { 10, 0x0,
0x01d, 0x00084 }
[0.304000] 10. Gecko 100 Core PS/2 Port at 0xf0108100 [2/0/12] { 10, 0x0,
0x01d, 0x00084 }
[0.304000] 11. Gecko 100 Core BA at 0xf050 [6] { 11, 0x0, 0x01d,
0x00081 }
[0.308000] 12. Gecko 100 (712/100) at 0xfffbe000 [8] { 0, 0x0, 0x602,
0x4 }
[
Bug#787794: lifimage fails to successfully boot on hppa
Helge Deller del...@gmx.de: the message 'seekread() returned 2048 expected 8192' on gzipped kernel. That seekread-message is not critical. I think I fixed it in a newer palo version. You attached the dmesg from latest debian kernel (4.0.0) - so it's booting fine with latest kernels. Initially the installer set a 3.16-something kernel for me, which worked fine as well. I've just upgraded to a newer kernel later. But could you try to boot (and attach the dmesg of it of) the kernel from the lifimage as well, e.g. by using this debian package: ftp://ftp.debian-ports.org/debian/obsolete/2015-04-14/linux-image-3.16.0-4-parisc_3.16.7-ckt9-1_hppa.deb I quite don't understand yet, why it fails to start the installer on your machine. It might be the old kernel, or some stuff in the initrd which allocates too much memory. Thanks, I will try. Will also grab a usb-to-serial adapter to catch the output of a failing boot. Maybe it will get you some clues. Helge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
lausg...@gmail.com: Helge Deller del...@gmx.de: only lifimage.old is able to boot on a subject machine. Other bring it into an endless HP SDC: Transaction add failed: transaction already queued ? print loop. Ok, I found this kernel commit: commit 305e342bba16730a0821131af6d7d0df43bfff4c Author: Helge Deller del...@gmx.de Date: Mon Jul 14 10:28:32 2008 -0400 Input: add option to disable HP SDC driver Add no_hpsdc kernel module option to the hp_sdc driver, so that the driver can be instructed to not enable the HP SDC port. This is useful on some older HPPA boxes with HIL keyboard and HIL mouse where the new HP SDC HIL drivers don't work yet. By disabling the new hp_sdc driver users are able to use the older hilkbd driver instead. Can you try to boot with the no_hpsdc=1 kernel parameter ? But I don't think the hp_sdc driver is the real issue why one lifimage boots while the other doesn't... Doesn't make difference. BTW, the boot hangs if I put this parameter not at the end of boot arguments line (i.e. after TERM=linux), but somewhere in the middle. Correction. Not the placement makes it hang, but the long waiting. If I've modified the arguments and started boot quickly enough it boots, otherwise it hangs at kernel loading and after some time machine reboots. But as I have previously said, this parameter doesn't help. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Helge Deller del...@gmx.de: On 05.06.2015 17:10, wrote: Machine: HP712/100 Hmm, your bug #302700 mentions a HP715/100XC machine. Do you have both or is it a mistake? If you have both machines, does it happens on both? How are you booting? Via tftpboot, or via CDROM ? Its the 712/100. 302700 is not my bug, that's just the one most similar I could find (HP SDC error messages too). I found this one as well: https://lists.debian.org/debian-hppa/2006/08/msg00019.html I'm booting lifimage via tftpboot. Ok. What is your tftpserver (e.g. a debian x86 box?). Some tftp servers may have issues. Yes, a Debian x86 box. Also tried another machine with different software stack and got the same result. only lifimage.old is able to boot on a subject machine. Other bring it into an endless HP SDC: Transaction add failed: transaction already queued ? print loop. So, this is the actual problem you have? Any other kernel messages after that? Yes, this is an actual problem. Unfortunately, see no other messages after that. They're are just printed in the loop. One idea is, that the combination of your tftpserver and maybe the firmware in your HP machine don't play nice with each other. That way maybe your initrd gets corrupted during the transfer? Did you checked if you run the lastest firmware on your machine? Yes, it seems to run the latest firmware. Ok. Do you have a chance to capture the boot logs via serial console and attach them ? Unfortunately I'm not will be able to hook to the COM port any time soon... That's really sad, because it would be extremely helpful. Not even a laptop? Actually, if it works on your machines, including 715/64 (which is similar to 712 as I see), that's looks more like issue with my particular hardware. Yes, maybe. Thanks for the help, and I'm not going to take your time with this anymore. I really would like to solve this issue, and I'm dependent on your input to be able to fix it since I don't see issues myself. So, if you find time, let me know. My initial thought was that no one still test PARISC Linux on an ancient PARISC hardware, but its seems that this assumption is wrong :-) I'm already more than happy with that it was possible to install Linux on a hardware like this. Yes, I'm testing the debian kernels/install images on a range of (old and new) hardware. And thank you for this! Helge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Helge Deller del...@gmx.de: only lifimage.old is able to boot on a subject machine. Other bring it into an endless HP SDC: Transaction add failed: transaction already queued ? print loop. Ok, I found this kernel commit: commit 305e342bba16730a0821131af6d7d0df43bfff4c Author: Helge Deller del...@gmx.de Date: Mon Jul 14 10:28:32 2008 -0400 Input: add option to disable HP SDC driver Add no_hpsdc kernel module option to the hp_sdc driver, so that the driver can be instructed to not enable the HP SDC port. This is useful on some older HPPA boxes with HIL keyboard and HIL mouse where the new HP SDC HIL drivers don't work yet. By disabling the new hp_sdc driver users are able to use the older hilkbd driver instead. Can you try to boot with the no_hpsdc=1 kernel parameter ? But I don't think the hp_sdc driver is the real issue why one lifimage boots while the other doesn't... Doesn't make difference. BTW, the boot hangs if I put this parameter not at the end of boot arguments line (i.e. after TERM=linux), but somewhere in the middle. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Helge Deller del...@gmx.de: Hi Lausgans, Could you please try to boot this lifimage: ftp://ftp.debian-ports.org/debian-cd/hppa/debian-8.0/lifimage_mini It's the same as the other lifimages, but all 64bit Linux kernel related drivers were dropped. Additionally it's without USB drivers and some other things which should not be relevant for 712/715 machines. I suspect out-of-memory situations with the other lifimage on your machine, since my machine has 160MB RAM and there does it boots. Thank you! Unfortunately it gives me the same exact issue. Anyway, since I have an installed working Debian 8 sid on this machine, should I gzip the kernel and try to boot it to see whether this issue occurs in non-netboot case too? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
On 08.06.2015 16:07, wrote: Anyway, since I have an installed working Debian 8 sid on this machine, should I gzip the kernel and try to boot it to see whether this issue occurs in non-netboot case too? Yes, please. And send the dmesg log of the sucessful boot. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Hi Lausgans, Could you please try to boot this lifimage: ftp://ftp.debian-ports.org/debian-cd/hppa/debian-8.0/lifimage_mini It's the same as the other lifimages, but all 64bit Linux kernel related drivers were dropped. Additionally it's without USB drivers and some other things which should not be relevant for 712/715 machines. I suspect out-of-memory situations with the other lifimage on your machine, since my machine has 160MB RAM and there does it boots. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
only lifimage.old is able to boot on a subject machine. Other bring it into an endless HP SDC: Transaction add failed: transaction already queued ? print loop. Ok, I found this kernel commit: commit 305e342bba16730a0821131af6d7d0df43bfff4c Author: Helge Deller del...@gmx.de Date: Mon Jul 14 10:28:32 2008 -0400 Input: add option to disable HP SDC driver Add no_hpsdc kernel module option to the hp_sdc driver, so that the driver can be instructed to not enable the HP SDC port. This is useful on some older HPPA boxes with HIL keyboard and HIL mouse where the new HP SDC HIL drivers don't work yet. By disabling the new hp_sdc driver users are able to use the older hilkbd driver instead. Can you try to boot with the no_hpsdc=1 kernel parameter ? But I don't think the hp_sdc driver is the real issue why one lifimage boots while the other doesn't... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Package: installation-reports Forwarded: debian-h...@lists.debian.org Debian-installer-version: debian-7.0, debian-8.0, both are sid snapshots uname -a: N/A Date: Sat Jul 04 13:03:37 CET 2015 Method: netboot Machine: HP712/100 Processor: PA7100LC Memory: 128 MB Root Device: SCSI, /dev/sda Root Size/partition table: N/A Output of lspci: N/A Base System Installation Checklist: Initial boot worked:[E] Configure network HW: [ ] Config network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Create file systems:[ ] Mount partitions: [ ] Install base system:[ ] Install boot loader:[ ] Reboot: [ ] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: From images at http://ftp.debian-ports.org/debian-cd/hppa/ debian-8.0/lifimage 13.8M debian-7.0: lifimage 13.2M lifimage.latest 13.2M lifimage.old 19.1M only lifimage.old is able to boot on a subject machine. Other bring it into an endless HP SDC: Transaction add failed: transaction already queued ? print loop. Sure the installation was still possible via that lifimage.old with some tinkering, but how long it will be hosted, and how long it will be suitable? Looking at the image sizes... Perhaps something ramdisk size related? Is it a way to fix, or what is the current workaround method for loading other images? Quite related ancient bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=302700 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
On 05.06.2015 08:08, wrote: Date: Sat Jul 04 13:03:37 CET 2015 You seem to be ahead of time :-) Machine: HP712/100 Hmm, your bug #302700 mentions a HP715/100XC machine. Do you have both or is it a mistake? If you have both machines, does it happens on both? How are you booting? Via tftpboot, or via CDROM ? From images at http://ftp.debian-ports.org/debian-cd/hppa/ debian-8.0/lifimage 13.8M debian-7.0: lifimage 13.2M lifimage.latest 13.2M lifimage.old 19.1M only lifimage.old is able to boot on a subject machine. Other bring it into an endless HP SDC: Transaction add failed: transaction already queued ? print loop. The main reason for the huge difference is size is because the kernel in the old image is uncompressed and in the newer ones it's gzip-compressed. Of course they could be different kernel versions, but usually all should work. Sure the installation was still possible via that lifimage.old with some tinkering, but how long it will be hosted, and how long it will be suitable? I see no reason why I should delete them. But if the old image is the one which boots for you, I could definitively keep it until your problem is solved. Looking at the image sizes... Perhaps something ramdisk size related? No, it's the kernel compression. Is it a way to fix, or what is the current workaround method for loading other images? We should try to narrow down the reason for your problem. I do have a 715/64 myself, and AFAICR all those images do work on my machine. Did you checked if you run the lastest firmware on your machine? Quite related ancient bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=302700 I don't see any similar issues on all my machines. Do you have a chance to capture the boot logs via serial console and attach them ? Helge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
Helge Deller del...@gmx.de: On 05.06.2015 08:08, wrote: Date: Sat Jul 04 13:03:37 CET 2015 You seem to be ahead of time :-) Machine: HP712/100 Hmm, your bug #302700 mentions a HP715/100XC machine. Do you have both or is it a mistake? If you have both machines, does it happens on both? How are you booting? Via tftpboot, or via CDROM ? Its the 712/100. 302700 is not my bug, that's just the one most similar I could find (HP SDC error messages too). I'm booting lifimage via tftpboot. From images at http://ftp.debian-ports.org/debian-cd/hppa/ debian-8.0/lifimage 13.8M debian-7.0: lifimage 13.2M lifimage.latest 13.2M lifimage.old 19.1M only lifimage.old is able to boot on a subject machine. Other bring it into an endless HP SDC: Transaction add failed: transaction already queued ? print loop. The main reason for the huge difference is size is because the kernel in the old image is uncompressed and in the newer ones it's gzip-compressed. Of course they could be different kernel versions, but usually all should work. Sure the installation was still possible via that lifimage.old with some tinkering, but how long it will be hosted, and how long it will be suitable? I see no reason why I should delete them. But if the old image is the one which boots for you, I could definitively keep it until your problem is solved. Looking at the image sizes... Perhaps something ramdisk size related? No, it's the kernel compression. Thanks for clearing it out! Is it a way to fix, or what is the current workaround method for loading other images? We should try to narrow down the reason for your problem. I do have a 715/64 myself, and AFAICR all those images do work on my machine. Did you checked if you run the lastest firmware on your machine? Yes, it seems to run the latest firmware. Quite related ancient bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=302700 I don't see any similar issues on all my machines. Do you have a chance to capture the boot logs via serial console and attach them ? Unfortunately I'm not will be able to hook to the COM port any time soon... Actually, if it works on your machines, including 715/64 (which is similar to 712 as I see), that's looks more like issue with my particular hardware. Thanks for the help, and I'm not going to take your time with this anymore. My initial thought was that no one still test PARISC Linux on an ancient PARISC hardware, but its seems that this assumption is wrong :-) I'm already more than happy with that it was possible to install Linux on a hardware like this. Helge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787794: lifimage fails to successfully boot on hppa
On 05.06.2015 17:10, wrote: Machine: HP712/100 Hmm, your bug #302700 mentions a HP715/100XC machine. Do you have both or is it a mistake? If you have both machines, does it happens on both? How are you booting? Via tftpboot, or via CDROM ? Its the 712/100. 302700 is not my bug, that's just the one most similar I could find (HP SDC error messages too). I found this one as well: https://lists.debian.org/debian-hppa/2006/08/msg00019.html I'm booting lifimage via tftpboot. Ok. What is your tftpserver (e.g. a debian x86 box?). Some tftp servers may have issues. only lifimage.old is able to boot on a subject machine. Other bring it into an endless HP SDC: Transaction add failed: transaction already queued ? print loop. So, this is the actual problem you have? Any other kernel messages after that? One idea is, that the combination of your tftpserver and maybe the firmware in your HP machine don't play nice with each other. That way maybe your initrd gets corrupted during the transfer? Did you checked if you run the lastest firmware on your machine? Yes, it seems to run the latest firmware. Ok. Do you have a chance to capture the boot logs via serial console and attach them ? Unfortunately I'm not will be able to hook to the COM port any time soon... That's really sad, because it would be extremely helpful. Not even a laptop? Actually, if it works on your machines, including 715/64 (which is similar to 712 as I see), that's looks more like issue with my particular hardware. Yes, maybe. Thanks for the help, and I'm not going to take your time with this anymore. I really would like to solve this issue, and I'm dependent on your input to be able to fix it since I don't see issues myself. So, if you find time, let me know. My initial thought was that no one still test PARISC Linux on an ancient PARISC hardware, but its seems that this assumption is wrong :-) I'm already more than happy with that it was possible to install Linux on a hardware like this. Yes, I'm testing the debian kernels/install images on a range of (old and new) hardware. Helge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
