Bug#1065073: cryptsetup: Make the information about changes of default cypher and hash in 2.7.0 more visible
Package: cryptsetup Version: 2:2.7.0-1 Severity: wishlist Hi, I recently upgraded my machine running unstable to 2:2.7.0-1, and found that cryptsetup stopped working for my custom encrypted device. I eventually tracked this down to the default cipher and hash settings changing in the latest upstream release. I was specifying the cipher explicitly, but I had to add '-h ripemd160' flag to my invocation, in order for it to use the previous default, which restored my setup to working condition. While this change is mentioned in the upstream release notes, I could not find any mention of it in the Debian's changelog or NEWS file. Given the potential for breakage, please consider making this change more visible in the documentation, before it propagates to testing. I would say that it should also be mentioned in the upgrade instructions for the next stable version, to prevent unpleasant surprises. Thanks. -- Package-specific info: -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cryptsetup depends on: ii cryptsetup-bin 2:2.7.0-1 ii debconf [debconf-2.0] 1.5.86 ii dmsetup2:1.02.196-1 ii libc6 2.37-15 cryptsetup recommends no packages. Versions of packages cryptsetup suggests: pn cryptsetup-initramfs ii dosfstools 4.2-1 pn keyutils ii liblocale-gettext-perl 1.07-6+b1 -- debconf information: cryptsetup/prerm_active_mappings: true
Bug#1016516: notion: Notion fails on startup (in sid)
On Mon, Aug 8, 2022 at 9:50 AM Göran Weinholt wrote: > > @Jurij: What happens if you update your libc6, could you give it a try? > It would be good to get confirmation that the bug was in libc6. > > I can confirm that upgrading libc6 (in my case, to Debian's 2.34-3 package) fixes the problem. -- Jurij Smakov | ju...@wooyd.org | Key ID: 43C30A7D
Bug#1016516: notion: Notion fails on startup (in sid)
On Wed, Aug 3, 2022 at 5:37 PM Dima Kogan wrote: > Jurij Smakov writes: > > > I tried launching notion under rr, and then this assertion does not > > trigger, unfortunately. > > That's too bad. Thanks for trying it out. > > This issue is a race condition, and rr inherently limits the process to > one core. Can you try "rr record --chaos"? This randomizes the thread > switching, and is often effective and triggering these kinds of failures > under rr. > Did not have much luck with --chaos either, the assertion does not trigger. I was able to get a fully symbolized trace with gdb though, it can be found here: http://wooyd.org/dbg/notion.backtrace.txt Does this help? It would probably be useful to get backtraces for other threads as well, but I was not able to quickly figure out how to get rid of this warning: "warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available." which might be preventing me from accessing other threads' information. -- Jurij Smakov | ju...@wooyd.org | Key ID: 43C30A7D
Bug#1016516: notion: Notion fails on startup (in sid)
On Tue, Aug 2, 2022 at 6:32 PM Dima Kogan wrote: > Jurij: thanks for the report. This issue is already tracked here: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016363#15 > > and here: > > https://github.com/raboof/notion/issues/345 > > Arnout (upstream) can't reproduce it currently. > > Jurij and Göran: since you can realiably see this breakage, can you get > a log to Arnout so that he can debug? One useful tool here would be the > rr debugger: > > http://rr-project.org I tried launching notion under rr, and then this assertion does not trigger, unfortunately. > > > You can save a trace of the crashing process, which can then be replayed > forwards and backwards later. "rr pack" would make the traces portable > so that they can be replayed on another machine. > > -- Jurij Smakov | ju...@wooyd.org | Key ID: 43C30A7D
Bug#1016516: notion: Notion fails on startup (in sid)
Package: notion Version: 4.0.2+dfsg-6 Severity: important Greetings, I ran the apt-get update yesterday on my laptop (running sid), and now notion fails to start. After I type my username and password at the DM prompt, it attempts to run it, but then returns back to the prompt. .xsession-errors looks like this: Xsession: X session started for jurij at Tue Aug 2 08:36:18 AM IST 2022 dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus dbus-update-activation-environment: setting DISPLAY=:0 dbus-update-activation-environment: setting XAUTHORITY=/home/jurij/.Xauthority localuser:jurij being added to access control list dbus-update-activation-environment: setting QT_ACCESSIBILITY=1 2022-08-02 08:36:18 INFO /notion/../ioncore.c:596: ioncore_startup: Starting Notion notion: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full: Assertion `e != ESRCH || !robust' failed. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-3-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages notion depends on: ii libc6 2.33-8 ii libice6 2:1.0.10-1 ii liblua5.3-0 5.3.6-1 ii libreadline8 8.1.2-1.2 ii libsm62:1.2.3-1 ii libx11-6 2:1.8.1-1 ii libxext6 2:1.3.4-1 ii libxft2 2.3.4-1 ii libxinerama1 2:1.1.4-3 ii libxrandr22:1.5.2-2+b1 ii lxterminal [x-terminal-emulator] 0.4.0-2 ii menu 2.1.49 ii terminator [x-terminal-emulator] 2.1.1-1 ii x11-utils 7.7+5 ii xterm [x-terminal-emulator] 372-1 Versions of packages notion recommends: ii xfonts-100dpi 1:1.0.4+nmu1.1 ii xfonts-75dpi 1:1.0.4+nmu1.1 Versions of packages notion suggests: ii wmdocker 1.5-2 -- no debconf information
Bug#981377: notion: /usr/share/notion/debian-menu-i18n.lua is a dangling symlink, leading to an error message on startup
Package: notion Version: 4.0.2+dfsg-1 Severity: normal Dear Maintainer, On a fresh install of notion package, I see the following: jurij@paddy:~$ ls -la /usr/share/notion/debian-menu-i18n.lua lrwxrwxrwx 1 root root 36 Jan 14 07:01 /usr/share/notion/debian-menu-i18n.lua -> /var/lib/notion/debian-menu-i18n.lua However, the file /var/lib/notion/debian-menu-i18n.lua does not exist, I only see debian-menu.lua in that directory: jurij@paddy:~$ ls -la /var/lib/notion/ total 24 drwxr-xr-x 2 root root 4096 Jan 30 10:10 . drwxr-xr-x 85 root root 4096 Jan 30 10:10 .. -rw-r--r-- 1 root root 12657 Jan 30 10:10 debian-menu.lua jurij@paddy:~$ Since debian-menu-i18n.lua is referenced somewhere in the config files, an error popup is displayed on every notion startup informing the user that it cannot be found. Cheers. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages notion depends on: ii gnome-terminal [x-terminal-emulator] 3.38.1-2 ii libc6 2.31-6 ii libice6 2:1.0.10-1 ii liblua5.3-0 5.3.3-1.1+b1 ii libreadline8 8.1-1 ii libsm62:1.2.3-1 ii libx11-6 2:1.7.0-2 ii libxext6 2:1.3.3-1.1 ii libxinerama1 2:1.1.4-2 ii libxrandr22:1.5.1-1 ii x11-utils 7.7+5 ii xterm [x-terminal-emulator] 363-1 Versions of packages notion recommends: ii xfonts-100dpi 1:1.0.4+nmu1.1 ii xfonts-75dpi 1:1.0.4+nmu1.1 Versions of packages notion suggests: ii menu 2.1.48 pn wmdocker -- debconf-show failed
Bug#978980: notion: ALTMETA value set to invalid value (empty string) in /etc/defaults/notion, breaking keybindings
Package: notion Version: 4.0.1+dfsg-2 Severity: important Dear Maintainer, Following the upgrade to the latest (unstable) notion package version, I found that keybindings are broken (I think the effect is that META key is considered to be always pressed in this case, leading to some interesting effects), and the following errors are logged on startup: Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]: 2021-01-01 14:24:07 INFO /notion/../ioncore.c:596: ioncore_startup: Starting Notion Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]: >> Can not wait on modifiers when no modifiers set in "L". Perhaps you have incorrectly set ALTMETA to the empty string? Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]: >> Stack trace: Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]:0 [C]: in 'do_defbindings' Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]:1 ioncore_bindings.lua:199: in 'defbindings' Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]:2 /etc/X11/notion/cfg_bindings.lua:127 Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]: [Skipping unnamed C functions.] Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]:5 [C]: in 'dopath' Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]:6 /etc/X11/notion/cfg_notioncore.lua:1 Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]: [Skipping unnamed C functions.] Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]:9 [C]: in 'dopath' Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]:10 /etc/X11/notion/cfg_defaults.lua:19 Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]: [Skipping unnamed C functions.] Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]:13 [C]: in 'dopath' Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]:14 /home/jurij/.notion/default-session--0/cfg_notion.lua:67 Jan 1 14:24:07 paddy /usr/libexec/gdm-x-session[3500]: [Skipping unnamed C functions.] Indeed, the original /etc/default/notion file, where the value of ALTMETA is set, is shipping with ALTMETA="". Setting it to non-empty value, for example ALTMETA="Mod4+Shift+", fixed the problem for me. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages notion depends on: ii gnome-terminal [x-terminal-emulator] 3.38.1-2 ii libc6 2.31-6 ii libice6 2:1.0.10-1 ii liblua5.3-0 5.3.3-1.1+b1 ii libreadline8 8.1-1 ii libsm62:1.2.3-1 ii libx11-6 2:1.6.12-1 ii libxext6 2:1.3.3-1.1 ii libxinerama1 2:1.1.4-2 ii libxrandr22:1.5.1-1 ii x11-utils 7.7+5 ii xterm [x-terminal-emulator] 363-1 Versions of packages notion recommends: ii xfonts-100dpi 1:1.0.4+nmu1 ii xfonts-75dpi 1:1.0.4+nmu1 Versions of packages notion suggests: ii menu 2.1.48 pn wmdocker -- Configuration Files: /etc/default/notion changed: META="Mod4+" ALTMETA="Mod4+Shift+" -- no debconf information
Bug#976053: sysdig-dkms in unstable fails to build with current kernel
Package: sysdig-dkms Version: 0.26.7-2 Severity: important Dear Maintainer, While trying to install sysdig-dkms in unstable, the building of the kernel module(s) fails with the following messages: DKMS make.log for sysdig-0.26.7 for kernel 5.9.0-3-amd64 (x86_64) Sat 28 Nov 2020 02:28:56 PM GMT make: Entering directory '/usr/src/linux-headers-5.9.0-3-amd64' AR /var/lib/dkms/sysdig/0.26.7/build/built-in.a CC [M] /var/lib/dkms/sysdig/0.26.7/build/main.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/dynamic_params_table.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/fillers_table.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/flags_table.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/ppm_events.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/ppm_fillers.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/event_table.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/syscall_table.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/ppm_cputime.o In file included from /usr/src/linux-headers-5.9.0-3-common/include/linux/export.h:43, from /usr/src/linux-headers-5.9.0-3-common/include/linux/linkage.h:7, from /usr/src/linux-headers-5.9.0-3-common/arch/x86/include/asm/cache.h:5, from /usr/src/linux-headers-5.9.0-3-common/include/linux/cache.h:6, from /usr/src/linux-headers-5.9.0-3-common/include/linux/time.h:5, from /usr/src/linux-headers-5.9.0-3-common/include/linux/compat.h:10, from /var/lib/dkms/sysdig/0.26.7/build/ppm_fillers.c:12: /var/lib/dkms/sysdig/0.26.7/build/ppm_fillers.c: In function ‘ppm_get_tty’: /var/lib/dkms/sysdig/0.26.7/build/ppm_fillers.c:691:15: error: implicit declaration of function ‘probe_kernel_read’; did you mean ‘kernel_read’? [-Werror=implicit-function-declaration] 691 | if (unlikely(probe_kernel_read(, >tty, sizeof(tty | ^ /usr/src/linux-headers-5.9.0-3-common/include/linux/compiler.h:78:42: note: in definition of macro ‘unlikely’ 78 | # define unlikely(x) __builtin_expect(!!(x), 0) | ^ cc1: some warnings being treated as errors make[2]: *** [/usr/src/linux-headers-5.9.0-3-common/scripts/Makefile.build:288: /var/lib/dkms/sysdig/0.26.7/build/ppm_fillers.o] Error 1 make[1]: *** [/usr/src/linux-headers-5.9.0-3-common/Makefile:1796: /var/lib/dkms/sysdig/0.26.7/build] Error 2 make: *** [/usr/src/linux-headers-5.9.0-3-common/Makefile:185: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-headers-5.9.0-3-amd64' Judging by the comments found online, this issue appears to be fixed in version 0.27.1. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_BAD_PAGE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sysdig-dkms depends on: ii dkms 2.8.3-4 sysdig-dkms recommends no packages. sysdig-dkms suggests no packages. -- no debconf information
Bug#865628: Please add information about this incompatibility to the installation/upgrading guide
Hello, I hit this issue as well after upgrading to Stretch, and I don't consider mentioning such a major incompatibility in the bug only to be appropriate. I have actually read the relevant parts of the upgrading guide, https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html but it did not mention anything about iscsitarget being deprecated, so the resulting service interruption came as a surprise. At a minimum, please make sure that this deprecation information is added to the documentation above, to prevent others from hitting the same issue unexpectedly. Thanks. -- Jurij Smakov | ju...@wooyd.org | Key ID: 43C30A7D
Bug#853073: Fixed upstream
tags 853073 fixed-upstream thanks A fix for this problem has been committed to mainline as part of the commit https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=926af6273fc683cd98cd0ce7bf0d04a02eed6742 A patch for it (rtlwifi-rtl8192ce-fix-loading-of-incorrect-firmware.patch) has also been added to the 4.9-stable tree: http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/commit/?id=53f769b4a76c06f7c4b7f74f8bdd028b28af6423 Cheers. -- Jurij Smakov | ju...@wooyd.org | Key ID: 43C30A7D
Bug#853073: Wrong firmware loaded as a result of commit 339162b
[Contacting authors of the problematic commit with proposed patch] Hello, I was investigating the regression in performance of wifi on my laptop (using rtl8192ce driver) and I believe that it is a result of recent commit 339162b: https://github.com/torvalds/linux/commit/cf4747d7535a936105f0abe8d8109d3fe339162b I believe that during the refactoring the default name of the firmware file was erroneously changed to rtlwifi/rtl8192cfwU.bin (was rtlwifi/rtl8192cfw.bin before this change) and, as a result, some logic used to determine the correct name of the firmware file for different sub-versions of the card was removed mistakenly as well. This causes wrong firmware to be loaded on my machine (rtl8192cfwU.bin instead of rtl8192cfw.bin), resulting in much more unstable link. Please consider applying the following patch to fix this situation: http://www.wooyd.org/tmp/rtl8192ce_firmware.patch I built a kernel with this patch applied, and the expected firmware was loaded as a result, fixing my problem: [ 13.202250] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin [ 13.253980] ieee80211 phy0: Selected rate control algorithm 'rtl_rc' [ 13.254434] rtlwifi: rtlwifi: wireless switch is on [ 13.460663] rtl8192ce :03:00.0: firmware: direct-loading firmware rtlwifi/rtl8192cfw.bin Cheers. -- Jurij Smakov | ju...@wooyd.org | Key ID: 43C30A7D
Bug#853073: linux-image-4.9.0-1-amd64: Wrong firmware for my card loaded by rtl8192ce driver
Package: src:linux Version: 4.9.2-2 Severity: important Tags: upstream Hello, In the last few weeks I noticed a regression in performance of the wifi card in my ThinkPad X220 laptop (running unstable), the connection has become significantly more flaky, especially further away from the access point. Trying to isolate the failure I booted from a Jessie live CD and noticed that the same wireless driver (rtl8192ce) is loading different firmware in Jessie (rtlwifi/rtl8192cfw.bin) compared to unstable (rtlwifi/rtl8192cfwU.bin). Looks like it is an inadvertent result of the following upstream commits: https://github.com/torvalds/linux/commit/d86e64768859fca82c78e52877ceeba04e25d27a https://github.com/torvalds/linux/commit/cf4747d7535a936105f0abe8d8109d3fe339162b I forced the driver to load the firmware (rtl8192cfw.bin) used by Jessie driver and which I believe to be correct for my card (PCI ID 10ec:8176) by renaming the firmware files, and in this configuration I see much better link stability and latency, as measured by ping to the access point. -- Package-specific info: ** Version: Linux version 4.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20161229 (Debian 6.3.0-2) ) #1 SMP Debian 4.9.2-2 (2017-01-12) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-1-amd64 root=UUID=476bc45a-c62d-409b-b6e9-81acb45fab7e ro quiet ** Not tainted ** Kernel log: ** Model information sys_vendor: LENOVO product_name: 4286CTO product_version: [ 12.688515] ACPI: AC Adapter [AC] (off-line) [ 12.79] ACPI: Battery Slot [BAT0] (battery present) [ 12.880100] Non-volatile memory driver v1.3 [ 12.952811] wmi: Mapper loaded [ 12.959853] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 12.959928] sd 6:0:0:0: Attached scsi generic sg1 type 0 [ 12.982634] thinkpad_acpi: ThinkPad ACPI Extras v0.25 [ 12.982635] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 12.982636] thinkpad_acpi: ThinkPad BIOS 8DET69WW (1.39 ), EC unknown [ 12.982637] thinkpad_acpi: Lenovo ThinkPad X220, model 4286CTO [ 12.983267] thinkpad_acpi: radio switch found; radios are enabled [ 12.983390] thinkpad_acpi: possible tablet mode switch found; ThinkPad in laptop mode [ 12.983505] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver [ 12.983506] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default... [ 12.985350] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [ 12.985925] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [ 13.005025] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input7 [ 13.022735] input: PC Speaker as /devices/platform/pcspkr/input/input8 [ 13.341597] i915: unknown parameter 'i915_enable_rc6' ignored [ 13.342150] [drm] Memory usable by graphics device = 2048M [ 13.342151] [drm] Replacing VGA console driver [ 13.342654] Console: switching to colour dummy device 80x25 [ 13.348084] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 13.348087] [drm] Driver supports precise vblank timestamp query. [ 13.348310] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 13.478619] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 163840 ms ovfl timer [ 13.478621] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules [ 13.478622] RAPL PMU: hw unit of domain package 2^-16 Joules [ 13.478623] RAPL PMU: hw unit of domain pp1-gpu 2^-16 Joules [ 13.559369] snd_hda_codec_conexant hdaudioC0D0: CX20590: BIOS auto-probing. [ 13.559841] snd_hda_codec_conexant hdaudioC0D0: autoconfig for CX20590: line_outs=1 (0x1f/0x0/0x0/0x0/0x0) type:speaker [ 13.559842] snd_hda_codec_conexant hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 13.559843] snd_hda_codec_conexant hdaudioC0D0:hp_outs=2 (0x1c/0x19/0x0/0x0/0x0) [ 13.559844] snd_hda_codec_conexant hdaudioC0D0:mono: mono_out=0x0 [ 13.559844] snd_hda_codec_conexant hdaudioC0D0:inputs: [ 13.559846] snd_hda_codec_conexant hdaudioC0D0: Internal Mic=0x23 [ 13.559846] snd_hda_codec_conexant hdaudioC0D0: Mic=0x1b [ 13.559847] snd_hda_codec_conexant hdaudioC0D0: Dock Mic=0x1a [ 13.561119] snd_hda_codec_conexant hdaudioC0D0: Enable sync_write for stable communication [ 13.588752] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [ 13.588836] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input14 [ 13.588907] [drm] Initialized i915 1.6.0 20160919 for :00:02.0 on minor 0 [ 13.609591] iTCO_vendor_support: vendor-support=0 [ 13.763632] usb 3-1.4: USB disconnect, device number 5 [ 13.781155] fbcon: inteldrmfb (fb0) is primary device [ 13.886155] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [ 13.886216] iTCO_wdt: Found a Cougar Point TCO device (Version=2, TCOBASE=0x0460) [ 13.886384] iTCO_wdt: initialized. heartbeat=30
Bug#802215: gdm3: DISPLAY env variable not set correctly for PostLogin script
Package: gdm3 Version: 3.18.0-2 Severity: important For quite a few years I had an /etc/gdm3/PostLogin/Default script which was executing the following command to set up a custom keyboard layout: setxkbmap -option 'grp:caps_toggle' 'us,ru(phonetic)' After sid update last night this command fails with Cannot open display "" A rather unfortunate consequence of that is that the greeter just displays "Failed to execute PostLogin script" after the password is entered, failing user login and rendering the system unusable. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gdm3 depends on: ii accountsservice 0.6.40-3 ii adduser 3.113+nmu3 ii awesome [x-window-manager] 3.5.6-1 ii dconf-cli0.24.0-2 ii dconf-gsettings-backend 0.24.0-2 ii debconf [debconf-2.0]1.5.57 ii gir1.2-gdm3 3.18.0-2 ii gnome-session [x-session-manager]3.18.0-1 ii gnome-session-bin3.18.0-1+b1 ii gnome-session-flashback [x-session-manager] 3.18.1-1 ii gnome-settings-daemon3.18.1-1+b1 ii gnome-shell 3.18.0-1 ii gnome-terminal [x-terminal-emulator] 3.18.1-1 ii gsettings-desktop-schemas3.18.0-1 ii i3-wm [x-window-manager] 4.11-1 ii libaccountsservice0 0.6.40-3 ii libaudit11:2.4.4-4 ii libc62.19-22 ii libcanberra-gtk3-0 0.30-2.1 ii libcanberra0 0.30-2.1 ii libgdk-pixbuf2.0-0 2.32.1-1 ii libgdm1 3.18.0-2 ii libglib2.0-0 2.46.1-1 ii libglib2.0-bin 2.46.1-1 ii libgtk-3-0 3.18.2-1 ii libpam-modules 1.1.8-3.1 ii libpam-runtime 1.1.8-3.1 ii libpam-systemd 227-2 ii libpam0g 1.1.8-3.1 ii librsvg2-common 2.40.11-1 ii libselinux1 2.3-2+b1 ii libsystemd0 227-2 ii libwrap0 7.6.q-25 ii libx11-6 2:1.6.3-1 ii libxau6 1:1.0.8-1 ii libxdmcp61:1.1.2-1 ii lsb-base 9.20150917 ii metacity [x-window-manager] 1:3.18.1-1 ii mutter [x-window-manager]3.18.0-1+b1 ii notion [x-window-manager]3+2014010901-1 ii policykit-1 0.105-12 ii ucf 3.0030 ii x11-common 1:7.7+12 ii x11-xserver-utils7.7+5 ii xterm [x-terminal-emulator] 320-1 Versions of packages gdm3 recommends: ii at-spi2-core 2.18.0-1 ii desktop-base 8.0.2 ii gnome-icon-theme 3.12.0-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii x11-xkb-utils 7.7+2 ii xserver-xephyr 2:1.17.2-3 ii xserver-xorg 1:7.7+12 ii zenity 3.18.0-1 Versions of packages gdm3 suggests: pn gnome-orca ii libpam-gnome-keyring 3.18.0-4 -- debconf information: gdm3/daemon_name: /usr/sbin/gdm3 * shared/default-x-display-manager: gdm3 -- debsums errors found: debsums: missing file /usr/share/gdm/greeter/autostart/orca-autostart.desktop (from gdm3 package)
Bug#748521: xkb-data: Key mapping changed unexpectedly in ru(phonetic)
Package: xkb-data Version: 2.11-1 Severity: important I've run a package update for unstable yesterday, and as a result the mapping of some keys has changed in the ru(phonetic) layout. Discrepancies with the previous version noticed so far: Latin h - Russian ч (used to be Russian х) Latin = - Russian ь (used to be Russian ч) Latin x - Russian х (used to be Russian ь) I guess that not that many people are using this layout, but still it would be nice to avoid such gratuitous changes. I've been using this mapping for years now, so having to re-train the muscle memory is a bit annoying :-). Cheers. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727775: autocutsel: cutsel cut segfaults if the cut buffer is empty
Package: autocutsel
Version: 0.9.0-2
Severity: important
Tags: patch
If I run cutsel cut when the cut buffer is empty, it fails with
segmentation fault. Looks like XFetchBuffer() returns NULL pointer
in this case, and we are trying to dereference by printing the
value. Checking the length for non-zero value before printing
is one way to avoid that, implemented by attached patch.
On a related (minor) note, cutsel's man page does not mention the
targets and length subcommands, which are implemented by the
binary.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages autocutsel depends on:
ii libc6 2.17-93
ii libice6 2:1.0.8-2
ii libsm62:1.2.1-2
ii libx11-6 2:1.6.2-1
ii libxaw7 2:1.0.11-1
ii libxext6 2:1.3.2-1
ii libxmu6 2:1.1.1-1
ii libxt61:1.1.4-1
autocutsel recommends no packages.
autocutsel suggests no packages.
-- no debconf information
diff -aur a/cutsel.c b/cutsel.c
--- a/cutsel.c 2006-11-05 09:25:50.0 +
+++ b/cutsel.c 2013-10-26 17:34:57.383765419 +0100
@@ -213,7 +213,8 @@
XtAppAddTimeOut(context, 10, Exit, 0);
} else {
options.value = XFetchBuffer(dpy, options.length, buffer);
- printf(%s\n, options.value);
+ if (options.length)
+printf(%s\n, options.value);
exit(0);
}
} else if (strcmp(argv[1], sel) == 0) {
Bug#721498: O: silo -- Sparc Improved LOader
On Wed, Oct 2, 2013 at 11:58 PM, Axel Beckert a...@debian.org wrote: Hi Jurij, Jurij Smakov wrote: On Wed, Oct 2, 2013 at 3:27 AM, Axel Beckert a...@debian.org wrote: I'll create the git repository on Alioth and push my changes as soon as I've got write permissions to /git/debootloaders/. I approved your membership request, so you should be good to go now. Done: http://anonscm.debian.org/gitweb/?p=debootloaders/silo.git;a=shortlog You might want to adjust debian/README.source to reflect the current reality. Upload preferably after I managed to build silo on sparc64, too. If that seems too far away, I'll probably upload earlier. Thanks for picking it up. Thanks for all your work on silo so far! Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- Jurij Smakov | ju...@wooyd.org | Key IDs: 43C30A7D/C99E03CC
Bug#721498: O: silo -- Sparc Improved LOader
On Wed, Oct 2, 2013 at 3:27 AM, Axel Beckert a...@debian.org wrote: Control: retitle -1 ITA: silo -- Sparc Improved LOader Control: owner -1 ! Hi Jurij, Jurij Smakov wrote: There are currently no serious bugs that I know of, so it's mostly about keeping it reasonably up to date. Ok, I'll try my luck. I managed to revamp the package in a way that my UltraSparc still boots. ;-) I though couldn't yet play around with silo on sparc64, see my other recent mail to debian-sp...@lists.debian.org. Prospective maintainers should have access to sparc hardware to be able to do at least minimal testing, Given. joining the 'debootloaders' project on Alioth (within which silo was previously maintained) is a good idea as well. Request sent. I'm also already subscribed to the debootloaders-silo mailing list. I though don't intent to continue maintaining the package in svn, but rather switch to git, with the git repository based on the previous svn repository. I'll create the git repository on Alioth and push my changes as soon as I've got write permissions to /git/debootloaders/. I approved your membership request, so you should be good to go now. Thanks for picking it up. Further co-maintainers of course still welcome! :-) Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- Jurij Smakov | ju...@wooyd.org | Key IDs: 43C30A7D/C99E03CC
Bug#721498: O: silo -- Sparc Improved LOader
Package: wnpp Severity: normal [This message is bcc'd to sub...@bugs.debian.org.] Given that I'm no longer involved with sparc port and none of the other silo maintainers appear to be active (no replies to [0], sent over a month ago), I think the best course of action is to orphan silo. There are currently no serious bugs that I know of, so it's mostly about keeping it reasonably up to date. Prospective maintainers should have access to sparc hardware to be able to do at least minimal testing, joining the 'debootloaders' project on Alioth (within which silo was previously maintained) is a good idea as well. Cheers. [0] http://lists.alioth.debian.org/pipermail/debootloaders-silo/2013-July/84.html
Bug#708864: Munin breaks Apache config on removal
Package: munin Version: 2.0.14-1 Severity: important As illustrated by the following transcript, removing munin and friends results in a dangling symlink /etc/apache2/conf.d/munin - ../../munin/apache.conf which breaks apache configuration. jurij@paddy:~$ sudo apt-get install munin Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: munin-common munin-doc munin-node munin-plugins-core munin-plugins-extra Suggested packages: libapache2-mod-fcgid munin-plugins-java liblwp-useragent-determined-perl libnet-irc-perl mysql-client smartmontools ethtool libdbd-pg-perl libdbd-mysql-perl libcache-cache-perl libtext-csv-xs-perl logtail libnet-netmask-perl libnet-telnet-perl conntrack The following NEW packages will be installed: munin munin-common munin-doc munin-node munin-plugins-core munin-plugins-extra 0 upgraded, 6 newly installed, 0 to remove and 117 not upgraded. Need to get 0 B/1,129 kB of archives. After this operation, 2,891 kB of additional disk space will be used. Do you want to continue [Y/n]? Selecting previously unselected package munin-common. (Reading database ... 237491 files and directories currently installed.) Unpacking munin-common (from .../munin-common_2.0.14-1_all.deb) ... Selecting previously unselected package munin. Unpacking munin (from .../munin_2.0.14-1_all.deb) ... Selecting previously unselected package munin-doc. Unpacking munin-doc (from .../munin-doc_2.0.14-1_all.deb) ... Selecting previously unselected package munin-plugins-core. Unpacking munin-plugins-core (from .../munin-plugins-core_2.0.14-1_all.deb) ... Selecting previously unselected package munin-node. Unpacking munin-node (from .../munin-node_2.0.14-1_all.deb) ... Selecting previously unselected package munin-plugins-extra. Unpacking munin-plugins-extra (from .../munin-plugins-extra_2.0.14-1_all.deb) ... Processing triggers for man-db ... Setting up munin-common (2.0.14-1) ... Setting up munin (2.0.14-1) ... [ ok ] Reloading web server config: apache2. Setting up munin-doc (2.0.14-1) ... Setting up munin-plugins-core (2.0.14-1) ... Setting up munin-node (2.0.14-1) ... Initializing plugins..done. [ ok rting munin-node..[] Stopping Munin-Node: stopped beforehand. [ ok ] Starting Munin-Node: done. [ ok ] Starting Munin-Node: started beforehand. Setting up munin-plugins-extra (2.0.14-1) ... jurij@paddy:~$ ls -al /etc/apache2/conf.d/munin lrwxrwxrwx 1 root root 23 May 19 10:29 /etc/apache2/conf.d/munin - ../../munin/apache.conf jurij@paddy:~$ sudo apt-get --purge remove munin-common munin-doc munin-node munin-plugins-core munin-plugins-extra Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: libdate-manip-perl libio-multiplex-perl libipc-shareable-perl liblog-dispatch-perl liblog-log4perl-perl libnet-cidr-perl libnet-server-perl libnet-snmp-perl rrdtool Use 'apt-get autoremove' to remove them. The following packages will be REMOVED: munin* munin-common* munin-doc* munin-node* munin-plugins-core* munin-plugins-extra* 0 upgraded, 0 newly installed, 6 to remove and 117 not upgraded. After this operation, 2,891 kB disk space will be freed. Do you want to continue [Y/n]? (Reading database ... 237933 files and directories currently installed.) Removing munin ... Purging configuration files for munin ... The generated web site or accumulated data won't be removed. dpkg: warning: while removing munin, directory '/var/cache/munin/www' not empty so not removed dpkg: warning: while removing munin, directory '/var/lib/munin' not empty so not removed dpkg: warning: while removing munin, directory '/etc/munin/munin-conf.d' not empty so not removed Removing munin-plugins-extra ... Removing munin-node ... [ ok ] Stopping Munin-Node: done. Purging configuration files for munin-node ... Removing munin-plugins-core ... dpkg: warning: while removing munin-plugins-core, directory '/etc/munin/plugins' not empty so not removed Removing munin-common ... Removing munin-doc ... Processing triggers for man-db ... jurij@paddy:~$ sudo /etc/init.d/apache2 restart apache2: Syntax error on line 265 of /etc/apache2/apache2.conf: Could not open configuration file /etc/apache2/conf.d/munin: No such file or directory Action 'configtest' failed. The Apache error log may have more information. failed! jurij@paddy:~$ ls -al /etc/apache2/conf.d/munin lrwxrwxrwx 1 root root 23 May 19 10:29 /etc/apache2/conf.d/munin - ../../munin/apache.conf jurij@paddy:~$ Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674908: Don't think it's the same bug
Hi, Based on your system information, I don't think it's the same bug. This bug is about Javascript-related crashes on sparc hardware and your backtrace was obtained on a x86 machine. It also does not look too useful, as it was obtained with 'xulrunner-stub' binary (no idea what this is). If your crash is reproducible, please get a useful backtrace and file a separate bug for it. Recommended procedure: 0. Install debug binaries (iceweasel-dbg and libmozjs10d-dbg packages). 1. Run 'ulimit -c unlimited'. 2. Start iceweasel. 3. Trigger the crash, it should dump core. 4. Run 'gdb /usr/lib/iceweasel/firefox-bin core'. 5. Enter 'bt' to show the backtrace. Thanks. -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674908: Status update
Following up on my previous update [0]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674908#38 Only Hartwig responded to my call to testing of fixed binary [1], and, unfortunately, it still crashes for him on the same site [2]. It does not for me, however I have a different CPU: UltraSPARC III as opposed to UltraSPARC II in Hartwig's SunBlade 100. As I don't have access to to a machine where the bug is reproducible, I will not able to make any further progress on this bug. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674908#38 [1] http://lists.debian.org/debian-sparc/2013/02/msg00011.html Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674908: Patch
Hi,
Attached is a patch against 10.0.12esr which (hopefully) fixes a bunch
of unaligned memory accesses described in my previous update. It's not
pretty, but a browser compiled with this patch is good enough to
browse www.cnn.com and gmail.com without crashing, and compiler should
be smart enough to optimize away all its effects on arches other than
sparc.
You probably want to run it past some upstream maintainer before
applying, but it is definitely an improvement compared to current
testing version. I'll make the binaries available and ask people on
debian-sparc to test.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
diff -aur a/js/src/methodjit/Compiler.cpp b/js/src/methodjit/Compiler.cpp
--- a/js/src/methodjit/Compiler.cpp 2013-01-03 17:43:19.0 +
+++ b/js/src/methodjit/Compiler.cpp 2013-02-10 20:49:38.925659583 +
@@ -965,22 +965,31 @@
}
/* Please keep in sync with JITScript::scriptDataSize! */
-size_t dataSize = sizeof(JITScript) +
- sizeof(NativeMapEntry) * nNmapLive +
- sizeof(InlineFrame) * inlineFrames.length() +
- sizeof(CallSite) * callSites.length() +
+size_t dataSize = sizeof(JITScript);
+dataSize += ALIGN_TO(dataSize, NativeMapEntry) +
+sizeof(NativeMapEntry) * nNmapLive;
+dataSize += ALIGN_TO(dataSize, InlineFrame) +
+sizeof(InlineFrame) * inlineFrames.length();
+dataSize += ALIGN_TO(dataSize, CallSite) +
+sizeof(CallSite) * callSites.length();
#if defined JS_MONOIC
- sizeof(ic::GetGlobalNameIC) * getGlobalNames.length() +
- sizeof(ic::SetGlobalNameIC) * setGlobalNames.length() +
- sizeof(ic::CallICInfo) * callICs.length() +
- sizeof(ic::EqualityICInfo) * equalityICs.length() +
+dataSize += ALIGN_TO(dataSize, ic::GetGlobalNameIC) +
+sizeof(ic::GetGlobalNameIC) * getGlobalNames.length();
+dataSize += ALIGN_TO(dataSize, ic::SetGlobalNameIC) +
+sizeof(ic::SetGlobalNameIC) * setGlobalNames.length();
+dataSize += ALIGN_TO(dataSize, ic::CallICInfo) +
+sizeof(ic::CallICInfo) * callICs.length();
+dataSize += ALIGN_TO(dataSize, ic::EqualityICInfo) +
+sizeof(ic::EqualityICInfo) * equalityICs.length();
#endif
#if defined JS_POLYIC
- sizeof(ic::PICInfo) * pics.length() +
- sizeof(ic::GetElementIC) * getElemICs.length() +
- sizeof(ic::SetElementIC) * setElemICs.length() +
+dataSize += ALIGN_TO(dataSize, ic::GetElementIC) +
+sizeof(ic::GetElementIC) * getElemICs.length();
+dataSize += ALIGN_TO(dataSize, ic::SetElementIC) +
+sizeof(ic::SetElementIC) * setElemICs.length();
+dataSize += ALIGN_TO(dataSize, ic::PICInfo) +
+sizeof(ic::PICInfo) * pics.length();
#endif
- 0;
uint8 *cursor = (uint8 *)cx-calloc_(dataSize);
if (!cursor) {
@@ -1014,6 +1023,7 @@
Label *jumpMap = a-jumpMap;
/* Build the pc - ncode mapping. */
+cursor += ALIGN_TO(cursor - (uint8 *) jit, NativeMapEntry);
NativeMapEntry *jitNmap = (NativeMapEntry *)cursor;
jit-nNmapPairs = nNmapLive;
cursor += sizeof(NativeMapEntry) * jit-nNmapPairs;
@@ -1049,6 +1059,7 @@
JS_ASSERT(ix == jit-nNmapPairs);
/* Build the table of inlined frames. */
+cursor += ALIGN_TO(cursor - (uint8 *) jit, InlineFrame);
InlineFrame *jitInlineFrames = (InlineFrame *)cursor;
jit-nInlineFrames = inlineFrames.length();
cursor += sizeof(InlineFrame) * jit-nInlineFrames;
@@ -1065,6 +1076,7 @@
}
/* Build the table of call sites. */
+cursor += ALIGN_TO(cursor - (uint8 *) jit, CallSite);
CallSite *jitCallSites = (CallSite *)cursor;
jit-nCallSites = callSites.length();
cursor += sizeof(CallSite) * jit-nCallSites;
@@ -1109,6 +1121,7 @@
jit-argsCheckPool = NULL;
}
+cursor += ALIGN_TO(cursor - (uint8 *) jit, ic::GetGlobalNameIC);
ic::GetGlobalNameIC *getGlobalNames_ = (ic::GetGlobalNameIC *)cursor;
jit-nGetGlobalNames = getGlobalNames.length();
cursor += sizeof(ic::GetGlobalNameIC) * jit-nGetGlobalNames;
@@ -1124,6 +1137,7 @@
stubCode.patch(from.addrLabel, to);
}
+cursor += ALIGN_TO(cursor - (uint8 *) jit, ic::SetGlobalNameIC);
ic::SetGlobalNameIC *setGlobalNames_ = (ic::SetGlobalNameIC *)cursor;
jit-nSetGlobalNames = setGlobalNames.length();
cursor += sizeof(ic::SetGlobalNameIC) * jit-nSetGlobalNames;
@@ -1157,6 +1171,7 @@
stubCode.patch(from.addrLabel, to);
}
+cursor += ALIGN_TO(cursor - (uint8 *) jit, ic::CallICInfo);
ic::CallICInfo *jitCallICs = (ic::CallICInfo *)cursor;
jit-nCallICs = callICs.length
Bug#674908: Testing with newer iceweasel
0xf1a5f02e -240783314 (gdb) Either way, I assume that chances of new version getting into wheezy at this point are pretty slim. For the current wheezy version I've posted some analysis of the crash at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688086#10 Perhaps we should look into fixing the alignment issues of this code. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674908: Clarification
To be clear: the Javascript crash described in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688086#10 is the one I currently see with the current version of iceweasel in wheezy (10.0.12esr-1). It is sufficient to go to www.cnn.com, for example, to trigger it. I believe that the crash originally reported by Hartwig is no longer there. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688086: Same issue as 634261
On Sun, Jan 13, 2013 at 11:14:38PM +0100, John Paul Adrian Glaubitz wrote: reassign 688086 libc6 merge 634261 688086 thanks Hi, I have upgraded a Ultra5 from stable to testing. A few weeks ago, Iceape ran fine even on sparc architecture, when testing package aborts with a bus error without opening first window. I cannot make more tests until next saturday. This is the same issue as in Debian bugs #634261 [1], reassigning to No, this is a completely different bug. Please see my update with analysis. libc6 and merging. This bug report also contains a detailed explanation by Michael Karcher where this bug originates from (it is actually a bug in libc6). As far as I know, newer releases of XULrunner avoid this problem by exporting the _IO_stdin_used symbol again, so that these crashes don't happen anymore. I don't see iceape crashing immediately on startup, but it's fairly common for it to crash on any site which uses Javascript, so I'll assume that this is the bug you see, lacking other information. I tried iceweasel (10.0.7esr-2) and it crashes in exactly the same way. And this is the same problem as described in #674908 [2], please refer to this bug report for a follow-up discussion. Cheers, Adrian [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634261 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674908 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688086: Analysis
I don't see iceape crashing immediately on startup, but it's fairly
common for it to crash on any site which uses Javascript, so I'll
assume that this is the bug you see, lacking other information. I
tried iceweasel (10.0.7esr-2) and it crashes in exactly the same way.
Here's a backtrace:
#0 updateLastPath (label=..., linker=..., this=0xee1544c4) at
/build/buildd-iceweasel_10.0.7esr-2-sparc-752pBb/iceweasel-10.0.7esr/js/src/methodjit/PolyIC.h:437
#1 SetPropCompiler::generateStub (this=0xffcd3ddc, initialShape=optimized
out, shape=optimized out, adding=optimized out)at
/build/buildd-iceweasel_10.0.7esr-2-sparc-752pBb/iceweasel-10.0.7esr/js/src/methodjit/PolyIC.cpp:502
#2 0xf741d748 in SetPropCompiler::update (this=0xffcd3ddc) at
/build/buildd-iceweasel_10.0.7esr-2-sparc-752pBb/iceweasel-10.0.7esr/js/src/methodjit/PolyIC.cpp:668
#3 0xf74124b4 in js::mjit::ic::SetProp (f=..., pic=0xee1544c4)at
/build/buildd-iceweasel_10.0.7esr-2-sparc-752pBb/iceweasel-10.0.7esr/js/src/methodjit/PolyIC.cpp:2058
#4 0xf746ce94 in JaegerStubVeneer () at
/build/buildd-iceweasel_10.0.7esr-2-sparc-752pBb/iceweasel-10.0.7esr/js/src/methodjit/TrampolineSparc.s:164
#5 0xf746ce94 in JaegerStubVeneer () at
/build/buildd-iceweasel_10.0.7esr-2-sparc-752pBb/iceweasel-10.0.7esr/js/src/methodjit/TrampolineSparc.s:164
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The disassembled portion of updateLastPath where the crash happens:
0xf741c764 +2436: ldd [ %fp + -1512 ], %g2
0xf741c768 +2440: ld [ %g1 + 0x14 ], %g4
= 0xf741c76c +2444: std %g2, [ %g1 + 0x30 ]
As far as I can tell, it translates to the following line of code in
js/src/methodjit/PolyIC.h (struct PICInfo):
lastStubStart = JITCode(loc.executableAddress(), linker.size());
JITCode is a class which has two word-size members, m_start (pointer)
and m_size (size_t). Compiler tries to store it as a double-word in
one instruction, and this is only possible if the lastStubStart is
8-bytes aligned. Offset of lastStubStart into struct PICInfo is 0x30
(as can be seen above), so in order for it to be 8-bytes aligned, the
whole PICInfo structure needs to be 8-bytes aligned. This is clearly
not the case, this=0xee1544c4 passed to updateLastPath is PICInfo
structure's address, and it's only 4-bytes aligned.
Trying to track down the place where PICInfo is allocated violating
alignment requirements, I found the mjit::Compiler::finishThisUp
(in js/src/methodjit/Compiler.cpp) which tries to construct some
complex data structure by computing its size as dataSize, allocating a
chunk of memory for it, then manually stuffing objects there,
including PICInfo:
[...]
ic::PICInfo *jitPics = (ic::PICInfo *)cursor;
jit-nPICs = pics.length();
cursor += sizeof(ic::PICInfo) * jit-nPICs;
for (size_t i = 0; i jit-nPICs; i++) {
new (jitPics[i]) ic::PICInfo();
[...]
Not surprisingly, this goes wrong at some point, and PICInfo structure
occasionally gets placed at an insufficiently aligned address - I was
able to confirm that by inserting an fprintf statement there to print
out the adresses of jitPics[i] and corresponding lastStubStart object.
I don't have a solid proof that this is the cause of the problem, but
it seems pretty likely, as any attempt of manual memory management
like this increases the probability that alignment requirements get
violated. I suggest notifying the iceweasel maintainer and reporting
this upstream, because I don't really see a simple way to fix it.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670578: FTBFS on ia64
Hi, The latest uploaded version failed to build on ia64, blocking propagation to testing: https://buildd.debian.org/status/fetch.php?pkg=gnunetarch=ia64ver=0.9.3-3stamp=1347735437 Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688521: Netra T1 200 watchdog timeouts
On Sun, Sep 23, 2012 at 02:07:46PM +, Mark Morgan Lloyd wrote: It went in as 688521 at about the same time as you posted. Pity I didn't hold off for another hour or so. Thanks, I'll bcc this response to the bug, let's continue discussion there. Looking at the output you see, I have doubts that it has anything to do with SILO though. SILO prints letters 'S', 'I', 'L' and 'O' (appearing before the prompt) after it completes execution of different parts of first-stage loader. As you can see in the code (first/first.S), printing 'S' is the first thing first-stage loader does upon startup. The fact that it is not seen in the console output suggests that even first-stage loader never got to run. The line Boot device: /pci@1f,0/pci@1/scsi@8/disk@0,0:a File and args: which is normally printed by OBP before control is passed to SILO does not appear in the watchdog-reset case either, which, again, is a strong sign that failure happens before SILO has a chance to run. In a failure case, how long does it take between you typing 'boot' and watchdog reset message being displayed? This doc http://docs.oracle.com/cd/E19102-01/n240.srvr/817-5481-11/understanding_wdtimer.html appears to suggest that stuck watchdog would initiate a XIR after 60 seconds by default, is it consistent with what you see? What are the values of various variables mentioned there on your system(s)? Does increasing the timeout help? I really can't come up with any reason why it would work for Squeeze but not other releases, so testing all suspect SILO versions on the same machine would be an interesting experiment. This is something I've not had to do before- Debian usually just works or I have to go upstream if I want something bleeding-edge. Is this syntax right and in view of the message what should I have in sources.list etc? root@firewall3:/home/markMLl# apt-get install silo=1.4.14+git20100228-1+b1 .. E: Version '1.4.14+git20100228-1+b1' for 'silo' was not found That only works when you have repositories containing older/newer packages listed in your /etc/apt/source.list. Simply adding them (without configuring apt pinning appropriately) may mess up too many things, so the simplest way is probably to just download older SILO debs (should be available on archive.debian.org) and install them using dpkg -i. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687454: Reassigning to installation-guide
retitle 687454 Mention that some drivers are functional without firmware reassign 687454 installation-guide thanks The problem of missing vio_type binary is already tracked in http://bugs.debian.org/678264, so no further action is required. Today I've received a report from another user who was confused by the tg3 driver prompting for firmware, so it looks like it would be beneficial to modify Devices Requiring Firmware section of the installation guide. In particular, We should include a note there that for some devices firmware may not be necessary, even though a firmware prompt is displayed. Broadcom devices using tg3 drivers may be mentioned as an example of such behavior. The pages http://wiki.debian.org/Firmware http://wiki.debian.org/DebianInstaller/NetbootFirmware also contain some useful firmware-related information and tricks, so might be worth mentioning. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686085: Built successfully on retry
FWIW, imagemagick built successfully on retry: https://buildd.debian.org/status/fetch.php?pkg=imagemagickarch=sparcver=8%3A6.7.7.10-4stamp=1347041889 Also, I was not able to reproduce this failure on my sparc box. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678264: Error messages on Sparc T1000
Hi, I got access to a Sparc T1000 which supports VIO devices. When I tried wheezy beta2 installer on it, I also saw error messages caused by missing vio_type binary on the initial boot(bug #687454). Even though I'm not installing into LDOM, there are still some devices matching 'vio' subsystem, so the rules involving vio_type are triggered. All of the end up with VIO_TYPE=none, so no modules would be loaded as a result (that happens on regular boots), but still it would be nice to include vio_type in the udeb, so that no errors are produced. I could test an installation into LDOM, but it's clear that it's not going to work out of the box while vio_type binary is not available in installer's initrd. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687454: Wheezy beta2 on Sparc T1000 server - mostly successful
Package: installation-reports I tried Wheezy beta2 installer netboot image on a Sparc T1000 server (there is no other way to boot installer on this machine) using console on the ethernet management port. Installation went ok apart from two minor issues: 1. During the initial boot the following messages appear on the screen: udevd[51]: failed to execute '/lib/udev/vio_type' 'vio_type --export /devices/channel-devices': No such file or directory udevd[54]: failed to execute '/lib/udev/vio_type' 'vio_type --export /devices/channel-devices/vldc-port-0-0': No such file or directory udevd[55]: failed to execute '/lib/udev/vio_type' 'vio_type --export /devices/channel-devices/ds-1': No such file or directory udevd[53]: failed to execute '/lib/udev/vio_type' 'vio_type --export /devices/channel-devices/ds-0': No such file or directory udevd[56]: failed to execute '/lib/udev/vio_type' 'vio_type --export /devices/channel-devices/vldc-port-0-1': No such file or directory udevd[57]: failed to execute '/lib/udev/vio_type' 'vio_type --export /devices/channel-devices/vldc-port-0-2': No such file or directory udevd[61]: failed to execute '/lib/udev/vio_type' 'vio_type --export /devices/channel-devices/vldc-port-1-0': No such file or directory udevd[62]: failed to execute '/lib/udev/vio_type' 'vio_type --export /devices/channel-devices/vldc-port-3-8': No such file or directory udevd[63]: failed to execute '/lib/udev/vio_type' 'vio_type --export /devices/channel-devices/vldc-port-3-0': No such file or directory This problem appears to be specific to installer's initrd, because I don't see these messages on post-installation reboots. 2. Before the network configuration step the installer prompts to load tg3 firmware from removable medium. It would be a problem, because machine does not have any USB ports, but it turned out that the ethernet cards are functional even without the firmware. Thus, all you need to do is decline the firmware loading step and the installation proceeds normally. According to dmesg, the cards are identified as Tigon3 [partno(BCM95714) rev 9001] (PCIX:133MHz:64-bit) (machine has 4 of them installed). It might be worth mentioning in the installation manual that even though some cards may indicate that they require firmware, it may be optional for their operation. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649841: Is the fix planned for wheezy?
Hi Kurt, Are you planning to fix this before wheezy is out? Releasing with all sparc-specific openssl optimizations disabled does seem suboptimal. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686451: unblock: silo/1.4.14+git20120819-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear release team, Please unblock silo/1.4.14+git20120819-1 for testing. It fixes an RC bug (#685245) affecting Debian installer images on Niagara machines and contains two more bug fixes from upstream. There are no packaging- or Debian-specific changes. Full changelog entry: silo (1.4.14+git20120819-1) unstable; urgency=low [ Jurij Smakov ] * New upstream release containing only the following bug fixes: - Fix ext4 extent resolution. Without this fix silo fails to read silo.conf off a ext4 filesystem. Commit: 6ab3e76216353af6b60a99f7e5ebf5611047c831 - Fix silo crash on Niagara (sun4v) machines whenever 'timeout' parameter is used in silo.conf. (Closes: #685245) Commits: 1121ecf7b087b940339e421b2928067c92f6237e dcee4ca86e88aeec8c6f2c8062035419204b4701 - Include stddef.h in stringops.h. Fixes build failure when compiled against 3.4 Linux headers. Commit: 2999c98e8241b81cb35846961672fc7d8c3fe235 -- Jurij Smakov ju...@debian.org Sun, 19 Aug 2012 16:14:18 +0100 This version was announced on debian-sparc and spent over 10 days in unstable after that. I did not receive any complaints or bugs about it during that time, no problems were reported to the upstream mailing list either. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666525: Bumping severity to RC
retitle 666525 pbuilder fails to create directory under ccache when run with sudo severity 666525 serious thanks Hello, I just ran into this bug. On a freshly installed testing system I ran sudo pbuilder --create --distribution sid --mirror http://ftp.ie.debian.org/debian and then ran a build with: sudo pbuilder build *.dsc Package build gets to the compilation stage and fails with error messages: [...] gcc -m32 -Os -Wall -I. -I../include -fomit-frame-pointer -fno-strict-aliasing -DSMALL_RELOC=0x28 -DLARGE_RELOC=0x38 -fno-stack-protector -c printf.c ccache: FATAL: Failed to create /var/cache/pbuilder/ccache/a/c: Permission denied make[2]: *** [printf.o] Error 1 make[2]: Leaving directory `/tmp/buildd/silo-1.4.14+git20120819/build-tree/common' make[1]: *** [all] Error 1 make[1]: Leaving directory `/tmp/buildd/silo-1.4.14+git20120819/build-tree' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Here are the permissions of relevant directories: jurij@debian:~$ ls -la /var/cache/pbuilder/ total 93404 drwxr-xr-x 9 root root 4096 Aug 19 15:12 . drwxr-xr-x 10 root root 4096 Aug 19 13:44 .. drwxr-xr-x 2 root root12288 Aug 19 15:17 aptcache -rw-r--r-- 1 root root 95597991 Aug 19 15:12 base.tgz drwxr-xr-x 2 root root 4096 Aug 19 15:17 build drwxr-xr-x 12 1234 1234 4096 Aug 19 15:17 ccache drwxr-xr-x 2 root root 4096 May 30 11:04 pbuildd drwxr-xr-x 2 root root 4096 May 30 11:04 pbuilder-mnt drwxr-xr-x 2 root root 4096 May 30 11:04 pbuilder-umlresult drwxr-xr-x 2 root root 4096 May 30 11:04 result jurij@debian:~$ ls -la /var/cache/pbuilder/ccache/ total 52 drwxr-xr-x 12 1234 1234 4096 Aug 19 15:17 . drwxr-xr-x 9 root root 4096 Aug 19 15:12 .. drwxr-xr-x 2 1234 1234 4096 Aug 19 15:17 1 drwxr-xr-x 2 1234 1234 4096 Aug 19 15:17 3 drwxr-xr-x 2 1234 1234 4096 Aug 19 15:17 4 drwxr-xr-x 2 1234 1234 4096 Aug 19 15:17 5 drwxr-xr-x 2 1234 1234 4096 Aug 19 15:17 8 drwxr-xr-x 2 1234 1234 4096 Aug 19 15:17 9 drwxr-xr-x 2 root root 4096 Aug 19 15:14 a drwxr-xr-x 2 1234 1234 4096 Aug 19 15:17 b -rw-r--r-- 1 root root 190 Aug 19 15:14 CACHEDIR.TAG drwxr-xr-x 2 1234 1234 4096 Aug 19 15:17 e drwxr-xr-x 2 root root 4096 Aug 19 15:14 tmp jurij@debian:~$ I don't think it's acceptable to release a package which fails a basic operation with default settings (I did not create or modify ~/.pbuilderrc or any other related configuration files), hence the RC severity. Looking around, I see a number of discussions mentioning similar problems, for example: http://lists.debian.org/debian-devel/2012/05/msg00223.html In case it matters, these tests were carried out on a sparc system. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683811: --link-dest is broken in some cases
Package: rsync Version: 3.0.9-3 Severity: important Hello, I've accidentally noticed that my home directory backups (done using rsync and --link-dest set to last backup directory) are taking up much more space than expected. Investigation revealed that the unchanged files are actually not hard-linked, as I would expect. Here's a small demo: jurij@paddy:~/tmp$ mkdir src jurij@paddy:~/tmp$ touch src/foo jurij@paddy:~/tmp$ rsync -r /home/jurij/tmp/src/ link jurij@paddy:~/tmp$ ls -al link total 8 drwxr-xr-x 2 jurij jurij 4096 Aug 4 10:13 . drwxr-xr-x 4 jurij jurij 4096 Aug 4 10:13 .. -rw-r--r-- 1 jurij jurij0 Aug 4 10:13 foo jurij@paddy:~/tmp$ rsync -r --link-dest /home/jurij/tmp/link /home/jurij/tmp/src/ dst jurij@paddy:~/tmp$ ls -al dst total 8 drwxr-xr-x 2 jurij jurij 4096 Aug 4 10:13 . drwxr-xr-x 5 jurij jurij 4096 Aug 4 10:13 .. -rw-r--r-- 1 jurij jurij0 Aug 4 10:13 foo jurij@paddy:~/tmp$ stat dst/foo File: `dst/foo' Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 807h/2055d Inode: 1572876 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ jurij) Gid: ( 1000/ jurij) Access: 2012-08-04 10:13:46.007097660 +0100 Modify: 2012-08-04 10:13:46.007097660 +0100 Change: 2012-08-04 10:13:46.007097660 +0100 Birth: - jurij@paddy:~/tmp$ As you can see, the file dst/foo has link count of 1, and I would expect it to be 2, as it should be just hardlinked to link/foo. In case it matters, /home is its own partition, with ext4 filesystem. Corresponding line from mount output (all options are default, as set during install): /dev/sda7 on /home type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered) I'm pretty sure that it used to work before, I've been doing the backups the same way for a couple of years, and older backups do have files hard-linked, as expected. If this bug is confirmed, I would expect its severity to be bumped to RC. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670578: Reassigning to gnunet
tags 670578 = patch reassign 670578 gnunet found 670578 0.9.3-2 thanks Hello, Christian confirmed that my analysis was correct and committed a fix for this issue to gnunet svn repo: http://lists.gnu.org/archive/html/gnunet-svn/2012-07/msg00548.html Please pick up this patch for Debian, as 0.9.3 (current unstable/wheezy version) is affected by it as well. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670578: Unable to reproduce in latest wheezy
tags 670578 unreproducible thanks Hi, I finally got some time to look into this. I tried following the instructions to reproduce and built extractor/libmicrohttpd/gnunet from svn head on a freshly installed wheezy system, but some steps did not produce expected results. For example, when i run 'make check' in src/vpn directory after building/installing the binaries, all I get is 'nothing to be done for check', and no tests get run. Also, it's not completely clear from your message how the gnunet.conf should look like to reproduce the crashes, to I just tried running everything with empty config (just did 'touch /home/jurij/.gnunet/gnunet.conf'). Here are the results: jurij@debian:~/.gnunet$ gnunet-arm -s Service `arm' has been started. jurij@debian:~/.gnunet$ ps auxww | grep gnunet jurij23989 0.1 0.0 5400 880 ?Ss 13:34 0:00 gnunet-service-arm -c /home/jurij/.gnunet/gnunet.conf -d jurij23990 0.2 0.0 7424 1672 ?S13:34 0:00 gnunet-daemon-topology -c /home/jurij/.gnunet/gnunet.conf jurij23991 0.5 0.1 12528 3544 ?S13:34 0:00 gnunet-daemon-hostlist -c /home/jurij/.gnunet/gnunet.conf -b jurij23992 0.5 0.1 8184 3088 ?SN 13:34 0:00 gnunet-service-dht -c /home/jurij/.gnunet/gnunet.conf jurij23993 0.2 0.0 5768 1488 ?S13:34 0:00 gnunet-service-nse -c /home/jurij/.gnunet/gnunet.conf jurij23994 0.2 0.0 6056 1552 ?S13:34 0:00 gnunet-service-mesh -c /home/jurij/.gnunet/gnunet.conf jurij23995 0.7 0.1 7680 2296 ?SN 13:34 0:00 gnunet-service-fs -c /home/jurij/.gnunet/gnunet.conf jurij23996 0.1 0.0 5920 1512 ?S13:34 0:00 gnunet-service-core -c /home/jurij/.gnunet/gnunet.conf jurij23997 0.2 0.0 5880 1520 ?S13:34 0:00 gnunet-service-transport -c /home/jurij/.gnunet/gnunet.conf jurij23998 0.8 0.1 6680 2504 ?SN 13:34 0:00 gnunet-service-datastore -c /home/jurij/.gnunet/gnunet.conf jurij23999 0.2 0.0 5576 1448 ?SN 13:34 0:00 gnunet-service-ats -c /home/jurij/.gnunet/gnunet.conf jurij24000 0.2 0.0 5560 1448 ?SN 13:34 0:00 gnunet-service-statistics -c /home/jurij/.gnunet/gnunet.conf jurij24001 0.2 0.0 5640 1664 ?SN 13:34 0:00 gnunet-service-peerinfo -c /home/jurij/.gnunet/gnunet.conf jurij24003 0.0 0.0 3808 1072 pts/0R+ 13:34 0:00 grep gnunet After that all binaries appear to be running, and I don't see any evidence of crashes (pids do not increment, nothing logged in dmesg/syslog, etc). The following messages appear on the terminal every few seconds: Jul 29 13:46:11-358652 util-23993 ERROR When trying to read hostkey file `/home/jurij/.gnunet/.hostkey' I found 0 bytes but I need at least 16. Jul 29 13:46:11-358747 util-23993 ERROR This may be ok if someone is currently generating a hostkey. Jul 29 13:46:11-368193 util-23994 ERROR When trying to read hostkey file `/home/jurij/.gnunet/.hostkey' I found 0 bytes but I need at least 16. Jul 29 13:46:11-368291 util-23994 ERROR This may be ok if someone is currently generating a hostkey. Jul 29 13:46:11-433488 util-23997 ERROR When trying to read hostkey file `/home/jurij/.gnunet/.hostkey' I found 0 bytes but I need at least 16. Jul 29 13:46:11-433570 util-23997 ERROR This may be ok if someone is currently generating a hostkey. Jul 29 13:46:11-435221 util-23996 ERROR When trying to read hostkey file `/home/jurij/.gnunet/.hostkey' I found 0 bytes but I need at least 16. Jul 29 13:46:11-435307 util-23996 ERROR This may be ok if someone is currently generating a hostkey. If you still can reproduce it on your machine, please provide the contents of gnunet.conf file used and more specific instructions (you may assume that I have all the binaries built from svn head installed). Thanks. -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670578: Crashes caused by gnunet bug
Hello,
I've spent some time looking at it today (after Christian kindly
provided access to gnunet's sparc buildbot and detailed instructions
on how to reproduce the bug), and by now I'm pretty certain that the
unaligned memory accesses are caused by a bug in gnunet. At first
glance it looks like the GNUNET_HashCode struct should always be
word-aligned, however closer inspection reveals that its definition
(in src/include/gnunet_common.h) looks like this:
GNUNET_NETWORK_STRUCT_BEGIN
[...]
/**
* @brief 512-bit hashcode
*/
struct GNUNET_HashCode
{
uint32_t bits[512 / 8 / sizeof (uint32_t)]; /* = 16 */
};
[...]
GNUNET_NETWORK_STRUCT_END
The preprocessed source indicates that these header and footer macros
expand into
#pragma pack(push)
#pragma pack(1)
and
#pragma pack(pop)
respectively. This essentially eliminates the alignment requirements
for members of this struct, so compiler is fully within its right to
place it at 2-bytes boundary, which eventually leads to an unaligned
memory access resulting in a crash.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678264: Reassigning to udev
reassign 678264 udev found 678264 175-3.1 severity 678264 important retitle 678264 vio_type binary is missing in udev-udeb on sparc thanks The most obvious problem from the installation report is that the vio_type binary is missing. It appears to be included in the udev-gtk-udeb, but not udev-udeb - I think this is an oversight. Unfortunately, I don't know whether re-adding it will be sufficient for the CD-ROM (connected over USB on these machines) to be detected, or something else is needed. -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673649: A few sparc installs with Wheezy Alpha installer
Package: installation-reports Severity: normal Hello, I ran a few installs using Wheezy Alpha on my machines (SunBlade 2000 and Sun T1000 server) over the last couple of days and it went mostly smoothly, see details below. 1. Machine: SunBlade 2000 Medium: netboot Console: serial Partitioning: guided, separate /home Result: ok 2. Machine: SunBlade 2000 Medium: netinst CD Console: serial Partitioning: guided, with LVM, separate /home Result: ok 3. Machine: SunBlade 2000 Medium: netinst CD Console: keyboard/screen Partitioning: guided, with LVM, separate partitions for /home, /var, /tmp, etc Result: ok 4. Machine: Sun T1000 server Medium: netboot (no other booting methods available) Console: via ethernet management port Partitioning: guided, with encrypted LVM, separate /home Result: ok Notes: one minor quirk is that during network hardware detection installer claims that required firmware is missing, and asks whether user wants to load tigon/tg3_tso.bin from removable medium. This server does not have any USB ports, so it would be rather tricky to deliver the firmware. Luckily, I found that if I just skip loading the firmware, the network works fine and install completes successfully. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671895: [sparc] Kernel NULL pointer dereference in sungem/gem_poll() (Re: updates)
On Fri, May 11, 2012 at 12:25:01PM -0300, gustavo panizzo gfa wrote:
adding debian-boot
i've installed unstable on the box (using debootstrap) and it boots
3.2.0-2-sparc64 sucessfully, networking works
obp diags shows no errors
but when i boot from network using
http://d-i.debian.org/daily-images/sparc/daily/netboot/boot.img 11-05-2012
i get the following error
┌───┤ Detecting link on eth0; please wait... ├┐
│ │
│ 100% [
246.994391] Unable to handle kernel NULL pointer dereference
247.074490] tsk-{mm,active_mm}-context = 019f │
14;10H[ 247.164534] tsk-{mm,active_mm}-pgd = f8001d48c000│
[ 247.240508] Kernel panic - not syncing: Aiee, killing interrupt handler! │
[ 247.328648] Call Trace: │
[ 247.360793] [0045dcd4] do_exit+0x94/0x708 │
[ 247.423821] [00427550] die_if_kernel+0x2a0/0x2c8┘
[ 247.494864] [00768c84] unhandled_fault+0x8c/0x98
[ 247.565915] [0076936c] do_sparc64_fault+0x6dc/0x780
[ 247.640377] [00407880] sparc64_realfault_common+0x10/0x20
[ 247.721722] [10015680] gem_poll+0x9fc/0x1328 [sungem]
[ 247.798478] [00697110] net_rx_action+0x9c/0x234
[ 247.868369] [004607f0] __do_softirq+0xdc/0x1c4
[ 247.937125] [0042a76c] do_softirq+0x54/0x80
[ 248.002442] [00460a6c] irq_exit+0x38/0x94
[ 248.065474] [0042df38] timer_interrupt+0x90/0xa8
[ 248.136516] [004209d4] tl0_irq14+0x14/0x20
[ 248.200692] [0049e764] touch_softlockup_watchdog+0x4/0xc
[ 248.280888] [008f07e4] start_kernel+0x390/0x3a0
[ 248.350783] [00750b88] tlb_fixup_done+0x80/0x88
[ 248.420672] [] (null)
[ 248.481416] Press Stop-A (L1-A) to return to the boot prom
Interesting, so we are doing something funky during link detection to
trip this bug. The code which does it is in netcfg:
http://anonscm.debian.org/gitweb/?p=d-i/netcfg.git;a=tree
Here's the relevant code from netcfg-common.c:
1277 debconf_capb(client, progresscancel);
1278 debconf_subst(client, netcfg/link_detect_progress, interface,
if_name);
1279 debconf_progress_start(client, 0, 100, netcfg/link_detect_progress);
1280 for (count = 0; count link_waits; count++) {
1281 usleep(25);
1282 if (debconf_progress_set(client, 50 * count / link_waits) == 30) {
1283 /* User cancelled on us... bugger */
1284 rv = 0;
1285 break;
1286 }
1287 if (ethtool_lite(if_name) == 1) /* ethtool-lite's CONNECTED */ {
1288 if (gateway.s_addr !is_wireless_iface(if_name)) {
1289 for (count = 0; count gw_tries; count++) {
1290 if (di_exec_shell_log(arping) == 0)
1291 break;
1292 if (debconf_progress_set(client, 50 + 50 * count /
gw_tries) == 30)
1293 break;
1294 }
1295 }
1296 rv = 1;
1297 break;
1298 }
1299 debconf_progress_set(client, 100);
1300 }
Only two non-trivial things here: execution of ethtool_lite(if_name)
and invocation of arping. I would put my money on the former (defined
in ethtool_lite.c), because it uses low-level ioctls to query the
interface state.
You can test whether running it would trigger a failure on your
machine by downloading ethtool_lite.c and building it as a standalone
binary, the following commands appear to do the trick:
$ sudo apt-get build-dep netcfg
[...]
$ gcc -o ethtool-lite -DTEST ethtool-lite.c -ldebconfclient -ldebian-installer
$ sudo ./ethtool-lite eth0
ethtool-lite: eth0 is connected.
$
If that triggers a null pointer exception on your machine (try it both
with and without network brought up and check dmesg afterwards), we
will be in a very good position to report it upstream for fixing.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671895: Kernel NULL pointer dereference in sungem/gem_poll()
Package: linux-2.6
Version: 3.2.16-1
Severity: important
Reported today on debian-sparc, kernel hits NULL pointer
dereference with the d-i netboot daily while trying to bring
the network up (machine is Netra T1 200), sungem driver seems to be
the culprit.
--
┌───┤ Detecting link on eth0; please wait... ├┐
│ │
│ 100% [
243.520556] Unable to handle kernel NULL pointer dereference
243.601245] tsk-{mm,active_mm}-context = 01a0 │
14;10H[ 243.691289] tsk-{mm,active_mm}-pgd = f8001d2c6000│
[ 243.767267] Kernel panic - not syncing: Aiee, killing interrupt handler! │
[ 243.855403] Call Trace: │
[ 243.887548] [0045dcd4] do_exit+0x94/0x708 │
[ 243.950577] [00427550] die_if_kernel+0x2a0/0x2c8┘
[ 244.021620] [00768c84] unhandled_fault+0x8c/0x98
[ 244.092659] [0076936c] do_sparc64_fault+0x6dc/0x780
[ 244.167130] [00407880] sparc64_realfault_common+0x10/0x20
[ 244.248476] [10015680] gem_poll+0x9fc/0x1328 [sungem]
[ 244.325234] [00697110] net_rx_action+0x9c/0x234
[ 244.395124] [004607f0] __do_softirq+0xdc/0x1c4
[ 244.463891] [0042a76c] do_softirq+0x54/0x80
[ 244.529196] [00460a6c] irq_exit+0x38/0x94
[ 244.592231] [0042df38] timer_interrupt+0x90/0xa8
[ 244.663271] [004209d4] tl0_irq14+0x14/0x20
[ 244.727450] [0043772c] touch_nmi_watchdog+0x0/0x34
[ 244.800780] [008f07e4] start_kernel+0x390/0x3a0
[ 244.870674] [00750b88] tlb_fixup_done+0x80/0x88
[ 244.940562] [] (null)
[ 245.001307] Press Stop-A (L1-A) to return to the boot prom
i've boot with diag-switch? = true and hw looks good
box is running 2.6.28, i will apply the same config to 3.2 and check
if it boots
--
I poked around and can't find any recent similar reports (in Debian or
elsewhere).
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645713: Similar problem is reproducible on my machine
Hello, After a month or so of not upgrading sid on my laptop I ran a dist-upgrade today and hit a similar problem: E: Could not perform immediate configuration on 'gnome-session-fallback'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) It's not exactly the original problem described in this bug, but perhaps the fact that I can reliably reproduce it by just re-running dist-upgrade on my machine right now can help in figuring out this class of problems? I'm attaching the output of sudo apt-get -o Debug::pkgProblemResolver=1 dist-upgrade which appears to be relevant, and will refrain from modifying package state on my machine for now. If there is any other useful information which could help with debugging, please let me know. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC Reading package lists... Building dependency tree... Reading state information... Starting Starting 2 Investigating (0) libcogl-pango0 [ amd64 ] 1.8.2-1 - 1.10.2-3 ( libs ) Broken libcogl-pango0:amd64 Breaks on libcogl5 [ amd64 ] 1.8.2-1 ( libs ) ( 1.10.0-1) Considering libcogl5:amd64 34 as a solution to libcogl-pango0:amd64 73 Added libcogl5:amd64 to the remove list Fixing libcogl-pango0:amd64 via remove of libcogl5:amd64 Investigating (0) libmx-1.0-2 [ amd64 ] 1.4.1-1 - 1.4.5-1 ( libs ) Broken libmx-1.0-2:amd64 Depends on libcogl5 [ amd64 ] 1.8.2-1 ( libs ) (= 1.7.4) Considering libcogl5:amd64 34 as a solution to libmx-1.0-2:amd64 19 Removing libmx-1.0-2:amd64 rather than change libcogl5:amd64 Investigating (0) libevolution [ amd64 ] 3.2.2-1 ( gnome ) Broken libevolution:amd64 Depends on libcogl5 [ amd64 ] 1.8.2-1 ( libs ) (= 1.7.4) Considering libcogl5:amd64 34 as a solution to libevolution:amd64 18 Removing libevolution:amd64 rather than change libcogl5:amd64 Investigating (0) gnome-panel [ amd64 ] 3.2.1-2+b1 - 3.4.1-1 ( gnome ) Broken gnome-panel:amd64 Breaks on libpanel-applet2-0 [ amd64 ] 2.30.2-4+b1 ( libs ) Considering libpanel-applet2-0:amd64 1 as a solution to gnome-panel:amd64 10 Added libpanel-applet2-0:amd64 to the remove list Fixing gnome-panel:amd64 via remove of libpanel-applet2-0:amd64 Investigating (0) evolution [ amd64 ] 3.2.2-1 ( gnome ) Broken evolution:amd64 Depends on libcogl5 [ amd64 ] 1.8.2-1 ( libs ) (= 1.7.4) Considering libcogl5:amd64 34 as a solution to evolution:amd64 7 Removing evolution:amd64 rather than change libcogl5:amd64 Investigating (0) evolution-plugins [ amd64 ] 3.2.2-1 ( gnome ) Broken evolution-plugins:amd64 Depends on libcogl5 [ amd64 ] 1.8.2-1 ( libs ) (= 1.7.4) Considering libcogl5:amd64 34 as a solution to evolution-plugins:amd64 6 Removing evolution-plugins:amd64 rather than change libcogl5:amd64 Investigating (0) libchamplain-0.12-0 [ amd64 ] 0.12.2-1 ( libs ) Broken libchamplain-0.12-0:amd64 Depends on libcogl5 [ amd64 ] 1.8.2-1 ( libs ) (= 1.7.4) Considering libcogl5:amd64 34 as a solution to libchamplain-0.12-0:amd64 6 Removing libchamplain-0.12-0:amd64 rather than change libcogl5:amd64 Investigating (0) gnome-shell [ amd64 ] 3.2.2.1-1 - 3.2.2.1-4 ( gnome ) Broken gnome-shell:amd64 Depends on libcogl5 [ amd64 ] 1.8.2-1 ( libs ) (= 1.7.4) Considering libcogl5:amd64 34 as a solution to gnome-shell:amd64 5 Removing gnome-shell:amd64 rather than change libcogl5:amd64 Investigating (0) libept1 [ amd64 ] 1.0.5 ( libs ) Broken libept1:amd64 Depends on libapt-pkg4.10 [ amd64 ] none ( none ) Considering apt:amd64 28 as a solution to libept1:amd64 4 Removing libept1:amd64 rather than change libapt-pkg4.10:amd64 Investigating (0) gnome-sushi [ amd64 ] 0.2.1-3 - 0.4.1-1 ( gnome ) Broken gnome-sushi:amd64 Depends on libcogl5 [ amd64 ] 1.8.2-1 ( libs ) (= 1.7.4) Considering libcogl5:amd64 34 as a solution to gnome-sushi:amd64 3 Removing gnome-sushi:amd64 rather than change libcogl5:amd64 Investigating (0) xserver-xorg-video-s3virge [ amd64 ] 1:1.10.4-4+b2 ( x11 ) Broken xserver-xorg-video-s3virge:amd64 Depends on xorg-video-abi-11 [ amd64 ] none ( none ) Considering xserver-xorg-core:amd64 67 as a solution to xserver-xorg-video-s3virge:amd64 3 Removing xserver-xorg-video-s3virge:amd64 rather than change xorg-video-abi-11:amd64 Investigating (0) xserver-xorg-video-tdfx [ amd64 ] 1:1.4.3-4+b2 ( x11 ) Broken xserver-xorg-video-tdfx:amd64 Depends on xorg-video-abi-11 [ amd64 ] none ( none ) Considering xserver-xorg-core:amd64 67 as a solution to xserver-xorg-video-tdfx:amd64 3 Removing xserver-xorg-video-tdfx:amd64 rather than change xorg-video-abi-11:amd64 Investigating (0) libchamplain-gtk-0.12-0 [ amd64 ] 0.12.2-1 ( libs ) Broken libchamplain-gtk-0.12-0:amd64 Depends on libchamplain-0.12-0 [ amd64 ] 0.12.2-1 ( libs ) (= 0.11.0) Considering libchamplain-0.12-0:amd64 6 as a solution to libchamplain-gtk-0.12-0:amd64 3 Removing
Bug#670578: More information needed
Hello, Is there an upstream bug for that? If there is, can you please provide a reference? Can you post a stack trace, preferrably obtained with the latest Debian binaries (gnunet version 0.8.1b-8), if possible? Thanks. -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669905: Analysis
Hi, It's pretty clear why the unaligned access happens. At js/xpconnect/src/xpcprivate.h:1335 a new XPCCallContext object is created using mCcxToDestroy = mCcx = new (mData) XPCCallContext(mCallerLanguage, mCx, mCallBeginRequest == CALL_BEGINREQUEST, mObj, mFlattenedJSObject, mWrapper, mTearOff); Memory for the object (pointed to by mData) is allocated at line 1363 using char mData[sizeof(XPCCallContext)]; Char array has no alignment requirements. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669905: Iceweasel crashes with bus error on startup on sparc
=..., construct=js::NO_CONSTRUCT) at /build/buildd-iceweasel_10.0.3esr-3-sparc-Mahwh3/iceweasel-10.0.3esr/js/src/jsinterp.cpp:629 #17 0xf765eb88 in js::Interpret (cx=0xf7924340, entryFrame=0xf10002b0, interpMode=js::JSINTERP_NORMAL) at /build/buildd-iceweasel_10.0.3esr-3-sparc-Mahwh3/iceweasel-10.0.3esr/js/src/jsinterp.cpp:3948 #18 0xf766ecb8 in js::InvokeKernel (cx=0xf7924340, args=..., construct=js::NO_CONSTRUCT) at /build/buildd-iceweasel_10.0.3esr-3-sparc-Mahwh3/iceweasel-10.0.3esr/js/src/jsinterp.cpp:647 #19 0xf766f154 in Invoke (construct=js::NO_CONSTRUCT, args=..., cx=0xf7924340) at /build/buildd-iceweasel_10.0.3esr-3-sparc-Mahwh3/iceweasel-10.0.3esr/js/src/jsinterp.h:148 #20 js::Invoke (cx=0xf7924340, thisv=..., fval=..., argc=2, argv=0x63f0, rval=0x6508) at /build/buildd-iceweasel_10.0.3esr-3-sparc-Mahwh3/iceweasel-10.0.3esr/js/src/jsinterp.cpp:679 #21 0xf75e38d8 in JS_CallFunctionValue (cx=0xf7924340, obj=0xf0c9c0d0, fval=..., argc=2, argv=0x63f0, rval=0x6508) at /build/buildd-iceweasel_10.0.3esr-3-sparc-Mahwh3/iceweasel-10.0.3esr/js/src/jsapi.cpp:5199 #22 0xf6e06730 in nsXPCWrappedJSClass::CallMethod (this=0xf1432890, wrapper=optimized out, methodIndex=optimized out, info=0xf79b6780, nativeParams=0x6640) at /build/buildd-iceweasel_10.0.3esr-3-sparc-Mahwh3/iceweasel-10.0.3esr/js/xpconnect/src/XPCWrappedJSClass.cpp:1530 #23 0xf6e013ec in nsXPCWrappedJS::CallMethod (this=0xefedb2c0, methodIndex=3, info=0xf79b6780, params=0x6640) at /build/buildd-iceweasel_10.0.3esr-3-sparc-Mahwh3/iceweasel-10.0.3esr/js/xpconnect/src/XPCWrappedJS.cpp:611 #24 0xf7192c74 in PrepareAndDispatch (self=0xefe1bd40, methodIndex=optimized out, args=optimized out) ---Type return to continue, or q return to quit--- at /build/buildd-iceweasel_10.0.3esr-3-sparc-Mahwh3/iceweasel-10.0.3esr/xpcom/reflect/xptcall/src/md/unix/xptcstubs_sparc_solaris.cpp:115 #25 0xf71944c0 in SharedStub () at /build/buildd-iceweasel_10.0.3esr-3-sparc-Mahwh3/iceweasel-10.0.3esr/xpcom/reflect/xptcall/src/md/unix/xptcstubs_asm_sparc_solaris.s:72 #26 0xf71944c0 in SharedStub () at /build/buildd-iceweasel_10.0.3esr-3-sparc-Mahwh3/iceweasel-10.0.3esr/xpcom/reflect/xptcall/src/md/unix/xptcstubs_asm_sparc_solaris.s:72 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) disass Dump of assembler code for function XPCCallContext::XPCCallContext(XPCContext::LangType, JSContext*, JSBool, JSObject*, JSObject*, XPCWrappedNative*, XPCWrappedNativeTearOff*): 0xf6de3800 +0: save %sp, -112, %sp 0xf6de3804 +4: sethi %hi(0x41c00), %g1 0xf6de3808 +8: clr [ %i0 + 4 ] 0xf6de380c +12:sethi %hi(0x754000), %l7 0xf6de3810 +16:call 0xf6657960 __sparc_get_pc_thunk.l7 0xf6de3814 +20:add %l7, 0x200, %l7! 0x754200 0xf6de3818 +24:xor %g1, -888, %g1 0xf6de381c +28:add %l7, %g1, %g1 0xf6de3820 +32:add %g1, 8, %g1 0xf6de3824 +36:call 0xf6de0708 nsXPConnect::GetXPConnect() 0xf6de3828 +40:st %g1, [ %i0 ] 0xf6de382c +44:clr [ %i0 + 0xc ] 0xf6de3830 +48:ld [ %fp + 0x5c ], %g1 0xf6de3834 +52:mov %i1, %o1 0xf6de3838 +56:mov %i3, %o2 0xf6de383c +60:st %o0, [ %i0 + 8 ] 0xf6de3840 +64:mov %i4, %o3 0xf6de3844 +68:mov %i0, %o0 0xf6de3848 +72:st %g1, [ %i0 + 0x34 ] 0xf6de384c +76:clr %o4 0xf6de3850 +80:clr %o5 0xf6de3854 +84:ld [ %fp + 0x60 ], %g1 0xf6de3858 +88:clr [ %i0 + 0x10 ] 0xf6de385c +92:st %g1, [ %i0 + 0x38 ] 0xf6de3860 +96:mov 2, %g1 0xf6de3864 +100: st %i2, [ %i0 + 0x14 ] 0xf6de3868 +104: st %g1, [ %sp + 0x5c ] 0xf6de386c +108: mov -1, %g1 = 0xf6de3870 +112: clrx [ %i0 + 0x18 ] 0xf6de3874 +116: st %i1, [ %i0 + 0x20 ] 0xf6de3878 +120: st %i5, [ %i0 + 0x30 ] 0xf6de387c +124: clrb [ %i0 + 0x78 ] 0xf6de3880 +128: clrb [ %i0 + 0x90 ] 0xf6de3884 +132: st %g1, [ %sp + 0x60 ] 0xf6de3888 +136: clr [ %sp + 0x64 ] 0xf6de388c +140: call 0xf6de3538 XPCCallContext::Init(XPCContext::LangType, int, JSObject*, JSObject*, XPCCallContext::WrapperInitOptions, int, unsigned int, JS::Value*, JS::Value*) 0xf6de3890 +144: clr [ %sp + 0x68 ] 0xf6de3894 +148: rett %i7 + 8 0xf6de3898 +152: nop End of assembler dump. (gdb) info reg i0 i0 0x566c -43412 This is an unaligned memory access, clrx argument must be 8-byte aligned. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669905: Invocation details
Hello again, Forgot to mention and it might matter: this was obtained after I logged in to my sparc box with 'ssh -Y' and ran iceweasel from there. It does not have the supported hardware to run X natively. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665899: Patch for FTBFS
tags 665899 patch
thanks
Hello,
The current code only special-cases UTF16-LE encoding, everything else
is simply converted to UTF-8. This causes a test failure on sparc,
where native 16-bit encoding is UTF16-BE. As far as I can tell, the
only effect of detecting the 16-bit encoding is to call sqlite3_open16
instead of sqlite3_open_v2, so attached patch should do the trick. I
verified that with it applied all tests pass on sparc and the package
is successfully built.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
diff -aur a/ext/sqlite3/database.c b/ext/sqlite3/database.c
--- a/ext/sqlite3/database.c 2012-01-08 16:24:47.0 +
+++ b/ext/sqlite3/database.c 2012-04-16 16:28:44.287997708 +0100
@@ -60,7 +60,7 @@
else Check_Type(opts, T_HASH);
#ifdef HAVE_RUBY_ENCODING_H
- if(UTF16_LE_P(file)) {
+ if(UTF16_LE_P(file) || UTF16_BE_P(file)) {
status = sqlite3_open16(utf16_string_value_ptr(file), ctx-db);
} else {
#endif
diff -aur a/ext/sqlite3/sqlite3_ruby.h b/ext/sqlite3/sqlite3_ruby.h
--- a/ext/sqlite3/sqlite3_ruby.h 2012-01-08 16:24:47.0 +
+++ b/ext/sqlite3/sqlite3_ruby.h 2012-04-16 16:28:20.315997261 +0100
@@ -21,6 +21,7 @@
#define UTF8_P(_obj) (rb_enc_get_index(_obj) == rb_utf8_encindex())
#define UTF16_LE_P(_obj) (rb_enc_get_index(_obj) == rb_enc_find_index(UTF-16LE))
+#define UTF16_BE_P(_obj) (rb_enc_get_index(_obj) == rb_enc_find_index(UTF-16BE))
#define SQLITE3_UTF8_STR_NEW2(_obj) \
(rb_enc_associate_index(rb_str_new2(_obj), rb_utf8_encindex()))
Bug#653653: nbd: FTBFS on sparc: Bus error (core dumped) - FAIL: integrity
On Thu, Apr 12, 2012 at 02:37:48PM +0100, peter green wrote:
based on Julien Cristau's and Patrick Baggett's comments I put
together the attatched patch to fix the alignment issues they
identified (I have not done anything regarding the poor choice of
prototype or the theoretical strict-aliasing issue).
Unfortunately the test still fails with a bus error and I can't seem
to figure out how to run the test manually to get a new backtrace.
The executable ./integrity simply doesn't seem to exist after the
build process ends.
Jurij, can you tell me exactly what you did to get your backtrace?
It runs the tests using simple_test script by invoking it with
'integrity' argument, in this case. I believe I just manually
reproduced the commands the script runs, for 'integrity' they look
like this:
*/integrity)
# Integrity test
cat ${conffile} EOF
[generic]
[export1]
exportname = $tmpnam
flush = true
fua = true
rotational = true
filesize = 52428800
temporary = true
EOF
./nbd-server -C ${conffile} -p ${pidfile}
PID=$!
sleep 1
./nbd-tester-client localhost -N export1 -i -t
${mydir}/integrity-test.tr
retval=$?
;;
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634261: Don't believe this bug is RC-critical
Hello, For the record, I do not consider this bug to be RC. As far as I know, it only manifested itself for iceweasel and only because iceweasel does really funky things with its symbols. The bug now contains enough information for a useful upstream report, however I don't intend to file one. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651934: How to debug seed FTBFS on sparc?
On Sat, Mar 03, 2012 at 08:07:33AM +, Jurij Smakov wrote:
[...]
Unfortunately, the build I tried last week failed with the following
messages while compiling Source/WebCore/svg/SVGFilterElement.cpp:
../Source/JavaScriptCore/wtf/ListHashSet.h:192:70: warning: cast from 'char*'
to 'WTF::ListHashSetNodeAllocatorWebCore::Element*, 64u::Node* {aka
WTF::ListHashSetNodeWebCore::Element*, 64u*}' increases required alignment
of target type [-Wcast-align]
/tmp/ccJFyoyk.s: Assembler messages:
/tmp/ccJFyoyk.s:107726: Error: unknown pseudo-op: `.ua'
/tmp/ccJFyoyk.s:107726: Error: junk at end of line, first unrecognized
character is `3'
make[1]: *** [Source/WebCore/svg/libWebCore_la-SVGFilterElement.lo] Error 1
make[1]: Leaving directory `/home/jurij/seed/webkit-1.6.3/build-3.0'
make: *** [build-stamp] Error 2
Last 500 lines of the logs are attached.
I'll try again today with the latest toolchain to see whether this was
some transient problem.
It built successfully this time! And after I installed the resulting
debs, seed built successfully too. The webkit patch I used is
attached.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
diff -aur a/Source/JavaScriptCore/wtf/Platform.h b/Source/JavaScriptCore/wtf/Platform.h
--- a/Source/JavaScriptCore/wtf/Platform.h 2012-02-25 11:10:13.0 +
+++ b/Source/JavaScriptCore/wtf/Platform.h 2012-02-25 11:26:17.992010602 +
@@ -295,7 +295,7 @@
#endif /* ARM */
-#if CPU(ARM) || CPU(MIPS) || CPU(SH4)
+#if CPU(ARM) || CPU(MIPS) || CPU(SH4) || CPU(SPARC)
#define WTF_CPU_NEEDS_ALIGNED_ACCESS 1
#endif
Bug#653653: nbd: FTBFS on sparc: Bus error (core dumped) - FAIL: integrity
On Fri, Mar 02, 2012 at 12:52:33AM +0100, Julien Cristau wrote: cc+=debian-sparc@ On Wed, Feb 29, 2012 at 14:14:46 +0100, Wouter Verhelst wrote: tags 653653 + help thanks On Fri, Dec 30, 2011 at 12:40:09AM +0100, Jakub Wilk wrote: Source: nbd Version: 1:2.9.25-2 Severity: serious Justification: fails to build from source User: debian-sp...@lists.debian.org Usertags: sparc nbd FTBFS on sparc: | ./integrity | 28870: Seq 0002 Queued: 0001 Inflight: Done: | Bus error (core dumped) | FAIL: integrity Full build log: https://buildd.debian.org/status/fetch.php?pkg=nbdarch=sparcver=1%3A2.9.25-2stamp=1325194394 So, I had a look at this on the porter machines a while back, and I have to say I'm a bit stumped as to what's wrong. There's some stack corruption going on inside nbd-tester-client (the test suite client that tests whether nbd-server runs correctly), which makes things a bit harder; but I can't see why there should be any such stack corruption. Running this inside valgrind (on amd64) also doesn't flag anything suspicious. Help from anyone familiar with SPARC would be appreciated. Here's a backtrace: Program received signal SIGBUS, Bus error. 0xf7f49c08 in g_int64_equal (v1=0x2bd28, v2=0xd104) at /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/gutils.c:3567 3567 /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/gutils.c: No such file or directory. (gdb) bt #0 0xf7f49c08 in g_int64_equal (v1=0x2bd28, v2=0xd104) at /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/gutils.c:3567 #1 0xf7ef529c in g_hash_table_lookup_node (hash_return=synthetic pointer, key=0xd104, hash_table=0x2b000) at /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/ghash.c:381 #2 g_hash_table_lookup (hash_table=0x2b000, key=0xd104) at /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/ghash.c:1029 #3 0x00014580 in integrity_test (hostname=optimized out, port=optimized out, name=optimized out, sock=7, sock_is_open=optimized out, close_sock=optimized out, testflags=0) at nbd-tester-client.c:1103 #4 0x00010f98 in main (argc=7, argv=0xd254) at nbd-tester-client.c:1309 According to g_int64_equal documentation, it expects its arguments to be pointers to gint64 values, which on sparc must be aligned on an 8-byte boundary. Looks like this is intentional, because nbd-tester-client.c creates its hash table like that: GHashTable *handlehash = g_hash_table_new(g_int64_hash, g_int64_equal); The 'key' pointer (0xd104) passed to g_hash_table_lookups from nbd-tester-client.c:1103 points to a location which is only 4-bytes aligned, causing the crash. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651934: How to debug seed FTBFS on sparc?
On Sun, Feb 26, 2012 at 02:19:59AM +, peter green wrote: Found 651934 3.0.0-2 Thanks Thanks jurij for your help. 'disassemble' command may be used to look up the assembler code around the instruction which caused the crash: Some further notes on the dissasemble command I ran into while trying to use it. 1: it seems you have to explicitly select a range unless you want a whole function 2: if you have debug symbols installed you have to use info frame to get the address of the program counter 3: the addresses were different on my system, i'm not sure whether this was because my system was slightly out of date at the time or because of address randomisation. Figuring out why this happens is the tricky part :-). mmm, the webkit (webkit is the source package for libjavascriptcore) build log has a huge number of cast alignment warnings :( worse the file in which the error occoured is generated at webkit build time and is therefore not available in the webkit source package. I don't have the resources to build webkit on sparc in a reasonable time. Since testing an unstable have different versions of both seed and webkit. I decided the next thing to try was to build both testing's version of seed and unstable's versions of seed in both testing and unstable to try and narrow down which package caused the regression. However all four combinations failed with a bus error so it seems this regression happened before the version of webkit that is now in testing. I'm now marking this bug as affecting the version in testing as well. Webkit maintainers: Is any form of testsuite for libjavascriptcore run at webkit build time? I didn't spot anything on a quick look at the log but the log is massive so it's possible I missed it. I poked around the webkit source a bit and found that there is a WTF_CPU_NEEDS_ALIGNED_ACCESS macro, which is conditionally set to 1 only for ARM, MIPS and SH4 CPUs. I'm currently trying to build webkit with attached patch to see whether this improves things. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC diff -aur a/Source/JavaScriptCore/wtf/Platform.h b/Source/JavaScriptCore/wtf/Platform.h --- a/Source/JavaScriptCore/wtf/Platform.h 2012-02-25 11:10:13.0 + +++ b/Source/JavaScriptCore/wtf/Platform.h 2012-02-25 11:26:17.992010602 + @@ -295,7 +295,7 @@ #endif /* ARM */ -#if CPU(ARM) || CPU(MIPS) || CPU(SH4) +#if CPU(ARM) || CPU(MIPS) || CPU(SH4) || CPU(SPARC) #define WTF_CPU_NEEDS_ALIGNED_ACCESS 1 #endif
Bug#651934: How to debug seed FTBFS on sparc?
this happens is the tricky part :-). Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657389: Tasksel is to blame
On Sun, Jan 29, 2012 at 02:26:54AM -0400, Joey Hess wrote:
Jurij Smakov wrote:
I noticed that as well with today's dailies. This is displayed by
tasksel, installer just invokes it in /target. I can also reproduce it
on an installed system by running 'tasksel -t'.
Since I can't reproduce this, I can only guess.
tasksel contains a sub list_installed() that parses
/var/lib/dpkg/status. Perhaps something about the status file format has
changed?
Parsing the file is a bit gratuitous, so I've attached a patch that
switches it to dpkg-query. Does it fix the issue?
No, that does not help. I investigated a bit and I believe that the
problem is in getdescriptions() function. In particular, it does the
following while processing the output of apt-cache show task-${task}:
my ($description)=/^Description-.*: (.*)$/m;
($description)=/^Description: (.*)$/m
unless defined $description;
This inadvertently catches the Description-md5 field (which is new, I
guess?):
# apt-cache show task-desktop | grep Description
Description: Debian desktop environment
Description-md5: 17cb4a1ed6025b48045cc576bf52317c
#
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657389: Tasksel is to blame
reassign 657389 tasksel found 657389 3.07 thanks I noticed that as well with today's dailies. This is displayed by tasksel, installer just invokes it in /target. I can also reproduce it on an installed system by running 'tasksel -t'. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655897: silo fails to build from source
': (.text+0x17c): undefined reference to `stdout' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_init': (.text+0x180): undefined reference to `stdout' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_init': (.text+0x18c): undefined reference to `fflush' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_update': (.text+0x228): undefined reference to `printf' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_update': (.text+0x230): undefined reference to `stdout' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_update': (.text+0x234): undefined reference to `stdout' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_update': (.text+0x26c): undefined reference to `fprintf' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_close': (.text+0x2c0): undefined reference to `stdout' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_close': (.text+0x2c4): undefined reference to `stdout' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_close': (.text+0x2fc): undefined reference to `fprintf' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_close': (.text+0x304): undefined reference to `stdout' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_close': (.text+0x308): undefined reference to `stdout' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_close': (.text+0x340): undefined reference to `fprintf' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_close': (.text+0x358): undefined reference to `stdout' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_close': (.text+0x35c): undefined reference to `stdout' /usr/lib/sparc-linux-gnu/libext2fs.a(progress.o): In function `ext2fs_numeric_progress_close': (.text+0x36c): undefined reference to `fputs' /usr/lib/sparc-linux-gnu/libext2fs.a(csum.o): In function `ext2fs_group_desc_csum': (.text+0x68): undefined reference to `printf' /usr/lib/sparc-linux-gnu/libext2fs.a(llseek.o): In function `ext2fs_llseek': (.text+0x6c): undefined reference to `lseek' /usr/lib/sparc-linux-gnu/libext2fs.a(llseek.o): In function `ext2fs_llseek': (.text+0xa4): undefined reference to `__errno_location' /usr/lib/sparc-linux-gnu/libext2fs.a(llseek.o): In function `ext2fs_llseek': (.text+0xdc): undefined reference to `lseek64' /usr/lib/sparc-linux-gnu/libext2fs.a(llseek.o): In function `ext2fs_llseek': (.text+0x108): undefined reference to `__errno_location' /usr/lib/sparc-linux-gnu/libext2fs.a(llseek.o): In function `ext2fs_llseek': (.text+0x140): undefined reference to `__errno_location' make[2]: *** [second] Error 1 make[2]: Leaving directory `/tmp/buildd/silo-1.4.14+git20100228/build-tree/second' make[1]: *** [all] Error 1 make[1]: Leaving directory `/tmp/buildd/silo-1.4.14+git20100228/build-tree' make: *** [build-stamp] Error 2 Package was last uploaded almost two years ago, so it looks like something has changed in the meantime. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652115: ruby1.8: FTBFS on sparc: ./sample/test.rb:1848: [BUG] Bus Error
On Wed, Jan 11, 2012 at 10:29:31PM +0100, Julien Cristau wrote: On Wed, Jan 11, 2012 at 21:21:07 +, Jurij Smakov wrote: The test fails at sample/test.rb:1848, which is ary2 = $x.unpack($format) We had a gcc-4.6 bug (http://bugs.debian.org/635126) which manifested itself as a miscompilation of pack/unpack function in Ruby. The bug got fixed in gcc-4.6 4.6.2-6 and the latest build attempt was done with 4.6.2-4, so it did not contain this fix. I'd say giving it back is pretty pointless unless we can bump gcc-4.6 version to 4.6.2-6 or later (which is a very good idea anyway, because we currently build packages with known bad compiler version). jcristau@grieg:~$ wb gb ruby1.8 . sparc . -o --extra-depends 'gcc-4.6 (= 4.6.2-6)' Thanks, build completed successfully: https://buildd.debian.org/status/fetch.php?pkg=ruby1.8arch=sparcver=1.8.7.352-2stamp=1326336427 Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652115: ruby1.8: FTBFS on sparc: ./sample/test.rb:1848: [BUG] Bus Error
On Wed, Jan 11, 2012 at 08:13:02PM +0100, Julien Cristau wrote: On Tue, Jan 10, 2012 at 22:55:16 +, Jurij Smakov wrote: It probably makes sense to ask someone with buildd super-powers to trigger another build on sparc to see if the problem is somehow buildd-specific. It was already tried 3 times on 2 different buildds: https://buildd.debian.org/status/logs.php?pkg=ruby1.8arch=sparcver=1.8.7.352-2 I can give it back once more, but... The test fails at sample/test.rb:1848, which is ary2 = $x.unpack($format) We had a gcc-4.6 bug (http://bugs.debian.org/635126) which manifested itself as a miscompilation of pack/unpack function in Ruby. The bug got fixed in gcc-4.6 4.6.2-6 and the latest build attempt was done with 4.6.2-4, so it did not contain this fix. I'd say giving it back is pretty pointless unless we can bump gcc-4.6 version to 4.6.2-6 or later (which is a very good idea anyway, because we currently build packages with known bad compiler version). Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642266: [DRE-maint] Bug#642266: please help with #642266
On Mon, Jan 09, 2012 at 10:09:58PM -0200, Antonio Terceiro wrote: Hi Jurij, Jurij Smakov escreveu isso aí: On Wed, Jan 04, 2012 at 10:54:07AM -0200, Antonio Terceiro wrote: Dear sparc porters, I need some help from you to make ruby-ffi build correctly on sparc. The source actually compiles OK, but the test suite crashes with an Illegal instruction error. Is this a known problem? I managed to create a minimal test script that reproduces the problem without running the entire test suite. It is attached to this bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642266), and all you need to do is run it from the root of the package source dir (it will compile everything that's needed before running the actual test code). I also attached strace output from running the test script against both ruby1.8 and ruby1.9.1 (a second run, after having the C code built to remove unecessary cruft): they have similar results. We used to have a bug in gcc-4.6 on sparc, which resulted in miscompilation of pack/unpack function in Ruby: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635126 The fact that your test case causes a failure in pack-related function makes me think that this might be the same problem. Last ruby-ffi package has been built with gcc-4.6 4.6.2-4, according to https://buildd.debian.org/status/fetch.php?pkg=ruby-ffiarch=sparcver=1.0.11debian-2stamp=1325143302 The first gcc-4.6 version containing a fix is 4.6.2-6, so the build still happened with broken gcc. If you can, try either building the code with older compiler and -fno-tree-sra flag, or newer compiler, to see whether this fixes the problem. I'm on vacation for another week and don't have access to my sparc box, so if you will not be able to confirm this fix, I'll be glad to give it a go once I'm back. I've just tested on smetana.debian.org (where those strace logs were obtained before), and the gcc there is way newer than that: gcc 4:4.6.2-4 gcc-4.6 4.6.2-11 I also tried building with -fno-tree-sra, but got the same results. So, it would be very nice if you could look at this issue. Right, it's a different issue. 'Illegal instruction' error is generated when the test code hits 'ta 6' instruction, which is generated due to the following code in libtest/NumberTest.c: #ifdef __sparc #define fix_mem_access __asm(ta 6) #else #define fix_mem_access #endif This instruction means 'software trap 6', which normally invokes some action in the kernel from userspace (kind of like 'int' instruction on x86). According to a cursory search, this trap is Solaris-specific, and its effect is to turn on the unaligned trap handler. In Linux userspace unaligned traps are not handled (they just cause program termination), so the #ifdef should be adjusted to only trigger on Solaris/sparc. This may have unintended side effects (if the tests have intentional unaligned accesses, for example), but I've confirmed that with the attached patch applied the package builds successfully. Note that I have no way to test it on Solaris, but judging by examples like http://www.winehq.org/pipermail/wine-patches/2011-February/098547.html it should do the trick. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC diff -aur a/libtest/NumberTest.c b/libtest/NumberTest.c --- a/libtest/NumberTest.c 2011-11-13 20:03:45.0 + +++ b/libtest/NumberTest.c 2012-01-10 17:53:07.684344142 + @@ -23,7 +23,7 @@ #include string.h #include stdint.h -#ifdef __sparc +#if defined(__sparc) defined(__sun__) #define fix_mem_access __asm(ta 6) #else #define fix_mem_access
Bug#652115: ruby1.8: FTBFS on sparc: ./sample/test.rb:1848: [BUG] Bus Error
On Mon, Dec 19, 2011 at 09:30:57PM +0100, Lucas Nussbaum wrote: On 14/12/11 at 23:40 +0100, Jakub Wilk wrote: Source: ruby1.8 Version: 1.8.7.352-2 Severity: serious Justification: fails to build from source User: debian-sp...@lists.debian.org Usertags: sparc ruby1.8 FTBFS on sparc: | ./sample/test.rb:1848: [BUG] Bus Error | ruby 1.8.7 (2011-06-30 patchlevel 352) [sparc-linux] | | test failed | make[1]: *** [test] Error 1 | make[1]: Leaving directory `/build/buildd-ruby1.8_1.8.7.352-2-sparc-NViQ1Z/ruby1.8-1.8.7.352' | make: *** [debian/stamp-makefile-build] Error 2 Full build log: https://buildd.debian.org/status/fetch.php?pkg=ruby1.8arch=sparcver=1.8.7.352-2stamp=1323883832 Hi debian-sparc@, Could someone take a look at this? It might be similar to #593138, #545345 and http://redmine.ruby-lang.org/issues/5244 I tried building ruby1.8 in a freshly-created sid pbuilder chroot today, and the build finished successfully, build log is available at http://www.wooyd.org/tmp/ruby1.8_1.8.7.352-2_build.log It probably makes sense to ask someone with buildd super-powers to trigger another build on sparc to see if the problem is somehow buildd-specific. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642266: please help with #642266
On Wed, Jan 04, 2012 at 10:54:07AM -0200, Antonio Terceiro wrote: Dear sparc porters, I need some help from you to make ruby-ffi build correctly on sparc. The source actually compiles OK, but the test suite crashes with an Illegal instruction error. Is this a known problem? I managed to create a minimal test script that reproduces the problem without running the entire test suite. It is attached to this bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642266), and all you need to do is run it from the root of the package source dir (it will compile everything that's needed before running the actual test code). I also attached strace output from running the test script against both ruby1.8 and ruby1.9.1 (a second run, after having the C code built to remove unecessary cruft): they have similar results. We used to have a bug in gcc-4.6 on sparc, which resulted in miscompilation of pack/unpack function in Ruby: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635126 The fact that your test case causes a failure in pack-related function makes me think that this might be the same problem. Last ruby-ffi package has been built with gcc-4.6 4.6.2-4, according to https://buildd.debian.org/status/fetch.php?pkg=ruby-ffiarch=sparcver=1.0.11debian-2stamp=1325143302 The first gcc-4.6 version containing a fix is 4.6.2-6, so the build still happened with broken gcc. If you can, try either building the code with older compiler and -fno-tree-sra flag, or newer compiler, to see whether this fixes the problem. I'm on vacation for another week and don't have access to my sparc box, so if you will not be able to confirm this fix, I'll be glad to give it a go once I'm back. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653221: Does not find files after media_dir configuration change
Package: minidlna Version: 1.0.21+dfsg-1+b1 Severity: important Hello, Here's the behavior I saw when I installed minidlna recently: 1. I install minidlna, it starts the daemon with default setting of media_dir=/opt, which is empty. 2. I modify /etc/minidlna.conf to point to the correct directory (media_dir=A,/home/jurij/Music, for example) and restart minidlna with /etc/init.d/minidlna restart. 3. The remote client still does not see any files. 4. I remove /var/lib/minidlna/files.db and restart minidlna again. 5. minidlna rescans the directories on startup and recreates files.db, all files are now visible to the remote client. I think that there is some bad handling of configuration file changes, I'd say that minidlna should always do a rescan on media_dir change. Most of new users are likely to hit this problem (unless they keep their files in /opt), and figuring out that you have to delete the files.db file to fix the problem may be non-trivial. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649033: Backtrace
The hang is in the initialization code of tpm_tis module. Simply running sudo modprobe -b acpi:SMO1200:PNP0C31: sudo modrpobe -r tpm_tis a dozen times in a loop was sufficient to trigger it. Here's the backtrace, courtesy of show-blocked-tasks magic SysRq key command: [ 1801.675853] SysRq : Show Blocked State [ 1801.675866] taskPC stack pid father [ 1801.675951] modprobeD 88021e252f40 0 3809 3808 0x [ 1801.675963] 880212080930 0086 8802155760c0 [ 1801.675973] 00012f40 88021375ffd8 88021375ffd8 880212080930 [ 1801.675983] 0286 00010286 88021d81ec80 00010005bc31 [ 1801.675993] Call Trace: [ 1801.676010] [8132c99d] ? schedule_timeout+0xa3/0xdb [ 1801.676021] [810510b3] ? usleep_range+0x3e/0x3e [ 1801.676029] [81051bf0] ? msleep+0x14/0x1c [ 1801.676041] [a01e3215] ? tpm_transmit+0x102/0x177 [tpm] [ 1801.676051] [a01e367b] ? transmit_cmd.isra.3+0xc/0x24 [tpm] [ 1801.676059] [a01e3b2a] ? tpm_get_timeouts+0x5d/0x210 [tpm] [ 1801.676072] [a026f171] ? tpm_tis_status+0x1e/0x20 [tpm_tis] [ 1801.676082] [a026f4e9] ? wait_for_stat+0x1f/0x18b [tpm_tis] [ 1801.676093] [a026f171] ? tpm_tis_status+0x1e/0x20 [tpm_tis] [ 1801.676102] [a026f825] ? tpm_tis_send_data+0x131/0x16d [tpm_tis] [ 1801.676112] [a026fc2d] ? tpm_tis_init+0x233/0x583 [tpm_tis] [ 1801.676122] [a026ff7d] ? tpm_tis_init+0x583/0x583 [tpm_tis] [ 1801.676133] [811fcc62] ? pnp_device_probe+0x70/0x9c [ 1801.676142] [8123dae2] ? pm_runtime_barrier+0x6e/0x76 [ 1801.676151] [81236f09] ? driver_probe_device+0xa8/0x138 [ 1801.676158] [81236fe8] ? __driver_attach+0x4f/0x6f [ 1801.676165] [81236f99] ? driver_probe_device+0x138/0x138 [ 1801.676175] [81236239] ? bus_for_each_dev+0x44/0x78 [ 1801.676184] [812368a1] ? bus_add_driver+0xa2/0x1f2 [ 1801.676216] [a0345000] ? 0xa0344fff [ 1801.676223] [8123740d] ? driver_register+0x8d/0xf5 [ 1801.676233] [a0345000] ? 0xa0344fff [ 1801.676241] [81002086] ? do_one_initcall+0x76/0x12c [ 1801.676250] [a0345000] ? 0xa0344fff [ 1801.676259] [81074921] ? sys_init_module+0x10c/0x25b [ 1801.676269] [81332792] ? system_call_fastpath+0x16/0x1b Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649033: Same here on Thinkpad X220
I occasionally see the same on Thinkpad X220 too. You don't need to shut down the machine in that case, pressing Ctrl-C is sufficient to interrupt udev and continue to boot. And I see the same messages about killing stuck modprobe, will confirm next time it happens. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634261: Analysis
I'm not sure how _IO_stdin_used comes into play here, but the failure
with this test case is actually happens because stdout itself is not
8-bytes aligned, as it should be. It looks like for the
normally-linked binary stdout is just set to the address of
_IO_2_1_stdout_, as one would expect from looking at libio/stdio.c in
libc source code, which contains:
_IO_FILE *stdin = (FILE *) _IO_2_1_stdin_;
_IO_FILE *stdout = (FILE *) _IO_2_1_stdout_;
_IO_FILE *stderr = (FILE *) _IO_2_1_stderr_;
Demo:
jurij@debian:~/libc/eglibc-2.13/tmp$ cat foo.c
#include stdio.h
#include stdlib.h
int main() {
printf(stdout=%p _IO_2_1_stdout_=%p\n, stdout, _IO_2_1_stdout_);
setbuf(stdout, 0);
return 0;
}
jurij@debian:~/libc/eglibc-2.13/tmp$ gcc -o foo foo.c
jurij@debian:~/libc/eglibc-2.13/tmp$ ./foo
stdout=0x207e0 _IO_2_1_stdout_=0x207e0
However, when using the version script, stdout is altered to point to
a unaligned location:
jurij@debian:~/libc/eglibc-2.13/tmp$ gcc -o foo foo.c -Wl,--version-script,ver
jurij@debian:~/libc/eglibc-2.13/tmp$ ./foo
stdout=0xf7d97114 _IO_2_1_stdout_=0x207c0
Bus error
The value is modified by the dynamic linker somewhere between the
_init and _start:
urij@debian:~/libc/eglibc-2.13/tmp$ gdb foo
GNU gdb (GDB) 7.3-debian
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show
copying
and show warranty for details.
This GDB was configured as sparc-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/jurij/libc/eglibc-2.13/tmp/foo...(no
debugging symbols found)...done.
(gdb) break _init
Breakpoint 1 at 0x1032c
(gdb) break _start
Breakpoint 2 at 0x10380
(gdb) run
Starting program: /home/jurij/libc/eglibc-2.13/tmp/foo
Breakpoint 1, _init (argc=-134233040, argv=0x1, envp=0xd814) at
../sysdeps/unix/sysv/linux/init-first.c:52
52 {
(gdb) print stdout
$1 = (struct _IO_FILE *) 0x207c0
(gdb) print _IO_2_1_stdout_
$2 = (struct _IO_FILE_plus *) 0xf7fc2d40
(gdb) c
Continuing.
Breakpoint 2, 0x00010380 in _start ()
(gdb) print stdout
$3 = (struct _IO_FILE *) 0xf7fc3114
(gdb) print _IO_2_1_stdout_
$4 = (struct _IO_FILE_plus *) 0xf7fc2d40
(gdb)
On amd64 stdout is set to the address of _IO_2_1_stdout_ even with the
version script:
jurij@paddy:~/tmp$ gcc -o foo foo.c -Wl,--version-script,ver
jurij@paddy:~/tmp$ ./foo
stdout=0x600a40 _IO_2_1_stdout_=0x600a40
Best regards
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634261: More debugging info
Some more debugging information:
In the failing case stdout get flipped to an unaligned value in
_IO_check_libio function defined in libio/oldstdfiles.c, which
contains the following code:
static void
_IO_check_libio ()
{
if (_IO_stdin_used == NULL)
{
/* We are using the old one. */
_IO_stdin = stdin = (_IO_FILE *) _IO_stdin_;
_IO_stdout = stdout = (_IO_FILE *) _IO_stdout_;
_IO_stderr = stderr = (_IO_FILE *) _IO_stderr_;
[...]
Why we are taking the 'if' branch is a bit of a mystery to me, because
_IO_stdin_used appears to be defined, as this bit of gdb session
illustrates:
(gdb) break _IO_check_libio
Function _IO_check_libio not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_IO_check_libio) pending.
(gdb) run
Starting program: /home/jurij/libc/tmp/foo
Breakpoint 1, _IO_check_libio () at oldstdfiles.c:79
warning: Source file is more recent than executable.
79if (_IO_stdin_used == NULL)
(gdb) print _IO_stdin_used
$1 = 131073
(gdb) print _IO_stdin_used
$2 = (const int *) 0x10638
(gdb) next
78 {
(gdb) next
79if (_IO_stdin_used == NULL)
(gdb) next
82_IO_stdin = stdin = (_IO_FILE *) _IO_stdin_;
(gdb) next
83_IO_stdout = stdout = (_IO_FILE *) _IO_stdout_;
(gdb) print stdout
$3 = (FILE *) 0x207c0
(gdb) print _IO_stdout_
$4 = (struct _IO_FILE_plus *) 0xf7fc3114
After this line is executed, stdout starts pointing to the new
unaligned location, eventually leading to a segfault. An important
observation is that symbol is unaligned even in libc, which obviously
should not be happening:
jurij@debian:~/libc/tmp$ nm /usr/lib/debug/lib/sparc-linux-gnu/libc-2.13.so |
grep _IO_stdout_
0017f114 D _IO_stdout_
To answer why we are hitting the _IO_stdin_used == NULL check, I've
looked at the assembly code, relevant parts of it look like that:
.LLADDPC0:
jmp %o7+8
add%o7, %l7, %l7
#NO_APP
.align 4
.align 32
.type _IO_check_libio, #function
.proc 020
_IO_check_libio:
.LLFB71:
.file 1 oldstdfiles.c
.loc 1 78 0
.cfi_startproc
save%sp, -96, %sp
.LLCFI0:
.cfi_def_cfa_register 30
.cfi_window_save
.loc 1 79 0
sethi %hi(_IO_stdin_used), %g1
.loc 1 78 0
sethi %hi(_GLOBAL_OFFSET_TABLE_-4), %l7
call.LLADDPC0
add%l7, %lo(_GLOBAL_OFFSET_TABLE_+4), %l7
.cfi_register 15, 31
.loc 1 79 0
or %g1, %lo(_IO_stdin_used), %g1
ld [%l7+%g1], %g1
cmp %g1, 0
[...]
So it's not simply using _IO_stdin_used address, but doing some
resolution of it, which, indeed, returns a NULL.
I don't think I can make any further progress on this bug without
investing significant amount of time into it, but we have enough
debugging information for a good upstream bug report, and I would be
glad to provide additional info if needed. One of the main questions
we should try to answer is why the _IO_std{in,out,err}_ symbols end up
to be not 8-byte aligned in libc, even though it looks like they
should be.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647627: FTBFS fix for sparc
With the attached patch the sparc build of the 2:2.4.2-1 version succeeds and all tests invoked by 'make test' pass (the previously posted patch is no longer required). I assume that fixes for other architectures are similarly trivial, however I don't know what their alignment requirements are and don't have a simple way to access them to test the build. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC --- a/deps/jemalloc/include/jemalloc/internal/jemalloc_internal.h.in 2011-10-26 15:16:33.0 +0100 +++ b/deps/jemalloc/include/jemalloc/internal/jemalloc_internal.h.in 2011-12-04 22:23:01.172009427 + @@ -132,6 +132,9 @@ #ifdef __alpha__ # define LG_QUANTUM 4 #endif +#ifdef __sparc__ +# define LG_QUANTUM 3 +#endif #ifdef __sparc64__ # define LG_QUANTUM 4 #endif
Bug#650085: Patch
tags 650085 patch
thanks
With the attached patch, suggested by Bastian Blank, the generated
headers are getting included in headers packages and the OOT modules
can be built again:
jurij@debian:~/tmp$ ls -al
/usr/src/linux-headers-3.1.0-1-sparc64*/arch/sparc/include/generated/asm
/usr/src/linux-headers-3.1.0-1-sparc64/arch/sparc/include/generated/asm:
total 24
drwxr-xr-x 2 root root 4096 Nov 27 18:52 .
drwxr-xr-x 3 root root 4096 Nov 27 18:52 ..
-rw-r--r-- 1 root root 31 Nov 27 09:01 div64.h
-rw-r--r-- 1 root root 34 Nov 27 09:01 irq_regs.h
-rw-r--r-- 1 root root 33 Nov 27 09:01 local64.h
-rw-r--r-- 1 root root 31 Nov 27 09:01 local.h
/usr/src/linux-headers-3.1.0-1-sparc64-smp/arch/sparc/include/generated/asm:
total 24
drwxr-xr-x 2 root root 4096 Nov 27 18:16 .
drwxr-xr-x 3 root root 4096 Nov 27 18:16 ..
-rw-r--r-- 1 root root 31 Nov 27 09:01 div64.h
-rw-r--r-- 1 root root 34 Nov 27 09:01 irq_regs.h
-rw-r--r-- 1 root root 33 Nov 27 09:01 local64.h
-rw-r--r-- 1 root root 31 Nov 27 09:01 local.h
jurij@debian:~/tmp$
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
diff -aur a/debian/rules.real b/debian/rules.real
--- a/debian/rules.real 2011-11-26 18:33:55.0 +
+++ b/debian/rules.real 2011-11-26 18:32:51.088008018 +
@@ -242,6 +242,7 @@
mkdir -p $(DIR)/arch/$(KERNEL_ARCH)/kernel
cp -a $(SOURCE_DIR)/{.config,.kernel*,Module.symvers,include} $(DIR)
+ cp -a $(SOURCE_DIR)/arch/$(KERNEL_ARCH)/include $(DIR)/arch/$(KERNEL_ARCH)
cp -a $(SOURCE_DIR)/arch/$(KERNEL_ARCH)/kernel/asm-offsets.s $(DIR)/arch/$(KERNEL_ARCH)/kernel
ifneq ($(filter powerpc ppc64,$(ARCH)),)
Bug#647627: Affects testing version as well
severity 647627 serious thanks Since this bug is also present in wheezy version, redis-server is completely unusable there as well, so it should really be RC. Also please note that the latest version in sid (2:2.4.2-1) failed to build on armel, s390 and sparc: https://buildd.debian.org/status/package.php?p=redis Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634261: Requesting clarification
Mike, can you clarify a bit how glibc is failing to meet your expectations here? I don't mind trying to work on this bug, but with the available information I don't quite understand the problem. Is it expected that glibc should work correctly even if _IO_stdin_used symbol is not exported? If you could provide a simple test case demonstrating the issue, it would be great too. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650085: Packaged headers do not include generated .h files
Package: linux-2.6
Version: 3.1.1-1
Severity: serious
Justification: breaks building of out-of-tree modules
Hello,
I'm unable to build any out-of-tree modules on sparc against headers
provided by a combination of linux-headers-3.1.0-1-common and
linux-headers-3.1.0-1-sparc64-smp packages (version 3.1.1-1). Typical
error messages:
jurij@debian:~/tmp/linux-3.1.1/samples/kprobes$ make -C
/lib/modules/3.1.0-1-sparc64-smp/build M=${PWD}
make: Entering directory `/usr/src/linux-headers-3.1.0-1-sparc64-smp'
CC [M] /home/jurij/tmp/linux-3.1.1/samples/kprobes/kprobe_example.o
In file included from
/usr/src/linux-headers-3.1.0-1-common/include/linux/time.h:9:0,
from
/usr/src/linux-headers-3.1.0-1-common/include/linux/stat.h:60,
from
/usr/src/linux-headers-3.1.0-1-common/include/linux/module.h:10,
from
/home/jurij/tmp/linux-3.1.1/samples/kprobes/kprobe_example.c:14:
/usr/src/linux-headers-3.1.0-1-common/include/linux/math64.h:5:23: fatal error:
asm/div64.h: No such file or directory
compilation terminated.
make[3]: *** [/home/jurij/tmp/linux-3.1.1/samples/kprobes/kprobe_example.o]
Error 1
make[2]: *** [_module_/home/jurij/tmp/linux-3.1.1/samples/kprobes] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
make: Leaving directory `/usr/src/linux-headers-3.1.0-1-sparc64-smp'
jurij@debian:~/tmp/linux-3.1.1/samples/kprobes$
It appears that asm/div64.h (along with some other headers) is
dynamically generated during the kernel build and it's
sufficient to invoke 'make prepare' target to get it done, for
example:
jurij@debian:~/tmp/linux-3.1.1$ make prepare
scripts/kconfig/conf --silentoldconfig Kconfig
WRAParch/sparc/include/generated/asm/div64.h
WRAParch/sparc/include/generated/asm/local64.h
WRAParch/sparc/include/generated/asm/irq_regs.h
WRAParch/sparc/include/generated/asm/local.h
CHK include/linux/version.h
UPD include/linux/version.h
CHK include/generated/utsrelease.h
UPD include/generated/utsrelease.h
CC kernel/bounds.s
GEN include/generated/bounds.h
CC arch/sparc/kernel/asm-offsets.s
GEN include/generated/asm-offsets.h
CALLscripts/checksyscalls.sh
jurij@debian:~/tmp/linux-3.1.1$
I guess that packaged headers are copied from a directory where this
command (or kernel build) was not run, and as a result they are not
included in the packages.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635126: Standalone test case
Hi,
Attached is a standalone test case for this bug, obtained on an
up-to-date sid/sparc system. With it I see the following behavior:
jurij@debian:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc-linux-gnu/4.6/lto-wrapper
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--enable-targets=all --with-long-double-128 --enable-checking=release
--build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu
Thread model: posix
gcc version 4.6.2 (Debian 4.6.2-5)
jurij@debian:~$
jurij@debian:~$ gcc -g -O2 -fno-tree-sra pack.c -o pack
jurij@debian:~$ ./pack
do_something called with item=-32767
do_something called with item=-123456
jurij@debian:~$
jurij@debian:~$ gcc -g -O2 pack.c -o pack
jurij@debian:~$ ./pack
do_something called with item=-32767
Bus error
jurij@debian:~$
jurij@debian:~$ gdb pack
GNU gdb (GDB) 7.3-debian
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as sparc-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/jurij/pack...done.
(gdb) run
Starting program: /home/jurij/pack
do_something called with item=-32767
Program received signal SIGBUS, Bus error.
pack_unpack (s=0x1068a \377\376\035\300, p=0x10692 ) at pack.c:62
62 memcpy (v.a, s, sizeof (int32_t));
(gdb) bt
#0 pack_unpack (s=0x1068a \377\376\035\300, p=0x10692 ) at pack.c:62
#1 0xf7e64854 in __libc_start_main () from /lib/sparc-linux-gnu/libc.so.6
#2 0x00010378 in _start ()
(gdb)
I don't believe that it's related to the upstream bug Lucas mentioned,
as it was specifically triggered by using bit fields, which are not
used in any way here.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
#include string.h
#include stdio.h
#include stdint.h
void
do_something (int item)
{
printf (do_something called with item=%d\n, item);
}
void do_something (int item) __attribute__ ((noinline));
int
pack_unpack (char *s, char *p)
{
char *send, *pend;
char type;
int integer_size;
send = s + strlen (s);
pend = p + strlen (p);
while (p pend)
{
type = *p++;
switch (type)
{
case 's':
integer_size = 2;
goto unpack_integer;
case 'l':
integer_size = 4;
goto unpack_integer;
unpack_integer:
switch (integer_size)
{
case 2:
{
union
{
int16_t i;
char a[sizeof (int16_t)];
}
v;
memcpy (v.a, s, sizeof (int16_t));
s += sizeof (int16_t);
do_something (v.i);
}
break;
case 4:
{
union
{
int32_t i;
char a[sizeof (int32_t)];
}
v;
memcpy (v.a, s, sizeof (int32_t));
s += sizeof (int32_t);
do_something (v.i);
}
break;
}
break;
}
}
return (int) *s;
}
int
main ()
{
return pack_unpack (\200\001\377\376\035\300, sl);
}
Bug#635126: Raising severity to 'serious'
severity 635126 serious thanks With my sparc port maintainer hat on, I'm setting severity of this bug back to serious. --ftree-sre is on by default for -O2, so pretty much every sparc binary in the archive is potentially affected by it. The fact that the test code does not do anything exotic to trigger it (well, nothing that I can see) convinces me that it should be fixed before we can release. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613590: Tagging as not present in testing/unstable
tags 613590 - moreinfo + squeeze notfound 613590 0.9.1-1 thanks Thanks, I've adjusted the tags appropriately. -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645822: Sparc FTBFS is fixed by --disable-checking
Hello, I've just confirmed that gcc-avr builds successfully on sparc if --disable-checking is dropped from configure options. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648016: Lower the severity as workaround has been found
severity 648016 important thanks I'm dropping the severity of this bug because gcc-avr FTBFS goes away if one drops --disable-checking from configure flags (it currently uses it), and using it is not recommended by GCC maintainers (see discussion in the upstream bug). Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613590: Please provide some information on how to reproduce the problem
tags 613590 moreinfo thanks Hi, Are you still experiencing this bug? If yes, then please provide some instructions on how to reproduce it. At least conntrack -L (using libnetfilter-conntrack3 0.9.1-1) on my mostly-up-to-date sid system appears to function as expected: jurij@debian:~$ uname -a Linux debian 3.0.0-2-sparc64-smp #1 SMP Wed Nov 2 11:28:15 UTC 2011 sparc64 GNU/Linux jurij@debian:~$ dpkg -l | grep conntrack ii conntrack1:1.0.0-2 Program to modify the conntrack tables ii libnetfilter-conntrack3 0.9.1-1 Netfilter netlink-conntrack library jurij@debian:~$ sudo conntrack -L tcp 6 431999 ESTABLISHED src=192.168.1.13 dst=192.168.1.14 sport=22 dport=37816 src=192.168.1.14 dst=192.168.1.13 sport=37816 dport=22 [ASSURED] mark=0 use=1 conntrack v1.0.0 (conntrack-tools): 1 flow entries have been shown. jurij@debian:~$ Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648016: Some analysis
reassign 648016 gcc-4.6
found 648016 4.6.2-4
thanks
This bug really is in gcc-4.6, because it is currently the default sid
gcc and it is used to (mis)compile src/build/genrecog.c during
gcc-avr build, which later crashes. I'm fairly certain that this is
gcc problem, because if the binary is compiled with -O0, the problem
goes away. All debugging output below was obtained on a sparc machine
running up-to-date sid, invoking build/genrecog under gdb with a
single argument of '../../src/gcc/config/avr/avr.md'.
Tracing the execution is somewhat tricky, since failure happens within
write_tree(), and most of the functions write_tree() calls
(write_tree_1, write_switch, write_node, write_action, etc) are
optimized out. The output generated by
build/genrecog ../../src/gcc/config/avr/avr.md
is the same as the one produced on an amd64 system until we hit the
following code in genrecog.c/write_switch():
else if (type == DT_mode
|| type == DT_veclen
|| type == DT_elt_zero_int
|| type == DT_elt_one_int
|| type == DT_elt_zero_wide_safe)
{
const char *indent = ;
/* We cast switch parameter to integer, so we must ensure that the value
fits. */
if (type == DT_elt_zero_wide_safe)
{
indent = ;
printf( if ((int) XWINT (x%d, 0) == XWINT (x%d, 0))\n, depth, depth);
}
printf (%s switch (, indent);
switch (type)
{
case DT_mode:
printf (GET_MODE (x%d), depth);
break;
case DT_veclen:
printf (XVECLEN (x%d, 0), depth);
break;
case DT_elt_zero_int:
printf (XINT (x%d, 0), depth);
break;
case DT_elt_one_int:
printf (XINT (x%d, 1), depth);
break;
case DT_elt_zero_wide_safe:
/* Convert result of XWINT to int for portability since some C
compilers won't do it and some will. */
printf ((int) XWINT (x%d, 0), depth);
break;
default:
gcc_unreachable ();
}
The problem appears after executing the
printf (%s switch (, indent);
statetement. It looks like compiler generates a number of small stubs
within write_tree() for calling printf with all possible format
statements. Here's how the generated assembler code looks for this
particular one, starting at 0x00013e60:
Dump of assembler code from 0x13e40 to 0x13ea0:
0x00013e40 write_tree+2144:ld [ %i5 + 0x1c ], %o2
0x00013e44 write_tree+2148:sethi %hi(0x1e800), %o0
0x00013e48 write_tree+2152:or %l1, 0x110, %o1
0x00013e4c write_tree+2156:call 0x3510c printf@plt
0x00013e50 write_tree+2160:or %o0, 0x258, %o0
0x00013e54 write_tree+2164:b %xcc, 0x13bf4 write_tree+1556
0x00013e58 write_tree+2168:ld [ %i0 ], %i5
0x00013e5c write_tree+2172:be,pn %icc, 0x13850 write_tree+624
= 0x00013e60 write_tree+2176:sethi %hi(0x1f400), %i3
0x00013e64 write_tree+2180:sethi %hi(0x1e800), %o0
0x00013e68 write_tree+2184:or %o0, 0x2b0, %o0 ! 0x1eab0
0x00013e6c write_tree+2188:call 0x3510c printf@plt
0x00013e70 write_tree+2192:or %i3, 0xe8, %o1
0x00013e74 write_tree+2196:cmp %l7, 7
0x00013e78 write_tree+2200:sll %l7, 2, %g1
0x00013e7c write_tree+2204:sethi %hi(0x1e800), %o0
0x00013e80 write_tree+2208:mov %l6, %o1
0x00013e84 write_tree+2212:call 0x3510c printf@plt
0x00013e88 write_tree+2216:or %o0, 0x3e8, %o0
0x00013e8c write_tree+2220:b %xcc, 0x13bac write_tree+1484
0x00013e90 write_tree+2224:ld [ %fp + -192 ], %g3
0x00013e94 write_tree+2228:b %xcc, 0x13ad0 write_tree+1264
0x00013e98 write_tree+2232:st %g2, [ %fp + -188 ]
0x00013e9c write_tree+2236:cmp %g0, %i3
End of assembler dump.
Confirmation that 0x1eab0 contains the correct format statement
(passed to printf in %o0):
(gdb) printf %s\n, (char *) 0x1eab0
%s switch (
(gdb)
A remarkable feature of this stub is that it does not have a return
branch statement, like others do (see 0x00013e54, for example). So,
instead of returning to the correct location where the stub was
invoked in write_switch(), we fall through to 0x00013e74, and start
executing the next stub, which invokes printf with a format
statement at 0x1ebe8 (== 0x1e800 | 0x3e8):
(gdb) printf %s\n, (char *) 0x1ebe8
%sreturn gen_split_%d (insn, operands);
(gdb)
This is completely unrelated code, normally invoked by
write_action(), line 2182. Once it's done, we jump back to completely
wrong location at 0x00013e8c, eventually causing a crash.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647627: Patch
tags 647627 patch thanks Hi, It crashes because of the improper alignment of allocated memory, due to wrong setting of PREFIX size on sparc. Attached patch fixes it. I believe that you should be able to drop 'defined(__sun)' completely from this clause, as Solaris on x86 hardware probably does not have strict alignment requirements, but I don't have a way to test that. By the way, after applying the patch and building redis-server I tried running the test suite (invoked by 'make test') and it eventually dies after about 15-20 minutes of execution (after executing quite a few tests successfully). Does not look like it's related to this bug, but I thought you might want to investigate. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC diff -aur a/src/zmalloc.c b/src/zmalloc.c --- a/src/zmalloc.c 2011-07-22 11:22:26.0 +0100 +++ b/src/zmalloc.c 2011-11-05 10:21:09.220008726 + @@ -38,7 +38,7 @@ #ifdef HAVE_MALLOC_SIZE #define PREFIX_SIZE (0) #else -#if defined(__sun) +#if defined(__sun) || defined(__sparc) || defined(__sparc__) #define PREFIX_SIZE (sizeof(long long)) #else #define PREFIX_SIZE (sizeof(size_t))
Bug#645657: Debian daily image isn't bootable on sparc
retitle 645657 Daily sparc netboot images are too big, fail to boot thanks The netboot images are too big and are larger than OBP can handle (it seems the limit is around 10MB). Here's the list of files in the initrd, sorted by size: http://www.wooyd.org/debian/initrd_contents.txt Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644856: gcc -mcpu=v8 generates asm code which latest as cannot grok
Package: binutils
Version: 2.21.90.20111004-2
Severity: important
Hello,
This code:
#include stdio.h
#include stdlib.h
int main(int argc, char **argv) {
long l = strtold(argv[1], NULL);
printf(%ld\n, l*1327);
return 0;
}
fails to compile on sparc with -mcpu=v8 with the latest gcc/binutils
from unstable:
jurij@debian:~/gcc$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc-linux-gnu/4.6.1/lto-wrapper
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.6.1-13' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --enable-targets=all --with-long-double-128
--enable-checking=release --build=sparc-linux-gnu
--host=sparc-linux-gnu --target=sparc-linux-gnu
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-13)
jurij@debian:~/gcc$ gcc -mcpu=v8 mul.c
/tmp/ccy32xBi.s: Assembler messages:
/tmp/ccy32xBi.s:39: Error: Hardware capability mul32 not enabled for
smul.
jurij@debian:~/gcc$
It appears that the culprit is the following recent commit to
binutils:
http://repo.or.cz/w/binutils.git/commitdiff/24f272de258d79c9d959143a8fd626b9961a8ac0
It tries to catch the cases when we use assembler instructions
incompatible with CPU type, and thinks that 'smul' is not appropriate
for -mcpu=v8, however this used to work before this commit.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640271: xserver-xorg-input-evdev: Fails to switch keyboard layouts with grp:caps_toggle
Package: xserver-xorg-input-evdev Version: 1:2.6.0-2+b2 Severity: important Greetings, I've added a simple xorg.conf (see below) on my new machine (Thinkpad X220) in order to be able to switch between US and Russian keyboard layouts. It worked fine in the past with kbd driver, but with evdev it does not appear to have any effect - pressing Caps Lock does not switch the layout. I've verified that behavior is the same in Gnome and awesome, and that I can still switch the layouts from the command line using setxkbmap. With xev I see the following when pressing Caps Lock: KeyPress event, serial 28, synthetic NO, window 0x181, root 0xb2, subw 0x0, time 17052057, (677,714), root:(678,734), state 0x0, keycode 66 (keysym 0xfe08, ISO_Next_Group), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 28, synthetic NO, window 0x181, root 0xb2, subw 0x0, time 17052136, (677,714), root:(678,734), state 0x0, keycode 66 (keysym 0xfe08, ISO_Next_Group), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False Please let me know if you need any other debugging info. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Sep 2 20:09 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1942640 Aug 28 12:00 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) Xorg X server configuration file status: -rw-r--r-- 1 root root 169 Sep 3 12:38 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: --- Section InputClass Identifier Keyboard Defaults MatchIsKeyboard yes Option XkbLayout us,ru(phonetic) Option XkbOptions grp:caps_toggle EndSection /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 3.0.0-1-amd64 (Debian 3.0.0-3) (b...@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-8) ) #1 SMP Sat Aug 27 16:21:11 UTC 2011 Xorg X server log files on system: -- -rw-r--r-- 1 root root 33587 Sep 3 15:09 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [27.497] X.Org X Server 1.11.0 Release Date: 2011-08-26 [27.497] X Protocol Version 11, Revision 0 [27.497] Build Operating System: Linux 3.0.0-1-amd64 x86_64 Debian [27.497] Current Operating System: Linux paddy 3.0.0-1-amd64 #1 SMP Sat Aug 27 16:21:11 UTC 2011 x86_64 [27.497] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.0.0-1-amd64 root=UUID=476bc45a-c62d-409b-b6e9-81acb45fab7e ro quiet [27.497] Build Date: 28 August 2011 10:58:30AM [27.497] xorg-server 2:1.11.0-1 (Cyril Brulebois k...@debian.org) [27.497] Current version of pixman: 0.22.2 [27.497]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [27.497] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [27.497] (==) Log file: /var/log/Xorg.0.log, Time: Sat Sep 3 15:09:22 2011 [27.592] (==) Using config file: /etc/X11/xorg.conf [27.592] (==) Using system config directory /usr/share/X11/xorg.conf.d [27.644] (==) No Layout section. Using the first Screen section. [27.644] (==) No screen section available. Using defaults. [27.644] (**) |--Screen Default Screen Section (0) [27.644] (**) | |--Monitor default monitor [27.658] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [27.658] (==) Automatically adding devices [27.658] (==) Automatically enabling devices [27.696] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. [27.696]Entry deleted from font path. [27.719] (WW) `fonts.dir' not found (or not valid) in /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType. [27.719]Entry deleted from font path. [27.719](Run 'mkfontdir' on /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType). [27.719] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [
Bug#640054: Download pages should have prominent links to image verification instructions
Package: www.debian.org Severity: normal Hello, It appears that the main download pages for media do not contain any links to instructions on how to verify that downloaded image is authentic (see http://www.debian.org/distrib/netinst, for example). I was eventually able to get to http://www.debian.org/CD/verify by reading the installation manual, but I believe that we can make it easier for our users by including links to signed checksums for every image along with the instructions. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637767: [da...@davemloft.net: [PATCH] Serious glibc sparc rlimits bug]
Package: libc6-dev Version: 2.13-16 Severity: important - Forwarded message from David Miller da...@davemloft.net - Date: Sun, 14 Aug 2011 00:29:18 -0700 (PDT) From: David Miller da...@davemloft.net To: ju...@wooyd.org CC: debian-sp...@lists.debian.org Subject: [PATCH] Serious glibc sparc rlimits bug X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Unfortunately, the sparc32 definition of the 64-bit RLIM_INFINITY value is wrong, and it's been wrong for a while. This causes serious problems, the worst of which is that no 64-bit pthread program executing as a child of 'make' can succeed. GLIBC's pthread_create() uses the current RLIMIT_STACK value as a hint for sizing thread stacks. It handles RLIM_INFINITY specially instead of trying to allocate an enormous stack. But if RLIM_INFINITY is wrong... right, nothing works. How this happens is that libpam corrupts the kernel default rlimits when it creates a login session, because even if you have no explicit settings in /etc/security/limits.conf it still reads every rlimit then sets it right back to the same value. It even has some pre-cooked defaults, and the default for RLIMIT_STACK is cur=8MB max=RLIM_INFINITY So if RLIM_INFINITY is wrong (for 32-bit binaries it's too small), the values will all get truncated down to this incorrect RLIM_INFINITY value. Next, make sets the current RLIMIT_STACK 'cur' value to the maximum, so now the current RLIMIT_STACK has this wrong RLIM_INFINITY value too. Then 64-bit glibc doesn't recognize this value as RLIM_INFINITY during pthread_create() and it tries to allocate a thread stack of size 0x8000 bytes. This, of course, fails. A bunch of binaries are going to need to be rebuilt because of this issue once the glibc build goes through, I would prioritize libpam0g, make, and emacs23. I'll be committing this soon to glibc GIT. I tested this by doing a glibc deb rebuild with this patch applied, installing, then rebuilding libpam0g and make. 2011-08-14 David S. Miller da...@davemloft.net * sysdeps/unix/sysv/linux/sparc/bits/resource.h (RLIM_INFINITY, RLIM64_INFINITY): Fix 64-bit values for 32-bit sparc. diff --git a/sysdeps/unix/sysv/linux/sparc/bits/resource.h b/sysdeps/unix/sysv/linux/sparc/bits/resource.h index 04d33e4..5c00b8f 100644 --- a/sysdeps/unix/sysv/linux/sparc/bits/resource.h +++ b/sysdeps/unix/sysv/linux/sparc/bits/resource.h @@ -130,11 +130,11 @@ enum __rlimit_resource #ifndef __USE_FILE_OFFSET64 # define RLIM_INFINITY ((long int)(~0UL 1)) #else -# define RLIM_INFINITY 0x7fffLL +# define RLIM_INFINITY 0xLL #endif #ifdef __USE_LARGEFILE64 -# define RLIM64_INFINITY 0x7fffLL +# define RLIM64_INFINITY 0xLL #endif #endif - End forwarded message - -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631593: udevadm logs to system console, interfering with d-i UI
On Mon, Jun 27, 2011 at 03:42:29AM +0200, Marco d'Itri wrote:
Apparently debug mode is enabled, but so far I do not understand what
causes this.
case $1 in
configure)
if [ -z $2 ]; then # first install
echo write_interfaces_rules
if ! chrooted ! in_debootstrap; then
enable_udev
fi
and
write_interfaces_rules() {
local devpath
for devpath in /sys/class/net/*; do
[ -d $devpath ] || continue
udevadm test --action=add $devpath /dev/null || true
done
}
so there is an invocation of udevadm not protected by
chroot/debootstrap checks. If I disable this invocation of
write_interfaces_rules (during the time when package is unpacked but
not configured), I don't see any messages on the console.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631593: udevadm logs to system console, interfering with d-i UI
On Sun, Jun 26, 2011 at 06:04:19AM +0200, Marco d'Itri wrote: On Jun 25, Jurij Smakov ju...@wooyd.org wrote: While testing the recent daily d-i build on sparc over serial console, I've noticed that at some point udevadm logs a few messages to the console, interfering with d-i user interface (see attached screenshot). As it happens during package installation phase, the screen remains messed up for quite a while, so it would be nice to get this fixed. I am not sure how this can happen: the first message you see has priority info, but udev.conf is configured to only log messages with priority = err. I see in the logs that during the installation of the base system rsyslog is configured soon after udev. It might be that before rsyslog is configured, the logging priorities are not honored. Depending on rsyslog (or, perhaps, system-log-daemon | rsyslog) should be a simple workaround. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631593: udevadm logs to system console, interfering with d-i UI
On Sun, Jun 26, 2011 at 04:26:00PM +0200, Marco d'Itri wrote: On Jun 26, Jurij Smakov ju...@wooyd.org wrote: I see in the logs that during the installation of the base system rsyslog is configured soon after udev. It might be that before rsyslog is configured, the logging priorities are not honored. Depending on rsyslog (or, perhaps, system-log-daemon | rsyslog) should be a simple workaround. No, this check happens inside udev(adm). I'm not sure what you mean. As far as I can tell, the messages are logged by udevadm, which is invoked in the postinst of udev package during package configuration. As rsyslog is unpacked but not configured at this point (it is configured later), I presume that logging priority is not honored and messages end up on the system console. If udev package would defend on rsyslog, it would guarantee that rsyslog is configured before udev is, and it might fix things (I have to admit that it's all pure speculation, as I don't really see what special things rsyslog package configuration does). Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631574: Oops while trying to mount installer CD-ROM
Package: linux-2.6
Version: 2.6.39-2
Severity: important
Hello,
I was testing today's sparc daily d-i build and noticed that the
kernel oopses during pkgsel stage, while trying to mount the installer
CD:
[ 2124.205340] Unable to handle kernel NULL pointer dereference
[ 2124.308334] tsk-{mm,active_mm}-context = 1c74
[ 2124.410818] tsk-{mm,active_mm}-pgd = f8007c422000
[ 2124.509451] \|/ \|/
[ 2124.509455] @'/ .. \`@
[ 2124.509460] /_| \__/ |_\
[ 2124.509464] \__U_/
[ 2124.509475] mount(8477): Oops [#1]
[ 2124.509490] TSTATE: 004411001601 TPC: 00529774 TNPC:
00529778 Y: Not tainted
[ 2124.509521] TPC: blkdev_get+0x26c/0x2e0
[ 2124.509532] g0: f8007e008c60 g1: f8004fe0 g2: fff6
g3: bf807fdec0102800
[ 2124.509545] g4: f8007c549860 g5: ff00 g6: f8007bbc8000
g7: 008d77c8
[ 2124.509557] o0: f8004fe0 o1: f8007d8040a0 o2:
o3: f8007783d748
[ 2124.509570] o4: o5: sp: f8007bbcb081
ret_pc: 0052976c
[ 2124.509585] RPC: blkdev_get+0x264/0x2e0
[ 2124.509595] l0: f8007d804060 l1: ffe2 l2: f8007d804078
l3:
[ 2124.509608] l4: 0047635c l5: 00527fa8 l6: f8007d8040a0
l7: 0053903c
[ 2124.509621] i0: f8007d804060 i1: 0083 i2: 101c7d78
i3: 0001
[ 2124.509634] i4: 0006 i5: 01f7 i6: f8007bbcb161
i7: 005298e0
[ 2124.509649] I7: blkdev_get_by_path+0x1c/0x6c
[ 2124.509656] Call Trace:
[ 2124.509668] [005298e0] blkdev_get_by_path+0x1c/0x6c
[ 2124.509688] [005020a8] mount_bdev+0x20/0x194
[ 2124.509701] [00501b44] mount_fs+0x64/0x170
[ 2124.509713] [00518338] vfs_kern_mount+0x48/0x90
[ 2124.509724] [005183c0] do_kern_mount+0x24/0xbc
[ 2124.509734] [00518b78] do_mount+0x720/0x784
[ 2124.509748] [00539204] compat_sys_mount+0x1c8/0x204
[ 2124.509768] [00405fd4] linux_sparc_syscall32+0x34/0x40
[ 2124.509778] Disabling lock debugging due to kernel taint
[ 2124.509792] Caller[005298e0]: blkdev_get_by_path+0x1c/0x6c
[ 2124.509805] Caller[005020a8]: mount_bdev+0x20/0x194
[ 2124.509818] Caller[00501b44]: mount_fs+0x64/0x170
[ 2124.509829] Caller[00518338]: vfs_kern_mount+0x48/0x90
[ 2124.509840] Caller[005183c0]: do_kern_mount+0x24/0xbc
[ 2124.509851] Caller[00518b78]: do_mount+0x720/0x784
[ 2124.509862] Caller[00539204]: compat_sys_mount+0x1c8/0x204
[ 2124.509875] Caller[00405fd4]: linux_sparc_syscall32+0x34/0x40
[ 2124.509892] Caller[000138e4]: 0x138e4
[ 2124.509899] Instruction DUMP: 90042040 7ffd32f2 92102000 c404e260
80a00011 82603fff 8530a008 80888001 0248000b
It appears that it has been already fixed upstream:
http://www.spinics.net/lists/stable-commits/msg12520.html
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628619: openjdk-7 7~b136-2.0~pre1-2 ftbfs on sparc
On Wed, Jun 01, 2011 at 08:18:33AM +0100, Jurij Smakov wrote: I think the uses of names like CON__G1 are just typos, as everywhere around this function names like CON_G1 (with one underscore) are used, and there is an enum near the top of the file defining them. I'll try to confirm tonight that removing one underscore fixes the build. It was slightly more complicated than just removing extra underscores, but the attached patch fixes this issue. Unfortunately, the build now dies later with make[5]: Entering directory `/home/jurij/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/make' make[5]: *** No rule to make target `/home/jurij/openjdk-7-7~b136-2.0~pre1/build/openjdk.build-boot/hotspot/import/docs/platform/jvmti/jvmti.html', needed by `generic_export'. Stop. make[5]: Leaving directory `/home/jurij/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/make' make[4]: *** [export_product] Error 2 make[4]: Leaving directory `/home/jurij/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/make' make[3]: *** [hotspot-build] Error 2 make[3]: Leaving directory `/home/jurij/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot' make[2]: *** [build_product_image] Error 2 make[2]: Leaving directory `/home/jurij/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot' make[1]: *** [stamps/icedtea-boot.stamp] Error 2 make[1]: Leaving directory `/home/jurij/openjdk-7-7~b136-2.0~pre1/build' /bin/bash: line 7: kill: (552) - No such process make: *** [stamps/build] Error 1 I'll poke it some more to see if I can fix it. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC diff -aurN a/debian/patches/hotspot-sparc-regnames-fix.diff b/debian/patches/hotspot-sparc-regnames-fix.diff --- a/debian/patches/hotspot-sparc-regnames-fix.diff 1970-01-01 01:00:00.0 +0100 +++ b/debian/patches/hotspot-sparc-regnames-fix.diff 2011-06-01 22:54:15.395996324 +0100 @@ -0,0 +1,48 @@ +--- openjdk/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp.orig 2011-06-01 22:50:13.444002377 +0100 openjdk/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp 2011-06-01 22:51:13.504004543 +0100 +@@ -309,29 +309,30 @@ + if (context == NULL) return; + + ucontext_t *uc = (ucontext_t*)context; ++ sigcontext* sc = (sigcontext*)context; + intptr_t *sp = (intptr_t *)os::Linux::ucontext_get_sp(uc); + + st-print_cr(Register to memory mapping:); + st-cr(); + + // this is only for the general purpose registers +- st-print(G1=); print_location(st, SIG_REGS(sc).u_regs[CON__G1]); +- st-print(G2=); print_location(st, SIG_REGS(sc).u_regs[CON__G2]); +- st-print(G3=); print_location(st, SIG_REGS(sc).u_regs[CON__G3]); +- st-print(G4=); print_location(st, SIG_REGS(sc).u_regs[CON__G4]); +- st-print(G5=); print_location(st, SIG_REGS(sc).u_regs[CON__G5]); +- st-print(G6=); print_location(st, SIG_REGS(sc).u_regs[CON__G6]); +- st-print(G7=); print_location(st, SIG_REGS(sc).u_regs[CON__G7]); ++ st-print(G1=); print_location(st, SIG_REGS(sc).u_regs[CON_G1]); ++ st-print(G2=); print_location(st, SIG_REGS(sc).u_regs[CON_G2]); ++ st-print(G3=); print_location(st, SIG_REGS(sc).u_regs[CON_G3]); ++ st-print(G4=); print_location(st, SIG_REGS(sc).u_regs[CON_G4]); ++ st-print(G5=); print_location(st, SIG_REGS(sc).u_regs[CON_G5]); ++ st-print(G6=); print_location(st, SIG_REGS(sc).u_regs[CON_G6]); ++ st-print(G7=); print_location(st, SIG_REGS(sc).u_regs[CON_G7]); + st-cr(); + +- st-print(O0=); print_location(st, SIG_REGS(sc).u_regs[CON__O0]); +- st-print(O1=); print_location(st, SIG_REGS(sc).u_regs[CON__O1]); +- st-print(O2=); print_location(st, SIG_REGS(sc).u_regs[CON__O2]); +- st-print(O3=); print_location(st, SIG_REGS(sc).u_regs[CON__O3]); +- st-print(O4=); print_location(st, SIG_REGS(sc).u_regs[CON__O4]); +- st-print(O5=); print_location(st, SIG_REGS(sc).u_regs[CON__O5]); +- st-print(O6=); print_location(st, SIG_REGS(sc).u_regs[CON__O6]); +- st-print(O7=); print_location(st, SIG_REGS(sc).u_regs[CON__O7]); ++ st-print(O0=); print_location(st, SIG_REGS(sc).u_regs[CON_O0]); ++ st-print(O1=); print_location(st, SIG_REGS(sc).u_regs[CON_O1]); ++ st-print(O2=); print_location(st, SIG_REGS(sc).u_regs[CON_O2]); ++ st-print(O3=); print_location(st, SIG_REGS(sc).u_regs[CON_O3]); ++ st-print(O4=); print_location(st, SIG_REGS(sc).u_regs[CON_O4]); ++ st-print(O5=); print_location(st, SIG_REGS(sc).u_regs[CON_O5]); ++ st-print(O6=); print_location(st, SIG_REGS(sc).u_regs[CON_O6]); ++ st-print(O7=); print_location(st, SIG_REGS(sc).u_regs[CON_O7]); + st-cr(); + + st-print(L0=); print_location(st, sp[L0-sp_offset_in_saved_window()]); diff -aurN a/debian/rules b/debian/rules --- a/debian/rules 2011-06-01 22:53:18.0 +0100 +++ b/debian/rules 2011-06-01 22:54:08.355997474 +0100 @@ -283,6 +283,11 @@ export USE_PRECOMPILED_HEADER=0 endif +ifneq (,$(filter $(DEB_HOST_ARCH), sparc sparc64)) + DISTRIBUTION_PATCHES
Bug#628619: openjdk-7 7~b136-2.0~pre1-2 ftbfs on sparc
~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:332:60: error: 'CON__O5' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:333:60: error: 'CON__O6' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:334:60: error: 'CON__O7' was not declared in this scope make[8]: *** [os_linux_sparc.o] Error 1 make[8]: *** Waiting for unfinished jobs make[8]: Leaving directory `/build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk.build-boot/hotspot/outputdir/linux_sparc_compiler2/product' make[7]: *** [the_vm] Error 2 make[7]: Leaving directory `/build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk.build-boot/hotspot/outputdir/linux_sparc_compiler2/product' make[6]: *** [product] Error 2 make[6]: Leaving directory `/build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk.build-boot/hotspot/outputdir' make[5]: *** [generic_build2] Error 2 I think the uses of names like CON__G1 are just typos, as everywhere around this function names like CON_G1 (with one underscore) are used, and there is an enum near the top of the file defining them. I'll try to confirm tonight that removing one underscore fixes the build. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623710: Processed: cloning 623710, retitle -1 to mklibs-copy is being
Hi, I've tested that if you build a debian-installer netboot image with latest version of binutils, then you get a broken image. Downgrading binutils (without touching anything else) fixed it. Steps to reproduce in up-to-date sid with a version of debian-installer in which mklibs were not replaced with mklibs-copy: 1. apt-get source debian-installer 2. apt-get build-dep debian-installer 3. cd debian-installer-20110106+squeeze1/build/ 4. make build_netboot 5. sudo chroot tmp/netboot/tree /bin/sh This will exit with a non-zero exit code as /bin/sh points to busybox which segfaults immediately. 6. Downgrade binutils to 2.21.0.20110327-3. 7. make reallyclean 8. make build_netboot 9. sudo chroot tmp/netboot/tree /bin/sh This will drop you into a busybox shell because everything is working properly. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623710: Reassigning to binutils
reassign 623710 binutils retitle 623710 New binutils break library reduction in d-i found 623710 2.21.51.20110419-2 severity 623710 serious thanks Hello, With binutils 2.21.51.20110419-2 library reduction is broken in d-i (part of the image building in debian-installer): a reduced libc.so.6 does not work, causing busybox (which is the first process executed) to segfault and kernel to panic (attempted to kill init) during boot. Problem is not reproducible with binutils 2.21.0.20110327-3. This currently renders all d-i daily builds unusable, hence the severity. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623710: Netboot build log
Some additional info: I've put a netboot image build log at http://www.wooyd.org/tmp/build_netboot.log.bz2 It shows what mklibs (a tool used to do the library reductions) actually does, looks like some relinking using gcc and then objcopy, look for the lines 'reducing libc.so.6'. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#392514: problem with XF86Config-4
On Mon, Apr 04, 2011 at 05:07:53AM +0200, Cyril Brulebois wrote: Hi, Jurij Smakov ju...@wooyd.org (13/10/2006): Sorry to disappoint you, but the card you have is Sun Elite3D, which is not supported by X.org at this moment, to the best of my knowledge. The only thing I can recommend is to get a Creator or Elite 3D card, which are supported fine by the sunffb driver. they managed to have both Sun Elite3D and non-Sun Elite 3D? Great. Given code didn't change, the status probably didn't change since 2006; but a confirmation would be welcome anyway. It should have read the card you have is Sun Expert3D. The Creator and Elite3D are actually supported, Expert3D is not (well, basic framebuffer functions do work, but X does not work). I don't think there is hope, even though it was mentioned recently on sparclinux mailing list, this post provides a summary: http://lists.debian.org/debian-sparc/2011/02/msg00019.html Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619435: Please increase NR_CPUS on sparc to 256
Package: linux-2.6 Version: 2.6.38-1 Severity: normal Hello, It is not uncommon for the last-generation T2+ sparc machines to have 128 and more CPUs. Please increase CONFIG_NR_CPUS on sparc to 256 to accomodate these cases. I've verified that this change leads to a tiny increase in the size of the compressed image (less than 1KB). Unfortunately, bumping this number breaks the ABI, so it's most likely not going to be suitable for the squeeze point release, but at least we'll get it into testing and unstable kernels. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616689: Root-on-LVM setup fails often due to timing issues
Package: initramfs-tools Version: 0.98.8 Severity: normal Hello, On my box (Sunblade 1000) the LVM initialization does not happen fast enough, so mounting root filesystem fails in roughly 95% of the cases: [ 90.520448] qla2xxx 0001:00:04.0: Allocated (252 KB) for firmware dump... [ 90.764373] qla2xxx 0001:00:04.0: LIP reset occurred (f8e8). [ 90.867334] scsi0 : qla2xxx [ 90.935081] qla2xxx 0001:00:04.0: LIP occurred (f7f7). [ 91.031152] qla2xxx 0001:00:04.0: LOOP UP detected (1 Gbps). [ 91.135284] qla2xxx 0001:00:04.0: [ 91.135288] QLogic Fibre Channel HBA Driver: 8.03.05-k0 [ 91.135293] QLogic QLA22xx - [ 91.135297] ISP2200: PCI (66 MHz) @ 0001:00:04.0 hdma-, host#=0, fw=2.02.08 TP Begin: Loading essential drivers ... done. Begin: Run[ 91.621764] device-mapper: uevent: version 1.0.3 ning /scripts/init-premount ... don[ 91.713376] device-mapper: ioctl: 4.18.0-ioctl (2010-06-29) initialised: dm-de...@redhat.com e. Begin: Mounting root file system ... Begin: Running /scrip[ 91.879330] scsi 0:0:0:0: Direct-Access HITACHI DKR1C-J072FC D7V5 PQ: 0 ANSI: 3 ts/local-top ... [ 92.031443] sd 0:0:0:0: Attached scsi generic sg2 type 0 [ 92.035463] sd 0:0:0:0: [sdb] 142410400 512-byte logical blocks: (72.9 GB/67.9 GiB) [ 92.054186] sd 0:0:0:0: [sdb] Write Protect is off [ 92.061913] sd 0:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA [ 92.101015] sdb: sdb1 sdb2 sdb3 [ 92.607567] sd 0:0:0:0: [sdb] Attached SCSI disk Volume group debian not found Skipping volume group debian Unable to find LVM volume debian/root done. Begin: Waiting for root file system ... done. Gave up waiting for root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/mapper/debian-root does not exist. Dropping to a shell! BusyBox v1.17.1 (Debian 1:1.17.1-10) built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty; job control turned off (initramfs) Running 'vgchange -a y' at this point activates all volume groups and exiting the initramfs shell causes the boot to proceed normally. The problem can be solved by passing either 'scsi_mod.scan=sync' or 'rootdelay=20' on the command line. The rootdelay option handling is slightly counterintuitive: in /scripts/init-top/udev we will sleep for $ROOTDELAY seconds if it is set, however if rootdelay= is not specified on the command line we will not sleep here, and boot will fail. in /scripts/local ROOTDELAY is set to a default of 30 seconds if rootdelay= is not set, but sleeping here does not help, as the LVM devices will not magically appear without vgchange being called, and that's not going to happen, because /scripts/local/top have been run at this point already. There are a few options of fixing it in the generic case: 1. Make scsi_mod.scan=sync the default. The implication of this are unclear to me. 2. Try to activate the volume groups at the end of the waiting-for-root time in /scripts/local. 3. Come up with some way of asynchronous notification of volume groups being available for activation, and invoke vgchange on this notification. I clearly don't know about how LVM works internally to accomplish something like this, an udev hook, perhaps? While the bug is fairly harmless and plenty of workarounds exist, I consider fixing it desirable, as it would case a boot failure on some systems immediately after installation, and figuring out what's going on may be a bit of a challenge for the user. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611314: SunFire V120 and sym53c8xx
On Sun, Feb 20, 2011 at 02:28:42PM +, Richard Mortimer wrote: On 19/02/2011 23:20, Jurij Smakov wrote: On Sat, Feb 19, 2011 at 11:06:04PM +, Jurij Smakov wrote: On Thu, Feb 10, 2011 at 10:49:39AM +, Richard Mortimer wrote: [Cc'd to 611...@bugs.debian.org] ... I tested with your netboot image and it exhibits the same behaviour as the official installer. The sym53c8xx driver does get loaded automatically. I'm pretty sure that this is a timing issue. I confirmed that all of the /dev/sd* files were present along with /dev/disk/* entries. Ok, I think the magic happens in the disk_found() function in disk-detect.sh [0]. It looks like it will retry up to 3 times to see whether devices have showed up (with list-devices disk), sleeping 2 seconds between attempts... If it takes up to 7 seconds for driver to initialize itself, we might be cutting it just a bit too short. Unfortunately, I don't see how we can test it easily, as neither netboot image nor miniiso contain the udebs, they are downloaded off the network. Hm, if expert install mode offers an opportunity to drop to shell after udebs are downloaded, then we can probably replace the udeb containing disk-detect.sh with a modified one. Can you check whether it's possible? Yeah I can use Go Back at Set up users and passwords to get to the installer main menu and then drop to a shell. I can likely modify any scripts in place if you give me pointers to what you would like to change/test. To get things started I tried changing the number of retries from 3 to 8 with sed -i 's/1 2 3/1 2 3 4 5 6 7 8/' /bin/disk-detect Thanks, that's the confirmation I was looking for. We are going to push a patch for this to 6.0.1 as it is fairly non-controversial. This detected the disks just fine. Regards Richard -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611314: SunFire V120 and sym53c8xx (was Re: Unofficial Squeeze installer image available)
On Thu, Feb 10, 2011 at 10:49:39AM +, Richard Mortimer wrote: [Cc'd to 611...@bugs.debian.org] On 10/02/2011 08:36, Jurij Smakov wrote: On Wed, Feb 09, 2011 at 11:07:49PM +, Richard Mortimer wrote: On 09/02/2011 21:43, Jurij Smakov wrote: ... snip ... http://www.wooyd.org/debian/squeeze/ ... Sure, I have just uploaded a netboot image to the same location. If you have encountered problems during Squeeze installation, please test this image and report the results, as a positive confirmation of fixes on a variety of different systems is essential for getting all these fixes into the first Squeeze point release. I did spot a couple of issues with the installer when I gave squeeze a try a couple of weeks back. I only got chance to file an installation report about one of them http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611314 Its not a massive show stopper and has an easy workaround but if that can be fixed then it will make others lives easier. Yeah, this bug was pointed out to me just yesterday. I don't know what's going on there yet, it appears that the PCI IDs of your card match the ones which are supported by the driver, so if module is not loaded at all there is probably something wrong with udev. At a point where it says it cannot detect the disks, can you drop back to shell and see whether the driver actually isn't loaded (as opposed to being loaded but failing to find the disks anyway)? Maybe there is something relevant showing up in dmesg or /var/log/messages? If not, I'll try to come up with some udev debugging commands to try and understand why this detection is failing. I tested with your netboot image and it exhibits the same behaviour as the official installer. The sym53c8xx driver does get loaded automatically. I'm pretty sure that this is a timing issue. I confirmed that all of the /dev/sd* files were present along with /dev/disk/* entries. Ok, I think the magic happens in the disk_found() function in disk-detect.sh [0]. It looks like it will retry up to 3 times to see whether devices have showed up (with list-devices disk), sleeping 2 seconds between attempts... If it takes up to 7 seconds for driver to initialize itself, we might be cutting it just a bit too short. Unfortunately, I don't see how we can test it easily, as neither netboot image nor miniiso contain the udebs, they are downloaded off the network. [0] http://git.debian.org/?p=d-i/hw-detect.git;a=blob_plain;f=disk-detect.sh;hb=HEAD Looking at the dmesg output I can see a 7 second delay whilst the driver/scsi subsystem settles itself down. (I also see a similar issue when I boot after install with raid/lvm setup - but both rootdelay the scsi probe sync option fixes that). After dropping to the installer shell I can re-enter the Detect disks screen and it find them without problem. Regards Richard Full console output below just in case it is useful. BusyBox v1.17.1 (Debian 1:1.17.1-8) built-in shell (ash) Enter 'help' for a list of built-in commands. ~ # ~ # lsmod Module Size Used by sd_mod 31548 0 crc_t10dif 1292 1 sd_mod ata_generic 3199 0 libata147511 1 ata_generic sym53c8xx 71569 0 scsi_transport_spi 20705 1 sym53c8xx alim15x34002 0 usb_storage41983 0 scsi_mod 132037 5 sd_mod,libata,sym53c8xx,scsi_transport_spi,usb_storage ohci_hcd 18603 0 uhci_hcd 20343 0 ehci_hcd 33777 0 sungem 25663 0 usbcore 117062 5 usb_storage,ohci_hcd,uhci_hcd,ehci_hcd nls_base6649 1 usbcore sungem_phy 9430 1 sungem ~ # ~ # ls /dev block shm tty42 bsg stderr tty43 bus stdin tty44 charstdout tty45 console tty tty46 coretty0tty47 cpu_dma_latency tty1tty48 disktty10 tty49 fd tty11 tty5 fulltty12 tty50 input tty13 tty51 kmsgtty14 tty52 log tty15 tty53 loop0 tty16 tty54 mdesc tty17 tty55 mem tty18 tty56 net tty19 tty57 network_latency tty2tty58 network_throughput tty20 tty59 nulltty21 tty6 openpromtty22 tty60 porttty23 tty61 ppp tty24 tty62 psaux tty25 tty63 ptmxtty26 tty7 pts
