Bug#777759: linux-image-3.16.0-4-amd64: When I use bluetooth speakers for audio output Wi-Fi stops working

2015-02-19 Thread Stefan Nagy 
The upstream maintainer closed the bug because he's sure he won't find
the time to fix it (see upstream bug report). He added the following
info to Linux Wireless wiki:

"Having bluetooth and WiFi running at the same time is a challenge.
These scenarios have been tested thoroughly on 7260 and up, less so on
earlier devices. This is why some people may face issues with devices
that are handled by iwldvm (pre-7260). For users of these devices who
have problems when WiFi and Bluetooth are running concurrently, we
suggest to disable BT Coex by loading iwlwifi with bt_coex_active=0 as a
module parameter."

I don't know how to proceed in this matter. If option bt_coex isn't
tested thoroughly on earlier devices and breaks Wi-Fi connections in
some cases – maybe it would be a good idea to disable it in debian?


-- 
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/1424341015.3803.11.ca...@stefan-nagy.at

Bug#777759: linux-image-3.16.0-4-amd64: When I use bluetooth speakers for audio output Wi-Fi stops working

2015-02-18 Thread Stefan Nagy 
The upstream maintainer suggested to disable iwlwifi module option
bt_coex. I created a file /etc/modprobe.d/iwlwifi.conf with the
following content:

options iwlwifi bt_coex_active=0

Since I did that and rebooted I can't reproduce this bug anymore. After
my confirmation the upstream maintainer closed the bug. I don't really
understand why.

As I understand it he expects users to read the iwlwifi documentation
and try to disable module option bt_coex when they have Wi-Fi Bluetooth
problems. In my view it's a bug.


-- 
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/1424259642.2584.81.ca...@stefan-nagy.at

Bug#777759: linux-image-3.16.0-4-amd64: When I use bluetooth speakers for audio output Wi-Fi stops working

2015-02-12 Thread Stefan Nagy 
Package: src:linux
Version: 3.16.7-ckt4-3
Severity: normal

Dear Maintainer,

often when I use my bluetooth speakers for audio output, my Wi-Fi connection
becomes unusable slow. When I stop the playback and wait a few seconds I can
use Wi-Fi again.

The Wi-Fi connection never breaks completely, I stay connected but I can't even
send or receive e-mails.

I'm affected by this bug on an HP Folio 13-2000 notebook with an Intel
Corporation Centrino Wireless-N 1030 [Rainbow Peak] [8086:008b] adapter. Since
I can't reproduce it with another notebook using the same WLAN and the same
bluetooth speakers I guess it's hardware related.



-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03)

** Command line:
BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/rosa-root ro quiet splash

** Not tainted

** Kernel log:
[  154.133125] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  154.755897] wlan0: authenticate with 70:72:3c:20:76:08
[  154.766082] wlan0: send auth to 70:72:3c:20:76:08 (try 1/3)
[  154.768436] wlan0: authenticated
[  154.769119] wlan0: associate with 70:72:3c:20:76:08 (try 1/3)
[  154.773148] wlan0: RX AssocResp from 70:72:3c:20:76:08 (capab=0x431 status=0 
aid=2)
[  154.782186] wlan0: associated
[  154.782236] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  154.782302] cfg80211: Calling CRDA for country: CA
[  154.785394] cfg80211: Regulatory domain changed to country: CA
[  154.785399] cfg80211:  DFS Master region: FCC
[  154.785402] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[  154.785406] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 3000 
mBm), (N/A)
[  154.785410] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 1700 mBm), (N/A)
[  154.785415] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2400 mBm), (0 s)
[  154.785419] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 2400 
mBm), (0 s)
[  154.785422] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 3000 
mBm), (N/A)
[  161.990013] usb 1-1.2: new full-speed USB device number 6 using ehci-pci
[  162.182647] usb 1-1.2: New USB device found, idVendor=8086, idProduct=0189
[  162.182651] usb 1-1.2: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
[  172.073227] input: 00:02:3C:49:93:08 as /devices/virtual/input/input17
[  662.130063] tun: Universal TUN/TAP device driver, 1.6
[  662.130068] tun: (C) 1999-2004 Max Krasnyansky 
[ 1727.831947] usb 2-2: new high-speed USB device number 2 using xhci_hcd
[ 1727.961783] usb 2-2: New USB device found, idVendor=1058, idProduct=1100
[ 1727.961792] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1727.961797] usb 2-2: Product: My Book 
[ 1727.961801] usb 2-2: Manufacturer: Western Digital 
[ 1727.961806] usb 2-2: SerialNumber: 57442D574341563530313235303133
[ 1727.979956] usb-storage 2-2:1.0: USB Mass Storage device detected
[ 1727.980136] scsi6 : usb-storage 2-2:1.0
[ 1727.980368] usbcore: registered new interface driver usb-storage
[ 1728.980093] scsi 6:0:0:0: Direct-Access WD   10EADS External  1.75 
PQ: 0 ANSI: 4
[ 1728.980932] sd 6:0:0:0: Attached scsi generic sg1 type 0
[ 1728.981261] sd 6:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 
TB/931 GiB)
[ 1728.981599] sd 6:0:0:0: [sdb] Write Protect is off
[ 1728.981605] sd 6:0:0:0: [sdb] Mode Sense: 23 00 00 00
[ 1728.982050] sd 6:0:0:0: [sdb] No Caching mode page found
[ 1728.982057] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 1729.003049]  sdb: sdb1
[ 1729.005054] sd 6:0:0:0: [sdb] Attached SCSI disk
[ 1729.861553] sha256_ssse3: Using AVX optimized SHA-256 implementation
[ 1730.112760] EXT4-fs (dm-4): warning: maximal mount count reached, running 
e2fsck is recommended
[ 1730.121083] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[ 2192.334964] usb 2-2: USB disconnect, device number 2
[ 2192.603577] usb 2-2: new high-speed USB device number 3 using xhci_hcd
[ 2192.733304] usb 2-2: New USB device found, idVendor=1058, idProduct=1100
[ 2192.733314] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2192.733319] usb 2-2: Product: My Book 
[ 2192.733323] usb 2-2: Manufacturer: Western Digital 
[ 2192.733327] usb 2-2: SerialNumber: 57442D574341563530313235303133
[ 2192.734329] usb-storage 2-2:1.0: USB Mass Storage device detected
[ 2192.734651] scsi7 : usb-storage 2-2:1.0
[ 2193.364260] usb 2-2: USB disconnect, device number 3
[ 3213.427171] input: 00:02:3C:49:93:08 as /devices/virtual/input/input18
[ 3375.406780] Loading kernel module for a network device with CAP_SYS_MODULE 
(deprecated).  Use CAP_NET_ADMIN and alias netdev- instead.
[ 4851.734371] SGI XFS with ACLs, security attributes, realtime, large 
block/inode numbers, no debug enabled
[ 4851.742536] JFS: nTxB

Bug#701050: linux-image-3.2.0-4-amd64: Wrong battery capacity values on HP Folio 13-2000

2013-03-25 Thread Stefan Nagy 
Am Donnerstag, den 21.02.2013, 00:50 + schrieb Ben Hutchings:
> > while my BIOS/UEFI reports a battery charge capacity of 92% for my notebook-
> > battery, upower still reports a charge capacity of 100% (AFAIK upower gets 
> > this
> > information from the kernel - I believe this to be a kernel ACPI bug).
> 
> The kernel driver doesn't do anything very interesting so it's actually
> very likely a BIOS bug.

You were right, this really seems to be a BIOS bug. I checked the
battery information in Windows with 'powercfg -energy': The reported
values for 'Design capacity' (= ENERGY_FULL_DESIGN) and 'Last full
charge' (= ENERGY_FULL) are the same: 59940.

At first I thought that Windows gets the correct values because the
charging level percentage reported by Windows corresponded to the
percentage reported by the 'HP Support Assistant' program which shows me
the correct battery info (including a realistic battery capacity value).

I don't know why or how this works, but the charging level percentage
seems to be quite accurate even if all the other reported values differ.
I also used a freeware tool in Windows to get more information on the
battery and it showed me the same info I get with
'cat /sys/class/power_supply/BAT1/uevent'.

> Apparently, for some systems and batteries, ACPI reports full capacity
> as 100 and current level as a percentage.  In this case the ACPI battery
> driver cannot know what the true full capacity is.  Its workaround is to
> assume it is equal to full design capacity.  Unfortunately there doesn't
> seem to be any way to find out whether this workaround was enabled.

The upstream maintainer, Lan Tianyu, provided a patch to comment the
quirk (see comment #6 in the upstream report). However, after applying
the patch the kernel reported the same values, so I guess the workaround
wasn't enabled in my case.

Since I can confirm that this is a BIOS bug I'm going to close this
report. For more information please have a look at the upstream bug
report.

Thanks,
Stefan.


signature.asc
Description: This is a digitally signed message part

Bug#684186: Kernel doesn't produce any power related uevents on HP Folio 13-2000

2013-03-01 Thread Stefan Nagy 
No matter if I'm on battery (discharging) or have the ac adapter plugged
in (charging), if I'm plugging the ac adapter in or out – I don't see
any power related uevents from the kernel with 'udevadm monitor' or
'udevadm monitor --kernel'. I also tried to change the logging priority
of udevadm with 'udevadm control --log-priority=debug' – but without any
luck.

Since the kernel sends no power related uevents, UPower doesn't update
the status of the ac adapter (un/plugged). The value 'Updated' for
device /org/freedesktop/UPower/devices/line_power_ACAD reported by
UPower will always be similar to uptime, no matter how long that is and
how often I un/plugged the ac adapter in the meantime. When I booted
with the ac adapter plugged in and at some point I plug it out and
decided to work on battery my notebook will never be sent into
hibernation because UPower thinks the ac adapter is still plugged in. I
guess UPower expects an uevent from the kernel.

However, UPower seems to force an update of the battery status every 30
seconds (upowerd tells me: 'No updates on
supply /org/freedesktop/UPower/devices/battery_BAT1 for 30 seconds;
forcing update'), so the charging level reported by the battery status
applet in GNOME corresponds to the reported value
in /sys/class/power_supply/BAT1/uevent (POWER_SUPPLY_CAPACITY).

This bug was filed against UPower but now I realized that UPower waits
for uevents from the kernel regarding the battery and the ac adapter
status; but since there are no power related uevents from the kernel at
all I have reasons to this in fact is a kernel bug.


--
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/1362178067.7364.51.camel@rosa

Bug#701050: linux-image-3.2.0-4-amd64: Wrong battery capacity values on HP Folio 13-2000

2013-02-22 Thread Stefan Nagy 
I tested this also with debian kernel linux-image-3.7-trunk-amd64 
(3.7.8-1~experimental.1) and with upstream kernel v3.7.9. Please tell me 
if I can provide more useful information.


Stefan.


--
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/b2e650f0a8b0bb5750c9651b54546...@stefan-nagy.at

Bug#701050: linux-image-3.2.0-4-amd64: Wrong battery capacity values on HP Folio 13-2000

2013-02-21 Thread Stefan Nagy 
while my BIOS/UEFI reports a battery charge capacity of 92% for my 
notebook-
battery, upower still reports a charge capacity of 100% (AFAIK 
upower gets this
information from the kernel - I believe this to be a kernel ACPI 
bug).


The kernel driver doesn't do anything very interesting so it's 
actually

very likely a BIOS bug.


I checked the situation in Windows 7 over the last days and I don't see 
the problem there. I can use the 'HP Support Assistant' in Windows to 
check the battery capacity and status – it seems to be the same tool as 
in the 'HP UEFI Support Environment'. The value 'Current' (in mAh) 
accords to the values (in percentage of 'Full Charge Capacity') reported 
by Windows.


This is why I don't think that this is a BIOS bug.

Can you send the contents of /sys/class/power_supply/BAT1/uevent so 
we

at least know what the kernel is reporting?


stefan@rosa:~$ cat /sys/class/power_supply/BAT1/uevent
POWER_SUPPLY_NAME=BAT1
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Unknown
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=1110
POWER_SUPPLY_VOLTAGE_NOW=10872000
POWER_SUPPLY_POWER_NOW=14851000
POWER_SUPPLY_ENERGY_FULL_DESIGN=5994
POWER_SUPPLY_ENERGY_FULL=5994
POWER_SUPPLY_ENERGY_NOW=17982000
POWER_SUPPLY_MODEL_NAME=Venturi
POWER_SUPPLY_MANUFACTURER=13-17
POWER_SUPPLY_SERIAL_NUMBER=01317 01/24/2012

Regarding my original issue ('GNOME fails to execute action on critical 
battery condition') I just want to add that there seem to be three 
issues involved: one is really a BIOS bug (see the last comments of 
#695634), one at least seems to be a UPower bug (see #6841869) and then 
there's this one.


Stefan.


--
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/f3f8b2040621f07fd5977b4d05a55...@stefan-nagy.at

Bug#701050: linux-image-3.2.0-4-amd64: Wrong battery capacity values on HP Folio 13-2000

2013-02-20 Thread Stefan Nagy 
Package: src:linux
Version: 3.2.35-2
Severity: normal

Dear Maintainer,

while my BIOS/UEFI reports a battery charge capacity of 92% for my notebook-
battery, upower still reports a charge capacity of 100% (AFAIK upower gets this
information from the kernel - I believe this to be a kernel ACPI bug). I
suspect this issue to be part of my power problems reported in bug #695634 and
bug #684186 - my notebook fails to execute action (hibernate) on critical
battery condition. I'll add the information provided by UEFI (1.) and by upower
(2.).

(1.) Here's the information provided by the HP UEFI Support Environment:
Charge Capacity: 92%
Warranty Type: 1 year
Cycle Count: 187
Manufacturer: 13-17
Battery Age: 391 days
Serial Number: 01317 01/24/2012
Temperature: 36 °C
Design Capacity: 5400 mAh
Full Charge Capacity: 5020 mAh
Remaining Capacity: 2499 mAh
Current: 1797 mA
Battery Status: OK(1)
FAILURE ID: OK
Terminal Voltage: 11143 mV
Design Voltage: 11100 mV
Cell Voltage 1: 3710 mV
Cell Voltage 2: 3735 mV
Cell Voltage 3: 3700 mV
Cell Voltage 4: 0 mV
Status: 00C0
AC Power: No
CT Number: 6CLFH02BJ2E08M

(2.) Here's the information provided by upower ('upower --dump'):
Device: /org/freedesktop/UPower/devices/battery_BAT1
  native-path:
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/PNP0C0A:00/power_supply/BAT1
  vendor:   13-17
  model:Venturi
  serial:   01317 01/24/2012
  power supply: yes
  updated:  Wed Feb 20 23:57:03 2013 (23 seconds ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   discharging
energy:  28.771 Wh
energy-empty:0 Wh
energy-full: 59.94 Wh
energy-full-design:  59.94 Wh
energy-rate: 20.668 W
voltage: 11.103 V
time to empty:   1.4 hours
percentage:  47.9997%
capacity:100%



-- 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=4f9dc00c-6e8b-431d-b71f-d7bbc5960ad8 ro quiet

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[3.432525] iwlwifi :02:00.0: pci_resource_len = 0x2000
[3.432529] iwlwifi :02:00.0: pci_resource_base = c90011088000
[3.432533] iwlwifi :02:00.0: HW Revision ID = 0x34
[3.432781] iwlwifi :02:00.0: irq 47 for MSI/MSI-X
[3.432898] iwlwifi :02:00.0: Detected Intel(R) Centrino(R) Wireless-N 
1030 BGN, REV=0xB0
[3.433028] iwlwifi :02:00.0: L1 Enabled; Disabling L0S
[3.448618] iwlwifi :02:00.0: device EEPROM VER=0x716, CALIB=0x6
[3.448620] iwlwifi :02:00.0: Device SKU: 0X150
[3.448623] iwlwifi :02:00.0: Valid Tx ant: 0X1, Valid Rx ant: 0X3
[3.448652] iwlwifi :02:00.0: Tunable channels: 13 802.11bg, 0 802.11a 
channels
[3.483191] mtrr: type mismatch for b000,1000 old: write-back new: 
write-combining
[3.483196] [drm] MTRR allocation failed.  Graphics performance may suffer.
[3.483773] i915 :00:02.0: irq 48 for MSI/MSI-X
[3.483780] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[3.483783] [drm] Driver supports precise vblank timestamp query.
[3.483824] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[3.490239] iwlwifi :02:00.0: firmware: agent loaded 
iwlwifi-6000g2b-6.ucode into memory
[3.490248] iwlwifi :02:00.0: loaded firmware version 18.168.6.1
[3.490556] Registered led device: phy0-led
[3.496268] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[3.509769] input: HP TrueVision HD as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/input/input4
[3.509853] usbcore: registered new interface driver uvcvideo
[3.509856] USB Video Class driver (1.1.1)
[3.831764] input: HP WMI hotkeys as /devices/virtual/input/input5
[4.086773] rts_pstor: device scan complete
[4.087092] scsi 6:0:0:0: Direct-Access Generic- xD/SD/M.S.   1.00 
PQ: 0 ANSI: 0 CCS
[4.087242] Bad LUN (0:1)
[4.087546] Bad target number (1:0)
[4.087848] Bad target number (2:0)
[4.088152] Bad target number (3:0)
[4.088454] Bad target number (4:0)
[4.088758] Bad target number (5:0)
[4.089060] Bad target number (6:0)
[4.089314] Bad target number (7:0)
[4.089730] sd 6:0:0:0: Attached scsi generic sg1 type 0
[4.090411] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[4.116191] fbcon: inteldrmfb (fb0) is primary device
[4.308482] Console: switching to colour frame buffer device 170x48
[4.318392] fb0: inteldrmfb frame buffer device
[4.318397] drm: registered panic notifier
[4.325575] acpi device:33: registered as cooling_device6
[4.326327] inp

Bug#695634: linux-image-3.6-trunk-amd64: fails to execute action (hibernate) on critical battery condition - HP Folio 13-2000

2013-02-04 Thread Stefan Nagy 
In the meantime I had the opportunity to test this on another HP Folio
13-2000 which is running Windows 7. The user wasn't affected by this bug
only because the default settings for 'critical battery level' were set
to 5 percent – so when the battery reached 5 percent the notebook would
be sent into hibernation.

When I changed this setting to 2 percent (in Windows 7) I was able to
reproduce this bug. So this really seems to be a firmware bug and not a
kernel bug. I'm in contact with the Hewlett Packard support now and hope
that they will fix their BIOS.

I'm going to keep the UPower bug open since UPower still fails to update
the status of the AC adapter but I'm going to close this bug since it
seems to be the BIOS which is responsible for the reported inaccurate
battery levels – not the kernel.

Thank you very much for your help!

Stefan.


--
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/1360012468.4077.13.camel@rosa

Bug#695634: linux-image-3.6-trunk-amd64: fails to execute action (hibernate) on critical battery condition - HP Folio 13-2000

2012-12-15 Thread Stefan Nagy 
Ben Hutchings wrote:
> And presumably not very old (upower reports that the 'full' value is
> the same as the 'full-design' value).

I bought the notebook half a year ago, so yes, the battery is quite new.

> However, I don't see any similar quirk in the battery driver for any
> other models, and this doesn't seem that likely to be a firmware bug
> as this would be a problem for Windows power management as well.  (And
> there don't seem to be any firmware updates available for this model.)
> Did you leave Windows installed, and if so can you check whether that
> detects the nearly-empty battery properly?

No, I didn't. And since I'm writing my master theses on this notebook
right now I have no time to back up all data and setup Windows… I don't
know how relibale this information ist, but I just tested the battery
with the 'HP Unified Extensible Firmware Interface (UEFI) Support
Environment' and it passed.

Stefan.




signature.asc
Description: This is a digitally signed message part

Bug#695634: linux-image-3.6-trunk-amd64: fails to execute action (hibernate) on critical battery condition - HP Folio 13-2000

2012-12-15 Thread Stefan Nagy 
I tested this the whole day and eventually got a clearer picture of this
bug. gnome-settings-daemon fails to send my notebook into hibernation
because of two separate issues:

1) UPower fails to update the status of the AC adaptor. 'upower --dump'
shows that the time of last update is always identical to uptime. When
the adapter was plugged in while boot process, action on critical
battery will never be fired.

2) At low battery level the information UPower gets (from the kernel?)
is not correct. The reported battery level will never be lower than
2.99967% ('upower --dump') or 2% ('acpi -b'), time remaining never less
than around 5 minutes. gnome-settings-daemon's default is
'use-time-for-policy true' and 'time-action 120'. This status will never
be reached since the battery drains while time remaining is something
around 300 seconds.


I managed to manipulate the settings so that Gnome sends my notebook
into hibernation in two different ways:

1) I set 'time-critical 420' and 'time-action 300' and booted with the
AC adaptor plugged out, so that the status reported by 'upower --dump'
would be: 'line-power online: no'.

2) I set 'use-time-for-policy false', 'percentage-critical
4' (default=3),'percentage-action 3' (default=2) and booted with the AC
adaptor plugged out, so that the status reported by 'upower --dump'
would be: 'line-power online: no'.


I reassigned the bug I reported against gnome-settings-daemon to UPower:
#684186 However, UPower definitely receives incorrect values when
battery level is low. So I'm going to leave this bug open.


signature.asc
Description: This is a digitally signed message part

Bug#695634: linux-image-3.6-trunk-amd64: fails to execute action (hibernate) on critical battery condition - HP Folio 13-2000

2012-12-14 Thread Stefan Nagy 
Ben Hutchings wrote:
> Is this a genuine HP or third party battery?

It's a genuin HP battery.


-- 
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/1355534655.4421.5.camel@rosa

Bug#695634: linux-image-3.6-trunk-amd64: fails to execute action (hibernate) on critical battery condition - HP Folio 13-2000

2012-12-12 Thread Stefan Nagy 
I just realized that UPower doesn't update the status of
/org/freedesktop/UPower/devices/line_power_ACAD (no matter which kernel
I use). It seems like the date in line 'updated:' is always identical to
uptime.

With kernel 3.6.9 however it gets even worse: both devices are affected
by this now:
- /org/freedesktop/UPower/devices/line_power_ACAD and
- /org/freedesktop/UPower/devices/battery_BAT1

I'll attach the output of 'upower --dump' (kernel 3.6.9-1). I had my AC
adaptor disconnected for more than 10 minutes – however, upower as well
as the GNOME indicator shows me I'm still connected and that my battery
has 100% left. At the same time 'acpi -b' gives me 93% (which makes
sense).

Maybe this is a upower bug?
Device: /org/freedesktop/UPower/devices/line_power_ACAD
  native-path:  
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/ACPI0003:00/power_supply/ACAD
  power supply: yes
  updated:  Wed Dec 12 07:08:23 2012 (12018 seconds ago)
  has history:  no
  has statistics:   no
  line-power
online: yes

Device: /org/freedesktop/UPower/devices/battery_BAT1
  native-path:  
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/PNP0C0A:00/power_supply/BAT1
  vendor:   13-17
  model:Venturi
  serial:   01317 01/24/2012
  power supply: yes
  updated:  Wed Dec 12 07:08:28 2012 (12013 seconds ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   fully-charged
energy:  59.94 Wh
energy-empty:0 Wh
energy-full: 59.94 Wh
energy-full-design:  59.94 Wh
energy-rate: 0.011 W
voltage: 12.391 V
percentage:  100%
capacity:100%

Daemon:
  daemon-version:  0.9.17
  can-suspend: yes
  can-hibernateyes
  on-battery:  no
  on-low-battery:  no
  lid-is-closed:   yes
  lid-is-present:  yes
  is-docked:   yes

Bug#695634: linux-image-3.6-trunk-amd64: fails to execute action (hibernate) on critical battery condition - HP Folio 13-2000

2012-12-11 Thread Stefan Nagy 
I tested this some more by observing the output of 'acpi -a'. When my
battery is low the values (percentage, time remaining) jump.

Two minutes before my notebook suddenly shut down I got 00:05:00 minutes
left, a few seconds later 00:04:34 minutes, then 00:04:46 minutes,
00:04:54 minutes… Two or three seconds before my notebook finally shut
down I got 00:04:42 minutes left. For all this time percentage was at
2%.

After plugging in the AC adaptor and booting up I got 4% and 00:04:53
minutes "until charged" (!). I disconnected the AC adaptor again – now I
still had 4%, but just 00:00:15 seconds left. However, a few seconds
later I got 00:29:31 minutes remaining again.

If 'acpi' shows ACPI information (as the manpage states), ACPI
information can't be correct. For me this seems to be a kernel bug.

Stefan.


--
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/1355253387.4190.15.camel@rosa

Bug#695634: linux-image-3.6-trunk-amd64: fails to execute action (hibernate) on critical battery condition - HP Folio 13-2000

2012-12-11 Thread Stefan Nagy 
Ben Hutchings wrote:
> You confirmed that hibernation works and that GNOME is properly
> detecting the low battery level, so I don't see how this is a kernel
> bug.  The decision to hibernate is a matter of userland policy, so I
> think you were right with #684186.

I'm not so sure about this since the lowest value I get with 'acpi -b'
is 2% and about 00:06:00 seconds remaining. I've tested this again today
and I saw those values seconds before my battery drained and my notebook
shut down.

As mentioned in message #57 of bug #684186 I guess I'm affected by two
separate bugs here: g-s-d fails to execute actions on low battery
condition and at the same time ACPI reports incorrect battery values –
that's the reason why I opened another bugreport.

Stefan.


--
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/1355246853.3939.11.camel@rosa

Bug#695634: linux-image-3.6-trunk-amd64: fails to execute action (hibernate) on critical battery condition - HP Folio 13-2000

2012-12-10 Thread Stefan Nagy 
Package: src:linux
Version: 3.6.9-1~experimental.1
Severity: grave
Justification: causes non-serious data loss

Dear Maintainer,

when my notebook's battery runs out (reaches a critical state), GNOME isn't
able to send it into hibernation. GNOME reports low as well as critical battery
level but fails to send my notebook into hibernation before it suddenly shuts
down – I already lost some work because of this. I reported this bug against
gnome-settings-daemon some months ago, see bug #684186. Since this seems to be
a hardware specific issue I'm filing a kernel bug now.

Sending my notebook into hibernation manually works without any problems.
linux-image-3.2.0-4-amd64 (3.2.32-1) is also affected by this bug. I also tried
various upstream kernel versions with no luck.

Please tell me if you need more information.



-- Package-specific info:
** Version:
Linux version 3.6-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 
4.6.3 (Debian 4.6.3-11) ) #1 SMP Debian 3.6.9-1~experimental.1

** Command line:
BOOT_IMAGE=/vmlinuz-3.6-trunk-amd64 root=/dev/mapper/rosa-root ro quiet 
video.use_bios_initial_backlight=0

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[   15.069087] lp: driver loaded but no devices found
[   15.075883] ppdev: user-space parallel port driver
[   15.342115] r8169 :01:00.0: eth0: link down
[   15.342252] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   15.345082] iwlwifi :02:00.0: L1 Enabled; Disabling L0S
[   15.351778] iwlwifi :02:00.0: Radio type=0x2-0x2-0x1
[   15.438700] iwlwifi :02:00.0: L1 Enabled; Disabling L0S
[   15.445461] iwlwifi :02:00.0: Radio type=0x2-0x2-0x1
[   15.530356] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   15.752174] input: ACPI Virtual Keyboard Device as 
/devices/virtual/input/input12
[   15.769085] Ebtables v2.0 registered
[   15.791303] ip_tables: (C) 2000-2006 Netfilter Core Team
[   15.807600] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   16.757462] wlan0: authenticate with 70:72:3c:20:76:08
[   16.784911] wlan0: send auth to 70:72:3c:20:76:08 (try 1/3)
[   16.789363] wlan0: authenticated
[   16.789609] wlan0: waiting for beacon from 70:72:3c:20:76:08
[   16.890685] wlan0: associate with 70:72:3c:20:76:08 (try 1/3)
[   16.894768] wlan0: RX AssocResp from 70:72:3c:20:76:08 (capab=0x431 status=0 
aid=1)
[   16.908879] wlan0: associated
[   16.909000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   16.909253] cfg80211: Calling CRDA for country: CA
[   16.915674] cfg80211: Regulatory domain changed to country: CA
[   16.915684] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp)
[   16.915694] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 
2700 mBm)
[   16.915701] cfg80211:   (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 
1700 mBm)
[   16.915707] cfg80211:   (525 KHz - 533 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[   16.915714] cfg80211:   (549 KHz - 571 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[   16.915722] cfg80211:   (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 
3000 mBm)
[   23.076233] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[   24.559455] hid-generic 0005:045E:0700.0001: unknown main item tag 0x0
[   24.559610] input: Microsoft Bluetooth Notebook Mouse 5000 as 
/devices/pci:00/:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/bluetooth/hci0/hci0:36/input13
[   24.560410] hid-generic 0005:045E:0700.0001: input,hidraw0: BLUETOOTH HID 
v1.00 Mouse [Microsoft Bluetooth Notebook Mouse 5000] on 4C:EB:42:1A:52:01
[   49.396700] hid-generic 0005:045E:0762.0002: unknown main item tag 0x0
[   49.397057] input: Microsoft Bluetooth Mobile Keyboard 6000 as 
/devices/pci:00/:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/bluetooth/hci0/hci0:40/input14
[   49.399554] hid-generic 0005:045E:0762.0002: input,hidraw1: BLUETOOTH HID 
v0.13 Keyboard [Microsoft Bluetooth Mobile Keyboard 6000] on 4C:EB:42:1A:52:01
[ 1810.780322] hid-generic 0005:045E:0700.0003: unknown main item tag 0x0
[ 1810.780576] input: Microsoft Bluetooth Notebook Mouse 5000 as 
/devices/pci:00/:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/bluetooth/hci0/hci0:36/input15
[ 1810.781007] hid-generic 0005:045E:0700.0003: input,hidraw0: BLUETOOTH HID 
v1.00 Mouse [Microsoft Bluetooth Notebook Mouse 5000] on 4C:EB:42:1A:52:01
[ 3822.678138] fuse init (API version 7.20)
[ 5152.411809] hid-generic 0005:045E:0762.0004: unknown main item tag 0x0
[ 5152.411957] input: Microsoft Bluetooth Mobile Keyboard 6000 as 
/devices/pci:00/:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/bluetooth/hci0/hci0:40/input16
[ 5152.412398] hid-generic 0005:045E:0762.0004: input,hidraw1: BLUETOOTH HID 
v0.13 Keyboard [Microsoft Bluetooth Mobile Keyboard 6000] on 4C:EB:42:1A:52:01
[12633.041158] hid-generic 0005:045E:0700.0005: unknown main item tag 0x0
[12633.041292] input: Microsoft Bluetooth Notebook Mouse 5000 as 
/devices/pci:00/:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/bluetooth/hci

Bug#692361: ACPI display backlight brightness is set to zero at every boot-up (HP Folio 13-2000)

2012-12-02 Thread Stefan Nagy 
Hi Jonathan,

> This patch does not seem to be part of linux-next nor in lenb's tree,
> unfortunately.  Please let us know when it is accepted upstream.

OK, sure. I presumed it was accepted already since Zhang Rui marked it
as RESOLVED CODE_FIX.

> Based on  I fear we haven't
> gotten to the bottom of this, since the quirk table entry only applies
> to your model whereas a fundamental fix would apply to all affected
> ones.

I know, but as I understand it, this issue is caused by a BIOS bug, so
there seems to be no way to provide a fundamental fix (at least that's
how I interpreted the mere existence of this quirk table).

Cheers,
Stefan.


-- 
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/1354482971.5549.30.camel@rosa

Bug#692361: ACPI display backlight brightness is set to zero at every boot-up (HP Folio 13-2000)

2012-12-02 Thread Stefan Nagy 
Am Montag, den 05.11.2012, 12:45 +0100 schrieb Stefan Nagy:
> Since I didn't encounter this problem before
> linux-image-3.6-trunk-amd64 I had a look at these settings on
> linux-image-3.2.0-4-amd64 with normal backlight brightness:
> 'acpi_video0' (brightness 0, actual_brightness 0),
> 'intel_backlight' (brightness 4882, actual_brightness 4882). So the
> difference between 3.2 and 3.6 seems to be that backlight brightness
> wasn't controlled by the ACPI driver but the device specific driver in
> 3.2. 

I was having the same problem with linux-image-3.2.0-4-amd64 for some
time now, I guess since update 3.2.32-1.

However, this bug was fixed upstream. I tested the patch on top of
kernel v3.2.32-1 and it fixes the problem.
>From 117af51d695c78bfdf618a183664f0e9f3769b9a Mon Sep 17 00:00:00 2001
From: Zhang Rui 
Date: Sun, 2 Dec 2012 10:00:41 +0800
Subject: [PATCH] ACPI video: ignore BIOS initial backlight value for HP Folio
 13-2000.

Or else the laptop will boot with a dimmed screen.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/video.c |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 1e0a9e1..58bddd3 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -389,6 +389,12 @@ static int __init video_set_bqc_offset(const struct dmi_system_id *d)
 	return 0;
 }
 
+static int video_ignore_initial_backlight(const struct dmi_system_id *d)
+{
+	use_bios_initial_backlight = 0;
+	return 0;
+}
+
 static struct dmi_system_id video_dmi_table[] __initdata = {
 	/*
 	 * Broken _BQC workaround http://bugzilla.kernel.org/show_bug.cgi?id=13121
@@ -433,6 +439,14 @@ static struct dmi_system_id video_dmi_table[] __initdata = {
 		DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 7720"),
 		},
 	},
+	{
+	 .callback = video_ignore_initial_backlight,
+	 .ident = "HP Folio 13-2000",
+	 .matches = {
+		DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+		DMI_MATCH(DMI_PRODUCT_NAME, "HP Folio 13 - 2000 Notebook PC"),
+		},
+	},
 	{}
 };
 
-- 
1.7.9.5

Bug#692361: ACPI display backlight brightness is set to zero at every boot-up (HP Folio 13-2000)

2012-12-02 Thread Stefan Nagy 
Am Montag, den 05.11.2012, 12:45 +0100 schrieb Stefan Nagy:
> Since I didn't encounter this problem before
> linux-image-3.6-trunk-amd64 I had a look at these settings on
> linux-image-3.2.0-4-amd64 with normal backlight brightness:
> 'acpi_video0' (brightness 0, actual_brightness 0),
> 'intel_backlight' (brightness 4882, actual_brightness 4882). So the
> difference between 3.2 and 3.6 seems to be that backlight brightness
> wasn't controlled by the ACPI driver but the device specific driver in
> 3.2. 

I was having the same problem with linux-image-3.2.0-4-amd64 for some
time now, I guess since update 3.2.32-1.

However, this bug was fixed upstream. I tested the patch on top of
kernel v3.2.32-1 and it fixes the problem.
>From 117af51d695c78bfdf618a183664f0e9f3769b9a Mon Sep 17 00:00:00 2001
From: Zhang Rui 
Date: Sun, 2 Dec 2012 10:00:41 +0800
Subject: [PATCH] ACPI video: ignore BIOS initial backlight value for HP Folio
 13-2000.

Or else the laptop will boot with a dimmed screen.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/video.c |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 1e0a9e1..58bddd3 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -389,6 +389,12 @@ static int __init video_set_bqc_offset(const struct dmi_system_id *d)
 	return 0;
 }
 
+static int video_ignore_initial_backlight(const struct dmi_system_id *d)
+{
+	use_bios_initial_backlight = 0;
+	return 0;
+}
+
 static struct dmi_system_id video_dmi_table[] __initdata = {
 	/*
 	 * Broken _BQC workaround http://bugzilla.kernel.org/show_bug.cgi?id=13121
@@ -433,6 +439,14 @@ static struct dmi_system_id video_dmi_table[] __initdata = {
 		DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 7720"),
 		},
 	},
+	{
+	 .callback = video_ignore_initial_backlight,
+	 .ident = "HP Folio 13-2000",
+	 .matches = {
+		DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+		DMI_MATCH(DMI_PRODUCT_NAME, "HP Folio 13 - 2000 Notebook PC"),
+		},
+	},
 	{}
 };
 
-- 
1.7.9.5

Bug#692361: linux-image-3.6-trunk-amd64: ACPI display backlight brightness is set to zero at every boot-up

2012-11-05 Thread Stefan Nagy 
Package: src:linux
Version: 3.6.4-1~experimental.1
Severity: normal
Tags: upstream

Dear Maintainer,

everytime I boot, my notebook's display stays black since kernel linux-
image-3.6-amd64. I'm using an external display most of the time and so I found
out that the backlight brightness in GNOME settings is set to zero – I can
solve the problem by increasing the screen brightness but at the next boot this
setting will be lost, screen brightness is set to zero again. Since my media-
keys to change screen brightness don't work for now (see bug #683777) I
wouldn't be able to change the setting without an external display. As
described in bug #681743, setting the kernel boot parameter
i915.invert_brightness=1 works fine as workaround.

I looked into /sys/class/backlight/acpi_video0/brightness to confirm that it's
set to zero and realized that I have two entries in backlight: 'acpi_video0'
(with brightness set to 0, actual_brightness is 0) and 'intel_backlight' (with
brightness set to 4882, actual_brightness is 0). When I increase screen
brightness to 100% in GNOME settings, the values change to: 'acpi_video0'
brightness & actual_brightness 10; 'intel_backlight' brightness &
actual_brightness 4882.

Since I didn't encounter this problem before linux-image-3.6-trunk-amd64 I had
a look at these settings on linux-image-3.2.0-4-amd64 with normal backlight
brightness: 'acpi_video0' (brightness 0, actual_brightness 0),
'intel_backlight' (brightness 4882, actual_brightness 4882). So the difference
between 3.2 and 3.6 seems to be that backlight brightness wasn't controlled by
the ACPI driver but the device specific driver in 3.2.

I tested this with vanilla kernel 3.6.4 and can confirm that this is an
upstream bug. I suppose this bug report is a duplicate of #681743 but since I'm
seeing this on another notebook (HP Folio 13-2000) than the original reporter
Jonathan Nieder asked me to open a new report.

Please tell me if you need more information.



-- Package-specific info:
** Version:
Linux version 3.6-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 
4.6.3 (Debian 4.6.3-1) ) #1 SMP Debian 3.6.4-1~experimental.1

** Command line:
BOOT_IMAGE=/vmlinuz-3.6-trunk-amd64 root=/dev/mapper/rosa-root ro quiet splash

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[   10.154473] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   10.170809] iTCO_vendor_support: vendor-support=0
[   10.174866] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10
[   10.174915] iTCO_wdt: Found a Cougar Point TCO device (Version=2, 
TCOBASE=0x0460)
[   10.175439] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   10.186166] iwlwifi :02:00.0: loaded firmware version 18.168.6.1
[   10.211152] input: HP TrueVision HD as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/input/input4
[   10.211575] usbcore: registered new interface driver uvcvideo
[   10.211577] USB Video Class driver (1.1.1)
[   10.214850] iwldvm: Intel(R) Wireless WiFi Link AGN driver for Linux, 
in-tree:
[   10.214853] iwldvm: Copyright(c) 2003-2012 Intel Corporation
[   10.214872] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEBUG disabled
[   10.214875] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[   10.214876] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[   10.214878] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
[   10.214880] iwlwifi :02:00.0: CONFIG_IWLWIFI_P2P enabled
[   10.214882] iwlwifi :02:00.0: Detected Intel(R) Centrino(R) Wireless-N 
1030 BGN, REV=0xB0
[   10.215001] iwlwifi :02:00.0: L1 Enabled; Disabling L0S
[   10.230647] iwlwifi :02:00.0: device EEPROM VER=0x716, CALIB=0x6
[   10.230651] iwlwifi :02:00.0: Device SKU: 0x150
[   10.230654] iwlwifi :02:00.0: Valid Tx ant: 0x1, Valid Rx ant: 0x3
[   10.230745] Registered led device: phy0-led
[   10.243258] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[   10.245943] cfg80211: World regulatory domain updated:
[   10.245947] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp)
[   10.245951] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[   10.245954] cfg80211:   (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 
2000 mBm)
[   10.245957] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 
2000 mBm)
[   10.245959] cfg80211:   (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[   10.245962] cfg80211:   (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[   10.435400] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
[   10.524024] input: HP WMI hotkeys as /devices/virtual/input/input5
[   10.655051] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit 
banging on pin 2
[   10.784579] fbcon: inteldrmfb (fb0) is primary device
[   10.834902] rts_pstor: device scan complete
[   10.835282] scsi 6:0:0:0: Direct-Access Generic- xD/SD/M.S.

Bug#681743:

2012-11-04 Thread Stefan Nagy 
At least in my case this is an upstream bug – I tested this with the
vanilla kernel v3.6.4 and got the same results.


--
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/1352076045.3917.3.camel@rosa

Bug#665493: bug fixed in 3.6; patch

2012-10-08 Thread Stefan Nagy 
I can confirm that the bug is fixed in kernel 3.6 and that applying the
patch provided by Jeroen in Message #71 ("PCI: acpiphp: check whether
_ADR evaluation succeeded") on top of 3.2.30 solves the problem.

Thanks!
Stefan.


-- 
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/1349707771.4421.6.camel@rosa

Bug#665493: linux-image-3.2.0-2-amd64: kernel fails to boot completely (timeout on modprobe -b pci:xxxx)

2012-08-27 Thread Stefan Nagy 
Here's the upstrem report:
https://bugzilla.kernel.org/show_bug.cgi?id=46481

Since I filed the bug against the ACPI PCI Hotplug driver I didn't want
to decide if we (me and the original reporter Jeroen Nijhof) are
affected by the same bug – all I know is that the build-in driver causes
similar symptoms. So I wrote the bug report for my machine now.

Cheers,
Stefan.


signature.asc
Description: This is a digitally signed message part

Bug#665493: linux-image-3.2.0-2-amd64: kernel fails to boot completely (timeout on modprobe -b pci:xxxx)

2012-08-26 Thread Stefan Nagy 
Am Sonntag, den 26.08.2012, 13:37 -0700 schrieb Ben Hutchings:
> Please test Linux 3.5 (packaged in experimental) and if that has the
> same problem then open an upstream bug report.

OK – I already tested linux-image-3.5-trunk-amd64
(3.5.2-1~experimental.1) & the bug is still present, so I'll file the
upstream bug report soon.

> > P.S. The default kernel configuration for this item is
> > CONFIG_HOTPLUG_PCI_ACPI=n.
> 
> The default kernel configuration has a lot of features disabled that
> many users need.

I see.

> > I also had a look at this configuration item
> > in Ubuntu – it's set to CONFIG_HOTPLUG_PCI_ACPI=m.
> 
> Have you checked whether they add it to /proc/modules?

You mean if they add it to /etc/modules, right? I don't know, I haven't
checked this yet.

But this is maybe interesting: When I compile my kernel with
CONFIG_HOTPLUG_PCI_ACPI=m and put acpiphp in /etc/modules I can't
reproduce this bug even though I'm sure the module is loaded:

[   19.299137] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[   19.299341] acpiphp: Slot [1] registered

$ lsmod | grep acpiphp
acpiphp22567  0 


Stefan.


signature.asc
Description: This is a digitally signed message part

Bug#665493: linux-image-3.2.0-2-amd64: kernel fails to boot completely (timeout on modprobe -b pci:xxxx)

2012-08-26 Thread Stefan Nagy 
As the original reporter pointed out, this bug is triggered by a change
in the debian kernel configuration regarding the ACPI PCI Hotplug driver
[1]. Since kernel update linux-image-3.2.0-2-amd64 (3.2.10-1) this
driver is build in (CONFIG_HOTPLUG_PCI_ACPI=y) instead of being compiled
as a module (CONFIG_HOTPLUG_PCI_ACPI=m).

The kernel changelog lists Ben Hutchings as author for this change:
- [x86] Change HOTPLUG_PCI_ACPI to built-in (Closes: #663433) [2]

The reason for this decision was that the ACPI PCI Hotplug driver didn't
get loaded on machines which need it for ExpressCard hotplugging to work
[3].

Since this bug got no attention at all on the kernel-pci mailinglist for
three months now [4] I wanted to file a bugreport upstream against
driver: pci – but I'm not sure what to do now since it doesn't seem to
be very safe to build-in this driver and maybe the debian kernel team
wants to reconsider this decision…?

Please tell me if this decision is final – even though the kernel fails
to load on at least two recent machines with the ACPI PCI Hotplug driver
build in. If it is I'll file a bugreport upstream.

Thanks,
Stefan.



P.S. The default kernel configuration for this item is
CONFIG_HOTPLUG_PCI_ACPI=n. I also had a look at this configuration item
in Ubuntu – it's set to CONFIG_HOTPLUG_PCI_ACPI=m.

[1] http://cateee.net/lkddb/web-lkddb/HOTPLUG_PCI_ACPI.html
[2]
http://packages.debian.org/changelogs/pool/main/l/linux/linux_3.2.23-1/changelog#version3.2.10-1
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663433
[4] http://thread.gmane.org/gmane.linux.kernel.pci/15559


signature.asc
Description: This is a digitally signed message part

Bug#683777: linux-image-3.2.0-3-amd64: some multimedia/action keys don't work

2012-08-05 Thread Stefan Nagy 
Dear Maintainer,

seems like some Ubuntu users were also affected by this bug (on the same
notebook model) [1] and already reported it upstream [2].

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/974568
[2] https://bugzilla.kernel.org/show_bug.cgi?id=43097

Cheers,
Stefan Nagy.


signature.asc
Description: This is a digitally signed message part

Bug#665493: linux-image-3.2.0-2-amd64: kernel fails to boot completely (timeout on modprobe -b pci:xxxx)

2012-07-25 Thread Stefan Nagy 
Package: linux-2.6
Followup-For: Bug #665493

Dear Maintainer,

I'm seeing the same symptoms as the original reporter on a free install of 
wheezy on an HP Folio 13-2000.

Since I seem to be too stupid to compile a booting custom kernel I installed 
linux-image-3.2.0-0.bpo.2-amd64 (3.2.20-1~bpo60+1) – and it works.

Cheers,
Stefan Nagy.



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


--
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/20120725144749.14433.35820.reportbug@rosa