Re: 8.0-RC1: AMD CS5536 (Geode) USB 2.0 controller strange behavour

2009-09-28 Thread Eugene Grosbein
On Mon, Sep 28, 2009 at 08:49:21AM +0200, Hans Petter Selasky wrote:

> > > If the USB stack puts the new job into the schedule and the USB
> > > controller does not pick it up, it is not an USB stack problem ...
> >
> > If so, any workarounds possible?
> 
> None which I know about.

I've just found one. I noticed that USB controller here uses IRQ10
and shares it with NIC and FireWire. This system does not support IO-APIC.
I've disabled ACPI and NIC has moved to another IRQ,
USB and FireWire still share one IRQ but now there are no stalled transfers.
I get stable 16.2 megabyte/s writing speed to USB HDD.

Now I wonder if there is another way to assign distinct IRQ for USB,
BIOS Setup does not help.

Eugene Grosbein.
___
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: sb600/sb700 ohci experimental patch

2009-09-28 Thread Andriy Gapon
on 28/09/2009 17:10 John Baldwin said the following:
> On Monday 28 September 2009 9:55:44 am Andriy Gapon wrote:
>> on 28/09/2009 14:48 John Baldwin said the following:
>>> I don't think you can do this because it is a "feature" to not disable SMM 
>>> if 
>>> ohci(4) is not loaded so that a USB keyboard works when the USB driver 
>>> isn't 
>>> loaded via PS/2 emulation, even when the OS is running.
>> Very good point.
>>
>>> I am curious if we 
>>> really need to do the handover for each controller or if disabling it for 
>>> ohci0 effectively disables it for all controllers?  What do other OS's do?
>>>
>> Don't have an answer about other OSes.
>> But OHCI controllers have individual "used by SMM" bits and taking over one
>> controller doesn't affect the bits of the other controllers - they remain 
>> set.
>> Not that it means that SMM code actually keeps on controlling them.
>>
>> Actually, just checked - Linux also does it per controller:
>> http://lxr.linux.no/#linux+v2.6.31/drivers/usb/host/ohci-hcd.c#L495
> 
> Hmm, it seems Linux now disables SMM for USB controllers (ohci, ehci, and 
> uhci)
> via PCI quirks rather than doing it in the device drivers themselves, which
> matches your original suggestion.  I'm not sure how best to fix that while 
> also
> allowing USB to work w/o drivers loaded.
> 

I looked at the quirk code (for OHCI only) and they don't disable SMI - they do
exactly the same takeover dance, only earlier:
http://lxr.linux.no/#linux+v2.6.31/drivers/usb/host/pci-quirks.c#L169

I.e. this actually matches what Hans suggested before - first early takeover of
all controllers, then probe/attach pass.
Not sure how to implement this best in our architecture - also using quirks or
perhaps something along the lines of multi-pass? :-)

-- 
Andriy Gapon
___
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: sb600/sb700 ohci experimental patch

2009-09-28 Thread John Baldwin
On Monday 28 September 2009 9:55:44 am Andriy Gapon wrote:
> on 28/09/2009 14:48 John Baldwin said the following:
> > I don't think you can do this because it is a "feature" to not disable SMM 
> > if 
> > ohci(4) is not loaded so that a USB keyboard works when the USB driver 
> > isn't 
> > loaded via PS/2 emulation, even when the OS is running.
> 
> Very good point.
> 
> > I am curious if we 
> > really need to do the handover for each controller or if disabling it for 
> > ohci0 effectively disables it for all controllers?  What do other OS's do?
> > 
> 
> Don't have an answer about other OSes.
> But OHCI controllers have individual "used by SMM" bits and taking over one
> controller doesn't affect the bits of the other controllers - they remain set.
> Not that it means that SMM code actually keeps on controlling them.
> 
> Actually, just checked - Linux also does it per controller:
> http://lxr.linux.no/#linux+v2.6.31/drivers/usb/host/ohci-hcd.c#L495

Hmm, it seems Linux now disables SMM for USB controllers (ohci, ehci, and uhci)
via PCI quirks rather than doing it in the device drivers themselves, which
matches your original suggestion.  I'm not sure how best to fix that while also
allowing USB to work w/o drivers loaded.

-- 
John Baldwin
___
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: sb600/sb700 ohci experimental patch

2009-09-28 Thread Andriy Gapon
on 28/09/2009 14:48 John Baldwin said the following:
> I don't think you can do this because it is a "feature" to not disable SMM if 
> ohci(4) is not loaded so that a USB keyboard works when the USB driver isn't 
> loaded via PS/2 emulation, even when the OS is running.

Very good point.

> I am curious if we 
> really need to do the handover for each controller or if disabling it for 
> ohci0 effectively disables it for all controllers?  What do other OS's do?
> 

Don't have an answer about other OSes.
But OHCI controllers have individual "used by SMM" bits and taking over one
controller doesn't affect the bits of the other controllers - they remain set.
Not that it means that SMM code actually keeps on controlling them.

Actually, just checked - Linux also does it per controller:
http://lxr.linux.no/#linux+v2.6.31/drivers/usb/host/ohci-hcd.c#L495

-- 
Andriy Gapon
___
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: sb600/sb700 ohci experimental patch

2009-09-28 Thread John Baldwin
On Sunday 27 September 2009 9:10:21 am Andriy Gapon wrote:
> on 27/09/2009 15:17 Andriy Gapon said the following:
> > Another idea of working around this:
> > 1) in pci fixup code disable USB SMI for these chipsets
> > 2) (optional) in ohci code skip takeover step
> > Sounds messy.
> 
> BTW, just for the sake of experiment I did exactly what I suggested.
> I've got the following messages:
> 
> kernel: ohci_controller_init:195: SMM active, request owner change
> kernel: usbus0: SMM does not respond, resetting
> kernel: ohci_controller_init:195: SMM active, request owner change
> kernel: usbus1: SMM does not respond, resetting
> kernel: ohci_controller_init:195: SMM active, request owner change
> kernel: usbus3: SMM does not respond, resetting
> kernel: ohci_controller_init:195: SMM active, request owner change
> kernel: usbus4: SMM does not respond, resetting
> kernel: ohci_controller_init:195: SMM active, request owner change
> kernel: usbus6: SMM does not respond, resetting
> 
> And the register value stayed intact after initial programming, so no
> re-programming was needed.
> 
> Here is the (dirty) hack:
> diff --git a/sys/dev/pci/fixup_pci.c b/sys/dev/pci/fixup_pci.c
> index 566e503..1463c24 100644
> --- a/sys/dev/pci/fixup_pci.c
> +++ b/sys/dev/pci/fixup_pci.c
> @@ -53,6 +53,7 @@ static int  fixup_pci_probe(device_t dev);
>  static void  fixwsc_natoma(device_t dev);
>  static void  fixc1_nforce2(device_t dev);
>  static void  fixrtc_piix4(device_t dev);
> +static void  fixsmi_usb(device_t dev);
> 
>  static device_method_t fixup_pci_methods[] = {
>  /* Device interface */
> @@ -84,6 +85,9 @@ fixup_pci_probe(device_t dev)
>  case 0x01e010de: /* nVidia nForce2 */
>   fixc1_nforce2(dev);
>   break;
> +case 0x96001022: /* AMD SB700 */
> + fixsmi_usb(dev);
> + break;
>  }
>  return(ENXIO);
>  }
> @@ -124,6 +128,21 @@
>  }
> 
> 
> +/* Disable USB SMI */
> +static void
> +fixsmi_usb(device_t dev)
> +{
> +uint32_t features;
> +
> +dev = pci_find_device(0x1002, 0x4385);
> +features = pci_read_config(dev, 0x64, 4);
> +if (features & (1 << 15)) {
> + printf("Disabling USB SMI on SB7xx\n");
> + features &= ~(1 << 15);
> + pci_write_config(dev, 0x64, features, 4);
> +}
> +}
> +
>  /*
>   * Set the SYSTEM_IDLE_TIMEOUT to 80 ns on nForce2 systems to work
>   * around a hang that is triggered when the CPU generates a very fast

I don't think you can do this because it is a "feature" to not disable SMM if 
ohci(4) is not loaded so that a USB keyboard works when the USB driver isn't 
loaded via PS/2 emulation, even when the OS is running.  I am curious if we 
really need to do the handover for each controller or if disabling it for 
ohci0 effectively disables it for all controllers?  What do other OS's do?

-- 
John Baldwin
___
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: SANE vs USB scanner on 8.0

2009-09-28 Thread Hans Petter Selasky
On Monday 28 September 2009 15:10:52 Daniel O'Connor wrote:
> Hi,
> I'm trying to get a USB scanner to work with FreeBSD 8.0, it did work
> with 7.2 via uscanner.
>
> It's an AcerScan 620U and I have the firmware and
> modified /usr/local/etc/sane.d/snapscan.conf.
>
> sane-find-scanner sees it, eg
> [midget 22:37] ~ >sudo sane-find-scanner  -q
> found USB scanner (vendor=0x04a5 [Color], product=0x2060 [ FlatbedScanner
> 13]) at libusb:/dev/usb:/dev/ugen0.5 found USB scanner (vendor=0x0403
> [FTDI], product=0xee18 [MaxStream PKG-U]) at libusb:/dev/usb:/dev/ugen1.2
>
> I have no idea why the FTDI serial device appears there..
>
> However scanimage -L doesn't show the scanner..
> [midget 22:40] ~ >sudo env SANE_DEBUG_SNAPSCAN=255 scanimage -v -v -L
> [sanei_debug] Setting debug level of snapscan to 255.
> [snapscan] sane_snapscan_init
> [snapscan] sane_snapscan_init: Snapscan backend version 1.4.53
> [snapscan] add_usb_device(libusb:/dev/usb:/dev/ugen0.5)
> [snapscan] add_usb_device: Detected (kind of) an USB device
> [snapscan] snapscani_usb_open(libusb:/dev/usb:/dev/ugen0.5)
> [snapscan] snapscani_mutex_open: could not parse device string: No such
> file or directory [snapscan] snapscani_usb_open: Can't get semaphore
> [snapscan] add_usb_device: error opening device
> libusb:/dev/usb:/dev/ugen0.5: Invalid argument [snapscan]
> sane_snapscan_get_devices (0x7fffe200, 0)
>
> No scanners were identified. If you were expecting something different,
> check that the scanner is plugged in, turned on and detected by the
> sane-find-scanner tool (if appropriate). Please read the documentation
> which came with this software (README, FAQ, manpages).
> Calling sane_exit
> [snapscan] sane_snapscan_exit
> scanimage: finished
>
> Anyone have any suggestions?

Hi,

Try this patch:

diff -u ./work/sane-backends-1.0.20/backend/snapscan-mutex.c ./snapscan-
mutex.c
--- ./work/sane-backends-1.0.20/backend/snapscan-mutex.c2008-03-28 
21:39:02.0 +0100
+++ ./snapscan-mutex.c  2009-09-28 15:33:41.0 +0200
@@ -130,7 +130,8 @@
return 0;
}
 
-   if (sscanf(dev, "libusb:%d:%d", &busnum, &devnum) != 2)
+   if ((sscanf(dev, "libusb:%d:%d", &busnum, &devnum) != 2) &&
+   (sscanf(dev, "libusb:/dev/usb:ugen%d.%d", &busnum, &devnum) != 2))
{
DBG (DL_MAJOR_ERROR, "%s: could not parse device string: %s\n", 
me, strerror(errno));
return 0;

If it works, get the patch sent to the sane developers.

--HPS

___
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"


SANE vs USB scanner on 8.0

2009-09-28 Thread Daniel O'Connor
Hi,
I'm trying to get a USB scanner to work with FreeBSD 8.0, it did work 
with 7.2 via uscanner.

It's an AcerScan 620U and I have the firmware and 
modified /usr/local/etc/sane.d/snapscan.conf.

sane-find-scanner sees it, eg
[midget 22:37] ~ >sudo sane-find-scanner  -q
found USB scanner (vendor=0x04a5 [Color], product=0x2060 [ FlatbedScanner 13]) 
at libusb:/dev/usb:/dev/ugen0.5
found USB scanner (vendor=0x0403 [FTDI], product=0xee18 [MaxStream PKG-U]) at 
libusb:/dev/usb:/dev/ugen1.2

I have no idea why the FTDI serial device appears there..

However scanimage -L doesn't show the scanner..
[midget 22:40] ~ >sudo env SANE_DEBUG_SNAPSCAN=255 scanimage -v -v -L
[sanei_debug] Setting debug level of snapscan to 255.
[snapscan] sane_snapscan_init
[snapscan] sane_snapscan_init: Snapscan backend version 1.4.53
[snapscan] add_usb_device(libusb:/dev/usb:/dev/ugen0.5)
[snapscan] add_usb_device: Detected (kind of) an USB device
[snapscan] snapscani_usb_open(libusb:/dev/usb:/dev/ugen0.5)
[snapscan] snapscani_mutex_open: could not parse device string: No such file or 
directory
[snapscan] snapscani_usb_open: Can't get semaphore
[snapscan] add_usb_device: error opening device libusb:/dev/usb:/dev/ugen0.5: 
Invalid argument
[snapscan] sane_snapscan_get_devices (0x7fffe200, 0)

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).
Calling sane_exit
[snapscan] sane_snapscan_exit
scanimage: finished

Anyone have any suggestions?

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


signature.asc
Description: This is a digitally signed message part.


usb/138675: [usb8] [panic] page fault, perhaps in USB

2009-09-28 Thread Hans Petter Selasky
The following reply was made to PR usb/138675; it has been noted by GNATS.

From: Hans Petter Selasky 
To: bug-follo...@freebsd.org,
 jha...@pangolin-systems.com
Cc:  
Subject: usb/138675: [usb8] [panic] page fault, perhaps in USB
Date: Mon, 28 Sep 2009 13:56:38 +0200

 I believe this issue has been fixed. Please close.
 
 --HPS
___
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"


Current problem reports assigned to freebsd-usb@FreeBSD.org

2009-09-28 Thread FreeBSD bugmaster
Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker  Resp.  Description

o usb/139142   usb[regression] ehci drivers (NVIDIA nForce4 USB 2.0 cont
o usb/138915   usb[patch][usb8][usb67] add support for SheevaPlug serial
o usb/138904   usb[rum] unpluging USB wifi card panics system
f usb/138882   usb[ohci] [panic] Can't install FreeBSD 7.2 due to ohci p
o usb/138879   usb[uftdi] [patch] Patch to add support for CTI USB-Mini 
o usb/138798   usb8.0-BETA4 can't boot from USB flash drive
o usb/138675   usb[usb8] [panic] page fault, perhaps in USB
o usb/138659   usb[usb8][uftdi] driver broken in RELENG_8/CURRENT
o usb/138563   usb[usb8] [patch] Increase buffer sizes to accomodate lon
o usb/138389   usb[usb8] [patch] NULL pointer dereference in usb_endpoin
o usb/138175   usb[usb67] [boot] System cannot boot, when USB reader wit
o usb/138172   usbAdditional dev id for u3g (Option mini PCIe)
o usb/138138   usbNovatel U760 for u3g (Verizon and Bell Canada)
o usb/138124   usb[usb8] Axed uaudio functionality in the usbng (alterna
o usb/138119   usbMultiBay CDROM (propably on USB bus) is not recognized
o usb/137872   usbslow booting on usb flash drive
f usb/137848   usbPage fault when using an USB bluetooth adapter
o usb/137806   usb[ukbd] USB keyboard doesn't work until it's unplugged
o usb/137763   usb[usb67][ukbd] Logitech wireless keyboard media keys no
o usb/137616   usb[usb67][usb8][usbdevs] [patch]: usbdevs update: Please
o usb/137377   usb[usb8] Support for Huawei E180
o usb/137341   usb[usb8][rum] driver if_rum doesn't work at all and thro
p usb/137226   usb[usb67][patch] quirk for Philips extern USB disk
o usb/137191   usb[usb8][patch] export ums(4) output report parser data 
o usb/137190   usb[usb8][patch] inhibit spurious button releases for som
o usb/137189   usb[usb8][patch] create and use sysctl nodes for HID repo
p usb/137188   usb[usb8][patch] correctly handle USB report descriptors 
o usb/137129   usbSteelSeries Ikari USB laser mouse not attaching
o usb/137035   usbSony cyber-shot DSC-P72 not accessible - cam quirks
p usb/136761   usb[usbdevs][usb67][patch] Teach usbdevs / u3g(4) about H
o usb/135938   usb[aue] aue driver only passes traffic in promisc mode
f usb/135857   usbRTL8187 Wireless Adapter
o usb/135575   usb[usbdevs] [patch] Add HTC Wizard phone vid/pid informa
o usb/135542   usb[keyboard] boot loader does not work with a usb keyboa
p usb/135372   usb[usb67][umass] Quirk report for Teclast TL-C300 usb me
o usb/135348   usb[umass] USB Drive Hangs with ZFS (JMicron USB2/eSata)
o usb/135206   usbmachine reboots when inserted USB device
o usb/135200   usbSAMSUNG i740 usb mass: Synchronize cache failed, statu
o usb/135182   usbUMASS quirk - Olympus FE20 camera
o usb/134950   usbLowering DTR for USB-modem via ubsa is not possible
o usb/134633   usbAdd support for WILLCOM03(SHARP smart phone)
o usb/134631   usb[usbdevs] [patch] WiSPY DBx support requires usb tweak
o usb/134299   usbKernel Panic plugging in MF626 USB UMTS Stick u3g
o usb/134193   usbSystem freeze on usb MP3 player insertion
o usb/134117   usb[Patch] Add support for 'Option GlobeTrotter HSDPA Mod
o usb/134085   usb[umass] Adding usb quirk for Sony USB flash drive
o usb/133989   usb[newusb] [ukbd] USB keyboard dead at mountroot> prompt
o usb/133712   usb[ural] [patch] RE: Fixed an issue with ural(4) that wa
o usb/133390   usbumass crashes system in 7.1 when Olympus D-540 attache
o usb/133296   usb[rum] driver not working properly in hostap mode
p usb/132799   usb[usb][patch]GENESYS USB2IDE requires NO_SYNCHRONIZE_CA
o usb/132785   usb[usb] [patch] Gemtech remote powersocket is classed as
o usb/132594   usbUSB subsystem causes page fault and crashes
o usb/132312   usbXorg 7.4 halts USB controller
o usb/132080   usb[patch] [usb] [rum] Kernel panic after NOMEM caused by
o usb/132066   usb[ukbd] Keyboard failure USB keyboard DELL 760
o usb/132036   usb[panic] page fault when connecting Olympus C740 camera
o usb/131912   usb[uslcom] [patch] New devices using Silicon Labs chips 
o usb/131900   usb[usbdevs] [patch] Additional product identification co
o usb/131583   usb[umass] Failure when detaching umass Device
o usb/131576   usb[aue] A

Re: usb/138563: commit references a PR

2009-09-28 Thread dfilter service
The following reply was made to PR usb/138563; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: usb/138563: commit references a PR
Date: Mon, 28 Sep 2009 07:41:31 + (UTC)

 Author: thompsa
 Date: Mon Sep 28 07:41:17 2009
 New Revision: 197559
 URL: http://svn.freebsd.org/changeset/base/197559
 
 Log:
   Add support for USB language selection.
   
   PR:  usb/138563
   Reported by: Bruce Cran
   Submitted by:Hans Petter Selasky
 
 Modified:
   head/sys/dev/usb/usb_bus.h
   head/sys/dev/usb/usb_device.c
 
 Modified: head/sys/dev/usb/usb_bus.h
 ==
 --- head/sys/dev/usb/usb_bus.h Mon Sep 28 07:39:51 2009(r197558)
 +++ head/sys/dev/usb/usb_bus.h Mon Sep 28 07:41:17 2009(r197559)
 @@ -98,10 +98,14 @@ struct usb_bus {
uint8_t devices_max;/* maximum number of USB devices */
uint8_t do_probe;   /* set if USB BUS should be re-probed */
  
 +  /* 
 +   * The scratch area can only be used inside the explore thread
 +   * belonging to the give serial bus.
 +   */
union {
struct usb_hw_ep_scratch hw_ep_scratch[1];
struct usb_temp_setup temp_setup[1];
 -  uint8_t data[128];
 +  uint8_t data[255];
}   scratch[1];
  };
  
 
 Modified: head/sys/dev/usb/usb_device.c
 ==
 --- head/sys/dev/usb/usb_device.c  Mon Sep 28 07:39:51 2009
(r197558)
 +++ head/sys/dev/usb/usb_device.c  Mon Sep 28 07:41:17 2009
(r197559)
 @@ -105,9 +105,23 @@ static void   usb_cdev_cleanup(void *);
  
  int   usb_template = 0;
  
 +TUNABLE_INT("hw.usb.usb_template", &usb_template);
  SYSCTL_INT(_hw_usb, OID_AUTO, template, CTLFLAG_RW,
  &usb_template, 0, "Selected USB device side template");
  
 +/* English is default language */
 +
 +static int usb_lang_id = 0x0009;
 +static int usb_lang_mask = 0x00FF;
 +
 +TUNABLE_INT("hw.usb.usb_lang_id", &usb_lang_id);
 +SYSCTL_INT(_hw_usb, OID_AUTO, usb_lang_id, CTLFLAG_RW,
 +&usb_lang_id, 0, "Preferred USB language ID");
 +
 +TUNABLE_INT("hw.usb.usb_lang_mask", &usb_lang_mask);
 +SYSCTL_INT(_hw_usb, OID_AUTO, usb_lang_mask, CTLFLAG_RW,
 +&usb_lang_mask, 0, "Preferred USB language mask");
 +
  static const char* statestr[USB_STATE_MAX] = {
[USB_STATE_DETACHED]= "DETACHED",
[USB_STATE_ATTACHED]= "ATTACHED",
 @@ -1436,7 +1450,7 @@ usb_alloc_device(device_t parent_dev, st
struct usb_device *adev;
struct usb_device *hub;
uint8_t *scratch_ptr;
 -  uint32_t scratch_size;
 +  size_t scratch_size;
usb_error_t err;
uint8_t device_index;
  
 @@ -1682,8 +1696,35 @@ usb_alloc_device(device_t parent_dev, st
if (err || (scratch_ptr[0] < 4)) {
udev->flags.no_strings = 1;
} else {
 -  /* pick the first language as the default */
 -  udev->langid = UGETW(scratch_ptr + 2);
 +  uint16_t langid;
 +  uint16_t pref;
 +  uint16_t mask;
 +  uint8_t x;
 +
 +  /* load preferred value and mask */
 +  pref = usb_lang_id;
 +  mask = usb_lang_mask;
 +
 +  /* align length correctly */
 +  scratch_ptr[0] &= ~1;
 +
 +  /* fix compiler warning */
 +  langid = 0;
 +
 +  /* search for preferred language */
 +  for (x = 2; (x < scratch_ptr[0]); x += 2) {
 +  langid = UGETW(scratch_ptr + x);
 +  if ((langid & mask) == pref)
 +  break;
 +  }
 +  if (x >= scratch_ptr[0]) {
 +  /* pick the first language as the default */
 +  DPRINTFN(1, "Using first language\n");
 +  langid = UGETW(scratch_ptr + 2);
 +  }
 +
 +  DPRINTFN(1, "Language selected: 0x%04x\n", langid);
 +  udev->langid = langid;
}
  
/* assume 100mA bus powered for now. Changed when configured. */
 @@ -2149,34 +2190,35 @@ usbd_set_device_strings(struct usb_devic
  #ifdef USB_VERBOSE
const struct usb_knowndev *kdp;
  #endif
 -  char temp[64];
 +  uint8_t *temp_ptr;
 +  size_t temp_size;
uint16_t vendor_id;
uint16_t product_id;
  
 +  temp_ptr = udev->bus->scratch[0].data;
 +  temp_size = sizeof(udev->bus->scratch[0].data);
 +
vendor_id = UGETW(udd->idVendor);
product_id = UGETW(udd->idProduct);
  
/* get serial number string */
 -  bzero(temp, sizeof(temp));
 -  usbd_req_get_string_any(udev, NULL, temp, sizeof(temp),
 +  usbd_req_get_string_any(udev, NULL, temp_ptr, temp_size,
udev->ddesc.iSerialNumber

Re: usb/138389: commit references a PR

2009-09-28 Thread dfilter service
The following reply was made to PR usb/138389; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: usb/138389: commit references a PR
Date: Mon, 28 Sep 2009 07:40:07 + (UTC)

 Author: thompsa
 Date: Mon Sep 28 07:39:51 2009
 New Revision: 197558
 URL: http://svn.freebsd.org/changeset/base/197558
 
 Log:
   Fix NULL-pointer dereference in usb_endpoint_foreach().
   
   PR:  usb/138389
   Submitted by:Patroklos Argyroudis at census, inc
 
 Modified:
   head/sys/dev/usb/usb_device.c
 
 Modified: head/sys/dev/usb/usb_device.c
 ==
 --- head/sys/dev/usb/usb_device.c  Mon Sep 28 07:32:11 2009
(r197557)
 +++ head/sys/dev/usb/usb_device.c  Mon Sep 28 07:39:51 2009
(r197558)
 @@ -367,12 +367,14 @@ usb_init_endpoint(struct usb_device *ude
  struct usb_endpoint *
  usb_endpoint_foreach(struct usb_device *udev, struct usb_endpoint *ep)
  {
 -  struct usb_endpoint *ep_end = udev->endpoints + udev->endpoints_max;
 +  struct usb_endpoint *ep_end;
  
/* be NULL safe */
if (udev == NULL)
return (NULL);
  
 +  ep_end = udev->endpoints + udev->endpoints_max;
 +
/* get next endpoint */
if (ep == NULL)
ep = udev->endpoints;
 ___
 svn-src-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-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: 8.0-RC1: AMD CS5536 (Geode) USB 2.0 controller strange behavour

2009-09-28 Thread Eugene Grosbein
On Mon, Sep 28, 2009 at 08:49:21AM +0200, Hans Petter Selasky wrote:

> > For USB HDD:
> >
> > %sysctl hw.usb.ehci.debug=15
> > hw.usb.ehci.debug: 0 -> 15
> > %date; dd if=/dev/zero bs=64k of=/dev/da0 count=100; date
> > Mon Sep 28 11:25:26 KRAST 2009
> > 100+0 records in
> > 100+0 records out
> > 6553600 bytes transferred in 14.912198 secs (439479 bytes/sec)
> > Mon Sep 28 11:25:43 KRAST 2009
> >
> > The log is half-megabyte and is available here (13KB compressed):
> >
> > http://www.grosbein.pp.ru/ehci.log.gz
> 
> I don't see any timeouts in there. You need to run the test until you see 
> something about "timeout".

It's so strange... While hw.usb.ehci.debug=15 idle periods are very seldom,
iostat shows nearly constat (but very slow) data rate:

 KB/t tps  MB/s 
 64.00   9  0.57 
 64.00   9  0.57 
 64.00   9  0.57 
 64.00   9  0.57 
 64.00   9  0.57

No 'timeout' word in the log. It seems that debugging changes something.

Eugene Grosbein
___
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"