Bug#591031: linux-image-2.6.35-rc6-686: suspend works for a while (once?) then stops working
Package: linux-2.6 Version: 2.6.35~rc6-1~experimental.1 Severity: normal Suspend to ram (closing laptop lid) works for a few times (maybe only once?) then starts failing legacy_suspend(): pnp_bus_suspend+0x0/0x57 returns 38 Here's what it looked like when it worked: [10619.731187] PM: Syncing filesystems ... done. [10619.737770] PM: Preparing system for mem sleep [10619.838203] Freezing user space processes ... (elapsed 0.01 seconds) done. [10619.852065] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [10619.868052] PM: Entering mem sleep [10619.868149] Suspending console(s) (use no_console_suspend to debug) [10619.869223] sd 0:0:0:0: [sda] Stopping disk [10619.870841] btusb_intr_complete: hci0 urb f665e700 failed to resubmit (1) [10619.871835] btusb_bulk_complete: hci0 urb f665e980 failed to resubmit (1) [10619.872836] btusb_bulk_complete: hci0 urb f665ec00 failed to resubmit (1) [10619.980087] ACPI handle has no context! [10619.980193] e100 :06:08.0: PCI INT A disabled [10619.980202] e100 :06:08.0: PME# enabled [10619.980215] e100 :06:08.0: wake-up capability enabled by ACPI [10619.980345] tifm_7xx1 :06:04.2: PCI INT C disabled [10619.981089] ata2: port disabled. ignoring. [10619.981156] ata_piix :00:1f.1: PCI INT B disabled [10619.981245] ata_piix :00:1f.1: power state changed by ACPI to D3 [10619.981467] ehci_hcd :00:1d.7: PCI INT D disabled [10619.981549] uhci_hcd :00:1d.3: PCI INT A disabled [10619.981631] uhci_hcd :00:1d.2: PCI INT C disabled [10619.981713] uhci_hcd :00:1d.1: PCI INT B disabled [10619.981795] uhci_hcd :00:1d.0: PCI INT A disabled [10619.982766] i915 :00:02.0: PCI INT A disabled [10620.188095] HDA Intel :00:1b.0: PCI INT A disabled [10620.204033] PM: suspend of devices complete after 335.646 msecs [10620.220180] PM: late suspend of devices complete after 16.140 msecs [10620.220613] ACPI: Preparing to enter system sleep state S3 [10620.276220] PM: Saving platform NVS memory [10620.351192] Disabling non-boot CPUs ... Hardware is Sony Vaio TX3 -- Package-specific info: ** Version: Linux version 2.6.35-rc6-686 (Debian 2.6.35~rc6-1~experimental.1) (b...@decadent.org.uk) (gcc version 4.4.4 (Debian 4.4.4-7) ) #1 SMP Mon Jul 26 09:46:49 UTC 2010 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.35-rc6-686 root=/dev/mapper/carbon_vg-root ro quiet ** Not tainted ** Kernel log: [14423.555002] btusb_bulk_complete: hci0 urb f52a5300 failed to resubmit (1) [14423.556001] btusb_bulk_complete: hci0 urb f52a5d80 failed to resubmit (1) [14423.608151] legacy_suspend(): pnp_bus_suspend+0x0/0x57 returns 38 [14423.608158] PM: Device 00:07 failed to suspend: error 38 [14423.608163] PM: Some devices failed to suspend [14423.608821] sd 0:0:0:0: [sda] Starting disk [14423.848119] PM: resume of devices complete after 239.947 msecs [14423.848222] PM: Finishing wakeup. [14423.848225] Restarting tasks ... done. [14424.249074] ADDRCONF(NETDEV_UP): wlan0: link is not ready [14424.270153] ADDRCONF(NETDEV_UP): eth0: link is not ready [14436.950026] wlan0: authenticate with 56:99:28:16:86:10 (try 1) [14436.954018] wlan0: authenticated [14436.954061] wlan0: associate with 56:99:28:16:86:10 (try 1) [14436.956546] wlan0: RX AssocResp from 56:99:28:16:86:10 (capab=0x411 status=0 aid=1) [14436.956554] wlan0: associated [14436.958186] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [14438.240054] usb 1-2: new high speed USB device using ehci_hcd and address 11 [14438.372732] usb 1-2: New USB device found, idVendor=0409, idProduct=0059 [14438.372742] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [14438.372749] usb 1-2: Product: USB2.0 Hub [14438.372754] usb 1-2: Manufacturer: NECEL [14438.375158] hub 1-2:1.0: USB hub found [14438.375264] hub 1-2:1.0: 3 ports detected [14438.660119] usb 1-2.1: new high speed USB device using ehci_hcd and address 12 [14438.768365] usb 1-2.1: New USB device found, idVendor=04b4, idProduct=6560 [14438.768374] usb 1-2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [14438.771006] hub 1-2.1:1.0: USB hub found [14438.771113] hub 1-2.1:1.0: 2 ports detected [14439.004176] e100 :06:08.0: eth0: NIC Link is Up 100 Mbps Full Duplex [14439.004672] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [14439.108125] usb 1-2.2: new high speed USB device using ehci_hcd and address 13 [14439.216362] usb 1-2.2: New USB device found, idVendor=050d, idProduct=0237 [14439.216372] usb 1-2.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [14439.219000] hub 1-2.2:1.0: USB hub found [14439.219108] hub 1-2.2:1.0: 4 ports detected [14439.620122] usb 1-2.3: new full speed USB device using ehci_hcd and address 14 [14439.732854] usb 1-2.3: New USB device found, idVendor=04d2, idProduct=9801 [14439.732864] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [14439.732871] usb 1-2.3: Product: Altec Lansing XT1 - USB Audio [14439.732877] usb 1-2.3: Manufacturer: Altec Lansing
Bug#591038: initramfs-tools: udev goes crazy spawnings many processes
Package: initramfs-tools Version: 0.97.2 Severity: important Recentl my system has stopped booting. I have two MD raid arrays with LVM on top of them. Each LVM volume (including root and swap) are encrypted, so obviously initramfs has to deal with them on boot. Several weeks ago system stop booting: 1. First, I see a lot of message like show here http://imagebin.ca/view/eL-M9KQz.html. 2. Then I get password prompt to entery passphrase for a new volume. 3. After that nothing happens any more. Debugging shows that udevd behaves wierdly by endlessly spawning multiple children. I've made a workaound by killing udevd and restarting it in /usr/share/initramfs-tools/scripts/local-top/cryptroot -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 12M Jul 31 12:23 /boot/initrd.img-2.6.32-5-amd64 -- /proc/cmdline BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=/dev/mapper/vg0stronghold-root_crypt ro quiet quiet -- resume RESUME=/dev/mapper/vg0stronghold-swap_crypt -- /proc/filesystems ext3 ext2 xfs fuseblk -- lsmod Module Size Used by ppdev 5030 0 lp 7462 0 binfmt_misc 6431 1 xt_TCPMSS 2919 1 ip6table_filter 2384 1 ip6_tables 15075 1 ip6table_filter act_police 3636 0 cls_flow5948 0 cls_fw 3513 0 cls_u32 5466 0 sch_htb11942 0 sch_hfsc 12119 0 sch_ingress 1624 0 sch_sfq 4686 0 xt_time 1723 0 xt_connlimit2863 0 xt_realm 919 0 iptable_raw 1867 0 xt_comment 907 31 xt_recent 5977 0 xt_policy 2170 0 ipt_ULOG7129 7 ipt_REJECT 1953 4 ipt_REDIRECT 0 ipt_NETMAP 1137 0 ipt_MASQUERADE 1554 0 ipt_ECN 1672 0 ipt_ecn 1272 0 ipt_CLUSTERIP 4910 0 ipt_ah 1061 0 ipt_addrtype1769 3 nf_nat_tftp 966 0 nf_nat_snmp_basic 7796 0 nf_nat_sip 4934 0 nf_nat_pptp 2034 0 nf_nat_proto_gre1245 1 nf_nat_pptp nf_nat_irc 1366 0 nf_nat_h323 5095 0 nf_nat_ftp 2031 0 nf_nat_amanda 1144 0 ts_kmp 1623 5 nf_conntrack_amanda 2197 1 nf_nat_amanda nf_conntrack_sane 3620 0 nf_conntrack_tftp 3321 1 nf_nat_tftp nf_conntrack_sip 13546 1 nf_nat_sip nf_conntrack_proto_sctp 6238 0 nf_conntrack_pptp 3801 1 nf_nat_pptp nf_conntrack_proto_gre 3579 1 nf_conntrack_pptp nf_conntrack_netlink13128 0 nf_conntrack_netbios_ns 1282 0 nf_conntrack_irc3347 1 nf_nat_irc nf_conntrack_h323 36992 1 nf_nat_h323 nf_conntrack_ftp5537 1 nf_nat_ftp xt_TPROXY 1329 0 nf_tproxy_core 1549 1 xt_TPROXY,[permanent] xt_tcpmss 1401 0 xt_pkttype 1003 0 xt_physdev 1508 0 xt_owner1063 0 xt_NFQUEUE 1989 0 xt_NFLOG1038 0 nfnetlink_log 7000 1 xt_NFLOG xt_multiport2267 6 xt_MARK 917 1 xt_mark 917 0 xt_mac 979 0 xt_limit1782 0 xt_length 1164 0 xt_iprange 1433 0 xt_helper 1227 0 xt_hashlimit7707 0 xt_DSCP 1995 0 xt_dscp 1611 0 xt_dccp 1915 0 xt_conntrack2407 10 xt_CONNMARK 1267 0 xt_connmark 1123 0 xt_CLASSIFY 925 0 ipt_LOG 4518 0 xt_tcpudp 2319 27 xt_state1303 0 iptable_nat 4299 0 nf_nat 13388 12 ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,nf_nat_tftp,nf_nat_sip,nf_nat_pptp,nf_nat_proto_gre,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat_amanda,iptable_nat nf_conntrack_ipv4 9833 13 iptable_nat,nf_nat nf_defrag_ipv4 1139 2 xt_TPROXY,nf_conntrack_ipv4 nf_conntrack 46551 31 xt_connlimit,ipt_MASQUERADE,ipt_CLUSTERIP,nf_nat_tftp,nf_nat_snmp_basic,nf_nat_sip,nf_nat_pptp,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat_amanda,nf_conntrack_amanda,nf_conntrack_sane,nf_conntrack_tftp,nf_conntrack_sip,nf_conntrack_proto_sctp,nf_conntrack_pptp,nf_conntrack_proto_gre,nf_conntrack_netlink,nf_conntrack_netbios_ns,nf_conntrack_irc,nf_conntrack_h323,nf_conntrack_ftp,xt_helper,xt_conntrack,xt_CONNMARK,xt_connmark,xt_state,iptable_nat,nf_nat,nf_conntrack_ipv4 iptable_mangle 2817 1 nfnetlink 2398 2 nf_conntrack_netlink,nfnetlink_log iptable_filter 2258 1 ip_tables 13899 4
Bug#591056: hook/boot scripts in /etc/initramfs-tools should override those in /u/s/initramfs-tools
Package: initramfs-tools Version: 0.97.2 Severity: wishlist Hi. It's already extremely nice that initramfs-tools allows adding hook/boot scripts to /etc/initramfs-tools/hooks/ and /etc/initramfs-tools/scripts/ in addition to /usr/share/initramfs-tools/hooks/ and /usr/share/initramfs-tools/scripts/. IMO it would be even nicer, if those in /etc override those in /usr. E.g. you have in the package lvm2 the following scripts: /usr/share/initramfs-tools/hooks/lvm2 /usr/share/initramfs-tools/scripts/local-top/lvm2 Now the way they work may not fit my custom setup so I add: /etc/initramfs-tools/hooks/lvm2 /etc/initramfs-tools/scripts/local-top/lvm2 If the later exists than the corresponding hook-script (of the same name) in /usr/share/initramfs-tools/hooks/ should not run and the corresponding boot script in /usr/share/initramfs-tools/scripts/ should not be copied to the initramfs image. It would however be nice, if a warning (for each of them) is printed when generating the initramfs. Otherwise users might accidentally override important scripts :) Cheers, Chris. -- 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/20100731141833.27503.13288.report...@heisenberg.scientia.net
Bug#591073: linux-image-2.6.32-5-amd64: Suspend-to-RAM regression
Package: linux-2.6 Version: 2.6.32-15 Severity: normal Suspending the computer to RAM (e.g., from the KDE menu) works fine in the previous kernel linux-image-2.6.32-3-amd64. But with the current -5 kernel it has ceased to work. The machine falls asleep but the system doesn't come up again afterwards when the hardware runs again but nothing is shown on the screen. This is on a fully up-to-date squeeze system. The bug was already present with the same kernel on last week's squeeze. It's clearly a regression, as it's the first Debian kernel which doesn't get this right on this machine. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: System manufacturer product_name: System Product Name product_version: System Version chassis_vendor: Chassis Manufacture chassis_version: Chassis Version bios_vendor: American Megatrends Inc. bios_version: 1006 board_vendor: ASUSTeK Computer INC. board_name: M4A78-EM board_version: Rev X.0x ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] RS780 Host Bridge [1022:9600] Subsystem: ASUSTeK Computer Inc. Device [1043:82f1] 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- Latency: 0 Capabilities: access denied 00:01.0 PCI bridge [0604]: ASUSTeK Computer Inc. RS880 PCI to PCI bridge (int gfx) [1043:9602] (prog-if 00 [Normal decode]) 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- Latency: 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: c000-cfff Memory behind bridge: fe80-fe9f Prefetchable memory behind bridge: d000-dfff Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied 00:0a.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 5) [1022:9609] (prog-if 00 [Normal decode]) 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 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: fea0-feaf Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:11.0 SATA controller [0106]: ATI Technologies Inc SB700/SB800 SATA Controller [IDE mode] [1002:4390] (prog-if 01 [AHCI 1.0]) Subsystem: ASUSTeK Computer Inc. Device [1043:82ef] 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- Latency: 64, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 22 Region 0: I/O ports at b000 [size=8] Region 1: I/O ports at a000 [size=4] Region 2: I/O ports at 9000 [size=8] Region 3: I/O ports at 8000 [size=4] Region 4: I/O ports at 7000 [size=16] Region 5: Memory at fe7ffc00 (32-bit, non-prefetchable) [size=1K] Capabilities: access denied Kernel driver in use: ahci 00:12.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397] (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device [1043:82ef] 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- Latency: 64, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at fe7fe000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd 00:12.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398] (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device [1043:82ef] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr-
Bug#590744: Fails to boot if /sbin/init is a symlink
* maximilian attems m...@stro.at [Fri Jul 30, 2010 at 01:04:30PM +0200]:
On Fri, Jul 30, 2010 at 11:49:32AM +0200, Michael Biebl wrote:
On 30.07.2010 11:31, Michael Biebl wrote:
On 30.07.2010 06:21, Michael Prokop wrote:
Can you please give the following snapshot version a try:
http://people.debian.org/~mika/initramfs-tools/initramfs-tools_0.97.3~1.gbp8d572e_all.deb
I've tested the following:
- /sbin/init being a relative symlink: works
- /sbin/init being an absolute symlink: works
- /sbin/init missing: correctly dropped to rescue shell, even if upstart
installed (/etc/init/)
- passing init=/bin/systemd on the boot command line: works
- passing bogus init=/sbin/foo on the boot command line: warning message
that
requested init was not found, is displayed, but continues booting with
/sbin/init.
So yes, it works correctly now for all cases I tested and expect.
Looking at the code, the only issue I see, is that validate_init is *always*
executed at least twice, even if we find a valid init at the first try.
This means, for most cases we unnecessarily execute validate_init at
# No init on rootmount
if ! validate_init ${init} ; then
Not that much of an issue, just an idea for a small optimization.
please this is executed on every boot, could we have a fastforward
path for the common cases.
dracut probably solved this long ago, please have a look there
what fedora guys are doing.
dracut doesn't seem to support symlinks at all AFAICS.
maks: I've implemented a fastfoward path, please review
branch mika/validate_init at
http://git.debian.org/?p=kernel/initramfs-tools.git
regards,
-mika-
signature.asc
Description: Digital signature
Bug#590744: Fails to boot if /sbin/init is a symlink
* Michael Biebl bi...@debian.org [Fri Jul 30, 2010 at 11:49:32AM +0200]:
On 30.07.2010 11:31, Michael Biebl wrote:
On 30.07.2010 06:21, Michael Prokop wrote:
Can you please give the following snapshot version a try:
http://people.debian.org/~mika/initramfs-tools/initramfs-tools_0.97.3~1.gbp8d572e_all.deb
I've tested the following:
- /sbin/init being a relative symlink: works
- /sbin/init being an absolute symlink: works
- /sbin/init missing: correctly dropped to rescue shell, even if upstart
installed (/etc/init/)
- passing init=/bin/systemd on the boot command line: works
- passing bogus init=/sbin/foo on the boot command line: warning message
that
requested init was not found, is displayed, but continues booting with
/sbin/init.
So yes, it works correctly now for all cases I tested and expect.
Thanks a lot for testing.
Looking at the code, the only issue I see, is that validate_init is *always*
executed at least twice, even if we find a valid init at the first try.
This means, for most cases we unnecessarily execute validate_init at
# No init on rootmount
if ! validate_init ${init} ; then
Not that much of an issue, just an idea for a small optimization.
Good catch. I think I've addressed this issue in branch
mika/validate_init at
http://git.debian.org/?p=kernel/initramfs-tools.git
If you think there's anything else we could improve there please let
me know.
thanks regards,
-mika-
signature.asc
Description: Digital signature
Bug#591024: marked as done (A cleanup of the nfs script in initramfs-tools)
Your message dated Sat, 31 Jul 2010 20:26:27 +0100 with message-id 1280604387.13192.355.ca...@localhost and subject line Re: Bug#591024: A cleanup of the nfs script in initramfs-tools has caused the Debian Bug report #591024, regarding A cleanup of the nfs script in initramfs-tools 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.) -- 591024: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591024 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: initramfs-tools Version: 0.97.2 The attachment is a cleanup patch of the scripts/nfs. initramfs-tools-0.92.2-nfs.patch Description: Binary data ---End Message--- ---BeginMessage--- On Fri, 2010-07-30 at 21:47 -0700, wol...@yahoo.com wrote: Package: initramfs-tools Version: 0.97.2 The attachment is a cleanup patch of the scripts/nfs. It's not cleanup; it changes behaviour. And it's missing a close-brace, so clearly you didn't actually test it. No thanks. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part ---End Message---
Bug#591073: linux-image-2.6.32-5-amd64: Suspend-to-RAM regression
tags 591073 moreinfo stop On Sat, Jul 31, 2010 at 06:42:03PM +0200, Josef Spillner wrote: Package: linux-2.6 Version: 2.6.32-15 Severity: normal Suspending the computer to RAM (e.g., from the KDE menu) works fine in the previous kernel linux-image-2.6.32-3-amd64. But with the current -5 kernel it has ceased to work. The machine falls asleep but the system doesn't come up again afterwards when the hardware runs again but nothing is shown on the screen. This is on a fully up-to-date squeeze system. The bug was already present with the same kernel on last week's squeeze. It's clearly a regression, as it's the first Debian kernel which doesn't get this right on this machine. outdated test against 2.6.32-18 from unstable, thanks. -- 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/20100731211308.gp19...@baikonur.stro.at
Processed: Re: Bug#591073: linux-image-2.6.32-5-amd64: Suspend-to-RAM regression
Processing commands for cont...@bugs.debian.org: tags 591073 moreinfo Bug #591073 [linux-2.6] linux-image-2.6.32-5-amd64: Suspend-to-RAM regression Added tag(s) moreinfo. stop Stopping processing here. Please contact me if you need assistance. -- 591073: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591073 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.12806113624372.transcr...@bugs.debian.org
Bug#590744: Fails to boot if /sbin/init is a symlink
On Sat, Jul 31, 2010 at 08:25:09PM +0200, Michael Prokop wrote: dracut doesn't seem to support symlinks at all AFAICS. well this seems sane to me. maks: I've implemented a fastfoward path, please review branch mika/validate_init at http://git.debian.org/?p=kernel/initramfs-tools.git will do in the next 48 hours, but haven't been told that the ! symlink cause is the usual fastpath. not sure this symlink complication is really worth it. -- 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/20100731211529.gq19...@baikonur.stro.at
Bug#590744: Fails to boot if /sbin/init is a symlink
On 31.07.2010 23:15, maximilian attems wrote: On Sat, Jul 31, 2010 at 08:25:09PM +0200, Michael Prokop wrote: dracut doesn't seem to support symlinks at all AFAICS. I'm pretty sure it does. Fedora 14 just switched to systemd and they use a symlink. I guess dracut does not really care and does not do any safety checks as initramfs-tools currently does. maks: I've implemented a fastfoward path, please review branch mika/validate_init at http://git.debian.org/?p=kernel/initramfs-tools.git will do in the next 48 hours, but haven't been told that the ! symlink cause is the usual fastpath. not sure this symlink complication is really worth it. I do think, it should be possible to boot with /sbin/init being a symlink (either absolute or relative). I don't really care if that means, that either the safety checks are made more sophisticated or dropped altogether. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#590875: Some additional information ...
Kernel Panics occur after random amount of time when copying huge amount (20GB) of data to one of my harddisks (HD154UI). The attached picture of the kernel panic trace occured when formatting a raid1-device consisting of 2 harddisks (HD154UI) with ext3. -- 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/1288586386.1280615217705.javamail.ngm...@webmail06.arcor-online.net
Bug#591149: linux-2.6: [INTL:fr] French debconf templates translation update
Package: linux-2.6 Version: N/A Severity: wishlist Tags: l10n patch Please find attached the French debconf templates translation updated, proofread by the debian-l10n-french mailing list contributors. This file should be put as debian/po/fr.po in your package build tree. Regards David fr.po.gz Description: GNU Zip compressed data signature.asc Description: OpenPGP digital signature
Bug#583731: Bug Traced to Application Code
I traced the change of behaviour when changing kernel versions to a problem in the application itself. One of the usb_control_msg calls was being made with data that the device did not understand, and so the device was not responding and usb_interrupt_read was returning an error status that the developer (not me :-) never checked. It is kind of amazing it ever worked, but the response buffer contained valid data from a previous usb call, however the patches to the kernel changed the contents of the buffer which 'broke' the broken application. I updated the application code to fix the arguments to the usb_control_msg call so that device responded correctly and to check the return status of all of the usb calls and the application has now been verified to work properly on 2.6.26-21lenny4, 2.6.26-22lenny1, 2.6.32-5, 2.6.32-trunk and a 2.6.34 kernel. Apologies for not having a much deeper dig into this at the start. -- 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/4c54c9c7.2060...@ozforecast.com.au
Bug#583731: marked as done (broken usbfs support after CVE-2010-1083)
Your message dated Sat, 31 Jul 2010 22:07:28 -0400
with message-id 20100801020728.ga11...@galadriel.inutil.org
and subject line Re: Bug Traced to Application Code
has caused the Debian Bug report #583731,
regarding broken usbfs support after CVE-2010-1083
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.)
--
583731: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583731
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: libusb
Version: 2:0.1.12-1
I have encountered problems with a program that uses libusb-0.1-4 ever since
installing the lenny1 security update of linux-image-2.6.26-2-686.
Perhaps it is a regression in the kernel related to CVE-2010-1083??
I am not sure whether the bug report should belong to the kernel or libusb, or
maybe its a fault in the program I use (although it worked well before the
kernel upgrade).
A partial strace follows:
open(/dev/bus/usb/002/002, O_RDWR)= 3
rt_sigaction(SIGTERM, {0x8048c64, [TERM], SA_RESTART}, {SIG_DFL}, 8) = 0
ioctl(3, USBDEVFS_GETDRIVER, 0xbfffe788) = -1 ENODATA (No data available)
ioctl(3, USBDEVFS_CLAIMINTERFACE, 0xbfffe8a4) = 0
ioctl(3, USBDEVFS_SETINTERFACE, 0xbfffe884) = 0
ioctl(3, USBDEVFS_CONTROL, 0xbfffe44c) = 18
ioctl(3, USBDEVFS_CONTROL, 0xbfffe44c) = 9
ioctl(3, USBDEVFS_CONTROL, 0xbfffe44c) = 34
ioctl(3, USBDEVFS_RELEASEINTERFACE, 0xbfffe4b4) = 0
ioctl(3, USBDEVFS_SETCONFIGURATION, 0xbfffe4b4) = 0
ioctl(3, USBDEVFS_CLAIMINTERFACE, 0xbfffe4b4) = 0
ioctl(3, USBDEVFS_SETINTERFACE, 0xbfffe494) = 0
ioctl(3, USBDEVFS_CONTROL, 0xbfffe48c) = 0
ioctl(3, USBDEVFS_CONTROL, 0xbfffe44c) = 59
ioctl(3, USBDEVFS_CONTROL, 0xbfffe48c) = 8
gettimeofday({1275206696, 628403}, NULL) = 0
ioctl(3, USBDEVFS_SUBMITURB, 0xbfffe464) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbfffe4a8) = -1 EAGAIN (Resource temporarily
unavailable)
select(4, NULL, [3], NULL, {0, 1000}) = 0 (Timeout)
gettimeofday({1275206696, 630976}, NULL) = 0
ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbfffe4a8) = -1 EAGAIN (Resource temporarily
unavailable)
select(4, NULL, [3], NULL, {0, 1000}) = 0 (Timeout)
The USBDEVFS_REAPURBNDELAY - EAGAIN / select / gettimeofday sequence happens
about 350 times and then the program prints rubbish data.
Kernel: Linux 2.6.26-2-686 #1 SMP Wed May 12 21:56:10 UTC 2010 i686 GNU/Linux
Libc6: 2.7-18lenny2
Details of the USB device (which is a Chinese weather station not a Dream Link
USB Missile Launcher):
Bus 002 Device 002: ID 1941:8021 Dream Link USB Missile Launcher
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x1941 Dream Link
idProduct 0x8021 USB Missile Launcher
bcdDevice1.00
iManufacturer 0
iProduct0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType33
bcdHID 1.00
bCountryCode0 Not supported
bNumDescriptors 1
bDescriptorType34 Report
wDescriptorLength 52
Report Descriptor: (length is 52)
Item(Global): Usage Page, data= [ 0xa0 0xff ] 65440
(null)
Item(Local ): Usage, data= [ 0x01 ] 1
(null)
Item(Main ): Collection, data= [ 0x01 ] 1
Application
Item(Local ): Usage, data= [ 0x02 ] 2
(null)
Item(Main ): Collection, data= [ 0x00 ] 0
Physical
Item(Global): Usage Page, data= [ 0xa1 0xff ] 65441
(null)
Item(Local ): Usage Minimum, data= [ 0x01 ] 1
(null)
Item(Local ): Usage Maximum, data=
Processed: tagging 590546
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 590546 + pending Bug #590546 [linux-2.6] [l10n:cs] Updated Czech translation of PO debconf template for package linux-2.6 2.6.32-18 Ignoring request to alter tags of bug #590546 to the same tags previously set End of message, stopping processing here. Please contact me if you need assistance. -- 590546: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590546 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.128063216421778.transcr...@bugs.debian.org
Processed: tagging 590557
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 590557 + pending Bug #590557 [linux-2.6] linux-2.6: [INTL:pt] Updated Portuguese translation for debconf messages Ignoring request to alter tags of bug #590557 to the same tags previously set End of message, stopping processing here. Please contact me if you need assistance. -- 590557: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590557 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.128063216721805.transcr...@bugs.debian.org
Processed: tagging 591149
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 591149 + pending Bug #591149 [linux-2.6] linux-2.6: [INTL:fr] French debconf templates translation update Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 591149: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591149 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.128063223822502.transcr...@bugs.debian.org
