Panic: EHCI and umass

Bryan Liesner bryan at
Mon Jun 28 10:56:02 PDT 2004

On Mon, 28 Jun 2004, Lukas Ertl wrote:

> On Sat, 26 Jun 2004, Bryan Liesner wrote:
>> Large transfers like dumping a filesystem or a tar of a filesystem causes 
>> the transfer to grind to a halt and eventually panic.  No dump is 
>> available, here is the transcribed DDB output:
>> Fatal trap 12: page fault while in kernel mode
>> fault virtual address   = 0x53425355
>> fault code              = supervisor read, page not present
>> instruction pointer     = 0x8:0xc05147d2
>> stack pointer           = 0x10:0xd4294b6c
>> frame pointer           = 0x10:0xd4294b8c
>> code  segment           = base 0x0 limit 0xffff, type 0x1b
>>                        = DPL0, pres 1, def32 1, gran1
>> processor eflags        = interrupt enabled, resume, IOPL=0
>> current process         = 20 (irq10: pcm0 ehci0)
>> kernel: type 12 trap,code=0
>> Stopped at usb_allocmem+0x82: cmpl %esi, 0(%eax)
> Could you try to get a vmcore and a backtrace from it?
> cheers,
> le

No crashdump available.  I would have loved a crashdump, it would have 
saved me an hour manually transcribing the DDB trace :)

I tried setting the no_sync_on _panic sysctl as well, but I can't coax 
a coredump.  I haven't been able to reliably produce a dump for quite 
some time now.  The system panics and then it's time to hit the reset 

If there is another way for me to help you diagnose this, please let 
me know.  I also saw an earlier email with someone else having a 
similar ECHI-umass issue.  Unlike my Buslink drive which has always 
worked, his drive never worked.  The new patches allowed his drive to 
work, but it locked up in mid-transfer as well.


More information about the freebsd-current mailing list