Bug#764162: [PATCH 0/1] mv643xx_eth: Disable TSO by default
On Tue, 2014-11-04 at 15:20 +0100, Karl Beldan wrote:
On Sat, Nov 01, 2014 at 12:30:19PM -0300, Ezequiel Garcia wrote:
Several users ([1], [2]) have been reporting data corruption with TSO on
Kirkwood platforms (i.e. using the mv643xx_eth driver).
Until we manage to find what's causing this, this simple patch will make
the TSO path disabled by default. This patch should be queued for stable,
fixing the TSO feature introduced in v3.16.
The corruption itself is very easy to reproduce: checking md5sum on a
mounted
NFS directory gives a different result each time. Same tests using the
mvneta
driver (Armada 370/38x/XP SoC) pass with no issues.
Frankly, I'm a bit puzzled about this, and so any ideas or debugging hints
are well received.
Hi,
Can you try this :
It fixes things for me, thanks!
Tested-by: Ian Campbell i...@hellion.org.uk
@@ -1067,7 +1082,8 @@ static int txq_reclaim(struct tx_queue *txq, int
budget, int force)
txq-tx_desc_count--;
skb = NULL;
- if (cmd_sts TX_LAST_DESC)
+ if ((cmd_sts (TX_LAST_DESC | TX_ENABLE_INTERRUPT)) ==
+(TX_LAST_DESC | TX_ENABLE_INTERRUPT))
skb = __skb_dequeue(txq-tx_skb);
if (cmd_sts ERROR_SUMMARY) {
--
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/1415176766.31613.7.ca...@hellion.org.uk
Bug#764162: [PATCH 0/1] mv643xx_eth: Disable TSO by default
On Wed, Nov 05, 2014 at 08:39:26AM +, Ian Campbell wrote: On Tue, 2014-11-04 at 15:20 +0100, Karl Beldan wrote: On Sat, Nov 01, 2014 at 12:30:19PM -0300, Ezequiel Garcia wrote: Several users ([1], [2]) have been reporting data corruption with TSO on Kirkwood platforms (i.e. using the mv643xx_eth driver). Until we manage to find what's causing this, this simple patch will make the TSO path disabled by default. This patch should be queued for stable, fixing the TSO feature introduced in v3.16. The corruption itself is very easy to reproduce: checking md5sum on a mounted NFS directory gives a different result each time. Same tests using the mvneta driver (Armada 370/38x/XP SoC) pass with no issues. Frankly, I'm a bit puzzled about this, and so any ideas or debugging hints are well received. Hi, Can you try this : It fixes things for me, thanks! Tested-by: Ian Campbell i...@hellion.org.uk Good thing, thanks for your feedbak Ian ! Karl -- 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/20141105100953.ga29...@magnum.frso.rivierawaves.com
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Tue, 2014-11-04 at 22:37 +0100, Karsten Merker wrote: I have run further installation tests with today's current d-i images (still based on the same 3.16.5-1 kernel) OOI if you bodge your way through the install does the resulting system boot and discover the PHY reliably? IOW is it specific to d-i or not? i.e. the PHY appears to have a seperate regulator on the BananaPi but not on the Cubietruck and I wonder whether the startup-delay-us = 5; might play a role here. I think that's a decent theory. Decent enoguh that it is probably worth taking it up with the sunxi kernel folks. Might also be the power supply differs between the two boards? -- 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/1415184312.11486.79.ca...@hellion.org.uk
Bug#768157: machine hangs when loading cirrus with modeset=1 while booted with vga=791
Package: src:linux Version: 3.16.7-1 Severity: normal Hi, while testing the new Grml release, I noticed an interesting hang of QEMU when the machine is booted. The initial testing was done using [1] in QEMU from Sid (2.1+dfsg-5), but I also could reproduce it with the same QEMU and a fresh Jessie install with both, 3.16.5-1 and 3.16.7-1. To reproduce: * boot a fresh Jessie with 3.16 kernel in QEMU and vga=791 as bootparam * modprobe cirrus modeset=1 * machine hangs I am not sure this will happen on real cirrus HW, as I don't have any, but QEMU is quite widespread and cirrus is the default VGA driver. Regards Evgeni [1] http://download.grml.org/devel/grml64-full_2014.10-rc1.iso -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-1 (2014-11-04) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/vg01-root ro quiet vga=791 ** Not tainted ** Kernel log: [0.565203] AMD IOMMUv2 functionality not available on this system [0.565321] TCP: cubic registered [0.565339] NET: Registered protocol family 10 [0.565544] mip6: Mobile IPv6 [0.565548] NET: Registered protocol family 17 [0.565553] mpls_gso: MPLS GSO support [0.565831] registered taskstats version 1 [0.566263] rtc_cmos 00:00: setting system clock to 2014-11-05 13:53:31 UTC (1415195611) [0.566318] PM: Hibernation image not present or could not be loaded. [0.567297] Freeing unused kernel memory: 1200K (818ed000 - 81a19000) [0.567299] Write protecting the kernel read-only data: 8192k [0.570060] Freeing unused kernel memory: 940K (880001515000 - 88000160) [0.570697] Freeing unused kernel memory: 224K (8800017c8000 - 88000180) [0.584291] systemd-udevd[51]: starting version 215 [0.584626] random: systemd-udevd urandom read with 1 bits of entropy available [0.594962] ACPI: bus type USB registered [0.594996] usbcore: registered new interface driver usbfs [0.595009] usbcore: registered new interface driver hub [0.597676] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10 [0.601839] SCSI subsystem initialized [0.611252] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10 [0.611884] usbcore: registered new device driver usb [0.612948] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [0.614231] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11 [0.616681] uhci_hcd: USB Universal Host Controller Interface driver [0.622091] uhci_hcd :00:01.2: UHCI Host Controller [0.622101] uhci_hcd :00:01.2: new USB bus registered, assigned bus number 1 [0.622127] uhci_hcd :00:01.2: detected 2 ports [0.622215] uhci_hcd :00:01.2: irq 11, io base 0xc040 [0.623527] libata version 3.00 loaded. [0.625041] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 [0.625045] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.625047] usb usb1: Product: UHCI Host Controller [0.625049] usb usb1: Manufacturer: Linux 3.16.0-4-amd64 uhci_hcd [0.625051] usb usb1: SerialNumber: :00:01.2 [0.625480] hub 1-0:1.0: USB hub found [0.625635] hub 1-0:1.0: 2 ports detected [0.626321] ata_piix :00:01.1: version 2.13 [0.632467] FDC 0 is a S82078B [0.639578] scsi0 : ata_piix [0.649203] scsi1 : ata_piix [0.649260] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc0a0 irq 14 [0.649262] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc0a8 irq 15 [0.651923] virtio-pci :00:03.0: irq 40 for MSI/MSI-X [0.651946] virtio-pci :00:03.0: irq 41 for MSI/MSI-X [0.651966] virtio-pci :00:03.0: irq 42 for MSI/MSI-X [0.653788] virtio-pci :00:05.0: irq 43 for MSI/MSI-X [0.653811] virtio-pci :00:05.0: irq 44 for MSI/MSI-X [0.654532] vda: vda1 vda2 [0.813146] ata2.01: NODEV after polling detection [0.813919] ata2.00: ATAPI: QEMU DVD-ROM, 2.1.2, max UDMA/100 [0.814966] ata2.00: configured for MWDMA2 [0.816265] scsi 1:0:0:0: CD-ROMQEMU QEMU DVD-ROM 2.1. PQ: 0 ANSI: 5 [0.828633] sr0: scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray [0.828638] cdrom: Uniform CD-ROM driver Revision: 3.20 [0.828869] sr 1:0:0:0: Attached scsi CD-ROM sr0 [0.829893] sr 1:0:0:0: Attached scsi generic sg0 type 5 [0.900192] device-mapper: uevent: version 1.0.3 [0.900644] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-de...@redhat.com [0.936061] usb 1-1: new full-speed USB device number 2 using uhci_hcd [0.947446] EXT4-fs (dm-0): INFO: recovery required on readonly filesystem [0.947451] EXT4-fs (dm-0): write access will be enabled during recovery [0.959940] EXT4-fs (dm-0): recovery complete [0.961943] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) [1.097518] usb 1-1: New USB device found,
Re: bug#708346 please help, wlan not working
Quoting Vincent Blut vincent.deb...@free.fr: Le mar. 4 nov. 2014 à 19:20, perih...@openmail.cc a écrit : hello. Hi, i did a fresh network install of debian wheezy 7.7. i have kernel 3.2.0-4-amd64 i have a laptop toshiba sattelite pro C850 - 1HG with the RTL8723AE wireless lan card. Problem: Wireless Lan not working basically i have the same problem as dannycrafts on the debian user forum: http://forums.debian.net/viewtopic.php?t=114077 i also (like him) tried install firmware-realtek from wheezy-backports. no sucess. I can turn on and off a little red light with a keyboard shortcut for WLAN on/off but there is no WLAN available. Please what can I do? Wired network works fine of course. Also my Wireless Lan did work in the past with other Linux distributions. Well, according to: $git tag --contains c592e631bcec the driver for your network controller has been first added in Linux 3.8, so please check if the driver has been backported in the wheezy kernel using for example: $grep RTL8723AE /boot/config-$(uname -r) If this command reports nothing on the standard output, then I fear you’ll have to ask to the kernel team to backport this driver, or to use a more recent kernel version (from wheezy-backports for example). THIS COMMAND DIDNT GIVE ANY OUTPUT. SO YOU WERE RIGHT. AM I REACHING THE KERNEL TEAM WITH THIS EMAIL? I TRIED INSTALL KERNEL 3.16-0 AMD64 but encountered dependency problems with initramfs-tool. I tried install a more recent version of initramfs-tools but again another dependency problem. I never manually updated the kernel before. So I am pretty lost. Maybe it would be a good idea to just send everyone an update with a newer kernel to fix this driver problem also for other users? Thank you in advance. Cheers,Vincent - VFEmail.net - http://www.vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options!
Re: kernel crashes after soft lockups in xen domU
And some more information ... Am 2014-10-13 12:04, schrieb Jonas Meurer: Am 2014-08-19 12:26, schrieb Jonas Meurer: I encounter kernel crashes on an up-to-date Debian/Wheezy Xen domU with the stock kernel. The dom0 runs the same linux kernel and xen/4.1.4-3+deb7u1. the bug is still reproducible with the latest kernel and Xen packages from Debian Wheezy. Unfortunately it seems like a corner case, somehow related to the hardware setup. I'm unable to reproduce the crash on another Xen system with same kernel an Xen versions but different CPU and motherboard. The VM runs in production mode on the second Xen system since several weeks without one single crash. I've got a test system now where I'm able to reproduce the bug by putting the VM (a webserver) under heavy load with the help of siege and pylot. The VM crashes every time I put the webserver under heavy load, everytime with the same backtrace. I replaced the full system (all hardware components except the harddisks) with a new one in the meantime - and still the bug is repoducible. I'll try to describe the setup: Two Xen virtualization servers (xen1 and xen2), mirroring one block device with DRBD using a primary/secondary setup. The DRBD device holds LVM with the LVs for one single virtual machine (the webserver). This webserver runs an Apache2 daemon. The first virtualization server (xen1, the one that's live) runs rock stable, same for the webserver VM on top. No crashes, no exploding load. The second virtualization server (xen2) runs well as long as it's only secondary (i.e. no virtual machine started). As soon as I switch the DRBD primary to xen2 and start the webserver VM there, load on the webserver is unusual high, it becomes laggy and after some hours (sometimes minutes) it crashes like described in earlier mails. Now I created a test-VM on xen2 that is not on top of the DRBD device in order to factor out DRBD as reason. As already written, if I fire some HTTP requests against the Apache daemon on the test-VM, the VM crashes the same way. I first replaced memory modules and CPU by similar ones without results. Now I replaced the whole hardware (except harddisks) by another one - still the same crashes. So the question is: why does the VM run stable on xen1 while it crashes all the time on xen2. If I compare xen1 and xen2, only real difference is mainboard (Supermicro X8 on xen1; Supermicro X9 on xen2) and CPU (Xeon L5939 on xen1; E5-2609 on xen2) As a next step I'll put the harddisks into another X8/Xeon L5639 server system and try to reproduce the crashes there. My bet is that this system will not crash anymore. In other words, I guess that this very bug is only triggered with the X9 + E-2609 combination. Can I do anything additional to help debugging the bug? Shall I report it to Xen upstream or send it to lkml? Still the same question. Shall I send the bugreport to upstream? Unfortunately nobody from Debian Linux kernel and/or Xen team seems to care :-/ Cheers, jonas Regarding the hardware: the RAM was checked with memtest86+ and no errors found and the CPU has been replaced by a new one (same model). Still, the VM crash is reproducible. The hardware on the crashing system is: CPU: Intel Xeon E5-2609v2/4x2,5GHz Motherboard: Supermicro X9SRI-F For information, the hardware on non-crashing system is: CPU: Intel XEON L5639/6x2,13 GHz Motherboard: Supermicro X8STi It seems like the crashes are related to a RT process, even though no sched_fifo/rr processes are started on this system intentionally. Also, the CPU usage is low all the time, no peaks at all. But the kernel reports: kernel: [39101.461586] sched: RT throttling activated This is still valid, even though I no longer think that it's related to a RT process at all, as no sched_fifo/rr processes are started. Usually, a few minutes later, soft lockups start to happen, and then the system crashes: The backtrace is slightly different now due to kernel and Xen updates: [353013.384931] sched: RT throttling activated [354008.100835] BUG: soft lockup - CPU#5 stuck for 22s! [apache2:24848] [354008.100846] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_page_alloc aesni_intel snd_timer aes_x86_64 snd aes_generic soundcore cryptd pcspkr ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [354008.100872] CPU 5 [354008.100874] Modules linked in: evdev coretemp crc32c_intel ghash_clmulni_intel snd_pcm snd_page_alloc aesni_intel snd_timer aes_x86_64 snd aes_generic soundcore cryptd pcspkr ext4 crc16 jbd2 mbcache dm_mod xen_netfront xen_blkfront [354008.100894] [354008.100898] Pid: 24848, comm: apache2 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.60-1+deb7u3 [354008.100904] RIP: e030:[8100122a] [8100122a] hypercall_page+0x22a/0x1000 [354008.100914] RSP: e02b:8802f0b41c00 EFLAGS: 0246 [354008.100918] RAX: 00040001 RBX: 88020200 RCX: 8100122a [354008.100922] RDX:
Bug#763606: Confirmation
Dear maintainers, I have the same exact problem. I have a bridge over an ethernet NIC and an OpenVPN tap interface. Kernel 3.14-2-powerpc works correctly and 3.16-[23]—powerpc do not. The remote openvpn host can reach the bridge interface correctly and thus communicate with the host. However any other access of the remote host that should be forwarded from the openvpn tap interface through the ethernet interface does not work. I have used netsniff-ng over the remote tap interface, the local tap interface, the local bridge interface, and the local ethernet interface while making a DHCP request from the remote host that should be forwarded to the local network. In all cases the request packet was visible, but not the response. Find below some of the hardware details of my system just in case it helps. - /proc/cpuinfo - processor : 0 cpu : 7447A, altivec supported clock : 1333.28MHz revision : 1.5 (pvr 8003 0105) bogomips : 83.20 timebase : 41600661 platform : PowerMac model : PowerMac10,2 machine : PowerMac10,2 motherboard : PowerMac10,2 MacRISC3 Power Macintosh detected as : 287 (Mac mini (Late 2005)) pmac flags: 0010 L2 cache : 512K unified pmac-generation : NewWorld Memory: 1024 MB - /proc/cpuinfo end - 08: PCI 2200b.0: 0600 Host bridge [Created at pci.328] Unique ID: 7rcY.vkm17Jxs1m3 SysFS ID: /devices/pci0002:20/0002:20:0b.0 SysFS BusID: 0002:20:0b.0 Hardware Class: bridge Model: Apple UniNorth 2 Internal PCI Vendor: pci 0x106b Apple Inc. Device: pci 0x0036 UniNorth 2 Internal PCI Module Alias: pci:v106Bd0036svsdbc06sc00i00 Config Status: cfg=new, avail=yes, need=no, active=unknown 11: PCI 2200f.0: 0200 Ethernet controller [Created at pci.328] Unique ID: rBUF.nAQ7Jnazou0 SysFS ID: /devices/pci0002:20/0002:20:0f.0 SysFS BusID: 0002:20:0f.0 Hardware Class: network Model: Apple UniNorth 2 GMAC (Sun GEM) Vendor: pci 0x106b Apple Inc. Device: pci 0x0032 UniNorth 2 GMAC (Sun GEM) Revision: 0x80 Driver: gem Driver Modules: sungem Device File: eth0 Memory Range: 0xf520-0xf53f (rw,non-prefetchable) Memory Range: 0xf510-0xf51f (ro,non-prefetchable,disabled) IRQ: 41 (7184 events) HW Address: 00:11:24:*:*:* Link detected: yes Module Alias: pci:v106Bd0032svsdbc02sc00i00 Driver Info #0: Driver Status: sungem is active Driver Activation Cmd: modprobe sungem Config Status: cfg=new, avail=yes, need=no, active=unknown 12: PCI 11017.0: ff00 Unclassified device [Created at pci.328] Unique ID: tO0B.wjNr0SYqtL5 SysFS ID: /devices/pci0001:10/0001:10:17.0 SysFS BusID: 0001:10:17.0 Hardware Class: unknown Model: Apple KeyLargo/Intrepid Mac I/O Vendor: pci 0x106b Apple Inc. Device: pci 0x003e KeyLargo/Intrepid Mac I/O Driver: macio Memory Range: 0x8000-0x8007 (rw,non-prefetchable) Module Alias: pci:v106Bd003EsvsdbcFFsc00i00 Config Status: cfg=new, avail=yes, need=no, active=unknown 15: PCI 1100b.0: 0600 Host bridge [Created at pci.328] Unique ID: zM3W.OKqHekp9WN3 SysFS ID: /devices/pci0001:10/0001:10:0b.0 SysFS BusID: 0001:10:0b.0 Hardware Class: bridge Model: Apple UniNorth 2 PCI Vendor: pci 0x106b Apple Inc. Device: pci 0x0035 UniNorth 2 PCI Module Alias: pci:v106Bd0035svsdbc06sc00i00 Config Status: cfg=new, avail=yes, need=no, active=unknown Cheers, Josep M. Perez -- 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/f708a000-4d2e-4233-a543-91ddeb0b5...@gmail.com
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Wed, Nov 05, 2014 at 10:45:12AM +, Ian Campbell wrote: On Tue, 2014-11-04 at 22:37 +0100, Karsten Merker wrote: I have run further installation tests with today's current d-i images (still based on the same 3.16.5-1 kernel) OOI if you bodge your way through the install does the resulting system boot and discover the PHY reliably? IOW is it specific to d-i or not? Ethernet works in the installed system (tested with several cold and warm boots): [2.448442] stmmaceth 1c5.ethernet: no reset control found [2.454322] Ring mode enabled [2.457396] No HW DMA feature register supported [2.461941] Normal descriptors [2.465279] TX Checksum insertion supported [2.495563] libphy: stmmac: probed [2.499078] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [2.505490] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) i.e. the PHY appears to have a seperate regulator on the BananaPi but not on the Cubietruck and I wonder whether the startup-delay-us = 5; might play a role here. I think that's a decent theory. Decent enoguh that it is probably worth taking it up with the sunxi kernel folks. Might also be the power supply differs between the two boards? Running the BananaPi with the Cubietruck's power supply does not change the behaviour. I have now run several tests with a modified BananaPi dtb in which I have added a regulator-always-on stanza to the reg_gmac_3v3 definition. With this change the PHY detection in d-i has worked every time, so this would support the theory that the regulator might not be powered up fast enough for the PHY detection to succeed, but I cannot see why this problem only occurs within the d-i environment. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- 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/20141105200107.ga4...@excalibur.cnev.de
Re: kernel crashes after soft lockups in xen domU
On Wed, 2014-11-05 at 17:56 +0100, Jonas Meurer wrote: [...] So the question is: why does the VM run stable on xen1 while it crashes all the time on xen2. If I compare xen1 and xen2, only real difference is mainboard (Supermicro X8 on xen1; Supermicro X9 on xen2) and CPU (Xeon L5939 on xen1; E5-2609 on xen2) As a next step I'll put the harddisks into another X8/Xeon L5639 server system and try to reproduce the crashes there. My bet is that this system will not crash anymore. In other words, I guess that this very bug is only triggered with the X9 + E-2609 combination. Can I do anything additional to help debugging the bug? Shall I report it to Xen upstream or send it to lkml? Still the same question. Shall I send the bugreport to upstream? Unfortunately nobody from Debian Linux kernel and/or Xen team seems to care :-/ [...] Sorry you haven't had a response from us so far. This seems to be fairly clearly a Linux/Xen interaction and I don't know enough about Xen to suggest how to debug it. As it involves a relatively old kernel version, I don't think Linux upstream developers will want to hear about this unless you can also reproduce it with a more recent version. Linux 3.16 is available (in testing and wheezy-backports) if you would like to try that. I don't know whether the Xen upstream developers will accept a bug report against this version. Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Bug#759809: linux-image-3.2.0-4-amd64: USB 3 devices fail, logging xHCI xhci_drop_endpoint called with disabled ep ffff8802165db0c0
On Sat, Nov 1, 2014 at 3:16 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Sat, Nov 1, 2014 at 2:56 PM, Sedat Dilek sedat.di...@gmail.com wrote: [...] The problem was solved by updating to linux-image-3.2.0-4-amd64 (3.2.63-2+deb7u1). Just for the sake of completeness (and for Jari)... Here I have an ASM1042 chipset... Looks like that chip has also some troubles with UAS (see [1] xhci: Disable streams on Asmedia 1042 xhci controllers). Not sure if Linux-3.2.y has the xhci-quirks-handling implemented. - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-linusid=2391eacbd00b706ff4902db7dbee21e33b6f1850 -- 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/CA+icZUWDXGEyM65POP3HYXm=cnmfa_0rz1bt9gnksr4ndxo...@mail.gmail.com
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Wed, Nov 05, 2014 at 09:01:08PM +0100, Karsten Merker wrote: [Failing ethernet PHY detection in d-i on the BananaPi] I have now run several tests with a modified BananaPi dtb in which I have added a regulator-always-on stanza to the reg_gmac_3v3 definition. With this change the PHY detection in d-i has worked every time, so this would support the theory that the regulator might not be powered up fast enough for the PHY detection to succeed, but I cannot see why this problem only occurs within the d-i environment. Further experiments show that increasing the startup-delay-us value in the regulator definition seems to solve the issue. I'll do some further experiments to determine a value that is long enough for a reliable detection without being unnecessary long and discuss the issue with the upstream author. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- 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/20141105205240.gb4...@excalibur.cnev.de
Bug#768157: machine hangs when loading cirrus with modeset=1 while booted with vga=791
Control: tag -1 upstream confirmed On Wed, 2014-11-05 at 15:02 +0100, Evgeni Golov wrote: Package: src:linux Version: 3.16.7-1 Severity: normal Hi, while testing the new Grml release, I noticed an interesting hang of QEMU when the machine is booted. The initial testing was done using [1] in QEMU from Sid (2.1+dfsg-5), but I also could reproduce it with the same QEMU and a fresh Jessie install with both, 3.16.5-1 and 3.16.7-1. To reproduce: * boot a fresh Jessie with 3.16 kernel in QEMU and vga=791 as bootparam * modprobe cirrus modeset=1 * machine hangs I am not sure this will happen on real cirrus HW, as I don't have any, but QEMU is quite widespread and cirrus is the default VGA driver. [...] The cirrus KMS driver only binds to QEMU Cirrus devices, not real hardware. It has been working for me, but I can reproduce the apparent hang with the 'vga=791' parameter. It's not actually hanging, though - using a serial console, I see the error messages: [1.976874] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM [1.978067] cirrus :00:02.0: Fatal error during GPU init: -6 and I can log in there. But, as the driver detects this error after the point of no return (remove_conflicting_framebuffers()), the display remains broken. Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Bug#759809: linux-image-3.2.0-4-amd64: USB 3 devices fail, logging xHCI xhci_drop_endpoint called with disabled ep ffff8802165db0c0
On Wed, 2014-11-05 at 21:20 +0100, Sedat Dilek wrote: On Sat, Nov 1, 2014 at 3:16 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Sat, Nov 1, 2014 at 2:56 PM, Sedat Dilek sedat.di...@gmail.com wrote: [...] The problem was solved by updating to linux-image-3.2.0-4-amd64 (3.2.63-2+deb7u1). Just for the sake of completeness (and for Jari)... Here I have an ASM1042 chipset... Looks like that chip has also some troubles with UAS (see [1] xhci: Disable streams on Asmedia 1042 xhci controllers). Not sure if Linux-3.2.y has the xhci-quirks-handling implemented. We do not enable UAS. It is not even possible to enable it in 3.2. Ben. - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-linusid=2391eacbd00b706ff4902db7dbee21e33b6f1850 -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#768157: machine hangs when loading cirrus with modeset=1 while booted with vga=791
Processing control commands: tag -1 upstream confirmed Bug #768157 [src:linux] machine hangs when loading cirrus with modeset=1 while booted with vga=791 Added tag(s) upstream and confirmed. -- 768157: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768157 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: https://lists.debian.org/handler.s.b768157.141522168026733.transcr...@bugs.debian.org
Processed: closing 759809
Processing commands for cont...@bugs.debian.org: close 759809 3.2.63-2+deb7u1 Bug #759809 [src:linux] linux-image-3.2.0-4-amd64: USB 3 devices fail, logging xHCI xhci_drop_endpoint called with disabled ep 8802165db0c0 Marked as fixed in versions linux/3.2.63-2+deb7u1. Bug #759809 [src:linux] linux-image-3.2.0-4-amd64: USB 3 devices fail, logging xHCI xhci_drop_endpoint called with disabled ep 8802165db0c0 Marked Bug as done thanks Stopping processing here. Please contact me if you need assistance. -- 759809: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759809 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: https://lists.debian.org/handler.s.c.14152227301980.transcr...@bugs.debian.org
Bug#759809: linux-image-3.2.0-4-amd64: USB 3 devices fail, logging xHCI xhci_drop_endpoint called with disabled ep ffff8802165db0c0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-11-2014 kl. 19:07 Ben Hutchings wrote: On Sat, 2014-11-01 at 14:56 +0100, Sedat Dilek wrote: On Tue, Sep 9, 2014 at 4:03 PM, Sedat Dilek sedat.di...@gmail.com wrote: Hi, this looks like what I reported in [wheezy][linux-3.2.60] Booting from a Debian system on an external USB-3.0 hdd hangs (see [1]). Unfortunately, there is no newer 3.2.y kernel for wheezy available [2]. Henrik, did you try a Linux-kernel = 3.2.61 (self-compiled)? Thanks. Regards, - Sedat - [1] https://lists.debian.org/debian-kernel/2014/08/msg00141.html [2] http://anonscm.debian.org/viewvc/kernel/dists/wheezy/linux/ The problem was solved by updating to linux-image-3.2.0-4-amd64 (3.2.63-2+deb7u1). Henrik, can you confirm this is also fixed on your computer? Confirmed, upgraded to 3.2.63-2+deb7u1 and my disk works again using the xhci_hcd driver. Thanks :-) Regards, Henrik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVFqUSPADgvSOCWu5AQJ5fgf8CJB1SGP1g3CbdxldVGfCU4nFBLrMJpE+ mrxOiRzC13KSWrRVAfyWNgkaO5L+7UtiCNYu6qKo6wFmY74rxuPjYX0cQAu0LsP+ v0Bz6PyxZQGi0HMIvnutiRJAIvBi7TA0xa3W16QfL81dIvcQi+JTr/WSP7iin+6O wjX5eNVm84rlXxFP2OTBxR5AF8KQZSeThoLS5mtP9E0sKhorq+2nnjPQHxmtWMGq Hd8TMea+dAdSskFVA0EUbLj8mzVuzhMI2kaZvUezCNRiShAiOiK2u6Vr8Y6P5wOu tHAZOISwPk+uFU3YxeE7uy9IESq869rFWLGUumjjuv9nYXzJZdGlYw== =OQrN -END PGP SIGNATURE- -- 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/545a9449.90...@hswn.dk
Re: bug#708346 please help, wlan not working
[removing Sergio Talens-Oliag from the cc list] Le mar. 4 nov. 2014 à 19:20, perih...@openmail.cc a écrit : hello. Hi, i did a fresh network install of debian wheezy 7.7. i have kernel 3.2.0-4-amd64 i have a laptop toshiba sattelite pro C850 - 1HG with the RTL8723AE wireless lan card. Problem: Wireless Lan not working basically i have the same problem as dannycrafts on the debian user forum: http://forums.debian.net/viewtopic.php?t=114077 i also (like him) tried install firmware-realtek from wheezy-backports. no sucess. I can turn on and off a little red light with a keyboard shortcut for WLAN on/off but there is no WLAN available. Please what can I do? Wired network works fine of course. Also my Wireless Lan did work in the past with other Linux distributions. Well, according to: $git tag --contains c592e631bcec the driver for your network controller has been first added in Linux 3.8, so please check if the driver has been backported in the wheezy kernel using for example: $grep RTL8723AE /boot/config-$(uname -r) If this command reports nothing on the standard output, then I fear you’ll have to ask to the kernel team to backport this driver, or to use a more recent kernel version (from wheezy-backports for example). THIS COMMAND DIDNT GIVE ANY OUTPUT. SO YOU WERE RIGHT. Ben, is it too late in the Wheezy release cycle to backport the rtl8723ae driver? AM I REACHING THE KERNEL TEAM WITH THIS EMAIL? Yes you are ! But note that the debian-kernel mailing list is not the best place to keep track of bug reports. So please next time use the reportbug tool ;-) I TRIED INSTALL KERNEL 3.16-0 AMD64 but encountered dependency problems with initramfs-tool.I tried install a more recent version of initramfs-tools but again another dependency problem. I never manually updated the kernel before. So I am pretty lost. Maybe it would be a good idea to just send everyone an update with a newer kernel to fix this driver problem also for other users? Yes, a newer version of initramfs-tools is needed on your system because since linux 3.8.2-1~experimental.1, the *minimum* version of initramfs-tools has been increased to 0.110~ What method did you use to upgrade your kernel? -- 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/1415229629.1963.6.ca...@free.fr
Re: bug#708346 please help, wlan not working
On Thu, 2014-11-06 at 00:20 +0100, Vincent Blut wrote: [removing Sergio Talens-Oliag from the cc list] Le mar. 4 nov. 2014 à 19:20, perih...@openmail.cc a écrit : hello. Hi, i did a fresh network install of debian wheezy 7.7. i have kernel 3.2.0-4-amd64 i have a laptop toshiba sattelite pro C850 - 1HG with the RTL8723AE wireless lan card. Problem: Wireless Lan not working basically i have the same problem as dannycrafts on the debian user forum: http://forums.debian.net/viewtopic.php?t=114077 i also (like him) tried install firmware-realtek from wheezy-backports. no sucess. I can turn on and off a little red light with a keyboard shortcut for WLAN on/off but there is no WLAN available. Please what can I do? Wired network works fine of course. Also my Wireless Lan did work in the past with other Linux distributions. Well, according to: $git tag --contains c592e631bcec the driver for your network controller has been first added in Linux 3.8, so please check if the driver has been backported in the wheezy kernel using for example: $grep RTL8723AE /boot/config-$(uname -r) If this command reports nothing on the standard output, then I fear you’ll have to ask to the kernel team to backport this driver, or to use a more recent kernel version (from wheezy-backports for example). THIS COMMAND DIDNT GIVE ANY OUTPUT. SO YOU WERE RIGHT. Ben, is it too late in the Wheezy release cycle to backport the rtl8723ae driver? We would probably only upgrade wireless drivers as a separate package (compat-drivers) because the kernel's wireless driver API changes quite often. This will not happen for wheezy. AM I REACHING THE KERNEL TEAM WITH THIS EMAIL? Yes you are ! But note that the debian-kernel mailing list is not the best place to keep track of bug reports. So please next time use the reportbug tool ;-) I TRIED INSTALL KERNEL 3.16-0 AMD64 but encountered dependency problems with initramfs-tool.I tried install a more recent version of initramfs-tools but again another dependency problem. I never manually updated the kernel before. So I am pretty lost. Maybe it would be a good idea to just send everyone an update with a newer kernel to fix this driver problem also for other users? Yes, a newer version of initramfs-tools is needed on your system because since linux 3.8.2-1~experimental.1, the *minimum* version of initramfs-tools has been increased to 0.110~ What method did you use to upgrade your kernel? The sensible method is to install both the kernel and initramfs-tools from wheezy-backports. (initramfs-tools from jessie won't work without upgrading several other packages.) Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Bug#766802: linux-image-amd64: rt2800usb driver does not include 1b75:a200 USB id's as a supported device
Control: tag -1 fixed-upstream Martin Mokrejs mmokr...@fold.natur.cuni.cz (2014-11-02): Hi Cyril, I patched manually 3.15.3 kernel and no longer need to force loading of the rt2800usb driver in /etc/modprobe.d/ralink.conf nor explicitly call rt2800usb in /etc/modules. Also I disabled in the RT2800 driver some option to support loading of unsupported devices (don't have the .config handy to paste it correct name). Many thanks for the confirmation. Sorry that I didn't spot earlier that the patch had been merged in mainline in the meanwhile: commit 664d6a792785cc677c2091038ce10322c8d04ae1 Author: Cyril Brulebois k...@debian.org Date: Tue Oct 28 16:42:41 2014 +0100 wireless: rt2x00: add new rt2800usb device 0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle References: https://bugs.debian.org/766802 Reported-by: Martin Mokrejs mmokr...@fold.natur.cuni.cz Cc: sta...@vger.kernel.org Signed-off-by: Cyril Brulebois k...@debian.org Acked-by: Stanislaw Gruszka sgrus...@redhat.com Signed-off-by: John W. Linville linvi...@tuxdriver.com I only noticed today because of a notification about the addition to the staging queue of 3.13.y.z extended stable. The above-mentioned commit is part of v3.18-rc3. Mraw, KiBi. signature.asc Description: Digital signature
Processed: Re: Bug#766802: linux-image-amd64: rt2800usb driver does not include 1b75:a200 USB id's as a supported device
Processing control commands:
tag -1 fixed-upstream
Bug #766802 {Done: Ben Hutchings b...@decadent.org.uk} [src:linux]
linux-image-amd64: rt2800usb driver does not include 1b75:a200 USB id's as a
supported device
Added tag(s) fixed-upstream.
--
766802: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766802
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:
https://lists.debian.org/handler.s.b766802.14152387745672.transcr...@bugs.debian.org
linux_3.16.5-1~bpo70+1_multi.changes ACCEPTED into wheezy-backports, wheezy-backports
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 02 Nov 2014 01:07:24 + Source: linux Binary: linux-source-3.16 linux-doc-3.16 linux-manual-3.16 linux-support-3.16-0.bpo.3 linux-libc-dev linux-headers-3.16-0.bpo.3-all linux-headers-3.16-0.bpo.3-all-amd64 kernel-image-3.16-0.bpo.3-amd64-di nic-modules-3.16-0.bpo.3-amd64-di nic-wireless-modules-3.16-0.bpo.3-amd64-di nic-shared-modules-3.16-0.bpo.3-amd64-di serial-modules-3.16-0.bpo.3-amd64-di usb-serial-modules-3.16-0.bpo.3-amd64-di ppp-modules-3.16-0.bpo.3-amd64-di pata-modules-3.16-0.bpo.3-amd64-di cdrom-core-modules-3.16-0.bpo.3-amd64-di firewire-core-modules-3.16-0.bpo.3-amd64-di scsi-core-modules-3.16-0.bpo.3-amd64-di scsi-modules-3.16-0.bpo.3-amd64-di scsi-common-modules-3.16-0.bpo.3-amd64-di scsi-extra-modules-3.16-0.bpo.3-amd64-di loop-modules-3.16-0.bpo.3-amd64-di btrfs-modules-3.16-0.bpo.3-amd64-di ext4-modules-3.16-0.bpo.3-amd64-di isofs-modules-3.16-0.bpo.3-amd64-di jfs-modules-3.16-0.bpo.3-amd64-di ntfs-modules-3.16-0.bpo.3-amd64-di xfs-modules-3.16-0.bpo.3-amd64-di fat-modules-3.16-0.bpo.3-amd64-di md-modules-3.16-0.bpo.3-amd64-di multipath-modules-3.16-0.bpo.3-amd64-di usb-modules-3.16-0.bpo.3-amd64-di usb-storage-modules-3.16-0.bpo.3-amd64-di pcmcia-storage-modules-3.16-0.bpo.3-amd64-di fb-modules-3.16-0.bpo.3-amd64-di input-modules-3.16-0.bpo.3-amd64-di event-modules-3.16-0.bpo.3-amd64-di mouse-modules-3.16-0.bpo.3-amd64-di nic-pcmcia-modules-3.16-0.bpo.3-amd64-di pcmcia-modules-3.16-0.bpo.3-amd64-di nic-usb-modules-3.16-0.bpo.3-amd64-di sata-modules-3.16-0.bpo.3-amd64-di core-modules-3.16-0.bpo.3-amd64-di acpi-modules-3.16-0.bpo.3-amd64-di i2c-modules-3.16-0.bpo.3-amd64-di crc-modules-3.16-0.bpo.3-amd64-di crypto-modules-3.16-0.bpo.3-amd64-di crypto-dm-modules-3.16-0.bpo.3-amd64-di efi-modules-3.16-0.bpo.3-amd64-di ata-modules-3.16-0.bpo.3-amd64-di mmc-core-modules-3.16-0.bpo.3-amd64-di mmc-modules-3.16-0.bpo.3-amd64-di nbd-modules-3.16-0.bpo.3-amd64-di squashfs-modules-3.16-0.bpo.3-amd64-di speakup-modules-3.16-0.bpo.3-amd64-di virtio-modules-3.16-0.bpo.3-amd64-di uinput-modules-3.16-0.bpo.3-amd64-di sound-modules-3.16-0.bpo.3-amd64-di hyperv-modules-3.16-0.bpo.3-amd64-di udf-modules-3.16-0.bpo.3-amd64-di fuse-modules-3.16-0.bpo.3-amd64-di linux-headers-3.16-0.bpo.3-common linux-image-3.16-0.bpo.3-amd64 linux-headers-3.16-0.bpo.3-amd64 linux-image-3.16-0.bpo.3-amd64-dbg xen-linux-system-3.16-0.bpo.3-amd64 linux-headers-3.16-0.bpo.3-all-armel kernel-image-3.16-0.bpo.3-kirkwood-di nic-modules-3.16-0.bpo.3-kirkwood-di nic-shared-modules-3.16-0.bpo.3-kirkwood-di usb-serial-modules-3.16-0.bpo.3-kirkwood-di ppp-modules-3.16-0.bpo.3-kirkwood-di cdrom-core-modules-3.16-0.bpo.3-kirkwood-di scsi-core-modules-3.16-0.bpo.3-kirkwood-di loop-modules-3.16-0.bpo.3-kirkwood-di btrfs-modules-3.16-0.bpo.3-kirkwood-di ext4-modules-3.16-0.bpo.3-kirkwood-di isofs-modules-3.16-0.bpo.3-kirkwood-di jfs-modules-3.16-0.bpo.3-kirkwood-di fat-modules-3.16-0.bpo.3-kirkwood-di minix-modules-3.16-0.bpo.3-kirkwood-di md-modules-3.16-0.bpo.3-kirkwood-di multipath-modules-3.16-0.bpo.3-kirkwood-di usb-modules-3.16-0.bpo.3-kirkwood-di usb-storage-modules-3.16-0.bpo.3-kirkwood-di fb-modules-3.16-0.bpo.3-kirkwood-di input-modules-3.16-0.bpo.3-kirkwood-di event-modules-3.16-0.bpo.3-kirkwood-di mouse-modules-3.16-0.bpo.3-kirkwood-di nic-usb-modules-3.16-0.bpo.3-kirkwood-di sata-modules-3.16-0.bpo.3-kirkwood-di core-modules-3.16-0.bpo.3-kirkwood-di crc-modules-3.16-0.bpo.3-kirkwood-di crypto-modules-3.16-0.bpo.3-kirkwood-di crypto-dm-modules-3.16-0.bpo.3-kirkwood-di mmc-modules-3.16-0.bpo.3-kirkwood-di nbd-modules-3.16-0.bpo.3-kirkwood-di squashfs-modules-3.16-0.bpo.3-kirkwood-di uinput-modules-3.16-0.bpo.3-kirkwood-di leds-modules-3.16-0.bpo.3-kirkwood-di udf-modules-3.16-0.bpo.3-kirkwood-di fuse-modules-3.16-0.bpo.3-kirkwood-di kernel-image-3.16-0.bpo.3-orion5x-di nic-modules-3.16-0.bpo.3-orion5x-di nic-shared-modules-3.16-0.bpo.3-orion5x-di usb-serial-modules-3.16-0.bpo.3-orion5x-di ppp-modules-3.16-0.bpo.3-orion5x-di cdrom-core-modules-3.16-0.bpo.3-orion5x-di scsi-core-modules-3.16-0.bpo.3-orion5x-di loop-modules-3.16-0.bpo.3-orion5x-di ipv6-modules-3.16-0.bpo.3-orion5x-di btrfs-modules-3.16-0.bpo.3-orion5x-di ext4-modules-3.16-0.bpo.3-orion5x-di isofs-modules-3.16-0.bpo.3-orion5x-di jffs2-modules-3.16-0.bpo.3-orion5x-di jfs-modules-3.16-0.bpo.3-orion5x-di fat-modules-3.16-0.bpo.3-orion5x-di minix-modules-3.16-0.bpo.3-orion5x-di md-modules-3.16-0.bpo.3-orion5x-di multipath-modules-3.16-0.bpo.3-orion5x-di usb-modules-3.16-0.bpo.3-orion5x-di usb-storage-modules-3.16-0.bpo.3-orion5x-di event-modules-3.16-0.bpo.3-orion5x-di nic-usb-modules-3.16-0.bpo.3-orion5x-di sata-modules-3.16-0.bpo.3-orion5x-di core-modules-3.16-0.bpo.3-orion5x-di crc-modules-3.16-0.bpo.3-orion5x-di crypto-modules-3.16-0.bpo.3-orion5x-di crypto-dm-modules-3.16-0.bpo.3-orion5x-di
