Bug#848952: linux-image-4.8.0-1-amd64: All USB devices unusable if a USB cable only plugged in to port

2016-12-20 Thread Michael David Wilson
Package: src:linux
Version: 4.8.7-1
Severity: normal
Tags: upstream

Dear Maintainer,

I booted my Debian distribution (working fine at last boot) and the USB
keyboard and mouse did not register with the kernel. No LEDs activated and no
input could be received. I rebooted the machine several times, in all cases,
once the Debian Kernel started the peripherals died.

Kernel was outputting:
usb 3-4: device descriptor read/64, error -110
usb 3-4: new high-speed USB device number 3 using xhci_hcd
usb 3-4: device descriptor read/64, error -110
usb 3-4: device descriptor read/64, error -110
usb 3-4: new high-speed USB device number 4 using xhci_hcd
xhci_hcd :00:14.0: Timeout while waiting for setup device command
xhci_hcd :00:14.0: Timeout while waiting for setup device command
usb 3-4: device not accepting address 4, error -62

I noticed I had a USB2 Type B cable plugged into the computer, but was not
plugged into the printer. Once this was plugged back into the HP printer, and
when I did this, the Kernel recognized the USB keyboard and mouse again (see
logs below). Whilst this is not a critical bug, it would save many users a
headache as other OS have no such issues with failing to enumerate USB devices
when one cable is not plugged in.

usb 3-4: new high-speed USB device number 5 using xhci_hcd
xhci_hcd :00:14.0: Timeout while waiting for setup device command
xhci_hcd :00:14.0: Timeout while waiting for setup device command
usb 3-4: device not accepting address 5, error -62
usb usb3-port4: unable to enumerate USB device
usb 3-5: new full-speed USB device number 6 using xhci_hcd
usb 3-5: New USB device found, idVendor=1532, idProduct=0043
usb 3-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-5: Product: Razer DeathAdder Chroma
usb 3-5: Manufacturer: Razer
usb 3-10: new full-speed USB device number 7 using xhci_hcd
usb 3-10: New USB device found, idVendor=0f39, idProduct=1084
usb 3-10: New USB device strings: Mfr=0, Product=2, SerialNumber=0
usb 3-10: Product: DK2108S
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
input: Razer Razer DeathAdder Chroma as
/devices/pci:00/:00:14.0/usb3/3-5/3-5:1.0/0003:1532:0043.0001/input/input20
hid-generic 0003:1532:0043.0001: input,hidraw0: USB HID v1.11 Mouse [Razer
Razer DeathAdder Chroma] on usb-:00:14.0-5/input0
input: Razer Razer DeathAdder Chroma as
/devices/pci:00/:00:14.0/usb3/3-5/3-5:1.1/0003:1532:0043.0002/input/input21
hid-generic 0003:1532:0043.0002: input,hidraw1: USB HID v1.11 Keyboard [Razer
Razer DeathAdder Chroma] on usb-:00:14.0-5/input1
input: Razer Razer DeathAdder Chroma as
/devices/pci:00/:00:14.0/usb3/3-5/3-5:1.2/0003:1532:0043.0003/input/input22
hid-generic 0003:1532:0043.0003: input,hidraw2: USB HID v1.11 Keyboard [Razer
Razer DeathAdder Chroma] on usb-:00:14.0-5/input2
input: DK2108S as
/devices/pci:00/:00:14.0/usb3/3-10/3-10:1.0/0003:0F39:1084.0004/input/input23
hid-generic 0003:0F39:1084.0004: input,hidraw3: USB HID v1.10 Keyboard
[DK2108S] on usb-:00:14.0-10/input0
input: DK2108S as
/devices/pci:00/:00:14.0/usb3/3-10/3-10:1.1/0003:0F39:1084.0005/input/input24
hid-generic 0003:0F39:1084.0005: input,hidraw4: USB HID v1.10 Device [DK2108S]
on usb-:00:14.0-10/input1
usb 3-3: new high-speed USB device number 8 using xhci_hcd
usb 3-3: New USB device found, idVendor=03f0, idProduct=2b17
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: HP LaserJet 1020
usb 3-3: Manufacturer: Hewlett-Packard
usb 3-3: SerialNumber: JL3Y1R

Thanks in advance,

Michael




-- Package-specific info:
** Version:
Linux version 4.8.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.7-1 (2016-11-13)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.8.0-1-amd64 
root=UUID=37433ec2-a5ad-42a0-b934-111cff1b8ac1 ro quiet

** Tainted: POE (12289)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:

** Model information
[   22.103724] usb 3-4: device descriptor read/64, error -110
[   22.331540] usb 3-4: new high-speed USB device number 3 using xhci_hcd
[   27.479687] usb 3-4: device descriptor read/64, error -110
[   38.609311] [UFW BLOCK] IN=wlp6s0 OUT= 
MAC=01:00:5e:00:00:01:c4:6e:1f:4b:19:df:08:00 SRC=192.168.1.1 DST=224.0.0.1 
LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2 
[   43.095623] usb 3-4: device descriptor read/64, error -110
[   43.323526] usb 3-4: new high-speed USB device number 4 using xhci_hcd
[   48.351571] xhci_hcd :00:14.0: Timeout while waiting for setup device 
command
[   53.727616] xhci_hcd :00:14.0: Timeout while waiting for setup device 
command
[   53.935545] usb 3-4: device not accepting address 4, error -62
[   54.055606] usb 3-4: new high-speed USB device number 5 using xhci_hcd
[   59.103577] xhci_hcd :00:14.0: Timeout while waiting for setup device 
command
[ 

Bug#696642: Bug present in 0.7.8

2013-04-15 Thread Michael David
Greetings,

Just a heads up, this problem has returned in 0.7.8.  The problem is was not 
present in 0.7.6~test nor 0.7.7.

Thanks,
Michael

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



Bug#696642: Oops.

2013-04-15 Thread Michael David
Andrew,

I fired that email off too quickly.  After further examination, I noticed I had 
typo'd bridge_ports as bridge_port. The timing of my change coincided with 
running updates earlier, and the behavior was as it was when I had the issue, 
so I was too quick to report.

 ifupdown is working fine.
 
Sincerest apologies,
Michael

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



Bug#696642: Updates and Workarounds

2013-01-04 Thread Michael David
On Jan 3, 2013, at 4:19 PM, Andrew Shadura wrote:
 I think it is actually a bug; not sure where exactly. Try to debug it
 by changing the shebang of /lib/bridge-utils/ifupdown.sh to #!/bin/sh -x
 and see what happens. It was supposed to bring the interface up, as I
 understand.

Ah, that is useful. On wheezy for br0.4094:

if test -d /sys/class/net/br0 -a ! -d /sys/class/net/br0.4094 ; 
then ip link set up dev br0; ip link add link br0 name br0.4094 
type vlan id 4094; fi
Configuring interface br0.4094=br0.4094 (inet)
run-parts --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
+ [ ! -x /sbin/brctl ]
+ . /lib/bridge-utils/bridge-utils.sh
+ INTERFACES=eth0.4094
+ [ start = start ]
+ [ ! -d /sys/class/net/br0.4094 ]
+ [ start = stop ]

Full-text for wheezy (VERBOSE=y, sh -x in ifupdown.sh): 
http://paste.debian.net/221661/

Full-text for squeeze (sh -x in ifupdown.sh) (=== echo'd start of script):
http://paste.debian.net/221662/

 Probably, I can teach ifupdown to know about bridge-utils existance, so it
 won't configure the link if it sees non-empty bridge_ports parameter.
 How do you think, should it be enough?
 
 If I do that, this part:
 
 if test -d /sys/class/net/br0 -a ! -d /sys/class/net/br0.4094 ; 
 then ip link set up dev br0;   
ip link add link br0 name br0.4094 type vlan id 4094; 
 fi
 
 will be executed if and only if bridge_ports parameter isn't specified.

I think that will do the trick. Doing so will cause brctl addbr to run as 
desired.

 I did notice there are some issues with the down process. For example,
 when br1 goes down, it's also removing VLAN eth0.4094 though
 technically eth0.4094 should be responsible for its own VLAN config.
 
 Don't really understand what exactly it is, let's try to fix (1) and
 (2) and then look into this thing — I assume you can try to get some
 debug logs.

Sounds good to me.

 run-parts: executing /etc/network/if-pre-up.d/bridge
 Set name-type for VLAN subsystem. Should be visible
 in /proc/net/vlan/config ERROR: trying to add VLAN #4094 to IF
 -:eth0:-  error: File exists run-parts:
 
 I guess there may be a bug in bridge-utils.

This happens in squeeze also. Seems to work regardless. I suspect
something lurking there. May cause issues down the road.

Thanks,
Michael

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



Bug#696642: Updates and Workarounds

2013-01-03 Thread Michael David
Preface:


Happy new year to all. :-) Had a chance to revisit this and have an update.

Pardon the length, but I figured being thorough would be more likely to be
of use to you, the maintainer, and anyone else who might stumble onto this
bug report.

Thanks,
Michael


Part 1: 
===
Neither squeeze nor wheezy will bring up a vlan alias dev/iface such
as this if it exists like that and nothing else references it. 

auto eth0.4094
iface eth0.4094 inet manual

HOWEVER, where they differ is that squeeze will bring this interface up if 
another dev/iface refers to it. In my original post this is seen as the 
existance of the br0.4094 dev/iface results in the eth0.4094 device coming up.  

In wheezy, I've changed the interface to appear like this, and the device
comes up, and if given an IP, is actually operating on the intended VLAN.

auto eth0.4094
iface eth0.4094 inet manual
vlan_raw_device eth0
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down

I consider this a bug as the behavior is changed and it silently breaks 
existing configs, however the workaround is simple enough. Ideally the
behavior from squeeze could be brought forward, but perhaps another option
is to warn if a manual iface has no up / down statements? Such warnings
could also be surpressed by a flag in /etc/defaults/networking.


Part 2: 
===
In squeeze, br0.XXX devices are treated as their own entities. It seems like
in wheezy they are treated as aliases of the root device.

With the fix of Part 1 applied on squeeze, after boot, I have the same 5
devices in ifconfig I saw on squeeze, however, br0.4094 never receives
any packets.  TX packets increases, RX packets never does. 

brctl and vlan info look the same as they did in the initial post.

I really appreciate that the new ifupdown has the VERBOSE=yes option now,
and saw this:  (full output below, appendix 1)

run-parts: executing /etc/network/if-up.d/upstart
if test -d /sys/class/net/br0 -a ! -d /sys/class/net/br0.4094 ; 
 then ip link set up dev br0;   
  ip link add link br0 name br0.4094 type vlan id 4094; 
fi

WORKAROUND:
Since the above tests were looking for the base device and creating an alias,
I decided to try a separate br device, br1.  This worked: brctl lists two
bridges, vlan config indicates just a single device doing tagging, and
br1 interface is seeing both RX and TX traffic (assigning an IP on br1 works.)
(Appendix  2 lists the output of the ifupdown process.)

root@wheezy:~# brctl show
bridge name bridge id   STP enabled interfaces
br0 8000.001cc45d53d6   no  eth0
br1 8000.001cc45d53d6   no  eth0.4094
root@wheezy:~# cat /proc/net/vlan/config 
VLAN Dev name| VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth0.4094  | 4094  | eth0
root@wheezy:~# ifconfig br1
br1   Link encap:Ethernet  HWaddr 00:1c:c4:5d:53:d6  
  inet6 addr: fe80::21c:c4ff:fe5d:53d6/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:70 errors:0 dropped:0 overruns:0 frame:0
  TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:4042 (3.9 KiB)  TX bytes:1580 (1.5 KiB)

However, I again feel that the squeeze behavior was appropriate. We've built 
our configs such that generally speaking eth$x corresponds to br$x. So, if 
you want VLAN 100 on the primary NIC, br0.100, secondary NIC, br1.100. 
With this workaround, you'd have to do tricks like VLAN 100 is br10 for first
NIC and br100 for second NIC.


Other Notes:


I did notice there are some issues with the down process. For example,
when br1 goes down, it's also removing VLAN eth0.4094 though technically
eth0.4094 should be responsible for its own VLAN config.





Appendix 1: ifupdown verbose output (using br0.4094)
===

Configuring interface br0=br0 (inet)
run-parts --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ifenslave
run-parts: executing /etc/network/if-pre-up.d/vlan

ip addr add 10.205.16.8/255.255.248.0 broadcast 10.205.23.255 dev br0 label 
br0
ip link set dev br0   up
 ip route add default via 10.205.16.1  dev br0 

run-parts --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/ifenslave
run-parts: executing /etc/network/if-up.d/ip
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/ntpdate
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/upstart

if test -d /sys/class/net/br0 -a ! -d /sys/class/net/br0.4094 ; 
 then ip link set up dev br0;   
  ip link add link br0 name br0.4094 type vlan id 4094; 
fi

Configuring interface br0.4094=br0.4094 (inet)
run-parts --verbose /etc/network/if-pre-up.d
run-parts: executing 

Bug#696642: ifupdown: fails to bring up eth0.xx alias in bridge/vlan setup

2012-12-24 Thread Michael David
Package: ifupdown
Version: 0.7.5
Severity: normal

Dear Maintainer,

I am using Debian as the host OS in a KVM virtualization environment. In 
testing Wheezy, I've discovered the following issue where an ethernet 
alias is not brought up, and then a bridge alias is created rather than 
a new bridge.  Also, the bridge alias is set up for a vlan rather than 
just the intended ethernet alias.

To illustrate, I have set up squeeze and wheezy the same way and included
output. Both machines installed with base+ssh server in tasksel with
thees packages installed afterward:

vlan bridge-utils qemu-kvm qemu-utils libvirt-bin 


## interfaces file. except for IP, exact same on both machines.
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet manual

auto eth0.4094
iface eth0.4094 inet manual
vlan_raw_device eth0

auto br0
iface br0 inet static
address 10.205.16.8   # 8 == wheezy, 9 == squeeze
netmask 255.255.248.0
gateway 10.205.16.1
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0

auto br0.4094
iface br0.4094 inet manual
bridge_ports eth0.4094
bridge_stp off
bridge_fd 0
bridge_maxwait 0


Squeeze: expected outcome; vms added to br0 and br0.4094 work as expected.

root@squeeze:~# ifconfig 
br0   Link encap:Ethernet  HWaddr 00:1a:4b:33:f8:b0  
  inet addr:10.205.16.9  Bcast:10.205.23.255  Mask:255.255.248.0
  inet6 addr: fe80::21a:4bff:fe33:f8b0/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:194 errors:0 dropped:0 overruns:0 frame:0
  TX packets:81 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:16684 (16.2 KiB)  TX bytes:9842 (9.6 KiB)

br0.4094  Link encap:Ethernet  HWaddr 00:1a:4b:33:f8:b0  
  inet6 addr: fe80::21a:4bff:fe33:f8b0/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:29 errors:0 dropped:0 overruns:0 frame:0
  TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:1450 (1.4 KiB)  TX bytes:468 (468.0 B)

eth0  Link encap:Ethernet  HWaddr 00:1a:4b:33:f8:b0  
  inet6 addr: fe80::21a:4bff:fe33:f8b0/64 Scope:Link
  UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
  RX packets:1524 errors:0 dropped:0 overruns:0 frame:0
  TX packets:93 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:203495 (198.7 KiB)  TX bytes:11402 (11.1 KiB)
  Interrupt:16 Memory:f600-f6012800 

eth0.4094 Link encap:Ethernet  HWaddr 00:1a:4b:33:f8:b0  
  inet6 addr: fe80::21a:4bff:fe33:f8b0/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:29 errors:0 dropped:0 overruns:0 frame:0
  TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:1450 (1.4 KiB)  TX bytes:936 (936.0 B)

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:14 errors:0 dropped:0 overruns:0 frame:0
  TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:1078 (1.0 KiB)  TX bytes:1078 (1.0 KiB)

root@squeeze:~# brctl show
bridge name bridge id   STP enabled interfaces
br0 8000.001a4b33f8b0   no  eth0
br0.40948000.001a4b33f8b0   no  eth0.4094
root@squeeze:~# cat /proc/net/vlan/config 
VLAN Dev name| VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth0.4094  | 4094  | eth0
root@squeeze:~# 


Wheezy: unexpected outcome; eth0.4094 isn't up, and also br0.4094
is not actually a bridge (see brctl output) 

root@wheezy:~# ifconfig 
br0   Link encap:Ethernet  HWaddr 00:1c:c4:5d:53:d6  
  inet addr:10.205.16.8  Bcast:10.205.23.255  Mask:255.255.248.0
  inet6 addr: fe80::21c:c4ff:fe5d:53d6/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:375 errors:0 dropped:0 overruns:0 frame:0
  TX packets:80 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:25089 (24.5 KiB)  TX bytes:8678 (8.4 KiB)

br0.4094  Link encap:Ethernet  HWaddr 00:1c:c4:5d:53:d6  
  inet6 addr: fe80::21c:c4ff:fe5d:53d6/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:0 (0.0 B)  TX bytes:578 (578.0 B)

eth0  Link encap:Ethernet  HWaddr 00:1c:c4:5d:53:d6  
  UP BROADCAST 

Bug#152361: Alternitives system

2008-11-18 Thread Michael David Jay
Yes, it would be good to link to alternatives.  awk, mt, nt, are vi can easily 
have an a busybox link called as an alternative -- since busybox changes 
behavior based on how it is called the alternative system works wonderfully... 
(did it manually on my box)  Perhaps busybox could provide, and be listed as an 
alternative for  awk, mt, nt, and vi.?  I suggest a low number for alternatives 
(like maybe 1)

Many of the other packages (DC, for example) have the same binary name as the 
busybox form -- I do not think it would be a good idea to provide these... it 
may make it too easy to break my system... and I cannot see how to put these 
into the alternative system.



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



Bug#328494: Package: installation-reports

2005-09-15 Thread Michael David Watson
Package: installation-reports

Debian-installer-version: rc3 sarge-i386-netinst.iso
uname -a:
Date: 15th September
Method: boot from CD image created from downloaded iso. attempting to do
a network install


Machine: Vanilla workstation
Processor: PIII 450
Memory:128Mb
Root Device: IDE (Intel i810 chipset motherboard)
Root Size/partition table: 10gb 256Mb Swap / 2.8gb root / 7 Gb /usr
Output of lspci and lspci -n:

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot worked:[O]
Configure network HW:   [O]
Config network: [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Create file systems:[O]
Mount partitions:   [O]
Install base system:[E]
Install boot loader:[ ]
Reboot: [ ]

Comments/Problems:

Failed to download the apt package.




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