Bug#720528: nvidia: driver fails kernel 3.10+ (GeForce 600M and 700M series)
> Control: tag -1 moreinfo > > On Sat, 23 Aug 2014 22:53:48 -0700 Ben Hutchings > wrote: > > On Sat, 2014-08-23 at 20:14 -0700, Andres Cimmarusti wrote: > > > Let me re-state: worked with debian 3.9, broke with debian 3.11 (but > > > works with Ubuntu vanilla LTS 3.11.10.x series), worked with debian > > > 3.12, broke again with debian 3.13 (but worked again with Ubuntu > > > vanilla LTS 3.13.11.x series) and finally doesn't work with debian > > > 3.14 and also not with 3.15, I have yet to try 3.16. > > > My guess is that a configuration option I'm using (processor timer > > > frequency 1000 Hz) when building the Ubuntu vanilla LTS kernels is > > > doing the trick, but then again I don't know why debian 3.12 did work. > > > Could this faster 1000 Hz vs 250 Hz (default in debian) have anything > > > to do with this ACPI issue Nvidia reported... > > Is this still an issue with the latest driver (390.67) and kernels > available in sid, buster, and stretch-backports? > Sorry I forgot to report back on this issue. Since Debian Jessie (kernel 3.16) and now Debian Wheezy this has been resolved
Bug#720528: nvidia: driver fails kernel 3.10+ (GeForce 600M and 700M series)
As this is apparently specific to a non-free driver, you should not expect that the kernel team will ever do any work on it. I understand However, if you can find a specific commit that introduced it, or that fixes it, we might be able to make some progress. At the moment this is difficult for me because this issue is very erratic and I think it has to do with some configuration option in the kernel. I would have tried different kernels, but currently everytime I try to compile a vanilla kernel either the deb-pkg way or the kernel-package way I get a blocking error... On Sun, 2014-04-27 at 11:13 -0400, Andres Cimmarusti wrote: found 720528 linux/3.13.10-1 linux/3.11.10-1 notfound 720528 linux/3.12.9-1 linux/3.9.6-1 thanks [...] So this worked in 3.9, broke in 3.11, worked in 3.12, broke again in 3.13? That seems unlikely. Let me re-state: worked with debian 3.9, broke with debian 3.11 (but works with Ubuntu vanilla LTS 3.11.10.x series), worked with debian 3.12, broke again with debian 3.13 (but worked again with Ubuntu vanilla LTS 3.13.11.x series) and finally doesn't work with debian 3.14 and also not with 3.15, I have yet to try 3.16. My guess is that a configuration option I'm using (processor timer frequency 1000 Hz) when building the Ubuntu vanilla LTS kernels is doing the trick, but then again I don't know why debian 3.12 did work. Could this faster 1000 Hz vs 250 Hz (default in debian) have anything to do with this ACPI issue Nvidia reported... -- 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/CAH=dYrFEsxzjShCatnhRZP9n=u2dcaka1pxqpwlpvg6wsrs...@mail.gmail.com
Bug#720528: nvidia: driver fails kernel 3.10+ (GeForce 600M and 700M series)
found 720528 linux/3.13.10-1 linux/3.11.10-1 notfound 720528 linux/3.12.9-1 linux/3.9.6-1 thanks From the forum: For the issues what I mentioned earlier in this thread, that we reproduced in-house and investigated : This is not an Nvidia bug. On affected notebooks Nvidia driver depends on ACPI subsystem to retrieve VBIOS image but it fails to do so as _ROM method takes way too long to evaluate. ACPI calls might be failing due to Linux kernel bug/SBIOS bug/3rd Party HW bug or some other reason. It appears this is some kernel issue, makes sense since some kernels work, but others don't with the same version of the nvidia-driver. I'm changing this bug report to the kernel. BTW I got this problem again as soon as the upgrade to kernel 3.13.x got into testing Curiously all LTS kernels from the ubuntu kernel git repository work just fine... I was running on 3.8.13.x and now on 3.11.10.x, but the newer LTS kernels from kernel.org fail: 3.10.x and 3.12.9 (this is particularly strange, because when testing had kernel 3.12.9, it worked just finebut when it had 3.11.10 it failed!) This is not a configuration issue, because I'm using the same configuration parameters as the Debian kernel builds for that specific version. This looks suspiciously like NVIDIA puts in a little more effort in supporting Ubuntu kernels or viceversa... -- 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/CAH=dyreyjkecun5cmpnps_v6mapudtdzwzs6o4tptnklpyg...@mail.gmail.com
Bug#699406: linux-image-3.2.0-4-amd64: HD Audio early patching ignored
Package: src:linux Version: 3.2.35-2 Severity: normal Due to BIOS issues, a lot of systems advertise several HDMI pins even though physically only one is reachable. In my case, a LC2131 (SP13R) laptop shows the following available pins: $ aplay -l List of PLAYBACK Hardware Devices card 0: Intel [HDA Intel], device 0: ALC269VB Analog [ALC269VB Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Fortunately, there's a way to disable the unused HDMI pins using a feature called early patching described here: http://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio.txt In my case I did this: I created a file containing below in /lib/firmware, such as, /lib/firmware/ibx-hdmi: [codec] 0x80862804 0x80860101 3 [pincfg] 0x04 0x41f0 0x06 0x41f0 Now pass this file to patch module option for snd-hda-intel. For example, create a file in /etc/modprobe.d/, e.g. /etc/modprobe.d/50-hdmi.conf, containing the line options snd-hda-intel patch=ibx-hdmi Up until recently (3.2.32), my system accepted the early patching and advertised only one (and the correct one) HDMI pin as follows: $ aplay -l List of PLAYBACK Hardware Devices card 0: Intel [HDA Intel], device 0: ALC269VB Analog [ALC269VB Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 Sadly after a recent upgrade, this functionality seems broken. The kernel log below shows the patch is accepted, but immediately after, it seems to be ignored and all HDMI pins are shown.. While this is not a big issue, it's annoying and can put off new users who don't know which HDMI pin to choose from. -- 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=be3ae895-1fd2-4375-901e-83ee4ecae1f0 ro quiet ** Not tainted ** Kernel log: [3.443127] iwlwifi :01:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels [3.504609] asus_wmi: Asus Management GUID not found [3.513004] mtrr: type mismatch for c000,1000 old: write-back new: write-combining [3.513011] [drm] MTRR allocation failed. Graphics performance may suffer. [3.513723] i915 :00:02.0: irq 45 for MSI/MSI-X [3.513732] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [3.513735] [drm] Driver supports precise vblank timestamp query. [3.513811] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [3.522795] iwlwifi :01:00.0: firmware: agent loaded iwlwifi-6000-4.ucode into memory [3.522807] iwlwifi :01:00.0: loaded firmware version 9.221.4.1 build 25532 [3.523429] Registered led device: phy0-led [3.544846] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' [3.551107] cfg80211: World regulatory domain updated: [3.551112] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [3.551119] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [3.551125] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [3.551130] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [3.551135] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [3.551140] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [3.764499] usb 2-1.5: New USB device found, idVendor=174f, idProduct=1420 [3.764510] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [3.764518] usb 2-1.5: Product: USB Camera Device [3.764525] usb 2-1.5: Manufacturer: Syntek [3.764530] usb 2-1.5: SerialNumber: STK1 [3.908270] Linux media interface: v0.10 [3.914634] Linux video capture interface: v2.00 [3.917916] uvcvideo: Found UVC 1.00 device USB Camera Device (174f:1420) [4.009071] input: USB Camera Device as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/input/input5 [4.009349] usbcore: registered new interface driver uvcvideo [4.009358] USB Video Class driver (1.1.1) [4.194089] fbcon: inteldrmfb (fb0) is primary device [4.285271] psmouse serio2: synaptics: Touchpad model: 1, fw: 6.2, id: 0x81a0b1, caps: 0xa04711/0x20/0x0 [4.330489] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio2/input/input6 [4.370203] Console: switching to colour frame buffer device 170x48 [
Bug#660111: multiple, non-physically accesible, HDMI devices
On 09/29/2012 01:47 PM, Jonathan Nieder wrote: Shouldn't we consider reverting 384a48d71520 (ALSA: hda: HDMI: Support codecs with fewer cvts than pins, 2011-06-01) in wheezy if userspace hasn't caught up with the new order of things? I haven't looked deeply into this or tried it, but it seems at least worth thinking over. Mmm. I don't know if this is a good idea. That patch allowed support for video cards with multiple (physically accessible) HDMI ports. Before, the kernel would just choose one to be advertised and the others could not be accessed. Andres -- 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/5069a51e.7040...@gmail.com
Bug#641749: package libmtp-runtime breaks AR3011 Bluetooth
I also found that removal of the libmtp-runtime package (version
1.1.2-2) solved the problem with my AR3011 Bluetooth device.
(AMD64 CPU, Linux v3.2)
After reading here:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/714862/comments/43
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/714862/comments/45
http://permalink.gmane.org/gmane.linux.kernel1.73/1262485
-- that there was a firmware patch which supposedly addressed this
problem, I obtained the Ubuntu linux-firmware package which contains
the updated ath3k-1.fw file (as of version 1.73):
http://packages.ubuntu.com/precise/linux-firmware
http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-firmware/linux-firmware_1.79/changelog
-- and substituted their file in place of the one from the Debian
firmware-atheros package (version 0.36). I confirmed that the firmware
images are in fact different.
Result: the firmware change appears to have no effect at all. I tried
booting up with all four combinations of
{libmtp-runtime present/not present} x {Debian firmware/Ubuntu firmware}
and the Bluetooth device works or not depending on the presence (no) or
absence (yes) of libmtp-runtime, regardless of the firmware version.
I urge other people to try this experiment.
Later comments in the corresponding Ubuntu bug report:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/714862
-- agree with this result:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/714862/comments/40
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/714862/comments/53
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/714862/comments/55
I apologize for taking so long to reply. I have reinstalled the newer
version of libmtp-runtime (1.1.3-x) and I confirm that now firmware to
the atheros bluetooth is loaded correctly.
I haven't tried any new firmware (in fact, as far asI know the
firmware patch never made into Debian). This is with current stock
wheezy kernel and firmware.
I think this bug can be closed.
--
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/CAH=dYrG=M7fZcLmwvc6nPET8n2=DyBvk9HBA5ypnR5=6gmh...@mail.gmail.com
Bug#660111: multiple, non-physically accesible, HDMI devices (Re: pulseaudio: pa can't handle multiple HDMI devices)
You're correct; even if the information is there, it isn't advertised in pavucontrol. I should probably implement that... (If you're using Ubuntu 12.04, you will have a new sound settings UI that hides unavailable devices. For upstreaming of this UI please see the gnome-cc list.) What you'll get is instead what the module-switch-on-port-available module provides. When you plug your headphones in, the selected port will switch (you should be able to notice this in pavucontrol I think), which means your media keys / sound indicator / etc would control your headphone's volume instead of your speaker's volume. For the multi HDMI case - if you have selected the wrong HDMI interface, and then activate your HDMI screen, module-switch-on-port-available should automatically switch to the correct one. This is all assuming you're running PulseAudio 2.0 - earlier versions of PulseAudio do not have this functionality. Should you be interested in backporting the jack detection kernel patches, I'll be happy to point you to the Ubuntu kernel's git tree, where I did the same thing. Has this been backported? Personally I think this bug should closed whether it's been backported or not. The gain in backporting jack detection is minimal because the GUI's haven't completely caught up with this feature yet as David mentioned and the user still needs to pick from one of the multiple HDMI ports advertised by the kernel. -- 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/CAH=dYrH7eMViw95-yxJA7n=6jme2bt4ltaogpcxaghle6na...@mail.gmail.com
Bug#660111: Bug#664653 pulseaudio: pa can't handle multiple HDMI devices -- chooses wrong default
fixed 664653 2.0-3 thanks As I reported earlier, version 2.0 of pulseaudio can handle multiple HDMI outputs. Bug# 664653 is completely fixed. I've tested it successfully in my computer. -- 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/CAH=dyregutd5xo4uxcm22t1cp1scik_4ik6r-ax5ubzpxrp...@mail.gmail.com
Bug#660111: Bug#664653 pulseaudio: pa can't handle multiple HDMI devices -- chooses wrong default
Do we still need to make kernel changes for wheezy, or does the new PA together with the current kernel package (version 3.2.19-1) avoid this problem? PA 2.0 can handle all the HDMI outputs advertised by the kernel, but one has to try all of them using pavucontrol to find the correct one. With kernel's 3.3 jack detection, this is done automatically. Personally I think PA 2.0 is sufficient, since the user can select the right HDMI output, but automatic detection is definitely better for ease of use. Since the Ubuntu team has already done the backport, perhaps this won't be too hard? -- 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/CAH=dyrerdc4fz6dg1kbbdb3f9ax8rrakzhafsoo0hqfjqbt...@mail.gmail.com
Bug#660111: multiple, non-physically accesible, HDMI devices (Re: pulseaudio: pa can't handle multiple HDMI devices)
Andres, do you know of relevant commit ids? Can you describe the difference in behavior between 3.2.19-1 and 3.4.1-1~experimental.1 and whether it's worth backporting these changes? I will try the kernel from experimental and let you know if the changes are worth while. Unfortunately I have not tracked the relevant commits. But it looks like you probably found them. We can probably contact David Henningsson from Canonical, since he was heavily involved in it and provided a lot of guidance to solve this issue. -- 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/CAH=dyrhh+_w8o6ssftxcy6_jjbbl+6b6bnhhqbjwjx557_v...@mail.gmail.com
Bug#660111: multiple, non-physically accesible, HDMI devices (Re: pulseaudio: pa can't handle multiple HDMI devices)
On Sun, Jun 10, 2012 at 8:25 PM, Andres Cimmarusti acimmaru...@gmail.com wrote: Andres, do you know of relevant commit ids? Can you describe the difference in behavior between 3.2.19-1 and 3.4.1-1~experimental.1 and whether it's worth backporting these changes? I will try the kernel from experimental and let you know if the changes are worth while. Unfortunately I have not tracked the relevant commits. But it looks like you probably found them. We can probably contact David Henningsson from Canonical, since he was heavily involved in it and provided a lot of guidance to solve this issue. I just tried kernel 3.4.1-1~experimental.1. I could see NO benefit at all in using that kernel. I still had to choose from a long list of advertised HDMI interfaces in pavucontrol before finding the correct one that produced sound on the TV speakers. On my laptop at least, I saw NO automatic jack detection benefit whatsoever. Is there anything else that needs to change? Perhaps David Henningsson can comment? Thanks Andres -- 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/CAH=dYrE_6QKppwuBoKdD6VRtsBjGyfbE0NTDE=g+58f+qnz...@mail.gmail.com
Re: firmware loading failure for AR3011 (0cf3:3000 or 0cf3:3005 ?)
James Leddy writes[1]: This turned out to be a problem with the firmware. It should be fixed by this modification to the firmware: http://comments.gmane.org/gmane.linux.kernel/1262485 Reassigning to firmware-atheros, but keeping the libmtp bug too in case an appropriate Breaks ends up being needed to handle upgrades. Thanks for your help, Jonathan [1] https://bugzilla.kernel.org/show_bug.cgi?id=27402 It's been months since I've been waiting for this patch to be merged upstream so that it can move to debian, but that hasn't happened. Since March 6th (date that the patch was posted), there hasn't been any related merged into the linux-firmware git repository: http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=shortlog I'm unsure how apply and test this git binary patch... Andres -- 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/CAH=dyrhpnf5pekxzquuyqoizto2sosfvlabqawdikswm-s8...@mail.gmail.com
Bug#660111: Bug#664653 pulseaudio: pa can't handle multiple HDMI devices -- chooses wrong default
tags 664653 fixed-upstream thanks Pulseaudio upstream version 1.99.1 (or master, specifically after commit e02cb7fb2e7865affed612693935c7fd698e3a6b) contains all the necessary bits to allow the user to select from several HDMI devices advertised by the kernel. Please consider packaging. Andres -- 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/CAH=dyrhswrdls65rdj1xt0q8vfeykvrasntoshu3yuo5kf1...@mail.gmail.com
Bug#660111: multiple, non-physically accesible, HDMI devices
Could you file a new report against pulseaudio summarizing the problem and your suggested fix and mentioning http://bugs.debian.org/660111 for background? Done, see bug report: http://bugs.debian.org/664653 -- 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/CAH=dYrG-WbeLL_u8O=lu8naflhvq8hmgtbugmnqs9bwkcbr...@mail.gmail.com
Bug#660111: [alsa-devel] multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB
Hello again, On Sat, Mar 3, 2012 at 9:43 PM, David Henningsson david.hennings...@canonical.com wrote: On 03/04/2012 12:36 AM, Andres Cimmarusti wrote: There is active work going on in this area. In fact, I just posted a patch to the PA mailinglist [1]. And yes, we already have it in Ubuntu 11.10 (to probe multiple hdmi devices for Intel and NVidia), and the main reason it took until now to upstream that patch, was the decision to switch jack detection method from input devices to kcontrols. Thank you for all the references you provided and your work in fixing this issue for all users. I just looked at the git repository for the source code of pulseaudio, but I see your patches have not been included yet. Do you have any estimate of when they will be merged? if so, do you think they'll be included in the next release (do you know when this will be?) ? I hope they'll be in PulseAudio 2.0, as they are currently waiting for review. For next release, see [2], but judging from the PulseAudio 1.0 release process - no, I don't know when this will be ;-) I'm considering reassigning this bug to pulseaudio in debian and asking them to include the appropriate patches. Which ones would actually be needed (say, to apply them to pulseaudio 1.1)? would your 6 patches announced on the mailing list in February be enough? If you want them to apply to PulseAudio 1.1, you can have a look at [1]. The patches currently posted apply to git head. You'll need all of the 06* patches (as well as Linux 3.3 for the kcontrols). It looks like your patches have been merged: http://cgit.freedesktop.org/pulseaudio/pulseaudio/log/ (but correct me if I'm wrong). However, I think Debian has decided to go with 3.2 kernel for the next stable release. This means no kcontrols. How is this being handled in Ubuntu 12.04 LTS, since it will also be based on kernel 3.2 A more light-weight version could be what I did in Ubuntu 11.04, where there was no jack detection, but I just exposed all four devices in PulseAudio and let the user choose manually, like this [4]. (I later renamed that file from nvidia.conf to extra-hdmi.conf, and added the same file to be used for Intel chips.) Can this still be done in the scenario were Debian has pulseaudio 2.0 with your patches, but kernel 3.2? Sorry for the basic questions. I just found out that the release of pulseaudio 2.0 is imminent and I want to push for its adoption in Debian, but with a fix for this HDMI issue. Thanks a million Andres -- 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/CAH=dyrgf2w0dxpgjdobpivqnnkuj+_drvllrj8vm4ymm--f...@mail.gmail.com
Bug#660111: multiple, non-physically accesible, HDMI devices
retitle 660111 multiple, non-physically accesible, HDMI devices affects 660111 + pulseaudio tags 660111 + fixed-upstream wheezy thanks (but correct me if I'm wrong). However, I think Debian has decided to go with 3.2 kernel for the next stable release. This means no kcontrols. How is this being handled in Ubuntu 12.04 LTS, since it will also be based on kernel 3.2 For Ubuntu 12.04, I've backported the jack detection patches from 3.3 and applied them to the Ubuntu 12.04 LTS kernel. Can this still be done in the scenario were Debian has pulseaudio 2.0 with your patches, but kernel 3.2? Sorry for the basic questions. I just found out that the release of pulseaudio 2.0 is imminentand I want to push for its adoption in Debian, but with a fix for this HDMI issue. So, with PA 2.0 but without jack detection support in the kernel, you would essentially get three or four HDMI devices showing up in your GUI, and the user would have to try them all manually to check which one is the right one. So, better than changing PA configuration files, but not as elegant as with the jack detection (where the right one is selected automatically), of course. I've marked this bug as affecting pulseaudio. In fact, it seems (to me) sufficient to get version 2.0 of pulseaudio into Debian to solve this bug. With convenience and user-friendliness in mind, I feel that the jack detection backport from kernel 3.3 to the Debian 3.2 kernel should be done. Since Ubuntu already did it, perhaps this will be easy enough ? Cheers Andres -- 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/CAH=dYrHDsh=hhvh_arrmvxq5gpe59otp+k9+hprveimjcuf...@mail.gmail.com
Bug#660111: [alsa-devel] multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB
There is active work going on in this area. In fact, I just posted a patch to the PA mailinglist [1]. And yes, we already have it in Ubuntu 11.10 (to probe multiple hdmi devices for Intel and NVidia), and the main reason it took until now to upstream that patch, was the decision to switch jack detection method from input devices to kcontrols. Thank you for all the references you provided and your work in fixing this issue for all users. I just looked at the git repository for the source code of pulseaudio, but I see your patches have not been included yet. Do you have any estimate of when they will be merged? if so, do you think they'll be included in the next release (do you know when this will be?) ? I'm considering reassigning this bug to pulseaudio in debian and asking them to include the appropriate patches. Which ones would actually be needed (say, to apply them to pulseaudio 1.1)? would your 6 patches announced on the mailing list in February be enough? If the new two pins can be never used, i.e. physically unreachable, we may disable these pins by giving the proper default pin-config values. Usually it's a job of BIOS. But if BIOS doesn't do it, user need to do it manually. Build your kernel with CONFIG_SND_HDA_HWDEP=y, CONFIG_SND_HDA_RECONFIG=y, CONFIG_SND_HDA_PATCH_LOADER=y. I guess most of distro kernels are built with them. Then create a file containing below in /lib/firmware, such as, /lib/firmware/ibx-hdmi: [codec] 0x80862804 0x80860101 3 [pincfg] 0x04 0x41f0 0x06 0x41f0 Now pass this file to patch module option for snd-hda-intel. For example, create a file in /etc/modprobe.d/, e.g. /etc/modprobe.d/50-hdmi.conf, containing the line options snd-hda-intel patch=ibx-hdmi Then reload the driver or reboot. This will disable pins 0x04 and 0x06 so that only the pin 0x05 will be used. Let me also push for the hda-jack-retask [2] application, which is an easy-to-use GUI for creating these types of firmware files. I advertised it here a while ago [3] but it seems to have gone unnoticed. This sounds like a good tool for making this happen. I will submit a Request For Package in Debian... but this can take time. Would you consider packaging it there? then it would easily flow into Ubuntu. I've encountered other hardware with the same issue recently. It's an NVIDIA card HDA MCP89 on a Macbook Pro 7,1. Is there a method I can follow for crafting my own patches? I'm afraid I don't understand how to find the appropriate HEX values that need to go in the [codec] and [pincfg] section. Thanks all for your help. Cheers, Andres -- 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/CAH=dyrexdb_exyr01pfq8lmnkxdukq8elrluengbvj8zf_v...@mail.gmail.com
Bug#622707: Closing bug as invalid
622707-done thanks I'm closing this bug as invalid. The problem was hardware related. I tested this by installing Lenny on the laptop (which used to work without any problems), yet the same behavior was observed. Shortly after testing I had to replace the laptop because of hardware malfunction. Thanks Andres -- 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/CAH=dyrhjltrgox7nsd5rvxtlk8voftfuxgoxqc0db1heffq...@mail.gmail.com
Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB
First of all, thank you for your feedback. It's been quite helpful / insightful The biggest problem is that PA checks only the first HDMI device. In that sense, this is no regression in the kernel side, although I know it's annoying. I agree this seems more like a shortcoming of pulseaudio. Else it's my BIOS' fault, which doesn't surprise me, seeing at this notebook is manufactured by some unknown OEM in Taiwan for other vendors and all they care is if Windows runs ok on it. In fact, I currently have many unsupported ACPI keys events because of it. If the new two pins can be never used, i.e. physically unreachable, we may disable these pins by giving the proper default pin-config values. Usually it's a job of BIOS. But if BIOS doesn't do it, user need to do it manually. Build your kernel with CONFIG_SND_HDA_HWDEP=y, CONFIG_SND_HDA_RECONFIG=y, CONFIG_SND_HDA_PATCH_LOADER=y. I guess most of distro kernels are built with them. Then create a file containing below in /lib/firmware, such as, /lib/firmware/ibx-hdmi: [codec] 0x80862804 0x80860101 3 [pincfg] 0x04 0x41f0 0x06 0x41f0 Now pass this file to patch module option for snd-hda-intel. For example, create a file in /etc/modprobe.d/, e.g. /etc/modprobe.d/50-hdmi.conf, containing the line options snd-hda-intel patch=ibx-hdmi Then reload the driver or reboot. This will disable pins 0x04 and 0x06 so that only the pin 0x05 will be used. I've tested this workaround and it works well. I don't suppose this could be added as a quirk to the kernel for this particular device? (when and only if there's only one physically accessible HDMI connector). There are ways to configure pulseaudio to allow the user to select which PCM device to use on a given sound card. David Henningsson made this work for NVIDIA GPUs at least in Ubuntu, and I imagine the same technique could be applied to Intel devices too. Mmm.. just in Ubuntu? was this work submitted upstream? It appears there are some related fixes shown in the Ubuntu pulseaudio changelog: http://changelogs.ubuntu.com/changelogs/pool/main/p/pulseaudio/pulseaudio_1.1-0ubuntu9/changelog I found a thread related to this issue here: http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg07433.html Started by yourself Stephen Warren! but it doesn't seem like it got anywhere... As Takashi mentions, from a kernel perspective, this isn't really a regression at all, but simply exposing all the features of the HW that were previously hidden. Without that change, others can't use some HW usefully at all. Unfortunately, pulseaudio makes some rather simplistic assumptions about how HW works by default, and can be confused by the additional features that are exposed. Agreed. But in the case of laptops, I don't think I've ever seen one that actually has more than one physical connector. I'm a little puzzled as to how all these outputs (in my case 3) make sense for my hardware... I thought that no regressions meant that the first sentence and not the second sentence of the previous paragraph apply from a kernel perspective. No? So I would be happiest if there is some way to teach the kernel about this quirk until everyone already has had a fixed pulseaudio for a year or two. I agree fixing pulseaudio is ideal, but a kernel quirk can be backported more easily from a distribution perspective. Anyways, thank you for your support Best Regards, Andres -- 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/CAH=dyrgug0wfbfamvmjdt28pckz3txutrq61-k++ui5vxsr...@mail.gmail.com
Bug#660111: [3.0 - 3.1.8 regression] intel ibexpeak hdmi no sound out
Found the first bad commit. It was the one you suspected all along! I will submit this issue upstream. Thanks for your invaluable help and demos! Cheers Andres 384a48d71520ca569a63f1e61e51a538bedb16df is the first bad commit commit 384a48d71520ca569a63f1e61e51a538bedb16df Author: Stephen Warren swar...@nvidia.com Date: Wed Jun 1 11:14:21 2011 -0600 ALSA: hda: HDMI: Support codecs with fewer cvts than pins The general concept of this change is to create a PCM device for each pin widget instead of each converter widget. Whenever a PCM is opened, a converter is dynamically selected to drive that pin based on those available for muxing into the pin. The one thing this model doesn't support is a single PCM/converter sending audio to multiple pin widgets at once. Note that this means that a struct hda_pcm_stream's nid variable is set to 0 except between a stream's open and cleanup calls. The dynamic de-assignment of converters to PCMs occurs within cleanup, not close, in order for it to co-incide with when controller stream IDs are cleaned up from converters. While the PCM for a pin is not open, the pin is disabled (its widget control's PIN_OUT bit is cleared) so that if the currently routed converter is used to drive a different PCM/pin, that audio does not leak out over a disabled pin. We use the recently added SPDIF virtualization feature in order to create SPDIF controls for each pin widget instead of each converter widget, so that state is specific to a PCM. In order to support this, a number of more mechanical changes are made: * s/nid/pin_nid/ or s/nid/cvt_nid/ in many places in order to make it clear exactly what the code is dealing with. * We now have per_pin and per_cvt arrays in hdmi_spec to store relevant data. In particular, we store a converter's capabilities in the per_cvt entry, rather than relying on a combination of codec_pcm_pars and the struct hda_pcm_stream. * ELD-related workarounds were removed from hdmi_channel_allocation into hdmi_instrinsic in order to simplifiy infoframe calculations and remove HW dependencies. * Various functions only apply to a single pin, since there is now only 1 pin per PCM. For example, hdmi_setup_infoframe, hdmi_setup_stream. * hdmi_add_pin and hdmi_add_cvt are more oriented at pure codec parsing and data retrieval, rather than determining which pins/converters are to be used for creating PCMs. This is quite a large change; it may be appropriate to simply read the result of the patch rather than the diffs. Some small parts of the change might be separable into different patches, but I think the bulk of the change will probably always be one large patch. Hopefully the change isn't too opaque! This has been tested on: * NVIDIA GeForce 400 series discrete graphics card. This model has the classical 1:1:1 codec:converter:pcm widget model. Tested stereo PCM audio to a PC monitor that supports audio. * NVIDIA GeForce 520 discrete graphics card. This model is the new 1 codec n converters m pins mn model. Tested stereo PCM audio to a PC monitor that supports audio. * NVIDIA GeForce 400 series laptop graphics chip. This model has the classical 1:1:1 codec:converter:pcm widget model. Tested stereo PCM, multi-channel PCM, and AC3 pass-through to an AV receiver. * Intel Ibex Peak laptop. This model is the new 1 codec n converters m pins mn model. Tested stereo PCM, multi-channel PCM, and AC3 pass- through to an AV receiver. Note that I'm not familiar at all with AC3 pass-through. Hence, I may not have covered all possible mechanisms that are applicable here. I do know that my receiver definitely received AC3, not decoded PCM. I tested with mplayer's -afm hwac3 and/or -af lavcac3enc options, and alsa a WAV file that I believe has AC3 content rather than PCM. I also tested: * Play a stream * Mute while playing * Stop stream * Play some other streams to re-assign the converter to a different pin, PCM, set of SPDIF controls, ... hence hopefully triggering cleanup for the original PCM. * Unmute original stream while not playing * Play a stream on the original pin/PCM. This was to test SPDIF control virtualization. Signed-off-by: Stephen Warren swar...@nvidia.com Signed-off-by: Takashi Iwai ti...@suse.de :04 04 894370c6534b1bf03df9a8a8c7d85c2eeffc7555 98cb8a73a0ed46f034e25bd35002930bc22376ef M sound git bisect log git bisect start # bad: [76531d4166fb620375ff3c1ac24753265216d579] Merge branch 'topic/hda' into for-linus git bisect bad 76531d4166fb620375ff3c1ac24753265216d579 # good: [7d339ae99758bc21033d4a19bcd4f7b55f96e24e] Merge branch
Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB
Dear Mr. Warren, I recently upgraded my laptop to Debian testing (from Debian stable + the longterm stable 3.0.x kernel). The newer kernel 3.2.x came with a regression that git bisect has traced down to one of your commits in the early 3.1.x kernel development stage (git bisect output and git bisect log attached). Under kernel 3.0.x HDMI sound works out-of-the-box as tested with pulse audio (choosing the option Digital Stereo (HDMI) Output) and by the command: $ aplay -D plughw:0,3 /usr/share/sounds/alsa/Front_Center.wav Alsa's device list reveals: $ aplay -l List of PLAYBACK Hardware Devices card 0: Intel [HDA Intel], device 0: ALC269VB Analog [ALC269VB Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 Unfortunately with kernel 3.2.x and 3.1.x I get no sound out choosing the same configuration in pulseaudio. Device is advertised correctly but there's a bizarre multiplicity advertised: $ aplay -l List of PLAYBACK Hardware Devices card 0: Intel [HDA Intel], device 0: ALC269VB Analog [ALC269VB Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 Using aplay with device 3 says device is busy. Device 7 works correctly (but is not available in pulseaudio unless forced by default, which then renders internal speakers disabled) and device 8 produces no sound out. This appears to be a regression in the kernel about this device, advertising non-physically connected HDMI sound devices that cause pulse audio to get confused (Pulseaudio only seems to be able to handle one HDMI output by default device 0,3). Output of the alsa-info script for kernel 3.0.20 and 3.2.4 is attached. Can you please advice how to fix this problem? I see there was a patch about the same time meant to address the multiplicity of port advertised and restrict to the ones being used, but this doesn't seem to be working here (see http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=0b6c49b59fb272c1a20f79202693ed1072e9548c) For reference, this is the original Debian bug report: http://bugs.debian.org/660111 Best Regards, Andres Cimmarusti 384a48d71520ca569a63f1e61e51a538bedb16df is the first bad commit commit 384a48d71520ca569a63f1e61e51a538bedb16df Author: Stephen Warren swar...@nvidia.com Date: Wed Jun 1 11:14:21 2011 -0600 ALSA: hda: HDMI: Support codecs with fewer cvts than pins The general concept of this change is to create a PCM device for each pin widget instead of each converter widget. Whenever a PCM is opened, a converter is dynamically selected to drive that pin based on those available for muxing into the pin. The one thing this model doesn't support is a single PCM/converter sending audio to multiple pin widgets at once. Note that this means that a struct hda_pcm_stream's nid variable is set to 0 except between a stream's open and cleanup calls. The dynamic de-assignment of converters to PCMs occurs within cleanup, not close, in order for it to co-incide with when controller stream IDs are cleaned up from converters. While the PCM for a pin is not open, the pin is disabled (its widget control's PIN_OUT bit is cleared) so that if the currently routed converter is used to drive a different PCM/pin, that audio does not leak out over a disabled pin. We use the recently added SPDIF virtualization feature in order to create SPDIF controls for each pin widget instead of each converter widget, so that state is specific to a PCM. In order to support this, a number of more mechanical changes are made: * s/nid/pin_nid/ or s/nid/cvt_nid/ in many places in order to make it clear exactly what the code is dealing with. * We now have per_pin and per_cvt arrays in hdmi_spec to store relevant data. In particular, we store a converter's capabilities in the per_cvt entry, rather than relying on a combination of codec_pcm_pars and the struct hda_pcm_stream. * ELD-related workarounds were removed from hdmi_channel_allocation into hdmi_instrinsic in order to simplifiy infoframe calculations and remove HW dependencies. * Various functions only apply to a single pin, since there is now only 1 pin per PCM. For example, hdmi_setup_infoframe, hdmi_setup_stream. * hdmi_add_pin and hdmi_add_cvt are more oriented at pure codec parsing and data retrieval, rather than determining which pins/converters are to be used for creating PCMs. This is quite a large change; it may be appropriate
Bug#660111: [3.0 - 3.1.8 regression] intel ibexpeak hdmi no sound out
To be clear, are you saying git bisect told you that 76531d4166 was the first bad commit? Not exactly. I told you I got confused on how to use git-bisect, so I didn't use it (I didn't understand how is it supposed to check each commit, when another kernel is running). I simply used your first suggestion for debugging which was: git checkout 76531d4166... cp /boot/config... .config make -j4 deb-pkg The kernel produced here showed the problem, however another kernel compiled before with commit 7d339ae99758bc21033d4a19bcd4f7b55f96e24e (which is exactly the one prior) wasn't affected. If so, that means that _both_ its parents (7d339ae and a353fbb) tested fine and that the merge tested as broken. Which would mean that either we have a heisenbug and all information so far is suspect, or their interaction produced the bug. mmm... I believe I tested the first parent and it worked fine. On the git web link I sent you that lists all the kernel commits that occurred around this time, there's a clear series of commits. It follows that 76531d4166 is preceded by 7d339ae, so I tested both, the former showed the problem and the latter did not. Is this enough? If you have been using git bisect, could you attach the output of git bisect log? Sorry I did not use it. If you point me in the right direction I can try to use it Thanks for all your help Andres -- 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/CAH=dYrEHw-m467atr1CbD+=+6x+ulkvrmcpp6xhovzvw6zy...@mail.gmail.com
Bug#660111: [3.0 - 3.1.8 regression] intel ibexpeak hdmi no sound out
Perhaps v3.1-rc2~4^2~47^2~89 (ALSA: hda: HDMI: Support codecs with fewer cvts than pins, 2011-07-01) is the problematic patch. Can you check this guess, like so? That patch that you mention is included in the 3.0.x kernels as the matter of fact. Thus I don't think it would have caused the problem. See for example: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=384a48d71520ca569a63f1e61e51a538bedb16df and http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=shortlog;h=384a48d71520ca569a63f1e61e51a538bedb16df I didn't find this out the easy way. I compiled the kernel with your instructions and suddenly the name was 3.0.0-rc2 instead of 3.1.0-rc2 as I expected. I'll try to find a relevant patch for alsa hda hdmi in the 3.1 development series. I've looked a good candidates, but always on the wrong development cycle... This one seems promising though: http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=0b6c49b59fb272c1a20f79202693ed1072e9548c How did you get that number you gave me before to use with git? basically I'm asking how do I get it for this patch ? I'm going to simply download the snapshot and try it for now. There are other suspicious patches submitted around the same time. I shall try them at some point: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=shortlog;h=0b6c49b59fb272c1a20f79202693ed1072e9548c Cheers Andres -- 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/CAH=dyrfjx06tng2haq75o2nr-zjuexcqbj8r_swan1izcnq...@mail.gmail.com
Bug#660111: [3.0 - 3.1.8 regression] intel ibexpeak hdmi no sound out
Thanks for the git crash course. I did not look at 'git-bisect' too much. It is more systematic, but how to test each commit confused me some. I found the patch that brings about the problem. It turns out it happened quite early in the 3.1 kernel merge window. This the commit that changes things: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=76531d4166fb620375ff3c1ac24753265216d579 Which is more elaborate in the alsa-git repo: http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=76531d4166fb620375ff3c1ac24753265216d579 Unfortunately this commit is rather extensive and includes many changes. I believe alsa-git has the detailed commits leading to this merge here: http://git.alsa-project.org/?p=alsa-kernel.git;a=shortlog;h=76531d4166fb620375ff3c1ac24753265216d579 Particularly, I found this commit rather suspicious: http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=4c11398edc19fdd9c651f3ff287cd628fecaf574 I'm not sure how to test each alsa commit individually. I guess I have to build alsa externally... Perhaps it's time to send this upstream? Cheers, Andres -- 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/CAH=dYrE1xYkLJmQ5N_h_u=ectsh9inoyjdcoq4wxfrgqcqv...@mail.gmail.com
Bug#660111: more info
retitle 660111 [linux-image-3.2] ALC269VB HDMI single physical port - multiple devices detected quit After some online searching for this card's codec alc269vb I found several reports (some very old...) of the problem in Arch Linux: https://bbs.archlinux.org/viewtopic.php?id=133222 They point to a solution which is no longer documented. However, I did some more digging around and found a workaround: ftp://download.nvidia.com/XFree86/gpu-hdmi-audio-document/gpu-hdmi-audio.html#_pulseaudio_default_device or http://wiki.xbmc.org/index.php?title=HOW-TO:Setup_HDMI_audio_on_GeForce_GT210,_GT220,_or_GT240#PulseAudio_Configuration or http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg07433.html However, all these discussions point to NVIDIA cards, which are known for having several HDMI ports available. My laptop only has one, which in case of the 3.0.x kernel was assigned to the default HDMI alsa device #3 (and pulseaudio had no trouble using it). Now with kernel 3.2.x, my card appears to have 3 HDMI ports. The one on device #3 is no longer the actual connector on the laptop, but device #7 is, however pulseaudio only loads the first device by default. The workaround, as listed in the 3 links provided, is to force pulse to load the device that actually works adding this line to /etc/pulse/default.pa load-module module-alsa-sink device=hw:0,7 This works, I have just tested it. But I don't understand why my device, having only one physical output can be detected as having three, this is why I think the bug report should remain open. Furthermore this workaround hinders me from manually choosing the output device on pavucontrol as I did before, thus I cannot use the laptop speakers.. Should a bug report be filed against pulseaudio for lacking the capability to handle several HDMI outputs? I'm of the opinion that this is not necessary seeing as they are already aware of the problem. -- 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/CAH=dyrgztjjv37ecu9g1pmjo9mhz4djd_er+vv-ry3cvvta...@mail.gmail.com
Bug#660111:
retitle 660111 ALC269VB HDMI 3 devices detected instead of 1 quit -- 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/CAH=dYrGWKM6ax0Er-0RKx5JqHJXzJk0mew=xzoTxJv=voae...@mail.gmail.com
Bug#660111: [3.0 - 3.2.4 regression] intel ibexpeak hdmi no sound out
retitle 660111 [3.0 to 3.1 regression] HDMI 3 devices instead of 1 quit Can you narrow down the regression range by a bisection search through kernels at http://snapshot.debian.org/ to find the first broken one? I installed two kernels from snapshots. Using date 2012-02-01 I was able to pull in a 3.1.8 kernel that exhibited the same problem as kernels 3.2.x. I also used data 20111201 and pulled in a debian 3.0.x kernel. This one didn't have the problem (as in the case of my own 3.0.20). So I guess this is a regression from 3.0 to 3.1 that is still a problem in 3.2. Andres -- 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/CAH=dyrgmuwfyrxej-vhhjzhek+u0y0vtftvnpohvybacafv...@mail.gmail.com
Bug#641749: firmware loading failure for AR3011 (0cf3:3000 or 0cf3:3005 ?)
I believe I have finally narrowed down the problem. It lies in the 'libmtp-runtime' package with the command 'mtp-probe' (only present in wheezy or newer). I'm not sure what this is doing to my system, but when the package mentioned is installed, it messes up my atheros bluetooth device so that the kernel/udev cannot load the firmware into it. As soon as I uninstalled this package and thus caused the boot process to throw some errors about missing mtp-probe command, my bluetooth module was correctly loaded and the led turned on. Inexplicably yesterday's (and the day before) Debian testing snapshot seems to have the problem fixed! I guess this snapshot that I tested earlier didn't have that package installed I found out about this completely by chance. For whatever reason, on my second upgrade to wheezy 'apt-get dist-upgrade' didn't pull 'libmtp-runtime' and my bluetooth module just worked. I tried to get the bootlog messages so I can send this info, but even with bootlogd enabled these messages happen too early on the boot process to be logged in /var/log/boot. I feel this is not necessarily a kernel bug anymore (all kernels tested work fine 3.0.x, 3.1.x, 3.2.x and even 3.3.0-rc3). But the experts will know better. This is definitely progress! Cheers Andres PS: please forward the info to other bug reports I don't have access to, like Red Hat / Fedora and Ubuntu. Additional testing is needed. -- 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/CAH=dyrfs+ty2xxwvv6y-omi6stt-tyr7nl20+2fyqlv3rgs...@mail.gmail.com
Bug#641749: ath3k_load_firmware: Can't change to loading configuration err
There's only silence in the linux-kernel and linux-bluetooth mailing lists... At this point there is only one thing I haven't tried because I can't at the moment. One of the differences between Wheezy and Squeeze in terms of, say the 3.1.x, kernel is that in Squeeze I compile it with gcc 4.4.5, but in wheezy this is done with gcc 4.6.x. Could there be a problem here? I don't have access to any machine with gcc 4.6.x nor wheezy, so I can't test this... somehow I doubt the wheezy live-usb image will allow me to do this... but I'll look around and see if it's possible. AFAIK this is the only thing left to test. Andres -- 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/CAH=dyrhpdukulbpfvtyfrisy+dzvdo0vpetfrlehqv1i_nd...@mail.gmail.com
Bug#641749: firmware loading failure for AR3011 (0cf3:3000 or 0cf3:3005 ?)
Dear all, This is an upstream bug report for known bugs in at least 3 linux distros: Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641749 Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=702375 ***Steps to reproduce*** - Boot current Debian testing / Fedora 16 / Ubuntu 11.10 (using kernels 3.1.x and 3.0.x) ***Expected behavior*** - Working bluetooth and no problems in rebooting laptop as occurs using Ubuntu 11.04 / Fedora 15 and/or Debian Squeeze (using kernels 2.6.38 or newer) - lsusb reveals this: Bus 001 Device 004: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth ***Actual Result*** - Boot process stalls and fails to load firmware for this Atheros AR3011 bluetooth module: [9.335184] ath3k_load_firmware: Can't change to loading configuration err [9.335413] ath3k: probe of 1-1.3:1.0 failed with error -110 [9.335459] usbcore: registered new interface driver ath3k - lsusb of the device shows this: Bus 001 Device 003: ID 0cf3:3000 Atheros Communications, Inc. AR3011 Bluetooth (no firmware) - After login bluetooth does not work. Furthermore, choosing to Restart the laptop causes it to hang at first pre-bios post screen. ***Things I've tried*** The weird part about this bug is that using Debian squeeze as a base, I can run the newest kernels (2.6.39, 3.0.x and 3.1.x) and I have no problems at all. Also the output of lsusb differs substantially from the working vs broken system. Ubuntu 11.04 and Fedora 15 also work fine using kernel 2.6.38. Here is an example dmesg, using kernel 3.0.8 on Squeeze (no problem): http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=56;filename=dmesg_stable%2B3.0.8.txt;att=2;bug=641749 And here is a similar 3.0.x Debian mainline kernel running on top of Debian testing (wheezy): http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=56;filename=dmesg_testing%2B3.0.0-2.txt;att=1;bug=641749 If you browse the Debian bug report link listed at the beginning of this email, you will also be able to get logs for kernel 3.1.x. Furthermore, I've tested downgrading the version of udev to the one found in Debian squeeze (version 164) as well as usb-modeswitch (also tried upgrading to the latest versions in Debian unstable), but this has yielded no progress and no clues at all...the error messages remain the same. Help debugging this issue would be most welcome. Best Regards Andres Cimmarusti PS: For reference this is a Linux Certified laptop model LC2131, also known as the Zareason Strata Pro 13 or the ASI SpringPeak 13 -- 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/CAH=dyrhhttmrjkvuo9qvj5_uqd+bjgcjjkamw8153rw1sfv...@mail.gmail.com
Bug#641749: ath3k_load_firmware: Can't change to loading configuration err
Hi there Yes, no ideas here, either. Please contact linux-blueto...@vger.kernel.org, cc-ing linux-ker...@vger.kernel.org and either me or this bug log so we can track it. I've spotted something odd that may give us some light as to why it's not working and I wanted to discuss it here before sending a full report to the kernel mailing lists: Using Debian testing, for some unknown reason, the device is labeled as: Bus 001 Device 003: ID 0cf3:3000 Atheros Communications, Inc. AR3011 Bluetooth (no firmware) But under Squeeze, it becomes something different! Bus 001 Device 004: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth Is this just because the firmware has been loaded and it changes or perhaps in testing, the device is being wrongly associated and thus cannot get its firmware properly? Thanks Andres -- 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/CAH=dyrh1yw4t7ux99yjhntp3v6-w00dymv6r0tfwufoeqtn...@mail.gmail.com
Bug#641749: ath3k_load_firmware: Can't change to loading configuration err
Hi Jonathan, I'd like to narrow down the difference even more. So, here are some ideas: 1. Can you reproduce this with a squeeze kernel? (I'm guessing it lacks support since it doesn't include commit v2.6.33-rc7~20^2~3^2~1, Bluetooth: Add DFU driver for Atheros Bluetooth chipset AR3011, but it can't hurt to try.) If you can, please test with the same kernel package on squeeze and testing. Squeeze's kernel (on squeeze) does not work. I tried that sometime ago. I haven't tried it on top of wheezy, but I'm pretty sure it won't work either. 2. Please test with v3.2-rc1 or later once it is available from experimental (or sooner, if you have time to build it from source). If you can reproduce it with that, everything else is moot, and we should try to get help from upstream by contacting linux-blueto...@vger.kernel.org, cc-ing linux-ker...@vger.kernel.org (please cc me or this bug log when doing so so we can track it). I can tell you that kernel 3.0.x and 3.1.x have no trouble with the atheros firmware loading process (on top of Squeeze). I haven't tried 3.2. 3. Can you reproduce this on wheezy using a pristine upstream kernel? See [1] for instructions on building one. At the moment I can't try this, because I don't have wheezy installed. I used to, but it gave me so much trouble with this laptop that I had go to Squeeze and use an upstream recent kernel. All my tests ever since have been based on a debian live usb-key with wheezy (I don't know how to tell live-build to boot the upstream package, instead of the main). What I can do is get a wheezy image with the 3.2 kernel from experimental. 4. Another thing to try would be downgrading just udev and libudev0 to the versions in squeeze from wheezy. I haven't tried downgrading. This could work. I will give this a shot for my next debian-live image. As it turns out, the new udev 175 breaks live-boot, so it's not working right now (I was hoping upgrading to 175 would solve the problem...). Hopefully downgrading will solve both issues! I will report back as soon as I get a chance Andres -- 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/CAH=dyrhryek+zwyqfictqqhqhuwdsjlfxmpgt9-hgzkkeil...@mail.gmail.com
Bug#641749: bug 641749 update
Hi, I've been successfully using a pristine 3.0.x kernel on the same laptop atop Debian Squeeze (using the firmware-atheros packages from backports and/or testing). I have no problems loading the AR3011 bluetooth module firmware and system restarts appropriately. I started doing this since 3.0.6. It also works with 3.0.7 and the latest 3.0.8. As a test, I created a Debian Live image on a USB stick with Debian testing (and the latest kernel from Sid which is like ~3.0.7). I also included the firmware-atheros and firmware-linux* packages. The system boots fine, but it fails to load the atheros firmware! I guess the problem does not reside in the kernel image package, nor in the firmware(?!). I'm puzzled by this. What other packages contain tools which are responsible for the loading of firmware? To further confirm the problem, the newest Ubuntu (Live CD) 11.10 or Xubuntu also fail to load the firmware. This releases uses kernel 3.0.x. I hope this helps in narrowing down the culprit. Andres -- 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/CAH=dYrEazwcm8pnDn0=hmpr3jqpmnc95p1ys0guvfx4uvpn...@mail.gmail.com
Bug#641749: firmware-atheros doesn't load for Atheros AR3011
The reason why it works in Ubuntu with kernel 2.6.38 is because they patched their kernel: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/720949 https://launchpadlibrarian.net/68723624/0002-UBUNTU-SAUCE-Revert-Bluetooth-Add-new-PID-for-Athero.patch Actually this patch is already in 3.0.0 and above. My issue remains. My specific device is: Bus 001 Device 003: ID 0cf3:3000 Atheros Communications, Inc. AR3011 Bluetooth (no firmware) Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0cf3 Atheros Communications, Inc. idProduct 0x3000 AR3011 Bluetooth (no firmware) bcdDevice2.00 iManufacturer 0 iProduct0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x000a (Bus Powered) Remote Wakeup Enabled -- 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/CAH=dYrEnehhRskEF6XQN-kLQpizvc_NT2XCALLhJGNaot7=0...@mail.gmail.com
Bug#641749: firmware-atheros doesn't load for Atheros AR3011
This error message indicates a communication failure with the device after the firmware has been loaded from disk but before it has been transferred into the device. So it's not a problem with the firmware but with the driver or the hardware. I see. Did this hardware work with a previous kernel version? Does it work with the current official kernel package (linux-image-3.0.0-1-amd64)? This device is rather peculiar. I currently have a dual boot with Ubuntu 11.04. In Ubuntu, using kernel 2.6.38 the device works correctly as expected. The bluetooth LED turns on and everything. In Debian, however, running either my vanilla kernel 3.0.4 or official Debian kernel 3.0.0-1-amd64 leads to the same error at boot time. The weird thing is that, sometimes when I restart Ubuntu and go into Debian, the firmware loaded into the AR3011 does not get wiped out and I get a clean boot with no errors using Debian. If I turn it off and boot into Debian, then I have trouble. I think this may be a bug in a recent kernel: https://bugzilla.redhat.com/show_bug.cgi?id=702375 I guess this should be reassigned to the kernel then? Thanks, Andres -- 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/CAH=dYrEZ_ZAwbU1Mma-gun0enr-jiLZwyr3qQ5nt3_omgM_r=a...@mail.gmail.com
Bug#641749: firmware-atheros doesn't load for Atheros AR3011
This device is rather peculiar. I currently have a dual boot with Ubuntu 11.04. In Ubuntu, using kernel 2.6.38 the device works correctly as expected. The bluetooth LED turns on and everything. In Debian, however, running either my vanilla kernel 3.0.4 or official Debian kernel 3.0.0-1-amd64 leads to the same error at boot time. The weird thing is that, sometimes when I restart Ubuntu and go into Debian, the firmware loaded into the AR3011 does not get wiped out and I get a clean boot with no errors using Debian. I forgot to mention something extra about this problem. I'm almost certain this is causing my system to freeze at the Pre-BIOS post screen after rebooting from Debian (when firmware has not been loaded). The reason for this assertion is that, as I told you above, when I boot into Ubuntu and restart to go into Debian, the device keeps the firmware loaded and remains so in the Debian session. Upon rebooting Debian (with firmware loaded from previous Ubuntu session) everything works as expected. This is a very annoying bug! I have to hard press the power button at post screen to be able get the system unstuck This is a LC2131 Linux certified Inc. Laptop, but it's really an ASI SP13R (Spring Peak) for reference. Andres -- 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/CAH=dyrh+zvn-wnp28knhubp980fowacxasd1x5mqdf31wcp...@mail.gmail.com
Bug#641749: firmware-atheros doesn't load for Atheros AR3011
Hey, I just found more information This device is rather peculiar. I currently have a dual boot with Ubuntu 11.04. In Ubuntu, using kernel 2.6.38 the device works correctly as expected. The bluetooth LED turns on and everything. In Debian, however, running either my vanilla kernel 3.0.4 or official Debian kernel 3.0.0-1-amd64 leads to the same error at boot time. The weird thing is that, sometimes when I restart Ubuntu and go into Debian, the firmware loaded into the AR3011 does not get wiped out and I get a clean boot with no errors using Debian. The reason why it works in Ubuntu with kernel 2.6.38 is because they patched their kernel: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/720949 https://launchpadlibrarian.net/68723624/0002-UBUNTU-SAUCE-Revert-Bluetooth-Add-new-PID-for-Athero.patch I also saw this patch also in a Gentoo forum: http://forums.gentoo.org/viewtopic-t-887112-view-previous.html?sid=46739f74e3419eb7efee8b0b1cb98ce0 Apparently there is an upstream bug report: https://bugzilla.kernel.org/show_bug.cgi?id=27402 But that is down right now, because kernel.org is down. Perhaps this patch could be applied to Debian's kernel? -- 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/CAH=dYrH5rLRhXogZH2a_JWBkiB_=u6hfneye9rattfbm7gk...@mail.gmail.com
Bug#641749: firmware-atheros doesn't load for Atheros AR3011
Package: firmware-atheros Version: 0.33 Severity: important Dear Maintainer, This is my device: Bus 001 Device 003: ID 0cf3:3000 Atheros Communications, Inc. AR3011 Bluetooth (no firmware) It does not turn on and kern.log shows following errors: [9.335184] ath3k_load_firmware: Can't change to loading configuration err [9.335413] ath3k: probe of 1-1.3:1.0 failed with error -110 [9.335459] usbcore: registered new interface driver ath3k Thanks, Andres -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.4-desktop-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash firmware-atheros depends on no packages. firmware-atheros recommends no packages. Versions of packages firmware-atheros suggests: ii initramfs-tools0.99 ii linux-image-3.0.0-1-amd64 [linux-image]3.0.0-3 ii linux-image-3.0.4-desktop-amd64 [linux-image] 3.0.4~desktop -- no debconf information -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110915180915.3747.95412.reportbug@lc2131
Bug#588602: xserver-xorg-video-radeon: xpress 200m 5955 = resume from suspend fails with KMS enabled
Sorry for not reporting back sooner. This bug was actually fixed for squeeze. Thus it's been fixed in testing and did for quite sometime. You can close this On Jul 30, 2011 5:05 AM, Moritz Mühlenhoff j...@inutil.org wrote: On Mon, May 31, 2010 at 05:15:41PM -0400, Andres Cimmarusti wrote: Package: xserver-xorg-video-radeon Version: 1:6.13.0-2 Severity: important Tags: squeeze When I try suspending using KMS my computer (an HP Pavilion dv5035nr laptop) does not resume. Furthermore I've tried logging into it remotely to obtain a backtrace from X with no success (following this procedure: http://ubuntuforums.org/showthread.php?t=1228332). I'm letting NetworkManager handle my network interfaces, however, I also tried using dhcp directly in the /etc/network/interfaces file. Unfortunately as soon as the resuming process starts (and fails) I am unable to establish a connection the laptop (wired or wireless). On top of this, upon hard reboot I have no network connectivity (if managed by network manager): http://mail.gnome.org/archives/networkmanager-list/2010-March/msg00123.html The workaround for the last bit has been to erase the stale file and reboot. When using UMS the resume process happens perfectly. I don't know how else to get a backtrace. The laptop screen is completely blank so I can't switch to another session. I've marked this bug as important because suspend/hibernate are almost essential features in a laptop. Does this still occur in current sid/testing? Cheers, Moritz
Bug#586270: linux-image-2.6.32-5-686: evo n610c compaq laptop fails to go into suspend mode
Sorry for the late followup. It is I who should be sorry for not reporting back as soon as this was fixed. Does this still occur with more recent kernels, i.e. the final Squeeze kernel or more recent versions from backports/testing/sid? Squeeze is running very well on this laptop. Suspend works as expected. You can close this bug report thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTimBW+WFQbyezTnd5W=cwxieg9a...@mail.gmail.com
Bug#622707: bug 622707 seems resolved upstream
Just a little update: Sync problems and lagging seems gone once I pass the options i8042.nomux to the kernel. This is true for the synaptics touchpad, but it causes a terrible problem: I started using Linux on this laptop since I started with Linux in 2008 with Ubuntu 8.04 based on the 2.6.24 kernel. Ever since kernels higher than this one I've had an issue of keyboard repeat: keys behave as if they would still be pressed when released! Usually I just accepted this problem (which happened on occasions). The solution was simply to press another key to un-jam the one repeating itself. You can imagine this being very annoying when the delete or backspace key gets jammed... This is an old problem in the kernel and X : http://ajaxxx.livejournal.com/62378.html https://bugs.launchpad.net/linux/+bug/124406?comments=all Unfortunately for me, by passing the kernel the nomux option, now I can't un-jam the key that keeps repeating!...in fact, I loose full control of the keyboard and touchpad when this happens...only the power button works (alternatively I can use an USB mouse to try to remedy the situation). I don't know what to do to solve this problem...the first link seems to have some ideas, but I don't know if work has gone into solving this rather obscure issue. I'll probably go back to using evdev to handle my touchpad for the time being Andres -- 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/BANLkTi=MV2fu+v=xonglo1zoesz0kuo...@mail.gmail.com
Bug#622707: bug 622707 seems resolved upstream
Hi, this is the upstream kernel bug report I submitted: https://bugzilla.kernel.org/show_bug.cgi?id=33652 Sync problems and lagging seems gone once I pass the options i8042.nomux to the kernel. The query no synaptics error message still shows up in Xorg.0.log. But the kernel developer pointed out this: http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html As you can see, not only Arch Linux, but Fedora also ship the following configuration file for xorg.conf.d Section InputClass Identifier touchpad catchall Driver synaptics MatchIsTouchpad on MatchDevicePath /dev/input/event* EndSection The important change from Debian is the inclusion of the line: MatchDevicePath /dev/input/event* But they also say this is purely cosmetic. Andres -- 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/BANLkTi=iv=bD-1+P4wOGhnSD_QCbL=g...@mail.gmail.com
Bug#618979: same here
I have the same issue. System is overall slow (I thought 2.6.38 was supposed to have major performance improvements including the famous desktop latency patch!). I'm running gnome with no desktop effects using radeon open source drivers. -- 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/AANLkTimk=aa81wp9gxveccj-gpwn2pjrwluvmst7t...@mail.gmail.com
Bug#611827: xserver-xorg-input-evdev: mice and touchpad losing sync and lagging (MORE INFO)
Allright, so I have been running for days the 2.6.37 kernel from experimental with no problems. My touchpad is working just fine. This bug is really affecting me in the 2.6.32. It was working fine, but there was an update that messed it up...perhaps a backport? I say this only because the people from Ubuntu are having problems with the 2.6.35 kernel -- 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/AANLkTi=u9xvdvr-c8-174w0k7+bbp0+gssu+srewj...@mail.gmail.com
Bug#611827: xserver-xorg-input-evdev: mice and touchpad losing sync and lagging (MORE INFO)
This is the contents of my Xorg.log. It seems the appropriate synaptics module is being unloaded... perhaps this is causing the issue? (II) LoadModule: evdev (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so (II) Module evdev: vendor=X.Org Foundation compiled for 1.7.6.901, module version = 2.3.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 7.0 (**) Power Button: always reports core events (**) Power Button: Device: /dev/input/event4 (II) Power Button: Found keys (II) Power Button: Configuring as keyboard (II) XINPUT: Adding extended input device Power Button (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model pc105 (**) Option xkb_layout us (II) config/udev: Adding input device Sleep Button (/dev/input/event5) (**) Sleep Button: Applying InputClass evdev keyboard catchall (**) Sleep Button: always reports core events (**) Sleep Button: Device: /dev/input/event5 (II) Sleep Button: Found keys (II) Sleep Button: Configuring as keyboard (II) XINPUT: Adding extended input device Sleep Button (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model pc105 (**) Option xkb_layout us (II) config/udev: Adding input device Video Bus (/dev/input/event7) (**) Video Bus: Applying InputClass evdev keyboard catchall (**) Video Bus: always reports core events (**) Video Bus: Device: /dev/input/event7 (II) Video Bus: Found keys (II) Video Bus: Configuring as keyboard (II) XINPUT: Adding extended input device Video Bus (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model pc105 (**) Option xkb_layout us (II) config/udev: Adding input device Power Button (/dev/input/event3) (**) Power Button: Applying InputClass evdev keyboard catchall (**) Power Button: always reports core events (**) Power Button: Device: /dev/input/event3 (II) Power Button: Found keys (II) Power Button: Configuring as keyboard (II) XINPUT: Adding extended input device Power Button (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model pc105 (**) Option xkb_layout us (II) config/udev: Adding input device Lid Switch (/dev/input/event2) (II) No input driver/identifier specified (ignoring) (II) config/udev: Adding input device AT Translated Set 2 keyboard (/dev/input/event1) (**) AT Translated Set 2 keyboard: Applying InputClass evdev keyboard catchall (**) AT Translated Set 2 keyboard: always reports core events (**) AT Translated Set 2 keyboard: Device: /dev/input/event1 (II) AT Translated Set 2 keyboard: Found keys (II) AT Translated Set 2 keyboard: Configuring as keyboard (II) XINPUT: Adding extended input device AT Translated Set 2 keyboard (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model pc105 (**) Option xkb_layout us (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/event8) (**) SynPS/2 Synaptics TouchPad: Applying InputClass evdev touchpad catchall (**) SynPS/2 Synaptics TouchPad: Applying InputClass touchpad catchall (II) LoadModule: synaptics (II) Loading /usr/lib/xorg/modules/input/synaptics_drv.so (II) Module synaptics: vendor=X.Org Foundation compiled for 1.7.6.901, module version = 1.2.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 7.0 (II) Synaptics touchpad driver version 1.2.2 (**) Option Device /dev/input/event8 (II) SynPS/2 Synaptics TouchPad: x-axis range 1472 - 5472 (II) SynPS/2 Synaptics TouchPad: y-axis range 1408 - 4448 (II) SynPS/2 Synaptics TouchPad: pressure range 0 - 255 (II) SynPS/2 Synaptics TouchPad: finger width range 0 - 0 (II) SynPS/2 Synaptics TouchPad: buttons: left right middle double triple (--) SynPS/2 Synaptics TouchPad: touchpad found (**) SynPS/2 Synaptics TouchPad: always reports core events (II) XINPUT: Adding extended input device SynPS/2 Synaptics TouchPad (type: TOUCHPAD) (**) SynPS/2 Synaptics TouchPad: (accel) keeping acceleration scheme 1 (**) SynPS/2 Synaptics TouchPad: (accel) acceleration profile 0 (**) SynPS/2 Synaptics TouchPad: (accel) acceleration factor: 2.000 (**) SynPS/2 Synaptics TouchPad: (accel) acceleration threshold: 4 (--) SynPS/2 Synaptics TouchPad: touchpad found (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/mouse1) (**) SynPS/2 Synaptics TouchPad: Applying InputClass touchpad catchall (II) Synaptics touchpad driver version 1.2.2 SynPS/2 Synaptics TouchPad no synaptics event device found (**) Option Device /dev/input/mouse1 Query no Synaptics: 6003C8 (--) SynPS/2 Synaptics TouchPad: no supported touchpad found (EE) SynPS/2 Synaptics TouchPad Unable to query/initialize Synaptics hardware. (EE) PreInit failed for input device SynPS/2 Synaptics TouchPad (II) UnloadModule: synaptics (II) config/udev: Adding input device PC Speaker (/dev/input/event6) (II) No input driver/identifier specified (ignoring) (II) config/udev: Adding input device Macintosh mouse button emulation (/dev/input/event0) (**) Macintosh mouse button emulation: Applying InputClass evdev pointer
Bug#605204: linux-image-2.6.32-5-amd64: hp dv5035nr laptop: failed suspend make X crash
It sounds like the radeon driver is not properly restoring power to the LCD when the suspend process is aborted. Could you test Linux 2.6.36 as packaged in experimental? I've been trying to reproduce it with linux 2.6.36 (+ the dbg package), but I have gotten no problem. In fact, I have opened rhythmbox and played a song while I play a video on youtube and then try to suspend, which happens successfully. I had tried kernel 2.6.36 and I had had the crash (without installing the dbg package), but it happened less than with 2.6.32. I will keep trying. -- 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/aanlkti=36aq3wfc92cwstaszjk4wapctejzdbcpbf...@mail.gmail.com
Bug#583968: xserver-xorg-video-radeon: xpress 200m 5955 = resume from suspend fails with KMS enabled
Patch seems to be http://article.gmane.org/gmane.comp.video.dri.devel/48108 Yes this patch works. It's been applied upstream since version 2.6.35. Could this be backported to squeeze's kernel? I have been using the patch on vanilla kernels 2.6.32, 2.6.33, 2.6.34 and 2.6.35 successfully. Thanks Andres -- 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/aanlktinyvavebjzxcbptw0a1otcov16t-4ejr4vot...@mail.gmail.com
Bug#583933: Bug # 583933: xserver-xorg-video-radeon: Latest radeon + KMS ASIC bug error message
In this xorg-radeon mailing list thread below the issue was discussed and it
was stated by the developers that after patch:
http://people.freedesktop.org/~agd5f/0001-drm-radeon-kms-fix-gtt-MC-base-alignment-on-rs4xx-rs.patchhttp://people.freedesktop.org/%7Eagd5f/0001-drm-radeon-kms-fix-gtt-MC-base-alignment-on-rs4xx-rs.patch
The code that causes the DRM error be removed
Please patch kernel 2.6.32 in Squeeze!
Andres
--- On *Fri, 7/16/10, Jerome Glisse gli...@freedesktop.org* wrote:
From: Jerome Glisse gli...@freedesktop.org
Subject: Re: DRM_ERROR(Forcing to 32M GART size (because of ASIC bug
?)\n);
To: Alex Deucher alexdeuc...@gmail.com
Cc: Andres Cimmarusti andrescimmaru...@yahoo.com,
xorg-driver-...@lists.x.org
Date: Friday, July 16, 2010, 10:33 AM
On 07/16/2010 09:53 AM, Alex Deucher wrote:
On Fri, Jul 16, 2010 at 12:45 AM, Andres Cimmarusti
andrescimmaru...@yahoo.comhttp://us.mc507.mail.yahoo.com/mc/compose?to=andrescimmaru...@yahoo.com
wrote:
In the kernel: drivers/gpu/drm/radeon/rs400.c
You will find this piece of code:
if (rdev-family == CHIP_RS400 || rdev-family == CHIP_RS480) {
/* FIXME: RS400 RS480 seems to have issue with GART
size
* if 4G of system memory (needs more testing) */
rdev-mc.gtt_size = 32 * 1024 * 1024;
DRM_ERROR(Forcing to 32M GART size (because of ASIC bug
?)\n);
}
I don't have 4Gb of system memory (I have 2Gb DDR) so I deleted the whole
thing and compiled my kernel fine. Testing it didn't lead me to any
problems. My gtt size went from 32Mb to 512Mb. Is this ok? my card is
supposed to have 128 Mb of VRAM.
Also if the issue is only when you are above 4Gb of system memory,
couldn't there be some sort of if statement that could probe the memory and
if it was bigger than 4G then it would force 32mb on gtt memory.?
should I play it safe? I guess I don't really understand what gtt memory
is
GTT is system memory that is mapped into the video card's address
space so it can be read from or rendered to; it's separate from vram.
I don't recall why we added that quirk, Jerome or Dave may remember,
but I suspect, it should be ok to remove it after this patch:
http://people.freedesktop.org/~agd5f/0001-drm-radeon-kms-fix-gtt-MC-base-alignment-on-rs4xx-rs.patchhttp://people.freedesktop.org/%7Eagd5f/0001-drm-radeon-kms-fix-gtt-MC-base-alignment-on-rs4xx-rs.patch
is applied.
Alex
Yes i think it should be ok to remove it after your patch.
I would like to test it but might not have the hw handy.
Cheers,
Jerome
Bug#588602: Bug#: 588601, 588602: xpress 200m 5955 = resume from suspend fails with KMS enabled
I dedicated a large portion of the day to finding a clue to this one. Following this advice: http://lxr.linux.no/#linux+v2.6.34.1/Documentation/power/s2ram.txt I was able to extract a trace from the failed resume process: Magic number: 0:981:799 hash matches drivers/base/power/main.c:523 pci :01:05.0: hash matches ec PNP0C09:00: hash matches The first hash match is none other than my ATI Radeon card as I easily verified with lspci: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon XPRESS 200M 5955 (PCIE) However, the above link says that the likely culprit in the failed resume process is the last hash match. This corresponds to the EC driver: http://lxr.free-electrons.com/source/drivers/acpi/ec.c My card was, till recently, listed under embedded graphics at the AMD/ATI website. So there appears to be some conflict when using KMS between radeon and ec that causes the kernel to hang (that explains why I can't ssh into my computer to get a trace). For this reason I've cloned the original bug and reported the copy as a kernel bug. I will try to delve deeper into the matter by activating more verbose debugging symbols for acpi. I would appreciate some advice and guidance, since I'm flying half-blind (I will try to follow the information present here http://ubuntuforums.org/showthread.php?t=505890) Cheers, Andres
Bug#586270: linux-image-2.6.32-5-686: evo n610c compaq laptop fails to go into suspend mode
Package: linux-2.6 Version: 2.6.32-15 Severity: important Tags: sid squeeze After recent updates, I can no longer successfully go into suspend moved with this laptop. The kernel log shows several backtraces. -- Package-specific info: ** Version: Linux version 2.6.32-5-686 (Debian 2.6.32-15) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-1) ) #1 SMP Tue Jun 1 04:59:47 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=a5779667-ac81-4bf8-ba7d-2129374a488a ro quiet ** Not tainted ** Kernel log: [ 210.251149] [c1049b5a] ? refrigerator+0x9c/0xae [ 210.251155] [c103e683] ? get_signal_to_deliver+0x6a/0x32f [ 210.251161] [c1002588] ? do_notify_resume+0x6f/0x713 [ 210.251166] [c10b3231] ? do_sync_read+0xc0/0x107 [ 210.251173] [c10445ca] ? autoremove_wake_function+0x0/0x2d [ 210.251179] [c104b6e8] ? ktime_get_ts+0xcd/0xd5 [ 210.251185] [c10bec43] ? sys_poll+0x44/0x8d [ 210.251190] [c10032b4] ? work_notifysig+0x13/0x1b [ 210.251194] pm-suspendR running 0 2552 1882 0x [ 210.251200] c12707fc dfce884b 0003 deb47e6f deb70440 c126c19e [ 210.251210] c12db756 0009 c1005522 c12db75a c12db75a deb47e5c deb70440 deb70440 [ 210.251219] 0001 c1006248 c130686a c102b5c7 07d0 [ 210.251229] Call Trace: [ 210.251235] [c100554b] ? show_stack_log_lvl+0x8b/0x93 [ 210.251241] [c1006248] ? show_stack+0x10/0x13 [ 210.251247] [c102b5c7] ? show_state_filter+0x39/0x78 [ 210.251253] [c1058b1d] ? try_to_freeze_tasks+0x172/0x22e [ 210.251260] [c1058bee] ? freeze_processes+0x15/0x77 [ 210.251265] [c1058ecc] ? enter_state+0x98/0x11a [ 210.251270] [c10587f9] ? state_store+0x91/0xa5 [ 210.251275] [c1058768] ? state_store+0x0/0xa5 [ 210.251282] [c1135eb3] ? kobj_attr_store+0x18/0x1c [ 210.251290] [c10f2b44] ? sysfs_write_file+0xb0/0xdd [ 210.251295] [c10f2a94] ? sysfs_write_file+0x0/0xdd [ 210.251301] [c10b3a56] ? vfs_write+0x7e/0xd6 [ 210.251306] [c10b3b46] ? sys_write+0x3c/0x63 [ 210.251311] [c10030fb] ? sysenter_do_call+0x12/0x28 [ 210.251319] Sched Debug Version: v0.09, 2.6.32-5-686 #1 [ 210.251324] now at 210251.321683 msecs [ 210.251327] .jiffies : 4294944858 [ 210.251332] .sysctl_sched_latency: 5.00 [ 210.251336] .sysctl_sched_min_granularity: 1.00 [ 210.251339] .sysctl_sched_wakeup_granularity : 1.00 [ 210.251343] .sysctl_sched_child_runs_first : 0.00 [ 210.251347] .sysctl_sched_features : 15834235 [ 210.251352] [ 210.251353] cpu#0, 1196.210 MHz [ 210.251356] .nr_running: 1 [ 210.251360] .load : 1024 [ 210.251364] .nr_switches : 99798 [ 210.251367] .nr_load_updates : 28251 [ 210.251370] .nr_uninterruptible: 1 [ 210.251374] .next_balance : 4294.940080 [ 210.251377] .curr-pid : 2552 [ 210.251381] .clock : 210248.015774 [ 210.251385] .cpu_load[0] : 1024 [ 210.251388] .cpu_load[1] : 1024 [ 210.251392] .cpu_load[2] : 1024 [ 210.251395] .cpu_load[3] : 1024 [ 210.251398] .cpu_load[4] : 1024 [ 210.251403] [ 210.251404] cfs_rq[0]:/ [ 210.251408] .exec_clock: 0.00 [ 210.251412] .MIN_vruntime : 0.01 [ 210.251416] .min_vruntime : 378355.014090 [ 210.251420] .max_vruntime : 0.01 [ 210.251423] .spread: 0.00 [ 210.251427] .spread0 : 0.00 [ 210.251430] .nr_running: 1 [ 210.251434] .load : 1024 [ 210.251437] .nr_spread_over: 0 [ 210.251440] .shares: 0 [ 210.251444] [ 210.251445] rt_rq[0]: [ 210.251448] .rt_nr_running : 0 [ 210.251451] .rt_throttled : 0 [ 210.251455] .rt_time : 0.00 [ 210.251459] .rt_runtime: 950.00 [ 210.251462] [ 210.251463] runnable tasks: [ 210.251465] task PID tree-key switches prio exec-runtime sum-execsum-sleep [ 210.251468] -- [ 210.251517] R pm-suspend 2552378355.014090 118 120 0 0 0.00 0.00 0.00 / [ 210.251529] [ 210.251595] mount [ 210.251606] [ 210.251608] Restarting tasks ... done. [ 210.924153] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) [ 210.972539] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 210.998313]
Bug#583924: linux-image-2.6.32-5-amd64: udevd-work and kernel names disagree
Package: linux-2.6 Version: 2.6.32-14 Severity: minor Tags: sid squeeze I keep getting this message at boot time: udevd-work[377]: kernel-provided name 'uinput' and NAME= 'input/uinput' disagree, please use SYMLINK+= or change the kernel to provide the proper name For a similar bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582639, the udev mantainer said this was a kernel bug. For this reason I'm reporting it here. -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-14) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-1) ) #1 SMP Sun May 30 17:20:42 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=43c718d2-f969-4312-b0c2-91544a2b744f ro quiet ** Not tainted ** Kernel log: [4.536359] processor LNXCPU:00: registered as cooling_device0 [4.536795] Switching to clocksource acpi_pm [4.614937] ACPI: AC Adapter [ACAD] (on-line) [4.615168] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input4 [4.615298] ACPI: Lid Switch [LID] [4.615711] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input5 [4.615788] ACPI: Power Button [PWRB] [4.615895] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6 [4.615945] ACPI: Power Button [PWRF] [4.616447] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input7 [4.616509] ACPI: Sleep Button [SLPF] [4.749441] ACPI: Battery Slot [BAT1] (battery present) [4.850769] EDAC MC: Ver: 2.1.0 May 30 2010 [4.863336] EDAC amd64_edac: Ver: 3.2.0 May 30 2010 [4.863409] EDAC amd64: This node reports that Memory ECC is currently disabled, set F3x44[22] (:00:18.3). [4.863414] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. [4.863416] Either enable ECC checking or force module loading by setting 'ecc_enable_override'. [4.863417] (Note that use of the override may cause unknown side effects.) [4.863433] amd64_edac: probe of :00:18.2 failed with error -22 [4.880191] piix4_smbus :00:14.0: SMBus Host Controller at 0x8400, revision 0 [4.917930] b43-phy0: Broadcom 4318 WLAN found (core revision 9) [4.940918] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [5.105757] Synaptics Touchpad, model: 1, fw: 6.2, id: 0x1a0b1, caps: 0xa04713/0x20/0x0 [5.136527] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:0e/LNXVIDEO:00/input/input8 [5.136605] ACPI: Video Device [VGA] (multi-head: yes rom: no post: no) [5.143622] ACPI: WMI: Mapper loaded [5.150511] yenta_cardbus :06:04.0: CardBus bridge found [103c:30a4] [5.150536] yenta_cardbus :06:04.0: Enabling burst memory read transactions [5.150543] yenta_cardbus :06:04.0: Using INTVAL to route CSC interrupts to PCI [5.150545] yenta_cardbus :06:04.0: Routing CardBus interrupts to ISA [5.150552] yenta_cardbus :06:04.0: TI: mfunc 0x00a61b22, devctl 0x64 [5.156492] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [5.180902] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input9 [5.217336] [drm] Initialized drm 1.1.0 20060810 [5.380923] yenta_cardbus :06:04.0: ISA IRQ mask 0x0ef8, PCI irq 20 [5.380929] yenta_cardbus :06:04.0: Socket status: 3006 [5.380937] yenta_cardbus :06:04.0: pcmcia: parent PCI bridge I/O window: 0xa000 - 0xafff [5.380941] yenta_cardbus :06:04.0: pcmcia: parent PCI bridge Memory window: 0xc020 - 0xc02f [5.380944] yenta_cardbus :06:04.0: pcmcia: parent PCI bridge Memory window: 0x8000 - 0x83ff [5.420961] phy0: Selected rate control algorithm 'minstrel' [5.421639] Registered led device: b43-phy0::radio [5.421710] Broadcom 43xx driver loaded [ Features: PMLS, Firmware-ID: FW13 ] [5.638680] tifm_7xx1 :06:04.3: PCI INT B - GSI 23 (level, low) - IRQ 23 [5.861005] pci :01:05.0: power state changed by ACPI to D0 [5.861014] pci :01:05.0: power state changed by ACPI to D0 [5.861023] pci :01:05.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [5.861222] [drm] Initialized radeon 1.32.0 20080528 for :01:05.0 on minor 0 [6.334742] ATI IXP AC97 controller :00:14.5: PCI INT B - GSI 17 (level, low) - IRQ 17 [6.361748] ATI IXP MC97 controller :00:14.6: PCI INT B - GSI 17 (level, low) - IRQ 17 [6.472078] MC'97 0 converters and GPIO not ready (0x1) [7.041359] Adding 2441840k swap on /dev/sda5. Priority:-1 extents:1 across:2441840k [7.413482] loop: module loaded [7.731940] EXT4-fs (sda6): mounted filesystem with ordered data mode [8.841093] fuse init (API version 7.13) [9.583174] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input10 [ 11.596076] b43 ssb0:0: firmware: requesting b43/ucode5.fw [ 11.673904] b43 ssb0:0: firmware: requesting b43/pcm5.fw [ 11.680420] b43
Bug#574555: linux-image-2.6.32-3-amd64: 2.6.32 kernel oops: Pid: 1700, comm: irq/21-b43 Not tainted 2.6.32-3-amd64
Package: linux-2.6 Version: 2.6.32-9 Severity: normal I've been regularly getting a kernel oops that leaves this trace (IMPORTANT: this doesn't happen with kernel 2.6.33, I thought it would be solved in upstream release 2.6.32.9): Mar 18 15:56:58 debturion kernel: [10281.468122] WARNING: at /build/mattems-linux-2.6_2.6.32-9-amd64-NYTFdD/linux-2.6-2.6.32-9/debian/build/source_amd64_none/net/mac80211/rc80211_minstrel.c:69 minstrel_tx_status+0x66/0xc4 [mac80211]() Mar 18 15:56:58 debturion kernel: [10281.468132] Hardware name: Pavilion dv5000 (EP414UA#ABA) Mar 18 15:56:58 debturion kernel: [10281.468137] Modules linked in: cryptd aes_x86_64 aes_generic ppdev lp parport sco bridge stp bnep l2cap bluetooth powernow_k8 cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace binfmt_misc uinput fuse radeon ttm drm_kms_helper drm i2c_algo_bit loop firewire_sbp2 snd_atiixp snd_atiixp_modem snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event arc4 snd_seq joydev snd_timer ecb snd_seq_device edac_core i2c_piix4 yenta_socket b43 tifm_7xx1 ac rsrc_nonstatic snd soundcore pcspkr edac_mce_amd rng_core i2c_core tifm_core wmi mac80211 cfg80211 k8temp rfkill snd_page_alloc serio_raw evdev battery processor psmouse shpchp pci_hotplug ext4 mbcache jbd2 crc16 ide_cd_mod cdrom ide_gd_mod ide_pci_generic ata_generic libata scsi_mod ssb sdhci_pci sdhci ohci_hcd 8139too pcmcia atiixp firewire_ohci mmc_core ehci_hcd video output 8139cp mii led_class firewire_core crc_itu_t pcmcia_core but ton ide_core usbcore nls_base thermal fa Mar 18 15:56:58 debturion kernel: n thermal_sys [last unloaded: scsi_wait_scan] Mar 18 15:56:58 debturion kernel: [10281.468299] Pid: 1700, comm: irq/21-b43 Not tainted 2.6.32-3-amd64 #1 Mar 18 15:56:58 debturion kernel: [10281.468306] Call Trace: Mar 18 15:56:58 debturion kernel: [10281.468329] [a031a2a3] ? minstrel_tx_status+0x66/0xc4 [mac80211] Mar 18 15:56:58 debturion kernel: [10281.468350] [a031a2a3] ? minstrel_tx_status+0x66/0xc4 [mac80211] Mar 18 15:56:58 debturion kernel: [10281.468362] [8104dbf0] ? warn_slowpath_common+0x77/0xa3 Mar 18 15:56:58 debturion kernel: [10281.468382] [a031a2a3] ? minstrel_tx_status+0x66/0xc4 [mac80211] Mar 18 15:56:58 debturion kernel: [10281.468402] [a030195a] ? ieee80211_tx_status+0x17e/0x3e4 [mac80211] Mar 18 15:56:58 debturion kernel: [10281.468428] [a03a6f6e] ? b43_dma_handle_txstatus+0x104/0x161 [b43] Mar 18 15:56:58 debturion kernel: [10281.468448] [a03a2d57] ? b43_handle_txstatus+0x4f/0x5c [b43] Mar 18 15:56:58 debturion kernel: [10281.468466] [a0397899] ? b43_do_interrupt_thread+0x51d/0x552 [b43] Mar 18 15:56:58 debturion kernel: [10281.468484] [a03978e7] ? b43_interrupt_thread_handler+0x19/0x2d [b43] Mar 18 15:56:58 debturion kernel: [10281.468496] [810941a8] ? irq_thread+0x113/0x212 Mar 18 15:56:58 debturion kernel: [10281.468507] [8103aabc] ? __wake_up_common+0x44/0x72 Mar 18 15:56:58 debturion kernel: [10281.468517] [81094095] ? irq_thread+0x0/0x212 Mar 18 15:56:58 debturion kernel: [10281.468525] [81064789] ? kthread+0x79/0x81 Mar 18 15:56:58 debturion kernel: [10281.468535] [81011baa] ? child_rip+0xa/0x20 Mar 18 15:56:58 debturion kernel: [10281.468554] [a0134eba] ? ssb_pci_write16+0x0/0x3a [ssb] Mar 18 15:56:58 debturion kernel: [10281.468562] [81064710] ? kthread+0x0/0x81 Mar 18 15:56:58 debturion kernel: [10281.468570] [81011ba0] ? child_rip+0x0/0x20 Mar 18 15:56:58 debturion kernel: [10281.468576] ---[ end trace ac4cd1434347df4e ]--- -- Package-specific info: ** Version: Linux version 2.6.32-3-amd64 (Debian 2.6.32-9) (m...@debian.org) (gcc version 4.3.4 (Debian 4.3.4-8) ) #1 SMP Wed Feb 24 18:07:42 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-3-amd64 root=UUID=43c718d2-f969-4312-b0c2-91544a2b744f ro quiet ** Tainted: W (512) * Taint on warning. ** Kernel log: [11361.456216] wlan0: associated [11481.426875] wlan0: deauthenticating from 00:26:cb:aa:fc:e2 by local choice (reason=3) [11481.440362] wlan0: direct probe to AP 00:26:cb:ab:00:42 (try 1) [11481.441715] wlan0: direct probe responded [11481.441723] wlan0: authenticate with AP 00:26:cb:ab:00:42 (try 1) [11481.443053] wlan0: authenticated [11481.443086] wlan0: associate with AP 00:26:cb:ab:00:42 (try 1) [11481.447754] wlan0: RX AssocResp from 00:26:cb:ab:00:42 (capab=0x431 status=0 aid=1) [11481.447762] wlan0: associated [12201.434465] wlan0: deauthenticating from 00:26:cb:ab:00:42 by local choice (reason=3) [12201.452436] wlan0: direct probe to AP 00:26:cb:aa:fc:e2 (try 1) [12201.453813] wlan0: direct probe responded [12201.453821] wlan0: authenticate with AP 00:26:cb:aa:fc:e2 (try 1) [12201.455194] wlan0: authenticated [12201.455234] wlan0: associate with AP 00:26:cb:aa:fc:e2 (try 1) [12201.458217] wlan0: RX
Bug#537879: linux-image-2.6.26-2-amd64/686: reloads b43-phy0
Hi, I've already tried the new 2.6.32 kernel and it works well. Actually the 2.6.27 kernel was already fixed (after a few .x updates). However the problem was also present in Network-Manager in lenny, but this is fixed in the version I found in lenny-backports. It's definitely fixed in Squeeze...but the problem remains in Debian plain stable. 2010/3/1 Moritz Muehlenhoff j...@inutil.org On Tue, Jul 21, 2009 at 10:21:19AM -0400, Andres Cimmarusti wrote: Package: linux-image-2.6.26-2-amd64 Version: 2.6.26-17 Severity: normal This doesn't happen everytime, but it happens often. My wireless device is based on a broadcom 4318 as can be evidenced below. When I boot, the firmware is loaded correctly and the LED turns on, but just as I log in the LED turns off and this causes Network-Manager to fail to automatically connect to my wireless network. A minute goes by and then the LED turns back on. This causes me to have to manually connect. Hi, The next release of Debian (6.0, code name Squeeze) will be based on 2.6.32. Please test the current 2.6.32 from unstable/testing and tell us whether the problem persists. If so, we should report it upstream to the kernel.org developers. The 2.6.32 kernel is available from packages.debian.org and can be installed in both Debian stable, testing and unstable installations. Thanks, Moritz
