Re: 31st address line sometimes not used on EHCI/UHCI/OHCI
On Sunday 27 May 2007 22:54, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : I've got some reports back that some USB host controllers do not support : transferring memory from a location higher than 2GB. : : What should we do about this? : : Should we limit all USB DMA allocations to the lower 2GB of the memory? busdma should be managing this behind the scenes. You shouldn't care, as the problematical usb controllers, if any, can do the bouncing as required. We need to get the hierarchical bus tagging stuff more fully integrated, then we'd get this for free. Yes, I just changed the lowaddr when I allocated the tag, and that did the trick! Of course, you'd have to stop using contigmalloc to allocate all the memory for usb. That won't work on some of the embedded platforms we have, for example, because memory on them isn't as fungible as it is on i386 and amd64. My new USB stack has been using bus_dmamem for quite a while. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/112461: ehci USB 2.0 doesn't work on nforce4
В сообщении от Sunday 13 May 2007 23:35:56 Hans Petter Selasky написал(а): On Tuesday 08 May 2007 08:19, Igor Popov wrote: В сообщении от Monday 07 May 2007 16:12:50 Hans Petter Selasky написал(а): On Monday 07 May 2007 08:09, Igor Popov wrote: Good morning. On Sunday 06 May 2007 13:51, Igor Popov wrote: Number: 112461 Category: usb Synopsis: ehci USB 2.0 doesn't work on nforce4 Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun May 06 12:00:11 GMT 2007 Closed-Date: Last-Modified: Originator: Igor Popov Release:6.0, 6.1, 6.2 Organization: Environment: FreeBSD unix.my.net 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Sat Jan 27 13:01:18 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SUPERKERNEL i386 Description: I have motherboard(Asus A8N-E) that built on nforce4 chipset, it has usb 2.0 ports, but under FreeBSD with usb 2.0 flashdrive max speed near 1.2Mb/s on file copying (my custom kernel has ehci driver), that is usb1.[01] speed. But under both linux an windows with the same flashdrive speed is near 10Mb/s. Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Sat Jan 27 13:01:18 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SUPERKERNEL ACPI APIC Table: Nvidia AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3000+ (1809.28-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20ff2 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MT RR ,P GE ,M CA ,CM OV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow+,3DNow AMD Features2=0x1LAHF real memory = 536805376 (511 MB) avail memory = 507523072 (484 MB) ioapic0 Version 1.1 irqs 0-23 on motherboard wlan: mac acl policy registered ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: Nvidia AWRDACPI on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI 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 pci0: memory at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 nfsmb0: nForce2/3/4 MCP SMBus Controller port 0xe400-0xe41f,0x4c00-0x4c3f,0x4c 40-0x4c7f irq 20 at device 1.1 on pci0 smbus0: System Management Bus on nfsmb0 smb0: SMBus generic I/O on smbus0 nfsmb1: nForce2/3/4 MCP SMBus Controller on nfsmb0 smbus1: System Management Bus on nfsmb1 smb1: SMBus generic I/O on smbus1 ohci0: OHCI (generic) USB controller mem 0xd3104000-0xd3104fff irq 21 at devic e 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 10 ports with 10 removable, self powered ehci0: NVIDIA nForce4 USB 2.0 controller mem 0xfeb0-0xfeb000ff irq 22 at d evice 2.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: NVIDIA nForce4 USB 2.0 controller on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 10 ports with 10 removable, self powered pcm0: nVidia nForce4 port 0xdc00-0xdcff,0xe000-0xe0ff mem 0xd3103000-0xd3103ff f irq 23 at device 4.0 on pci0 pcm0: Avance Logic ALC850 AC97 Codec atapci0: nVidia nForce CK804 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0 x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 atapci1: nVidia nForce CK804 SATA300 controller port 0x9f0-0x9f7,0xbf0-0xbf3,0 x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xd3102000-0xd3102fff irq 21 at device 7.0 on pci0 ata2: ATA channel 0 on
Re: 31st address line sometimes not used on EHCI/UHCI/OHCI
On Sunday 27 May 2007 23:53, John-Mark Gurney wrote: Hans Petter Selasky wrote this message on Sun, May 27, 2007 at 22:35 +0200: I've got some reports back that some USB host controllers do not support transferring memory from a location higher than 2GB. What should we do about this? Should we limit all USB DMA allocations to the lower 2GB of the memory? No, a quirk table should be setup and pass the restriction to bus_dma at tag initalization time when a broken controller is detected.. Yes, I can do that. But I am also thinking about a static quirk, like a sysctl you can set at boot time. I hope that this is not a wide-spread problem. And I am not surprised that hardware manufacturers are not specification compliant, which really makes me wonder if they support a true 64-bit address bus on the EHCI controller at all. I would maybe cost too much money? And therefore we should just stick with 32-bit addressing on 32-bit platforms aswell. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/112461: ehci USB 2.0 doesn't work on nforce4
On Monday 28 May 2007 08:50, Igor Popov wrote: В сообщении от Sunday 13 May 2007 23:35:56 Hans Petter Selasky написал(а): On Tuesday 08 May 2007 08:19, Igor Popov wrote: В сообщении от Monday 07 May 2007 16:12:50 Hans Petter Selasky написал(а): On Monday 07 May 2007 08:09, Igor Popov wrote: Good morning. On Sunday 06 May 2007 13:51, Igor Popov wrote: Hi, I have recompiled kernel with new USB stack, now on files copying speed is about 3.8Mb/s, but it is still slower than linux or windows (~10Mb/s), may be it is by debug options in usb code. Could you supply some more details: How much ram has your system got? What filesystem is on your disks? What version of FreeBSD are you using? What is the dmesg when you boot? Hint: Simply run the dmesg command and pipe the output to a file. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 31st address line sometimes not used on EHCI/UHCI/OHCI
Hans Petter Selasky wrote: On Sunday 27 May 2007 23:53, John-Mark Gurney wrote: Hans Petter Selasky wrote this message on Sun, May 27, 2007 at 22:35 +0200: I've got some reports back that some USB host controllers do not support transferring memory from a location higher than 2GB. What should we do about this? Should we limit all USB DMA allocations to the lower 2GB of the memory? No, a quirk table should be setup and pass the restriction to bus_dma at tag initalization time when a broken controller is detected.. Yes, I can do that. But I am also thinking about a static quirk, like a sysctl you can set at boot time. I hope that this is not a wide-spread problem. What manufacturers are we talking about here? and is there any possibility that it's not the USB chipset, but rather, some feature of an intermediary bus? And I am not surprised that hardware manufacturers are not specification compliant, which really makes me wonder if they support a true 64-bit address bus on the EHCI controller at all. I would maybe cost too much money? And therefore we should just stick with 32-bit addressing on 32-bit platforms aswell. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 31st address line sometimes not used on EHCI/UHCI/OHCI
Hans Petter Selasky wrote this message on Mon, May 28, 2007 at 08:53 +0200: On Sunday 27 May 2007 23:53, John-Mark Gurney wrote: Hans Petter Selasky wrote this message on Sun, May 27, 2007 at 22:35 +0200: I've got some reports back that some USB host controllers do not support transferring memory from a location higher than 2GB. What should we do about this? Should we limit all USB DMA allocations to the lower 2GB of the memory? No, a quirk table should be setup and pass the restriction to bus_dma at tag initalization time when a broken controller is detected.. Yes, I can do that. But I am also thinking about a static quirk, like a sysctl you can set at boot time. The only issue w/ this is that it would also effect add in USB PCI cards that aren't effected by the bug... Which means a sysctl would limit the hardware to the lowest common denominator... I hope that this is not a wide-spread problem. And I am not surprised that hardware manufacturers are not specification compliant, which really makes me wonder if they support a true 64-bit address bus on the EHCI controller at all. I would maybe cost too much money? And therefore we should just stick with 32-bit addressing on 32-bit platforms aswell. Don't forget we have PAE for i386... so restricting to 32bit addressing for i386 would have an impact... As for it being an intermediate bus being the issue, I'd be surprised as that would mean that pci bridge to the USB controller is seriously broken... At least dealing w/ a intermediate bus is easier now that was have bus_get_dma_tag... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 31st address line sometimes not used on EHCI/UHCI/OHCI
John-Mark Gurney wrote: Hans Petter Selasky wrote this message on Mon, May 28, 2007 at 08:53 +0200: On Sunday 27 May 2007 23:53, John-Mark Gurney wrote: Hans Petter Selasky wrote this message on Sun, May 27, 2007 at 22:35 +0200: I've got some reports back that some USB host controllers do not support transferring memory from a location higher than 2GB. What should we do about this? Should we limit all USB DMA allocations to the lower 2GB of the memory? No, a quirk table should be setup and pass the restriction to bus_dma at tag initalization time when a broken controller is detected.. Yes, I can do that. But I am also thinking about a static quirk, like a sysctl you can set at boot time. The only issue w/ this is that it would also effect add in USB PCI cards that aren't effected by the bug... Which means a sysctl would limit the hardware to the lowest common denominator... I hope that this is not a wide-spread problem. And I am not surprised that hardware manufacturers are not specification compliant, which really makes me wonder if they support a true 64-bit address bus on the EHCI controller at all. I would maybe cost too much money? And therefore we should just stick with 32-bit addressing on 32-bit platforms aswell. Don't forget we have PAE for i386... so restricting to 32bit addressing for i386 would have an impact... As for it being an intermediate bus being the issue, I'd be surprised as that would mean that pci bridge to the USB controller is seriously broken... At least dealing w/ a intermediate bus is easier now that was have bus_get_dma_tag... I'd rather it were a screwed up MB than a screwed up chip :-) ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Current problem reports assigned to you
Current FreeBSD problem reports Critical problems S Tracker Resp. Description o usb/84750usb[hang] 6-BETA2 reboot/shutdown with root_fs on externa o usb/91629usbusbd_abort_pipe() may result in infinite loop 2 problems total. Serious problems S Tracker Resp. Description o usb/40792usbsignals lead to data loss on device ugen o usb/46176usb[panic] umass causes kernel panic if device removed be o i386/46371 usbUSB controller cannot be initialized on IBM Netfinity f usb/5usb[ums] system freezes with access to /dev/ums0 o bin/57255usbusbd and multi-function devices o usb/62088usb[usb] Logitech Cordless/Optical Mouse not working o usb/62309usb[ugen] [panic] panic: ugen(4) driver o usb/63621usb[usb] USB MemoryStick Reader stalls/crashes system o usb/69006usb[patch] Apple Cinema Display hangs USB ports o usb/71155usb[usb] misbehaving usb-printer hangs processes, causes o usb/73307usb[panic] Kernel panics on USB disconnect o usb/74771usb[umass] mounting write-protected umass device as read/ o usb/75705usb[panic] da0 attach / Optio S4 (with backtrace) o usb/75797usb5.3-STABLE(2005 1/4) detect USB headset, But can not f f usb/76204usbpanic while using usb attached modem o usb/76395usbUSB printer does not work, usbdevs says addr 0 should o usb/77184usbkernel panic on USB device disconnect o usb/77294usbucom + ulpcom panic o usb/77940usb[quirk] [patch] insertion of usb keyboard panics syste f i386/78218 usb[kue] kue not detected on Sony PCG-F370 VAIO o usb/78989usbplease add USB keyboard support to install CD's o usb/79140usbWD Firewire/USB Combo hangs under load on USB interfac o usb/79269usbUSB ohci da0 plug/unplug causes crashes and lockups. o usb/79287usbUHCI hang after interrupt transfer o usb/79524usbprinting to Minolta PagePro 1[23]xxW via USB fails wit f usb/79656usb[usb] RHSC interrupts lost o usb/79722usb[usb] wrong alignments in ehci.h o usb/80040usb[hang] Use of sound mixer causes system freeze with ua f usb/80260usbTravan USB tape drive fails to write o usb/80361usbmounting of usb-stick fails o usb/80829usbpossible panic when loading USB-modules o usb/80862usb[patch] USB locking issues: missing some Giant calls o usb/81308usb[ugen] [patch] polling a ugen(4) control endpoint caus f usb/82198usbPanic on attaching of ONKI N-338 USB MP3 player f usb/82272usbCan not recognize Casio camera EX-Z40 as a umass devic o usb/82350usb[usb] null pointer dereference in USB stack o usb/82520usbReboot when USL101 connected s usb/82569usb[usb] USB mass storage plug/unplug causes system panic o usb/82660usbEHCI: I/O stuck in state 'physrd'/panic o usb/83504usb[usb] SpeedTouch USB stop working on recent current (a o usb/83563usb[panic] Page Fault while detaching Mpman Usb device o usb/83677usb[usb] usb controller often not detected (Sun W2100z) o usb/83756usbMicrosoft Intellimouse Explorer 4.0A doesn't work. o usb/83977usb[ucom] [panic] ucom1: open bulk out error (addr 2): IN o usb/84326usb[umass] Panic trying to connect SCSI tape drive via US o usb/84336usb[usb] [reboot] instant system reboot when unmounting a o usb/84936usbinstall - usb keyboard not recognized o usb/86031usbneed support usb nic rt2500 in my 5.4 STABLE o usb/86767usb[usb] bogus slice starts beyond end of the disk:... o usb/87099usbpanic: ohci_add_done: addr 0x000d1bf0 not found o usb/88743usb[hang] USB makes kernel hang at boot (regression in 6. o usb/88966usbkldunload ucom.ko returns Device busy error. o usb/89003usbLaCie Firewire drive not properly supported under 6.0 o usb/89954usb[usb] USB Disk driver race condition? f usb/89997usb[umass] [panic] panic on iPod mini detach o usb/90162usb[usb] [patch] Add support for the MS Wireless USB Mous o usb/90700usbKernel panic on connect/mount/use umass device o usb/91238usbUSB tape unit fails to write a second tape file to the o usb/91263usb[patch] USB quirk needed for Logitec USB Hard disk LHD o usb/91283usbbooting very slow with usb devices connection (regress o usb/91538usbUnable to print to EPSON CX3500 o usb/91906usbFreeBSD hangs while booting with USB legacy support on
Re: ucom0: could not set data multiplex mode
On Monday 28 May 2007 11:39, Nikolay Pavlov wrote: Hi folks. I have an issue with CCU-550 CDMA modem (http://www.cmotech.com/eproduct6-1.htm) on recent current. Every time i am reattaching it i see this error: ucom0: could not set data multiplex mode So in order to work with it i have to reboot after each detache procedure. The only known workaround for this is to delete the goto bad; code in /usr/src/sys/dev/usb/umodem.c: printf(%s: could not set data multiplex mode\n, devname); goto bad; Could someone comment on this? P.S. Please cc me, becuase i am not subscribe to freebsd-usb or freebsd-mobile I'm not sure if it will help, but there is a new USB stack that you can try: http://www.turbocat.net/~hselasky/usb4bsd Download the SVN version. I recommend installing on FreeBSD 6-stable, hence there is a small bug in the memory allocation code on FreeBSD 7-current, that will cause regular panics. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
UMASS pbm at startup
Hi, I have a pbm with my usb disk-key under freebsd. When i start the system (FreeBSD 5.2) with the key already plugged, it is not recognised. If I unplug and replug it, it is recognised. With an other motherboard, I do not have this problem. Is there a way to rescan for usb devices? I already tried camcontrol rescan all with no success. Thanks Cheers Alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UMASS pbm at startup
In message: [EMAIL PROTECTED] Aymeric MUNTZ \(Cerbere3\) [EMAIL PROTECTED] writes: : Is there a way to rescan for usb devices? I already tried camcontrol rescan : all with no success. Not presently in current, let alone 5.2. Maybe 6.2 would work better. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
RE : UMASS pbm at startup
I can not try this FBSD release. It is a server in production and I can not reinstall it. I have to find the solution with the 5.2 FreeBSD version. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Hans Petter Selasky Envoyé : lundi 28 mai 2007 19:13 À : freebsd-usb@freebsd.org Objet : Re: UMASS pbm at startup On Monday 28 May 2007 18:52, Aymeric MUNTZ (Cerbere3) wrote: Hi, I have a pbm with my usb disk-key under freebsd. When i start the system (FreeBSD 5.2) with the key already plugged, it is not recognised. If I unplug and replug it, it is recognised. With an other motherboard, I do not have this problem. Is there a way to rescan for usb devices? I already tried camcontrol rescan all with no success. Have you tried the SVN version of the new USB stack with FreeBSD 6.2 installed? --HPS PS: The new USB stack does not support FreeBSD 5.2 any more. http://www.turbocat.net/~hselasky/usb4bsd ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
RE : UMASS pbm at startup
But why does it work with an other motherboard and not with an other one? It is the same usb mass storage and the same system. Is it possible that it is due to IRQ interruptions? Maybe that the first motherboard doesn't have IRQ on USB port!? Alex -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de M. Warner Losh Envoyé : lundi 28 mai 2007 20:02 À : [EMAIL PROTECTED] Cc : freebsd-usb@FreeBSD.ORG Objet : Re: UMASS pbm at startup In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : On Monday 28 May 2007 18:52, Aymeric MUNTZ (Cerbere3) wrote: : Hi, : : I have a pbm with my usb disk-key under freebsd. : When i start the system (FreeBSD 5.2) with the key already plugged, it is : not recognised. If I unplug and replug it, it is recognised. : With an other motherboard, I do not have this problem. : : Is there a way to rescan for usb devices? I already tried camcontrol : rescan all with no success. : : : Have you tried the SVN version of the new USB stack with FreeBSD 6.2 : installed? Let's just change one thing at a time... Try going to 6.2 first. changing both the usb stack and the freebsd version at one time might not be wise. We also need to track down problems in the current USB stack, since we are never going to put hps' stack into RELENG_6. Since it hasn't yet been committed to current and there's a freeze coming up shortly, it is doubtful that it will be in RELENG_7 either. We need to not view hps' stack as this magical thing that solves all problems because we have at least RELENG_6 to support for a while, and may have to support the current stack in RELENG_7 too. To be honest, I really wish Hans would be more pro-active in merging changes to the old stack so that the delta between it and his would be more manageable. I've said this plenty of times privately, but no fixes to the old stack have been forthcoming, not even new vendor IDs for existing drivers... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RE : UMASS pbm at startup
Alexandre DELAY wrote: But why does it work with an other motherboard and not with an other one? It is the same usb mass storage and the same system. Is it possible that it is due to IRQ interruptions? Maybe that the first motherboard doesn't have IRQ on USB port!? try a different USB port.. some motherboards do wierd things with some ports. Alex -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de M. Warner Losh Envoyé : lundi 28 mai 2007 20:02 À : [EMAIL PROTECTED] Cc : freebsd-usb@FreeBSD.ORG Objet : Re: UMASS pbm at startup In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : On Monday 28 May 2007 18:52, Aymeric MUNTZ (Cerbere3) wrote: : Hi, : : I have a pbm with my usb disk-key under freebsd. : When i start the system (FreeBSD 5.2) with the key already plugged, it is : not recognised. If I unplug and replug it, it is recognised. : With an other motherboard, I do not have this problem. : : Is there a way to rescan for usb devices? I already tried camcontrol : rescan all with no success. : : : Have you tried the SVN version of the new USB stack with FreeBSD 6.2 : installed? Let's just change one thing at a time... Try going to 6.2 first. changing both the usb stack and the freebsd version at one time might not be wise. We also need to track down problems in the current USB stack, since we are never going to put hps' stack into RELENG_6. Since it hasn't yet been committed to current and there's a freeze coming up shortly, it is doubtful that it will be in RELENG_7 either. We need to not view hps' stack as this magical thing that solves all problems because we have at least RELENG_6 to support for a while, and may have to support the current stack in RELENG_7 too. To be honest, I really wish Hans would be more pro-active in merging changes to the old stack so that the delta between it and his would be more manageable. I've said this plenty of times privately, but no fixes to the old stack have been forthcoming, not even new vendor IDs for existing drivers... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
ETA on HPS USB stack into CURRENT?
What requirements still need to be met before the HPS USB stack is committed to CURRENT? I understand that introducing a major sub-system change so close the start of a release cycle can be very disruptive. My main concern is that the RELENG_7 branch will be arriving in the next couple months and imp@ mentioned in the (Re: UMASS pbm at startup) thread that RELENG_7 might not see the new stack. This means that we'll have to wait until an 8.x release (2009?) until we see the new stack in a stock install. Also the current stack will then need to be supported during the entire life of RELENG_7 which will probably into at least late 2010. From here on out the limitations of the current USB stack not being MPSAFE will only become more apparent with more systems shipping with multiple processors. Such as not allow CPUs to drop to C3 when USB is loaded, performance issues, and various HID parsing problems. With all that said what would be needed so that we could see the new stack in 7.1 eventhough 7.0 would have the old stack? Though this does seem to be asking for a lot of trouble since it would be a STABLE branch. -- Anish Mistry [EMAIL PROTECTED] AM Productions http://am-productions.biz/ pgpShyowbYv64.pgp Description: PGP signature
Re: ETA on HPS USB stack into CURRENT?
In message: [EMAIL PROTECTED] Anish Mistry [EMAIL PROTECTED] writes: : What requirements still need to be met before the HPS USB stack is : committed to CURRENT? It will go into the into the tree when it is ready. The FreeBSD project has a policy that all significant code must be reviewed before it goes into the tree, and that the concerns that have been raised in the review be addressed. This process is ongoing with the hps usb stack, and when it is complete, it will go into current. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RE : UMASS pbm at startup
In message: [EMAIL PROTECTED] Alexandre DELAY [EMAIL PROTECTED] writes: : But why does it work with an other motherboard and not with an other one? It : is the same usb mass storage and the same system. Is it possible that it is : due to IRQ interruptions? Maybe that the first motherboard doesn't have IRQ : on USB port!? The no IRQ is a big hint. Often times, usb is disabled by the BIOS by not assigning an interrupt to the controller. You might want to check to see if usb isn't disabled. Also, different motherboards have different chipsets, supported by different drivers. Warner : -Message d'origine- : De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De : la part de M. Warner Losh : Envoyé : lundi 28 mai 2007 20:02 : À : [EMAIL PROTECTED] : Cc : freebsd-usb@FreeBSD.ORG : Objet : Re: UMASS pbm at startup : : : In message: [EMAIL PROTECTED] : Hans Petter Selasky [EMAIL PROTECTED] writes: : : On Monday 28 May 2007 18:52, Aymeric MUNTZ (Cerbere3) wrote: : : Hi, : : : : I have a pbm with my usb disk-key under freebsd. : : When i start the system (FreeBSD 5.2) with the key already plugged, it : is : : not recognised. If I unplug and replug it, it is recognised. : : With an other motherboard, I do not have this problem. : : : : Is there a way to rescan for usb devices? I already tried camcontrol : : rescan all with no success. : : : : : : Have you tried the SVN version of the new USB stack with FreeBSD 6.2 : : installed? : : Let's just change one thing at a time... Try going to 6.2 first. changing : both the usb stack and the freebsd version at one time might not be wise. : We also need to track down problems in the current USB stack, since we are : never going to put hps' stack into RELENG_6. Since it hasn't yet been : committed to current and there's a freeze coming up shortly, it is doubtful : that it will be in RELENG_7 either. We need to not view hps' stack as this : magical thing that solves all problems because we have at least RELENG_6 to : support for a while, and may have to support the current stack in RELENG_7 : too. : : To be honest, I really wish Hans would be more pro-active in merging changes : to the old stack so that the delta between it and his would be more : manageable. I've said this plenty of times privately, but no fixes to the : old stack have been forthcoming, not even new vendor IDs for existing : drivers... : : Warner : : ___ : freebsd-usb@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-usb : To unsubscribe, send any mail to [EMAIL PROTECTED] : : : ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RE : UMASS pbm at startup
In message: [EMAIL PROTECTED] Julian Elischer [EMAIL PROTECTED] writes: : Alexandre DELAY wrote: : But why does it work with an other motherboard and not with an other one? It : is the same usb mass storage and the same system. Is it possible that it is : due to IRQ interruptions? Maybe that the first motherboard doesn't have IRQ : on USB port!? : : : try a different USB port.. some motherboards do wierd things with some ports. That also suggests another workaround: Adding a 2.0 hub can paper over some problems too. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ETA on HPS USB stack into CURRENT?
Anish Mistry wrote: What requirements still need to be met before the HPS USB stack is committed to CURRENT? I understand that introducing a major sub-system change so close the start of a release cycle can be very disruptive. My main concern is that the RELENG_7 branch will be arriving in the next couple months and imp@ mentioned in the (Re: UMASS pbm at startup) thread that RELENG_7 might not see the new stack. This means that we'll have to wait until an 8.x release (2009?) until we see the new stack in a stock install. Also the current stack will then need to be supported during the entire life of RELENG_7 which will probably into at least late 2010. From here on out the limitations of the current USB stack not being MPSAFE will only become more apparent with more systems shipping with multiple processors. Such as not allow CPUs to drop to C3 when USB is loaded, performance issues, and various HID parsing problems. With all that said what would be needed so that we could see the new stack in 7.1 eventhough 7.0 would have the old stack? Though this does seem to be asking for a lot of trouble since it would be a STABLE branch. This is a question we've been discussing a lot. Your public question probably deserves a public answer. There are some requirements that all subsystems require. HPS's USB code is no different from others. I will borrow from a talk at BSDCan that talked about project dynamics.. 1/ Bus factor of the project must not increase. i.e. number of developers that may be hit by a bus before the project is really screwed. (bigger is better) Currently the bus factor of the existing USB code is about 5 (busy) people Bus factor of new code is 1 2/ The nuclear powerplant problem. The direct opposite from a bikeshed. Everyone understands a bikeshed and they can all comment on it. Very few people understand a nuclear powerplant so sometimes they can get installed with almost no review and comment. When they go wrong however they go wrong in a big way and influence a lot. They tend to decrease the bus factor of a project. (not good). What this means: A large module needs comprehensive review by other developers. The module needs to be split up into chunks that can be reviewed by humans. Ether by implementing it as a sequence of patches to get from Here to there in understandable steps, or by heavily documenting it. Preferably with lots of diagrams etc. (see the papers in the docs section for some of the examples of what people have done in the past) The code needs to reviewed, which means that it needs to be well laid out and commented. I beieve HPS is currently going through his code commenting it. It's curently under commented. He has also been asked to provide some sort of design document to assist the reviewers. To some extent this means that HPS must be willing to let the control of his code slip from his hads somewhat. None of this of course means that it will get in if the reviewers don't like what they see, but if they do it comes in when all issues are addressed. Unless a really superior competitor exists, which seems doubtful at this time. The biggest competitor th HPS's USB code is fix the old USB code. he needs to demonstrate that his co de is superior to this option. BTW after first cut reviews (done with great pain on the undocumented code), current issues of concern (also somewhat present in the existing code) include Locking issues and interaction with the newbus/device framework. When the commented and documented version of the code become available then it wil be reviewed more thoroughly and more issues will be raised undoubtedly. Currently the lack of documentation has hindered review. Implementation details: New code modules such as this should be installed with a transition period. In other words, for a short while both new and old code should exist side-by-side in some way. This allows people who need teh functionality and cannot spare the time to debug the new code, to keep working while others can work on the new code. This has happenned severaltimes in the past, with #ifdefs etc. being used to compile a kernle with new or old versions of various modules (e.g. pcmcia code vs pccard/newcard, or fastforward vs. regular forwarding) HPS is hoping to be able to present his code to developers attending EuroBSDcon in some way, and has agreed to assist us in reviewing it by adding comments and other documentation. (in some cases adding back commenting that already existed but he removed from his versions of the files). Until now all the work on HPS's code has been on the technical side, and none of it has been on the project integration side of things. This often tends to be overlooked but if Hans-Peter can get that side of his act together He has a chance that it could be accepted well. (assuming that reviewing results in a well integrated result.) Anyhow this is the basic thrust of a long discussion that I and
Re: UMASS pbm at startup
On Monday 28 May 2007 20:01, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : On Monday 28 May 2007 18:52, Aymeric MUNTZ (Cerbere3) wrote: : Hi, : : I have a pbm with my usb disk-key under freebsd. : When i start the system (FreeBSD 5.2) with the key already plugged, it : is not recognised. If I unplug and replug it, it is recognised. : With an other motherboard, I do not have this problem. : : Is there a way to rescan for usb devices? I already tried camcontrol : rescan all with no success. : : Have you tried the SVN version of the new USB stack with FreeBSD 6.2 : installed? Let's just change one thing at a time... Try going to 6.2 first. changing both the usb stack and the freebsd version at one time might not be wise. We also need to track down problems in the current USB stack, since we are never going to put hps' stack into RELENG_6. Since it hasn't yet been committed to current and there's a freeze coming up shortly, it is doubtful that it will be in RELENG_7 either. We need to not view hps' stack as this magical thing that solves all problems because we have at least RELENG_6 to support for a while, and may have to support the current stack in RELENG_7 too. To be honest, I really wish Hans would be more pro-active in merging changes to the old stack so that the delta between it and his would be more manageable. I've said this plenty of times privately, but no fixes to the old stack have been forthcoming, not even new vendor IDs for existing drivers... My schedule is full. I'm tracking all changes going into HEAD at least. There are some deltas that could have been backported, but I do not specifically keep track of all the small things I fix. I would need a secretary for that :-) Any volunteers ;-) With regard to the topic of this thread I know about some specific issues that leaves the result that attached devices are not detected. This is related to missed PCD interrupts. You have to fake a PCD interrupt every time you enable the PCD again, to catch any missed PCD interrupts. The problem is the same with OHCI, but there this interrupt is called something else. The PCD interrupt is connected to the root interrupt endpoint on the root HUB, which is a virtual device. I think that this is the problem. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ETA on HPS USB stack into CURRENT?
On Monday 28 May 2007, Julian Elischer wrote: Anish Mistry wrote: What requirements still need to be met before the HPS USB stack is committed to CURRENT? I understand that introducing a major sub-system change so close the start of a release cycle can be very disruptive. My main concern is that the RELENG_7 branch will be arriving in the next couple months and imp@ mentioned in the (Re: UMASS pbm at startup) thread that RELENG_7 might not see the new stack. This means that we'll have to wait until an 8.x release (2009?) until we see the new stack in a stock install. Also the current stack will then need to be supported during the entire life of RELENG_7 which will probably into at least late 2010. From here on out the limitations of the current USB stack not being MPSAFE will only become more apparent with more systems shipping with multiple processors. Such as not allow CPUs to drop to C3 when USB is loaded, performance issues, and various HID parsing problems. With all that said what would be needed so that we could see the new stack in 7.1 eventhough 7.0 would have the old stack? Though this does seem to be asking for a lot of trouble since it would be a STABLE branch. This is a question we've been discussing a lot. Your public question probably deserves a public answer. There are some requirements that all subsystems require. HPS's USB code is no different from others. I will borrow from a talk at BSDCan that talked about project dynamics.. 1/ Bus factor of the project must not increase. i.e. number of developers that may be hit by a bus before the project is really screwed. (bigger is better) Currently the bus factor of the existing USB code is about 5 (busy) people Bus factor of new code is 1 2/ The nuclear powerplant problem. The direct opposite from a bikeshed. Everyone understands a bikeshed and they can all comment on it. Very few people understand a nuclear powerplant so sometimes they can get installed with almost no review and comment. When they go wrong however they go wrong in a big way and influence a lot. They tend to decrease the bus factor of a project. (not good). What this means: A large module needs comprehensive review by other developers. The module needs to be split up into chunks that can be reviewed by humans. Ether by implementing it as a sequence of patches to get from Here to there in understandable steps, or by heavily documenting it. Preferably with lots of diagrams etc. (see the papers in the docs section for some of the examples of what people have done in the past) The code needs to reviewed, which means that it needs to be well laid out and commented. I beieve HPS is currently going through his code commenting it. It's curently under commented. He has also been asked to provide some sort of design document to assist the reviewers. To some extent this means that HPS must be willing to let the control of his code slip from his hads somewhat. None of this of course means that it will get in if the reviewers don't like what they see, but if they do it comes in when all issues are addressed. Unless a really superior competitor exists, which seems doubtful at this time. The biggest competitor th HPS's USB code is fix the old USB code. he needs to demonstrate that his co de is superior to this option. BTW after first cut reviews (done with great pain on the undocumented code), current issues of concern (also somewhat present in the existing code) include Locking issues and interaction with the newbus/device framework. When the commented and documented version of the code become available then it wil be reviewed more thoroughly and more issues will be raised undoubtedly. Currently the lack of documentation has hindered review. Implementation details: New code modules such as this should be installed with a transition period. In other words, for a short while both new and old code should exist side-by-side in some way. This allows people who need teh functionality and cannot spare the time to debug the new code, to keep working while others can work on the new code. This has happenned severaltimes in the past, with #ifdefs etc. being used to compile a kernle with new or old versions of various modules (e.g. pcmcia code vs pccard/newcard, or fastforward vs. regular forwarding) HPS is hoping to be able to present his code to developers attending EuroBSDcon in some way, and has agreed to assist us in reviewing it by adding comments and other documentation. (in some cases adding back commenting that already existed but he removed from his versions of the files). Until now all the work on HPS's code has been on the technical side, and none of it has been on the project integration side of things. This often tends to be overlooked but if Hans-Peter can get that side of his act together He has a chance that it could be accepted well. (assuming that
