Re: scsi_da quirk for a device with no name
This is me again on the issue of a weird umass device that reports empty strings to SCSI inquiry command. Currently the only way to specify some SCSI-level quirk for such a device is to create a quirk entry with all fields set to wildcard *, but apparently such a quirk would be applied to many more devices. A suggestion: what about umass intercepting a response of inquiry command and generating some names in such a case. E.g. vendor and product identification could be generated from the USB ids like Vendor_abcd, Product_1234. In this case we would get some sufficient identification for such devices. P.S. it also seems that if NO_INQUIRY umass quirk is specified for a device, then its identification will be empty as well. I think that this is not good because, for example, scsi_da quirks are troublesome then. P.P.S. it is currently impossible to have scsi_da quirk entries with empty fields (), they get ignored. on 16/08/2007 15:22 Andriy Gapon said the following: I have ASUS P535 PPC+phone with Windows Mobile 5 on it. It has an option to act as a USB mass storage (instead of attempting acivesync). When I tried it, it first got recognized by umass and then it immediately panicked my system. From messages: kernel: umass0: ASUS Generic Mass Storage, rev 2.00/0.00, addr 3 kernel: da0 at umass-sim0 bus 0 target 0 lun 0 kernel: da0:Removable Direct Access SCSI-0 device kernel: da0: 1.000MB/s transfers kernel: da0: 1952MB (3998720 512 byte sectors: 255H 63S/T 248C) From panic (typed from memory): umass0: Invalid CSW: tag 7 should be 8 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x0, scsi status == 0x4 I googled up several reports of similar and not so similar panics. Here's a small overview that is not directly related to a question that I really want to ask: 1. Invalid CSW problems where a signature is wrong, I see that WRONG_CSWSIG umass quirk is recommended for that; 2. Invalid CSW problems where a tag is wrong and the values are very different, I see that one person attempted to cure that with a new hand-rolled quirk to simply ignore the mismatch; 3. Invalid CSW problems where a tag is wrong and the difference is exactly one. I don't know if there is anything special about that, but it looks the most interesting of all the cases. In some cases but not all Invalid CSW comes together with Synchronize cache failed and DA_Q_NO_SYNC_CACHE scsi_da quirk is recommended for that. So I attempted the latter quirk and it helped me! But there is one not good thing about the way I did that - I used wild cards (*) for all three of vendor, product and revision. This is because they all appear to be empty/unset. This is shown in both kernel messages and by camcontrol devlist and by camcontrol inquiry. I am not sure if there are any risks of applying the quirk to all possible da devices, there will be only umass ones in my case, but I still would like to do something more specific to the device in question. Will empty patterns work ? I mean if I put , , entry into the quirk array. Actually, I can test this myself soon, but not today. Thank you. P.S. some links to the problems that others have reported: http://www.freebsd.org/cgi/query-pr.cgi?pr=114916cat= http://osdir.com/ml/os.freebsd.devel.usb/2005-12/msg00039.html http://lists.freebsd.org/pipermail/freebsd-bugs/2004-November/010483.html http://lists.freebsd.org/pipermail/freebsd-bugs/2004-January/005170.html http://lists.freebsd.org/mailman/htdig/freebsd-usb/2004-December/000318.html http://lists.freebsd.org/mailman/htdig/freebsd-usb/2005-February/000660.html -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
usb/119945: rum device in hostap mode, cause kernel core dump.
Number: 119945
Category: usb
Synopsis: rum device in hostap mode, cause kernel core dump.
Confidential: no
Severity: serious
Priority: low
Responsible:freebsd-usb
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Thu Jan 24 16:40:02 UTC 2008
Closed-Date:
Last-Modified:
Originator: Y.Okabe
Release:7.0-PRERELEASE
Organization:
Environment:
FreeBSD 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE
CPU: VIA C7 Esther+RNG+AES+AES-CTR+SHA1+SHA256+RSA (1500.00-MHz 686-class CPU)
Origin = CentaurHauls Id = 0x6d0 Stepping = 0
Features=0xa7c9bbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CLFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE
Features2=0x4181SSE3,EST,TM2,xTPR
dmesg follow:
uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb4
uhub4: 8 ports with 8 removable, self powered
rum0: buffalo WLI-U2-SG54HP, class 0/0, rev 2.00/0.01, addr 2 on uhub4
rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528
rum0: Ethernet address: 00:16:xx:xx:xx:xx
rum0: if_start running deferred for Giant
Description:
I made rum device into hostap mode.
When receive some packet by rum device,
kernel was panic and core dumped at module uhci.ko.
How-To-Repeat:
1. install GENERIC kernel for RENENG_7,
2. configure hostapd using rum0.
3. setup rum0 and wired lan ingerface bridge
i.e. run ifconfig bridge0 create
run ifconfig bridge0 addm rum0 addm eth0
run ifconfig bridge0 inet 192.168.1.9/24
4. run hostapd.
5. accsess wlan client this hostap accces point
(by WPA-PSK, WPA-AES, WPA2-AES, etc...)
6. some packet send, kernel panic.
Fix:
rum_free_tx_list function on if_rum.c , at the OpenBSD current source is
--- openbsd if_rum.c start
void
rum_free_tx_list(struct rum_softc *sc)
{
int i;
for (i = 0; i RUM_TX_LIST_COUNT; i++) {
struct rum_tx_data *data = sc-tx_data[i];
if (data-xfer != NULL) {
usbd_free_xfer(data-xfer);
data-xfer = NULL;
}
/*
* The node has already been freed at that point so don't call
* ieee80211_release_node() here.
*/
data-ni = NULL;
}
}
--- openbsd if_rum.c end
therefor, freebsd's rum_free_tx_list function at if_rum.c
/usr/src/sys/dev/usb/if_rum.c at line 650
static void
rum_free_tx_list(struct rum_softc *sc)
{
struct rum_tx_data *data;
int i;
for (i = 0; i RUM_TX_LIST_COUNT; i++) {
data = sc-tx_data[i];
if (data-xfer != NULL) {
usbd_free_xfer(data-xfer);
data-xfer = NULL;
}
if (data-ni != NULL) {
- ieee80211_free_node(data-ni);
+ /*ieee80211_free_node(data-ni);*/
data-ni = NULL;
}
}
}
I don't know this patch's work reason.
but, hostapd can work at patched kernel.
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 [EMAIL PROTECTED]
pre-2.0 USB rev ehci problem
Hi, I have a AMD Geode (embedded platform) based hardware with problems in EHCI. Here's an excerpt from dmesg: ohci0: OHCI (generic) USB controller mem 0xe0215000-0xe0215fff irq 11 at device 15.4 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 4 ports with 4 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xe0216000-0xe0216fff irq 11 at device 15.5 on pci0 ehci0: pre-2.0 USB rev device_attach: ehci0 attach returned 6 USB 1.0 works fine with cca 1 MB/s transfer rate from a flash memory drive. EHCI capability works fine in Linux. Here's an excerpt from pciconf -lv: [EMAIL PROTECTED]:0:15:4: class=0x0c0310 card=0x20941022 chip=0x20941022 rev=0x02 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'CS5536 CS5536 OHCI USB Host Controller' class = serial bus subclass = USB [EMAIL PROTECTED]:0:15:5: class=0x0c0320 card=0x20951022 chip=0x20951022 rev=0x02 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'CS5536 CS5536 EHCI USB Host Controller' class = serial bus subclass = USB Since it works in Linux, I suppose there should be some relatively simple quirks to make it work. Any ideas on what should I try? signature.asc Description: OpenPGP digital signature
