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 switch. 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. ThanksReceived on Mon Jun 28 2004 - 15:56:02 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:59 UTC