Re: Kernel built with CONFIG_PREEMPT_RT
Hello again, As for the RT kernel being old, here is some news : https://www.osadl.org/Single-View.111+M5acfc476362.0.html http://www.spinics.net/lists/linux-rt-users/msg06611.html It's just a remainder that the RT part is coming closer to mainline. bye .. 2011/7/11 Luis Henriques luis.hen...@gmail.com Hi, Lars Segerlund lars.segerl...@gmail.com writes: Hi, Since it's possible to configure the kernel with the CONFIG_PREEMPT_RT since 2.6.39 ... ( mainline ) , it would be supernice if there were prebuilt kernels in debian ( sid ). I just wanted to point this out and here what everyone thought about it. It would be a great boon for audio users, and for some RT tasks. / regards, Lars Segerlund. Are you sure this is available on mainline? I couldn't find any references to it. AFAIK, its available only through the -rt patch. Also, the latest official version of this patch is 2.6.33.9-rt31, so there is no support for latter kernels. Cheers, -- Luis Henriques
Re: Symbolic links to kernel image files and initial RAM file system image files
On Tue, 2011-07-19 at 19:56 -0400, Stephen Powell wrote: [...] The last time I checked, the do_symlinks = yes setting in /etc/kernel-img.conf was still honored by the maintainer scripts for official stock Debian kernel image packages; Still correct. And they also support making hard-links or copies to vmlinuz/vmlinux/initrd. [...] o Require boot loader hook scripts to either edit their configuration files or maintain the symbolic links o Provide hook scripts in some other package (base-files? initramfs-tools?) that maintain symbolic links o Eliminate symbolic links entirely and require boot loader hook scripts to edit their configuration files o Bury our heads in the sand and ignore the problem [...] Boot loaders *should not* maintain symbolic links, since that means duplicating logic (and there are probably cases where multiple boot loaders are installed and they may trip over each other). Hook scripts will just perpetuate the use of the undocumented /etc/kernel-img.conf. I would like to see these 'traditional' boot loaders provide the option to update their configuration automatically. This should be done with the aid of the new 'linux-version' command from linux-base. I have been meaning to work on this, but it's just one of a long list of tasks. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#632475: btrfs flushing hangs
Hi Chris, When my Sheevaplug's btrfs partition gets near-full (df will report 1.8 or 1.9 gigs free), the filesystem hangs. I get messages as seen below, and I can no longer read or write. This occurs with Debian's linux-image-2.6.39-2-kirkwood and 3.0.0~rc5-1~experimental.1 as well. It is consistently reproducible. Please let me know what additional information would be helpful. [ 4852.113592] device fsid 1b48baae86d0b237-51ab536c499a6594 devid 1 transid 163957 /dev/sda1 [ 5288.244963] INFO: task btrfs-transacti:2232 blocked for more than 120 seconds. [ 5288.252250] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 5288.260132] btrfs-transacti D c02e3e4c 0 2232 2 0x [ 5288.266549] [c02e3e4c] (schedule+0x4ac/0x510) from [c02e43b8] (schedule_timeout+0x1c/0x230) [ 5288.275492] [c02e43b8] (schedule_timeout+0x1c/0x230) from [bf0df564] (btrfs_commit_transaction+0x2dc/0x6ec [btrfs]) [ 5288.286568] [bf0df564] (btrfs_commit_transaction+0x2dc/0x6ec [btrfs]) from [bf0d9df8] (transaction_kthread+0x12c/0x200 [btrfs]) [ 5288.298586] [bf0d9df8] (transaction_kthread+0x12c/0x200 [btrfs]) from [c006177c] (kthread+0x84/0x8c) [ 5288.308149] [c006177c] (kthread+0x84/0x8c) from [c00315b0] (kernel_thread_exit+0x0/0x8) [ 5408.308976] INFO: task btrfs-transacti:2232 blocked for more than 120 seconds. [ 5408.316338] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 5408.324204] btrfs-transacti D c02e3e4c 0 2232 2 0x [ 5408.330642] [c02e3e4c] (schedule+0x4ac/0x510) from [c02e43b8] (schedule_timeout+0x1c/0x230) [ 5408.339655] [c02e43b8] (schedule_timeout+0x1c/0x230) from [bf0df564] (btrfs_commit_transaction+0x2dc/0x6ec [btrfs]) [ 5408.350780] [bf0df564] (btrfs_commit_transaction+0x2dc/0x6ec [btrfs]) from [bf0d9df8] (transaction_kthread+0x12c/0x200 [btrfs]) [ 5408.362807] [bf0d9df8] (transaction_kthread+0x12c/0x200 [btrfs]) from [c006177c] (kthread+0x84/0x8c) [ 5408.372359] [c006177c] (kthread+0x84/0x8c) from [c00315b0] (kernel_thread_exit+0x0/0x8) [ 5528.397412] INFO: task btrfs-transacti:2232 blocked for more than 120 seconds. [ 5528.404701] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 5528.412564] btrfs-transacti D c02e3e4c 0 2232 2 0x [ 5528.418985] [c02e3e4c] (schedule+0x4ac/0x510) from [c02e43b8] (schedule_timeout+0x1c/0x230) [ 5528.427927] [c02e43b8] (schedule_timeout+0x1c/0x230) from [bf0df564] (btrfs_commit_transaction+0x2dc/0x6ec [btrfs]) [ 5528.439004] [bf0df564] (btrfs_commit_transaction+0x2dc/0x6ec [btrfs]) from [bf0d9df8] (transaction_kthread+0x12c/0x200 [btrfs]) [ 5528.451025] [bf0d9df8] (transaction_kthread+0x12c/0x200 [btrfs]) from [c006177c] (kthread+0x84/0x8c) [ 5528.460580] [c006177c] (kthread+0x84/0x8c) from [c00315b0] (kernel_thread_exit+0x0/0x8) -- 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/20110720095128.ga1...@scru.org
Re: Symbolic links to kernel image files and initial RAM file system image files
On Wed, 20 Jul 2011 04:52:59 -0400 (EDT), Ben Hutchings wrote: Boot loaders *should not* maintain symbolic links, since that means duplicating logic (and there are probably cases where multiple boot loaders are installed and they may trip over each other). I agree that if it's going to be done it would be best to do it in one place (i.e. avoid duplicating logic). Hook scripts will just perpetuate the use of the undocumented /etc/kernel-img.conf. Hmm. I don't follow that logic. If symbolic links are maintained in hook scripts, then it makes sense to me that the user would set do_symlinks = no in /etc/kernel-img.conf to avoid duplication of effort. That's what I do. And if do_symlinks is set to no, then the settings for link_in_boot and relative_links become meaningless. And that's one more step in the direction of eliminating /etc/kernel-img.conf. To me, it's similar to setting do_bootloader = no in conjunction with providing boot loader hook scripts. Once boot loader hook scripts are provided, boot loader invocation logic can be eliminated from the kernel image package maintainer scripts, and the value of do_bootloader in /etc/kernel-img.conf can be ignored. Similarly, once symbolic links are maintained in hook scripts, the values of do_symlinks, link_in_boot, and relative_links in /etc/kernel-img.conf can also be ignored, and symbolic link maintenance logic can be eliminated from the kernel image package maintainer scripts. It's almost an exact analogy with boot loader hook scripts to my way of thinking. What I was thinking was that if the hook scripts detect pre-existing symbolic links they will maintain them, and if symbolic links don't currently exist, they won't create them. Here's what I'm currently using on my system. For /etc/kernel/postinst.d I have a hook script called zy-symlinks, available here: http://users.wowway.com/~zlinuxman/kernel/postinst.d/zy-symlinks and for /etc/kernel/postrm.d I have a similar (but not identical) hook script, also called zy-symlinks, available here: http://users.wowway.com/~zlinuxman/kernel/postrm.d/zy-symlinks That gives you some idea of what I had in mind. Note that since the name starts with zy, they will be invoked before any boot loader hook script, which must start with zz. Yet, they will be invoked after any currently-existing hook script other than a boot loader hook script. In particular, they will be invoked after initramfs-tools. That is the order in which it needs to run. I would like to see these 'traditional' boot loaders provide the option to update their configuration automatically. This should be done with the aid of the new 'linux-version' command from linux-base. I guess my working definition of traditional boot loaders means anything other than grub (either version). But keep in mind that on some architectures a traditional boot loader is all that is available. zipl is all there is for s390, for example. That's a nice idea, but there are implementation problems that come to mind. I don't know about zipl, I'll check; but I do know that lilo, for example, is limited to 15-character names in it's labels. The traditional labels, used with the symbolic links, are something like Linux and LinuxOLD, which are well within the 15-character limit. But if one attempts to auto-generate labels based on the name of the kernel, I can easily see a problem with guaranteeing uniqueness while still remaining within the 15-character limit. Also, since each boot loader has its own unique configuration file format, similar logic will need to be invented multiple times. I have been meaning to work on this, but it's just one of a long list of tasks. I didn't start this thread as criticism. As a matter of fact, I am amazed at the prolific productivity of the kernel team. I don't know how you find time to do all that you do. But I didn't want to wait until the last minute to bring up the subject. I want to give whoever needs to make changes plenty of time before the freeze to get things implemented. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/1454887986.786413.1311161961069.javamail.r...@md01.wow.synacor.com
Re: Symbolic links to kernel image files and initial RAM file system image files
On Wed, 2011-07-20 at 07:39 -0400, Stephen Powell wrote:
On Wed, 20 Jul 2011 04:52:59 -0400 (EDT), Ben Hutchings wrote:
Boot loaders *should not* maintain symbolic links, since that means
duplicating logic (and there are probably cases where multiple boot
loaders are installed and they may trip over each other).
I agree that if it's going to be done it would be best to do it
in one place (i.e. avoid duplicating logic).
Hook scripts will just perpetuate the use of the undocumented
/etc/kernel-img.conf.
Hmm. I don't follow that logic. If symbolic links are maintained
in hook scripts, then it makes sense to me that the user would set
do_symlinks = no in /etc/kernel-img.conf to avoid duplication
of effort.
If the hook scripts are in some common package then they would need to
be configured somehow.
[...]
I would like to see these 'traditional' boot loaders provide the option
to update their configuration automatically. This should be done with
the aid of the new 'linux-version' command from linux-base.
I guess my working definition of traditional boot loaders means anything
other than grub (either version). But keep in mind that on some
architectures a traditional boot loader is all that is available.
zipl is all there is for s390, for example.
That's a nice idea, but there are implementation problems
that come to mind. I don't know about zipl, I'll check; but I do know that
lilo, for example, is limited to 15-character names in it's labels. The
traditional labels, used with the symbolic links, are something like
Linux and LinuxOLD, which are well within the 15-character limit.
But if one attempts to auto-generate labels based on the name of the
kernel, I can easily see a problem with guaranteeing uniqueness while
still remaining within the 15-character limit.
The version list could then be truncated, e.g.:
#!/bin/bash
generate_entry() {
...
}
{ read new_version; read old_version; } (linux-version list |
linux-version sort --reverse)
[ -z new_version ] || generate_entry Linux $new_version
[ -z old_version ] || generate_entry LinuxOLD $old_version
Also, since each boot
loader has its own unique configuration file format, similar logic will
need to be invented multiple times.
[...]
I'm not convinced it's that complicated.
Ben.
--
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
signature.asc
Description: This is a digitally signed message part
Bug#633738: ip6_tunnel: kernel BUG at net_namespace.c:497
* dann frazier da...@dannf.org [2011-07-15 13:24:39-0600]: I'd appreciate it if you could test Arnaud's proposed fix in your configuration to help verify that no other issues remain. Applying the patch fixes the problem and the tunnel works as expected. Cheers -- Alexander Clouter .sigmonster says: You will forget that you ever knew me. -- 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/20110720201907.GY17412@chipmunk
Bug#633738: ip6_tunnel: kernel BUG at net_namespace.c:497
On Wed, Jul 20, 2011 at 09:19:07PM +0100, Alexander Clouter wrote: * dann frazier da...@dannf.org [2011-07-15 13:24:39-0600]: I'd appreciate it if you could test Arnaud's proposed fix in your configuration to help verify that no other issues remain. Applying the patch fixes the problem and the tunnel works as expected. Excellent, thanks for your testing and feedback. I'll get a fix committed shortly. -- 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/20110720210831.gg15...@dannf.org
Bug#634697: update kernel 2.6.39-2-amd64
On Tue, Jul 19, 2011 at 04:06:14PM +0200, pascal.berna...@free.fr wrote: Since the update of the kernel from 2.6.38-2 to 2.6.39-2, I cannot get my card to work. [...] With 2.6.38 kernel, the r8192se_pci.ko module activates the card. It is not present with 2.6.39: [...] pascal@ordidesfilles ~ $ find /lib/modules/2.6.38-2-amd64/ -name '*819*' /lib/modules/2.6.38-2-amd64/kernel/drivers/net/wireless/r8192se_pci.ko r8192se_pci.ko is produced by the out-of-tree rtl8192se driver made available by Realtek. Its included makefiles installed the module to that location. As this driver is not supplied in Debian kernel images, you would need to recompile/reinstall the module for use with Linux 2.6.39. lspci lists: 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10) A mac80211 driver (rtl8192se) supporting your device (PCI ID 10ec:8172) will be part of Linux 3.0. For testing purposes, packages of 3.0 release candidates are currently available in experimental; firmware-realtek (= 0.32) is also required. Geoff -- 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/20110720213840.gm3...@chmmr.gsimmons.org
Re: Kernel built with CONFIG_PREEMPT_RT
Hi, I can help to build a kernel with rt. Yerterday the rt team uploaded the patches for 3.0 rc7. http://www.kernel.org/pub/linux/kernel/projects/rt/patches-3.0-rc7-rt0.tar.gz On 20/07/11 03:06, Lars Segerlund wrote: Hello again, As for the RT kernel being old, here is some news : https://www.osadl.org/Single-View.111+M5acfc476362.0.html http://www.spinics.net/lists/linux-rt-users/msg06611.html I'll test a patch It's just a remainder that the RT part is coming closer to mainline. bye .. 2011/7/11 Luis Henriques luis.hen...@gmail.com mailto:luis.hen...@gmail.com Hi, Lars Segerlund lars.segerl...@gmail.com mailto:lars.segerl...@gmail.com writes: Hi, Since it's possible to configure the kernel with the CONFIG_PREEMPT_RT since 2.6.39 ... ( mainline ) , it would be supernice if there were prebuilt kernels in debian ( sid ). I just wanted to point this out and here what everyone thought about it. It would be a great boon for audio users, and for some RT tasks. / regards, Lars Segerlund. Are you sure this is available on mainline? I couldn't find any references to it. AFAIK, its available only through the -rt patch. Also, the latest official version of this patch is 2.6.33.9-rt31, so there is no support for latter kernels. Cheers, -- Luis Henriques -- 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/4e275b1f.5090...@gnu.org
Processed: forcibly merging 634681 633890
Processing commands for cont...@bugs.debian.org: forcemerge 634681 633890 Bug#634681: linux-image-2.6.39-2-686-pae: Usb oops with 2.6.39 (elv_put_request) Bug#633890: [linux-2.6] kernel oops while disconnecting usb cdrom Forcibly Merged 633890 634681. thanks Stopping processing here. Please contact me if you need assistance. -- 633890: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633890 634681: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634681 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13112020484817.transcr...@bugs.debian.org
Bug#634681: linux-image-2.6.39-2-686-pae: Usb oops with 2.6.39 (elv_put_request)
On Tue, 2011-07-19 at 15:08 +0300, Touko Korpela wrote:
Package: linux-2.6
Version: 2.6.39-3
This is based on stable update 2.6.39.2, which includes a backport of
commit 0a58e077eb600d1efd7e54ad9926a75a39d7f8ae ('block: add proper
state guards to __elv_next_request').
Severity: important
Plug/unplug (interface disconnected)/plug cycle with Huawei E1552 USB 3G
modem (also emulates cdrom) sometimes causes kernel oops.
Wlan was disabled at crash time.
Oops message is at end of this message.
[...]
Jul 19 14:00:31 lisko kernel: [232636.442489] BUG: unable to handle kernel
paging request at 76656463
Jul 19 14:00:31 lisko kernel: [232636.442677] IP: [c1140f25]
elv_put_request+0x5/0x11
Jul 19 14:00:31 lisko kernel: [232636.442823] *pdpt = 32ccb001 *pde =
Jul 19 14:00:31 lisko kernel: [232636.442982] Oops: [#1] SMP
Jul 19 14:00:31 lisko kernel: [232636.443074] last sysfs file:
/sys/devices/pci:00/:00:13.2/class
Jul 19 14:00:31 lisko kernel: [232636.443238] Modules linked in:
ipt_MASQUERADE xt_state ipt_REJECT xt_tcpudp iptable_filter nf_nat_h323
nf_conntrack_h323 nf_nat_pptp nf_conntrack_pptp nf_conntrack_proto_gre
nf_nat_proto_gre nf_nat_tftp nf_conntrack_tftp nf_nat_sip nf_conntrack_sip
nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp iptable_nat nf_nat
nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables ppp_deflate
zlib_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc option usb_wwan
usbserial sg sr_mod cdrom nls_utf8 nls_cp437 vfat fat bridge stp bnep rfcomm
powernow_k8 mperf cpufreq_stats cpufreq_powersave cpufreq_userspace
cpufreq_conservative fuse loop snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_intel arc4 snd_hda_codec snd_hwdep ecb snd_pcm snd_seq joydev
brcmsmac(C) mac80211 radeon uvcvideo ttm videodev media drm_kms_helper
snd_timer snd_seq_device drm snd soundcore snd_page_alloc i2c_algo_bit btusb
cfg80211 bluetooth i2c_piix4 psmouse serio_raw evdev shpchp tpm_tis tpm
battery v
Jul 19 14:00:31 lisko kernel: ideo tpm_bios samsung_laptop processor button
ac i2c_core power_supply rfkill pcspkr k10temp pci_hotplug ext4 mbcache jbd2
crc16 sd_mod usb_storage crc_t10dif uas ahci libahci libata ohci_hcd ehci_hcd
usbcore scsi_mod thermal sky2 thermal_sys [last unloaded: scsi_wait_scan]
Jul 19 14:00:31 lisko kernel: [232636.444009]
Jul 19 14:00:31 lisko kernel: [232636.444009] Pid: 9956, comm:
hald-probe-stor Tainted: GWC 2.6.39-2-686-pae #1 SAMSUNG
ELECTRONICS CO., LTD. X125 /X125
Jul 19 14:00:31 lisko kernel: [232636.444009] EIP: 0060:[c1140f25] EFLAGS:
00010006 CPU: 0
Jul 19 14:00:31 lisko kernel: [232636.444009] EIP is at
elv_put_request+0x5/0x11
Jul 19 14:00:31 lisko kernel: [232636.444009] EAX: 7665642f EBX: f763248c
ECX: 023a4800 EDX: f2ff1a2c
Jul 19 14:00:31 lisko kernel: [232636.444009] ESI: f2ff1a2c EDI: 023a4800
EBP: f71b7eec ESP: f71b7e4c
Jul 19 14:00:31 lisko kernel: [232636.444009] DS: 007b ES: 007b FS: 00d8 GS:
00e0 SS: 0068
Jul 19 14:00:31 lisko kernel: [232636.444009] Process hald-probe-stor (pid:
9956, ti=f71b6000 task=f4d445e0 task.ti=f71b6000)
Jul 19 14:00:31 lisko kernel: [232636.444009] Stack:
Jul 19 14:00:31 lisko kernel: [232636.444009] c1145633 f763248c 0246
f2ff1a2c c1145b27 f2ff1a2c 0802 f2ff1ace
Jul 19 14:00:31 lisko kernel: [232636.444009] f84f824f f73dad40 f71b7eec
f4f8a000 f71b7ed4 f84f82ae
Jul 19 14:00:31 lisko kernel: [232636.444009] f73dad40 09c4 0005
0003 0400 f4f8a000
Jul 19 14:00:31 lisko kernel: [232636.444009] Call Trace:
Jul 19 14:00:31 lisko kernel: [232636.444009] [c1145633] ?
__blk_put_request+0x76/0xa1
Jul 19 14:00:31 lisko kernel: [232636.444009] [c1145b27] ?
blk_put_request+0x1e/0x2e
Jul 19 14:00:31 lisko kernel: [232636.444009] [f84f824f] ?
scsi_execute+0xfc/0x103 [scsi_mod]
Jul 19 14:00:31 lisko kernel: [232636.444009] [f84f82ae] ?
scsi_execute_req+0x58/0x83 [scsi_mod]
Jul 19 14:00:31 lisko kernel: [232636.444009] [f84f36f9] ?
T.912+0x48/0x12c [scsi_mod]
Jul 19 14:00:31 lisko kernel: [232636.444009] [f84f382a] ?
scsi_set_medium_removal+0x4d/0x84 [scsi_mod]
Jul 19 14:00:31 lisko kernel: [232636.444009] [fa655469] ?
cdrom_release+0x163/0x1c3 [cdrom]
Jul 19 14:00:31 lisko kernel: [232636.444009] [c12b1204] ?
__mutex_lock_common+0xf0/0x13a
Jul 19 14:00:31 lisko kernel: [232636.444009] [f8766629] ?
sr_block_release+0x22/0x38 [sr_mod]
Jul 19 14:00:31 lisko kernel: [232636.444009] [c10ed5e9] ?
__blkdev_put+0x7c/0x10c
Jul 19 14:00:31 lisko kernel: [232636.444009] [c10cd743] ? fput+0xd5/0x19d
Jul 19 14:00:31 lisko kernel: [232636.444009] [c10cae2c] ?
filp_close+0x54/0x5a
Jul 19 14:00:31 lisko kernel: [232636.444009] [c10cae8a] ?
sys_close+0x58/0x85
Jul 19 14:00:31 lisko kernel: [232636.444009] [c12b721f] ?
sysenter_do_call+0x12/0x28
Jul 19
Processed: forcibly merging 634681 631187
Processing commands for cont...@bugs.debian.org: forcemerge 634681 631187 Bug#634681: linux-image-2.6.39-2-686-pae: Usb oops with 2.6.39 (elv_put_request) Bug#631187: Kernel panics when removing external hard drive Bug#633890: [linux-2.6] kernel oops while disconnecting usb cdrom Forcibly Merged 631187 633890 634681. thanks Stopping processing here. Please contact me if you need assistance. -- 631187: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631187 633890: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633890 634681: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634681 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13112024465890.transcr...@bugs.debian.org
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
On Mon, 2011-07-18 at 17:09 +0200, Paul Millar wrote: Hi Ben, Thanks for the update. On Friday 15 July 2011 16:32:41 Ben Hutchings wrote: No news. The question remains, what the cost may be to other NFS users. Certainly NFS v4.1 is not a minor change, and it adds a lot of new code to the nfs module. I guess the question is how do we go forward here? If the stumbling block is the fear of breaking something, how do we assess the risk involved against the potential benefits? One way would be to simply test it: just roll out an updated kernel to sid. This would allow people to complain if it breaks NFS support (if the code is broken then it needs to be fixed and the sooner the better). Perhaps another approach would be to provide an additional kernel package with NFS v4.1 support built-in and ask for feedback from people (either directly or perhaps via popcon). If it helps, I can provide some tests against NFS v4.1 and NFS v4.0 servers. It's really too much trouble to do that sort of thing for every feature we might consider enabling. How about we start by enabling NFSv4.1 starting with release candidates for Linux 3.1, and see what feedback we get for that? A third possibility would be to wait until other distros (e.g., RHEL) have enabled NFS v4.1 support and see if there is a corresponding increase in NFS support tickets. [...] As I said, RHEL 6 has it - but bug reports for RHEL 6 are mostly hidden. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#633961: linux images must conflict with unfixed input-utils
On Mon, 2011-07-18 at 14:29 +0300, Adrian Bunk wrote: On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote: ... This is wrong on so many levels. 1. There is no way to declare relations to 'all kernel packages'. Why not? 1. There are many different binary packages for different hardware configurations, and we add and remove them quite regularly. 2. Although the binary packages provide virtual packages, virtual packages aren't versioned. How could a package declare I need at least kernel 2.6.39? (I know that self-compiled kernels are a different story, but for kernel packages that should be possible.) It can't. The only kind of relation you can use to binary kernel packages is an exact dependency from a binary module package. [...] I suspect that the correct way to deal with this may be to build input-utils from the linux-2.6 source package and add some sort of wrapper in linux-base to select the right version (like we do for perf). Or, you change the program to check which protocol version to use at run-time. After looking a bit into it, and especially at commit ab4e0192 (Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2) in the kernel, the correct fix for input-utils is a different and quite simple one: The input kernel-userspace API might be enhanced with additional functionality in the future, but it will never change in a way that breaks the ABI. Therefore the old functionality input-utils is using will always be available, and the bug was that EVIOCGVERSION shouldn't be used to check with equality for EV_VERSION (version = 0x010001 might be a valid check for software using EVIOCGKEYCODE_V2). A patch for input-utils to remove the wrong version check is below. After that, a Breaks in all kernel images on the unfixed input-utils would be required. [...] Not going to happen. You need to fix this through a stable update. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Processed: tagging 633961
Processing commands for cont...@bugs.debian.org: tags 633961 + wontfix Bug #633961 [linux-image-2.6.39-2-amd64] linux images must conflict with unfixed input-utils Added tag(s) wontfix. thanks Stopping processing here. Please contact me if you need assistance. -- 633961: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633961 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13112036329988.transcr...@bugs.debian.org
Bug#634697: marked as done (update kernel 2.6.39-2-amd64)
Your message dated Thu, 21 Jul 2011 01:12:27 +0200 with message-id 1311203547.1041.66.camel@localhost and subject line Re: Bug#634697: update kernel 2.6.39-2-amd64 has caused the Debian Bug report #634697, regarding update kernel 2.6.39-2-amd64 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 634697: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634697 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: firmware-realtek Version: 0.32 Since the update of the kernel from 2.6.38-2 to 2.6.39-2, I cannot get my card to work. I have re-installed the package with the new kernel running. With 2.6.38 kernel, the r8192se_pci.ko module activates the card. It is not present with 2.6.39: pascal@ordidesfilles ~ $ find /lib/modules/2.6.39-2-amd64/ -name '*819*' /lib/modules/2.6.39-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192ce /lib/modules/2.6.39-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192ce/rtl8192ce.ko /lib/modules/2.6.39-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192c /lib/modules/2.6.39-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192c/rtl8192c-common.ko /lib/modules/2.6.39-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192cu /lib/modules/2.6.39-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko /lib/modules/2.6.39-2-amd64/kernel/drivers/media/video/bt819.ko /lib/modules/2.6.39-2-amd64/kernel/drivers/staging/rtl8192u /lib/modules/2.6.39-2-amd64/kernel/drivers/staging/rtl8192u/r8192u_usb.ko /lib/modules/2.6.39-2-amd64/kernel/drivers/staging/rtl8192e /lib/modules/2.6.39-2-amd64/kernel/drivers/staging/rtl8192e/r8192e_pci.ko pascal@ordidesfilles ~ $ find /lib/modules/2.6.38-2-amd64/ -name '*819*' /lib/modules/2.6.38-2-amd64/kernel/drivers/net/wireless/r8192se_pci.ko /lib/modules/2.6.38-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192ce /lib/modules/2.6.38-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192ce/rtl8192ce.ko /lib/modules/2.6.38-2-amd64/kernel/drivers/media/video/bt819.ko /lib/modules/2.6.38-2-amd64/kernel/drivers/staging/rtl8192u /lib/modules/2.6.38-2-amd64/kernel/drivers/staging/rtl8192u/r8192u_usb.ko /lib/modules/2.6.38-2-amd64/kernel/drivers/staging/rtl8192e /lib/modules/2.6.38-2-amd64/kernel/drivers/staging/rtl8192e/r8192e_pci.ko lspci lists: 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10) ---End Message--- ---BeginMessage--- On Thu, 2011-07-21 at 07:38 +1000, Geoff Simmons wrote: On Tue, Jul 19, 2011 at 04:06:14PM +0200, pascal.berna...@free.fr wrote: Since the update of the kernel from 2.6.38-2 to 2.6.39-2, I cannot get my card to work. [...] With 2.6.38 kernel, the r8192se_pci.ko module activates the card. It is not present with 2.6.39: [...] pascal@ordidesfilles ~ $ find /lib/modules/2.6.38-2-amd64/ -name '*819*' /lib/modules/2.6.38-2-amd64/kernel/drivers/net/wireless/r8192se_pci.ko r8192se_pci.ko is produced by the out-of-tree rtl8192se driver made available by Realtek. Its included makefiles installed the module to that location. As this driver is not supplied in Debian kernel images, you would need to recompile/reinstall the module for use with Linux 2.6.39. [...] Thanks, Geoff. Looks like this is not a bug. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part ---End Message---
system hangs during shutdown...
...while unmounting an NFS import.
Hi,
[Please Cc me with any replies.]
--- copied from console ---
Asking all remaining processes to terminate... done.
Currently running processes (pstree):
init-+-4*[kded4---{kded4}]
|-rc---startpar---sendsigs---pstree
|-rpc.statd
|-rpcbind
'-rsyslogd---3*[{rsyslogd}]
Killing all remaining processes... Saving random seed... done.
failed.
Stopping enhanced syslogd: rsyslogd
Unmounting remote and non-toplevel virtual filesystems...[285770.720036] nfs:
server satone not responding, still trying
[After about 20 minutes had passed I hit the power button. :( ]
---
Satone is a dual-boot laptop that just happened to have changed from DGL
serving up a user's $HOME via NFS (the only fs it exports) to Windows Vista.
I'm mentioning this fact because I don't know if it matters that the exporting
server disappeared period, or that it was replaced by a non-unix-like system
that doesn't run an NFS server.
The Unmounting remote and non-toplevel virtual filesystems message comes
from /etc/init.d/umountnfs.sh which belongs to the initscripts package,
umountnfs.sh calls on umount (from the mount package), and I'm assuming the
[285770.720036] nfs: server satone not responding, still trying message is
coming from the kernel.
So, who should get this bug? ...'cause someone needs to timeout (sooner?)
instead of hanging (or appearing to hang?) the system!
Then there is the question of why is the system even trying to umount the
import from satone when it (satone) was properly shutdown and as-such the
system should know that the imported FS is no longer around--the fstab-decode
umount $FLAGS $DIRS line in umountnfs.sh appears the culprit here, a proc-
mounts-decode or mtab-decode seems more appropriate than blindly(?) trying to
umount whatever is in fstab, assuming either of those is possible and I'm not
mistaken in assuming that unexporting a FS causes the importing host to remove
it from /proc/mounts.
- Bruce
--
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/201107201834.55679.bms...@shaw.ca
Re: Symbolic links to kernel image files and initial RAM file system image files
On Wed, 20 Jul 2011 09:25:37 -0400 (EDT), Ben Hutchings wrote:
On Wed, 2011-07-20 at 07:39 -0400 (EDT), Stephen Powell wrote:
On Wed, 20 Jul 2011 04:52:59 -0400 (EDT), Ben Hutchings wrote:
Hook scripts will just perpetuate the use of the undocumented
/etc/kernel-img.conf.
Hmm. I don't follow that logic. If symbolic links are maintained
in hook scripts, then it makes sense to me that the user would set
do_symlinks = no in /etc/kernel-img.conf to avoid duplication
of effort.
If the hook scripts are in some common package then they would need to
be configured somehow.
I must not understand something. What's to configure? Just drop them
into /etc/kernel/postinst.d and /etc/kernel/postrm.d, respectively,
and you're done. /etc/kernel-img.conf doesn't need to be touched.
You can put something into linux-base, if you want to, that issues
a warning if it finds do_symlinks = yes set in /etc/kernel-img.conf,
as you did in Squeeze for do_bootloader = yes, but you would do that
anyway, I presume, regardless of the solution implemented.
The hook scripts that I have written are boot-loader-independent,
and I presume that any hook scripts that maintain symbolic links
that end up in production will be as well.
I would like to see these 'traditional' boot loaders provide the option
to update their configuration automatically. This should be done with
the aid of the new 'linux-version' command from linux-base.
That's a nice idea, but there are implementation problems
that come to mind. I don't know about zipl, I'll check; but I do know that
lilo, for example, is limited to 15-character names in its labels.
The traditional labels, used with the symbolic links, are something like
Linux and LinuxOLD, which are well within the 15-character limit.
But if one attempts to auto-generate labels based on the name of the
kernel, I can easily see a problem with guaranteeing uniqueness while
still remaining within the 15-character limit.
The version list could then be truncated, e.g.:
#!/bin/bash
generate_entry() {
...
}
{ read new_version; read old_version; } (linux-version list |
linux-version sort --reverse)
[ -z new_version ] || generate_entry Linux $new_version
[ -z old_version ] || generate_entry LinuxOLD $old_version
...
I'm not convinced it's that complicated.
Oh, I get it now. Keep the label names the same as before, but change
the image and initrd values to point directly to file names instead
of symbolic link names. Yes, that would work. I was thinking of
trying to incorporate the kernel name into the label. Something like
2.6.39-2custom1-686-pae is too long.
But that still leaves each boot loader maintainer with the task of
coming up with his own script to automatically generate his boot
loader's configuration file with each kernel installed or removed,
allowing for invariant sections too, of course. This would be the
equivalent of the update-grub command of grub-legacy, except that
something like it would have to be created for each boot loader.
That is more work and it does involve duplication of effort, but it
can probably be done that way.
I'm OK with it either way, but I am not a package maintainer for
any boot loader. I would really like to get some participation in
this thread by boot loader maintainers. They are more of a stake
holder than I am. My interest is simply to see custom kernels
generated by make-kpkg or make deb-pkg work properly in the
Debian environment without users having to write their own hook
scripts to maintain the symbolic links. But since I've already
done that for my own purposes, I have little work to do in the
future, regardless of the implementation chosen. That is not the
case for the boot loader maintainers.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
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/139049450.806101.1311211183164.javamail.r...@md01.wow.synacor.com
Bug#633961: linux images must conflict with unfixed input-utils
On Thu, Jul 21, 2011 at 01:09:34AM +0200, Ben Hutchings wrote: On Mon, 2011-07-18 at 14:29 +0300, Adrian Bunk wrote: On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote: ... This is wrong on so many levels. 1. There is no way to declare relations to 'all kernel packages'. Why not? 1. There are many different binary packages for different hardware configurations, and we add and remove them quite regularly. 2. Although the binary packages provide virtual packages, virtual packages aren't versioned. That doesn't answer the question Why there are no versioned virtual packages. How could a package declare I need at least kernel 2.6.39? (I know that self-compiled kernels are a different story, but for kernel packages that should be possible.) It can't. The only kind of relation you can use to binary kernel packages is an exact dependency from a binary module package. [...] I suspect that the correct way to deal with this may be to build input-utils from the linux-2.6 source package and add some sort of wrapper in linux-base to select the right version (like we do for perf). Or, you change the program to check which protocol version to use at run-time. After looking a bit into it, and especially at commit ab4e0192 (Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2) in the kernel, the correct fix for input-utils is a different and quite simple one: The input kernel-userspace API might be enhanced with additional functionality in the future, but it will never change in a way that breaks the ABI. Therefore the old functionality input-utils is using will always be available, and the bug was that EVIOCGVERSION shouldn't be used to check with equality for EV_VERSION (version = 0x010001 might be a valid check for software using EVIOCGKEYCODE_V2). A patch for input-utils to remove the wrong version check is below. After that, a Breaks in all kernel images on the unfixed input-utils would be required. [...] Not going to happen. You need to fix this through a stable update. Why isn't that going to happen? That's the one proper solution in this case. Especially considering that Backports are now more or less an official part of Debian, there are many scenarios where a stable update does not solve the problem. And keep in mind that if the fix for input-utils wasn't that trivial, a stable update would not even be an option. Ben. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20110721040551.gb13...@localhost.pp.htv.fi
