Re: 8.x grudges
In message: aanlktikdj39liaffibdwkfa1vgt4w7m8toxevjykh...@mail.gmail.com
Garrett Cooper yanef...@gmail.com writes:
: On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
: 07.07.2010 14:59, Jeremy Chadwick ???(??):
:
: FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and
: thus not an option) -- the kernel-config files, that worked with
: 7.x, break without this option in them (in addition to all the
: nuisance, that's documented in UPDATING -- which, somehow, makes
: the breakage acceptable). config(8) would not warn about this, but
: kernel build fails.
:
:
: We don't use this option (meaning it's removed from our kernels). It's
: definitely not required. All it does is ensure your kernel can
: comprehend executables/binaries built on 7.x.
:
:
: Attached is the kernel config-file (i386), that worked fine under 7.x. The
: kernel-compile will break (some *freebsd7* structs undefined), without the
: COMPAT_FREEBSD7 option. Try it for yourself...
:
: options SYSVSHM # SYSV-style shared memory
: options SYSVMSG # SYSV-style message queues
: options SYSVSEM # SYSV-style semaphores
:
: Those require COMPAT_FREEBSD7. This does seem like a bug:
:
: static struct syscall_helper_data shm_syscalls[] = {
: SYSCALL_INIT_HELPER(shmat),
: SYSCALL_INIT_HELPER(shmctl),
: SYSCALL_INIT_HELPER(shmdt),
: SYSCALL_INIT_HELPER(shmget),
: #if defined(COMPAT_FREEBSD4) || defined(COMPAT_FREEBSD5) || \
: defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD7)
: SYSCALL_INIT_HELPER(freebsd7_shmctl),
: #endif
:
: The check should be for COMPAT_FREEBSD7 only I would think.
:
: Apart from that, everything else should work without it I would think.
You would think that, but you'd be wrong.
In general, if you have COMPAT_FREEBSDx defined, you need all
COMPAT_FREEBSDy for y x defined.
The reason for this is that we name the compat shim for the version
where it was removed, but it is needed for all prior versions.
freebsd7_shmctl is needed to emulate the earlier versions as well...
This is why we'd like to move to something more like
COMPAT_MIN_FREEBSD=z, but there's hooks into the config system and
syscall tables that make it tricky...
Warner
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Help troubleshooting...
In message: 200910260959.20772.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Monday 26 October 2009 01:05:03 n...@ever.sanda.gr.jp wrote: : M. Warner Losh wrote: : I have a usb stick (8GB) on it. This stick has about 5GB of junk on : it at this point. : : I tried to do 'cat * /dev/null' recently, to measure how fast it : goes. It got about 1GB into the drive and then I got device missing : messages. : : So devfs thinks the device went missing: : : Warner-san, maybe it is caused by the hardware problem on the USB flash : memory. Some chip on the memory might have too much heat when you access : the memory at fast rate. Then it stops working. : : : What happens if you read from two USB disks at the same time? I know that the august 25th version failed badly when I tried to burn DVDs from a USB drive to a USB attached DVD burner. This used to work flawlessly. : If the device went missing the USB HUB signalled that. This is maybe an : indication that the USB firmware on the device crashed. Maybe this is due to : heat, or unhandled race conditions when the load goes high. This same flash drive will do 20MB sustained on windows without a glitch using similar commands. : Try using dd and vary the block size from 512 to 65536 bytes. Does it stop : working with all block sizes over time? Once I get the message I posted, it is lights out for da0. No further access to the drive works at all. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Help troubleshooting...
In message: 200910261258.08135.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Monday 26 October 2009 12:48:16 M. Warner Losh wrote: : I know that the august 25th version failed badly when I tried to burn : DVDs from a USB drive to a USB attached DVD burner. This used to work : flawlessly. : : Hi, : : There has been a recent fix to the EHCI driver, which might affect Mass : Storage when short transfers are used. : : Also someone else has pointed out that certain VIA chipsets have an IRQ bug : requiring the need for a software callout to restart the EHCI interrupt : handler. This is not yet patched, hence I don't know if this is a real issue. : : http://svn.freebsd.org/viewvc/base?view=revisionrevision=197682 : : Is your code from after 1st of October? This code is from: FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri Oct 23 10:08:48 MDT 2009 i...@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE amd64 so it would have r197682 baked in (the first number in my rev string is a mystery to me). Re another post: This is a 8GB flash, so I'm sure that there's enough power. Looking at the dmesg, this happend the second or third time I'd plugged in this flash drive. Here's a partial dmesg for usb things: CPU: AMD Turion(tm) 64 Mobile Technology ML-37 (1994.21-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x20f42 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow! AMD Features2=0x1LAHF real memory = 2147483648 (2048 MB) avail memory = 2059546624 (1964 MB) ACPI APIC Table: PTLTD APIC MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 2.1 irqs 0-23 on motherboard ... pcib2: ACPI PCI-PCI bridge at device 5.0 on pci0 pci2: ACPI PCI bus on pcib2 ohci0: ATI SB400 USB Controller mem 0xc000-0xcfff irq 19 at device 19.0 on pci0 Activate PA 0xc000 at VA 0xff00c000 ohci0: [ITHREAD] usbus0: ATI SB400 USB Controller on ohci0 ohci1: ATI SB400 USB Controller mem 0xc0001000-0xc0001fff irq 19 at device 19.1 on pci0 Activate PA 0xc0001000 at VA 0xff00c0001000 ohci1: [ITHREAD] usbus1: ATI SB400 USB Controller on ohci1 ehci0: ATI SB400 USB 2.0 controller mem 0xc0002000-0xc0002fff irq 19 at device 19.2 on pci0 Activate PA 0xc0002000 at VA 0xff00c0002000 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: ATI SB400 USB 2.0 controller on ehci0 ... Timecounter TSC frequency 1994209008 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 Status is 0x3106 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire Activate i/o 0x8014 Activate i/o 0x8015 ugen0.1: ATI at usbus0 uhub0: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: ATI at usbus1 uhub1: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 ugen2.1: ATI at usbus2 uhub2: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus2 ad0: 114473MB FUJITSU MHV2120AT PL 008300A1 at ata0-master UDMA100 GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). uhub0: 4 ports with 4 removable, self powered uhub1: 4 ports with 4 removable, self powered ... Root mount waiting for: usbus2 uhub2: 8 ports with 8 removable, self powered Root mount waiting for: usbus2 Trying to mount root from ufs:/dev/ad0s2a ugen0.2: Broadcom Corp at usbus0 ubt0: Broadcom Corp HP Integrated Module, class 224/1, rev 2.00/1.00, addr 2 on usbus0 usb_alloc_device:1635: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! ugen2.2: HP at usbus2 umass0: HP v125w, class 0/0, rev 2.00/1.10, addr 2 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x umass0:2:0:-1: Attached to scbus2 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: HP v125w PMAP Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C) ugen2.2: HP at usbus2 (disconnected) umass0: at uhub2, port 6, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): Invalidating pack g_vfs_done():da0s1[READ(offset=5298202624, length=65536)]error = 6 g_vfs_done():da0s1[READ(offset=5298268160, length=65536)]error = 6 g_vfs_done():da0s1[READ(offset=5298333696, length=65536)]error = 6 g_vfs_done():da0s1[WRITE(offset=1976320, length=32768)]error = 6 g_vfs_done():da0s1[READ(offset=5298137088, length=65536)]error = 6 (da0:umass-sim0:0:0:0
Re: Help troubleshooting...
In message: 86skd6cmm8@ds4.des.no Dag-Erling_Smørgrav d...@des.no writes: : M. Warner Losh i...@bsdimp.com writes: : FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri Oct 23 10:08:48 MDT 2009 i...@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE amd64 : : so it would have r197682 baked in (the first number in my rev string : is a mystery to me). : : It means you have an inconsistent tree. The first number is the oldest : revision in your tree, the second is the newest, and the M means you : have local modifications. Yes. Of course I have local modifications, but none in the usb stack. But I've also done a svn update from the top of the tree multiple times and this version number persists. : Re another post: This is a 8GB flash, so I'm sure that there's enough : power. : : Non sequitur. Bigger chips draw more power. Is it plugged directly : into the computer? If not, is it plugged into a powered hub? How many : other devices are connected to the computer or hub? Not entirely. This flash has worked in this computer in the past without issues (like a year ago when we were first integrating hpsusb into the tree). This flash is plugged directly into the computer. This behavior is consistent across multiple ports on the computer (so it isn't a bad port). While this doesn't prove it isn't a power issue, the odds are stacked against it being one. If there were a way to get the internal hub to tell me how much power it can deliver, and for me to query the flash to see maximum current draws, we could see if we're close to the edge or not... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Help troubleshooting...
I have a usb stick (8GB) on it. This stick has about 5GB of junk on
it at this point.
I tried to do 'cat * /dev/null' recently, to measure how fast it
goes. It got about 1GB into the drive and then I got device missing
messages.
Here's the dmesg messages:
# Plug it in
da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
da0: HP v125w PMAP Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C)
# mount it, etc
# run the cat command
Device da0s1 went missing before all of the data could be written to it; expect
data loss.
# get error messages
# Remove the drive
ugen2.2: HP at usbus2 (disconnected)
umass0: at uhub2, port 1, addr 2 (disconnected)
(da0:umass-sim0:0:0:0): lost device
(da0:umass-sim0:0:0:0): removing device entry
So devfs thinks the device went missing:
static int
devfs_fsync(struct vop_fsync_args *ap)
{
...
if (!vn_isdisk(ap-a_vp, error)) {
bo = ap-a_vp-v_bufobj;
de = ap-a_vp-v_data;
if (error == ENXIO bo-bo_dirty.bv_cnt 0) {
printf(Device %s went missing before all of the data
could be written to it; expect data loss.\n,
de-de_dirent-d_name);
...
So it thinks that it isn't a disk. vn_isdisk is return ENXIO because
either vp-v_rdev == NULL or the v_rdev-si_devsw == NULL.
So how the heck can that happen without other warnings? It appears
the only place it is set like this is in devfs_reclaim. But I'm
having trouble tracking down where *THAT* is called.
This is with the following system:
FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri Oct
23 10:08:48 MDT 2009
i...@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE amd64
Warner
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Performance issues
Hans, Just trying to do some stuff I used to be able to do with the USB stack on a recent (July 23rd) kernel. I've had some disappointing results. I have a 750GB disk that's attached via USB. Nothing fancy or special about it. I can stream up to about 18MB/s to it when things are going well. Older code works flawlessly with this device. I have one other device attached, a bluetooth dongle that's really just buit into my laptop. There's no bluetooth devices attached to the laptop via this dongle, but plenty of bluetooth in the general area... The bt stack is enabled. What I see is that from time to time the writes to the disk stop for seconds at a time. This can happen when I'm writing from DV streams (which are 25Mb/s or 4.1MB/s) as well as a dd from either /dev/zero or from a dvd I have in my laptop's DVD reader. The /dev/zero ones go at about 16-18MB/s, while the DVD reader is about 5MB/s. When it happens, the process hangs in wdrain. This makes it impossible to use umass devices for things like reading my DV camera to stream things to disk for later processing into DVDs. It also seems to make it impossible to burn DVDs, since this same hic-up is seen in read speed as well. If I remove the bluetooth dongle from the system, then I don't seem to see this problem. Any ideas how to track this down? Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Performance issues
In message: 200908091840.55000.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Sunday 09 August 2009 18:23:41 M. Warner Losh wrote: : Any ideas how to track this down? : : Hi, : : USB is only draining from usbd_transfer_drain() in : /sys/dev/usb/usb_transfer.c . You could add a print including the backtrace : and see if that function gets called when it freezes. Ummm. No. Adding a traceback print to a function that's called 60 times a second in steady state doesn't seem like a viable option. : Else I would try to compile a fresh kernel from USB P4. There are : some patches there in relation to the recent newbus lock change, : that might help. This kernel predates the newbus lock change. : USB uses uppercase WDRAIN. Is your printout lowercase wdrain ? Yes. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Performance issues
In message: 3bbf2fe10908091038m3efb3612l2923d8b3238e1...@mail.gmail.com Attilio Rao atti...@freebsd.org writes: : 2009/8/9 Attilio Rao atti...@freebsd.org: : 2009/8/9 M. Warner Losh i...@bsdimp.com: : In message: 200908091840.55000.hsela...@c2i.net : Hans Petter Selasky hsela...@c2i.net writes: : : On Sunday 09 August 2009 18:23:41 M. Warner Losh wrote: : : Any ideas how to track this down? : : : : Hi, : : : : USB is only draining from usbd_transfer_drain() in : : /sys/dev/usb/usb_transfer.c . You could add a print including the backtrace : : and see if that function gets called when it freezes. : : Ummm. No. Adding a traceback print to a function that's called 60 : times a second in steady state doesn't seem like a viable option. : : : Else I would try to compile a fresh kernel from USB P4. There are : : some patches there in relation to the recent newbus lock change, : : that might help. : : This kernel predates the newbus lock change. : : : USB uses uppercase WDRAIN. Is your printout lowercase wdrain ? : : Yes. : : That's used by the buffer cache in order to reduce pressure of : asynchronous writes. It waits for other writes to complete before to : go on. Probabilly, I/O requests get stuck for another reasong starving : the asynchronous requests queue flushing. : : It would be also interesting to understand if the allowed requests are : just lost or still pending and can be effectively flushed out. Can you : please show the content of vm.runningbufspace ? The writes eventually happen, it is just stalled. I'll run the experiment again and see if I can give you that info... : However, keep in mind that as long as the buffer cache is global, if : the bluethoot dongle breaks I/O requests, it can be the offending : part, so USB may not be involved. I'm not sure I understand this statement. I think what is happening is a race between multiple devices. I also see problems when I have both a usb disk and a usb dvd burner attached. I didn't used to see that problem (I made hundreds of DVDs of my son's hockey games). Now, I can't even burn one disc to save my life... Besides, the bluetooth dongle isn't going to be doing any disk block requests, so how can that interfere with the buffer cache? Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: About the USB Cache and busdma usage in USB thread
In message: 200907232209.47729.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Thursday 23 July 2009 20:53:06 Marcel Moolenaar wrote: : All, : : I went over the thread and this is what I have to say about it: : : Using busdma to manage/control CPU caches is wrong for the : following simple reason: bus_dmamap_sync() has the side-effect : of copying to and from the bounce buffer (if applicable). : : CPU caches should be kept coherent by using an appropriate API. : We already have cpu_flush_dcache(). All we have to do is add : cpu_inval_dcache() and let the MD code determine how best to : do this -- even if they decide to use busdma. : : In general: D-cache and I-cache control/handling should not be : hidden from MI code. It should not be treated as an artifact of : some platform. It should not be implemented by banking on some : side-effect of other function(s). We only achieve efficient : cache control if MI code calls appropriate APIs so that we can : precisely express what we need to achieve at that point. : : For example: when we write a breakpoint into the text segment : of some process by using ptrace(2), the ptrace(2) code must : call an appropriate API to make sure that the I-cache is made : coherent with memory. This may require a previous D-cache : flush! We should not kluge uiomove(9) like we did on PowerPC : to deal with this. Note ARM and ia64 are still broken in this : respect. : : Hi, : : I would be fine with a solution where cpufunctions are used directly in USB. : The only problem is that if bounce pages are used, which happens in the case : of loading kernel virtual data into DMA, then busdma sync calls would still be : required. They are needed on i386 kernels with more than 4GB of ram... Or ram located above 4GB... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Atheros wireless device driver developer
You know, it would be a lot easier if you just email Sam directly rather than spam the lists with this :) Especially since you don't mention FreeBSD at all... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: detaching usb device without unmounting it
In message: permail-20090710090548f7e55a9d3ae0-a_bes...@message-id.uni-muenster.de Alexander Best alexbes...@math.uni-muenster.de writes: : since the usb2 stack allows one to detach a mounted usb device without the : kernel panic'ing usb1 allowed that too. the problem rarely was inside the usb stack (although there were some problems). The problem was at the higher levels of cam, the buffer cache and the file system. There were changes scattered throughout the rest of the system to allow devices to suddenly disappear. All usb2 did was fix a few edge cases in usb. : i'd like to know which steps are necessary to be taken after : detaching a device? because i tried the following: : : 1. attach device : 2. mount device : 3. detach device : : when i tried to unmount the device i got the follwing error message: : : g_vfs_done():label/usb[WRITE(offset=19456, length=4096)]error = 6 The proper action is limited to 'umount -f'. You can't reattach it, you can't really touch any files in the system (some cached files might be ok), you certainly can't write to it. : and the console got locked up (ctr+c didn't work). so i tried to reboot using : ctrl+alt+del. however after the message: All buffers synced there was no : reboot. so i had to do a hard reset. however after the reset freebsd fsck'ed : my harddrives. so they didn't unmount properly. : : should i have used `umount -f`? or just plug the device back in again? or : isn't it possible to unmount a device that has already been detached? You should have done an umount -f. You can't plug it back in again because we don't have support at the right levels (CAM(?), GEOM, buffer cache, fs) to allow previously orphaned resources to be reconnected to a new device. The device was destroyed, and data was destroyed with it... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: CPU Cache and busdma usage in USB
In message: 200907081103.45388.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Wednesday 08 July 2009 10:58:17 Rafal Jaworowski wrote: : On 2009-07-07, at 18:46, Hans Petter Selasky wrote: : I had Checked USB behaviour on PowerPC without hardware cache : coherency. : The problem also exists here and patch helps. : : In my source code view the busdma sync function is empty for power- : pc. Your : patch should have no effect at all for sync operations? : : This was about the PPC4xx PowerPC port, not committed to the tree yet. : Unlike most PowerPC this system has a de-coherent DMA and therefore : its busdma sync is non empty, but needs to enforce coherency by : software. : : The point is this is another platform on which USB stack (usb_pc_cpu_* : functions) shows similar issues as reported for ARM and MIPS. : : And what about my patch suggestion in my previous e-mail having the same : subject. Does it work? : : Regarding my testing on the AT91RM9200 I was short of time yesterday and will : try to get it done today. I think that the root cause of this issue is two fold. First, The 4 operations for busdma are being collapsed to only 2 operations. There are four for a reason (since you have to do different things for each case). Second, and I think this is more important, I think that we're seeing some cache-line poisoning. We're flushing the entire busdma tag rather than just one cache line since we don't have the API to do that. In addition, I don't think that the USB code is being careful enough to ensure that we don't have buffers that live in the same cache line that are simultaneously being used for read and write. The corruption we're seeing is a classic signal that this may be going on, although I must admit that I've not done the detailed analysis to prove it. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: CPU Cache and busdma usage in USB
In message: 200906231912.20741.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Tuesday 23 June 2009 11:11:29 Alexandr Rybalko wrote: : On Tue, 23 Jun 2009 10:35:42 +0200 : : Piotr Zięcik ko...@semihalf.com wrote: : While bringing up EHCI (8-CURRENT, new USB stack) on ARM machine we : have found cache-related problem in the USB stack. : : The usb_pc_cpu_flush() and usb_pc_cpu_invalidate() functions are used to : flush/invalidate CPU caches in various places in USB code. Internally, : the functions are implemented using bus_dmamap_sync(). In our case, on : ARM machine, flags passed to the bus_dmamap_sync() function did not : correspond with requested operation. We have fixed the problem by : changing flags passed to the bus_dmamap_sync() function (see attached : patch). : : My question is about general idea of bus_dma usage for cache operations. : In my opinion we should not rely on bus_dmamap_sync() behaviour as this : function may do different things on different architectures. This not : always works as expected, which is clearly visible in our case. Better : solution is to use cpu-specific functions implementing cache operations. : Please comment on why CPU-specific functions are not used... I think because busdma is supposed to abstract this out. The problem is that the usb code chose different terms to represent these operations than is typically used. : Patch fixing our problem: : diff --git a/sys/dev/usb/usb_busdma.c b/sys/dev/usb/usb_busdma.c : index 3d6a5be..69a6fff 100644 : --- a/sys/dev/usb/usb_busdma.c : +++ b/sys/dev/usb/usb_busdma.c : @@ -658,8 +658,7 @@ usb_pc_cpu_invalidate(struct usb_page_cache *pc) : /* nothing has been loaded into this page cache! */ : return; : } : - bus_dmamap_sync(pc-tag, pc-map, : - BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD); : + bus_dmamap_sync(pc-tag, pc-map, BUS_DMASYNC_PREREAD); :} I think this patch is currect. Invalidate should be done to a region before you read into it. : /*-- : --* @@ -672,8 +671,7 @@ usb_pc_cpu_flush(struct usb_page_cache *pc) /* : nothing has been loaded into this page cache! */ return; : } : - bus_dmamap_sync(pc-tag, pc-map, : - BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD); : + bus_dmamap_sync(pc-tag, pc-map, BUS_DMASYNC_PREWRITE); :} This makes sense as well. Flushing the cache to memory is the right logical operation before writing to the device with a DMA transfer. : /*-- : --* : : : : Great thanks Piotr! : I work on MIPS BCM5354 and BCM5836 and after apply your patch USB work : correct. : : We are currently investigating if your patch is correct. Thanks for your patch : suggestion! From the comments in the code, they look correct. I don't know if all the usages of these functions is reflected in their comments. I've not had a chance to audit them all... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: EHCI Problem on FreeBSD arm port
In message: 260bb65e0905091102y272de752r750a3a799404...@mail.gmail.com Yohanes Nugroho yoha...@gmail.com writes: : On Sat, May 9, 2009 at 3:09 PM, Hans Petter Selasky hsela...@c2i.net wrote: : : Hi, : : If the strings are corrupt I would guess at a busdma issue. : : thank you, adding a flush all instruction makes the USB controller : works properly. : : Now i should check the implementation of the FA526 invalidate/flush : instruction, because I shouldn't need the extra flush instruction if : bus_dmamap_sync works properly, right?. I believe so. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: u3g serial device name query
In message: 200904301412.38313.freebsd-...@dino.sk Milan Obuch freebsd-...@dino.sk writes: : On Thursday 30 April 2009 12:58:36 Hans Petter Selasky wrote: : On Thursday 30 April 2009, Milan Obuch wrote: : Hi, : : I have HUAWEI 3g usb modem. It works with u3g from current. There is : however one thing I did not get working yet. : : When device attaches, it is added into tree as u3gN, devd event is sent. : It is easily matched with 'device-name u3g[0-9]' clause in devd.conf. I : can start ppp automatically and it works well, given no other USB serial : device is present. : : If another USB serial device such as uplcom is present, u3g serial ports : does not have the same name. I found no way to relate serial device name : to this event and looking in source I see no place where it is created. I : would like to put a devctl notify call there. This way I could start ppp : with correct device name even if there is some other USB serial device. : : Could someone point me in the right direction? : : USB serial devices have their own unit management. There is however a way : to override the unit number through the usb2_com_tty_name callback, which : requires some code changes to the u3g driver. : : All USB modems and serial adapters end up with the same naming : prefix: /dev/cuaU%d.%d, so the assigned numbers must be serialised. : : What we could do is to have a separate naming prefix for 3G modems, and use : the device_get_unit() for unit number. : : See: src/sys/dev/usb/serial and usb_serial.c : : : I looked over usb2_com_attach_tty function in usb_serial.c, and somewhere : after call to tty_makedev (where a DPRINT is too) I could put a devctl call. : : All I need for it would be device name. In /var/log/message file I see a line : telling 'u3g0 : Found 2 ports' just after usb2_com_attach_tty function is : called. If you could tell me how I can get 'u3g0' name via sc argument in : usb2_com_attach_tty function, I can solve this with no other change. While I have issues with the names of the new ttys, since they are gratuitously different than the past, it isn't the fundamental problem. What we really need in devd is the ability to tie events to /dev entries appearing rather than at device attach time, since the two can be different... What you really need to do is to take the u3g0 attach, find out what its children are and use that to figure out things... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Bad USB port explanation?
In message: 009e01c9ca01$356cca70$a0465f...@com Engineering e...@athyriogames.com writes: : Only on one USB port is it going haywire. I can disconnect the camera while : the app is running, move it to another port, and it pops up at 30fps. Move : it back to the top left port, and it goes bad again. I've seen three things cause this. 1: static damage. 2: improper balancing of the inputs and 3: overloaded hub for other ports... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: boot panic on current(04.20)
In message: 41877.147.83.40.213.1240324705.squir...@webmail.entel.upc.edu Gustavo Perez Querol gpe...@entel.upc.edu writes: : lists :boot panic on current(2009.04.20).it seems caused by usbus4 : : Root mount waiting for: usbus4 : uhub4: 8 ports with 8 removable, self powered : Root mount waiting for: usbus4 : ugen4.2: NEC at usbus4 : Fatal trap 12: page fault while in kernel mode : cpuid = 0; apic id = 00 : fault virtual address = 0x0 : fault code = supervisor read, page not present : instruction pointer = 0x20:0xc08ed3a3 : stack pointer = 0x28:0xe4c38b40 : frame pointer = 0x28:0xe4c38b44 : code segment= base 0x0, limit 0xf, type 0x1b : = DPL 0,pres 1, def32 1, gran 1 : processor eflags= interrupt enabled, resume, IOPL = 0 : current process = 28 (usbus4) : trap number = 12 : panic: page fault : cpuid = 0 : uptime: 5s : : I'm having the same problem with my laptop. It fails (if I remember : well) when checkig an O2 Micro device (probably my card reader, don't : know). When rebooting got to loader prompt, unload kernel and load : /boot/kernel.old/kernel. This arrises a few questions : : : 1.- How can I install a custom kernel under a different directory : under /boot. I did it, but I can't find how (google doesn't : help)I did it. I think there's a define when installing the : kernel. make installkernel KERNEL=fred will install the kernel into /boot/fred. Might want to look add # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. to the kernel so you can get a traceback... : 2.- nextboot allows me to choose a different kernel a give it : options, but is it possible to make the changes permanent ? Not sure. I don't use nextboot. :Well, now I'm csup down to current 18/04. Hope it will work :) : :Excuse me for the previous mail, that webmail I'm using is driving me : more crazy :) Web mail has been known to do that to me too :) Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
usb2 broken wrt devd
When you plug in a device that has no driver, the following traffic is generated to devd: +ugen0.2 vendor=0x0bda product=0x8150 devclass=0x00 devsubclass=0x00 sernum= at port=1 on ugen0.1 ? at port=1 interface=0 vendor=0x0bda product=0x8150 devclass=0x00 devsubclass=0x00 sernum= intclass=0xff intsubclass=0x00 on uhub0 -ugen0.2 vendor=0x0bda product=0x8150 devclass=0x00 devsubclass=0x00 sernum= at port=1 on ugen0.1 There's many things wrong with this: (1) First, ugen0.2 is not a valid device tree node name. Or rather, it suggests a device whose class name is ugen0. instance 2. 0.2 is not a valid device number. (2) Second, it is contradictory. It says that ugen0.2 attached, but it also says that device didn't attach. That's confusing. (3) Third, devinfo -v | grep ugen produces no output. If devd is told that the device node is in the device tree, then it needs to be able to look it up in the tree. It doesn't today, but many races in the 'ticker' model can be solved by querying for the actual device. (4) There's no ugen0.1 in the tree either, and suffers from #1 and #3. This output comes from: ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: external DVD Rewriter
In message: 49c90409.8020...@yahoo.fr dan mesli...@yahoo.fr writes: : Hi, thank you for the answer ! : : So, If I am not wrong, you are suggesting to forget about this warning : and go on using the writer, right ? If it works, yes. Don't worry. Be happy! : Hmmm ... I would be at least interested in understanding the nature of : the problem, to be honest. And avoid that hundreds of these messages : fill in the screen sometimes hiding important error messages :-) The problem is with old Flash memory sticks. They wedge hard when certain commands are sent to them. The original filter was put in place to ensure a strict compliance to one of the scsi subsets that was used for the flash sticks. However, it caught more than just memory sticks in its net. so when the burning software sends the commands to query the state of the disk, set the burn speed, etc, you'll see these commands appear in the logs. : Any suggestion ? Did that help? Warner : Thank you, : : dan : : : M. Warner Losh wrote: : In message: 49c7affe.4060...@yahoo.fr : dan mesli...@yahoo.fr writes: : : Hi ! : : : : I recently added an external LG dvd rewriter to a clean FreeBSD 7.1 : : installation. : : : : --- : : umass0: HLDS Inc SuperMulti RW, class 0/0, rev 2.00/1.59, addr 2 on uhub3 : : cd0 at umass-sim0 bus 0 target 0 lun 0 : : cd0: HL-DT-ST DVDRAM GE20LU10 FE05 Removable CD-ROM SCSI-0 device : : --- : : : : As soon as I installed the xorg + gnome 2 ports these `odd` messages : : started to continuously appear in ttyv0 : : : : : --- : : umass0: Unsupported ATAPI command 0x4a - trying anyway : : umass0: Unsupported ATAPI command 0x4a - trying anyway : : umass0: Unsupported ATAPI command 0x46 - trying anyway : : umass0: Unsupported ATAPI command 0x4a - trying anyway : : [] : : umass0: Unsupported ATAPI command 0x4a - trying anyway : : [] : : --- : : : : After investigating a bit, I suppose these messages are a kind of an : : answer from the umass driver to HAL inquiries ( ... disabling HAL the : : messages disappear). : : : : the doubts and questions are: ...is the command really an unsupported : : command or is it a bug ? : : : : In case it is a bug, to whom should I fill in a PR ? : : Old usb printed this warning because of history. Originally it was an : error because the thumb drives were stupid POS at the time and any : command that they didn't understand would take an error path that hung : the device. Bad kharma. In time, I got tired of adding each new : command so that my dvd burner would work, so I just said screw it, : this is a warning now, and if somebody's drive fraks up, then so be : it: they will know what's going on at least. Besides, people that try : to burn a CD/DVD on their 256MB flash drive don't need that much : protection: bad things happening to them isn't necessarily bad. : : Usb in 8.0 I think eliminated the warning. : : Warner : : : : : ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: external DVD Rewriter
In message: 49c7affe.4060...@yahoo.fr dan mesli...@yahoo.fr writes: : Hi ! : : I recently added an external LG dvd rewriter to a clean FreeBSD 7.1 : installation. : : --- : umass0: HLDS Inc SuperMulti RW, class 0/0, rev 2.00/1.59, addr 2 on uhub3 : cd0 at umass-sim0 bus 0 target 0 lun 0 : cd0: HL-DT-ST DVDRAM GE20LU10 FE05 Removable CD-ROM SCSI-0 device : --- : : As soon as I installed the xorg + gnome 2 ports these `odd` messages : started to continuously appear in ttyv0 : : : --- : umass0: Unsupported ATAPI command 0x4a - trying anyway : umass0: Unsupported ATAPI command 0x4a - trying anyway : umass0: Unsupported ATAPI command 0x46 - trying anyway : umass0: Unsupported ATAPI command 0x4a - trying anyway : [] : umass0: Unsupported ATAPI command 0x4a - trying anyway : [] : --- : : After investigating a bit, I suppose these messages are a kind of an : answer from the umass driver to HAL inquiries ( ... disabling HAL the : messages disappear). : : the doubts and questions are: ...is the command really an unsupported : command or is it a bug ? : : In case it is a bug, to whom should I fill in a PR ? Old usb printed this warning because of history. Originally it was an error because the thumb drives were stupid POS at the time and any command that they didn't understand would take an error path that hung the device. Bad kharma. In time, I got tired of adding each new command so that my dvd burner would work, so I just said screw it, this is a warning now, and if somebody's drive fraks up, then so be it: they will know what's going on at least. Besides, people that try to burn a CD/DVD on their 256MB flash drive don't need that much protection: bad things happening to them isn't necessarily bad. Usb in 8.0 I think eliminated the warning. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Still wrong
ugen2.2: Myson Century, Inc. at usbus2 umass0: Mass Storage Class on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x4480 umass0:2:0:-1: Attached to scbus2 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): Unretryable error da0 at umass-sim0 bus 0 target 0 lun 0 da0:Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present This is a cd player. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
usbdevs -v
So what's the new way to say usbdevs -v? usbconfig list doesn't list device IDs. And devinfo doesn't show a device unless it is attached to a driver. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Still wrong
In message: 20090322.071220.1447367564@bsdimp.com M. Warner Losh i...@bsdimp.com writes: : ugen2.2: Myson Century, Inc. at usbus2 : umass0: Mass Storage Class on usbus2 : umass0: SCSI over Bulk-Only; quirks = 0x4480 : umass0:2:0:-1: Attached to scbus2 : (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 : (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error : (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition : (probe0:umass-sim0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 : (probe0:umass-sim0:0:0:0): Medium not present : (probe0:umass-sim0:0:0:0): Unretryable error : da0 at umass-sim0 bus 0 target 0 lun 0 : da0:Removable Direct Access SCSI-2 device : da0: 40.000MB/s transfers : da0: Attempt to query device size failed: NOT READY, Medium not present : : This is a cd player. The MYSON HEDEN entry most likely can just be removed entirely. I don't think it is needed, and certainly isn't necessary for my device. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Still wrong
In message: 200903221455.13414.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Sunday 22 March 2009, M. Warner Losh wrote: : In message: 20090322.071220.1447367564@bsdimp.com : : M. Warner Losh i...@bsdimp.com writes: : : ugen2.2: Myson Century, Inc. at usbus2 : : umass0: Mass Storage Class on usbus2 : : umass0: SCSI over Bulk-Only; quirks = 0x4480 : : umass0:2:0:-1: Attached to scbus2 : : (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 : : (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error : : (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition : : (probe0:umass-sim0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 : : (probe0:umass-sim0:0:0:0): Medium not present : : (probe0:umass-sim0:0:0:0): Unretryable error : : da0 at umass-sim0 bus 0 target 0 lun 0 : : da0:Removable Direct Access SCSI-2 device : : da0: 40.000MB/s transfers : : da0: Attempt to query device size failed: NOT READY, Medium not present : : : : This is a cd player. : : The MYSON HEDEN entry most likely can just be removed entirely. I : don't think it is needed, and certainly isn't necessary for my : device. : : Maybe you can limit the entry by the revision ID ? : : It seems like multiple products are using the same vendor + product ID's. Do we have the history about why the quirk was needed to start with? Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usbdevs -v
In message: 200903221454.10594.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Sunday 22 March 2009, M. Warner Losh wrote: : So what's the new way to say usbdevs -v? usbconfig list doesn't list : device IDs. And devinfo doesn't show a device unless it is attached : to a driver. : : usbconfig dump_device_desc | grep id So the answer would basically be no, there isn't a simple one: sudo usbconfig dump_device_desc | grep id idVendor = 0x idProduct = 0x idVendor = 0x idProduct = 0x idVendor = 0x idProduct = 0x idVendor = 0x04cf idProduct = 0x8818 idVendor = 0x0d49 idProduct = 0x7310 It is possible to find the info, but it is burried in a very verbose output. It is some cool very verbose output, granted, but still, it can take a while to find... Guess that's what they made emacs for... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usbdevs -v
In message: 49c68ebb.8090...@telenix.org Chuck Robey chu...@telenix.org writes: : -BEGIN PGP SIGNED MESSAGE- : Hash: SHA1 : : Hans Petter Selasky wrote: : On Sunday 22 March 2009, M. Warner Losh wrote: : So what's the new way to say usbdevs -v? usbconfig list doesn't list : device IDs. And devinfo doesn't show a device unless it is attached : to a driver. : : usbconfig dump_device_desc | grep id : : Is this usbconfig interface planned to be the only remaining tool? Having only : those difficult to remember long form commands makes this tool quite user : unfriendly. In my own system, I'm going to have to implement a shell shim, to : help me out. Doesn't this seem hard to remember, to anyone else? I'd be happy with a 'usbconfig list -v' for this request. usbdevs does little more than that. That would make the usbdevs program #!/bin/sh exec usbconfig list $* (or is that list bit $*, I forget). Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usbdevs -v
In message: 20090322.141641.1942082123@bsdimp.com M. Warner Losh i...@bsdimp.com writes: : In message: 49c68ebb.8090...@telenix.org : Chuck Robey chu...@telenix.org writes: : : -BEGIN PGP SIGNED MESSAGE- : : Hash: SHA1 : : : : Hans Petter Selasky wrote: : : On Sunday 22 March 2009, M. Warner Losh wrote: : : So what's the new way to say usbdevs -v? usbconfig list doesn't list : : device IDs. And devinfo doesn't show a device unless it is attached : : to a driver. : : : : usbconfig dump_device_desc | grep id : : : : Is this usbconfig interface planned to be the only remaining tool? Having only : : those difficult to remember long form commands makes this tool quite user : : unfriendly. In my own system, I'm going to have to implement a shell shim, to : : help me out. Doesn't this seem hard to remember, to anyone else? : : I'd be happy with a 'usbconfig list -v' for this request. usbdevs : does little more than that. That would make the usbdevs program : : #!/bin/sh : exec usbconfig list $* : : (or is that list bit $*, I forget). Oh, just ran the man page, and it is a little more than that... -f is the only hard one to implement... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USBTODO
In message: 20090319223756.gf2...@citylink.fud.org.nz Andrew Thompson thom...@freebsd.org writes: : Remember there is a page tracking the new USB stack to the 8.0 release. : Please add any items/regressions or even better would be to pick up a : task and work on it. : : http://wiki.freebsd.org/USBTODO I have a flash drive that dies under heavy load (the LED on it goes out) and then any further disk I/O fails. Would something like that go on the page? Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Belkin Cardbus USB2 adaptors too hot.
In message: 200903181907.n2ij7k1d042...@fire.js.berklix.net Julian Stacey j...@berklix.org writes: : Hi, : Anyone else noticed Belkin Cardbus USB2 adaptors run extremely hot ? : I've been having weird things happen : umass errs, g_vfs_done()da0a[WRITE(offset=, : length=131072)]error = 5 first errors after a 66G write, : subsequent errors after just 1G more, (in retrospect when : truly hot) : I've built a break out box to check Voltages Current : delivered into external USB2 to IDE enclosures, : just bought another new 250G IDE for another enclosure, : lots of enclosures usb2 hub power blocks tried, then I : remembered this card used to run hot on FreeBSD-6, in this : Toshiba Satellite S5100-603, I think BSD + this laptop : cooked my brothers identical Belkin card too last year. : The laptop BTW: : http://www.berklix.com/~jhs/hardware/toshiba/satellite.s5100-603/ : So 2 things: : FreeBSD-7.1-RELEASE is still cooking by default. : I recall cardbus can run at 2 different voltages ? : Well we need to change something to detect that. : Anyone want to throw me an RTFM URL start point for reading ? : (Sorry to ask here not read first, trying to catch a boat ASAP). Cardbus runs at 3.3V only. There's X.X and Y.Y low-voltage specs, but nobody seems to implement them. PC Card (the 16-bit version) runs at 3.3V or 5.0V. The usual reason for cards running really hot is too much current draw over the bus for supplied devices. Many of the cards have an external power supply that can be used to provide more power over a path that is made for it rather than exceeding the CardBus specs to pull the power in over that power bus. Don't know if this card has that or not... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Xorg 7.4 and umass devices - a bad combination?
In message: 20090316205626.b0ed5027.torfinn.ingolf...@broadpark.no Torfinn Ingolfsen torfinn.ingolf...@broadpark.no writes: : Have anyone seen bad performance when using umass devices (external : hard drives) in combination with Xorg 7.4? I don't see it. But I'm not using a usb mouse/keyboard... Are you? Warner : The reason I ask is that I have this machine[1] which is both a test : workstation, and cheap-ass fileserver. I am using external usb drives : for storage (it was the cheapest option when I set this up). : r...@kg-quiet# dmesg | grep da[01234] : da4 at sbp0 bus 0 target 0 lun 0 : da4: Maxtor OneTouch II 0310 Fixed Direct Access SCSI-4 device : da4: 50.000MB/s transfers : da4: 286188MB (586114704 512 byte sectors: 255H 63S/T 36483C) : da3 at umass-sim3 bus 3 target 0 lun 0 : da3: WD 5000AAK External 1.06 Fixed Direct Access SCSI-0 device : da3: 40.000MB/s transfers : da3: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) : da2 at umass-sim2 bus 2 target 0 lun 0 : da2: WD 5000AAK External 1.06 Fixed Direct Access SCSI-0 device : da2: 40.000MB/s transfers : da2: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) : da1 at umass-sim1 bus 1 target 0 lun 0 : da1: WD 5000AAV External 1.06 Fixed Direct Access SCSI-0 device : da1: 40.000MB/s transfers : da1: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) : da0 at umass-sim0 bus 0 target 0 lun 0 : da0: WD 5000AAK External 1.06 Fixed Direct Access SCSI-0 device : da0: 40.000MB/s transfers : da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) : : Yes, there is a firewire drive in there too. : : The machine currently runs FreeBSD 6.4-stable / amd64, and have run : through most releases sine 6.1-prerelease. I use Samba for file serving. : r...@kg-quiet# uname -a : FreeBSD kg-quiet.kg4.no 6.4-STABLE FreeBSD 6.4-STABLE #27: Sun Mar 15 : 19:42:19 CET 2009 r...@kg-quiet.kg4.no:/usr/obj/usr/src/sys/QUIET : amd64 : : The machine have always been in X when it is up (I use XFce) and this hasn't created any problems that I have noticed. : However, after I upgraded Xorg to 7.4, I get lots of these messages in /var/log/messages if I try to : do a simple 'ls' on any filesystem on a usb drive: : Mar 16 17:09:02 kg-quiet kernel: umass2: BBB bulk-out clear stall failed, TIMEOUT : Mar 16 17:09:31 kg-quiet kernel: umass1: BBB bulk-out clear stall failed, TIMEOUT : Mar 16 17:10:00 kg-quiet kernel: umass3: BBB bulk-out clear stall failed, TIMEOUT : Mar 16 17:10:43 kg-quiet kernel: umass0: BBB reset failed, TIMEOUT : Mar 16 17:11:12 kg-quiet kernel: umass2: BBB reset failed, TIMEOUT : Mar 16 17:11:41 kg-quiet kernel: umass1: BBB reset failed, TIMEOUT : Mar 16 17:11:48 kg-quiet kernel: umass0: BBB bulk-in clear stall failed, TIMEOUT : Mar 16 17:12:10 kg-quiet kernel: umass3: BBB reset failed, TIMEOUT : : Followed by these: : Mar 16 17:12:53 kg-quiet kernel: g_vfs_done():da0s1d[WRITE(offset=196864589824, length=16384)]error = 5 : Mar 16 17:12:53 kg-quiet kernel: g_vfs_done():da0s1d[WRITE(offset=114688, length=16384)]error = 5 : Mar 16 17:13:15 kg-quiet kernel: umass3: BBB bulk-in clear stall failed, TIMEOUT : Mar 16 17:13:22 kg-quiet kernel: umass2: BBB bulk-out clear stall failed, TIMEOUT : Mar 16 17:13:22 kg-quiet kernel: g_vfs_done():da2s1d[WRITE(offset=357707874304, length=16384)]error = 5 : Mar 16 17:13:22 kg-quiet kernel: g_vfs_done():da2s1d[WRITE(offset=114688, length=16384)]error = 5 : : and the 'ls' takes several minutes to complete. : : Notice that the messages mention all umass drives (umass0 - umass3), even if I only do an ls on one of them. : Also notice that the firewire drive is absent fom any messages. : Note: hal is NOT running on this machine. : : What is my workaround? Reboot the machine (needing a forced reset, as the machine hangs on shutdown : after the umass errors), let fsck do its thing and then don't start Xorg. But this is no solution. : : The funny thing is that It worked find before I upgraded Xorg from 7.3.2 to 7.4... : : Any hints on how I can debug this? : : More info: FreeBSD work log[2], dmesg output normal[3] and verbose[4]. : : References: : 1) http://tingox.googlepages.com/rs480m2 : 2) http://tingox.googlepages.com/rs480m2_freebsd : 3) http://tingox.googlepages.com/quiet-dmesg-6.4-stable-20090315.txt : 4) http://tingox.googlepages.com/quiet-dmesg-6.4-stable-20090315_verb.txt : -- : Regards, : Torfinn Ingolfsen, : Norway : : ___ : freebsd-usb@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-usb : To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org : : ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Latest kernel breaks scanner
In message: 20090308.130659.-1303465250@bsdimp.com M. Warner Losh i...@bsdimp.com writes: : Sigh. Had a working system from Mar 4th. Upgraded now it doesn't : work. Scanner not found by xsane. Most likely userland, since the kernel that it worked on last week doesn't work now. Warner : Warner : ___ : freebsd-usb@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-usb : To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org : : ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Latest kernel breaks scanner
In message: 20090308203157.gc30...@citylink.fud.org.nz Andrew Thompson thom...@freebsd.org writes: : On Sun, Mar 08, 2009 at 01:06:59PM -0600, M. Warner Losh wrote: : Sigh. Had a working system from Mar 4th. Upgraded now it doesn't : work. Scanner not found by xsane. : : Are you sure its not this? : : 20090227: :The /dev handling for the new USB stack has changed, a :buildworld/installworld is required for libusb20. Yes. Been there, done that. Also have the libmap.conf changes in place for old binaries that had worked for months before that. xsane used to just work in this setup, but now fails. Looks like some kind of mismatch in the ABI: found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 it used to print a real product/vendor there... : Does usbconfig list your devices? Yes. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Knobs to reduce PCI interrupt latency
In message: 200903040942.39191.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : Do we have any knobs in FreeBSD to reduce the interrupt latency? I am : currently seeing performance differences between 8.x and 7.x. Anyone have any : ideas? If we did, don't you think they would be enabled by default :) Seriously, I measured interrupt latency on a 7.0-current system at around 20us for a fast interrupt/filter (300MHz or 400MHz low-power CPU). For fast machines, this can approach 1us, which is hard to measure with the setup I had for the 300MHz case. Deferring work to the scheduled interrupt can be useful, especailly if you can keep the pipeline full such that the filter can kick off the next set of transactions quickly, and then call the completion routines on the last set in parallel in the ithread. This works well for most random-access things, but less well for single threaded, sequential benchmarks. Warner : --HPS : : On Wednesday 04 March 2009, Artyom Mirgorodsky wrote: : Repeat the same test using FreeBSD -current. : : a) On the machine where it is slow. : : vmstat -i ; sleep 1 ; vmstat -i : interrupt total rate : irq1: atkbd0 233 2 : irq14: ata0 85 0 : irq16: vgapci0 5377 52 : irq21: hdac0 ohci0 742 7 : irq22: nfe0 ehci0 23610229 : irq23: atapci1 5405 52 : cpu0: timer 203959 1980 : cpu1: timer 200914 1950 : Total 440325 4275 : interrupt total rate : irq1: atkbd0 234 2 : irq14: ata0 85 0 : irq16: vgapci0 5439 52 : irq21: hdac0 ohci0 742 7 : irq22: nfe0 ehci0 24621236 : irq23: atapci1 5405 51 : cpu0: timer 205981 1980 : cpu1: timer 202937 1951 : Total 445444 4283 : : I think the reduced performance can be explained by a clamp on the : interrupt rate around 1000 interrupts per second instead of 8000. Maybe : someone has an explanation for this? : : You right, the interrupt rate around 1000 (1011) on this machine, but on : FreeBSD 7.1 more 3000. If it is some kind of interrupt aggregation, may be : I can try to turn it off? : : b) On the machine where it is fast. : : vmstat -i ; sleep 1 ; vmstat -i : interrupt total rate : irq4: uart0 4154 0 : irq14: ata0 472922 0 : irq15: ata1 26 0 : irq18: em0752711 0 : irq21: ahc0 53 0 : irq23: ehci0 103456 0 : irq24: em1 147 0 : cpu0: timer 1551216517 2000 : cpu1: timer 1551195251 2000 : Total 3103745237 4001 : interrupt total rate : irq4: uart0 4154 0 : irq14: ata0 472923 0 : irq15: ata1 26 0 : irq18: em0752713 0 : irq21: ahc0 53 0 : irq23: ehci0 110949 0 : irq24: em1 147 0 : cpu0: timer 1551218551 2000 : cpu1: timer 1551197285 2000 : Total 3103756801 4001 : : : ___ : freebsd-usb@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-usb : To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org : : ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Low perfomance when read from usb flash drive
In message: 200903041910.58446.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Wednesday 04 March 2009, Andrew Thompson wrote: : On Wed, Mar 04, 2009 at 10:01:36AM +0100, Hans Petter Selasky wrote: : On Wednesday 04 March 2009, M. Warner Losh wrote: :In message: 200903040922.48163.hsela...@c2i.net : :: I am looking at using FreeBSD in an embedded product. I have not :: examined your ehci software, but I am aware of how Linux and other :: OSes run the controller. :: :: Why are you taking an interrupt every uFrame SOF? :: :: If the transaction completes before 125us we take the interrupt :: before 125us. The problem is that the interrupt delay becomes :: critical to performance when the interrupt rate is close to the :: interrupt limitation. :: :: For example: :: :: Transferring 13Mbyte/sec at blocksize equal to 65536 bytes generates :: 600 interrupts. Hence the Mass Storage state machine has three steps :: the throughput is computed like (600/3)*65536 bytes. If we on the :: average have to wait 0.5ms for an interrupt we loose throughput. : :Shouldn't you be using filters and such to make this less relevant? A :filter runs on the order of 5us after the interrupt on fast machines, :and 20us on slower (400MHz) ones. You can feed the pipeline better, :and handle higher interrupt rates... : : Yes, that's one possibility. It looks like there is some timing slightly : out of sync. I have an AMD box with the same symptoms. I will try to : figure out what is causing it. : : If you do change to filters then this is much easier with taskqueues as : it has a fast variant, otherwise you would need an intermediate step in : order to signal the existing usb threading scheme. The taskqueue : changeover will be happening soonish anyway. : : I am not going to do anything with filters. I'm going to try some other : things. Then you will always have the scheduling delay... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: The rc.d mess strikes back
In message: 2fd864e0903020512i22b2c31fg487aaf37fed63...@mail.gmail.com Astrodog astro...@gmail.com writes: : As unfortunate (and annoying) as that delay was, your system was in a : defined state, at the end of rc.d. As things stand now, that doesn't : appear to be the case anymore, and I think that may be a more : significant issue than the delay. I'd be happy with synchronous dhcp. Warner : --- Harrison : : On Mon, Mar 2, 2009 at 6:19 AM, Mike Makonnen mmakon...@gmail.com wrote: : Garrett Cooper wrote: : : : Could we just unwind this rc.d mess? It seems to be causing issues : : and wasn't very thoroughly tested before commit. : : : This is not an option because the previous behavior caused an unconditional : 30 sec. delay if the system wasn't plugged in (or if it is plugged in but : not on a DHCP network). I think making synchronous_dhclient default to YES : is the best option. : : Cheers. : -- : Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc : mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 : FreeBSD | http://www.freebsd.org : ___ : freebsd-curr...@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-current : To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org : : : : : -- : A human being should be able to change a diaper, plan an invasion, : butcher a hog, conn a ship, design a building, write a sonnet, balance : accounts, build a wall, set a bone, comfort the dying, take orders, : give orders, cooperate, act alone, solve equations, analyze a new : problem, pitch manure, program a computer, cook a tasty meal, fight : efficiently, die gallantly. Specialization is for insects. : --- Robert A. Heinlein : : ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: The rc.d mess strikes back
In message: 20090302233215.ga53...@duncan.reilly.home Andrew Reilly andrew-free...@areilly.bpc-users.org writes: : On Mon, Mar 02, 2009 at 01:25:22PM -0700, M. Warner Losh wrote: : In message: 2fd864e0903020512i22b2c31fg487aaf37fed63...@mail.gmail.com : Astrodog astro...@gmail.com writes: : : As unfortunate (and annoying) as that delay was, your system was in a : : defined state, at the end of rc.d. As things stand now, that doesn't : : appear to be the case anymore, and I think that may be a more : : significant issue than the delay. : : I'd be happy with synchronous dhcp. : : The more general problem is the (large) number of network : applications that assume that network addresses and routes never : change (because that's how things were when they were written.) : My personal pet peeve is ntpd, but there are many others. Any : daemon that caches host IP address information at startup is : (IMO) broken, and needs to be fixed. There are many reasons why : network addresses may change *after* startup, and it is not : reasonable to go around and manually HUP everything when that : happens. True. : Needing synchronous DHCP as a work-around here is just the : signifier of the problem: it isn't the over-all solution. It is a short-term work-around at best. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2+umass: root mount fails
In message: 20090301190057.gd90...@citylink.fud.org.nz Andrew Thompson thom...@freebsd.org writes: : On Mon, Feb 16, 2009 at 01:53:36PM -0800, Marcel Moolenaar wrote: : It appears that the root mount isn't serialized with USB discovery : in the same way it was under USB1. : : It seems that this is not completly resolved with the root mount hold in : r188907 as geom may not have tasted the partition tables when : vfs_rootmount is woken. USB still needs to finish its bus probe earlier : on the boot process. This sounds like a more fundamental ordering problem. It sounds like we need two gates here. (1) All the underlying devices are there and (2) All tasting is done. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: ums no longer loads on CURRENT
In message: cb26d07a-6d29-4b53-b3f1-cd1cab8af...@gmail.com Garrett Cooper yanef...@gmail.com writes: : Recently built kernel as of today around 4pm. The mouse is available : on the console and moused isn't running; this issue prevents me from : using X11. I'm looking for all libraries linked against libusb-0.1.so. : 8 right now... Did you read updating? Warner : More details: : : [r...@orangebox /usr/home/gcooper]# kldload ums : module_register: module ushub/ums already exists! : Module ushub/ums failed to register: 17 : kldload: can't load ums: File exists : : [r...@orangebox /usr/home/gcooper]# cat /root/ORANGEBOX-common /root/ : ORANGEBOX : # START COMMON INCLUDE FILE : : cpu I686_CPU : ident ORANGEBOX : : # To statically compile in device wiring instead of /boot/device.hints : #hintsGENERIC.hints # Default places to look for devices. : : makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols : : options SCHED_ULE # ULE scheduler : options PREEMPTION # Enable kernel thread preemption : options INET# InterNETworking : #options INET6 # IPv6 communications protocols : options SCTP# Stream Control Transmission Protocol : options FFS # Berkeley Fast Filesystem : options SOFTUPDATES # Enable FFS soft updates support : options UFS_ACL # Support for access control lists : options UFS_DIRHASH # Improve performance on big directories : options UFS_GJOURNAL# Enable gjournal-based UFS journaling : options MD_ROOT # MD is a potential root device : options NFSCLIENT # Network Filesystem Client : options NFSSERVER # Network Filesystem Server : options NFSLOCKD# Network Lock Manager : options NFS_ROOT# NFS usable as /, requires NFSCLIENT : options NTFS# NT File System : options MSDOSFS # MSDOS Filesystem : options CD9660 # ISO 9660 Filesystem : options PROCFS # Process filesystem (requires PSEUDOFS) : options PSEUDOFS# Pseudo-filesystem framework : options GEOM_BSD : options GEOM_MBR : options GEOM_PART_GPT # GUID Partition Tables. : options GEOM_LABEL # Provides labelization : options COMPAT_43TTY# BSD 4.3 TTY compat [KEEP THIS!] : options COMPAT_FREEBSD4 # Compatible with FreeBSD4 : options COMPAT_FREEBSD5 # Compatible with FreeBSD5 : options COMPAT_FREEBSD6 # Compatible with FreeBSD6 : options COMPAT_FREEBSD7 # Compatible with FreeBSD7 : options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI : options KTRACE # ktrace(1) support : options STACK # stack(9) support : options SYSVSHM # SYSV-style shared memory : options SYSVMSG # SYSV-style message queues : options SYSVSEM # SYSV-style semaphores : options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time : extensions : options KBD_INSTALL_CDEV# install a CDEV entry in /dev : options STOP_NMI# Stop CPUS using NMI instead of IPI : options AUDIT # Security event auditing : options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) : : # Debugging for use in -current : options KDB # Enable kernel debugger support. : options KDB_UNATTENDED # I don't want to be here when shit crashes.. : options DDB # Support DDB. : options GDB # Support remote GDB. : options INVARIANTS # Enable calls of extra sanity checking : options INVARIANT_SUPPORT # Extra sanity checks of internal : structures, required by INVARIANTS : #options WITNESS # Enable checks to detect deadlocks and cycles : #options WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed : options COMPAT_LINUX : : # Make an SMP-capable kernel by default : options SMP # Symmetric MultiProcessor Kernel : : deviceapic : : # CPU frequency control : devicecpufreq : : # Bus support. : deviceacpi : devicepci : : # ATA and ATAPI devices : deviceata : deviceatadisk # ATA disk drives : deviceatapicam# Required for [C|DV]D burning : #device ataraid # ATA RAID drives : deviceatapicd
Re: The rc.d mess strikes back
In message: e39d3873-3f36-467a-b225-347a088b6...@gmail.com Garrett Cooper yanef...@gmail.com writes: : On Mar 1, 2009, at 7:36 PM, Garrett Cooper wrote: : : On Mar 1, 2009, at 7:20 PM, Garrett Cooper wrote: : : On Mar 1, 2009, at 6:36 PM, Sam Leffler wrote: : : Garrett Cooper wrote: : deviceums# Mouse : : This is why you cannot kldload. Not sure about any functional : regression. : : Sam : : Yeah, well that message was printed out by another process : altogether while loading up the kernel after the ata subsystem was : brought up, so something's getting confused and trying to kldload : by accident... I was just reproducing the message. : I'll provide more data to prove this claim when I can. : Thanks, : -Garrett : : Here's the picture from my iPhone: http://s303.photobucket.com/albums/nn159/yaneurabeya/?action=viewcurrent=IMG_0032.png : . I OBVIOUSLY didn't do the kldload... and because my /boot/ : loader.conf doesn't contain ums_load=YES, I'm really curious who : the actual culprit is in rc.d land... : I used to do WITHOUT_MODULES=* to not build modules, but I'm trying : to move away from that mentality for some things like snd_emu10kx, : but obviously there's a conflict somewhere for ums; hopefully it's : merely cosmetic... : Thanks, : -Garrett : : Ok, found the culprit. It turns out moused is being called from : devd... this is all probably related to the startup mess I reported 2 : weeks ago with my NIC. I'm seeing a lot of additional problems in : terms of keeping track of daemons; for instance syslogd is getting : started up twice, but the first instance isn't recording a PID and the : second one is dying because the first one is bound to the address. : Agh... I didn't think that moused loaded anything. And what do extra nics have to do with this? I think you are confusing multiple problems... : Could we just unwind this rc.d mess? It seems to be causing issues : and wasn't very thoroughly tested before commit. This is a little to vague to be actionable. Do you have specific instances? Do you have rcorder output? Etc... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Low perfomance when read from usb flash drive
In message: 200903010038.29534.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Saturday 28 February 2009, Artyom Mirgorodsky wrote: : Read speed when copy from usb flash drive decreased from 20MB/s (old usb : stack) to 12MB/s. (on windows above 22Mb/s). : : : Hi please explain what kind of test you have done. It's most likely not : related to USB, but rather the file system. : : Maybe you can run the following test on Windows and FreeBSD to compare: : : dd if=/dev/da0 of=/dev/null bs=65536 I've done a lot of data movement with usb1 and usb2 (love those .dv videos of youth hockey). This is exactly opposite of the results that I'd typically see through the filesystem (ufs). For usb1 I'd see about 15MB/s and for usb2 I'd see between 16MB/s and 18MB/s. Since this is all ufs, no windows numbers are available for comparison. These are the numbers reported by gstat, so it includes all the filesystem traffic. So a drop from 20MB/s to 12MB/s would be somewhat out of my range of experience... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: CFR: usb switchover patches
In message: 20090220100115.r53...@maildrop.int.zabbadoz.net Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net writes: : On Thu, 19 Feb 2009, Andrew Thompson wrote: : : On Thu, Feb 19, 2009 at 07:37:40PM -0800, Andrew Thompson wrote: : Hi, : : : I have put together a proposed set of changes for moving USB2 to its : permanent location. The layout has some differences to how it is right : now so I am looking for feedback. : : The changeover requires that the old usb stack be available until 8.0 is : branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason : for this location is to reduce the changes in #includes (using -I : compiler hacks). The patch doesnt show userland changes required for : usbdevs and friends but they will be done. : : Also, I wasnt planning on keeping the old usb kernel modules hooked into : the build unless someone particularly wants them. They can all still be : built into the kernel. : : what about renaming it to dev/usb1 instead of starting another top : level directory in sys/ ? I mean I like legacy and would prefer to : move netinet/ in there asap but;-)) We'd have to hack all the old usb1 drivers. Moving to sys/legacy/dev/usb means minimal frobbing of the code. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2+umass: root mount fails
In message: 200902190926.42992.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : Do you understand why probe and attach is currently partially deferred in some : drivers? It has to do with the ability to quickly recover if a device is : suddenly detached when doing multiple sequential USB operations towards a USB : device. I have the impression that you are not thinking about failure cases : like constant timeouts. What makes the picture additionaly complicated is : that there are multiple sources of detach, that do not all go through the USB : stack. : : kldunload does not go through the USB stack. : set_config does. : device_detach does. You are doing something wrong then. All of these *DO* go through newbus for proper drivers. If not, then that's a bug in newbus and should be fixed there, not kludged around. What, exactly, is the problem with kldunload? : Another point I have is that we want to do operations in parallell. I see no : reason at all to slow down the USB enumeration at boot. We are talking about : a considerable amount of time! Instead the system needs to be changed. If you : try to mount a device which is not present, then you need to retry mounting : that device if some re-try flag is set. None of this prevents the usb stack from signaling when the probe/attach is done. You can't expect mountroot to wait forever. Also, there are times when there's multiple disks available that could be root. Just waiting for root is also bad because that root might not ever get there. There has to be some sanity timeout. By properly signaling that the operation is complete, you can have better semantics. All the other drivers in the system can accommodate this paradigm. What makes usb so special? : Adding some flag to struct usb2_device saying that the device is gone will : almost solve the problem, but it does not cover the kldunload case. Also it : can be quite dangerous if attach is hanging and we do a kldunload. Then I : don't know what will happen. And we don't want to open that window by making : USB attach always synchronous. Neither should we depend on the EHCI/OHCI/UHCI : hardware to simply eject transfers on dissappeared devices, see three strikes : and you are gone rule. These sound like they might be bugs in newbus. Can you elaborate on the details? Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: CFR: usb switchover patches
In message: 20090220033740.ga...@citylink.fud.org.nz Andrew Thompson thom...@freebsd.org writes: : Hi, : : : I have put together a proposed set of changes for moving USB2 to its : permanent location. The layout has some differences to how it is right : now so I am looking for feedback. : : The changeover requires that the old usb stack be available until 8.0 is : branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason : for this location is to reduce the changes in #includes (using -I : compiler hacks). The patch doesnt show userland changes required for : usbdevs and friends but they will be done. : : Some ports will break. Any that exist solely for the old usb stack can : be marked broken (like udesc_dump). I dont know that the fallout will be : like for the others, maybe portmgr would be interested in doing a build : test. : : The change roughly goes : : svn move sys/dev/usb - sys/legacy/dev/usb : svn move sys/dev/usb2 - sys/dev/usb (with fixups, see below) : : : The patch for the build system can be viewed here, : http://people.freebsd.org/~thompsa/usb_layout/usb_xover.diff : : Now the changes... For starters the '2' will be removed from the : filenames but furthermore I want to flatten dev/usb2/core and : dev/usb2/include into just dev/usb, keeping the peripheral drivers in : their subdirs. Its hard to show with a diff so simply browse the layout : here, http://people.freebsd.org/~thompsa/usb_layout/dev/ : : Please send any minor/nitpick changes to me privately, keeping any list : replies to the overall changes. While I might want to nitpick here, I'm going to refrain from doing so and just say Close enough for my tastes, please go ahead. I could argue that there are a number of inconsistencies with historic practice that this (or the original usb2 commit) introduces, we shouldn't hold up this commit on those grounds. Instead, we should get experience with this layout and look to socialize ideas for a reorg post 8.0 that is more comprehensive in nature. This will give people plenty of time to think about it, and a chance for people with competing ideas to flesh them out. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2+umass: root mount fails
In message: 20090219050200.ga84...@citylink.fud.org.nz Andrew Thompson thom...@freebsd.org writes: : On Tue, Feb 17, 2009 at 08:54:24AM -0700, M. Warner Losh wrote: : In message: 200902170856.11631.hsela...@c2i.net : Hans Petter Selasky hsela...@c2i.net writes: : : On Tuesday 17 February 2009, Marcel Moolenaar wrote: : : But it looks like the old usb code didn't call it either... I think : : old code enumerated right away during boot, while the new code defers : : the enumeration until events can be processed... : : : : Yes, you're right. USB1 used the following: : : : : SYSINIT(usb_cold_explore, SI_SUB_CONFIGURE, SI_ORDER_MIDDLE, : : usb_cold_explore, NULL); : : : : SI_SUB_CONFIGURE didn't complete before all USB busses : : were enumerated. : : : : I would really prefer that first time USB enumeration is not synchronous. This : : has to do with startup timing. It simply wastes a lot of time to wait for all : : the busses to be probed in serial. Sure it works nice with a USB keyboard and : : a USB mouse, but when you have a couple of USB HUBs and +8 devices connected, : : it simply speeds up the boot time so that you reach the root prompt by the : : time you would else have done the mount root mfs. : : : : If the mountroot code cannot find the disk, it should sleep and loop. : : I think this is a weak argument. I'm strongly in favor of the usb1 : behavior here. : : I think its slightly more complex that adding a cold explore task. Most : of the USB2 periperhel drivers defer a portion of their attach to a : thread task, a change which needs to be reverted first. As others have : said both the probe and attach must be synchronous. That's true too. The point I was trying to make wasn't that we needed a cold explore task, but more that usb should know when it is done with the probe phase and then do what other hot-plug busses have started doing. See my recent changes to dev/pccbb for one example. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: HEADSUP: USB2 now default in GENERIC kernels
In message: 20090216165814.d03fd8f1.torfinn.ingolf...@broadpark.no Torfinn Ingolfsen torfinn.ingolf...@broadpark.no writes: : On Sun, 15 Feb 2009 14:41:04 -0800 : Andrew Thompson thom...@freebsd.org wrote: : : The GENERIC kernels for all architectures now default to the new USB2 : stack. : : To avoid confusion: : Is this only for -current (ie RELENG_8)? Or laso for RELENG_7 and / or : other branches? Just for -current. usb2 isn't even in older branches. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2+umass: root mount fails
In message: 741faa3b-b91a-4a23-b47f-21141a8d0...@mac.com Marcel Moolenaar xcl...@mac.com writes: : : On Feb 16, 2009, at 3:13 PM, M. Warner Losh wrote: : : In message: acb7dff1-6c8e-4936-9bd9-bb2fd375f...@mac.com : Marcel Moolenaar xcl...@mac.com writes: : : Before I dig into the code, what's the current status of : : root mounts on USB mass storage devices? : : First, there's a kludge-o-round that is similar to your sleep 10 : that you've added. It loops waiting for more devices to show up if : the desired root file system hasn't appeared yet. : : There's no way for hot-plug busses to tell the kernel I've tried my : best to enumerate everything on my bus, and I'm done : : Of course there is. Any and all USB hubs have a certain : number of ports. You can trivially iterate over all of : them and declare completion when you've tried them all. The hot-plug busses know. The mountroot code doesn't have a way to wait for the hot-plug busses. : Recursion is also not a big deal. When you find a HUB : underneath a port, you iterate over all the ports of : that downstream hub before you declare completion of : the USB discovery process. : : When the USB discovery process is done, you release : the root mount lock... : : So what's the problem? You're looking on the wrong side of the problem. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2+umass: root mount fails
In message: 6e9b5ff6-685b-427c-87a7-c95850da5...@mac.com Marcel Moolenaar xcl...@mac.com writes: : : On Feb 16, 2009, at 4:35 PM, M. Warner Losh wrote: : : In message: 741faa3b-b91a-4a23-b47f-21141a8d0...@mac.com : Marcel Moolenaar xcl...@mac.com writes: : : : : On Feb 16, 2009, at 3:13 PM, M. Warner Losh wrote: : : : : In message: acb7dff1-6c8e-4936-9bd9-bb2fd375f...@mac.com : : Marcel Moolenaar xcl...@mac.com writes: : : : Before I dig into the code, what's the current status of : : : root mounts on USB mass storage devices? : : : : First, there's a kludge-o-round that is similar to your sleep 10 : : that you've added. It loops waiting for more devices to show up : if : : the desired root file system hasn't appeared yet. : : : : There's no way for hot-plug busses to tell the kernel I've : tried my : : best to enumerate everything on my bus, and I'm done : : : : Of course there is. Any and all USB hubs have a certain : : number of ports. You can trivially iterate over all of : : them and declare completion when you've tried them all. : : The hot-plug busses know. The mountroot code doesn't have a way to : wait for the hot-plug busses. : : Huh? : root_mount_hold() and root_mount_rel() are specifically : designed to inform the mountroot code that it needs to : wait (or that it should go ahead and mount root). Those must be new :-) Last time I went looking for these, I found #defines that did nothing... usb2 just needs to use them. And cardbus/pccard event loops too... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2+umass: root mount fails
In message: 6e9b5ff6-685b-427c-87a7-c95850da5...@mac.com Marcel Moolenaar xcl...@mac.com writes: : : On Feb 16, 2009, at 4:35 PM, M. Warner Losh wrote: : : In message: 741faa3b-b91a-4a23-b47f-21141a8d0...@mac.com : Marcel Moolenaar xcl...@mac.com writes: : : : : On Feb 16, 2009, at 3:13 PM, M. Warner Losh wrote: : : : : In message: acb7dff1-6c8e-4936-9bd9-bb2fd375f...@mac.com : : Marcel Moolenaar xcl...@mac.com writes: : : : Before I dig into the code, what's the current status of : : : root mounts on USB mass storage devices? : : : : First, there's a kludge-o-round that is similar to your sleep 10 : : that you've added. It loops waiting for more devices to show up : if : : the desired root file system hasn't appeared yet. : : : : There's no way for hot-plug busses to tell the kernel I've : tried my : : best to enumerate everything on my bus, and I'm done : : : : Of course there is. Any and all USB hubs have a certain : : number of ports. You can trivially iterate over all of : : them and declare completion when you've tried them all. : : The hot-plug busses know. The mountroot code doesn't have a way to : wait for the hot-plug busses. : : Huh? : root_mount_hold() and root_mount_rel() are specifically : designed to inform the mountroot code that it needs to : wait (or that it should go ahead and mount root). r145250 | phk | 2005-04-18 15:21:26 -0600 (Mon, 18 Apr 2005) | 12 lines Add a named reference-count KPI to hold off mounting of the root filesystem. While we wait for holds to be released, print a list of who holds us back once per second. Use the new KPI from GEOM instead of vfs_mount.c calling g_waitidle(). Use the new KPI also from ata. With ATAmkIII's newbusification, ata could narrowly miss the window and ad0 would not exist when we tried to mount root. But it looks like the old usb code didn't call it either... I think old code enumerated right away during boot, while the new code defers the enumeration until events can be processed... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2: umass not detected correctly, axe not transmitting
In message: 20090211225701.gl68...@elvis.mu.org Alfred Perlstein alf...@freebsd.org writes: : * Hans Petter Selasky hsela...@c2i.net [090211 00:52] wrote: : Hi, : : On Wednesday 11 February 2009, Hiroharu Tamaru wrote: : Hi, : : I have an Atom Z530 semi-embedded system and tried the new USB2 stack. : I found some oddities and decided to report here. : : It is running 8.0-CURRENT as of yesterday, and I have GENERIC and USB2 : kernels to test with. I am testing with two usb devices: : : umass0: JetFlash Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2 on : usbus3 axe0: ASIX Electronics AX88178, rev 2.00/0.01, addr 3 on usbus3 : : First about the USB memory stick: : : 1) I setup a bootable USB memory stick, and this system : boots off umass da0 if I have the old USB1 kernel. : However, with USB2 kernel, it does not detect da0 at its final stage, : and fails to find the root filesystem. : I mean that the 'da0 at umass-sim0 bus 0 target 0 lun 0' message is not : shown, and it is not listed in the kernel detected list of disks at : 'mountroot' prompt (shown by typing '?'). : : This is a known issue, see: : : http://wiki.freebsd.org/USB : : Is this the delay in mountroot patch? If so, I think it should go : in. Can you send to Andrew for commit? If he's not available, please : remind me to commit it. That patch needs comments that say it is a workaround because we don't have a way to signal the mountroot code that all my configuration is done. This is a problem for all hot-plug technologies... but other than a comment, I'm cool with that patch going in. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: HEADSUP usb2/usb4bsd to become default in GENERIC
In message: 200902081951.16823.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Sunday 08 February 2009, Andrew Thompson wrote: : On Sun, Feb 08, 2009 at 06:48:39PM +0100, Remko Lodder wrote: : On Sun, February 8, 2009 6:21 am, Alfred Perlstein wrote: : : : Please name it usb_*. : : Beware that if you rename everything from usb2_ to usb_ there will be : symbol and structure clashes with the linux USB compat layer, which needs to : be resolved. No. that's not the case. usb2_foo vs usb_foo in the kernel config files only affects what files config brings in, and we can easily tell it to bring the right ones in w/o any symbol issues. I'd leave everything else where it is now in the source tree. The rename is fairly trivial. Do people want me to float a patch? Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: HEADSUP usb2/usb4bsd to become default in GENERIC
In message: 20090208.124756.-942592244@bsdimp.com M. Warner Losh i...@bsdimp.com writes: : In message: 200902081951.16823.hsela...@c2i.net : Hans Petter Selasky hsela...@c2i.net writes: : : On Sunday 08 February 2009, Andrew Thompson wrote: : : On Sun, Feb 08, 2009 at 06:48:39PM +0100, Remko Lodder wrote: : : On Sun, February 8, 2009 6:21 am, Alfred Perlstein wrote: : : : : : : Please name it usb_*. : : : : Beware that if you rename everything from usb2_ to usb_ there will be : : symbol and structure clashes with the linux USB compat layer, which needs to : : be resolved. : : No. that's not the case. usb2_foo vs usb_foo in the kernel config : files only affects what files config brings in, and we can easily tell : it to bring the right ones in w/o any symbol issues. : : I'd leave everything else where it is now in the source tree. The : rename is fairly trivial. Do people want me to float a patch? Of course, the kernel config file names are just one aspect here. There's also the module names, that need to be considered. And also just because it can be done, doesn't mean we have to it. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: HEADSUP usb2/usb4bsd to become default in GENERIC
In message: f8077156-96ad-4831-9ba9-eee68a2ef...@elvandar.org Remko Lodder re...@elvandar.org writes: : : : I take it the stage (1) is to switch over GENERIC to the new usb2 code : and will not involve renaming the config items. : : stage (2) moves the usb code around in svn and all USB2 kernel config : items will assume their original names, ie. usb2_controller_echi - : ehci. : : I think this is what Alfred was getting about with only changing it : once. : : Andrew : : : That I would like :-) : : thnx for the additional comment :) Also, keep in mind, once Alfred does the hand off, the project will be free to do #2. It really isn't a second change, if you think about it. Just because we change the default, that doesn't force people to use the new default... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: eToken and USB2 (ugen issue?)
In message: 200902071303.53394.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Saturday 07 February 2009, Mike Tancsa wrote: : At 04:36 AM 2/7/2009, Hans Petter Selasky wrote: : Hi Mike, : : The ugen devices are invisible and dynamically created. : : Try open /dev/ugen0.2.0.0 (control endpoint) : : Also you need to re-link your application with : dev/usb2/include/usb2_ioctl.h : : Format is /dev/ugenbus.addr.ifaceindex.endpointno : : I recommend using libusb20 to access your USB device. : : See man libusb20. : : Hi, : Thanks for the response. These are all out of the ports : (openct,opensc). Are there any pointers somewhere on how to best : teach old apps about the new USB2 world on FreeBSD ? : : : Hi Mike, : : Most commonly the following advice helps: : : Add to /etc/libmap.conf: : libusb-0.1.so libusb20.so : libusb-0.1.so.8 libusb20.so.1 : : Also see: : http://wiki.freebsd.org/USB What about for apps that don't use libusb? Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: eToken and USB2 (ugen issue?)
In message: 200902071808.48709.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Saturday 07 February 2009, M. Warner Losh wrote: : In message: 200902071303.53394.hsela...@c2i.net : : Hans Petter Selasky hsela...@c2i.net writes: : : On Saturday 07 February 2009, Mike Tancsa wrote: : : At 04:36 AM 2/7/2009, Hans Petter Selasky wrote: : : Hi Mike, : : : : The ugen devices are invisible and dynamically created. : : : : Try open /dev/ugen0.2.0.0 (control endpoint) : : : : Also you need to re-link your application with : : dev/usb2/include/usb2_ioctl.h : : : : Format is /dev/ugenbus.addr.ifaceindex.endpointno : : : : I recommend using libusb20 to access your USB device. : : : : See man libusb20. : : : : Hi, : : Thanks for the response. These are all out of the ports : : (openct,opensc). Are there any pointers somewhere on how to best : : teach old apps about the new USB2 world on FreeBSD ? : : : : Hi Mike, : : : : Most commonly the following advice helps: : : : : Add to /etc/libmap.conf: : : libusb-0.1.so libusb20.so : : libusb-0.1.so.8 libusb20.so.1 : : : : Also see: : : http://wiki.freebsd.org/USB : : What about for apps that don't use libusb? : : : Hi Warner, : : Applications that use /dev/ugen, needs to be recompiled at least and modified : to open /dev/ugenX.Y.A.B instead of /dev/ugenY.B . Any reason not to provide the old name as an alias to the new? : I recommend people using the libusb or libusb20 API. Using a library makes : porting much easier! That's true. And very cool that it helps enable more technology... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: eToken and USB2 (ugen issue?)
In message: 200902072044.53830.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Saturday 07 February 2009, M. Warner Losh wrote: : : Hi, : : : : : Applications that use /dev/ugen, needs to be recompiled at least and : : modified to open /dev/ugenX.Y.A.B instead of /dev/ugenY.B . : : Any reason not to provide the old name as an alias to the new? : : Technically it will complicate the ugen kernel code. That's a very vague answer.. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: HEADSUP usb2/usb4bsd to become default in GENERIC
Doesn't the busdma issue need to be solved before we do this? usb2 currently doesn't work if you have memory above 4GB due to this issue. I thought we tagged it as a show stopper for making it the default. Warner In message: 20090206045349.gq78...@elvis.mu.org Alfred Perlstein alf...@freebsd.org writes: : Hello -current and -usb. : : We are in the final stages of bringing in the new usb : stack. : : Features include: SMP, better device support, speed increases. : : We hope to make it in for 8.0. It will really take a unified effort : to make this all work and I look forward to all contributors input. : : We have a few large steps ahead of us and I wanted to lay out the : schedule so that people understand what is coming and what to expect. : : At this point we expect there to be no style or changes in usb2 : that are not bugfixes until Phase 3 Hand off. The reason for : this is to prevent bugs from creeping in and allow the maintainer : to focus 100% on bugs and feature parity with the oldusb stack. : : Here is the plan and timeline: : : Phase 1) Make usb2 the default, by enabling it in GENERIC. : : * Sunday 8 Feb 2009 -- Toggle the usb2 knob in GENERIC : : - Add all the usb2 options to NOTES, including commented : documentation about recommended usb2 'sets' of options, : and the usual NOTES-based hints about the options. : : - Update GENERIC to use usb2 device names. : : - Bump __FreeBSD_version and edit UPDATING to note usb2 is now the : default. : : - Verify that it still possible to use the old usb code as a : fallback, until we are ready to detach and remove it from /head : : * Sunday 22 Feb 2009 -- Go through quirks in old-usb code and port : over any remaining bits to usb2 : : - Lock the oldusb code for 2 weeks, until the next usb2 : checkpoint, to verify usb2 is a viable replacement without : having to keep chasing a moving oldusb target. : : Phase 2) Removing the oldusb code. : : * Sunday 15 Mar 2009 -- usb2 bug busting weekend : : - Go through the open usb2 problem reports, and see if there are : any usb2 blocker bugs that need fixing. : : - If the bug hunt shows we are ready to do away with oldusb, : unlink the old usb code from the build, but leave it in for : a few more days. : : * Sunday 22 Mar 2009 -- remove oldusb code. : : - old usb code will be removed. : : Phase 3) Hand-off. : : * Sunday 29 Mar 2009 -- usb2 hand over to src-committers : : - The switch from a private Hans-only repository to the main : subversion tree. : : - At this point, the usb2 is handed over to the src-committers : and Hans has to go through a mentor/committer before committing : changes. : : Thank you! : : -- : - Alfred Perlstein : ___ : freebsd-curr...@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-current : To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org : ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 patches
In message: 200902011123.47690.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : Hi Andrew, : : First of all thanks for helping out. I will spend some time now to go through : your changes. : : One thing about the taskqueue. How does it work? I mean, if multiple events : gets queued on the same handler, how will the events get executed? In : parallell, in serial. I never fully understood that. Serially. If they are the same task that's queued multiple times, you get a count of how many times it was queued to do something useful with. Warner : --HPS : : On Sunday 01 February 2009, Andrew Thompson wrote: : Hi, : : : I have several patches in my svn user branch that I would like to see : committed to HEAD. Some of these change the usb2 core code so I am : interested in feedback or shootdowns. I am right behind the change to : USB2 and this is an effort to help. : : The patch can be found here, : http://people.freebsd.org/~thompsa/usb_head1.diff : 73 files changed, 9229 insertions(+), 13261 deletions(-) : : but its rather large so it may be easier to look at the various changes : via the svn web interface. : : http://svn.freebsd.org/viewvc/base/user/thompsa/usb/ : : : r187750 :http://svn.freebsd.org/viewvc/base?view=revisionrevision=187750 : :Change over to using taskqueue(9) instead of hand rolled threads and :the config_td system. This removes the config_td code and makes the :API much simpler to use. : : r187751, r187752, r187753, r187754, r187755, r187756 :http://svn.freebsd.org/viewvc/base?view=revisionrevision=187751 : :Change over to usb2_proc w/ taskqueues for the usb2/ethernet, :usb2/serial and usb2/wlan code. : : r187965 :http://svn.freebsd.org/viewvc/base?view=revisionrevision=187965 : :Move most of the ifnet logic into the usb2_ethernet module, this : includes, - make all usb ethernet interfaces named ue%d : - handle all threading in usb2_ethernet : - provide default ioctl handler : - handle mbuf rx : - provide locked callbacks for init,start,stop,etc : :The drivers are not much more than data pushers now. : : : regards, : Andrew : : : ___ : freebsd-usb@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-usb : To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org : : ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 patches
In message: 200902011937.32679.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : Hi Warner, : : On Sunday 01 February 2009, M. Warner Losh wrote: : In message: 20090201175021.ga32...@citylink.fud.org.nz : : Andrew Thompson thom...@freebsd.org writes: : : The only way that a 'deferred attach' makes sense is : : if the ifnet and other external resources are setup as part of : that deferred attach. That way, you don't have the NULL pointer issue. : : That was what the initial code did. : : : However, doing that introduces races with devd, which are a pita to : cope with... Even without deferring the setting up if ifnet, you have : races with devd if you defer things in attach that can be hard to cope : with in the code. : : No, not if the ifnet attach is deferred too. : : My conclusion is: Do not make match rules for rumX/uralX/zydX, instead match : for the IFNET event in devd.conf. : : devctl_notify(IFNET, ifp-if_xname, ATTACH, NULL); Yes. We already do that. I was thinking of the geom/device race that we haven't closed rather than this race which we have. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 patches
In message: 20090201191851.ge32...@citylink.fud.org.nz
Andrew Thompson thom...@freebsd.org writes:
: xxx_set_channel()
: {
: ieee80211_channel c = wlan-curchan;
:
: hw_reg = array1[c];
: write USB register;
: hw_reg = array2[c];
: write USB register;
: }
:
: And don't forget volatile ...
:
: I dont understand this. c is a pointer to a valid net80211 channel which
: will never disappear.
volatile would be a bug here. There's no reason to use it at all,
since wlan-curchan doesn't match what ANSI-C says a volatile is for.
In addition, since it is only loaded once, there wouldn't be a need
for it even if it did meet the definition.
You *CANNOT* rely on 'volatile' fixing locking issues.
Warner
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 patches
In message: 200902012031.56899.hsela...@c2i.net
Hans Petter Selasky hsela...@c2i.net writes:
: On Sunday 01 February 2009, Andrew Thompson wrote:
: On Sun, Feb 01, 2009 at 08:01:05PM +0100, Hans Petter Selasky wrote:
: Hi Andrew,
:
: Regarding using taskqueues.
:
: Yes - USB2 can use taskqueues, but I would very much like to have the
: original queueing mechanism intact.
:
: Can you explain this further? What is t0 vs t1?
:
: A taskqueue will execute tasks sequentially,
:
: Hi Andrew,
:
: I've looked in the taskqueue code:
:
: if (task-ta_pending) {
: task-ta_pending++;
: TQ_UNLOCK(queue);
: return 0;
: }
:
: Take the following for example. Now you changed it a little bit, but I see
: similar issues where other commands are involved:
:
: 1) queue DTR on cmd
: 2) queue DTR off cmd
: 3) queue DTR on cmd
This is a bad example. In this case, clearly you'd want to turn it
on, wait for it to go on, wait a while, turn it off, wait for it to go
off, wait a while, then repeat the on part. If you are trying to get
a notch signal in DTR, you have to cope this way. If you are
implementing an ioctl from userland to do this (as exposed by the tty
system), then you'd need to wait for the DTR command to finish anyway
before returning to userland, no?
There's likely other reasons for wanting to do this, but DTR changes
should be synchronous to the caller.
Warner
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 patches
In message: 20090201030628.ge65...@elvis.mu.org Alfred Perlstein alf...@freebsd.org writes: : I'll defer to Hans if he feels confident or not about this. These changes all look good to me : For what it's worth, we're about to switch GENERIC to use : usb4bsd. Moving files or just changing names... Warner : -Alfred : : * Andrew Thompson thom...@freebsd.org [090131 15:20] wrote: : Hi, : : : I have several patches in my svn user branch that I would like to see : committed to HEAD. Some of these change the usb2 core code so I am : interested in feedback or shootdowns. I am right behind the change to : USB2 and this is an effort to help. : : The patch can be found here, : http://people.freebsd.org/~thompsa/usb_head1.diff : 73 files changed, 9229 insertions(+), 13261 deletions(-) : : but its rather large so it may be easier to look at the various changes : via the svn web interface. : : http://svn.freebsd.org/viewvc/base/user/thompsa/usb/ : : : r187750 :http://svn.freebsd.org/viewvc/base?view=revisionrevision=187750 : :Change over to using taskqueue(9) instead of hand rolled threads and :the config_td system. This removes the config_td code and makes the :API much simpler to use. : : r187751, r187752, r187753, r187754, r187755, r187756 :http://svn.freebsd.org/viewvc/base?view=revisionrevision=187751 : :Change over to usb2_proc w/ taskqueues for the usb2/ethernet, :usb2/serial and usb2/wlan code. : : r187965 :http://svn.freebsd.org/viewvc/base?view=revisionrevision=187965 : :Move most of the ifnet logic into the usb2_ethernet module, this includes, : - make all usb ethernet interfaces named ue%d : - handle all threading in usb2_ethernet : - provide default ioctl handler : - handle mbuf rx : - provide locked callbacks for init,start,stop,etc : :The drivers are not much more than data pushers now. : : : regards, : Andrew : : -- : - Alfred Perlstein : ___ : freebsd-usb@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-usb : To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org : : ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB2 patches
In message: 20090201033641.gg65...@elvis.mu.org Alfred Perlstein alf...@freebsd.org writes: : * M. Warner Losh i...@bsdimp.com [090131 19:33] wrote: : In message: 20090201030628.ge65...@elvis.mu.org : Alfred Perlstein alf...@freebsd.org writes: : : I'll defer to Hans if he feels confident or not about this. : : These changes all look good to me : : : For what it's worth, we're about to switch GENERIC to use : : usb4bsd. : : Moving files or just changing names... : : Changing the default kernel configs only. : : A few/several weeks later we will rename over the old if all : goes well. Sounds good. I assume you'll be coordinating with Andrew to make sure that he doesn't have any changes in flight, or can cope with the ones he does? Warner : Warner : : : -Alfred : : : : * Andrew Thompson thom...@freebsd.org [090131 15:20] wrote: : : Hi, : : : : : : I have several patches in my svn user branch that I would like to see : : committed to HEAD. Some of these change the usb2 core code so I am : : interested in feedback or shootdowns. I am right behind the change to : : USB2 and this is an effort to help. : : : : The patch can be found here, : : http://people.freebsd.org/~thompsa/usb_head1.diff : : 73 files changed, 9229 insertions(+), 13261 deletions(-) : : : : but its rather large so it may be easier to look at the various changes : : via the svn web interface. : : : : http://svn.freebsd.org/viewvc/base/user/thompsa/usb/ : : : : : : r187750 : :http://svn.freebsd.org/viewvc/base?view=revisionrevision=187750 : : : :Change over to using taskqueue(9) instead of hand rolled threads and : :the config_td system. This removes the config_td code and makes the : :API much simpler to use. : : : : r187751, r187752, r187753, r187754, r187755, r187756 : :http://svn.freebsd.org/viewvc/base?view=revisionrevision=187751 : : : :Change over to usb2_proc w/ taskqueues for the usb2/ethernet, : :usb2/serial and usb2/wlan code. : : : : r187965 : :http://svn.freebsd.org/viewvc/base?view=revisionrevision=187965 : : : :Move most of the ifnet logic into the usb2_ethernet module, this includes, : : - make all usb ethernet interfaces named ue%d : : - handle all threading in usb2_ethernet : : - provide default ioctl handler : : - handle mbuf rx : : - provide locked callbacks for init,start,stop,etc : : : :The drivers are not much more than data pushers now. : : : : : : regards, : : Andrew : : : : -- : : - Alfred Perlstein : : ___ : : freebsd-usb@freebsd.org mailing list : : http://lists.freebsd.org/mailman/listinfo/freebsd-usb : : To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org : : : : : : -- : - Alfred Perlstein : : ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: xsane busted with usb2
In message: 200901060940.21830.hsela...@c2i.net
Hans Petter Selasky hsela...@c2i.net writes:
: On Tuesday 06 January 2009, M. Warner Losh wrote:
: With sys/dev/usb, I'm able to kldload uscanner and xsane just works.
: With usb2, I klduscanner, and it doesn't. There's no /dev/uscanner0
: in the ls listing, but one can open that file directly. trussing
: sane-find-scanners yields:
:
: ...
: open(/dev/,O_NONBLOCK,020222513) = 4 (0x4)
: fstat(4,{ mode=dr-xr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 (0x0)
: fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0)
: fstatfs(0x4,0x7fffda80,0x0,0x0,0x60,0x801200110) = 0 (0x0)
: getdirentries(0x4,0x80120c000,0x1000,0x80120a0a8,0x30,0x801200158) = 1516
: (0x5ec)
: getdirentries(0x4,0x80120c000,0x1000,0x80120a0a8,0x8064d180,0x7
: fffdd18) = 0 (0x0) lseek(4,0x0,SEEK_SET) = 0
(0x0)
: close(4) = 0 (0x0)
: open(/dev/usb0,O_RDWR,00) ERR#6 'Device not configured'
: open(/dev/usb1,O_RDWR,00) ERR#6 'Device not configured'
: open(/dev/usb2,O_RDWR,00) ERR#6 'Device not configured'
: open(/dev/usb3,O_RDWR,00) ERR#6 'Device not configured'
: open(/dev/usb4,O_RDWR,00) ERR#6 'Device not configured'
: open(/dev/usb5,O_RDWR,00) ERR#6 'Device not configured'
: open(/dev/usb6,O_RDWR,00) ERR#6 'Device not configured'
: open(/dev/usb7,O_RDWR,00) ERR#6 'Device not configured'
: open(/dev/usb8,O_RDWR,00) ERR#6 'Device not configured'
: open(/dev/usb9,O_RDWR,00) ERR#6 'Device not configured'
: write(1, # No USB scanners found. If yo...,79) = 79 (0x4f)
: ...
:
: Is there a fix for this?
:
: Hi,
:
: I looks like xsane is linked with libusb-0.1 . Try re-linking xsane with
: libusb20. Then everything should work.
So I have to rebuild all the programs that use sane? Grump.
Warner
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: xsane busted with usb2
In message: 200901061630.02022.hsela...@c2i.net
Hans Petter Selasky hsela...@c2i.net writes:
: On Tuesday 06 January 2009, M. Warner Losh wrote:
: In message: 200901060940.21830.hsela...@c2i.net
:
: Hans Petter Selasky hsela...@c2i.net writes:
: : On Tuesday 06 January 2009, M. Warner Losh wrote:
: : With sys/dev/usb, I'm able to kldload uscanner and xsane just works.
: : With usb2, I klduscanner, and it doesn't. There's no /dev/uscanner0
: : in the ls listing, but one can open that file directly. trussing
: : sane-find-scanners yields:
: :
: : ...
: : open(/dev/,O_NONBLOCK,020222513) = 4 (0x4)
: : fstat(4,{ mode=dr-xr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 (0x0)
: : fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0)
: : fstatfs(0x4,0x7fffda80,0x0,0x0,0x60,0x801200110) = 0 (0x0)
: : getdirentries(0x4,0x80120c000,0x1000,0x80120a0a8,0x30,0x801200158) =
: : 1516 (0x5ec)
: : getdirentries(0x4,0x80120c000,0x1000,0x80120a0a8,0x8064d180,0x7
: : fffdd18) = 0 (0x0) lseek(4,0x0,SEEK_SET)
= 0 (0x0)
: : close(4) = 0 (0x0)
: : open(/dev/usb0,O_RDWR,00) ERR#6 'Device not
configured'
: : open(/dev/usb1,O_RDWR,00) ERR#6 'Device not
configured'
: : open(/dev/usb2,O_RDWR,00) ERR#6 'Device not
configured'
: : open(/dev/usb3,O_RDWR,00) ERR#6 'Device not
configured'
: : open(/dev/usb4,O_RDWR,00) ERR#6 'Device not
configured'
: : open(/dev/usb5,O_RDWR,00) ERR#6 'Device not
configured'
: : open(/dev/usb6,O_RDWR,00) ERR#6 'Device not
configured'
: : open(/dev/usb7,O_RDWR,00) ERR#6 'Device not
configured'
: : open(/dev/usb8,O_RDWR,00) ERR#6 'Device not
configured'
: : open(/dev/usb9,O_RDWR,00) ERR#6 'Device not
configured'
: : write(1, # No USB scanners found. If yo...,79) = 79 (0x4f)
: : ...
: :
: : Is there a fix for this?
: :
: : Hi,
: :
: : I looks like xsane is linked with libusb-0.1 . Try re-linking xsane with
: : libusb20. Then everything should work.
:
:
: FYI: libusb20 in FreeBSD is binary compatible with libusb-0.1
I built all these things with ports, will just updating the ports fix
them, or will I need to jump through some weird hoops?
Warner
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: bin/129963: [newusb] usbconfig(8) fails with misleading error when run as a normal user
In message: 7d6fde3d0901061110r79333a07jf4eb134224a94...@mail.gmail.com
Garrett Cooper yanef...@gmail.com writes:
: On Tue, Jan 6, 2009 at 10:32 AM, Hans Petter Selasky hsela...@c2i.net wrote:
: On Saturday 03 January 2009, Volker wrote:
: On 01/03/09 01:35, Hans Petter Selasky wrote:
: On Wednesday 31 December 2008, v...@freebsd.org wrote:
: Synopsis: [newusb] usbconfig(8) fails with misleading error when run as
: a normal user
:
: Responsible-Changed-From-To: freebsd-bugs-freebsd-usb
: Responsible-Changed-By: vwe
: Responsible-Changed-When: Wed Dec 31 12:55:52 UTC 2008
: Responsible-Changed-Why:
: reassign
:
: http://www.freebsd.org/cgi/query-pr.cgi?pr=129963
:
: Hi,
:
: usbconfig will only show USB devices which the user has access to.
:
: What should be the correct display message when no devices are accessible
: due to innsufficient permissions?
:
: --HPS
:
: Hans,
:
: what about access denied or insufficient privileges?
:
: Someone might have a better idea but everything should be better than
: silently refusing to do anything.
:
: Volker
:
: Is this Ok:
:
: http://perforce.freebsd.org/chv.cgi?CH=155731
:
: --HPS
:
: Eh? I still think that strerror or something along those lines would
: be more helpful.
:
: You could also do
:
: if (getuid() != 0) {
: errx(1, Cluebat -- you might not be able to read the usb devices
: if you're not root);
: }
:
: or...
:
: struct stat usb_s;
:
: int fd = open(..., O_RDONLY /* blah, blah... */);
:
: if (fd == -1) {
: errx(1, Does the file -- %s -- exist?, file);
: }
:
: if (fstat(fd, usb_s) == -1) {
: errx(1, Couldn't stat the file: %s, file);
: }
:
: if (!S_IRUSR(usb_s.st_mode) !S_IRGRP(usb_s.st_mode)
: !S_IROTH(usb_s.st_mode)) {
: errx(1, File not readable (do you have read permissions?));
: }
:
: /* Continue on merry way reading devices; maybe use strerror(3) for
: more intuitive error messages? */
:
: Thoughts?
Do you really have to be root to find the devices, if so, that's bad.
Very bad. xsane refuses to run as root. I have:
[localrules=10]
add path 'uscanner*' mode 0660
to make it work. /dev/usb* in old usb allow listing w/o privs...
Warner
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: bin/129963: [newusb] usbconfig(8) fails with misleading error when run as a normal user
In message: 200901062103.28124.hsela...@c2i.net
Hans Petter Selasky hsela...@c2i.net writes:
: On Tuesday 06 January 2009, M. Warner Losh wrote:
: In message: 200901062024.31100.hsela...@c2i.net
:
: Hans Petter Selasky hsela...@c2i.net writes:
: : On Tuesday 06 January 2009, M. Warner Losh wrote:
: : In message:
: : 7d6fde3d0901061110r79333a07jf4eb134224a94...@mail.gmail.com
: :
: : Garrett Cooper yanef...@gmail.com writes:
: : : On Tue, Jan 6, 2009 at 10:32 AM, Hans Petter Selasky
: : : hsela...@c2i.net
: :
: : wrote:
: : : On Saturday 03 January 2009, Volker wrote:
: : : On 01/03/09 01:35, Hans Petter Selasky wrote:
: : : On Wednesday 31 December 2008, v...@freebsd.org wrote:
: : : Synopsis: [newusb] usbconfig(8) fails with misleading error
: : : when run as a normal user
: : :
: : : Responsible-Changed-From-To: freebsd-bugs-freebsd-usb
: : : Responsible-Changed-By: vwe
: : : Responsible-Changed-When: Wed Dec 31 12:55:52 UTC 2008
: : : Responsible-Changed-Why:
: : : reassign
: : :
: : : http://www.freebsd.org/cgi/query-pr.cgi?pr=129963
: : :
: : : Hi,
: : :
: : : usbconfig will only show USB devices which the user has access
: : : to.
: : :
: : : What should be the correct display message when no devices are
: : : accessible due to innsufficient permissions?
: : :
: : : --HPS
: : :
: : : Hans,
: : :
: : : what about access denied or insufficient privileges?
: : :
: : : Someone might have a better idea but everything should be better
: : : than silently refusing to do anything.
: : :
: : : Volker
: : :
: : : Is this Ok:
: : :
: : : http://perforce.freebsd.org/chv.cgi?CH=155731
: : :
: : : --HPS
: : :
: : : Eh? I still think that strerror or something along those lines would
: : : be more helpful.
: : :
: : : You could also do
: : :
: : : if (getuid() != 0) {
: : : errx(1, Cluebat -- you might not be able to read the usb devices
: : : if you're not root);
: : : }
: : :
: : : or...
: : :
: : : struct stat usb_s;
: : :
: : : int fd = open(..., O_RDONLY /* blah, blah... */);
: : :
: : : if (fd == -1) {
: : : errx(1, Does the file -- %s -- exist?, file);
: : : }
: : :
: : : if (fstat(fd, usb_s) == -1) {
: : : errx(1, Couldn't stat the file: %s, file);
: : : }
: : :
: : : if (!S_IRUSR(usb_s.st_mode) !S_IRGRP(usb_s.st_mode)
: : : !S_IROTH(usb_s.st_mode)) {
: : : errx(1, File not readable (do you have read permissions?));
: : : }
: : :
: : : /* Continue on merry way reading devices; maybe use strerror(3) for
: : : more intuitive error messages? */
: : :
: : : Thoughts?
: :
: : Do you really have to be root to find the devices, if so, that's bad.
: : Very bad. xsane refuses to run as root. I have:
: :
: : No, no. That's wrong.
: :
: : Do it like this for example:
: :
: : usbconfig -u xxx -a xxx set_owner xxx set_perm 660
: :
: : This won't have no effect at all with USB2:
: : [localrules=10]
: : add path 'uscanner*' mode 0660
: :
: : to make it work. /dev/usb* in old usb allow listing w/o privs...
:
: That's bad. I'm sorry, but having to do something weird to get the
: scanner to work every time isn't good design.
:
: I don't understand. If you are lazy you do:
It has to do with providing a consistent interface to the user...
: usbconfig -u xxx set_perm 777
:
: That will give everyone access to all USB devices on the given controller -u
: xxx. Note: No -a argument.
:
: Or:
:
: usbconfig set_owner warner:wheel set_perm 660
:
: All USB devices ever plugged on your machine will be accessible by you.
:
: I think Rink Springer is working on something in this area.
Great! I look forward to the rework...
Warner
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: bin/129963: [newusb] usbconfig(8) fails with misleading error when run as a normal user
In message: 4963c48b.9030...@elischer.org Julian Elischer jul...@elischer.org writes: : Hans Petter Selasky wrote: : On Tuesday 06 January 2009, M. Warner Losh wrote: : In message: 200901062024.31100.hsela...@c2i.net : : Do it like this for example: : : : : usbconfig -u xxx -a xxx set_owner xxx set_perm 660 : : : : This won't have no effect at all with USB2: : : [localrules=10] : : add path 'uscanner*' mode 0660 : : : : to make it work. /dev/usb* in old usb allow listing w/o privs... : : That's bad. I'm sorry, but having to do something weird to get the : scanner to work every time isn't good design. : : I don't understand. If you are lazy you do: : : usbconfig -u xxx set_perm 777 : : how about using the standard devd stuff? You mean devfs. : why invent a completely new way of doing things for USB? Exactly my point. I can paper over this with devd, but that's really not a good way to roll long term. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/130122: [hpsusb] DVD drive detects as 'da' device
In message: 200901030028.38064.hsela...@c2i.net
Hans Petter Selasky hsela...@c2i.net writes:
: On Friday 02 January 2009, M. Warner Losh wrote:
: In message: 200901022123.57193.hsela...@c2i.net
:
: Hans Petter Selasky hsela...@c2i.net writes:
: : On Friday 02 January 2009, M. Warner Losh wrote:
: : Number: 130122
: : Category: usb
: : Synopsis: [hpsusb] DVD drive detects as 'da' device
: : Confidential: no
: : Severity: serious
: : Priority: medium
: : Responsible:freebsd-usb
: : State: open
: : Quarter:
: : Keywords:
: : Date-Required:
: : Class: sw-bug
: : Submitter-Id: current-users
: : Arrival-Date: Fri Jan 02 19:30:04 UTC 2009
: : Closed-Date:
: : Last-Modified:
: : Originator: M. Warner Losh
: : Release:FreeBSD 8.0-CURRENT amd64
: : Organization:
: :
: : FreeBSD
: :
: : Environment:
: :
: : System: FreeBSD lighthouse 8.0-CURRENT FreeBSD 8.0-CURRENT #0
: : r185338:186501M: Fri Dec 26 17:56:39 MST 2008
: : i...@lighthouse:/tmp/imp/obj/cache/svn/head/sys/LIGHTHOUSE amd64
: :
: : Description:
: :
: : My externeal usb DVD drive is showing up as 'da' rather than as 'cd'
: : when using usb2_storage_mass. When I load usb2_storage_ata it shows
: : up as a 'cd' device that's usable. mass should behave as well as ata
: : in this case, or it should detect that it can't get it right and
: : refuse to attach things.
: :
: : How-To-Repeat:
: :
: : I loaded all the usb2 drivers at runtime:
: :
: : kldload usb2_controller_{e,o}hci
: : kldload usb2_sotrage_mass
: :
: : I then plugged in the drive. This is an external DVD drive.
: :
: : ehci0: ATI SB400 USB 2.0 controller mem 0xc0002000-0xc0002fff irq 19
: : at device 19.2 on pci0 ehci0: memory enable already set.
: : Activate PA 0xc0002000 at VA 0xff00c0002000
: : ehci0: [ITHREAD]
: : usbus0: EHCI version 1.0
: : usbus0: ATI SB400 USB 2.0 controller on ehci0
: : usbus0: 480Mbps High Speed USB v2.0
: : ugen0.1: ATI at usbus0
: : ushub0: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0
: : ushub0: 8 ports with 8 removable, self powered
: : ohci0: ATI SB400 USB Controller mem 0xc000-0xcfff irq 19 at
: : device 19.0 on pci0 ohci0: memory enable already set.
: : Activate PA 0xc000 at VA 0xff00c000
: : ohci0: [ITHREAD]
: : usbus1: ATI SB400 USB Controller on ohci0
: : usbus1: 12Mbps Full Speed USB v1.0
: : ugen1.1: ATI at usbus1
: : ushub1: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1
: : ushub1: 4 ports with 4 removable, self powered
: : ohci1: ATI SB400 USB Controller mem 0xc0001000-0xc0001fff irq 19 at
: : device 19.1 on pci0 ohci1: memory enable already set.
: : Activate PA 0xc0001000 at VA 0xff00c0001000
: : ohci1: [ITHREAD]
: : usbus2: ATI SB400 USB Controller on ohci1
: : usbus2: 12Mbps Full Speed USB v1.0
: : ugen2.1: ATI at usbus2
: : ushub2: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2
: : ushub2: 4 ports with 4 removable, self powered
: : ugen0.2: Myson Century, Inc. at usbus0
: : umass0: Mass Storage Class on usbus0
: : umass0: SCSI over Bulk-Only; quirks = 0x0480
: : umass0:2:0:-1: Attached to scbus2
: : da0 at umass-sim0 bus 0 target 0 lun 0
: : da0:Removable Direct Access SCSI-2 device
: : da0: 40.000MB/s transfers
: : da0: Attempt to query device size failed: NOT READY, Medium not present
: :
: : It should be 'cd1'.
: :
: : Fix:
: :
: : Unknown.
: :
: : Release-Note:
: : Audit-Trail:
: : Unformatted:
: :
: : Hi,
: :
: : Maybe the AutoInstall CD detecter is interfering with your device.
:
: Hmmm...
:
: : Can you use usbconfig to dump the device and config descriptors of your
: : CD device?
:
: How?
:
: Run usbconfig -h.
That doesn't tell me enough to know what you need to diagnose this
problem.
: usbconfig -u xxx -a yyy dump_curr_config_desc
: usbconfig -u xxx -a yyy dump_device_desc
How do I now the address? Is it the .Y in ugenX.Y?
If so, here's what you requested:
ugen0.3: USB Mass Storage Device Myson Century, Inc. at usbus0, cfg=0 md=HOST
spd=HIGH (480Mbps) pwr=ON
Configuration index 0
bLength = 0x0009
bDescriptorType = 0x0002
wTotalLength = 0x0020
bNumInterfaces = 0x0001
bConfigurationValue = 0x0001
iConfiguration = 0x0004 USB Mass Storage
bmAttributes = 0x00c0
bMaxPower = 0x0005
Interface 0
bLength = 0x0009
bDescriptorType = 0x0004
bInterfaceNumber = 0x
bAlternateSetting = 0x
bNumEndpoints = 0x0002
bInterfaceClass = 0x0008
bInterfaceSubClass = 0x0005
bInterfaceProtocol = 0x0050
iInterface = 0x0005 Mass Storage Class
Endpoint 0
bLength = 0x0007
bDescriptorType = 0x0005
bEndpointAddress = 0x0003
bmAttributes = 0x0002
Re: usb/130122: [hpsusb] DVD drive detects as 'da' device
The following reply was made to PR usb/130122; it has been noted by GNATS.
From: M. Warner Losh i...@bsdimp.com
To: hsela...@c2i.net
Cc: freebsd-usb@freebsd.org, freebsd-gnats-sub...@freebsd.org
Subject: Re: usb/130122: [hpsusb] DVD drive detects as 'da' device
Date: Sat, 03 Jan 2009 12:29:38 -0700 (MST)
In message: 200901030028.38064.hsela...@c2i.net
Hans Petter Selasky hsela...@c2i.net writes:
: On Friday 02 January 2009, M. Warner Losh wrote:
: In message: 200901022123.57193.hsela...@c2i.net
:
: Hans Petter Selasky hsela...@c2i.net writes:
: : On Friday 02 January 2009, M. Warner Losh wrote:
: : Number: 130122
: : Category: usb
: : Synopsis: [hpsusb] DVD drive detects as 'da' device
: : Confidential: no
: : Severity: serious
: : Priority: medium
: : Responsible:freebsd-usb
: : State: open
: : Quarter:
: : Keywords:
: : Date-Required:
: : Class: sw-bug
: : Submitter-Id: current-users
: : Arrival-Date: Fri Jan 02 19:30:04 UTC 2009
: : Closed-Date:
: : Last-Modified:
: : Originator: M. Warner Losh
: : Release:FreeBSD 8.0-CURRENT amd64
: : Organization:
: :
: : FreeBSD
: :
: : Environment:
: :
: : System: FreeBSD lighthouse 8.0-CURRENT FreeBSD 8.0-CURRENT #0
: : r185338:186501M: Fri Dec 26 17:56:39 MST 2008
: : i...@lighthouse:/tmp/imp/obj/cache/svn/head/sys/LIGHTHOUSE amd64
: :
: : Description:
: :
: : My externeal usb DVD drive is showing up as 'da' rather than as 'cd'
: : when using usb2_storage_mass. When I load usb2_storage_ata it shows
: : up as a 'cd' device that's usable. mass should behave as well as ata
: : in this case, or it should detect that it can't get it right and
: : refuse to attach things.
: :
: : How-To-Repeat:
: :
: : I loaded all the usb2 drivers at runtime:
: :
: : kldload usb2_controller_{e,o}hci
: : kldload usb2_sotrage_mass
: :
: : I then plugged in the drive. This is an external DVD drive.
: :
: : ehci0: ATI SB400 USB 2.0 controller mem 0xc0002000-0xc0002fff irq 19
: : at device 19.2 on pci0 ehci0: memory enable already set.
: : Activate PA 0xc0002000 at VA 0xff00c0002000
: : ehci0: [ITHREAD]
: : usbus0: EHCI version 1.0
: : usbus0: ATI SB400 USB 2.0 controller on ehci0
: : usbus0: 480Mbps High Speed USB v2.0
: : ugen0.1: ATI at usbus0
: : ushub0: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0
: : ushub0: 8 ports with 8 removable, self powered
: : ohci0: ATI SB400 USB Controller mem 0xc000-0xcfff irq 19 at
: : device 19.0 on pci0 ohci0: memory enable already set.
: : Activate PA 0xc000 at VA 0xff00c000
: : ohci0: [ITHREAD]
: : usbus1: ATI SB400 USB Controller on ohci0
: : usbus1: 12Mbps Full Speed USB v1.0
: : ugen1.1: ATI at usbus1
: : ushub1: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1
: : ushub1: 4 ports with 4 removable, self powered
: : ohci1: ATI SB400 USB Controller mem 0xc0001000-0xc0001fff irq 19 at
: : device 19.1 on pci0 ohci1: memory enable already set.
: : Activate PA 0xc0001000 at VA 0xff00c0001000
: : ohci1: [ITHREAD]
: : usbus2: ATI SB400 USB Controller on ohci1
: : usbus2: 12Mbps Full Speed USB v1.0
: : ugen2.1: ATI at usbus2
: : ushub2: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2
: : ushub2: 4 ports with 4 removable, self powered
: : ugen0.2: Myson Century, Inc. at usbus0
: : umass0: Mass Storage Class on usbus0
: : umass0: SCSI over Bulk-Only; quirks = 0x0480
: : umass0:2:0:-1: Attached to scbus2
: : da0 at umass-sim0 bus 0 target 0 lun 0
: : da0:Removable Direct Access SCSI-2 device
: : da0: 40.000MB/s transfers
: : da0: Attempt to query device size failed: NOT READY, Medium not present
: :
: : It should be 'cd1'.
: :
: : Fix:
: :
: : Unknown.
: :
: : Release-Note:
: : Audit-Trail:
: : Unformatted:
: :
: : Hi,
: :
: : Maybe the AutoInstall CD detecter is interfering with your device.
:
: Hmmm...
:
: : Can you use usbconfig to dump the device and config descriptors of your
: : CD device?
:
: How?
:
: Run usbconfig -h.
That doesn't tell me enough to know what you need to diagnose this
problem.
: usbconfig -u xxx -a yyy dump_curr_config_desc
: usbconfig -u xxx -a yyy dump_device_desc
How do I now the address? Is it the .Y in ugenX.Y?
If so, here's what you requested:
ugen0.3: USB Mass Storage Device Myson Century, Inc. at usbus0, cfg=0
md=HOST spd=HIGH (480Mbps) pwr=ON
Configuration index 0
bLength = 0x0009
bDescriptorType = 0x0002
wTotalLength = 0x0020
bNumInterfaces = 0x0001
bConfigurationValue = 0x0001
iConfiguration = 0x0004 USB Mass Storage
bmAttributes = 0x00c0
bMaxPower = 0x0005
Interface 0
usb/130122: [hpsusb] DVD drive detects as 'da' device
Number: 130122
Category: usb
Synopsis: [hpsusb] DVD drive detects as 'da' device
Confidential: no
Severity: serious
Priority: medium
Responsible:freebsd-usb
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Fri Jan 02 19:30:04 UTC 2009
Closed-Date:
Last-Modified:
Originator: M. Warner Losh
Release:FreeBSD 8.0-CURRENT amd64
Organization:
FreeBSD
Environment:
System: FreeBSD lighthouse 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r185338:186501M:
Fri Dec 26 17:56:39 MST 2008
i...@lighthouse:/tmp/imp/obj/cache/svn/head/sys/LIGHTHOUSE amd64
Description:
My externeal usb DVD drive is showing up as 'da' rather than as 'cd'
when using usb2_storage_mass. When I load usb2_storage_ata it shows
up as a 'cd' device that's usable. mass should behave as well as ata
in this case, or it should detect that it can't get it right and
refuse to attach things.
How-To-Repeat:
I loaded all the usb2 drivers at runtime:
kldload usb2_controller_{e,o}hci
kldload usb2_sotrage_mass
I then plugged in the drive. This is an external DVD drive.
ehci0: ATI SB400 USB 2.0 controller mem 0xc0002000-0xc0002fff irq 19 at
device 19.2 on pci0
ehci0: memory enable already set.
Activate PA 0xc0002000 at VA 0xff00c0002000
ehci0: [ITHREAD]
usbus0: EHCI version 1.0
usbus0: ATI SB400 USB 2.0 controller on ehci0
usbus0: 480Mbps High Speed USB v2.0
ugen0.1: ATI at usbus0
ushub0: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0
ushub0: 8 ports with 8 removable, self powered
ohci0: ATI SB400 USB Controller mem 0xc000-0xcfff irq 19 at device
19.0 on pci0
ohci0: memory enable already set.
Activate PA 0xc000 at VA 0xff00c000
ohci0: [ITHREAD]
usbus1: ATI SB400 USB Controller on ohci0
usbus1: 12Mbps Full Speed USB v1.0
ugen1.1: ATI at usbus1
ushub1: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1
ushub1: 4 ports with 4 removable, self powered
ohci1: ATI SB400 USB Controller mem 0xc0001000-0xc0001fff irq 19 at device
19.1 on pci0
ohci1: memory enable already set.
Activate PA 0xc0001000 at VA 0xff00c0001000
ohci1: [ITHREAD]
usbus2: ATI SB400 USB Controller on ohci1
usbus2: 12Mbps Full Speed USB v1.0
ugen2.1: ATI at usbus2
ushub2: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2
ushub2: 4 ports with 4 removable, self powered
ugen0.2: Myson Century, Inc. at usbus0
umass0: Mass Storage Class on usbus0
umass0: SCSI over Bulk-Only; quirks = 0x0480
umass0:2:0:-1: Attached to scbus2
da0 at umass-sim0 bus 0 target 0 lun 0
da0:Removable Direct Access SCSI-2 device
da0: 40.000MB/s transfers
da0: Attempt to query device size failed: NOT READY, Medium not present
It should be 'cd1'.
Fix:
Unknown.
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/130122: [hpsusb] DVD drive detects as 'da' device
In message: 200901022123.57193.hsela...@c2i.net
Hans Petter Selasky hsela...@c2i.net writes:
: On Friday 02 January 2009, M. Warner Losh wrote:
: Number: 130122
: Category: usb
: Synopsis: [hpsusb] DVD drive detects as 'da' device
: Confidential: no
: Severity: serious
: Priority: medium
: Responsible:freebsd-usb
: State: open
: Quarter:
: Keywords:
: Date-Required:
: Class: sw-bug
: Submitter-Id: current-users
: Arrival-Date: Fri Jan 02 19:30:04 UTC 2009
: Closed-Date:
: Last-Modified:
: Originator: M. Warner Losh
: Release:FreeBSD 8.0-CURRENT amd64
: Organization:
:
: FreeBSD
:
: Environment:
:
: System: FreeBSD lighthouse 8.0-CURRENT FreeBSD 8.0-CURRENT #0
: r185338:186501M: Fri Dec 26 17:56:39 MST 2008
: i...@lighthouse:/tmp/imp/obj/cache/svn/head/sys/LIGHTHOUSE amd64
:
: Description:
:
: My externeal usb DVD drive is showing up as 'da' rather than as 'cd'
: when using usb2_storage_mass. When I load usb2_storage_ata it shows
: up as a 'cd' device that's usable. mass should behave as well as ata
: in this case, or it should detect that it can't get it right and
: refuse to attach things.
:
: How-To-Repeat:
:
: I loaded all the usb2 drivers at runtime:
:
: kldload usb2_controller_{e,o}hci
: kldload usb2_sotrage_mass
:
: I then plugged in the drive. This is an external DVD drive.
:
: ehci0: ATI SB400 USB 2.0 controller mem 0xc0002000-0xc0002fff irq 19 at
: device 19.2 on pci0 ehci0: memory enable already set.
: Activate PA 0xc0002000 at VA 0xff00c0002000
: ehci0: [ITHREAD]
: usbus0: EHCI version 1.0
: usbus0: ATI SB400 USB 2.0 controller on ehci0
: usbus0: 480Mbps High Speed USB v2.0
: ugen0.1: ATI at usbus0
: ushub0: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0
: ushub0: 8 ports with 8 removable, self powered
: ohci0: ATI SB400 USB Controller mem 0xc000-0xcfff irq 19 at
: device 19.0 on pci0 ohci0: memory enable already set.
: Activate PA 0xc000 at VA 0xff00c000
: ohci0: [ITHREAD]
: usbus1: ATI SB400 USB Controller on ohci0
: usbus1: 12Mbps Full Speed USB v1.0
: ugen1.1: ATI at usbus1
: ushub1: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1
: ushub1: 4 ports with 4 removable, self powered
: ohci1: ATI SB400 USB Controller mem 0xc0001000-0xc0001fff irq 19 at
: device 19.1 on pci0 ohci1: memory enable already set.
: Activate PA 0xc0001000 at VA 0xff00c0001000
: ohci1: [ITHREAD]
: usbus2: ATI SB400 USB Controller on ohci1
: usbus2: 12Mbps Full Speed USB v1.0
: ugen2.1: ATI at usbus2
: ushub2: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2
: ushub2: 4 ports with 4 removable, self powered
: ugen0.2: Myson Century, Inc. at usbus0
: umass0: Mass Storage Class on usbus0
: umass0: SCSI over Bulk-Only; quirks = 0x0480
: umass0:2:0:-1: Attached to scbus2
: da0 at umass-sim0 bus 0 target 0 lun 0
: da0:Removable Direct Access SCSI-2 device
: da0: 40.000MB/s transfers
: da0: Attempt to query device size failed: NOT READY, Medium not present
:
: It should be 'cd1'.
:
: Fix:
:
: Unknown.
:
: Release-Note:
: Audit-Trail:
: Unformatted:
:
: Hi,
:
: Maybe the AutoInstall CD detecter is interfering with your device.
Hmmm...
: Can you use usbconfig to dump the device and config descriptors of your CD
: device?
How?
: You can also try:
:
: kldload usb2_quirk
: usbconfig add_dev_quirk_vplh vid pid lo_rev hi_rev UQ_CFG_INDEX_0
What the heck are these different fields? vid, pid, etc?
Warner
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/130122: [hpsusb] DVD drive detects as 'da' device
The following reply was made to PR usb/130122; it has been noted by GNATS.
From: M. Warner Losh i...@bsdimp.com
To: hsela...@c2i.net
Cc: freebsd-usb@FreeBSD.org, freebsd-gnats-sub...@freebsd.org
Subject: Re: usb/130122: [hpsusb] DVD drive detects as 'da' device
Date: Fri, 02 Jan 2009 15:15:01 -0700 (MST)
In message: 200901022123.57193.hsela...@c2i.net
Hans Petter Selasky hsela...@c2i.net writes:
: On Friday 02 January 2009, M. Warner Losh wrote:
: Number: 130122
: Category: usb
: Synopsis: [hpsusb] DVD drive detects as 'da' device
: Confidential: no
: Severity: serious
: Priority: medium
: Responsible:freebsd-usb
: State: open
: Quarter:
: Keywords:
: Date-Required:
: Class: sw-bug
: Submitter-Id: current-users
: Arrival-Date: Fri Jan 02 19:30:04 UTC 2009
: Closed-Date:
: Last-Modified:
: Originator: M. Warner Losh
: Release:FreeBSD 8.0-CURRENT amd64
: Organization:
:
: FreeBSD
:
: Environment:
:
: System: FreeBSD lighthouse 8.0-CURRENT FreeBSD 8.0-CURRENT #0
: r185338:186501M: Fri Dec 26 17:56:39 MST 2008
: i...@lighthouse:/tmp/imp/obj/cache/svn/head/sys/LIGHTHOUSE amd64
:
: Description:
:
: My externeal usb DVD drive is showing up as 'da' rather than as 'cd'
: when using usb2_storage_mass. When I load usb2_storage_ata it shows
: up as a 'cd' device that's usable. mass should behave as well as ata
: in this case, or it should detect that it can't get it right and
: refuse to attach things.
:
: How-To-Repeat:
:
: I loaded all the usb2 drivers at runtime:
:
: kldload usb2_controller_{e,o}hci
: kldload usb2_sotrage_mass
:
: I then plugged in the drive. This is an external DVD drive.
:
: ehci0: ATI SB400 USB 2.0 controller mem 0xc0002000-0xc0002fff irq 19 at
: device 19.2 on pci0 ehci0: memory enable already set.
: Activate PA 0xc0002000 at VA 0xff00c0002000
: ehci0: [ITHREAD]
: usbus0: EHCI version 1.0
: usbus0: ATI SB400 USB 2.0 controller on ehci0
: usbus0: 480Mbps High Speed USB v2.0
: ugen0.1: ATI at usbus0
: ushub0: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0
: ushub0: 8 ports with 8 removable, self powered
: ohci0: ATI SB400 USB Controller mem 0xc000-0xcfff irq 19 at
: device 19.0 on pci0 ohci0: memory enable already set.
: Activate PA 0xc000 at VA 0xff00c000
: ohci0: [ITHREAD]
: usbus1: ATI SB400 USB Controller on ohci0
: usbus1: 12Mbps Full Speed USB v1.0
: ugen1.1: ATI at usbus1
: ushub1: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1
: ushub1: 4 ports with 4 removable, self powered
: ohci1: ATI SB400 USB Controller mem 0xc0001000-0xc0001fff irq 19 at
: device 19.1 on pci0 ohci1: memory enable already set.
: Activate PA 0xc0001000 at VA 0xff00c0001000
: ohci1: [ITHREAD]
: usbus2: ATI SB400 USB Controller on ohci1
: usbus2: 12Mbps Full Speed USB v1.0
: ugen2.1: ATI at usbus2
: ushub2: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2
: ushub2: 4 ports with 4 removable, self powered
: ugen0.2: Myson Century, Inc. at usbus0
: umass0: Mass Storage Class on usbus0
: umass0: SCSI over Bulk-Only; quirks = 0x0480
: umass0:2:0:-1: Attached to scbus2
: da0 at umass-sim0 bus 0 target 0 lun 0
: da0:Removable Direct Access SCSI-2 device
: da0: 40.000MB/s transfers
: da0: Attempt to query device size failed: NOT READY, Medium not present
:
: It should be 'cd1'.
:
: Fix:
:
: Unknown.
:
: Release-Note:
: Audit-Trail:
: Unformatted:
:
: Hi,
:
: Maybe the AutoInstall CD detecter is interfering with your device.
Hmmm...
: Can you use usbconfig to dump the device and config descriptors of your CD
: device?
How?
: You can also try:
:
: kldload usb2_quirk
: usbconfig add_dev_quirk_vplh vid pid lo_rev hi_rev UQ_CFG_INDEX_0
What the heck are these different fields? vid, pid, etc?
Warner
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/130066: [newusb] Serial adaptor use fail with 'unsupported speed XXX'
In message: 200901030132.03840.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : This issue is cause by an IOCTL returning ENOTTY instead of ENOIOCTL. I think I fixed this in usb1 not too long ago. It was introduced in the mpsafetty conversion... Well, exposed might be a better word... : I will be fixed shortly. I'm sorry to hear that... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/130066: [newusb] Serial adaptor use fail with 'unsupported speed XXX'
The following reply was made to PR usb/130066; it has been noted by GNATS. From: M. Warner Losh i...@bsdimp.com To: hsela...@c2i.net Cc: freebsd-usb@FreeBSD.org, si...@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: usb/130066: [newusb] Serial adaptor use fail with 'unsupported speed XXX' Date: Fri, 02 Jan 2009 23:06:05 -0700 (MST) In message: 200901030132.03840.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : This issue is cause by an IOCTL returning ENOTTY instead of ENOIOCTL. I think I fixed this in usb1 not too long ago. It was introduced in the mpsafetty conversion... Well, exposed might be a better word... : I will be fixed shortly. I'm sorry to hear that... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: ucom serial bug?
In message: [EMAIL PROTECTED]
Gabor [EMAIL PROTECTED] writes:
: Hi,
:
: thanks for looking at this issue. Are you guys saying that this was not
meant to work? As in I shouldn't expect to see carrier?
Ian Lepore sent me this patch a little while ago. I've not had time
to look into it. If you could test it and let me know, then I'll be
able to commit it more quickly. It is against a slightly hacked
version of 6.1, but should translate right over.
Warner
Index: uftdi.c
===
RCS file: /base/FreeBSD-tsc-6/sys/dev/usb/uftdi.c,v
retrieving revision 1.2
diff -u -r1.2 uftdi.c
--- uftdi.c 24 Sep 2007 21:37:33 - 1.2
+++ uftdi.c 14 Nov 2008 18:17:02 -
@@ -457,13 +457,24 @@
{
struct uftdi_softc *sc = vsc;
u_char msr, lsr;
+ u_char ftdi_msr;
DPRINTFN(15,(uftdi_read: sc=%p, port=%d count=%d\n, sc, portno,
*count));
- msr = FTDI_GET_MSR(*ptr);
+ ftdi_msr = FTDI_GET_MSR(*ptr);
lsr = FTDI_GET_LSR(*ptr);
+ msr = 0;
+ if (ftdi_msr FTDI_SIO_CTS_MASK)
+ msr |= SER_CTS;
+ if (ftdi_msr FTDI_SIO_DSR_MASK)
+ msr |= SER_DSR;
+ if (ftdi_msr FTDI_SIO_RI_MASK)
+ msr |= SER_RI;
+ if (ftdi_msr FTDI_SIO_RLSD_MASK)
+ msr |= SER_DCD;
+
#ifdef USB_DEBUG
if (*count != 2)
DPRINTFN(10,(uftdi_read: sc=%p, port=%d count=%d data[0]=
:
: On 12/4/08 1:15 PM, M. Warner Losh wrote:
: In message: [EMAIL PROTECTED]
: Hans Petter Selasky [EMAIL PROTECTED] writes:
: : On Thursday 04 December 2008, Mike Tancsa wrote:
: : At 02:33 PM 12/3/2008, Gabor wrote:
: : everything works fine. When we try to use a USB to serial
: : converter(type doesn't matter, UFTDI or Prolific) we run into
: : problems. The first time we start up our side, everything
: : works. The second time we don't get carrier(DCD). The other side
: : is always running. Since we have no control
: :
: : Also tried with the usb2 development stack, and we never see carrier.
: :
: : Id Refs AddressSize Name
: :1 20 0xc040 9f8014 kernel (/boot/kernel/kernel)
: :21 0xc4b95000 3000 usb2_serial_ftdi.ko
: : (/boot/kernel/usb2_serial_ftdi.ko)
: :35 0xc4b99000 36000usb2_core.ko (/boot/kernel/usb2_core.ko)
: :41 0xc4c56000 4000 usb2_serial.ko
(/boot/kernel/usb2_serial.ko)
: :51 0xc4cb4000 a000 usb2_controller_uhci.ko
: : (/boot/kernel/usb2_controller_uhci.ko)
: :62 0xc4cbe000 3000 usb2_controller.ko
: : (/boot/kernel/usb2_controller.ko)
: :71 0xc4d5 d000 usb2_controller_ehci.ko
: : (/boot/kernel/usb2_controller_ehci.ko)
: :
: :
: : Hi,
: :
: : I think this event is not implemented in the driver. Try to diff the
NetBSD
: : and FreeBSD uftdi.c files.
:
: I have some diffs in my inbox from someone that was trying to
: implement modem control for uftdi chips. Let me see if they make
: sense...
:
: Warner
: ___
: freebsd-usb@freebsd.org mailing list
: http://lists.freebsd.org/mailman/listinfo/freebsd-usb
: To unsubscribe, send any mail to [EMAIL PROTECTED]
:
:
: --
: Success is the result when preparation meets opportunity.
: ___
: 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: Device IDs for HP hs2300 HSDPA modem
In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : I think SVN is more up to date. Just give it some time and CVS will : be updated aswell. The lag between these two is measure in minutes, at most If that isn't the case, we need to know... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Serious] busdma bug in -current in relation to USB hardware - review wanted
In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : Hi, : : It turns out my initial patch need to be limited to the use-case only. Before : I start any real work, I want to know if anyone will object if I implement : the following new BUS_DMA flag into FreeBSD's busdma system? : : amd64/amd64/busdma_machdep.c : i386/i386/busdma_machdep.c : arm/arm/busdma_machdep.c : ia64/ia64/busdma_machdep.c : mips/mips/busdma_machdep.c : powerpc/powerpc/busdma_machdep.c : sparc64/sparc64/bus_machdep.c : sun4v/sun4v/bus_machdep.c : sys/bus_dma.h : : /* : * The following flag specifies that no re-alignment of individual : * memory pages is allowed when loaded into DMA. It can only be used : * when maxsegsz is equal to PAGE_SIZE and alignment is less : * than or equal to 1. : * : * Background: Some kinds of DMA hardware only stores the full : * physical address of the first memory page when multiple memory : * pages are loaded into DMA. Consequtive memory pages only gets the : * non-offset part of the physical address updated. The hardware : * computes the amount of data that should be stored in the first : * memory page from the minimum of the total transfer length and : * PAGE_SIZE minus the initial page offset. When the initial page : * offset is not preserved the hardware ends up transferring an : * invalid number of bytes to or from the initial memory page. : */ : #define BUS_DMA_NOREAL 0x400 /* no page re-alignment allowed */ : : : : Without this new feature in busdma the USB hardware will not work when the DMA : data is placed on bounce pages, for example on 64-bit architectures with more : than 4GB of RAM. I'm having trouble understanding the need for this patch. Can you provide a patch to usb2 to use it as well as doing one of the implementations (say i386 or amd64) so that it is easier to judge the problem it is trying to solve? Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB4BSD release candidate number 3 - request for review
In message: [EMAIL PROTECTED] Paul B. Mahol [EMAIL PROTECTED] writes: : On 11/7/08, Paul B. Mahol [EMAIL PROTECTED] wrote: : On 11/7/08, Paul B. Mahol [EMAIL PROTECTED] wrote: : On recent CURRENT when attaching rum card, strange bug appear: : : usb2_alloc_device:1417: set address 2 failed (ignored) : usb2_alloc_device:1452: getting device descriptor at addr 2 failed! : uhub_reattach_port:401: could not allocate new device! : : uhub_reattach_port:355: port 5 reset failed, error=USB_ERR_TIMEOUT : uhub_reattach_port:421: device problem (USB_ERR_TIMEOUT), disabling port 5 : uhub_reattach_port:370: giving up port reset - device vanished! : uhub_reattach_port:370: giving up port reset - device vanished! : uhub_reattach_port:370: giving up port reset - device vanished! : uhub_reattach_port:370: giving up port reset - device vanished! : uhub_reattach_port:370: giving up port reset - device vanished! : uhub_reattach_port:370: giving up port reset - device vanished! : uhub_reattach_port:370: giving up port reset - device vanished! : uhub_reattach_port:370: giving up port reset - device vanished! : uhub_reattach_port:355: port 5 reset failed, error=USB_ERR_TIMEOUT : uhub_reattach_port:421: device problem (USB_ERR_TIMEOUT), disabling port 5 : uhub_reattach_port:370: giving up port reset - device vanished! : usb2_alloc_device:1417: set address 2 failed (ignored) : usb2_alloc_device:1452: getting device descriptor at addr 2 failed! : uhub_reattach_port:401: could not allocate new device! : : usb2_alloc_device:1417: set address 2 failed (ignored) : usb2_alloc_device:1452: getting device descriptor at addr 2 failed! : uhub_reattach_port:401: could not allocate new device! : : But not so old one from svn was working fine. : : kldstat : Id Refs AddressSize Name : 1 155 0xc040 51f700 kernel (/boot/kernel/kernel) : 22 0xc092 51bb0sound.ko (/boot/kernel/sound.ko) : 31 0xc0972000 1a5e0snd_hda.ko (/boot/kernel/snd_hda.ko) : 42 0xc098d000 18170agp.ko (/boot/kernel/agp.ko) : 51 0xc09a6000 c3fc random.ko (/boot/kernel/random.ko) : 62 0xc09b3000 16b14drm.ko (/boot/kernel/drm.ko) : 71 0xc09ca000 af9c i915.ko (/boot/kernel/i915.ko) : 85 0xc09d5000 e3cc ata.ko (/boot/kernel/ata.ko) : 92 0xc09e4000 5230 ataahci.ko (/boot/kernel/ataahci.ko) : 103 0xc09ea000 88b0 atapci.ko (/boot/kernel/atapci.ko) : 111 0xc09f3000 4638 atadisk.ko (/boot/kernel/atadisk.ko) : 121 0xc09f8000 5834 ataintel.ko (/boot/kernel/ataintel.ko) : 131 0xc09fe000 be08 cpufreq.ko (/boot/kernel/cpufreq.ko) : 141 0xc0a0a000 4dc8 sysvmsg.ko (/boot/kernel/sysvmsg.ko) : 151 0xc0a0f000 5e9c sysvsem.ko (/boot/kernel/sysvsem.ko) : 161 0xc0a15000 5034 sysvshm.ko (/boot/kernel/sysvshm.ko) : 171 0xc0a1b000 6b974acpi.ko (/boot/kernel/acpi.ko) : 189 0xc462c000 35000usb2_core.ko (/boot/kernel/usb2_core.ko) : 194 0xc46eb000 3000 usb2_controller.ko : (/boot/kernel/usb2_controller.ko) : 201 0xc46f8000 a000 usb2_controller_uhci.ko : (/boot/kernel/usb2_controller_uhci.ko) : 211 0xc474e000 c000 usb2_controller_ehci.ko : (/boot/kernel/usb2_controller_ehci.ko) : 221 0xc477b000 a000 usb2_controller_ohci.ko : (/boot/kernel/usb2_controller_ohci.ko) : 231 0xc47a8000 a000 usb2_storage_mass.ko : (/boot/kernel/usb2_storage_mass.ko) : 241 0xc47b2000 43000cam.ko (/boot/kernel/cam.ko) : 251 0xc47fe000 2000 usb2_storage.ko (/boot/kernel/usb2_storage.ko) : 261 0xc480 a000 usb2_wlan_rum.ko : (/boot/kernel/usb2_wlan_rum.ko) : 271 0xc480a000 2000 wlan_amrr.ko (/boot/kernel/wlan_amrr.ko) : 284 0xc480c000 34000wlan.ko (/boot/kernel/wlan.ko) : 291 0xc4849000 2000 usb2_wlan.ko (/boot/kernel/usb2_wlan.ko) : : : After some time it will appear but will start attaching and dettaching : all the time: : : ugen4.2: Ralink at usbus4 : rum0: Ralink 802.11 bg WLAN, class 0/0, rev 2.00/0.01, addr 2 on usbus4 : rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 : rum0: at ushub4, port 6, addr 2 (disconnected) : rum0: detached : ugen4.2: Ralink at usbus4 : rum0: Ralink 802.11 bg WLAN, class 0/0, rev 2.00/0.01, addr 2 on usbus4 : rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 : rum0: at ushub4, port 6, addr 2 (disconnected) : rum0: detached : ugen2.2: Ralink at usbus2 : rum0: Ralink 802.11 bg WLAN, class 0/0, rev 2.00/0.01, addr 2 on usbus2 : rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 : rum0: at ushub2, port 2, addr 2 (disconnected) : rum0: detached : : : Looks like some code is missing because loading only usb2_wlan_rum do : not load ehci and uhci usb2 modules. (causing card to not attach) : : I managed to get card working with usb2_controller_uhci and : usb2_controller_ehci loaded. (without ohci) That's not a bug. Warner ___
Re: USB4BSD release candidate number 3 - request for review
In message: [EMAIL PROTECTED] Paul B. Mahol [EMAIL PROTECTED] writes: : On 11/7/08, M. Warner Losh [EMAIL PROTECTED] wrote: : In message: [EMAIL PROTECTED] : Paul B. Mahol [EMAIL PROTECTED] writes: : : On 11/7/08, Paul B. Mahol [EMAIL PROTECTED] wrote: : : On 11/7/08, Paul B. Mahol [EMAIL PROTECTED] wrote: : : On recent CURRENT when attaching rum card, strange bug appear: : : : : usb2_alloc_device:1417: set address 2 failed (ignored) : : usb2_alloc_device:1452: getting device descriptor at addr 2 failed! : : uhub_reattach_port:401: could not allocate new device! : : : : uhub_reattach_port:355: port 5 reset failed, error=USB_ERR_TIMEOUT : : uhub_reattach_port:421: device problem (USB_ERR_TIMEOUT), disabling : port 5 : : uhub_reattach_port:370: giving up port reset - device vanished! : : uhub_reattach_port:370: giving up port reset - device vanished! : : uhub_reattach_port:370: giving up port reset - device vanished! : : uhub_reattach_port:370: giving up port reset - device vanished! : : uhub_reattach_port:370: giving up port reset - device vanished! : : uhub_reattach_port:370: giving up port reset - device vanished! : : uhub_reattach_port:370: giving up port reset - device vanished! : : uhub_reattach_port:370: giving up port reset - device vanished! : : uhub_reattach_port:355: port 5 reset failed, error=USB_ERR_TIMEOUT : : uhub_reattach_port:421: device problem (USB_ERR_TIMEOUT), disabling : port 5 : : uhub_reattach_port:370: giving up port reset - device vanished! : : usb2_alloc_device:1417: set address 2 failed (ignored) : : usb2_alloc_device:1452: getting device descriptor at addr 2 failed! : : uhub_reattach_port:401: could not allocate new device! : : : : usb2_alloc_device:1417: set address 2 failed (ignored) : : usb2_alloc_device:1452: getting device descriptor at addr 2 failed! : : uhub_reattach_port:401: could not allocate new device! : : : : But not so old one from svn was working fine. : : : : kldstat : : Id Refs AddressSize Name : : 1 155 0xc040 51f700 kernel (/boot/kernel/kernel) : : 22 0xc092 51bb0sound.ko (/boot/kernel/sound.ko) : : 31 0xc0972000 1a5e0snd_hda.ko (/boot/kernel/snd_hda.ko) : : 42 0xc098d000 18170agp.ko (/boot/kernel/agp.ko) : : 51 0xc09a6000 c3fc random.ko (/boot/kernel/random.ko) : : 62 0xc09b3000 16b14drm.ko (/boot/kernel/drm.ko) : : 71 0xc09ca000 af9c i915.ko (/boot/kernel/i915.ko) : : 85 0xc09d5000 e3cc ata.ko (/boot/kernel/ata.ko) : : 92 0xc09e4000 5230 ataahci.ko (/boot/kernel/ataahci.ko) : : 103 0xc09ea000 88b0 atapci.ko (/boot/kernel/atapci.ko) : : 111 0xc09f3000 4638 atadisk.ko (/boot/kernel/atadisk.ko) : : 121 0xc09f8000 5834 ataintel.ko (/boot/kernel/ataintel.ko) : : 131 0xc09fe000 be08 cpufreq.ko (/boot/kernel/cpufreq.ko) : : 141 0xc0a0a000 4dc8 sysvmsg.ko (/boot/kernel/sysvmsg.ko) : : 151 0xc0a0f000 5e9c sysvsem.ko (/boot/kernel/sysvsem.ko) : : 161 0xc0a15000 5034 sysvshm.ko (/boot/kernel/sysvshm.ko) : : 171 0xc0a1b000 6b974acpi.ko (/boot/kernel/acpi.ko) : : 189 0xc462c000 35000usb2_core.ko (/boot/kernel/usb2_core.ko) : : 194 0xc46eb000 3000 usb2_controller.ko : : (/boot/kernel/usb2_controller.ko) : : 201 0xc46f8000 a000 usb2_controller_uhci.ko : : (/boot/kernel/usb2_controller_uhci.ko) : : 211 0xc474e000 c000 usb2_controller_ehci.ko : : (/boot/kernel/usb2_controller_ehci.ko) : : 221 0xc477b000 a000 usb2_controller_ohci.ko : : (/boot/kernel/usb2_controller_ohci.ko) : : 231 0xc47a8000 a000 usb2_storage_mass.ko : : (/boot/kernel/usb2_storage_mass.ko) : : 241 0xc47b2000 43000cam.ko (/boot/kernel/cam.ko) : : 251 0xc47fe000 2000 usb2_storage.ko : (/boot/kernel/usb2_storage.ko) : : 261 0xc480 a000 usb2_wlan_rum.ko : : (/boot/kernel/usb2_wlan_rum.ko) : : 271 0xc480a000 2000 wlan_amrr.ko (/boot/kernel/wlan_amrr.ko) : : 284 0xc480c000 34000wlan.ko (/boot/kernel/wlan.ko) : : 291 0xc4849000 2000 usb2_wlan.ko (/boot/kernel/usb2_wlan.ko) : : : : : : After some time it will appear but will start attaching and dettaching : : all the time: : : : : ugen4.2: Ralink at usbus4 : : rum0: Ralink 802.11 bg WLAN, class 0/0, rev 2.00/0.01, addr 2 on : usbus4 : : rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 : : rum0: at ushub4, port 6, addr 2 (disconnected) : : rum0: detached : : ugen4.2: Ralink at usbus4 : : rum0: Ralink 802.11 bg WLAN, class 0/0, rev 2.00/0.01, addr 2 on : usbus4 : : rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 : : rum0: at ushub4, port 6, addr 2 (disconnected) : : rum0: detached : : ugen2.2: Ralink at usbus2 : : rum0: Ralink 802.11 bg WLAN, class 0/0, rev 2.00/0.01, addr 2 on : usbus2 : : rum0: MAC/BBP RT2573 (rev
Re: USB4BSD release candidate number 3 - request for review
In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : On Thursday 06 November 2008, Bruce Cran wrote: : On Wed, 5 Nov 2008 17:22:43 +0100 : : Hans Petter Selasky [EMAIL PROTECTED] wrote: : On Wednesday 05 November 2008, kevin wrote: :Hans Petter Selasky wrote: : On Wednesday 05 November 2008, kevin wrote: : Hans Petter Selasky wrote: : Hi, : : A new USB release is available: : : http://www.selasky.org/hans_petter/usb4bsd/for_review/ : : %md5 usb2_release_003.* : MD5 (usb2_release_003.diff) = e31a032d0234bb7d72eb968c33118d84 : MD5 (usb2_release_003.tar.gz) = 0a0d9dd44e93ba2ceaa849c577f6fecf : %sha256 usb2_release_003.* : SHA256 (usb2_release_003.diff) = : 9b4359f76eeef43d9b6c0c524198e529f2debff14e6158ebac8f35d51efb211b : SHA256 (usb2_release_003.tar.gz) = : 3040714546fc21bc2943c2e7aec1734150845271664aad44639ff5c553e3ed31 : : Changes since 002 release: : : I try to compile kernel with usb2. : : Hi, : : Try to load the module instead of having bluetooth in the kernel. : Then all dependancies are loaded automatically. : : Depends on some bluetooth stuff. : : --HPS : :I build kernel without usb2_bluetooth_ng successfully. i notice that :fingerpring and bluetooth mouse nolonger work now. :in dmesg: :ugen0.2: Broadcom Corp at usbus0 :ugen0.3: STMicroelectronics at usbus0 :maybe /etc/rc.d/bthidd and fprint package need update now. : : Try: : : kldload usb2_bluetooth_ng : : I don't know if this is a problem in general, but I can't load : : usb2_serial_modem and have usb2_serial load automatically: : kldload usb2_serial_modem : : interface ucom.1 already present in the KLD 'ucom.ko'! : kldload: /boot/kernel/usb2_serial.ko: Unsupported file type : KLD usb2_serial_modem.ko: depends on usb2_serial - not available : kldload: /boot/kernel/usb2_serial_modem.ko: Unsupported file type : : kldload'ing usb2_serial followed by usb2_serial_modem works though. : : Hi, : : Fixed in the following commit: : : http://perforce.freebsd.org/chv.cgi?CH=152584 : : Thanks again for your reporting. I've merged this into -head. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB4BSD release candidate number 3 - request for review
In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : On Wednesday 05 November 2008, Lars Engels wrote: : : Hi Lars, : : Now I just removed everything but usb2_core from the kernel config and : load the modules manually. So far it runs pretty good. : : Mounting a umass device, removing it and doing an 'ls' on the mountpoint : freezes the system, I thought this should not happen with the new stack? : : It is not a USB problem. It is the CAM layer that is hanging on the disk. Sure it is CAM layer and not buffer cache or filesystem code? Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB4BSD release candidate number 3 - request for review
In message: [EMAIL PROTECTED] kevin [EMAIL PROTECTED] writes: : Hans Petter Selasky wrote: : On Wednesday 05 November 2008, kevin wrote: : : Hans Petter Selasky wrote: : : Hi, : : A new USB release is available: : : http://www.selasky.org/hans_petter/usb4bsd/for_review/ : : %md5 usb2_release_003.* : MD5 (usb2_release_003.diff) = e31a032d0234bb7d72eb968c33118d84 : MD5 (usb2_release_003.tar.gz) = 0a0d9dd44e93ba2ceaa849c577f6fecf : %sha256 usb2_release_003.* : SHA256 (usb2_release_003.diff) = : 9b4359f76eeef43d9b6c0c524198e529f2debff14e6158ebac8f35d51efb211b : SHA256 (usb2_release_003.tar.gz) = : 3040714546fc21bc2943c2e7aec1734150845271664aad44639ff5c553e3ed31 : : Changes since 002 release: : : I try to compile kernel with usb2. : : : Hi, : : Try to load the module instead of having bluetooth in the kernel. Then all : dependancies are loaded automatically. : : Depends on some bluetooth stuff. : : --HPS : : : I build kernel without usb2_bluetooth_ng successfully. i notice that : fingerpring and bluetooth mouse nolonger work now. : in dmesg: : ugen0.2: Broadcom Corp at usbus0 : ugen0.3: STMicroelectronics at usbus0 : maybe /etc/rc.d/bthidd and fprint package need update now. Almost certainly... And they will likely have to deal with both stacks for a while... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB4BSD release candidate number 3 - request for review
In message: [EMAIL PROTECTED] Rink Springer [EMAIL PROTECTED] writes: : On Wed, Nov 05, 2008 at 02:18:17AM -0700, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Hans Petter Selasky [EMAIL PROTECTED] writes: : : On Wednesday 05 November 2008, Lars Engels wrote: : : Mounting a umass device, removing it and doing an 'ls' on the mountpoint : : freezes the system, I thought this should not happen with the new stack? : : : : It is not a USB problem. It is the CAM layer that is hanging on the disk. : : Sure it is CAM layer and not buffer cache or filesystem code? : : Well, the CAM layer problem will immediately first - it does not like : CAM busses disappearing. Once this is fixed or avoided and the problem : still shows up, we can blame buffer cache / filesystem code. : : As I suggested before, a good fix is to create one CAM bus per USB root : hub, and use that to attach all umass devices to. This will also get rid : of the one-bus-per-umass-device which is visually unappealling. That might work. It might also be useful to see if the DragonFly patches to allow this port over or not... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB4BSD release candidate number 3 - request for review
In message: [EMAIL PROTECTED] Bruce Cran [EMAIL PROTECTED] writes: : On Wed, 5 Nov 2008 00:04:02 +0100 : Lars Engels [EMAIL PROTECTED] wrote: : Now I just removed everything but usb2_core from the kernel config and : load the modules manually. So far it runs pretty good. : : Mounting a umass device, removing it and doing an 'ls' on the : mountpoint freezes the system, I thought this should not happen with : the new stack? : : : I seem to remember the problem was tracked back to something in the cam : layer not liking surprise removals? For msdos filesystem, there were a number of minor tweaks that were made to make this suck less. Some were in the old usb layer, but most were in the buffer cache of FreeBSD to make it more resilient to errors from the device... But it wasn't totally fixed... Hans' stack did have a period of time when card removal was working better than the stock FreeBSD stack, but that got cleaned up before 7.0. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ucom panic
In message: [EMAIL PROTECTED] Steve Franks [EMAIL PROTECTED] writes: : Perhaps someone can make sense of my backtrace, this is a ucom causes : a panic, but only when I open it from one specific program. If I talk : to the ucom with minicom, no issues. That aside, a panic when talking : to any serial port with any program would be considered a bug, right? Is there any way you could boot a -current kernel? I think this is a bug I fixed in -current, but maybe didn't back merge to 7... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/127543: [patch] [ubsa] Support Option Globetrotter HSDPA modem
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : Synopsis: [patch] [ubsa] Support Option Globetrotter HSDPA modem : : Responsible-Changed-From-To: freebsd-usb-n_hibma : Responsible-Changed-By: n_hibma : Responsible-Changed-When: Thu Oct 16 09:58:54 UTC 2008 : Responsible-Changed-Why: : Assign this bug to me. Adding the ID is one thing, considering the : adding of all IDs found in the Linux another. But the real question is : whether the Linux driver contains useful stuff: DTR/DSD handling. I've added them to the uipaq driver... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB4BSD - release candidate 2 - coming to FreeBSD this week.
I'm worried about the sound changes folded in here. i think they should be separated out, perhaps with a note that uaudio doesn't work without them. They should come in via the normal sound driver maintainer's processes. I think they break other things. Other than that, I'm happy with these going in. That isn't to say I like everything about usb2, but it is to the point where it needs wider testing and wider comment. I suspect there's a number of contentious items lingering in the code, but they shouldn't prevent it going in. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [usb2] new usb stack and suser in CURRENT
In message: [EMAIL PROTECTED] Rink Springer [EMAIL PROTECTED] writes: : On Sat, Sep 20, 2008 at 09:59:09PM +0800, Intron is my alias on the Internet wrote: : How soon will the new USB stack be committed to the main source tree? : Since it can peacefully co-exist with the old one in a source tree, : why not commit it at once? : For a driver writer/porter, a standard version of the new USB stack : is needed for compiling/debugging. : : The main problem was that the new stack would be imported just days : after the new TTY layer was committed, which caused a lot of resistance : (which makes sense, as debugging problems would become much harder). I : believe Alfred, who would be doing the import, went on vacation a few : weeks after. This timeline isn't quite right. The concerns over the new TTY drivers and usb weren't relevant. There were a number of other issues that ran out the clock for Alfred's free time to commit this before his vacation. After he got back, he hasn't had the time to commit. I personally said I'd deal with the new TTY layer and usb (at least ucom). I fixed a few nits that ed overlooked in a couple devices he didn't have in the old stack. : Personally, since we have the new TTY layer for some time now, I think : it would be good if Alfred (CC'ed) would attempt to request this import : again, if his time permits. I'd like to see this. I know he's very busy at work, but hope he has some time to cope with this. I'd do it, but all my FreeBSD time these days is booked up with MIPS, ARM and a paper for EuroBSDCon. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: legacy usb stack fixes
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : Scott Long wrote: : This is close to How Things Should Be. Each umass target having its own : SIM and bus is indeed wrong, but I'm not sure if it's correct for all : USB controllers and buses to be under a single SIM. What would be the : most correct is for each physical USB controller/bus instance to have : its own SIM instance. I don't know if it's better to do the attachment : in ehci/ohci/uhci controller drivers or in usb bus driver; up in the : controller drivers is probably more correct. I don't like this hack of : attaching stuff in a SYSINIT. : : Scott : : : : Now that I've thought some on it, I'll go one step further and say that : registering a single SIM for multiple controller+bus instances in a : SYSINIT will be highly undesirable thing to do. Since you have to : register a lock with the CAM when you register the SIM, you'll wind up : serializing all of the USB controllers under a single lock. Or you'll : probably try something dangerous and tricky with dropping the new global : lock and picking up an individual lock, then swizzling locks in the : completion and event paths, with the result being rather unsatisfying : and unpleasant. So I know that you'll do what you believe is correct, : but please take my advice on the matter anyways. Yes. A SIM will serialize all operations, and the most logical place for that is the computer - usb interface, which is the host controller. So having one SIM per host controller would be the optimal placement. Having one SIM per usb device doesn't result in any more real parallelism because the host controller necessarily serializes things because of how USB is defined... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: legacy usb stack fixes
In message: [EMAIL PROTECTED] Rink Springer [EMAIL PROTECTED] writes: : On Thu, Sep 11, 2008 at 10:13:22AM +0200, Hans Petter Selasky wrote: : I also see crashes with my new stuff and the umass driver when the USB device : is un-plugged too early. The backtraces I've got so far does not indicate a : USB problem, though : : That is correct, this is a bug in CAM. More specifically, CAM does not : handle the removal of busses well. There are two possible options: : : 1) Obviously, fix CAM to handle this scenarion :DragonflyBSD seems to have a lot of fixes in this area, which I :intend to take a look at 'some day' (no thanks to $reallife...) This is the better option. : 2) Create a CAM bus per USB bus : I think this is reasonable, and it makes a lot more sense than the :one-bus-per-device approach that we have now. The idea is that :every USB controller hub creates a CAM bus, and umass(4) attaches to :this bus instead of creating its own. Of course, until CAM is fixed, :detaching PCMCIA or equivalent USB cards will still cause panics, but :it would be a lot better than it is now... This would mitigate the problem, but there's a lot of people that use CardBus USB cards, and they complain to me from time to time of the problem. Fortunately, the wireless broadband cards that are a usb host controller plus usb device in CardBus format aren't affected... : Personally, I'd like to see option 2 implemented in the USB2 stack, as : it avoids the issue and makes a lot more sense from user perspective : (I'm probably onot the only one who gets scared by 'camcontrol devlist' : if you have a single MP3 player which advertises 2 disks :-)) It may make good sense for other reasons as well. Firewire does something similar, and also umass used to do exactly this. There's also problems right now with huge bus load leading to devices disconnecting and reconnecting for some suck-ass, but common, chipsets. If things were implemented this way, then there'd be options to silently reconnect the device when it goes away and comes back a few hundred milliseconds later... Firewire handles this case too, at the expense of never disconnecting the disk, which isn't so good for a thumb drive... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP new usb code coming in.
In message: [EMAIL PROTECTED] Antony Mawer [EMAIL PROTECTED] writes: : On 24/08/2008 3:10 PM, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Antony Mawer [EMAIL PROTECTED] writes: : ... : : This wasn't about the new USB stack -- we were discussing the buffer : : cache and CAM-related fixes that prevents the system from panic'ing when : : a USB device is unplugged without first unmounting the filesystem. These : : patches are in HEAD with the existing USB stack. :-) : : The best I can do is say Maybe and the answer is closer to yes if : somebody data-mines the changes I've made in this area in -current. : That's the hard part of back porting them.. : : I'm going to try and do just that - is there a particular date that this : must be done by in order to make sure these would make it in for the 7.1 : release cycle? End of this month would be ideal. By the middle of next would be acceptable, I think. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb4bsd patch review
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], Hans Petter Selasky writes: : : : The problem about devfs.rules with regard to USB is that you don't know what : you are giving permissions to. A rule that gives permission to /dev/ulpt0 : will give permissions to the first printer you plug into the USB system. That : is not neccessarily what the user wants. : : I think this might be a good time to consider the devd/devfs : distribution of work. : : The reason devfs(8) works like firewall rules is that we did not want : some mandatory daemon to set the modes, in particular on embedded : systems. : : The alternative solution is to always create device nodes root:wheel r-- : and let the daemon set the mode as desired. : : This model has the advantage of not needing the uid, gid and mode arguments : to make_dev, something that has always been acknowleded as a kludge. : : The down side is that devd(8) becomes a mandatory daemon on most systems. : : Given that devfs(8) has not exactly been a stellar success and that it : often and repeatedly bites people with it slightly pedantic semantics, : transitioning in that direction might be a good thing. While this may be a good idea, I'm hesitant about races that it may introduce. This is the classic point of attack: do something between steps of a formerly atomic operation that was made non-atomic. I can't think of anything off the top of my head, but I'm still concerned. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb4bsd patch review
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], M. Warner Losh writes : : : : While this may be a good idea, I'm hesitant about races that it may : introduce. This is the classic point of attack: do something between : steps of a formerly atomic operation that was made non-atomic. I : can't think of anything off the top of my head, but I'm still : concerned. : : We have ways of closing the race if need be, but they're all slightly : kludgy, but I am not overly concerned about those races as long as : the default is to not give access. I guess I'm worried about a device that comes and goes and comes back and there being some difference between the two that causes us to bogusly do something to the new device that was appropriate for the old one, but not the new one... Wraner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP new usb code coming in.
In message: [EMAIL PROTECTED] Antony Mawer [EMAIL PROTECTED] writes: : On 23/08/2008 8:08 PM, Volker wrote: : On 12/23/-58 20:59, Antony Mawer wrote: : M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Antony Mawer [EMAIL PROTECTED] writes: : : Warner Losh wrote: : : From: Bakul Shah [EMAIL PROTECTED] : : Subject: Re: HEADSUP new usb code coming in. : Date: Tue, 19 Aug : 2008 14:18:13 -0700 : : : On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky : [EMAIL PROTECTED] wrote: : : New stuff (all of which I can remember right now): : : ... : : : : Accidentally unplugging a mounted USB disk (without : : unmounting it) resulted in a hang or a crash. Is this fixed? : : : That's fixed in -current right now with the old stack. It : isn't a usb : : issue at all, but a buffer cache issue. : : : Is this change that is likely to be MFC'd in time for 7.1? And/or : is : there a specific patch that can manually be applied to -STABLE to : fix this? : : I should spend the time to dig into the changes in current. There : turned out to be several little changes... And I need to verify all : the edge cases were covered... : I'd be happy to test patches if you do end up doing this.. it would be : really nice to have in 7.1, or at least available as a patchset if it : isn't suitable for MFC (eg. ABI changes)... : : I'm a bit behind with reading emails. Please forgive me if this has : already been answered. : : Don't expect the new USB stack for 7.1-R. It's too short and the new USB : stack will introduce an ABI breakage. For that, all drivers written for : the old USB stack need to be rewritten and I guess, we need to take care : about 3rd party developers and inform them in advance about that massive : change. I would not wonder if this will never get MFC'd but I don't know : actually. : : This wasn't about the new USB stack -- we were discussing the buffer : cache and CAM-related fixes that prevents the system from panic'ing when : a USB device is unplugged without first unmounting the filesystem. These : patches are in HEAD with the existing USB stack. :-) The best I can do is say Maybe and the answer is closer to yes if somebody data-mines the changes I've made in this area in -current. That's the hard part of back porting them.. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb4bsd patch review
In message: [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] writes: : Hans Petter Selasky wrote: : On Thursday 21 August 2008, Kris Kennaway wrote: : Hans Petter Selasky wrote: : On Thursday 21 August 2008, Kris Kennaway wrote: : Hans Petter Selasky wrote: : * How much of the userland support is incomplete or in flux, and what : functionality is missing for users of the usb2 code until it is : finished? : The USB userland library is nearly complete. All it lacks is proper : documentation: : : svn --username anonsvn --password anonsvn \ :checkout svn://svn.turbocat.net/i4b/trunk/libusb20 : : The USB config utility is also starting to become finished. It will be : renamed to usbconfig. Currently it is called usbview : : : svn --username anonsvn --password anonsvn \ :checkout svn://svn.turbocat.net/i4b/trunk/usbview : So...what functionality is missing for users of the usb2 code until it : is finished? : : Stated even more clearly, what things will users of the USB2 code not be : able to do until the above userland code is imported? : : Seriously, I'm trying to understand this! : Hi, : : There are some USB drivers which run in userland that will not work until : this library is complete. These are currently not part of the FreeBSD : distribution. You find them in /usr/ports : : : grep libusb /usr/ports/INDEX : : The kernel USB drivers provided under /sys/dev/usb2 do not directly : depend on any userland utilities, but rather indirectly through the TTY, : KBD, NET ... : : One exception is the USB mouse driver which depends on moused, and : currently have some warnings because moused tries to load the old ums : module, which fails. : OK, now we're approaching half way. The moused thing should be : documented somewhere with a workaround (or fix). If the new ums2 module : is present before moused is started will it still try to load the old : one? Is there another workaround? : : Hi, : : What happens is this: : : 1. devd reports ums0 like before. : 2. moused is started : 3. moused tries to kldload ums : 4. The ums module depens on the usb module which is also tried loaded. : 5. Loading the usb module fails. : 6. moused finally tries to open /dev/ums0 and the mouse works like before. : : ums0: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM), class 0/0, rev : 1.10/3.00, addr 3 on usbus3 : ums0: 3 buttons and [XYZ] coordinates : Symlink: ums0 - usb3.3.0.16 : : module_register: module pci/uhci already exists! : Module pci/uhci failed to register: 17 : module_register: module cardbus/uhci already exists! : Module cardbus/uhci failed to register: 17 : module_register: module pci/ohci already exists! : Module pci/ohci failed to register: 17 : module_register: module cardbus/ohci already exists! : Module cardbus/ohci failed to register: 17 : module_register: module pci/ehci already exists! : Module pci/ehci failed to register: 17 : module_register: module cardbus/ehci already exists! : Module cardbus/ehci failed to register: 17 : KLD ums.ko: depends on usb - not available : : OK, so just cosmetic. It kind of sounds like moused is doing the wrong : thing, but this can hopefully be fixed later. : : What about the second thing: usbconfig? : : The USB stack will work fine without usbconfig. Its purpose is mostly to : view the currently attached USB devices, where the USB devices are located : and to select a non-default USB configuration. One thing which might be : missed is to change owner and permission of a USB device, which means you : must be either UID=root or GID=OPERATOR to be able to use USB devices that : create devices under /dev/ . : : OK great, this isn't critical either. I think all of the issues I : raised are agreed upon now! : : Unfortunately since Alfred is going away for 3 weeks it looks like that : is now going to put this on hold for a bit. It's probably a good thing : that the initial import was delayed actually, since he is going to need : to be available for the inevitable followup work after it gets imported, : and leaving 3 days after the planned import would have really hurt that : process. : : Unless someone else comes forward to take over from Alfred, here's what : I recommend as a plan: : : * post the revised diff with the minor changes/bits left out that we : have agreed upon. Users can continue to test this commit candidate : while Alfred is away. : : * When Alfred gets back and has a block of free time, he will proceed : with the import and handle followup commits to fix issues that are : identified. : : * If the commit candidate diff changes in the meantime due to bug : fixes etc, then you should keep the mailing list updated regularly with : a pointer to the latest version of the commit candidate diff. Other new : stuff like the forthcoming userland changes should stay out of this : first diff for now so we don't invalidate things
Re: HEADSUP new usb code coming in.
In message: [EMAIL PROTECTED] Paul Schmehl [EMAIL PROTECTED] writes: : So, if we're running 7.0 STABLE, will these changes show up with : csup so we can rebuild kernel? Or are these diffs something you : need to download and build separately? This code won't be committed to RELENG_7... However I think hps has patches for it... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP new usb code coming in.
In message: [EMAIL PROTECTED] Antony Mawer [EMAIL PROTECTED] writes: : Warner Losh wrote: : From: Bakul Shah [EMAIL PROTECTED] : Subject: Re: HEADSUP new usb code coming in. : Date: Tue, 19 Aug 2008 14:18:13 -0700 : : On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky [EMAIL PROTECTED] wrote: : New stuff (all of which I can remember right now): : ... : : Accidentally unplugging a mounted USB disk (without : unmounting it) resulted in a hang or a crash. Is this fixed? : : That's fixed in -current right now with the old stack. It isn't a usb : issue at all, but a buffer cache issue. : : Is this change that is likely to be MFC'd in time for 7.1? And/or is : there a specific patch that can manually be applied to -STABLE to fix this? I should spend the time to dig into the changes in current. There turned out to be several little changes... And I need to verify all the edge cases were covered... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/124604: Wireless Mouse doesn't work
I'm picking a random message to reply to... As we move forward with Hans Peter Selasky's usb stack, I think many of these issues will resolve themselves, or will be easier to resolve than in the current stack. Microsoft does like to have extensions to standards, and this is no different. There are some hacks for them in the kernel now, but, frankly, a better framework is needed to make it happen. This is one of the pros of the Selasky stack: it tries cleans up HID processing a lot. There's some weaknesses in that stack, but I believe it is slated to go into the tree along side the classic stack so that the issues can be worked out. So it isn't that people don't want to solve the problems here, it just may take a little while for things to stabilize. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/122819: Patch to provide dynamic additions to the usb quirks table
In message: [EMAIL PROTECTED]
Hans Petter Selasky [EMAIL PROTECTED] writes:
: You need to do a little bit more work regarding the token naming. There is no
: USB module called UAU. Instead of UAU_NO_FRAC I think you should have
: changed it to UAUDIO_NO_FRAC. The same applies for most of the other quirk
: tokens aswell. UHID_IGNORE is fine.
:
: Search the kernel sources for where these tokens are used to figure out the
: module name:
:
: find /usr/src/sys -name *.c -and -exec grep -H AU_NO_FRAC {} \;
:
: Else your changes are OK.
I don't suppose there's some way to automatically generate these
things? I like the idea...
Warner
: --HPS
:
: On Thursday 17 April 2008, Maurice Castro wrote:
: The following reply was made to PR usb/122819; it has been noted by GNATS.
:
: --Apple-Mail-2-311066617
: Content-Disposition: attachment;
: filename=usb.diff
: Content-Type: application/octet-stream;
: x-unix-mode=0644;
: name=usb.diff
: Content-Transfer-Encoding: 7bit
:
: diff -ru /usr/src/share/man/man4/usb.4 /scratch/src/share/man/man4/usb.4
: --- /usr/src/share/man/man4/usb.4 2008-04-11 22:43:31.0 +1000
: +++ /scratch/src/share/man/man4/usb.4 2008-04-17 08:39:01.0
+1000
: @@ -288,6 +288,66 @@
:.Em DANGEROUS
:and should be used with great care since it
:can destroy the bus integrity.
: +.It Dv USB_SETDYNQUIRKS
: +This command will cause the dynamic quirks table to be rebuilt from the
: +contents of the kernel environment. Environment strings of the form
: +.Pp
: +.Ic usb.quirk.N=VENDOR PRODUCT REVISION FLAGS
: +.Pp
: +where
: +.Ic N
: +is a number between 0 and 9 and quirks must be numbered contiguously;
: +.Ic VENDOR PRODUCT
: +and
: +.Ic REVISION
: +are constants that identify the device (the value 0x for
: +.Ic REVISION
: +denotes all revisions); and
: +.Ic FLAGS
: +is any combination of
: +.Bl -tag -width UOPEN_CLEARSTALL -compact -offset indent
: +.It USWAP_UNICODE
: +has some Unicode strings swapped.
: +.It UMS_REVZ
: +mouse has Z-axis reversed
: +.It UNO_STRINGS
: +string descriptors are broken.
: +.It UBAD_ADC
: +bad audio spec version number.
: +.It UBUS_POWERED
: +device is bus powered, despite claim
: +.It UBAD_AUDIO
: +device claims audio class, but isn't
: +.It USPUR_BUT_UP
: +spurious mouse button up events
: +.It UAU_NO_XU
: +audio device has broken extension unit
: +.It UPOWER_CLAIM
: +hub lies about power status
: +.It UAU_NO_FRAC
: +don't adjust for fractional samples
: +.It UAU_INP_ASYNC
: +input is async despite claim of adaptive
: +.It UBROKEN_BIDIR
: +printer has broken bidir mode
: +.It UOPEN_CLEARSTALL
: +device needs clear endpoint stall
: +.It UHID_IGNORE
: +device should be ignored by hid class
: +.It UKBD_IGNORE
: +device should be ignored by both kbd and hid class
: +.It UMS_BAD_CLASS
: +doesn't identify properly
: +.It UMS_LEADING_BYTE
: +mouse sends an unknown leading byte.
:
:
:
: ___
: 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: FreeBSD 6.2 and USB Serial Port
In message: [EMAIL PROTECTED] Thomas D. Dean [EMAIL PROTECTED] writes: : I attempted to use a Prolific Technology USB-Serial Controller on FreeBSD 6.2. : : I have ucom and uftdi loaded. : : I am using a Logitech Receiver for keyboard and mouse on usb0 addr1, port2. : : I connect the USB-Serial Controller to usb1 addr1 port1. usbdevs shows it. : : When I connect the device, I see the console message and ugen1,ugen1.[1-3] in /dev. However, none of cuaUx or ttyUx are created. : : What am I doing wrong? You eed to load uplcom instead of uftdi. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
