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

2013-08-27 Thread Bjørn Mork
Christoph Anton Mitterer cales...@scientia.net writes:

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

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

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

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

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


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

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

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

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

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


Bjørn


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



Bug#721088: initramfs-tools: nfsroot with pxelinux fails on systems with multiple NICs

2013-08-27 Thread Martin Mares
Package: initramfs-tools
Version: 0.109.1
Severity: normal

When I try to use Debian initramfs to mount root over NFS on a machine with
multiple NICs, it never succeeds, because the initramfs configures all NICs
with the same IP address.

In more detail, the following happens:

  o  I have configured pxelinux to boot Linux kernel and set ipappend 3,
 so that pxelinux appends ip= and BOOTIF= to kernel options. The
 former contains the IP address and netmask (but no information on the
 interface, which is logical, because it has no idea how will the kernel
 name the interface). The latter contains the MAC address of the boot
 interface.

  o  configure_networking() in scripts/functions inside the initramfs
 correctly detects that BOOTIF was passed and sets the DEVICE variable
 to the name of the right network device.

  o  Later, configure_networking() detects that the ip parameter contains
 something complex (different from trivial things like any, off,
 dhcp, ...) and runs ipconfig on all interfaces.

  o  Therefore, the DEVICE variable calculated from BOOTIF is not used at all.

A simple work-around exists: let pxelinux pass only the BOOTIF parameter
(ipappend 2) and add ip=dhcp manually, in which case configure_networking()
behaves correctly and runs ipconfig only on the matching interface. However,
(1) this is unnecessarily slow (DHCP is run twice, once in PXE and then in
the initramfs), (2) one should not need such tricks to get a working nfsroot.

I propose the following fix: In the complex ip parameter case (around line
393 in my version of the scripts/functions file), the DEVICE variable should
be checked and if it already set, ipconfig should be run only on the selected
device.

Also, the NEW_DEVICE logic below that call to ipconfig is likely wrong for the
same reason. I think it should be moved to the same place where the BOOTIF
check resides.

If you wish, I can provide a patch.


-- Package-specific info:
-- initramfs sizes
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.9.2-kam 
root=UUID=9a1f02a6-70f0-4958-821a-b603696c6d2d ro

-- /proc/filesystems
ext3
ext2
ext4
vfat
msdos
iso9660
romfs
udf

-- lsmod
Module  Size  Used by
usblp   9474  0 
tun15607  2 
deflate 1775  0 
zlib_deflate   17451  1 deflate
ctr 3415  0 
twofish_generic 6017  0 
twofish_x86_64_3way18587  0 
twofish_x86_64  5221  1 twofish_x86_64_3way
twofish_common 12753  3 
twofish_generic,twofish_x86_64_3way,twofish_x86_64
camellia_generic   18041  0 
camellia_x86_6443873  0 
serpent_sse2_x86_6444621  0 
serpent_generic18028  1 serpent_sse2_x86_64
xts 2687  3 
camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way
lrw 3069  3 
camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way
gf128mul5138  2 lrw,xts
glue_helper 3105  3 
camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way
blowfish_generic3032  0 
blowfish_x86_6413244  0 
blowfish_common 6159  2 blowfish_generic,blowfish_x86_64
cast5_generic  10293  0 
cast_common 4849  1 cast5_generic
ablk_helper 1556  1 serpent_sse2_x86_64
cryptd  6479  1 ablk_helper
xcbc2269  0 
rmd160  7160  0 
sha512_generic  4553  0 
sha256_generic  9509  0 
sha1_generic1822  0 
crypto_null 2468  0 
af_key 22195  0 
xfrm_algo   4208  1 af_key
ip6t_REJECT 2428  3 
xt_nat  1777  6 
ipt_REJECT  2009  2 
xt_LOG  9702  5 
xt_limit1678  7 
xt_state1151  3 
xt_multiport1566  2 
xt_DSCP 2003  2 
xt_owner1107  3 
xt_mark 1133  8 
xt_connmark 1653  2 
ip6table_filter 1284  1 
ip6_tables 13824  1 ip6table_filter
iptable_mangle  1424  1 
iptable_nat 2382  1 
nf_conntrack_ipv4   6526  6 
nf_defrag_ipv4  1259  1 nf_conntrack_ipv4
nf_nat_ipv4 2992  1 iptable_nat
nf_nat 11007  3 nf_nat_ipv4,xt_nat,iptable_nat
nf_conntrack   50975  6 
nf_nat,xt_state,nf_nat_ipv4,xt_connmark,iptable_nat,nf_conntrack_ipv4
iptable_filter  1312  1 
ip_tables  13378  3 iptable_filter,iptable_mangle,iptable_nat
x_tables   13511  16 
ip6table_filter,xt_DSCP,xt_mark,ip_tables,xt_limit,xt_owner,xt_state,xt_LOG,xt_nat,xt_multiport,iptable_filter,xt_connmark,ipt_REJECT,iptable_mangle,ip6_tables,ip6t_REJECT
acpi_cpufreq6294  1 
mperf   1107  1 acpi_cpufreq
snd_hda_codec_hdmi 24489  1 
kvm_amd43896  0 
snd_hda_codec_realtek26712  1 
kvm