Bug #1120

Problems with HUAWEI E220 rev 1.10

Added by omniuwo over 5 years ago. Updated about 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

I've come around the earlier problem, with fatal trap, by building a new kernel, without umass support (and other unrelated changes, kernelconf PLATT2 attached), and putting

ugensa_load="YES"

in /boot/loader.conf.
After this the modem shows up as ucom0, but I was not able to connect to it. A friend spent one of his first days on vacation to figure the problem out and found out that you could "reboot" the modem by disretely disconnect the cable from it but leave the ground connected and then, when the message

ucom0: detatched

shows up, reconnect it again. This time it shows up as three devices:

ucom0: <HUAWEI Technologies HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr 2> onuhub0
ucom1: <HUAWEI Technologies HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr 2> onuhub0
ucom2: <HUAWEI Technologies HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr 2> on

and now you can connect to it with, for example, ppp.

I then stumbled over another problem. I wanted to disconnect the modem connection to change to LAN, so I said 'down' to ppp and was at the same time updating /usr/pkgsrc vith cvsup and got a panic (seen at the first boot in attached file dmesg.out2):

putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
putc to a clist with no reserved cblocks
panic: uhci_abort_xfer: not in process context
Trace beginning at fram 0xca605b94
panic(ca605bb8,c04f0e40,c13adf28,c13adf28,ca605bd0) at panic+0x8c
panic(c049f3dc,6,c1305ec0,ca691ec0,c04f0e40) at panic+0x9c
uhci_abort_xfer(ca605bec,c03b5784,c13adf28,c1349f00,1) at uhci_abort_xfer+0xbb
uhci_device_bulk_abort(c13adf28,c1349f00,1,ca605bf8,c05fd2fd) at uhci_device_bulk_abort+0x10
usbd_abort_pipe(c1305ec0,ca605c0c,c05fd8af,0,c146ced0) at usb_abort_pipe+0x36
ucomstopread(0,c146ced0,1,ca605c28,c027679a) at ucomstopread+0x1f
ucomstop(c14ced0,1) at ucomstop+0x37
ttyflush(c14ced0,1) at ttyflush+0x4e
ttyinput(1a,c14ced0,c14ced0,c02777d3,c125f1ae) at ttyinput+0x2c9
ucomreadcb(c13adf28,c1349f00, at ucomreadcb+0x209
usb_transfer_complete(c13adf28,c1305ec0,0,c0260e58,c13adf98) at usb_transfer_complete+0x149
uhci_idone(c948eaf0,c13adfb0,c13adf7c) at uhci_idone+0x120
uhci_softintr(ca691ec0,0) at uhci_softintr+0xcd
usb_schedsoftintr(ca691ec0,c1201b00,c04f0e3c,ff800000,ca605d2c) at usb_schedsoftintr+0xd
uhci_intr1(ca605d84,c02361a7,ca691ec0,0,1f84) at uhci_intr1+0x199
uhci_intr(ca691ec0, 0) at uhci_intr+0x26
ithread_handler(b,0,0,0,0) at ithread_handler+0xa2
lwkt_exit() at lwkt_exit
Debugger("panic")
Stopped at Debugger+0x34: movb $0,in_Debugger.3954
db>

Dillon made a change to uhci.c, but I can still reproduce the panic.

For the curious, this is my ppp.config for 3G:

three:
set device /dev/ucom0
set speed 115200
set phone "*99***1#"
set authname username
set authkey password
disable ipv6cp
enable dns
#set log all -debug -timer -Physical -Async -HDLC
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
\"\" ATZ ATZ \"\" OK \
ATQ0V1E1S0=0&C1&D2+FCLASS=0 ATQ0V1E1S0=0&C1&D2+FCLASS=0 ''\\c OK \
AT+CGDCONT=1,\\\"IP\\\",\\\"data.tre.se\\\" AT+CGDCONT=1,\\\"IP\\\",\\\" data.tre.se\\\" ''\\c OK \
\\dATDT\\T TIMEOUT 20 CONNECT"
set ifaddr 0.0.0.0/0 10.64.64.64/8 255.255.255.255 0.0.0.0
add! default HISADDR

/omniuwo

PLATT2 (8.95 KB) omniuwo, 08/13/2008 02:51 AM

dmesg.out2 (14.6 KB) omniuwo, 08/13/2008 02:51 AM

dmesg.out3 (16.3 KB) omniuwo, 08/13/2008 12:59 PM

History

#1 Updated by hasso over 5 years ago

This kind of silly games with "discrete diconnections" shouln't be
necessary. Umass support should work, but as there is something wrong
with umass part of the device and it's probably not good idea to depend
on umass anyway ... Try this patch:

http://leaf.dragonflybsd.org/~hasso/ugensa-huawei-e220.patch

#2 Updated by omniuwo over 5 years ago

I tried your patch but now it does

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x38
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc019956b
stack pointer = 0x10:0xca614d90
frame pointer = 0x10:0xca614dcc
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = Idle
current thread = pri 44 (CRIT)

panic: from debugger

Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc040034c
stack pointer = 0x10:0xca614b9c
frame pointer = 0x10:0xca614ba4
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, IOPL = 0
current process = Idle
current thread = pri 44 (CRIT)

panic: from debugger

again when I boot with the modem connected, or connect it after boot.

/omniuwo

#3 Updated by hasso over 5 years ago

... etc ...

Yes, it wasn't supposed to solve this particular problem. This patch
solves the problem that you don't have to play silly games with "discrete
diconnections" to switch modems' mode. And AFAICS it does exactly that:

ucom0: <HUAWEI Technologies HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr
2> on uhub0
device_probe_and_attach: ucom0 attach returned 6
ucom0: at uhub0 port 1 (addr 2) disconnected
ucom0: <HUAWEI Technologies HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr
2> on uhub0
ucom1: <HUAWEI Technologies HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr
2> on uhub0

That it pagefaults is probably atausb to blame. Please comment natausb
option out from kernel config and try again.

#4 Updated by dillon over 5 years ago

: panic: uhci_abort_xfer: not in process context
: Trace beginning at fram 0xca605b94
: panic(ca605bb8,c04f0e40,c13adf28,c13adf28,ca605bd0) at panic+0x8c
: panic(c049f3dc,6,c1305ec0,ca691ec0,c04f0e40) at panic+0x9c
: uhci_abort_xfer(ca605bec,c03b5784,c13adf28,c1349f00,1) at uhci_abort_xfer+0xbb
: uhci_device_bulk_abort(c13adf28,c1349f00,1,ca605bf8,c05fd2fd) at uhci_device_bulk_abort+0x10
: usbd_abort_pipe(c1305ec0,ca605c0c,c05fd8af,0,c146ced0) at usb_abort_pipe+0x36
: ucomstopread(0,c146ced0,1,ca605c28,c027679a) at ucomstopread+0x1f
: ucomstop(c14ced0,1) at ucomstop+0x37
: ttyflush(c14ced0,1) at ttyflush+0x4e
: ttyinput(1a,c14ced0,c14ced0,c02777d3,c125f1ae) at ttyinput+0x2c9
: ucomreadcb(c13adf28,c1349f00, at ucomreadcb+0x209
: usb_transfer_complete(c13adf28,c1305ec0,0,c0260e58,c13adf98) at usb_transfer_complete+0x149
: uhci_idone(c948eaf0,c13adfb0,c13adf7c) at uhci_idone+0x120
: uhci_softintr(ca691ec0,0) at uhci_softintr+0xcd
: usb_schedsoftintr(ca691ec0,c1201b00,c04f0e3c,ff800000,ca605d2c) at usb_schedsoftintr+0xd
: uhci_intr1(ca605d84,c02361a7,ca691ec0,0,1f84) at uhci_intr1+0x199
: uhci_intr(ca691ec0, 0) at uhci_intr+0x26

My patch didn't fix this panic unfortunately, because the supposed
uhci_softint() is not actually a software interrupt. It's still being
run directly from the hard interrupt.

-Matt

#5 Updated by dillon over 5 years ago

Please try this patch:

fetch http://apollo.backplane.com/DFlyMisc/usb02.patch

It's another bad hack, but it might work. Basically I removed
the assertion.

-Matt
Matthew Dillon
<>

#6 Updated by omniuwo over 5 years ago

I've been busy so I haven't had time to follow up on this until now.
I'm sorry guys, as you can see in my dmesg output files I've been booting "kernel.uhci" and never my numerous rebuilt kernels. I feel kinda stupid that I never noticed. =)
An interesting thing though is that a friend of mine built the kernel, called it kernel.uhci and rebooted with 'reboot -k kernel.uhci'. The manual says it will only boot once if boot is successfull, but this apparently got stuck in /boot/nextboot.conf and loaded kernel.uhci wether boot was successfull or not. Any ideas or am I missing something?

I know that I was about to comment this as a great idea until I did it and failed (due to the reasons above).

Anyways, now it works jolly fine and only panics when I kldunload the ugensa module (with your patch) while transferring data (I've done some testing).

#7 Updated by omniuwo over 5 years ago

Hmm, no.. it does disconnect now and then and ppp gives me the error message:

Warning: deflink: Unable to set up physical to speed 0

and dmesg says:

ucom0: ucomreadcb: CANCELLED

and sometimes I get alot of:

putc to a clist with no reserved cblocks

Any ideas?

/omniuwo

#8 Updated by corecode about 5 years ago

original bug resolved

Also available in: Atom PDF