Bug#987083: iwlmvm: sometimes doesn't initialise on boot, requires a reboot

2021-04-17 Thread Russell Stuart 
Package: src:linux
Version: 5.10.28-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

As of the upgrade 10 linux-image-5.10.0-6-amd64 the Intel AX200 WiFi
(0x8086 0x2723) doesn't work.  Network Manager doesn't find any Wireless
Networks.

rmmod'ing iwlmvm, iwlwifi, cfg80211, mac80211 and then modprob'ing
iwlmvm does not fix the problem.  I have to reboot.  This normally
happens on boot up, but has happened once when I changed to a
different SSID.


- -- Package-specific info:
** Version:
Linux version 5.10.0-6-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.28-1 (2021-04-09)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-6-amd64 
root=UUID=f58461ea-cd6d-434d-abf4-81ff52141b6b ro quiet

** Not tainted

** Kernel log:
[6.362591] NET: Registered protocol family 38
[6.375402] Bluetooth: RFCOMM TTY layer initialized
[6.375406] Bluetooth: RFCOMM socket layer initialized
[6.375409] Bluetooth: RFCOMM ver 1.11
[6.886692] rfkill: input handler disabled
[   10.226501] wlp82s0: authenticate with 9e:92:1f:4c:0b:b8
[   10.234700] wlp82s0: send auth to 9e:92:1f:4c:0b:b8 (try 1/3)
[   10.397715] wlp82s0: authenticated
[   10.401110] wlp82s0: associate with 9e:92:1f:4c:0b:b8 (try 1/3)
[   10.414197] wlp82s0: RX AssocResp from 9e:92:1f:4c:0b:b8 (capab=0x1431 
status=0 aid=1)
[   10.434958] wlp82s0: associated
[   10.566237] IPv6: ADDRCONF(NETDEV_CHANGE): wlp82s0: link becomes ready
[   11.036243] bridge: filtering via arp/ip/ip6tables is no longer available by 
default. Update your scripts to load br_netfilter if you need this.
[   11.301638] kauditd_printk_skb: 24 callbacks suppressed
[   11.301641] audit: type=1400 audit(1618641084.841:35): apparmor="STATUS" 
operation="profile_replace" info="same as current profile, skipping" 
profile="unconfined" name="/usr/bin/lxc-start" pid=1520 comm="apparmor_parser"
[   11.353157] audit: type=1400 audit(1618641084.893:36): apparmor="STATUS" 
operation="profile_replace" info="same as current profile, skipping" 
profile="unconfined" name="lxc-container-default" pid=1524 
comm="apparmor_parser"
[   11.353164] audit: type=1400 audit(1618641084.893:37): apparmor="STATUS" 
operation="profile_replace" info="same as current profile, skipping" 
profile="unconfined" name="lxc-container-default-cgns" pid=1524 
comm="apparmor_parser"
[   11.353168] audit: type=1400 audit(1618641084.893:38): apparmor="STATUS" 
operation="profile_replace" info="same as current profile, skipping" 
profile="unconfined" name="lxc-container-default-with-mounting" pid=1524 
comm="apparmor_parser"
[   11.353171] audit: type=1400 audit(1618641084.893:39): apparmor="STATUS" 
operation="profile_replace" info="same as current profile, skipping" 
profile="unconfined" name="lxc-container-default-with-nesting" pid=1524 
comm="apparmor_parser"
[   18.283646] nouveau :01:00.0: fb: VPR locked, but no scrubber binary!
[   18.613288] rfkill: input handler enabled
[   20.405397] rfkill: input handler disabled
[  514.369698] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[  514.391132] usb 2-2: New USB device found, idVendor=152d, idProduct=0578, 
bcdDevice= 2.09
[  514.391139] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  514.391143] usb 2-2: Product: USB to ATA/ATAPI Bridge
[  514.391146] usb 2-2: Manufacturer: JMicron
[  514.391148] usb 2-2: SerialNumber: 0123456789ABCDEF
[  514.421422] SCSI subsystem initialized
[  514.424884] usbcore: registered new interface driver usb-storage
[  514.428996] scsi host0: uas
[  514.429067] usbcore: registered new interface driver uas
[  514.429478] scsi 0:0:0:0: Direct-Access JMicron  Generic  0209 
PQ: 0 ANSI: 6
[  514.438420] scsi 0:0:0:0: Attached scsi generic sg0 type 0
[  516.823958] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 
GiB)
[  516.823965] sd 0:0:0:0: [sda] 4096-byte physical blocks
[  516.824148] sd 0:0:0:0: [sda] Write Protect is off
[  516.824152] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
[  516.824547] sd 0:0:0:0: [sda] Disabling FUA
[  516.824551] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[  516.824889] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a 
multiple of physical block size (4096 bytes)
[  516.851569]  sda: sda1
[  516.853924] sd 0:0:0:0: [sda] Attached SCSI disk
[  755.948101] usb 2-2: USB disconnect, device number 2
[  755.949812] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  756.187902] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: 
hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 1051.709005] nouveau :01:00.0: fb: VPR locked, but no scrubber binary!
[ 1476.739325] nouveau :01:00.0: fb: VPR locked, but no scrubber binary!
[ 1862.143451] nouveau :01:00.0: fb: VPR locked, but no scrubber binary!
[ 2783.993471] nouveau :01:00.0: fb: VPR locked, but no scrubber

Bug#865984: linux-image-4.9.0-3-amd64: hairpin NAT doesn't work across bridges

2017-06-26 Thread Russell Stuart 
On Mon, 2017-06-26 at 16:57 +0100, Ben Hutchings wrote:
> Control: tag -1 upstream wontfix

I'll file it upstream.  I'm never quite sure whether the maintainer is
supposed to do that or the bug submitter - it seems to vary by package.

Should I link the bug report here?

> You should put the WAN and LAN traffic on separate VLANs and set the
> router's switch port to trunked mode.

If the switch's port had a trunked mode that would be a good idea.  The
5 port switches we put in these "occasionally manned" offices don't
have them.

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

Bug#865984: linux-image-4.9.0-3-amd64: hairpin NAT doesn't work across bridges

2017-06-26 Thread Russell Stuart 
Package: src:linux
Version: 4.9.30-2+deb9u1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Configuration:
  A box running 4.9.0-3-amd64 is acting as a NAT'ing router.  It has
  a single Ethernet NIC and a wireless NIC servicing the local LAN.
  These devices are bridged.  Since it has only one wired NIC it is
  used to connect to both the LAN and internet via a switch.  This
  means it must do hairpin NAT over the wired NIC.

  internet <--> modem<--> switch <--> LAN
[10.99.99.97/30] ^[10.91.91.0/24]
 |^
  +--+   ||
  |  [10.91.91.1/24] eth0=<--/  v antenna LAN |
  |  [10.99.99.98/30] br0<---+   |  | [10.91.91.0/24] |
  | wlan0=<-/ v
  |  |+---=--+
  | ip r a default via 10.99.99.97   || eth-lan0 |
  | iptables -t nat -A POSTROUTING \ || 10.91.91.129/24  |
  |   -s 10.91.91.0/24 -j MASQUERADE ||  |
  +--+| ip r a default \ |
  |  via 10.91.91.1  |
  +--+

  While wlan0 is the reason for bridge exists in my case it doesn't
  have to be a wireless connection.  Connecting any two Ethernet
  devices to the bridge (so it has to do some work) triggers the
  problem.

Problem:
  10.91.91.129 can not receive packets from the internet.  A packet
  arriving from the internet hits eth0, then br0, then is mangled by
  iptables nat, and then is supposed to be sent out br0, eth0 again.
  The mangled version never makes it out of eth0.
  
Possible cause:
  The bridge is implementing it's "never send a packet out over the
  interface it arrived on rule" but it this case it's misapplied the
  rule: the packet that is to be sent is not the same packet that
  arrived earlier on eth0. It has different source and destination IP
  addresses and MAC addresses, and in any case is not being reflected -
  it hit the INPUT chain, not the FORWARD chain.

Workarounds:
  Set the "hairpin" flag on br0.  This works if are to be no loops in
  the LAN wiring (which will normally be hidden by STP).  If there
  are a packet storm will soon ensue, followed in my case by chaos
  and panic.

  An alternate workaround that mostly works is the use ebtables to
  make internet packets bypass the bridge:

ebtables -t broute -A BROUTING -d Multicast -j ACCEPT 
ebtables -t broute -A BROUTING -p IPv4 --ip-dst 10.0.0.0/8 -j ACCEPT 
ebtables -t broute -A BROUTING -p IPv4 --ip-dst 172.16.0.0/12 -j ACCEPT 
ebtables -t broute -A BROUTING -p IPv4 --ip-dst 169.254.0.0/16 -j ACCEPT 
ebtables -t broute -A BROUTING -p IPv4 --ip-dst 192.168.0.0/16 -j ACCEPT 
ebtables -t broute -A BROUTING -p IPv4 --ip-src 10.0.0.0/8 -j ACCEPT 
ebtables -t broute -A BROUTING -p IPv4 --ip-src 172.16.0.0/12 -j ACCEPT 
ebtables -t broute -A BROUTING -p IPv4 --ip-src 169.254.0.0/16 -j ACCEPT 
ebtables -t broute -A BROUTING -p IPv4 --ip-src 192.168.0.0/16 -j ACCEPT 
ebtables -t broute -A BROUTING -p IPv4 -j DROP 
ebtables -t broute -A BROUTING -p IPv6 --ip6-dst fc00::/fc00:: -j ACCEPT 
ebtables -t broute -A BROUTING -p IPv6 --ip6-src fc00::/fc00:: -j ACCEPT 
ebtables -t broute -A BROUTING -p IPv6 -j DROP 

  It only "mostly" works because it fails with OpenVPN.  OpenVPN gets
  TLS errors if the incoming packets don't go via the bridge.

Reproducing:
  Run the attached shell script under Debian on a kernel with the
  problem.  The shell script sets up the configuration shown in the
  diagram above using containers created by systemd-nspawn.

  Invoking it using "hairpin-bug.sh bridge" creates the conditions
  show in the diagram and produces the following output (spurious
  selinux warnings produced by systemd-nspawn have been omitted for
  clarity):

  PING 10.99.99.90 (10.99.99.90) 56(84) bytes of data.

  --- 10.99.99.90 ping statistics ---
  1 packets transmitted, 0 received, 100% packet loss, time 0ms

  The script doesn't need an internet to connection to work as it
  "emulates" it.   10.99.99.90 is the one and only address on this
  emulated internet.

  Invoking it using "hairpin-bug.sh direct" creates the conditions
  show in the diagram, with one exception: the eth0 device is not
  connected to the br0, and IP addresses assigned to br0 have been
  moved to eth0.  The output in that case is:

  PING 10.99.99.90 (10.99.99.90) 56(84) bytes of data.
  64 bytes from 10.99.99.90: icmp_seq=1 ttl=63 time=0.080 ms

  --- 10.99.99.90 ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 0.080/0.080/0.080/0.000 ms

  This invocation method is mostly a unit test for the

Bug#859611: linux-image-4.9.0-0.bpo.2-amd64: ipsec gre tunnel not receiving packets

2017-04-19 Thread Russell Stuart 
On Tue, 2017-04-18 at 21:06 +1000, Russell Stuart wrote:
> I'll try it again with 4.9.18.

4.9.18 behaves identically.

However I loaded it on another machine, and it worked.  In fact it
worked with both 4.9.13 and 4.9.18.  These machines have very different
hardware, and are running running very different networking
configurations - but both are from the same image so only configuration
files are different.  Another way of saying the same thing is all non-
conf files installed by debian are identical.

Unfortunately while the software may be the same and the ipsec
configuration is almost identical (only my endpoint differs) the rest
of the networking configuration is very different. One is a AMD A10,
talking  to the internet over a single NIC using ADSL (pppoe).  The one
that doesn't work is a Dell dual Xeon, with a direct connection to the
internet over two bridged 10G NIC's with 3 different gateways.  I get
about 1 hour to a day to experiment with the machine that doesn't work,
and I don't have a clue where to start looking.

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

Bug#859611: linux-image-4.9.0-0.bpo.2-amd64: ipsec gre tunnel not receiving packets

2017-04-18 Thread Russell Stuart 
Sorry, I missed your reply.

On Fri, 2017-04-07 at 20:40 +0100, Ben Hutchings wrote:
> Does the affected system have a firewall?

Yes, it does.

>   If so, you might need to
> load nf_conntrack_proto_gre explicitly now (explained in
> ).
> Although it isn't obvious why only some of the GRE tunnels would be
> affected.

As it happens I load all nf_conntrack modules at boot so they are
available to containers.  I've just checked, nf_conntrack_proto_gre is
definitely loaded.

I'll try it again with 4.9.18.

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

Bug#859611: linux-image-4.9.0-0.bpo.2-amd64: ipsec gre tunnel not receiving packets

2017-04-05 Thread Russell Stuart 
Package: src:linux
Version: 4.9.13-1~bpo8+1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

We have a IPSec tunnel.  It works under 3.16, and doesn't work under
4.9.13.  Under 4.9.13 racoon reports the isakmp setup is successfull.
Looking at it with tcdump (I've got captures, with xfrm keys) 
under 4.9.13 I see ESP packets going out, but none coming in.

   /etc/racoon/racon.conf:

  remote "optus-lube4g"
  {
exchange_mode   main;
lifetimetime 24 hours;
my_identifier   address 113.52.1.20;
nat_traversal   off;
ph1id   0;
proposal_check  obey;
remote_address  119.225.62.29;
proposal {
  encryption_algorithm  3des;
  hash_algorithmsha1;
  authentication_method pre_shared_key;
  dh_group  1;
  lifetime  time 1 hour;
}
  }

  sainfo address 113.52.1.20 47 address 119.225.62.29 47
  {
authentication_algorithmhmac_sha1, hmac_md5, hmac_sha256, 
non_auth;
compression_algorithm   deflate;
encryption_algorithm3des, des, des_iv64, des_iv32, 
blowfish, null_enc, twofish, rijndael, aes;
lifetimetime 24 hours;
pfs_group   1;
remoteid0;
  }

  sainfo address 119.225.62.29 47 address 113.52.1.20 47
  {
authentication_algorithmhmac_sha1, hmac_md5, hmac_sha256, 
non_auth;
compression_algorithm   deflate;
encryption_algorithm3des, des, des_iv64, des_iv32, 
blowfish, null_enc, twofish, rijndael, aes;
lifetimetime 24 hours;
pfs_group   1;
remoteid0;
  }

  /etc/ipsec-tools.conf:

# ipsec tunnel optus-lube3g.
spdadd -4 203.217.12.211 119.225.62.29 gre -P out ipsec
  esp/tunnel/203.217.12.211-119.225.62.29/require;

spdadd -4 119.225.62.29 203.217.12.211 gre -P in ipsec
  esp/tunnel/119.225.62.29-203.217.12.211/require;

# ipsec tunnel optus-lube4g.
spdadd -4 113.52.1.20 119.225.62.29 gre -P out ipsec
  esp/tunnel/113.52.1.20-119.225.62.29/require;

spdadd -4 119.225.62.29 113.52.1.20 gre -P in ipsec
  esp/tunnel/119.225.62.29-113.52.1.20/require;

  ip tunnel show:

gre0: gre/ip  remote any  local any  ttl inherit  nopmtudisc
optus-lube4g: gre/ip  remote 119.225.62.29  local 113.52.1.20  ttl inherit 
(Plus lots of other un-encrypted GRE tunnels, all of which were
working.)


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

** Model information
sys_vendor: Dell Inc.
product_name: PowerEdge R420
product_version: 
chassis_vendor: Dell Inc.
chassis_version: 
bios_vendor: Dell Inc.
bios_version: 1.2.4
board_vendor: Dell Inc.
board_name: 072XWF
board_version: A01

** Network interface configuration:


auto lo
iface lo inet loopback

allow-hotplug br-eth0
auto br-eth0
iface br-eth0 inet static
pre-up  ip link set up dev eth0 || true
pre-up  ! ip link show | egrep --silent '^[0-9]+: eth0: ' || ip 
addr show dev eth0 | sed -n 's/^ *inet6\? \+\([^ ]*\) .*/\1/p' | while read 
addr; do ([ x"${VERBOSITY}" != x"1" ] || set -x; ip addr del "$addr" dev eth0 
|| :); done
pre-up  ip link set up dev eth1 || true
pre-up  ! ip link show | egrep --silent '^[0-9]+: eth1: ' || ip 
addr show dev eth1 | sed -n 's/^ *inet6\? \+\([^ ]*\) .*/\1/p' | while read 
addr; do ([ x"${VERBOSITY}" != x"1" ] || set -x; ip addr del "$addr" dev eth1 
|| :); done
bridge_portseth0 eth1
bridge_stp  on
bridge_fd   2
bridge_maxwait  2
pre-downip link set nomaster dev eth1 || true
pre-downip link set nomaster dev eth0 || true
post-down   ip link set down dev eth1 || true
post-down   ip link set down dev eth0 || true
address 113.52.1.20/28
post-up ip addr add 113.52.1.21/28 dev br-eth0 || true
post-up ip addr add 10.201.0.2/24 dev br-eth0 || true
post-down   ! ip link show | egrep --silent '^[0-9]+: br-eth0: ' || 
ip addr show dev br-eth0 | sed -n 's/^ *inet6\? \+\([^ ]*\) .*/\1/p' | while 
read addr; do ([ x"${VERBOSITY}" != x"1" ] || set -x; ip addr del "$addr" dev 
br-eth0 || :); done
post-up ip route add default via 113.52.1.17 src 113.52.1.20 
metric 20 || true
post-up ip route add default via 113.52.1.17 src 113.52.1.21 
metric 21 || true
post-up ip route add 58.178.242.194/32 via 113.52.1.17 dev 
br-eth0 src 113.52.1.21 || true
post-up ip route add 211.27.154.166/32 via 113.52.1.17 dev 
br-eth0 src 113.52.1.21 || true
post-up

Bug#842762: firmware-linux-nonfree: Please add video drivers for Intel Kabylake

2016-10-31 Thread Russell Stuart 
Package: firmware-linux-nonfree
Version: 20160824-1
Severity: normal

Without this firmware the i915 driver crashes in about 10 minutes
after an external monitor is plugged in to a
Dell Inc. Inspiron 13-7378, causing both the LCD screen and the
external monitor to go blank.  The work around is to unplug the
HDMI cable and reconnect every 10 minutes or so.

The current firmware can be found here:


https://01.org/sites/default/files/downloads/intelr-graphics-linux/kbldmcver101.tar.bz2

The latest versions are listed on Intels open source site here:

https://01.org/linuxgraphics/downloads/


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

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

Versions of packages firmware-linux-nonfree depends on:
ii  firmware-amd-graphics  20160824-1
ii  firmware-misc-nonfree  20160824-1

Versions of packages firmware-linux-nonfree recommends:
ii  amd64-microcode  3.20160316.2
ii  intel-microcode  3.20160714.1

firmware-linux-nonfree suggests no packages.

-- no debconf information

Bug#594845: Acknowledgement (linux-image-2.6.32-5-amd64: kernel BUG at /build/buildd-linux-2.6_2.6.32-20-amd64-lNUT1p/..../fs/sysfs/file.c:539)

2010-09-07 Thread Russell Stuart 
 You are editing in the wrong place.  The patch needs to be applied in
 debian/build/source_amd64_none.

Ta.  I applied the patch to every copy of tun.c other than the one in
source_amd64_openvz_amd64, and now the my trace is printed as it should
be.  

And with the patch applied properly the problem disappears, so it does
indeed fix the problem.

 The debian/bin/test-patches script can handle this all for you.

Unfortunately the patch doesn't apply to source_amd64_openvz_amd64, and
test-patches dies as soon as that fails.  That is why I was doing it
manually.




-- 
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/1283844141.4098.113.ca...@russell-laptop

Bug#594845: Acknowledgement (linux-image-2.6.32-5-amd64: kernel BUG at /build/buildd-linux-2.6_2.6.32-20-amd64-lNUT1p/..../fs/sysfs/file.c:539)

2010-09-06 Thread Russell Stuart 
On Sun, 2010-09-05 at 01:45 +0100, Ben Hutchings wrote:
 Are you quite sure you used the modified kernel?

Nope. 

 'cat /proc/version' will tell you for sure which version you are
 running.

$ cat /proc/version 
Linux version 2.6.32-5-amd64 (Debian 2.6.32-20.2) (russell-deb...@stuart.id.au) 
(gcc version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Mon Sep 6 09:14:09 EST 2010

So that looks like I am running the right kernel.  But because the
symptoms didn't change overly I had my doubts from the beginning, and
thus have been trying to prove I was running the kernel with your patch
applied.  Doing that in various ways is why it took me a while to
respond to your request to test the patch.

One way I tried to confirm it by adding trace:

--- x/linux-2.6-2.6.32/drivers/net/tun.c2009-12-03 13:51:21.0 
+1000
+++ linux-2.6-2.6.32/drivers/net/tun.c  2010-09-06 08:09:44.068458190 +1000
@@ -36,7 +36,7 @@
 
 #define DRV_NAME   tun
 #define DRV_VERSION1.6
-#define DRV_DESCRIPTIONUniversal TUN/TAP device driver
+#define DRV_DESCRIPTIONUniversal TUN/TAP device driver + 
0001-tun-Don-t-add-sysfs-attributes-to-devices-without-sy.patch applied
 #define DRV_COPYRIGHT  (C) 1999-2004 Max Krasnyansky m...@qualcomm.com
 
 #include linux/module.h
@@ -1006,7 +1006,9 @@
if (err  0)
goto err_free_sk;
 
-   if (device_create_file(tun-dev-dev, dev_attr_tun_flags) ||
+   printk(KERN_INFO 
0001-tun-Don-t-add-sysfs-attributes-to-devices-without-sy.patch\n);
+   if (!net_eq(dev_net(tun-dev), init_net) ||
+   device_create_file(tun-dev-dev, dev_attr_tun_flags) ||
device_create_file(tun-dev-dev, dev_attr_owner) ||
device_create_file(tun-dev-dev, dev_attr_group))
printk(KERN_ERR Failed to create tun sysfs files\n);

None of the trace is ever appears in /var/log/kern.log, which is to say
grep 0001-tun /var/log/kern.log prints nothing. Yet I am evidently
running a different kernel as I don't ever hit the BUG the buildd kernel
generates.  I don't have a clue what is going on.

The steps I used to generate the kernel are:

  $ apt-get source linux-2.6
  $ cd linux-2.6-2.6.32
  $ fakeroot debian/rules source
  $ fakeroot debian/rules setup
  $ patch -p1 
.../0001-tun-Don-t-add-sysfs-attributes-to-devices-without-sy.patch
  $ ed drivers/net/tun.c  # add trace
  $ ed debian/changelog   # add rev 2.6.30-20.2
  $ fakeroot debian/rules binary
  $ sudo dpkg -i ../linux-image-2.6.32-5-amd64_2.6.32-20.2_amd64.deb
  $ sudo ed /boot/grub/grub.cfg   # set the default kernel
  $ sudo reboot -f





-- 
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/1283773622.4264.65.ca...@russell-laptop

Bug#594845: Acknowledgement (linux-image-2.6.32-5-amd64: kernel BUG at /build/buildd-linux-2.6_2.6.32-20-amd64-lNUT1p/..../fs/sysfs/file.c:539)

2010-09-03 Thread Russell Stuart 
On Mon, 2010-08-30 at 14:48 +0100, Ben Hutchings wrote: 
 On Mon, 2010-08-30 at 17:34 +1000, Russell Stuart wrote:
  The problem disappears in
  linux-image-2.6.35-trunk-amd64_2.6.35-1~experimental.2.
 
 Yes, as I expected.
 
 Can you please test the attached patch against the version in unstable?
 Directions for rebuilding an official kernel package are at
 http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official.

Applied that.  It changed the problem.

Before I got a nice repeatable BUG.  Now the openvpn instance
unconditionally segfaults and normally nothing appears on the console or
in kern.log.  Once I got lucky and this appeared on the console:

Message from sysl...@toby at Sep  4 09:11:57 ...
 kernel:[52062.327222] [ cut here ]

Message from sysl...@toby at Sep  4 09:11:57 ...
 kernel:[52062.329577] invalid opcode:  [#1] SMP 

Message from sysl...@toby at Sep  4 09:11:57 ...
 kernel:[52062.330671] last sysfs
file: /sys/devices/virtual/misc/tun/uevent

Message from sysl...@toby at Sep  4 09:11:57 ...
 kernel:[52062.330671] Stack:

Message from sysl...@toby at Sep  4 09:11:57 ...
 kernel:[52062.330671] Call Trace:

Message from sysl...@toby at Sep  4 09:11:57 ...
 kernel:[52062.330671] Code: 74 0f 48 89 ef e8 24 07 00 00 eb 05
bb fe ff ff ff 89 d8 5b 5d 41 5c c3 48 85 ff 74 0e 48 8b 7f 30
48 85 ff 74 05 48 85 f6 75 04 0f 0b eb fe ba 02 00 00 00 e9 5d
ff ff ff 55 53 48 89 fb 48 c7 

The machine appears to freeze in various ways - eg you can't get a login
prompt to have a sniff around and the first command you type at an
existing shell prompt that requires disk IO freezes, and a sleep 300;
sudo reboot -f doesn't do anything.  On the other hand a for f in
$(seq 1000); do echo $f; sleep 1; done continues on as though nothing
has happened.  Disk IO is probably borked.




-- 
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/1283556425.23992.14.ca...@russell-laptop

Bug#594845: Acknowledgement (linux-image-2.6.32-5-amd64: kernel BUG at /build/buildd-linux-2.6_2.6.32-20-amd64-lNUT1p/..../fs/sysfs/file.c:539)

2010-08-30 Thread Russell Stuart 
The problem disappears in
linux-image-2.6.35-trunk-amd64_2.6.35-1~experimental.2.




-- 
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/1283153685.4366.2.ca...@russell-laptop

Bug#536309: linux-image-2.6.30-1-amd64: {/dev, /sys/class/vc}/{vcs, vcsa1} don't exist in 2.6.30

2009-07-08 Thread Russell Stuart 
Package: linux-image-2.6.30-1-amd64
Version: 2.6.30-1
Severity: normal


In 2.6.30 these files no longer appear:

  /dev/vcs1
  /dev/vcsa1
  /sys/class/vc/vcs1
  /sys/class/vc/vcsa1
  
All the other virtual console device files (eg /dev/vcs2) are OK.  If you
manually create /dev/vcsa1 it works as expected.

This is a buck pass from bug #535625.


-- Package-specific info:
** Version:
Linux version 2.6.30-1-amd64 (Debian 2.6.30-1) (wa...@debian.org) (gcc version 
4.3.2 (Debian 4.3.2-1.1) ) #1 SMP Wed Jul 8 13:57:36 EST 2009

** Command line:
root=/dev/sda5 ro quiet resume=/dev/sda6

** Tainted: P (1)

** Kernel log:
[7.560570] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 
1.3.27ks
[7.560572] iwlagn: Copyright(c) 2003-2009 Intel Corporation
[7.560947] iwlagn :0c:00.0: PCI INT A - GSI 17 (level, low) - IRQ 17
[7.560955] iwlagn :0c:00.0: setting latency timer to 64
[7.560991] iwlagn :0c:00.0: Detected Intel Wireless WiFi Link 5300AGN 
REV=0x24
[7.582923] iwlagn :0c:00.0: Tunable channels: 13 802.11bg, 24 802.11a 
channels
[7.582994]   alloc irq_desc for 31 on cpu 0 node 0
[7.582995]   alloc kstat_irqs on cpu 0 node 0
[7.583014] iwlagn :0c:00.0: irq 31 for MSI/MSI-X
[7.585583] dcdbas dcdbas: Dell Systems Management Base Driver (version 
5.6.0-3.2)
[7.732606] HDA Intel :00:1b.0: PCI INT A - GSI 21 (level, low) - IRQ 
21
[7.732644] HDA Intel :00:1b.0: setting latency timer to 64
[7.824734] phy0: Selected rate control algorithm 'iwl-agn-rs'
[7.863920] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/input/input8
[7.960985] input: HDA Intel Mic at Sep Left Jack as 
/devices/pci:00/:00:1b.0/input/input9
[7.961044] input: HDA Intel Mic at Ext Right Jack as 
/devices/pci:00/:00:1b.0/input/input10
[7.961084] input: HDA Intel Line Out at Sep Left Jack as 
/devices/pci:00/:00:1b.0/input/input11
[7.961124] input: HDA Intel HP Out at Ext Right Jack as 
/devices/pci:00/:00:1b.0/input/input12
[8.063421] input: DualPoint Stick as 
/devices/platform/i8042/serio1/input/input13
[8.080553] input: AlpsPS/2 ALPS DualPoint TouchPad as 
/devices/platform/i8042/serio1/input/input14
[   14.025003] Adding 4192924k swap on /dev/sda6.  Priority:-1 extents:1 
across:4192924k 
[   14.529853] EXT3 FS on sda5, internal journal
[   15.072415] loop: module loaded
[   16.576361] fuse init (API version 7.11)
[   18.586483] NET: Registered protocol family 15
[   18.615046] alg: No test for cipher_null (cipher_null-generic)
[   18.615086] alg: No test for ecb(cipher_null) (ecb-cipher_null)
[   18.615188] alg: No test for digest_null (digest_null-generic)
[   18.615255] alg: No test for compress_null (compress_null-generic)
[   19.153917] Intel AES-NI instructions are not detected.
[   21.417473] e1000e :00:19.0: irq 29 for MSI/MSI-X
[   21.473114] e1000e :00:19.0: irq 29 for MSI/MSI-X
[   21.473633] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   23.001236] Clocksource tsc unstable (delta = -146643916 ns)
[   42.848951] lp: driver loaded but no devices found
[   42.901420] ppdev: user-space parallel port driver
[   52.600964] iwlagn :0c:00.0: firmware: requesting iwlwifi-5000-2.ucode
[   52.672630] iwlagn :0c:00.0: iwlwifi-5000-2.ucode firmware file req 
failed: -2
[   52.672777] iwlagn :0c:00.0: firmware: requesting iwlwifi-5000-1.ucode
[   52.723004] iwlagn :0c:00.0: Loaded firmware iwlwifi-5000-1.ucode, which 
is deprecated. Please use API v2 instead.
[   52.723155] iwlagn :0c:00.0: Firmware has old API version. Expected v2, 
got v1. New firmware can be obtained from http://www.intellinuxwireless.org.
[   52.723301] iwlagn :0c:00.0: loaded firmware version 5.4.1.16
[   52.887376] Registered led device: iwl-phy0::radio
[   52.887418] Registered led device: iwl-phy0::assoc
[   52.887462] Registered led device: iwl-phy0::RX
[   52.887498] Registered led device: iwl-phy0::TX
[   52.894993] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   53.253892] warning: `ntpd' uses 32-bit capabilities (legacy support in use)
[   57.523301] Registered led device: iwl-phy0::radio
[   57.523347] Registered led device: iwl-phy0::assoc
[   57.523384] Registered led device: iwl-phy0::RX
[   57.523421] Registered led device: iwl-phy0::TX
[   57.530814] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   57.975243] wlan0: authenticate with AP 00:21:29:d7:b7:15
[   57.975275] wlan0: privacy configuration mismatch and mixed-cell disabled - 
disassociate
[   57.977220] wlan0: authenticated
[   57.977227] wlan0: associate with AP 00:21:29:d7:b7:15
[   57.977233] wlan0: mismatch in privacy configuration and mixed-cell disabled 
- abort association
[   57.978385] wlan0: authenticate with AP 00:21:29:d7:b7:15
[   57.978408] wlan0: privacy configuration mismatch and mixed-cell disabled - 
disassociate
[   57.980343] wlan0: authenticated
[   57.980349] wlan0: associate with AP

Bug#530726: linux-image-2.6.29-2-xen-amd64: linux-image-2.6.29-2 does not build with the xen feature enabled

2009-05-27 Thread Russell Stuart 
Package: linux-image-2.6.29-2-xen-amd64
Version: 2.6.29-5
Severity: serious
Justification: no longer builds from source


I am trying to build linux-image-2.6.29-2-xen-amd64 from the source
package, and admit I don't have a clue how to do this.  (Some doco
in debian/README.txt on how to use the featuresets would be nice).  In
the end I edited debian/config/defines and set enabled to true
for the xen feature.

The debuild without the xen featureset worked. With the xen feature
enabled it died trying to copy vmlimuz to the install directory.
This is because there is no vmliumz under arch/x86/boot.  There
is however a bzImage.  Changing line 418 in debian/rules.real
from:

  cp '$(DIR)'/arch/$(KERNEL_ARCH)/boot/vmlinuz 
$(INSTALL_DIR)/vmlinuz-$(REAL_VERSION)

to:

  cp '$(DIR)'/arch/$(KERNEL_ARCH)/boot/bzImage 
$(INSTALL_DIR)/vmlinuz-$(REAL_VERSION)

seemed to fix the problem. Well it does if:

  ls -l linux-image-2.6.29-2-xen-amd64_2.6.29-5_amd64.deb 
  -rw-r--r-- 1 it it 2159982 2009-05-27 17:22 
linux-image-2.6.29-2-xen-amd64_2.6.29-5_amd64.deb

means it is fixed.  Might introduce other problems though - I
didn't check.



-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages linux-image-2.6.29-2-xen-amd64 depends on:
ii  initramfs-tools   0.92o  tools for generating an initramfs
ii  linux-modules-2.6.29-2-xen-am 2.6.29-5   Linux 2.6.29 modules on AMD64

linux-image-2.6.29-2-xen-amd64 recommends no packages.

Versions of packages linux-image-2.6.29-2-xen-amd64 suggests:
ii  grub   0.97-47lenny2 GRand Unified Bootloader (Legacy v
ii  linux-doc-2.6.29   2.6.29-5  Linux kernel specific documentatio

-- no debconf information


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

linux-kbuild

2009-04-06 Thread Russell Stuart 
Hi.  I have a problem I am sure is not atypical.  My new laptop doesn't
work too well with the lenny 2.6.26 kernel.  This in itself isn't the
problem, nor is it surprising.  I don't actually recall ever getting a
new laptop that was fully supported by Debian stable.

In the past solving it has been a combination of waiting until a kernel
that did support it was packaged by Debian, then recompiling compiling
it myself.  As I use several kernel modules I usually end up having to
either fix the Debian versions so they compile or package the newer
upstream versions.  Tedious, but no big issue - at least no bigger than
I would face if I didn't use Debian.

And so it went with 2.6.28 in experimental.  Except when it came to
compiling the modules.  I ran into linux-kbuild.  A brief look revealed
a version for 2.6.28 it wasn't available in debian/pool.  A longer look
at the 2.6.26 version revealed it didn't come from any upstream package,
but was somehow hand crafted from the kernel source.  At that point I
would have been stuffed, except somehow you guys let some version of
linux-kbuild 2.6.28 escape to the web and I was able to find it with
google.  Comparing the source to 2.6.26, I still am no wiser about how
you put it together.

And so to the my real request: please make the same mistake with 2.6.29.
The linux-2.6 source package is bloody near useless without the matching
linux-kbuild, so if you aren't going to release it at the same time as
you release your first version of 2.6.29, please please let it escape,
preferably with big hints planted around the web so I can find it.

--
Regards,
Russell Stuart


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

Bug#291357: kernel-source-2.4.27: SIGHUP not being sent when controlling process exits

2005-01-20 Thread Russell Stuart 
Package: kernel-source-2.4.27
Version: 2.4.27-6
Severity: important



-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-6-lube-686-smp
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)

Versions of packages kernel-source-2.4.27 depends on:
ii  binutils  2.15-5 The GNU assembler, linker and bina
ii  bzip2 1.0.2-1A high-quality block-sorting file 
ii  coreutils [fileutils] 5.2.1-2The GNU core utilities

-- no debconf information

drivers/char/tty_io.c, line 768, contains this line:

/* tty_deferred_ldisc_switch(N_TTY);

Note: no trailing */.  I am not sure what was intended here,
but the net result is to comment out the code that sends a
SIGHUP to child processed when their leader exits.

This is bad, real bad.  This means that after:

login: me
$ sleep 1000
$ exit

sleep still runs.  The errant patch is in
093_tty_lockup.diff.bz2.



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

Bug#291357: A Better Example

2005-01-20 Thread Russell Stuart 
It appears the example I gave happens on a working
kernel as well.  This one doesn't:

[EMAIL PROTECTED]:~$ ssh 10.7.0.3
Linux titan.brisbane.lube 2.4.27-6-lube-686-smp #1 SMP Thu Jan 13 
16:01:29 EST 2005 i686 GNU/Linux

[EMAIL PROTECTED]:~$ ps -fu $LOGNAME
UIDPID  PPID  C STIME TTY  TIME CMD
rstuart  15870 15868  0 23:33 ?00:00:00 sshd: [EMAIL 
PROTECTED]/0
rstuart  15872 15870  2 23:33 pts/000:00:00 -bash
rstuart  15895 15872  0 23:33 pts/000:00:00 ps -fu rstuart
[EMAIL PROTECTED]:~$ (sleep 2; kill -9 15870)  sleep 12345
[1] 15900
Connection to 10.7.0.3 closed by remote host.
Connection to 10.7.0.3 closed.
[EMAIL PROTECTED]:~$ ssh 10.7.0.3
Linux titan.brisbane.lube 2.4.27-6-lube-686-smp #1 SMP Thu Jan 13 
16:01:29 EST 2005 i686 GNU/Linux

[EMAIL PROTECTED]:~$ ps -fu $LOGNAME
UIDPID  PPID  C STIME TTY  TIME CMD
rstuart  15872 1  0 23:33 ?00:00:00 -bash
rstuart  15901 15872  0 23:33 ?00:00:00 sleep 12345
rstuart  15905 15903  0 23:33 ?00:00:00 sshd: [EMAIL 
PROTECTED]/2
rstuart  15907 15905  2 23:33 pts/200:00:00 -bash
rstuart  15932 15907  0 23:33 pts/200:00:00 ps -fu rstuart
[EMAIL PROTECTED]:~$

Notice the sleep is still running.  On a working kernel is isn't
because it has been sent a SIGHUP.

By the way, it appears the code concerned was copied from 2.6.8,
or a 2.6 kernel a least.  In 2.6.8, the code looks like this:

/* Defer ldisc switch */
/* tty_deferred_ldisc_switch(N_TTY);

  This should get done automatically when the port closes and
  tty_release is called */

read_lock(tasklist_lock);

When copied to 2.4.27, the code ended up like this:

/* Defer ldisc switch */
/* tty_deferred_ldisc_switch(N_TTY);

read_lock(tasklist_lock);

When the trailing */ is restored, the kernel works again.





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