Bug#779931: [Pkg-utopia-maintainers] Bug#779931: Bug#779931: sk_disk_check_sleep_mode: Operation not supported for USB3 HDD docking based on JMicron 152d:0551
On Sun, 29 Mar 2015 05:40:47 +0200 Michael Biebl bi...@debian.org wrote: Am 29.03.2015 um 05:31 schrieb Michael Gilbert: control: severity -1 important On Mon, Mar 9, 2015 at 10:07 AM, Gianluca Oglietti wrote: If the problem is the kernel, can you suggest me a way to debug this issue? Try starting a discussion on the linux kernel mailing list (lkml.org) or bugzilla (bugzilla.kernel.org). Another alternative might be a buggy USB controller in the docking station. It's hard to tell. JMicron USB controllers are in fact notoriously buggy. I have the same problem with id 152d:0539, and i had to blacklist it in libatasmart/atasmart.c disk_find_type(). / C -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784874: Fwd: Bug#784874: mdadm --re-add Segmentation Fault
The raid was a degraded raid 6 array of 5 disks with one missing disk, so only one parity disk, [_] in /proc/mdstat There was a malfunction in the hard drive enclosure so that it momentarily lost contact with the 4 active disks, and then /proc/mdstat said [_], meaning no disks at all. I'm not sure if --re-add is supposed to work in this scenario, however --stop and --assemble worked fine. Thank you for your help! / C On Thu, May 14, 2015 at 8:07 AM, NeilBrown ne...@suse.de wrote: On Wed, 13 May 2015 11:22:47 +0200 Christoffer Hammarström christoffer.hammarst...@linuxgods.com wrote: Yes, i'm sorry, i thoughtlessly ran mdadm --stop /dev/md/storage before reporting the bug. Well that explains some of it. I'd really like to know what the state of the array was when mdadm crashed - that code path should hardly ever be reached. Anyway, the fix is at: http://git.neil.brown.name/?p=mdadm.git;a=commitdiff;h=2609f339028a6035a3fadb1190b565438000e35c in case the Debian maintainer wants to pick it up. Thanks for the report. NeilBrown I managed to reassemble the raid later with --assemble. / C
Bug#784874: Fwd: Bug#784874: mdadm --re-add Segmentation Fault
Yes, i'm sorry, i thoughtlessly ran mdadm --stop /dev/md/storage before reporting the bug. I managed to reassemble the raid later with --assemble. / C
Bug#784874: mdadm --re-add Segmentation Fault
Package: mdadm
Version: 3.3.2-5
Severity: normal
I was trying to re-add some disks to a RAID, and mdadm crashed with a
segmentation fault.
So i rebuilt mdadm with DEB_BUILD_OPTIONS=nostrip and backtraced the core dump
in gdb, which yielded the following output:
# gdb mdadm core
GNU gdb (Debian 7.9-1) 7.9
...
For help, type help.
Type apropos word to search for commands related to word...
Reading symbols from mdadm...done.
[New LWP 28013]
Core was generated by `mdadm --manage /dev/md/storage --re-add /dev/sdg
/dev/sdh /dev/sdi /dev/sdj'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 avail_size1 (st=0x11dc960, devsize=7814037168, data_offset=1) at
super1.c:1966
1966if (__le32_to_cpu(super-feature_map)MD_FEATURE_BITMAP_OFFSET)
{
(gdb) bt
#0 avail_size1 (st=0x11dc960, devsize=7814037168, data_offset=1) at
super1.c:1966
#1 0x004130de in Manage_add (fd=3, tfd=5, dv=0x11d9040, tst=0x11dc960,
array=0x7ffe80631230, force=optimized out, verbose=0, devname=0x7ffe80633344
/dev/md/storage,
update=0x0, rdev=2144, array_size=7813774336) at Manage.c:798
#2 0x00414ae8 in Manage_subdevs (devname=0x11dc960 \300\362g, fd=3,
devlist=0x11d9040, verbose=-1745019929, test=1920, update=0x0, force=0) at
Manage.c:1496
#3 0x004067d0 in main (argc=0, argv=0x7ffe80631b01) at mdadm.c:1311
-- Package-specific info:
--- mdadm.conf
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST system
MAILADDR christoffer.hammarst...@example.com
ARRAY /dev/md0 metadata=1.2 UUID=cff59daa:79b96c84:81ccdee1:7f285430
name=castle:0
ARRAY /dev/md/127_0 metadata=0.90 UUID=330fd1c3:84792c10:ca3448ee:fb2f679d
ARRAY /dev/md/minaret:1 metadata=1.2 name=minaret:1
UUID=56e54e7c:0b15f6b9:01ad7ab6:d6662cd8
--- /etc/default/mdadm
INITRDSTART='/dev/md0'
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS=--syslog
VERBOSE=false
--- /proc/mdstat:
Personalities : [raid1] [raid6] [raid5] [raid4]
md1 : active raid1 sdd[1] sdc[0]
3906887488 blocks super 1.2 [2/2] [UU]
bitmap: 0/30 pages [0KB], 65536KB chunk
md127 : active raid1 sde[0] sdf[1]
1953514496 blocks [2/2] [UU]
md0 : active raid1 sdb1[1] sda1[0]
976629760 blocks super 1.2 [2/2] [UU]
unused devices: none
--- /proc/partitions:
major minor #blocks name
1101048575 sr0
8 16 976762584 sdb
8 17 976760832 sdb1
80 976762584 sda
81 976760832 sda1
90 976629760 md0
2590 960052401 md0p1
2591 1 md0p2
2592 16571016 md0p5
8 32 3907018584 sdc
8 80 1953514584 sdf
8 64 1953514584 sde
8 48 3907018584 sdd
9 127 1953514496 md127
91 3906887488 md1
8 96 3907018584 sdg
8 112 3907018584 sdh
8 128 3907018584 sdi
8 144 3907018584 sdj
--- LVM physical volumes:
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1009236,mode=755)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=1618704k,mode=755)
/dev/md0p1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup
(rw,nosuid,nodev,noexec,relatime,perf_event)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=21,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
sysfs on /var/chroot/jessie-32bit/sys type sysfs (rw,relatime)
proc on /var/chroot/jessie-32bit/proc type
Bug#440607: closed by Boris Pek tehnic...@yandex.ru (Re:, RFP: steam-powered -- Valve's steam game content delivery system)
Hi! I am nobody really, but i disagree that this bug should be closed. I have been running Windows games through Steam in Wine for several years. I think that until the Linux Steam client supports running all the Windows games that aren't available on Linux (e.g. through Wine), i believe it is useful to have the Windows Steam client side by side with the Linux Steam client. Kind regards, / Christoffer Hammarström -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#354105: /etc/init.d/xprint sets ulimit -n 1024
Drew Parsons wrote: I think you've now successfully arranged your system so that your default user limit is 8192, correct? You've now set /etc/security/limits.conf to provide that. So when you login, ulimit -n already shows 8192, and your ant build is good to go, correct? Did you make the change to /etc/security/limits.conf *after* you had switched Xprint off? What I expect then is that you can reinstate Xprint, let it run with its lower limit of 1024, but when you log in to your own account, you should still be seeing the same 8192 limit that you see now without Xprt running. Xprt's lower file limit should not be affecting any of your other processes, which should run with the 8192 you've given them in /etc/security/limits.conf. The causality I'm expecting is that your ant build now runs because you changed /etc/security/limits.conf, *not* because you switched Xprt off. Can you confirm this causality? D'oh! You're (of course) perfectly correct! I've now reinstated xprint, and i still have my 8192 ulimit. I feel really stupid now. I'm honestly terribly sorry for wasting so much of your time on this matter. Many thanks for your patience. Christoffer Hammarström [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Bug#354105: /etc/init.d/xprint sets ulimit -n 1024
Package: xprint Version: 1:0.1.0.alpha1-13 Severity: critical Justification: breaks unrelated software /etc/init.d/xprint sets ulimit -n 1024. This makes other programs break with too many open files, but more importantly, i can't set a higher ulimit in bash: $ ulimit -n 8192 -bash: ulimit: open files: cannot modify limit: Operation not permitted My workaround was to update-rc.d -f xprint remove since i don't need printing anyway. -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (700, 'stable'), (600, 'testing'), (550, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-k8-smp Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Versions of packages xprint depends on: ii libc6 2.3.5-13 GNU C Library: Shared libraries an ii libice66.9.0.dfsg.1-4Inter-Client Exchange library ii libsm6 6.9.0.dfsg.1-4X Window System Session Management ii libx11-6 6.9.0.dfsg.1-4X Window System protocol client li ii libxau66.9.0.dfsg.1-4X Authentication library ii libxaw76.9.0.dfsg.1-4X Athena widget set library ii libxext6 6.9.0.dfsg.1-4X Window System miscellaneous exte ii libxmu64.3.0.dfsg.1-14sarge1 X Window System miscellaneous util ii libxp6 6.9.0.dfsg.1-4X Window System printing extension ii libxpm46.9.0.dfsg.1-4X pixmap library ii libxt6 6.9.0.dfsg.1-4X Toolkit Intrinsics ii xprint-common 1:0.1.0.alpha1-13 Xprint - the X11 print system (con ii zlib1g 1:1.2.3-9 compression library - runtime xprint recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354105: /etc/init.d/xprint sets ulimit -n 1024
Drew Parsons wrote: I'm not sure that I can see what the problem is. ulimit -n 8192 does not run even when Xprt is not running, the limit it can be set to is -n 512, though higher values can be set as su. As far as I can tell this behaviour is system controlled somewhere, not related to Xprt. Can you really run ulimit -n 8192 after having removed xprint? Yes, i can. This is because i've added the following lines to /etc/security/limits.conf: *softnofile 8192 *hardnofile 32768 I'm sorry for not stating this earlier. I can now do this: [EMAIL PROTECTED]:~$ ulimit -n 8192 [EMAIL PROTECTED]:~$ ulimit -n 8192 Furthermore as far as I can tell 1024 is a standard ulimit for -n, at least it's reported as such by default from the bash command line (ulimit -a). As far other programs breaking, can you be more specific which ones? How much memory does your system have? The first time i discovered it i was running an ant compile of my java software project with many other terminals open on the desktop. I opened some more terminals, and then the build failed even earlier. Now after setting the ulimit higher, i can build again. My memory right now looks like: $ free -m total used free sharedbuffers cached Mem: 2008924 1083 0 42532 -/+ buffers/cache:348 1659 Swap: 3812 0 3812 Also, i'm not sure if it's the right way to get the number of open files, but here you go: # lsof 2/dev/null|wc -l 3471 If you want to sustain this bug, you'll need to convince me that Xprt is causing tangible problems. How much system resources is it using? What exactly is happening when your other programs break. What is Xprt's open file usage? Measure it with lsof | grep Xprt | wc and compare with the total lsof | wc. The problem is not Xprt or xprint itself, but that the ulimit is set too low for my daily usage, in /etc/init.d/xinit I'm unable to change it, and the values set in /etc/security/limits.conf are ignored. It sets both the hard and the soft limit (it should be enough to set the soft limit, right?) without first checking if the hard and the soft limit are not set higher already. Thank you for your attention. Christoffer Hammarström [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Bug#354105: /etc/init.d/xprint sets ulimit -n 1024
Drew Parsons wrote: On Thu, 2006-02-23 at 14:57 +0100, Christoffer Hammarström wrote: Can you really run ulimit -n 8192 after having removed xprint? Yes, i can. This is because i've added the following lines to /etc/security/limits.conf: *softnofile 8192 *hardnofile 32768 I'm sorry for not stating this earlier. OK, but then... The problem is not Xprt or xprint itself, but that the ulimit is set too low for my daily usage, in /etc/init.d/xinit I'm unable to change it, and the values set in /etc/security/limits.conf are ignored. This doesn't make sense. If you can change /etc/security/limits.conf (i.e. you do have superuser rights) than why can't you likewise change the value in /etc/init.d/xprint to suit your needs ? I'm sorry, i misspoke. What i actually meant is that of course i can change it as root, but i should not have to. It should be enough to set it in /etc/security/limits.conf. Suppose that i did not have superuser rights, and asked some admin to increase my ulimit? He would edit /etc/security/limits.conf appropriately, but this would be hard-overridden the next time /etc/init.d/xprint is executed, for example during boot. The problem is that /etc/init.d/xprint hard-overrides whatever setting is in /etc/security/limits.conf Can you explain what led you to believe Xprt was the cause of the problem? Xprt's use of ulimit -n 1024 should affect it, and it alone, not other processes. I do *not* believe Xprt is the problem. I'm no longer running it. I disabled it to work around this problem, as i don't need printing anyway. To reiterate, i *do* believe the problem is that the script /etc/rc.d/xprint hard-overrides whatever value is set in /etc/security/limits.conf. How about only setting the ulimit to 1024 if it's lower than 1024? I want to contribute something useful to this discussion :) I believe something like the following patch should fix the problem: --- xprint 2006-02-23 16:11:11.0 +0100 +++ xprint.new 2006-02-23 16:11:43.0 +0100 @@ -202,7 +202,7 @@ umask 022 # Bump limit for per-process open files to ensure that Xprt can open many many fonts -ulimit -n 1024 +((`ulimit -n` 1024)) ulimit -n 1024 Thank you for your attention and patience. Christoffer Hammarström [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Bug#354105: /etc/init.d/xprint sets ulimit -n 1024
Drew Parsons wrote: It sounds like your ant build is the real problem. You need the default ulimit -n to be 1024 for everything else, but increase it only for the shell running the build. I forgot to mention, after /etc/init.d/xprint sets ulimit -n 1024, i *cannot* increase the ulimit without superuser rights, since ulimit -n 1024 sets the *hard* limit as well as the soft limit. Thank you for your attention, Christoffer Hammarström [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Bug#350129: uqm: Segfaults on startup just after showing the window.
Joey Hess wrote: Also, it's quite possible that this is an amd64 specific problem, so I also suggest you try running the i386 version on your machine. It's apparently a 64 bit problem. It's bug 252 in the uqm bugzilla: http://uqm.stack.nl/cgi-bin/bugs/show_bug.cgi?id=252 signature.asc Description: OpenPGP digital signature
Bug#350129: uqm: Segfaults on startup just after showing the window.
Package: uqm Version: 0.3-3 Severity: important Segfaults on startup with the following output: The Ur-Quan Masters v0.3 (compiled Apr 11 2005 02:28:09) This software comes with ABSOLUTELY NO WARRANTY; for details see the included 'COPYING' file. Saved games are kept in /home/kreiger/.uqm/save/. Initializing SDL (pure). SDL driver used: x11 SDL initialized. Initializing Screen. Set the resolution to: 640x480x32 Initializing SDL audio subsystem. ALSA lib timer_hw.c:269:(snd_timer_hw_open) extended read is not supported (SNDRV_TIMER_IOCTL_TREAD) SDL audio subsystem initialized. Initializing MixSDL mixer. MixSDL using driver 'SDL_audio' ALSA lib timer_hw.c:269:(snd_timer_hw_open) extended read is not supported (SNDRV_TIMER_IOCTL_TREAD) MixSDL Mixer initialized. opened alsa at 44100 Hz 16 bit stereo, 4096 samples audio buffer Initializing sound decoders. Sound decoders initialized. 0 joysticks were found. 'lbm/title.ani' -- 19 bytes /usr/games/uqm: line 3: 17347 Segmentation fault /usr/lib/games/uqm/uqm --contentdir=/usr/share/games/uqm/content $@ -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-amd64-generic Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Versions of packages uqm depends on: ii libc6 2.3.5-12 GNU C Library: Shared libraries an ii libsdl-image1.2 1.2.4-1image loading library for Simple D ii libsdl1.2debian 1.2.9-0.1 Simple DirectMedia Layer ii libvorbis0a 1.1.0-1The Vorbis General Audio Compressi ii libvorbisfile31.1.0-1The Vorbis General Audio Compressi ii uqm-content 0.3-1 The Ur-Quan Masters - Game data fi ii xlibmesa-gl [libgl1] 6.9.0.dfsg.1-4 Mesa 3D graphics library [X.Org] ii zlib1g1:1.2.3-9 compression library - runtime Versions of packages uqm recommends: pn uqm-music none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
