DragonFlyBSD

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

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

... 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.

: 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

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 
                    <dillon@backplane.com>

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).

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

original bug resolved