Bug#922666: confirmed bug report

2021-05-04 Thread Antoine Beaupré 
Another thing I should mention is that I accidentally (I swear) ended up
in memtest86 during some kernel switching tests, and figured I would let
that run. It found about a dozen errors in 10-20 minutes testing, so
there's also that: it could be a problem with the RAM.

That said, those are new modules I got on this laptop, and the problem
was happening before those were changed...

Bug#928189: Bug#922666: confirmed bug report

2021-05-03 Thread Antoine Beaupré 
On 2021-05-03 20:44:31, Antoine Beaupré wrote:
> On 2021-05-03 20:27:26, Antoine Beaupré wrote:
>
> [...]
>
>> Interestingly, it seems that the machine indeed doesn't go to sleep: it
>> loops over a failure to sleep and fills up syslog with errors as long as
>> it's trying to sleep, pretty catastrophic, from a battery usage
>> perspective.
>>
>> I attach the two logs and am continuing my investigation. User now
>> reports situation is actually much worse than before the backports
>> upgrade: at least 5.7 was intermittent, now the crash is systematic.
>
> Relevant: booting into 4.19.132, from plain buster, doesn't reproduce
> the above failure to suspend. The machine suspends fine, and resumes,
> and the mouse even still works correctly.
>
> I wonder if this is a regression introduced in backports. But I could
> have sworn this was happening *before* I upgraded to the backported
> kernels...

And that is confirmed: it does happen in older kernels, just less
reliably.

a.

-- 
We know the road to freedom has always been stalked by death.
- Angela Davis

Bug#922666: confirmed bug report

2021-05-03 Thread Antoine Beaupré 
On 2021-05-03 20:27:26, Antoine Beaupré wrote:

[...]

> Interestingly, it seems that the machine indeed doesn't go to sleep: it
> loops over a failure to sleep and fills up syslog with errors as long as
> it's trying to sleep, pretty catastrophic, from a battery usage
> perspective.
>
> I attach the two logs and am continuing my investigation. User now
> reports situation is actually much worse than before the backports
> upgrade: at least 5.7 was intermittent, now the crash is systematic.

Relevant: booting into 4.19.132, from plain buster, doesn't reproduce
the above failure to suspend. The machine suspends fine, and resumes,
and the mouse even still works correctly.

I wonder if this is a regression introduced in backports. But I could
have sworn this was happening *before* I upgraded to the backported
kernels...

And here I was hoping that upgrading to bullseye might fix this, maybe
it would make things even worse because the old kernel wouldn't be
available anymore (although if it's an interoperability issue, then
maybe it would fix it, who knows nowadays...)

-- 
No animal has more liberty than the cat; but it buries the mess it
makes. The cat is the best anarchist. Until they learn that from the cat
I cannot respect them.
- For whom the bell tolls, Ernest Hemingway

Bug#922666: confirmed bug report

2021-05-03 Thread Antoine Beaupré 
On 2021-05-03 07:37:42, Salvatore Bonaccorso wrote:
> Control: found -1 5.10.24-1
>
> Hi Antoine,
>
> On Sun, May 02, 2021 at 08:22:07PM -0400, Antoine Beaupré wrote:
>> On 2021-05-01 07:59:01, Salvatore Bonaccorso wrote:
>> > Hi Antoine
>> >
>> > On Fri, Apr 30, 2021 at 07:34:04PM -0400, Antoine Beaupré wrote:
>> >> On 2021-04-30 21:04:29, Salvatore Bonaccorso wrote:
>> >> > Control: tags -1 + moreinfo
>> >> >
>> >> > Hi Tollef, Antoine,
>> >> >
>> >> > On Wed, Sep 11, 2019 at 08:20:22PM -0400, Antoine Beaupré wrote:
>> >> >> Control: forcemerge 922666 928189
>> >> >> Control: severity 922666 important
>> >> >> Control: tags 922666 +patch +confirmed
>> >> >> 
>> >> >> I also see a regression with touchpads and trackpoint on a Thinkpad 
>> >> >> E431
>> >> >> after upgrading from Debian stretch to buster. My research indicates
>> >> >> this is a kernel regression, as yet to be fixed.
>> >> >> 
>> >> >> This is the result of my research, as available online at:
>> >> >> 
>> >> >> https://anarc.at/services/upgrades/buster/#touchpad-trackpoint-freeze-after-sleep
>> >> >> 
>> >> >> On a Thinkpad E431, the entire mouse interface (touch, trackpoint)
>> >> >> freezes after sleep. Keyboard still works but not mouse until a
>> >> >> reboot.
>> >> >> 
>> >> >> There's [bug 922666][] in Debian buster, without a fix. It also says
>> >> >> it eventually recovers, which is not our experience. Possible dupe is
>> >> >> [bug 928189][].
>> >> >> 
>> >> >> [bug 928189]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928189
>> >> >> [bug 922666]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922666
>> >> >> 
>> >> >> There's also [bug 1791427][] in Ubuntu 18.04 that seems related, and
>> >> >> which proposes the following workarounds:
>> >> >> 
>> >> >>  * In gsettings: `org.gnome.desktop.peripherals.touchpad click-method 
>> >> >> disabled`
>> >> >> 
>> >> >>  * A .service file:
>> >> >> 
>> >> >> # /etc/systemd/system/touchpad-sleep.service
>> >> >> # restore touchpad on suspend
>> >> >> 
>> >> >> [Unit]
>> >> >> Description=Restore Touchpad on suspend
>> >> >> Before=sleep.target
>> >> >> StopWhenUnneeded=yes
>> >> >> 
>> >> >> [Service]
>> >> >> #Type=oneshot
>> >> >> Type=idle
>> >> >> RemainAfterExit=yes
>> >> >> ExecStart=/bin/bash -c 'echo ":00:1f.4" > 
>> >> >> /sys/bus/pci/drivers/i801_smbus/unbind'
>> >> >> ExecStop=/bin/bash -c 'echo ":00:1f.4" > 
>> >> >> /sys/bus/pci/drivers/i801_smbus/bind'
>> >> >> 
>> >> >> [Install]
>> >> >> WantedBy=sleep.target
>> >> >> 
>> >> >>  * "Maybe try xserver-xorg-input-evdev instead of 
>> >> >> xserver-xorg-input-libinput?"
>> >> >> 
>> >> >>  * reloading `psmouse`:
>> >> >>  
>> >> >> sudo modprobe -r psmouse
>> >> >> sudo modprobe psmouse
>> >> >> 
>> >> >>  * "`modprobe i2c-i801` after removing it from the `blacklist.conf` 
>> >> >> seems to solve the issue."
>> >> >> 
>> >> >>  * whatever this is:
>> >> >>  
>> >> >> # echo 1 > /sys/devices/rmi4-00/nosleep
>> >> >> 
>> >> >>  * "Anyone who still affected by touchpad issues after S3. Please
>> >> >>switch back to suspend-to-idle in BIOS if s2idle is
>> >> >>supported. ThinkPad Carbon 6th and Yoga 3rd do support
>> >> >>suspend-to-idle in BIOS->config->power menu."
>> >> >> 
>> >> >> [bug 1791427]: 
>> >> >> https://bugs.launchpad.net/ubuntu/+sourc

Bug#928189: Bug#922666: confirmed bug report

2021-05-03 Thread Antoine Beaupré 
On 2021-05-03 07:37:42, Salvatore Bonaccorso wrote:
> Control: found -1 5.10.24-1
>
> Hi Antoine,
>
> On Sun, May 02, 2021 at 08:22:07PM -0400, Antoine Beaupré wrote:
>> On 2021-05-01 07:59:01, Salvatore Bonaccorso wrote:
>> > Hi Antoine
>> >
>> > On Fri, Apr 30, 2021 at 07:34:04PM -0400, Antoine Beaupré wrote:
>> >> On 2021-04-30 21:04:29, Salvatore Bonaccorso wrote:
>> >> > Control: tags -1 + moreinfo
>> >> >
>> >> > Hi Tollef, Antoine,
>> >> >
>> >> > On Wed, Sep 11, 2019 at 08:20:22PM -0400, Antoine Beaupré wrote:
>> >> >> Control: forcemerge 922666 928189
>> >> >> Control: severity 922666 important
>> >> >> Control: tags 922666 +patch +confirmed
>> >> >> 
>> >> >> I also see a regression with touchpads and trackpoint on a Thinkpad 
>> >> >> E431
>> >> >> after upgrading from Debian stretch to buster. My research indicates
>> >> >> this is a kernel regression, as yet to be fixed.
>> >> >> 
>> >> >> This is the result of my research, as available online at:
>> >> >> 
>> >> >> https://anarc.at/services/upgrades/buster/#touchpad-trackpoint-freeze-after-sleep
>> >> >> 
>> >> >> On a Thinkpad E431, the entire mouse interface (touch, trackpoint)
>> >> >> freezes after sleep. Keyboard still works but not mouse until a
>> >> >> reboot.
>> >> >> 
>> >> >> There's [bug 922666][] in Debian buster, without a fix. It also says
>> >> >> it eventually recovers, which is not our experience. Possible dupe is
>> >> >> [bug 928189][].
>> >> >> 
>> >> >> [bug 928189]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928189
>> >> >> [bug 922666]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922666
>> >> >> 
>> >> >> There's also [bug 1791427][] in Ubuntu 18.04 that seems related, and
>> >> >> which proposes the following workarounds:
>> >> >> 
>> >> >>  * In gsettings: `org.gnome.desktop.peripherals.touchpad click-method 
>> >> >> disabled`
>> >> >> 
>> >> >>  * A .service file:
>> >> >> 
>> >> >> # /etc/systemd/system/touchpad-sleep.service
>> >> >> # restore touchpad on suspend
>> >> >> 
>> >> >> [Unit]
>> >> >> Description=Restore Touchpad on suspend
>> >> >> Before=sleep.target
>> >> >> StopWhenUnneeded=yes
>> >> >> 
>> >> >> [Service]
>> >> >> #Type=oneshot
>> >> >> Type=idle
>> >> >> RemainAfterExit=yes
>> >> >> ExecStart=/bin/bash -c 'echo ":00:1f.4" > 
>> >> >> /sys/bus/pci/drivers/i801_smbus/unbind'
>> >> >> ExecStop=/bin/bash -c 'echo ":00:1f.4" > 
>> >> >> /sys/bus/pci/drivers/i801_smbus/bind'
>> >> >> 
>> >> >> [Install]
>> >> >> WantedBy=sleep.target
>> >> >> 
>> >> >>  * "Maybe try xserver-xorg-input-evdev instead of 
>> >> >> xserver-xorg-input-libinput?"
>> >> >> 
>> >> >>  * reloading `psmouse`:
>> >> >>  
>> >> >> sudo modprobe -r psmouse
>> >> >> sudo modprobe psmouse
>> >> >> 
>> >> >>  * "`modprobe i2c-i801` after removing it from the `blacklist.conf` 
>> >> >> seems to solve the issue."
>> >> >> 
>> >> >>  * whatever this is:
>> >> >>  
>> >> >> # echo 1 > /sys/devices/rmi4-00/nosleep
>> >> >> 
>> >> >>  * "Anyone who still affected by touchpad issues after S3. Please
>> >> >>switch back to suspend-to-idle in BIOS if s2idle is
>> >> >>supported. ThinkPad Carbon 6th and Yoga 3rd do support
>> >> >>suspend-to-idle in BIOS->config->power menu."
>> >> >> 
>> >> >> [bug 1791427]: 
>> >> >> https://bugs.launchpad.net/ubuntu/+sourc

Bug#922666: confirmed bug report

2021-05-02 Thread Antoine Beaupré 
On 2021-05-01 07:59:01, Salvatore Bonaccorso wrote:
> Hi Antoine
>
> On Fri, Apr 30, 2021 at 07:34:04PM -0400, Antoine Beaupré wrote:
>> On 2021-04-30 21:04:29, Salvatore Bonaccorso wrote:
>> > Control: tags -1 + moreinfo
>> >
>> > Hi Tollef, Antoine,
>> >
>> > On Wed, Sep 11, 2019 at 08:20:22PM -0400, Antoine Beaupré wrote:
>> >> Control: forcemerge 922666 928189
>> >> Control: severity 922666 important
>> >> Control: tags 922666 +patch +confirmed
>> >> 
>> >> I also see a regression with touchpads and trackpoint on a Thinkpad E431
>> >> after upgrading from Debian stretch to buster. My research indicates
>> >> this is a kernel regression, as yet to be fixed.
>> >> 
>> >> This is the result of my research, as available online at:
>> >> 
>> >> https://anarc.at/services/upgrades/buster/#touchpad-trackpoint-freeze-after-sleep
>> >> 
>> >> On a Thinkpad E431, the entire mouse interface (touch, trackpoint)
>> >> freezes after sleep. Keyboard still works but not mouse until a
>> >> reboot.
>> >> 
>> >> There's [bug 922666][] in Debian buster, without a fix. It also says
>> >> it eventually recovers, which is not our experience. Possible dupe is
>> >> [bug 928189][].
>> >> 
>> >> [bug 928189]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928189
>> >> [bug 922666]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922666
>> >> 
>> >> There's also [bug 1791427][] in Ubuntu 18.04 that seems related, and
>> >> which proposes the following workarounds:
>> >> 
>> >>  * In gsettings: `org.gnome.desktop.peripherals.touchpad click-method 
>> >> disabled`
>> >> 
>> >>  * A .service file:
>> >> 
>> >> # /etc/systemd/system/touchpad-sleep.service
>> >> # restore touchpad on suspend
>> >> 
>> >> [Unit]
>> >> Description=Restore Touchpad on suspend
>> >> Before=sleep.target
>> >> StopWhenUnneeded=yes
>> >> 
>> >> [Service]
>> >> #Type=oneshot
>> >> Type=idle
>> >> RemainAfterExit=yes
>> >> ExecStart=/bin/bash -c 'echo ":00:1f.4" > 
>> >> /sys/bus/pci/drivers/i801_smbus/unbind'
>> >> ExecStop=/bin/bash -c 'echo ":00:1f.4" > 
>> >> /sys/bus/pci/drivers/i801_smbus/bind'
>> >> 
>> >> [Install]
>> >> WantedBy=sleep.target
>> >> 
>> >>  * "Maybe try xserver-xorg-input-evdev instead of 
>> >> xserver-xorg-input-libinput?"
>> >> 
>> >>  * reloading `psmouse`:
>> >>  
>> >> sudo modprobe -r psmouse
>> >> sudo modprobe psmouse
>> >> 
>> >>  * "`modprobe i2c-i801` after removing it from the `blacklist.conf` seems 
>> >> to solve the issue."
>> >> 
>> >>  * whatever this is:
>> >>  
>> >> # echo 1 > /sys/devices/rmi4-00/nosleep
>> >> 
>> >>  * "Anyone who still affected by touchpad issues after S3. Please
>> >>switch back to suspend-to-idle in BIOS if s2idle is
>> >>supported. ThinkPad Carbon 6th and Yoga 3rd do support
>> >>suspend-to-idle in BIOS->config->power menu."
>> >> 
>> >> [bug 1791427]: 
>> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791427
>> >> 
>> >> There's also [bug 1442699][] in Fedora, which suggests those
>> >> workarounds:
>> >> 
>> >>  * another module reload:
>> >>  
>> >> sudo rmmod i2c_hid
>> >> sudo modprobe i2c_hid
>> >> 
>> >>  * "Just updated to kernel-4.12.5-300.fc26.x86_64 in updates-testing
>> >>and this issue seems to have been resolved (for me)."
>> >> 
>> >>  * another `/proc` hack:
>> >>  
>> >> echo -n "reconnect" >  /sys/bus/serio/devices/serio1/drvctl
>> >> 
>> >>  * "The `psmouse.synaptics_intertouch=0` workaround still works for me."
>> >> 
>> >> [bug 1442699]: https://bugzilla.redhat.com/show_bug.cgi?id=1442699
>> >> 
>> >> Als

Bug#922666: confirmed bug report

2021-04-30 Thread Antoine Beaupré 
On 2021-04-30 21:04:29, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
>
> Hi Tollef, Antoine,
>
> On Wed, Sep 11, 2019 at 08:20:22PM -0400, Antoine Beaupré wrote:
>> Control: forcemerge 922666 928189
>> Control: severity 922666 important
>> Control: tags 922666 +patch +confirmed
>> 
>> I also see a regression with touchpads and trackpoint on a Thinkpad E431
>> after upgrading from Debian stretch to buster. My research indicates
>> this is a kernel regression, as yet to be fixed.
>> 
>> This is the result of my research, as available online at:
>> 
>> https://anarc.at/services/upgrades/buster/#touchpad-trackpoint-freeze-after-sleep
>> 
>> On a Thinkpad E431, the entire mouse interface (touch, trackpoint)
>> freezes after sleep. Keyboard still works but not mouse until a
>> reboot.
>> 
>> There's [bug 922666][] in Debian buster, without a fix. It also says
>> it eventually recovers, which is not our experience. Possible dupe is
>> [bug 928189][].
>> 
>> [bug 928189]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928189
>> [bug 922666]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922666
>> 
>> There's also [bug 1791427][] in Ubuntu 18.04 that seems related, and
>> which proposes the following workarounds:
>> 
>>  * In gsettings: `org.gnome.desktop.peripherals.touchpad click-method 
>> disabled`
>> 
>>  * A .service file:
>> 
>> # /etc/systemd/system/touchpad-sleep.service
>> # restore touchpad on suspend
>> 
>> [Unit]
>> Description=Restore Touchpad on suspend
>> Before=sleep.target
>> StopWhenUnneeded=yes
>> 
>> [Service]
>> #Type=oneshot
>> Type=idle
>> RemainAfterExit=yes
>> ExecStart=/bin/bash -c 'echo ":00:1f.4" > 
>> /sys/bus/pci/drivers/i801_smbus/unbind'
>> ExecStop=/bin/bash -c 'echo ":00:1f.4" > 
>> /sys/bus/pci/drivers/i801_smbus/bind'
>> 
>> [Install]
>> WantedBy=sleep.target
>> 
>>  * "Maybe try xserver-xorg-input-evdev instead of 
>> xserver-xorg-input-libinput?"
>> 
>>  * reloading `psmouse`:
>>  
>> sudo modprobe -r psmouse
>> sudo modprobe psmouse
>> 
>>  * "`modprobe i2c-i801` after removing it from the `blacklist.conf` seems to 
>> solve the issue."
>> 
>>  * whatever this is:
>>  
>> # echo 1 > /sys/devices/rmi4-00/nosleep
>> 
>>  * "Anyone who still affected by touchpad issues after S3. Please
>>switch back to suspend-to-idle in BIOS if s2idle is
>>supported. ThinkPad Carbon 6th and Yoga 3rd do support
>>suspend-to-idle in BIOS->config->power menu."
>> 
>> [bug 1791427]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791427
>> 
>> There's also [bug 1442699][] in Fedora, which suggests those
>> workarounds:
>> 
>>  * another module reload:
>>  
>> sudo rmmod i2c_hid
>> sudo modprobe i2c_hid
>> 
>>  * "Just updated to kernel-4.12.5-300.fc26.x86_64 in updates-testing
>>and this issue seems to have been resolved (for me)."
>> 
>>  * another `/proc` hack:
>>  
>> echo -n "reconnect" >  /sys/bus/serio/devices/serio1/drvctl
>> 
>>  * "The `psmouse.synaptics_intertouch=0` workaround still works for me."
>> 
>> [bug 1442699]: https://bugzilla.redhat.com/show_bug.cgi?id=1442699
>> 
>> Also related is this [libinput bug][] that's closed as "not our bug"
>> because they claim it's a bug in the kernel.
>> 
>> [libinput bug]: https://bugs.freedesktop.org/show_bug.cgi?id=103149
>> 
>> There are [two][] [patches][] on the Linux kernel which apparently fix the
>> issue, still pending approval:
>> 
>> [two]: https://lkml.org/lkml/2019/2/20/700
>> [patches]: https://lkml.org/lkml/2019/2/20/701
>> 
>> Possibly related: https://lkml.org/lkml/2016/8/18/134
>> 
>> [5.1rc7][] shipped two fixes against the `synaptics-rmi4` module. A
>> [pull request][] has been merged in mainline with two other fixes on
>> the module./ [5.0.11][] also has fixes on the module. It's clearly a
>> regression from Debian stretch (kernel 4.9) since it was working fine
>> before.
>> 
>> Possibly related, [two-finger scrolling bug in Ubuntu][], which
>> identifies [this commit][] as the source of the regression. [Upstrea

Bug#898446: Please reconsider enabling the user namespaces by default

2020-11-17 Thread Antoine Beaupré 
On 2020-10-22 22:55:33, Salvatore Bonaccorso wrote:
> Hi,
>
> On Tue, Oct 20, 2020 at 05:21:24PM +0100, Simon McVittie wrote:
>> On Thu, 16 Apr 2020 at 03:09:25 +0100, Ben Hutchings wrote:
>> > I don't think we should keep patching in
>> > kernel.unprivileged_userns_clone forever, so the documented way to
>> > disable user namespaces should be setting user.max_user_namespaces to
>> > 0.  But then there's no good way to have a drop-in file that changes
>> > back to the upstream default, because that's dependent on system memory
>> > size.
>> > 
>> > So I think we should do something like this:
>> > 
>> > * Document user.max_user_namespaces in procps's shipped
>> >   /etc/sysctl.conf
>> > * Set kernel.unprivileged_userns_clone to 1 by default, and deprecate
>> >   it (log a warning if it's changed)
>> > * Document the change in bullseye release notes
>> 
>> Is this something you intend to do before bullseye, or is it now going
>> to be after bullseye?
>> 
>> If this is intended to happen before bullseye, I'd like enough time
>> before the freeze to put an as-graceful-as-possible transition in place
>> in the bubblewrap package.
>> 
>> (I'm not sure what form that transition should take - suggestions welcome!
>> Ideally I'd like bubblewrap to be setuid root if and only if we are still
>> using a kernel where it needs to be.)
>
> TBH, I think not having it enabled by default until now saved us a
> couple of time from needing to release urgent fixes. It is more a gut
> feeling and might not have enough weight: but having it still disabled
> in bullseye by default we would be still better of from security
> releases/DSA's perspectives.

Could we get a little more hard data about the attack vectors here? I
totally trust the security team's "gut feeling" on this, but it would be
great to be able to evaluate more concretely what we're talking about
here.

Local root privilege escalation, basically? Can we get a sense of what
those vulerabilities are, say with some example CVEs?

I'm asking because my main concern with security these days is with the
web browser. It's this huge gaping hole: every measure we can take to
sandbox that thing is become more and more critical, so I wonder if the
our tradeoff's evaluation is well adjusted here, especially considering
a lot of user_ns consumers are bypassing those restrictions by running
as root anyways...

It seems that, in those cases, we're getting the worst of both worlds...

a.
-- 
It is a miracle that curiosity survives formal education
- Albert Einstein

Bug#922666: confirmed bug report

2019-09-11 Thread Antoine Beaupré 
Control: forcemerge 922666 928189
Control: severity 922666 important
Control: tags 922666 +patch +confirmed

I also see a regression with touchpads and trackpoint on a Thinkpad E431
after upgrading from Debian stretch to buster. My research indicates
this is a kernel regression, as yet to be fixed.

This is the result of my research, as available online at:

https://anarc.at/services/upgrades/buster/#touchpad-trackpoint-freeze-after-sleep

On a Thinkpad E431, the entire mouse interface (touch, trackpoint)
freezes after sleep. Keyboard still works but not mouse until a
reboot.

There's [bug 922666][] in Debian buster, without a fix. It also says
it eventually recovers, which is not our experience. Possible dupe is
[bug 928189][].

[bug 928189]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928189
[bug 922666]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922666

There's also [bug 1791427][] in Ubuntu 18.04 that seems related, and
which proposes the following workarounds:

 * In gsettings: `org.gnome.desktop.peripherals.touchpad click-method disabled`

 * A .service file:

# /etc/systemd/system/touchpad-sleep.service
# restore touchpad on suspend

[Unit]
Description=Restore Touchpad on suspend
Before=sleep.target
StopWhenUnneeded=yes

[Service]
#Type=oneshot
Type=idle
RemainAfterExit=yes
ExecStart=/bin/bash -c 'echo ":00:1f.4" > 
/sys/bus/pci/drivers/i801_smbus/unbind'
ExecStop=/bin/bash -c 'echo ":00:1f.4" > 
/sys/bus/pci/drivers/i801_smbus/bind'

[Install]
WantedBy=sleep.target

 * "Maybe try xserver-xorg-input-evdev instead of xserver-xorg-input-libinput?"

 * reloading `psmouse`:
 
sudo modprobe -r psmouse
sudo modprobe psmouse

 * "`modprobe i2c-i801` after removing it from the `blacklist.conf` seems to 
solve the issue."

 * whatever this is:
 
# echo 1 > /sys/devices/rmi4-00/nosleep

 * "Anyone who still affected by touchpad issues after S3. Please
   switch back to suspend-to-idle in BIOS if s2idle is
   supported. ThinkPad Carbon 6th and Yoga 3rd do support
   suspend-to-idle in BIOS->config->power menu."

[bug 1791427]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791427

There's also [bug 1442699][] in Fedora, which suggests those
workarounds:

 * another module reload:
 
sudo rmmod i2c_hid
sudo modprobe i2c_hid

 * "Just updated to kernel-4.12.5-300.fc26.x86_64 in updates-testing
   and this issue seems to have been resolved (for me)."

 * another `/proc` hack:
 
echo -n "reconnect" >  /sys/bus/serio/devices/serio1/drvctl

 * "The `psmouse.synaptics_intertouch=0` workaround still works for me."

[bug 1442699]: https://bugzilla.redhat.com/show_bug.cgi?id=1442699

Also related is this [libinput bug][] that's closed as "not our bug"
because they claim it's a bug in the kernel.

[libinput bug]: https://bugs.freedesktop.org/show_bug.cgi?id=103149

There are [two][] [patches][] on the Linux kernel which apparently fix the
issue, still pending approval:

[two]: https://lkml.org/lkml/2019/2/20/700
[patches]: https://lkml.org/lkml/2019/2/20/701

Possibly related: https://lkml.org/lkml/2016/8/18/134

[5.1rc7][] shipped two fixes against the `synaptics-rmi4` module. A
[pull request][] has been merged in mainline with two other fixes on
the module./ [5.0.11][] also has fixes on the module. It's clearly a
regression from Debian stretch (kernel 4.9) since it was working fine
before.

Possibly related, [two-finger scrolling bug in Ubuntu][], which
identifies [this commit][] as the source of the regression. [Upstream
kernel bug][], still open.

[5.1rc7]: https://lkml.org/lkml/2019/4/28/270
[pull request]: https://lkml.org/lkml/2019/7/12/19
[5.0.11]: https://lkml.org/lkml/2019/5/2/287
[Upstream kernel bug]: https://bugzilla.kernel.org/show_bug.cgi?id=196719
[this commit]: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e839ffab028981ac77f650faf8c84f16e1719738
[two-finger scrolling bug in Ubuntu]: 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1722478

I haven't tried any of those workarounds. I hope this helps!

-- 
Si les triangles avaient un Dieu, ils lui donneraient trois côtés.
- Montesquieu, Lettres persanes

Bug#860264: similar bug with sshfs, maybe in systemd/ifupdown

2019-01-29 Thread Antoine Beaupré 
On 2019-01-29 21:32:24, Gabriel Filion wrote:
> Hi there,
>
> On 2019-01-29 9:26 p.m., Antoine Beaupre wrote:
>> We'd need an easier way to reproduce this however. Has anyone worked on
>> getting some virtual machine images up to try and orchestrate a
>> reproducer for this? That would be ideal but a step-by-step set of
>> minimal instructions starting from a clean install would be an
>> acceptable compromise.
>
> The bug is hard to reproduce since it's a run condition that might not
> happen sometimes.

It's pretty reliable on the vero 4k+, for what that's worth. But it's a
slower ARM machine...

> The simplest way to reproduce is to have an nfs (or maybe sshfs if it's
> possible to reproduce with this) server, then on a buster machine to add
> the nfs mount as a line to the fstab file, then reboot.
>
> when the mount does not work, it is quite apparent: the boot process
> hangs for some time before NFS decides to timeout.

understood. do you think it would be possible to setup a vagrant box
with this somehow?

a

-- 
>From the age of uniformity, from the age of solitude, from the age of
Big Brother, from the age of doublethink - greetings!
- Winston Smith, 1984

Re: Bug#889098: enforce fs.protected_hardlinks in sysctl.d by default

2018-02-03 Thread Antoine Beaupré 
On 2018-02-03 10:54:18, Salvatore Bonaccorso wrote:
> Hi
>
> On Fri, Feb 02, 2018 at 09:25:31PM +0100, Moritz Mühlenhoff wrote:
>> Antoine Beaupré wrote:
>> > There are, however, people *not* running Debian-built kernels, and
>> > sometimes for good reasons. This is a configuration that we should
>> > still support.
>> 
>> Is it supported, but it's also clearly documented that people need to
>> enable this sysctl for custom kernels:
>> https://www.debian.org/releases/jessie/amd64/release-notes/ch-whats-new.en.html#security
>
> Just to add a note: if procps is as well going to ship this hardening
> for fs.protected_hardlinks then I think it would be best to follow the
> kernel and do the same for fs.protected_symlinks as well, not only
> the fs.protected_hardlinks.

Agreed.

>> > Incidentally, I wonder if we should remove the patch we have on the
>> > Debian kernels to change the defaults, and instead rely on the
>> > sysctl. I have added the kernel team in CC to have their input.
>> 
>> Why revert the kernel? That doesn't buy us anything. It would be
>> better to ask upstream to revisit this decision (e.g. by contacting
>> KSPP mailing list). I suppose that SuSE, Ubuntu and Red Hat have
>> are shipping similar patches/defaults, so it's probably safe to say
>> that those protections are now the status quo (as opposed to five
>> years ago when that feature was freshly introduced).
>
> Agreed with you and Ben to actually not revert the sane defaults in
> the Debian kernel.
>
> Btw, upstream did initially as well set those, then reverted due to
> some userspace programms breaking, they are/were rare, but the rule is
> to not break userspace (this was done in the referenced commit, "VFS:
> don't do protected {sym,hard}links by default", where it's noted that
> it e.g. broke AFD.) 

Right. But we've been running with this as default in Debian for a
while. We also have good mechanisms (config file tracking) to allow
custom changes for users that build their own kernels, although that
might need a release notes update or something because that won't be
flagged by those mechanisms.

A.

-- 
Drowning people
Sometimes die
Fighting their rescuers.
- Octavia Butler

Re: enforce fs.protected_hardlinks in sysctl.d by default

2018-02-02 Thread Antoine Beaupré 
On 2018-02-02 21:25:31, Moritz Mühlenhoff wrote:
> Antoine Beaupré wrote:
>> There are, however, people *not* running Debian-built kernels, and
>> sometimes for good reasons. This is a configuration that we should
>> still support.
>
> Is it supported, but it's also clearly documented that people need to
> enable this sysctl for custom kernels:
> https://www.debian.org/releases/jessie/amd64/release-notes/ch-whats-new.en.html#security

True. I guess what I'm arguing for is to do this explicitly from here
on.

>> Incidentally, I wonder if we should remove the patch we have on the
>> Debian kernels to change the defaults, and instead rely on the
>> sysctl. I have added the kernel team in CC to have their input.
>
> Why revert the kernel? That doesn't buy us anything. It would be
> better to ask upstream to revisit this decision (e.g. by contacting
> KSPP mailing list). I suppose that SuSE, Ubuntu and Red Hat have
> are shipping similar patches/defaults, so it's probably safe to say
> that those protections are now the status quo (as opposed to five
> years ago when that feature was freshly introduced).

It was just an idea: I'm fine with keeping the patch and I think it's a
good idea to enforce this in two places, to keep defense in depth.

I'm not sure I want to go through the emotional trauma of trying to
bring this upstream, unfortunately. ;)

Thanks for the response.

A.

-- 
All governments are run by liars and nothing they say should be
believed.
   - I. F. Stone

enforce fs.protected_hardlinks in sysctl.d by default

2018-02-01 Thread Antoine Beaupré 
Control: retitle 889098 enforce fs.protected_hardlinks in sysctl.d by default

Package: procps
Version: 2:3.3.12-3
Severity: normal
Tags: security

Following the disclosure of CVE-2017-18078, there was an elaborate
discussion on the #debian-devel and #debian-security IRC channels
regarding the scope of the vulnerability. It was then realized that
the impact of this was broader than just systemd: any time a command
like `chown -R` is ran over an untrusted directory, by root, the same
problem occurs.

This is of course mitigated by the fs.protected_hardlinks kernel
configuration, which is enforced through a patch on all the official
Debian kernels distributed by Debian, including in wheezy. See for
example:

https://sources.debian.org/src/linux/3.16.7-ckt20-1+deb8u3/debian/patches/debian/fs-enable-link-security-restrictions-by-default.patch/
https://sources.debian.org/src/linux/4.14.13-1/debian/patches/debian/fs-enable-link-security-restrictions-by-default.patch/

There are, however, people *not* running Debian-built kernels, and
sometimes for good reasons. This is a configuration that we should
still support.

Therefore, it seems to me we should enable this more broadly, for
example in /etc/sysctl.d/protected-hardlinks.conf. Configuring this in
user space is actually what is recommended by Linus Torvalds and the
upstream Linux kernel:

https://github.com/torvalds/linux/commit/561ec64ae67ef25cac8d72bb9c4bfc955edfd415

systemd ships this configuration as well, but this was deliberately
removed from Debian's systemd configuration:

https://salsa.debian.org/systemd-team/systemd/commit/3e1bfe0d84545557d268c1293fff0d5f3db3b5c7

I agree with the above perspective: systemd is not sufficient to
resolve that issue. We still have other init systems and we shouldn't
fix this in systemd, but in a broader package. This is why I am
proposing to fix this in procps, which ultimately owns /etc/sysctl.d/
(and /etc/sysctl.conf).

This is not a strong position: if people think this belongs in systemd
more than procps, or there is some more relevant place this can be
done *by default*, let's do it there and not quibble over that
peculiar bikeshed. :)

I would suggest adding the following configuration:

# Enable hard link protection
fs.protected_hardlinks = 1

Note that the original systemd config also enables softlink
protection:

https://salsa.debian.org/systemd-team/systemd/blob/master/sysctl.d/50-default.conf

I'm not sure if that's also relevant here so I'd keep this to
hardlinks for now to avoid unnecessary debate.

Incidentally, I wonder if we should remove the patch we have on the
Debian kernels to change the defaults, and instead rely on the
sysctl. I have added the kernel team in CC to have their input.

Thanks!

PS: sorry for the duplicate email, I had a copy-paste problem with
reportbug and forgot to re-set a subject.

-- 
We don't need any more heroes.
We just need someone to take out recycling.
- Banksy

Bug#814648: linux kernel backports broken

2016-05-31 Thread Antoine Beaupré 
Also, it seems impossible to rebuild the backport from source:

[1060]anarcat@angela:dist$ sudo DIST=jessie ARCH=amd64 cowbuilder --build  
linux_4.5.4-1~bpo8+1.dsc
 -> Copying COW directory
  forking: rm -rf /var/cache/pbuilder/build//cow.9542 
  forking: cp -al /var/cache/pbuilder/base-jessie-amd64.cow/ 
/var/cache/pbuilder/build//cow.9542 
I: removed stale ilistfile /var/cache/pbuilder/build//cow.9542/.ilist
  forking: chroot /var/cache/pbuilder/build//cow.9542 cowdancer-ilistcreate 
/.ilist find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a 
-links +1 -print0 \) | xargs -0 stat --format '%d %i ' 
 -> Invoking pbuilder
  forking: pbuilder build --buildplace /var/cache/pbuilder/build//cow.9542 
--buildresult /var/cache/pbuilder/jessie-amd64/result/ --debbuildopts  
--no-targz --internal-chrootexec chroot /var/cache/pbuilder/build//cow.9542 
cow-shell /home/anarcat/dist/linux_4.5.4-1~bpo8+1.dsc 
W: /root/.pbuilderrc does not exist
I: Running in no-targz mode
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Tue May 31 16:05:41 EDT 2016
I: pbuilder-time-stamp: 1464725141
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /var/cache/archive
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper, python3:any, quilt, cpio , xz-utils , 
kernel-wedge (>= 2.93~), kmod , bc , libssl-dev 
, openssl , asciidoc , 
xmlto , bison , 
flex , gcc-multilib , 
libaudit-dev , libdw-dev , libelf-dev , libiberty-dev 
, libnewt-dev , 
libnuma-dev , libperl-dev , libunwind8-dev , python-dev 
, autoconf , automake 
, libtool , 
libglib2.0-dev , libudev-dev , libwrap0-dev , libpci-dev 
, dh-python , dh-systemd , gcc-4.9, patchutils , xmlto 
dpkg-deb: error: parsing file 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy/DEBIAN/control' 
near line 8 package 'pbuilder-satisfydepends-dummy':
 `Depends' field, syntax error after reference to package `cpio'
E: pbuilder-satisfydepends failed.
I: Copying back the cached apt archive contents
I: unmounting /var/cache/archive filesystem
I: unmounting dev/pts filesystem
I: unmounting run/shm filesystem
I: unmounting proc filesystem
 -> Cleaning COW directory
  forking: rm -rf /var/cache/pbuilder/build//cow.9542 

with dpkg-buildpackage, it's a little better, but the dependency for
kernel-wedge is off too.

a.
-- 
Be yourself. Everyone else is already taken!
- Oscar Wilde

Bug#814648: linux kernel backports broken

2016-05-31 Thread Antoine Beaupré 
Control: found -1 4.5.4-1~bpo8+1

Hi,

I still see this problem in debian jessie right now. I can't install the
linux kernel backport.

cp: impossible d'évaluer « /boot/initrd.img-4.5.0-0.bpo.2-amd64 »: Aucun 
fichier ou dossier de ce type

The initrd is simply not in the .deb:

[1043]anarcat@angela:~$ dpkg -c 
/var/cache/apt/archives/linux-image-4.5.0-0.bpo.2-amd64_4.5.4-1~bpo8+1_amd64.deb
 | grep initrd
[1044]anarcat@angela:~1$ 

In fact, it's not in any of the last uploads:

$ for image in /var/cache/apt/archives/linux-image-4.*bpo8+1_amd64.deb; do echo 
$image;  dpkg -c $image | grep initrd; done
/var/cache/apt/archives/linux-image-4.3.0-0.bpo.1-amd64_4.3.5-1~bpo8+1_amd64.deb
/var/cache/apt/archives/linux-image-4.4.0-0.bpo.1-amd64_4.4.6-1~bpo8+1_amd64.deb
/var/cache/apt/archives/linux-image-4.5.0-0.bpo.1-amd64_4.5.1-1~bpo8+1_amd64.deb
/var/cache/apt/archives/linux-image-4.5.0-0.bpo.2-amd64_4.5.4-1~bpo8+1_amd64.deb

I don't understand how anyone can use any of those backports without a
initrd.

Does *anyone* run linux backports on jessie right now?

A.
-- 
>From the age of uniformity, from the age of solitude, from the age of
Big Brother, from the age of doublethink - greetings!
- Winston Smith, 1984

Bug#814648: initrd missing from backport build (Failed to copy /boot/initrd.img-4.3.0-0.bpo.1-amd64 to /initrd.img)

2016-02-13 Thread Antoine Beaupré 
Package: linux-image-4.3.0-0.bpo.1-amd64
Version: 4.3.3-7~bpo8+1
Severity: normal

This version of the backport seems to fail to install properly:

$ sudo apt install -t jessie-backports linux-image-4.3.0-0.bpo.1-amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  linux-doc-4.3 debian-kernel-handbook
The following NEW packages will be installed:
  linux-image-4.3.0-0.bpo.1-amd64
0 upgraded, 1 newly installed, 0 to remove and 210 not upgraded.
Need to get 0 B/35.5 MB of archives.
After this operation, 173 MB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously unselected package linux-image-4.3.0-0.bpo.1-amd64.
(Reading database ... 447530 files and directories currently installed.)
Preparing to unpack 
.../linux-image-4.3.0-0.bpo.1-amd64_4.3.3-7~bpo8+1_amd64.deb ...
Unpacking linux-image-4.3.0-0.bpo.1-amd64 (4.3.3-7~bpo8+1) ...
Setting up linux-image-4.3.0-0.bpo.1-amd64 (4.3.3-7~bpo8+1) ...
cp: cannot stat '/boot/initrd.img-4.3.0-0.bpo.1-amd64': No such file or 
directory
Failed to copy /boot/initrd.img-4.3.0-0.bpo.1-amd64 to /initrd.img .
dpkg: error processing package linux-image-4.3.0-0.bpo.1-amd64 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 linux-image-4.3.0-0.bpo.1-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

and indeed, the initrd is not in /boot:

[1012]anarcat@angela:~100$ ls -al /boot/
total 73248K
drwxr-xr-x  5 root root 1024 Feb 13 12:26 .
drwxr-xr-x 26 root root 4096 Feb 13 12:26 ..
-rw-r--r--  1 root root  2676277 Jan 17 16:30 System.map-3.16.0-4-amd64
-rw-r--r--  1 root root  2889500 Dec 15 05:16 System.map-4.2.0-0.bpo.1-amd64
-rw-r--r--  1 root root  2949440 Jan 20 18:17 System.map-4.3.0-0.bpo.1-amd64
-rw-r--r--  1 root root   157726 Jan 17 16:30 config-3.16.0-4-amd64
-rw-r--r--  1 root root   169935 Dec 15 05:16 config-4.2.0-0.bpo.1-amd64
-rw-r--r--  1 root root   171928 Jan 20 18:17 config-4.3.0-0.bpo.1-amd64
drwxr-xr-x  5 root root 7168 Feb 13 12:24 grub
drwxr-xr-x  2 root root 1024 Sep 24 21:54 images
-rw-r--r--  1 root root 27164630 Jan 23 12:19 initrd.img-3.16.0-4-amd64
-rw-r--r--  1 root root 28134677 Jan 23 12:20 initrd.img-4.2.0-0.bpo.1-amd64
drwx--  2 root root12288 Mar 29  2010 lost+found
-rw-r--r--  1 root root25372 Sep 24 21:50 memdisk
-rw-r--r--  1 root root   182704 Sep 10  2014 memtest86+.bin
-rw-r--r--  1 root root   184840 Sep 10  2014 memtest86+_multiboot.bin
-rw-r--r--  1 root root98964 Mar 10  2015 memtest86.bin
-rw-r--r--  1 root root  3119888 Jan 17 16:27 vmlinuz-3.16.0-4-amd64
-rw-r--r--  1 root root  3480512 Dec 15 05:15 vmlinuz-4.2.0-0.bpo.1-amd64
-rw-r--r--  1 root root  3566064 Jan 20 18:14 vmlinuz-4.3.0-0.bpo.1-amd64

Heck, it's not even in the package itself:

$ dpkg -c 
/var/cache/apt/archives/linux-image-4.3.0-0.bpo.1-amd64_4.3.3-7~bpo8+1_amd64.deb
  | grep /boot/
drwxr-xr-x root/root 0 2016-01-20 18:17 ./boot/
-rw-r--r-- root/root   2949440 2016-01-20 18:17 
./boot/System.map-4.3.0-0.bpo.1-amd64
-rw-r--r-- root/root171928 2016-01-20 18:17 
./boot/config-4.3.0-0.bpo.1-amd64
-rw-r--r-- root/root   3566064 2016-01-20 18:14 
./boot/vmlinuz-4.3.0-0.bpo.1-amd64

Something really wrong happened when this backport was built...

a.

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (500, 'oldstable'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.3.0-0.bpo.1-amd64 depends on:
ii  debconf [debconf-2.0]   1.5.56
ii  initramfs-tools [linux-initramfs-tool]  0.120
ii  kmod18-3
ii  linux-base  3.5

Versions of packages linux-image-4.3.0-0.bpo.1-amd64 recommends:
ii  firmware-linux-free  3.3
ii  irqbalance   1.0.6-3

Versions of packages linux-image-4.3.0-0.bpo.1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta2-22+deb8u1
pn  linux-doc-4.3   

-- debconf information:
  
linux-image-4.3.0-0.bpo.1-amd64/postinst/depmod-error-initrd-4.3.0-0.bpo.1-amd64:
 false
  
linux-image-4.3.0-0.bpo.1-amd64/prerm/removing-running-kernel-4.3.0-0.bpo.1-amd64:
 true
  linux-image-4.3.0-0.bpo.1-amd64/postinst/mips-initrd-4.3.0-0.bpo.1-amd64:

Bug#776816: firmware-realtek: fails to connect after a few suspends (or some uptime?)

2015-11-22 Thread Antoine Beaupré 
On 2015-02-28 18:08:50, Ben Hutchings wrote:
> Control: severity -1 normal
> Control: notfixed -1 0.36+wheezy.1
>
> On Wed, 2015-02-18 at 23:25 -0500, Antoine Beaupré wrote:
>> Control: severity -1 grave
>> Control: fixed -1 0.36+wheezy.1
>> 
>> I am now pretty sure this is a bug, a regression, even, in the realtek
>> firmware. I downgraded to the wheezy version 4 days ago, and problems
>> went away (hence the "fixed" above). Now that I upgraded again, problems
>> are back.
> [...]
>
> The rtl8192ce firmware (rtl8192cfw.bin, rtl8192cfwU.bin and
> rtl8192cfwU_B.bin for various versions of the chip) has not been changed
> since version 0.36+wheezy.1 of the package.  So this problem is not a
> regression.

So I know this is pretty old now, but i'm still stuck with this wifi
card that basically doesn't work at all as soon as encryption is used
over the airwaves. I get a minute or two of traffic then boom, it goes
down and i need to turn the wifi off and on again to fix it. That is, to
say the least, disruptive to things like TCP.

In february I documented that downgrading to the wheezy version fixed
it. I double-checked my dpkg logs (while they're stil around!) and
figured it could be useful to paste those to confirm that:

2015-02-14 23:20:17 startup archives unpack
2015-02-14 23:20:21 upgrade firmware-realtek:all 0.43 0.36+wheezy.1
2015-02-14 23:20:21 status half-configured firmware-realtek:all 0.43
2015-02-14 23:20:21 status unpacked firmware-realtek:all 0.43
2015-02-14 23:20:21 status half-installed firmware-realtek:all 0.43
2015-02-14 23:20:21 status half-installed firmware-realtek:all 0.43
2015-02-14 23:20:22 status unpacked firmware-realtek:all 0.36+wheezy.1
2015-02-14 23:20:22 status unpacked firmware-realtek:all 0.36+wheezy.1
2015-02-14 23:20:22 startup packages configure
2015-02-14 23:20:22 configure firmware-realtek:all 0.36+wheezy.1

2015-02-14 23:20:22 status unpacked firmware-realtek:all 0.36+wheezy.1
2015-02-14 23:20:22 status half-configured firmware-realtek:all
0.36+wheezy.1
2015-02-14 23:20:22 status installed firmware-realtek:all 0.36+wheezy.1
2015-02-14 23:20:22 status triggers-pending initramfs-tools:all 0.116
2015-02-14 23:20:22 trigproc initramfs-tools:all 0.116 
2015-02-14 23:20:22 status half-configured initramfs-tools:all 0.116
2015-02-14 23:20:46 status installed initramfs-tools:all 0.116
2015-02-14 23:20:47 startup packages configure

I am currently running into the same issues with the firmware from 0.44,
which *has* changed from 0.43 and previous. Yet the problem is still
there.

I have found similar threads here and there... Here's one in Ubuntu that
is similar:

https://askubuntu.com/questions/504777/unstable-wireless-connection-in-ubuntu-14-04

the suggested workaround ("swenc=1 ips=0") doesn't work. I do not
control the wireless routers in a lot of cases, so the other suggestions
do not apply. (Although i did try to disable IPv6, which doesn't work
either.)

this thread is also somewhat similar and explains a lot of options in
diagnostics of the realtek firmware:

http://ubuntuforums.org/showthread.php?t=2180178

Somehow, if the wifi connection is continuously active, the delay until
which i need to restart it is longer. Ping doesn't suffice, it needs to
be a bunch of tabs in a browser or something. I feel there's a
correlation between me switching from my web browser to a mosh session,
but that could just be an impression. In fact, it seems that if the
connection is *idle* too long, something times out and the wifi
crumbles.

this kernel bug also seems related:

https://bugzilla.kernel.org/show_bug.cgi?id=60713

It could explain the regression i saw from wheezy (linux 3.2) to jesssie
(linux 3.16). But downgrading to Linux 3.2 doesn't completely solve the
problem. The connexion is slightly more reliable, but not in a
definitive way. I still saw it crash two times since the reboot, but it
feels way more reliable. Whereas 3.16 crashes very frequently (every one
or two minutes), i have just now spent 10 minutes without a crash on
3.2, which almost never happens on 3.16.

The 4.2 kernel also looks a little more reliable. I need to test it a
little more, but so far there has been no crashes in about 10 minutes of
uptime. This is exceptional: i couldn't get anything that reliable in
jessie so far with or without the wheezy kernel.

(One new problem, however, is that the network-manager applet doesn't
notice the network going up anymore, which looks really weird because
the animation is stuck at "the first ball is green, the other gray" and
stays there, even though the UI is still responsive. Restarting
nm-applet fixes that specific problem.)

It certainly feels that something is wrong with the gain control, as
described in the kernel bug report above; another symptom i just noticed
is that, through mosh i can see my irssi clock being update on a shell,
even when i can't ping the

Bug#776816: Acknowledgement (firmware-realtek: fails to connect after a few suspends (or some uptime?))

2015-02-18 Thread Antoine Beaupré 
Control: severity -1 grave
Control: fixed -1 0.36+wheezy.1

I am now pretty sure this is a bug, a regression, even, in the realtek
firmware. I downgraded to the wheezy version 4 days ago, and problems
went away (hence the fixed above). Now that I upgraded again, problems
are back.

Since this is a fairly serious regression, I think it's fair to mark
this as release-critical (hence the severity change).

More details on the wifi adapter:

04:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188CE 
802.11b/g/n WiFi Adapter [10ec:8176] (rev 01)
Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:8195]
Physical Slot: 0
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at 2000 [size=256]
Memory at f010 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-91-81-fe-ff-4c-e0-00
Kernel driver in use: rtl8192ce

I'm of course available to debug any problems with this.

A.


-- 
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/87fva2o7cd@marcos.anarc.at

Bug#776816: firmware-realtek: fails to connect after a few suspends (or some uptime?)

2015-02-01 Thread Antoine Beaupré 
Package: firmware-realtek
Version: 0.43
Severity: normal

I started seeing this behavior after the upgrade from wheezy to jessie.
I am not sure it's directly related to the firmware, because I upgraded
it shortly before the upgrade. This is the history of upgrades, in
reverse order:

/var/log/dpkg.log.1:2014-12-30 17:35:43 upgrade firmware-realtek:all 
0.43~bpo70+1 0.43
/var/log/dpkg.log.1:2014-12-05 15:46:29 upgrade firmware-realtek:all 
0.41~bpo70+1 0.43~bpo70+1
/var/log/dpkg.log.10.gz:2014-03-23 20:14:57 upgrade firmware-realtek:all 
0.40~bpo70+1 0.41~bpo70+1
/var/log/dpkg.log.12.gz:2014-01-19 14:10:55 upgrade firmware-realtek:all 
0.39~bpo70+1 0.40~bpo70+1

It could also be the kernel's fault:

root@angela:/etc/ssh# grep linux-image /var/log/dpkg.log* | grep -v status
/var/log/dpkg.log:2015-01-23 15:59:56 remove linux-image-3.2.0-4-amd64:amd64 
3.2.63-2+deb7u2 aucune
/var/log/dpkg.log:2015-01-23 16:00:05 purge linux-image-3.2.0-4-amd64:amd64 
3.2.63-2+deb7u2 aucune
/var/log/dpkg.log.1:2014-12-09 15:35:48 upgrade linux-image-3.2.0-4-amd64:amd64 
3.2.63-2+deb7u1 3.2.63-2+deb7u2
/var/log/dpkg.log.1:2014-12-09 15:36:14 configure 
linux-image-3.2.0-4-amd64:amd64 3.2.63-2+deb7u2 none
/var/log/dpkg.log.1:2014-12-30 18:33:13 install 
linux-image-3.16.0-4-amd64:amd64 aucune 3.16.7-ckt2-1
/var/log/dpkg.log.1:2014-12-30 18:42:23 upgrade linux-image-amd64:amd64 3.2+46 
3.16+63
/var/log/dpkg.log.1:2014-12-30 18:53:07 configure 
linux-image-3.16.0-4-amd64:amd64 3.16.7-ckt2-1 aucune
/var/log/dpkg.log.1:2014-12-30 19:50:42 configure linux-image-amd64:amd64 
3.16+63 aucune

notice how that clever boy of yours uninstalled the previous kernel, making it
difficult to test the regression. i'll try to find one of those somewhere...

I believe the problem may have started in december. I recall having
similar issues in the past, but reloading the driver would always fix
it:

modprobe -r rtl8192ce
modprobe rtl8192ce

but now this doesn't work anymore. nothing short of a reboot can restore
proper wifi. this may be related to secure hotspots but since they are
so frequent nowadays it's hard to tell.

here's a typical failing NM chitchat:

Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0) starting 
connection 'CrapN6'
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0) Stage 1 
of 5 (Device Prepare) scheduled...
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0) Stage 1 
of 5 (Device Prepare) started...
Feb  1 22:44:24 angela NetworkManager[682]: info (wlan0): device state 
change: disconnected - prepare (reason 'none') [30 40 0]
Feb  1 22:44:24 angela NetworkManager[682]: info NetworkManager state is now 
CONNECTING
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0) Stage 2 
of 5 (Device Configure) scheduled...
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0) Stage 1 
of 5 (Device Prepare) complete.
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0) Stage 2 
of 5 (Device Configure) starting...
Feb  1 22:44:24 angela NetworkManager[682]: info (wlan0): device state 
change: prepare - config (reason 'none') [40 50 0]
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0/wireless): 
access point 'CrapN6' has security, but secrets are required.
Feb  1 22:44:24 angela NetworkManager[682]: info (wlan0): device state 
change: config - need-auth (reason 'none') [50 60 0]
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0) Stage 2 
of 5 (Device Configure) complete.
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0) Stage 1 
of 5 (Device Prepare) scheduled...
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0) Stage 1 
of 5 (Device Prepare) started...
Feb  1 22:44:24 angela NetworkManager[682]: info (wlan0): device state 
change: need-auth - prepare (reason 'none') [60 40 0]
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0) Stage 2 
of 5 (Device Configure) scheduled...
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0) Stage 1 
of 5 (Device Prepare) complete.
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0) Stage 2 
of 5 (Device Configure) starting...
Feb  1 22:44:24 angela NetworkManager[682]: info (wlan0): device state 
change: prepare - config (reason 'none') [40 50 0]
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0/wireless): 
connection 'CrapN6' has security, and secrets exist.  No new secrets needed.
Feb  1 22:44:24 angela NetworkManager[682]: info Config: added 'ssid' value 
'CrapN6'
Feb  1 22:44:24 angela NetworkManager[682]: info Config: added 'scan_ssid' 
value '1'
Feb  1 22:44:24 angela NetworkManager[682]: info Config: added 'key_mgmt' 
value 'WPA-PSK'
Feb  1 22:44:24 angela NetworkManager[682]: info Config: added 'auth_alg' 
value 'OPEN'
Feb  1 22:44:24 angela NetworkManager[682]: info Config: added 'psk' value 
'omitted'
Feb  1 22:44:24 angela NetworkManager[682]: info Activation (wlan0)

Bug#693942: linux-image-3.2.0-4-amd64: regression / high load confirmed after wheezy upgrade

2014-11-20 Thread Antoine Beaupré 
On 2014-11-20 13:23:03, Fran Rodríguez wrote:
 Hi,

 How about this?¿ is it solved?¿

Not that I know of.

A.

-- 
They say that time changes things, but you actually have to change
them yourself.   - Andy Warhol


pgpy9HDsXsGrf.pgp
Description: PGP signature

Bug#765309: fails to play video since at least 3.14

2014-10-15 Thread Antoine Beaupré 
Control: tag -1 -moreinfo
Control: fixed -1 3.16.5-1

On 2014-10-13 21:28:11, Ben Hutchings wrote:
 The latter seems to say that this is fixed in 3.16.4. This may be the fix:
 
 https://lkml.org/lkml/2014/6/18/712
 [...]

 So please test version 3.16.5-1 from unstable.

Ah. I missed that release in rmadison for some reason. I gotta say I
always get confused by the package names and versions.

I confirm that the bug isn't present in linux-image-3.16-3-amd64
3.16.5-1 anymore.

Thanks for the quick feedback,

A.

-- 
One of the things the Web teaches us is that everything is connected
(hyperlinks) and we all should work together (standards). Too often
school teaches us that everything is separate (many different
'subjects') and that we should all work alone.
 - Aaron Swartz


pgp5_I4eHCyY9.pgp
Description: PGP signature

Bug#765309: fails to play video since at least 3.14

2014-10-13 Thread Antoine Beaupré 
Package: src:linux
Version: 3.16.3-2
Severity: important

For a few weeks, I haven't been able to play any videos in jessie.

This happened during one of the latest upgrades, although it's hard for
me to pinpoint exactly when. I also doubt it's directly connected to a
xorg upgrade, since there was no significant change in the xorg packages
since then:

anarcat@marcos:log$ zgrep upgrade dpkg.log* | grep xorg:amd64
dpkg.log.6.gz:2014-04-15 23:32:26 upgrade xserver-xorg:amd64 1:7.7+6 1:7.7+7
dpkg.log.6.gz:2014-04-15 23:32:27 upgrade xorg:amd64 1:7.7+6 1:7.7+7
dpkg.log.8.gz:2014-02-21 00:03:38 upgrade xserver-xorg:amd64 1:7.7+5 1:7.7+6
dpkg.log.8.gz:2014-02-21 00:03:39 upgrade xorg:amd64 1:7.7+5 1:7.7+6
dpkg.log.9.gz:2014-02-02 23:55:08 upgrade xserver-xorg:amd64 1:7.7+3~deb7u1 
1:7.7+5
dpkg.log.9.gz:2014-02-02 23:55:09 upgrade xorg:amd64 1:7.7+3~deb7u1 1:7.7+5

However, I think one of those may be the cause:

anarcat@marcos:log$ zgrep linux-image dpkg.log* | grep  install 
dpkg.log.1:2014-09-08 14:49:13 install linux-image-3.14-2-amd64:amd64 aucune 
3.14.15-2
dpkg.log.1:2014-09-26 15:43:30 install linux-image-3.16-2-amd64:amd64 aucune 
3.16.3-2
dpkg.log.4.gz:2014-06-01 20:44:33 install linux-image-3.14-1-amd64:amd64 
aucun 3.14.4-1
dpkg.log.7.gz:2014-03-18 19:31:34 install linux-image-3.13-1-amd64:amd64 
aucun 3.13.5-1
dpkg.log.8.gz:2014-02-03 00:43:08 install linux-image-3.12-1-amd64:amd64 
aucun 3.12.6-2
dpkg.log.9.gz:2014-01-09 18:17:50 install linux-image-3.10-0.bpo.3-amd64:amd64 
aucun 3.10.11-1~bpo70+1
dpkg.log.9.gz:2014-01-09 18:43:17 install linux-image-3.10-0.bpo.3-amd64:amd64 
3.10.11-1~bpo70+1 3.10.11-1~bpo70+1

Specifically, I believe this started when i started running the 3.14
kernel, back in june (or maybe september! it's possible i didn't reboot
after the 3.14-1 install).

The symptom is that neither mpv, mplayer or vlc can play videos in a
graphical X session anymore. mplayer gives me those errors:

anarcat@marcos:stimulator$ mplayer ITE_116.mp4
MPlayer2 2.0-728-g2c378c7-3 (C) 2000-2012 MPlayer Team
Cannot open file '/home/anarcat/.mplayer/input.conf': No such file or directory
Failed to open /home/anarcat/.mplayer/input.conf.
Cannot open file '/etc/mplayer/input.conf': No such file or directory
Failed to open /etc/mplayer/input.conf.

Playing ITE_116.mp4.
Detected file format: QuickTime / MOV (libavformat)
[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (aac), -aid 0, -alang eng
Clip info:
 major_brand: mp42
 minor_version: 1
 compatible_brands: mp42mp41
 creation_time: 2012-07-30 01:25:05
Load subtitles in .
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object 
file: No such file or directory
[vdpau] Error when calling vdp_device_create_x11: 1
[ass] auto-open
Selected video codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [libavcodec]
Selected audio codec: AAC (Advanced Audio Coding) [libavcodec]
AUDIO: 48000 Hz, 2 ch, floatle, 160.0 kbit/5.21% (ratio: 2-384000)
AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample)
Starting playback...
VIDEO:  640x480  29.970 fps  1398.4 kbps (174.8 kB/s)
VO: [xv] 640x480 = 640x480 Planar YV12
A:  -0.0 V:   0.0 A-V: -0.001 ct:  0.000   0/  0 ??% ??% ??,?% 0 0
X11 error: BadAlloc (insufficient resources for operation)
A:   0.0 V:   0.0 A-V:  0.000 ct:  0.000   0/  0 ??% ??% ??,?% 0 0
X11 error: BadAlloc (insufficient resources for operation)

mpv fails similarly:

anarcat@marcos:stimulator$ mpv ITE_116.mp4
Playing: ITE_116.mp4
[stream] Video (+) --vid=1 (*) (h264)
[stream] Audio (+) --aid=1 --alang=eng (*) (aac)
File tags:
 major_brand: mp42
 minor_version: 1
 compatible_brands: mp42mp41
 creation_time: 2012-07-30 01:25:05
[vo/opengl] Missing OpenGL features: [NO_SW]
[vo/opengl] Rejecting suspected software OpenGL renderer.
[vo/opengl] OpenGL context creation failed!
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object 
file: No such file or directory
[vo/vdpau] Error when calling vdp_device_create_x11: 1
AO: [pulse] 48000Hz stereo 2ch float
VO: [xv] 640x480 = 640x480 yuv420p
[vo/xv/x11] X11 error: BadAlloc (insufficient resources for operation)
[vo/xv] X11 can't keep up! Waiting for XShm completion events...
AV: 00:00:00 / 00:14:54 (0%) A-V:  0.000
[vo/xv/x11] X11 error: BadAlloc (insufficient resources for operation)

VLC as well, but without significant debugging.

For some reason it seems that OpenGL got kicked out during some upgrade. And
this is where I am tempted to blame the kernel more than Xorg: neither the
intel xorg drivers or xorg has seen a significant upgrade since at least
february and I don't believe things have been broken for so long.

I suspect the problem may be related to this dmesg entry:

[   12.168038] [drm:init_ring_common] *ERROR* render ring initialization failed 
ctl 0001f001 (valid? 1) head a02c tail  start 00303000 [expected 
00303000]
[   12.168051] [drm:i915_gem_init] *ERROR* Failed to initialize GPU, declaring 
it wedged

This looks like:

Bug#765309: Acknowledgement (fails to play video since at least 3.14)

2014-10-13 Thread Antoine Beaupré 
Forgot to mention that things seem to work in XBMC, and using -vo x11 in
mplayer works around the issue, probably for similar reasons.

A.

-- 
L'art n'est pas un bureau d'anthropométrie.
- Léo Ferré, Préface


pgpoTMxg7LkFH.pgp
Description: PGP signature

Bug#693942: linux-image-3.2.0-4-amd64: regression / high load confirmed after wheezy upgrade

2013-10-19 Thread Antoine Beaupré 
Also, note that we have many Debian servers, and this one is the only
one (so far) affected by this problem. Here are dom0 xen servers that
had their load actually go *down* by a factor of two since their move to
wheezy:

http://stats.koumbit.net/koumbit.net/chypre.koumbit.net/load.html
http://stats.koumbit.net/koumbit.net/eros.koumbit.net/load.html
http://stats.koumbit.net/koumbit.net/artemis.koumbit.net/load.html

This server, however, had its load stable:

http://stats.koumbit.net/koumbit.net/cereales.koumbit.net/load.html

The only difference with that server is that it's using SSD drives, and
so is the server I previously mentionned in my report (ceres).

A.

-- 
Antoine Beaupré +++ Réseau Koumbit Networks +++ +1.514.387.6262 #208



pgpSTI_3RnqsS.pgp
Description: PGP signature

Bug#701744: fix also confirmed here

2013-07-10 Thread Antoine Beaupré 
We have two machines that are identical here. I had the bug reproduced
fairly reliably on both machines regularly, last week it happened
exactly at the same time.

I installed the squeeze4~ijc0 kernel on one of them this weekend, and
today only the one without the kernel failed.

In other words, the fix works. It would be nice if this would be
deployed through -security quickly, as this affects a lot of our
infrastructure.

A.
-- 
Le pouvoir n'est pas à conquérir, il est à détruire
- Jean-François Brient, de la servitude moderne


pgpj77gNcIBFY.pgp
Description: PGP signature

Bug#674907: severity

2012-10-01 Thread Antoine Beaupré 
On 2012-10-01, Mauro wrote:
 The shift time happens also in dom0 not only in domUs.

That is correct.

-- 
Le pouvoir n'est pas à conquérir, il est à détruire
- Jean-François Brient, de la servitude moderne


pgpfZEzl94epH.pgp
Description: PGP signature

Bug#645055: realtek 8188CE ad-hoc mode not supported

2011-10-12 Thread Antoine Beaupré 
On Wed, 12 Oct 2011 14:08:32 +0100, Ben Hutchings b...@decadent.org.uk wrote:
 Can you create an ad-hoc interface like this:
 
 iw dev wlan0 interface add wlan1 type adhoc
 
 (you'll need the iw package).

Interesting - this works. Didn't know of the iw tool. But this creates a
separate interface, kind of odd!

The adhoc mode works like that. I am not sure I understand why it
doesn't work with iwconfig, can you enlighten me?

Thanks!

-- 
L'art n'est pas un bureau d'anthropométrie.
- Léo Ferré, Préface


pgp3eoZBwKYa7.pgp
Description: PGP signature

Bug#645055: realtek 8188CE ad-hoc mode not supported

2011-10-12 Thread Antoine Beaupré 
On Thu, 13 Oct 2011 00:24:12 +0100, Ben Hutchings b...@decadent.org.uk wrote:
 I looked a little further and saw that nl80211 does support changing
 interface type (mode).  But this driver (rtl8192ce) only supports
 creating new interfaces, not changing their type.
 
 Should mac80211 drivers generally support changing interface type
 (change_interface operation)?

Seems to me really counter-intuitive that it didn't work. It was the
first time I ever see such a problem.

I have seen numerous drivers not support Master or Monitor mode,
because of limitations of the implementation or the hardware, but if
this is purely a API problem, it seems like a problem that should be
fixed...

Is this the right place though?

A.
-- 
The idea that Bill Gates has appeared like a knight in shining armour to
lead all customers out of a mire of technological chaos neatly ignores
the fact that it was he who, by peddling second-rate technology, led
them into it in the first place. - Douglas Adams (1952-2001)


pgpBs94vlwEjh.pgp
Description: PGP signature

Bug#645055: realtek 8188CE ad-hoc mode not supported

2011-10-12 Thread Antoine Beaupré 
On Thu, 13 Oct 2011 03:25:17 +0100, Ben Hutchings b...@decadent.org.uk wrote:
  but the 
  iw interface changes the mode for an existing interface when using 
  rtl8192ce.
  
  BTW, I added a new iface because I did not want to interrupt my
  internat connection.
 
 Hmm.  Maybe the change_interface operation is only needed to change
 type/mode while the interface is up.
 
 Antoine, did you bring the interface down before setting its mode?

Crap. No, I didn't. And now it works if I bring it down first. Oh well,
I guess I just made a lot of noise for nothing, this bug can be closed,
thank you!

A.

-- 
Travail, du latin Tri Palium trois pieux, instrument de torture.


pgps1pnD2TlEW.pgp
Description: PGP signature

Bug#645055: realtek 8188CE ad-hoc mode not supported

2011-10-11 Thread Antoine Beaupré 
Package: linux-2.6
Version: 2.6.39-3~bpo60+1
Severity: normal
Tags: upstream

Hi,

The documentation for the rtl8192ce driver explicitely mentions that
it supports ad-hoc mode, yet, on the rtl8188CE card I have here (which
is advertised as supported both by the upstream driver and the driver
in the linux source), the ad-hoc mode yields this error:

root@angela:/home/anarcat# iwconfig wlan0 mode Ad-hoc essid foo
Error for wireless request Set Mode (8B06) :
SET failed on device wlan0 ; Device or resource busy.

I have tried changing the case of the ad-hoc word and various
spellings, nothing works there. I have also tried the upstream driver
available here:

http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PFid=48Level=5Conn=4ProdID=278DownTypeID=3GetDown=falseDownloads=true

without any more luck, which means this is a problem with upstream (or
with the card not supporting ad-hoc mode at all, although that would
be very surprising).

-- Package-specific info:
** Version:
Linux version 2.6.39-bpo.2-686-pae (Debian 2.6.39-3~bpo60+1) 
(norb...@tretkowski.de) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Thu Aug 4 
11:02:22 UTC 2011

** Command line:
BOOT_IMAGE=/vmlinuz-2.6.39-bpo.2-686-pae root=/dev/mapper/angela-root ro quiet

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Model information
not available

** Loaded modules:
Module  Size  Used by
rtl8192ce 123507  0 
rtlwifi96056  1 rtl8192ce
mac80211  164606  2 rtl8192ce,rtlwifi
cfg80211  107076  2 rtlwifi,mac80211
parport_pc 21895  0 
ppdev  12621  0 
lp 12858  0 
parport27018  3 parport_pc,ppdev,lp
mperf  12387  0 
cpufreq_conservative12987  0 
cpufreq_stats  12711  0 
cpufreq_userspace  12520  0 
cpufreq_powersave  12422  0 
bridge 59217  0 
stp12368  1 bridge
bnep   17147  2 
rfcomm 31961  4 
binfmt_misc12778  1 
uinput 12984  1 
fuse   55666  1 
radeon712182  2 
ttm46736  1 radeon
drm_kms_helper 26550  1 radeon
drm   129190  3 radeon,ttm,drm_kms_helper
btusb  17209  0 
bluetooth  92361  11 bnep,rfcomm,btusb
crc16  12327  1 bluetooth
i2c_algo_bit   12706  1 radeon
joydev 16906  0 
snd_hda_codec_conexant35673  1 
snd_hda_codec_hdmi 21870  1 
snd_hda_intel  21529  0 
snd_hda_codec  57741  3 
snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel
snd_hwdep  12906  1 snd_hda_codec
snd_pcm_oss35864  0 
snd_mixer_oss  17649  1 snd_pcm_oss
snd_pcm52731  4 
snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_seq_midi   12744  0 
snd_rawmidi22407  1 snd_seq_midi
snd_seq_midi_event 13124  1 snd_seq_midi
arc4   12418  2 
ecb12649  2 
snd_seq39172  2 snd_seq_midi,snd_seq_midi_event
snd_timer  22171  2 snd_pcm,snd_seq
rtl8192c_common43386  0 
uvcvideo   52490  0 
snd_seq_device 12995  3 snd_seq_midi,snd_rawmidi,snd_seq
thinkpad_acpi  46976  0 
videodev   61226  1 uvcvideo
nvram  12853  1 thinkpad_acpi
tpm_tis12949  0 
snd38189  13 
snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device,thinkpad_acpi
tpm17476  1 tpm_tis
ac 12552  0 
evdev  17180  28 
media  13692  1 videodev
video  17345  0 
battery12957  0 
tpm_bios   12799  1 tpm
psmouse45863  0 
power_supply   13283  3 radeon,ac,battery
serio_raw  12758  0 
wmi13018  0 
rfkill 18510  5 cfg80211,bluetooth,thinkpad_acpi
button 12783  0 
i2c_piix4  12480  0 
pcspkr 12515  0 
processor  26983  2 
i2c_core   19022  6 
radeon,drm_kms_helper,drm,i2c_algo_bit,videodev,i2c_piix4
k10temp12539  0 
soundcore  12878  1 snd
snd_page_alloc 12841  2 snd_hda_intel,snd_pcm
ext3  102125  4 
jbd40818  1 ext3
mbcache12810  1 ext3
sha256_generic 16709  2 
cryptd 14071  0 
aes_i586   16608  4 
aes_generic37066  1 aes_i586
cbc12659  2 
dm_crypt   17809  1 
raid10 25831  0 
raid45651462  0 
async_raid6_recov  12459  1 raid456
async_pq   12503  2 raid456,async_raid6_recov

Bug#597664: linux-image-2.6.32-5-686: Xorg crashes with radeon kernel messages

2011-10-03 Thread Antoine Beaupré 
On Wed, 31 Aug 2011 02:47:18 -0500, Jonathan Nieder jrnie...@gmail.com wrote:
 Because it's been so long, I also should ask:
 
  - can you still reproduce this with recent sid and squeeze kernels?

No, as the hardware is offline.

  - any ideas, weird symptoms, or workarounds discovered since then?
How have you been coping in the meantime?

I have gotten rid of that device. I may rebuild it at some point, and
I'll get back to you if I can! :)

A.

-- 
Le monochrome, c'est pour ceux qui s'intéressent (encore) au contenu.
Usenet dans ces conditions, c'est comme le web avec lynx, on prend
trop conscience du vide, c'est déprimant.
- JLC dans le Guide du linuxien pervers:
  Coup de cafard...


pgpugkAJt3QCn.pgp
Description: PGP signature