Bug#1014793: linux-image-5.10.0-16-amd64: Kernel crashes while serving NFS
Den 2022-07-15 kl. 21:58, skrev Salvatore Bonaccorso:
I would be interested to either pinpoint the regressing commit
upstream beween 5.10.120 and 5.10.127 or conversely the fixing commit
beween 5.10.127 upstream and 5.10.130 where you are not able anymore
to reproduce the error. What I can say, I have already imported
5.10.130 for furture upload (cf.
https://salsa.debian.org/kernel-team/linux/-/merge_requests/506).
Bisection for the regression proved too hard.
Bisection for the fix went better, I can get a crash with 5.10.128-00010
but not yet with 5.10.128-00011. This indicates that the fixing commit
was probably:
commit 6a0b9512a6aa7b7835d8138f5ffdcb4789c093d4
Author: Chuck Lever
Date: Thu Jun 30 16:48:18 2022 -0400
SUNRPC: Fix READ_PLUS crasher
which indeed seems to touch code involved in NFS service.
Consequently, the breaking commit was probably:
6c254bf3b637 ("SUNRPC: Fix the calculation of xdr->end in
xdr_get_next_encode_buffer()")
Bisection would be a new experience for me, even compiling the kernel seem
like ages ago ... (using Debian since 0.93R6).
Would the following help?
https://wiki.debian.org/DebianKernel/GitBisect
Do you need any more specifc help to get it rolling?
That was indeed helpful.
Regards,
Salvatore
Thanks
Arne
Bug#1014793: linux-image-5.10.0-16-amd64: Kernel crashes while serving NFS
Sorry for the late reply. Den 2022-07-13 kl. 12:07, skrev Salvatore Bonaccorso: Control: tags -1 + moreinfo Hello Arne, ... As you seem to reliably reproduce the issue, do you have the possiblity (on the nonproduction instance) to try to bisect down the problem? Additionally to the bisect, on a testinstance were the issue is reproducible, can you run a selfcompiled 5.10.130 upstream to see if the problem is still present? I have now set up a test environment, and been able to reproduce NFS crashes with the Debian linux-image-5.10.0-16-amd64 and self-compiled upstream v5.10.127 kernels. I have not been able to get a self-compiled upstream v5.10.130 to crash. As for bisection, I am not entirely clear what is expected from me. Do you mean bisect the upstream kernels? Between which points? v5.10.120 to v5.10.127? Bisection would be a new experience for me, even compiling the kernel seem like ages ago ... (using Debian since 0.93R6). Regards, Salvatore Thanks again, Arne
Bug#1014793: linux-image-5.10.0-16-amd64: Kernel crashes while serving NFS
Package: src:linux Version: 5.10.127-1 Severity: normal Dear Maintainer, The new kernel in Debian 11.4 seems unstable and crashes when serving NFS. On two different computers, these lockups happens within minutes, typically when a client runs firefox on an NFS-mounted home directory. Typically the servers lock up without any printout, but on one occasion, the following was logged: jul 10 08:35:13 ano4 kernel: general protection fault, probably for non-canonical address 0x2f48514544455145: [#1] SMP PTI jul 10 08:35:13 ano4 kernel: CPU: 2 PID: 1244 Comm: nfsd Not tainted 5.10.0-16-amd64 #1 Debian 5.10.127-1 jul 10 08:35:13 ano4 kernel: Hardware name: System manufacturer System Product Name/P5Q DELUXE, BIOS 220105/21/2009 jul 10 08:35:13 ano4 kernel: RIP: 0010:fsnotify+0x2d9/0x570 jul 10 08:35:13 ano4 kernel: Code: 78 08 44 0b 30 44 0b 68 40 48 83 c1 01 48 83 f9 04 75 d9 66 66 66 66 90 44 8b 4c 24 1c 44 89 e8 f7 d0 45 21 f1 41 85 c1 74 4f <49> 8b 3f 48 8b 07 48 85 c0 0f 84 0a 01 00 00 48 8d 7c 24 38 44 89 jul 10 08:35:13 ano4 kernel: RSP: 0018:abe901fa3bc8 EFLAGS: 00010202 jul 10 08:35:13 ano4 kernel: RAX: bab6aebe RBX: 0001 RCX: 0004 jul 10 08:35:13 ano4 kernel: RDX: 00035a00 RSI: 0001 RDI: 2f48514544455145 jul 10 08:35:13 ano4 kernel: RBP: abe901fa3c20 R08: 0001 R09: 0002 jul 10 08:35:13 ano4 kernel: R10: 0002 R11: 0002 R12: 0002 jul 10 08:35:13 ano4 kernel: R13: 45495141 R14: 424d6757 R15: 2f48514544455145 jul 10 08:35:13 ano4 kernel: FS: () GS:939527d0() knlGS: jul 10 08:35:13 ano4 kernel: CS: 0010 DS: ES: CR0: 80050033 jul 10 08:35:13 ano4 kernel: CR2: 560b8cee4000 CR3: 0001034da000 CR4: 000406e0 jul 10 08:35:13 ano4 kernel: Call Trace: jul 10 08:35:13 ano4 kernel: __fsnotify_parent+0xe7/0x2d0 jul 10 08:35:13 ano4 kernel: ? ext4_buffered_write_iter+0xce/0x160 [ext4] jul 10 08:35:13 ano4 kernel: ? do_iter_readv_writev+0x152/0x1b0 jul 10 08:35:13 ano4 kernel: do_iter_write+0xc8/0x1b0 jul 10 08:35:13 ano4 kernel: nfsd_vfs_write+0x175/0x510 [nfsd] jul 10 08:35:13 ano4 kernel: nfsd4_write+0x135/0x1b0 [nfsd] jul 10 08:35:13 ano4 kernel: nfsd4_proc_compound+0x40d/0x680 [nfsd] jul 10 08:35:13 ano4 kernel: nfsd_dispatch+0xd3/0x180 [nfsd] jul 10 08:35:13 ano4 kernel: svc_process_common+0x3d4/0x6d0 [sunrpc] jul 10 08:35:13 ano4 kernel: ? nfsd_svc+0x320/0x320 [nfsd] jul 10 08:35:13 ano4 kernel: svc_process+0xb7/0xf0 [sunrpc] jul 10 08:35:13 ano4 kernel: nfsd+0xe8/0x140 [nfsd] jul 10 08:35:13 ano4 kernel: ? nfsd_destroy+0x60/0x60 [nfsd] jul 10 08:35:13 ano4 kernel: kthread+0x11b/0x140 jul 10 08:35:13 ano4 kernel: ? __kthread_bind_mask+0x60/0x60 jul 10 08:35:13 ano4 kernel: ret_from_fork+0x22/0x30 jul 10 08:35:13 ano4 kernel: Modules linked in: dm_snapshot dm_bufio tun cpufreq_ondemand cpufreq_powersave cpufreq_conservative cpufreq_userspace aes_generic libaes crypto_simd cryptd glue_helper cbc cts rpcsec_gss_krb5 sit tunnel4 ip_tunnel nft_nat sch_fq_codel rc_pinnacl e_pctv_hd em28xx_rc rc_core si2157 si2168 i2c_mux em28xx_dvb dvb_core snd_hda_codec_analog snd_hda_codec_generic ledtrig_audio ivtv_alsa tuner_simple tuner_types snd_hda_codec_hdmi wm8775 snd_hda_intel tda9887 tda8290 snd_intel_dspcfg tea5767 soundwire_intel tuner soundwire_generic_allocation snd_soc_core snd _compress soundwire_cadence cx25840 snd_hda_codec ivtv snd_hda_core snd_hwdep soundwire_bus em28xx kvm_intel radeon tveeprom snd_pcm cx2341x kvm ttm videodev snd_timer snd irqbypass soundcore drm_kms_helper mc serio_raw evdev cec i2c_algo_bit iTCO_wdt intel_pmc_bxt iTCO_vendor_support pcspkr watchdog sg acpi_ cpufreq asus_atk0110 button nft_chain_nat nf_nat nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_counter nft_ct jul 10 08:35:13 ano4 kernel: nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 coretemp firewire_sbp2 nf_tables nfnetlink loop nfsd parport_pc ppdev nfs_acl lockd lp auth_rpcgss parport grace drm fuse sunrpc configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 raid10 raid4 56 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid0 multipath linear dm_mod raid1 md_mod sd_mod hid_generic t10_pi ata_generic crc_t10dif crct10dif_generic st crct10dif_common usbhid pata_marvell hid ahci libahci mpt3sas firewire_ohci firewire_core aic7xxx crc_itu_t libata skge ehci_pci uhci_hcd scsi_transport_spi lpc_ich i2c_i801 sky2 ehci_hcd psmouse i2c_smbus raid_class scsi_transport_sas usbcore scsi_mod usb_common floppy jul 10 08:35:13 ano4 kernel: ---[ end trace 159cb95f57d30ea4 ]--- jul 10 08:35:13 ano4 kernel: RIP: 0010:fsnotify+0x2d9/0x570 jul 10 08:35:13 ano4 kernel: Code: 78 08 44 0b 30 44 0b 68 40 48 83 c1 01 48 83 f9 04 75 d9 66 66 66 66 90 44 8b 4c 24 1c 44 89 e8 f7 d0 45 21 f1 41 85 c1 74 4f
Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services
I have also seen this on a couple of SSD-only systems. I think the problem is that the random number generator takes about two minutes to initialize, long enough for systemd to give up on these processes. Unbound is similar, but there unit file keeps trying until the random numbers are available. >From the log: May 5 10:19:02 ano2 kernel: [ 126.436729] random: crng init done Pressing the keyboard a few times (thus providing entropy) will allow the boot to continue. This definitely seems to be a kernel problem. Arne
Bug#886768: Acknowledgement (linux-headers-3.16.0-5-amd64: inode_change_ok() missing, breaks openafs module build)
Newer OpenAFS versions replace code = inode_change_ok(inode, ); by code = setattr_prepare(file_dentry(afile->filp), ); The file_dentry() helper is not present in linux-headers-3.16.0-5 either, but code = setattr_prepare(afile->filp->f_path.dentry, ); at least seems to compile. Is this the correct replacement? Arne
Bug#753732: NFS sec=krb5 does not work with cross-realm
On Fri, 04 Jul 2014 16:36:12 +0200 Jaap Winius jwin...@umrk.nl wrote: Package: nfs-common Version: 1.2.6-4 NFS with sec=krb5i or sec=krb5p using MIT Kerberos does not work when cross-realm authentication is used -- only when clients have an Kerberos ticket for the same realm. This happens consistently and in cases when cross-realm authentication does work with other services on the same machine, such as SSH. ... The second set involves a user account with the same name, jwinius, but with a Kerberos ticket from a different, albeit trusted realm: UMRK.NL. This always results in an authentication failure: ... The user experience ends with a Permission denied message, although the client does receive a Kerberos service ticket despite the failure. The rpc.idmapd daemon seems to translate the jwin...@umrk.nl account to jwin...@dapadam.nl with user ID 1. In some situations this might be incorrect, but here it's okay because both accounts belong to the same person. When authentication fails, the only evidence that I can see for this in the server's log output is in the fifth line shown: nss_gss_princ_to_ids: Local-Realm 'UMRK.NL': NOT FOUND. Apparently, the local Kerberos KDC is not interrogated and the trust entry for the UMRK.NL realm is never discovered. You have not included the content of /etc/idmapd.conf. There are several options for translating principals, and if user names are the same in both realms a simple line like Local-Realms: DAPADAM.NL, UMRK.NL might do it. Arne Nordmark -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55a35290.2040...@mech.kth.se
Bogus(?) /dev/sda appearing with linux-image-3.2.0-4-amd64 3.2.65-1
With the latest Wheezy kernel I am seeing a new device /dev/sda that has not been seen in previous kernels. Below is some info that may be of interest. ls -l /dev/disk/by-path/ totalt 0 lrwxrwxrwx 1 root root 9 jan 11 17:24 pci-:03:00.0-scsi-1:0:0:0 - ../../sda lspci 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II / PATA Controller (rev b2) ls -l /dev/disk/by-id totalt 0 lrwxrwxrwx 1 root root 9 jan 11 17:24 ata-Config_Disk_0_CP-5723_Port_0_1_0_J - ../../sda lrwxrwxrwx 1 root root 9 jan 11 17:24 scsi-SATA_Config_Disk_0CP-5723_Port_0_1_0_J - ../../sda grep -E 'Config|sda' /var/log/kern.log Jan 11 17:24:32 ano4 kernel: [1.236338] ata2.00: ATA-7: Config Disk 0, 1.2569, max MWDMA2 Jan 11 17:24:32 ano4 kernel: [1.26] scsi 1:0:0:0: Direct-Access ATA Config Disk 0 1.25 PQ: 0 ANSI: 5 Jan 11 17:24:32 ano4 kernel: [2.848798] sd 1:0:0:0: [sda] 16777215 512-byte logical blocks: (8.58 GB/7.99 GiB) Jan 11 17:24:32 ano4 kernel: [2.848847] sd 1:0:0:0: [sda] Write Protect is off Jan 11 17:24:32 ano4 kernel: [2.848849] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Jan 11 17:24:32 ano4 kernel: [2.848870] sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA Jan 11 17:24:32 ano4 kernel: [2.850470] sda: unknown partition table Jan 11 17:24:32 ano4 kernel: [2.850631] sd 1:0:0:0: [sda] Attached SCSI disk Could it be something with RAID on the motherboard? Should it be reported as a bug? Arne Nordmark -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b2b056.1010...@mech.kth.se
Re: Bogus(?) /dev/sda appearing with linux-image-3.2.0-4-amd64 3.2.65-1
Den 2015-01-11 18:18, Arne Nordmark skrev: With the latest Wheezy kernel I am seeing a new device /dev/sda that has not been seen in previous kernels. The claim of the device being new was not correct. I though I had online logs going back before the latest reboot. Checking offline logs I still find the device (as /dev/sdc) so the issue seems only to be a (perhaps unlucky) change in device discovery order. Anyway, if anyone knows what this device is, it would be helpful. Arne -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b2bdb3.6020...@mech.kth.se
Bug#661581: Fails to resume from suspend on ASUS P67-M mainboard
2012-03-01 16:31, Jonathan Nieder skrev: tags 661581 = upstream forwarded 661581 http://thread.gmane.org/gmane.linux.kernel/1240187/focus=52118 quit Arne Nordmark wrote: Some newer ASUS mainboards fails to resume from suspend on Linux. Instead the computer immediately restarts a few times, and then does a full boot. This has been traced to an ACPI problem, and a symtom is the kernel messages: [...] ACPI Error: [RAMB] Namespace lookup failure, AE_NOT_FOUND (20110623/psargs-359) ACPI Exception: AE_NOT_FOUND, Could not execute arguments for [RAMW] (Region) (20110623/nsinit-349) When applying the commit [...];h=8931d9ea78848b073bf299594f148b83abde4a5e to the current kernel sources from backports, the error messages disappears, and resume functionality is restored. Thanks. Was this a regression? Passed upstream. Hopefully the fix can be part of the 3.2.y series some time soon, so everyone benefits from it. Looks like this made it into 3.2.16: ... drivers/acpi/acpica/acobject.h|1 drivers/acpi/acpica/dsargs.c |2 drivers/acpi/acpica/excreate.c|6 + ... Lin Ming (1): ACPICA: Fix to allow region arguments to reference other scopes ... Hope that helps, Jonathan Thanks, Arne -- 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/4f97adb8.6060...@mech.kth.se
Bug#661581: Fails to resume from suspend on ASUS P67-M mainboard
2012-03-01 16:31, Jonathan Nieder skrev: tags 661581 = upstream forwarded 661581 http://thread.gmane.org/gmane.linux.kernel/1240187/focus=52118 quit Arne Nordmark wrote: Some newer ASUS mainboards fails to resume from suspend on Linux. Instead the computer immediately restarts a few times, and then does a full boot. This has been traced to an ACPI problem, and a symtom is the kernel messages: [...] ACPI Error: [RAMB] Namespace lookup failure, AE_NOT_FOUND (20110623/psargs-359) ACPI Exception: AE_NOT_FOUND, Could not execute arguments for [RAMW] (Region) (20110623/nsinit-349) When applying the commit [...];h=8931d9ea78848b073bf299594f148b83abde4a5e to the current kernel sources from backports, the error messages disappears, and resume functionality is restored. Thanks. Was this a regression? No. The same problem is found in the squeeze kernel and in 2.6.39 from backports, so I think it is safe to say that this has never worked before. Thanks Arne Passed upstream. Hopefully the fix can be part of the 3.2.y series some time soon, so everyone benefits from it. Hope that helps, Jonathan -- 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/4f4fa845.4080...@mech.kth.se
Bug#661581: linux-image-3.2.0-0.bpo.1-amd64: Fails to resume from suspend on ASUS P67-M mainboard
Package: linux-2.6 Version: 3.2.4-1~bpo60+1 Severity: normal Tags: patch Some newer ASUS mainboards fails to resume from suspend on Linux. Instead the computer immediately restarts a few times, and then does a full boot. This has been traced to an ACPI problem, and a symtom is the kernel messages: Feb 19 01:13:55 ano1 kernel: [0.493066] ACPI Error: [RAMB] Namespace lookup failure, AE_NOT_FOUND (20110623/psargs-359) Feb 19 01:13:55 ano1 kernel: [0.493070] ACPI Exception: AE_NOT_FOUND, Could not execute arguments for [RAMW] (Region) (20110623/nsinit-349) When applying the commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=8931d9ea78848b073bf299594f148b83abde4a5e to the current kernel sources from backports, the error messages disappears, and resume functionality is restored. It would be nice to have this fix in wheezy. Thanks Arne -- Package-specific info: ** Version: Linux version 3.2.0-0.bpo.1-amd64 (Debian 3.2.4-1~bpo60+1) (nordm...@mech.kth.se) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Mon Feb 27 11:19:28 CET 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-0.bpo.1-amd64 root=/dev/mapper/part2-root ro enable_mtrr_cleanup quiet ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [29165.078180] pata_jmicron :07:00.1: restoring config space at offset 0x5 (was 0x1, writing 0xc031) [29165.078186] pata_jmicron :07:00.1: restoring config space at offset 0x4 (was 0x1, writing 0xc041) [29165.078196] pata_jmicron :07:00.1: restoring config space at offset 0x1 (was 0x10, writing 0x15) [29165.078266] r8169 :08:00.0: restoring config space at offset 0x1 (was 0x17, writing 0x100407) [29165.078370] xhci_hcd :09:00.0: restoring config space at offset 0x1 (was 0x16, writing 0x100402) [29165.078404] pcieport :00:1c.7: wake-up capability disabled by ACPI [29165.078410] xhci_hcd :09:00.0: PME# disabled [29165.078455] PM: early resume of devices complete after 1.295 msecs [29165.078565] ehci_hcd :00:1a.0: PCI INT A - GSI 23 (level, low) - IRQ 23 [29165.078578] ehci_hcd :00:1a.0: setting latency timer to 64 [29165.078594] snd_hda_intel :00:1b.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [29165.078601] snd_hda_intel :00:1b.0: setting latency timer to 64 [29165.078626] pci :00:1c.4: PCI INT A - GSI 17 (level, low) - IRQ 17 [29165.078632] pci :00:1c.4: setting latency timer to 64 [29165.078654] ehci_hcd :00:1d.0: PCI INT A - GSI 23 (level, low) - IRQ 23 [29165.078660] ehci_hcd :00:1d.0: setting latency timer to 64 [29165.078666] ahci :00:1f.2: setting latency timer to 64 [29165.078669] snd_hda_intel :00:1b.0: irq 55 for MSI/MSI-X [29165.078690] radeon :01:00.0: setting latency timer to 64 [29165.078692] snd_hda_intel :01:00.1: PCI INT B - GSI 17 (level, low) - IRQ 17 [29165.078701] snd_hda_intel :01:00.1: setting latency timer to 64 [29165.078732] pci :05:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [29165.078742] pci :05:00.0: setting latency timer to 64 [29165.078757] ahci :07:00.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [29165.078771] pata_jmicron :07:00.1: PCI INT B - GSI 18 (level, low) - IRQ 18 [29165.078775] ahci :07:00.0: setting latency timer to 64 [29165.078794] pata_jmicron :07:00.1: setting latency timer to 64 [29165.078811] pcieport :00:1c.6: wake-up capability disabled by ACPI [29165.078829] r8169 :08:00.0: PME# disabled [29165.078850] snd_hda_intel :01:00.1: irq 56 for MSI/MSI-X [29165.078884] xhci_hcd :09:00.0: setting latency timer to 64 [29165.078910] usb usb3: root hub lost power or was reset [29165.078911] usb usb4: root hub lost power or was reset [29165.079884] parport_pc 00:03: activated [29165.080717] serial 00:09: activated [29165.086038] xhci_hcd :09:00.0: irq 49 for MSI/MSI-X [29165.086048] xhci_hcd :09:00.0: irq 50 for MSI/MSI-X [29165.086051] xhci_hcd :09:00.0: irq 51 for MSI/MSI-X [29165.086053] xhci_hcd :09:00.0: irq 52 for MSI/MSI-X [29165.086056] xhci_hcd :09:00.0: irq 53 for MSI/MSI-X [29165.093419] [drm] PCIE GART of 512M enabled (table at 0x0004). [29165.093474] radeon :01:00.0: WB enabled [29165.094542] sd 1:0:0:0: [sdb] Starting disk [29165.094565] sd 2:0:0:0: [sdc] Starting disk [29165.094567] sd 0:0:0:0: [sda] Starting disk [29165.117175] r8169 :08:00.0: eth0: link down [29165.139248] [drm] ring test succeeded in 1 usecs [29165.139265] [drm] ib test succeeded in 0 usecs [29165.146602] firewire_core: skipped bus generations, destroying all nodes [29165.398276] ata7: SATA link down (SStatus 0 SControl 300) [29165.430229] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [29165.483465] ata5.00: configured for UDMA/100 [29165.574272] usb 3-1: reset low-speed USB device number 2 using xhci_hcd [29165.604232] xhci_hcd :09:00.0: xHCI xhci_drop_endpoint called with
Bug#574555: BUG: scheduling while atomic: irq/11-b43/2018/0x00000101
Ben Hutchings wrote: On Fri, 2010-06-18 at 16:40 +0200, Arne Nordmark wrote: My problem seems related to those in Ubuntu report #55 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/55. If I unload the 3c59x module, I can no longer reproduce this problem, and wireless is stable. With the 3c59x module loaded, b43 wireless is essentially unusable, since the machine will reliably lock up. I've attached two patches which together may fix this problem, but they involve quite major changes to the driver. I do not have any hardware of this type which I could use to test them. Indeed, I can no longer reproduce the problem with these patches applied. Both wired (3c59x) and wireless (b43) can now handle GB transfers, which is about 100x more than was typically needed to trigger the problem for wireless. I now question my judgement in reporting my problem on an existing bug report, as the resolution does not fit the original reporter's description (no 3c59x module loaded). Please could you follow the instructions at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official to build a package with these changes included, then test whether these changes fix the problem for you and keep the wired network card working. Since that section is very explicit in mentioning dependencies, may I point out that the test-patches script relies on commands (dch at least) from the devscripts package. Ben. Thanks Arne -- 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/4c225c88.90...@mech.kth.se
Bug#574555: BUG: scheduling while atomic: irq/11-b43/2018/0x00000101
My problem seems related to those in Ubuntu report #55 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/55. If I unload the 3c59x module, I can no longer reproduce this problem, and wireless is stable. With the 3c59x module loaded, b43 wireless is essentially unusable, since the machine will reliably lock up. Arne -- 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/4c1b8554.8090...@mech.kth.se
Bug#574555: BUG: scheduling while atomic: irq/11-b43/2018/0x00000101
ext3 jbd mbcache sd_mod crc_t10dif ata_generic uhci_hcd ata_piix ehci_hcd video libata 3c59x usbcore output floppy button mii nls_base scsi_mod thermal fan thermal_sys [last unloaded: scsi_wait_scan] May 8 09:35:48 dhcp190 kernel: [ 1830.65] Pid: 2018, comm: irq/11-b43 Not tainted 2.6.32-5-686 #1 May 8 09:35:48 dhcp190 kernel: [ 1830.644452] Call Trace: May 8 09:35:48 dhcp190 kernel: [ 1830.644479] [c1267c45] ? schedule+0x7e/0x7dc May 8 09:35:48 dhcp190 kernel: [ 1830.644550] [d0beda88] ? ieee80211_invoke_rx_handlers+0x12e7/0x1970 [mac80211] May 8 09:35:48 dhcp190 kernel: [ 1830.644580] [d09461aa] ? vortex_timer+0x0/0x1f3 [3c59x] May 8 09:35:48 dhcp190 kernel: [ 1830.644608] [c106d4ce] ? synchronize_irq+0x89/0x9b May 8 09:35:48 dhcp190 kernel: [ 1830.644631] [c10445ce] ? autoremove_wake_function+0x0/0x2d May 8 09:35:48 dhcp190 kernel: [ 1830.644650] [d09461cf] ? vortex_timer+0x25/0x1f3 [3c59x] May 8 09:35:48 dhcp190 kernel: [ 1830.644671] [d09461aa] ? vortex_timer+0x0/0x1f3 [3c59x] May 8 09:35:48 dhcp190 kernel: [ 1830.644689] [c103b56c] ? run_timer_softirq+0x16a/0x1eb May 8 09:35:48 dhcp190 kernel: [ 1830.644709] [c1035e8c] ? __do_softirq+0xaa/0x151 May 8 09:35:48 dhcp190 kernel: [ 1830.644721] [c1035f64] ? do_softirq+0x31/0x3c May 8 09:35:48 dhcp190 kernel: [ 1830.644733] [c10360cf] ? _local_bh_enable_ip+0x63/0x6e May 8 09:35:48 dhcp190 kernel: [ 1830.644792] [d0df490f] ? b43_rx+0x434/0x456 [b43] May 8 09:35:48 dhcp190 kernel: [ 1830.644816] [d0df4208] ? b43_attr_interfmode_store+0xc5/0xe9 [b43] May 8 09:35:48 dhcp190 kernel: [ 1830.644843] [d0df86e3] ? op32_fill_descriptor+0x2a/0x8b [b43] May 8 09:35:48 dhcp190 kernel: [ 1830.644868] [d0df80a0] ? b43_dma_rx+0x211/0x283 [b43] May 8 09:35:48 dhcp190 kernel: [ 1830.644891] [d0de9d1f] ? b43_do_interrupt_thread+0x3fa/0x4cb [b43] May 8 09:35:48 dhcp190 kernel: [ 1830.644914] [d0de9e05] ? b43_interrupt_thread_handler+0x15/0x27 [b43] May 8 09:35:48 dhcp190 kernel: [ 1830.644929] [c106ce05] ? irq_thread+0xc4/0x1a5 May 8 09:35:48 dhcp190 kernel: [ 1830.644955] [c10252de] ? complete+0x28/0x36 May 8 09:35:48 dhcp190 kernel: [ 1830.644967] [c106cd41] ? irq_thread+0x0/0x1a5 May 8 09:35:48 dhcp190 kernel: [ 1830.644979] [c104439c] ? kthread+0x61/0x66 May 8 09:35:48 dhcp190 kernel: [ 1830.644991] [c104433b] ? kthread+0x0/0x66 May 8 09:35:48 dhcp190 kernel: [ 1830.645012] [c1003d47] ? kernel_thread_helper+0x7/0x10 Arne Nordmark -- 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/4be69056@mech.kth.se
Bug#276134: kernel-source-2.6.8: Minolta DIMAGE cameras stopped working with usb-st orage in 2.6.8
Horms wrote: Thanks, that looks good to me. I will put the patch into SVN and it should appear in the next release. Just to clarify: I did try the patch and it solved my problem. Many thanks, Arne -- Arne Nordmark Tel: +46 8 - 790 71 92 KTH/Mekanik Fax: +46 8 - 723 04 75 SE-100 44 STOCKHOLM Internet: [EMAIL PROTECTED] Sweden
Bug#276134: kernel-source-2.6.8: Minolta DIMAGE cameras stopped working with usb-st orage in 2.6.8
Package: kernel-source-2.6.8 Version: 2.6.8-7 Severity: normal A change form 2.6.7 to 2.6.8 in the error return handling of usb_stor_Bulk_max_lun() in usb-storage/transport.c exposed a problem with Minolta DIMAGE cameras, causing probing to fail, and thus these cameras cannot be used with 2.6.8. The included patch from the linux-usb-devel list claims to restore functionality. Arne List: linux-usb-devel Subject:[linux-usb-devel] PATCH: help vendors count to 1... From: Matthew Dharm mdharm-usb () one-eyed-alien ! net Date: 2004-08-22 18:54:59 Message-ID: 20040822185459.GA30746 () one-eyed-alien ! net [Download message RAW] This patch started out life as as356. All I did was re-generate it against the tip of the tree. It turns out that the Konica-Minolta DiMAGE A2 camera, in addition to all its other problems, returns a 0-length reply to the GetMaxLUN rquest. With this patch (accept a null reply as meaning a single LUN) it is somewhat useable. It's amazing to me that vendors have this much trouble counting to 1 Greg, please apply. Matt Signed-off-by: Alan Stern [EMAIL PROTECTED] Signed-off-by: Matthew Dharm [EMAIL PROTECTED] # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/08/22 11:49:19-07:00 [EMAIL PROTECTED] # as356 # # drivers/usb/storage/transport.c # 2004/08/22 11:48:49-07:00 [EMAIL PROTECTED] +2 -1 # as356 # diff -Nru a/drivers/usb/storage/transport.c #b/drivers/usb/storage/transport.c --- a/drivers/usb/storage/transport.c Sun Aug 22 11:52:19 2004 +++ b/drivers/usb/storage/transport.c Sun Aug 22 11:52:19 2004 @@ -911,6 +911,7 @@ int result; /* issue the command */ + us-iobuf[0] = 0; result = usb_stor_control_msg(us, us-recv_ctrl_pipe, US_BULK_GET_MAX_LUN, USB_DIR_IN | USB_TYPE_CLASS | @@ -921,7 +922,7 @@ result, us-iobuf[0]); /* if we have a successful request, return the result */ - if (result == 1) + if (result = 0) return us-iobuf[0]; /* -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: LANG=C, LC_CTYPE=en_US Versions of packages kernel-source-2.6.8 depends on: ii binutils 2.15-4 The GNU assembler, linker and bina ii bzip2 1.0.2-1A high-quality block-sorting file ii coreutils [fileutils] 5.2.1-2The GNU core utilities -- no debconf information
