Bug#710938: Packard Bell EasyNote LV need i915.invert_brightness on Linux
For the record, I reinstalled the machine in question with Ubuntu 18.04 a few days ago, and upgraded it since to 20.04, and the problem was not present there. This make me suspect this issue is fixed in kernel 5.4.0 and possible earlier versions. I am unable to test with a Debian kernel. :( -- Happy hacking Petter Reinholdtsen
Bug#916718: linux-image-4.18.0-3-amd64: Booting on Thinkpad X300 leave screen black (NULL pointer dereference in i915 drm driver)
Package: linux-image-4.18.0-3-amd64 Version: 4.18.20-2 Severity: important When booting a Thinkpad X300 with the latest kernel in testing, the screen go black shortly after grub hand over the control to the kernel, and the machine become unusable. Booting from kernel linux-image-4.17.0-1-amd64 work, luckily. I found these lines in /var/log/kern.log that seem to be relevant. Dec 17 20:11:10 thinkpadx300 kernel: [3.036115] [drm] RC6 disabled, disabling runtime PM support Dec 17 20:11:10 thinkpadx300 kernel: [3.036162] BUG: unable to handle kernel NULL pointer dereference at 0008 Dec 17 20:11:10 thinkpadx300 kernel: [3.036170] PGD 0 P4D 0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036180] Oops: [#1] SMP PTI Dec 17 20:11:10 thinkpadx300 kernel: [3.036189] CPU: 1 PID: 103 Comm: systemd-udevd Not tainted 4.18.0-3-amd64 #1 Debian 4.18.20-2 Dec 17 20:11:10 thinkpadx300 kernel: [3.036196] Hardware name: LENOVO 647815G/647815G, BIOS 7TET30WW (1.04 ) 05/07/2008 Dec 17 20:11:10 thinkpadx300 kernel: [3.036307] RIP: 0010:gen4_render_ring_flush+0x55/0xf0 [i915] Dec 17 20:11:10 thinkpadx300 kernel: [3.036313] Code: 00 be 16 00 00 00 48 89 ef e8 87 fe ff ff 48 3d 00 f0 ff ff 77 69 89 18 c7 40 04 02 40 00 7a 48 8b 55 78 48 8b 92 10 02 00 00 <48> 8b 52 08 48 c7 40 0c 00 00 00 00 83 ca 04 89 50 08 48 8d 50 14 Dec 17 20:11:10 thinkpadx300 kernel: [3.036389] RSP: 0018:ab47405c3a88 EFLAGS: 00010287 Dec 17 20:11:10 thinkpadx300 kernel: [3.036396] RAX: ab4750002000 RBX: 0202 RCX: 0001ff68 Dec 17 20:11:10 thinkpadx300 kernel: [3.036403] RDX: RSI: 01a8 RDI: 0150 Dec 17 20:11:10 thinkpadx300 kernel: [3.036410] RBP: 9bb6355a1680 R08: 0001 R09: 0020 Dec 17 20:11:10 thinkpadx300 kernel: [3.036417] R10: ab47405c3a58 R11: R12: 9bb635288000 Dec 17 20:11:10 thinkpadx300 kernel: [3.036424] R13: 9bb6723d8800 R14: R15: 9bb6355a1680 Dec 17 20:11:10 thinkpadx300 kernel: [3.036432] FS: 7f3bd80938c0() GS:9bb67d50() knlGS: Dec 17 20:11:10 thinkpadx300 kernel: [3.036441] CS: 0010 DS: ES: CR0: 80050033 Dec 17 20:11:10 thinkpadx300 kernel: [3.036447] CR2: 0008 CR3: 723b8000 CR4: 06e0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036454] Call Trace: Dec 17 20:11:10 thinkpadx300 kernel: [3.036533] i915_request_alloc+0x243/0x360 [i915] Dec 17 20:11:10 thinkpadx300 kernel: [3.036607] i915_gem_init+0x284/0x480 [i915] Dec 17 20:11:10 thinkpadx300 kernel: [3.036675] i915_driver_load+0xb22/0xef0 [i915] Dec 17 20:11:10 thinkpadx300 kernel: [3.036688] ? mutex_lock+0xe/0x30 Dec 17 20:11:10 thinkpadx300 kernel: [3.036696] ? acpi_dev_found+0x5f/0x70 Dec 17 20:11:10 thinkpadx300 kernel: [3.036705] local_pci_probe+0x42/0xa0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036713] ? pci_assign_irq+0x27/0x130 Dec 17 20:11:10 thinkpadx300 kernel: [3.036721] pci_device_probe+0x146/0x1b0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036731] driver_probe_device+0x2fa/0x470 Dec 17 20:11:10 thinkpadx300 kernel: [3.036739] __driver_attach+0xdc/0x100 Dec 17 20:11:10 thinkpadx300 kernel: [3.036746] ? driver_probe_device+0x470/0x470 Dec 17 20:11:10 thinkpadx300 kernel: [3.036753] bus_for_each_dev+0x76/0xc0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036761] ? klist_add_tail+0x3b/0x70 Dec 17 20:11:10 thinkpadx300 kernel: [3.036769] bus_add_driver+0x161/0x260 Dec 17 20:11:10 thinkpadx300 kernel: [3.036776] ? 0xc07fb000 Dec 17 20:11:10 thinkpadx300 kernel: [3.036783] driver_register+0x5b/0xe0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036790] ? 0xc07fb000 Dec 17 20:11:10 thinkpadx300 kernel: [3.036798] do_one_initcall+0x46/0x1c8 Dec 17 20:11:10 thinkpadx300 kernel: [3.036806] ? _cond_resched+0x15/0x40 Dec 17 20:11:10 thinkpadx300 kernel: [3.036814] ? kmem_cache_alloc_trace+0xb5/0x1c0 Dec 17 20:11:10 thinkpadx300 kernel: [3.036822] ? do_init_module+0x22/0x201 Dec 17 20:11:10 thinkpadx300 kernel: [3.036829] do_init_module+0x5b/0x201 Dec 17 20:11:10 thinkpadx300 kernel: [3.036837] load_module.constprop.56+0x1649/0x1d80 Dec 17 20:11:10 thinkpadx300 kernel: [3.036846] ? vfs_read+0x113/0x130 Dec 17 20:11:10 thinkpadx300 kernel: [3.036852] ? vfs_read+0x113/0x130 Dec 17 20:11:10 thinkpadx300 kernel: [3.036860] ? __do_sys_finit_module+0xe9/0x110 Dec 17 20:11:10 thinkpadx300 kernel: [3.036866] __do_sys_finit_module+0xe9/0x110 Dec 17 20:11:10 thinkpadx300 kernel: [3.036875] do_syscall_64+0x55/0x110 Dec 17 20:11:10 thinkpadx300 kernel: [3.036882] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Dec 17 20:11:10 thinkpadx300 kernel: [3.036889] RIP: 0033:0x7f3bd8afc309 Dec 17 20:11:10 thinkpadx300 kernel: [
Re: dkms: Build with an alternative like compiler rather than gcc
[Sedat Dilek] > As a workaround I have symlinked my mycompiler wrapper-script to > /usr/bin/gcc. That works. > > What is the recommended way to do this correctly? Perhaps you should use dpkg-divert to ensure your replaced gcc is not lost in a future package upgrade? The DKMS team in Debian need active members. I'm not one of them. :( -- Happy hacking Petter Reinholdtsen
Bug#877911: Please set CONFIG_BRCMFMAC_SDIO=y for WiFi on the Raspberry Pi 3
[Michael Stapelberg] > Please include CONFIG_BRCMFMAC_SDIO=y in the next upload for arm64. Having the default Debian kernel work out of the box with the WIFI card on RPi 3 would help me a lot. Is there anything technical blocking this from happening? -- Happy hacking Petter Reinholdtsen
Bug#857043: nfs-common: Can nfsstat be made to show timeouts per mount point or globally for the machine?
[Petter Reinholdtsen] > I can find a per-process NFS timeouts count in /proc/$$/mountstats: I was mistaken. This is not per process, it is shared between everyone seing the same mount points. -- Happy hacking Petter Reinholdtsen
Bug#857043: nfs-common: Can nfsstat be made to show timeouts per mount point or globally for the machine?
093 LINK: 289131 289131 0 72770368 67078392 2199 2564894 2585412 READDIR: 2924687 2924687 0 514995436 13933369380 10350 3170214 3277591 READDIRPLUS: 1646905 1646905 0 297559972 6868670432 84713 14240605 14381440 FSSTAT: 5921 5921 0 974272 994728 50 8681 9039 FSINFO: 2 2 0 232 328 0 1 1 PATHCONF: 1 1 0 116 140 0 0 0 COMMIT: 0 0 0 0 0 0 0 0 The third number in the per-op statistics lines is the timeout count per operation. But I am looking for the total for the machine / mount point, not the per process count. -- Happy hacking Petter Reinholdtsen
Bug#827340: linux: CVE-2010-5321 memory leak in videobuf on multiple calls to mmap()
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=120571 I got some more information on the #v4l IRC channel and decided to report the issue upstream while I was at it. which driver are you using ? I guess uvcvideo based on the lsmod output. uvcvideo uses videobuf2 I quickly looked at the videobuf code and the bug seems to still be present easy to fix? that I can't tell without a deeper analysis of the code it would need to be fixed in four places, as there are four memory allocator backends for videobuf moving drivers to videobuf2 would be much better especially the bttv driver and if Debian decides to disable the above 11 drivers by default until they get fixed, I won't complain although users might what is the upstream location for v4l bugs? I guess it should be reported somewhere else than in redhat and debian? perhaps it already is reported and I can't find it. there's a bugzilla instance on kernel.org https://bugzilla.kernel.org/ bugs are usually reported on the linux-media mailing list hm, http://www.gossamer-threads.com/lists/linux/kernel/852719?page=last > seem related reported upstream as https://bugzilla.kernel.org/show_bug.cgi?id=120571 > -- Happy hacking Petter Reinholdtsen
Bug#827340: linux: CVE-2010-5321 memory leak in videobuf on multiple calls to mmap()
Control: found -1 4.6.2-1 [Petter Reinholdtsen] > If I understand the issue correctly, a user with access to /dev/video > can cause the kernel to leak memory and eventually run out of memory by > doing repeated calls to mmap(). In other words, users with video group > membership can bring down the machine. I've tried to track down a way to reproduce the problem without any luck so far. I asked on #v4l to see if anyone there could help and got some more information: hi. I'm trying to figure out if CVE-2010-5321 reported via https://bugzilla.redhat.com/show_bug.cgi?id=620629 > still exist in the linux kernel, and it links to https://linuxtv.org/irc/v4l/index.php?date=2010-07-29 > for more information. But that IRC log page is empty. Anyone here know how to reproduce the problem or find the log from that day? pere: that's old the bug seems to affect videobuf only, not videobuf2 yeah. at it seem to be unsolved, but I have not been able to verify it. not all drivers have been converted to videobuf2 but if the drivers you are interested in have been, then you should be safe from that point of view my focus is tracking CVEs in Debian, to know if the issue still exist or not. https://security-tracker.debian.org/tracker/CVE-2010-5321 > show the kernel still vulnerable... I don't know I'm afraid (one more reason to get rid of videobuf) how can I tell if a driver/device uses videobuf and not videobuf2? I assume some specific hardware is needed to reproduce the problem. search for #include in the sources there's 9 of them left if I count properly via-camera, fsl-viu, bttv, cx18, tm6000, zr364xx, cx231xx, pxa_camera and omap_vout ah, and omap1_camera and timblogiw in staging so that's 11 hm, wonder if I have a PCI card supported by bttv... patches would be great :-) I am sure it would, but lack the capacity too look into that. :) pinchartl: is the description in that bug report enough for you to know how to reproduce it? I've tried writing a test program, but only got a v4l2 device and got EBUSY when calling mmap() several times there. but I suspect my test program is flawed, as I did not really quite understand the description. the redhat bug report was very short, and I suspect the details are in one of the referred bug reports, which are not available to the public. :( According to this report the issue still exist in the kernel for a small number of camera drivers, so I mark it as found in the unstable kernel too. I notice this bug is tagged upstream. Is there a bug report upstream too? I've been unable to find any. -- Happy hacking Petter Reinholdtsen
Bug#827340: linux: CVE-2010-5321 memory leak in videobuf on multiple calls to mmap()
Package: src:linux Version: 3.2.78-1 Severity: minor Tags: security In 2010 an issue with the linux kernel implementation of v4l was discovered and reported to RedHat as https://bugzilla.redhat.com/show_bug.cgi?id=620629 >. It was assigned a CVE last year in http://www.openwall.com/lists/oss-security/2015/02/08/4 > and is still unsolved as far as I can tell. If I understand the issue correctly, a user with access to /dev/video can cause the kernel to leak memory and eventually run out of memory by doing repeated calls to mmap(). In other words, users with video group membership can bring down the machine. According to https://security-tracker.debian.org/tracker/CVE-2010-5321 > the issue is present in Wheezy and onwards. It is probably present in earlier versions too. I picked the kernel version number used in wheezy for this report. I noticed this issue, as it is the oldest non-fixed CVE number reported by debsecan on my laptop, and decided it was time to track its progress in a bug report. -- Happy hacking Petter Reinholdtsen
Bug#789019: linux-image-3.16.0-4-amd64: please enable CONFIG_CFS_BANDWIDTH
[Gustavo Panizzo] > please enable CONFIG_CFS_BANDWIDTH, i need it to run cpu-limited lxc > guests I just discovered that I need it to use appfap to reduce the priority of background desktop applications, so I would very much like to get it enabled in Stable too. Is there any reason not to enable it? -- Happy hacking Petter Reinholdtsen
Bug#767064: firmware-iwlwifi: Where did iwlwifi-5000-1.ucode, iwlwifi-5000-3.ucode and iwlwifi-5000-4.ucode go?
Package: firmware-iwlwifi Version: 0.43 Severity: wishlist User: debian-...@lists.debian.org Usertags: debian-edu When installing Debian Edu Jessie on a Thinkpad X200, we provide all the firmware debs available from ftp.debian.org in /firmware/ on the ISO. Yet a question show up asking for more firmware, as the files iwlwifi-5000-1.ucode, iwlwifi-5000-3.ucode and iwlwifi-5000-4.ucode are missing. In the changelog for firmware-iwlwifi I find that iwlwifi-5000-1.ucode was added in version 0.15 to close bug #497717. I find no similar comment about the iwlwifi-5000-3.ucode and iwlwifi-5000-4.ucode files. Were they ever part of this firmware package? What happened with the iwlwifi-5000-1.ucode file? Is it possible to reinsert it, and perhaps also add the two other requested files? -- Happy hacking Peter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2fl61f4k2pq@diskless.uio.no
Bug#691427: journal commit I/O error on brand-new Thinkpad T430s ext4 on lvm on SSD
Just for the record, I believe this is a firmware bug in the Intel SSD 520 180GB disks used by Lenovo, causing the disks to lock up under heavy load. Perhaps this bug should be closed, or tagged as wontfix, or something else? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2fl38a8jvwt@diskless.uio.no
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
Here is another draft patch for hw-detect. This one is tested, and
find the missing firmware on my X200 test laptop.
This approach keep the non-functioning code and add two new
approaches, one looking at the meta information for loadmed modules,
and one parsing the dmesg output. The union from all three methods
are then presented as the list of wanted firmware.
diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh
index 60c6ff4..74db55b 100755
--- a/check-missing-firmware.sh
+++ b/check-missing-firmware.sh
@@ -61,6 +61,18 @@ nic_is_configured() {
return 1
}
+add_if_fw_missing() {
+fwfile=$1
+if [ ! -e /lib/firmware/$fwfile ] ; then
+if grep -q ^$fwfile$ $DENIED 2/dev/null; then
+ log listed in $DENIED
+continue
+fi
+files=${files:+$files }$fwfile
+modules=$module${modules:+ $modules}
+fi
+}
+
check_missing () {
upnics
@@ -117,11 +129,30 @@ check_missing () {
done
done
+# Workaround for bug #725714, the kernel and udev no longer
+# let us know via /dev/.udev/firmware-missing and
+# /run/udev/firmware-missing which firmware files the kernel
+# drivers look for. This approach will only find firmware for
+# the loaded kernel modules. Modules refusing to
+# register/load when the firmware is missing will be missed.
+for module in $(cut -d -f1 /proc/modules); do
+for fwfile in $(modinfo $module | grep ^firmware: | cut -d: -f2);
do
+log looking for firmware file $fwfile needed by $module
+add_if_fw_missing $fwfile
+done
+done
+for fwfile in $(dmesg | grep 'firmware: failed' | sed 's/.*firmware:
failed to load //' | cut -d -f1); do
+# Dummy make sure '-n $modules' test below find something
+module=kernel
+log looking for firmware file $fwfile requested by kernel
+add_if_fw_missing $fwfile
+done
+
if [ -n $modules ]; then
log missing firmware files ($files) for $modules
return 0
else
- log no missing firmware in $MISSING
+ log no missing firmware for any kernel module
return 1
fi
}
--
Happy hacking
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007135247.gp10...@ulrik.uio.no
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
Thank you for the code review. :) [Ben Hutchings] The firmware agent is never coming back, so please do remove the related code. I know and agree, but URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725714#163 asked for the non-working code to be kept to work with older kernels. I do not have any strong feelings, so I left it as it was. This belongs in the changelog not the code. Actually, as long as there are several blocks doing similar things, I believe an explanation should be close to the code to explain why. I will wonder when I return in a few years time. :) The driver name should appear at the start of the log line (after the timestamp). Use that instead of 'kernel'. Yeah, but did not find a simple way to do it, and it is not affecting the functionallity, only the user messages. Should probably be fixed in the final version. Redundant use of grep; sed can do that (sed -n 's/.../.../p'). Yeah. Indentation of the above is inconsistent with the surrounding code (4 spaces vs hard tab). It will happen before any commit is done. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141007150911.gq10...@ulrik.uio.no
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
I noticed this bug was mentioned as a regression in the Jessie
installer, and thought I should have a look at how this could be
improved from the hw-detect side.
The following patch replaces the code looking in
/dev/.udev/firmware-missing and /run/udev/firmware-missing for firmware
wanted by the kernel with code looking for firmware listed in the
meta-info of loaded modules. It will solve the problem for at least
some kernel modules, but not the class of modules refusing to load if
their firmware files are missing.
Perhaps something do use while we wait for more information from the
kernel side?
The patch is only partly tested on the command line inside d-i, and is
based on the isenkram code, but rewritten to avoid awk, as awk is not
available in d-i. I can brush it up if we decide to go in this
direction.
diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh
index 60c6ff4..77a670e 100755
--- a/check-missing-firmware.sh
+++ b/check-missing-firmware.sh
@@ -2,7 +2,6 @@
set -e
. /usr/share/debconf/confmodule
-MISSING='/dev/.udev/firmware-missing /run/udev/firmware-missing'
DENIED=/tmp/missing-firmware-denied
if [ x$1 = x-n ]; then
@@ -67,61 +66,29 @@ check_missing () {
# Give modules some time to request firmware.
sleep 1
- modules=
- files=
- for missing_dir in $MISSING
- do
- if [ ! -d $missing_dir ]; then
- log $missing_dir does not exist, skipping
- continue
- fi
- for file in $(find $missing_dir -type l); do
- # decode firmware filename as encoded by
- # udev firmware.agent
- fwfile=$(basename $file | sed -e 's#\\x2f#/#g')
-
- # strip probably nonexistant firmware subdirectory
- devpath=$(readlink $file | sed 's/\/firmware\/.*//')
- # the symlink is supposed to point to the device in /sys
- if ! echo $devpath | grep -q '^/sys/'; then
- devpath=/sys$devpath
- fi
-
- module=$(get_module $devpath)
- if [ -z $module ]; then
- log failed to determine module from $devpath
- continue
- fi
-
- rm -f $file
-
- if grep -q ^$fwfile$ $DENIED 2/dev/null; then
- continue
- fi
-
- files=$fwfile${files:+ $files}
-
- if [ $module = usbcore ]; then
- # Special case for USB bus, which puts the
- # real module information in a subdir of
- # the devpath.
- for dir in $(find $devpath -maxdepth 1
-mindepth 1 -type d); do
- module=$(get_module $dir)
- if [ -n $module ]; then
- modules=$module${modules:+
$modules}
- fi
- done
- else
- modules=$module${modules:+ $modules}
- fi
- done
- done
-
+# Workaround for bug #725714, the kernel and udev no longer
+# let us know via /dev/.udev/firmware-missing and
+# /run/udev/firmware-missing which firmware files the kernel
+# drivers look for. This approach will only find firmware for
+# the loaded kernel modules. Modules refusing to
+# register/load when the firmware is missing will be missed.
+for fwfile in $(for module in $(cut -d -f1 /proc/modules); do
modinfo $module | grep ^firmware:|cut -d: -f2; done); do
+if [ ! -e /lib/firmware/$fwfile ] ; then
+
+if grep -q ^$fwfile$ $DENIED 2/dev/null; then
+continue
+fi
+
+files=${files:+$files }$fwfile
+modules=$module${modules:+ $modules}
+fi
+done
+
if [ -n $modules ]; then
log missing firmware files ($files) for $modules
return 0
else
- log no missing firmware in $MISSING
+ log no missing firmware for any loaded kernel module
return 1
fi
}
--
Happy hacking
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2fl8ukt1fpt@diskless.uio.no
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
[Cyril Brulebois] The idea is to parse kernel logs. OK, that might work too. Is the idea to use the output from 'dmesg'? Who is implementing it? Is there a draft patch somewhere? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141006144842.gn10...@ulrik.uio.no
Bug#740491: nfs-common: fails to upgrade (action restart failed)
I had a look at this issue, and the underlying problem seem to be that rpcbind do not notice that rpc.statd was stopped, and believe the port it request is occupied by another already running process when it try to register its port when it start again. The 'status' RPC service stay in the list even after rpc.statd is stopped. I was able to work around the problem by wiping the status of rpcbind like this: service rpcbind stop ; rm /run/rpcbind/* ; service rpcbind stop But this should only be done if it is safe to restart all the RPC services, as rpcbind will forget about all of them. Check the output of 'rpcinfo -p' before and after to see which services need to be restarted and registered again with rpcbind. I have no idea why rpc.statd failed to tell rpcbind that its service was no longer active, and no idea how the changes in libtirpc since 0.2.2-5 could cause this. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2fl4n3f4lzz@diskless.uio.no
Re: Accepted nfs-utils 1:1.2.8-6 (source amd64)
[Steve Langasek] * Only start nfs-common in runlevel S; it doesn't need to be started more than once (and startpar won't actually run it more than once, anyway). Closes: #510528. Actually, the question is not if it need to be started more than once, but if it should be restarted when switching to runlevel 1, and back to runlevels 2-5. :) So all daemons started in rcS.d (which really should be named rcboot.d :) should have start symlinks in runlevels 2-5 too, to make sure runlevel 1 have a chance of working. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140224202656.gx3...@ulrik.uio.no
Bug#726398: linux: Fail to work with USB wifi dongle TP-Link TL-WN725N V2 (USB id 0bda:8179)
: I/O ports at 50a0 [size=8] Region 3: I/O ports at 50b0 [size=4] Region 4: I/O ports at 5060 [size=32] Region 5: Memory at f2538000 (32-bit, non-prefetchable) [size=2K] Capabilities: access denied Kernel driver in use: ahci 00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller [8086:1e22] (rev 04) Subsystem: Lenovo Device [17aa:21fa] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin C routed to IRQ 18 Region 0: Memory at f2534000 (64-bit, non-prefetchable) [size=256] Region 4: I/O ports at efa0 [size=32] Kernel driver in use: i801_smbus 02:00.0 System peripheral [0880]: Ricoh Co Ltd MMC/SD Host Controller [1180:e822] (rev 07) (prog-if 01) Subsystem: Lenovo Device [17aa:21fa] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at f1d0 (32-bit, non-prefetchable) [size=256] Capabilities: access denied Kernel driver in use: sdhci-pci 03:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] [8086:0085] (rev 34) Subsystem: Intel Corporation Centrino Advanced-N 6205 AGN [8086:1311] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 45 Region 0: Memory at f1c0 (64-bit, non-prefetchable) [size=8K] Capabilities: access denied Kernel driver in use: iwlwifi ** USB devices: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 014: ID 0bdb:1926 Ericsson Business Mobile Networks BV Bus 001 Device 003: ID 147e:2020 Upek Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. Bus 001 Device 005: ID 5986:02d2 Acer, Inc Bus 001 Device 012: ID 0bda:8179 Realtek Semiconductor Corp. -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-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 linux-image-3.2.0-4-amd64 depends on: ii debconf [debconf-2.0] 1.5.49 ii initramfs-tools [linux-initramfs-tool] 0.109.1 ii kmod9-3 ii linux-base 3.5 ii module-init-tools 9-3 Versions of packages linux-image-3.2.0-4-amd64 recommends: pn firmware-linux-free none Versions of packages linux-image-3.2.0-4-amd64 suggests: pn debian-kernel-handbook none ii extlinux2:4.05+dfsg-6+deb7u1 ii grub-pc 1.99-27+deb7u2 pn linux-doc-3.2 none Versions of packages linux-image-3.2.0-4-amd64 is related to: pn firmware-atherosnone pn firmware-bnx2 none pn firmware-bnx2x none pn firmware-brcm80211 none pn firmware-intelwimax none pn firmware-ipw2x00none pn firmware-ivtv none ii firmware-iwlwifi0.36+wheezy.1 pn firmware-libertas none pn firmware-linux none pn firmware-linux-nonfree none pn firmware-myricomnone pn firmware-netxen none pn firmware-qlogic none pn firmware-ralink none pn firmware-realteknone pn xen-hypervisor none -- debconf information: linux-image-3.2.0-4-amd64/postinst/depmod-error-initrd-3.2.0-4-amd64: false linux-image-3.2.0-4-amd64/prerm/removing-running-kernel-3.2.0-4-amd64: true linux-image-3.2.0-4-amd64/postinst/ignoring-ramdisk: linux-image-3.2.0-4-amd64/postinst/missing-firmware-3.2.0-4-amd64: -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fld2n6ag88@diskless.uio.no
Bug#726398: linux: Fail to work with USB wifi dongle TP-Link TL-WN725N V2 (USB id 0bda:8179)
Control: found -1 3.10.11-1 [Steve Cotton] Sorry for incorrect information. Bjørn is correct. (I guess it's better to confirm this in the BTS log than not to). Yes, I tested it on Jessie too, so I can confirm that it do not work there either. Trying to tag this in the BTS meta information. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131015152423.gr15...@ulrik.uio.no
Bug#701823: installation-report: Encrypted LVM assisted install failed on Lenovo T430s
Control: forcemerge -1 691427 I believe this is the same problem I experienced with my Thinkpad X230 with 180 GB Intel SSD disk with Lenovo firmware. As far as I can tell, the disk model with the latest Lenovo firmware is broken, and can't handle sustained writes without locking up and disappearing from the SATA bus until you power cycle it. It can happen while writing random data to the disk, but also when doing database operations or writing other stuff to the disk. It affect Windows and Linux users alike. If you never stress the disk, it will probably not fail you, so you might avoid the problem. See URL: http://people.skolelinux.org/pere/blog/The_Thinkpad_is_dead__long_live_the_Thinkpad_X230_.html , URL: http://people.skolelinux.org/pere/blog/How_to_fix_a_Thinkpad_X230_with_a_broken_180_GB_SSD_disk.html and URL: http://people.skolelinux.org/pere/blog/Intel_SSD_520_Series_180_GB_with_Lenovo_firmware_still_lock_up_from_sustained_writes.html for my story. I got a replacement disk of a different vendor/model. Btw: Filling an SSD with random data to encrypt it is going to kill performance and reduce the life time of the SSD. You might want to reconsider and not fill it with random data even if you encrypt it. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130720164417.gd21...@ulrik.uio.no
Bug#684213: e1000e interface eth0 on Thinkpad X230 disappear after suspect (add power to fix it)
Control: found -1 3.2.46-1 I got a problem with the ethernet connection on my new Thinkpad X230. Some times when taking I it out of suspend, the ethernet plug do not work. I found a similar report at SuSe[1], ArchLinux[2] and Ubuntu[3]. 1) URL: https://bugzilla.novell.com/show_bug.cgi?id=806966 2) URL: https://bbs.archlinux.org/viewtopic.php?pid=1275016 3) URL: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173157 According to the Ubuntu bug report it only trigger when running on battery (inserting the power plug fix it), and one can also fix it by running this as root: echo on /sys/devices/pci\:00/\:00\:19.0/power/control I tested and can confirm that the problem disappear when plugging in power and when running the above command as root. After looking in BTS, I believe this is the same problem as the one reported in 684213 as it involve the same kernel driver and the same workaround. The SuSe bug report have references to kernel patches that are supposed to fix this. It would be great if this problem could be fixed in Wheezy. Happy hacking Petter Reinholdtsen -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.46-1 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/minervavg-root ro quiet ** Not tainted ** Kernel log: [101250.591004] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off [101250.797494] usb 3-4: reset high-speed USB device number 8 using xhci_hcd [101250.813360] usb 3-4: device firmware changed [101250.885189] usb 1-1.4: reset full-speed USB device number 4 using ehci_hcd [101250.908989] ata5: SATA link down (SStatus 0 SControl 300) [101250.909018] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [101250.909664] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded [101250.909672] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out [101250.909921] ata1.00: supports DRM functions and may not be fully accessible [101250.910423] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded [101250.910430] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out [101250.910662] ata1.00: supports DRM functions and may not be fully accessible [101250.910725] ata1.00: configured for UDMA/133 [101250.924959] ata2: SATA link down (SStatus 0 SControl 300) [101250.978984] btusb 1-1.4:1.0: no reset_resume for driver btusb? [101250.978990] btusb 1-1.4:1.1: no reset_resume for driver btusb? [101251.048871] usb 1-1.6: reset high-speed USB device number 5 using ehci_hcd [101251.068735] sdhci-pci :02:00.0: setting latency timer to 64 [101251.228578] PM: resume of devices complete after 670.720 msecs [101251.228952] PM: Finishing wakeup. [101251.228953] Restarting tasks ... done. [101251.229847] video LNXVIDEO:00: Restoring backlight state [101251.244683] usb 3-4: USB disconnect, device number 8 [101251.245683] cdc_ncm 3-4:1.6: usb0: unregister 'cdc_ncm' usb-:00:14.0-4, CDC NCM [101251.273053] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800c87106c0 [101251.273057] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800c8710700 [101251.273059] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88009e2563c0 [101251.273061] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88009e256400 [101251.273064] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800af3552c0 [101251.273067] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800af355300 [101251.273069] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800608de800 [101251.273071] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88009e256840 [101251.273074] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88009e256880 [101251.273077] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003736a780 [101251.273079] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800b724d840 [101251.273081] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88009e2be300 [101251.273084] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 880060bcf880 [101251.273087] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800b724d180 [101251.439919] usb 3-4: new high-speed USB device number 9 using xhci_hcd [101251.456200] usb 3-4: New USB device found, idVendor=0bdb, idProduct=1927 [101251.456204] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [101251.456206] usb 3-4: Product: H5321 gw [101251.456208] usb 3-4: Manufacturer: Lenovo [101251.456210] usb 3-4: SerialNumber: D91A460A86C7C990 [101251.457297] generic-usb: probe of 0003:0BDB:1927.0003 failed with error -71
Bug#691427: journal commit I/O error on brand-new Thinkpad T430s ext4 on lvm on SSD
I just discovered that this bug seem to be reported to the kernel develoers as URL: https://bugzilla.kernel.org/show_bug.cgi?id=51861 . According to that report, the problem went away on its own. While according to URL: http://forums.lenovo.com/t5/T400-T500-and-newer-T-series/T430s-Intel-SSD-520-180GB-issue/td-p/888083/page/2 , replacing the motherboard can help. Not quite sure what to believe. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130704081949.ge26...@diskless.uio.no
Bug#710938: Packard Bell EasyNote LV need i915.invert_brightness on Linux
[Luca Capello] The above was enough to solve the same problem on an Acer Aspire V3-771G (model VA70): Great. I checked the upstream source, and your video card ID is not in the quirk list yet. Can you submit a patch to dri-devel@ to make sure a permanent fix is included upstream and solve the problem for every distribution? See URL: http://lists.freedesktop.org/archives/dri-devel/2013-June/039763.html and the thread that followed for my success story. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130626130155.ga9...@diskless.uio.no
Bug#710938: Packard Bell EasyNote LV need i915.invert_brightness on Linux
Btw, I have tried to fix my KDE problem (#711237), and the solution to this problem seem to be to disable the acpi backlight support (boot with acpi_backlight=vendor), causing the intel_backlight kernel module to take effect instead and allowing KDE to find a device it understand. But using acpi_backlight=vendor and i915.invert_brightness=1 together have the sad effect of cancelling out each other, leaving me with a black screen again. So you can only use one or the other, but not both. Does this work for your Acer Aspire V3-771G too? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130626164426.gr28...@ulrik.uio.no
Bug#710938: Packard Bell EasyNote LV need i915.invert_brightness on Linux
found 710938 3.9.5-1
tags 710938 + patch
thanks
I had a closer look at the source, and the output from lspci:
00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core
processor Graphics Controller [8086:0156] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Device [1025:0688]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SE RR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort-SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 42
Region 0: Memory at c200 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at b000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 4000 [size=64]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915
If I understand the source correctly, this is the patch relative to
the Debian linux package 3.9.5-1 needed to avoid the black screen on
the Packard Bell EasyNote LV:
--- drivers/gpu/drm/i915/intel_display.c.orig 2013-06-11 09:44:27.159941945
+0200
+++ drivers/gpu/drm/i915/intel_display.c2013-06-11 09:45:35.495938898
+0200
@@ -8786,6 +8786,9 @@
/* Acer Aspire 4736Z */
{ 0x2a42, 0x1025, 0x0260, quirk_invert_brightness },
+
+ /* Packard Bell EasyNote LV11HC */
+ { 0x0156, 0x1025, 0x0688, quirk_invert_brightness },
};
static void intel_init_quirks(struct drm_device *dev)
I am a bit unsure about the first number, but concluded after reading
the source that this is pci_dev-device for the card in question, ie
the number after 8086 in the lspci output above.
Please include it in a future version, and it would be great if it
could be applied to Wheezy too.
--
Happy hacking
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130611075143.gb31...@ulrik.uio.no
Bug#710938: Packard Bell EasyNote LV need i915.invert_brightness on Linux
[Petter Reinholdtsen] I am not sure if this is a bug in the kernel driver or some other package. After boot with i915.invert_brightness=1, kdm start and display the login screen as it should, but when I log into KDE, the screen go black again. After a while, possible about the same time the screen saver kick in, the screen is turned on again. The moment I move the mouse the screen go black again. Perhaps this is a bug in X or the screen saver and not the kernel driver? Actually, I suspect the black screen after login is a bug in KDE and not the kernel. When I login to Gnome, the screen is not turned off. I also tested the same on Ubuntu Raring, and there Gnome do not turn off the sceeen, while using Kubuntu do turn off the screen when I log in. Not quite sure what package in KDE could be the trigger for this problem. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130604212444.gn11...@ulrik.uio.no
Bug#710938: Packard Bell EasyNote LV need i915.invert_brightness on Linux
Package: src:linux Version: 3.2.41-2 Severity: important Dear Maintainer, When installing Debian Wheezy on a Packard Bell EasyNote LV laptop with the firmware (UEFI BIOS) set to legacy mode, the installation work just fine, but after boot the screen go completely black and the laptop become unusable. This problem also affect Ubuntu Raring (launchpad bug 765438). See URL: http://www.linlap.com/packard_bell_easynote_lv for the notes on installing Ubuntu on this laptop. The fix is to either set the kernel option i915.invert_brightness=1 during boot, or to create a file in /etc/ like this (as root): echo options i915 invert_brightness=1 | tee /etc/modprobe.d/i915.conf update-initramfs -u -k all URL: http://bugs.debian.org/681743 contain a similar bug report for a different laptop. According to that bug report and URL: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=4dca20efb1a9c2efefc28ad2867e5d6c3f5e1955 there is a mechanism in the Linux kernel that can be used to enable the invert_brightness=1 setting for hardware that need it. According to 'modinfo i915', this is the definition for invert_brightness: invert_brightness:Invert backlight brightness (-1 force normal, 0 machine defaults, 1 force inversion), please report PCI device ID, subsystem vendor and subsystem device ID to dri-de...@lists.freedesktop.org, if your machine needs it. It will then be included in an upcoming module version. (int) Please change the i915 module for the hardware in question, to get this laptop working out of the box with Debian Wheezy (and future versions). I've already sent an email to dri-de...@lists.freedesktop.org about this, but it is not (yet, at least) shown up on URL: http://lists.freedesktop.org/archives/dri-devel/2013-June/thread.html so far. I might have included too little detail in that email, as I am a bit unsure what kind of information they need to fix it. I hope this bug report contain everything that is needed. PS: I changed the version number of this bug from 3.2.41-2+deb7u2 to 3.2.41-2, to make sure BTS assume this bug exist in all versions of Debian. Happy hacking Petter Reinholdtsen -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.41-2+deb7u2 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/vg_system-root ro quiet i915.invert_brightness=1 ** Tainted: C (1024) * Module from drivers/staging has been loaded. ** Kernel log: [6.257272] scsi6 : SCSI emulation for PCI-Express Mass Storage devices [6.257409] rts_pstor: waiting for device to settle before scanning [6.268938] [drm] failed to retrieve link info, disabling eDP [6.398416] ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control' [6.398917] Registered led device: ath9k-phy0 [6.398926] ieee80211 phy0: Atheros AR9485 Rev:1 mem=0xc9000550, irq=17 [6.438057] ACPI: AC Adapter [AC0] (on-line) [6.530098] ACPI: Battery Slot [BAT0] (battery present) [6.540793] audit: name_count maxed, losing inode data: dev=00:06, inode=1917 [6.540798] audit: name_count maxed, losing inode data: dev=00:06, inode=1917 [6.540803] audit: name_count maxed, losing inode data: dev=00:06, inode=1917 [6.540807] audit: name_count maxed, losing inode data: dev=00:06, inode=1904 [6.540810] audit: name_count maxed, losing inode data: dev=00:06, inode=1922 [6.540813] audit: name_count maxed, losing inode data: dev=00:06, inode=1922 [6.540817] audit: name_count maxed, losing inode data: dev=00:06, inode=1922 [6.540821] audit: name_count maxed, losing inode data: dev=00:06, inode=1922 [6.540824] audit: name_count maxed, losing inode data: dev=00:06, inode=1904 [6.540829] audit: name_count maxed, losing inode data: dev=00:06, inode=1927 [6.540832] audit: name_count maxed, losing inode data: dev=00:06, inode=1927 [6.540837] audit: name_count maxed, losing inode data: dev=00:06, inode=1927 [6.540840] audit: name_count maxed, losing inode data: dev=00:06, inode=1927 [6.540844] audit: name_count maxed, losing inode data: dev=00:06, inode=1904 [6.540848] audit: name_count maxed, losing inode data: dev=00:06, inode=1932 [6.540851] audit: name_count maxed, losing inode data: dev=00:06, inode=1932 [6.540856] audit: name_count maxed, losing inode data: dev=00:06, inode=1932 [6.540859] audit: name_count maxed, losing inode data: dev=00:06, inode=1932 [6.588764] Linux media interface: v0.10 [6.591185] Linux video capture interface: v2.00 [6.597418] uvcvideo: Found UVC 1.00 device HD WebCam (1bcf:2c18) [6.603538] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off [6.606189] input: HD WebCam as /devices/pci:00/:00:1a.0/usb3/3-1/3-1.1/3-1.1:1.0/input/input6 [6.606248] usbcore: registered new interface driver uvcvideo [6.606250] USB Video Class driver
Bug#657802: nfs-kernel-server: NFSv4 kerberos mount stopped working after upgrade to 6.0.4 point release
[Andreas B. Mundt]
For kerberized NFSv4 on squeeze 6.0.4 you need:
[libdefaults]
permitted_enctypes = des-cbc-crc
allow_weak_crypto = true
This setting broke Kerberos authentication using pam_sss. I found
lines like this in the server kdc.log:
Jan 31 15:26:42 tjener.intern krb5kdc[16339](info): AS_REQ (4 etypes
{18 17 16 23}) 10.0.15.1: NEEDED_PREAUTH: pere@INTERN for
krbtgt/INTERN@INTERN, Additional pre-authentication required
I then looked up what the etypes meant, and found
URL: http://pig.made-it.com/kerberos-etypes.html mapping IDs to
names.
By adding the names for 16-18,23 to krb5.conf on the KDC I was able to
get pam_sss working again. The result looked like this:
[libdefaults]
permitted_enctypes = des-cbc-crc rc4-hmac des3-cbc-sha1-kd
aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
allow_weak_crypto = true
I'm not sure which of these etypes should be listed, nor the other
consequence of listing them like this, but thought it best to mention
it here.
Is this a good solution? Which of the etypes should one permit? Will
any of them cause problems with NFSv4 or other systems?
--
Happy hacking
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120131184126.ga13...@login1.uio.no
Bug#607356: black screen after resume HP EliteBook 8440p
[Jonathan Nieder] Sorry for the lack of reply. I assume we're too late. :) Yeah. The laptop is out of my hands. :) Do you mean that the backlight was off or dim? My memory is not to be completely trusted, but I believe the backlight was off. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120126004710.ga22...@login2.uio.no
Bug#587355: i915: X locks up when trying to play DVD on Thinkpad X40
[Jonathan Nieder] Thanks, Petter! That's good to hear. I just tested with the kernel from Squeeze, and got a crash while playing. Not quite sure if it is the same crash as earlier, as the video projector is replaced with a small flat screen at the moment, and the USB DVD player is replaced with a DVD ISO fetched over NFS. Anyway, this was the dmesg output when X hung this time. [ 612.460045] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [ 612.460064] render error detected, EIR: 0x [ 612.460098] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 895 at 894) [ 633.354247] [ cut here ] [ 633.354255] kernel BUG at /build/buildd-linux-2.6_2.6.32-38-i386-G9QRBd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/gpu/drm/i915/intel_display.c:1933! [ 633.354261] invalid opcode: [#1] SMP [ 633.354266] last sysfs file: /sys/devices/virtual/backlight/thinkpad_screen/uevent [ 633.354269] Modules linked in: nfs lockd fscache nfs_acl auth_rpcgss sunrpc acpi_cpufreq cpufreq_conservative cpufreq_powersave cpufreq_userspace cpufreq_stats sco bridge parport_pc stp ppdev rfcomm bnep l2cap crc16 lp bluetooth parport binfmt_misc uinput fuse loop snd_intel8x0m snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi pcmcia snd_seq_midi_event i915 snd_seq drm_kms_helper yenta_socket rsrc_nonstatic snd_timer drm snd_seq_device nsc_ircc pcmcia_core i2c_algo_bit snd i2c_i801 soundcore irda video ac processor psmouse pcspkr evdev button crc_ccitt i2c_core battery snd_page_alloc ipw2200 thinkpad_acpi libipw rfkill lib80211 shpchp rng_core nvram serio_raw output pci_hotplug ext3 jbd mbcache dm_mod sd_mod crc_t10dif ata_generic ata_piix sdhci_pci sdhci uhci_hcd thermal libata mmc_core thermal_sys e1000 ehci_hcd led_class scsi_mod usbcore nls_base [last unloaded: scsi_wait_scan] [ 633.354370] [ 633.354375] Pid: 1666, comm: Xorg Not tainted (2.6.32-5-686 #1) 2371H4G [ 633.354379] EIP: 0060:[f84b78fc] EFLAGS: 00013282 CPU: 0 [ 633.354400] EIP is at intel_crtc_dpms_overlay+0x31/0x42 [i915] [ 633.354404] EAX: fffb EBX: ef490cc0 ECX: EDX: 037f [ 633.354408] ESI: ef65e000 EDI: 6014 EBP: 00070180 ESP: ef679df8 [ 633.354412] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 633.354417] Process Xorg (pid: 1666, ti=ef678000 task=ef63bb80 task.ti=ef678000) [ 633.354420] Stack: [ 633.354422] f84b975a ef68c800 ef62c800 00070184 00070008 ef68c800 [ 633.354430] 0 0003 ef62c800 f84b6b94 ef62cd28 ef68c800 ef62cad4 f84b6b6c [ 633.354439] 0 f84179a1 0003 f83a92f2 ef62cab0 f84bb194 0004 ef490a20 [ 633.354448] Call Trace: [ 633.354464] [f84b975a] ? i9xx_crtc_dpms+0x181/0x264 [i915] [ 633.354479] [f84b6b94] ? intel_crtc_dpms+0x28/0xc1 [i915] [ 633.354493] [f84b6b6c] ? intel_crtc_dpms+0x0/0xc1 [i915] [ 633.354501] [f84179a1] ? drm_helper_connector_dpms+0x1d2/0x1da [drm_kms_helper] [ 633.354514] [f83a92f2] ? drm_mode_getproperty_ioctl+0x240/0x24a [drm] [ 633.354529] [f84bb194] ? intel_crt_dpms+0x0/0x72 [i915] [ 633.354541] [f83a8ff3] ? drm_mode_connector_property_set_ioctl+0xf3/0x152 [drm] [ 633.354553] [f83a05ba] ? drm_ioctl+0x244/0x2de [drm] [ 633.354564] [f83a8f00] ? drm_mode_connector_property_set_ioctl+0x0/0x152 [drm] [ 633.354574] [c10087e9] ? __switch_to_xtra+0x10c/0x173 [ 633.354580] [c1001f52] ? __switch_to+0x111/0x141 [ 633.354591] [f83a0376] ? drm_ioctl+0x0/0x2de [drm] [ 633.354599] [c10bdce0] ? vfs_ioctl+0x1c/0x5f [ 633.354604] [c10be274] ? do_vfs_ioctl+0x4aa/0x4e5 [ 633.354613] [c126d68e] ? schedule+0x78f/0x7dc [ 633.354620] [c10b3e1a] ? vfs_read+0x9b/0xd3 [ 633.354625] [c10be2f0] ? sys_ioctl+0x41/0x58 [ 633.354630] [c10030fb] ? sysenter_do_call+0x12/0x28 [ 633.354633] Code: 98 50 04 00 00 85 db 74 31 8b 03 83 c0 14 e8 df 65 db c8 89 d8 e8 35 d5 00 00 85 c0 74 11 31 d2 89 d8 e8 ae d3 00 00 85 c0 74 e8 0f 0b eb fe 8b 03 5b 83 c0 14 e9 98 63 db c8 5b c3 57 89 d7 56 [ 633.354680] EIP: [f84b78fc] intel_crtc_dpms_overlay+0x31/0x42 [i915] SS:ESP 0068:ef679df8 [ 633.354699] ---[ end trace 7dc0393898b837f7 ]--- Hm. Are there any GPU hangs, oopses, or other weird symptoms associated to that? No idea, did not have time to debug. It normally happen when I only have very little spare time to spend on getting movie playing, and the kids do not accept to wait while their father debug it. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flsjmhexzy@diskless.uio.no
Bug#587355: i915: X locks up when trying to play DVD on Thinkpad X40
[Jonathan Nieder] Hi again, Hi. Sorry for the lack of response. Real life kept me busy. Ping. Do you still have this hardware? (If life is just busy, that's fine, but if there's not much chance of making progress in the future, we'd naturally like to know.) I still have the hardware, in fact it is my DVD player, and the problem is no longer present in my daily use. I am using the kernel 2.6.35~rc6-1~experimental.1 and the crash do not happen there. I test with version 2.6.32-38 from squeeze when I get home. Now it only crashes when I enable the external VGA output while VLC is starting, which I try to remember to avoid. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flpqhw7xam@diskless.uio.no
Bug#607356: linux-image-2.6.32-5-686-bigmem: black screen after resume HP EliteBook 8440p
Package: linux-2.6 Version: 2.6.32-29 Severity: important When using suspend in KDE on a HP EliteBook 8440p laptop, the screen is almost black when resuming. This problem is not present in RHEL 6 and Ubuntu Maverik, but also found in Ubuntu Lucid. I got the laptop available for testing for a few more days, so if there is anything more information I can provide, please let me know. The kernel log below is just after boot, and not after resume. I found URL: https://bugzilla.redhat.com/show_bug.cgi?id=598162 over at RH that seem similar but is using a different video driver (mine uses intel). URL: https://bugzilla.redhat.com/show_bug.cgi?id=597141 got another display related bug for the same model. For Ubuntu, I found URL: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/570604 , which might be related. After hibernate, the machine did not come up at all. Not sure if this is the same bug or if I should report it as a separate bug. -- Package-specific info: ** Version: Linux version 2.6.32-5-686-bigmem (Debian 2.6.32-29) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Fri Dec 10 16:59:53 UTC 2010 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.32-5-686-bigmem root=/dev/mapper/vg_system-root ro quiet ** Not tainted ** Kernel log: [ 28.265835] name_count maxed, losing inode data: dev=00:07, inode=8 [ 28.265839] name_count maxed, losing inode data: dev=00:07, inode=4849 [ 28.265842] loop: module loaded [ 28.428395] Adding 5935096k swap on /dev/mapper/vg_system-swap_1. Priority:-1 extents:1 across:5935096k [ 33.509329] kjournald starting. Commit interval 5 seconds [ 33.509725] EXT3 FS on sda1, internal journal [ 33.509732] EXT3-fs: mounted filesystem with ordered data mode. [ 33.511677] kjournald starting. Commit interval 5 seconds [ 33.512124] EXT3 FS on dm-2, internal journal [ 33.512130] EXT3-fs: mounted filesystem with ordered data mode. [ 34.208106] fuse init (API version 7.13) [ 35.859886] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input15 [ 36.866010] apm: BIOS not found. [ 37.885284] Bluetooth: L2CAP ver 2.14 [ 37.885288] Bluetooth: L2CAP socket layer initialized [ 37.929099] Bluetooth: RFCOMM TTY layer initialized [ 37.929106] Bluetooth: RFCOMM socket layer initialized [ 37.929110] Bluetooth: RFCOMM ver 1.11 [ 38.024787] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 38.024792] Bluetooth: BNEP filters: protocol multicast [ 38.181512] Bridge firewalling registered [ 38.575978] Bluetooth: SCO (Voice Link) ver 0.6 [ 38.575983] Bluetooth: SCO socket layer initialized [ 39.884638] e1000e :00:19.0: irq 32 for MSI/MSI-X [ 39.940147] e1000e :00:19.0: irq 32 for MSI/MSI-X [ 39.940604] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 39.943661] iwlagn :43:00.0: firmware: requesting iwlwifi-6000-4.ucode [ 39.977784] iwlagn :43:00.0: iwlwifi-6000-4.ucode firmware file req failed: -2 [ 39.981455] iwlagn :43:00.0: firmware: requesting iwlwifi-6000-3.ucode [ 39.984385] iwlagn :43:00.0: iwlwifi-6000-3.ucode firmware file req failed: -2 [ 39.987684] iwlagn :43:00.0: firmware: requesting iwlwifi-6000-2.ucode [ 39.990604] iwlagn :43:00.0: iwlwifi-6000-2.ucode firmware file req failed: -2 [ 39.994163] iwlagn :43:00.0: firmware: requesting iwlwifi-6000-1.ucode [ 39.997131] iwlagn :43:00.0: iwlwifi-6000-1.ucode firmware file req failed: -2 [ 40.000545] iwlagn :43:00.0: Could not read microcode: -2 [ 40.261576] iwlagn :43:00.0: firmware: requesting iwlwifi-6000-4.ucode [ 40.263237] iwlagn :43:00.0: iwlwifi-6000-4.ucode firmware file req failed: -2 [ 40.264873] iwlagn :43:00.0: firmware: requesting iwlwifi-6000-3.ucode [ 40.266792] iwlagn :43:00.0: iwlwifi-6000-3.ucode firmware file req failed: -2 [ 40.268598] iwlagn :43:00.0: firmware: requesting iwlwifi-6000-2.ucode [ 40.270363] iwlagn :43:00.0: iwlwifi-6000-2.ucode firmware file req failed: -2 [ 40.272043] iwlagn :43:00.0: firmware: requesting iwlwifi-6000-1.ucode [ 40.274418] iwlagn :43:00.0: iwlwifi-6000-1.ucode firmware file req failed: -2 [ 40.276152] iwlagn :43:00.0: Could not read microcode: -2 [ 42.976088] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 42.977914] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 47.519196] lp0: using parport0 (interrupt-driven). [ 47.555109] ppdev: user-space parallel port driver [ 53.041726] eth0: no IPv6 routers present [ 59.390745] type=1305 audit(1292580497.690:30637): auid=4294967295 ses=4294967295 op=remove rule key=(null) list=4 res=1 [ 59.390754] type=1305 audit(1292580497.690:30638): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 res=1 [ 72.806339] CPUFREQ: Per core ondemand sysfs interface is deprecated - up_threshold [ 72.996660] CPU0 attaching NULL sched-domain. [ 72.99] CPU1 attaching NULL sched-domain. [ 72.996670] CPU2 attaching
Bug#598493: nfs-exports does not work after reboot
[Ben Hutchings] Except that nothing appears to provide $named yet. How strange. At least powerdns and bind should provide it. See /etc/insserv.conf*. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101017043247.gc23...@login2.uio.no
Bug#598493: nfs-exports does not work after reboot
[Oliver Joa] now it seems to work. I added the following line in /etc/init.d/nfs-kernel-server: ### BEGIN INIT INFO ... # Should-Start: bind9 ... ### END INIT INFO I believe it is better to use $named instead of bind9. To work with any local DNS service. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flocavtezl@login2.uio.no
Bug#599927: Kernel crashes when I start X on my Dell Latitude D505
reassign 599927 linux-2.6 found 599927 2.6.32-23 thanks [Ben Hutchings] This is extremely short on information. Please use reportbug. Sure. Here is the info collected by reportbug. Assume it also include the kernel log Julien asked for. This is a freshly installed Squeeze system. What more can I do to test and try to pinpoint the problem? Reassigning to the package and version suggested by reportbug. -- Package-specific info: ** Version: Linux version 2.6.32-5-686 (Debian 2.6.32-23) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-3) ) #1 SMP Sat Sep 18 02:14:45 UTC 2010 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.32-5-686 root=/dev/mapper/vg_system-root ro quiet ** Not tainted ** Kernel log: [6.334153] [drm] Initialized drm 1.1.0 20060810 [6.347300] phy0: Selected rate control algorithm 'minstrel' [6.348448] Registered led device: b43-phy0::tx [6.348603] Registered led device: b43-phy0::rx [6.348654] Registered led device: b43-phy0::radio [6.349082] Broadcom 43xx driver loaded [ Features: PMLS, Firmware-ID: FW13 ] [6.455516] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3af: clean. [6.456563] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3e0-0x4ff: clean. [6.457301] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x820-0x8ff: clean. [6.457360] pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcf7: clean. [6.457819] pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: clean. [6.499257] pci :00:02.0: PCI INT A - Link[LNKA] - GSI 11 (level, low) - IRQ 11 [6.499264] pci :00:02.0: setting latency timer to 64 [6.504554] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [6.520710] Intel ICH :00:1f.5: PCI INT B - Link[LNKB] - GSI 5 (level, low) - IRQ 5 [6.520750] Intel ICH :00:1f.5: setting latency timer to 64 [7.348031] intel8x0_measure_ac97_clock: measured 55245 usecs (2662 samples) [7.348035] intel8x0: clocking to 48000 [7.349274] Intel ICH Modem :00:1f.6: PCI INT B - Link[LNKB] - GSI 5 (level, low) - IRQ 5 [7.349291] Intel ICH Modem :00:1f.6: setting latency timer to 64 [7.452166] MC'97 1 converters and GPIO not ready (0xff00) [7.742844] EXT3 FS on dm-0, internal journal [7.838228] loop: module loaded [7.884901] fuse init (API version 7.13) [9.011457] Adding 3997688k swap on /dev/mapper/vg_system-swap_1. Priority:-1 extents:1 across:3997688k [ 14.898484] kjournald starting. Commit interval 5 seconds [ 14.898758] EXT3 FS on sda1, internal journal [ 14.898764] EXT3-fs: mounted filesystem with ordered data mode. [ 14.958830] kjournald starting. Commit interval 5 seconds [ 14.959109] EXT3 FS on dm-4, internal journal [ 14.959114] EXT3-fs: mounted filesystem with ordered data mode. [ 15.000230] kjournald starting. Commit interval 5 seconds [ 15.000494] EXT3 FS on dm-8, internal journal [ 15.000498] EXT3-fs: mounted filesystem with ordered data mode. [ 15.044450] kjournald starting. Commit interval 5 seconds [ 15.044761] EXT3 FS on dm-6, internal journal [ 15.044766] EXT3-fs: mounted filesystem with ordered data mode. [ 15.100210] kjournald starting. Commit interval 5 seconds [ 15.100503] EXT3 FS on dm-1, internal journal [ 15.100507] EXT3-fs: mounted filesystem with ordered data mode. [ 15.155516] kjournald starting. Commit interval 5 seconds [ 15.155825] EXT3 FS on dm-2, internal journal [ 15.155830] EXT3-fs: mounted filesystem with ordered data mode. [ 15.232935] kjournald starting. Commit interval 5 seconds [ 15.233167] EXT3 FS on dm-5, internal journal [ 15.233171] EXT3-fs: mounted filesystem with ordered data mode. [ 15.346647] kjournald starting. Commit interval 5 seconds [ 15.346914] EXT3 FS on dm-7, internal journal [ 15.346918] EXT3-fs: mounted filesystem with ordered data mode. [ 18.129141] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 18.132149] e100: eth0 NIC Link is Up 100 Mbps Full Duplex [ 18.132256] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 23.814261] RPC: Registered udp transport module. [ 23.814265] RPC: Registered tcp transport module. [ 23.814267] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 23.872861] Slow work thread pool: Starting up [ 23.872913] Slow work thread pool: Ready [ 23.872988] FS-Cache: Loaded [ 23.933274] FS-Cache: Netfs 'nfs' registered for caching [ 23.976484] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 28.171881] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input9 [ 28.228026] eth0: no IPv6 routers present [ 29.568061] b43 ssb0:0: firmware: requesting b43/ucode5.fw [ 29.601732] b43 ssb0:0: firmware: requesting b43-open/ucode5.fw [ 29.609602] b43-phy0 ERROR: Firmware file b43/ucode5.fw not found [ 29.609680] b43-phy0 ERROR: Firmware file b43-open/ucode5.fw not found [ 29.609742] b43-phy0 ERROR: You must go to
Bug#599927: Kernel crashes when I start X on my Dell Latitude D505
(xkbcomp) reports: Warning: Type ONE_LEVEL has 1 levels, but RALT has 2 symbols Ignoring extra symbols Errors from xkbcomp are not fatal to the X server AlpsPS/2 ALPS GlidePoint no synaptics event device found Query no Synaptics: 6003C8 (EE) AlpsPS/2 ALPS GlidePoint Unable to query/initialize Synaptics hardware. (EE) PreInit failed for input device AlpsPS/2 ALPS GlidePoint ^C r...@pxe-test0-pre:~# When I now start kdm, the login screen show up as it should. I guess the default X screen was just black, and starting kdm changed the colors to something more interesting. :) I guess the conclusion is that the kernel and intel Xorg driver in Sid work just fine. I hope the new packages make it into Squeeze. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101013124259.ge...@login1.uio.no
Bug#599927: Kernel crashes when I start X on my Dell Latitude D505
Package: linux-image-2.6.32-5-686 Version: 2.6.32-23 Severity: important The X server involved is as far as I know xserver-xorg-video-intel version 2:2.9.1-4. When I install the current Squeeze on my test laptop, a Dell Latitude D505, starting kdm kill the machine. This is what happen when I start X manually when logged in via ssh: r...@pxe-test0-pre:~# X X.Org X Server 1.7.7 Release Date: 2010-05-04 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-5-686 i686 Debian Current Operating System: Linux pxe-test0-pre.uio.no 2.6.32-5-686 #1 SMP Sat Sep 18 02:14:45 UTC 2010 i686 Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.32-5-686 root=/dev/mapper/vg_system-root ro quiet Build Date: 20 September 2010 03:40:46PM xorg-server 2:1.7.7-7 (Julien Cristau jcris...@debian.org) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Tue Oct 12 15:26:01 2010 (==) Using system config directory /usr/share/X11/xorg.conf.d (EE) open /dev/fb0: No such file or directory After this, the network connection is dead and the screen and keyboard on the laptop is black and dead. I was a similar problem with Ubuntu earlier, reported at URL: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/592682 . As the workaround for Ubuntu mentioned the file /etc/modprobe.d/i915-kms.conf and changing modeset there, I tried to change the current 'modeset=1' to 'modeset=0' and ran 'update-initramfs -u' before testing a reboot, but the problem was still there. Not quite sure what more to test. Any suggestions? I'm unable to get any kernel messages from the crash. Tried tailing /var/log/syslog over ssh, but no messages showed up. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flpqvfzg9z@login1.uio.no
Bug#587355: i915: X locks up when trying to play DVD on Thinkpad X40
[250593.976007] [c1002588] ? do_notify_resume+0x6f/0x713 [250593.976007] [c103d56c] ? do_send_sig_info+0x4f/0x59 [250593.976007] [c103d5c9] ? do_send_specific+0x53/0x6e [250593.976007] [c10b2e76] ? fsnotify_modify+0x5a/0x61 [250593.976007] [c103bf9a] ? recalc_sigpending+0xf/0x2e [250593.976007] [c103c2b2] ? sigprocmask+0x9d/0xbc [250593.976007] [c103c57c] ? sys_rt_sigprocmask+0x47/0xb5 [250593.976007] [c103c57c] ? sys_rt_sigprocmask+0x47/0xb5 [250593.976007] [c10032b4] ? work_notifysig+0x13/0x1b [250593.976007] Code: 98 58 04 00 00 85 db 74 31 8b 03 83 c0 14 e8 92 9c e4 c8 89 d8 e8 fc c9 00 00 85 c0 74 11 31 d2 89 d8 e8 75 c8 00 00 85 c0 74 e8 0f 0b eb fe 8b 03 5b 83 c0 14 e9 55 9a e4 c8 5b c3 57 89 d7 56 [250593.976007] EIP: [f8423647] intel_crtc_dpms_overlay+0x31/0x42 [i915] SS:ESP 0068:c9c93c5c [250593.976364] ---[ end trace bd6ec22bc4b9abff ]--- [250593.976367] Fixing recursive fault but reboot is needed! This was with xserver-xorg version 1:7.5+6 and xserver-xorg-video-intel version 2:2.9.1-4. As this is my video playing machine, I'll reinstall it with Lenny soon to get my DVD player back, but thought it best to report the problem before I reverted the machine into a working condition. Is there anything I should test before I do this? This is the output from 'lspci -nn': 00:00.0 Host bridge [0600]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3580] (rev 02) 00:00.1 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3584] (rev 02) 00:00.3 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3585] (rev 02) 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:02.1 Display controller [0380]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 01) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 01) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 01) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 01) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 81) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge [8086:24cc] (rev 01) 00:1f.1 IDE interface [0101]: Intel Corporation 82801DBM (ICH4-M) IDE Controller [8086:24ca] (rev 01) 00:1f.3 SMBus [0c05]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller [8086:24c3] (rev 01) 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] (rev 01) 00:1f.6 Modem [0703]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller [8086:24c6] (rev 01) 02:00.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev 8d) 02:00.1 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 13) 02:01.0 Ethernet controller [0200]: Intel Corporation 82541GI Gigabit Ethernet Controller [8086:1077] 02:02.0 Network controller [0280]: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection [8086:4220] (rev 05) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flr5js1be6@login1.uio.no
Re: linux-image-2.6-686: cold reset, the password inquiry, isnt good at all for servers head off, no monitorskeyboard. Please make sure to make everything auto
I'm not quite sure what the problem described is all about. There is not enough information provided to understand the problem. But the fsck comments make me suspect you want to change the server configuration to automatically repair file systems. See rcS(5) and the FSCKFIX option for that. Which version of the initscripts package do you have installed? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541980: redhat-cluster: Incorrect provides, dependencies and runlevels in init.d scripts
I had a closer look at the package, and here is an updated patch which should reproduce the order of the init.d scripts before dependency based boot sequencing. I've uploaded a package with this patch to the 2 day delayed queue. diff -ruN ../redhat-cluster-2.20081102/debian/changelog ../redhat-cluster-2.20081102-pere/debian/changelog --- ../redhat-cluster-2.20081102/debian/changelog 2009-09-16 20:11:35.0 +0200 +++ ../redhat-cluster-2.20081102-pere/debian/changelog 2009-09-16 21:40:42.0 +0200 @@ -1,3 +1,12 @@ +redhat-cluster (2.20081102-1.1) unstable; urgency=low + + * Non-maintainer upload to fix release goal. + * Fix init.d script provides, runlevels and dependency headers +and add code in postinst to recover from installations with +incorrect runlevels enabled (Closes: #541980). + + -- Petter Reinholdtsen p...@debian.org Wed, 16 Sep 2009 19:53:08 +0200 + redhat-cluster (2.20081102-1) unstable; urgency=medium * New upstream release version 2.03.09. diff -ruN ../redhat-cluster-2.20081102/debian/cman.init ../redhat-cluster-2.20081102-pere/debian/cman.init --- ../redhat-cluster-2.20081102/debian/cman.init 2009-09-16 20:11:35.0 +0200 +++ ../redhat-cluster-2.20081102-pere/debian/cman.init 2009-09-16 20:55:55.0 +0200 @@ -1,13 +1,13 @@ #!/bin/sh ### BEGIN INIT INFO -# Provides: cluster manager +# Provides: cman # Required-Start:$network $remote_fs # Required-Stop: $network $remote_fs -# Should-Start: $named $time $syslog ssh -# Should-Stop: $named $time $syslog ssh -# Default-Start: 2 3 4 5 -# Default-Stop: 0 1 6 +# Should-Start: $time +# Should-Stop: $time +# Default-Start: S +# Default-Stop: 0 6 # Short-Description: Starts and stops cman ### END INIT INFO diff -ruN ../redhat-cluster-2.20081102/debian/cman.postinst ../redhat-cluster-2.20081102-pere/debian/cman.postinst --- ../redhat-cluster-2.20081102/debian/cman.postinst 1970-01-01 01:00:00.0 +0100 +++ ../redhat-cluster-2.20081102-pere/debian/cman.postinst 2009-09-16 20:25:11.0 +0200 @@ -0,0 +1,14 @@ +#!/bin/sh + +set -e + +# Those using dependency based boot sequencing with sysv-rc and +# installing cman before version 2.20081102-1.1 would have wrong +# runlevel symlinks. Recover from this. +if [ $1 = configure ] dpkg --compare-versions $2 le 2.20081102-1.1 \ +[ -f /etc/rc2.d/S[0-9][0-9]cman ] [ ! -f /etc/rcS.d/S[0-9][0-9]cman ] +then +update-rc.d -f cman remove +fi + +#DEBHELPER# diff -ruN ../redhat-cluster-2.20081102/debian/gfs-tools.init ../redhat-cluster-2.20081102-pere/debian/gfs-tools.init --- ../redhat-cluster-2.20081102/debian/gfs-tools.init 2009-09-16 20:11:35.0 +0200 +++ ../redhat-cluster-2.20081102-pere/debian/gfs-tools.init 2009-09-16 21:02:23.0 +0200 @@ -1,11 +1,13 @@ #!/bin/sh ### BEGIN INIT INFO -# Provides: global filesystem -# Required-Start:cman -# Required-Stop: cman -# Default-Start: 2 3 4 5 -# Default-Stop: 0 1 6 +# Provides: gfs-tools +# Required-Start:$network $remote_fs +# Required-Stop: $network $remote_fs +# Should-Start: cman gnbd-server gnbd-client +# Should-Stop: cman gnbd-server gnbd-client +# Default-Start: S +# Default-Stop: 0 6 # Short-Description: mount and unmount GFS shares ### END INIT INFO diff -ruN ../redhat-cluster-2.20081102/debian/gfs-tools.postinst ../redhat-cluster-2.20081102-pere/debian/gfs-tools.postinst --- ../redhat-cluster-2.20081102/debian/gfs-tools.postinst 1970-01-01 01:00:00.0 +0100 +++ ../redhat-cluster-2.20081102-pere/debian/gfs-tools.postinst 2009-09-16 20:32:19.0 +0200 @@ -0,0 +1,14 @@ +#!/bin/sh + +set -e + +# Those using dependency based boot sequencing with sysv-rc and +# installing gfs-tools before version 2.20081102-1.1 would have wrong +# runlevel symlinks. Recover from this. +if [ $1 = configure ] dpkg --compare-versions $2 le 2.20081102-1.1 \ +[ -f /etc/rc2.d/S[0-9][0-9]gfs-tools ] [ ! -f /etc/rcS.d/S[0-9][0-9]gfs-tools ] +then +update-rc.d -f gfs-tools remove +fi + +#DEBHELPER# diff -ruN ../redhat-cluster-2.20081102/debian/gfs2-tools.init ../redhat-cluster-2.20081102-pere/debian/gfs2-tools.init --- ../redhat-cluster-2.20081102/debian/gfs2-tools.init 2009-09-16 20:11:35.0 +0200 +++ ../redhat-cluster-2.20081102-pere/debian/gfs2-tools.init2009-09-16 21:07:55.0 +0200 @@ -1,11 +1,13 @@ #!/bin/sh ### BEGIN INIT INFO -# Provides: global filesystem version 2 -# Required-Start:cman -# Required-Stop: cman -# Default-Start: 2 3 4 5 -# Default-Stop: 0 1 6 +# Provides: gfs2-tools +# Required-Start:$network $remote_fs +# Required-Stop: $network $remote_fs +# Should-Start: cman gnbd-server gnbd-client gfs-tools +# Should-Stop: cman gnbd-server gnbd-client gfs-tools +# Default-Start: S +# Default-Stop: 0 6
Bug#541980: redhat-cluster: Incorrect provides, dependencies and runlevels in init.d scripts
Any hope of having a fix for this issue uploaded soon? Should I NMU to fix it? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541980: redhat-cluster: Incorrect provides, dependencies and runlevels in init.d scripts
:$network -# Required-Stop: $network -# Default-Start: 2 3 4 5 -# Default-Stop: 0 1 6 +# Provides: gnbd-server +# Required-Start:$remote_fs $network +# Required-Stop: $remote_fs $network +# Default-Start: S +# Default-Stop: 0 6 # Short-Description: start and stop the gnbd server ### END INIT INFO diff -ru redhat-cluster-2.20081102/debian/rgmanager.init redhat-cluster-2.20081102-pere/debian/rgmanager.init --- redhat-cluster-2.20081102/debian/rgmanager.init 2009-08-17 07:35:15.0 +0200 +++ redhat-cluster-2.20081102-pere/debian/rgmanager.init2009-08-17 07:40:28.0 +0200 @@ -1,13 +1,13 @@ #!/bin/sh ### BEGIN INIT INFO -# Provides: cluster service manager -# Required-Start:cman -# Required-Stop: cman +# Provides: rgmanager +# Required-Start:$remote_fs cman +# Required-Stop: $remote_fs cman # Should-Start: clvm gfs-tools gfs2-tools # Should-Stop: clvm gfs-tools gfs2-tools -# Default-Start: 2 3 4 5 -# Default-Stop: 0 1 6 +# Default-Start: S +# Default-Stop: 0 6 # Short-Description: start and stop the cluster service manager ### END INIT INFO Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#441327: unionfs: NFS kernel crashes when loaded during boot
Package: unionfs-modules-2.6.18-5-486 Version: 2.6.18+1.4+debian-7+etch3 Severity: important When trying to set up a NFS server using the live-helper scripts (Debian Edu Main-Server), the DVD boots just fine, but the NFS server do not start. There is a kernel OOPS related to unionfs when it starts. This is the messages that seem related in /var/log/syslog: Sep 8 14:34:11 debian kernel: Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). Sep 8 14:34:12 debian kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 0094 Sep 8 14:34:12 debian kernel: printing eip: Sep 8 14:34:12 debian kernel: cd0c28fe Sep 8 14:34:12 debian kernel: *pde = Sep 8 14:34:12 debian kernel: Oops: [#1] Sep 8 14:34:12 debian kernel: Modules linked in: nfsd exportfs lockd nfs_acl sunrpc ppdev lp button ac battery autofs4 cpufreq_userspace cpufreq_stats freq_table cpufreq_powersave cpufreq_ondemand cpufreq_conservative ipv6 dm_snapshot dm_mirror dm_mod fuse tsdev floppy parport_pc psmouse parport serio_raw i2c_piix4 pcspkr i2c_core evdev squashfs loop unionfs nls_iso8859_1 isofs ide_cd cdrom ne2k_pci 8390 piix generic ide_core thermal processor fan vga16fb vgastate Sep 8 14:34:12 debian kernel: CPU:0 Sep 8 14:34:12 debian kernel: EIP:0060:[cd0c28fe]Not tainted VLI Sep 8 14:34:12 debian kernel: EFLAGS: 0202 (2.6.18-5-486 #1) Sep 8 14:34:12 debian kernel: EIP is at unionfs_file_revalidate+0x522/0x866 [unionfs] Sep 8 14:34:12 debian kernel: eax: ebx: c162022c ecx: edx: cc0b5360 Sep 8 14:34:12 debian kernel: esi: caa6c614 edi: 1000 ebp: c09c6000 esp: c09c7f4c Sep 8 14:34:12 debian kernel: ds: 007b es: 007b ss: 0068 Sep 8 14:34:12 debian kernel: Process exportfs (pid: 4759, ti=c09c6000 task=c03dcab0 task.ti=c09c6000) Sep 8 14:34:12 debian kernel: Stack: 0001 caa075c0 cbf6200d cc02f000 caa6c614 c9c20790 0001 Sep 8 14:34:12 debian kernel:cd0c2fae 0001 cc02f000 0008 caa075c0 cbf1fe40 1000 c09c6000 Sep 8 14:34:12 debian kernel:cd0c2fce cbf1fe40 08050538 caa075c0 cbf1fe40 1000 c09c6000 c0147553 Sep 8 14:34:12 debian kernel: Call Trace: Sep 8 14:34:12 debian kernel: [cd0c2fae] unionfs_file_release+0x18b/0x195 [unionfs] Sep 8 14:34:12 debian kernel: [cd0c2fce] unionfs_flush+0x16/0xd4 [unionfs] Sep 8 14:34:12 debian kernel: [c0147553] filp_close+0x2f/0x54 Sep 8 14:34:12 debian kernel: [c0102a47] syscall_call+0x7/0xb Sep 8 14:34:12 debian kernel: Code: 10 8b 46 4c 8b 90 48 01 00 00 89 c8 c1 e0 04 03 42 18 f6 40 0c 02 0f 84 c6 02 00 00 8d 04 8d 00 00 00 00 03 43 24 8b 00 8b 40 08 8b 80 94 00 00 00 f6 40 30 01 0f 85 a7 02 00 00 e9 87 02 00 00 Sep 8 14:34:12 debian kernel: EIP: [cd0c28fe] unionfs_file_revalidate+0x522/0x866 [unionfs] SS:ESP 0068:c09c7f4c I've already added the fsid=42 flag to /etc/exports, but that did not solve the problem. It did solve part of the problem, though, as it is now possible to start the NFS server after the boot (manually). But during the boot, it refuses to start properly. The live image with the problem is available from URL:http://ftp.skolelinux.no/cd-etch-live/ (the edulive-Main-Server+Thin-Client-Server images). if you want to test it. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#383248: Suggestion about usplash-themes
[Daniel Baumann] Are there now any news about uploading the new usplash upstream version of ubuntu to debian? I believe that decision to Maximilian. If a new usplash version is uploaded, a new version of debian-edu-artwork need to be uploaded as well. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mount _netdev
[Patrick Donker] Is this a bug or is there a Grand Plan^© behind the way Deb did it? Will it ever work? It is ment to be fixed in initscripts version 2.86.ds1-16. Is it not working for you, or are you using an older version? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386349: usplash: Should include init.d dependency information
Package: usplash Version: 0.3e The usplash init.d script is missing dependency information. After a quick look at the script, I suspect this would be correct: ### BEGIN INIT INFO # Provides: usplash # Required-Start:$all # Required-Stop: $all # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 ### END INIT INFO Please include it at the top of the script. More info on the format is available from URL:http://wiki.debian.org/LSBInitScripts. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383248: usplash: Please add a default debian splash theme
I believe it is a bad idea to mix mechanism and policy, or in the case of usplash to mix the splash screen implementation with the artwork using it. I would recommend a separate package with some nice debian artwork, instead of including it as part of the usplash package. For debian-edu, I have made an debian-edu-artwork package with an usplash image (still ugly, but we are working on fixing that. :). I suggest some debian-artwork package is created to include an usplash image, instead of adding it to the usplash package itself. This way it is easy for all custom debian distros and users to select with theme to install by selecting the artwork package they want to use. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Avoid running update-initramfs more than once during installation
When installing debian-edu-artwork-usplash, the initrd is updated twice, once in the usplash postinst, and once in the debian-edu-artwork-usplash postinst. This seem like a waste of time to me. Could it be possible to rewrite initramfs-tools to make sure the initrd is only generated once, at the end of the install? One idea is to make two commands, update-initramfs-intent and update-initramfs-delayed, where the former register the packages intent to run update-initramfs in their config script, and the last package to call the latter will do the updating in their postinst script. The code of the programs will look something like this: update-initramfs-intent #!/bin/sh package=$1 statefile=/var/lib/initramfs-tools/intendtoupdateinitrd echo $package $statefile update-initramfs-delayed #!/bin/sh package=$1 statefile=/var/lib/initramfs-tools/intendtoupdateinitrd grep -v ^$package\$ $statefile $statefile.new mv $statefile.new $statefile if [ -s $state ] ; then # Not empty, more packages left : else # Last package, run command update-initramfs fi When the statefile is empty, all packages who registered their intend have executed update-initramfs-delayed, and it is time to run update-initramfs. I suspect this might speed up the installation quite a bit if there are several packages adding hooks to initramfs. The existing packages will continue to work, while packages moving to this new approach need to add update-initramfs-intent packagename to their config script, and replace update-initramfs with update-initramfs-intent packagename in their postinst script. Is there any reason why this can't be done? Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Avoid running update-initramfs more than once during installation
[Maximilian Attems] agreed, but that is an dpkg bug not having a do this last and once hook. I know there is a long-term request for dpkg to get such support. But I've seen no indication that such support is approaching soon, so I believe it is best to solve this problem for update-initramfs right now, like the dictionaries-common solution for the dictionary packages, instead of not doing anything while we hope for some generic solution in dpkg. NACK, that seems to fragile, i would really prefer to get that bug fixed in dpkg than having such a workaround in initramfs-tools. How is it fragile? The only problem I see is if packages run the -intent script without running the -delayed script. That should be easy to detect and fix, perhaps using a lintian check. Perhaps there is something to learn from the dictionaries-common package? I have not checked how they do it, but know the dictionary packages only ask the user once to select language, after all the language packages are installed. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381104: usplash: 15 second timeout is sometimes not enough
Package: usplash Version: 0.3a Severity: minor At the moment, usplash have a 15 second timeout. If no command is sent to usplash for 15 seconds, it terminates and return to the text console. When using usplash in qemu on my laptop, it sometimse take more than 15 seconds between such commands during boot, and the splash screen disappears. Would it be an idea to increase the timeout, or perhaps make it configurable? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380752: usplash: Make it possible to use the default font in external themes
Package: usplash
Version: 0.3a
Tags: patch
At the moment, usplash themes need to include their own font in the
.so file. It would be useful to have a way to use the default font.
This patch make it possible, by setting the 'font' struct member to
NULL. It is tested and found to be working.
--- usplash.c.orig 2006-08-01 08:14:02.0 +0200
+++ usplash.c 2006-08-01 12:14:29.0 +0200
@@ -63,6 +63,9 @@
/* Default theme, used when no suitable alternative can be found */
extern struct usplash_theme testcard_theme;
+/* Font structure built-in to bogl */
+extern struct bogl_font font_helvB10;
+
/* Theme being used */
static struct usplash_theme *theme;
@@ -129,6 +132,9 @@
if ((theme == NULL) || (theme-version != THEME_VERSION)) {
dlclose (theme_handle);
theme = testcard_theme;
+
+ if (NULL == theme-font)
+ theme-font = font_helvB10;
}
} else {
theme = testcard_theme;
Please include the patch in a future version of usplash.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380745: usplash: Make it easier to backport to sarge
Package: usplash Version: 0.3a Severity: wishlist Tags: patch When building usplash on Debian/Sarge, dpkg complains DEB_BUILD_ARCH_CPU is not a supported variable name at /usr/bin/dpkg-architecture line 271. This patch fixes the issue, by using DEB_BUILD_ARCH instead of DEB_BUILD_ARCH_CPU. --- bogl/Makefile.orig 2006-06-20 12:11:12.0 +0200 +++ bogl/Makefile 2006-08-01 12:05:02.0 +0200 @@ -8,7 +8,7 @@ WARNCFLAGS += -Wall -D_GNU_SOURCE ALLCFLAGS = $(CFLAGS) $(WARNCFLAGS) $(FBCFLAGS) -architecture := $(shell dpkg-architecture -qDEB_BUILD_ARCH_CPU) +architecture := $(shell dpkg-architecture -qDEB_BUILD_ARCH) LIBOBJECTS = $(LIBBOGLOBJECTS) $(LIBBOMLOBJECTS) $(LIBBOWLOBJECTS) \ $(LIBRSRCOBJECTS) Please apply it to a future version of usplash. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380750: usplash: Make it possible to use the default font in external themes
Package: usplash Version: 0.3a Severity: important When building usplash themes, the usplash-theme.h header file need to be available to know the layout of the usplash_theme struct. Please provide it in some binary debian package, perhaps usplash-dev or similar. At the moment I build my theme by copying the file into the theme source package, but this will lead to problems when the theme version changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381009: usplash: Should run during the entire shutdown sequence
Package: usplash Version: 0.3a Tags: patch When doing shutdown on a machine using usplash, the usplash process isn't started at the begining of runlevel 6. It is started by sendsigs halfway throught the shutdown instead. I'm not sure how ubuntu starts usplash during their shutdown process (could be useful to check out), but one way that work is to modify the init.d script to start usplash in the 'stop' target. The start and stop behaviour for usplash seem to be the wrong way, but because sysv-rc runs start scripts after stop scripts, it need to use a S-type symlink in rc2.d to stop usplash, and a K-type symlink in rc6.d to start it. This patch make sure the K-type symlink in rc6.d and rc1.d starts usplash. --- debian/usplash.init.orig2006-06-20 12:11:13.0 +0200 +++ debian/usplash.init 2006-08-01 14:48:36.0 +0200 @@ -68,6 +68,7 @@ usplash_quit ;; stop) + usplash -c usplash_write TEXT Resetting the usplash timeout... usplash_write TIMEOUT 15 usplash_write SUCCESS ok -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357980: initramfs-tools: Should include cpqarray module by default?
Package: initramfs-tools
Version: 0.53c
Severity: important
Tags: patch
I just upgraded a Compaq ProLiant DL360 with Debian/etch to use the
2.6.15-1-686-smp kernel, and ran into a problem in the process. The
RAID controller module, cpqarray, was not included in the initrd by
default, and the boot failed as the root file system was missing.
I managed to work around the problem by adding it to
/etc/mkinitramfs/modules, but believe it is better to make sure the
kernel module is installed by default to get it working out of the box
on this hardware.
I tried running update-initramfs with the -v option to get some info
on the kernel modules included by default, but it was rather silent.
Perhaps it should report the list of kernel modules included in the
initrd? This was all the output I got:
# update-initramfs -k 2.6.15-1-686-smp -u -v
Generating /boot/initrd.img-2.6.15-1-686-smp
#
Here is a patch to add the cpqarray module to the list of SCSI modules
to load.
--- /usr/share/initramfs-tools/hook-functions.orig 2006-02-27
10:50:38.0 +0100
+++ /usr/share/initramfs-tools/hook-functions 2006-03-20 17:03:50.0
+0100
@@ -153,7 +153,7 @@
done
;;
scsi)
- for x in 3w-9xxx 3w- a100u2x aacraid advansys ahci aic79xx
aic7xxx ata_piix atari_scsi atp870u BusLogic cciss ch dc395x dmx3191d dpt_i2o
eata fdomain ibmvscsic initio ipr ips isp1020 lpfc max_scsi mac53c94 megaraid
megaraid_mbox megaraid_mm mesh mptfc mptscsih mptsas mptspi nsp32 osst qla1280
qla2100 qla2200 qla2300 qla2322 qla2xxx qla6312 qlogicfas408 qlogicfc
sata_promise sata_nv sata_qstor sata_sil sata_sis sata_svw sata_sx4 sata_uli
sata_via sata_vsc scsi_mod scsi_transport_fc scsi_transport_iscsi
scsi_transport_spi sd_mod sym53c8xx tmscsim; do
+ for x in 3w-9xxx 3w- a100u2x aacraid advansys ahci aic79xx
aic7xxx ata_piix atari_scsi atp870u BusLogic cciss ch dc395x dmx3191d dpt_i2o
eata fdomain ibmvscsic initio ipr ips isp1020 lpfc max_scsi mac53c94 megaraid
megaraid_mbox megaraid_mm mesh mptfc mptscsih mptsas mptspi nsp32 osst qla1280
qla2100 qla2200 qla2300 qla2322 qla2xxx qla6312 qlogicfas408 qlogicfc
sata_promise sata_nv sata_qstor sata_sil sata_sis sata_svw sata_sx4 sata_uli
sata_via sata_vsc scsi_mod scsi_transport_fc scsi_transport_iscsi
scsi_transport_spi sd_mod sym53c8xx tmscsim cpqarray; do
manual_add_modules ${x}
done
;;
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298000: kernel-image-2.6.8-2-686: airo driver fail to work with AIRONET Wireless Communications PC4800 (rev 01) [PCI 14b9:0350]
I just upgraded the kernel on the machine in question to the kernel found at URL:ftp://ftp.skolelinux.no/debian/pool/main/l/linux-2.6/linux-image-2.6.12-1-686_2.6.12-2_i386.deb, and the airo driver worked there too. :) Please consider upgrading the kernel in debian/stable (sarge) to a newer kernel where where this airo driver work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298000: kernel-image-2.6.8-2-686: airo driver fail to work with AIRONET Wireless Communications PC4800 (rev 01) [PCI 14b9:0350]
I just tested using kernel package kernel-image-2.6.11-1-686_2.6.11-5_i386.deb from URL:ftp://ftp.skolelinux.no/debian/pool/main/k/kernel-image-2.6.11-i386/ on the machine in question, and this kernel worked with the wifi card in my machine. Great! :) I guess this can be considered a request to upgrade the kernel in sarge to a version supporting my wifi card. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
[Sven Luther] the problem is not the reject, is the no news in weeks and no communication channel open. But again, i think and hope that this will become better now. I agree. Complete silence and no feedback is a real problem when it happen, and only worse if it is an official debian role failing to communicate. But I believe things are improving a lot when it comes to the ftpmaster role, and have great hopes that Jeroen is part of the solution. :) Maybe, if one would reply to all mails you send out, one wouldn't have time for ANY other Debian work. No-one is asking anyone to reply to the wast flod of emails coming from Sven the last few days. But emails sent to the official debian role ftpmaster should get some kind of response. Well, sending email to a discussion forum like debian-devel, and sending email to a debian-role like ftp-master is not comparable, and i think it shows a profund lack of responsability on your part even suggesting this. I believe Joroen tried to express that mistakes do happen, and that the ftpmasters can delete email by mistake when their mailbox is filling up. Perhaps this could be solved with some kind of ticket system handling email to the official roles in debian? I'm not sure if BTS is the best option to handle emails to ftpmaster, leader and others. Perhaps request-tracker is a better option? We use it at work, and it seem to do request handling quite well (at least when we added the email administration interface. :). What surprises me is the energy and hostality Matthew Wilcox demonstrates by attacking you in later private emails. A good thing he isn't part of the ftpmaster team (as far as I can see). The ftpmasters seem to have a professional attitude towards the role they have in the project. I wish we could expect that from all the participants in the project. (But you are right, Sven. No-one should have to accept abuse for the work one does as a volunteer in the Debian project. That applies for both you, the ftpmasters, the release managers, all the debian developers and the users. Those unable to behave sivilised against their fellow volunteers should be ashamed of themselves.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
[Petter Reinholdtsen] in later private emails. This was a misunderstanding on my part, due to the fact that I received the replies from Sven before I received the replies from Matthew. The fact that the replies were done on public lists and not in private email do not change how I react to their content. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
[Sven Luther] No, he is not, as far as i am concerned, unless he presents his apologies first. For what? Commenting on your wast amount of email posted the last few days, and his suggestion that the amount of email could make the ftpmasters delete mails by mistake? I can not really believe that is your problem, so please enlighten me. No, that is not acceptable, and probably not the right reason for this. Until evidence proves otherwise, it is just because they don't care to read those emails, and that that email address is simply forwarded to /dev/null. I didn't say it was acceptable. I tried to put it in perspective. I'm well aware of at least some of the communication issues with the ftpmasters, but truly believe these problems are because the ftpmasters are overworked, not because they are evil. And I believe this even though one of the ftpmasters told me on IRC to stop wasting his time when I wanted to discuss making the list of packages in NEW public. I put it on the account of misjudgement during stress, not evil will. I suspect you would be better off if you accepted that misjudgement and mistakes happen also for the ftpmasters. After all, your emails haven't been the perfect examples of rational and clear speek either (though not as hostile as others on the list. :). I do not hold that against you, and wish you didn't hold such miscommunications and and misjudgements against the other volunteers in Debian. That would be a solution. But then are the ftp-masters ready to get the problems they receive publicly visible ? I didn't propose to make it all public. request-tracker is capable of fine grained access control. No, a professional attitude would have them reply to the people they are working with. Again, I agree that the ftpmaster role should reply to all requests. But if the volunteers filling this role are very busy, it does not help to shout at them and send even more email. A different solution must be found, and I hope and believe we are on our way to a solution to the problems the project is facing. but this have become the norm these past couple month, and Steve's 'proposal' was the last straw. I guess I do not read the proposal the way you read it. I read it as a document describing the problems the release team and the ftpmaster experiences with the release process, and their ideas on how to improve the situation. But first and formost, I read the proposal as a good step forward for the release of sarge. After all, the ideas for reorganizing the process for etch wasn't the most important part of the vancouver announcement. The most important part was that the release managers and the ftpmasters are coordinated in their work to release Sarge. Since the meeting 189 packages have been processed from the NEW queue. I believe this is the result of the meeting, where the ftpmasters was able to meet with prospective ftpmaster assistant. I also believe the increased effort to release sarge is a result of this meeting. Well, this email is already getting fairly long. Enough hot air from me this time, I believe. I am truly sorry for loosing you. You have done a good job helping Debian progress the state of free software, and it is sad that you decide to throw in the towel because of hard language from a fellow Debian volunteer. :( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298000: kernel-image-2.6.8-2-686: airo driver fail to work with AIRONET Wireless Communications PC4800 (rev 01) [PCI 14b9:0350]
I tested with a 2.6.10 kernel from sid, kernel-image-2.6.10-1-686_2.6.10-4_i386.deb, to see if the airo driver worked any better with that version. This didn't help at all. The network was still broken, so I had to go back to the 2.4 kernel again. So, this problem exist in 2.6.10 too. Should the bug be reassigned? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298000: kernel-image-2.6.8-2-686: airo driver fail to work with AIRONET Wireless Communications PC4800 (rev 01) [PCI 14b9:0350]
Package: kernel-image-2.6.8-2-686 Version: 2.6.8-13 Severity: important I recently tried to upgrade the kernel of one of my machines from 2.4.27 to 2.6.8. Most of the upgrade when fine, but the network card in the machine didn't work with the new kernel. The machine have several network cards, but the one in use is a WLAN card (PCI). discover recognized it and loaded the airo module for it, and the airo module recognized the card and claimed everything was just fine. These are the relevant lspci (-n) lines: :00:0e.0 Network controller: AIRONET Wireless Communications PC4800 (rev 01) :00:0e.0 0280: 14b9:0350 (rev 01) But, when dhclient tried to get an IP address, no replies from the DHCP server was detected. The stats from ifconfig reported lots of 'misc' errors on the TX line, but no pakcages transmitted. When the module was loaded, these messages were reported to syslog: kernel: PCI: Setting latency timer of device :00:0e.0 to 64 kernel: airo: cmd= 111 kernel: airo: status= 7f11 kernel: airo: Rsp0= 2 kernel: airo: Rsp1= 0 kernel: airo: Rsp2= 0 kernel: airo: Doing fast bap_reads kernel: airo: MAC enabled eth0 0:40:96:3a:64:bb kernel: airo: Finished probing for PCI adapters After trying several times to rmmod and modprobe the airo module, and running dhclient on the interface, the kernel started to send out lots of messages like this: kernel: airo: Bad size 58569 kernel: airo: Bad size 6106 kernel: airo: Bad size 26500 kernel: airo: Bad size 58570 kernel: airo: Bad size 6107 kernel: airo: Bad size 58571 kernel: airo: Bad size 58572 In between, it sent a few messages like this: kernel: airo: BAP error 4000 0 At this point, I decided to reboot back to the 2.4 kernel. How can I get the 2.6 kernel working with this PCI card? Without a working network driver for the WLAN card, I can't use the machine, so I have to stick with the 2.4 kernel for now. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kernel-image-2.6.8-2-686 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities ii initrd-tools 0.1.77 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: irc meeting regarding kernel status d-i RC3
[Matthew Wilcox] I will not subject myself to the whims of Rob Levin. Why do you believe others are interested in your conflict with some (to me at least) unknown person Rob Levin? If you wanted to be constructive, you might have suggested an alternative network, and provided some explanation of the positive features of this alternative network. It would have made me at least view your email in a better light. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
