Bugzilla – Bug 308671
hwinfo --isdn crashes in VirtualBox
Last modified: 2010-09-30 12:17:42 UTC
Installation in VirtualBox, in 2.nd stage yast (network proposal) crashes. It's caused by "hwinfo --isdn" segfault. Strace will follow
*** This bug has been marked as a duplicate of bug 239637 ***
I too see this problem. This bug may be a duplicate of bug 239637, but that bug is not accessible to me. Why? Are you sure this is Beta 3, not Alpha 3???????? I have gotten two killer bugs and I haven't even finished installation. I have been a SuSE user since 6.4 but you guys are driving me to another distro!
>> I too see this problem. This bug may be a duplicate of bug 239637, but that bug is not accessible to me. Why? bug #239637 is reported to SLED >> Are you sure this is Beta 3, not Alpha 3? Yes, pretty sure (this worked in Beta2)
ok, this does affect only virtualbox and qemu -> nothing critical
*** Bug 310600 has been marked as a duplicate of this bug. ***
Same error here. Manually starting /usr/lib/YaST2/startup/YaST2.Second-Stage afterwards works, so only the first call crashes.
Well, does booting with 'hwprobe=-isa' help?
Just tested using RC1: - First boot, directly after installation (2nd stage) -> ISDN detection crashes -> Select reboot from kdm - Second boot -> ISDN detection crashes -> Select reboot from kdm - Third boot, using hwprobe=-isa -> no crashes anymore :) It seems that this parameter helps...
Created attachment 173681 [details] fixed hwinfo Here's a hwinfo package that probably helps. Please give it a try.
I don't think that isa probing is the issue. I can reproduce it by running hwinfo --vbe within virtualbox. the problem seems to be only when using the qt frontend, which uses multithreading and installs its own signal handler. with the ncurses frontend the correct signalhandler (the one that hwinfo installs) is called.
vbe would be the same reason: it uses i/o instructions when doing the BIOS emulation.
with RC1 the problem is still there. How can I disable checking for isdn without doing a manual=1 installation? The recommendations from old http://en.opensuse.org/SDB:YaST2_hangs_during_the_hardware_detection wouldn't work.
see comment 7
Thanks, I am just not sure "hwprobe=-isa" excludes ISDN setup only. There has to be a deeper bug around the installation stage 2, however. Therefore I've filed bug 327061.
The bug is not isdn related at all but caused by (I believe) i/o port accesses. Hence '-isa'.
(In reply to comment #15 from Steffen Winterfeldt) > The bug is not isdn related at all but caused by (I believe) i/o port > accesses. Hence '-isa'. Interesting... I've also seen hwclock segfaulting when trying to access the hardware clock. Might be a virtualbox bug (vmware has no problems there). However, don't have it running anymore because of other problems, so I cannot test anymore...
No, it's not a VirtualBox problem, RC1 has hwclock segfaulting on native hardware,too.
*** Bug 327836 has been marked as a duplicate of this bug. ***
I installed 10.3 RC1 inside VirtualBox 1.5.0 and was affected by this bug (configuration, user creating steps were skipped). What's important, in my case it is probably not because of hwinfo. Look at this, please: # hwinfo --isdn # hwinfo --isdn && echo OK OK Not any hwinfo's crash visible. May I give you more info? Is y2log useful in this case?
Hm, it's weird. I restared my virtual machine and openSUSE started installation from stage 2. This time I was looking what's going on and you were right ─ even in my case installation crashed od "Detecting ISDN devices". So hwinfo --isdn seems to crash only while installation. When installation crashes and system boots, I can log in as root and use this command fine.
Do you have an Intel or AMD cpu?
So, to clear thing s up a bit: it is _not_ 'hwinfo --isdn' that crashes but yast during ISDN detection. Is that correct, or has anyone seen hwinfo crash?
Steffen, see initial comment - it was "hwinfo --isdn" segfault that caused yast crash
YaST does not run 'hwinfo --isdn' and even if it would, you surely are not suggesting that it is ok for a program to crash just because another program did?
>> YaST does not run 'hwinfo --isdn' yes, it does /usr/share/YaST2/modules/ISDN.ycp: ... 287 Hardware = ReadHardware("isdn"); ... which calls SCR probe agent with .isdn parameter (same like hwinfo --isdn) >> program to crash just because another program did I never told it's ok, but it works this way - SCR agents are executed in the same context like yast code
Michal, the above code does *NOT* run hwinfo! It adds much to the confusion around this bug to mix those two things.
ReadHardware("isdn") function executes SCR::Read(.probe.isdn) - this uses libhd shared with hwinfo (you know this better than me ;-)) VirtualBox with last RC1: echo '`Read(.probe.isdn)'|/usr/lib/YaST2/y2base stdio scr ([]) YaST got signal 11 at YCP file :1 Segmentation fault hwinfo --isdn >isa.1: isdnSegmentation fault
But it is not the same! If I ask about 'hwinfo --isdn' I really mean the command. Else we spend forever speculating if this bug is caused by libhd or yast's thread handling as Dirk suggests. Now, as you can reproduce it with hwinfo, can you run it in gdb and identify the instruction causing the segfault?
gdb hwinfo GNU gdb 6.6.50.20070726-cvs Copyright (C) 2007 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run --isdn Starting program: /usr/sbin/hwinfo --isdn [Thread debugging using libthread_db enabled] [New Thread 0xb7c026c0 (LWP 3436)] > isa.1: isdn Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7c026c0 (LWP 3436)] 0xb7df4f75 in avm_a1_detect (ii=0xbfa1b26c) at /usr/include/sys/io.h:48 48 __asm__ __volatile__ ("inb %w1,%0":"=a" (_v):"Nd" (port)); (gdb) bt #0 0xb7df4f75 in avm_a1_detect (ii=0xbfa1b26c) at /usr/include/sys/io.h:48 #1 0xb7df5009 in isdn_detect () at isa_probe.c:229 #2 0xb7dd98b9 in hd_scan_isa (hd_data=0x8050008) at isa.c:48 #3 0xb7dc7f34 in hd_scan_no_hal (hd_data=0x8050008) at hd.c:1977 #4 0xb7dcad5e in hd_scan (hd_data=0x8050008) at hd.c:1831 #5 0xb7dcb700 in hd_list (hd_data=0x8050008, item=hw_isdn, rescan=1, hd_old=0x0) at hd.c:3236 #6 0x0804ba62 in do_hw (hd_data=0x8050008, f=0x0, hw_item=hw_isdn) at hwinfo.c:536 #7 0x0804c9d2 in main (argc=2, argv=0xbfa1b5e4) at hwinfo.c:357 #8 0xb7c85fe0 in __libc_start_main () from /lib/libc.so.6 #9 0x08049631 in _start () (gdb)
And comment 9 works?
BTW, 'hwinfo --vbe' works for you?
hwinfo --vbe works
yes, attached hwinfo fixed segfault problem
*** Bug 328775 has been marked as a duplicate of this bug. ***
BTW, I just tried some VirtualBox VMs on my test machines and was unable to get 'hwinfo --isdn' segfault.
ok, I can. And the work around is pretty easy: after initial crash of the installation, reboot and add hwprobe=-isa as boot paramater to the installation. Then the second stage continue just fine.
can reproduce it again with virtualbox 1.5.0, it was not reproduceable with the 2007082x snapshot iirc.
Why is this my bug anyway?
I suggest to remove ISDN card probing from proposal for factory. it's about time
This is a really old bug. Sorry for not resolving it earlier, but apparently it's either solved or there are no resources to fix it. Please reopen if you find it unsolved and very important.