Centrino Wireless-N 1000 support is also broken (Re: iwn(4) in -HEAD supporting Centrino Wireless-N 135)
Hello, -current members I have a similar problem with Centrino Wireless-N 1000. It operated until r257951 and have a trouble after r258030. I use r262433 kernel with sys/dev/iwn reverted to r257951 and changed from IEEE80211_FC1_WEP to EEE80211_FC1_PROTECTED. r262422 if_iwn module with IWN_DEBUG in opt_iwn.h and dev.iwn.0.debug=1 says: -- output of `dmesg -a` -- iwn0: Intel Centrino Wireless-N 1000 mem 0xd250-0xd2501fff irq 19 at device 0.0 on pci2 wlan0: Ethernet address: 00:1e:64:45:f5:64 iwn0: iwn_setregdomain: invalid channel 8 freq 2447/0x20480 iwn_notif_intr: scanning channel 1 status 1 iwn_notif_intr: scanning channel 6 status 1 iwn_notif_intr: scanning channel 11 status 1 iwn_notif_intr: scanning channel 7 status 1 iwn_notif_intr: scanning channel 13 status 1 iwn_notif_intr: scanning channel 2 status 1 iwn_notif_intr: scanning channel 3 status 1 iwn_notif_intr: scanning channel 4 status 1 iwn_notif_intr: scanning channel 5 status 1 iwn_notif_intr: scanning channel 8 status 1 iwn_notif_intr: scanning channel 9 status 1 iwn_notif_intr: scanning channel 10 status 1 iwn_notif_intr: scanning channel 12 status 1 iwn_tx_data_raw: qid 3 idx 0 len 6 nsegs 1 iwn5000_tx_done: qid 3 idx 0 retries 0 nkill 0 rate 420a duration 778 status 201 iwn_tx_data_raw: qid 3 idx 1 len 86 nsegs 1 iwn5000_tx_done: qid 3 idx 1 retries 0 nkill 0 rate 420a duration 1418 status 201 iwn_set_link_quality: 1stream antenna=0x01, 2stream antenna=0x03, ntxstreams=1 iwn_set_link_quality: i=0, txrate=7, rate=0x87 iwn_set_link_quality: i=1, txrate=6, rate=0x86 iwn_set_link_quality: i=2, txrate=5, rate=0x85 iwn_set_link_quality: i=3, txrate=4, rate=0x84 iwn_set_link_quality: i=4, txrate=3, rate=0x83 iwn_set_link_quality: i=5, txrate=2, rate=0x82 iwn_set_link_quality: i=6, txrate=1, rate=0x81 iwn_set_link_quality: i=7, txrate=0, rate=0x80 iwn_set_link_quality: i=8, txrate=0, rate=0x80 iwn_set_link_quality: i=9, txrate=0, rate=0x80 iwn_set_link_quality: i=10, txrate=0, rate=0x80 iwn_set_link_quality: i=11, txrate=0, rate=0x80 iwn_set_link_quality: i=12, txrate=0, rate=0x80 iwn_set_link_quality: i=13, txrate=0, rate=0x80 iwn_set_link_quality: i=14, txrate=0, rate=0x80 iwn_set_link_quality: i=15, txrate=0, rate=0x80 wlan0: link state changed to UP iwn0: iwn_intr: fatal firmware error firmware error log: error type = SYSASSERT (0x0005) program counter = 0x00018DBC source line = 0x0032 error data = 0x0001 branch link = 0x00018D6E00018D6E interrupt link = 0x0826 time= 1043083265 driver status: tx ring 0: qid=0 cur=0 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=2 queued=0 tx ring 4: qid=4 cur=57 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=55 -- output of `pciconf -lvcb` -- iwn0@pci0:2:0:0:class=0x028000 card=0x13058086 chip=0x00838086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Wireless-N 1000 [Condor Peak]' class = network bar [10] = type Memory, range 64, base 0xd250, size 8192, enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(128) FLR link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 3 corrected ecap 0003[140] = Serial 1 001e6445f564 -- Kaho Toshikazu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: loopback interface broken on current
Hello, There is still ifa_del_loopback_route: deletion failed: 3 that wasn't there before,but the 127.0.0.1 seems to be configured now: Do you have a line like network_interfaces=lo0 bge0 in /etc/rc.conf? If you have it, try to remove it. I think something broken, but people using automatic configuration don't notice the breakage. -- k...@elam.kais.kyoto-u.ac.jp ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: loopback interface broken on current
Hello, If I comment out : ifconfig_bge0=inet 192.168.0.5 netmask 255.255.255.0 Network doesn't work. Yes, you should not commnet out it, you cannot connect from/to outside. network_interfaces=auto is same as /etc/default/rc.conf, so that you can remove it safely from /etc/rc.conf. I cannot identify the problematic line caused the problem. -- vi...@elam.kais.kyoto-u.ac.jp ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: loopback interface broken on current
Hello, I have a similar problem if ifconfig_lo0 line is exist in /etc/rc.conf. Can you remove lo0 configure line from /etc/rc.conf. /etc/rc.conf: ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. -- vi...@elam.kais.kyoto-u.ac.jp ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: no keyboard after booting r235646 in laptop FS Amilo D 7830
Hello, John Baldwin j...@freebsd.org wrote: Almost all systems use one of the IDs we do support as a _CID if not a _HID. In fact, in this case it likely seems to be a BIOS bug as it used the same value for the _CID and _HID. I suspect it is supposed to be using 0303 as its _CID. I don't think the BIOS should say PNP0303 as a keyboard _CID. Using _CID may help some systems, but it may not be helpful for many systems having keyboard probe problem. I think it's a specification bug made by Microsoft, same devices connected different type devices should not have different ID but same ID. http://download.microsoft.com/download/5/7/7/577a5684-8a83-43ae-9272-ff260a9c20e2/pnp_legacy.doc Note that 030B is listed as reserved in this table, and not a valid keyboard device. Yes, it's a invalid type, but reserved as a keyborad. I don't know why the BIOS builder puts PNP030B as a keyboard, but it seems to be not a bug. People with this problem can override AML code, but I don't think it is a bad idea adding other IDs to the list for probing. -- k...@elam.kais.kyoto-u.ac.jp ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: no keyboard after booting r235646 in laptop FS Amilo D 7830
Hello, Interesting question remains: why it works in the older revision r21? I don't know exactly resource management, but ISA_PNP_PROBE() ignores device.hints if acpi unknown device takes resources. I think this problem is related to some acpi changes. -- k...@elam.kais.kyoto-u.ac.jp ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: no keyboard after booting r235646 in laptop FS Amilo D 7830
Hello Matthias Apitz, and ML members,
Thanks to upload acpi dump. Your keyboard controller ID is PNP030B,
and your posted patch may be correct. Please undo your reversion,
and try your patch.
Matthias Apitz g...@unixarea.de wrote:
and there is now an entry for PS2K (not for KBC):
Device (PS2K)
{
Name (_HID, EisaId (PNP030B))
Name (_CID, EisaId (PNP030B))
Method (_STA, 0, NotSerialized)
{
ShiftLeft (0x01, 0x0A, Local0)
If (And (IOST, Local0))
{
Return (0x0F
the full file is here: http://www.unixarea.de/acpidump-r21.txt
maybe it helps to add a line like this:
static struct isa_pnp_id atkbdc_ids[] = {
{ 0x0303d041, Keyboard controller (i8042) }, /* PNP0303 */
{ 0x2003d041, Keyboard controller (i8042) }, /* PNP0320 */
+ { 0x0b03d041, Keyboard controller (i8042) }, /* PNP030B */
{ 0 }
--
k...@elam.kais.kyoto-u.ac.jp
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: no keyboard after booting r235646 in laptop FS Amilo D 7830
Hello John Baldwin, and all, John Baldwin j...@freebsd.org wrote: The system in general in 9.0 and later is more strict about honoring what the BIOS says in terms of allocating resources, so we have to be more correct in probing devices. The only wrinkles so far do in fact seem to stem from the keyboard controller. I don't have any plans for treating unknown ID device's resources. Many keyboard PNP ID are listed on a file at the below URL, and FreeBSD doesn't know almost of them. http://download.microsoft.com/download/5/7/7/577a5684-8a83-43ae-9272-ff260a9c20e2/pnp_legacy.doc -- k...@elam.kais.kyoto-u.ac.jp ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: no keyboard after booting r235646 in laptop FS Amilo D 7830
Hello, Can you put the file acpidump-r21.txt on the Internet? When you run `grep Device /tmp/acpidump-r21.txt` to get device list, can you find PS2K or KBC or similar word? Matthias Apitz g...@unixarea.de wrote: The command `acpidump -dt` in both releases (r21 and r235646) gives an error: # acpidump -dt /tmp/acpidump-r21.txt acpidump: RSDT entry 2 (sig OEMB) is corrupt the output in r235646 is only some 70 lines and in r21 I do not see any keyboard related; so I can't answer your question if the keyboard controller is PNP0303; Based on r235646 sources, I have checked the SVN-diff between r21 (where the keyboard is working) and r235646, see attachment /tmp/atkbdc_isa.c-r21:r235646; and the logic of the kb detection has changed; I will just give it a try and will revert this SVN change, i.e. 'svn up -r r21 atkbdc_isa.c to see if this works... it does not help; Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: no keyboard after booting r235646 in laptop FS Amilo D 7830
Hello Matthias Apitz and -current member, sys/dev/atkbdc/atkbdc_isa.c may not have your keyboard controller's ID. Run `acpidump -dt` and search your keyboard description. Is your keyboard controller PNP0303 ? -- k...@ed.niigata-u.ac.jp El d$(D+c*$(B Sunday, July 01, 2012 a las 06:29:28AM +0700, Erich Dollansky escribi$(D+Qk(B Hi, and no older versions. I will install the USB booted system to harddisk and hope when booted from disk and not from USB the keyboard is working. I installed the system r235646 to disk and it shows the same problem: no keyboard; if 7.4 still runs but not anything after 8.0, it is most likely what I have written. Some USB hardware is not supported anymore in 8 and later. I would install the old one just to see You will also know wat hwardware is used there and how it is supported. This might be the faster route before starting debugging something which is not there. I said already that it works with a r21 version, CURRENT from October 2010; so I booted this again and concerning keyboard, here is the diff: r21: $ fgrep -i kb /tmp/dmesg-r21.txt kbd1 at kbdmux0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: PS/2 Mouse irq 12 on atkbdc0 $ ls -l /dev/kb* lrwxr-xr-x 1 root wheel 6 Jul 1 08:39 /dev/kbd0 - atkbd0 lrwxr-xr-x 1 root wheel 7 Jul 1 08:39 /dev/kbd1 - kbdmux0 crw--- 1 root wheel0, 17 Jul 1 08:39 /dev/kbdmux0 r235646: $ fgrep -i kb /tmp/dmesg-r235646.txt atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) atkbdc0 failed to probe at port 0x60 on isa0 $ ls -l /dev/kb* lrwxr-xr-x 1 root wheel 7 Jul 1 08:39 /dev/kbd1 - kbdmux0 crw--- 1 root wheel0, 17 Jul 1 08:39 /dev/kbdmux0 the complete /tmp/dmesg-r21.txt is attached, the /tmp/dmesg-r235646.txt was in some message of this thread; So the question is: why the Keyboard controller (i8042) is not detected anymore in r235646, while it is in r21? Thanks matthias ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB Flash drive problem with 9.0
Hello Alexander Motin,
Your patch solves the problem. Thank you.
--
Kaho Toshikazu
On 03/31/12 07:57, Kaho Toshikazu wrote:
Could you collect more information about what's exactly happens
with the device? Can you execute some camcontrol inquiry or
camcontrol readcap commands after kernel misdetected size with
READ CAPACITY(16)?
If yes (device is still alive), could you run these commands
(with proper device name) and send me the output files:
camcontrol cmd da0 -E -v -c 12 00 00 00 80 00 -i 128 - INQ.res
camcontrol cmd da0 -E -v -c 9e 10 00 00 00 00 00 00 00 00 00 00
00 20 00 00 -i 32 - RC16.result
usbconfig -d 0.3 dump_device_desc
ugen0.3:Mass Storage Device JetFlash at usbus0, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON
bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x
bDeviceSubClass = 0x
bDeviceProtocol = 0x
bMaxPacketSize0 = 0x0040
idVendor = 0x8564
idProduct = 0x1000
bcdDevice = 0x1100
iManufacturer = 0x0001JetFlash
iProduct = 0x0002Mass Storage Device
iSerialNumber = 0x000383CA7S8M3LD8UGSF
bNumConfigurations = 0x0001
-- dmesg without any quirks --
ugen0.3:JetFlash at usbus0
umass0:JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3
on usbus0
da0 at umass-sim0 bus 0 scbus11 target 0 lun 0
da0:JetFlash Transcend 16GB 1100 Removable Direct Access SCSI-4 device
da0: 40.000MB/s transfers
da0: 17454747090944MB (71776119061217281 512 byte sectors: 64H 32S/T 0C)
hexdump -Cv RC16.result
00 ff 00 00 00 00 00 00 00 00 02 00 00 00 00 00
||
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
||
0020
`hexdump -Cv INQ.res`
00 80 04 02 1f 73 6d 69 4a 65 74 46 6c 61 73 68
|.smiJetFlash|
0010 54 72 61 6e 73 63 65 6e 64 20 31 36 47 42 20 20 |Transcend 16GB
|
0020 31 31 30 30 00 80 02 00 00 00 00 00 00 00 00 00
|1100|
0030 00 00 00 00 00 00 28 00 03 01 82 06 00 3f 00 00
|..(..?..|
0040 00 00 28 32 00 00 00 00 00 00 00 50 50 00 00 00
|..(2...PP...|
0050 30 50 50 00 00 00 00 00 00 00 00 21 84 84 21 1e
|0PP!..!.|
0060 00 03 48 00 00 c0 00 00 00 00 00 00 00 00 00 00
|..H..@..|
0070 00 00 00 00 00 00 01 00 24 15 01 09 00 00 00 00
|$...|
0080
-- dmesg with UQ_MSC_NO_INQUIRY --
ugen0.3:JetFlash at usbus0
umass0:JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3
on usbus0
da0 at umass-sim0 bus 0 scbus11 target 0 lun 0
da0: Removable Direct Access SCSI-2 device
da0: 40.000MB/s transfers
da0: 15477MB (31696896 512 byte sectors: 255H 63S/T 1973C)
Hmm, READ CAPACITY(16) can be used and device is alive.
With UQ_MSC_NO_INQUIRY, after run camcontrol, dd can read normally.
Without UQ_MSC_NO_INQUIRY, camcontrol can return something,
but dd can not be usable.
Thank you.
I see number of inconsistencies there. Device reports support
for SPC-2
spec, but has PROTECT bit set in INQUIRY data, which is defined
only since SPC-3 and reserved in SPC-2. Protection information,
same as READ CAPACITY(16) command, defined only from
SPC-3. SPC-2 devices should not know about it, returning error,
but this device doesn't return error, instead returning
something strange (correct sector size, but wrong number of
sectors).
I see the only clean solution in following specs more closely
and not checking PROTECT bit for pre-SPC-3 devices. I don't know
why Linux does for all SCSI-3/SPC devices, but for this device
result is fatal.
Please try the following patch. It should disable use of READ
CAPACITY(16) in your case.
--- scsi_da.c (revision 233697)
+++ scsi_da.c (working copy)
@@ -1631,9 +1631,7 @@
softc-minimum_cmd_size = 16;
/* Predict whether device may support READ CAPACITY(16). */
- if (SID_ANSI_REV(cgd-inq_data) = SCSI_REV_SPC3 ||
- (SID_ANSI_REV(cgd-inq_data) = SCSI_REV_SPC
-(cgd-inq_data.spc3_flags SPC3_SID_PROTECT))) {
+ if (SID_ANSI_REV(cgd-inq_data) = SCSI_REV_SPC3) {
softc-flags |= DA_FLAG_CAN_RC16;
softc-state = DA_STATE_PROBE2;
}
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB Flash drive problem with 9.0
Hello Alexander Motin, Could you collect more information about what's exactly happens with the device? Can you execute some camcontrol inquiry or camcontrol readcap commands after kernel misdetected size with READ CAPACITY(16)? If yes (device is still alive), could you run these commands (with proper device name) and send me the output files: camcontrol cmd da0 -E -v -c 12 00 00 00 80 00 -i 128 - INQ.res camcontrol cmd da0 -E -v -c 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00 -i 32 - RC16.result usbconfig -d 0.3 dump_device_desc ugen0.3: Mass Storage Device JetFlash at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x8564 idProduct = 0x1000 bcdDevice = 0x1100 iManufacturer = 0x0001 JetFlash iProduct = 0x0002 Mass Storage Device iSerialNumber = 0x0003 83CA7S8M3LD8UGSF bNumConfigurations = 0x0001 -- dmesg without any quirks -- ugen0.3: JetFlash at usbus0 umass0: JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3 on usbus0 da0 at umass-sim0 bus 0 scbus11 target 0 lun 0 da0: JetFlash Transcend 16GB 1100 Removable Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 17454747090944MB (71776119061217281 512 byte sectors: 64H 32S/T 0C) hexdump -Cv RC16.result 00 ff 00 00 00 00 00 00 00 00 02 00 00 00 00 00 || 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0020 `hexdump -Cv INQ.res` 00 80 04 02 1f 73 6d 69 4a 65 74 46 6c 61 73 68 |.smiJetFlash| 0010 54 72 61 6e 73 63 65 6e 64 20 31 36 47 42 20 20 |Transcend 16GB | 0020 31 31 30 30 00 80 02 00 00 00 00 00 00 00 00 00 |1100| 0030 00 00 00 00 00 00 28 00 03 01 82 06 00 3f 00 00 |..(..?..| 0040 00 00 28 32 00 00 00 00 00 00 00 50 50 00 00 00 |..(2...PP...| 0050 30 50 50 00 00 00 00 00 00 00 00 21 84 84 21 1e |0PP!..!.| 0060 00 03 48 00 00 c0 00 00 00 00 00 00 00 00 00 00 |..H..@..| 0070 00 00 00 00 00 00 01 00 24 15 01 09 00 00 00 00 |$...| 0080 -- dmesg with UQ_MSC_NO_INQUIRY -- ugen0.3: JetFlash at usbus0 umass0: JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3 on usbus0 da0 at umass-sim0 bus 0 scbus11 target 0 lun 0 da0:Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 15477MB (31696896 512 byte sectors: 255H 63S/T 1973C) Hmm, READ CAPACITY(16) can be used and device is alive. With UQ_MSC_NO_INQUIRY, after run camcontrol, dd can read normally. Without UQ_MSC_NO_INQUIRY, camcontrol can return something, but dd can not be usable. -- Kaho Toshikazu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB Flash drive problem with 9.0
Hello, Andriy Gapon and ML members, Date: Sun, 25 Mar 2012 13:15:26 +0300 on 25/03/2012 08:02 Kaho Toshikazu said the following: Hello Andriy Gapon, Thank you for your comment. Message-ID: 4f6d9672.4050...@freebsd.org Date: Sat, 24 Mar 2012 11:40:02 +0200 on 24/03/2012 04:17 Kaho Toshikazu said the following: Hello, I have a similar problem with Transcend 16GB USB flash. When the flash is plugged, FreeBSD attache it, but reports very big capacity and can not read/write it. UQ_MSC_NO_INQUIRY makes jobs in my machines. 10-current and 8-stable have same problem, and 9-stable is not tested. Could the problem be related to r229288 (r232943 in stable/9)? The dates below match the MFC date 2012-03-13. 10-current r26 with reveting only scsi_da.c changed by r233288 has same problem. Should I revert whole system ? Sorry, it seems that I copied wrong revisions into my email. They should have been r232941 for stable/9 and r228846 for head. Yes, r228846 for current is related this problem. 10-current reverting scsi/scsi_da.c introduced by r228846 detects valid capacity and can read/write USB flash. USB flash may be died of READ CAPACITY(16). -- Andriy Gapon -- Kaho Toshikazu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB Flash drive problem with 9.0
Hello Andriy Gapon, Thank you for your comment. Message-ID: 4f6d9672.4050...@freebsd.org Date: Sat, 24 Mar 2012 11:40:02 +0200 on 24/03/2012 04:17 Kaho Toshikazu said the following: Hello, I have a similar problem with Transcend 16GB USB flash. When the flash is plugged, FreeBSD attache it, but reports very big capacity and can not read/write it. UQ_MSC_NO_INQUIRY makes jobs in my machines. 10-current and 8-stable have same problem, and 9-stable is not tested. Could the problem be related to r229288 (r232943 in stable/9)? The dates below match the MFC date 2012-03-13. 10-current r26 with reveting only scsi_da.c changed by r233288 has same problem. Should I revert whole system ? -- Kaho Toshikazu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB Flash drive problem with 9.0
Hello, I have a similar problem with Transcend 16GB USB flash. When the flash is plugged, FreeBSD attache it, but reports very big capacity and can not read/write it. UQ_MSC_NO_INQUIRY makes jobs in my machines. 10-current and 8-stable have same problem, and 9-stable is not tested. -- Kaho Toshikazu -- To: freebsd-...@freebsd.org Subject: Re: USB Flash drive problem with 9.0 From: Hans Petter Selasky hsela...@c2i.net Date: Fri, 23 Mar 2012 08:25:32 +0100 Cc: Alexander Motin m...@freebsd.org, freebsd-current@freebsd.org, J.J. Day day1...@hotmail.com On Friday 23 March 2012 06:14:08 J.J. Day wrote: I am upgrading a FreeBSD server and have encountered a problem with mounting a USB flash drive. The system was on 6.3 and I upgraded to 9.0 using CVS repositories. The flash drive worked properly at all steps throughout the upgrade. However, after the OS upgrade was complete, I made a mistake and destroyed some of the server application. So, I set the upgraded drive aside, copied the original source drive to a different spare, and repeated the upgrade process taking care to verify the functioning of the applications during the process. When I finished the second time, everything worked properly except for mounting the flash drive. it appears that something changed with the OS code that reads the drive firmware between the first time I ran cvsup on (about) the 9th and the second time I ran it about the 18th. This is the output from the first upgrade (3/11/2012) when the drive is inserted: ugen4.2: HP at usbus4 umass0: HP v165w, class 0/0, rev 2.00/32.76, addr 2 on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:2:0:-1: Attached to scbus2 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: hp v165w 3276 Removable Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 30960MB (63406080 512 byte sectors: 255H 63S/T 3946C) And diskinfo output: da0 512 # sectorsize 32463912960 # mediasize in bytes (30G) 63406080# mediasize in sectors 0 # stripesize 0 # stripeoffset 3946# Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. AA22064F0035# Disk ident. This is the output from the second upgrade (3/18/2012) when the drive is inserted: ugen4.2: HP at usbus4 umass0: HP v165w, class 0/0, rev 2.00/32.76, addr 2 on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:2:0:-1: Attached to scbus2 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: hp v165w 3276 Removable Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 17454747090944MB (71776119061217281 512 byte sectors: 64H 32S/T 0C) And diskinfo shows: Hi, da0 512 # sectorsize -144115188075855360 # mediasize in bytes () -281474976710655# mediasize in sectors 0 # stripesize 0 # stripeoffset -137438953471 # Cylinders according to firmware. 64 # Heads according to firmware. 32 # Sectors according to firmware. AA22064F0035# Disk ident. Since the size information is incorrect, the /dev/da0s1 device is not created and the drive cannot be mounted. The problem only happens with a large drive. When I use a 4GB or 8GB drive, everything works correctly. If there is any information that I can submit that can assist in solving the problem please let me know. This does not look like a USB problem. It is the SCSI/CAM layer which queries over SCSI USB how big the disk is. BTW: dec2hex(17454747090944) ans = FE0 So it looks like some additional bits have sneaked in there? dec2hex(32463912960) ans = 78F00 0xFE0 / 0x78F00 ans = 537.67 So it looks like the mediasize was multiplied by 512 when it shouldn't. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
