Bug#695492: CIFS mount hangs after not using it for a while
Seems like the same problem here. Linux guest (VirtualBox) trying to access a Windows share (on host, Windows 7). # cat /proc/10254/stack [c121e547] wait_for_response.isra.5+0x97/0xf0 [c121f41b] SendReceive+0xeb/0x240 [c1202ff5] CIFSSMBNegotiate+0x155/0x6e0 [c1224945] cifs_negotiate+0x15/0x60 [c120e98c] cifs_negotiate_protocol+0x5c/0xb0 [c1202c0c] cifs_reconnect_tcon+0x14c/0x270 [c1202d4f] smb_init+0x1f/0x80 [c12070bc] CIFSSMBQPathInfo+0x3c/0x220 [c12248de] cifs_query_path_info+0x3e/0x90 [c1219524] cifs_get_inode_info+0x1d4/0x4f0 [c121af85] cifs_revalidate_dentry_attr+0xa5/0x1a0 [c121b12c] cifs_getattr+0x4c/0x120 [c1109daf] vfs_getattr+0x3f/0x70 [c1109e34] vfs_fstatat+0x54/0x90 [c1109eab] vfs_stat+0x1b/0x20 [c110a211] sys_stat64+0x11/0x30 [c170b4fa] sysenter_do_call+0x12/0x22 [] 0x = ls on previously working share. Kernel log: [ 1099.860691] CIFS VFS: Server server has not responded in 120 seconds. Reconnecting... # cat /proc/fs/cifs/DebugData Display Internal CIFS Data Structures for Debugging --- CIFS Version 2.0 Features: Active VFS Requests: 1 Servers: 1) Name: 10.0.2.2 Domain: domain Uses: 1 OS: Windows 7 Professional 7601 Service Pack 1 NOS: Windows 7 Professional 6.1 Capability: 0x1e3fc SMB session status: 1 TCP status: 4 Local Users To Server: 1 SecMode: 0x3 Req On Wire: 1 Shares: 1) \\server\cc_latest$ Mounts: 1 Type: NTFS DevInfo: 0x20 Attributes: 0xc700ff PathComponentMax: 255 Status: 0x1 type: DISKDISCONNECTED MIDs: State: 2 com: 114 pid: 10254 cbdata: de598500 mid 8 # mount //server/cc_latest$ on /home/flo/dev/cc_latest type cifs (rw,nosuid,nodev,relatime,vers=1.0,sec=ntlm,cache=none,unc=\\server\cc_latest$,username=flo,uid=1000,forceuid,gid=1000,forcegid,addr=10.0.2.2,file_mode=0755,dir_mode=0755,nounix,rsize=61440,wsize=65536,actimeo=1) Share is connected using this entry from /etc/fstab: //server/cc_latest$ /home/flo/dev/cc_latest cifs user,noauto,username=flo,nounix,noserverino,sec=ntlm,cache=none 0 0 (cache=none seems to be irrelevant for the issue to reproduce) Linux kernel is v3.8 from experimental running on wheezy. # dpkg -p linux-source-3.8 Package: linux-source-3.8 Priority: optional Section: kernel Installed-Size: 81955 Maintainer: Debian Kernel Team debian-kernel@lists.debian.org Architecture: all Multi-Arch: foreign Source: linux Version: 3.8.5-1~experimental.1 # lsmod Module Size Used by none Same issue occurs for the stable kernel from wheezy: # dpkg -p linux-image-3.2.0-4-686-pae Package: linux-image-3.2.0-4-686-pae Priority: optional Section: kernel Installed-Size: 80201 Maintainer: Debian Kernel Team debian-kernel@lists.debian.org Architecture: i386 Source: linux Version: 3.2.41-2 I can easily reproduce the problem by not making use of the share for some time. Please let me know if you need other info. (BTW, the problem didn't occur for linux-2.6 on squeeze). Florian -- 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/fcfcf8a3ad9ebe021bd61d0ea5aed20d-EhVcXl5HQwdXRwQRAQkKVxcwfgFLV15YQUBGAEFbXEk3XVgWXVtwH1ZXQ1xcLkQBWVNaSF1TXQg=-webmail...@server04.webmailer.hosteurope.de
Bug#708965: grub-config was needed
On Fri, 2013-05-24 at 06:06 +0200, nobswolf wrote: Am 21.05.2013 02:54, schrieb Ben Hutchings: A kernel installation should run update-grub anyway, so running that only 'solves the problem' until the next security update that doesn't get properly installed. For some reason in file /etc/kernel-img.conf the entry do_bootloader was set to no. I guess this was set by the initial installation as I can not remember having fiddled with such settings. This was actually the correct setting for a system using GRUB, and is now ignored. All boot loaders are updated by scripts installed under /etc/kernel. Have you moved the /boot partition on this system in the last year or so? (The kernel you were running, Debian version 2.6.32-41, dates from January 2012.) No. The harddisks and the partitions have not changed since the installation. Do you remember which release you originally installed? Assuming you're using GRUB 2, what does 'debsums -a grub-pc' say? Lots of lines, all ending with OK: http://pastebin.com/7RmqPBwa Do you have a separate /boot partition, and is there a /boot/boot/grub directory? Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
Bug#709616: floods the network with pause packets
Package: src:linux Version: 3.8.13-1 Severity: important Dear Maintainers, With Linux 3.8, my computer starts (after some time) flooding its network interface with pause packets, effectively freezing it and other network-dependent computers connected to the same switch. When I disconnect it from the switch, the other computers resume their operations. But the faulty computer is still frozen. When I connect directly my laptop to the computer, and run tcpdump on the laptop, I see: 12:09:03.242511 MPCP, Opcode Pause, length 46 0x: 0180 c200 0001 3cd9 2b79 81b8 8808 0001 0x0010: 0650 0x0020: 0x0030: A lot of them. Two per millisecond. Indefinitely. Meanwhile, the computer is unresponsive. Until I forcibly reboot it. This bug started after an upgrade to a 3.8 kernel from experimental, during the freeze. I don't know exactly how to trigger it. I've observed times between boot and bug ranging from 1 day to 1 week. I downgraded to 3.2 (wheezy) and saw no problem for 2 weeks. After a reboot with the 3.8 kernel that is currently in unstable, the bug happened again after 1 day. Hence, the 3.8 kernel is unusable for me and I have to stick to the 3.2 one. A colleague of mine reported similar issues on the same hardware with Ubuntu but he didn't investigate. Cheers, -- Stéphane -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Hewlett-Packard product_name: HP Compaq 8200 Elite CMT PC product_version: chassis_vendor: Hewlett-Packard chassis_version: bios_vendor: Hewlett-Packard bios_version: J01 v02.06 board_vendor: Hewlett-Packard board_name: 1494 board_version: ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0100] (rev 09) Subsystem: Hewlett-Packard Company Device [103c:1494] 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 Capabilities: access denied Kernel driver in use: agpgart-intel 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device [103c:1494] 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 Interrupt: pin A routed to IRQ 48 Region 0: Memory at fe00 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at d000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at f000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04) Subsystem: Hewlett-Packard Company Device [103c:1494] 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 Interrupt: pin A routed to IRQ 11 Region 0: Memory at fe42a000 (64-bit, non-prefetchable) [size=16] Capabilities: access denied 00:16.3 Serial controller [0700]: Intel Corporation 6 Series/C200 Series Chipset Family KT Controller [8086:1c3d] (rev 04) (prog-if 02 [16550]) Subsystem: Hewlett-Packard Company Device [103c:1494] 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 Interrupt: pin B routed to IRQ 17 Region 0: I/O ports at f0e0 [size=8] Region 1: Memory at fe429000 (32-bit, non-prefetchable) [size=4K] Capabilities: access denied Kernel driver in use: serial 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04) Subsystem: Hewlett-Packard Company Device [103c:1494] 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 Interrupt: pin A routed to IRQ 46 Region 0: Memory at fe40 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at
Bug#707960: rpc.gssd segfaults when mounting a nfsv4 volume
Package: nfs-common Followup-For: Bug #707960 Same issue here, v1.2.8 is unusable and I have had to revert to 1.2.6 as well. A more thorough analysis is given in #709525, which I'm pretty sure is reporting the same issue. Could #708037 be causing this? Unrelated: the nfs-utils changelog for 1:1.2.8-1 mentions closing #657188, but that bug is against package libwww-mechanize-ruby. It should be referring to #675188 instead. Regards, Arno -- Package-specific info: -- rpcinfo -- -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (900, 'stable'), (300, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-rt-amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nfs-common depends on: ii adduser 3.113+nmu3 ii initscripts 2.88dsf-41 ii libc6 2.17-3 ii libcap2 1:2.22-1.2 ii libcomerr2 1.42.5-1.1 ii libdevmapper1.02.1 2:1.02.74-7 ii libevent-2.0-5 2.0.19-stable-3 ii libgssglue1 0.4-2 ii libk5crypto31.10.1+dfsg-5 ii libkeyutils11.5.5-7 ii libkrb5-3 1.10.1+dfsg-5 ii libmount1 2.20.1-5.4 ii libnfsidmap20.25-4 ii libtirpc1 0.2.2-5 ii libwrap07.6.q-24 ii lsb-base4.1+Debian9 ii rpcbind 0.2.0-8 ii ucf 3.0025+nmu3 Versions of packages nfs-common recommends: ii python 2.7.3-5 Versions of packages nfs-common suggests: pn open-iscsi none pn watchdognone -- no debconf information -- 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/20130524131226.11180.58803.report...@murid.intra.loos.site
Bug#709625: protected_hardlinks is too broad - make it per-filesystem instead?
Package: src:linux Version: 3.2.41-2 Severity: normal Hi, I think that the new security feature to restrict hardlinks is a great idea, but it is also causing me problems. In debian-cd, we rely on the ability to make hardlinked copies of files from a debian mirror into temporary disk trees. Since upgrading pettersson (the CD build box), this broke due to the default protected_hardlinks setting. On that system: * we have a push mirror setup using the archvsync user; * we build CDs using as the debian-cd user These two user accounts explicitly don't share credentials: archvsync can be triggered remotely so we don't trust it to be directly involved in the CD build process. The debian-cd user explicitly does not have write access to the mirror area on the machine, so as to ensure we can't/don't make any changes to the mirror when building CDs. For now, on that system we have changed the default settings via /proc but it's not a real solution for us and DSA don't want to do it permanently. I can see a few ways that we could change things: * run things using the same account (not wanted, as described above) * share a group between the users and make everything group-writable (ditto) * come up with a fakelink ld_preload lib like we have fakeroot (eww) Alternatively, I'm pondering: if the main thrust of the hardlink protection is to prevent attacks against system files, then it might make more sense to change protected_hardlinks to be a per-filesystem mount option. By all means protect the root filesystem etc., but for a purely data-carrying filesystem it's a bit obstructive. What do you think? -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- 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/20130524143045.13172.66494.reportbug@tack.local
Bug#708965: grub-config was needed
Am 24.05.2013 14:02, schrieb Ben Hutchings: Do you remember which release you originally installed? No idea by myself, but: root@okami:~# cat /var/log/installer/lsb-release DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=6.0 (squeeze) - installer build 20110106+squeeze4 X_INSTALLATION_MEDIUM=cdrom Do you have a separate /boot partition, and is there a /boot/boot/grub directory? /dev/sdb2 on /boot type xfs (rw,noatime) no /boot/boot/grub but /boot/grub : root@okami:/boot# ls -l insgesamt 14296 -rw-r--r-- 1 root root 106193 10. Mai 14:09 config-2.6.32-5-amd64 drwxr-xr-x 3 root root8192 20. Mai 08:49 grub -rw-r--r-- 1 root root 9957187 19. Mai 23:11 initrd.img-2.6.32-5-amd64 -rw-r--r-- 1 root root 124648 21. Mär 2010 memtest86.bin -rw-r--r-- 1 root root 165084 21. Okt 2010 memtest86+.bin -rw-r--r-- 1 root root 167264 21. Okt 2010 memtest86+_multiboot.bin -rw-r--r-- 1 root root 1667938 10. Mai 14:09 System.map-2.6.32-5-amd64 -rw-r--r-- 1 root root 2426848 10. Mai 13:57 vmlinuz-2.6.32-5-amd64 -- 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/519f7ef8.3030...@nobswolf.info
Bug#709632: gssd: Ignore a preferred_realm specified via the -R option
Package: nfs-common
Version: 1:1.2.2-4squeeze2
Severity: normal
Tags: patch
gssd ignores a preferred_realm specified via the -R command line option.
The attached patch fixes this problem and has already been sent to linux-nfs
upstream.
This problem affects all Debian suites.
Will there be a fix for Squeeze and Wheezy?
-- System Information:
Debian Release: 6.0.7
APT prefers oldstable
APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
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 nfs-common depends on:
ii adduser3.112+nmu2add and remove users and groups
ii initscripts2.88dsf-13.1+squeeze1 scripts for initializing and shutt
ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib
ii libcap21:2.19-3 support for getting/setting POSIX.
ii libcomerr2 1.41.12-4stable1 common error description library
ii libevent-1.4-2 1.4.13-stable-1 An asynchronous event notification
ii libgssapi-krb5-2 1.8.3+dfsg-4squeeze6 MIT Kerberos runtime libraries - k
ii libgssglue10.1-4 mechanism-switch gssapi library
ii libk5crypto3 1.8.3+dfsg-4squeeze6 MIT Kerberos runtime libraries - C
ii libkrb5-3 1.8.3+dfsg-4squeeze6 MIT Kerberos runtime libraries
ii libnfsidmap2 0.23-2An nfs idmapping library
ii librpcsecgss3 0.19-2allows secure rpc communication us
ii libwrap0 7.6.q-19 Wietse Venema's TCP wrappers libra
ii lsb-base 3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
ii netbase4.45 Basic TCP/IP networking system
ii portmap6.0.0-2 RPC port mapper
ii ucf3.0025+nmu1 Update Configuration File: preserv
nfs-common recommends no packages.
nfs-common suggests no packages.
-- no debconf information
commit 722bd62d1e6a9d38db57e919d914a371e67d804d
Author: Maximilian Wilhelm m...@rfc2324.org
Date: Fri May 24 14:46:41 2013 +0200
Fix handling of preferred realm command line option.
The current implementation ignores any preferred realm specified on the
command line. Fix this behaviour and make sure the preferred realm is
used as first realm when trying to acquire a keytab entry.
Signed-off-by: Maximilian Wilhelm m...@rfc2324.org
Signed-off-by: Frederik Moellers frederik.moell...@upb.de
diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c
index 6275dd8..fb706a8 100644
--- a/utils/gssd/krb5_util.c
+++ b/utils/gssd/krb5_util.c
@@ -852,11 +852,18 @@ find_keytab_entry(krb5_context context, krb5_keytab kt,
const char *tgtname,
}
/*
-* Try the appropriate realm first, and if nothing found for that
-* realm, try the default realm (if it hasn't already been tried).
+* Make sure the preferred_realm (which may have been explicitly set
+* on the command line, is tried first. If nothing is found go on with
+* the host and local default realm (if that hasn't already been tried).
*/
i = 0;
realm = realmnames[i];
+
+ if (strcmp (realm, preferred_realm) != 0) {
+ realm = preferred_realm;
+ i = -1;
+ }
+
while (1) {
if (realm == NULL) {
tried_all = 1;
Kernel image and OOT auto builder environment (Was: Using out of tree modules in d-i)?
On May 22, 2013, at 3:52 PM, Ben Hutchings wrote: Quoting from the report of our 2009 meeting, 20091015123106.ga16...@kyllikki.org: out of tree modules --- After a somewhat involved discussion taking into account the FTP masters extreme irritation about trying to match binaries to source by hand for the lenny release it was resolved to remove linux-modules-extra and -nonfree as they are an impossible to support approach. The Built-Using header should cover FTP masters' concerns. However it is still the case that omnibus source packages are unsustainable as many OOT modules are not kept up to date with the kernel API. I haven't been keeping up with the inner workings of Debian GNU/Linux the last couple of years, so please take this as-is. Is it possible to setup an automatic build system for kernel and modules? I know that we have (had?) an auto builder to build everything automatically (think it was mostly (?) used for the ports), but I was thinking about a special build system here. Very possibly just a modification of what we already have... That is, a special place to upload the kernel source to, and once the auto builder have successfully built a linux-image* package(s), then it will look in a special list for source packages to build as well. And once all those have succeeded to, THEN it will upload the kernel (and the OOT modules) to the ftp archive... To clarify: the kernel maintainer does not build and upload the package to the archives, but only uploads the source package to this special build system and it will do the rest... That way OOT modules should be able to keep up with the kernel releases and uploads without much (hopefully) extra work. And the added benefit is that once a new kernel version is available in the archives, the OOT modules will as well, without any extra lagg... This should be reasonably easy to do, and I volunteer to do the initial setup and/or prof-of-consept for all the versions we currently support (oldstable, stable and unstable). -- 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/7556b503-9234-4767-b6f1-b86d1280d...@bayour.com
Processed: Re: Bug#709616: floods the network with pause packets
Processing control commands: tag -1 moreinfo Bug #709616 [src:linux] floods the network with pause packets Added tag(s) moreinfo. -- 709616: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709616 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.b709616.1369411653547.transcr...@bugs.debian.org
Bug#709616: floods the network with pause packets
Control: tag -1 moreinfo On Fri, May 24, 2013 at 02:40:59PM +0200, Stéphane Glondu wrote: Package: src:linux Version: 3.8.13-1 Severity: important Dear Maintainers, With Linux 3.8, my computer starts (after some time) flooding its network interface with pause packets, effectively freezing it and other network-dependent computers connected to the same switch. Switches should normally be configured to generate but not respond to pause frames. I don't know how unmanaged switches are typically configured. What do ethtool (no options and 'ethtool -a' report for this device? When I disconnect it from the switch, the other computers resume their operations. But the faulty computer is still frozen. When I connect directly my laptop to the computer, and run tcpdump on the laptop, I see: 12:09:03.242511 MPCP, Opcode Pause, length 46 0x: 0180 c200 0001 3cd9 2b79 81b8 8808 0001 0x0010: 0650 0x0020: 0x0030: A lot of them. Two per millisecond. Indefinitely. Meanwhile, the computer is unresponsive. Until I forcibly reboot it. There seems to be a bug in your laptop's network driver, because pause frames should not be passed to the kernel. (Usually they are discarded by the MAC.) [...] 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04) Subsystem: Hewlett-Packard Company Device [103c:1494] 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 Interrupt: pin A routed to IRQ 46 Region 0: Memory at fe40 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at fe428000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at f080 [size=32] Capabilities: access denied Kernel driver in use: e1000e [...] I assume this is the device that's spewing pause frames? Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20130524160727.gm4...@decadent.org.uk
Re: [Pkg-zfsonlinux-devel] Kernel image and OOT auto builder environment (Was: Using out of tree modules in d-i)?
On Fri, May 24, 2013 at 11:53 PM, Turbo Fredriksson tu...@bayour.com wrote: On May 22, 2013, at 3:52 PM, Ben Hutchings wrote: Quoting from the report of our 2009 meeting, 20091015123106.ga16...@kyllikki.org: out of tree modules --- After a somewhat involved discussion taking into account the FTP masters extreme irritation about trying to match binaries to source by hand for the lenny release it was resolved to remove linux-modules-extra and -nonfree as they are an impossible to support approach. The Built-Using header should cover FTP masters' concerns. However it is still the case that omnibus source packages are unsustainable as many OOT modules are not kept up to date with the kernel API. I haven't been keeping up with the inner workings of Debian GNU/Linux the last couple of years, so please take this as-is. Is it possible to setup an automatic build system for kernel and modules? I know that we have (had?) an auto builder to build everything automatically (think it was mostly (?) used for the ports), but I was thinking about a special build system here. Very possibly just a modification of what we already have... That is, a special place to upload the kernel source to, and once the auto builder have successfully built a linux-image* package(s), then it will look in a special list for source packages to build as well. And once all those have succeeded to, THEN it will upload the kernel (and the OOT modules) to the ftp archive... To clarify: the kernel maintainer does not build and upload the package to the archives, but only uploads the source package to this special build system and it will do the rest... That way OOT modules should be able to keep up with the kernel releases and uploads without much (hopefully) extra work. And the added benefit is that once a new kernel version is available in the archives, the OOT modules will as well, without any extra lagg... This should be reasonably easy to do, and I volunteer to do the initial setup and/or prof-of-consept for all the versions we currently support (oldstable, stable and unstable). Having something like this may (or may not) generally help, but I'm not sure this is what we want to solve the problem. If OOT modules are added into d-i images directly, then we must set up something like this proposal to make sure the modules are available whenever a new kernel ABI is uploaded, and help d-i people to handle the brokenness if a change in kernel makes the OOT module does not build, or even function badly. This is hard to do, and I think there could be easier way for this specific issue. What I can think of is to do the trick in d-i, since it already has the ability to retrieve and load udeb on the fly, and even prompt users for missing firmware. Such functionality may be reused so that related udebs can be fetched and loaded when selected, and if all effort failed just generate an error message. By doing this a small check is performed to make sure the d-i kernel and the OOT modules are matched, so that d-i may get the ability to include OOT modules in the image, and the worst case is wasting several megabytes in the resulting images. debian-cd may also be improved to check OOT modules included in the image has correct version info to work together with the target d-i kernel to avoid such a waste. Finally, OOT modules may be listed in a separate list so that users are aware what they are doing, and d-i team can coordinate with maintainers of modules they want to include whenever an official image is generated (e.g. release CDs). As for how the small check would be implemented, the question can be discussed later in more detail if we agree that it's the preferred way to go with. -- Regards, Aron Xu -- 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/CAMr=8w7TsXC9tOYkws48sV0r+mv=mfzlb8l6z_3-xrqexfy...@mail.gmail.com
Bug#709647: linux-source-3.2: USB 1.1 no longer works
Package: linux-source-3.2 Version: 3.2.41-2+deb7u2 Severity: normal Dear Maintainer, [why capital M? (and singular?): Dear maintainer(s)?] USB always worked until version Wheezy (Debian 7.0.0) From /var/log/kern.log: pci :00:01.2: can't find IRQ for PCI INT D; please try using pci=biosirq uhci_hcd :00:01.2: Found HC with no IRQ. Check BIOS/PCI :00:01.2 setup! uhci_hcd :00:01.2: init :00:01.2 fail, -19 Using pci=biosirq has no effect From lshw (part of): *-firmware:0 description: BIOS vendor: SystemSoft physical id: 0 version: Version R3.03 date: 08/10/99 size: 80KiB capacity: 192KiB capabilities: isa pci pcmcia pnp apm upgrade shadowing cdboot edd int13floppy720 int5printscreen int9keyboard int14serial int17printer int10video acpi usb zipboot smartbattery biosbootspecification netboot virtualmachine *-pci description: Host bridge product: 430TX - 82439TX MTXC vendor: Intel Corporation physical id: 100 bus info: pci@:00:00.0 version: 01 width: 32 bits clock: 33MHz *-usb UNCLAIMED description: USB controller product: 82371AB/EB/MB PIIX4 USB vendor: Intel Corporation physical id: 1.2 bus info: pci@:00:01.2 version: 01 width: 32 bits clock: 33MHz capabilities: uhci configuration: latency=64 resources: ioport:1040(size=32) From lsusb -v (standard error): unable to initialize libusb: -99 From lspci -n -vvv (device 00:01.2): 00:01.2 0c03: 8086:7112 (rev 01) (prog-if 00 [UHCI]) 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 D routed to IRQ 0 Region 4: I/O ports at 1040 [size=32] Kernel (Debian 3.2.41-... compiled with this .config: # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.2.41 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_NEED_DMA_MAP_STATE is not set CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_LOCALVERSION=-47 # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_FHANDLE is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SPARSE_IRQ=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # CONFIG_CGROUPS is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set # CONFIG_SCHED_AUTOGROUP is not set #
Re: [Pkg-zfsonlinux-devel] Kernel image and OOT auto builder environment (Was: Using out of tree modules in d-i)?
On Sat, May 25, 2013 at 2:45 AM, Turbo Fredriksson tu...@bayour.com wrote: On May 24, 2013, at 7:04 PM, Aron Xu wrote: and help d-i people to handle the brokenness if a change in kernel makes the OOT module does not build This should only happen when a new major version of the kernel comes out, which means it should only happen in unstable.. And we could make it so that it is possible to make that particular OOT skipped (manually or automatically after a specified time), and hence won't be available for that run of d-i. But within a oldstable or stable kernel, only the Debian version changes, right, so... But if a kernel changes a lot and often in unstable, support for that specific OOT will be intermittent. Might not be a huge problem in unstable. Unwanted, but not a huge deal... What I can think of is to do the trick in d-i, since it already has the ability to retrieve and load udeb on the fly, and even prompt users for missing firmware. Maybe even build them using dkms? I saw that you can make d-i build all packages... So adding a extra hook or something that sees that this is a OOT module, then get it's dkms package, build (to a .deb/.udeb which I have patches sent upstream for) it and use that... It could be possible, but I don't think building it is acceptable, because it means you must pull in everything of build-essential to the d-i image, which is useless for most other people when they run d-i. But either way would mean that the d-i builder have to do the fixing, instead of a group of people (should be the responsibility of the OOT module maintainer(s)). Such functionality may be reused so that related udebs can be fetched and loaded when selected, and if all effort failed just generate an error message. What if an OOT is a network module? Might be needed before the network is up to fetch it... This is what I've said that d-i can ask users for firmware, and the case is usually network drivers: http://wiki.debian.org/Firmware And if it's included in the monolithic image, then it will be up to the d-i builder/uploader to make sure that the module is available, not a group of people... -- Regards, Aron Xu -- 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/CAMr=8w7burLHc=0rStLTDSrge=se67jghvpajmu3rh_-p3q...@mail.gmail.com
Re: [Pkg-zfsonlinux-devel] Kernel image and OOT auto builder environment (Was: Using out of tree modules in d-i)?
On May 24, 2013, at 7:04 PM, Aron Xu wrote: and help d-i people to handle the brokenness if a change in kernel makes the OOT module does not build This should only happen when a new major version of the kernel comes out, which means it should only happen in unstable.. And we could make it so that it is possible to make that particular OOT skipped (manually or automatically after a specified time), and hence won't be available for that run of d-i. But within a oldstable or stable kernel, only the Debian version changes, right, so... But if a kernel changes a lot and often in unstable, support for that specific OOT will be intermittent. Might not be a huge problem in unstable. Unwanted, but not a huge deal... What I can think of is to do the trick in d-i, since it already has the ability to retrieve and load udeb on the fly, and even prompt users for missing firmware. Maybe even build them using dkms? I saw that you can make d-i build all packages... So adding a extra hook or something that sees that this is a OOT module, then get it's dkms package, build (to a .deb/.udeb which I have patches sent upstream for) it and use that... But either way would mean that the d-i builder have to do the fixing, instead of a group of people (should be the responsibility of the OOT module maintainer(s)). Such functionality may be reused so that related udebs can be fetched and loaded when selected, and if all effort failed just generate an error message. What if an OOT is a network module? Might be needed before the network is up to fetch it... And if it's included in the monolithic image, then it will be up to the d-i builder/uploader to make sure that the module is available, not a group of people... -- 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/e46ce809-7a99-4572-9af2-64ee1f645...@bayour.com
Re: [Pkg-zfsonlinux-devel] Kernel image and OOT auto builder environment (Was: Using out of tree modules in d-i)?
On May 24, 2013, at 8:54 PM, Aron Xu wrote: What I can think of is to do the trick in d-i, since it already has the ability to retrieve and load udeb on the fly, and even prompt users for missing firmware. Maybe even build them using dkms? I saw that you can make d-i build all packages... So adding a extra hook or something that sees that this is a OOT module, then get it's dkms package, build (to a .deb/.udeb which I have patches sent upstream for) it and use that... It could be possible, but I don't think building it is acceptable, because it means you must pull in everything of build-essential to the d-i image, which is useless for most other people when they run d-i. Ah, ok then I think I know what you mean. I thought you meant when the d-i image is built... But how does this help keeping 'the current kernel' and the OOT's up-to-date? From what I think I understand of you proposal, the user. Which means we can't offer 'whatever-support-the-OOT-provides' globally in our install images. It would be up to the user to make sure that this is available. I was kind'a hoping we could do this as an organization and provide this for our users, instead of putting it to them to make it available for themselves. -- 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/cd9b3b40-3a48-473d-8cd0-643aa1440...@bayour.com
