Re: USB crappiness?
On Sat, 19 Jul 2003, Juli Mallett wrote: Hi, I tried to upgrade my workstation to current recently, and I have to use a lot of USB, and while using some USB mass storage device, with a UFS filesystem on it, and doing a large operation to it (tar c|tar x) everything deadlocked on ufs, the USB stack blew up, and upon causing an interrupt to it, it panicked, and panic pagefaulted. Anyone else seeing these sorts of cohesive fallovers? Thanx, juli. Yes, I can confirm that. I do an nightly dump to a file on my USB hard disk (ehci). I woke up to find a screen full of read errors, and at first I thought the disk went belly up. I reverted back and it was working fine. I/O speed has _seriously_ degraded as well. Prior to the bus dma patches, I was getting a little better than 8 MB/s writes to the disk, afterwards, less than 2 MB/s. The performance hit discussed prior to the commit is a bit of an understatement. -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB crappiness?
On Sun, Jul 20, 2003 at 02:06:16AM -0400, Bryan Liesner wrote: On Sat, 19 Jul 2003, Juli Mallett wrote: Hi, I tried to upgrade my workstation to current recently, and I have to use a lot of USB, and while using some USB mass storage device, with a UFS filesystem on it, and doing a large operation to it (tar c|tar x) everything deadlocked on ufs, the USB stack blew up, and upon causing an interrupt to it, it panicked, and panic pagefaulted. Anyone else seeing these sorts of cohesive fallovers? Thanx, juli. Yes, I can confirm that. I do an nightly dump to a file on my USB hard disk (ehci). I woke up to find a screen full of read errors, and at first I thought the disk went belly up. I reverted back and it was working fine. I/O speed has _seriously_ degraded as well. Prior to the bus dma patches, I was getting a little better than 8 MB/s writes to the disk, afterwards, less than 2 MB/s. The performance hit discussed prior to the commit is a bit of an understatement. I've got a backtrace: I was unzipping zipslack.zip onto a 128MB USB key, when one I got a message 'Device not configured' after one file, and subseqent files failed with 'Input/output error'. I cancelled it, and tried to run 'df -h' to see if the disk was full. Then I got the panic: panic: kmem_malloc(4096): kmem_map too small: 218132480 total allocated Debugger(panic) Stopped at Debugger+0x54: xchgl%ebx,in_Debugger.0 db tr Debugger(c038d566,c03fdea0,c0399f78,d8d999ec,100) at Debugger+0x54 panic(c0399f78,1000,d007000,d8d99a1c,14) at panic+0xd5 kmem_malloc(...) at kmem_alloc+0x100 page_alloc(...) at page_alloc+0x27 slab_zalloc(...) at slab_zalloc+0x127 uma_zone_slab(...) at uma_zone_slab+0xe8 uma_zalloc_internal(...) at uma_zalloc_internal+0x7c slab_zalloc(...) at slab_zalloc+0x7f uma_zone_slab(...) at uma_zone_slab+0xe8 uma_zalloc_bucket(...) at uma_zalloc_bucket+0x176 uma_zalloc_arg(...) at uma_zalloc_arg+0x2c7 malloc(adc,c03cf520,102,21b,21b) at malloc+0x5c sigacts_alloc(c03fdcc0,0,0,d8d99c48,c5051980) at sigacts_alloc+0x25 fork1(c4457000,8034,0,d8d99ccc,c4457000) at fork1+0x7d5 vfork(c4457000,d8d99d10,0,16,0) at vfork+0x2b syscall(2f,2f,2f,bfbfda90,0) at syscall+0x2b0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (66, FreeBSD ELF32, vfork), eip = 0x8096ef8, esp = 0xbfbfb850, ebp = 0xbfbfc938 --- db -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB crappiness?
Juli Mallett wrote this message on Sat, Jul 19, 2003 at 19:42 -0500:
I tried to upgrade my workstation to current recently, and I have to
use a lot of USB, and while using some USB mass storage device, with
a UFS filesystem on it, and doing a large operation to it (tar c|tar x)
everything deadlocked on ufs, the USB stack blew up, and upon causing
an interrupt to it, it panicked, and panic pagefaulted.
Anyone else seeing these sorts of cohesive fallovers?
Ok, I think I know the problem now. It's a big different between NetBSD
and FreeBSD's bus_dma code. In NetBSD, they keep the same bus_dma_tag_t,
but in FreeBSD it is encouraged/required to create a new tag for sets of
allocations because of size (we can't do a bus_dmamem_alloc w/ a size).
So, in usb_allocmem, the tag equality doesn't work and allocated a full
page for each 64byte allocation. This quickly causes kmem to get exhusted.
ohci doesn't have this problem since it has it's own allocator for small
sizes.
this patch should fix it temporarily while I investigate a more complete
fix (xterm pasted):
Index: usb_mem.c
===
RCS file: /home/ncvs/src/sys/dev/usb/usb_mem.c,v
retrieving revision 1.1
diff -u -r1.1 usb_mem.c
--- usb_mem.c 2003/07/15 22:42:37 1.1
+++ usb_mem.c 2003/07/21 01:26:38
@@ -256,6 +259,8 @@
return (err);
}
b-fullblock = 0;
+ /* XXX - override the tag */
+ b-tag = tag;
for (i = 0; i USB_MEM_BLOCK; i += USB_MEM_SMALL) {
f = (struct usb_frag_dma *)((char *)b-kaddr + i);
f-block = b;
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
USB crappiness?
Hi, I tried to upgrade my workstation to current recently, and I have to use a lot of USB, and while using some USB mass storage device, with a UFS filesystem on it, and doing a large operation to it (tar c|tar x) everything deadlocked on ufs, the USB stack blew up, and upon causing an interrupt to it, it panicked, and panic pagefaulted. Anyone else seeing these sorts of cohesive fallovers? Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; aim: bsdflata; i have lost my way home early - i don't care cause i won't stay there. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
