Bug#703390: This bug cannot be reproduced in Kernel 3.8.2 in experimental
I have tried the kernel you mentioned, and the bug also does not exist in this version.
Bug#703390: This bug cannot be reproduced in Kernel 3.8.2 in experimental
No, this bug occurs again just after I sent the mail. So I think maybe I should report the bug to bugs.freedesktop.org. 2013/3/19 SuperCat supercatexp...@gmail.com I have tried the kernel you mentioned, and the bug also does not exist in this version.
Bug#703390: This bug cannot be reproduced in Kernel 3.8.2 in experimental
I have report the bug to freedebug.org, and the link is: https://bugs.freedesktop.org/show_bug.cgi?id=62507 2013/3/19 SuperCat supercatexp...@gmail.com No, this bug occurs again just after I sent the mail. So I think maybe I should report the bug to bugs.freedesktop.org. 2013/3/19 SuperCat supercatexp...@gmail.com I have tried the kernel you mentioned, and the bug also does not exist in this version.
Bug#703209: linux: Please Add multiplatform flavour to armhf
Ben Hutchings b...@decadent.org.uk writes: Hi, On Mon, 2013-03-18 at 08:41 +0900, Nobuhiro Iwamatsu wrote: Hi, Thank you for your comment. On Sun, Mar 17, 2013 at 10:23 AM, Ben Hutchings b...@decadent.org.uk wrote: On Sun, 2013-03-17 at 08:35 +0900, Nobuhiro Iwamatsu wrote: Package: linux Version: 3.8.2-1~experimental.1 Severity: wishlist Tags: patch Hi, From linux 3.8, support of armada 370/xp was added in arm. This is classified into the armhf architecture of debian. First I began and thought that an armada flavor would be added. When I consulted about this in debian-arm ML, I got advice from several developers what multiplatform flavour was better than armada flavour[0]. Since arm is developed toward multiplatform from now on, I think that multiplatform is desirable. Although there is still little SoC which is supporting multiplatform, I would like to support armada 370/xp (mach-mvebu) first. I created the patch which supports this. Please check and apply. In future all ARM kernels should be multi-platform, but I expect there will still be different flavours, such as for LPAE or the RT featureset. I would much prefer a name that will provide a more useful distinction in future (and not be too long!). Perhaps it should refer to the CPU requirement like the flavours for some other architectures. I see. Although it is very simple, how is armmp? armmp is imho confusing. There are some Marvell platforms called MMP. [...] Sounds alright to be, but let's allow the other ARM porters a few more days to comment. I already commented some days ago on debian-arm that currently multiplatform support must wait. It is useless as usb support is _broken_ on multiplatform. Hopefully, Linaro devs seem back to work and looks like we may have a patch merged soon. Until then, doing more is near to a waste of time. And about the patch in this bug, it fails to be really multiplatform. During my tests on 3.8, I could already enable platforms like MVEBU, HIGHBANK, BCM, MXC and you can enable OMAP too with 2-3 backports. Once done, it needs to be tested on real platforms as it would probably allow to detect some more bugs. 3.9 may be better. On the long term, we'll have also to consider if we should keep omap/mx5/vexpress or not. If we remove them, we should make sure that the transition will work nicely. Arnaud -- 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/87zjxzbzqm@lebrac.rtp-net.org
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Sun, Mar 17, 2013 at 9:23 AM, Ben Hutchings wrote: I would much prefer a name that will provide a more useful distinction in future (and not be too long!). Perhaps it should refer to the CPU requirement like the flavours for some other architectures. How about the same scheme as on other arches? linux-image-`uname -r`-armel linux-image-`uname -r`-armhf linux-image-`uname -r`-arm64 Or maybe the CPU is better: linux-image-`uname -r`-armv4 linux-image-`uname -r`-armv7 linux-image-`uname -r`-armv8 -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6gbw+qkddwj_sefrmumjue3xm9utybf4oddjzzjiaj...@mail.gmail.com
Bug#703356: megasas: Failed to alloc kernel SGL buffer for IOCTL (ref.#688198)
Jean-Francois Chevrette jf.cr...@gmail.com writes: Package: src:linux Version: 3.2.39-2 Severity: important (first time submiting to a bug report, sorry if I missed anything) We are still affected by bug #688198 Yes, I see that it was closed after applying a related bugfix. But as I noted in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688198#25 the reported bug would not be fixed by this after all. The fixed bug was real, but unrelated to the reported one. We have other seemingly identical servers (hardware software) and not all of them have this problem. Is there anything else I can provide to help? The message indicates a memory allocation problem related to sending management commands from userspace to the driver/controller. Management commands are e.g. requests from smartctl, raid monitoring etc. All data transferred between these userspace applications and the controller must be copied to/from dma-coherent buffers for transfer to the controller, and it is the allocation of these buffers which fails. Either because the requests are so bogus (too many or too big) that they just cannot be serviced, or because the system is out of memory in the appropriate pool. Maybe we can get some ideas about why this fails if you describe the conditions you experience the problem under. I believe the fact that you only see this on some of otherwise identical servers is very interesting. If we could find some pattern here, then that would help. Is there some special monitoring application running on the failing servers? Are there other devices in these servers which may have drivers eating memory? I can't, but maybe the Debian kernel gurus can read something out of /proc/slabinfo /proc/buddyinfo /proc/pagetypeinfo Comparing those files on a failing server and a non-failing server would certainly be interesting. Bjørn -- 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/87zjxz241l@nemi.mork.no
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Tue, 2013-03-19 at 03:46 +, Ben Hutchings wrote: On Mon, 2013-03-18 at 08:41 +0900, Nobuhiro Iwamatsu wrote: On Sun, Mar 17, 2013 at 10:23 AM, Ben Hutchings b...@decadent.org.uk wrote: [...] In future all ARM kernels should be multi-platform, but I expect there will still be different flavours, such as for LPAE or the RT featureset. I would much prefer a name that will provide a more useful distinction in future (and not be too long!). Perhaps it should refer to the CPU requirement like the flavours for some other architectures. I see. Although it is very simple, how is armmp? [...] Sounds alright to be, but let's allow the other ARM porters a few more days to comment. 'MP' has some history as meaning multi-processor, so might be confusing. (But perhaps not confusing to many.) -- Tixy -- 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/1363680223.3247.8.ca...@computer5.home
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Tue, 2013-03-19 at 08:44 +0100, Arnaud Patard wrote: I already commented some days ago on debian-arm that currently multiplatform support must wait. It is useless as usb support is _broken_ on multiplatform. Hopefully, Linaro devs seem back to work and looks like we may have a patch merged soon. Until then, doing more is near to a waste of time. I don't think making a start on a MP flavour is a waste of time at all. We are talking about packages in trunk (currently == experimental) rather than Sid/Wheezy. There's no possibility of us releasing anything with 3.8 but in the meantime adding the multiplatform flavour allows us to start laying the packaging ground work, finding bugs in the MP stuff and generally kicking the tyres etc. It's also an obvious step in the right direction. As you say the known issues, like the USB think, will be fixed upstream sooner rather than later. Since we are currently not yet talking about removing existing flavours I'm not sure there are any downsides to just doing it. And about the patch in this bug, it fails to be really multiplatform. During my tests on 3.8, I could already enable platforms like MVEBU, HIGHBANK, BCM, MXC and you can enable OMAP too with 2-3 backports. Once done, it needs to be tested on real platforms as it would probably allow to detect some more bugs. 3.9 may be better. This patch is a start though and doesn't preclude adding those other platforms either straight away or when 3.9 comes around as we like. Having the flavour would also enable testing on real platforms so that isn't a reason to wait IMHO. On the long term, we'll have also to consider if we should keep omap/mx5/vexpress or not. If we remove them, we should make sure that the transition will work nicely. Ack. Ian. -- 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/1363682093.2891.9.ca...@dagon.hellion.org.uk
Re: XFS contention fix backport (3.5 - 3.2) feasible?
On 3/19/13 4:44 , Ben Hutchings wrote: Having read this: http://thread.gmane.org/gmane.linux.kernel.stable/45323/focus=50810 my impression is that backporting XFS changes is fraught with peril. So anyone who wants to do that had better get the result properly reviewed and tested. (There is a test suite available called xfstests; and it's actually supposed to be useful for other POSIX filesystems as well.) I don't have the time to go through all that, so I personally won't work on it. Ok, thanks for the update. Best, Oliver -- 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/51482964.5070...@aei.mpg.de
Bug#664767: Brcmsmac driver woes, possible regression?
2013/3/18 Jonathan Nieder jrnie...@gmail.com: Camaleón wrote: El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió: Sorry to hear. Reading back the bug report I noticed you are having a bcm4313 and we recently had a regression on it. Could you provide debugfs information from debugfs_mount/brcmsmac/bcma0:0/hardware I see. My /sys/kernel/debug/* directory is empty mount -t debugfs debugfs /sys/kernel/debug Perfect, thanks. root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware board vendor: 103c board type: 145c board revision: 2209 board flags: 8002a00 board flags2: 800 firmware revision: 262032b Now let's see how reverting the patch makes any difference as soon as I can compile the module. I will keep you updated Greetings, -- Camaleón -- 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/CAKprTDFXV4J7cxGqNck95Cu=ncbxcfdntir40awrtxjplpo...@mail.gmail.com
Bug#703356: megasas: Failed to alloc kernel SGL buffer for IOCTL (ref.#688198)
Jean-Francois Chevrette jf.cr...@gmail.com writes: On Tue, Mar 19, 2013 at 4:21 AM, Bjørn Mork bj...@mork.no wrote: Maybe we can get some ideas about why this fails if you describe the conditions you experience the problem under. This server is running Xen 4.1 and a single VM. Nothing fancy there. It's also running DRBD to replicate a device to another server. It's also running a few userland tools for monitoring (nagios) and graphing (munin). Other than that nothing fancy. Nagios is the one calling MegaCli to monitor the array consistency. One thing to note is that after a server reboot, the MegaCli tool works fine for a while. This does sounds like there's leak somewhere. I just found out that this server is also running a service called MegaRAID Storage Manager which is a tool provided by LSI to manage the array through a java GUI. Maybe this tool is somehow causing this problem. That sounds like a very likely suspect, yes. Stopping it didn't solve the problem. I'll try disabling the tool and reboot without ever starting it to see if the problem occurs again. Good. If that works then we probably should find out what this tool does to trigger the problem, so that it can be handled properly by the driver. Bjørn -- 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/87mwtz1qma@nemi.mork.no
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Tue, 2013-03-19 at 08:03 +, Tixy wrote: On Tue, 2013-03-19 at 03:46 +, Ben Hutchings wrote: On Mon, 2013-03-18 at 08:41 +0900, Nobuhiro Iwamatsu wrote: On Sun, Mar 17, 2013 at 10:23 AM, Ben Hutchings b...@decadent.org.uk wrote: [...] In future all ARM kernels should be multi-platform, but I expect there will still be different flavours, such as for LPAE or the RT featureset. I would much prefer a name that will provide a more useful distinction in future (and not be too long!). Perhaps it should refer to the CPU requirement like the flavours for some other architectures. I see. Although it is very simple, how is armmp? [...] Sounds alright to be, but let's allow the other ARM porters a few more days to comment. 'MP' has some history as meaning multi-processor, so might be confusing. (But perhaps not confusing to many.) All multi-platform configurations will have to be multi-processor as well, so that shouldn't matter too much. Ben. -- Ben Hutchings When you say `I wrote a program that crashed Windows', people just stare ... and say `Hey, I got those with the system, *for free*'. - Linus Torvalds signature.asc Description: This is a digitally signed message part
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Tue, 2013-03-19 at 16:13 +0800, Paul Wise wrote: On Sun, Mar 17, 2013 at 9:23 AM, Ben Hutchings wrote: I would much prefer a name that will provide a more useful distinction in future (and not be too long!). Perhaps it should refer to the CPU requirement like the flavours for some other architectures. How about the same scheme as on other arches? linux-image-`uname -r`-armel I think the question here is what the `uname -r` bit should be. Specifically the $FLAVOUR in 3.x.y-z-$FLAVOUR. I think there is an argument for making the multiplatform case be the default no-flavour flavour i.e. $FLAVOUR is armhf/arm64 etc. Or maybe that's what you are suggesting having not realised that `uname -r` currently includes the -$FLAVOUR suffix. Hrm, I think we may actually be talking about the same thing ;-) linux-image-`uname -r`-armhf linux-image-`uname -r`-arm64 Or maybe the CPU is better: linux-image-`uname -r`-armv4 linux-image-`uname -r`-armv7 linux-image-`uname -r`-armv8 -- bye, pabs http://wiki.debian.org/PaulWise -- 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/1363705537.2891.41.ca...@dagon.hellion.org.uk
Processing of linux_3.8.3-1~experimental.1_multi.changes
linux_3.8.3-1~experimental.1_multi.changes uploaded successfully to localhost along with the files: linux_3.8.3-1~experimental.1.dsc linux_3.8.3.orig.tar.xz linux_3.8.3-1~experimental.1.debian.tar.xz linux-support-3.8-trunk_3.8.3-1~experimental.1_all.deb linux-doc-3.8_3.8.3-1~experimental.1_all.deb linux-manual-3.8_3.8.3-1~experimental.1_all.deb linux-source-3.8_3.8.3-1~experimental.1_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- 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/e1uhy1n-0002bb...@franck.debian.org
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Tue, 2013-03-19 at 15:05 +, Ian Campbell wrote: I think the question here is what the `uname -r` bit should be. Specifically the $FLAVOUR in 3.x.y-z-$FLAVOUR. Woops, I missed that uname -r includes the flavour bit. I think there is an argument for making the multiplatform case be the default no-flavour flavour i.e. $FLAVOUR is armhf/arm64 etc. Or maybe that's what you are suggesting having not realised that `uname -r` currently includes the -$FLAVOUR suffix. Hrm, I think we may actually be talking about the same thing ;-) Right, my suggestion is just to use the architecture for the flavour, as is done on the other architectures. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#703370: No more problems after increasing frame buffer size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Jonathan, Thank you for the fast response and for the hint with kernel 3.8.2. Possibly, i have found the issue. Kernel 3.8.2 from experimental: === After installing kernel 3.8.2 from experimental, the gnome shell didn't start. Reason was a too small frame buffer size with 32MB in UEFI. The output from dmesg: [8.118003] radeon_gem_object_create:69 alloc size 64Mb bigger than 32Mb limit [8.132380] radeon_gem_object_create:69 alloc size 64Mb bigger than 32Mb limit [8.132574] radeon_gem_object_create:69 alloc size 64Mb bigger than 32Mb limit [8.132629] gnome-shell[2737]: segfault at 14 ip 7f5da2b5865d sp 7fff8af907b0 error 4 in r600_dri.so[7f5da28a+d05000] [9.233377] radeon_gem_object_create:69 alloc size 64Mb bigger than 32Mb limit [9.247754] radeon_gem_object_create:69 alloc size 64Mb bigger than 32Mb limit [9.247957] radeon_gem_object_create:69 alloc size 64Mb bigger than 32Mb limit [9.248014] gnome-shell[2785]: segfault at 14 ip 7f99356b065d sp 7fff2c699900 error 4 in r600_dri.so[7f99353f8000+d05000] After increasing the frame buffer size from 32MB to 64MB, gnome shell starts without any errors. There is no error message regarding the radeon-drm problem described in my bug report. Kernel 3.2.39-2 from testing: = After increasing the frame buffer size to 64MB, the error message described in my bug report is no more in /var/log/syslog. Sorry for the trouble and hope that helps, I have to say thank you for your support and for the Debian distribution. - From my side, you can close this bug report. Best regards Bernhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJRSImlAAoJEDWlcaaSSHRw+QkP/A+T+sRAXNM41CSFNk695IR4 iF0HumTDiy2t/8ND0KbKEv6g9YbBizgyNJIUICiJ/QxUl19FdduDFOUv1LcecsAZ yd5f8j0pXfNV9MHSEL2yp6JP0rjZSFuNP4qnYF2axKzWTX8iMFELVUCyfxpQkgsZ S4pe+ONstxXUwq4zNC1qZGeSo8rJe/9ANxwHk48iaO20mxRlWmZmHn6M0iT7gUip Sn7X+Lma2FkM8bEWC8gIUl43a2Gsod0RXar/3BteQIwgeQqO2qAYcB9gkeRW+/yo TUZ/hN8sVaiy0eDZ5tE5Kb1Fsf7lc6CeYpXlp32I4rOcnYEUnFkonbLZyQFb7KNV VD/4Qlrp2tEjv8xm7hbkbb9rnK/IsteUv1faXA40qUTJTVkNmhTsnGDQhp5P5zB2 t6LVMHZ19pBBnauiMngaVaJH+5L90xzHiHvAkIBFyPUC0V9BhvtJ/56YE7EPk19x i46DeppyyfPP7sUNeOMZ7v29AEHENXHoxhtNiZ5M/1j3qSJ9b8YtxCfX0A+g9oHl Txo7u8pqkmJz9VLY0KBJewNOFJl48cIiFyxuiQ5Wzhc66VhSsnnJW+DBUh0sNZjt VwrblJuoJ64DfUCxE+78IrxkZrvRAEQM7XaJSKau0NxEk7VxZVJYvBSXsh6EskK2 aDT8er5NCXTvgK4MSfIh =+p+2 -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: http://lists.debian.org/514889b9.4030...@yahoo.de
Bug#664767: Brcmsmac driver woes, possible regression?
On Tue, 2013-03-19 at 17:21 +0100, Camaleón wrote: 2013/3/19 Camaleón noela...@gmail.com: 2013/3/18 Jonathan Nieder jrnie...@gmail.com: Camaleón wrote: El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió: Sorry to hear. Reading back the bug report I noticed you are having a bcm4313 and we recently had a regression on it. Could you provide debugfs information from debugfs_mount/brcmsmac/bcma0:0/hardware I see. My /sys/kernel/debug/* directory is empty mount -t debugfs debugfs /sys/kernel/debug Perfect, thanks. root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware board vendor: 103c board type: 145c board revision: 2209 board flags: 8002a00 board flags2: 800 firmware revision: 262032b Now let's see how reverting the patch makes any difference as soon as I can compile the module. I will keep you updated Update: applied the patch to revert the other patch but I still cannot get the driver to work (see attached syslog). N-M still asks for password until desists :-( Note that NM 0.9.8 won't ask for a password when just anything fails, but will ask for a password if the 4-way handshake fails, because if that fails, it's probably your password. We're contemplating getting rid of that too, and just notifying the user that their password may be wrong and that they should go update it in the network configuration panel so we don't interrupt. But if you're 100% sure your PSK is correct, then it is, most likely, a driver bug. Dan -- 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/1363711989.2225.8.ca...@dcbw.foobar.com
Bug#701743: [linux-image-3.2.0-4-amd64] radeon driver breaks gnome-shell on Radeon HD 6670/TURKS GPU
Am Donnerstag, den 28.02.2013, 16:52 +0100 schrieb Julien Cristau: On Tue, Feb 26, 2013 at 18:27:11 +0100, Bruno Kleinert wrote: Package: linux-image-3.2.0-4-amd64 Version: 3.2.39-1 Severity: normal --- Please enter the report below this line. --- Hi there, GNOME shell gets broken with this kernel version on my Radeon HD 6670/TURKS generation GPU. GDM3 still works, but it seems as soon as gnome-shell wants to use GPU acceleration the whole screen gets scrambled. Only the mousecursor appears normally and it can be moved around. dmesg spits out a lot of messages like those: Is this reproducible with 3.4.x? No it isn't. By the help of kernel-package I built a vanilla 3.4.0 kernel package, installed and booted it. I reused the Debian's 3.2 kernel configuration from 3.2.35-2 as input to make oldconfig and accepted the default answers for all kernel config questions added in the 3.4.0 kernel. Though gnome-shell works, I see the following warning in dmesg: [ 29.387744] radeon :02:00.0: evergreen_cs_track_validate_texture:796 texture bo too small (layer size 7526400, offset 0, max layer 1, depth 1, bo size 7299072) (1792 1050) [ 29.387758] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! Greetings - Fuddl signature.asc Description: This is a digitally signed message part
Bug#664767: Brcmsmac driver woes, possible regression?
El 2013-03-19 a las 11:53 -0500, Dan Williams escribió: On Tue, 2013-03-19 at 17:21 +0100, Camaleón wrote: 2013/3/19 Camaleón noela...@gmail.com: 2013/3/18 Jonathan Nieder jrnie...@gmail.com: Camaleón wrote: El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió: Sorry to hear. Reading back the bug report I noticed you are having a bcm4313 and we recently had a regression on it. Could you provide debugfs information from debugfs_mount/brcmsmac/bcma0:0/hardware I see. My /sys/kernel/debug/* directory is empty mount -t debugfs debugfs /sys/kernel/debug Perfect, thanks. root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware board vendor: 103c board type: 145c board revision: 2209 board flags: 8002a00 board flags2: 800 firmware revision: 262032b Now let's see how reverting the patch makes any difference as soon as I can compile the module. I will keep you updated Update: applied the patch to revert the other patch but I still cannot get the driver to work (see attached syslog). N-M still asks for password until desists :-( Note that NM 0.9.8 won't ask for a password when just anything fails, but will ask for a password if the 4-way handshake fails, because if that fails, it's probably your password. We're contemplating getting rid of that too, and just notifying the user that their password may be wrong and that they should go update it in the network configuration panel so we don't interrupt. But if you're 100% sure your PSK is correct, then it is, most likely, a driver bug. Password is correct. I have a second wireless card (external, using rt2800usb driver) that connects without a glitch to the same AP. Moreover, unless I type the right password, N-M dialog does not allow me to click on the Connect button. Greetings, -- Camaleón -- 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/20130319173054.ga7...@stt008.linux.site
Bug#664767: Brcmsmac driver woes, possible regression?
On Tue, 2013-03-19 at 18:30 +0100, Camaleón wrote: El 2013-03-19 a las 11:53 -0500, Dan Williams escribió: On Tue, 2013-03-19 at 17:21 +0100, Camaleón wrote: 2013/3/19 Camaleón noela...@gmail.com: 2013/3/18 Jonathan Nieder jrnie...@gmail.com: Camaleón wrote: El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió: Sorry to hear. Reading back the bug report I noticed you are having a bcm4313 and we recently had a regression on it. Could you provide debugfs information from debugfs_mount/brcmsmac/bcma0:0/hardware I see. My /sys/kernel/debug/* directory is empty mount -t debugfs debugfs /sys/kernel/debug Perfect, thanks. root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware board vendor: 103c board type: 145c board revision: 2209 board flags: 8002a00 board flags2: 800 firmware revision: 262032b Now let's see how reverting the patch makes any difference as soon as I can compile the module. I will keep you updated Update: applied the patch to revert the other patch but I still cannot get the driver to work (see attached syslog). N-M still asks for password until desists :-( Note that NM 0.9.8 won't ask for a password when just anything fails, but will ask for a password if the 4-way handshake fails, because if that fails, it's probably your password. We're contemplating getting rid of that too, and just notifying the user that their password may be wrong and that they should go update it in the network configuration panel so we don't interrupt. But if you're 100% sure your PSK is correct, then it is, most likely, a driver bug. Password is correct. I have a second wireless card (external, using rt2800usb driver) that connects without a glitch to the same AP. Moreover, unless I type the right password, N-M dialog does not allow me to click on the Connect button. NM minimally verifies the PSK, which by 802.11 standards is between 8 and 63 ASCII characters inclusive. So you should be able to type anything you want within those constraints, but clearly only one is your real PSK. Dan -- 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/1363715961.2225.22.ca...@dcbw.foobar.com
Bug#664767: Brcmsmac driver woes, possible regression?
El 2013-03-19 a las 12:59 -0500, Dan Williams escribió: On Tue, 2013-03-19 at 18:30 +0100, Camaleón wrote: El 2013-03-19 a las 11:53 -0500, Dan Williams escribió: Note that NM 0.9.8 won't ask for a password when just anything fails, but will ask for a password if the 4-way handshake fails, because if that fails, it's probably your password. We're contemplating getting rid of that too, and just notifying the user that their password may be wrong and that they should go update it in the network configuration panel so we don't interrupt. But if you're 100% sure your PSK is correct, then it is, most likely, a driver bug. Password is correct. I have a second wireless card (external, using rt2800usb driver) that connects without a glitch to the same AP. Moreover, unless I type the right password, N-M dialog does not allow me to click on the Connect button. NM minimally verifies the PSK, which by 802.11 standards is between 8 and 63 ASCII characters inclusive. So you should be able to type anything you want within those constraints, but clearly only one is your real PSK. Oops! Okay, so what user inputs is not bullet-proof. Anyway, this does not seem to be a problem of bad password. I was finally able to get connected to the AP as soon as I carry the nebook and put it next to the AP which is the problem I've always have had with this driver (brcmsmac). As soon as I back to another room, N-M asks me again for the pass-key and disconnects. Greetings, -- Camaleón -- 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/20130319181135.ga7...@stt008.linux.site
Bug#664767: Brcmsmac driver woes, possible regression?
On Tue, 2013-03-19 at 19:11 +0100, Camaleón wrote: El 2013-03-19 a las 12:59 -0500, Dan Williams escribió: On Tue, 2013-03-19 at 18:30 +0100, Camaleón wrote: El 2013-03-19 a las 11:53 -0500, Dan Williams escribió: Note that NM 0.9.8 won't ask for a password when just anything fails, but will ask for a password if the 4-way handshake fails, because if that fails, it's probably your password. We're contemplating getting rid of that too, and just notifying the user that their password may be wrong and that they should go update it in the network configuration panel so we don't interrupt. But if you're 100% sure your PSK is correct, then it is, most likely, a driver bug. Password is correct. I have a second wireless card (external, using rt2800usb driver) that connects without a glitch to the same AP. Moreover, unless I type the right password, N-M dialog does not allow me to click on the Connect button. NM minimally verifies the PSK, which by 802.11 standards is between 8 and 63 ASCII characters inclusive. So you should be able to type anything you want within those constraints, but clearly only one is your real PSK. Oops! Okay, so what user inputs is not bullet-proof. Anyway, this does not seem to be a problem of bad password. I was finally able to get connected to the AP as soon as I carry the nebook and put it next to the AP which is the problem I've always have had with this driver (brcmsmac). Yeah, that's a symptom of bad power control or bad gain or who knows what in the driver. But also, make sure your antennas are connected correctly :) As soon as I back to another room, N-M asks me again for the pass-key and disconnects. NM 0.9.8 shouldn't do that; I bet you're not even getting to the point where the 4-way handshake and password verification are done. NM 0.9.8 will retry a few times, notify you and fail, then wait a couple minutes and try again. It shouldn't ask for a password anymore in situations like this. Dan -- 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/1363716980.2225.32.ca...@dcbw.foobar.com
Bug#664767: Brcmsmac driver woes, possible regression?
El 2013-03-19 a las 13:16 -0500, Dan Williams escribió: On Tue, 2013-03-19 at 19:11 +0100, Camaleón wrote: (...) NM minimally verifies the PSK, which by 802.11 standards is between 8 and 63 ASCII characters inclusive. So you should be able to type anything you want within those constraints, but clearly only one is your real PSK. Oops! Okay, so what user inputs is not bullet-proof. Anyway, this does not seem to be a problem of bad password. I was finally able to get connected to the AP as soon as I carry the nebook and put it next to the AP which is the problem I've always have had with this driver (brcmsmac). Yeah, that's a symptom of bad power control or bad gain or who knows what in the driver. But also, make sure your antennas are connected correctly :) I'm starting to think the embedded wireless adapter could have been damaged somehow. The fact is that the card worked fine until kernel 2.6.38 (IIRC), but afterwards... well, I had to connect an additional USB card. As soon as I back to another room, N-M asks me again for the pass-key and disconnects. NM 0.9.8 shouldn't do that; I bet you're not even getting to the point where the 4-way handshake and password verification are done. NM 0.9.8 will retry a few times, notify you and fail, then wait a couple minutes and try again. It shouldn't ask for a password anymore in situations like this. Debian Wheezy still has 0.9.4 but well, that's a minor issue ;-( Greetings, -- Camaleón -- 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/20130319183044.ga8...@stt008.linux.site
Bug#703370: No more problems after increasing frame buffer size
Bernhard wrote: Reason was a too small frame buffer size with 32MB in UEFI. [...] After increasing the frame buffer size from 32MB to 64MB, gnome shell starts without any errors. Where do you configure that? Is this a BIOS bug? We might want to warn users in the wheezy release notes, so more details would be welcome. Thanks, 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/20130319185103.ga3...@google.com
Bug#703390: GPU hungs, the X11 process has high CPU usage and the screen becomes lag
forwarded 703390 https://bugs.freedesktop.org/62507 quit SuperCat wrote: I have report the bug to freedebug.org Thanks! Chris Wilson writes: | your hangs are a result of bugs in the rc6 implementation (enabled by | default as it saves a lot of power on all systems) which sounds like they understand it somewhat. If you can confirm that passing i915.i915_enable_rc6=0 on the kernel command line makes the hangs go away, that would be useful. Regards, 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/20130319191359.gc3...@google.com
Processed: Re: GPU hungs, the X11 process has high CPU usage and the screen becomes lag
Processing commands for cont...@bugs.debian.org: forwarded 703390 https://bugs.freedesktop.org/62507 Bug #703390 [src:linux] linux-image-3.2.0-4-amd64: GPU hungs, the X11 process has high CPU usage and the screen becomes lag Set Bug forwarded-to-address to 'https://bugs.freedesktop.org/62507'. quit Stopping processing here. Please contact me if you need assistance. -- 703390: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703390 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.136372045023260.transcr...@bugs.debian.org
Re: Bug#703291: [xserver-xorg-video-nouveau] Dual display problem: Using xrandr to setup dual displays causes X to hang
On 2013-03-18 22:44 +0100, Guy Heatley wrote: Sven - I can confirm that your downgrading suggestion fixes this problem. On 18/03/13 17:03, Sven Joachim wrote: Kernel folks, this appears to be a regression resulting from the DRM 3.4 backport. Can you confirm that downgrading linux-image-3.2.0-4-amd64 to 3.2.35-2 (available on snapshots.debian.org[1]) fixes the problem? Yes, this fixes it. Could you please try a 3.8 kernel from experimental (requires initramfs-tools from experimental as well)? If the problem persists, file a bug on https://bugs.freedesktop.org/. Choose product xorg, component Driver/nouveau, and let us know the bug number. Cheers, Sven -- 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/874ng7ji0y@turtle.gmx.de
Bug#703370: No more problems after increasing frame buffer size
Bernhard wrote: I have configured the frame buffer size in UEFI (see attached screenshot). I don't know, if this is a BIOS bug. I have installed the latest version from february 2013. Thanks much. That helps a lot. I'll try to find time to see if the patch that improved the error message is minimal enough to backport and whether there is any documentation where we can add this advice. -- 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/20130319205417.ge3...@google.com
Bug#664767: Brcmsmac driver woes, possible regression?
On 03/19/2013 05:21 PM, Camaleón wrote: Mar 19 17:05:28 stt300 kernel: [26034.188562] wlan0: authenticated Mar 19 17:05:28 stt300 kernel: [26034.192108] wlan0: associate with 00:1a:2b:97:7a:97 (try 1/3) Mar 19 17:05:28 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: authenticating - associating Mar 19 17:05:30 stt300 kernel: [26036.586947] wlan0: RX AssocResp from 00:1a:2b:97:7a:97 (capab=0x411 status=0 aid=1) Mar 19 17:05:30 stt300 kernel: [26036.587560] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated Mar 19 17:05:30 stt300 kernel: [26036.587576] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement) Mar 19 17:05:30 stt300 kernel: [26036.587603] wlan0: associated Mar 19 17:05:30 stt300 kernel: [26036.587698] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Mar 19 17:05:30 stt300 wpa_supplicant[2855]: wlan0: Associated with 00:1a:2b:97:7a:97 Seems to be heading in the right direction, but Mar 19 17:05:30 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: associating - associated Mar 19 17:05:30 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: associated - 4-way handshake Mar 19 17:05:32 stt300 avahi-daemon[2630]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::ae81:12ff:fe34:6963. Mar 19 17:05:32 stt300 avahi-daemon[2630]: New relevant interface wlan0.IPv6 for mDNS. Mar 19 17:05:32 stt300 avahi-daemon[2630]: Registering new address record for fe80::ae81:12ff:fe34:6963 on wlan0.*. Mar 19 17:05:32 stt300 NetworkManager[30971]: warn Activation (wlan0/wireless): association took too long. Here it seem to go bad again... Mar 19 17:05:32 stt300 NetworkManager[30971]: info (wlan0): device state change: config - need-auth (reason 'none') [50 60 0] Mar 19 17:05:32 stt300 NetworkManager[30971]: warn Activation (wlan0/wireless): asking for new secrets Mar 19 17:05:32 stt300 kernel: [26039.005158] wlan0: deauthenticating from 00:1a:2b:97:7a:97 by local choice (reason=3) And we get a deauth request with WLAN_REASON_DEAUTH_LEAVING. Mar 19 17:05:33 stt300 kernel: [26040.004150] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: disassociated Mar 19 17:05:33 stt300 kernel: [26040.004172] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement) Mar 19 17:05:34 stt300 kernel: [26040.504402] cfg80211: Calling CRDA to update world regulatory domain Mar 19 17:05:34 stt300 ntpd[2611]: Listen normally on 16 wlan0 fe80::ae81:12ff:fe34:6963 UDP 123 Mar 19 17:05:34 stt300 ntpd[2611]: peers refreshed Mar 19 17:05:34 stt300 wpa_supplicant[2855]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3 Mar 19 17:05:34 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: 4-way handshake - disconnected Mar 19 17:05:34 stt300 NetworkManager[30971]: warn Couldn't disconnect supplicant interface: This interface is not connected. I am trying to make sense of it, but it is getting late over here. Have a fresh look tomorrow. Regards, Arend -- 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/5148dec9.50...@broadcom.com
Bug#664767: Brcmsmac driver woes, possible regression?
On Tue, 2013-03-19 at 22:55 +0100, Arend van Spriel wrote: On 03/19/2013 05:21 PM, Camaleón wrote: Mar 19 17:05:28 stt300 kernel: [26034.188562] wlan0: authenticated Mar 19 17:05:28 stt300 kernel: [26034.192108] wlan0: associate with 00:1a:2b:97:7a:97 (try 1/3) Mar 19 17:05:28 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: authenticating - associating Mar 19 17:05:30 stt300 kernel: [26036.586947] wlan0: RX AssocResp from 00:1a:2b:97:7a:97 (capab=0x411 status=0 aid=1) Mar 19 17:05:30 stt300 kernel: [26036.587560] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated Mar 19 17:05:30 stt300 kernel: [26036.587576] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement) Mar 19 17:05:30 stt300 kernel: [26036.587603] wlan0: associated Mar 19 17:05:30 stt300 kernel: [26036.587698] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Mar 19 17:05:30 stt300 wpa_supplicant[2855]: wlan0: Associated with 00:1a:2b:97:7a:97 Seems to be heading in the right direction, but Mar 19 17:05:30 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: associating - associated Mar 19 17:05:30 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: associated - 4-way handshake Mar 19 17:05:32 stt300 avahi-daemon[2630]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::ae81:12ff:fe34:6963. Mar 19 17:05:32 stt300 avahi-daemon[2630]: New relevant interface wlan0.IPv6 for mDNS. Mar 19 17:05:32 stt300 avahi-daemon[2630]: Registering new address record for fe80::ae81:12ff:fe34:6963 on wlan0.*. Mar 19 17:05:32 stt300 NetworkManager[30971]: warn Activation (wlan0/wireless): association took too long. Here it seem to go bad again... Mar 19 17:05:32 stt300 NetworkManager[30971]: info (wlan0): device state change: config - need-auth (reason 'none') [50 60 0] Mar 19 17:05:32 stt300 NetworkManager[30971]: warn Activation (wlan0/wireless): asking for new secrets Mar 19 17:05:32 stt300 kernel: [26039.005158] wlan0: deauthenticating from 00:1a:2b:97:7a:97 by local choice (reason=3) And we get a deauth request with WLAN_REASON_DEAUTH_LEAVING. That local choice (reason=3) is NetworkManager terminating the association attempt because it already took 25 seconds, which is way too long for a simple association. The cause is long before that. NM tells the supplicant to start associating here: Mar 19 17:05:07 stt300 NetworkManager[30971]: info Config: set interface ap_scan to 1 and finally kills the attempt here: Mar 19 17:05:32 stt300 NetworkManager[30971]: warn Activation (wlan0/wireless): association took too long. So the supplicant gets a total of 25 seconds to associate to the AP, which, if you're not associated within that time, you're definitely not going to get associated if you're given more time. But between 17:05:07 and 17:05:32, NM is just waiting for the association to succeed. It really does look like the supplicant or driver tries to associate but then fails, eg: Mar 19 17:05:08 stt300 kernel: [26014.833011] wlan0: send auth to 00:1a:2b:97:7a:97 (try 1/3) Mar 19 17:05:13 stt300 kernel: [26019.834259] wlan0: deauthenticating from 00:1a:2b:97:7a:97 by local choice (reason=3) There's a whole lot of authentication/association failures in that log, which do appear to indicate that the STA can see the AP, but the AP can't hear the STA. Then we also have stuff like: Mar 19 17:05:24 stt300 wpa_supplicant[2855]: wlan0: SME: Authentication request to the driver failed where it would be nice to know why the request failed. Dan Mar 19 17:05:33 stt300 kernel: [26040.004150] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: disassociated Mar 19 17:05:33 stt300 kernel: [26040.004172] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement) Mar 19 17:05:34 stt300 kernel: [26040.504402] cfg80211: Calling CRDA to update world regulatory domain Mar 19 17:05:34 stt300 ntpd[2611]: Listen normally on 16 wlan0 fe80::ae81:12ff:fe34:6963 UDP 123 Mar 19 17:05:34 stt300 ntpd[2611]: peers refreshed Mar 19 17:05:34 stt300 wpa_supplicant[2855]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3 Mar 19 17:05:34 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: 4-way handshake - disconnected Mar 19 17:05:34 stt300 NetworkManager[30971]: warn Couldn't disconnect supplicant interface: This interface is not connected. I am trying to make sense of it, but it is getting late over here. Have a fresh look tomorrow. Regards, Arend -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Bug#703464: Acer Aspire 3810T laptop hotkeys produce ACPI exceptions errors in dmesg log
Package: src:linux Version: 3.2.35-2 Severity: minor Dear Maintainer, my Acer Aspire 3810T laptop hotkeys (+) seem to function good, but when pressed, they produce some kernel log messages like this: ACPI Exception: AE_AML_PACKAGE_LIMIT ... ACPI Error: Method parse/execution failed ... (look at the tail of kernel log for more details). -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-2 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=UUID=... ro ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [ 26.980943] sirdev_receive - too early: 880137c5cc9a / 1! [ 26.983009] sirdev_receive - too early: (null) / 0! [ 26.985038] sirdev_receive - too early: (null) / 0! [ 26.986954] sirdev_receive - too early: (null) / 0! [ 26.988814] sirdev_receive - too early: 880137c5cca0 / 3! [ 30.866958] Bluetooth: Core ver 2.16 [ 30.868926] NET: Registered protocol family 31 [ 30.870804] Bluetooth: HCI device and connection manager initialized [ 30.872718] Bluetooth: HCI socket layer initialized [ 30.874569] Bluetooth: L2CAP socket layer initialized [ 30.876418] Bluetooth: SCO socket layer initialized [ 30.913041] Bluetooth: RFCOMM TTY layer initialized [ 30.914885] Bluetooth: RFCOMM socket layer initialized [ 30.916718] Bluetooth: RFCOMM ver 1.11 [ 30.993990] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 30.995787] Bluetooth: BNEP filters: protocol multicast [ 31.349671] lp: driver loaded but no devices found [ 31.508076] ppdev: user-space parallel port driver [ 32.069922] vboxdrv: Found 2 processor cores. [ 32.070107] vboxdrv: fAsync=0 offMin=0x193 offMax=0x7f2 [ 32.072252] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'. [ 32.074179] vboxdrv: Successfully loaded version 4.2.6 (interface 0x001a0004). [ 33.315332] vboxpci: IOMMU not found (not registered) [ 34.425477] iwlwifi :01:00.0: L1 Enabled; Disabling L0S [ 34.428979] iwlwifi :01:00.0: Radio type=0x1-0x2-0x0 [ 34.545166] iwlwifi :01:00.0: L1 Enabled; Disabling L0S [ 34.548269] iwlwifi :01:00.0: Radio type=0x1-0x2-0x0 [ 34.596618] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 34.661449] atl1c :02:00.0: irq 46 for MSI/MSI-X [ 34.721214] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 124.688338] NOHZ: local_softirq_pending 08 [ 124.775098] NOHZ: local_softirq_pending 08 [ 124.863335] NOHZ: local_softirq_pending 08 [ 124.951332] NOHZ: local_softirq_pending 08 [ 125.039335] NOHZ: local_softirq_pending 08 [ 125.127331] NOHZ: local_softirq_pending 08 [ 125.217306] NOHZ: local_softirq_pending 08 [ 127.696324] NOHZ: local_softirq_pending 08 [ 127.783319] NOHZ: local_softirq_pending 08 [ 127.871315] NOHZ: local_softirq_pending 08 [ 131.181869] wlan0: authenticate with 11:22:33:44:55:66 (try 1) [ 131.380294] wlan0: authenticate with 11:22:33:44:55:66 (try 2) [ 131.382478] wlan0: authenticated [ 131.387612] wlan0: associate with 11:22:33:44:55:66 (try 1) [ 131.584299] wlan0: associate with 11:22:33:44:55:66 (try 2) [ 131.587891] wlan0: RX AssocResp from 11:22:33:44:55:66 (capab=0x431 status=0 aid=1) [ 131.587901] wlan0: associated [ 131.597601] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 142.800247] wlan0: no IPv6 routers present [ 647.844458] cfg80211: Calling CRDA to update world regulatory domain [ 647.855260] cfg80211: World regulatory domain updated: [ 647.855360] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 647.855490] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 647.855614] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [ 647.855737] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [ 647.855863] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 647.855986] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 906.511841] iwlwifi :01:00.0: RF_KILL bit toggled to disable radio. [ 906.536288] iwlwifi :01:00.0: Not sending command - RF KILL [ 906.543432] iwlwifi :01:00.0: Error sending REPLY_RXON: enqueue_hcmd failed: -5 [ 906.550410] iwlwifi :01:00.0: Error clearing ASSOC_MSK on BSS (-5) [ 907.044350] iwlwifi :01:00.0: RF_KILL bit toggled to enable radio. [ 907.808281] iwlwifi :01:00.0: L1 Enabled; Disabling L0S [ 907.818516] iwlwifi :01:00.0: Radio type=0x1-0x2-0x0 [ 907.878203] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 992.113239] wlan0: authenticate with 11:22:33:44:55:66 (try 1) [ 992.115141] wlan0: authenticated [ 992.119297] wlan0: associate with 11:22:33:44:55:66 (try 1) [ 992.123115] wlan0: RX AssocResp from 11:22:33:44:55:66 (capab=0x431 status=0 aid=1) [ 992.123124] wlan0: associated [ 992.129305] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 1003.024127] wlan0: no IPv6 routers present [ 1727.033517] fuse init (API version 7.17) [ 1767.558259] ACPI Exception:
Bug#703464: Acer Aspire 3810T laptop hotkeys produce ACPI exceptions errors in dmesg log
my Acer Aspire 3810T laptop hotkeys (+) seem to function good, I meant hotkeys (Fn+SomeKey) instead. It's some weird webmail issue. Best wishes, Bob
Bug#703468: linux-image-3.2.0-4-amd64 fails to boot on apple iMac
Package: src:linux Version: 3.2.39-2 Severity: grave Dear Maintainer, I upgraded to the 3.2.39-2 package last night, and this morning my system wouldn't boot. I used Marco's advice in #551798 to set init=/bin/bash, and found the boot stopped after running /etc/rcS.d/S02udev. Sometimes there would be a screen full of kernel messages, that ended in a message like: fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver Sorry I can't provide more details, I didn't take a photo of the screen. Using by init=/bin/bash shell I downgraded the kernel package to the 3.2.35-2 package (which was what I was running prior to yesterdays upgrade), and my system booted successfully. The attached linux-image-reportbugoutput file was generated by running: $ reportbug -q --template -T none -s none -S normal -b --list-cc none -q linux-image-3.2.0-4-amd64 ~/tmp/linux-image-reportbugoutput Please note that this reportbug run was while running on the 3.2.35-2 package of the kernel, so some of the details will be misleading. Include network configuration and status from this computer? Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Geoff Crompton geo...@trinity.unimelb.edu.au To: Debian Bug Tracking System sub...@bugs.debian.org Subject: linux-image-3.2.0-4-amd64: none X-Debbugs-Cc: none Package: src:linux Version: 3.2.35-2 Severity: normal Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-2 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=UUID=7de8ea19-10bf-4b66-a1e3-a14e6ac34d80 ro quiet ** Not tainted ** Kernel log: [ 11.154250] ATOM BIOS: Apple [ 11.154260] [drm] GPU not posted. posting now... [ 11.172389] radeon :01:00.0: VRAM: 512M 0x - 0x1FFF (512M used) [ 11.172391] radeon :01:00.0: GTT: 512M 0x2000 - 0x3FFF [ 11.174594] [drm] Detected VRAM RAM=512M, BAR=256M [ 11.174596] [drm] RAM width 128bits DDR [ 11.174675] [TTM] Zone kernel: Available graphics memory: 2019148 kiB. [ 11.174677] [TTM] Initializing pool allocator. [ 11.174711] [drm] radeon: 512M of VRAM memory ready [ 11.174713] [drm] radeon: 512M of GTT memory ready. [ 11.174726] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 11.174727] [drm] Driver supports precise vblank timestamp query. [ 11.174765] radeon :01:00.0: irq 50 for MSI/MSI-X [ 11.174770] radeon :01:00.0: radeon: using MSI. [ 11.174814] [drm] radeon: irq initialized. [ 11.174817] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 11.175157] [drm] Loading TURKS Microcode [ 11.264106] Bluetooth: Generic Bluetooth USB driver ver 0.6 [ 11.264325] usbcore: registered new interface driver btusb [ 11.338630] platform radeon_cp.0: firmware: agent loaded radeon/TURKS_pfp.bin into memory [ 11.526432] platform radeon_cp.0: firmware: agent loaded radeon/TURKS_me.bin into memory [ 11.612326] platform radeon_cp.0: firmware: agent loaded radeon/BTC_rlc.bin into memory [ 11.662351] platform radeon_cp.0: firmware: agent loaded radeon/TURKS_mc.bin into memory [ 11.665046] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 11.665170] radeon :01:00.0: WB enabled [ 11.681439] [drm] ring test succeeded in 2 usecs [ 11.681532] [drm] radeon: ib pool ready. [ 11.681635] [drm] ib test succeeded in 0 usecs [ 11.683096] [drm] Radeon Display Connectors [ 11.683097] [drm] Connector 0: [ 11.683098] [drm] eDP [ 11.683099] [drm] HPD3 [ 11.683101] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c [ 11.683102] [drm] Encoders: [ 11.683104] [drm] LCD1: INTERNAL_UNIPHY2 [ 11.683105] [drm] Connector 1: [ 11.683106] [drm] DisplayPort [ 11.683107] [drm] HPD1 [ 11.683108] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [ 11.683109] [drm] Encoders: [ 11.683110] [drm] DFP1: INTERNAL_UNIPHY1 [ 11.683112] [drm] Connector 2: [ 11.683112] [drm] DisplayPort [ 11.683113] [drm] HPD2 [ 11.683115] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [ 11.683116] [drm] Encoders: [ 11.683117] [drm] DFP2: INTERNAL_UNIPHY1 [ 11.683118] [drm] Connector 3: [ 11.683119] [drm] DisplayPort [ 11.683120] [drm] HPD5 [ 11.683121] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [ 11.683123] [drm] Encoders: [ 11.683124] [drm] DFP3: INTERNAL_UNIPHY2 [ 11.683125] [drm] Connector 4: [
Bug#703271: linux-image-3.2.0-4-amd64: Fix brightness hotkeys on ASUS UX31A laptop
On Sun, 2013-03-17 at 21:54 +0100, Vincent Blut wrote: Package: src:linux Version: 3.2.39-2 Severity: normal Tags: upstream Hi, Since Linux 3.7, the brightness hotkeys work on this laptop. Initially I thought that this support was added by a specific plateform driver commit but after diving in git log it didn't make any sense about why these hotkeys worked in 3.7 so I started to bisect in order to find the culprit. Here it is: Please apply this to stable branches earlier than 3.7. It doesn't appear to depend on any other changes post-3.0. From d627b62ff8d4d36761adbcd90ff143d79c94ab22 Mon Sep 17 00:00:00 2001 From: Lekensteyn lekenst...@gmail.com Date: Mon, 25 Jun 2012 22:36:24 + Subject: i915: initialize CADL in opregion [...] Well, after this result I was puzzled because it seemed to be a Clevo specific issue but I decided to give it a try and effectively it gave me the expected behavior, so please could you add it in the next Wheezy upload? Also this should probably be forwarded to sta...@vger.kernel.org with a revised commit message stipulating that not only Clevo laptop are affected, don't know if it is possible though. Normally the original commit message is used unchanged. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Processed: tagging 703271
Processing commands for cont...@bugs.debian.org: tags 703271 + pending Bug #703271 [src:linux] linux-image-3.2.0-4-amd64: Fix brightness hotkeys on ASUS UX31A laptop Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 703271: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703271 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.136375120830814.transcr...@bugs.debian.org
