Re: yep, umass still broken
What motherboards are you using with the OHCI controller? John-Mark Gurney (jmg@) and I kicked this around at bsdcon but couldn't reproduce it. If its a common board or chipset we can probably get it and work on the issue. The zeroed block showed up in 8KB boundaries in the instance we saw, which is asupicious since most OHCI controllers have a DMA limitation of 1 page crossing. I have a ppro with Intel OHCI which I haven't tested yet. On Sat, 27 Sep 2003, Dave Truesdell wrote: -- Your message was: (from Wesley Morgan) On Fri, 26 Sep 2003, Brian Fundakowski Feldman wrote: I can get fdisk to read the MBR, but when I try mdir, I get this trace back (of course, no crash dump because those haven't worked for me in a year): trap 0xc memcpy() ohci_softintr() usb_schedsoftintr() ohci_intr1() ohci_intr() ithread_loop() Anyone have any clued? I'll include my dmesg, of course. It was unbroken for a while, but has been broken for at least a month (seem my earlier post about it). The umass driver has been a constant source of frustation for me and suffers from constant breakage and neglect. -- End of Message You may not want to blame the umass driver. I've been doing a little experimenting trying to get a handle on what's going on. Luckily I have two machines sitting side-by-side, one with OHCI and one with UHCI. Many of the UMASS devices I have fail with 5.1-CURRENT on the OHCI machine but work just fine on the UHCI system. Here's the note I sent as a followup to kern/54982: I am encountering this problem as well. What I've seen so far is this: 1. The corruption does not occur with all UMASS devices. For example, I see data corruption with a Creative Labs MUVO (128M) and NEXDISK (256M) devices, but not with an Easydisc (128M) device. 2. I've only seen the corruption with OHCI based controllers. When I connect the same device to a UHCI based machine, built from an identical copy of the source tree, I see no corruption. 3. The pattern of corruption is decidely non-random. If you view the file as a series of 4K blocks numbered 0 to N, the corruption I've seen follows the following pattern: (B == a zero filled 4k block) Original: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ... Corrupt: 0 3 2 B 4 7 6 B 8 11 10 B 12 15 14 B ... I can provide logs of a file copy done on both the OHCI and UHCI based systems done with hw.usb.debug=3 hw.usb.uhci.debug=6 hw.usb.ohci.debug=6 and hw.usb.umass.debug=4294901760 if you wish. They are far too long to attach here. This test was last run on 5.1-CURRENT cvsup'd on Sep 17th 2003. I'm presently updating both machines to -CURRENT cvsup'd this afternoon. I haven't gotten to the point where I understand the interactions between umass, ohci/uhci and cam well enough to even hazzard a guess about where the corruption is occuring. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: yep, umass still broken
-- Your message was: (from Wesley Morgan) On Fri, 26 Sep 2003, Brian Fundakowski Feldman wrote: I can get fdisk to read the MBR, but when I try mdir, I get this trace back (of course, no crash dump because those haven't worked for me in a year): trap 0xc memcpy() ohci_softintr() usb_schedsoftintr() ohci_intr1() ohci_intr() ithread_loop() Anyone have any clued? I'll include my dmesg, of course. It was unbroken for a while, but has been broken for at least a month (seem my earlier post about it). The umass driver has been a constant source of frustation for me and suffers from constant breakage and neglect. -- End of Message You may not want to blame the umass driver. I've been doing a little experimenting trying to get a handle on what's going on. Luckily I have two machines sitting side-by-side, one with OHCI and one with UHCI. Many of the UMASS devices I have fail with 5.1-CURRENT on the OHCI machine but work just fine on the UHCI system. Here's the note I sent as a followup to kern/54982: I am encountering this problem as well. What I've seen so far is this: 1. The corruption does not occur with all UMASS devices. For example, I see data corruption with a Creative Labs MUVO (128M) and NEXDISK (256M) devices, but not with an Easydisc (128M) device. 2. I've only seen the corruption with OHCI based controllers. When I connect the same device to a UHCI based machine, built from an identical copy of the source tree, I see no corruption. 3. The pattern of corruption is decidely non-random. If you view the file as a series of 4K blocks numbered 0 to N, the corruption I've seen follows the following pattern: (B == a zero filled 4k block) Original: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ... Corrupt: 0 3 2 B 4 7 6 B 8 11 10 B 12 15 14 B ... I can provide logs of a file copy done on both the OHCI and UHCI based systems done with hw.usb.debug=3 hw.usb.uhci.debug=6 hw.usb.ohci.debug=6 and hw.usb.umass.debug=4294901760 if you wish. They are far too long to attach here. This test was last run on 5.1-CURRENT cvsup'd on Sep 17th 2003. I'm presently updating both machines to -CURRENT cvsup'd this afternoon. I haven't gotten to the point where I understand the interactions between umass, ohci/uhci and cam well enough to even hazzard a guess about where the corruption is occuring. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: yep, umass still broken
On Friday 26 September 2003 09:18, Brian Fundakowski Feldman wrote: ohci_intr() ithread_loop() Anyone have any clued? I'll include my dmesg, of course. Yes, the same bad thing with umass on my sony vaio pcg-v505bx laptop. This is the only reason I have to keep slackware linux within to burn cd's and mount usb-drives on this laptop :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: yep, umass still broken
On Fri, 26 Sep 2003, Brian Fundakowski Feldman wrote: I can get fdisk to read the MBR, but when I try mdir, I get this trace back (of course, no crash dump because those haven't worked for me in a year): trap 0xc memcpy() ohci_softintr() usb_schedsoftintr() ohci_intr1() ohci_intr() ithread_loop() Anyone have any clued? I'll include my dmesg, of course. It was unbroken for a while, but has been broken for at least a month (seem my earlier post about it). The umass driver has been a constant source of frustation for me and suffers from constant breakage and neglect. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
yep, umass still broken
I can get fdisk to read the MBR, but when I try mdir, I get this trace back (of course, no crash dump because those haven't worked for me in a year): trap 0xc memcpy() ohci_softintr() usb_schedsoftintr() ohci_intr1() ohci_intr() ithread_loop() Anyone have any clued? I'll include my dmesg, of course. Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #24: Thu Sep 25 22:07:39 EDT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GREEN-SMP Preloaded elf kernel /boot/kernel/kernel at 0xc0556000. Preloaded elf module /boot/kernel/if_dc.ko at 0xc055626c. Preloaded elf module /boot/kernel/miibus.ko at 0xc0556318. Preloaded elf module /boot/kernel/if_xl.ko at 0xc05563c4. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0556470. Preloaded elf module /boot/kernel/snd_cmi.ko at 0xc055651c. Preloaded elf module /boot/kernel/usb.ko at 0xc05565c8. Preloaded elf module /boot/kernel/uhid.ko at 0xc0556670. Preloaded elf module /boot/kernel/ums.ko at 0xc055671c. Preloaded elf module /boot/kernel/umass.ko at 0xc05567c4. Preloaded elf module /boot/kernel/cam.ko at 0xc0556870. Preloaded elf module /boot/kernel/agp.ko at 0xc0556918. Preloaded elf module /boot/kernel/random.ko at 0xc05569c0. Preloaded elf module /boot/kernel/acpi.ko at 0xc0556a6c. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) MP 1800+ (1533.40-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! real memory = 536788992 (511 MB) avail memory = 513359872 (489 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7M266-D on motherboard pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00f24a0 acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 17 - irq 2 IOAPIC #0 intpin 18 - irq 5 IOAPIC #0 intpin 19 - irq 9 agp0: AMD 762 host to AGP bridge port 0xe800-0xe803 mem 0xfb80-0xfb800fff,0xfc00-0xfdff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 IOAPIC #0 intpin 16 - irq 10 pci1: display, VGA at device 5.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: AMD 768 UDMA100 controller port 0xd800-0xd80f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] amdpm0: AMD 756/766/768 Power Management Controller port 0xe4e0-0xe4ff at device 7.3 on pci0 smbus0: System Management Bus on amdpm0 smb0: SMBus generic I/O on smbus0 ohci0: NEC uPD 9210 USB controller mem 0xed80-0xed800fff irq 2 at device 9.0 on pci0 usb0: OHCI version 1.0 usb0: NEC uPD 9210 USB controller on ohci0 usb0: USB revision 1.0 uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: NEC uPD 9210 USB controller mem 0xed00-0xed000fff irq 5 at device 9.1 on pci0 usb1: OHCI version 1.0 usb1: NEC uPD 9210 USB controller on ohci1 usb1: USB revision 1.0 uhub1: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0: NEC uPD 720100 USB 2.0 controller mem 0xec80-0xec8000ff irq 9 at device 9.2 on pci0 ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 usb2: EHCI version 0.95 usb2: companion controllers, 3 ports each: usb0 usb1 usb2: NEC uPD 720100 USB 2.0 controller on ehci0 usb2: USB revision 2.0 uhub2: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 5 ports with 5 removable, self powered pcib2: ACPI PCI-PCI bridge at device 16.0 on pci0 pci2: ACPI PCI bus on pcib2 ohci2: OHCI (generic) USB controller mem 0xec00-0xec000fff irq 9 at device 0.0 on pci2 usb3: OHCI version 1.0, legacy support usb3: SMM does not respond, resetting usb3: OHCI (generic) USB controller on ohci2 usb3: USB revision 1.0 uhub3: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 4 ports with 4 removable, self powered uhub4: Texas Instruments TUSB2046 hub, class 9/0, rev 1.10/1.25, addr 2 uhub4: 4 ports with 4 removable, bus powered ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.00, addr 3, iclass 3/1
