Bug#681418: debugfs is a big security hole

[Bjørn Mork]

Ben Hutchings  writes:

> I would like to address this by backporting this feature:
>
> commit d6e486868cde585842d55ba3b6ec57af090fc343
> Author: Ludwig Nussel 
> 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  writes:

> On Wed, Jun 13, 2012 at 07:58:18PM +0200, Bjørn Mork wrote:
>> Marcin Szewczyk  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

Bug#677164: [3.2.17-1 -> 3.2.18-1 regression] Wacom tablet in Thinkpad x220t not working

[Bjørn Mork]

Jonathan Nieder  writes:

> Nils Kanning wrote:
>
>> patches 0020-0023: tablet works
>> patches 0020-0024: tablet works
>> patches 0020-0025: does not work
>> patches 0020-0026: does not work
>> patches 0020-0024,0026: does not work
>
> Thanks!  How about 0026 alone?
>
> (0025 is more tricky to test because it depends on 0024.  Quick
> two-patch series for that attached in case you are interested.)

If I may add a personal opinion here

This commit is so obviously buggy that it should be reverted and redone
in any case:

>>From b4ede6ebf876fbe2c5242e71c7eb195c6f0de6cc Mon Sep 17 00:00:00 2001
> From: Ping Cheng 
> Date: Sun, 29 Apr 2012 21:09:18 -0700
> Subject: [PATCH 2/2] Input: wacom - add 0xE5 (MT device) support
>
> commit 1963518b9b1b8019d33b4b08deee6f873ffa2730 upstream.
>
> Main part of patch is adding support for a new Wacom MT touch
> packet and labels these devices using MTSCREEN type.
>
> Other items of interest:

What's that?  There are supposed to be no "Other items of interest" in a
commit.  One commit, one item.


> Delete some duplicate code in HID parsing for Y info since
> its already done in X path.

Deleting duclicate code while adding new features is a no-no.

> In wacom_query_tablet_data(), only invoke the set report
> that requests tablets to send Wacom Touch packets for
> Finger interfaces.  Mostly, this is to make code intent clear.

I suspect this is the bug hitting Nils.  Apart from the same comment as
above, the "make code intent clear" commit message just obfuscates the
fact that it changes code flow significantly for existing devices.
Such changes have absolutely no place in a new features patch.


These two hunks are suspicious because they remove the setting of
features->device_type:

> @@ -346,18 +350,15 @@ static int wacom_parse_hid(struct usb_interface *intf,
>   case HID_USAGE_Y:
>   if (usage == WCM_DESKTOP) {
>   if (finger) {
> - features->device_type = 
> BTN_TOOL_FINGER;
> - if (features->type == 
> TABLETPC2FG) {
> - /* need to reset back */
> - features->pktlen = 
> WACOM_PKGLEN_TPC2FG;
> + int type = features->type;
> +
> + if (type == TABLETPC2FG || type 
> == MTSCREEN) {
>   features->y_max =
>   
> get_unaligned_le16(&report[i + 3]);
>   features->y_phy =
>   
> get_unaligned_le16(&report[i + 6]);
>   i += 7;
> - } else if (features->type == 
> BAMBOO_PT) {
> - /* need to reset back */
> - features->pktlen = 
> WACOM_PKGLEN_BBTOUCH;
> + } else if (type == BAMBOO_PT) {
>   features->y_phy =
>   
> get_unaligned_le16(&report[i + 3]);
>   features->y_max =
> @@ -371,10 +372,6 @@ static int wacom_parse_hid(struct usb_interface *intf,
>   i += 4;
>   }
>   } else if (pen) {
> - /* penabled only accepts exact 
> bytes of data */
> - if (features->type == 
> TABLETPC2FG)
> - features->pktlen = 
> WACOM_PKGLEN_GRAPHIRE;
> - features->device_type = 
> BTN_TOOL_PEN;
>   features->y_max =
>   
> get_unaligned_le16(&report[i + 3]);
>   i += 4;


This hunk is probably the one mucking up, as it adds a new test for
features->device_type == BTN_TOOL_FINGER, which given the above change
may never be true:


> @@ -437,22 +434,29 @@ static int wacom_query_tablet_data(struct usb_interface 
> *intf, struct wacom_feat
>   if (!rep_data)
>   return error;
>  
> - /* ask to report tablet data if it is MT Tablet PC or
> -  * not a Tablet PC */
> - if (features->type == TABLETPC2FG) {
> - do {
> - rep_data[0] = 3;
> - rep_data[1] = 4;
> - rep_data[2] = 0;

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

[Bjørn Mork]

Marcin Szewczyk  writes:

> I hope this is acceptable to post this kind of thing here. I've got a
> problem with Huawei E173u-2 modem. I've found only one more case on the
> Internet [1]. It isn't a full solution though, rather a workaround.
>
> 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.  So if the firmware provides this descriptor while using
another fixed address, then that is certainly a firmware bug.  Not too
surprising unfortunately...

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?

What does lsusb -v say?

> Is there anything that can be done inside the module (cdc_ether I
> suppose) so that it becomes more consistent and both packets and wwan0
> have the same MAC address without changing MAC manually? Or maybe there
> is something wrong with the hardware?
>
> [1] 
> https://groups.google.com/d/topic/comp.os.linux.hardware/BBiXbAZYfYA/discussion

The driver (either cdc_ether or a dedicated one for this device) could
hardcode the 00:01:02:03:04:05 address, but then we'd have to know which
devices to apply that to. That's probably impossible, as it will depend
on firmware revision, moon phase and other unknown factors. Working
around this problem now may very well cause new problems once the
firmware is fixed. 

So I believe setting the MAC address in your local configuration is an
acceptable workaround for now.

Or you can bug Huawei about it...

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.

SniffUsb works very well if you've got Windows XP:
http://www.pcausa.com/Utilities/UsbSnoop/default.htm


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/87y5nrjdqd@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  writes:
> On Mon, 2012-06-04 at 22:07 +0200, Bjørn Mork wrote:
>> A few changes since the bug was reported:
>> 
>> - v3.2.19 includes a few fixes in cdc-wdm which conflict with the
>>   backport.  The easiest way to merge these is to first revert them, do
>>   the backport, and then reapply the fixes as cherry-picks from
>>   mainline.
>
> Having to revert is not ideal, but it's OK.

The advantage is that all mainline patches apply cleanly.  I can prepare
a set without the reverts if you want that, but that would mean a number
of context adjustments in the backport.

> [...]
>> The resulting drivers will be identical to the 3.5-rc1 versions, with
>> the exception of the module_usb_driver() macro and the
>> disable_hub_initiated_lpm patch:
> [...]
>
> I'm quite happy to add module_usb_driver() if it helps to make cleaner
> backports.

I don't think it helps much.  The mainline patch applying the macro to
the drivers cannot be used anyway, as that is a bulk change touching a
large number of drivers at once.  And this part of the driver is rarely
used as context, so it doesn't affect backporting other patches.  Better
just leave it as it is.


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/87zk8iuql6@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]

A few changes since the bug was reported:

- v3.2.19 includes a few fixes in cdc-wdm which conflict with the
  backport.  The easiest way to merge these is to first revert them, do
  the backport, and then reapply the fixes as cherry-picks from
  mainline.

- The sierra driver fix has been included in stable and can be dropped.

- A few new device IDs has been added to the qmi_wwan driver.


The following procedure will produce a backported version of qmi_wwan
and the supporting cdc-wdm driver on top of a clean v3.2.19:


1) revert the following conflicting stable fixes (will be reapplied in
   the next step):

8fd4242 USB: cdc-wdm: cannot use dev_printk when device is gone
0c68ab1 USB: cdc-wdm: add debug messages on cleanup
7569109 USB: cdc-wdm: fix memory leak
811c72b USB: cdc-wdm: sanitize error returns


2) cherry-pick to add subdriver support to cdc-wdm:

19b85b3 USB: cdc-wdm: no need to fill the in request URB every time it's 
submitted
8143a89 USB: cdc-wdm: kill the now unnecessary bMaxPacketSize0 field and udev 
variable
820c629 USB: cdc-wdm: avoid printing odd-looking "cdc-wdm-176" names
fec67b4 usb: cdc-wdm: Add device-id for Huawei 3G/LTE modems
8804420 usb: cdc-wdm: make reset work with blocking IO
8457d99 USB: cdc-wdm: no need to use usb_alloc_coherent
0dffb48 usb: cdc-wdm: split out reusable parts of probe
b0c1386 usb: cdc-wdm: adding list lookup indirection
3cc3615 usb: cdc-wdm: adding usb_cdc_wdm_register subdriver support
24a85ba USB: cdc-wdm: sanitize error returns
2f338c8 USB: cdc-wdm: fix memory leak
880bca3 USB: cdc-wdm: add debug messages on cleanup
12a98b2 USB: cdc-wdm: cleanup error codes
6b0b79d USB: cdc-wdm: cannot use dev_printk when device is gone
6286d85 USB: cdc-wdm: remove from device list on disconnect


3) cherry-pick to add qmi_wwan driver:

423ce8c net: usb: qmi_wwan: New driver for Huawei QMI based WWAN devices
c3ecb08 net: qmi_wwan: support devices having a shared QMI/wwan interface
b086cf0 net: qmi_wwan: add Gobi and Pantech UML290 device IDs
11207b6 net: qmi_wwan: add support for ZTE MF820D
1aa35a2 USB: qmi_wwan: Add ZTE (Vodafone) K3565-Z and K4505-Z net interfaces
dbb6d09 USB: qmi_wwan: Add ZTE (Vodafone) K3570-Z and K3571-Z net interfaces
3bc17d1 net: qmi_wwan: support Sierra Wireless MC77xx devices in QMI mode
88c16dc net: qmi_wwan: Add Vodafone/Huawei K5005 support
188 USB: qmi_wwan: Make forced int 4 whitelist generic
8965c98 USB: qmi_wwan: Add ZTE (Vodafone) K3765-Z
f7142e6 USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
5e071b5 net: qmi_wwan: Add Sierra Wireless device IDs



The diffstat of the above is:

bjorn@nemi:/usr/local/src/git/linux$ git diff --stat v3.2.19..HEAD
 drivers/net/usb/Kconfig |   22 +++
 drivers/net/usb/Makefile|1 +
 drivers/net/usb/qmi_wwan.c  |  581 

 drivers/usb/class/cdc-wdm.c |  345 

 include/linux/usb/cdc-wdm.h |   19 ++
 5 files changed, 849 insertions(+), 119 deletions(-)



The resulting drivers will be identical to the 3.5-rc1 versions, with
the exception of the module_usb_driver() macro and the
disable_hub_initiated_lpm patch:


bjorn@nemi:/usr/local/src/git/linux$ git diff HEAD..v3.5-rc1 -- 
drivers/usb/class/cdc-wdm.c include/linux/usb/cdc-wdm.h 
drivers/net/usb/qmi_wwan.c
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 32755c6..3b20678 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -562,6 +562,7 @@ static struct usb_driver qmi_wwan_driver = {
.resume   = qmi_wwan_resume,
.reset_resume = qmi_wwan_resume,
.supports_autosuspend = 1,
+   .disable_hub_initiated_lpm = 1,
 };
 
 static int __init qmi_wwan_init(void)
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index 2236fe7..ea8b304 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -1034,26 +1034,10 @@ static struct usb_driver wdm_driver = {
.post_reset =   wdm_post_reset,
.id_table = wdm_ids,
.supports_autosuspend = 1,
+   .disable_hub_initiated_lpm = 1,
 };
 
-/* --- low level module stuff --- */
-
-static int __init wdm_init(void)
-{
-   int rv;
-
-   rv = usb_register(&wdm_driver);
-
-   return rv;
-}
-
-static void __exit wdm_exit(void)
-{
-   usb_deregister(&wdm_driver);
-}
-
-module_init(wdm_init);
-module_exit(wdm_exit);
+module_usb_driver(wdm_driver);
 
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);




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

Bug#655387: [PATCH net v2] cdc_ether: Ignore bogus union descriptor for RNDIS devices

[Bjørn Mork]

Jonathan Nieder  writes:

> Hi Iker,
>
> David Miller wrote:
>> From: Bjørn Mork 
>> Date: Thu, 26 Apr 2012 14:35:10 +0200
>
>>> The same comments as for v1 regarding testing applies.  This is build
>>> tested only.  Should go through some functional testing before being
>>> applied.
>>
>> Well?  Is anyone gonna test this?
>
> Looks like it's up to you, unless some firmware upgrade already
> made the problem go away.
>
> It works like this:
>
>  0. prerequisites:
>
>   apt-get install git build-essential
>
>  1. grab the kernel history, if you don't already have it:
>
>   git clone \
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
>  2. add point releases:
>
>   cd linux
>   git remote add stable \
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>   git fetch stable
>
>  3. configure, build, test:
>
>   git checkout stable/linux-3.2.y
>   cp /boot/config-$(uname -r) .config; # current configuration
>   make localmodconfig; # optional: minimize configuration
>   scripts/config --disable DEBUG_INFO
>   make deb-pkg; # optionally with -j for parallel build
>   dpkg -i ../; # as root
>   reboot
>   ... test test test ...
>
>Hopefully it reproduces the problem.  So:
>
>  4. try the patch (attached):
>
>   cd linux
>   git am -3sc /path/to/the/patch
>   make deb-pkg; # maybe with -j4
>   dpkg -i ../; # as root
>   reboot
>   ... test test test ...

Actually, given that this is a really minor change to a module and not
touching any externally visible interfaces at all, you can get away with
far less work for a simple verification test.

Do step 1 and 2, and then

apt-get install linux-headers-`uname -r`; # as root
git checkout stable/linux-3.2.y
git am -3sc /path/to/the/patch
make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd`/drivers/net/usb 
cdc_ether.ko
# as root:
rmmod cdc_ether
insmod drivers/net/usb/cdc_ether.ko


No reboot required, and no need to build all the unmodified drivers.
All thanks to the excellent Debian kernel packages :-)



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

Bug#655387: [PATCH net v2] cdc_ether: Ignore bogus union descriptor for RNDIS devices

[Bjørn Mork]

Some RNDIS devices include a bogus CDC Union descriptor pointing
to non-existing interfaces.  The RNDIS code is already prepared
to handle devices without a CDC Union descriptor by hardwiring
the driver to use interfaces 0 and 1, which is correct for the
devices with the bogus descriptor as well. So we can reuse the
existing workaround.

Cc: Markus Kolb 
Cc: Iker Salmón San Millán 
Cc: Jonathan Nieder 
Cc: Oliver Neukum 
Cc: 655...@bugs.debian.org
Cc: sta...@vger.kernel.org
Signed-off-by: Bjørn Mork 
---
v2: adding a test to verify that the resulting control interface is the
probed interface, as suggested by Oliver Neukum

The same comments as for v1 regarding testing applies.  This is build
tested only.  Should go through some functional testing before being
applied.


Bjørn

 drivers/net/usb/cdc_ether.c |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 90a3002..00880ed 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -83,6 +83,7 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct 
usb_interface *intf)
struct cdc_state*info = (void *) &dev->data;
int status;
int rndis;
+   boolandroid_rndis_quirk = false;
struct usb_driver   *driver = driver_of(intf);
struct usb_cdc_mdlm_desc*desc = NULL;
struct usb_cdc_mdlm_detail_desc *detail = NULL;
@@ -195,6 +196,11 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct 
usb_interface *intf)
info->control,
info->u->bSlaveInterface0,
info->data);
+   /* fall back to hard-wiring for RNDIS */
+   if (rndis) {
+   android_rndis_quirk = true;
+   goto next_desc;
+   }
goto bad_desc;
}
if (info->control != intf) {
@@ -271,11 +277,15 @@ next_desc:
/* Microsoft ActiveSync based and some regular RNDIS devices lack the
 * CDC descriptors, so we'll hard-wire the interfaces and not check
 * for descriptors.
+*
+* Some Android RNDIS devices have a CDC Union descriptor pointing
+* to non-existing interfaces.  Ignore that and attempt the same
+* hard-wired 0 and 1 interfaces.
 */
-   if (rndis && !info->u) {
+   if (rndis && (!info->u || android_rndis_quirk)) {
info->control = usb_ifnum_to_if(dev->udev, 0);
info->data = usb_ifnum_to_if(dev->udev, 1);
-   if (!info->control || !info->data) {
+   if (!info->control || !info->data || info->control != intf) {
dev_dbg(&intf->dev,
"rndis: master #0/%p slave #1/%p\n",
info->control,
-- 
1.7.10




--
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/1335443710-2627-1-git-send-email-bj...@mork.no

Bug#655387: [PATCH net] cdc_ether: Ignore bogus union descriptor for RNDIS devices

[Bjørn Mork]

Some RNDIS devices include a bogus CDC Union descriptor pointing
to non-existing interfaces.  The RNDIS code is already prepared
to handle devices without a CDC Union descriptor by hardwiring
the driver to use interfaces 0 and 1, which is correct for the
devices with the bogus descriptor as well. So we can reuse the
existing workaround.

Cc: Markus Kolb 
Cc: Iker Salmón San Millán 
Cc: Jonathan Nieder 
Cc: Oliver Neukum 
Cc: 655...@bugs.debian.org
Cc: sta...@vger.kernel.org
Signed-off-by: Bjørn Mork 
---
Something like this, then?

This has only been build tested by me as I don't have any of the affected
devices.  It would be great if any of the reporters could verify that it
solves the problem.  I can provide prebuilt modules for Debian 3.2 based
kernels to simplify the testing (just rmmod and insmod - no need to build
or boot).  Send me an email if you want the module.

Sorry for the long delay in following up this.  I totally forgot about it.


Bjørn

 drivers/net/usb/cdc_ether.c |   12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 90a3002..4ed5a38 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -83,6 +83,7 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct 
usb_interface *intf)
struct cdc_state*info = (void *) &dev->data;
int status;
int rndis;
+   boolandroid_rndis_quirk = false;
struct usb_driver   *driver = driver_of(intf);
struct usb_cdc_mdlm_desc*desc = NULL;
struct usb_cdc_mdlm_detail_desc *detail = NULL;
@@ -195,6 +196,11 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct 
usb_interface *intf)
info->control,
info->u->bSlaveInterface0,
info->data);
+   /* fall back to hard-wiring for RNDIS */
+   if (rndis) {
+   android_rndis_quirk = true;
+   goto next_desc;
+   }
goto bad_desc;
}
if (info->control != intf) {
@@ -271,8 +277,12 @@ next_desc:
/* Microsoft ActiveSync based and some regular RNDIS devices lack the
 * CDC descriptors, so we'll hard-wire the interfaces and not check
 * for descriptors.
+*
+* Some Android RNDIS devices have a CDC Union descriptor pointing
+* to non-existing interfaces.  Ignore that and attempt the same
+* hard-wired 0 and 1 interfaces.
 */
-   if (rndis && !info->u) {
+   if (rndis && (!info->u || android_rndis_quirk)) {
info->control = usb_ifnum_to_if(dev->udev, 0);
info->data = usb_ifnum_to_if(dev->udev, 1);
if (!info->control || !info->data) {
-- 
1.7.10




--
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/1335437703-6800-1-git-send-email-bj...@mork.no

Bug#670241: linux-2.6: Backporting the qmi_wwan driver to the Debian 3.2/wheezy kernels

[Bjørn Mork]

Bjørn Mork  writes:

> The second batch is just a single bugfix for the sierra
> driver, which is necessary to allow the qmi_wwan driver
> to support some Sierra Wireless devices.  This could have
> gone to stable/linux-3.2.y but I did't submit it there as
> it is mostly irrelevant without the qmi_wwan driver.

Never underestimate Greg's efficiency...  Looks like he just picked up
this for 3.0-stable and 3.3-stable, so then I assume Ben will pick it
for 3.2-longterm as well.

> 2) prevent sierra from binding to QMI/wwan interfaces
>
> 749541d USB: sierra: avoid QMI/wwan interface on MC77xx

And if he does, then please ignore this commit.  It will go through
3.2-longterm upstream instead.



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

Bug#670241: linux-2.6: Backporting the qmi_wwan driver to the Debian 3.2/wheezy kernels

[Bjørn Mork]

Package: linux-2.6
Version: 3.2.15-1
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Please add the qmi_wwan driver from current (v3.4-rc)
mainline to the Debian linux-3.2 based kernels. This
is as simple as cherry-picking the commits listed below in
the listed order.  I've verified that the list applies
cleanly on top of v3.2.16 and that it produces the expected
result.

CONFIG_USB_NET_QMI_WWAN must of course be enabled after
adding the driver.  No other CONFIG changes are necessary.


The first batch updates the existing cdc-wdm driver to the
version in v3.4-rc4, except for the module_usb_driver()
changes from commit 65db43054.  That commit touches a large
number of unrelated drivers, and all listed commits apply
cleanly without it, so I believe it's best ignored. The
other changes are necessary to add the subdriver interface
used by the qmi_wwan driver.

The second batch is just a single bugfix for the sierra
driver, which is necessary to allow the qmi_wwan driver
to support some Sierra Wireless devices.  This could have
gone to stable/linux-3.2.y but I did't submit it there as
it is mostly irrelevant without the qmi_wwan driver.

The third batch adds the new qmi_wwan driver as it will appear
in v3.4-rc5.  The driver has been stabilizing for a while,
and I don't expect any major changes to it in the near future.

Thanks for considering this.  Let me know if there are any
problems with this request.



1) add subdriver support to cdc-wdm

19b85b3 USB: cdc-wdm: no need to fill the in request URB every time it's 
submitted
8143a89 USB: cdc-wdm: kill the now unnecessary bMaxPacketSize0 field and udev 
variable
820c629 USB: cdc-wdm: avoid printing odd-looking "cdc-wdm-176" names
fec67b4 usb: cdc-wdm: Add device-id for Huawei 3G/LTE modems
8804420 usb: cdc-wdm: make reset work with blocking IO
8457d99 USB: cdc-wdm: no need to use usb_alloc_coherent
0dffb48 usb: cdc-wdm: split out reusable parts of probe
b0c1386 usb: cdc-wdm: adding list lookup indirection
3cc3615 usb: cdc-wdm: adding usb_cdc_wdm_register subdriver support


2) prevent sierra from binding to QMI/wwan interfaces

749541d USB: sierra: avoid QMI/wwan interface on MC77xx


3) add qmi_wwan driver

423ce8c net: usb: qmi_wwan: New driver for Huawei QMI based WWAN devices
c3ecb08 net: qmi_wwan: support devices having a shared QMI/wwan interface
b086cf0 net: qmi_wwan: add Gobi and Pantech UML290 device IDs
11207b6 net: qmi_wwan: add support for ZTE MF820D
1aa35a2 USB: qmi_wwan: Add ZTE (Vodafone) K3565-Z and K4505-Z net interfaces
dbb6d09 USB: qmi_wwan: Add ZTE (Vodafone) K3570-Z and K3571-Z net interfaces
3bc17d1 net: qmi_wwan: support Sierra Wireless MC77xx devices in QMI mode



Bjørn

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

iEYEARECAAYFAk+Wig0ACgkQ10rqkowbIskgBQCdF9SobH3sjMjNPNjgc19OW6iD
fusAn2aPg1yICRWvKCjrc5ZIGlCQjKOV
=aDUe
-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/20120424111008.7913.83337.report...@canardo.mork.no

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

[Bjørn Mork]

Shannon Dealy  writes:

> I created a file "/etc/modprobe.d/iwlagn.conf" and placed the
> following line in it:
>
>   options iwlagn 11n_disable=1 11n_disable50=1

Note that the 11n_disable50 options was removed in 3.0 and the iwlagn
module was renamed to iwlwifi in 3.2.

Which makes this workaround pretty much irrelevant to any current Debian
kernel as noone(?) has seen the bug in 2.6.32.  Are you still using the
2.6.39-1 kernel you originally opened this bug against?

FWIW, I enabled power_save a few days ago (was previously at default)
after the nice summary from Meenakshi, just to see if I could replicate
this issue.  My module parameters are now:

bjorn@nemi:~$ grep . /sys/module/iwlwifi/parameters/*
/sys/module/iwlwifi/parameters/11n_disable:0
/sys/module/iwlwifi/parameters/ack_check:N
/sys/module/iwlwifi/parameters/amsdu_size_8K:1
/sys/module/iwlwifi/parameters/antenna_coupling:0
/sys/module/iwlwifi/parameters/auto_agg:Y
/sys/module/iwlwifi/parameters/bt_ch_inhibition:Y
/sys/module/iwlwifi/parameters/bt_coex_active:Y
/sys/module/iwlwifi/parameters/fw_restart:1
/sys/module/iwlwifi/parameters/led_mode:0
/sys/module/iwlwifi/parameters/no_sleep_autoadjust:Y
/sys/module/iwlwifi/parameters/plcp_check:Y
/sys/module/iwlwifi/parameters/power_level:0
/sys/module/iwlwifi/parameters/power_save:Y
/sys/module/iwlwifi/parameters/queues_num:0
/sys/module/iwlwifi/parameters/swcrypto:0
/sys/module/iwlwifi/parameters/ucode_alternative:1
/sys/module/iwlwifi/parameters/wd_disable:0


And I am often using 802.11n at 5GHz.  Still haven't seen the issue.

But I wonder about Juha's observation about this difference between my
setup: 

  [   12.611061] iwlwifi :03:00.0: L1 Disabled; Enabling L0S

and his:

  [245082.407512] iwlwifi :03:00.0: L1 Enabled; Disabling L0S

This looks extremely suspicious to me in light of Meenakshi's comment on
known issues with L1 on these devices and that Intel therefore use L0S
by default.

How come Juha end up with L1 enabled, then?  And is that the case for
everyone seeing this bug?



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

Bug#663433: udev: does not load acpiphp on ThinkPad T520 although it is needed for ExpressCard hotplugging

[Bjørn Mork]

Ben Hutchings  writes:

> We should build in whichever hotplug drivers can't be auto-loaded.

Even if it's known to break some hardware, as Greg KH confirmes in
http://www.spinics.net/lists/linux-pci/msg11140.html
?


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/877gyqnru9@nemi.mork.no

Bug#663433: udev: does not load acpiphp on ThinkPad T520 although it is needed for ExpressCard hotplugging

[Bjørn Mork]

Martin Steigerwald  writes:

> Am Sonntag, 11. März 2012 schrieb Marco d'Itri:
>> On Mar 11, Martin Steigerwald  wrote:
>> > So please advice. Is it sufficient for ask for module aliases being
>> > added upstream? If I know how I can provide the necessary info for
>> > my ThinkPad T520.
>> 
>> I am not familiar with ExpressCard, so I do not know exactly what is
>> needed.
>
> No problem. Maybe someone from the Debian kernel team knows. If not I can 
> also ask upstream.

The issue has already been discussed among the upstream experts. See e.g.
http://www.spinics.net/lists/linux-pci/msg11140.html
for an explanation why autoloading acpiphp on all machines historically
has been impossible.

Don't know if anything ever came out of this though:
http://www.spinics.net/lists/linux-pci/msg11148.html

If not, then I guess a distribution could add an init script which
checked DMI dates and loaded acpiphp by default on all modern machines.
It's a pity that users have to research this themselves to get
ExpressCard slots working.


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

Bug#628444: Info received (iwlagn - "MAC is in deep sleep", cannot restore wifi operation)

[Bjørn Mork]

Juha Jäykkä  writes:

> One thing just occurred to me: I added 2 GB of memory (total 4 GB) at about 
> the time these problems started. I cannot say for sure the problems did not 
> start earlier, but it is quite possible they started after! (Please do not 
> tell Lenovo that I added the memory myself as I still have on-site warranty 
> for another year or so. =) )
>
> If the replugging of the wifi card does not solve the problem, i.e. if it 
> resurfaces, I will try going back to 2 GB to see if that helps.

FWIW I am using the exact same card in an X301 with 8 GB memory and have
never seen any such problems. Don't think a RAM upgrade can have any
impact, except maybe by causing the card to move in its slot. I assume
that the memory slots and mini-pcie slots are behind the same cover in
the X201 as well? Replugging it seems like a good idea...

I have been using 3.x kernels from unstable for a while and am currently
running 3.2.6-1. Card details:


[   12.610246] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:
[   12.610317] Copyright(c) 2003-2011 Intel Corporation
[   12.610447] iwlwifi :03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[   12.610522] iwlwifi :03:00.0: setting latency timer to 64
[   12.610552] iwlwifi :03:00.0: pci_resource_len = 0x2000
[   12.610618] iwlwifi :03:00.0: pci_resource_base = c90005794000
[   12.610685] iwlwifi :03:00.0: HW Revision ID = 0x0
[   12.610835] iwlwifi :03:00.0: irq 44 for MSI/MSI-X
[   12.610913] iwlwifi :03:00.0: Detected Intel(R) Ultimate N WiFi Link 
5300 AGN, REV=0x24
[   12.611061] iwlwifi :03:00.0: L1 Disabled; Enabling L0S
[   12.630680] iwlwifi :03:00.0: device EEPROM VER=0x11e, CALIB=0x4
[   12.630752] iwlwifi :03:00.0: Device SKU: 0Xf0
[   12.912837] iwlwifi :03:00.0: Tunable channels: 13 802.11bg, 24 802.11a 
channels
[   13.129544] iwlwifi :03:00.0: loaded firmware version 8.83.5.1 build 
33692
[   13.130194] Registered led device: phy0-led
[   13.198329] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'

nemi:/tmp# lspci -vvnns 03:00.0 
03:00.0 Network controller [0280]: Intel Corporation Ultimate N WiFi Link 5300 
[8086:4236]
Subsystem: Intel Corporation Device [8086:1011]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- http://lists.debian.org/87d38xcr31@nemi.mork.no

Bug#655387: [PATCH] usb: cdc_ether: Ignore bogus union descriptor for RNDIS devices

[Bjørn Mork]

Bjørn Mork  writes:
> Iker Salmón San Millán  writes:
>
>> Sorry, but didn't work, same dmesg with bad cdc descriptors and usb0
>> interface is not created.
>> I tested with 3.2.0-rc7 kernel.
>
> OK, thanks for testing.  I must have missed some finer detail somewhere.

Pretty obvious detail:  The next if() will fail since info->control is
NULL and therefore != intf.  

Could be fixed by e.g. setting info->control = intf inside the 
if (rndis) {} section if you have the patience to test yet-another-patch.


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

Bug#655387: [PATCH] usb: cdc_ether: Ignore bogus union descriptor for RNDIS devices

[Bjørn Mork]

Iker Salmón San Millán  writes:

> Sorry, but didn't work, same dmesg with bad cdc descriptors and usb0
> interface is not created.
> I tested with 3.2.0-rc7 kernel.

OK, thanks for testing.  I must have missed some finer detail somewhere.



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

Bug#655387: [PATCH] usb: cdc_ether: Ignore bogus union descriptor for RNDIS devices

[Bjørn Mork]

Some RNDIS devices include a bogus CDC Union descriptor pointing
to non-existing interfaces.  The RNDIS code is already prepared
to handle devices without a CDC Union descriptor, so we can just
ignore it.

Cc: Markus Kolb 
Cc: Iker Salmón San Millán 
Cc: Jonathan Nieder 
Cc: Oliver Neukum 
Cc: 655...@bugs.debian.org
Cc: sta...@vger.kernel.org
Signed-off-by: Bjørn Mork 
---
How about this, which IMHO is less intrusive? Only build-tested, as I
don't have any of the failing devices, so it will obviously need 
testing from anyone with such a device.
 
 drivers/net/usb/cdc_ether.c |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 41a61ef..2109f34 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -195,7 +195,15 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct 
usb_interface *intf)
info->control,
info->u->bSlaveInterface0,
info->data);
-   goto bad_desc;
+   /* Fallback to guessing for rndis
+* class devices with bogus union
+* descriptor.
+* Fixes some Samsung Android devices
+*/
+   if (rndis)
+   info->u = NULL;
+   else
+   goto bad_desc;
}
if (info->control != intf) {
dev_dbg(&intf->dev, "bogus CDC Union\n");
-- 
1.7.7.3




--
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/1326233716-11083-1-git-send-email-bj...@mork.no

Bug#649486: Forget about this - was triggered by extensive IPv6 address scanning

[Bjørn Mork]

Ben Hutchings  writes:

> The configuration looks fine to me.

OK.

It does not look like I'm able to reproduce this either.   I am only
able to trigger the expected

  "Neighbour table overflow."

and a few additional

  "ICMPv6 ND: ndisc_build_skb() failed to allocate an skb, err=-11."

but no TX watchdog.


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

Bug#649486: Forget about this - was triggered by extensive IPv6 address scanning

[Bjørn Mork]

Ben Hutchings  writes:

> On Mon, 2011-11-21 at 20:13 +0100, Bjørn Mork wrote:
>> Looks like my wife did some external scans of our home network :-)
>> 
>> Have to investigate further how she managed to kill the interface, but
>> this is definitely not related to the driver upgrade.  Sorry for my
>> misleading initial report.
>
> So far as I'm aware, if the TX watchdog fires it indicates one of:
>
> 1. A bug in the driver, firmware or hardware caused the hardware
> transmit queue to stop.
> 2. A bug in the driver, firmware or hardware meant that the kernel was
> not notified of link-down or another interruption that is expected to
> stop the hardware transmit queue.
> 3. Transmission is being continually blocked by (full-duplex link) pause
> frames or (half-duplex link) collisions.  This may occur due to a switch
> misconfiguration or inconsistent configuration between switch and host.
>
> High levels of traffic or specific traffic patterns that overload the
> CPU should never cause this to happen.  As the primary maintainer of
> another Linux network driver, I have to treat every 'TX watchdog' report
> as a bug unless it falls into case 3.

This may very well be an example of case 3. The failing interface is
connected to a gig port on a Cisco Catalyst C2950G.  Both the switch
port and the host port is configured for both input and output
flow-control.

canardo:/tmp# ethtool -a eth1
Pause parameters for eth1:
Autonegotiate:  on
RX: on
TX: on

canardo:/tmp# ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full 
100baseT/Half 100baseT/Full 
1000baseT/Full 
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full 
100baseT/Half 100baseT/Full 
1000baseT/Full 
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on
Supports Wake-on: d
Wake-on: d
Current message level: 0x0001 (1)
Link detected: yes

c2950a#show interfaces gigabitEthernet 0/1
GigabitEthernet0/1 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is 000d.bc45.b3d9 (bia 000d.bc45.b3d9)
  Description: canardo
  MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, 
 reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is T
  input flow-control is on, output flow-control is on 
  ARP type: ARPA, ARP Timeout 04:00:00
  1000BaseT module in GBIC slot.
  Last input 00:00:03, output 00:00:01, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 544000 bits/sec, 159 packets/sec
  5 minute output rate 117000 bits/sec, 103 packets/sec
 85269919 packets input, 1110719891 bytes, 756 no buffer
 Received 1673801 broadcasts (1543541 multicast)
 0 runts, 0 giants, 0 throttles
 0 input errors, 0 CRC, 0 frame, 0 overrun, 756 ignored
 0 watchdog, 1543541 multicast, 11987 pause input
 0 input packets with dribble condition detected
 61473019 packets output, 2505206278 bytes, 0 underruns
 0 output errors, 0 collisions, 2 interface resets
 0 babbles, 0 late collision, 0 deferred
 0 lost carrier, 0 no carrier, 0 PAUSE output
 0 output buffer failures, 0 output buffers swapped out


NOTE: switch counters have unfortunately been reset since the event.



The host network configuration is rather unusual, and may seem
unnecessarily complex (but I have my reasons for most of this - I've
just forgotten them :-)


The eth1 interface is bridged with a tap interface connected to a VDE
switch running on the host.  Both the physical and virtual switch ports
are configured as trunks and a number of VLAN interfaces are put on top
of the bridge interface:

bjorn@canardo:~$ brctl show
bridge name bridge id   STP enabled interfaces
br0 8000.0015171e5e35   no  eth1
tap0
canardo:/tmp# cat /proc/net/vlan/config 
VLAN Dev name| VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
br0.1  | 1  | br0
br0.7  | 7  | br0
br0.90 | 90  | br0
br0.93 | 93  | br0
br0.666| 666  | br0


This way, I can easily connect any combination I want of physical switch
port, virtual switch port and host interface, using only a single cable.

To make this ev

Bug#649486: linux-image-2.6.32-5-amd64: NETDEV WATCHDOG: eth1 (e1000e): transmit queue 0 timed out

[Bjørn Mork]

Package: linux-2.6
Version: 2.6.32-39
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


I have started to get these warnings from time to time after upgrading to a 
squeeze kernel
with the backported new version of the e1000e driver:


Nov 21 12:35:51 canardo kernel: [157688.362907] [ cut here 
]
Nov 21 12:35:51 canardo kernel: [157688.362914] WARNING: at 
/build/buildd-linux-2.6_2.6.32-39-amd64-7yVIH2/linux-2.6-2.6.32/debian/build/source_amd64_none/net/sched/sch_generic.c:261
 dev_watchdog+0xe2/0x194()
Nov 21 12:35:51 canardo kernel: [157688.362916] Hardware name: P5K
Nov 21 12:35:51 canardo kernel: [157688.362918] NETDEV WATCHDOG: eth1 (e1000e): 
transmit queue 0 timed out
Nov 21 12:35:51 canardo kernel: [157688.362919] Modules linked in: tcp_diag 
inet_diag parport_pc ppdev lp parport ip6t_rt nf_conntrack_ipv6 ip6t_REJECT 
ip6t_LOG ip6table_filter ip6_tables ipt_MASQUERADE xt_state ipt_REDIRECT 
xt_multiport xt_tcpudp ipt_REJECT iptable_nat iptable_filter ip_tables x_tables 
nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_irc 
nf_conntrack_ftp microcode nf_conntrack fuse cls_u32 sch_htb ppp_deflate 
zlib_deflate nfsd exportfs bsd_comp nfs lockd fscache nfs_acl auth_rpcgss 
sunrpc sit tunnel4 ppp_async crc_ccitt ppp_generic slhc sch_tbf 8021q garp 
bridge stp ext2 raid456 async_raid6_recov async_pq raid6_pq async_xor xor 
async_memcpy async_tx mptctl tun coretemp kvm_intel kvm tda10023 tda10021 
radeon snd_pcm snd_timer ttm snd soundcore snd_page_alloc mantis mantis_core 
drm_kms_helper dvb_core drm i2c_i801 ir_common i2c_algo_bit io_edgeport 
usbserial pcspkr evdev joydev serio_raw i2c_core button processor asus_atk0110 
ext3 jbd mbcache dm_mod raid1 md_mod usbhid hid sd_mod cr
Nov 21 12:35:51 canardo kernel: c_t10dif uhci_hcd mptsas mptscsih ata_generic 
mptbase scsi_transport_sas pata_jmicron firewire_ohci firewire_core crc_itu_t 
ahci atl1 mii libata scsi_mod ehci_hcd thermal thermal_sys e1000e usbcore 
nls_base [last unloaded: scsi_wait_scan]
Nov 21 12:35:51 canardo kernel: [157688.362987] Pid: 7, comm: ksoftirqd/1 Not 
tainted 2.6.32-5-amd64 #1
Nov 21 12:35:51 canardo kernel: [157688.362988] Call Trace:
Nov 21 12:35:51 canardo kernel: [157688.362990][] ? 
dev_watchdog+0xe2/0x194
Nov 21 12:35:51 canardo kernel: [157688.362995]  [] ? 
dev_watchdog+0xe2/0x194
Nov 21 12:35:51 canardo kernel: [157688.362998]  [] ? 
warn_slowpath_common+0x77/0xa3
Nov 21 12:35:51 canardo kernel: [157688.363001]  [] ? 
dev_watchdog+0x0/0x194
Nov 21 12:35:51 canardo kernel: [157688.363003]  [] ? 
warn_slowpath_fmt+0x51/0x59
Nov 21 12:35:51 canardo kernel: [157688.363006]  [] ? 
netif_tx_lock+0x3d/0x69
Nov 21 12:35:51 canardo kernel: [157688.363010]  [] ? 
netdev_drivername+0x3b/0x40
Nov 21 12:35:51 canardo kernel: [157688.363012]  [] ? 
dev_watchdog+0xe2/0x194
Nov 21 12:35:51 canardo kernel: [157688.363018]  [] ? 
nf_conntrack_free+0x3e/0x50 [nf_conntrack]
Nov 21 12:35:51 canardo kernel: [157688.363022]  [] ? 
death_by_timeout+0x0/0x4a [nf_conntrack]
Nov 21 12:35:51 canardo kernel: [157688.363026]  [] ? 
death_by_timeout+0x0/0x4a [nf_conntrack]
Nov 21 12:35:51 canardo kernel: [157688.363030]  [] ? 
run_timer_softirq+0x1c9/0x268
Nov 21 12:35:51 canardo kernel: [157688.363039]  [] ? 
__do_softirq+0xdd/0x1a6
Nov 21 12:35:51 canardo kernel: [157688.363042]  [] ? 
call_softirq+0x1c/0x30
Nov 21 12:35:51 canardo kernel: [157688.363044][] ? 
do_softirq+0x3f/0x7c
Nov 21 12:35:51 canardo kernel: [157688.363048]  [] ? 
ksoftirqd+0x5f/0xd3
Nov 21 12:35:51 canardo kernel: [157688.363050]  [] ? 
ksoftirqd+0x0/0xd3
Nov 21 12:35:51 canardo kernel: [157688.363053]  [] ? 
kthread+0x79/0x81
Nov 21 12:35:51 canardo kernel: [157688.363055]  [] ? 
child_rip+0xa/0x20
Nov 21 12:35:51 canardo kernel: [157688.363058]  [] ? 
kthread+0x0/0x81
Nov 21 12:35:51 canardo kernel: [157688.363060]  [] ? 
child_rip+0x0/0x20
Nov 21 12:35:51 canardo kernel: [157688.363062] ---[ end trace 94994b9aa1d86dd1 
]---

The frequency is low (once a week or less), but AFAIK this is a regression from 
the old driver.  I
cannot remember to have seen any such warnings with earlier squeeze kernels.

The warning is followed by a couple of reset:

Nov 21 12:35:52 canardo kernel: [157692.873860] e1000e :04:00.1: eth1: 
Reset adapter
Nov 21 12:37:02 canardo kernel: [157763.525692] e1000e :04:00.1: eth1: 
Reset adapter
Nov 21 12:37:52 canardo kernel: [157814.218261] e1000e: eth1 NIC Link is Up 
1000 Mbps Full Duplex, Flow Control: None


I did not watch this in action myself, but both PPPoE sessions running over 
this 
interface timed out at the same time, so I assume that the interface actually 
was
down for 2 minutes here due to whatever caused the warning:

Nov 21 12:36:40 canardo pppd[2414]: No response to 6 echo-requests
Nov 21 12:36:40 canardo pppd[2414]: Serial link appears to be disconnected.
Nov 21 12:36:40 canardo pppd[2414]: Connect time 2626.9 minutes.
Nov 21 12:36:40 canardo pppd[2414]: Sent 12704

Bug#638913: linux-source-3.0.0: cpu frequency speedstep_centrino Intel(R) Pentium(R) M processor

[Bjørn Mork]

Grzegorz Kochański  writes:

>> It works on my T42 with the 1.8 GHz version of this processor, using
>> lenny, squeeze and sid kernel versions.  The BIOS version is 3.05a.
>> Maybe there was a regression in a later BIOS version?
>>
>> Ben.
>>
>>
>> I have applied the newest BIOS version available at lenovo support for my
> T42 (model 2374):
> BIOS Version   3.23 (1RETDRWW)
> BIOS Date   2007-06-18
> Embedded Controller Version 3.03

Please see 

 
http://support.lenovo.com/en_US/downloads/detail.page?&LegacyDocID=MIGR-50273#summary

which says

 "Note: This BIOS version will only work with Embedded Controller
  Program Version 3.04 (or higher)."

This may explain your issues unless the values above are a result of a
typo.


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

Re: Bug#632929: linux-image-2.6.32-5-amd64: missing aha152x module in amd64 architecture

[Bjørn Mork]

Ben Hutchings  writes:
> On Thu, 2011-07-07 at 15:41 +0200, Denis Prost wrote:
>> is that related to the kernel version number ?
>
> No, this has not changed in a long time.
>
>> Mageia 1 pour x86_64 architecture has an aha152x module, but it uses a 
>> 2.6.38.7 kernel.
>
> I think you're mistaken.  But if they do have it, then they must have
> modified the kernel and not sent their changes upstream.

There was an attempt to enable it a while ago:
http://lkml.org/lkml/2010/9/24/415

But it looks like they missed the SCSI_AHA152X part in
drivers/scsi/Kconfig , making it rather pointless.  Probably because of
the missing Kconfig dependency.



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

Re: 3.0-rc6 upload

[Bjørn Mork]

Ben Hutchings  writes:
> On Tue, 2011-07-05 at 07:29 +, maximilian attems wrote:
>> upload of 3.0-rc6 soonest to exp.
>> 
>> 3.0 is awaited with an high probabilty next week.
>> (with an unstable upload shortly after that)
>> some build breakage is expected due the "unreal" version bump.
>> It is very likely to keep three digits, for backward compat.
>
> We have to keep three digits at least for this release, otherwise the
> version of linux-libc-dev will go backwards.

Huh?  That cannot be impossible to fix, can it?  I assume something like
this for the upstream build script could be applied to your build script
as well?  Or am I missing the obvious (again)?


diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index f6cbc3d..ffbcc3b 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -13,7 +13,7 @@
 set -e
 
 create_package() {
-   local pname="$1" pdir="$2"
+   local pname="$1" pdir="$2" version="$3"
 
cp debian/copyright "$pdir/usr/share/doc/$pname/"
cp debian/changelog "$pdir/usr/share/doc/$pname/changelog.Debian"
@@ -60,9 +60,12 @@ create_package() {
if [ -n "$debarch" ] ; then
forcearch="-DArchitecture=$debarch"
fi
+   if [ -n "$version" ] ; then
+   version="-v$version"
+   fi
 
# Create the package
-   dpkg-gencontrol -isp $forcearch -p$pname -P"$pdir"
+   dpkg-gencontrol -isp $forcearch $version -p$pname -P"$pdir"
dpkg --build "$pdir" ..
 }
 
@@ -287,7 +290,7 @@ Description: Linux support headers for userspace development
  are used by the installed headers for GNU glibc and other system libraries.
 EOF
 
-create_package "$libc_headers_packagename" "$libc_headers_dir"
+create_package "$libc_headers_packagename" "$libc_headers_dir" 
"1:$packageversion"
 create_package "$packagename" "$tmpdir"
 
 exit 0



Anyway, doesn't look like Linus has disabled SUBLEVEL in the Makefile
yet, so this discussion is probably pointless...


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

Bug#632778: iwlagn: Driver unable to support your firmware API. Driver supports v5, firmware is v0.

[Bjørn Mork]

Package: linux-2.6
Version: 2.6.32-35
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Just thought I might report this for reference, so that others googling for
it will find a Debian bug report as well...

The story:  I  noticed this in my logs after upgrading to 2.6.32-35:

[326452.367013] iwlagn :03:00.0: Firmware has old API version. Expected v5, 
got v2. New firmware can be obtained from http://www.intellinuxwireless.org.

and stupid as I am, I thought that "Hey, let me just grab firmware-iwlwifi
from sid".  The result was the message in the subject, and a need to get
an ethernet cable so I could downgrade the firmware to get my wireless
network running again.  Well, after reading the fix I assume it would 
have been sufficient to just delete the /lib/firmware/iwlwifi-5000-[3-5].ucode
files, but...

Anyway, this bug is already fixed in upstream 2.6.32-longterm, 
so just close when this enters Debian:


commit c49ed7e7d1461ed0ce88548de0d67c88784a99f3
Author: Greg Kroah-Hartman 
Date:   Thu Jun 23 15:24:26 2011 -0700

Linux 2.6.32.42

commit 2a96ae707525ef00a85bf374e56f0219c07eac5a
Author: Greg Kroah-Hartman 
Date:   Wed Jun 15 13:12:35 2011 -0700

Revert "iwlagn: Support new 5000 microcode."

This reverts commit 6f63415fc1b690cb50c2ad48ba6e9e6e88e271b4.

It turns out this is not what we want to have happen for the .32 and
.33-longterm kernels as it does not work properly at all.

This was reported by Gentoo, Arch, and Canonical developers as causing
problems for their users:
https://bugs.archlinux.org/task/24302
http://bugs.gentoo.org/show_bug.cgi?id=359445
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796336

Cc: Herton Ronaldo Krzesinski 
Cc: Gordon Malm 
Cc: Don Fry 
Cc: Wey-Yi Guy 
Cc: Stanislaw Gruszka 
Signed-off-by: Greg Kroah-Hartman 




Bjørn

- -- Package-specific info:
** Version:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) (da...@debian.org) (gcc version 
4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 09:42:28 UTC 2011

** Command line:
initrd=/initrd.img-2.6.32-5-amd64 root=/dev/nemi/root ro i915.modeset=1 
BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 

** Not tainted

** Kernel log:
[328956.388238] e1000e :00:19.0: setting latency timer to 64
[328956.388249] e1000e :00:19.0: wake-up capability disabled by ACPI
[328956.388255] e1000e :00:19.0: PME# disabled
[328956.388299] e1000e :00:19.0: irq 26 for MSI/MSI-X
[328956.456196] uhci_hcd :00:1a.0: setting latency timer to 64
[328956.456224] usb usb3: root hub lost power or was reset
[328956.456254] uhci_hcd :00:1a.1: setting latency timer to 64
[328956.456281] usb usb4: root hub lost power or was reset
[328956.456303] uhci_hcd :00:1a.2: setting latency timer to 64
[328956.456329] usb usb5: root hub lost power or was reset
[328956.456350] ehci_hcd :00:1a.7: setting latency timer to 64
[328956.456378] HDA Intel :00:1b.0: PCI INT B -> GSI 17 (level, low) -> IRQ 
17
[328956.456386] HDA Intel :00:1b.0: setting latency timer to 64
[328956.545612] uhci_hcd :00:1d.0: setting latency timer to 64
[328956.545639] usb usb6: root hub lost power or was reset
[328956.545663] uhci_hcd :00:1d.1: setting latency timer to 64
[328956.545688] usb usb7: root hub lost power or was reset
[328956.545717] uhci_hcd :00:1d.2: setting latency timer to 64
[328956.545742] usb usb8: root hub lost power or was reset
[328956.545768] ehci_hcd :00:1d.7: setting latency timer to 64
[328956.545802] pci :00:1e.0: setting latency timer to 64
[328956.545816] ahci :00:1f.2: setting latency timer to 64
[328956.812122] sd 0:0:0:0: [sda] Starting disk
[328957.144638] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[328957.148407] ata2.00: ACPI cmd e3/00:1f:00:00:00:a0 (IDLE) succeeded
[328957.149459] ata2.00: ACPI cmd e3/00:02:00:00:00:a0 (IDLE) succeeded
[328957.158162] ata2.00: ACPI cmd e3/00:1f:00:00:00:a0 (IDLE) succeeded
[328957.159138] ata2.00: ACPI cmd e3/00:02:00:00:00:a0 (IDLE) succeeded
[328957.161671] ata2.00: configured for UDMA/33
[328958.432629] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[328958.453235] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[328958.453240] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) 
filtered out
[328958.453244] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered 
out
[328958.453946] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[328958.453950] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) 
filtered out
[328958.453954] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered 
out
[328958.454152] ata1.00: configured for UDMA/100
[328958.509259] Registered led device: iwl-phy0::radio
[328958.509283] Registered led device: iwl-phy0::assoc
[328958.509304] Registered led device: iwl-phy0::RX
[328958.509326] Registered led device: iwl-phy0::TX
[328958.532489] PM: 

Bug#628676: firmware-nonfree: add ti-connectivity firmware

[Bjørn Mork]

David Woodhouse  writes:

> If you do nothing with the firmware, but it merely exists in your clone of 
> the git tree (by virtue of TI's having deliberately put it there), what 
> exactly are you restricted from doing?

Downloading the firmware.  

That's only allowed if you are authorized and willing to accept the
license terms.  Which you do not know about until after you've violated
them.

So what do I do if I download this firmware and find that I don't really
want to accept the license?  If I don't accept it, then I have already
broken the license by downloading it without an intention to accept it.
Catch 22.

> Why is this different to GPL'd firmware on which you violate the licence, 
> and lose your rights?

Because you cannot do that without having the opportunity to read the
license terms first.  Merely downloading GPL'd software will never
violate the license, no matter what your intentions are. 



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

Re: Bug#627837: linux-2.6: Aufs apparently silently dropped, breaking debian-live

[Bjørn Mork]

Daniel Baumann  writes:

> On 05/29/2011 10:34 PM, Julien Cristau wrote:
>> The maintainers have already made that call, and I don't see a reason to
>> override their decision.
>
> so no change after squeeze, the release team gives a shit about breaking
> debian-live, sigh. but don't worry, from now on, i will not care anymore
> either.

I believe your address is wrong. This is neither about the release team,
nor the kernel team.

As for the kernel team, the message they sent you over a year ago should
be pretty clear (and it wasn't the first one AFAIK):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573189#31

They way I read that message, it has:
1) a requirement that aufs2 is going to be updated to work with upstream
   kernel releases
2) no promise that the kernel team will do this work, or even aid it
3) no promise about this support continuing forever (more than a year
   might be considered more than "a while" by many)
4) absolutely no promise that "a while" will last until wheezy is
   released
5) a polite request that you do whatever you can to aid in development
   of union mounts


Did you read something else?


In the mean time, we've seen dicussions like this one:
https://lkml.org/lkml/2011/3/23/72 where the fact that Debian includes
aufs2 is abused as an argument against union mounts!  Where were you in
that discussion?  Ben did what he could, but I wouldn't be suprised if
most people just thought: "Used by Debian" == "must be OK".  For a reason.
It usually works like that :-)

But it is pretty clear that the outcome of that thread could have been
quite another if you and Ben had presented the union mount ready
debian-live and a plan for getting that into wheezy instead of aufs2.

Please stop this nonsense now, and start working with the kernel team
instead of against them.  And that also means working with upstream
kernel maintainers, who have been pretty clear wrt the future of aufs2:
There is none.


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/8762osr2pl@nemi.mork.no

Bug#627592: /usr/sbin/mkinitramfs: copying all files requires too big /tmp - fails on e.g low memory systems using tmpfs

[Bjørn Mork]

Package: initramfs-tools
Version: 0.99
Severity: important
File: /usr/sbin/mkinitramfs

The new "copy all files" policy makes update-initramfs fail on my virtual 
machines
with 128MB RAM and /tmp on a default (20%) tmpfs:

cp: writing `/tmp/mkinitramfs_G8WN9F/bin/sh.shared': No space left on device
cp: writing `/tmp/mkinitramfs_G8WN9F/bin/sleep': No space left on device
cp: writing `/tmp/mkinitramfs_G8WN9F/bin/sync': No space left on device
cp: writing `/tmp/mkinitramfs_G8WN9F/bin/true': No space left on device
cp: writing `/tmp/mkinitramfs_G8WN9F/bin/umount': No space left on device
cp: writing `/tmp/mkinitramfs_G8WN9F/bin/uname': No space left on device
cp: writing `/tmp/mkinitramfs_G8WN9F/bin/zcat': No space left on device
cp: writing `/tmp/mkinitramfs_G8WN9F/lib/klibc-r1_A6R6EwMsdze5h5xz93JiNuoM.so': 
No space left on device
cp: writing 
`/tmp/mkinitramfs_G8WN9F//lib/modules/2.6.39-1-amd64/kernel/drivers/thermal/thermal_sys.ko':
 No space left on device
cp: writing 
`/tmp/mkinitramfs_G8WN9F//lib/modules/2.6.39-1-amd64/kernel/drivers/acpi/fan.ko':
 No space left on device
cp: writing 
`/tmp/mkinitramfs_G8WN9F//lib/modules/2.6.39-1-amd64/kernel/drivers/acpi/thermal.ko':
 No space left on device
E: /usr/share/initramfs-tools/hooks/udev failed with return 1.
update-initramfs: failed for /boot/initrd.img-2.6.39-1-amd64 with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Failed to process /etc/kernel/postinst.d at 
/var/lib/dpkg/info/linux-image-2.6.39-1-amd64.postinst line 771.
dpkg: error processing linux-image-2.6.39-1-amd64 (--configure):
 subprocess installed post-installation script returned error exit status 1


So my /tmp filesystem isn't very big, but this is the first time that has been
a problem:

frtest4:~# mount | grep /tmp
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime,size=20%,mode=1777)
frtest4:~# df -h /tmp/
FilesystemSize  Used Avail Use% Mounted on
tmpfs  24M - -   -  /tmp
frtest4:~# du -s /tmp/*
0   /tmp/mkinitramfs_6QnkFf
2   /tmp/mkinitramfs_G8WN9F
0   /tmp/mkinitramfs-OL_6YFwE3
0   /tmp/mkinitramfs-OL_OLlr3h
0   /tmp/PajnAm


I don't know if there are exact requirements for the size of /tmp, but until 
someone
shows me documentation stating otherwise I will claim that any script or binary 
requiring more than 10MB free space on /tmp, without any sane fallback 
mechanism, is
seriously buggy.

I see the advantage of the new "copy all files" policy wrt including symlinks 
in the
generated initramfs, but I believe this means it has to be generated somewhere 
with 
more available space - at least as a fallback on failure.  Using /tmp by 
default is
probably OK as long as there is an automatic fallback to something safer.  

I suggest using /var/spool/initramfs


Bjørn



-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 9.3M May 14 07:39 /boot/initrd.img-2.6.38-2-amd64
-- /proc/cmdline
initrd=/initrd.img root=UUID=0d3e856e-8f99-4b3e-8d4f-37a65486930b ro 
console=tty0 console=ttyS0,9600n8 BOOT_IMAGE=/vmlinuz 

-- resume
# RESUME=/dev/hda5
RESUME='UUID=70ab49d2-2ac0-47ee-b17a-2fb7258db37f'
-- /proc/filesystems
ext3

-- lsmod
Module  Size  Used by
nfsd  258504  2 
exportfs   12591  1 nfsd
nfs   250037  0 
lockd  70844  2 nfsd,nfs
fscache36071  1 nfs
nfs_acl12511  2 nfsd,nfs
auth_rpcgss36692  2 nfsd,nfs
sunrpc162075  6 nfsd,nfs,lockd,nfs_acl,auth_rpcgss
loop   22515  0 
snd_pcm67327  0 
snd_timer  22658  1 snd_pcm
snd52280  2 snd_pcm,snd_timer
soundcore  13014  1 snd
snd_page_alloc 12969  1 snd_pcm
parport_pc 22191  0 
psmouse55199  0 
pcspkr 12579  0 
parport31650  1 parport_pc
evdev  17475  2 
i2c_piix4  12536  0 
processor  27431  0 
button 12994  0 
serio_raw  12878  0 
i2c_core   23725  1 i2c_piix4
thermal_sys17939  1 processor
ext3  112218  1 
jbd41698  1 ext3
mbcache12930  1 ext3
sg 25769  0 
sr_mod 21824  0 
sd_mod 35501  3 
crc_t10dif 12348  1 sd_mod
cdrom  35134  1 sr_mod
ata_generic12479  0 
ata_piix   25319  2 
uhci_hcd   26290  0 
floppy 56861  0 
ehci_hcd   39529  0 
libata147240  2 ata_generic,ata_piix
usbcore   122908  3 uhci_hcd,ehci_hcd
scsi_mod  161457  4 sg,sr_mod,sd_mod,libata
e1000  89591  0 
nls_base   12753  1 usbcore

-- /etc/initramfs-tools/modules

-- /etc/kernel-img.conf
# Kernel image management overrides
# See kernel-img.conf(

Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL

[Bjørn Mork]

Marc-Christian Petersen  writes:

> so, what's up guys?
>
> may we get this patch into Debian this year (2011)?
>
> or should we wait for 21.12.2012? ;->

Uhm, yeah.  Sorry about that. I never figured it would be this difficult
to get the fix into ustream, which is a requirement for getting it into 
the stable kernels.

And then upstream managed to refactor/rename the files involved before
the fix was applied, and the version that finally went in (to 2.6.39)
also missed the stable Cc...

But I've now sent a backported version of the upstream fix to stable, so
that it hopefully will end up in 2.6.32.x Real Soon Now(tm).  That
should also make it appear in Debian squeeze.

2.6.38 might still require special handling.  The fix from 2.6.39
upstream will apply directly, but I don't know if I care enough to
actually push it.  I assume 2.6.38.x stable will be dead in a while
anyway.



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

Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL

[Bjørn Mork]

Ben Hutchings  writes:
> On Tue, 2011-01-25 at 09:24 +0100, Bjørn Mork wrote:
>> Marc-Christian Petersen  writes:
>> 
>> > so, what's up with this fix? Any chance to get it into Debians kernel tree?
>> >
>> > It's kind of uncomfortable to rebuild the whole kernel, with this applied,
>> > when Debian releases a new kernel which happens frequently ;->
>> 
>> I fully understand. I must admit that I thought it would be a no-brainer
>> to verify this and get it into the upstream and the 2.6.32.x stable tree.  
> [...]
>
> Your patch removes the initialisation of kern_sge32[i] when
> ioc->sgl[i].iov_len is zero.  I think it should at least set the length
> to zero.

Yes, you are of course right.  I just considered it's usage in that
function, where it won't be used as long as kbuff_arr[i] is 0, but
kern_sge32[i] should be set to be absolutely safe with the firmware.

> Perhaps it's safest to pass max(ioc->sgl[i].iov_len, 1) as the length
> parameter to dma_alloc_coherent().

I agree that it would fix things, and that may be appropriate for a
Debian specific workaround where the workaround context always is clear,
but I don't think it's good as a permanent fix.  Reading the patched
code would be very confusing.  Not allocating 0 is self-explanatory.


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/878vxh3g7z@nemi.mork.no

Re: link_in_boot

[Bjørn Mork]

Ben Hutchings  writes:
> On Sun, 2011-02-13 at 20:24 +0100, Bjørn Mork wrote:
>> Ben Hutchings  writes:
>> 
>> > This has nothing to do with where the kernel images are (they are always
>> > installed in /boot), but only to do with where the symlinks are created.
>> > The default is to create them in /, but I recall there is an option (now
>> > deprecated) to create them in /boot. 
>> 
>> Not related to this bug, but I was wondering: Why deprecate this
>> feature?
>
> All configuration through kernel-img.conf is deprecated.  It is a legacy
> of kernel-package, and even current versions of kernel-package do not
> use it.

Ah, right.  That makes sense.

>> I find it very useful for systems where I keep /boot in a separate
>> partition.  Having the symlinks in the same partition allow you to
>> configure boot loaders like extlinux with the generic symlink names.
>
> They should be using hook scripts to generate a separate entry for each
> installed kernel version.

Yes, I know. 

In practise, I often find myself turning that off and configuring the
boot loader manually instead.  The reason is the lack of flexibility in
the automatic scripts, like e.g. missing serial support in extlinux.  Or
the ability to keep a few special kernels in /boot without adding all of
them to the boot menu.

Might be just me.  Just wanted to register an interest in keeping the 
link_in_boot feature.  But I can of course implement it using the hook
feature instead of kernel-img.conf.  I do understand the wish to get
rid of that file.

>> The links in / are generally not very useful IMHO if /boot and / are
>> different partitions.
>
> That depends on whether the symlink is resolved at installation time or
> at boot time.

Well, links in /boot can be used at both times, links in / cannot.


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

link_in_boot (was: Re: Bug#613200: linux-base: lilo.conf not updated to UUIDs for kernels not in /)

[Bjørn Mork]

Ben Hutchings  writes:

> This has nothing to do with where the kernel images are (they are always
> installed in /boot), but only to do with where the symlinks are created.
> The default is to create them in /, but I recall there is an option (now
> deprecated) to create them in /boot. 

Not related to this bug, but I was wondering: Why deprecate this
feature?

I find it very useful for systems where I keep /boot in a separate
partition.  Having the symlinks in the same partition allow you to
configure boot loaders like extlinux with the generic symlink names.

The links in / are generally not very useful IMHO if /boot and / are
different partitions.


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

Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL

[Bjørn Mork]

Marc-Christian Petersen  writes:

> so, what's up with this fix? Any chance to get it into Debians kernel tree?
>
> It's kind of uncomfortable to rebuild the whole kernel, with this applied,
> when Debian releases a new kernel which happens frequently ;->

I fully understand. I must admit that I thought it would be a no-brainer
to verify this and get it into the upstream and the 2.6.32.x stable tree.  

But after nagging about it recently, it appears that the driver
maintainer didn't really understand the issue.  The last I heard from
LSI was this: http://marc.info/?l=linux-scsi&m=129549117927641 which
wouldn't be so bad if it weren't for the fact that it was sent well
*after* that I already had done exactly that, as FUJITA Tomonori
helpfully pointed out in a reply to that message

So I honestly don't know.  Looks like getting it upstream will still
take some time.  Maybe the Debian kernel maintainers can take it as a
temporary bugfix until it gets there?  The fix is rather obvious (in my
eyes at least  :-).


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

Bug#606237: linux-kernel: poweroff-button fails on 2.6.32-5-openvz-686

[Bjørn Mork]

Richard Landsman - Rimote Media  writes:

> The bug you mentioned looks relevant. I did not use X. But I've tried to
> install acpi-support from both the testing and unstable repo and it
> doesn't seem to maken any difference. 

You currently need acpi-support-base from unstable.  Doesn't look like
acpi-support will pull that in.  It is satisfied with acpi-support-base
from testing. 

> Maybe the update is not yet in the
> repo? It looks like it still needs X and it is installed now so it looks
> like missing X does not have to do with the broken ACPI support.

acpi-support-base version 0.138-4  Works For Me (tm)

But the code is still doing a lot of weird stuff to verify that you are
a console user and to look for a number of power event handlers.

You could verify that you are using the default powerbtn script by
looking at the acpi config:

 frtest5:~# cat /etc/acpi/events/powerbtn-acpi-support 
 event=button[ /]power
 action=/etc/acpi/powerbtn-acpi-support.sh

and then run the script with sh -x to see where (and if it fails).
Beware:  This will poweroff your host if it doesn't fail


frtest5:~# sh -x /etc/acpi/powerbtn-acpi-support.sh
+ [ -f /etc/acpi/events/powerbtn -o -f /etc/acpi/events/powerbtn.dpkg-bak ]
+ [ -e /usr/share/acpi-support/policy-funcs ]
+ . /usr/share/acpi-support/policy-funcs
+ . /usr/share/acpi-support/power-funcs
+ umask 022
+ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
+ POWERSTATE=/var/lib/acpi-support/powerstate
+ HDPARM=/sbin/hdparm -q
+ LIDSTATE=/var/lib/acpi-support/lidstate
+ CheckPolicy
+ local PMS
+ getXconsole
+ fgconsole
+ activeVT=serial
+ return
+ PMS=/usr/bin/gnome-power-manager /usr/bin/kpowersave 
/usr/bin/xfce4-power-manager
+ PMS=/usr/bin/gnome-power-manager /usr/bin/kpowersave 
/usr/bin/xfce4-power-manager /usr/bin/guidance-power-manager 
/usr/lib/dalston/dalston-power-applet
+ pidof -x /usr/bin/gnome-power-manager /usr/bin/kpowersave 
/usr/bin/xfce4-power-manager /usr/bin/guidance-power-manager 
/usr/lib/dalston/dalston-power-applet
+ test  != 
+ PowerDevilRunning
+ test -x /usr/bin/dbus-send
+ local DBUS_SESS
+ pidof kded4
+ return 1
+ [ -x /etc/acpi/powerbtn.sh ]
+ [ -x /etc/acpi/powerbtn.sh.dpkg-bak ]
+ /sbin/shutdown -h -P now Power button pressed

Broadcast message from r...@frtest5 (pts/0) (Fri Dec 17 13:40:32 2010):

Power button pressed 
The system is going down for system halt NOW!
frtest5:~# Connection to frtest5.lab closed by remote host.
Connection to frtest5.lab closed.


As you can see, it now works for me because "activeVT=serial" has been
added as a special case in /usr/share/acpi-support/power-funcs:

# getXconsole gets the foreground (console) X user
getXconsole() {
activeVT=$(fgconsole) || pwf_error "can't get active VT"
case $activeVT in
serial)
return
;;
''|*[!0-9]*)
pwf_error "invalid active VT '$activeVT'"
;;
esac


But I assume this will still fail for any unknown console type.  Run
"fgconsole" to see what yours is.


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

Bug#606237: linux-kernel: poweroff-button fails on 2.6.32-5-openvz-686

[Bjørn Mork]

Richard  writes:

> Package: linux-kernel
> Version: 10
> Severity: normal
>
>
> To reproduce use a standard clean install of debian 5 and install the openvz 
> kernel like this:
>
> apt-get update && apt-get -y upgrade && apt-get -y install -t testing 
> linux-image-openvz-686
>
> After restart poweroff with powerbutton does not work. Before it did
> (with the standard kernel) and it used to work a few months ago too
> with the new kernel. ACPID packages seem to be installed fine and
> modules are loaded.


let me guess:  You don't run X on this host.  

See bug#606214 in acpi-support-base


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

Bug#606096: linux-2.6: Please reset CONFIG_FUSION_MAX_SGE to upstream default

[Bjørn Mork]

Package: linux-2.6
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Debian is deviating from the upstream default for CONFIG_FUSION_MAX_SGE
This confuses users and makes upstream bug reporting more difficult
than necessary.  Ref http://permalink.gmane.org/gmane.linux.scsi/64136

I assume this difference never was intentional, but was caused by an 
unnoticed upstream change of default (default == max and max was increased):


commit 5f5affddad836978f057d316ba8083a5d553773c
Author: Moore, Eric Dean  
Date:   Fri Apr 22 18:00:52 2005 -0400

[SCSI] mptfusion: Kconfig Adding new bus type drivers for fusion drivers.

(1) Kconfig - added new mptspi and mptfc scsi lld drivers
(2) Kconfig - increased MAX_SGE from 40 to 128
(2) Makefile - compilation support for split drivers
(3) Makefile - cleaned up debug defines; e.g. removed obsolete, added others

Signed-off-by: Eric Moore 
Signed-off-by: James Bottomley 

diff --git a/drivers/message/fusion/Kconfig b/drivers/message/fusion/Kconfig
index 452418b..2d5a76f 100644
- --- a/drivers/message/fusion/Kconfig
+++ b/drivers/message/fusion/Kconfig
[..]
 config FUSION_MAX_SGE
int "Maximum number of scatter gather entries"
- -   depends on FUSION
- -   default "40"
+   depends on FUSION_SPI || FUSION_FC
+   default "128"
help
  This option allows you to specify the maximum number of scatter-



Bjørn

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

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

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

iEYEARECAAYFAkz8x2sACgkQ10rqkowbIsm74gCghnzlX7JerPk8ZFzEz39m5/QE
nLMAoJDozGjwStn3v2kGOIeucCzc6Oje
=y34G
-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/2010120611.2744.55888.report...@canardo.mork.no

Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL

[Bjørn Mork]

Marc-Christian Petersen  writes:
> On Tue, 23 Nov 2010 15:25:44 +0100, Bjørn Mork  wrote:
>
>> Please see if this is fixed by the patch I recently posted to the
>> linux-scsi list: http://permalink.gmane.org/gmane.linux.ide/47847
>> 
>> I believe you are seeing another symptom of the same bug: The driver
>> happily forwards a 0 length from userspace to dma_alloc_coherent().
>> smartctl will trigger this when trying to enable the self tests.
>> 
>> I've attached the patch for simplicity.  Note that I haven't yet
>> received any ack on this, but it did fix the problems for the other user
>> reporting similar issues.
>
> first: sorry for the late answer!
>
> That patch also fixes my problems. Very cool :-D

Does the selftest actually work?  Artem Bokhan reports that the patch
fixes the visible error, but that the selftest does not start.  I really
don't understand why, as AFAICS the patch does not change or modify any
part of the command from smartctl.  It only ensures that a command with
dxfer_len == 0 doesn't cause an attempt to dma_alloc_coherent zero bytes
(which will fail).

> Many thanks!
>
> now, how do we get that patch into the official Debian Kernel? ;)

I believe that is as easy as getting it into an upstream kernel, which
will trigger stable, which will be included in Debian automatically.

But I haven't received any feedback from the driver maintainers yet. I
don't know if I should expect any...  They seem to collect a number of
changes in internal releases, which are then pushed 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/87r5e4l7qy@nemi.mork.no

Bug#604083: add support for megaraid 9240 9260 9280 8704 8708 8880 8888

[Bjørn Mork]

Ivan Sergio Borgonovo  writes:

> I've just tested 2.6.32-28 from latest iso and it still doesn't work.
> The version of this driver included in experimental is reported to work
> on other distribution (0.17).
>
> If you'd point me to some RTFM to help you test something that could
> give some more chance to add support to these controller in the upcoming
> stable I'd try to help.

A start would be to use the reportbug tool so that the kernel team got
all the relevant data in the bug report, in particular the lspci
listing.  Took me a while to finally find a PCI device id to verify
which devices you're after. Finally found it in
http://launchpadlibrarian.net/51569322/Lspci.txt:

 01:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS 
9240 [1000:0073] (rev 02)

which was added to the driver between v2.6.32..v2.6.33.  

commit 879111224d in Linus' tree is the one that actually added the
device to the module alias list. I've included it below.  You could try
and see if this is enough, or if the whole driver needs to be updated to
the 2.6.33 version (which is LSI megasas version "00.00.04.12-rc1").


Bjørn

commit 879111224d0784eab623fe8130a1f4481e0e1966
Author: Yang, Bo 
Date:   Tue Oct 6 14:31:54 2009 -0600

[SCSI] megaraid_sas: Add new megaraid SAS 2 controller support to the driver

Add the new megaraid sas 2 controller to the driver.  megaraid sas2 is
LSI next generation SAS products.  driver add the interface to support
this product.

Signed-off-by Bo Yang
Signed-off-by: James Bottomley 

diff --git a/drivers/scsi/megaraid/megaraid_sas.c b/drivers/scsi/megaraid/megaraid_sas.c
index 0121413..b6e4327 100644
--- a/drivers/scsi/megaraid/megaraid_sas.c
+++ b/drivers/scsi/megaraid/megaraid_sas.c
@@ -76,6 +76,10 @@ static struct pci_device_id megasas_pci_table[] = {
 	/* gen2*/
 	{PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_SAS0079GEN2)},
 	/* gen2*/
+	{PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_SAS0073SKINNY)},
+	/* skinny*/
+	{PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_SAS0071SKINNY)},
+	/* skinny*/
 	{PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_VERDE_ZCR)},
 	/* xscale IOP, vega */
 	{PCI_DEVICE(PCI_VENDOR_ID_DELL, PCI_DEVICE_ID_DELL_PERC5)},
@@ -335,6 +339,99 @@ static struct megasas_instance_template megasas_instance_template_ppc = {
 };
 
 /**
+ * megasas_enable_intr_skinny -	Enables interrupts
+ * @regs:			MFI register set
+ */
+static inline void
+megasas_enable_intr_skinny(struct megasas_register_set __iomem *regs)
+{
+	writel(0x, &(regs)->outbound_intr_mask);
+
+	writel(~MFI_SKINNY_ENABLE_INTERRUPT_MASK, &(regs)->outbound_intr_mask);
+
+	/* Dummy readl to force pci flush */
+	readl(®s->outbound_intr_mask);
+}
+
+/**
+ * megasas_disable_intr_skinny -	Disables interrupt
+ * @regs:			MFI register set
+ */
+static inline void
+megasas_disable_intr_skinny(struct megasas_register_set __iomem *regs)
+{
+	u32 mask = 0x;
+	writel(mask, ®s->outbound_intr_mask);
+	/* Dummy readl to force pci flush */
+	readl(®s->outbound_intr_mask);
+}
+
+/**
+ * megasas_read_fw_status_reg_skinny - returns the current FW status value
+ * @regs:			MFI register set
+ */
+static u32
+megasas_read_fw_status_reg_skinny(struct megasas_register_set __iomem *regs)
+{
+	return readl(&(regs)->outbound_scratch_pad);
+}
+
+/**
+ * megasas_clear_interrupt_skinny -	Check & clear interrupt
+ * @regs:MFI register set
+ */
+static int
+megasas_clear_intr_skinny(struct megasas_register_set __iomem *regs)
+{
+	u32 status;
+	/*
+	 * Check if it is our interrupt
+	 */
+	status = readl(®s->outbound_intr_status);
+
+	if (!(status & MFI_SKINNY_ENABLE_INTERRUPT_MASK)) {
+		return 1;
+	}
+
+	/*
+	 * Clear the interrupt by writing back the same value
+	 */
+	writel(status, ®s->outbound_intr_status);
+
+	/*
+	* dummy read to flush PCI
+	*/
+	readl(®s->outbound_intr_status);
+
+	return 0;
+}
+
+/**
+ * megasas_fire_cmd_skinny -	Sends command to the FW
+ * @frame_phys_addr :		Physical address of cmd
+ * @frame_count :		Number of frames for the command
+ * @regs :			MFI register set
+ */
+static inline void
+megasas_fire_cmd_skinny(dma_addr_t frame_phys_addr, u32 frame_count,
+			struct megasas_register_set __iomem *regs)
+{
+	writel(0, &(regs)->inbound_high_queue_port);
+	writel((frame_phys_addr | (frame_count<<1))|1,
+		&(regs)->inbound_low_queue_port);
+}
+
+static struct megasas_instance_template megasas_instance_template_skinny = {
+
+	.fire_cmd = megasas_fire_cmd_skinny,
+	.enable_intr = megasas_enable_intr_skinny,
+	.disable_intr = megasas_disable_intr_skinny,
+	.clear_intr = megasas_clear_intr_skinny,
+	.read_fw_status_reg = megasas_read_fw_status_reg_skinny,
+};
+
+
+/**
 *	The following functions are defined for gen2 (deviceid : 0x78 0x79)
 *	controllers
 */
@@ -1587,16 +1684,34 @@ megasas_transition_to_ready(struct megasas_instance* instance)
 			/*
 			 * Set the CLR bit in inbound doorbell
 			 */
-			writel(MFI_INIT_CLEAR_HANDSHAKE|

Bug#604948: IPv6 problems in Squeeze

[Bjørn Mork]

Kolbjørn Barmen  writes:

> Package: linux-image-2.6.32-5-amd64
> Version: 2.6.32-27
>
> With ipv6 buildt into kernel and not available as a kernel module, there
> is no way to pass on the module options that those of us who run IPv6 in
> production environments very often need.

You have exactly the same possibilities as before.  Quoting from
Documentation/kernel-parameters.txt:


Module parameters for modules that are built into the kernel image
are specified on the kernel command line with the module name plus
'.' plus parameter name, with '=' and value if appropriate, such as:

usbcore.blinkenlights=1


A "disable" option has also been added for completely disabling the
module, for those who wanted to blacklist it (which I guess you don't
want, but still...)

> For example, I have servers that need to explicitly have IPv6 configured
> staticly, that sit on LANs that have autoconf/ra enabled.

> Now - it would ofcourse be _very much_ prefared that if one in
> /etc/network/interfaces configure interfaces with static ipv6 addresses
> and static router, all of the above happen automatically.

I don't think that's necessarily something everyone would want.  I can
imagine situations where you'd like both a static address and a SLAAC
address on an interface.


> A workaround
> that we've been using till now is to have in interfaces for example:
>
> auto eth0
>iface eth0 inet static
>   address 10.10.10.10
>   gateway 10.10.10.1
>   netmask 255.255.255.0
>iface eth0 inet6 static
>   address 2001:700:0::beaf
>   gateway 2001:700::1
>   netmask 64
>up /sbin/sysctl -w net.ipv6.conf.eth0.autoconf=0
>up /sbin/sysctl -w net.ipv6.conf.eth0.accept_ra=0
>
> But this only work _most_ of the time. Every now and then the sysctl lines are
> not performed quickly enough and due to bad luck the server also picks up
> autoconf address and router announcement, ending up with double set of
> addresses and non-static default route.

How about using pre-up?  Wouldn't that always work?



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

Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL

[Bjørn Mork]

Marc-Christian Petersen  writes:

> I am unable to do short and long tests initiated with smartd/smartctl.
>
> calling 'smartctl -d megaraid,0 /dev/sda -t short' gives:
>
> smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
> Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
> Short offline self test failed [Cannot allocate memory]
> megasas: Failed to alloc kernel SGL buffer for IOCTL

Please see if this is fixed by the patch I recently posted to the
linux-scsi list: http://permalink.gmane.org/gmane.linux.ide/47847

I believe you are seeing another symptom of the same bug: The driver
happily forwards a 0 length from userspace to dma_alloc_coherent().
smartctl will trigger this when trying to enable the self tests.

I've attached the patch for simplicity.  Note that I haven't yet
received any ack on this, but it did fix the problems for the other user
reporting similar issues.



Bjørn


--- Begin Message ---
The ioc->sgl[i].iov_len value is supplied by the ioctl caller, and can be
zero in some cases.  Assume that's valid and continue without error.

Fixes:

[   69.162538] [ cut here ]
[   69.162806] kernel BUG at /build/buildd/linux-2.6.32/lib/swiotlb.c:368!
[   69.163134] invalid opcode:  [#1] SMP
[   69.163570] last sysfs file: 
/sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
[   69.163975] CPU 0
[   69.164227] Modules linked in: fbcon tileblit font bitblit softcursor 
vga16fb vgastate ioatdma radeon ttm drm_kms_helper shpchp drm i2c_algo_bit lp 
parport floppy pata_jmicron megaraid_sas igb dca
[   69.167419] Pid: 1206, comm: smartctl Tainted: GW  2.6.32-25-server 
#45-Ubuntu X8DTN
[   69.167843] RIP: 0010:[]  [] 
map_single+0x255/0x260
[   69.168370] RSP: 0018:88081c0ebc58  EFLAGS: 00010246
[   69.168655] RAX: 0003bffc RBX:  RCX: 0002
[   69.169000] RDX:  RSI:  RDI: 88001dffe000
[   69.169346] RBP: 88081c0ebcb8 R08:  R09: 88030840
[   69.169691] R10: 0010 R11:  R12: 
[   69.170036] R13:  R14: 0001 R15: 0020
[   69.170382] FS:  7fb8de189720() GS:88001de0() 
knlGS:
[   69.170794] CS:  0010 DS:  ES:  CR0: 80050033
[   69.171094] CR2: 7fb8dd59237c CR3: 00081a79 CR4: 06f0
[   69.171439] DR0:  DR1:  DR2: 
[   69.171784] DR3:  DR6: 0ff0 DR7: 0400
[   69.172130] Process smartctl (pid: 1206, threadinfo 88081c0ea000, task 
88081a76)
[   69.194513] Stack:
[   69.205788]  0034 0002817e3390  
88081c0ebe00
[   69.217739] <0>  0003bffc  

[   69.241250] <0>   88081c5b4080 
88081c0ebe00
[   69.277310] Call Trace:
[   69.289278]  [] swiotlb_alloc_coherent+0xec/0x130
[   69.301118]  [] x86_swiotlb_alloc_coherent+0x61/0x70
[   69.313045]  [] megasas_mgmt_fw_ioctl+0x1ae/0x690 
[megaraid_sas]
[   69.336399]  [] megasas_mgmt_ioctl_fw+0x198/0x240 
[megaraid_sas]
[   69.359346]  [] megasas_mgmt_ioctl+0x35/0x50 [megaraid_sas]
[   69.370902]  [] vfs_ioctl+0x22/0xa0
[   69.382322]  [] ? alloc_fd+0x10a/0x150
[   69.393622]  [] do_vfs_ioctl+0x81/0x410
[   69.404696]  [] ? do_page_fault+0x153/0x3b0
[   69.415761]  [] sys_ioctl+0x81/0xa0
[   69.426640]  [] system_call_fastpath+0x16/0x1b
[   69.437491] Code: fe ff ff 48 8b 3d 74 38 76 00 41 bf 00 00 20 00 e8 51 f5 
d7 ff 83 e0 ff 48 05 ff 07 00 00 48 c1 e8 0b 48 89 45 c8 e9 13 fe ff ff <0f> 0b 
eb fe 0f 1f 80 00 00 00 00 55 48 89 e5 48 83 ec 20 4c 89
[   69.478216] RIP  [] map_single+0x255/0x260
[   69.489668]  RSP 
[   69.500975] ---[ end trace 6a2181b634e2abc7 ]---

Reported-by: Bokhan Artem 
Signed-off-by: Bjørn Mork 
Cc: sta...@kernel.org
---
 drivers/scsi/megaraid/megaraid_sas.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.c 
b/drivers/scsi/megaraid/megaraid_sas.c
index eb29d50..72713c5 100644
--- a/drivers/scsi/megaraid/megaraid_sas.c
+++ b/drivers/scsi/megaraid/megaraid_sas.c
@@ -4359,6 +4359,11 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance,
 * For each user buffer, create a mirror buffer and copy in
 */
for (i = 0; i < ioc->sge_count; i++) {
+   if (ioc->sgl[i].iov_len == 0) {
+   kbuff_arr[i] = NULL;
+   continue;
+   }
+
kbuff_arr[i] = dma_alloc_coherent(&instance->pdev->dev,
ioc->sgl[i].iov_len,
&buf_handle, GFP_KERNEL);
-- 
1.7.2.3

--- End Message ---

Bug#598793: sas controller resets causes drives to fail under mdadm

[Bjørn Mork]

Quintin  writes:

> Package: linux-image-2.6.26-2-xen-amd64
> Version: 2.6.26-24lenny1
> Severity: important
>
> The mpt SAS controller seems to misinterpret messages from the SATA
> drives connected to the SAS controller - causing mdadm to remove them
> from the array. The net result during this event is the array goes
> read-only or worse corrupts data.
>
> This issue has occurred on this version of equipment when running
> S.M.A.R.T. - which may be related?
[..]
> 05:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E 
> PCI-Express Fusion-MPT SAS (rev 08)


Sure is.  I have seen similar issues with this controller, especially
when running smartctl.

I believe this was fixed in the latest 2.6.32 stable update (2.6.32.23):

commit aaf3b48b50681f779723ea9bb141931739b75c4b
Author: Ryan Kuester 
Date:   Mon Apr 26 18:11:54 2010 -0500

SCSI: mptsas: fix hangs caused by ATA pass-through

commit 2a1b7e575b80ceb19ea50bfa86ce0053ea57181d upstream.

I may have an explanation for the LSI 1068 HBA hangs provoked by ATA
pass-through commands, in particular by smartctl.

First, my version of the symptoms.  On an LSI SAS1068E B3 HBA running
01.29.00.00 firmware, with SATA disks, and with smartd running, I'm seeing
occasional task, bus, and host resets, some of which lead to hard faults of
the HBA requiring a reboot.  Abusively looping the smartctl command,

# while true; do smartctl -a /dev/sdb > /dev/null; done

dramatically increases the frequency of these failures to nearly one per
minute.  A high IO load through the HBA while looping smartctl seems to
improve the chance of a full scsi host reset or a non-recoverable hang.

I reduced what smartctl was doing down to a simple test case which
causes the hang with a single IO when pointed at the sd interface.  See
the code at the bottom of this e-mail.  It uses an SG_IO ioctl to issue
a single pass-through ATA identify device command.  If the buffer
userspace gives for the read data has certain alignments, the task is
issued to the HBA but the HBA fails to respond.  If run against the sg
interface, neither the test code nor smartctl causes a hang.

sd and sg handle the SG_IO ioctl slightly differently.  Unless you
specifically set a flag to do direct IO, sg passes a buffer of its own,
which is page-aligned, to the block layer and later copies the result
into the userspace buffer regardless of its alignment.  sd, on the other
hand, always does direct IO unless the userspace buffer fails an
alignment test at block/blk-map.c line 57, in which case a page-aligned
buffer is created and used for the transfer.

The alignment test currently checks for word-alignment, the default
setup by scsi_lib.c; therefore, userspace buffers of almost any
alignment are given directly to the HBA as DMA targets.  The LSI 1068
hardware doesn't seem to like at least a couple of the alignments which
cross a page boundary (see the test code below).  Curiously, many
page-boundary-crossing alignments do work just fine.

So, either the hardware has an bug handling certain alignments or the
hardware has a stricter alignment requirement than the driver is
advertising.  If stricter alignment is required, then in no case should
misaligned buffers from userspace be allowed through without being
bounced or at least causing an error to be returned.

It seems the mptsas driver could use blk_queue_dma_alignment() to advertise
a stricter alignment requirement.  If it does, sd does the right thing and
bounces misaligned buffers (see block/blk-map.c line 57).  The following
patch to 2.6.34-rc5 makes my symptoms go away.  I'm sure this is the wrong
place for this code, but it gets my idea across.

Acked-by: Kashyap Desai 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman 



which was included in Debian linux-image-2.6.32-5-amd64 version
2.6.32-24.  You should check whether the issue is still present with
that version.

Given the age and stability of this driver, I believe it's reasonable to
guess that the issue was present in all 2.6.26 versions, and I guess it
won't be backported unless you do it yourself.



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

Bug#595502: closed by Ben Hutchings (Re: Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources)

[Bjørn Mork]

Thibaut VARENE  writes:

> Please find attached the dmesg pertaining to this wonderful disaster.
> What it doesn't show is the fact that I also saw the endless
> /sys/devices enumeration during this boot.

That's probably an unrelated bug in mdadm: http://bugs.debian.org/594418
Fixed in mdadm/3.1.4-1


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/877hizf5mc@nemi.mork.no

Bug#591951: linux-2.6: should suggest extlinux as an alternate bootloader on x86

[Bjørn Mork]

Package: linux-2.6
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The extlinux package is an excellent alternative to grub and lilo, and
deserves to be included in the linux-image "Suggests".

Thanks,
Bjørn

- -- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (700, 'stable'), (600, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (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

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

iEYEARECAAYFAkxcQ5oACgkQ10rqkowbIsnlYQCfc08Z40XF6VaB3t6kO3wuo63R
qJIAnRdPNnkKge0IX0BzhONapBpkQ6xP
=EFbg
-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/20100806171718.16294.90035.report...@nemi.mork.no

Re: Bug#588509: linux-image-2.6.32-5-amd64: hangs under Xen after Write protecting the kernel read-only data: 4220k

[Bjørn Mork]

Timo Juhani Lindfors  writes:

> However, it seems that the OOPS is caused by a write (error_code==3)
> to variable called "last_value" that is in read-only memory (.rodata):

Yes, Linus has already explained why here:
http://permalink.gmane.org/gmane.linux.kernel/1009506

Note that the patch he posts there isn't complete, and isn't fixing the
relevant part for the above problem, but the explanation is still
valid.


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

Re: Bug#588509: also 2.6.32-17 hangs

[Bjørn Mork]

Timo Juhani Lindfors  writes:

> I booted 2.6.32-17 once and it hang at
>
> Write protecting the kernel read-only data: 4220k

This is the same bug as #588426

You may try the patch from Linus Torvalds/Peter Palfrader:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=37;filename=linus.diff.backported;att=3;bug=588426


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/87630fk8vd@nemi.mork.no

Bug#588426: linux-image-2.6.32-5-amd64: fail to boot in a kvm virtual machine

[Bjørn Mork]

Ben Hutchings  writes:
> On Mon, 2010-07-12 at 10:22 +0200, Bjørn Mork wrote:
>
>> But I must admit that I was a bit surprised when 2.6.32-17 was uploaded
>> without a fix for this problem.  It makes me wonder if the severity
>> shouldn't have been higher after all  Just to be clear: This bug
>> does break all KVM based systems, making them completely unbootable, and
>> requiring console access to fix.  I'm pretty sure there are plenty of
>> KVM based hosting solutions around where this will be a severe problem.
>
> I haven't seen a fix for it yet.

Ah, sorry, I thought the fix was clear from the bug report: 

Peter Palfrader has bisected it down to commit 1345126c 
"x86, paravirt: Add a global synchronization point for pvclock" 
which sounds very reasonable, IMHO.  See
http://lkml.indiana.edu/hypermail/linux/kernel/1007.0/02385.html

To be absolutely sure this is correct, I just built a kernel based on
your 2.6.32-17 with commit 1345126c reverted, and that does indeed boot
under KVM.  The revert patch is attached.  Please try it.

I do hope this goes into next 2.6.32-stable as well, although the
discussion following Peter Palfrader's bisect seems a bit discouraging.
"that patch shouldn't affect anything outside..."  Right.  Well, it
does.  So please revert it in stable.


Thanks,
Bjørn

>From 5ffe322b5f3a76969525bf2cff3f029297179f27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= 
Date: Mon, 12 Jul 2010 13:23:57 +0200
Subject: [PATCH] Revert "x86, paravirt: Add a global synchronization point for pvclock"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This reverts commit 1345126c761f0360dc108973bf73281d51945bc1.

Signed-off-by: Bjørn Mork 
---
 arch/x86/kernel/pvclock.c |   24 
 1 files changed, 0 insertions(+), 24 deletions(-)

diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index dfdfe46..03801f2 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -109,14 +109,11 @@ unsigned long pvclock_tsc_khz(struct pvclock_vcpu_time_info *src)
 	return pv_tsc_khz;
 }
 
-static atomic64_t last_value = ATOMIC64_INIT(0);
-
 cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
 {
 	struct pvclock_shadow_time shadow;
 	unsigned version;
 	cycle_t ret, offset;
-	u64 last;
 
 	do {
 		version = pvclock_get_time_values(&shadow, src);
@@ -126,27 +123,6 @@ cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
 		barrier();
 	} while (version != src->version);
 
-	/*
-	 * Assumption here is that last_value, a global accumulator, always goes
-	 * forward. If we are less than that, we should not be much smaller.
-	 * We assume there is an error marging we're inside, and then the correction
-	 * does not sacrifice accuracy.
-	 *
-	 * For reads: global may have changed between test and return,
-	 * but this means someone else updated poked the clock at a later time.
-	 * We just need to make sure we are not seeing a backwards event.
-	 *
-	 * For updates: last_value = ret is not enough, since two vcpus could be
-	 * updating at the same time, and one of them could be slightly behind,
-	 * making the assumption that last_value always go forward fail to hold.
-	 */
-	last = atomic64_read(&last_value);
-	do {
-		if (ret < last)
-			return last;
-		last = atomic64_cmpxchg(&last_value, last, ret);
-	} while (unlikely(last != ret));
-
 	return ret;
 }
 
-- 
1.7.1

Bug#588426: linux-image-2.6.32-5-amd64: fail to boot in a kvm virtual machine

[Bjørn Mork]

Vincent Danjean  writes:

> Package: linux-2.6
> Version: 2.6.32-16
> Severity: important

[..]

> PS: the severity can be increased if lots of people experiments the same thing
> or lowered if this is specific to my configuration.

At first, I thought that the severity was appropriate as this bug
doesn't break *all* systems, and the kernel is somewhat special in that
most bugs will affect "the whole system".

But I must admit that I was a bit surprised when 2.6.32-17 was uploaded
without a fix for this problem.  It makes me wonder if the severity
shouldn't have been higher after all  Just to be clear: This bug
does break all KVM based systems, making them completely unbootable, and
requiring console access to fix.  I'm pretty sure there are plenty of
KVM based hosting solutions around where this will be a severe problem.

Is KVM a supported "hardware" platform i Debian?  I would expect so.  If
it is, then please raise the severity of this bug high enough to reflect
this.


Thanks,
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/87lj9hp0s9@nemi.mork.no

Re: A way to get 2.6.33 or 34 (or head)?

[Bjørn Mork]

Jeff Carr  writes:

> Is there a way to pull down newer versions of the kernels? I put sid
> on a new laptop, but the wireless is flaky. It's of course worth
> trying newer kernels with something like this. I'd try the stock deb
> packages if there was a apt repository for them.

It's in experimental:

bj...@nemi:~$ apt-cache policy linux-image-2.6.34-1-amd64
linux-image-2.6.34-1-amd64:
  Installed: (none)
  Candidate: 2.6.34-1~experimental.2
  Version table:
 2.6.34-1~experimental.2 0
  1 http://ftp.no.debian.org experimental/main Packages


See http://wiki.debian.org/DebianExperimental for instructions.



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

Re: Bug#585661: linux-2.6: support for gobi 2000 WWAN devices

[Bjørn Mork]

Mark Hymers  writes:
> On Tue, 15, Jun, 2010 at 01:44:45AM +0100, Ben Hutchings spoke thus..
>
>> > @@ -610,7 +610,7 @@
>> >for (i = 0; i < serial->num_ports; i++) {
>> >port = serial->port[i];
>> >if (!port->interrupt_in_urb) {
>> > -  dbg("%s: No interrupt URB for port %d\n", __func__, i);
>> > +  dbg("%s: No interrupt URB for port %d", __func__, i);
>> 
>> The newline should definitely be included, though this is not really
>> important.
>
> It was merged upstream without the newline.

Probably because include/linux/usb/serial.h has this:

/* Use our own dbg macro */
#undef dbg
#define dbg(format, arg...) \
do {\
if (debug)  \
printk(KERN_DEBUG "%s: " format "\n", __FILE__, ##arg); \
} while (0)



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

Bug#581876: Please apply upstream patch to fix the beep for some Thinkpad machines

[Bjørn Mork]

Note: the commits I refer below to are taken from
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git


Andrei Popescu  writes:

> 2.6.30 introduced a regression where some Thinkpads would not beep 
> anymore on plugging/unplugging the power chord. See this thread
> http://sourceforge.net/mailarchive/message.php?msg_id=m31vgd2v3h.fsf%40fox.lamasti.net
> for more info.
>
> The alsa developers came up with a patch[1], but I haven't been able to 
> test it myself as it won't apply against 2.6.32 from sid or even 2.6.33 
> from experimental.

That's because it depends on ee6e365e30f7ee89bd214ff1215aaf90e93d4c40
which isn't merged.  You may apply that first and then
0bf0e5a6f304ac1bc93a80cdd68b4d91f3519eb5 (which is the patch you refer
to taken from Linus' tree).  Together they apply cleanly to 2.6.32.

Or you could try the patch I've attached, which is a backported variant
of 0bf0e5a6f304ac1bc93a80cdd68b4d91f3519eb5, avoiding the change in
ee6e365e30f7ee89bd214ff1215aaf90e93d4c40.

If this does fix a regression in 2.6.32, then I guess it's really more
material for 2.6.32 stable than for Debian kernels directly?



Bjørn

>From 2ac9a8175fe49bb994f87eedbc30572978325d05 Mon Sep 17 00:00:00 2001
From: Jaroslav Kysela 
Date: Fri, 26 Mar 2010 10:33:18 +0100
Subject: [PATCH] ALSA: hda-intel - AD1984 thinkpad - add analog beep input control
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

commit 0bf0e5a6f304ac1bc93a80cdd68b4d91f3519eb5 upstream
[bjorn: backported to 2.6.32 to avoid applying
ee6e365e30f7ee89bd214ff1215aaf90e93d4c40 as well]

For Lenovo Thinkpad T61/X61, the analog beep input is connected
to node 0x20, index 3. Move the digital beep mute/volume controls
as "Digital Beep" and create analog beep controls for mentioned node.

Signed-off-by: Jaroslav Kysela 
Signed-off-by: Bjørn Mork 
---
 sound/pci/hda/patch_analog.c |   19 ---
 1 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c
index bd0794e..8ff539e 100644
--- a/sound/pci/hda/patch_analog.c
+++ b/sound/pci/hda/patch_analog.c
@@ -71,8 +71,9 @@ struct ad198x_spec {
 	struct hda_input_mux private_imux;
 	hda_nid_t private_dac_nids[AUTO_CFG_MAX_OUTS];
 
-	unsigned int jack_present :1;
-	unsigned int inv_jack_detect:1;
+	unsigned int jack_present: 1;
+	unsigned int inv_jack_detect: 1;/* inverted jack-detection */
+	unsigned int analog_beep: 1;	/* analog beep input present */
 
 #ifdef CONFIG_SND_HDA_POWER_SAVE
 	struct hda_loopback_check loopback;
@@ -163,6 +164,12 @@ static struct snd_kcontrol_new ad_beep_mixer[] = {
 	{ } /* end */
 };
 
+static struct snd_kcontrol_new ad_beep2_mixer[] = {
+	HDA_CODEC_VOLUME("Digital Beep Playback Volume", 0, 0, HDA_OUTPUT),
+	HDA_CODEC_MUTE_BEEP("Digital Beep Playback Switch", 0, 0, HDA_OUTPUT),
+	{ } /* end */
+};
+
 #define set_beep_amp(spec, nid, idx, dir) \
 	((spec)->beep_amp = HDA_COMPOSE_AMP_VAL(nid, 1, idx, dir)) /* mono */
 
@@ -196,7 +203,8 @@ static int ad198x_build_controls(struct hda_codec *codec)
 	/* create beep controls if needed */
 	if (spec->beep_amp) {
 		struct snd_kcontrol_new *knew;
-		for (knew = ad_beep_mixer; knew->name; knew++) {
+		knew = spec->analog_beep ? ad_beep2_mixer : ad_beep_mixer;
+		for ( ; knew->name; knew++) {
 			struct snd_kcontrol *kctl;
 			kctl = snd_ctl_new1(knew, codec);
 			if (!kctl)
@@ -3362,6 +3370,8 @@ static struct snd_kcontrol_new ad1984_thinkpad_mixers[] = {
 	HDA_CODEC_MUTE("Mic Playback Switch", 0x20, 0x00, HDA_INPUT),
 	HDA_CODEC_VOLUME("Internal Mic Playback Volume", 0x20, 0x01, HDA_INPUT),
 	HDA_CODEC_MUTE("Internal Mic Playback Switch", 0x20, 0x01, HDA_INPUT),
+	HDA_CODEC_VOLUME("Beep Playback Volume", 0x20, 0x03, HDA_INPUT),
+	HDA_CODEC_MUTE("Beep Playback Switch", 0x20, 0x03, HDA_INPUT),
 	HDA_CODEC_VOLUME("Docking Mic Playback Volume", 0x20, 0x04, HDA_INPUT),
 	HDA_CODEC_MUTE("Docking Mic Playback Switch", 0x20, 0x04, HDA_INPUT),
 	HDA_CODEC_VOLUME("Mic Boost", 0x14, 0x0, HDA_INPUT),
@@ -3403,6 +3413,8 @@ static struct hda_verb ad1984_thinkpad_init_verbs[] = {
 	{0x1c, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE},
 	/* docking mic boost */
 	{0x25, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_ZERO},
+	/* Analog PC Beeper - allow firmware/ACPI beeps */
+	{0x20, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(3) | 0x1a},
 	/* Analog mixer - docking mic; mute as default */
 	{0x20, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)},
 	/* enable EAPD bit */
@@ -3535,6 +3547,7 @@ static int patch_ad1984(struct hda_codec *codec)
 		spec->input_mux = &ad1984_thinkpad_capture_source;
 		spec->mixers[0] = ad1984_thinkpad_mixers;
 		spec->init_verbs[spec->num_init_verbs++] = ad1984_thinkpad_init_verbs;
+		spec->analog_beep = 1;
 		break;
 	case AD1984_DELL_DESKTOP:
 		spec->multiout.dig_out_nid = 0;
-- 
1.7.1

Re: Adding new drivers to Debian's 2.6.32 kernel?

[Bjørn Mork]

Ben Hutchings  writes:
> On Wed, 2010-06-02 at 10:39 +0200, Bjørn Mork wrote:
>
>> I am still unsure about the preferred way to provide such a driver
>> patch.  The first version attached to the bug was just a copy of the
>> upstream version with the necessary modifications to make it build under
>> 2.6.32. 
>> 
>> I have now done the job identifying which commits created the current
>> upstream version, and instead provided a patch set consisting of cherry
>> picked upstream commits. Is this preferred, even though it results in a
>> high number of patches (120 to be exact)?  It keeps a lot of meta data,
>> which I guess is useful.
> [...]
>
> We can use either form.  In this case, where there were several drivers
> involved, your patch set was very helpful.

Thanks for looking at it, and for providing this feedback.  Nice to know
for the next time I go out and buy some new hardware without checking
which kernel release the driver was added :-)


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

Re: Adding new drivers to Debian's 2.6.32 kernel?

[Bjørn Mork]

Ben Hutchings  writes:
> On Sat, 2010-04-10 at 21:21 +0200, Bjørn Mork wrote:
>
>> Do you think an exception may be possible for this driver?  If so, I can
>> prepare a patch proposal for review.
>
> Please do.  Also, report this as a bug.

I understand that the kernel team has lots of more important bugs to
take care of than wishlist bugs, but I'd really appreciate it if someone
commented on http://bugs.debian.org/577264

I am still unsure about the preferred way to provide such a driver
patch.  The first version attached to the bug was just a copy of the
upstream version with the necessary modifications to make it build under
2.6.32. 

I have now done the job identifying which commits created the current
upstream version, and instead provided a patch set consisting of cherry
picked upstream commits. Is this preferred, even though it results in a
high number of patches (120 to be exact)?  It keeps a lot of meta data,
which I guess is useful. 

This alternate patchset is now attached to the bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=mantis-patches.tar.gz;att=1;bug=577264


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

Re: uploading 2.6.32-13

[Bjørn Mork]

Ben Hutchings  writes:

> We rely on the kernel build configuration mechanism to select the
> frontend and tuner modules associated with a controller driver (such as
> budget), rather than explicitly enabling them.  Currently, enabling
> budget does not also enable stv090x.  I have included a fix for this in
> 2.6.32-13 and submitted it upstream.

Right.  That makes sense.  Thanks.


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/878w7lhtsg@nemi.mork.no

Re: uploading 2.6.32-13

[Bjørn Mork]

Hello,

you may want to note that adding stable 2.6.32.13 will close #575207 (or
so I hope :-).  See
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;h=65f202ba


It would be nice if the accompanying wishlist bug #575223 (enabling
CONFIG_DVB_STV090x) was fixed as well so that things actually worked,
but at least it won't oops anymore...



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

Re: RC bug #548434 seems kernel related

[Bjørn Mork]

Matteo Cypriani  writes:

> I'm currently adopting the fdutils package, and looking at the bug list, I 
> found that it has a RC bug (#548434) that seems not related to him but to the 
> kernel (this problem exist with several programs when trying to access floppy 
> drives).
> It is forwarded to https://patchwork.kernel.org/patch/69588/ and it seems 
> that 
> a patch has been developed and fixes the bug, but they don't say if this 
> patch 
> is integrated nor even give a pointer to it.
>
> Could someone have a look on that bug (lng page!) and on the patchwork 
> page and tell me if I can reassign the bug (and to which package exactly)?

The dialogue seems to point to this upstream commit:

commit 73472a46b5b28116b145fb5fc05242c1aa8e1461
Author: Pallipadi, Venkatesh 
Date:   Thu Jan 21 11:09:52 2010 -0800

x86: Disable HPET MSI on ATI SB700/SB800

HPET MSI on platforms with ATI SB700/SB800 as they seem to have some
side-effects on floppy DMA. Do not use HPET MSI on such platforms.

Original problem report from Mark Hounschell
http://lkml.indiana.edu/hypermail/linux/kernel/0912.2/01118.html

[ This patch needs to go to stable as well. But, there are some
  conflicts that prevents the patch from going as is. I can
  rebase/resubmit to stable once the patch goes upstream.
  hpa: still Cc:'ing stable@ as an FYI. ]

Tested-by: Mark Hounschell 
Signed-off-by: Venkatesh Pallipadi 
Cc: 
LKML-Reference: <20100121190952.ga32...@linux-os.sc.intel.com>
Signed-off-by: H. Peter Anvin 


This was included in the 2.6.32.8 stable release and thereby also in the
newest Debian kernels (since version 2.6.32-8).  You may want to get the
submitter to retest with the latest kernel from unstable.



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/874oiiy3ip@nemi.mork.no

Re: Adding new drivers to Debian's 2.6.32 kernel?

[Bjørn Mork]

Ben Hutchings  writes:

> On Sat, 2010-04-10 at 21:21 +0200, Bjørn Mork wrote:
>> Hello,
>> 
>> I am aware of the policy stated on
>> http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
>> and that this in general means that new features/drivers are rejected.
>
> That page is quite outdated, and I should fix it.  New drivers can be
> added so long as they have already been accepted upstream.
>
> [...]
>> I do realize that current policy is that new drivers should be packaged
>> as dkms source packages, but I believe that this is not a good solution
>> in this specific case because:
>
> We recommend DKMS for out-of-tree drivers, that is drivers that have not
> been accepted upstream.
>
> [...]
>> Do you think an exception may be possible for this driver?  If so, I can
>> prepare a patch proposal for review.
>
> Please do.  Also, report this as a bug.

Thanks. Great news!  Will do ASAP.


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

Adding new drivers to Debian's 2.6.32 kernel?

[Bjørn Mork]

Hello,

I am aware of the policy stated on
http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
and that this in general means that new features/drivers are rejected.

I still would like to ask for an exception: The "mantis" DVB driver was
included in upstream version 2.6.33. This driver is very self contained,
adding one directory under drivers/media/dvb/, 5 files (2 new frontends)
under drivers/media/dvb/frontends/, a one-line bugfix patch to
drivers/media/dvb/frontends/tda10021.c (which might be forwarded through
upstream stable, if so required) and otherwise only the necessary
Makefile and Kconfig changes.

I do realize that current policy is that new drivers should be packaged
as dkms source packages, but I believe that this is not a good solution
in this specific case because:
 - the separate driver package will only ever be needed for the 2.6.32 kernel
 - the driver is highly integrated in the DVB subsystem and links with a
   number of existing frontends.  The necessary header files are not
   part of linux-headers and would therefore have to be copied from the
   kernel source, creating problems if these should ever be changed.

Do you think an exception may be possible for this driver?  If so, I can
prepare a patch proposal for review.

If not, then I guess a dkms package is the way forward.  In that case,
do you have any guidelines on how to deal with the inclusion of header
files from kernel source?  The necessary headers are:

drivers/media/dvb/dvb-core/demux.h
drivers/media/dvb/dvb-core/dmxdev.h
drivers/media/dvb/dvb-core/dvb_ca_en50221.h
drivers/media/dvb/dvb-core/dvb_demux.h
drivers/media/dvb/dvb-core/dvbdev.h
drivers/media/dvb/dvb-core/dvb_frontend.h
drivers/media/dvb/dvb-core/dvb_net.h
drivers/media/dvb/dvb-core/dvb_ringbuffer.h
drivers/media/dvb/frontends/lnbp21.h
drivers/media/dvb/frontends/stb0899_cfg.h
drivers/media/dvb/frontends/stb0899_drv.h
drivers/media/dvb/frontends/stb0899_reg.h
drivers/media/dvb/frontends/stb6100_cfg.h
drivers/media/dvb/frontends/stb6100.h
drivers/media/dvb/frontends/stv0299.h
drivers/media/dvb/frontends/zl10353.h



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

Bug#573176: linux-kbuild-2.6.33

[Bjørn Mork]

Just a FYI for those noticing this bug report:  There are excellent
instructions on how to build a linux-kbuild-2.6.33 package yourself on 
http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage#Thestoryoflinux-kbuild-2.6

Something like the attached hack is necessary due to changes in
scripts/mod/modpost.c in 2.6.33, but other than that the 2.6.32 kbuild
source should do just fine.


Bjørn

ref http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage#Thestoryoflinux-kbuild-2.6

This patch seems necessary for 2.6.33 because scripts/mod/modpost.c 
now includes 

It only does 

/* Some toolchains use a `_' prefix for all user symbols. */
#ifdef CONFIG_SYMBOL_PREFIX
#define MODULE_SYMBOL_PREFIX CONFIG_SYMBOL_PREFIX
#else
#define MODULE_SYMBOL_PREFIX ""
#endif

based on it, so the following patch should be safe on Debian


Index: debian/bin/genorig.py
===
--- a/debian/bin/genorig.py	(revision 15501)
+++ b/debian/bin/genorig.py	(working copy)
@@ -97,10 +97,12 @@
 orig = os.path.join(self.dir, self.orig, 'kbuild')
 temp = os.path.join(self.dir, 'temp')
 os.makedirs(os.path.join(orig, 'include', 'linux'))
+os.makedirs(os.path.join(orig, 'include', 'generated'))
 for i in 'COPYING', 'Kbuild', 'Makefile':
 shutil.copyfile(os.path.join(temp, i), os.path.join(orig, i))
 for i in 'input.h', 'license.h', 'mod_devicetable.h':
 shutil.copyfile(os.path.join(temp, 'include', 'linux', i), os.path.join(orig, 'include', 'linux', i))
+shutil.copyfile('/dev/null', os.path.join(orig, 'include', 'generated', 'autoconf.h'))
 shutil.copytree(os.path.join(temp, 'scripts'), os.path.join(orig, 'scripts'))
 
 def tar(self):

Bug#575207: [PATCH] V4L/DVB: budget: Oops: "BUG: unable to handle kernel NULL pointer dereference"

[Bjørn Mork]

Never call dvb_frontend_detach if we failed to attach a frontend. This fixes
the following oops, which will be triggered by a missing stv090x module:

[8.172997] DVB: registering new adapter (TT-Budget S2-1600 PCI)
[8.209018] adapter has MAC addr = 00:d0:5c:cc:a7:29
[8.328665] Intel ICH :00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ 
17
[8.328753] Intel ICH :00:1f.5: setting latency timer to 64
[8.562047] DVB: Unable to find symbol stv090x_attach()
[8.562117] BUG: unable to handle kernel NULL pointer dereference at 00ac
[8.562239] IP: [] dvb_frontend_detach+0x4/0x67 [dvb_core]


Ref http://bugs.debian.org/575207


Signed-off-by: Bjørn Mork 
Cc: sta...@kernel.org
Cc: 575...@bugs.debian.org
---
This patch should apply cleanly to 2.6.32, 2.6.33, 2.6.34-rc2 and with an 
offset to git://linuxtv.org/v4l-dvb.git

Please apply to all of them


 drivers/media/dvb/ttpci/budget.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb/ttpci/budget.c b/drivers/media/dvb/ttpci/budget.c
index e48380c..95a463c 100644
--- a/drivers/media/dvb/ttpci/budget.c
+++ b/drivers/media/dvb/ttpci/budget.c
@@ -643,9 +643,6 @@ static void frontend_init(struct budget *budget)
&budget->i2c_adap,
&tt1600_isl6423_config);
 
-   } else {
-   dvb_frontend_detach(budget->dvb_frontend);
-   budget->dvb_frontend = NULL;
}
}
break;
-- 
1.5.6.5




--
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/1269428277-6709-1-git-send-email-bj...@mork.no

Bug#575207: linux-image-2.6.33-2-686: budget.ko causes kernel Oops with TT-budget S2-1600 DVB pci card

[Bjørn Mork]

clone 575207 -1
retitle -1 
severity -1 wishlist
found -1 2.6.32-10
tags 575207 + patch
thanks

Fladischer Michael  writes:

> [8.172997] DVB: registering new adapter (TT-Budget S2-1600 PCI)
> [8.209018] adapter has MAC addr = 00:d0:5c:cc:a7:29
> [8.328665] Intel ICH :00:1f.5: PCI INT B -> GSI 17 (level, low) -> 
> IRQ 17
> [8.328753] Intel ICH :00:1f.5: setting latency timer to 64
> [8.562047] DVB: Unable to find symbol stv090x_attach()

There are actually two bugs here.  This is one of them, and local to the
Debian kernel:  I assume it is built without 'CONFIG_DVB_STV090x=m',
like the 2.6.32 kernels seem to be?

I'm cloning that as a wishlist bug.


> [8.562117] BUG: unable to handle kernel NULL pointer dereference at 
> 00ac
> [8.562239] IP: [] dvb_frontend_detach+0x4/0x67 [dvb_core]

This is the second and far worse bug.  I'll followup with a patch for
upstream and stable.


Bjørn


pgpo3VHQFTzud.pgp
Description: PGP signature

Re: Requirements for inclusion in firmware-linux-nonfree

[Bjørn Mork]

Ben Hutchings  writes:

> Instead of complaining about a decision which was taken by the project
> several years ago, perhaps you could talk to Edgeport about fixing the
> licence (bug #548745).

You're of course perfectly right.  Sorry about the rant.  I've opened a
support case with Digi International Inc., who have taken over the
Edgeport product line.  I don't have much hope since the product is
quite old, but it can't hurt to let them know that this problem exists.
At least it gives them the opportunity to get some Linux community
goodwill for free (assuming that relicensing won't cost them a dime).


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/876350rl3q@nemi.mork.no

Requirements for inclusion in firmware-linux-nonfree

[Bjørn Mork]

This is probably answered somewhere, but I just can't find it right now:
what are the actual requirements for including a firmware which is
distributed from kernel.org in the Debian package firmware-linux-nonfree?

The reason I ask is because I was a bit surprised to find that my
edgeport usb serial adapter stopped working after upgrading from
2.6.26-2 to 2.6.32-3.  I knew the firmware had been moved outside the
driver and into the firmware/ directory of the upstream kernel source,
so I thought that installing firmware-linux-nonfree would solve this.
I then found bug #548745 and the question arised.  Why can't Debian
distribute something that is distributed from kernel.org, not even in
non-free?  Is that restriction really gaining anyone?

Well, not really a problem to me.  I can get the firmware from the
upstream kernel source.  But I assume other users may have more problems
with this.  And I believe that such self-imposed unnecessary
restrictions are only causing harm to Debian.



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

Re: Bug#565789: [ltp] Bug#565789: say what the current Thinkpad BIOS/Firmware should be

[Bjørn Mork]

Yves-Alexis Perez  writes:
> On 18/01/2010 21:28, jida...@jidanni.org wrote:
>
>> WARNING: Outdated ThinkPad BIOS/EC firmware
>> WARNING: This firmware may be missing critical bug fixes and/or important 
>> features
>> 
>> Perhaps it could mention what it believes the current versions should
>> be, so we can check the IBM website before decide we have send the unit
>> back to IBM to get whatever it is that is bothering it updated (as we
>> Linux users can't update the BIOS ourselves.)
>> 
>> Also it could mention perhaps some URLs on where it got its information
>> about what is current from.

This is all very well documented in drivers/platform/x86/thinkpad_acpi.c:

/*
 * The changelogs would let us track down the exact
 * reason, but it is just too much of a pain to track
 * it.  We only list BIOSes that are either really
 * broken, or really stable to begin with, so it is
 * best if the user upgrades the firmware anyway.
 */
printk(TPACPI_WARN
"WARNING: Outdated ThinkPad BIOS/EC firmware\n");
printk(TPACPI_WARN
"WARNING: This firmware may be missing critical bug "
"fixes and/or important features\n");
}


and 

/*
 * Table of recommended minimum BIOS versions
 *
 * Reasons for listing:
 *1. Stable BIOS, listed because the unknown ammount of
 *   bugs and bad ACPI behaviour on older versions
 *
 *2. BIOS or EC fw with known bugs that trigger on Linux
 *
 *3. BIOS with known reduced functionality in older versions
 *
 *  We recommend the latest BIOS and EC version.
 *  We only support the latest BIOS and EC fw version as a rule.
 *
 *  Sources: IBM ThinkPad Public Web Documents (update changelogs),
 *  Information from users in ThinkWiki
 *
 *  WARNING: we use this table also to detect that the machine is
 *  a ThinkPad in some cases, so don't remove entries lightly.
 */


Note especially the
 *  We recommend the latest BIOS and EC version.
 *  We only support the latest BIOS and EC fw version as a rule.



> I'm not sure about that particular ThinkPad, but I definitely can update
> my T61 bios. Lenovo provides bootable cd iso for them.

They don't for the older ThinkPads, but they do provide bootable floppy
images which are just as good (don't know if the R50e has a floppy
drive, but you can always convert the floppy image to an el-torito CD or
to a USB stick if necessary).  

The only problem with the Lenovo floppies is that they are embedded in a
floppy write utility for DOS, Windows or OS/2.  But there is a neat
Linux trick which I used with a Thinkpad T42: Download the "Non-Diskette" 
version from Lenovo and unpack it with "cabextract" (from the Debian
package with the same name).  The .exe contains a raw bootable floppy
image which can be dd'ed to a floppy or used on an el-torito CD or
whatever.  The rest of the files are just the Windows utilites which you
don't need.

E.g:

bj...@nemi:/tmp$ wget 
http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/1wuj25us.exe
--2010-01-19 10:48:21--  
http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/1wuj25us.exe
Resolving download.lenovo.com... 92.122.64.27
Connecting to download.lenovo.com|92.122.64.27|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1355800 (1.3M) [application/octet-stream]
Saving to: `1wuj25us.exe'

100%[==>]
 1,355,800173K/s   in 7.2s

2010-01-19 10:48:30 (183 KB/s) - `1wuj25us.exe' saved [1355800/1355800]

bj...@nemi:/tmp$ cabextract 1wuj25us.exe 
1wuj25us.exe: library not compiled to support large files.
1wuj25us.exe: library not compiled to support large files.
Extracting cabinet: 1wuj25us.exe
  extracting 1WUJ25US.IMG
  extracting IBMTPI.XML
  extracting BIOSUPTP.EXE
  extracting doboot.exe
  extracting DOSBOOT.COM
  extracting dosboot.sys
  extracting DOSBOOT.vxd
  extracting DOSBOOT2.COM
  extracting dosboot2.sys
  extracting dosboot3.COM
  extracting eflashas.sys

All done, no errors.

bj...@nemi:/tmp$ ls -l 1WUJ25US.IMG
-rw-r--r-- 1 bjorn bjorn 1474560 2006-12-11 02:10 1WUJ25US.IMG
bj...@nemi:/tmp$ file 1WUJ25US.IMG
1WUJ25US.IMG: DOS floppy 1440k, x86 hard disk boot sector



Follow the Lenovo instructions after creating the floppy or CD images.



Bjørn


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#435387: Redirect to Kernel?

[Bjørn Mork]

Patrik Schindler  writes:

> Good point. But Token Ring Card drivers already exist, even if there
> is likely not a very much bigger demand. :-)

Well, they do exist but they are probably going away too.  I don't see
anyone really interested in hacking on them, so they are staying just as
long as they continue to work.  Which may not be that long...

E.g. my nice triple lanstreamer card doesn't work after upgrading the
rest of the system to 64bit, as the original driver does a whole lot of
magic DMA access and no-one has cleaned it up for 64bit.  So the driver
is disabled for 64bit systems.  I don't think anyone will bother to fix
it.  I briefly looked at it, and found that there's definitely a reason
why this was just disabled.  It's a mess.

The card is in the attic now, with the rest of my Token Ring stuff.
Except for a Cisco 2612 which serves as an Ethernet/Serial only router.


Bjørn



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#435387: Redirect to Kernel?

[Bjørn Mork]

I just noticed this bug report, and couldn't let be commenting...

I believe "buried in ddp.c" is a little unprecise.  ddp.c implements the
EtherTalk Link Access Protocol (ELAP).  See the header of
net/appletalk/ddp.c:

 *  DDP:An implementation of the AppleTalk DDP protocol for
 *  Ethernet 'ELAP'.


If you want to run AppleTalk on Token Ring, then you need an
implementation of the TokenTalk Link Access Protocol (TLAP).  See e.g. 
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/AppleTalk.html#wp1020654

My guess is that you'd have to write that yourself.  I would be
surprised if there was a high demand...


Bjørn



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#535331: 2.6.26-17lenny2 => 2.6.26-19 OK, 2.6.26-19 => 2.6.26-19lenny1 NOT OK

[Bjørn Mork]

Just to add another data point, lilo failed to run again for me too on
the 2.6.26-19lenny1 upgrade.  Even after working on the previous kernel
upgrade!  

I'm now totally lost wrt what triggers this bug...


To summarize:

2.6.26-17lenny2 =>  2.6.26-19  
  lilo OK

2.6.26-19 => 2.6.26-19lenny1
  lilo not running


There were no changes to neither initramfs-tools nor /etc/kernel-img.conf 
between these upgrades.  My /etc/kernel-img.conf is still

 adler:/tmp# cat /etc/kernel-img.conf 
 # Kernel Image management overrides
 # See kernel-img.conf(5) for details
 do_symlinks = Yes
 do_initrd = Yes
 do_bootloader = yes


The upgrade log is shorter, and the shortage is of course the problem:

 Setting up linux-image-2.6.26-2-686 (2.6.26-19lenny1) ...
 Running depmod.
 Running mkinitramfs-kpkg.
 Not updating initrd symbolic links since we are being updated/reinstalled 
 (2.6.26-19 was configured last, according to dpkg)
 Not updating image symbolic links since we are being updated/reinstalled 
 (2.6.26-19 was configured last, according to dpkg)
 Setting up linux-libc-dev (2.6.26-19lenny1) ...

(nothing more)

At this point, the previous upgrade continued with 
"update-initramfs: deferring update (trigger activated)"
so maybe this is some trigger-related problem?  I do however note that
the initrd.img is updated, even though the message
"update-initramfs: Generating /boot/initrd.img-2.6.26-2-686"
also is missing.

Any clues are appreciated.  It's a real hassle to have to log in to each
and every server and manually run lilo after each kernel security
update, or risk dead servers on the next reboot.


Bjørn



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#535331:

[Bjørn Mork]

I am sorry, but I'm afraid my previous analysis in this bug report is
completely wrong. 

The kernel image maintainer scripts are not supposed to run lilo
directly.  They trigger an initramfs update, and that should in turn
cause lilo to run after it's finished.  The initramfs update must do
this regardless of why it was run, and having the kernel scripts run
lilo would therefore be useless.

And now for the weird stuff: This did suddenly work for me with the
2.6.26-19 upgrade.  I got:

Setting up linux-image-2.6.26-2-686 (2.6.26-19) ...
Running depmod.
Running mkinitramfs-kpkg.
Not updating initrd symbolic links since we are being updated/reinstalled 
(2.6.26-17lenny2 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled 
(2.6.26-17lenny2 was configured last, according to dpkg)
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.26-2-686
Added Linux *
Added LinuxOLD


But I cannot understand what may have changed.  My /etc/kernel-img.conf
is still and has always been:

# Kernel Image management overrides
# See kernel-img.conf(5) for details
do_symlinks = Yes
do_initrd = Yes
do_bootloader = yes


And initramfs-tools have not been upgraded since the last time this
failed according to the dpkg log.  But the dpkg log above shows
something very interesting: This time I got a "status triggers-pending
initramfs-tools 0.92o" which I did not see on the previous kernel image
upgrade:

adler:/tmp# egrep 'linux-image|initramfs-tools' /var/log/dpkg.log{.1,}
/var/log/dpkg.log.1:2009-08-15 01:00:40 upgrade linux-image-2.6.26-2-686 
2.6.26-17lenny1 2.6.26-17lenny2
/var/log/dpkg.log.1:2009-08-15 01:00:40 status half-configured 
linux-image-2.6.26-2-686 2.6.26-17lenny1
/var/log/dpkg.log.1:2009-08-15 01:00:41 status unpacked 
linux-image-2.6.26-2-686 2.6.26-17lenny1
/var/log/dpkg.log.1:2009-08-15 01:00:41 status half-installed 
linux-image-2.6.26-2-686 2.6.26-17lenny1
/var/log/dpkg.log.1:2009-08-15 01:00:47 status half-installed 
linux-image-2.6.26-2-686 2.6.26-17lenny1
/var/log/dpkg.log.1:2009-08-15 01:00:49 status unpacked 
linux-image-2.6.26-2-686 2.6.26-17lenny2
/var/log/dpkg.log.1:2009-08-15 01:00:49 status unpacked 
linux-image-2.6.26-2-686 2.6.26-17lenny2
/var/log/dpkg.log.1:2009-08-15 01:00:53 configure linux-image-2.6.26-2-686 
2.6.26-17lenny2 2.6.26-17lenny2
/var/log/dpkg.log.1:2009-08-15 01:00:53 status unpacked 
linux-image-2.6.26-2-686 2.6.26-17lenny2
/var/log/dpkg.log.1:2009-08-15 01:00:53 status half-configured 
linux-image-2.6.26-2-686 2.6.26-17lenny2
/var/log/dpkg.log.1:2009-08-15 01:01:27 status installed 
linux-image-2.6.26-2-686 2.6.26-17lenny2
/var/log/dpkg.log:2009-09-06 01:00:53 upgrade linux-image-2.6.26-2-686 
2.6.26-17lenny2 2.6.26-19
/var/log/dpkg.log:2009-09-06 01:00:53 status half-configured 
linux-image-2.6.26-2-686 2.6.26-17lenny2
/var/log/dpkg.log:2009-09-06 01:00:55 status unpacked linux-image-2.6.26-2-686 
2.6.26-17lenny2
/var/log/dpkg.log:2009-09-06 01:00:55 status half-installed 
linux-image-2.6.26-2-686 2.6.26-17lenny2
/var/log/dpkg.log:2009-09-06 01:01:07 status half-installed 
linux-image-2.6.26-2-686 2.6.26-17lenny2
/var/log/dpkg.log:2009-09-06 01:01:09 status unpacked linux-image-2.6.26-2-686 
2.6.26-19
/var/log/dpkg.log:2009-09-06 01:01:09 status unpacked linux-image-2.6.26-2-686 
2.6.26-19
/var/log/dpkg.log:2009-09-06 01:01:26 configure linux-image-2.6.26-2-686 
2.6.26-19 2.6.26-19
/var/log/dpkg.log:2009-09-06 01:01:26 status unpacked linux-image-2.6.26-2-686 
2.6.26-19
/var/log/dpkg.log:2009-09-06 01:01:27 status half-configured 
linux-image-2.6.26-2-686 2.6.26-19
/var/log/dpkg.log:2009-09-06 01:02:02 status installed linux-image-2.6.26-2-686 
2.6.26-19
/var/log/dpkg.log:2009-09-06 01:02:03 status triggers-pending initramfs-tools 
0.92o
/var/log/dpkg.log:2009-09-06 01:02:08 trigproc initramfs-tools 0.92o 0.92o
/var/log/dpkg.log:2009-09-06 01:02:08 status half-configured initramfs-tools 
0.92o
/var/log/dpkg.log:2009-09-06 01:02:55 status installed initramfs-tools 0.92o


Why? Or rather:  Why doesn't it always do that?



Bjørn



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#544756: linux-image-2.6.26-2-686: Kernel still vulnerable by dsa-1862

[Bjørn Mork]

Christoph Siess  writes:

> I'm very, sorry - I forgot to run lilo :(.

Maybe #535331 should get a security tag?  It does deserve to get fixed
both in lenny and etchnhalf IMHO, so the severity should be increased at
some point.  But I was kind of hoping that the kernel team would just
add the build fix silently in connection with other security fixes.

As Christoph has demonstrated: The issue does have real world security
consequences.


Bjørn


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#542470: closed by maximilian attems (Re: Bug#542470: linux-image-2.6.30-1-686: IPv6 can not be disabled)

[Bjørn Mork]

advocatux  writes:

> Yep, I know I can add "ipv6.disable=1" in /boot/grub/menu.lst but this
> method doesn't work always, it depends on which 2.6.30 kernel version
> you're running.

It works with the 2.6.30 kernel in Debian.  I'm no DD but I believe that
is about as much as you can expect Debian to support...

>>> Yeah, just like having IPv4 enabled by default.  Given the number of
>>> attacks, I would say that IPv4 is much more dangerous and should be
>>> disabled immediately by any sane administrator :-)
>>
>> triple *lol* ;)
>
> Certainly that mockery doesn't fit with Debian community spirit, does
> it? and for sure doesn't help to fill bug reports.

I put the smiley there for a reason.  I apologize if my comment hurt you
in any way.

I'm sure the kernel team found your bug report very useful even if it
was closed.  It does help documenting the potential problems users may
face, and will serve as help to others having the same question as you.

> People analizing this bug in Ubuntu Bug System
> (https://bugs.launchpad.net/bugs/351656) changed the status from
> security vulnerability "no" to "yes", and that's because an initial
> machine running other kernel, with IPv4 traffic filtered and IPv6
> disabled, after install a 2.6.30 kernel ends with unfiltered ports
> listening to IPv6 traffic.

Well, AFAIK there is no change to a default Debian installation. IPv6 is
enabled by default both in 2.6.26 and 2.6.30 and there are no iptables
or ip6tables rules installed.

Something could of course have checked on upgrade whether the admin
chose to blacklist the ipv6 module and warn that this has no effect
anymore, but personally I don't see the need.  If you do, I'm pretty
sure that patches are welcome as usual.

For the record: Unfiltered ports are not a security problem.  Network
protocol support is not a security problem.  Debian is as secure with
IPv6 enabled as it is with IPv4 enabled.  If you think otherwise, then I
suggest you demonstrate the attack and file appropriate bugs against the
packages with the real security problem.  Security in Linux is not based
on the kernel preventing application abuse by disabling any useful
feature.



Bjørn


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#542470: linux-image-2.6.30-1-686: IPv6 can not be disabled

[Bjørn Mork]

advocatux  writes:

> IPv6 is enabled by default in kernel 2.6.30 and can't be disabled, at
> least not in an easy way.

Sure there is.  Boot with "ipv6.disable=1" on the command line.


kvm-sid:~# dmesg|grep -i ipv6
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.30-1-amd64 
root=UUID=0d3e856e-8f99-4b3e-8d4f-37a65486930b ro console=tty0 
console=ttyS0,9600n8 ipv6.disable=1
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.30-1-amd64 
root=UUID=0d3e856e-8f99-4b3e-8d4f-37a65486930b ro console=tty0 
console=ttyS0,9600n8 ipv6.disable=1
[0.585652] IPv6: Loaded, but administratively disabled, reboot required to 
enable
[0.588546] Mobile IPv6
kvm-sid:~# ifconfig eth0
eth0  Link encap:Ethernet  HWaddr 00:aa:00:ff:00:fc  
  inet addr:192.168.3.230  Bcast:192.168.3.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:13 errors:0 dropped:0 overruns:0 frame:0
  TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:1406 (1.3 KiB)  TX bytes:1190 (1.1 KiB)



> I've tried both echo 1 >/proc/sys/net/ipv6/conf/all/disable_ipv6 and sysctl 
> -w net.ipv6.conf.all.disable_ipv6=1 methods without any success.
>
> I think this bug is related to https://bugs.launchpad.net/bugs/351656 in 
> Ubuntu.
>
> In that report someone says there's a fix from upstream and that's already 
> fixed in 2.6.31 series.

Oh, it went in a while ago.  See
http://patchwork.ozlabs.org/patch/27856/

> There'd be a possible security risk in this whole thing.

Yeah, just like having IPv4 enabled by default.  Given the number of
attacks, I would say that IPv4 is much more dangerous and should be
disabled immediately by any sane administrator :-)



Bjørn



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#535331: Can anyone please explain why 'lilo' was removed from linux-image-*.postinst?

[Bjørn Mork]

maximilian attems  writes:

> thanks for your fine analysis, could you for completness please post
> the output of the following:
> cat /etc/kernel-img.conf

Of course, but do note that there is nothing you can set there which
will make the postinst script continue past the line

  last unless $loaderloc;

as $loaderloc will be undefined if $loader is '', and none of these
variables are controlled by /etc/kernel-img.conf.


bm...@adler:~$ cat /etc/kernel-img.conf
# Kernel Image management overrides
# See kernel-img.conf(5) for details
do_symlinks = Yes
do_initrd = Yes
do_bootloader = yes



Bjørn



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#535331: Can anyone please explain why 'lilo' was removed from linux-image-*.postinst?

[Bjørn Mork]

The issue is this difference:

--- /var/lib/dpkg/info/linux-image-2.6.18-6-686.postinst2009-05-05 
07:43:48.0 +0200
+++ /var/lib/dpkg/info/linux-image-2.6.24-etchnhalf.1-686.postinst  
2009-07-27 06:37:00.0 +0200
@@ -25,7 +25,7 @@
 $|=1;
 
 # Predefined values:
-my $version   = "2.6.18-6-686";
+my $version   = "2.6.24-etchnhalf.1-686";
 my $link_in_boot  = "";  # Should be empty, mostly
 my $no_symlink= "";   # Should be empty, mostly
 my $reverse_symlink   = "";   # Should be empty, mostly
@@ -34,8 +34,8 @@
 my $do_bootfloppy = "Yes";  # target machine defined
 my $do_bootloader = "Yes";  # target machine defined
 my $move_image= ''; # target machine defined
-my $kimage= "bzImage";   # Should be empty, mostly
-my $loader= "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, 
arcboot or delo
+my $kimage= "";   # Should be empty, mostly
+my $loader= ""; # lilo, silo, quik, palo, vmelilo, nettrom, 
arcboot or delo
 my $image_dir = "/boot";# where the image is located
 my $clobber_modules   = '';  # target machine defined
 my $relative_links= "";  # target machine defined


The $loader change prevents lilo from being automatically run after
installing the image.

I've been running into this problem for a while, and until now just
made one of the two workarounds I suspect most users choose:
a) replace lilo with grub
b) run lilo manually after installing a new linux-image

I do however manage a few servers where installing grub has been
considered too risky at the moment (due to no-way-out-if-it-blows-up).
So they still have lilo.  However, running lilo is also risky with the
newer kernel images due to this bug.  Security updates may overwrite the
lilo default image, causing a boot failure unless lilo is run manually
first.  I only have serial console access to these servers, so that
means a dead server until I can arrange physical access (which is why I
can't just install grub either). This makes the bug serious to me.

Now, to stop whining and start working:  I have tried to find the answer
to the question in the subject, but have found nothing. Which suggests
that the bug is just a mere accident when the build system was changed
somewhere between the 2.6.18 and 2.6.24 etch images.

It would be very nice if someone from the kernel team could verify that,
and if the attached patch could be considered.  The patch is made
against the 2.6.24-etchnhalf.1 source, but does also apply to the
2.6.26-2 source. Please let me know if I should provide it in some other
way.  The point is that it needs to be applied to the current etch and
lenny builds. 

Please note that similar bug reports seem to have been pushed back and
forth between linux-image-* and lilo for a while.  See e.g. bug #342542.

Removing lilo is of course also an option for future releases, but it
won't fix the bug wrt the etch and lenny linux-images.


Bjørn
--- linux-2.6.24-2.6.24/debian/rules.real.orig	2009-07-31 12:07:59.0 +0200
+++ linux-2.6.24-2.6.24/debian/rules.real	2009-07-31 12:57:04.0 +0200
@@ -403,6 +403,9 @@
 
 install-image_powerpc_$(FEATURESET)_$(FLAVOUR)_plain_templates: ARG_KIMAGE = vmlinux
 
+install-image_amd64_$(FEATURESET)_$(FLAVOUR)_plain_templates \
+install-image_i386_$(FEATURESET)_$(FLAVOUR)_plain_templates: ARG_BOOTLOADER = lilo
+
 install-image_s390_$(FEATURESET)_$(FLAVOUR)_plain_templates: ARG_BOOTLOADER = zipl
 
 install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_plain_templates:

Bug#521279: linux-2.6: bluetooth on/off button stopped working on Lenovo Thinkpad

[Bjørn Mork]

Package: linux-2.6
Version: 2.6.29-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The button switching bluetooth on/off on Lenovo Thinkpad stopped working 
after upgrading from 2.6.28-1-amd64 to 2.6.29-1-amd64.

According to Henrique de Moraes Holschuh (thinkpad_acpi maintainer), 
this is because CONFIG_ACPI_PROC_EVENT is disabled.  Quoting from a
discussion on the linux-thinkpad list:

- ---
On Wed, 25 Mar 2009, Bjørn Mork wrote:
> config thing.  I noticed that Debian now has disabled
> CONFIG_ACPI_PROC_EVENT.  Could this be related?

Yes.  Without CONFIG_ACPI_PROC_EVENT you will get hotkey events *ONLY*
through the thinkpad-acpi input device.

It has been that way for more than one year, now.  It is warned everywhere
in the driver, there is even a backwards compatibility strategy in place,
which won't help you because acpid never got fixed to deal with netlink
events.
- ---

(ref http://permalink.gmane.org/gmane.linux.hardware.thinkpad/38534 )

I do use the latest and greatest acpid:

bj...@nemi:~$ apt-cache policy acpid
acpid:
  Installed: 1.0.8-6
  Candidate: 1.0.8-6
  Version table:
 *** 1.0.8-6 0
600 http://ftp.no.debian.org sid/main Packages
100 /var/lib/dpkg/status
 1.0.8-1 0
700 http://ftp.no.debian.org lenny/main Packages

I believe acpid have to be fixed before CONFIG_ACPI_PROC_EVENT can be
disabled.  Please enable it again for the next release.


Bjørn


- -- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.29-1-amd64 (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

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

iEYEARECAAYFAknLc1wACgkQ10rqkowbIskG+wCdGQbonRa+7SrMuWqoQGTONGf8
WAIAoIFysrZPzid27nBy0NagHrn0KVMO
=uXTk
-END PGP SIGNATURE-



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#516734: linux-headers-2.6.28-1-amd64: Dependency on linux-kbuild-2.6.28 cannot be meet

[Bjørn Mork]

"Nikolay A. Panov"  writes:

> I cannot install linux-header-2.6.18-1-amd64 package sice it depends
> on linux-kbuild-2.6.28 package which is not in repository.

Any hope of getting this fixed?  I'd really like to build a few modules
for this kernel.



Bjørn
-- 
I couldn't care less about your system call


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#515826: your mail

[Bjørn Mork]

Steve Langasek  writes:

>> Comments/Problems:
>> Trying to boot the Debian 5.0 netboot install image fails to detect CD
>> and/or network card (DE422). It boots up to the install screen just fine,
>> but without CD/network card support unable to install base system. (scsi
>> controller- aha1742 (eisa), network card - de422 (eisa)
>
> Do you know what kernel drivers are supposed to be used for these devices? 
> possibly aha1740 for the SCSI card, but I don't have a guess as to which
> driver should be used for the network card.

depca.  Don't think that's included in Debian kernels.

config DEPCA
tristate "DEPCA, DE10x, DE200, DE201, DE202, DE422 support"
depends on ISA || EISA || MCA
select CRC32
---help---
  If you have a network (Ethernet) card of this type, say Y and read
  the Ethernet-HOWTO, available from
   as well as
  .

  To compile this driver as a module, choose M here. The module
  will be called depca.


Bjørn



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#508460: ipv6: add/up results in permanent 'tentative' flag, up/add works

[Bjørn Mork]

martin f krafft <[EMAIL PROTECTED]> writes:

> If I add an address to an interface (bridge or physical interface,
> does not matter), and then up the iface, then the tentative flag on
> the address never gets cleared (look for SEE HERE markers):

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e3ec6cfc260e2322834e200c2fa349cdf104fd13


Bjørn
-- 
return -ENOCOFFEE;



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#506419: Driver from Supermicro fixes issue

[Bjørn Mork]

martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Bjørn Mork <[EMAIL PROTECTED]> [2008.12.09.1413 +0100]:
>> This should not apply against linux-2.6 2.6.26-11 since it is already a
>> part of debian/patches/bugfix/all/stable/2.6.26.4.patch. Are you sure
>> your patch really does apply?  If it does, then I'd suggest trying
>> *just* edcfe5f7e307846e578fb88d69fa27051fded0ab instead.
>
> My patch does no "apply", it was made against 2.6.26-11 --
> Supermicro just sent me their forcedeth.c and I made the patch.

Probably against the unpatched 2.6.26 then?  OK, that will explain the
similarities.  But then the real problem must be something else.  Sorry
for the confusion.

>> BTW, I also noticed that linux-2.6 2.6.26-11 includes the patch
>> linux-2.6-2.6.26/debian/patches/features/all/net-use-gso.patch
>> which very well may trigger the problem.  You might also want to
>> try building without that patch.
>
> I have not tried -11 on the server, only -8 and -10, which both had
> the problems.
>
> How do I find out when net-use-gso.patch was added? The changelog
> does not mention it, and I cannot find a repository for the source
> (there are also no Vcs-* links in the package).

http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.26-11/changelog#versionversion2.6.26-2

has a

  * net: use software GSO for SG+CSUM capable netdevices (Lennert Buytenhek)

line, which matches the subject in the patch.


Bjørn



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#508259: linux-image-2.6.18-6-k7: Local kernel panic exploit

[Bjørn Mork]

Kuba Plichcinski <[EMAIL PROTECTED]> writes:

> Package: linux-image-2.6.18-6-k7
> Version: 2.6.18.dfsg.1-23
> Severity: critical
> Tags: security
> Justification: breaks the whole system
>
>
> These exploit freezess all my Debian/Ubuntu machines:
>
> http://www.milw0rm.com/exploits/7091

See http://security-tracker.debian.net/tracker/CVE-2008-5029

You could consider upgrading to linux-image-2.6.24-etchnhalf.1-686
version 2.6.24-6~etchnhalf.7 or later if you don't want for the fix
backport to 2.6.18.



Bjørn
-- 
return -ENOCOFFEE;



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#506419: Driver from Supermicro fixes issue

[Bjørn Mork]

martin f krafft <[EMAIL PROTECTED]> writes:

> The attached patch against linux-2.6 2.6.26-11 seems to fix the
> original problem for me, but I have not had a chance to verify the
> second ('downstream') problem I identified in the bug report.
>
> The patch is based on the driver source I obtained via Transtec from
> Supermicro, the board manufacturer. It's quite ugly and big and
> I don't have the time to dissect it right now, but if you want me to
> try out particulars, I will.


Hmm, this part of your patch looks a lot like half of
edcfe5f7e307846e578fb88d69fa27051fded0ab which Bastian already has
pointed you to:

> @@ -5417,11 +6978,15 @@ static int __devinit nv_probe(struct pci_dev 
> *pci_dev, const struct pci_device_i
>   if (id->driver_data & DEV_HAS_LARGEDESC)
>   np->pkt_limit = NV_PKTLIMIT_2;
>  
> + dev->mtu = ETH_DATA_LEN;
> +
>   if (id->driver_data & DEV_HAS_CHECKSUM) {
>   np->rx_csum = 1;
>   np->txrxctl_bits |= NVREG_TXRXCTL_RXCHECK;
> - dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> + dev->features |= NETIF_F_IP_CSUM|NETIF_F_SG;
> +#ifdef NETIF_F_TSO
>   dev->features |= NETIF_F_TSO;
> +#endif
>   }
>  
>   np->vlanctl_bits = 0;


This should not apply against linux-2.6 2.6.26-11 since it is already a
part of debian/patches/bugfix/all/stable/2.6.26.4.patch. Are you sure
your patch really does apply?  If it does, then I'd suggest trying
*just* edcfe5f7e307846e578fb88d69fa27051fded0ab instead.


BTW, I also noticed that linux-2.6 2.6.26-11 includes the patch 
linux-2.6-2.6.26/debian/patches/features/all/net-use-gso.patch
which very well may trigger the problem.  You might also want to try
building without that patch.

In fact, I'm a little confused as to the reasons that patch is in
Debian.  It is probably the correct thing to do, but it is also the kind
of thing that is bound to cause regressions because it will expose
latent bugs in drivers.

But then again, there's your performance requirements.  I guess you'd
better get a proper NIC :-)


Bjørn
-- 
You have the narrow-mindedness of a disease carrier



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#506628: linux-2.6: please add usbmon module to the amd64 kernel image

[Bjørn Mork]

Paul Wise <[EMAIL PROTECTED]> writes:

> Package: linux-2.6
> Severity: wishlist
>
> usbmon.ko is available on most platforms, but it seems to have been
> overlooked on amd64. I would like to have it for reverse engineering USB
> protocols. I switched from i386 to amd64 since the last time I was doing
> that and was surprised to find it was not available.
>
> http://packages.debian.org/file:usbmon.ko

It is not a module because USB support is built-in:

[EMAIL PROTECTED]:~$  egrep '^CONFIG_USB(_MON)?=' /boot/config-2.6.26-1-amd64 
CONFIG_USB=y
CONFIG_USB_MON=y

Which means that it is available by default:

[EMAIL PROTECTED]:~$ uname -a
Linux canardo 2.6.26-1-amd64 #1 SMP Thu Oct 9 14:16:53 UTC 2008 x86_64 GNU/Linux
[EMAIL PROTECTED]:~$ df /sys/kernel/debug
Filesystem   1K-blocks  Used Available Use% Mounted on
debug0 0 0   -  /sys/kernel/debug
[EMAIL PROTECTED]:~$ ls -ld /sys/kernel/debug/usbmon
drwxr-xr-x 2 root root 0 2008-10-17 17:20 /sys/kernel/debug/usbmon



Bjørn
-- 
Insecure dependency in cortex while running with -T switch



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#505961: linux-2.6: Please add a proper description of the -xen- packages

[Bjørn Mork]

Package: linux-2.6
Version: 2.6.26-10
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Searching for available kernels on amd64 and i686 gives

[EMAIL PROTECTED]:~$ apt-cache search linux-image-2.6.26|grep image
linux-image-2.6.26-1-amd64 - Linux 2.6.26 image on AMD64
linux-image-2.6.26-1-openvz-amd64 - Linux 2.6.26 image on AMD64, OpenVZ support
linux-image-2.6.26-1-vserver-amd64 - Linux 2.6.26 image on AMD64, Linux-VServer 
support
linux-image-2.6.26-1-xen-amd64 - Linux 2.6.26 image on AMD64

[EMAIL PROTECTED]:/tmp$ apt-cache search linux-image-2.6.26|grep image
linux-image-2.6.26-1-486 - Linux 2.6.26 image on x86
linux-image-2.6.26-1-686 - Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4
linux-image-2.6.26-1-686-bigmem - Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4
linux-image-2.6.26-1-amd64 - Linux 2.6.26 image on AMD64
linux-image-2.6.26-1-openvz-686 - Linux 2.6.26 image on 
PPro/Celeron/PII/PIII/P4, OpenVZ support
linux-image-2.6.26-1-vserver-686 - Linux 2.6.26 image on 
PPro/Celeron/PII/PIII/P4, Linux-VServer support
linux-image-2.6.26-1-vserver-686-bigmem - Linux 2.6.26 image on 
PPro/Celeron/PII/PIII/P4, Linux-VServer support
linux-image-2.6.26-1-xen-686 - Linux 2.6.26 image on i686


There is absolutely nothing here indicating the difference between 
linux-image-2.6.26-1-amd64 and linux-image-2.6.26-1-xen-amd64
or between linux-image-2.6.26-1-686 and linux-image-2.6.26-1-xen-686


Even worse, looking at the full description doesn't give any more clues:

[EMAIL PROTECTED]:~$ apt-cache show linux-image-2.6.26-1-amd64
Package: linux-image-2.6.26-1-amd64
Priority: optional
Section: admin
Installed-Size: 80592
Maintainer: Debian Kernel Team 
Architecture: amd64
Source: linux-2.6
Version: 2.6.26-10
Provides: linux-image, linux-image-2.6, linux-modules-2.6.26-1-amd64
Depends: module-init-tools, initramfs-tools (>= 0.55) | yaird (>= 0.0.13) | 
linux-initramfs-tool
Pre-Depends: debconf | debconf-2.0
Suggests: linux-doc-2.6.26, grub | lilo
Conflicts: initramfs-tools (<< 0.55), yaird (<< 0.0.13)
Filename: pool/main/l/linux-2.6/linux-image-2.6.26-1-amd64_2.6.26-10_amd64.deb
Size: 20890590
MD5sum: 57a7c479b688d8d001af9cfac2ebe0d4
SHA1: 005c0059bfff9dd7e44a939b3fc6c6e5c24409e0
SHA256: bca9497b3eb10a439ed5166fe5115a0acef9633c90ec560819652af1cfe5639a
Description: Linux 2.6.26 image on AMD64
 This package provides the binary image and pre-built loadable modules for
 Linux kernel 2.6.26 on all 64bit single- and multiprocessor AMD and Intel
 machines.
Tag: admin::kernel, implemented-in::c

[EMAIL PROTECTED]:~$ apt-cache show linux-image-2.6.26-1-xen-amd64
Package: linux-image-2.6.26-1-xen-amd64
Priority: optional
Section: admin
Installed-Size: 1836
Maintainer: Debian Kernel Team 
Architecture: amd64
Source: linux-2.6
Version: 2.6.26-10
Provides: linux-image, linux-image-2.6
Depends: linux-modules-2.6.26-1-xen-amd64 (= 2.6.26-10), initramfs-tools (>= 
0.55)
Suggests: linux-doc-2.6.26, grub
Conflicts: initramfs-tools (<< 0.55)
Filename: 
pool/main/l/linux-2.6/linux-image-2.6.26-1-xen-amd64_2.6.26-10_amd64.deb
Size: 1795348
MD5sum: f2d4ac2aca85eb8f0d56022a80e83dba
SHA1: 6b3ef2b3565779f62a5bb16c572748ecbc670f58
SHA256: 1c5744fed9f97c24f6c20c3bd3768071143a1cf361d6f327f60c3a510c1e4d7e
Description: Linux 2.6.26 image on AMD64
 This package provides the binary image for Linux kernel 2.6.26 on all
 64bit single- and multiprocessor AMD and Intel machines.
Tag: admin::kernel, implemented-in::c



How is a novice user expected to guess which one of these to choose?
Could the description of the Xen images please be updated with somewhat
less generic descriptions?


Thanks,
Bjørn


- -- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)

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

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

iEYEARECAAYFAkkhJuMACgkQ10rqkowbIsk/OACfe4NLVMS3o6av3SYAPghi3OEZ
rdEAnje7LwUa5w7O6lAGr8MgnUj4iD7W
=thJ8
-END PGP SIGNATURE-



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#464114: linux-image-2.6.24-1-686: ath5k gets stuck at 1Mbits/s and dhclient can't get an address

[Bjørn Mork]

maximilian attems <[EMAIL PROTECTED]> writes:

> how is 2.6.25 in unstable doing? installs just fine in Testing.

Looks really good!  I've barely tested it so far, but it does look
promising.  Specifically:  The two problems reported in this bug seem to
be gone.  DHCP works.  Auto speed negotiation works.

Thanks for all the good work both to you and to the linux-wireless
developers! 


Bjørn



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#464114: linux-image-2.6.24-1-686: ath5k gets stuck at 1Mbits/s and dhclient can't get an address

[Bjørn Mork]

Package: linux-image-2.6.24-1-686
Version: 2.6.24-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Card has been working for quite a while using madwifi and the same access 
points. Usually at
maximum speed (54Mbits/s).  With ath5k I could barely get it to associate, and 
the rate was
stuck at 1Mbits/s.  In addition, dhclient was unable to get an ipaddress, 
indicating that
packets either could not be sent or received.  Rebooting into 2.6.23-1-686 with 
madwifi
worked as expected, showing that neither card, AP nor DHCP server has any 
problems.

Feb  5 06:57:18 obelix kernel: ACPI: PCI Interrupt :02:02.0[A] -> Link 
[LNKC] -> GSI 11 (level, low) -> IRQ 11
Feb  5 06:57:18 obelix kernel: ath5k_pci :02:02.0: registered as 'phy0'
Feb  5 06:57:18 obelix kernel: phy0: Selected rate control algorithm 'simple'
Feb  5 06:57:18 obelix kernel: ath5k phy0: Atheros AR5213 chip found (MAC: 
0x56, PHY: 0x41)
Feb  5 06:57:18 obelix kernel: ath5k phy0: RF5111 5GHz radio found (0x17)
Feb  5 06:57:18 obelix kernel: ath5k phy0: RF2111 2GHz radio found (0x23)

Feb  5 07:07:26 obelix kernel: ADDRCONF(NETDEV_UP): ath0: link is not ready
Feb  5 07:07:26 obelix dhclient: Internet Software Consortium DHCP Client 2.0pl5
Feb  5 07:07:26 obelix dhclient: Copyright 1995, 1996, 1997, 1998, 1999 The 
Internet Software Consortium.
Feb  5 07:07:26 obelix dhclient: All rights reserved.
Feb  5 07:07:26 obelix dhclient: 
Feb  5 07:07:26 obelix dhclient: Please contribute if you find this software 
useful.
Feb  5 07:07:26 obelix dhclient: For info, please visit 
http://www.isc.org/dhcp-contrib.html
Feb  5 07:07:26 obelix dhclient: 
Feb  5 07:07:26 obelix dhclient: wmaster0: unknown hardware address type 801
Feb  5 07:07:26 obelix dhclient: irda0: unknown hardware address type 783
Feb  5 07:07:26 obelix kernel: ADDRCONF(NETDEV_UP): ath0: link is not ready
Feb  5 07:07:27 obelix dhclient: wmaster0: unknown hardware address type 801
Feb  5 07:07:27 obelix dhclient: irda0: unknown hardware address type 783
Feb  5 07:07:27 obelix dhclient: Listening on LPF/ath0/00:05:4e:4c:77:69
Feb  5 07:07:27 obelix dhclient: Sending on   LPF/ath0/00:05:4e:4c:77:69
Feb  5 07:07:27 obelix dhclient: Sending on   Socket/fallback/fallback-net
Feb  5 07:07:27 obelix dhclient: DHCPREQUEST on ath0 to 255.255.255.255 port 67
Feb  5 07:07:33 obelix dhclient: DHCPREQUEST on ath0 to 255.255.255.255 port 67
Feb  5 07:07:41 obelix dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 
67 interval 4
Feb  5 07:07:45 obelix dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 
67 interval 11
Feb  5 07:07:56 obelix dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 
67 interval 12
Feb  5 07:08:08 obelix dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 
67 interval 8
Feb  5 07:08:16 obelix dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 
67 interval 8
Feb  5 07:08:24 obelix dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 
67 interval 15
Feb  5 07:08:39 obelix dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 
67 interval 3
Feb  5 07:08:50 obelix kernel: ath0: Initial auth_alg=0
Feb  5 07:08:50 obelix kernel: ath0: authenticate with AP 00:11:d8:76:09:1d
Feb  5 07:08:50 obelix kernel: ath0: RX authentication from 00:11:d8:76:09:1d 
(alg=0 transaction=2 status=0)
Feb  5 07:08:50 obelix kernel: ath0: authenticated
Feb  5 07:08:50 obelix kernel: ath0: associate with AP 00:11:d8:76:09:1d
Feb  5 07:08:50 obelix kernel: ath0: RX AssocResp from 00:11:d8:76:09:1d 
(capab=0x401 status=0 aid=5)
Feb  5 07:08:50 obelix kernel: ath0: associated
Feb  5 07:08:50 obelix kernel: ath0: switched to short barker preamble 
(BSSID=00:11:d8:76:09:1d)
Feb  5 07:08:50 obelix kernel: ADDRCONF(NETDEV_CHANGE): ath0: link becomes ready
Feb  5 07:09:02 obelix dhclient: Internet Software Consortium DHCP Client 2.0pl5
Feb  5 07:09:02 obelix dhclient: Copyright 1995, 1996, 1997, 1998, 1999 The 
Internet Software Consortium.
Feb  5 07:09:02 obelix dhclient: All rights reserved.
Feb  5 07:09:02 obelix dhclient: 
Feb  5 07:09:02 obelix dhclient: Please contribute if you find this software 
useful.
Feb  5 07:09:02 obelix dhclient: For info, please visit 
http://www.isc.org/dhcp-contrib.html
Feb  5 07:09:02 obelix dhclient: 
Feb  5 07:09:02 obelix dhclient: wmaster0: unknown hardware address type 801
Feb  5 07:09:02 obelix dhclient: irda0: unknown hardware address type 783
Feb  5 07:09:02 obelix kernel: ADDRCONF(NETDEV_UP): ath0: link is not ready
Feb  5 07:09:02 obelix kernel: ath0: switched to short barker preamble 
(BSSID=00:11:d8:76:09:1d)
Feb  5 07:09:03 obelix dhclient: wmaster0: unknown hardware address type 801
Feb  5 07:09:03 obelix dhclient: irda0: unknown hardware address type 783
Feb  5 07:09:03 obelix dhclient: Listening on LPF/ath0/00:05:4e:4c:77:69
Feb  5 07:09:03 obelix dhclient: Sending on   LPF/ath0/00:05:4e:4c:77:69
Feb  5 07:09:03 obelix dhclient: Sending on   Socket/fallback/fallback-net
Feb  5 07:09:03 obelix dhclient: DHCPREQUEST on ath0 to

Bug#402447: [patch] proper fix for pci_set_power_state()

[Bjørn Mork]

Filippo Giunchedi <[EMAIL PROTECTED]> writes:
> On Thu, May 10, 2007 at 09:48:55PM +0200, Bjjjrn Mork wrote:
>> The feedback from the netdev list is that this should be fixed in the
>> PCI subsystem instead.  Attached is a suggested patch against the
>> current stable kernel source (2.6.18.dfsg.1-12etch1).
>
> Any chance that this patch will be merged upstream? It looks like the issue is
> still present in 2.6.22.

FYI, this patch, which should fix the problem, is included in the stock
2.6.23-rc1 kernel:
http://www.kernel.org/pub/linux/kernel/people/gregkh/pci/2.6/2.6.22/pci-pci_set_power_state-check-for-pm-capabilities-earlier.patch

I assume it will end up in Debian when 2.6.23 is released.



Bjørn

Bug#402447: [patch] proper fix for pci_set_power_state()

[Bjørn Mork]

The feedback from the netdev list is that this should be fixed in the
PCI subsystem instead.  Attached is a suggested patch against the
current stable kernel source (2.6.18.dfsg.1-12etch1).


Bjørn


--- linux-source-2.6.18/drivers/pci/pci.c.orig	2006-09-20 05:42:06.0 +0200
+++ linux-source-2.6.18/drivers/pci/pci.c	2007-05-10 21:46:21.0 +0200
@@ -299,6 +299,13 @@
 	int pm, need_restore = 0;
 	u16 pmcsr, pmc;
 
+	/* find PCI PM capability in list */
+	pm = pci_find_capability(dev, PCI_CAP_ID_PM);
+	
+	/* abort if the device doesn't support PM capabilities */
+	if (!pm)
+		return -EIO; 
+
 	/* bound the state we're entering */
 	if (state > PCI_D3hot)
 		state = PCI_D3hot;
@@ -322,13 +329,6 @@
 	if ((state == PCI_D1 || state == PCI_D2) && pci_no_d1d2(dev))
 		return 0;
 
-	/* find PCI PM capability in list */
-	pm = pci_find_capability(dev, PCI_CAP_ID_PM);
-	
-	/* abort if the device doesn't support PM capabilities */
-	if (!pm)
-		return -EIO; 
-
 	pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc);
 	if ((pmc & PCI_PM_CAP_VER_MASK) > 3) {
 		printk(KERN_DEBUG

Bug#402447: [patch] Disabling pci_set_power_state() in vortex_ioctl() if the device doesn't support PM

[Bjørn Mork]

tags 402447 patch
thanks

I believe the problem really is bad logic in pci_set_power_state(),
making it fail if the device doesn't support PM and a driver 
 1) saves power_state, 
 2) wakes up and does something, and 
 3) then reset to the saved state.

I've reported this upstream along with a patch for pci.c

The attached patch works around the problem in the 3c59x.c driver.


Bjørn

--- linux-source-2.6.18/drivers/net/3c59x.c.orig	2006-09-20 05:42:06.0 +0200
+++ linux-source-2.6.18/drivers/net/3c59x.c	2007-05-05 00:08:01.0 +0200
@@ -2899,7 +2899,7 @@
 	unsigned long flags;
 	int state = 0;
 
-	if(VORTEX_PCI(vp))
+	if(VORTEX_PCI(vp) && pci_find_capability(VORTEX_PCI(vp), PCI_CAP_ID_PM)) 
 		state = VORTEX_PCI(vp)->current_state;
 
 	/* The kernel core really should have pci_get_power_state() */

Bug#403051: linux-image-2.6.18-3-686: lm78 hwmon driver stopped working on upgrade from Sarge

[Bjørn Mork]

Package: linux-image-2.6.18-3-686
Version: 2.6.18-7
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

lm78 hwmon stopped working after upgrading from Sarge (kernel-image-2.6.8-3-686 
version 2.6.8-16sarge6) to Etch (linux-image-2.6.18-3-686 version 2.6.18-7).

The system is an Asus P2L97S, having a LM78-J on ISA port 0x290.  This used to 
show up as the directory /sys/bus/i2c/drivers/lm78/0-0290/. After upgrading,
this directory has disappeared:

canardo:/home/bjorn# lsmod|grep lm78
lm78   15988  0 
i2c_isa 5152  1 lm78
hwmon_vid   2784  1 lm78
i2c_core   19680  6 
lm78,i2c_dev,i2c_algo_bit,i2c_isa,eeprom,i2c_piix4
canardo:/home/bjorn# ls -l /sys/bus/i2c/drivers/lm78/
total 0
- --w--- 1 root root 4096 2006-12-14 12:20 bind
lrwxrwxrwx 1 root root0 2006-12-14 12:20 module -> ../../../../module/lm78
- --w--- 1 root root 4096 2006-12-14 12:20 unbind


sensors-detect still finds the chip:
...
Some chips are also accessible through the ISA I/O ports. We have to
write to arbitrary I/O ports to probe them. This is usually safe though.
Yes, you do have ISA I/O ports even if you do not have any ISA slots!
Do you want to scan the ISA I/O ports? (YES/no): 
Probing for `National Semiconductor LM78' at 0x290...   No
Probing for `National Semiconductor LM78-J' at 0x290... Success!
(confidence 6, driver `lm78')
Probing for `National Semiconductor LM79' at 0x290...   No
...
Driver `lm78' (should be inserted):
  Detects correctly:
  * ISA bus address 0x0290 (Busdriver `i2c-isa')
Chip `National Semiconductor LM78-J' (confidence: 6)
...
 
But sensors can't read anything (as expected since the sysfs entries are 
missing):
canardo:/home/bjorn# sensors
No sensors found!
Make sure you loaded all the kernel drivers you need.
Try sensors-detect to find out which these are.


Let me know if you need more information about the system.



Bjørn

- -- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (700, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages linux-image-2.6.18-3-686 depends on:
ii  coreutils 5.97-5 The GNU core utilities
ii  debconf [debconf-2.0] 1.5.8  Debian configuration management sy
ii  initramfs-tools [linux-initra 0.85c  tools for generating an initramfs
ii  module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo

Versions of packages linux-image-2.6.18-3-686 recommends:
pn  libc6-i686 (no description available)

- -- debconf information:
  linux-image-2.6.18-3-686/postinst/bootloader-error-2.6.18-3-686:
  linux-image-2.6.18-3-686/postinst/old-dir-initrd-link-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/kimage-is-a-directory:
  linux-image-2.6.18-3-686/postinst/old-system-map-link-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/create-kimage-link-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/bootloader-test-error-2.6.18-3-686:
  linux-image-2.6.18-3-686/preinst/abort-overwrite-2.6.18-3-686:
  linux-image-2.6.18-3-686/postinst/old-initrd-link-2.6.18-3-686: true
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.18-3-686/preinst/elilo-initrd-2.6.18-3-686: true
  linux-image-2.6.18-3-686/preinst/lilo-initrd-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/depmod-error-initrd-2.6.18-3-686: false
  linux-image-2.6.18-3-686/preinst/bootloader-initrd-2.6.18-3-686: true
  linux-image-2.6.18-3-686/prerm/removing-running-kernel-2.6.18-3-686: true
  linux-image-2.6.18-3-686/prerm/would-invalidate-boot-loader-2.6.18-3-686: true
  linux-image-2.6.18-3-686/preinst/abort-install-2.6.18-3-686:
  linux-image-2.6.18-3-686/preinst/overwriting-modules-2.6.18-3-686: true
  linux-image-2.6.18-3-686/preinst/initrd-2.6.18-3-686:
  linux-image-2.6.18-3-686/preinst/lilo-has-ramdisk:
  linux-image-2.6.18-3-686/preinst/already-running-this-2.6.18-3-686:
  linux-image-2.6.18-3-686/postinst/depmod-error-2.6.18-3-686: false
  linux-image-2.6.18-3-686/preinst/failed-to-move-modules-2.6.18-3-686:

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

iD8DBQFFgThz10rqkowbIskRAucmAKCS/YiFi5tVyuL/XHnDO8Vu4cEcsACfdtrr
TvPdOWSXIMYTf3kgkedikP8=
=tBXe
-END PGP SIGNATURE-