Bugzilla – Bug 461161
dangling "module" link to non-existing /sys/module/agpgart-amd64/ dir
Last modified: 2009-11-24 17:10:42 UTC
When having installed GNOME and KDE4 at the same time yast2 --qt crashes with the segmention fault "YaST got signal 11 at YCP file Arch.ycp:46 - /sbin/yast2: line 437: 7607 Segmention fault $ybindir/y2base $module "$@" $Y2_GEOMETRY $Y2UI_ARGS" when you want to add community repositories with the help of the yast2 assistant.
Stephan , please provide y2logs. More info on http://en.opensuse.org/Bugs/YaST
Created attachment 262216 [details] y2log of segemention fault of Arch.ycp I'm sorry I totally forgot about y2log. I attached it.
Stephan , can you please attach full logs: $ save_y2logs /tmp/y2logs.tgz
Created attachment 263114 [details] save_y2logs Ok, here you go. Unfortunally I found more parts of YaST2 that seem to have problems with Arch.ycp and other components: Software Mediacheck (checkmedia/ui.ycp:40) (5216) Hardware Hardware-Information (/usr/share/YaST2/clients/hwinfo.ycp:188) (5244) Joystick (Arch.ycp:46) (5275) Sound (Arch.ycp:46) (5302) TV-Tuner (Arch.ycp:46) (5329) Keyboardlayout (Arch.ycp:46) (5356) System Bootloader (Arch.ycp:46) (19662) Date & Time (Arch.ycp:46) (19696) Kernelsettings (Arch.ycp:46) (19761) Partitioner (Arch.ycp:46) (19794) Language (Arch.ycp:46) (19875) Systemrecovery (restore/ui.ycp:71) (20190) Networkdevices DSL (network/routines.ycp:594) (20246) ISDN (network/routines.ycp:594) (20286) Modem (network/routines.ycp:594) (20319) Networksettings (Arch.ycp:46) (20352) Networkservices Memberschip in Windows-Domain (Arch.ycp:46) (20665) Manufactor Driver-CD (Arch.ycp:46) (22403) hwinfo and gnome-system-monitor terminate with segmentation faults aswell. Those segmentation faults appear in random sessions. Sometimes YaST2 works without problems, but after a reboot YaST2 doesn't work properly.
Reassign to yast2-maintainers.
The backtrace looks like this: Frame 0: /usr/lib/liby2.so.2 log_backtrace() Frame 1: /usr/lib/liby2.so.2 signal_handler(int) Frame 2: [0xffffe400] Frame 3: /lib/libc.so.6(strrchr+0xa3) [0xb7876bb3] Frame 4: /usr/lib/libhd.so.15(hd_sysfs_driver_list+0x23a) [0xb61fe7da] Frame 5: /usr/lib/libhd.so.15(hd_scan_int+0xa20) [0xb6210a60] Frame 6: /usr/lib/libhd.so.15(hd_scan+0x1b0) [0xb6201850] Frame 7: /usr/lib/libhd.so.15(hd_list+0x20a) [0xb62035da] Frame 8: /usr/lib/YaST2/plugin/libpy2ag_hwprobe.so.2 HwProbe::checkPath(YCPPath const&, YCPValue const&, YCPValue const&, int) Frame 9: /usr/lib/YaST2/plugin/libpy2ag_hwprobe.so.2 HwProbe::Read(YCPPath const&, YCPValue const&, YCPValue const&) Frame 10: /usr/lib/YaST2/plugin/libpy2ag_hwprobe.so.2 Y2AgentComp<HwProbe>::evaluate(YCPValue const&) Frame 11: /usr/lib/liby2.so.2 Y2PluginComponent::evaluate(YCPValue const&) Frame 12: /usr/lib/YaST2/plugin/libpy2scr.so.2 ScriptingAgent::executeSubagentCommand(char const*, YCPPath const&, YCPValue const&, YCPValue const&) Frame 13: /usr/lib/YaST2/plugin/libpy2scr.so.2 ScriptingAgent::Read(YCPPath const&, YCPValue const&, YCPValue const&) Frame 14: /usr/lib/libscr.so.2 [0xb7eb2f71] Frame 15: /usr/lib/libscr.so.2 [0xb7eb3208] Frame 16: /usr/lib/libycp.so.3 YEBuiltin::evaluate(bool) Frame 17: /usr/lib/libycp.so.3 YEPropagate::evaluate(bool) Frame 18: /usr/lib/libycp.so.3 YSAssign::evaluate(bool) Frame 19: /usr/lib/libycp.so.3 YSIf::evaluate(bool) Frame 20: /usr/lib/libycp.so.3 YBlock::evaluate(bool) Frame 21: /usr/lib/libycp.so.3 Y2YCPFunction::evaluateCall() Frame 22: /usr/lib/libycp.so.3 YEFunction::evaluate(bool) Frame 23: /usr/lib/libycp.so.3 YECompare::evaluate(bool) Frame 24: /usr/lib/libycp.so.3 YSReturn::evaluate(bool) Frame 25: /usr/lib/libycp.so.3 YBlock::evaluate(bool) Frame 26: /usr/lib/libycp.so.3 Y2YCPFunction::evaluateCall() Frame 27: /usr/lib/libycp.so.3 YEFunction::evaluate(bool) Frame 28: /usr/lib/libycp.so.3 [0xb7e4aeab] Frame 29: /usr/lib/libycp.so.3 YEBinary::evaluate(bool) Frame 30: /usr/lib/libycp.so.3 YSReturn::evaluate(bool) Frame 31: /usr/lib/libycp.so.3 YBlock::evaluate(bool) Frame 32: /usr/lib/libycp.so.3 Y2YCPFunction::evaluateCall() Frame 33: /usr/lib/libycp.so.3 YEFunction::evaluate(bool) Frame 34: /usr/lib/libycp.so.3 YSIf::evaluate(bool) Frame 35: /usr/lib/libycp.so.3 YBlock::evaluate(bool) Frame 36: /usr/lib/libycp.so.3 Y2YCPFunction::evaluateCall() Frame 37: /usr/lib/liby2.so.2 Y2Namespace::initialize() Frame 38: /usr/lib/libycp.so.3 YSImport::evaluate(bool) Frame 39: /usr/lib/libycp.so.3 YBlock::evaluate(bool) Frame 40: /usr/lib/libycp.so.3 YCPCodeRep::evaluate(bool) const Frame 41: /usr/lib/YaST2/plugin/libpy2wfm.so.2 Y2WFMComponent::doActualWork(YCPList const&, Y2Component*) Frame 42: /usr/lib/liby2.so.2(main+0x11e5) [0xb7d4e2c5] Frame 43: /lib/libc.so.6(__libc_start_main+0xe5) [0xb7819705] Frame 44: /usr/lib/YaST2/bin/y2base [0x8048591]
I guess the segfault is caused by the hardware detection. Reassigning to yast2-hardware-detection maintainer.
yast2-hardware-detection is just a wrapper over libhd in hwinfo.rpm. YaST is reading .probe.architecture which corresponds to pr_cpu in libhd. Please try, as root, "hwinfo --cpu". If that does not crash, try "/usr/lib/YaST2/bin/y2base language qt". Then get a better backtrace of the crash: enable the Debug repository and install gdb, hwinfo-debuginfo and hwinfo-debugsource. See: http://en.opensuse.org/Bugs:An_application_crashed#Install_-debuginfo_Packages http://en.opensuse.org/Bugs:An_application_crashed#Using_GDB and attach the backtrace (up to libpy2ag_hwprobe is enough, libycp is not interesting).
Created attachment 263259 [details] YaST2 backtrace Have a look at the backtrace of gdb running "/usr/lib/YaST2/bin/y2base language qt" in the attachment. The three dots mark the section of the backtrace of libycp. I'm not sure what package caused the malfunctions of hwinfo, I just noticed it the first time after I had installed the Gnome desktop.
hd.c:5855: module = strrchr(hd_read_sysfs_link(drv, sf_drv2_e->str), '/'); I think hd.c is not coping with some anomaly of some driver.
Very weird. Stephan, does 'hwinfo --cpu' crash as well?
Created attachment 264221 [details] hwinfo --cpu Yes, it does ... *sign* Everything went fine with 11.0, so I don't think my hardware is going down.
*** Bug 462745 has been marked as a duplicate of this bug. ***
Ah, that's good. Please run 'getsysinfo' and attach the log.
Created attachment 264490 [details] getsysinfo I attached the result of "getsysinfo".
Thanks! There's a dangling symlink in sysfs. I've fixed libhd not to segfault, but the kernel should be fixed as well: # ls -l sys/bus/pci/drivers/agpgart-amd64 total 0 lrwxrwxrwx 1 snwint suse 28 2009-01-12 14:25 module -> ../../../../module/amd64_agp The directory 'amd64_agp' does not exist.
Reassign to : kernel-maintainers
(In reply to comment #16) > Thanks! There's a dangling symlink in sysfs. I've fixed libhd not to segfault, > but the kernel should be fixed as well: > > # ls -l sys/bus/pci/drivers/agpgart-amd64 > total 0 > lrwxrwxrwx 1 snwint suse 28 2009-01-12 14:25 module -> > ../../../../module/amd64_agp > > The directory 'amd64_agp' does not exist. There really is no /sys/module/amd64_agp directory? That's really wierd, Kay, any ideas?
Hmm, no idea, I have that directory: $ ls -l /sys/module/amd64_agp/ total 0 $ uname -a Linux nga 2.6.27.7-9-default #1 SMP 2008-12-04 18:10:04 +0100 x86_64 x86_64 x86_64 GNU/Linux
In the data Stephan sent it's missing: # ls -l sys/bus/pci/drivers/agpgart-amd64 total 0 lrwxrwxrwx 1 snwint suse 28 2009-01-12 14:25 module -> ../../../../module/amd64_agp # ls -l sys/module | head -10 total 0 drwxr-xr-x 3 snwint suse 80 2009-01-12 14:12 8250 drwxr-xr-x 5 snwint suse 240 2009-01-12 14:12 ac97_bus drwxr-xr-x 3 snwint suse 80 2009-01-12 14:12 acpi drwxr-xr-x 2 snwint suse 48 2009-01-12 14:12 aerdriver drwxr-xr-x 5 snwint suse 240 2009-01-12 14:12 af_packet drwxr-xr-x 5 snwint suse 240 2009-01-12 14:12 agpgart drwxr-xr-x 6 snwint suse 264 2009-01-12 14:07 amd74xx drwxr-xr-x 3 snwint suse 80 2009-01-12 14:12 apparmor drwxr-xr-x 6 snwint suse 288 2009-01-12 14:07 ata_generic
btw: # cat proc/version Linux version 2.6.27.7-9-pae (geeko@buildhost) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP 2008-12-04 18:10:04 +0100
I'm running the same version here: amd32os111:/home/stephan # cat /proc/version Linux version 2.6.27.7-9-pae (geeko@buildhost) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP 2008-12-04 18:10:04 +0100 amd32os111:/home/stephan # ls -l /sys/bus/pci/drivers/agpgart-amd64 insgesamt 0 --w------- 1 root root 4096 22. Jan 13:16 bind lrwxrwxrwx 1 root root 0 22. Jan 13:16 module -> ../../../../module/amd64_agp --w------- 1 root root 4096 22. Jan 13:16 new_id --w------- 1 root root 4096 22. Jan 13:16 uevent --w------- 1 root root 4096 22. Jan 13:16 unbind amd32os111:/home/stephan # ls -l /sys/module | head -10 insgesamt 0 drwxr-xr-x 3 root root 0 22. Jan 13:30 8250 drwxr-xr-x 5 root root 0 22. Jan 13:30 ac97_bus drwxr-xr-x 3 root root 0 22. Jan 13:30 acpi drwxr-xr-x 2 root root 0 22. Jan 13:30 aerdriver drwxr-xr-x 5 root root 0 22. Jan 13:30 af_packet drwxr-xr-x 5 root root 0 22. Jan 13:30 agpgart drwxr-xr-x 6 root root 0 22. Jan 13:16 amd74xx drwxr-xr-x 3 root root 0 22. Jan 13:30 apparmor drwxr-xr-x 6 root root 0 22. Jan 13:16 ata_generic And /sys/module/amd64_agp/ is missing. Could it be caused by my cpu (AMD Athlon 64 3200+) and a broken detection during the setup?
Stephan, comments 22 & 23 _are_ from your system.
Do you see anything about "AGP" in "dmesg" output after a reboot?
"dmesg | grep "AGP"" outputs this: agpgart-amd64 0000:00:00.0: AGP bridge [10de/00e1] agpgart-amd64 0000:00:00.0: setting up Nforce3 AGP pci 0000:00:00.0: AGP bridge [10de/00e1] pci 0000:00:00.0: setting up Nforce3 AGP pci 0000:01:00.0: AGP bridge [10de/02e0] pci 0000:01:00.0: setting up Nforce3 AGP "dmesg | grep "agp"" is quite similar: Linux agpgart interface v0.103 agpgart-amd64 0000:00:00.0: AGP bridge [10de/00e1] agpgart-amd64 0000:00:00.0: setting up Nforce3 AGP agpgart-amd64 0000:00:00.0: aperture base > 4G
Since my YaST Software update bug was marked a duplicate of this one (crash when original DVD was not present), let me report that I do not have a ls -l sys/bus/pci/drivers/agpgart-amd64 directory. Maybe that helps.
BTW: I had the same problem with yast and hwinfo on my system (AMD Sempron) and could avoid it by switching from kernel-pae to kernel-default.
Not sure why this is set as NEEDINFO, but this report hasn't been touched in over 9 months. On my system, I see a working sysfs entry for amd64_agp. Closing as NORESPONSE.