Re: Request: Enable Symbols for Lenovo Thinkpad P14s Gen4 (AMD)

[Bjørn Mork]

Salvatore Bonaccorso  writes:
> On Mon, Dec 11, 2023 at 06:36:39PM -0500, Michael T. Kloos wrote:
>
>> Copy that.
>
> Michael, sorry I lost you. What do you mean?

That's an ack from before packet radio :-)
https://en.wiktionary.org/wiki/copy_that



Bjørn

Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message

[Bjørn Mork]

Salvatore Bonaccorso  writes:

> AFAIK there is no commit upstream with fixes tag on that commit. But
> Bjorn suspects that might be the suspicious commit introducing the
> issue.

Yes, I noticed that, so I could very well be wrong...

But it stood out as the only change to any x86 IOAPIC stuff
since Linux 6.1.0-6-amd64.  That's of course not any guarantee.  But
worth testing.



Bjørn

Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message

[Bjørn Mork]

Guy Durrieu  writes:

> 
> [ 0.117782] Kernel panic — not syncing: timer doesn’t work through
> Interrupt-
> remapped I0-APIC
> [ 0.117848] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-7-and64 #1
> Debian
> 6.1.20-1
> [ 0.117913] Hardware name: Gigabyte Technology Co., Ltd. ABS50M-Gaming
> 3/AB350M-Gaming 3-CF, BIOS F50d 07/02/2020
> [ 0.117982] Call Trace:
> [ 0.118634] 
> [ 0.118685] dump_stack_lvl+0x44/0x5c
> [ 0.118143] panic+0x118/0x2ed
> [ 0.118198] panic_if_irq_remap.cold+0x5/0x5
> [ 0.118256] setup_I0_APIC+0x3db/0x64b
> [ 0.118313] ? _raw_spin_unlock_irqrestore+0x23/0x40
> [ 0.118372] ? clear_IO_APIC_pin+0x169/0x240
> [ 0.118429] apic_intr_node_init+0x101/0x106
> [ 0.118485] x86_late_time_init+0x20/0x34
> [ 0.118542] start_kerne1+0x667/0x727
> [ 0.118598] secondary_startup_64_no_verify+0xe5/0xeb
> [ 0.118658] 
> [ 0.118711] ---[ end Kernel panic - not syncing: timer doesn’t work through
> Interrupt-remapped IO-APIC J---
> 

Extremely suspiscious commit in the v6.1.15..v6.1.20 update:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?id=ce7d894bed1a539a8d6cff42f6f78f9db0c9c26b



Bjørn

Bug#1022022: New btusb hardware IDs (MT7922, MT7921, others)

[Bjørn Mork]

Chris Hofstaedtler  writes:
> * Diederik de Haas  [221019 00:07]:
>> On dinsdag 18 oktober 2022 23:44:17 CEST Chris Hofstaedtler wrote:
>> > it appears quite some new btusb hardware was released recently.
>> > linux-next has a lot of simple "Add xyz ID" patches for btusb.c:
>> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/driv
>> > ers/bluetooth/btusb.c
>> > 
>> > Please consider applying 57117d7234dadfba2a83615b2a9369f6f2f9914f
>> > and/or the other patches adding new hwids to btusb.c for the
>> > bookworm kernel.
>> 
>> It's already part of Linux 6.1-rc1 and it is expected that 6.1 will be the
>> next LTS release and I'd guess thus also the Bookworm kernel.
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/bluetooth?h=v6.1-rc1
>
> Right, that'd be good. I've manually applied
> 57117d7234dadfba2a83615b2a9369f6f2f9914f against 5.9.11-1, and that
> works for me; but only after making available
> BT_RAM_CODE_MT7922_1_1_hdr.bin from linux-firmware.git.

If this is a simple device ID addition without any other dependencies,
then it qualifies for Linux stable.  And you'll get it in Debian stable
for free.

New device ID patches are regularily backported to the maintained stable
kernels, and usually picked up automatically by the stable maintainers.
You can request a backport of a specific commit in mainline by sending
an email to sta...@vger.kernel.org

See https://docs.kernel.org/process/stable-kernel-rules.html


Bjørn

Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.

[Bjørn Mork]

Hank Barta  writes:

> ** Kernel log:
> [  723.735217] mmc0: sdhci: Timeout:   0x | Int stat: 0x00018000
> [  723.741743] mmc0: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
> [  723.748270] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001
> [  723.754797] mmc0: sdhci: Caps:  0x45ee6432 | Caps_1:   0xa525
> [  723.761324] mmc0: sdhci: Cmd:   0x0502 | Max curr: 0x00080008
> [  723.767851] mmc0: sdhci: Resp[0]:   0x01aa | Resp[1]:  0x
> [  723.774379] mmc0: sdhci: Resp[2]:   0x | Resp[3]:  0x
> [  723.780905] mmc0: sdhci: Host ctl2: 0x
> [  723.785404] mmc0: sdhci: ADMA Err:  0x | ADMA Ptr: 0x
> [  723.791930] mmc0: sdhci: 
> [  733.923993] mmc0: Timeout waiting for hardware cmd interrupt.

These repeated messages are normal on the RPi4 if you boot it without an
SD card.  E.g. from USB or network.  If that's what you intend to do,
then you can avoid the repeated messages by adding

 dtparam=sd_poll_once=on

to the config.txt file in your firmware partition.  Often mounted as
/boot/firmware/.

The effect depends on which device-tree you are using.  I believe it
will only work with the ones coming with the Raspberry Pi firmware.  See

https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README

for docs.


Bjørn

Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)

[Bjørn Mork]

Cyril Brulebois  writes:

> Cyril Brulebois  (2022-04-29):
>> > I'll try and pinpoint when it broke using the various intermediary
>> > versions:
>> > 
>> >  - 5.17~rc3-1~exp1
>> 
>> The first attempt was sufficient: it breaks as early as that version.
>
> Using the same base image as before, and only updating the kernel: I've
> tested upstream builds, starting from the .config found in the Debian
> 5.16.18-1 package, using oldconfig and accepting everything by default:
>
>  - v5.16 is confirmed a first good;
>  - v5.17-rc1 is confirmed a first bad;
>  - the culprit seems to be 3ceff4ea07410763d5d4cccd60349bf7691e7e61

But that's a merge commit. Not likely the real cuplrit, unless there's a
merge bug.

I looked briefly at what was merged there, and I believe this commit
stands out as suspicious:

bjorn@miraculix:/usr/local/src/git/linux$ git show f59f6aaead97
commit f59f6aaead975f0ec4d8ff2d59c4ffb8cf0127b2
Author: Arnd Bergmann 
Date:   Mon Nov 22 23:21:56 2021 +0100

mmc: bcm2835: stop setting chan_config->slave_id

The field is not interpreted by the DMA engine driver, as all the data
is passed from devicetree instead. Remove the assignment so the field
can eventually be deleted.

Reviewed-by: Nicolas Saenz Julienne 
Signed-off-by: Arnd Bergmann 
Acked-by: Ulf Hansson 
Acked-by: Mark Brown 
Link: https://lore.kernel.org/r/2021112203.4103644-5-a...@kernel.org
Signed-off-by: Vinod Koul 

diff --git a/drivers/mmc/host/bcm2835.c b/drivers/mmc/host/bcm2835.c
index 8c2361e66277..463b707d9e99 100644
--- a/drivers/mmc/host/bcm2835.c
+++ b/drivers/mmc/host/bcm2835.c
@@ -1293,14 +1293,12 @@ static int bcm2835_add_host(struct bcm2835_host *host)
 
host->dma_cfg_tx.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
host->dma_cfg_tx.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-   host->dma_cfg_tx.slave_id = 13; /* DREQ channel */
host->dma_cfg_tx.direction = DMA_MEM_TO_DEV;
host->dma_cfg_tx.src_addr = 0;
host->dma_cfg_tx.dst_addr = host->phys_addr + SDDATA;
 
host->dma_cfg_rx.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
host->dma_cfg_rx.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-   host->dma_cfg_rx.slave_id = 13; /* DREQ channel */
host->dma_cfg_rx.direction = DMA_DEV_TO_MEM;
host->dma_cfg_rx.src_addr = host->phys_addr + SDDATA;
host->dma_cfg_rx.dst_addr = 0;


But I'm basing that only on it being related to the bcm28/27xx SoCs and
a bit unexpected in the sound merge...  I cannot explain why this mmc
host driver change should affect your display.  Could be completely
wrong.  But migt be worth testing?



Bjørn

Re: Problem: USB Ethernet PCI-E card does not work with kernel 5.10.0-11-amd64

[Bjørn Mork]

Flacusbigotis  writes:

> The kernel logs indicating issues in Bullseye include a warning of a "host
> failure" by xhci_hcd, and several write/read errors by the ax88179 ethernet
> driver/module for the card, as follows:
>
> Feb 22 17:22:53 server1 kernel: [1.380198] xhci_hcd :1c:00.0: xHCI
> Host Controller
> Feb 22 17:22:53 server1 kernel: [1.380205] xhci_hcd :1c:00.0: new
> USB bus registered, assigned bus number 5
> Feb 22 17:22:53 server1 kernel: [1.380209] xhci_hcd :1c:00.0: Host
> supports USB 3.0 SuperSpeed
> Feb 22 17:22:53 server1 kernel: [1.380260] usb usb5: New USB device
> found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.10
> Feb 22 17:22:53 server1 kernel: [1.380261] usb usb5: New USB device
> strings: Mfr=3, Product=2, SerialNumber=1
> Feb 22 17:22:53 server1 kernel: [1.380263] usb usb5: Product: xHCI Host
> Controller
> Feb 22 17:22:53 server1 kernel: [1.380264] usb usb5: Manufacturer:
> Linux 5.10.0-11-amd64 xhci-hcd
> Feb 22 17:22:53 server1 kernel: [1.380265] usb usb5: SerialNumber:
> :1c:00.0
> Feb 22 17:22:53 server1 kernel: [1.380396] hub 5-0:1.0: USB hub found
> Feb 22 17:22:53 server1 kernel: [1.380411] hub 5-0:1.0: 4 ports detected
> Feb 22 17:22:53 server1 kernel: [5.508457] ax88179_178a 5-1:1.0 eth0:
> register 'ax88179_178a' at usb-:1c:00.0-1, ASIX AX88179 USB 3.0 Gigabit
> Ethernet, 00:11:22:33:44:55
> Feb 22 17:23:25 server1 kernel: [   39.576966] xhci_hcd :1c:00.0:
> WARNING: Host System Error
> Feb 22 17:26:00 server1 kernel: [  194.596335] ax88179_178a 5-1:1.0
> enx001122334455: Failed to read reg index 0x0002: -22

I am guessing that the random mac address is a symptom caused by a
failure to read the permanent mac from the USB ethernet
controller. Which again probably is caused by one or more of these read
errors.

But I believe those are only symptoms, and that the real error is that
unspecified "Host System Error".

I wonder is this could be related to some of the quirks that have been
added for this xhci controller since v4.19?  There have been a few since
the VL805 is used in the RPi4. Some of these might very well be
misunderstood and RPI related only.  There is also an odd code path in
drivers/usb/host/pci-quirks.c where we select a different path on RPi
than on other systems because "things are taken care of by the board's
co-processor".  I find that very suspiscious.

And I must admit that my interest in this bug is because I'm worried
that the quirk I recently pushed could have unexpected side effects...
I have no clue.

but the most likely cause is some power managenment issue.  Test
disabling ASPM e.g. by adding pcie_aspm=off  to the kernel command line.

Or disabling USB autosuspend, e.g by adding usbcore.autosuspend=-1  to the
kernel command line.

I do NOT suggest that you run with those settings by default.  Only
testing to try to narrow down the problem.

It would also be intersting to know if removing the XHCI_LPM_SUPPORT
quirk would make a difference, since this was added to the VL805 between
v4.19 and v5.10 without anyone really knowing if it works..  But I can't
figure out how to disable a device specific quirk like that without
patching the kernel.  Anyone?



Bjørn

Bug#1002465: /boot/vmlinuz-5.10.0-10-amd64: btusb: CSR clone fails with "debugfs: File 'dut_mode' in directory 'hci1' already present!"

[Bjørn Mork]

Package: src:linux
Version: 5.10.84-1
Severity: normal
File: /boot/vmlinuz-5.10.0-10-amd64

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Just got a couple of CSR clones of a type I haven't tried before.  Unfortunately
they fail with  the error message:

  "debugfs: File 'dut_mode' in directory 'hci1' already present!"

Kernel log after plugging in:

usb 1-1: new high-speed USB device number 7 using xhci_hcd
usb 1-1: New USB device found, idVendor=0fce, idProduct=31f4, bcdDevice= 4.04
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: G8441
usb 1-1: Manufacturer: Sony
usb 1-1: SerialNumber: BH901MPJ9E
usb 1-1: USB disconnect, device number 7
usb 1-1: new high-speed USB device number 8 using xhci_hcd
usb 1-1: New USB device found, idVendor=0fce, idProduct=51f4, bcdDevice= 4.04
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: G8441
usb 1-1: Manufacturer: Sony
usb 1-1: SerialNumber: BH901MPJ9E
usb 1-1: USB disconnect, device number 8
8021q: adding VLAN 0 to HW filter on device wwan0
input: WH-1000XM4 (AVRCP) as /devices/virtual/input/input29
usb 1-3: new full-speed USB device number 9 using xhci_hcd
usb 1-3: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
usb 1-3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
usb 1-3: Product: BT DONGLE10
Bluetooth: hci1: CSR: Unbranded CSR clone detected; adding workarounds...

Controller shows up:

root@miraculix:/tmp# hciconfig hci1
hci1:   Type: Primary  Bus: USB
BD Address: 00:1A:7D:DA:71:13  ACL MTU: 679:8  SCO MTU: 48:16
DOWN 
RX bytes:734 acl:0 sco:0 events:24 errors:0
TX bytes:74 acl:0 sco:0 commands:24 errors:0

But trying to bring it up results in:

root@miraculix:/tmp# hciconfig hci1 up
Can't init device hci1: Invalid argument (22)


and the workaround messages is repeated in the kernel log along with the
new error message:

 Bluetooth: hci1: CSR: Unbranded CSR clone detected; adding workarounds...
 debugfs: File 'dut_mode' in directory 'hci1' already present!

The debugfs file *is* already present prior to this. Trying to trick the
system by unmounting debugfs does not help - as expected, I guess.  The
duplicate file registration is still running.

Looks like the adapter initialisation is running twice for some reason?

This is the full lsusb -v dump for this device:



Bus 001 Device 009: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle 
(HCI mode)
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  224 Wireless
  bDeviceSubClass 1 Radio Frequency
  bDeviceProtocol 1 Bluetooth
  bMaxPacketSize064
  idVendor   0x0a12 Cambridge Silicon Radio, Ltd
  idProduct  0x0001 Bluetooth Dongle (HCI mode)
  bcdDevice   88.91
  iManufacturer   0 
  iProduct2 BT DONGLE10
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x00b1
bNumInterfaces  2
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   224 Wireless
  bInterfaceSubClass  1 Radio Frequency
  bInterfaceProtocol  1 Bluetooth
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   224 

Re: Bug#983332: sane-utils: incorrectly identifies Wifi USB dongles as scanners

[Bjørn Mork]

Martin-Éric Racine  writes:

>> [1] https://wiki.debian.org/DeviceDatabase/USB

YUCK!

That is fundamentally flawed. It is so misleading that it is harmful.
Could someone with Wiki access pleaase delete that page?



Bjørn

Bug#990868: lenovo T460 Shutdown Problem

[Bjørn Mork]

Faustin Lammler  writes:

> Hi!
> I seem to have the same problem on my T460s and it is impossible to
> suspend the laptop (lid close or systemctl suspend).
>
> As far as I can remember, the problem appeared with kernel 5 branch (bpo
> on buster).
>
> At that time I did not wanted to open a bug report because I was not
> sure of my installation (dist-upgrade from buster, plus lots of bpo
> kernel installation and test) and I had found a workaround for the
> suspend problem, using those commands after reboot:
> | echo reboot >/sys/power/disk
> | echo disk >/sys/power/state
>
> Now I have a clean Debian 11 installation and both suspend and poweroff
> does not work anymore.

This sounds like https://bugs.debian.org/949020

Short version: Disable TPM 2.0 (select 1.2) i BIOS, or disable IOMMU by
booting with intel_iommu=off on the command line.


Bjørn

Re: Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002

[Bjørn Mork]

Heiner Kallweit  writes:

> A number of Gigabyte boards from ~2009 have broken BIOS support, resulting in 
> the PHY
> reporting an invalid PHY ID. Realtek / Gigabyte don't release errata 
> information,
> therefore there's not much that can be done. In bugzilla.kernel.org you can 
> find
> workarounds that helped for some users, else use the r8168 driver.

Why can't we add a quirk for the invalid IDs?  Are they variable or just
too many?  Or colliding with some real PHY ID in use?  If not, then I
don't see why this problem can't be solved.

Yes, yes, stealing IDs is bad.  But our priority is making hardware work
despite buggy firmware.  And ALL firmware is buggy.  After all, it's
just software in a straitjacket.



Bjørn

Bug#965074: Patches to make multicast proccesing on CDC NCM drivers

[Bjørn Mork]

Santiago Ruano Rincón  writes:
> El 02/09/20 a las 17:45, Greg KH escribió:
>> On Wed, Sep 02, 2020 at 03:27:28PM +0200, Santiago Ruano Rincón wrote:
>>
>> > This:
>> > 
>> > 37a2ebdd9e597ae1a0270ac747883ea8f6f767b6
>> > e10dcb1b6ba714243ad5a35a11b91cc14103a9a9
>> > e506addeff844237d60545ef4f6141de21471caf
>> > 0226009ce0f6089f9b31211f7a2703cf9a327a01
>> 
>> These do not look like bugfixes, but a new feature being added for this
>> driver.  So why not just use a newer kernel version for this feature?
>
> From my point of view as user these are bugfixes, since IPv6 NDP or any
> other protocol relying on multicast do not work without them. In other
> words, my computer's networking is broken.

I was in doubt when I submitted these, but ended up specfying net-next
instead of net+stable as the target for a reason.  This is a new feature
as Greg says. Even if the feature is essential for your use case, it is
still new. "Has never been supported" isn't really a bug.

And I am still convinced that my decision was correct.  The patches are
a bit more intrusive than I'd be comfortable submitting to stable, as
was demonstrated by the stupid build bug I added... Fixed by commit
5fd99b5d9950 ("net: cdc_ncm: Fix build error") BTW.

> I want to have them in linux stable releases because that would make
> easier to include them in Debian stable release.

This has not been an absolute requirement in the past. Distros tend to
have a more relaxed stable policy.

Using a newer kernel until Debian moves on is obviously also an option.



Bjørn

Bug#969365: USB-C dock lacks multicast Ethernet functionality (so IPv6 is broken)

[Bjørn Mork]

"Santiago R.R."  writes:

> The patches proposed by Miguel Rodríguez have been merged upstream, and
> are part of 5.9-rc1 now. C.f. commits:
> 37a2ebdd9e597ae1a0270ac747883ea8f6f767b6
> e10dcb1b6ba714243ad5a35a11b91cc14103a9a9
> e506addeff844237d60545ef4f6141de21471caf
> 0226009ce0f6089f9b31211f7a2703cf9a327a01

Note that

 5fd99b5d9950 ("net: cdc_ncm: Fix build error")

should be included in this series for completeness.

It won't make any difference with the default Debian configuration,
where cdc_ether always is enabled, but it was an unfortunate glitch on
my side.


Bjørn

Bug#965074: cdc_ncm: ethernet multicast traffic is filtered out

[Bjørn Mork]

FWIW, I made an attempt resubmitting these patches since it looked like
I was part of the problem back in 2018 ;-)

I'd CCed you, and would appreciate it if you could test the series.  I
don't have any cdc_ncm devices with multicast filter support AFAIK.


Bjørn

Bug#964480: linux: ath9k (USB) broken in upstresm linux 5.7.3 after commit 6602f080cb

[Bjørn Mork]

Juergen  writes:

> In 5.7 reverting 6602f080cb is known to fix the problem, but it hasn't yet 
> been
> analyzed by an expert, therefore I'd like to report my findings to perhaps get
> an expert interested:-)
>
> At least one problem is in function ath9k_hif_usb_reg_in_cb(). In the call to
> usb_fill_int_urb() it should be rx_buf instead of nskb as penultimate
> parameter.

Yes, that's an obvious killer bug.  That patch should definitely be
reverted, and replaced with a proper and tested fix.

IMHO, it would be much safer and simpler to validate the expected
descriptors when probing these devices instead of allocating new helper
structs and making changes all over the place.  There is no reason to
add support for the syzbot simulated device.  Returning -ENODEV on probe
is fine, and is much less likely to add new and critical bugs.

And it's not like the fix actually took care of all the hard coded well
known descriptor values in this driver anyway.  We still have stuff like

 usb_sndintpipe(hif_dev->udev, USB_REG_OUT_PIPE)

and

 usb_sndbulkpipe(hif_dev->udev, USB_WLAN_TX_PIPE)

These will not crash the driver, but are still solid indications that
the driver is written for a very specific USB device configuration.  It
will not work with arbitrary descriptors.

I assume the "0" interface is just as fixed as those endpoints, so that
simply validating the values in ath9k_hif_usb_probe() is a perfectly
fine and safe solution.  Without the need to mess up the rest of the
driver.



Bjørn

Bug#949020: linux-image-5.6.0-2-amd64: Lenovo poweroff/suspend failure

[Bjørn Mork]

Package: src:linux
Followup-For: Bug #949020

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Just confirming that this issue is still present, causing a terrible
user experience when upgrading from Buster to Bullseye on a Lenovo
laptop. Verified on a 4th Gen Thinkpad X1 Carbon.

Setting intel_iommu=off is confirmed as workaround.

I understand from the upstream discussion that this is mostly a
Lenovo firmware issue.  But I still believe something needs to be
done in Debian to avoid every Lenovo user having to discover this
bug report and implement the workaround manually.  After first
experiencing a complete system failure when trying to suspend 
the system.  A feature which worked without a flaw on Debian
Buster.


- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (700, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iIQEARYKACwWIQRoe+CASfFh7aZ6shIiBE7Lv6RhXQUCXvSVXQ4cYmpvcm5AbW9y
ay5ubwAKCRAiBE7Lv6RhXd/GAQCIsozUqKlBr9BkIXoOXp7lFk9WouEh0QSYMm1F
oqluMwEA34mOpMqJL7bZWRAydIEctD1rWSAg7r1kpPAel1IwxAc=
=hTTU
-END PGP SIGNATURE-

Bug#961459: linux-signed-arm64: option that might support raspberry pi 4 usb

[Bjørn Mork]

Rob Browning  writes:

> If I get a chance and figure out how, I can try to build a local kernel
> with that option and test it, or I could fairly quickly test any version
> uploaded somewhere like experimental.

I have done this, and verified that the USB ports work if
CONFIG_PCIE_BRCMSTB is enabled.  See

https://bugs.debian.org/960129



Bjørn

Bug#961130: ethtool can read DOM values

[Bjørn Mork]

Ben Hutchings  writes:
> On Wed, 2020-05-20 at 13:09 +, Yannis Aribaud wrote:
>> Package: ethtool
>> Version: 1:4.19-1
>> Severity: important
>> The command ethtool -m  is unable to read the transceiver DOM values.
>
> Again, this is a driver or hardware issue, not a bug in ethtool.
>
> [...]
>> As you can see all mesuring values are zeros.
>> I am using Debian GNU/Linux 10 (buster), kernel 4.19.0-9-amd64 #1 SMP
>> Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux and libc6 2.28-10
>> 
>> FYI, I get correct values using SystemRescueCD 6 (ethtool 5.0, kernel
>> 4.19.34-1-lts) on this same hardware, using the same command.
>
> I see no changes to ethtool between 4.19 and 5.0 that would explain
> that.

I assume you're aware of this, but there are some interesting changes in
that driver between v4.19.34 and v4.19.118

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=7da11d6a5d85ab3f4d28fa660d8c90566fdaa1e6
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=935f39807a7e95678e5bda50757af326691a211c


The net effect seems to be that they removed the part that actually made
DOM reading work. Makes me wonder what happens if you revert both those
patches?  I don't have the hardware, so I can't test..

This issue might also be fixed in mainline with the more generic high
page support for QSFP28 and QSFP+?


Bjørn

Bug#960702: ethtool -m values change when output is redirected

[Bjørn Mork]

"Yannis Aribaud"  writes:

> Package: ethtool
> Version: 1:4.19-1
> Severity: important
> I'm facing a very strange behavior. The command ethtool -m  report the 
> transceiver DOM values correctly, but when the command output is redirected 
> to an other program, values change to somthing else.

AFAICS, your SFP+ is reporting strange values in either case.  I do not
think any of these are correct.  Looking at the non-redirected one:

>  Laser output power : 3.0768 mW / 4.88 dBm

This is insanely high.

>  Receiver signal average optical power : 1.2298 mW / 0.90 dBm
>  Module temperature : 48.47 degrees C / 119.24 degrees F
>  Module voltage : 1.2336 V

Should be 3.3 V

>  Laser bias current high alarm threshold : 4.744 mA
>  Laser bias current low alarm threshold : 49.896 mA

Right...

>  Laser output power high alarm threshold : 2.5701 mW / 4.10 dBm

I don't think this can be trusted either, but I do note that it is lower
than your current output.

>  Laser output power low alarm threshold : 0.8224 mW / -0.85 dBm
>  Laser output power high warning threshold : 0.8224 mW / -0.85 dBm
>  Laser output power low warning threshold : 0.8224 mW / -0.85 dBm

Strange limits.  There are too many -0.85 dBm values here.

>  Module temperature high alarm threshold : 0.00 degrees C / 32.00 degrees F
>  Module temperature low alarm threshold : 0.00 degrees C / 32.00 degrees F
>  Module temperature high warning threshold : 0.00 degrees C / 32.00 degrees F
>  Module temperature low warning threshold : 0.00 degrees C / 32.00 degrees F

Makes no sense at all.

>  Module voltage high alarm threshold : 0.4356 V
>  Module voltage low alarm threshold : 0. V
>  Module voltage high warning threshold : 0. V
>  Module voltage low warning threshold : 0. V

Makes even less sense.  


>  Laser rx power high alarm threshold : 0.8224 mW / -0.85 dBm
>  Laser rx power low alarm threshold : 0.8224 mW / -0.85 dBm
>  Laser rx power high warning threshold : 0.8224 mW / -0.85 dBm
>  Laser rx power low warning threshold : 0.8224 mW / -0.85 dBm

...



To me it looks like you are just reading arbitrary numbers from the
SFP+.  Try replacing it and see if the results are more reliable.



Bjørn

Bug#960129: linux-image-5.6.0-1-arm64: please enable CONFIG_PCIE_BRCMSTB in the arm64 kernel for Raspberry Pi 4

[Bjørn Mork]

Bjørn Mork  writes:

> Note that I found that I had to remove the cma=xx option raspi-firmware
> wants to put into the cmdline.txt.  This messed up mailbox access to the
> firmware, and took several drivers/devices with it in the fall.  Don't
> think the SD card was one one them.  But still worth trying.  Makes the
> sound driver load at least, and allows vcgencmd to talk to the firmware.


Sorry about all the mails.. Should have tested this myself before
sending the previous one.

I do believe this is the problem. I just tested with 'cma=64M' on the
command line, like raspi-firmware wants to put there, and it fails to
load the mmc driver too:


[0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
[0.00] Linux version 5.6.0-1-arm64 (debian-kernel@lists.debian.org) 
(gcc version 9.3.0 (Debian 9.3.0-11)) #1 SMP Debian 5.6.7-1 (2020-04-29)
[0.00] Machine model: Raspberry Pi 4 Model B Rev 1.2
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] Reserved memory: bypass linux,cma node, using cmdline CMA params 
instead
[0.00] OF: reserved mem: node linux,cma compatible matching fail
[0.00] cma: Reserved 64 MiB at 0xf800
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem 
0x-0xfbff]
[0.00] NUMA: NODE_DATA [mem 0xf781d0c0-0xf781efff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x-0x3fff]
[0.00]   DMA32[mem 0x4000-0xfbff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x3b3f]
[0.00]   node   0: [mem 0x4000-0xfbff]
[0.00] Initmem setup node 0 [mem 0x-0xfbff]
[0.00] percpu: Embedded 32 pages/cpu s93976 r8192 d28904 u131072
[0.00] Detected PIPT I-cache on CPU0
[0.00] CPU features: detected: EL2 vector hardening
[0.00] CPU features: kernel page table isolation forced ON by KASLR
[0.00] CPU features: detected: Kernel page table isolation (KPTI)
[0.00] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware
[0.00] CPU features: detected: ARM erratum 1319367
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 996912
[0.00] Policy zone: DMA32
[0.00] Kernel command line:  dma.dmachans=0x71f5 
bcm2709.boardrev=0xc03112 bcm2709.serial=0xf5ccdafc bcm2709.uart_clock=4800 
bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 
smsc95xx.macaddr=DC:A6:32:77:E5:5E vc_mem.mem_base=0x3ec0 
vc_mem.mem_size=0x4000  console=tty0 console=ttyS1,115200 
root=/dev/mmcblk1p3 ro net.ifnames=0 cma=64M apparmor=0 rootwait
[0.00] Dentry cache hash table entries: 524288 (order: 10, 4194304 
bytes, linear)
[0.00] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, 
linear)
[0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
[0.00] software IO TLB: mapped [mem 0x3740-0x3b40] (64MB)
[0.00] Memory: 1925100K/4050944K available (10108K kernel code, 1836K 
rwdata, 3752K rodata, 5184K init, 557K bss, 174912K reserved, 65536K 
cma-reserved)
[0.00] random: get_random_u64 called from 
__kmem_cache_create+0x44/0x5c8 with crng_init=0
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] ftrace: allocating 36361 entries in 143 pages
[0.00] ftrace: allocated 143 pages with 5 groups
[0.00] rcu: Hierarchical RCU implementation.
[0.00] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4.
[0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 
jiffies.
[0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[0.00] GIC: Using split EOI/Deactivate mode
[0.00] arch_timer: cp15 timer(s) running at 54.00MHz (phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
[0.06] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 
4398046511102ns
[0.000184] Console: colour dummy device 80x25
[0.000554] printk: console [tty0] enabled
[0.000683] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 108.00 BogoMIPS (lpj=216000)
[0.000708] pid_max: default: 32768 minimum: 301
[0.000871] LSM: Security Framework initializing
[0.000944] Yama: disabled by default; enable with sysctl kernel.yama.*
[0.000983] SELinux:  Initializing.
[0.001067] TOMOYO Linux initialized
[0.001202] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, 
linear)
[0.001273] Mountpoint-cache hash table entries:

Bug#960129: linux-image-5.6.0-1-arm64: please enable CONFIG_PCIE_BRCMSTB in the arm64 kernel for Raspberry Pi 4

[Bjørn Mork]

Lucas Nussbaum  writes:
> On 09/05/20 at 20:44 +0200, Bjørn Mork wrote:
>> Please enable CONFIG_PCIE_BRCMSTB on arm64.
>> 
>> The Raspberry Pi 4 has a VL805 xhci controller connected to the
>> PCIe bus on the SoC.  All USB ports are connected to this controller.
>> CONFIG_PCIE_BRCMSTB is therefore necessary for USB support.
>
> I am trying to boot a RPI4 with the 5.6 kernel from unstable, but it
> fails to boot (while it worked with 5.5 from unstable).
>
> What I'm seeing with 5.5, but not with 5.6, is:
> [4.500333] mmc1: SDHCI controller on fe34.emmc2 [fe34.emmc2] 
> using ADMA
> [4.500585] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
> [4.577842] mmc0: new high speed SDIO card at address 0001
> [4.610694] mmc1: new ultra high speed DDR50 SDHC card at address 
> [4.618812] mmcblk1: mmc1: SC16G 14.8 GiB
> [4.629268]  mmcblk1: p1 p2
>
> Did you also see that issue?

No, I didn't.  I am netbooting, so I wouldn't have noticed...

Don't think I've tried booting any Debian kernels from an SD card yet.
Will try to find some time to test it.  But I find using SD cards more
quite a hassle :-)

> Was it fixed by enabling
> CONFIG_PCIE_BRCMSTB, or is that a different issue?

Probably different.  I believe this driver just enables the PCIe
controller, which should be independent of anything else except the PCIe
connected xhci controller.


Bjørn

Bug#960129: linux-image-5.6.0-1-arm64: please enable CONFIG_PCIE_BRCMSTB in the arm64 kernel for Raspberry Pi 4

[Bjørn Mork]

Package: src:linux
Version: 5.6.7-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

Please enable CONFIG_PCIE_BRCMSTB on arm64.

The Raspberry Pi 4 has a VL805 xhci controller connected to the
PCIe bus on the SoC.  All USB ports are connected to this controller.
CONFIG_PCIE_BRCMSTB is therefore necessary for USB support.

I tested rebuilding the current Debian 5.6 kernel in sid with just
this change, and it is enough to enable the USB port on the RPi4:

root@buster-rpi4:~# lspci -nn
00:00.0 PCI bridge [0604]: Broadcom Limited Device [14e4:2711] (rev 10)
01:00.0 USB controller [0c03]: VIA Technologies, Inc. VL805 USB 3.0 Host 
Controller [1106:3483] (rev 01)
root@buster-rpi4:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@buster-rpi4:~# dmesg |egrep -i 'pci|usb|xhci'
[0.877939] PCI: CLS 0 bytes, default 64
[1.359321] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[1.359879] brcm-pcie fd50.pcie: host bridge /scb/pcie@7d50 ranges:
[1.359905] brcm-pcie fd50.pcie:   No bus range found for 
/scb/pcie@7d50, using [bus 00-ff]
[1.359943] brcm-pcie fd50.pcie:  MEM 0x06..0x0603ff -> 
0x00f800
[1.359978] brcm-pcie fd50.pcie:   IB MEM 0x00..0x00bfff -> 
0x00
[1.409038] brcm-pcie fd50.pcie: link up, 5 GT/s x1 (SSC)
[1.409257] brcm-pcie fd50.pcie: PCI host bridge to bus :00
[1.409277] pci_bus :00: root bus resource [bus 00-ff]
[1.409296] pci_bus :00: root bus resource [mem 0x6-0x603ff] 
(bus address [0xf800-0xfbff])
[1.409340] pci :00:00.0: [14e4:2711] type 01 class 0x060400
[1.409442] pci :00:00.0: PME# supported from D0 D3hot
[1.411585] pci :00:00.0: bridge configuration invalid ([bus 00-00]), 
reconfiguring
[1.411761] pci :01:00.0: [1106:3483] type 00 class 0x0c0330
[1.411849] pci :01:00.0: reg 0x10: [mem 0x-0x0fff 64bit]
[1.412028] pci :01:00.0: PME# supported from D0 D3cold
[1.424884] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
[1.424924] pci :00:00.0: BAR 14: assigned [mem 0x6-0x6000f]
[1.424947] pci :01:00.0: BAR 0: assigned [mem 0x6-0x60fff 
64bit]
[1.424975] pci :00:00.0: PCI bridge to [bus 01]
[1.424991] pci :00:00.0:   bridge window [mem 0x6-0x6000f]
[1.425165] pcieport :00:00.0: enabling device ( -> 0002)
[1.425312] pcieport :00:00.0: PME: Signaling with IRQ 40
[1.425631] pcieport :00:00.0: AER: enabled with IRQ 40
[1.425806] pci :01:00.0: enabling device ( -> 0002)
[3.189692] usb_phy_generic phy: phy supply vcc not found, using dummy 
regulator
[3.278169] usbcore: registered new interface driver usbfs
[3.284814] usbcore: registered new interface driver hub
[3.291153] usbcore: registered new device driver usb
[3.336101] dwc2 fe98.usb: fe98.usb supply vusb_d not found, using 
dummy regulator
[3.344668] dwc2 fe98.usb: fe98.usb supply vusb_a not found, using 
dummy regulator
[3.459118] dwc2 fe98.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM
[   15.946055] xhci_hcd :01:00.0: xHCI Host Controller
[   15.954077] xhci_hcd :01:00.0: new USB bus registered, assigned bus 
number 1
[   15.967736] xhci_hcd :01:00.0: hcc params 0x002841eb hci version 0x100 
quirks 0x0090
[   15.989621] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, 
bcdDevice= 5.06
[   15.998076] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   16.005520] usb usb1: Product: xHCI Host Controller
[   16.010535] usb usb1: Manufacturer: Linux 5.6.0-2-arm64 xhci-hcd
[   16.016722] usb usb1: SerialNumber: :01:00.0
[   16.023171] hub 1-0:1.0: USB hub found
[   16.033311] xhci_hcd :01:00.0: xHCI Host Controller
[   16.039381] xhci_hcd :01:00.0: new USB bus registered, assigned bus 
number 2
[   16.039400] xhci_hcd :01:00.0: Host supports USB 3.0 SuperSpeed
[   16.039510] usb usb2: We don't know the algorithms for LPM for this host, 
disabling LPM.
[   16.039578] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, 
bcdDevice= 5.06
[   16.039581] usb usb2: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   16.039584] usb usb2: Product: xHCI Host Controller
[   16.039587] usb usb2: Manufacturer: Linux 5.6.0-2-arm64 xhci-hcd
[   16.039589] usb usb2: SerialNumber: :01:00.0
[   16.039938] hub 2-0:1.0: USB hub found
[   16.197384] usbcore: registered new interface driver brcmfmac
[   16.443015] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[   16.601666] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, 
bcdDevice= 4.21
[   16.613530] usb 1-1: New USB device strings: 

Re: initramfs-tools_0.136_source.changes ACCEPTED into unstable

[Bjørn Mork]

Debian FTP Masters  writes:

>* [835d584] mkinitramfs: Copy modules.builtin.bin into initramfs
>  (Closes: #948257)


It's a bit depressing to see bugs hidden under the carpet instead of
solved.  But whatever.  If you prefer adding a bug in mkinitramfs
instead of fixing the problem, then I guess that's your decision.

If anyone is interested in solving the kmod bug, then that is as simple
as deleting a Debian patch,  Which BTW seems to have been added in for
the exact same reason:  To hide another bug.

Nice work



Bjørn

Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_XXXXXXX/lib/modules/5.4.0-1-amd64/modules.builtin.bin'

[Bjørn Mork]

Pierrick CHANTEUX  writes:

> This bug resulted in complete system breakage and I couldn't boot
> anymore (systemd failing to load Kernel modules). I can guarantee that
> this isn't only cosmetic.
>
> I believe this isn't related to initramfs-tools, because downgrading
> kmod and libkmod2 from version 26+20191223-1 to version 26-3 fixes the
> issue. Initramfs now build (and run) correctly.

IMHO this is probably an unrelated bug in the same kmod upgrade.  You
should report it as such, which the full log output and a subject
decribing the issue instead of the bogus error message.

The logspam caused by the lookup_builtin_file() bug makes it hard to
spot real errors, but hopefully there is some clue to your problem there
too.



Bjørn

Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_N1a1Mk/lib/modules/5.4.0-1-amd64/modules.builtin.bin'

[Bjørn Mork]

Bjørn Mork  writes:
> Marco d'Itri  writes:
>
>> Control: severity -1 normal
>> Control: tags -1 patch
>> Control: reassign -1 initramfs-tools
>>
>> On Jan 06, crvi  wrote:
>>
>>>* What outcome did you expect instead?
>>> 
>>> Successful ramfs generation
>> Do you have any reason to believe that the initrfamfs was not generated 
>> successfully?
>>
>> This is only cosmetic, and it needs to be fixed in /usr/sbin/mkinitramfs
>> by copying modules.builtin.bin too:
>>
>> -for x in modules.builtin modules.order; do
>> +for x in modules.builtin modules.builtin.bin modules.order; do
>
> modules.builtin.bin is created, and always regenerated, by depmod based
> on modules.builtin.  Requiring modules.builtin.bin to exist before
> running depmod makes no sense at all.
>
> So what change made depmod spit out this pointless warning?  You should
> fix that bug instead insisting that some other package paper over it.

FYI: the bug is Debian-specific and introduced long ago with this patch:

bjorn@miraculix:/tmp/kmod-26+20191223$ cat debian/patches/verbose_missing_bin 
Description: Report an error when some .bin files do not exist
Author: Marco d'Itri 
Bug-Debian: http://bugs.debian.org/684901
---

--- a/libkmod/libkmod.c
+++ b/libkmod/libkmod.c
@@ -503,7 +503,7 @@ static char *lookup_builtin_file(struct
 
idx = index_file_open(fn);
if (idx == NULL) {
-   DBG(ctx, "could not open builtin file '%s'\n", fn);
+   ERR(ctx, "could not open builtin file '%s'\n", fn);
return NULL;
}
 
@@ -575,7 +575,7 @@ char *kmod_search_moddep(struct kmod_ctx
 
idx = index_file_open(fn);
if (idx == NULL) {
-   DBG(ctx, "could not open moddep file '%s'\n", fn);
+   ERR(ctx, "could not open moddep file '%s'\n", fn);
return NULL;
}
 




Non-existing files is expected for libkmod in some situations, like the
current example when depmod is looking up a module while generating
dependencies for it.



Bjørn

Re: Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_N1a1Mk/lib/modules/5.4.0-1-amd64/modules.builtin.bin'

[Bjørn Mork]

Marco d'Itri  writes:

> Control: severity -1 normal
> Control: tags -1 patch
> Control: reassign -1 initramfs-tools
>
> On Jan 06, crvi  wrote:
>
>>* What outcome did you expect instead?
>> 
>> Successful ramfs generation
> Do you have any reason to believe that the initrfamfs was not generated 
> successfully?
>
> This is only cosmetic, and it needs to be fixed in /usr/sbin/mkinitramfs
> by copying modules.builtin.bin too:
>
> -for x in modules.builtin modules.order; do
> +for x in modules.builtin modules.builtin.bin modules.order; do

modules.builtin.bin is created, and always regenerated, by depmod based
on modules.builtin.  Requiring modules.builtin.bin to exist before
running depmod makes no sense at all.

So what change made depmod spit out this pointless warning?  You should
fix that bug instead insisting that some other package paper over it.


Bjørn

Bug#926261: closed by Ben Hutchings (Re: Bug#926261: linux-image-4.19.0-4-amd64: fan continiously spinning above 6900 RPM after resume on lenovo carbon x1 thinkpad with isa adap

[Bjørn Mork]

Not going to argue against this being a firmware bug.  I'm sure that is
true.  But Linux must deal with buggy firmware.  Else it cannot run on
any real system :-)

And this bug (or at least the bad effect on Linux) is a regression
introduced by commit c3a696b6e8f8 ("ACPI / EC: Use busy polling mode
when GPE is not enabled"), which again was an attempt to work around
firmware bugs in other systems.

This has been reported upstream, but AFAICS it is still only partially
fixed.  Ref the thread ending here:
https://spinics.net/lists/stable/msg214463.html


Bjørn

Re: why is the build so complex ?

[Bjørn Mork]

"Enrico Weigelt, metux IT consult"  writes:

> while trying to build a debian kernel w/ some minor config changes
> (actually, just need the gpio keyboard modules),

Can't help with answers to your questions, but i believe I can help with
this task.  It's as simple as

 $ git clone https://github.com/notro/fbtft_tools.git
 Cloning into 'fbtft_tools'...
 remote: Enumerating objects: 95, done.
 remote: Total 95 (delta 0), reused 0 (delta 0), pack-reused 95
 Unpacking objects: 100% (95/95), done.
 $ cd fbtft_tools/gpio_keys_device/
 $ make
 make -C /lib/modules/4.18.0-3-amd64/build 
M=/usr/local/src/git/fbtft_tools/gpio_keys_device modules
 make[1]: Entering directory '/usr/src/linux-headers-4.18.0-3-amd64'
   CC [M]  /usr/local/src/git/fbtft_tools/gpio_keys_device/gpio_keys_device.o
   Building modules, stage 2.
   MODPOST 1 modules
   CC  
/usr/local/src/git/fbtft_tools/gpio_keys_device/gpio_keys_device.mod.o
   LD [M]  /usr/local/src/git/fbtft_tools/gpio_keys_device/gpio_keys_device.ko
 make[1]: Leaving directory '/usr/src/linux-headers-4.18.0-3-amd64'


provided you have installed the linux-headers package matching your
kernel.  No need to care about the Debian kernel patches and build
infrastructure at all.

Or did you mean something else?


Bjørn

Bug#914495: linux-image-4.18.0-3-amd64: does not boot here

[Bjørn Mork]

Bjørn Mork  writes:
> Given this, there is an extremely suspicious commit added in v4.18.20: 
>
>  06e562e7f515 ("drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for 
> gen4/gen5")
>
> I do have an old laptop with an affected chipset generation, and
> verified that it had the same symptoms.  But never got the time to
> actually test any further.  Still, I do think that there is good reason
> to simply try a revert of that commit.

FWIW, I have now verified that reverting commit 06e562e7f515
("drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5") fixes
this issue for me.



Bjørn

Bug#914495: linux-image-4.18.0-3-amd64: does not boot here

[Bjørn Mork]

Ben Hutchings  writes:
> On Mon, 2018-12-03 at 23:08 +0100, TS wrote:
>
>> Just out of curiosity since linux-image-amd64 4.18+100 has been uploaded to
>> unstable. This issue here seems not to be wide spread, or reproducible?
>
> Hard to tell.  There are a few people that reported the same *symptom*,
> but that doesn't mean they found the same bug.

True of course.  But in this case there seems to be a very strong
correlation with Gen4 Intel GPUs. I believe every one of the reports
have had at least a lspci dump showing one of those. And a couple of
the reports had stack traces pointing to gen4_render_ring_flush as well.

Given this, there is an extremely suspicious commit added in v4.18.20: 

 06e562e7f515 ("drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5")

I do have an old laptop with an affected chipset generation, and
verified that it had the same symptoms.  But never got the time to
actually test any further.  Still, I do think that there is good reason
to simply try a revert of that commit.



Bjørn

Bug#906593: Crash with intel 8265

[Bjørn Mork]

Hugo Mercier  writes:

> It seems I have a similar problem on a Thinkpad X1 4th generation.

So, since I also run Debian sid on one of those, and haven't got any
issues, I thought I would compare firmware versions etc


> $ lspci -v
> 04:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 88)
>   Subsystem: Intel Corporation Wireless 8265 / 8275 (Dual Band
> Wireless-AC 8265)


But this didn't match...

> Nov 19 10:42:20 mhugo kernel: [ 5007.023990] Hardware name: LENOVO 
> 20HRCTO1WW/20HRCTO1WW, BIOS N1MET39W (1.24 ) 09/27/2017

And neither did this.

Which is becuase this isn't a log from a 4th gen.  You have a 5th gen
X1.  Not that I think it matters, since you got the 8265 right.  But
still.  Best to have correct info in the bug report.



Bjørn

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

[Bjørn Mork]

Phil  writes:

> Hi, I hope you're all doing well.
>
> Shall we/I maybe reopen a new issue?

I believe so.  I am almost sure we fixed the original memset BUG in
cdc_ncm_fill_tx_frame. Or at least one of them...

So you are probably seeing another issue if you still have problems with
that fix in place.  Although the issues may or may not be related.  But
still, aother bug report would make it easier to track given that we
alread have one fix for 893393.

> I'm still affected by this and I'd could use some advice how to debug
> the issue a little bit better, especially since the kexec kernel
> crashdumps appear not to be helpful. Can I maybe compile the module with
> special debug flags and load it via. dkms or something?

Crash reports of some sort are best.  But any info is useful.  Like what
device is this really and what mode is in currently in?  What driver
does it use?  Most Huawei firmwares will support many different modes
using different USB drivers. But laptop internal modems are most likely
not tested with anything but the Windows MBIM class driver, since that
is the certification requirement and only target platform.

You can enable the little debugging that's already in the drivers by
doing something like

 echo 'module cdc_ncm +fp' >/sys/kernel/debug/dynamic_debug/control
 echo 'module cdc_mbim +fp' >/sys/kernel/debug/dynamic_debug/control
 echo 'module huawei_cdc_ncm +fp' >/sys/kernel/debug/dynamic_debug/control

See https://www.kernel.org/doc/html/v4.11/admin-guide/dynamic-debug-howto.html

Not sure it will be useful to debug a freeze though.

> I don't see any actual changes in [cdc_ncm.c][cdc_ncm], besides the one
> change in `cdc_ncm_unbind`.

Not sure I understood this...  Are you referring to the fix for bug
893393?  That's part of the v4.9.111 stable release:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/usb/cdc_ncm.c?h=linux-4.9.y=35fd10aeb2248cc7f8d3d48ccc2eff1cf19918f4

> Also I'm confused why this is happening now again, I managed to do an
> rsync upload with ~10GB over night back then - and my system didn't
> crash - but right now even if I'm just trying to upload a picture to
> twitter via. Firefox my laptop freezes.

Freezing without any Oops or similar? 



Bjørn

Re: linux_4.17.3-1_multi.changes ACCEPTED into unstable, unstable

[Bjørn Mork]

Debian FTP Masters  writes:

>  - cdc_ncm: avoid padding beyond end of skb

I believe this fixes https://bugs.debian.org/893393 , but I have no way
to verify it.


Bjørn

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

[Bjørn Mork]

This issue should be fixed by commit

 49c2c3f246e2 ("cdc_ncm: avoid padding beyond end of skb")

which has been backported to v4.17.3, v4.16.18 and v4.14.52.  Please
check again with one of those kernel versions (or newer).

I see now that the fix doesn't apply cleanly to v4.9 stable due to
unrelated context changes.  I'll go fix that and resubmit a backport for
v4.9, so we get the fix into "stretch" too.  Thanks for reminding me.



Bjørn

Bug#897572: urandom hang in early boot

[Bjørn Mork]

Ben Hutchings  writes:
> On Tue, 2018-05-08 at 11:12 +1200, Ben Caradoc-Davies wrote:
>> On 08/05/18 05:34, Laurent Bigonville wrote:
>> > Apparently it's also happening for other applications that are starting 
>> > later during the boot like GDM.
>> > Somebody has reported an issue on IRC where GDM was taking upto 8 
>> > minutes to start (dmesg was showing several "random: systemd: 
>> > uninitialized urandom read (16 bytes read)" during boot)
>> > That problem might impact lot of people I'm afraid.
>> 
>> systemd is the underlying cause: plymouthd uses libudev1, which expects 
>> getrandom/urandom(?) to never block:
>> https://github.com/systemd/systemd/blob/master/src/basic/random-util.c#L34
>> 
>> See discussion here about systemd usage of random numbers:
>> systemd reads from urandom before initialization
>> https://github.com/systemd/systemd/issues/4167
>> 
>> The new problem is that 43838a23a05f ("random: fix crng_ready() test") 
>> turns an ugly warning and cryptographic weakness into an indefinite 
>> hang. Security achieved!
>
> You keep saying this, but based on my reading of the code I don't see
> how reads from /dev/urandom can end up blocking.

It's a bit convoluted, but if I read the code correctly then
acquire_random_bytes() falls back to busy-loop reading from /dev/urandom
until it has the requested number of bytes if 'high_quality_required' is
true.

There aren't more than two such calls, but one of then is
sd_id128_randomize() which calls acquire_random_bytes(, sizeof t, true).

And sd_id128_randomize() is called from all over the place.  I haven't
bothered looking at all the call sites, but would be surprised if not at
least one of them is unconditionally called at boot.

If I am correct, then I guess this is a systemd bug?


Bjørn

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

[Bjørn Mork]

Горбешко Богдан  writes:

> vboxdrv(O)
> binder_linux(O)
> ashmem_linux(O)

Can you reproduce the problem without these modules loaded?

AFAICS there is no way the only memset in cdc_ncm can be called with
crashing input parameters. Unless something is scribbling over the
driver's data.


Bjørn

Bug#871639: NULL pointer dereference in reset_common_ring+0xc3/0x170 [i915]

[Bjørn Mork]

Package: src:linux
Version: 4.9.30-2+deb9u3
Severity: normal
File: /boot/vmlinuz-4.9.0-3-amd64

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've been having issues with the i915 driver ever since I got this Skylake 
laptop.
The GPU is hanging every now and then.  But the error handling has become worse
over time, from merely pausing a few seconds via X restarting,  to now ooopsing
after updating to 4.9.30-2+deb9u3.

The issue started with a few warnings I've seen before, followed by the oops 
(which
is a new symptom AFAIK):

[drm] GPU HANG: ecode 9:0:0xffd7fffe, in Xorg [842], reason: Hang on render 
ring, action: reset
[drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including 
userspace.
[drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> 
DRM/Intel
[drm] drm/i915 developers can then reassign to the right component if it's not 
a kernel issue.
[drm] The gpu crash dump is required to analyze gpu hangs, so please always 
attach it.
[drm] GPU crash dump saved to /sys/class/drm/card0/error
drm/i915: Resetting chip after gpu hang
[drm] RC6 on
[drm] GuC firmware load skipped
drm/i915: Resetting chip after gpu hang
[drm] RC6 on
[drm] GuC firmware load skipped
- [ cut here ]
WARNING: CPU: 3 PID: 842 at 
/build/linux-me40Ry/linux-4.9.30/drivers/gpu/drm/i915/intel_display.c:14180 
intel_atomic_commit_tail+0xf2b/0xf50 [i915]
pipe A vblank wait timed out
Modules linked in: ses enclosure sd_mod scsi_transport_sas sg uas usb_storage 
scsi_mod rfcomm ctr ccm ipt_REJECT nf_reject_ipv4 iptable_filter xt_set 
ip_set_hash_ip ip_set nfnetlink 8021q garp mrp stp llc tun cmac bnep arc4 
snd_hda_codec_hdmi snd_hda_codec_conexant intel_rapl x86_pkg_temp_thermal 
intel_powerclamp snd_hda_codec_generic coretemp kvm_intel kvm irqbypass 
snd_soc_skl snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp crct10dif_pclmul 
snd_hda_ext_core crc32_pclmul snd_soc_sst_match nls_ascii snd_soc_core 
nls_cp437 ghash_clmulni_intel cdc_mbim snd_compress cdc_wdm cdc_ncm usbnet 
qcserial intel_cstate usb_wwan vfat mii fat usbserial sparse_keymap iwlmvm 
btusb btrtl btbcm btintel bluetooth mac80211 intel_uncore iwlwifi efi_pstore 
snd_hda_intel intel_rapl_perf snd_hda_codec evdev
 iTCO_wdt joydev snd_hda_core snd_hwdep snd_pcm serio_raw efivars 
iTCO_vendor_support i915 snd_timer hid_sensor_accel_3d uvcvideo 
hid_sensor_trigger videobuf2_vmalloc hid_sensor_iio_common videobuf2_memops 
cfg80211 industrialio_triggered_buffer videobuf2_v4l2 kfifo_buf rtsx_pci_ms 
thinkpad_acpi videobuf2_core drm_kms_helper industrialio nvram memstick 
videodev drm mei_me snd media soundcore mei shpchp intel_pch_thermal rfkill ac 
battery i2c_algo_bit video tpm_crb wmi button parport_pc ppdev lp parport 
sunrpc efivarfs ip_tables x_tables autofs4 ext4 crc16 jbd2 fscrypto ecb mbcache 
crc32c_generic hid_sensor_custom hid_sensor_hub intel_ishtp_hid hid 
rtsx_pci_sdmmc mmc_core crc32c_intel aesni_intel aes_x86_64 glue_helper lrw 
gf128mul ablk_helper cryptd i2c_i801 psmouse i2c_smbus e1000e ptp nvme pps_core 
nvme_core xhci_pci xhci_hcd rtsx_pci mfd_core usbcore intel_ish_ipc usb_common 
intel_ishtp thermal
CPU: 3 PID: 842 Comm: Xorg Not tainted 4.9.0-3-amd64 #1 Debian 4.9.30-2+deb9u3
Hardware name: LENOVO 20FB006AMN/20FB006AMN, BIOS N1FET47W (1.21 ) 11/28/2016
  82728574 bea0c2be3b18 
 82476ebe  bea0c2be3b70 9c1b2c59
  9c1b2c565000 0001 82476f3f
Call Trace:
 [] ? dump_stack+0x5c/0x78
 [] ? __warn+0xbe/0xe0
 [] ? warn_slowpath_fmt+0x5f/0x80
 [] ? finish_wait+0x3c/0x70
 [] ? intel_atomic_commit_tail+0xf2b/0xf50 [i915]
 [] ? prepare_to_wait_event+0xf0/0xf0
 [] ? drm_atomic_helper_setup_commit+0x27c/0x380 
[drm_kms_helper]
 [] ? intel_atomic_commit+0x355/0x4c0 [i915]
 [] ? drm_atomic_helper_connector_dpms+0xe8/0x190 
[drm_kms_helper]
 [] ? drm_mode_connector_set_obj_prop+0x5b/0x70 [drm]
 [] ? drm_mode_obj_set_property_ioctl+0x11b/0x160 [drm]
 [] ? drm_mode_connector_property_set_ioctl+0x3e/0x60 [drm]
 [] ? drm_ioctl+0x1ea/0x470 [drm]
 [] ? drm_mode_connector_set_obj_prop+0x70/0x70 [drm]
 [] ? pipe_read+0x288/0x2d0
 [] ? do_vfs_ioctl+0x9f/0x600
 [] ? vfs_read+0x119/0x130
 [] ? SyS_ioctl+0x74/0x80
 [] ? system_call_fast_compare_end+0xc/0x9b
- ---[ end trace 93f14b701ef00ca8 ]---
[drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* 
[CRTC:26:pipe A] flip_done timed out
[drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* 
[CRTC:26:pipe A] flip_done timed out
drm/i915: Resetting chip after gpu hang
[drm] RC6 on
[drm] GuC firmware load skipped
drm/i915: Resetting chip after gpu hang
[drm] RC6 on
[drm] GuC firmware load skipped
- [ cut here ]
WARNING: CPU: 2 PID: 879 at 
/build/linux-me40Ry/linux-4.9.30/drivers/gpu/drm/i915/intel_display.c:14180 
intel_atomic_commit_tail+0xf2b/0xf50 [i915]
pipe A vblank wait timed out
Modules linked in: 

Bug#864878: /boot/vmlinuz-4.9.0-3-amd64: Please enable CONFIG_HPFS_FS as a module

[Bjørn Mork]

Package: src:linux
Version: 4.9.30-2
Severity: wishlist
File: /boot/vmlinuz-4.9.0-3-amd64

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Hello,

it's hard to claim this is important to me since I haven't noticed it was gone 
until
today.  But could you please re-enable CONFIG_HPFS_FS unless there are any 
reasons
not to do so?

It seems to have been disabled as part of the BKL cleanups a long time ago: 

linux-2.6 (2.6.38-1) unstable; urgency=low

  * New upstream release: http://kernelnewbies.org/Linux_2_6_38

  [ Ben Hutchings ]
  * Move firmware-linux-free to separate source package (firmware-free)
  * Move linux-base to separate source package
  * net/can: Enable CAN_SLCAN as module (Closes: #617629)
  * sound: Enable SND_ALOOP as module (Closes: #617869)
  * Remove the Big Kernel Lock:
- adfs,appletalk,i810,ufs,usbip: Refactor locking
- hpfs: Disable HPFS_FS
  * ext4: Disable FS_IOC_FIEMAP ioctl temporarily (together with fixes
for btrfs in 2.6.38, closes: #615035)
  * sched: Build with SCHED_AUTOGROUP, but do not enable autogrouping by
default (use sysctl kernel.sched_autogroup_enabled=1) (Closes: #618486)
  * Set ABI to 1

  [ Aurelien Jarno]
  * mips/malta-[45]kc: 
- disable ATM, TR, WAN.
- synchronize options in malta-4kc and malta-5kc.

 -- Ben Hutchings   Wed, 16 Mar 2011 04:47:57 +



There has been som real work done on this driver since then, including new
feature support, so it is not in a completely unmaintained state at least.
And it builds fine with the current Stretch kernel, of course.  So unless
there is something I miss, I don't really see any reason not to enable it
as a module.

Yes, I do still have a couple of OS/2 Warp disk images leftover from the
90's.  Obviously not something I mount every day.  About once every decade,
I guess.  Looking forward to having Debian suppport then next time I try it
in 2025 or something like that ;-)



Bjørn

- -- Package-specific info:
** Version:
Linux version 4.9.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2 (2017-06-12)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 
root=UUID=71507198-90f4-4c25-be41-efc47d2dedd1 ro

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20FB006AMN
product_version: ThinkPad X1 Carbon 4th
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N1FET47W (1.21 )
board_vendor: LENOVO
board_name: 20FB006AMN
board_version: SDK0J40697 WIN

** Loaded modules:
rfcomm
ipt_REJECT
nf_reject_ipv4
iptable_filter
xt_set
ip_set_hash_ip
ip_set
nfnetlink
8021q
garp
mrp
stp
llc
tun
cmac
bnep
snd_hda_codec_hdmi
snd_hda_codec_conexant
snd_hda_codec_generic
arc4
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
kvm
irqbypass
snd_soc_skl
nls_ascii
snd_soc_skl_ipc
crct10dif_pclmul
snd_soc_sst_ipc
nls_cp437
crc32_pclmul
snd_soc_sst_dsp
snd_hda_ext_core
snd_soc_sst_match
vfat
snd_soc_core
fat
snd_compress
ghash_clmulni_intel
intel_cstate
sparse_keymap
iwlmvm
efi_pstore
uvcvideo
intel_uncore
videobuf2_vmalloc
videobuf2_memops
mac80211
videobuf2_v4l2
intel_rapl_perf
joydev
evdev
videobuf2_core
efivars
serio_raw
snd_hda_intel
videodev
rtsx_pci_ms
snd_hda_codec
snd_hda_core
snd_hwdep
memstick
iwlwifi
iTCO_wdt
snd_pcm
iTCO_vendor_support
btusb
snd_timer
media
btrtl
cfg80211
thinkpad_acpi
hid_sensor_accel_3d
btbcm
cdc_mbim
btintel
mei_me
cdc_wdm
cdc_ncm
nvram
hid_sensor_trigger
i915
bluetooth
mei
shpchp
usbnet
qcserial
drm_kms_helper
usb_wwan
intel_pch_thermal
mii
hid_sensor_iio_common
snd
industrialio_triggered_buffer
drm
kfifo_buf
soundcore
usbserial
industrialio
i2c_algo_bit
rfkill
wmi
button
ac
battery
video
tpm_crb
parport_pc
ppdev
lp
parport
sunrpc
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
jbd2
fscrypto
ecb
mbcache
crc32c_generic
hid_sensor_custom
hid_sensor_hub
intel_ishtp_hid
hid
rtsx_pci_sdmmc
mmc_core
crc32c_intel
aesni_intel
aes_x86_64
glue_helper
lrw
gf128mul
ablk_helper
cryptd
psmouse
e1000e
ptp
i2c_i801
pps_core
i2c_smbus
xhci_pci
nvme
xhci_hcd
nvme_core
rtsx_pci
mfd_core
usbcore
intel_ish_ipc
usb_common
intel_ishtp
thermal

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM 
Registers [8086:1904] (rev 08)
Subsystem: Lenovo Skylake Host Bridge/DRAM Registers [17aa:2238]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 520 
[8086:1916] (rev 07) (prog-if 00 [VGA controller])
Subsystem: Lenovo HD Graphics 520 [17aa:2238]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- 

Re: [PATCH initramfs-tools 0/9] Fix resume device configuration

[Bjørn Mork]

Ben Hutchings  writes:

> The change in version 0.128 to wait for the resume device to appear
> uncovered a number of systems for which the resume device is not
> properly configured.  In fact, systems with swap partitions that
> are never available at boot could not be configured correctly,
> other than by adding 'noresume' to the kernel command line!
>
> While working on that, I found and fixed a couple of other
> longstanding bugs in resume device selection.
>
> This patch series:
>
> - Fixes the sorting of swap partitions
> - Makes the RESUME variable work like every other configuration
>   variable, and documents it
> - Adds support for RESUME=none (disable resume) and RESUME=auto
>   (explicitly request automatic selection)
> - Adds warning and informational messages where the resume device
>   configuration is automatically fixed-up

Hmm, I got this warning, which seems harmless but unexpected:

Processing triggers for initramfs-tools (0.129) ...
update-initramfs: Generating /boot/initrd.img-4.9.0-2-amd64
W: initramfs-tools configuration sets 
RESUME=UUID=30db89e8-91f2-44ee-a8fa-61e5855ead41
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/nvme0n1p4
I: (UUID=30db89e8-91f2-44ee-a8fa-61e5855ead41)
I: Set the RESUME variable to override this.



My swap/resume settings are:


bjorn@miraculix:~$ cat /proc/swaps 
FilenameTypeSizeUsedPriority
/dev/nvme0n1p4  partition   164249561119612 
-1
bjorn@miraculix:~$ cat /etc/initramfs-tools/conf.d/resume 
RESUME=UUID=30db89e8-91f2-44ee-a8fa-61e5855ead41
bjorn@miraculix:~$ file -s /dev/nvme0n1p4
/dev/nvme0n1p4: no read permission
bjorn@miraculix:~$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 15 Mar 23 19:22 30db89e8-91f2-44ee-a8fa-61e5855ead41 -> 
../../nvme0n1p4
lrwxrwxrwx 1 root root 15 Mar 23 19:22 71507198-90f4-4c25-be41-efc47d2dedd1 -> 
../../nvme0n1p3
lrwxrwxrwx 1 root root 15 Mar 23 19:22 DA5D-17DD -> ../../nvme0n1p1



Bjørn

Bug#859641: Please increase USBIP_VHCI_HC_PORTS and USBIP_VHCI_NR_HCS

[Bjørn Mork]

Steve McIntyre  writes:

> In Linaro we're making a lot of use of USB-over-IP devices these days
> for our testing lab. We've hit a (very small!) limit defined in kernel
> config for the number of virtual host controllers and the ports
> allowed per controller.
>
> Currently these are defaulting to
>
> CONFIG_USBIP_VHCI_HC_PORTS=8
> (can be 1 <= CONFIG_USBIP_VHCI_HC_PORTS <= 31)
>
> and
> CONFIG_USBIP_VHCI_NR_HCS=1
> (can be 1 <= CONFIG_USBIP_VHCI_NR_HCS <= 128)
>
> The normal limits are very small; could you please raise these to
> (say) 31 and 8 for us? There will obviously be a small increase in
> memory usage in the kernel, but only for users of these particular
> devices.

FWIW, I believe those constants never should have been accepted. But I
just gave up after getting this answer:
http://www.spinics.net/lists/linux-usb/msg134862.html

"Because it is easy to implement." was obviously more important than
easy to use...  I don't think distro users were considered.

If you care about these limits, then I think you should look into what
needs to be done to make them dynamic.  I cannot imagine that it is all
that difficult.  Which of course is easy to say when you don't actually
plan on doing the work :)



Bjørn

Re: LED on keyboard

[Bjørn Mork]

Jan Niggemann  writes:

> I'm building a 4.8.15 kernel (which is working great) for my Thinkpad
> T460s. What bothers me, is that I can't get the LEDs on the F1 and F4
> key working ((F1=mute, F4=mic on/off). I checked CONFIG_ directives
> that seem relevant to me, but - well, I'm missing something. I have
> enabled LED-related options as well as GPIO options.
>
> The relevant LEDs work fine using the backports 4.8 kernel
> (4.8.0-0.bpo.2-amd64 #1 SMP Debian 4.8.11-1~bpo8+1 (2016-12-14) x86_64
> GNU/Linux). I have diffed both configs, but didn't spot the relevant
> option.

These LEDs seem to be hardwired to the analog mixer on my X1 gen4.  So
they only work as expected when muting analog input and output. 


Bjørn

Bug#850064: /boot/vmlinuz-4.8.0-2-amd64: kernel NULL pointer dereference in icmp6_send related to bridge port link changes

[Bjørn Mork]

OK, this looks like a known v4.8 stable regression, caused by the
backport of commit 5d41ce29e3b9 ("net: icmp6_send should use dst dev to
determine L3 domain") introduced in v4.8.10.

Should be fixed by commit 79dc7e3f1cd3 ("net: handle no dst on skb in
icmp6_send") as soon as Debian moves to v4.9

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



Bjørn

Bug#850064: /boot/vmlinuz-4.8.0-2-amd64: kernel NULL pointer dereference in icmp6_send related to bridge port link changes

[Bjørn Mork]

The first crash dumps were from my console, which was overwritten by
the later boot process and therefore incomplete.  Should have dug up
the complete logs from the console server in the first place..

Anyways, here are the complete stack traces:


[509753.194825] ixgbe :02:00.0 uplink: NIC Link is Down
[509753.206127] br0: port 1(uplink) entered disabled state
[509813.399798] BUG: unable to handle kernel NULL pointer dereference at 
0018
[509813.416211] IP: [] icmp6_send+0x229/0x9f0
[509813.428016] PGD 0 
[509813.432678] Oops:  [#1] SMP
[509813.439548] Dumping ftrace buffer:
[509813.446926](ftrace buffer empty)
[509813.454651] Modules linked in: xt_set ip_set_hash_ip ip_set nfnetlink 
ip6t_rt nf_log_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_REJECT nf_reject_ipv6 
ip6table_filter ip6_tables nfsd auth_rpcgss nfs_acl nfs lockd grace fscache 
sunrpc sch_tbf sit tunnel4 ip_tunnel xt_CT xt_nat ipt_MASQUERADE 
nf_nat_masquerade_ipv4 xt_REDIRECT nf_nat_redirect xt_multiport nf_log_ipv4 
nf_log_common xt_LOG xt_tcpudp xt_recent xt_conntrack ipt_REJECT nf_reject_ipv4 
iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 
iptable_filter ip_tables x_tables nf_nat_ftp nf_nat nf_conntrack_ftp 
nf_conntrack 8021q garp mrp bridge stp llc nls_ascii nls_cp437 vfat fat tun 
nct6775 hwmon_vid fuse intel_rapl x86_pkg_temp_thermal coretemp kvm_intel ast 
iTCO_wdt kvm iTCO_vendor_support hci_uart ttm irqbypass pl2303 btbcm 
crct10dif_pclmul drm_kms_helper efi_pstore btqca evdev crc32_pclmul btintel 
i2c_i801 serio_raw pcspkr i2c_smbus drm ghash_clmulni_intel efivars 
intel_lpss_acpi ipmi_si ie31200_edac mei_me bluetooth sg usbserial edac_core 
intel_lpss mei ipmi_msghandler shpchp battery acpi_als tpm_tis rfkill video 
mfd_core kfifo_buf button acpi_power_meter tpm_tis_core industrialio tpm ext4 
crc16 jbd2 fscrypto mbcache dm_mod raid1 raid456 async_raid6_recov async_memcpy 
async_pq async_xor async_tx md_mod xor raid6_pq libcrc32c sd_mod ahci xhci_pci 
crc32c_intel libahci xhci_hcd aesni_intel igb libata ixgbe aes_x86_64 
i2c_algo_bit glue_helper nvme lrw dca gf128mul scsi_mod ptp ablk_helper 
nvme_core cryptd usbcore pps_core usb_common i2c_hid mdio thermal fan hid fjes
[509813.739069] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.8.0-2-amd64 #1 
Debian 4.8.11-1
[509813.755700] Hardware name: ASUSTeK COMPUTER INC. P10S-E Series/P10S-E 
Series, BIOS 0505 03/01/2016
[509813.774316] task: 9f68a88c60c0 task.stack: 9f68a8a8c000
[509813.786889] RIP: 0010:[]  [] 
icmp6_send+0x229/0x9f0
[509813.803736] RSP: 0018:9f68efd03aa0  EFLAGS: 00010246
[509813.815068] RAX:  RBX: 9f68a4df7600 RCX: 
0020
[509813.830064] RDX: 0001 RSI: 0200 RDI: 
9f637b792048
[509813.845060] RBP: 9f68efd03bd0 R08: 9f68efd03bf0 R09: 
94b046f4
[509813.860052] R10: 0003 R11:  R12: 
9f637b792040
[509813.875030] R13: 87ada680 R14:  R15: 
0001
[509813.890020] FS:  () GS:9f68efd0() 
knlGS:
[509813.906976] CS:  0010 DS:  ES:  CR0: 80050033
[509813.919172] CR2: 0018 CR3: 0002c1e06000 CR4: 
003426e0
[509813.934137] DR0:  DR1:  DR2: 

[509813.949108] DR3:  DR6: fffe0ff0 DR7: 
0400
[509813.964094] Stack:
[509813.968801]  0046 9f68efd03b80 9f68a5d4a100 
9f68efd03c68
[509813.984437]  9f68efd03bf0  9f637b792048 
9f68
[509814.72]  9f680003 9f680001 9f637b792058 
9f68a3eacd80
[509814.015750] Call Trace:
[509814.021339]   
[509814.025406]  [] ? fib_rules_lookup+0x117/0x170
[509814.039032]  [] ? fib6_rule_lookup+0x53/0xc0
[509814.051394]  [] ? rt6_multipath_select+0xd0/0xd0
[509814.064453]  [] ? rt6_lookup+0x7b/0xb0
[509814.075793]  [] ? ip6_err_gen_icmpv6_unreach+0x140/0x260
[509814.090315]  [] ? __wake_up_sync_key+0x3d/0x60
[509814.103001]  [] ? ipip6_err+0xbd/0x1d0 [sit]
[509814.115341]  [] ? tunnel64_err+0x2d/0x40 [tunnel4]
[509814.128737]  [] ? icmp_unreach+0xb7/0x240
[509814.140567]  [] ? icmp_rcv+0x26f/0x390
[509814.151908]  [] ? ip_local_deliver_finish+0x8b/0x1c0
[509814.165631]  [] ? ip_local_deliver+0x6b/0xf0
[509814.177979]  [] ? ip_rcv_finish+0x3e0/0x3e0
[509814.190141]  [] ? ip_rcv+0x286/0x3c0
[509814.201084]  [] ? inet_del_offload+0x40/0x40



[  260.181699] BUG: unable to handle kernel NULL pointer dereference at 
0018
[  260.197481] IP: [] icmp6_send+0x229/0x9f0
[  260.208708] PGD 0 
[  260.212792] Oops:  [#1] SMP
[  260.219080] Dumping ftrace buffer:
[  260.225906](ftrace buffer empty)
[  260.233059] Modules linked in: xt_set ip_set_hash_ip ip_set nfnetlink xt_CT 
xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_REDIRECT nf_nat_redirect 
nf_log_ipv4 ipt_REJECT nf_reject_ipv4 iptable_raw iptable_nat 

Bug#850064: /boot/vmlinuz-4.8.0-2-amd64: kernel NULL pointer dereference in icmp6_send related to bridge port link changes

[Bjørn Mork]

Package: src:linux
Version: 4.8.11-1
Severity: important
File: /boot/vmlinuz-4.8.0-2-amd64

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

I just had two crashes in a row in icmp6_send while rebooting a switch in
the other end of one of the br0 bridge ports.  Both crash dumps follow:

[509753.194825] ixgbe :02:00.0 uplink: NIC Link is Down
[509753.206127] br0: port 1(uplink) entered disabled state
[509813.399798] BUG: unable to handle kernel NULL pointer dereference at 
0018
[509813.416211] IP: [] icmp6_send+0x229/0x9f0
[509813.428016] PGD 0 
[509813.432678] Oops:  [#1] SMP
[509813.439548] Dumping ftrace buffer:
[509813.446926](ftrace buffer empty)
[509813.454651] Modules linked in: xt_set ip_set_hash_ip ip_set nfnetlink 
ip6t_rt nf_log_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_REJECT nf_reject_ipv6 
ip6table_filter ip6_tables nfsd auth_rpcgss nfs_acl nfs lockd grace fscache 
sunrpc sch_tbf sit tunnel4 ip_tunnel xt_CT xt_nat ipt_MASQUERADE 
nf_nat_masquerade_ipv4 xt_REDIRECT nf_nat_redirect xt_multiport nf_log_ipv4 
nf_log_common xt_LOG xt_tcpudp xt_recent xt_conntrack ipt_REJECT nf_reject_ipv4 
iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 
iptable_filter ip_tables x_tables nf_nat_ftp nf_nat nf_conntrack_ftp 
nf_conntrack 8021q garp mrp bridge stp llc nls_ascii nls_cp437 vfat fat tun 
nct6775 hwmon_vid fuse intel_rapl x86_pkg_temp_thermal coretemp kvm_intel ast 
iTCO_wdt kvm iTCO_vendor_support hci_uart ttm irqbypass pl2303 btbcm 
crct10dif_pclmul drm_kms_helper efi_pstore btqca evdev crc32_pclmul btintel 
i2c_i801 serio_raw pcspkr i2c_smbus drm ghash_clmulni_intel efivars 
intel_lpss_acpi ipmi_si ie31200_e!
 dac mei_me bluetooth sg usbserial edac_core intel_lpss mei ipmi_msghandler 
shpchp battery acpi_als tpm_tis rfkill video mfd_core kfifo_buf button 
acpi_power_meter tpm_tis_core industrialio tpm ext4 crc16 jbd2 fscrypto mbcache 
dm_mod raid1 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx 
md_mod xor raid6_pq libcrc32c sd_mod ahci xhci_pci crc32c_intel libahci 
xhci_hcd aesni_intel igb libata ixgbe aes_x86_64 i2c_algo_bit glue_helper nvme 
lrw dca gf128mul scsi_mod ptp ablk_helper nvme_core cryptd usbcore pps_core 
usb_common i2c_hid mdio thermal fan hid fjes
[509813.739069] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.8.0-2-amd64 #1 
Debian 4.8.11-1
[509813.755700] Hardware name: ASUSTeK COMPUTER INC. P10S-E Series/P10S-E 
Series, BIOS 0505 03/01/2016
[509813.774316] task: 9f68a88c60c0 task.stack: 9f68a8a8c000
[509813.786889] RIP: 0010:[]  [] 
icmp6_send+0x229/0x9f0

[  260.181699] BUG: unable to handle kernel NULL pointer dereference at 
0018
[  260.197481] IP: [] icmp6_send+0x229/0x9f0
[  260.208708] PGD 0 
[  260.212792] Oops:  [#1] SMP
[  260.219080] Dumping ftrace buffer:
[  260.225906](ftrace buffer empty)
[  260.233059] Modules linked in: xt_set ip_set_hash_ip ip_set nfnetlink xt_CT 
xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_REDIRECT nf_nat_redirect 
nf_log_ipv4 ipt_REJECT nf_reject_ipv4 iptable_raw iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat_ftp nf_nat 
nf_conntrack_ftp xt_multiport ip6t_rt nf_log_ipv6 nf_log_common xt_LOG 
xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_recent xt_conntrack nf_conntrack 
ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables x_tables nfsd auth_rpcgss 
nfs_acl nfs lockd grace fscache sunrpc sch_tbf sit tunnel4 ip_tunnel 8021q garp 
mrp bridge stp llc nls_ascii nls_cp437 vfat fat tun nct6775 hwmon_vid fuse 
intel_rapl x86_pkg_temp_thermal coretemp kvm_intel iTCO_wdt ast 
iTCO_vendor_support kvm hci_uart ttm btbcm btqca mei_me irqbypass ie31200_edac 
i2c_i801 crct10dif_pclmul btintel crc32_pclmul ipmi_si evdev efi_pstore pcspkr 
drm_kms_helper i2c_smbus ghash_clmulni_intel bluetooth serio_raw efivars 
edac_co!
 re pl2303 drm sg mei video ipmi_msghandler usbserial intel_lpss_acpi shpchp 
battery intel_lpss rfkill mfd_core acpi_power_meter acpi_als tpm_tis kfifo_buf 
button tpm_tis_core industrialio tpm ext4 crc16 jbd2 fscrypto mbcache dm_mod 
raid1 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx md_mod 
xor raid6_pq libcrc32c sd_mod ahci crc32c_intel xhci_pci libahci aesni_intel 
igb xhci_hcd aes_x86_64 glue_helper lrw ixgbe i2c_algo_bit nvme libata gf128mul 
dca ablk_helper usbcore cryptd ptp scsi_mod usb_common nvme_core pps_core 
i2c_hid mdio fan thermal hid fjes
[  260.511842] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.8.0-2-amd64 #1 
Debian 4.8.11-1
[  260.527695] Hardware name: ASUSTeK COMPUTER INC. P10S-E Series/P10S-E 
Series, BIOS 0505 03/01/2016
[  260.545604] task: 8bbde88c7000 task.stack: 8bbde8a94000
[  260.557636] RIP: 0010:[]  [] 
icmp6_send+0x229/0x9f0
[  260.573798] RSP: 0018:8bbe2fd43760  EFLAGS: 00010246
[  260.584527] RAX:  RBX: 8bbde5a15900 RCX: 0020
[  260.598814] RDX: 0001 RSI: 0200 RDI: 

Bug#832458: linux-image-4.6.0-0.bpo.1-amd64: Please enable SND_SOC_INTEL_BYT_MAX98090_MACH, needed for some Baytrail devices

[Bjørn Mork]

Ben Hutchings  writes:
> On Mon, 2016-07-25 at 13:10 -0600, Ivan M wrote:
>> Package: src:linux
>> Version: 4.6.3-1~bpo8+1
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> Please enable CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH=m - it is
>> necessary for audio on certain Baytrail hardware.
>> 
>> (I note that it is also necessary to set CONFIG_DW_DMAC=y (not m) for
>> this, although I don't understand why.)
>
> This is an upstream regression.  It is simply not possible to select
> all the Intel SoC sound drivers any more.  It seems that some
> developers don't care to support a generic distribution configuration.

I believe that is supposed to be fixed by commit a395bdd6b24b ("ASoC:
intel: Fix sst-dsp dependency on dw stuff"), but I haven't verified it.

Looks like it's destined for v4.8 and not yet backported to any stable
kernel, though. Which is a bit odd given the "Fixes" tag..



Bjørn

Bug#833918: linux: Please enable cdc_ncm and cdc_mbim in d-i to support 'Dell 4-in-1 Adapter' Ethernet

[Bjørn Mork]

John Paul Adrian Glaubitz  writes:

> This adapter uses the cdc_ncm/cdc_mbim kernel modules which are currently 
> being disabled for
> debian-installer as those were suspected to be used by modems only [2], which 
> is not the
> case, however.

cdc_mbim is modem-only. cdc_ncm is not.

The reason you see cdc_mbim loaded is because of an oddity in the MBIM
spec, allowing an USB interface to be both NCM and MBIM depening on the
active altsetting. The cdc_mbim driver is therefore matching NCM
interfaces to be able to detect this sort of dual function.  But that's
completely irrelevant to your ethernet adapter.  MBIM cannot be used on
an ethernet (it has no no L2 headers).

By avoiding cdc_mbim, you can also drop the cdc_wdm dependency.


> [ 9105.605635] cdc_ncm 2-1.1:1.5: MAC-Address: 9c:eb:e8:20:f5:5b
> [ 9105.605640] cdc_ncm 2-1.1:1.5: setting rx_max = 16384
> [ 9105.605743] cdc_ncm 2-1.1:1.5: setting tx_max = 16384
> [ 9105.605991] cdc_ncm 2-1.1:1.5 usb0: register 'cdc_ncm' at 
> usb-:00:14.0-1.1, CDC NCM, 9c:eb:e8:20:f5:5b
> [ 9105.680400] cdc_ncm 2-1.1:1.5 enx9cebe820f55b: renamed from usb0

See?  This is only using cdc_ncm and will work fine even if cdc_mbim is 
unavailable.


Bjørn

Bug#808792: firmware-iwlwifi: iwlwifi-7260-17.ucode is missing

[Bjørn Mork]

Ben Hutchings <b...@decadent.org.uk> writes:
> On Wed, 2016-04-20 at 20:51 +0200, Bjørn Mork wrote:
>> Ben Hutchings <b...@decadent.org.uk> writes:
>> 
>> > 
>> > Our upstream is linux-firmware.git, not a hundred vendor web sites.
>> > Frankly I'm quite sick of the iwlwifi maintainers thinking their
>> > firmware is special and should be distributed differently from every.
>> Huh?  I always though they sent a pull request whenever they felt a new
>> update was "ready".  Like this:
>> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/149963
> [...]
>
> But apparently the firmware sometimes isn't 'ready' until *after* the
> previous major version reaches end of life.
>
> If all versions of firmware are either EOL or beta, Intel is
> effectively disclaiming support for the affected hardware.

Well, yes, that is confusing. I cannot imagine that it was their
intention.  FWIW, the current driver still supports firmwares back to
"13" for the 7260:

/* Highest firmware API version supported */
#define IWL7260_UCODE_API_MAX   17
#define IWL7265_UCODE_API_MAX   17
#define IWL7265D_UCODE_API_MAX  21
#define IWL3168_UCODE_API_MAX   21

/* Oldest version we won't warn about */
#define IWL7260_UCODE_API_OK13
#define IWL7265_UCODE_API_OK13
#define IWL7265D_UCODE_API_OK   13
#define IWL3168_UCODE_API_OK20

/* Lowest firmware API version supported */
#define IWL7260_UCODE_API_MIN   13
#define IWL7265_UCODE_API_MIN   13
#define IWL7265D_UCODE_API_MIN  13
#define IWL3168_UCODE_API_MIN   20


That is the authoritative source wrt "support".


Bjørn

Bug#808792: firmware-iwlwifi: iwlwifi-7260-17.ucode is missing

[Bjørn Mork]

Ben Hutchings  writes:

> Our upstream is linux-firmware.git, not a hundred vendor web sites.
> Frankly I'm quite sick of the iwlwifi maintainers thinking their
> firmware is special and should be distributed differently from every.

Huh?  I always though they sent a pull request whenever they felt a new
update was "ready".  Like this:
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/149963

But I'm not sure there has been a pull request for the 7260-17.ucode
yet?  It's going to be the last revision for that hardware, so they
might want to get it "right" first.  Nothing wrong about that AFAICS.
Or the fact that the driver has support for a revision which isn't yet
in the official repo. The driver works fine with the 7260-16.ucode too.

I don't see neither the website, or their firmware repo, as any attmept
to distribute firmware differently.  It's merely a service to users
wanting to beta test early firmware.  Personally I like having that
choice.  But Debian should definitely not start packaging any of the
firmware revisions which aren't in linux-firmware.git.


Bjørn

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

[Bjørn Mork]

Ben Hutchings <b...@decadent.org.uk> writes:
> On Mon, 2016-04-11 at 09:55 +0200, Bjørn Mork wrote:
>> Ben Hutchings <b...@decadent.org.uk> writes:
>> > 
>> > On Sun, 2016-04-10 at 11:15 -0700, Vagrant Cascadian wrote:
>> > > 
>> > > It works for the most part, but floods syslog with messages:
>> > > 
>> > > [501966.870273] net_ratelimit: 35702 callbacks suppressed
>> > > [501966.875438] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
>> > > 
>> > > It seems to function ok, though I'm not sure if there's degraded
>> > > network performance...
>> > [...]
>> > 
>> > I understand network performance on all RPi models is poor due to lack
>> > of a built-in Ethernet MAC and the poor design of the USB interface.
>> > Also that message is a generic error message from the usbnet core and
>> > is not specific to the smsc95xx driver.
>> Yes, kevent 2 is "EVENT_RX_MEMORY", and this error affects any usbnet
>> based device under memory pressure.  The usbnet framework just doesn't
>> handle the case where GFP_KERNEL allocations fail. How could it? 
>
> What I don't understand, given this, is why Vagrant didn't report any
> OOM warnings.  (I wondered whether the __GFP_NOWARN flag was wrongly
> being added somewhere, but I don't see that.)

Maybe I'm wrong?  Looking at this again, I notice that rx_submit()
always will call usb_submit_urb(urb, GFP_ATOMIC) regardless of the input
mem_flags, because it's holding a spinlock when submitting the urb.  So
it doesn't necessarily help much that the urb and skb are allocated with
GFP_KERNEL.

Exactly what allocations usb_submit_urb() may end up with seems to be
depending on the host controller. So the error spam could very well be
caused by a problematic host controller.  At least partly.

>> The only viable "fix" I can see is by preallocating and recycling all
>> buffers instead of the repeated allocations done by usbnet now.  But
>> that's a major refactoring of usbnet.
>> 
>> The log message spam could of course be fixed, but the rate-limiting is
>> "good enough".
>
> How is anyone supposed to know what "kevent 2" is though?

By looking it up in include/linux/usb/usbnet.h :)

Yes, that could certainly be improved by translating the number back to
a readable description.  

> The drivers that support batching into large RX buffers should
> automatically fall back to smaller buffers if this happens, or whenever
> they're running on a small (for some definition of small) machine.  I
> understand that the dynamic fallback may be tricky though.

I don't think the smsc95xx use any large buffers.  Looks like it's an
ethernet packet + 12 bytes.  And usbnet limits the total rx queue to
60 * 1518 bytes.


Bjørn

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

[Bjørn Mork]

Ben Hutchings  writes:
> On Sun, 2016-04-10 at 11:15 -0700, Vagrant Cascadian wrote:
>> It works for the most part, but floods syslog with messages:
>> 
>> [501966.870273] net_ratelimit: 35702 callbacks suppressed
>> [501966.875438] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
>> 
>> It seems to function ok, though I'm not sure if there's degraded
>> network performance...
> [...]
>
> I understand network performance on all RPi models is poor due to lack
> of a built-in Ethernet MAC and the poor design of the USB interface.
> Also that message is a generic error message from the usbnet core and
> is not specific to the smsc95xx driver.

Yes, kevent 2 is "EVENT_RX_MEMORY", and this error affects any usbnet
based device under memory pressure.  The usbnet framework just doesn't
handle the case where GFP_KERNEL allocations fail. How could it? 

The only viable "fix" I can see is by preallocating and recycling all
buffers instead of the repeated allocations done by usbnet now.  But
that's a major refactoring of usbnet.

The log message spam could of course be fixed, but the rate-limiting is
"good enough".


Bjørn

Bug#820176: 3.16.7-ckt25-1: BUG: unable to handle kernel paging request (when connecting a USB device)

[Bjørn Mork]

Ben Hutchings <b...@decadent.org.uk> writes:
> On Wed, 2016-04-06 at 16:51 +0200, Bjørn Mork wrote:
>> Antonis Christofides <anth...@itia.ntua.gr> writes:
>> 
>> > 
>> > Apr  5 13:32:47 thames kernel: [86003.993994] BUG: unable to handle kernel 
>> > paging request at eba40a800380
>> > Apr  5 13:32:47 thames kernel: [86003.994005] IP: [] kfree+0x76/0x220
>> ..
>> > 
>> > Apr  5 13:32:47 thames kernel: [86003.994679] Call Trace:
>> > Apr  5 13:32:47 thames kernel: [86003.994689]  [] ? 
>> > usb_release_bos_descriptor+0x1d/0x40 [usbcore]
>> I believe this bug is fixed by commit e5bdfd50d6f7 ("Revert "usb: hub:
>> do not clear BOS field during reset device"") in mainline.  Don't know
>> the stable status of that.  I don't see it in v3.16.x yet.  I assume Ben
>> keeps track of it :)
>
> The crash after disconnection certainly seems like it could be fixed by
> that.  But the rapid disconnections (at 13:31:32 and 13:32:47) appear
> to be a different bug.

Yes.  My guess would be a voltage dip since it happens when spinning up
the disk.  There is little the host can do about USB disconnects anyway.
That's a device hardware or firmware issue. It won't help tracking it as
a kernel bug.

I would start by adding more power, using an external power supply if
supported or a split USB cable drawing power from 2 ports.


Bjørn

Bug#820176: 3.16.7-ckt25-1: BUG: unable to handle kernel paging request (when connecting a USB device)

[Bjørn Mork]

Antonis Christofides  writes:

> Apr  5 13:32:47 thames kernel: [86003.993994] BUG: unable to handle kernel 
> paging request at eba40a800380
> Apr  5 13:32:47 thames kernel: [86003.994005] IP: [] 
> kfree+0x76/0x220
..
> Apr  5 13:32:47 thames kernel: [86003.994679] Call Trace:
> Apr  5 13:32:47 thames kernel: [86003.994689]  [] ? 
> usb_release_bos_descriptor+0x1d/0x40 [usbcore]

I believe this bug is fixed by commit e5bdfd50d6f7 ("Revert "usb: hub:
do not clear BOS field during reset device"") in mainline.  Don't know
the stable status of that.  I don't see it in v3.16.x yet.  I assume Ben
keeps track of it :)


Bjørn

Bug#820061: linux-image-amd64: kernel hangs since debian 8.4

[Bjørn Mork]

Benoît Tonnerre  writes:

> Apr  4 18:52:55 pci003-01 kernel: [   79.329223] RIP: 
> 0010:[]
> [] radeon_fence_ref+0xd/0x50 [radeon]
> Apr  4 18:52:55 pci003-01 kernel: [   79.330192] RSP: 0018:88003639fb18
> EFLAGS: 00010292
> Apr  4 18:52:55 pci003-01 kernel: [   79.331154] RAX:  RBX:
> 8802218f55f8 RCX: 8802218f4d08
> Apr  4 18:52:55 pci003-01 kernel: [   79.332125] RDX: 0001 RSI:
>  RDI: 
> Apr  4 18:52:55 pci003-01 kernel: [   79.333110] RBP: 8802218f5550 R08:
> 8802218f4000 R09: 
> Apr  4 18:52:55 pci003-01 kernel: [   79.334119] R10: 0002 R11:
> 88003639fe08 R12: 0020
> Apr  4 18:52:55 pci003-01 kernel: [   79.335117] R13: 88003639fbe0 R14:
> 88003639fbb0 R15: 8802218f55f8
> Apr  4 18:52:55 pci003-01 kernel: [   79.336120] FS:  7fd8f5323980()
> GS:88022dc6() knlGS:
> Apr  4 18:52:55 pci003-01 kernel: [   79.337143] CS:  0010 DS:  ES: 
> CR0: 80050033
> Apr  4 18:52:55 pci003-01 kernel: [   79.338142] CR2: 0008 CR3:
> 000223b3e000 CR4: 000407e0
> Apr  4 18:52:55 pci003-01 kernel: [   79.339125] Stack:
> Apr  4 18:52:55 pci003-01 kernel: [   79.340065]  a04900bc
> 0020 eea00100 88003639fcd0
> Apr  4 18:52:55 pci003-01 kernel: [   79.341006]  8802218f4000
> 8802216c0a20 8802216c0a20 0001
> Apr  4 18:52:55 pci003-01 kernel: [   79.341952]  
>   
> Apr  4 18:52:55 pci003-01 kernel: [   79.342899] Call Trace:
> Apr  4 18:52:55 pci003-01 kernel: [   79.343854]  [] ?
> radeon_sa_bo_new+0x25c/0x460 [radeon]

I believe this is fixed by commit f80be5a9b1cc ("Revert "drm/radeon:
hold reference to fences in radeon_sa_bo_new"") in v3.16.7-ckt26.


Bjørn

Bug#767088: /boot/vmlinuz-3.16-3-amd64: Please add backported iwlwifi firmware debugging features

[Bjørn Mork]

Package: src:linux
Version: 3.16.5-1
Severity: wishlist
File: /boot/vmlinuz-3.16-3-amd64
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Is it possible to get the iwlwifi firmware debugging feature from v3.17
into the Jessie kernel?  Emmanuel has provided a v3.16 backport patch
series here: http://www.spinics.net/lists/linux-wireless/msg128672.html

This feature is useful when debugging/reporting problems related
to the driver/firmware interface.  Having the feature in the Jessie
kernel can save Debian end users from having to upgrade the kernel
just to report iwlwifi firmware bugs.


Thanks,
Bjørn


- -- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 2776LEG
product_version: ThinkPad X301
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: 6EET55WW (3.15 )
board_vendor: LENOVO
board_name: 2776LEG
board_version: Not Available

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory 
Controller Hub [8086:2a40] (rev 07)
Subsystem: Lenovo Device [17aa:20e0]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort+ SERR- PERR- INTx-
Latency: 0
Capabilities: access denied
Kernel driver in use: agpgart-intel

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Device [17aa:20e4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 28
Region 0: Memory at f000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at d000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 1800 [size=8]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915

00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller [8086:2a43] (rev 07)
Subsystem: Lenovo Device [17aa:20e4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Region 0: Memory at f040 (64-bit, non-prefetchable) [size=1M]
Capabilities: access denied

00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series 
Chipset MEI Controller [8086:2a44] (rev 07)
Subsystem: Lenovo Device [17aa:20e6]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx+
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: Memory at f0826800 (64-bit, non-prefetchable) [size=16]
Capabilities: access denied

00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network 
Connection [8086:10f5] (rev 03)
Subsystem: Lenovo Device [17aa:20ee]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 30
Region 0: Memory at f060 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at f0625000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at 1840 [size=32]
Capabilities: access denied
Kernel driver in use: e1000e

00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #4 [8086:2937] (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device [17aa:20f0]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 20
Region 4: I/O ports at 1860 [size=32]
Capabilities: access denied
Kernel driver in use: uhci_hcd

00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #5 [8086:2938] (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device [17aa:20f0]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- 

Bug#764263: linux-image-3.16-2-amd64: WARNING at drivers/base/firmware_class.c:1109 _request_firmware+0x521/0xaf0() [btusb?]

[Bjørn Mork]

Ben Hutchings b...@decadent.org.uk writes:

 On Mon, 2014-10-06 at 20:15 +0200, Julien Cristau wrote:
 Package: src:linux
 Version: 3.16.3-2
 Severity: normal
 
 Hi,
 
 I get the following trace in my kernel log, which I don't think I've
 seen in pre-3.16 versions:
 
 Sep 29 19:12:49 betterave kernel: [ 7696.920600] PM: resume of devices 
 complete after 508.149 msecs
 Sep 29 19:12:49 betterave kernel: [ 7696.921181] [ cut here 
 ]
 Sep 29 19:12:49 betterave kernel: [ 7696.921188] WARNING: CPU: 2 PID: 3533 
 at /build/linux-P15SNz/linux-3.16.3/drivers/base/firmware_class.c:1109 
 _request_firmware+0x521/0xaf0()
 [...]
 Sep 29 19:12:49 betterave kernel: [ 7696.921405]  [813af8ac] ? 
 request_firmware+0x2c/0x40
 Sep 29 19:12:49 betterave kernel: [ 7696.921412]  [a065f895] ? 
 btusb_setup_bcm_patchram+0x85/0x430 [btusb]
 Sep 29 19:12:49 betterave kernel: [ 7696.921419]  [813a663a] ? 
 rpm_check_suspend_allowed+0x6a/0xc0
 [...]
 Sep 29 19:12:49 betterave kernel: [ 7696.921528] bluetooth hci0: firmware: 
 brcm/BCM20702A0-0a5c-21e6.hcd will not be loaded
 [...]

 This means: btusb tries to load firmware during its resume operation,
 when userland is not yet available.  This doesn't work if firmware
 loading depends on the userland firmware agent.

 The warning won't appear if the firmware is installed in the usual
 place, as direct loading will work.  And the firmware agent is npw
 deprecated and not even enabled in Debian kernels.  We could remove this
 warning, but it would be papering over a driver bug.

Are you sure about this?  FWIW I've occasionally seen similar warnings
from another btusb device with firmware (using kernels I've built
myself, so not reported here of course). And I haven't really bothered to
look at the root cause before, so I haven't reported it upstream either.

But looking at _request_firmware() now it seems to me that this warning
is triggered _before_ we attempt any direct loading:


_request_firmware(const struct firmware **firmware_p, const char *name,
  struct device *device, unsigned int opt_flags)
{

..
if (opt_flags  FW_OPT_NOWAIT) {
timeout = usermodehelper_read_lock_wait(timeout);
if (!timeout) {
dev_dbg(device, firmware: %s loading timed out\n,
name);
ret = -EBUSY;
goto out;
}
} else {
ret = usermodehelper_read_trylock();
if (WARN_ON(ret)) {
dev_err(device, firmware: %s will not be loaded\n,
name);
goto out;
}
}

ret = fw_get_filesystem_firmware(device, fw-priv);

 

That's the WARN_ON() we are hitting, as can be seen by the error message
following the warning.  So we fail to get the usermodehelper read lock
(why do we need that?) and bail out before even attempting the direct
loading.

I will not claim I understand any of this.  But the warning is
definitely triggered on some resumes, with firmware in the usual place
and without the firmware agent being enabled.


Bjørn


--
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/8738b02vr1@nemi.mork.no

Re: Enabling MBIM in Debian

[Bjørn Mork]

Ben Hutchings b...@decadent.org.uk writes:

 Starting with linux version 3.8.2-1~experimental.1 we've included the
 new cdc_mbim driver for MBIM (Mobile Broadband Interface Model).

 Newer modems support both NCM or MBIM, but only one at a time, selected
 by the kernel drivers.  For compatibility with current userland, the
 kernel has been changed in version 3.8.5-1~experimental.1 to prefer NCM.
 Once your package has support for MBIM, you should enable it in the
 kernel by installing a uniquely named file in /lib/modprobe.d
 containing:

 options cdc_ncm prefer_mbim=Y

Just FYI: There is now a set of modems which claim to support a NCM/MBIM
backwards compatible function, but where we do not know how to use the
NCM variant. Or even if it is actually supportable at all - there is no
evidence that any other OS uses it.

The implication is that the 'prefer_mbim=Y' configuration shown above is
*required* to make these modems work in Jessie.  ModemManager will
otherwise fail to recognise and manage them.

The most common example of such a modem is the Sierra Wireless EM7345,
used by Lenovo in their current range of Thinkpad T and X series
laptops. These are popular enough to make me expect this problem to
become a FAQ once Jessie is out.

Unfortunately I did not anticipate this situation when adding the module
parameter in the first place.  I stupidly assumed that we would be able
to support both NCM and MBIM modes for all modems which claimed such
dual support. There is therefore no way to make a per-device setting of
this option in the 3.16 kernel.

Sorry about this mess... Suggestions on how to improve/fix it (both for
mainline and for the Jessie kernel) are appreciated.


Bjørn (who just stumbled into this while testing out the 3.16 kernel in
experimental)


--
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/871tsngpoz@nemi.mork.no

Re: Bug#753816: [systemd] Broken audio

[Bjørn Mork]

Michael Biebl bi...@debian.org writes:

 Be aware that systemd-modules-load does *not* read module parameters
 from /etc/modules. You'll need to set them via a /etc/modprobe.d/ file.

Hmm... Is that considered a bug, or is it just the way things are going
to be?

The modules(5) man page from the kmod package still says

   The /etc/modules file contains the names of kernel modules that
   are to be loaded at boot time, one per line. Arguments can be
   given in the same line as the module name. Lines beginning with a
   '#' are ignored.

and I would expect a few might have used that feature in the past. It
seems unnecessary to break such configurations.


Bjørn


-- 
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/87oax2s3oq@nemi.mork.no

Re: Netconsole scripts for Debian

[Bjørn Mork]

Pavel Odintsov pavel.odint...@gmail.com writes:

 Hello!

 At now I configure netconsole dynamically and got network
 configuration from ip route command. For getting netconsole server MAC
 address I use arping to it.

 But I can generate modprobe configuration file with current
 configuration and integrate it to initrd.

 You can check my approach here:
 1) On first netconsole script start I can get netconsole collector IP
 and MAC address (of destination server or gateway for current server)

The MAC address is optional and should be so in your package too.

 2) I create /etc/modprobe.d/netconsole.conf configuration with fixed
 MAC, PORT and IP of netconsole server

Why?  You have to load the module from a script anyway, so you could just
set the options there.

 3) I add netconsole to initramfs configuration file
 (/etc/initramfs-tools/modules) with fixed IP/MAC configuration
 4) I rebuild initramfs for current kernel: update-initramfs -v -u -k
 `uname -r` -t
 5) On every system run I will check if MAC/IP of destination server
 was changes I will reconfigure netconsole modprobe.conf file and
 rebuilt initrd.

There is already netconsole= cmdline support in initramfs-tools.
Whatever you add should integrate nicely with this IMHO.



Bjørn


-- 
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/87ionxq9vt@nemi.mork.no

Re: Netconsole scripts for Debian

[Bjørn Mork]

Ritesh Raj Sarraf r...@debian.org writes:

 On 06/17/2014 03:00 PM, Pavel Odintsov wrote:
 Hello, folks!
 
 I'm prepared and thoroughly tested scripts for managing netconsole
 kernel facility in Debian 6/7. Netconsole facility is very useful for
 debugging kernel bugs.
 
 These scripts are inspired by CentOS 6 netconsole scripts in some
 cases and work in same way. Scripts are written in clean bash.
 
 All scripts and configuration you can find here:
 https://github.com/FastVPSEestiOu/debian_netconsole
 
 Yes, it's possible to configure netconsole statically (i.e. as
 /etc/modprobe.d/netconsole.conf) but it's a bad way because it relies
 on network configuration (i.e. gateway address, server address) which
 may be changed and netconsole will not work.
 
 I tested both startup option:
 1) As /etc/init.d/netconsole
 2) As /etc/network/if-up.d/netconsole script
 
 IMHO, the first variant is more reliable and convenient for this task.
 But both variants have some troubles because some network cards (like
 e1000) call /etc/network/if-up.d and /etc/init.d scripts on network
 level BEFORE real network initialization.
 
 I fixed this issue only by adding fixed timeout in my
 /etc/init.d/netconsole script. In the same way this issue was fixed in
 RH. Maybe you can provide more convenient solution?
 
 Thank you for any feedback!
 


 You should add support for it in initrd. netconsole is more useful at
 that stage. In real boot, why would one want netconsole if syslog is
 running.

To debug a driver/kernel crash.

netconsole is generally a very useful feature for oops debugging on
laptops and other devices with no serial ports.  Having some scripts
making it simpler to configure sounds like a great idea.  Will these
depend on configfs being mounted? Or are they only using module
parameters?



Bjørn


--
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/87ppi6sfma@nemi.mork.no

Bug#730065: document new_id interface

[Bjørn Mork]

Geert Stappers stapp...@stappers.nl writes:

 Package: debian-kernel-handbook
 Version: 1.0.15
 Severity: wishlist

 Op 2013-11-17 om 12:28 schreef Bastian Blank:
 
 snip/  Also you want to use new_id interface[1] if possible.
 
 Bastian
 
 [1]: /sys/class/usb/drivers/*/new_id
  http://www.ha19.no/usb/

 Adding that URL to the kernel-handbook would be an improvement.

 Now filed as a separate bugreport.

well, you should note that this interface will not necessarily work for
all drivers despite being available.  If you take a look at the
sunplus.c file for example, you'll notice that the struct usb_device_id
table sets the .driver_info field.  This field will be 0 for dynamically
added device IDs.  Whether or not the driver does anything useful in
this case depends on how the driver probe is written.

But other than that, I am fully in favour of documenting the new_id
interface, preferably with a note to contact the upstream driver
maintainer with information about the devices you add.  Or maybe a
wishlist bug if the new_id interface is there but unsupported.



Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ob5etffh@nemi.mork.no

Bug#728535: which size increment to expect

[Bjørn Mork]

Geert Stappers stapp...@stappers.nl writes:
 Op 2013-11-17 om 11:15 schreef Geert Stappers:
 Op 2013-11-17 om 10:55 schreef Geert Stappers:
  
  Edit on the kernel module source file, to add USB ID.
  
  Executed `fakeroot debian/rules binary-arh
  Produced a same size .ko, but it should be bigger due the extra USB ID
 
 Is it correct to expect an increase in size of the .ko with a few bytes?
 
 Or is size increment in steps of 256 of 1024 bytes?
 

 Answer on my question:

 Yes, adding in .c source a line with VendorID and ProductID
 does increase the .ko module. In my case 120 bytes. 
 So no increment in steps of 256 or 1024 bytes.


 $ filtered ls -l  output
 -rw-r--r-- 1 root root  23144 Nov 15 20:55 
 /lib/modules/3.11-1-amd64/kernel/drivers/media/usb/gspca/gspca_sunplus.ko
 -rw-r--r-- 1 stappers stappers  23264 Nov 17 14:40 
 /home/stappers/src/linux/linux-3.11.5-goed/debian/linux-image-3.11-1-amd64/lib/modules/3.11-1-amd64/kernel/drivers/media/usb/gspca/gspca_sunplus.ko


If I understand you correctly, you want to build a modified version of
gspca_sunplus.ko for your Debian 3.11-1-amd64 kernel?

You do not need to rebuild the whole kernel to do that.  You can build
your modified driver like it was an out-of-tree module:

 apt-get install linux-headers-3.11-1-amd64
 make -C /lib/modules/3.11-1-amd64/build 
SUBDIRS=/home/stappers/src/linux/linux-3.11.5-goed/drivers/media/usb/gspca 
gspca_sunplus.ko
 rmmod gspca_sunplus
 insmod 
/home/stappers/src/linux/linux-3.11.5-goed/drivers/media/usb/gspca/gspca_sunplus.ko

(this module is probably much bigger than the original due to debug
symbols not being stripped)

Now, if that worked then you might want to install it in place of the
original gspca_sunplus.ko module.  The easiest way to do that is

 mkdir /lib/modules/3.11-1-amd64/updates
 cp 
/home/stappers/src/linux/linux-3.11.5-goed/drivers/media/usb/gspca/gspca_sunplus.ko
 /lib/modules/3.11-1-amd64/updates
 depmod -a

It will now override the other gspca_sunplus.ko module for this kernel
version, even if you upgrade the kernel.  But if the kernel ABI changes,
then you will have to repeat the procedure for the new version.  That's
of course a feature...

And please: If you do stuff like this, and it works, then do report your
success back to the upstream maintainer! They will usually want to add
the new device IDs to the driver. Such changes are normally backported
to stable kernels, and appearing in Debian kernels a few weeks later.
So by doing that, you ensure that you won't have to keep on rebuilding
the driver forever.

Note: The above procedure should never be necessary for any end user
unless their quest is to test a new device ID before sending the patch
upstream.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3g2tefl@nemi.mork.no

Bug#729801: linux-image-3.10-3-amd64: kernel module i2c-hid does not exist

[Bjørn Mork]

Ben Hutchings b...@decadent.org.uk writes:

 Can I compile the module by my own or can it be
 integrated into Debian?

 You might be able to compile the module but I can't provide simple
 instructions for this.

Since this is a simple driver with few dependencies, it seems to be as
simple as

 1) get a recent kernel source with the driver you want.  Mainline is
   fine, but you are safer if you stick with a stable release matching
   the Debian kernel you want to build it for.

 2) Install Debian kernel headers:
  apt-get install linux-headers-`uname -r`

 3) build the module:
  cd /where/you/put/the/kernelsrc
  make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd`/drivers/hid/i2c-hid 
CONFIG_I2C_HID=m 

 4) optionally copy the resulting module to /lib/modules
  mkdir -p /lib/modules/`uname -r`/extra
  cp drivers/hid/i2c-hid/i2c-hid.ko /lib/modules/`uname -r`/extra/
  depmod -a

 5) load it manually, or reboot to have it autoloaded if you've got the
ACPI device


 I will enable this for Linux 3.12.

Which of course is much better.  But the above should work until this is
available.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874n7ajc63@nemi.mork.no

Bug#726398: linux: Fail to work with USB wifi dongle TP-Link TL-WN725N V2 (USB id 0bda:8179)

[Bjørn Mork]

Petter Reinholdtsen p...@hungry.com writes:

 I just bought a USB wifi dongle and it fail to work with the Linux
 kernel in Debian Stable/Wheezy.  lsusb show this information about the
 device:

   Bus 001 Device 010: ID 0bda:8179 Realtek Semiconductor Corp.

 A similar device is mentioned in URL: http://bugs.debian.org/584945/ ,
 which was reported solved a while back.  I suspect this was version 1 of
 the dongle, using a different chipset.

 According to URL: http://www.elinux.org/RPi_USB_Wi-Fi_Adapters 
 version 1 of the TL-WN725N dongle should work out of the box in Linux,
 while version 2 require manual driver installation, see
 URL: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=26t=29752  for
 the details.  So there is source out there to get this working with
 Linux.  I hope to test it later today.

Just FYI:  This driver is also in staging, starting with v3.12-rc1:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/rtl8188eu


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87siw2pu73@nemi.mork.no

Bug#726398: linux: Fail to work with USB wifi dongle TP-Link TL-WN725N V2 (USB id 0bda:8179)

[Bjørn Mork]

Steve Cotton st...@s.cotton.clara.co.uk writes:

 On Tue, Oct 15, 2013 at 14:08 +0200, Petter Reinholdtsen wrote:
 Dear Maintainer,
 
 I just bought a USB wifi dongle and it fail to work with the Linux
 kernel in Debian Stable/Wheezy.  lsusb show this information about the
 device:
 
   Bus 001 Device 010: ID 0bda:8179 Realtek Semiconductor Corp.
  
 But I was hoping this dongle would work out of the box with Debian
 stable, or at least with the next stable (Jessie).  Can you add the
 driver to the kernel package to make this happen?

 Hi Petter,

 That device should work with kernel 3.10, module rtl8188ee.ko.

I doubt that.  r(tl)8188ee is a PCI-E chip and driver.  The USB version
is r(tl)8188eu. See http://wireless.kernel.org/en/users/Drivers/rtl819x
for the full overview.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d2n6pps0@nemi.mork.no

Bug#723761: irq 16: nobody cared errors for the mptsas driver

[Bjørn Mork]

Marco d'Itri m...@linux.it writes:

 Package: src:linux
 Version: 3.2.46-1+deb7u1
 Severity: normal

 This is an IBM x3250 server.

 At boot time I get:

 [7.160384] scsi2 : ioc0: LSISAS1064E B1, FwRev=0110h, Ports=1, 
 MaxQ=511, IRQ=16
 [7.184758] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 5, 
 phy 0, sas_addr 0xdd61424dbd929f78
 [7.187410] scsi 2:0:0:0: Direct-Access ATA  WDC WD2500YS-23S 6C04 
 PQ: 0 ANSI: 5
 [7.189626] scsi 2:0:0:0: Attached scsi generic sg1 type 0
 [7.191026] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 1, 
 phy 1, sas_addr 0xdd61424dbe8a9e78
 [7.193670] scsi 2:0:1:0: Direct-Access ATA  WDC WD2500YS-23S 6C04 
 PQ: 0 ANSI: 5
 [7.195860] scsi 2:0:1:0: Attached scsi generic sg2 type 0
 [7.197245] mptsas: ioc0: attaching raid volume, channel 1, id 0
 [7.198152] scsi 2:1:0:0: Direct-Access LSILOGIC Logical Volume   3000 
 PQ: 0 ANSI: 2
 [7.205961] scsi 2:1:0:0: Attached scsi generic sg3 type 0

 [   10.683522] irq 16: nobody cared (try booting with the irqpoll option)


Don't know how to solve the bug, but wanted to tip about a workaround
I've been happy with (on a LSISAS1068E B3):  Adding

  options mptbase mpt_msi_enable_sas=1

to /etc/modprobe.d/somefile.conf makes the controller use MSI instead.

I haven't got the faintest idea why that's not the default setting for
these devices...



Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vc1w22ag@nemi.mork.no

Bug#721005: linux: sierra Gobi 3000 WWAN no longer works

[Bjørn Mork]

Christoph Anton Mitterer cales...@scientia.net writes:

 I'm having a Fujitsu Lifebook E782 which has some Sierra Gobi 3000
 UMTS modem in it.

 For many years it simply used to work perfectly, but a year ago or so it 
 already stopped
 working (i.e. wasn't detected anymore by the kernel)... but it came back 
 surprisingly
 around March that year and worked at least until May.

Could you relate this to kernel versions and/or BIOS upgrades?  It is
hard for anyone else to know exactly what you were doing in March last
year...

 Unfortunately I don't know when exactly it stopped worked since I use
 it only rarley when I'm on train.

I don't know that either, I'm afraid.


 # lsusb 
 Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 009: ID 04f2:b2fc Chicony Electronics Co., Ltd 
 Bus 001 Device 011: ID 0489:e052 Foxconn / Hon Hai 
 Bus 001 Device 010: ID 0b97:7772 O2 Micro, Inc. OZ776 CCID Smartcard Reader
 Bus 001 Device 003: ID 0b97:7761 O2 Micro, Inc. Oz776 1.1 Hub
 Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 Manually loading sierra or sierra_net doens't help either, but the
 device is enabled in the BIOS.

The device doesn't even show up, which really indicates either that
it isn't there or that the BIOS has powered it off.

Kernel logs might tell more about why the device is failing.  Who knows?

Does rfkill list say that the wwan device is enabled?  If so, then
this sounds like a problem with your laptop platform driver.  I assume
that is fujitsu-laptop?  Hmm, that hasn't changed in ages, so I don't
think we'll find any explanation there.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ioyr74bp@nemi.mork.no

Bug#628444: iwlagn - MAC is in deep sleep, cannot restore wifi operation

[Bjørn Mork]

Shannon Dealy de...@deatech.com writes:

 I have not seen this problem or any of the other iwl instabilities in
 a long time, however, I have been running with these option lines
 disabling 11n functionality in order to achieve that stability:

 options iwlagn 11n_disable50=1
 options iwlwifi 11n_disable=1

 since I am no longer running kernels which use iwlagn (currently
 running 3.2.xx), I can't really speak to the original issue anymore.
 Of course iwlwifi has had 11n related stability issues as well,
 however, I have never seen the:

   MAC is in deep sleep

 bug (as far as I can recall) while running a newer kernel with iwlwifi
 instead of iwlagn.  Not sure how much code (if any) is common between
 iwlwifi and the older iwlagn module.

AFAIK the code printing that particular error message is still the same
in 3.2. The error message was changed and a stack trace was added in
v3.4, so you have to look for another message if testing newer kernels:


commit aa5affbacb24cb5d8fd6f7c66e57d62164ed6d34
Author: Stanislaw Gruszka sgrus...@redhat.com
Date:   Wed Mar 7 09:52:23 2012 -0800

iwlwifi: dump stack when fail to gain access to the device

Print dump stack when the device is not responding. This should give
some more clue about the reason of failure. Also change the message we
print, since MAC in deep sleep is kinda confusing.

On the way add unlikely(), as fail to gain NIC access is hmm ...
unlikely.

Signed-off-by: Stanislaw Gruszka sgrus...@redhat.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
Signed-off-by: Wey-Yi Guy wey-yi.w@intel.com
Signed-off-by: John W. Linville linvi...@tuxdriver.com

diff --git a/drivers/net/wireless/iwlwifi/iwl-io.c 
b/drivers/net/wireless/iwlwifi/iwl-io.c
index e2e3b5c..fc36535 100644
--- a/drivers/net/wireless/iwlwifi/iwl-io.c
+++ b/drivers/net/wireless/iwlwifi/iwl-io.c
@@ -121,10 +121,10 @@ int iwl_grab_nic_access_silent(struct iwl_trans *trans)
 int iwl_grab_nic_access(struct iwl_trans *trans)
 {
int ret = iwl_grab_nic_access_silent(trans);
-   if (ret) {
+   if (unlikely(ret)) {
u32 val = iwl_read32(trans, CSR_GP_CNTRL);
-   IWL_ERR(trans,
-   MAC is in deep sleep!. CSR_GP_CNTRL = 0x%08X\n, val);
+   WARN_ONCE(1, Timeout waiting for hardware access 
+(CSR_GP_CNTRL 0x%08x)\n, val);
}
 
return ret;



This code has since been refactored and moved into
drivers/net/wireless/iwlwifi/pcie/trans.c but the Timeout waiting for
hardware access message is still there.

 I suppose I should try enabling 11n again to see what happens (I had
 forgotten it was disabled).

Time to move on to 11ac now :)


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppte7rg9@nemi.mork.no

Bug#719623: linux-image-3.10-2-amd64: kernel panic on inserting DVB-T stick

[Bjørn Mork]

] ? do_IRQ+0x40/0x95
[  846.863906]  [813883ed] ? common_interrupt+0x6d/0x6d
[  846.863906]  EOI
[  846.863906]
[  846.863906]  [812a011c] ? arch_local_irq_enable+0x4/0x8
[  846.863906]  [812a04f3] ? cpuidle_enter_state+0x52/0xc1
[  846.863906]  [812a0636] ? cpuidle_idle_call+0xd4/0x143
[  846.863906]  [8101398c] ? arch_cpu_idle+0x5/0x17
[  846.863906]  [81072571] ? cpu_startup_entry+0x10d/0x187
[  846.863906]  [816b3d3d] ? start_kernel+0x3e8/0x3f3
[  846.863906]  [816b3777] ? repair_env_string+0x54/0x54
[  846.863906]  [816b3598] ? x86_64_start_kernel+0xf2/0xfd
[  846.863906] Code: 25 09 00 00 c6 83 da 08 00 00 03 8b 45 54 48 01 83 b6 08 00 00 8b 45 50 48 01 83 db 08 00 00 8b 4d 18 69 c1 ff ff 00 00 03 4d 14 48 f7 f1 89 83 a8 09 00 00 e9 68 fe ff ff 48 8b 7f 10 e8 79 92
[  846.863906] RIP  [a092be0c] smsdvb_onresponse+0x264/0xa86 [smsdvb]
[  846.863906]  RSP 88013bc03cf0

Reported-by: Johannes Rohr jor...@gmail.com
Reference: http://bugs.debian.org/719623
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Signed-off-by: Bjørn Mork bj...@mork.no
---
 drivers/media/common/siano/smsdvb-main.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/common/siano/smsdvb-main.c b/drivers/media/common/siano/smsdvb-main.c
index 0862622..63676a8 100644
--- a/drivers/media/common/siano/smsdvb-main.c
+++ b/drivers/media/common/siano/smsdvb-main.c
@@ -276,7 +276,8 @@ static void smsdvb_update_per_slices(struct smsdvb_client_t *client,
 
 	/* Legacy PER/BER */
 	tmp = p-ets_packets * 65535;
-	do_div(tmp, p-ts_packets + p-ets_packets);
+	if (p-ts_packets + p-ets_packets)
+		do_div(tmp, p-ts_packets + p-ets_packets);
 	client-legacy_per = tmp;
 }
 
-- 
1.7.10.4

Bug#717005: firmware-iwlwifi: Missing iwlwifi-3160-6.ucode and iwlwifi-7260-6.ucode

[Bjørn Mork]

Ben Hutchings b...@decadent.org.uk writes:

 These files are for firmware ABI version 6, which apparently was never
 released.  There are firmware files for these chips with ABI version 7.
 I'll add that firmware and update the driver so that's what it expects.

Thanks for doing that.  It's not clear to me whether you got the 3.10
patches tested or not.  But in case not:  I can confirm that the

 3.10-2-amd64 #1 SMP Debian 3.10.5-1 (2013-08-07) x86_64 GNU/Linux

kernel works fine with one of these newer cards:

bjorn@nemi:~$ dmesg|grep iwlwifi
[3.271503] iwlwifi :03:00.0: irq 45 for MSI/MSI-X
[3.350516] iwlwifi :03:00.0: firmware: agent loaded 
iwlwifi-7260-7.ucode into memory
[3.351572] iwlwifi :03:00.0: loaded firmware version 22.0.7.0 op_mode 
iwlmvm
[3.456373] iwlwifi :03:00.0: Detected Intel(R) Dual Band Wireless 
AC7260, REV=0x144
[3.456490] iwlwifi :03:00.0: L1 Disabled; Enabling L0S
[3.456694] iwlwifi :03:00.0: L1 Disabled; Enabling L0S
[3.580400] iwlwifi :03:00.0: NVM section 0 read completed
[3.580453] iwlwifi :03:00.0: NVM section 1 read completed
[3.580502] iwlwifi :03:00.0: NVM section 4 read completed
[3.580564] iwlwifi :03:00.0: NVM section 5 read completed




Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878v05rc3k@nemi.mork.no

Bug#714754: firmware-iwlwifi: please include iwlwifi-7260-7.ucode and iwlwifi-3160-7.ucode

[Bjørn Mork]

Package: firmware-iwlwifi
Version: 0.38
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The new Intel 7260 and 3160 cards require new firmware. Patch is
available upstream:
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/109724

Please add.  Thanks,
Bjørn

- -- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10.0 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.113
ii  linux-image-3.10.0 [linux-image] 3.10.0-123
ii  linux-image-3.10.0-rc7 [linux-image] 3.10.0-rc7-122
ii  linux-image-3.2.0-4-amd64 [linux-image]  3.2.46-1
ii  linux-image-3.9-1-amd64 [linux-image]3.9.8-1

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlHS38MACgkQ10rqkowbIskioQCfSXzHK/oTmCb8Kx3GT9NKgrBP
ByQAoIWYXqiM0gWY0Pe5mNahZDNWMcHG
=K3HG
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130702141221.18249.40086.report...@nemi.mork.no

Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))

[Bjørn Mork]

Tomasz Figa tomasz.f...@gmail.com
writes:

 Seeing from your posts you don't have any knowledge on how Linux kernel 
 development works and even on how Allwinner's cooperation with our 
 community looks (and seem to be completely closed to our effort of showing 
 you the reality), so I'm not sure if you are the right person to take any 
 of those roles...

Try googling for Luke Leighton troll.  The pattern is some lengthy
semi-technical post, followed by very long threads with no substance
whatsoever.  It seems like some sick joke trying to waste as much time
for as many people as possible.

He's even become an -ENOPATCH example:
http://linuxmafia.com/~rick/lexicon.html#enopatch


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87li6mxlcr@nemi.mork.no

Bug#710883: /boot/vmlinuz-3.2.0-4-amd64: iptables PREROUTING match on bridge VLAN interfaces stopped working between 2.6.32 and 3.2

[Bjørn Mork]

Package: src:linux
Version: 3.2.41-2+deb7u2
Severity: minor
File: /boot/vmlinuz-3.2.0-4-amd64

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

Intercepting http traffic entering VLAN tagged on a bridge interface
stopped working after upgrading from Squeeze to Wheezy.

I assume this is an upstream issue, and that it may be fixed upstream
with the introduction of the bridge-nf-pass-vlan-input-dev sysctl.
This does however not seem easily backported to v3.2, as it is based
on other changes to the VLAN/bridge stacking logic.

I have not bothered verifying these assumptions, but have instead
implemented a workaround which is acceptable to me.  Based on this I
do not expect anyone else to use any time investigating this issue.  I
report this bug mostly to document the issue in case someone else
hits it.  Please close or leave open as you find best.

My original setup from squeeze was (simplified and anonymized):

auto br0
iface br0 inet manual
 bridge_ports eth1
 up sysctl -w net.bridge.bridge-nf-filter-vlan-tagged=0

auto br0.7
iface br0.7 inet static
 vlan-raw-device br0
 address 192.168.0.1
 netmask 255.255.255.0

Setting bridge-nf-filter-vlan-tagged=0 used to be the trick to make
iptables match against VLANs stacked on bridge interfaces work. I
was using a rule like this to redirect all http traffic to a local
squid server:

 iptables -t nat -A PREROUTING -i br0.7 -p tcp --dport 80 -j REDIRECT --to-port 
3128

But with wheezy this stopped matching.  Enabling a bit of logging
showed that no packets ever appeared with source interface br0.7 in
the PREROUTING chain.  They all had br0 as source interface 
regardless of VLAN tag (used icmp for the log rule, but the results
are similar for tcp and udp):

[862122.574098] IN=br0 OUT= PHYSIN=eth1 
MAC=00:15:17:1e:5e:35:00:16:ea:b3:07:88:08:00 SRC=192.168.0.4 DST=91.195.8.200 
LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=10869 
SEQ=1 


Oddly enough, tagged packets entering the nat/INPUT chain from the
same source would appear twice, once with br0 and once with br0.7
as source interface (both lines triggered by the same packet):

[862660.693281] IN=br0 OUT= PHYSIN=eth1 
MAC=00:15:17:1e:5e:35:00:16:ea:b3:07:88:08:00 SRC=192.168.0.4 DST=192.168.0.1 
LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=10916 
SEQ=1 
[862660.925843] IN=br0.7 OUT= PHYSIN=eth1 
MAC=00:15:17:1e:5e:35:00:16:ea:b3:07:88:08:00 SRC=192.168.0.4 DST=192.168.0.1 
LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=10916 
SEQ=1 

I did briefly look through some of the changes between v2.6.32
and v3.2, but could spot any obvious cause of this change.

As a workaround I instead modified the rule to use br0 as source
interface, adding an IP source address match to mostly limit it
to packets from clients on VLAN 7.  I also had to add a dummy
address to the br0 interface because the REDIRECT target needs to
rewrite the destination  address.  Resulting workaround is:

auto br0
iface br0 inet static
 bridge_ports eth1
 address 192.168.255.1
 netmask 255.255.255.255

auto br0.7
iface br0.7 inet static
 vlan-raw-device br0
 address 192.168.0.1
 netmask 255.255.255.0


iptables -t nat -A PREROUTING -i br0 -p tcp -s 192.168.0.0/24 --dport 80 -j 
REDIRECT --to-port 3128


This is uglier than the original setup, bit it solves the task.



Bjørn

- -- 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.41-2+deb7u2

** Command line:
initrd=/initrd.img root=/dev/mapper/vg00-root ro console=tty0 
console=ttyS0,9600n8 BOOT_IMAGE=/vmlinuz 

** Not tainted

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlGsVdcACgkQ10rqkowbIslZbACdG8KnbJDTmUnhCGSWvfjNqzQ5
UwwAnApY8abIJW+RbErxLhVdhXNfCFU/
=qHjT
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130603083746.7455.9879.report...@canardo.mork.no

Bug#681092: linux-image-3.2.0-3-686-pae: Sierra WWAN modem not functioning

[Bjørn Mork]

Hello,

do you still have this problem?

I was looking at your log and the USB serial changes introduced around
the time you hit this, and one of the suspicious patches seem to be
mine...

This looks very wrong:

[3.075097] usbcore: registered new interface driver usbserial
[3.075139] USB Serial support registered for generic
[3.262423] [drm] initialized overlay support
[3.276289] usbserial_generic 6-1:1.0: generic converter detected
[3.276592] usb 6-1: generic converter now attached to ttyUSB0
[3.276876] usb 6-1: generic converter now attached to ttyUSB1
[3.277137] usb 6-1: generic converter now attached to ttyUSB2
[3.277178] usbcore: registered new interface driver usbserial_generic
[3.277185] usbserial: USB Serial Driver core
[3.279835] USB Serial support registered for Sierra USB modem
[3.279902] usbcore: registered new interface driver sierra
[3.279907] sierra: v.1.7.16:USB Driver for Sierra Wireless USB modems



Your modem should not match the generic converter.  It should match
the sierra driver.  But as you can see, the generic driver has already
bound to the three serial ports by the time the sierra driver is loaded,
so this won't happen.

Do you by any chance set the vendor and product usbserial
parameters manually somewhere?  That would explain the above log.  Look
for any usbserial entry in /etc/modules /etc/modprobe.d/*.conf or local
init scripts.  These are unnecessary and may cause problems.

But I still do not understand how this can prevent the modem from
working.  AFAICS it should still work, only at the slower generic serial
driver speed.  The change I introdcued in v3.2.20 should only affect
probing, and only the case where a device could end up being
unintentionally bound to the generic driver.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppw34kw8@nemi.mork.no

Bug#703356: megasas: Failed to alloc kernel SGL buffer for IOCTL (ref.#688198)

[Bjørn Mork]

Jean-Francois Chevrette jf.cr...@gmail.com writes:

 Package: src:linux
 Version: 3.2.39-2
 Severity: important

 (first time submiting to a bug report, sorry if I missed anything)

 We are still affected by bug #688198

Yes, I see that it was closed after applying a related bugfix.  But as I
noted in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688198#25 the
reported bug would not be fixed by this after all.  The fixed bug was
real, but unrelated to the reported one.

 We have other seemingly identical servers (hardware  software) and not
 all of them have this problem.

 Is there anything else I can provide to help?

The message indicates a memory allocation problem related to sending
management commands from userspace to the driver/controller.  Management
commands are e.g. requests from smartctl, raid monitoring etc.

All data transferred between these userspace applications and the
controller must be copied to/from dma-coherent buffers for transfer to
the controller, and it is the allocation of these buffers which fails.
Either because the requests are so bogus (too many or too big) that they
just cannot be serviced, or because the system is out of memory in the
appropriate pool.

Maybe we can get some ideas about why this fails if you describe the
conditions you experience the problem under.  I believe the fact that
you only see this on some of otherwise identical servers is very
interesting. If we could find some pattern here, then that would help.
Is there some special monitoring application running on the failing
servers?  Are there other devices in these servers which may have
drivers eating memory?

I can't, but maybe the Debian kernel gurus can read something out of 

 /proc/slabinfo 
 /proc/buddyinfo
 /proc/pagetypeinfo

Comparing those files on a failing server and a non-failing server would
certainly be interesting.



Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zjxz241l@nemi.mork.no

Bug#703356: megasas: Failed to alloc kernel SGL buffer for IOCTL (ref.#688198)

[Bjørn Mork]

Jean-Francois Chevrette jf.cr...@gmail.com writes:
 On Tue, Mar 19, 2013 at 4:21 AM, Bjørn Mork bj...@mork.no wrote:

 Maybe we can get some ideas about why this fails if you describe the
 conditions you experience the problem under.

 This server is running Xen 4.1 and a single VM. Nothing fancy there.
 It's also running DRBD to replicate a device to another server. It's
 also running a few userland tools for monitoring (nagios) and graphing
 (munin). Other than that nothing fancy.

 Nagios is the one calling MegaCli to monitor the array consistency.

 One thing to note is that after a server reboot, the MegaCli tool
 works fine for a while. This does sounds like there's leak somewhere.

 I just found out that this server is also running a service called
 MegaRAID Storage Manager which is a tool provided by LSI to manage the
 array through a java GUI. Maybe this tool is somehow causing this
 problem.

That sounds like a very likely suspect, yes.

 Stopping it didn't solve the problem. I'll try disabling the
 tool and reboot without ever starting it to see if the problem occurs
 again.

Good.  If that works then we probably should find out what this tool
does to trigger the problem, so that it can be handled properly by the
driver.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwtz1qma@nemi.mork.no

Bug#692607: linux-image-3.2.0-4-686-pae: Kernel crash when coming out of screen saver

[Bjørn Mork]

Ben Hutchings b...@decadent.org.uk writes:
 On Thu, 2013-02-28 at 11:31 +0100, Bjørn Mork wrote:

 Anyone able to spot the missing INIT_WORK()'s?  Based on the
 I915_HAS_HOTPLUG(dev) test, I assume that leaving the first one out was
 intentional.  But the second one cannot be left out, as demonstrated by
 these bug reports.

 Agreed.  And this is a faithful backport of the upstream change, i.e.
 the bug was not introduced in backporting.  However it seems to have
 been almost immediately fixed upstream by:

 commit 8b2e326dc7c5aa6952c88656d04d0d81fd85a6f8
 Author: Chris Wilson ch...@chris-wilson.co.uk
 Date:   Tue Apr 24 22:59:41 2012 +0100

 drm/i915: Unconditionally initialise the interrupt workers

Yup. That's the patch Steinar is currently testing.  Backported and
refreshed against the Debian 3.2.39-2 source.  Attached for your
convenience.

FWIW, I have no problems understanding how this bug could be missed
during backport.  There is nothing in the upstream commit messages
indicating that the second change fixes a serious bug or that there is a
strict dependency between these two changes.

 I am attaching a proposed fix on top of the 655152 patch, which I have
 not tested at all on actual Debian kernel sources.  Might need context
 adjustments.  I'd appreciate it if anyone with crashing hardware could
 test it.

 It applies and builds.

 Instructions for building a patched package are at:
 http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official

It was a long time since I last built a Debian kernel, and I was
positively surprised by the test-patches script.  I was not aware that
testing a patch on top of a Debian kernel would be as simple as
installing the source and running a script.  Thanks for making such
tasks so easy for end users.

But if I may request another feature for the script, then I believe a
fuzz option would have been useful.  Or a more lenient default than 0
at least. That's just annoyingly strict.



Bjørn
From 3738ac736bf08e589968d8b5af52cef409047472 Mon Sep 17 00:00:00 2001
From: Chris Wilson ch...@chris-wilson.co.uk
Date: Tue, 24 Apr 2012 22:59:41 +0100
Subject: [PATCH] drm/i915: Unconditionally initialise the interrupt workers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

commit 8b2e326dc7c5aa6952c88656d04d0d81fd85a6f8 upstream.

Rather than duplicate similar code across the IRQ installers, perform
the initialisation of the workers upfront. This will lead to simpler
teardown and quiescent code as we can assume that the workers have
been initialised.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
[bmork: deleted valleyview hunk for 3.2 backport]
Signed-off-by: Bjørn Mork bj...@mork.no
---
 drivers/gpu/drm/i915/i915_irq.c |   13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

Index: linux-3.2.39/drivers/gpu/drm/i915/i915_irq.c
===
--- linux-3.2.39.orig/drivers/gpu/drm/i915/i915_irq.c	2013-02-28 15:02:55.0 +0100
+++ linux-3.2.39/drivers/gpu/drm/i915/i915_irq.c	2013-02-28 15:07:25.882044365 +0100
@@ -1806,10 +1806,6 @@
 
 	atomic_set(dev_priv-irq_received, 0);
 
-	INIT_WORK(dev_priv-hotplug_work, i915_hotplug_work_func);
-	INIT_WORK(dev_priv-error_work, i915_error_work_func);
-	if (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
-		INIT_WORK(dev_priv-rps_work, gen6_pm_rps_work);
 
 	I915_WRITE(HWSTAM, 0xeffe);
 
@@ -1983,9 +1979,6 @@
 
 	atomic_set(dev_priv-irq_received, 0);
 
-	INIT_WORK(dev_priv-hotplug_work, i915_hotplug_work_func);
-	INIT_WORK(dev_priv-error_work, i915_error_work_func);
-
 	if (I915_HAS_HOTPLUG(dev)) {
 		I915_WRITE(PORT_HOTPLUG_EN, 0);
 		I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -2290,6 +2283,12 @@
 
 void intel_irq_init(struct drm_device *dev)
 {
+	struct drm_i915_private *dev_priv = dev-dev_private;
+
+	INIT_WORK(dev_priv-hotplug_work, i915_hotplug_work_func);
+	INIT_WORK(dev_priv-error_work, i915_error_work_func);
+	INIT_WORK(dev_priv-rps_work, gen6_pm_rps_work);
+
 	dev-driver-get_vblank_counter = i915_get_vblank_counter;
 	dev-max_vblank_count = 0xff; /* only 24 bits of frame count */
 	if (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {

Bug#701953: initramfs-tools: Missing modules prevent passphrase entry with usb keyboard

[Bjørn Mork]

Ben Caradoc-Davies ben.caradoc-dav...@csiro.au writes:

 Package: initramfs-tools
 Version: 0.109
 Severity: critical
 Justification: breaks the whole system

Others will have to decide on that, but it seems a bit high to me. This
is an experimental kernel and you do hopefully not try to install it
without keeping a working version as well?


 I have a usb keyboard attached to a system with an unencrypted /boot and a
 LUKS-encrypted partition (LVM physical volume) containing the other
 filesystems. Today I installed linux-image-3.8-trunk-amd64
 (3.8-1~experimental.1). initramfs-tools created a corresponding initrd, as
 expected. Booting this kernel/initrd in grub2 resulted in a plymouth 
 passphrase
 entry screen, but a usb keyboard that did not work in any port. All keyboard
 lights were off. The system was thus unbootable without a non-usb keyboard
 (hence critical severity). Without a non-usb keyboard or backup grub entry 
 (3.7
 kernel with working initrd), I would have been unable to access my system
 without rescue media.

 This is a regression from the behaviour of initramfs-tools with 
 linux-image-3.7
 -trunk-amd64 (3.7.8-1~experimental.1).

 The failure appears identical to this:
 http://linux-kernel.2935.n7.nabble.com/PROBLEM-3-8-0-rc4-keyboard-failure-at-
 boot-tp585937p587518.html

 Workaround is to add the following modules to /etc/initramfs-tools/modules, as
 described in the link above:

 ehci_pci

Right.  This is quite possibly a result of this bug:
http://bugs.debian.org/700572


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lia75yyp@nemi.mork.no

Bug#701869: linux-image-3.8-trunk-amd64: Please enable CONFIG_USB_NET_CDC_MBIM - new driver for Mobile Broadband modems

[Bjørn Mork]

Package: src:linux
Version: 3.8-1~experimental.1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

could you please enable this driver in 3.8 and later?

 bjorn@nemi:~$ grep MBIM /boot/config-3.8-trunk-amd64 
 # CONFIG_USB_NET_CDC_MBIM is not set

It supports CDC MBIM compliant Mobile Broadband devices. A userspace
management application is still required to actually use the driver.
This is planned for a yet unknown future ModemManager version.  There
are currently only developer-friendly tools available.

But these devices are generally not supportable in any other way, so
enabling the driver will not prevent any existing solution from working.
I therefore request that it is enabled now, hopefully accelerating the
userspace application development as soon as enough Debian developers
end up with one of these devices :)


Bjørn


- -- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 2776LEG
product_version: ThinkPad X301
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: 6EET55WW (3.15 )
board_vendor: LENOVO
board_name: 2776LEG
board_version: Not Available

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory 
Controller Hub [8086:2a40] (rev 07)
Subsystem: Lenovo Device [17aa:20e0]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort+ SERR- PERR- INTx-
Latency: 0
Capabilities: access denied
Kernel driver in use: agpgart-intel

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Device [17aa:20e4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 46
Region 0: Memory at f000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at d000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 1800 [size=8]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915

00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller [8086:2a43] (rev 07)
Subsystem: Lenovo Device [17aa:20e4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Region 0: Memory at f040 (64-bit, non-prefetchable) [size=1M]
Capabilities: access denied

00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series 
Chipset MEI Controller [8086:2a44] (rev 07)
Subsystem: Lenovo Device [17aa:20e6]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 42
Region 0: Memory at f0826800 (64-bit, non-prefetchable) [size=16]
Capabilities: access denied
Kernel driver in use: mei

00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network 
Connection [8086:10f5] (rev 03)
Subsystem: Lenovo Device [17aa:20ee]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 44
Region 0: Memory at f060 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at f0625000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at 1840 [size=32]
Capabilities: access denied
Kernel driver in use: e1000e

00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #4 [8086:2937] (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device [17aa:20f0]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 20
Region 4: I/O ports at 1860 [size=32]
Capabilities: access denied
Kernel driver in use: uhci_hcd

00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #5 

Bug#692607: linux-image-3.2.0-4-686-pae: Kernel crash when coming out of screen saver

[Bjørn Mork]

Dale Schroeder d...@briannassaladdressing.com writes:

 I've been able to narrow this down a bit more.  One of my other
 systems still had 3.2.0-3-686-pae (3.2.23-1) in its apt archives. This
 kernel also boots successfully and does not hang at mdm startup.  So,
 the problem did not exist in any of the 3.2.0-3 series released to
 Wheezy, but was introduced sometime between this image and 3.2.32-1,
 the 1st of the 3.2.0-4 series released to Wheezy.


I note that the changelog for

 linux (3.2.29-1) unstable; urgency=low

includes

   * [x86] drm/i915: Fix i8xx interrupt handling (Closes: #655152)

which is extremely suspiscious in this context.  I wonder if anyone
experiencing this bug has tried reverting this patch?:

 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=59;filename=drm-i915-i8xx-interrupt-handler.patch;att=1;bug=655152

Note that it is another shot in the dark - I have absolutely no idea
what's going on here.  But I have a feeling that patch is replacing an
annoying bug on one platform with a critical bug on another.

Not sure that is a good tradeoff...


The debug output kindly provided by Сергей in
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=36;filename=dmesg.txt;att=4;bug=692607
shows (don't know why I included work-entry - that's pointless):

 [   59.548011] work-data=0x, work-entry=de33c56c, work-entry.next= 
 (null), work-entry.prev=  (null)

which clearly tells us that the problem is related to
i915_handle_error() calling

queue_work(dev_priv-wq, dev_priv-error_work);

with an uninitialized error_work.  As noted earlier, this is supposed to
be initialized in intel_irq_init() so either that has not happend (yet?)
or something has zeroed it out later.

I am putting a beer on the first alternative.

Right.  It's even bloody obvious (no that you all have pointed to the
releases surrounding the 655152 bugfix).  That patch adds this i8xx
specific function:

+static void i8xx_irq_preinstall(struct drm_device * dev)
+{
+   drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
+   int pipe;
+
+   atomic_set(dev_priv-irq_received, 0);
+
+   for_each_pipe(pipe)
+   I915_WRITE(PIPESTAT(pipe), 0);
+   I915_WRITE16(IMR, 0x);
+   I915_WRITE16(IER, 0x0);
+   POSTING_READ16(IER);
+}

replacing this for all chips matching (INTEL_INFO(dev)-gen == 2):

static void i915_driver_irq_preinstall(struct drm_device * dev)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
int pipe;

atomic_set(dev_priv-irq_received, 0);

INIT_WORK(dev_priv-hotplug_work, i915_hotplug_work_func);
INIT_WORK(dev_priv-error_work, i915_error_work_func);

if (I915_HAS_HOTPLUG(dev)) {
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
}

I915_WRITE(HWSTAM, 0xeffe);
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0);
I915_WRITE(IMR, 0x);
I915_WRITE(IER, 0x0);
POSTING_READ(IER);
}


Anyone able to spot the missing INIT_WORK()'s?  Based on the
I915_HAS_HOTPLUG(dev) test, I assume that leaving the first one out was
intentional.  But the second one cannot be left out, as demonstrated by
these bug reports.

I am attaching a proposed fix on top of the 655152 patch, which I have
not tested at all on actual Debian kernel sources.  Might need context
adjustments.  I'd appreciate it if anyone with crashing hardware could
test it.



Bjørn
From d2451aff41d2db6047586c22317cd247e4c000ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= bj...@mork.no
Date: Thu, 28 Feb 2013 11:26:20 +0100
Subject: [PATCH] drm/i915: initialize error_work for i8xx interrupt handler
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The backport of upstream commit c2798b19bac2538393fc932bfbe59807a4734b3e
failed to initialize the error_work struct for gen2 hardware, resulting
in hitting a BUG in kernel/workqueue.c if/when the interrupt handler
tried to queue error handling work.

Signed-off-by: Bjørn Mork bj...@mork.no
---
 drivers/gpu/drm/i915/i915_irq.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 47b08ce..bb9b943 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2102,6 +2102,8 @@ static void i8xx_irq_preinstall(struct drm_device * dev)
 
 	atomic_set(dev_priv-irq_received, 0);
 
+	INIT_WORK(dev_priv-error_work, i915_error_work_func);
+
 	for_each_pipe(pipe)
 		I915_WRITE(PIPESTAT(pipe), 0);
 	I915_WRITE16(IMR, 0x);
-- 
1.7.10.4

Bug#692607: linux-image-3.2.0-4-686-pae: Kernel crash when coming out of screen saver

[Bjørn Mork]

Just an additional note.  I'll soon shut up now.

I went looking at mainline, trying to find out why this bug never hit
anyone there.  And that's because it was implicitly fixed by this later
commit in the same series as the backported gen2 fix:


commit 8b2e326dc7c5aa6952c88656d04d0d81fd85a6f8
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Tue Apr 24 22:59:41 2012 +0100

drm/i915: Unconditionally initialise the interrupt workers

Rather than duplicate similar code across the IRQ installers, perform
the initialisation of the workers upfront. This will lead to simpler
teardown and quiescent code as we can assume that the workers have
been initialised.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch



You may want to add a backported variant of that instead of my
quickfix.  Note that it unconditionally initializes hotplug_work as
well.



Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874ngw7hyi@nemi.mork.no

Bug#700739: Kernel panic - not syncing: Fatal exception in interrupt

[Bjørn Mork]

Kubo Hiroshi h-k...@geisya.or.jp writes:

 Hi.

 Do the functions 'i8xx_irq_handler' and 'queue_work_on' always appear in
 the call trace?
 
 I can't remember. If I encounter the problem again, 
 I will check it.

 After the last reply, I encountered the same problems twice.
 In the both problems, the functions 'i8xx_irq_handler' and
  'queue_work_on' appeared in the call trace.

This is most likely a duplicate of http://bugs.debian.org/692607

I am sorry I haven't had any time following up on that.  It seems that
the necessarry debugging output has been collected by Сергей, confirming
the suspicions.

But I still don't see how this corruption can happen, and the fact that
the machine crashes even if we ignore it shows that it is not limited to
this particular struct.  It's just one of the points where we will crash
after such corruptions because of the BUG_ON in kernel/workqueue.c


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uc18zk3@nemi.mork.no

Bug#700572: initramfs-tools: The ehci-hcd module has been split into ehci-pci + ehci-hcd in Linux v3.8

[Bjørn Mork]

Package: initramfs-tools
Version: 0.98.8
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Linux v3.8 changes the name of the PCI ehci driver from ehci-hcd to
ehci-pci.  Ref

commit adfa79d1c06a32650332930ca4c488ca570b3407
Author: Alan Stern st...@rowland.harvard.edu
Date:   Thu Nov 1 11:13:04 2012 -0400

USB: EHCI: make ehci-pci a separate driver

This patch (as1625) splits the PCI portion of ehci-hcd out into its
own separate driver module, called ehci-pci.  Consistently with the
current practice, the decision whether to build this module is not
user-configurable.  If EHCI and PCI are enabled then the module will
be built, always.

Signed-off-by: Alan Stern st...@rowland.harvard.edu
CC: Felipe Balbi ba...@ti.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org



ehci-pci should be added to the hardcoded lists of modules everywhere ehci-hcd
is included. Patch is included.


Bjørn


- -- Package-specific info:
- -- initramfs sizes
- -rw-r--r-- 1 root root 8.5M Apr  9  2010 /boot/initrd.img-2.6.32-4-amd64
- -rw-r--r-- 1 root root  11M Nov  6 02:13 /boot/initrd.img-2.6.32-5-amd64
- -rw-r--r-- 1 root root  11M May 10  2012 /boot/initrd.img-2.6.32-5-amd64.bak
- -- /proc/cmdline
initrd=/initrd.img root=/dev/mapper/vg00-root ro console=tty0 
console=ttyS0,9600n8 BOOT_IMAGE=/vmlinuz 

- -- resume
RESUME=
- -- /proc/filesystems
ext3
ext2
fuseblk
vfat

- -- lsmod
Module  Size  Used by
xt_recent   5977  0 
cpuid   1971  0 
vfat7884  0 
fat40038  1 vfat
loop   11799  0 
ipt_LOG 4518  0 
tcp_diag 880  0 
inet_diag   6914  1 tcp_diag
parport_pc 18855  0 
ppdev   5030  0 
lp  7462  0 
parport27954  3 parport_pc,ppdev,lp
ip6t_rt 1960  2 
nf_conntrack_ipv6  10451  1 
ip6t_REJECT 2580  1 
ip6t_LOG4378  2 
ip6table_filter 2384  1 
ip6_tables 15107  3 ip6t_rt,ip6t_LOG,ip6table_filter
ipt_MASQUERADE  1554  2 
xt_state1303  5 
ipt_REDIRECT  2 
xt_multiport2267  9 
xt_tcpudp   2319  51 
ipt_REJECT  1953  1 
iptable_nat 4299  1 
iptable_filter  2258  1 
ip_tables  13915  2 iptable_nat,iptable_filter
x_tables   12845  14 
xt_recent,ipt_LOG,ip6t_rt,ip6t_REJECT,ip6t_LOG,ip6_tables,ipt_MASQUERADE,xt_state,ipt_REDIRECT,xt_multiport,xt_tcpudp,ipt_REJECT,iptable_nat,ip_tables
microcode  21611  0 
nf_nat_ftp  2031  0 
nf_nat 13388  4 
ipt_MASQUERADE,ipt_REDIRECT,iptable_nat,nf_nat_ftp
nf_conntrack_ipv4   9833  7 iptable_nat,nf_nat
nf_defrag_ipv4  1139  1 nf_conntrack_ipv4
nf_conntrack_irc3347  0 
nf_conntrack_ftp5537  1 nf_nat_ftp
nf_conntrack   46535  9 
nf_conntrack_ipv6,ipt_MASQUERADE,xt_state,iptable_nat,nf_nat_ftp,nf_nat,nf_conntrack_ipv4,nf_conntrack_irc,nf_conntrack_ftp
fuse   50924  1 
cls_u32 5466  1 
sch_htb11942  1 
ppp_deflate 3410  0 
zlib_deflate   17746  1 ppp_deflate
bsd_comp4452  0 
nfsd  254782  13 
exportfs3170  1 nfsd
nfs   241306  0 
lockd  57619  2 nfsd,nfs
fscache29834  1 nfs
nfs_acl 2031  2 nfsd,nfs
auth_rpcgss33508  2 nfsd,nfs
sunrpc161660  28 nfsd,nfs,lockd,nfs_acl,auth_rpcgss
sch_tbf 3588  1 
sit 8176  0 
tunnel4 1973  1 sit
ppp_async   6245  2 
crc_ccitt   1323  1 ppp_async
ppp_generic19259  11 ppp_deflate,bsd_comp,ppp_async
slhc4003  1 ppp_generic
8021q  17158  0 
garp5050  1 8021q
bridge 39646  0 
stp 1440  2 garp,bridge
ext2   52905  1 
raid45644516  1 
async_raid6_recov   5170  1 raid456
async_pq3479  2 raid456,async_raid6_recov
raid6_pq   77179  2 async_raid6_recov,async_pq
async_xor   2478  3 raid456,async_raid6_recov,async_pq
xor 4380  1 async_xor
async_memcpy1198  2 raid456,async_raid6_recov
async_tx1734  5 
raid456,async_raid6_recov,async_pq,async_xor,async_memcpy
mptctl 20982  0 
tun10844  6 
coretemp4325  0 
kvm_intel  38194  29 
kvm   215391  1 kvm_intel
tda100235823  2 
tda100214774  0 
io_edgeport35871  0 
mantis 16776  0 
snd_pcm60487  0 
snd_timer  

Bug#699237: Huawei E220 does not work under Debian Wheezy

[Bjørn Mork]

T hex...@gmail.com writes:

 Reloading module with: modprobe usbserial vendor=0x12d1 product=0x1003

Probably unrelated to your problem, but...

You should not do that.  This device is mode-switched by the usb-storage
driver and handled in modem mode by the option driver. Forcing the
generic serial driver to handle it in either mode is pointless at best.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ham0p0vs@nemi.mork.no

Bug#688198: megasas: Failed to alloc kernel SGL buffer for IOCTL - Possible regression from 2.6.32.41~3

[Bjørn Mork]

Todd Fleisher t...@fleetstreetops.com writes:

 FYI - I'm seeing this same issue in Ubuntu 12.04: Linux deb015.pod02
 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64
 x86_64 x86_64 GNU/Linux

Shit!  I have a bad feeling I might be responsible here...

Looks like the fix I submitted a while ago results in leaking
dma_allocated memory instead of BUGing out. Maybe slightly better in a
short term, but slightly more difficult to notice. Does it take a while
before this error starts appearing?  Do you run some smartctl commands
periodically?

I'd appreciate it if the good Debian kernel team could tak a look at
this before it goes upstream, but I believe something like the attached
patch might fix the bug.  This patch is based on v3.2.34, but I'll
rebase it on current mainline and submit it upstream with Cc stable if
any of you confirms that this look sane


Bjørn

From 4c41818461c2604f859d2fecda2657827071f0d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= bj...@mork.no
Date: Tue, 20 Nov 2012 18:17:48 +0100
Subject: [PATCH] megaraid_sas: fix memory leak if SGL has 0 length entries
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

commit 98cb7e44 ([SCSI] megaraid_sas: Sanity check user
supplied length before passing it to dma_alloc_coherent())
introduced a memory leak.  Memory allocated for entries
following zero length SGL entries will not be freed.

Signed-off-by: Bjørn Mork bj...@mork.no
---
 drivers/scsi/megaraid/megaraid_sas_base.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
index 7c471eb..f013432 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4886,8 +4886,9 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance,
 sense, sense_handle);
 	}
 
-	for (i = 0; i  ioc-sge_count  kbuff_arr[i]; i++) {
-		dma_free_coherent(instance-pdev-dev,
+	for (i = 0; i  ioc-sge_count; i++) {
+		if (kbuff_arr[i])
+			dma_free_coherent(instance-pdev-dev,
 kern_sge32[i].length,
 kbuff_arr[i], kern_sge32[i].phys_addr);
 	}
-- 
1.7.10.4

Bug#688198: megasas: Failed to alloc kernel SGL buffer for IOCTL - Possible regression from 2.6.32.41~3

[Bjørn Mork]

Todd Fleisher t...@fleetstreetops.com writes:

 I get this periodically (seemingly random - but usually once it starts 
 happening it sticks around for a while, then disappears only to return later) 
 when I'm using LSI's MegaCli64 utility. When the kernel logs the error the 
 MegaCli64 command doesn't return any data either.

 Ex:
 root@deb015.pod02:~# MegaCli64 -PDList -aALL


 Exit Code: 0x00


 Which is paired with a kernel message:
 Nov 20 20:29:50 deb015 kernel: [797020.797811] megasas: Failed to alloc 
 kernel SGL buffer for IOCTL 

 Other times that same command (or other MegaCli64 commands) will succeed and 
 return the associated data. When this happens, there is no megasas kernel 
 message.


Thanks.  I don't know what the MegaCli64 utility does, but I assume it
use the driver specific ioctls to send passthrough commands like the
smartmontools do.  That is consistent with your description.

But I was concluding too fast as usual.  The bug I found needs to be
fixed, but it cannot be the cause of this problem.  If it were then you
would most likely see many other effects on your system.  And the same
bug has been backported to 2.6.32 as well.  And if if had not been, and
you are in fact hit by it, then your system would have crashed instead.

So that cannot be the problem.  And then I don't know what could have
changed between 2.6.32 and 3.2.  Could be something outside this driver.

It would be interesting to know something about the size of the buffers
which cannot be allocated.  But running with debug pacthes is maybe out
of the question? Otherwise you could try running with something like
this to get a better picture of why this is failing:


diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index f013432..1c0fa1d 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4797,6 +4797,7 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance,
if (!kbuff_arr[i]) {
printk(KERN_DEBUG megasas: Failed to alloc 
   kernel SGL buffer for IOCTL \n);
+   printk(KERN_DEBUG megasas: iov_len=%d\n, 
ioc-sgl[i].iov_len);
error = -ENOMEM;
goto out;
}




Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txsj5smj@nemi.mork.no

Bug#692607: linux-image-3.2.0-4-686-pae: Kernel crash when coming out of screen saver

[Bjørn Mork]

Steinar Bang s...@dod.no writes:
 Ben Hutchings b...@decadent.org.uk:

 Please send a readable photograph of this text.

 The problem occurred for the third time, and I couldn't find the camera,
 so I'm typing in what's shown on the console.

 This time it had happened while the macine was sitting unmanned and I
 can't say it had anything to do with the screen saver, unless someone
 unintentionally have moved the mouse.

 I also note that it says invalid opcode.  This machine has an Intel P4
 CPU.  Is it too old for the current kernels?

 Console text follows:
 [523708.506472] [ cut here ]---
 [523708.506472] kernel BUG at 
 /build/build-linux_3.2.32-1-i386-Z3rOrf/linux-3.2.32/kernel/workqueue.c:1040!

This should not be a BUG IMHO, and it is in fact made easier debuggable
in newer kernels:


commit f5b2552b4ebbeadcadde1532d7bbd3f850719046
Author: Dan Carpenter dan.carpen...@oracle.com
Date:   Fri Apr 13 22:06:58 2012 +0300

workqueue: change BUG_ON() to WARN_ON()

This BUG_ON() can be triggered if you call schedule_work() before
calling INIT_WORK().  It is a bug definitely, but it's nicer to just
print a stack trace and return.

Reported-by: Matt Renzelmann m...@cs.wisc.edu
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Tejun Heo t...@kernel.org

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 5abf42f..66ec08d 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1032,7 +1032,10 @@ static void __queue_work(unsigned int cpu, struct 
workqueue_struct *wq,
cwq = get_cwq(gcwq-cpu, wq);
trace_workqueue_queue_work(cpu, cwq, work);
 
-   BUG_ON(!list_empty(work-entry));
+   if (WARN_ON(!list_empty(work-entry))) {
+   spin_unlock_irqrestore(gcwq-lock, flags);
+   return;
+   }
 
cwq-nr_in_flight[cwq-work_color]++;
work_flags = work_color_to_flags(cwq-work_color);



Any chance that could be included in Debian wheezy kernels, although I
guess it does not meet stable requirements?



 [523708.506472] invalid opcode:  [#1] SMP
 [523708.506472] Modules linked in: mperf speedstep_lib ip6table_filter 
 ip6_tables cpufreq_powersave iptable_filter ip_tables cpufreq_stats 
 cpufreq_conservative cpufreq_userspace ebtable_nat ebtables x_tables ppdev lp 
 bnep rfcomm bluetooth rfkill crc16 binfmt_misc fuse nfsd nfs nfs_acl 
 auth_rpcgss fscache lockd sunrpc loop snd_intel8x0 snd_ac97_codec i915 
 snd_pcm_oss snd_mixer_oss snd_pcm video snd_page_alloc drm_kms_helper 
 snd_seq_midi snd_seq_midi_event psmouse snd_rawmidi snd_seq snd_seq_device 
 snd_timer snd pcspkr drm i2c_i801 i2c_algo_bit soundcore ac97_bus i2c_core 
 iTCO_wdt serio_raw evdev parport_pc iTCO_vendor_support parport processor 
 thermal_sys rng_core button shpchp usbhid hid ext3 mbcache jbd dm_mod sg 
 sd_mod sr_mod cdrom crc_t10dif ata_generic floppy ata_piix libata uhci_hcd e
  hci_hcd tg3 usbcore libphy scsi_mod usb_common [last unloaded: 
 scsi_wait_scan]
 [523708.506472] 
 [523708.506472] Pid: 0, comm: swapper/0 Not tainted 3.2.0-4-686-pae #1 Debian 
 3.2.32-1 Hewlett-Packard HP d530 CMT(DZ036T)/085Ch
 [523708.506472] EIP: 0060:[c10494b1] EFLAGS: 00010013 CPU: 0
 [523708.506472] EIP is at __queue_work+0x193/0x1f4
 [523708.506472] EAX: f739e56c EBX: f708c800 ECX: 0020 EDX: f739e568
 [523708.506472] ESI: c14b5240 EDI: 0010 EBP: 0046 ESP: f5809f60
 [523708.506472]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
 [523708.506472] Process swapper/0 (pid: 0, ti=f5808000 task=c13defe0 
 task.ti=c13d8000)
 [523708.506472] Stack:
 [523708.506472]  f739e568 f085fe80  f085fe80  0010 
 f7398000 c1049555
 [523708.506472]  f739e568 f739e000 f0871400 f85abe17 c11e601f 0c00a511 
 8000 1930
 [523708.506472]  f739e568 0006 f739e028 0046 0046 f71147c0 
 f58068d4 0010
 [523708.506472] Call Trace:
 [523708.506472]  [c1049555] ? queue_work_on+0x25/0x30
 [523708.506472]  [f85abe17] ? i8xx_irq_handler+0x6b/0x1dc [i915]


I took a quick look at this, and my guess is that i8xx_irq_handler
tries to queue an error event through i915_handle_error() here.

The error_work work_struct is initialized in intel_irq_init(), so I
cannot see how the error can happen unless something scribbles over it
at some point.  Which may be what happens here?  That would be a lot
easier to see if we could have queue_work fail with a warning instead.

Maybe add a few extra debugging tests to i915_handle_error() to see if
this is indeed what happens here?  Completely untested of course:


diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 32e1bda..614f3f4 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1414,6 +1414,19 @@ static void i915_report_and_clear_eir(struct drm_device 
*dev)
}
 }
 
+/* debugging helper only... */
+static bool safe_queue_work(struct workqueue_struct *wq, struct work_struct 
*work)
+{
+  

Bug#692225: [3.2-3.6.4 regression] screen starts to flicker after suspend-to-disk

[Bjørn Mork]

Jonathan Nieder jrnie...@gmail.com writes:

 Hi Bjørn,

 Sebastian Ramacher wrote[1]:

 I've recently upgrade from 3.2 to 3.6. Since the upgrade after resuming from
 supsend-to-disk the screen starts to flicker and the kernel log contains the
 following traceback:

 [ 4730.108047] [ cut here ]
 [ 4730.108073] WARNING: at 
 /build/buildd-linux_3.6.4-1~experimental.1-amd64-QnAy6j/linux-3.6.4/drivers/gpu/drm/i915/intel_display.c:1225
  intel_crtc_disable+0x52/0x86 [i915]()
 [ 4730.108074] Hardware name: 7458WTH
 [ 4730.108076] pipe B assertion failure (expected off, current on)

 Looks like http://thread.gmane.org/gmane.comp.video.dri.devel/75108.
 Do you know if this got fixed?

Looks like you already found the answer, but for the record: As a result
of that thread I started using the fixes from the drm-intel-fixes branch
of git://people.freedesktop.org/~danvet/drm-intel , including the
referenced fa555837 commit, and I have not seen the warning since.

I cannot remember having noticed the flicker issue though, so I cannot
confirm whether that is fixed or not.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gq1iswk@nemi.mork.no

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Bjørn Mork]

Per Foreby p...@foreby.se writes:

 On 2012-10-01 23:29, Jonathan Nieder wrote:
 Per Foreby wrote:

 The debug logging from drm isn't forwarded via netconsole, so I suppose it
 isn't supposed to?

 Oh, that's because of the console_loglevel setting[1].  You can change
 it by running dmesg -n 8 (or by adding the word debug or a
 loglevel= parameter to the kernel command line).

 Ah, RTFM :)

 However, it looks like the netconsole documentation and the dmesg man
 page should be updated:

   # dmesg -n 8
   dmesg: unknown level '8'

 Instead I tried

   # dmesg -n debug
   # dmesg -E

 but still nothing at the remote end.

Yes, I vaguely remember having struggled with the same issue the last
time I use netconsole.  Try 

 echo 8 /proc/sys/kernel/printk

instead.

I believe the bug is in the dmesg utility.  It should shift all values
by one. Setting dmesg -n debug will currently log all messages with a
level *higher* than debug.

 Instead I added remote logging of
 kern.* in rsyslog.conf, so now I have everything at the server.

As long as you don't crash anything...



Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uhhu7zp@nemi.mork.no

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Bjørn Mork]

Per Foreby p...@foreby.se writes:
 On 2012-10-02 00:45, Bjørn Mork wrote:

 I believe the bug is in the dmesg utility.  It should shift all values
 by one. Setting dmesg -n debug will currently log all messages with a
 level *higher* than debug.

 You're probably right about the bug. I don't know what the four values
 in /proc/sys/kernel/printk are, but the first value was 7, not 8:

 # cat /proc/sys/kernel/printk
 7   4   1   7
 # echo 8  /proc/sys/kernel/printk
 # cat /proc/sys/kernel/printk
 8   4   1   7


From Documentation/sysctl/kernel.txt :
quote

printk:

The four values in printk denote: console_loglevel,
default_message_loglevel, minimum_console_loglevel and
default_console_loglevel respectively.

These values influence printk() behavior when printing or
logging error messages. See 'man 2 syslog' for more info on
the different loglevels.

- console_loglevel: messages with a higher priority than
  this will be printed to the console
- default_message_loglevel: messages without an explicit priority
  will be printed with this priority
- minimum_console_loglevel: minimum (highest) value to which
  console_loglevel can be set
- default_console_loglevel: default value for console_loglevel

/quote

 However, this did not affect the remote logging, so I'm back to the
 remote syslog approach.

Odd.  Then there are other issues I don't understand here.

But the dmesg bug is quite obvious, so I sent off a fix upstream.  The
bug was introduced with the support for level names in July 2011.


Bjørn





 /Per


--
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/87wqz9spvc@nemi.mork.no

Bug#684881: linux-image-3.2.0-3-amd64: increasing hardware compatibility: enable firmware-less support for e100

[Bjørn Mork]

Package: src:linux
Version: 3.2.21-3
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello kernel team!

I understand you plan at least one more kernel version
before wheezy.

Please consider backporting

 8b0d2f9 net: e100: ucode is optional in some cases

currently in v3.6-rc1, to the wheezy and installer
kernels.  It applies cleanly on top of v3.2.27.

The patch improves hardware support by allowing the driver
to work (in a non-accellerated mode) without firmware on a
number of older Intel ethernet chips, often present in older
laptops and desktops. This is even more important for the
installer, where it allows the user to complete the
installation process from default Debian media without
providing the firmware on separate media.

I created the patch after a frustrating experience trying
to get an installer snapshot running on and old laptop.
First being able to PXE boot and then told that the ethernet
card needs firmware to continue the installation is not a
pleasant user experience...

The driver will still log the firmware request as usual,
allowing the user to choose to download and install the
nonfree firmware after installation.  Being able to do
this over the network interface is IMHO a great improvement
compared to preparing a USB stick or floppy.



Bjørn

- -- Package-specific info:
** Kernel log: boot messages should be attached


- -- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (600, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.5.0-next-20120726+ (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages linux-image-3.2.0-3-amd64 depends on:
ii  debconf [debconf-2.0]   1.5.44
ii  initramfs-tools [linux-initramfs-tool]  0.107
ii  kmod8-2
ii  linux-base  3.5
ii  module-init-tools   8-2

Versions of packages linux-image-3.2.0-3-amd64 suggests:
pn  debian-kernel-handbook  none
ii  extlinux2:4.05+dfsg-6
pn  linux-doc-3.2   none

Versions of packages linux-image-3.2.0-3-amd64 is related to:
pn  firmware-atherosnone
pn  firmware-bnx2   none
pn  firmware-bnx2x  none
pn  firmware-brcm80211  none
pn  firmware-intelwimax none
pn  firmware-ipw2x00none
pn  firmware-ivtv   none
ii  firmware-iwlwifi0.36
pn  firmware-libertas   none
pn  firmware-linux  none
pn  firmware-linux-nonfree  none
pn  firmware-myricomnone
pn  firmware-netxen none
pn  firmware-qlogic none
pn  firmware-ralink none
pn  firmware-realteknone
pn  xen-hypervisor  none

- -- debconf information:
  linux-image-3.2.0-3-amd64/postinst/depmod-error-initrd-3.2.0-3-amd64: false
  linux-image-3.2.0-3-amd64/prerm/removing-running-kernel-3.2.0-3-amd64: true
  linux-image-3.2.0-3-amd64/postinst/ignoring-ramdisk:
  linux-image-3.2.0-3-amd64/postinst/missing-firmware-3.2.0-3-amd64:

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlAqPzsACgkQ10rqkowbIsn/SQCePmoKJQfRqbXljpJiyhiPtHPh
CrgAnA6wFDm6HLsNgdP70hWKpGxUFhT6
=1paQ
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120814120621.5579.26458.report...@nemi.mork.no

Re: Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works

[Bjørn Mork]

Julien Cristau jcris...@debian.org writes:

 On Fri, Jul 27, 2012 at 02:39:14 +0100, Wookey wrote:

 A way to confirm if the slowkeys feature is currently engaged would
 allow me to confirm this more directly next time. 
 
 http://cgit.freedesktop.org/xorg/xserver/commit/?id=4af8e22b1a539778388fe509a7f3a25860a7879c
 is in the X server in sid, so the X log should tell you.

That's OK, but how do I permanently disable this mis-feature?  I am now
starting to get pissed enough to be willing to replace whatever part of
the system is necessary.  I can probably manage better without an X
server than without a keyboard...


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hass50fz@nemi.mork.no

Re: Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works

[Bjørn Mork]

Vincent Lefevre vinc...@vinc17.net writes:

 I've finally found the solution:

 # apt-get install xkbset
 $ xkbset -a

Thanks.  That's useful.  But I found an even better solution:

 apt-cache search xdm
 (install one of the alternatives)
 apt-get purge gdm3


This has the extra bonus that XAUTHORITY is back where you expect it to
be, and the X server command line is configurable again.



Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3xollht@nemi.mork.no

Re: Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works

[Bjørn Mork]

Vincent Lefevre vinc...@vinc17.net writes:
 On 2012-07-20 08:58:57 +0200, Vincent Lefevre wrote:
 So, it would seem that some part of the system would enable SlowKeys
 in my back for one of the keyboards (I recall that when this happens
 while I'm using the USB keyboard, only the USB keyboard is affected,
 not the laptop keyboard).
 
 If there a way to know whether SlowKeys is enabled, for each available
 keyboard? (Note: I'm not using GNOME, and even GNOME would be useless
 because according to what I see on this page, it cannot differentiate
 keyboards.)

 Additional information:

 * SlowKeys can be turned on and off by pressing the Shift key for
   at least 10 seconds:
 https://bugzilla.redhat.com/show_bug.cgi?id=816764
   I've tried and I confirm that this works. When several keyboards
   are attached, only the keyboard for which the Shift key is pressed
   is affected (I suppose that this is expected).

Thanks a lot for posting this.  I've now hit the bug several times
myself over the last few days, and without having read this thread first
I would never have known how to get out ot it.  And that would have been
really annoying given that this typically happens in the middle of some
heavy editing session. I would have hated to have to throw away the work
and reboot to get the system working again, and I don't think I ever
would have figured out the shift key trick.

BTW, is it only me, or do you have to hold down the key significantly
longer to turn the feature off than to turn it on?  It certainly feels
like it.

 * When the bug occurred in my case, I don't think I've pressed Shift
   for 10 seconds (well, when I do this, this is in combination with
   another key like PageUp / PageDown, but in this case, SlowKeys
   switching isn't triggered), at least in most of the cases.

In my case it seems to happen most often when I do cut and paste,
combining mouse selection with shift + del.  I often end up holding down
the shift key while selecting and bam...


IMNSHO, the hotkey choice is too generic to be acceptable at
all. Holding down any single key to silently enable a feature like this
is not going to do.  I find it somwhat surprising in light of the
Ctrl+Alt+Backspace disabling

Why couldn't they have used *both* shift keys as a trigger?  That would
have eliminated all false positives with no drawbacks AFAICS.

Anyway, please disable this extremely annoying feature until some safer
trigger can be found.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4ryjp3z@nemi.mork.no

Bug#682063: firmware-iwlwifi: Version 0.36 breaks firmware loading

[Bjørn Mork]

Sylvestre Ledru sylves...@debian.org writes:

 Package: firmware-iwlwifi
 Version: 0.36
 Severity: important

 Hello,

 With the version 0.36 of firmware-iwlwifi fails to load the iwlagn module 
 with the error:
 Jul 19 08:39:23 pomegues kernel: [ 1241.775811] iwlagn :01:00.0: request 
 for firmware file 'iwlwifi-6000g2b-5.ucode' failed.
 Jul 19 08:39:23 pomegues kernel: [ 1241.779455] iwlagn :01:00.0: request 
 for firmware file 'iwlwifi-6000g2b-4.ucode' failed.

 Rollback to 0.35 fixes the problem.

 Thanks for your work,
 Sylvestre


 PS: modinfo iwlagn gives:
 # modinfo iwlagn
 filename:   
 /lib/modules/3.1.0-1-amd64/kernel/drivers/net/wireless/iwlwifi/iwlagn.ko

Your kernel is not in the archive.  The firmware-iwlwifi package support
all kernels in squeeze, wheezy and sid. You need to keep track of the
necessary firmware yourself if you want to run other kernel versions.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipdkujtc@nemi.mork.no

Re: [PATCH] scripts/package/builddeb: upgrade to current practices

[Bjørn Mork]

maximilian attems m...@stro.at writes:

 Jonathan already answered it, saying that firmwares are put
 in versioned dir.

 Just use git to look it up, easy:
 ~/src/linux-next (master %=)$ git log scripts/package/builddeb

 6607ddadf93d19c7f64139f1475c342152f39fe5

But..but.. won't that prevent installing firmware for more than one
builddeb kernel?  I.e., shouldn't the fw package name also be versioned
if you are going to do this (which it seems you are)?

But then again, I thought versioned firmware was dropped from the
official packages for good reasons.  Any reason why you couldn't add
/lib/firmware/something (where something is fixed and independent of
version) to the firmware.agent search path, and use that for unofficial
linux-firmware packages?

That would allow unofficial firmware packages from different kernel
versions to continue sharing their package name without conflicting with
the official packages in any way.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87629lbjdy@nemi.mork.no

Re: [PATCH] scripts/package/builddeb: upgrade to current practices

[Bjørn Mork]

Martin-Éric Racine martin-eric.rac...@iki.fi writes:

 Does the kernel look for modules in versioned, then non-versioned
 directories, in that order? More importantly, does it even attempt
 looking in the versioned directory at all?

/lib/udev/firmware.agent does this:

FIRMWARE_DIRS=/lib/firmware/$(uname -r) /lib/firmware /usr/local/lib/firmware 
/usr/lib/hotplug/firmware

for DIR in $FIRMWARE_DIRS; do
[ -e $DIR/$FIRMWARE ] || continue



Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uk9bikl@nemi.mork.no

Bug#670241: Updated qmi_wwan backport based on v3.2.19, including new device IDs from v3.5-rc1

[Bjørn Mork]

block 670241 by 681912
thanks

Please don't implement this just yet.  The ModemManager version in
wheezy may choke on the ports provided by the new driver.  Ref
https://bugzilla.redhat.com/show_bug.cgi?id=835153

I've opened a bug against ModemManager requesting the addition of the
upstream workaround, and am now blocking this bug against it.  Better
not include the driver until we sure it won't trigger any ModemManager
regressions.

Feel free to close this bug with a wontfix if you like.  After all, the
qmi_wwan driver will never be very useful in wheezy, given that the
modemmanager package is frozen on a version too old to ever gain QMI
support.

And thanks for delaying this until Fedora sorted out the worst problems
:-)  That's wise.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txx6jmh7@nemi.mork.no

Bug#670241: Updated qmi_wwan backport based on v3.2.19, including new device IDs from v3.5-rc1

[Bjørn Mork]

Ben Hutchings b...@decadent.org.uk writes:
 On Tue, Jul 17, 2012 at 08:01:24PM +0200, Bjørn Mork wrote:

 Feel free to close this bug with a wontfix if you like.  After all, the
 qmi_wwan driver will never be very useful in wheezy, given that the
 modemmanager package is frozen on a version too old to ever gain QMI
 support.
  
 How large are the required changes to ModemManager?  

Huge.

The next version (0.6) will use a completely new D-Bus API making it
incompatible with the current NetworkManager and any other ModemManager
users. Ref http://www.freedesktop.org/wiki/ModemManager06

And the QMI support might even not be ready for 0.6.  It's currently
being developed in a separate branch and not yet fully operational.

 New hardware
 support is a perfectly good reason for a freeze exception, whichever
 package it's in.

Sure, and I appreciate that.  But do note that this driver does not add
support for any new USB device.  All supported modems are composite
devices having at least one serial port supporting PPP.  This means that
the driver isn't critical for basic device support.  It only adds
support for another device function, which most users will see as
redundant.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pq7ujj48@nemi.mork.no

Bug#681418: debugfs is a big security hole

[Bjørn Mork]

Ben Hutchings b...@decadent.org.uk writes:

 I would like to address this by backporting this feature:

 commit d6e486868cde585842d55ba3b6ec57af090fc343
 Author: Ludwig Nussel ludwig.nus...@suse.de
 Date:   Wed Jan 25 11:52:28 2012 +0100

 debugfs: add mode, uid and gid options

 and then changing the default mode (mask) to be 0700. 

I like the proposal, but the feature does not seem mature yet.  Played a
bit with it and noticed a couple of confusing bugs which IMHO should be
fixed first:

 1) mode and owner is not propagated to files below the mount point:

nemi:/tmp# mount /sys/kernel/debug -o uid=42,mode=0700
nemi:/tmp# ls -la /sys/kernel/debug/
total 0
drwx-- 16   42 root 0 Jul  2 00:07 .
drwxr-xr-x  6 root root 0 Jul  2 00:07 ..
drwxr-xr-x  2 root root 0 Jul  2 00:07 acpi
drwxr-xr-x 32 root root 0 Jul 11 14:36 bdi
drwxr-xr-x  2 root root 0 Jul 13 11:51 bluetooth
drwxr-xr-x  4 root root 0 Jul  2 00:07 dri
drwxr-xr-x  2 root root 0 Jul  2 00:07 dynamic_debug
drwxr-xr-x  2 root root 0 Jul  2 00:07 extfrag
-r--r--r--  1 root root 0 Jul  2 00:07 gpio
drwxr-xr-x  3 root root 0 Jul  2 00:07 ieee80211
drwxr-xr-x  2 root root 0 Jul  2 00:07 kprobes
drwxr-xr-x  2 root root 0 Jul  2 00:07 kvm
drwxr-xr-x  2 root root 0 Jul  2 00:07 mce
drwxr-xr-x  2 root root 0 Jul  2 00:07 regmap
-rw-r--r--  1 root root 0 Jul  2 00:07 sched_features
-r--r--r--  1 root root 0 Jul  2 00:07 suspend_stats
drwxr-xr-x  5 root root 0 Jul  2 00:07 tracing
drwxr-xr-x  2 root root 0 Jul  2 00:07 usb
-r--r--r--  1 root root 0 Jul  2 00:07 wakeup_sources
drwxr-xr-x  2 root root 0 Jul  2 00:07 x86


 2) ownership and mode seems to be shared amoung all mount points,
resulting in the following unexpected behaviour:

nemi:/tmp# mount /sys/kernel/debug -o uid=42,mode=0700
nemi:/tmp# ls -ld /sys/kernel/debug
drwx-- 16 42 root 0 Jul  2 00:07 /sys/kernel/debug
nemi:/tmp# mount -t debugfs none /mnt/temp -o uid=0,mode=0755
nemi:/tmp# ls -ld /sys/kernel/debug
drwxr-xr-x 16 root root 0 Jul  2 00:07 /sys/kernel/debug


 3) ownership (but not mode?!) seems to be cached between mounts,
resulting in the following unexpected behaviour:

nemi:/tmp# mount /sys/kernel/debug -o uid=42,mode=0700
nemi:/tmp# ls -ld /sys/kernel/debug
drwx-- 16 42 root 0 Jul  2 00:07 /sys/kernel/debug
nemi:/tmp# umount /sys/kernel/debug
nemi:/tmp# grep debugfs /proc/mounts 
nemi:/tmp# grep debugfs /etc/fstab
debug   /sys/kernel/debug   debugfs defaults
nemi:/tmp# mount /sys/kernel/debug
nemi:/tmp# ls -ld /sys/kernel/debug
drwxr-xr-x 16 42 root 0 Jul  2 00:07 /sys/kernel/debug



These can all be considered minor glitches, but they sure confused me
the first time I hit them.



Bjørn



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d33zgbrs@nemi.mork.no

Re: cdc_ether, Huawei E173u-2, wrong MAC address of packets vs wwan0

[Bjørn Mork]

Marcin Szewczyk marcin.szewc...@wodny.org writes:

 On Wed, Jun 13, 2012 at 07:58:18PM +0200, Bjørn Mork wrote:
 Marcin Szewczyk marcin.szewc...@wodny.org writes:
  When using RNDIS wwan0 interface has MAC address 02:50:f3:00:00:00 while
  packets coming from Internet have destination MAC address set to
  00:01:02:03:04:05. So the workaround is to set wwan0 MAC to that value.
 
 I guess the 02:50:f3:00:00:00 comes from a USB descriptor as it's not
 exactly random.

 You're right. As You suggested - it is visible as iMacAddress in lsusb
 output.

 So if the firmware provides this descriptor while using
 another fixed address, then that is certainly a firmware bug.  Not too
 surprising unfortunately...

 Roger.

 Normally such devices will pick the MAC address they see in the DHCP
 discover message, but that doesn't seem to happen here unless you sent a
 DHCP request with 00:01:02:03:04:05 as MAC source address?

 Negative. MAC address set for the interface was used.

 Another thing worth noticing is that 02:50:f3:00:00:00 is used as the
 destination address for outgoing packets and source address for
 returning packets. Both before and after setting interface MAC address.

Yuck!  Looks like someone put the wrong address into the string
descriptor.



 What does lsusb -v say?

 Output attached.

Yes, as expected.  Fixing the mac address string descriptor shouldn't be
a big problem for Huawei.

I don't think there is any existing infrastructure in place for
overriding it in Linux.  And I believe it shouldn't be added either,
given that:
 - your modem is the only affected one AFAIK,
 - a usable workaround exists, 
 - the firmware bug is extremely easy to fix for Huawei (and might
   already be fixed for all we know)


 Or you can bug Huawei about it...

 I will check if Huawei cares...

 Another option would be using another usb_modeswitch command.  These
 modems often support many different USB descriptor sets, selectable by
 the usb_modeswitch command.  For some reason, Huawei thinks that it is a
 good idea to use different USB descriptors for Linux and Windows. Guess
 which set is tested...  You could sniff the device under Windows, find
 out what the Windows driver does, and try that in Linux as well.

 I will search for a Windows PC...

 Thank You for a reply. I've also uploaded two tcpdumps:
 1) one with default MAC
 http://wodny.org/special/huawei/huawei-e137-wwan0-defaultmac.cap
 2) one with MAC manually set to 00:01:02:03:04:05
 http://wodny.org/special/huawei/huawei-e137-wwan0-00-05-mac.cap


Thanks.  That demonstrates the problem really well.



Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bokenzaq@nemi.mork.no