Re: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
On Wed, Sep 4, 2019 at 5:12 AM Guenter Roeck wrote: > > Note that I don't object to the patch set in general. There may be symbols > which only need be exported in the context of a single subsystem or even > driver (if a driver consists of more than one module). For example, a mfd > driver may export symbols which should only be called by its client drivers. > In such a situation, it may well be beneficial to limit the use of exported > symbols. I can appreciate this benefit. > I am not sure what good that does in practice (if I understand correctly, > a driver only has to declare that it wants to use a restricted use symbol > if it wants to use it), but that is a different question. I think this question implies that you are coming from the perspective of "security" or wanting to restrict access to the underlying functions, rather than wanting to clean-up the way symbols are handled for manageability / maintainability purposes (which is the goal, as I understand it). HOWEVER, I have one question: If these patches are included, and someone wants to introduce a bit of code which needs to use two symbols from different namespaces but with the same name, can that be done? That is, if driver A has symbol 'foo' and driver B has symbol 'foo' (both in their respective namespaces), and driver C wants to use A.foo and B.foo, can that be supported? Matt -- Matthew Dharm Former Maintainer, USB Mass Storage driver for Linux
Re: [PATCH] Add Apple Carplay driver
Why is this a kernel-level driver, rather than a userspace application that uses libusb to send the single vendor-specific command required? Since this command would be applicable to many CarPlay devices, with many different VID/PIDs, it would seem to make more sense as a userspace app that took a reference to a USB device or VID/PID. Matt On Tue, Mar 13, 2018 at 11:02 PM, Chunfeng Yun <chunfeng@mediatek.com> wrote: > From bf48dcd9cb254576cfea373c9a5d2ab996408895 Mon Sep 17 00:00:00 2001 > From: Chunfeng Yun <chunfeng@mediatek.com> > Date: Tue, 13 Mar 2018 11:47:38 +0800 > Subject: [PATCH] Add Apple Carplay driver > > Some Apple devices which support Carplay can enter USB Host Mode from USB > Device Mode after receiving a specific USB Vendor Request. There is a > requirement apply to accesssories that support the USB dual role switch > feature, and must have a USB-A receptacle that is capable of functioning > in both USB Host and USB Device roles. > It means that the driver should supports manual Dual-Role switch, due to > no IDDIG pin is avaliable. > > There is no suitable place to add this spicific USB Vendor Request, so > here I extract a single driver which allow user force to send it by a debug > interface when need it, and keep it independent on USB Dual-Role Controller > Drivers. > But to implement carplay feature, there are some requirments for USB Dual-Role > Driver: > 1. supports manual dual-role switch, such as, by a debug interface; > 2. keep vbus alive even when switch host into device mode; > > More information please refer to "Chapter 46. USB Role Switch" in > MFI Accessroy Interface Specification.pdf > > Chunfeng Yun (1): > usb: misc: supports Apple Carplay driver > > drivers/usb/misc/Kconfig |9 +++ > drivers/usb/misc/Makefile |1 + > drivers/usb/misc/carplay.c | 193 > > 3 files changed, 203 insertions(+) > create mode 100644 drivers/usb/misc/carplay.c > > -- > 1.7.9.5 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Matthew Dharm Former Maintainer, USB Mass Storage driver for Linux
Re: [PATCH] Add Apple Carplay driver
Why is this a kernel-level driver, rather than a userspace application that uses libusb to send the single vendor-specific command required? Since this command would be applicable to many CarPlay devices, with many different VID/PIDs, it would seem to make more sense as a userspace app that took a reference to a USB device or VID/PID. Matt On Tue, Mar 13, 2018 at 11:02 PM, Chunfeng Yun wrote: > From bf48dcd9cb254576cfea373c9a5d2ab996408895 Mon Sep 17 00:00:00 2001 > From: Chunfeng Yun > Date: Tue, 13 Mar 2018 11:47:38 +0800 > Subject: [PATCH] Add Apple Carplay driver > > Some Apple devices which support Carplay can enter USB Host Mode from USB > Device Mode after receiving a specific USB Vendor Request. There is a > requirement apply to accesssories that support the USB dual role switch > feature, and must have a USB-A receptacle that is capable of functioning > in both USB Host and USB Device roles. > It means that the driver should supports manual Dual-Role switch, due to > no IDDIG pin is avaliable. > > There is no suitable place to add this spicific USB Vendor Request, so > here I extract a single driver which allow user force to send it by a debug > interface when need it, and keep it independent on USB Dual-Role Controller > Drivers. > But to implement carplay feature, there are some requirments for USB Dual-Role > Driver: > 1. supports manual dual-role switch, such as, by a debug interface; > 2. keep vbus alive even when switch host into device mode; > > More information please refer to "Chapter 46. USB Role Switch" in > MFI Accessroy Interface Specification.pdf > > Chunfeng Yun (1): > usb: misc: supports Apple Carplay driver > > drivers/usb/misc/Kconfig |9 +++ > drivers/usb/misc/Makefile |1 + > drivers/usb/misc/carplay.c | 193 > > 3 files changed, 203 insertions(+) > create mode 100644 drivers/usb/misc/carplay.c > > -- > 1.7.9.5 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Matthew Dharm Former Maintainer, USB Mass Storage driver for Linux
Re: [usb-storage] Re: [opensuse-factory] huawei usb dongle e173 not working on tumbleweed
(Ron replied separately with kernel versions and usb_modeswitch versions.) Ron, it appears that while Tumbleweed upgraded the kernel version, it didn't upgrade the usb_modeswitch version. You probably need a newer version to support that device. I just checked http://www.draisberghof.de/usb_modeswitch/ and the current version (2.0.1) has support for your device. You will either need to update your usb_modeswitch manually or get the Tumbleweed maintainers to do so. Matt On Thu, Oct 3, 2013 at 4:57 PM, Matthew Dharm wrote: > Ron -- > > We're going to need the version numbers of both the kernel and the > usb_modeswitch utility from both openSUSE 12.3 and Tumbleweed if we're > going to make any sense of the situation. > > Matt > > On Thu, Oct 3, 2013 at 4:50 PM, Ron Brickle wrote: >> On Thu, 2013-10-03 at 12:07 -0500, Larry Finger wrote: >>> On 10/03/2013 02:13 AM, Ron Brickle wrote: >>> > On Wed, 2013-10-02 at 22:56 -0500, Larry Finger wrote: >>> >> On 10/02/2013 09:02 PM, Ron Brickle wrote: >>> >>> Hi I have been trying to get my huawei usb dongle working on Tumbleweed >>> >>> but to no avail so in desperation I am sending this email. it works >>> >>> fine on 12.3 opensuse so hopefully you can fix this problem I tried to >>> >>> get it working from help from the tumbleweed forum it is recognized in >>> >>> lsusb but doesn show in network-manager >>> >>> regards and thanks Ron Brickle >>> >> >>> >> Firmware? >>> >> >>> >> A device present in lsusb only means that it is connected to the USB >>> >> system. For >>> >> NM to have it, any firmware must be present, the wifi-enable switch for >>> >> *ALL* >>> >> devices must be on, the device must be recognized by some driver, and >>> >> that >>> >> driver must load and initialize correctly. From the information you >>> >> provided, it >>> >> is impossible to tell where it is failing. >>> >> >>> >> Larry >>> >> >>> >> Hi i just put this in terminal as normal user then as root >>> > >>> > rpm -ql usb_modeswitch-data|grep 1446 >>> > it returns no answer and it should be this I am told if so the driver >>> > isnt installed for this usb modem TargetVendor= 0x12d1 >>> > TargetProductList="1001,1406,140b,140c,1412,141b,1433,1436,14ac,1506" >>> > >>> > MessageContent="55534243123456780011062001" >>> > is this any help >>> > regards ron >>> > lsusb gives thisron@desktop:~> rpm -ql usb_modeswitch-data|grep 1446 >>> > ron@desktop:~> lsusb >>> > Bus 001 Device 002: ID 8087:8008 Intel Corp. >>> > Bus 002 Device 002: ID 8087:8000 Intel Corp. >>> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> > Bus 001 Device 003: ID 046d:0809 Logitech, Inc. Webcam Pro 9000 >>> > Bus 002 Device 003: ID 174c:2074 ASMedia Technology Inc. >>> > Bus 002 Device 004: ID 2109:2812 >>> > Bus 002 Device 007: ID 12d1:1446 Huawei Technologies Co., Ltd. >>> > E1552/E1800/E173 (HSPA modem) >>> > Bus 002 Device 005: ID 046d:c526 Logitech, Inc. Nano Receiver >>> > Bus 002 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver >>> > and usb-devices gives this >>> > Bus=02 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 >>> > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 >>> > P: Vendor=12d1 ProdID=1446 Rev=00.00 >>> > S: Manufacturer=HUAWEI Technology >>> > S: Product=HUAWEI Mobile >>> > C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA >>> > I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 >>> > Driver=usb-storage >>> > I: If#= 1 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 >>> > Driver=usb-storage >>> > thanks for your reply regards ron >>> >>> From the usb-devices output, the device obviously needs to be mode >>> switched. >>> >>> There may be a regression from the openSUSE 12.3 kernel (probably 3.7) to >>> the >>> one used by Tumbleweed. The usb-storage drivers are maintinaed by Matthew >>> Dharm >>> . I suggest you contact him with a Cc to >>> linux-...@vger.kernel.org, usb-stor...@lists.one-eyed-alien.
Re: [usb-storage] Re: [opensuse-factory] huawei usb dongle e173 not working on tumbleweed
(Ron replied separately with kernel versions and usb_modeswitch versions.) Ron, it appears that while Tumbleweed upgraded the kernel version, it didn't upgrade the usb_modeswitch version. You probably need a newer version to support that device. I just checked http://www.draisberghof.de/usb_modeswitch/ and the current version (2.0.1) has support for your device. You will either need to update your usb_modeswitch manually or get the Tumbleweed maintainers to do so. Matt On Thu, Oct 3, 2013 at 4:57 PM, Matthew Dharm mdharm-...@one-eyed-alien.net wrote: Ron -- We're going to need the version numbers of both the kernel and the usb_modeswitch utility from both openSUSE 12.3 and Tumbleweed if we're going to make any sense of the situation. Matt On Thu, Oct 3, 2013 at 4:50 PM, Ron Brickle rb19...@gmail.com wrote: On Thu, 2013-10-03 at 12:07 -0500, Larry Finger wrote: On 10/03/2013 02:13 AM, Ron Brickle wrote: On Wed, 2013-10-02 at 22:56 -0500, Larry Finger wrote: On 10/02/2013 09:02 PM, Ron Brickle wrote: Hi I have been trying to get my huawei usb dongle working on Tumbleweed but to no avail so in desperation I am sending this email. it works fine on 12.3 opensuse so hopefully you can fix this problem I tried to get it working from help from the tumbleweed forum it is recognized in lsusb but doesn show in network-manager regards and thanks Ron Brickle Firmware? A device present in lsusb only means that it is connected to the USB system. For NM to have it, any firmware must be present, the wifi-enable switch for *ALL* devices must be on, the device must be recognized by some driver, and that driver must load and initialize correctly. From the information you provided, it is impossible to tell where it is failing. Larry Hi i just put this in terminal as normal user then as root rpm -ql usb_modeswitch-data|grep 1446 it returns no answer and it should be this I am told if so the driver isnt installed for this usb modem TargetVendor= 0x12d1 TargetProductList=1001,1406,140b,140c,1412,141b,1433,1436,14ac,1506 MessageContent=55534243123456780011062001 is this any help regards ron lsusb gives thisron@desktop:~ rpm -ql usb_modeswitch-data|grep 1446 ron@desktop:~ lsusb Bus 001 Device 002: ID 8087:8008 Intel Corp. Bus 002 Device 002: ID 8087:8000 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 046d:0809 Logitech, Inc. Webcam Pro 9000 Bus 002 Device 003: ID 174c:2074 ASMedia Technology Inc. Bus 002 Device 004: ID 2109:2812 Bus 002 Device 007: ID 12d1:1446 Huawei Technologies Co., Ltd. E1552/E1800/E173 (HSPA modem) Bus 002 Device 005: ID 046d:c526 Logitech, Inc. Nano Receiver Bus 002 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver and usb-devices gives this Bus=02 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=12d1 ProdID=1446 Rev=00.00 S: Manufacturer=HUAWEI Technology S: Product=HUAWEI Mobile C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage I: If#= 1 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage thanks for your reply regards ron From the usb-devices output, the device obviously needs to be mode switched. There may be a regression from the openSUSE 12.3 kernel (probably 3.7) to the one used by Tumbleweed. The usb-storage drivers are maintinaed by Matthew Dharm mdharm-...@one-eyed-alien.net. I suggest you contact him with a Cc to linux-...@vger.kernel.org, usb-stor...@lists.one-eyed-alien.net, and linux-kernel@vger.kernel.org and and state your problem, that it worked in kernel 3.7, but fails in the kernel 3.XX with the XX replaced by the version returned by 'uname -r'. Larry -- You received this message because you are subscribed to the Google Groups USB Mass Storage on Linux group. To unsubscribe from this group and stop receiving emails from it, send an email to usb-storage+unsubscr...@lists.one-eyed-alien.net. To post to this group, send email to usb-stor...@lists.one-eyed-alien.net. Visit this group at http://groups.google.com/a/lists.one-eyed-alien.net/group/usb-storage/. For more options, visit https://groups.google.com/a/lists.one-eyed-alien.net/groups/opt_out. -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [usb-storage] Re: [opensuse-factory] huawei usb dongle e173 not working on tumbleweed
Ron -- We're going to need the version numbers of both the kernel and the usb_modeswitch utility from both openSUSE 12.3 and Tumbleweed if we're going to make any sense of the situation. Matt On Thu, Oct 3, 2013 at 4:50 PM, Ron Brickle wrote: > On Thu, 2013-10-03 at 12:07 -0500, Larry Finger wrote: >> On 10/03/2013 02:13 AM, Ron Brickle wrote: >> > On Wed, 2013-10-02 at 22:56 -0500, Larry Finger wrote: >> >> On 10/02/2013 09:02 PM, Ron Brickle wrote: >> >>> Hi I have been trying to get my huawei usb dongle working on Tumbleweed >> >>> but to no avail so in desperation I am sending this email. it works >> >>> fine on 12.3 opensuse so hopefully you can fix this problem I tried to >> >>> get it working from help from the tumbleweed forum it is recognized in >> >>> lsusb but doesn show in network-manager >> >>> regards and thanks Ron Brickle >> >> >> >> Firmware? >> >> >> >> A device present in lsusb only means that it is connected to the USB >> >> system. For >> >> NM to have it, any firmware must be present, the wifi-enable switch for >> >> *ALL* >> >> devices must be on, the device must be recognized by some driver, and that >> >> driver must load and initialize correctly. From the information you >> >> provided, it >> >> is impossible to tell where it is failing. >> >> >> >> Larry >> >> >> >> Hi i just put this in terminal as normal user then as root >> > >> > rpm -ql usb_modeswitch-data|grep 1446 >> > it returns no answer and it should be this I am told if so the driver >> > isnt installed for this usb modem TargetVendor= 0x12d1 >> > TargetProductList="1001,1406,140b,140c,1412,141b,1433,1436,14ac,1506" >> > >> > MessageContent="55534243123456780011062001" >> > is this any help >> > regards ron >> > lsusb gives thisron@desktop:~> rpm -ql usb_modeswitch-data|grep 1446 >> > ron@desktop:~> lsusb >> > Bus 001 Device 002: ID 8087:8008 Intel Corp. >> > Bus 002 Device 002: ID 8087:8000 Intel Corp. >> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> > Bus 001 Device 003: ID 046d:0809 Logitech, Inc. Webcam Pro 9000 >> > Bus 002 Device 003: ID 174c:2074 ASMedia Technology Inc. >> > Bus 002 Device 004: ID 2109:2812 >> > Bus 002 Device 007: ID 12d1:1446 Huawei Technologies Co., Ltd. >> > E1552/E1800/E173 (HSPA modem) >> > Bus 002 Device 005: ID 046d:c526 Logitech, Inc. Nano Receiver >> > Bus 002 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver >> > and usb-devices gives this >> > Bus=02 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 >> > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 >> > P: Vendor=12d1 ProdID=1446 Rev=00.00 >> > S: Manufacturer=HUAWEI Technology >> > S: Product=HUAWEI Mobile >> > C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA >> > I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 >> > Driver=usb-storage >> > I: If#= 1 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 >> > Driver=usb-storage >> > thanks for your reply regards ron >> >> From the usb-devices output, the device obviously needs to be mode switched. >> >> There may be a regression from the openSUSE 12.3 kernel (probably 3.7) to the >> one used by Tumbleweed. The usb-storage drivers are maintinaed by Matthew >> Dharm >> . I suggest you contact him with a Cc to >> linux-...@vger.kernel.org, usb-stor...@lists.one-eyed-alien.net, and >> linux-kernel@vger.kernel.org and and state your problem, that it worked in >> kernel 3.7, but fails in the kernel 3.XX with the XX replaced by the version >> returned by 'uname -r'. >> >> Larry >> >> > > > -- > You received this message because you are subscribed to the Google Groups > "USB Mass Storage on Linux" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to usb-storage+unsubscr...@lists.one-eyed-alien.net. > To post to this group, send email to usb-stor...@lists.one-eyed-alien.net. > Visit this group at > http://groups.google.com/a/lists.one-eyed-alien.net/group/usb-storage/. > For more options, visit > https://groups.google.com/a/lists.one-eyed-alien.net/groups/opt_out. -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [usb-storage] Re: [opensuse-factory] huawei usb dongle e173 not working on tumbleweed
Ron -- We're going to need the version numbers of both the kernel and the usb_modeswitch utility from both openSUSE 12.3 and Tumbleweed if we're going to make any sense of the situation. Matt On Thu, Oct 3, 2013 at 4:50 PM, Ron Brickle rb19...@gmail.com wrote: On Thu, 2013-10-03 at 12:07 -0500, Larry Finger wrote: On 10/03/2013 02:13 AM, Ron Brickle wrote: On Wed, 2013-10-02 at 22:56 -0500, Larry Finger wrote: On 10/02/2013 09:02 PM, Ron Brickle wrote: Hi I have been trying to get my huawei usb dongle working on Tumbleweed but to no avail so in desperation I am sending this email. it works fine on 12.3 opensuse so hopefully you can fix this problem I tried to get it working from help from the tumbleweed forum it is recognized in lsusb but doesn show in network-manager regards and thanks Ron Brickle Firmware? A device present in lsusb only means that it is connected to the USB system. For NM to have it, any firmware must be present, the wifi-enable switch for *ALL* devices must be on, the device must be recognized by some driver, and that driver must load and initialize correctly. From the information you provided, it is impossible to tell where it is failing. Larry Hi i just put this in terminal as normal user then as root rpm -ql usb_modeswitch-data|grep 1446 it returns no answer and it should be this I am told if so the driver isnt installed for this usb modem TargetVendor= 0x12d1 TargetProductList=1001,1406,140b,140c,1412,141b,1433,1436,14ac,1506 MessageContent=55534243123456780011062001 is this any help regards ron lsusb gives thisron@desktop:~ rpm -ql usb_modeswitch-data|grep 1446 ron@desktop:~ lsusb Bus 001 Device 002: ID 8087:8008 Intel Corp. Bus 002 Device 002: ID 8087:8000 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 046d:0809 Logitech, Inc. Webcam Pro 9000 Bus 002 Device 003: ID 174c:2074 ASMedia Technology Inc. Bus 002 Device 004: ID 2109:2812 Bus 002 Device 007: ID 12d1:1446 Huawei Technologies Co., Ltd. E1552/E1800/E173 (HSPA modem) Bus 002 Device 005: ID 046d:c526 Logitech, Inc. Nano Receiver Bus 002 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver and usb-devices gives this Bus=02 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=12d1 ProdID=1446 Rev=00.00 S: Manufacturer=HUAWEI Technology S: Product=HUAWEI Mobile C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage I: If#= 1 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage thanks for your reply regards ron From the usb-devices output, the device obviously needs to be mode switched. There may be a regression from the openSUSE 12.3 kernel (probably 3.7) to the one used by Tumbleweed. The usb-storage drivers are maintinaed by Matthew Dharm mdharm-...@one-eyed-alien.net. I suggest you contact him with a Cc to linux-...@vger.kernel.org, usb-stor...@lists.one-eyed-alien.net, and linux-kernel@vger.kernel.org and and state your problem, that it worked in kernel 3.7, but fails in the kernel 3.XX with the XX replaced by the version returned by 'uname -r'. Larry -- You received this message because you are subscribed to the Google Groups USB Mass Storage on Linux group. To unsubscribe from this group and stop receiving emails from it, send an email to usb-storage+unsubscr...@lists.one-eyed-alien.net. To post to this group, send email to usb-stor...@lists.one-eyed-alien.net. Visit this group at http://groups.google.com/a/lists.one-eyed-alien.net/group/usb-storage/. For more options, visit https://groups.google.com/a/lists.one-eyed-alien.net/groups/opt_out. -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: storage: fix Huawei mode switching regression
Frankly, I consider it appropriate. The question is not one of reminding me of what I said earlier it's one of pointing people in the right direction. Frankly, some of the fault for this patch lies with Greg and myself for letting it through. I had just assumed that the Huawei guys had already been in touch with usb-modeswitch for some reason, and that this was just an optimization of existing logic (not an expansion). And, frankly, I was just a bit tired of fighting this fight over and over again; having something in the file which says "here's the right and official way to do this" would be good. I also asked the Huawei guys about the possibility of affecting other devices than the one listed I guess one of us either wasn't clear or mis-understood the request. The fact that there are devices out there failing now illustrates that. Avoiding breaking existing systems is one of the highest priorities Who is maintaining usb-modeswitch these days, anyway? The comment in the file should point people directly there And, as of now, I would really like to see as many of these devices migrated (albeit slowly) to using usb-modeswitch wherever possible. I know there are a few devices for which that might not be possible, but I am DONE dealing with this same issue over and over and over again. It will certainly be work to migrate support; maybe we should wrap all the relevant unusual_devs.h entires with CONFIG_UPDATED_MODESWITCH_INSTALLED_SO_MAKE_THESE_GO_AWAY during a transition period? Matt On Mon, Mar 4, 2013 at 8:47 AM, Bjørn Mork wrote: > Ben Hutchings writes: >> On Mon, 2013-03-04 at 14:19 +0100, Bjørn Mork wrote: >> [...] >>> In-kernel mode switching was deprecated years ago with the >>> development of the more user friendly userspace alternatives. The >>> existing list of devices in usb-storage was only kept to prevent >>> breaking already working systems. The long term plan is to remove >>> the list, not to add to it. Ref: >>> http://permalink.gmane.org/gmane.linux.usb.general/28543 >> [...] >> >> Can you add a comment to this effect? > > In the table in unusual_devs.h, you mean? Sure, I can do that. > > But it feels a bit strange since I can only quote and/or refer to what > Matthew and Greg said about the issue years ago. Putting a comment in > the code to remind the current maintainers about their own statements > could be considered out of line? Or is this appropriate here? > > > Bjørn -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: storage: fix Huawei mode switching regression
Frankly, I consider it appropriate. The question is not one of reminding me of what I said earlier it's one of pointing people in the right direction. Frankly, some of the fault for this patch lies with Greg and myself for letting it through. I had just assumed that the Huawei guys had already been in touch with usb-modeswitch for some reason, and that this was just an optimization of existing logic (not an expansion). And, frankly, I was just a bit tired of fighting this fight over and over again; having something in the file which says here's the right and official way to do this would be good. I also asked the Huawei guys about the possibility of affecting other devices than the one listed I guess one of us either wasn't clear or mis-understood the request. The fact that there are devices out there failing now illustrates that. Avoiding breaking existing systems is one of the highest priorities Who is maintaining usb-modeswitch these days, anyway? The comment in the file should point people directly there And, as of now, I would really like to see as many of these devices migrated (albeit slowly) to using usb-modeswitch wherever possible. I know there are a few devices for which that might not be possible, but I am DONE dealing with this same issue over and over and over again. It will certainly be work to migrate support; maybe we should wrap all the relevant unusual_devs.h entires with CONFIG_UPDATED_MODESWITCH_INSTALLED_SO_MAKE_THESE_GO_AWAY during a transition period? Matt On Mon, Mar 4, 2013 at 8:47 AM, Bjørn Mork bj...@mork.no wrote: Ben Hutchings b...@decadent.org.uk writes: On Mon, 2013-03-04 at 14:19 +0100, Bjørn Mork wrote: [...] In-kernel mode switching was deprecated years ago with the development of the more user friendly userspace alternatives. The existing list of devices in usb-storage was only kept to prevent breaking already working systems. The long term plan is to remove the list, not to add to it. Ref: http://permalink.gmane.org/gmane.linux.usb.general/28543 [...] Can you add a comment to this effect? In the table in unusual_devs.h, you mean? Sure, I can do that. But it feels a bit strange since I can only quote and/or refer to what Matthew and Greg said about the issue years ago. Putting a comment in the code to remind the current maintainers about their own statements could be considered out of line? Or is this appropriate here? Bjørn -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2]linux-usb:Define a new macro for USB storage match rules
On Fri, Jan 25, 2013 at 6:05 PM, Greg KH wrote:
> On Sat, Jan 26, 2013 at 01:39:50AM +, Fangxiaozhi (Franko) wrote:
>>
>>
>> > -Original Message-
>> > From: Greg KH [mailto:g...@kroah.com]
>> > Sent: Saturday, January 26, 2013 1:45 AM
>> > To: Fangxiaozhi (Franko)
>> > Cc: Sergei Shtylyov; linux-...@vger.kernel.org;
>> > linux-kernel@vger.kernel.org;
>> > Xueguiying (Zihan); Linlei (Lei Lin); Yili (Neil); Wangyuhua (Roger,
>> > Credit);
>> > Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net;
>> > sebast...@breakpoint.cc
>> > Subject: Re: [PATCH 1/2]linux-usb:Define a new macro for USB storage match
>> > rules
>> >
>> > On Fri, Jan 25, 2013 at 04:18:34PM +0400, Sergei Shtylyov wrote:
>> > > Hello.
>> > >
>> > > On 25-01-2013 6:44, fangxiaozhi 00110321 wrote:
>> > >
>> > > >From: fangxiaozhi
>> > >
>> > > >1. Define a new macro for USB storage match rules:
>> > > > matching with Vendor ID and interface descriptors.
>> > >
>> > > >Signed-off-by: fangxiaozhi
>> > > >
>> > > >
>> > > > diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/usb.c
>> > > >linux-3.8-rc4/drivers/usb/storage/usb.c
>> > > >--- linux-3.8-rc4_orig/drivers/usb/storage/usb.c 2013-01-22
>> > > >14:12:42.595238727 +0800
>> > > >+++ linux-3.8-rc4/drivers/usb/storage/usb.c 2013-01-22
>> > > >+++ 14:16:01.398250305 +0800
>> > > >@@ -120,6 +120,17 @@ MODULE_PARM_DESC(quirks, "supplemental l
>> > > > .useTransport = use_transport, \
>> > > > }
>> > > >
>> > > >+#define UNUSUAL_VENDOR_INTF(idVendor, cl, sc, pr, \
>> > > >+ vendor_name, product_name, use_protocol, use_transport, \
>> > > >+ init_function, Flags) \
>> > > >+{ \
>> > > >+ .vendorName = vendor_name, \
>> > > >+ .productName = product_name, \
>> > > >+ .useProtocol = use_protocol, \
>> > > >+ .useTransport = use_transport, \
>> > > >+ .initFunction = init_function, \
>> > > >+}
>> > >
>> > > Shouldn't the field initilaizers be indented with tab, not space?
>> >
>> > Yes it must. fangxiaozhi, please always run your patches through the
>> > scripts/checkpatch.pl tool before sending them out (note, you will have to
>> > ignore the CamelCase warnings your patch produces, but not the other
>> > ones.)
>> >
>> -What's wrong with it?
>> -I have checked the patches with scripts/checkpatch.pl before sending.
>> -There is no other warning or error in my patches except CamelCase
>> warnings.
>> -So what's wrong now?
>
> Then your email client messed up the patches and put spaces in the code
> instead of tabs. Try looking at the message on the mailing list and run
> that through checkpatch, it will show you the problems.
>
> What I received isn't ok, sorry.
Fangxiaozhi --
According to the headers of your E-mail, you are using MS Outlook to
send your patches. Outlook commonly mangles patches, unfortunately.
It is not a very good e-mail client.
I suggest one of two options:
1) Setup an alternative mail client. There are many to choose from
which will not damage your patches. I personally like 'mutt' (which
you should be able to install on your linux machine). Others may be
able to recommend ones that work for them; in general, I think you
will find that most e-mail clients that run on Linux will be suitable.
2) If you plan on contributing to the linux kernel in the future, it
may be worth your time to setup a repo on github that Greg can then
directly pull from. All you would need to do is send Greg a "pull
request" indicating the URL of the branch in your repo that he should
pull from. Greg can then pull directly from your repo, bypassing this
issue entirely.
Matt
--
Matthew Dharm
Maintainer, USB Mass Storage driver for Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2]linux-usb:Define a new macro for USB storage match rules
On Fri, Jan 25, 2013 at 6:05 PM, Greg KH g...@kroah.com wrote:
On Sat, Jan 26, 2013 at 01:39:50AM +, Fangxiaozhi (Franko) wrote:
-Original Message-
From: Greg KH [mailto:g...@kroah.com]
Sent: Saturday, January 26, 2013 1:45 AM
To: Fangxiaozhi (Franko)
Cc: Sergei Shtylyov; linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org;
Xueguiying (Zihan); Linlei (Lei Lin); Yili (Neil); Wangyuhua (Roger,
Credit);
Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net;
sebast...@breakpoint.cc
Subject: Re: [PATCH 1/2]linux-usb:Define a new macro for USB storage match
rules
On Fri, Jan 25, 2013 at 04:18:34PM +0400, Sergei Shtylyov wrote:
Hello.
On 25-01-2013 6:44, fangxiaozhi 00110321 wrote:
From: fangxiaozhi huana...@huawei.com
1. Define a new macro for USB storage match rules:
matching with Vendor ID and interface descriptors.
Signed-off-by: fangxiaozhi huana...@huawei.com
diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/usb.c
linux-3.8-rc4/drivers/usb/storage/usb.c
--- linux-3.8-rc4_orig/drivers/usb/storage/usb.c 2013-01-22
14:12:42.595238727 +0800
+++ linux-3.8-rc4/drivers/usb/storage/usb.c 2013-01-22
+++ 14:16:01.398250305 +0800
@@ -120,6 +120,17 @@ MODULE_PARM_DESC(quirks, supplemental l
.useTransport = use_transport, \
}
+#define UNUSUAL_VENDOR_INTF(idVendor, cl, sc, pr, \
+ vendor_name, product_name, use_protocol, use_transport, \
+ init_function, Flags) \
+{ \
+ .vendorName = vendor_name, \
+ .productName = product_name, \
+ .useProtocol = use_protocol, \
+ .useTransport = use_transport, \
+ .initFunction = init_function, \
+}
Shouldn't the field initilaizers be indented with tab, not space?
Yes it must. fangxiaozhi, please always run your patches through the
scripts/checkpatch.pl tool before sending them out (note, you will have to
ignore the CamelCase warnings your patch produces, but not the other
ones.)
-What's wrong with it?
-I have checked the patches with scripts/checkpatch.pl before sending.
-There is no other warning or error in my patches except CamelCase
warnings.
-So what's wrong now?
Then your email client messed up the patches and put spaces in the code
instead of tabs. Try looking at the message on the mailing list and run
that through checkpatch, it will show you the problems.
What I received isn't ok, sorry.
Fangxiaozhi --
According to the headers of your E-mail, you are using MS Outlook to
send your patches. Outlook commonly mangles patches, unfortunately.
It is not a very good e-mail client.
I suggest one of two options:
1) Setup an alternative mail client. There are many to choose from
which will not damage your patches. I personally like 'mutt' (which
you should be able to install on your linux machine). Others may be
able to recommend ones that work for them; in general, I think you
will find that most e-mail clients that run on Linux will be suitable.
2) If you plan on contributing to the linux kernel in the future, it
may be worth your time to setup a repo on github that Greg can then
directly pull from. All you would need to do is send Greg a pull
request indicating the URL of the branch in your repo that he should
pull from. Greg can then pull directly from your repo, bypassing this
issue entirely.
Matt
--
Matthew Dharm
Maintainer, USB Mass Storage driver for Linux
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command
On Wed, Dec 19, 2012 at 12:34 AM, Sebastian Andrzej Siewior wrote: > On Wed, Dec 19, 2012 at 03:13:32AM +, Fangxiaozhi (Franko) wrote: >> > And shouldn't you read something from the us->recv_bulk_pipe after >> > that? >> Well, because our device will re-connect to switch the ports if it >> receives the command. >> So it is not necessary to read the response of the command. > > Hmm. I guess this for Matthew / Greg to decide, I don't insist on anything. > Maybe a comment would be nice because now it looks, atleast to me, that > something is missing. I think an unusual situation like that deserves a comment that explains that the device is about to disconnect / reconnect, so reading status is not necessary. I am also concerned about the error of using instead of bcbw. I doubt this code would have worked with that typo in place. How was this patch tested? Also, the dongles_pid function is really just a different implementation of the unusual_devs.h table. I think that it is much easier for people to add new entries to the table, rather than edit your code, when new dongles are released. BUT, your code includes many more PIDs than the table did. Again, how was this tested for the new PIDs covered? At a minimum, some comment in dongles_pid is required to highlight this area of code for possible future expansion as new devices are released. Matt -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command
On Wed, Dec 19, 2012 at 12:34 AM, Sebastian Andrzej Siewior sebast...@breakpoint.cc wrote: On Wed, Dec 19, 2012 at 03:13:32AM +, Fangxiaozhi (Franko) wrote: And shouldn't you read something from the us-recv_bulk_pipe after that? Well, because our device will re-connect to switch the ports if it receives the command. So it is not necessary to read the response of the command. Hmm. I guess this for Matthew / Greg to decide, I don't insist on anything. Maybe a comment would be nice because now it looks, atleast to me, that something is missing. I think an unusual situation like that deserves a comment that explains that the device is about to disconnect / reconnect, so reading status is not necessary. I am also concerned about the error of using bcbw instead of bcbw. I doubt this code would have worked with that typo in place. How was this patch tested? Also, the dongles_pid function is really just a different implementation of the unusual_devs.h table. I think that it is much easier for people to add new entries to the table, rather than edit your code, when new dongles are released. BUT, your code includes many more PIDs than the table did. Again, how was this tested for the new PIDs covered? At a minimum, some comment in dongles_pid is required to highlight this area of code for possible future expansion as new devices are released. Matt -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wrong cylinders of kingston usb pendrive [intel 82801DB]
On Sun, Feb 03, 2008 at 05:59:38PM -0800, Greg KH wrote: > On Mon, Feb 04, 2008 at 01:50:37AM +0100, Patrick Ringl wrote: > > Hello, > > > > I am suffering from the following (usb-related?) problem: > > > > I have several different mashines - all x86 architecture - just lets call > > them mashineA, mashineB and mashineC. > > Is the kernel the same on all of these machines? I'm not sure it matters... usb-storage has no knowledge of CHS geometery. It deals entirely in LBA. Does anyone know where the kernel gets the CHS geometery equivalent from? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver E: You run this ship with Windows?! YOU IDIOT! L: Give me a break, it came bundled with the computer! -- ESR and Lan Solaris User Friendly, 12/8/1998 pgp0cO5f1PG26.pgp Description: PGP signature
Re: wrong cylinders of kingston usb pendrive [intel 82801DB]
On Sun, Feb 03, 2008 at 05:59:38PM -0800, Greg KH wrote: On Mon, Feb 04, 2008 at 01:50:37AM +0100, Patrick Ringl wrote: Hello, I am suffering from the following (usb-related?) problem: I have several different mashines - all x86 architecture - just lets call them mashineA, mashineB and mashineC. Is the kernel the same on all of these machines? I'm not sure it matters... usb-storage has no knowledge of CHS geometery. It deals entirely in LBA. Does anyone know where the kernel gets the CHS geometery equivalent from? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver E: You run this ship with Windows?! YOU IDIOT! L: Give me a break, it came bundled with the computer! -- ESR and Lan Solaris User Friendly, 12/8/1998 pgp0cO5f1PG26.pgp Description: PGP signature
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29, 2008 at 08:15:04PM +0100, Jens Axboe wrote: > On Tue, Jan 29 2008, Matthew Dharm wrote: > > On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: > > > On Tue, Jan 29 2008, Jens Axboe wrote: > > > > On Tue, Jan 29 2008, Oliver Neukum wrote: > > > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL > > > > > > > PROTECTED]> wrote: > > > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > > >> Greg KH wrote: > > > > > > > > > > > > > No difference, still just a lot of resets. > > > > > > > > > > > > > > > Where you able to figure out which usb storage transport is used? > > > > > > > > > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and > > > > > > > get_transport() > > > > > > > functions. I'm not sure if these get stored in sysfs perhaps. > > > > > > > This will > > > > > > > pinpoint better where to look. Let me research a bit. > > > > > > > > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' > > > > > > and > > > > > > transport is 'Bulk' > > > > > > > > > > You can recompile your kernel with CONFIG_USB_DEBUG and > > > > > CONFIG_STORAGE_DEBUG > > > > > That should tell the reason for the resets. > > > > > > > > Sure, I'll do that. Will post the results tonight. > > > > > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged > > > in the device, waited 10 seconds or so and pulled it out. These are the > > > messages. > > > > > > It all looks good until the MODE_SENSE command, where it only transfers > > > 4 of 192 bytes. > > > > No, that's not the problem. This is the problem: > > It's where the problem starts, otherwise there would not be a need to > sense :-) MODE_SENSE has nothing to do with it. A short MODE_SENSE response is perfectly valid, and the log shows it was handled correctly and subsequent commands worked just fine. It's not until the TUR fails that we get the problem. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver P: Nine more messages in admin.policy. M: I know, I'm typing as fast as I can! -- Pitr and Mike User Friendly, 11/27/97 pgpW4yRSsBzaD.pgp Description: PGP signature
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: > On Tue, Jan 29 2008, Jens Axboe wrote: > > On Tue, Jan 29 2008, Oliver Neukum wrote: > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL PROTECTED]> > > > > > wrote: > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > >> Greg KH wrote: > > > > > > > > > No difference, still just a lot of resets. > > > > > > > > > > > Where you able to figure out which usb storage transport is used? > > > > > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and > > > > > get_transport() > > > > > functions. I'm not sure if these get stored in sysfs perhaps. This > > > > > will > > > > > pinpoint better where to look. Let me research a bit. > > > > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and > > > > transport is 'Bulk' > > > > > > You can recompile your kernel with CONFIG_USB_DEBUG and > > > CONFIG_STORAGE_DEBUG > > > That should tell the reason for the resets. > > > > Sure, I'll do that. Will post the results tonight. > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged > in the device, waited 10 seconds or so and pulled it out. These are the > messages. > > It all looks good until the MODE_SENSE command, where it only transfers > 4 of 192 bytes. No, that's not the problem. This is the problem: > usb-storage: *** thread awakened. > usb-storage: Command TEST_UNIT_READY (6 bytes) > usb-storage: 00 00 00 00 00 00 > usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6 > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > usb-storage: Status code 0; transferred 31/31 > usb-storage: -- transfer complete > usb-storage: Bulk command transfer result=0 > usb-storage: Attempting to get CSW... > usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes > usb-storage: Status code 0; transferred 13/13 > usb-storage: -- transfer complete > usb-storage: Bulk status result = 0 > usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1 > usb-storage: -- transport indicates command failure > usb-storage: Issuing auto-REQUEST_SENSE > usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6 > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > usb-storage: Status code 0; transferred 31/31 > usb-storage: -- transfer complete > usb-storage: Bulk command transfer result=0 > usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries > usb-storage: usb_sg_init returned -22 > usb-storage: Bulk data transfer result 0x4 > usb-storage: -- auto-sense failure > usb-storage: storage_pre_reset > ehci_hcd :00:1d.7: port 1 high speed > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > ehci_hcd :00:1d.7: port 1 high speed > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT > usb-storage: storage_post_reset > usb-storage: usb_reset_composite_device returns 0 > usb-storage: scsi cmd done, result=0x7 > usb-storage: *** thread sleeping. For some reason, usb_sg_init is boned during auto-sense. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgpb4Ng6xEurV.pgp Description: PGP signature
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29, 2008 at 02:15:15PM +0200, Boaz Harrosh wrote: > Greg KH wrote: > > On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote: > >> Hi, > >> > >> Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and > >> connecting my cf usb storage device yields and endless stream of: > >> > >> Initializing USB Mass Storage driver... > >> scsi6 : SCSI emulation for USB Mass Storage devices > >> usb-storage: device found at 2 > >> usb-storage: waiting for device to settle before scanning > >> usbcore: registered new interface driver usb-storage > >> USB Mass Storage support registered. > >> scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > >> ANSI: 0 > >> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > >> sd 6:0:0:0: [sdb] Write Protect is off > >> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > >> sd 6:0:0:0: [sdb] Assuming drive cache: write through > >> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > >> sd 6:0:0:0: [sdb] Write Protect is off > >> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > >> sd 6:0:0:0: [sdb] Assuming drive cache: write through > >> sdb: sdb1 > >> sd 6:0:0:0: [sdb] Attached SCSI removable disk > >> sd 6:0:0:0: Attached scsi generic sg1 type 0 > >> scsi 6:0:0:1: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > >> ANSI: 0 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> [...] > >> > >> until I disconnect it. The device doesn't work. Worked fine in 2.6.24. > >> I'm attaching boot messages and my .config. > > > > That's a bit wierd, as we haven't added any USB patches to the -git tree > > yet after 2.6.24 :) > > > > Could this be caused by some scsi changes perhaps? > > > > thanks, > > > > greg k-h > > - > Yes it is ;) > > Jens could you test the patch below? if it works I'll submit a proper > patch. Please forgive me for the bug. > > Matthew, Greg, Is there a way to extract from messages the usb storage > transport > used? I'm guessing it is freecom do to the fact that I find a bug there. The freecom transport is exceptionally rare these days. It's primary user was a device made by a company that went out of business. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Way to go, lava boy. -- Stef to Greg User Friendly, 3/26/1998 pgpNyvPb2LQWH.pgp Description: PGP signature
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29, 2008 at 02:15:15PM +0200, Boaz Harrosh wrote: Greg KH wrote: On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote: Hi, Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and connecting my cf usb storage device yields and endless stream of: Initializing USB Mass Storage driver... scsi6 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning usbcore: registered new interface driver usb-storage USB Mass Storage support registered. scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 ANSI: 0 sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) sd 6:0:0:0: [sdb] Write Protect is off sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 sd 6:0:0:0: [sdb] Assuming drive cache: write through sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) sd 6:0:0:0: [sdb] Write Protect is off sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 sd 6:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 6:0:0:0: [sdb] Attached SCSI removable disk sd 6:0:0:0: Attached scsi generic sg1 type 0 scsi 6:0:0:1: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 ANSI: 0 usb 5-1: reset high speed USB device using ehci_hcd and address 2 usb 5-1: reset high speed USB device using ehci_hcd and address 2 usb 5-1: reset high speed USB device using ehci_hcd and address 2 usb 5-1: reset high speed USB device using ehci_hcd and address 2 usb 5-1: reset high speed USB device using ehci_hcd and address 2 usb 5-1: reset high speed USB device using ehci_hcd and address 2 usb 5-1: reset high speed USB device using ehci_hcd and address 2 [...] until I disconnect it. The device doesn't work. Worked fine in 2.6.24. I'm attaching boot messages and my .config. That's a bit wierd, as we haven't added any USB patches to the -git tree yet after 2.6.24 :) Could this be caused by some scsi changes perhaps? thanks, greg k-h - Yes it is ;) Jens could you test the patch below? if it works I'll submit a proper patch. Please forgive me for the bug. Matthew, Greg, Is there a way to extract from messages the usb storage transport used? I'm guessing it is freecom do to the fact that I find a bug there. The freecom transport is exceptionally rare these days. It's primary user was a device made by a company that went out of business. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Way to go, lava boy. -- Stef to Greg User Friendly, 3/26/1998 pgpNyvPb2LQWH.pgp Description: PGP signature
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: On Tue, Jan 29 2008, Jens Axboe wrote: On Tue, Jan 29 2008, Oliver Neukum wrote: Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: On Tue, Jan 29 2008, Boaz Harrosh wrote: On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe [EMAIL PROTECTED] wrote: On Tue, Jan 29 2008, Boaz Harrosh wrote: Greg KH wrote: No difference, still just a lot of resets. Where you able to figure out which usb storage transport is used? in drivers/usb/storage/usb.c you have get_protocol() and get_transport() functions. I'm not sure if these get stored in sysfs perhaps. This will pinpoint better where to look. Let me research a bit. Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and transport is 'Bulk' You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG That should tell the reason for the resets. Sure, I'll do that. Will post the results tonight. OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged in the device, waited 10 seconds or so and pulled it out. These are the messages. It all looks good until the MODE_SENSE command, where it only transfers 4 of 192 bytes. No, that's not the problem. This is the problem: usb-storage: *** thread awakened. usb-storage: Command TEST_UNIT_READY (6 bytes) usb-storage: 00 00 00 00 00 00 usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1 usb-storage: -- transport indicates command failure usb-storage: Issuing auto-REQUEST_SENSE usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries usb-storage: usb_sg_init returned -22 usb-storage: Bulk data transfer result 0x4 usb-storage: -- auto-sense failure usb-storage: storage_pre_reset ehci_hcd :00:1d.7: port 1 high speed ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT usb 5-1: reset high speed USB device using ehci_hcd and address 2 ehci_hcd :00:1d.7: port 1 high speed ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT usb-storage: storage_post_reset usb-storage: usb_reset_composite_device returns 0 usb-storage: scsi cmd done, result=0x7 usb-storage: *** thread sleeping. For some reason, usb_sg_init is boned during auto-sense. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgpb4Ng6xEurV.pgp Description: PGP signature
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29, 2008 at 08:15:04PM +0100, Jens Axboe wrote: On Tue, Jan 29 2008, Matthew Dharm wrote: On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: On Tue, Jan 29 2008, Jens Axboe wrote: On Tue, Jan 29 2008, Oliver Neukum wrote: Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: On Tue, Jan 29 2008, Boaz Harrosh wrote: On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe [EMAIL PROTECTED] wrote: On Tue, Jan 29 2008, Boaz Harrosh wrote: Greg KH wrote: No difference, still just a lot of resets. Where you able to figure out which usb storage transport is used? in drivers/usb/storage/usb.c you have get_protocol() and get_transport() functions. I'm not sure if these get stored in sysfs perhaps. This will pinpoint better where to look. Let me research a bit. Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and transport is 'Bulk' You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG That should tell the reason for the resets. Sure, I'll do that. Will post the results tonight. OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged in the device, waited 10 seconds or so and pulled it out. These are the messages. It all looks good until the MODE_SENSE command, where it only transfers 4 of 192 bytes. No, that's not the problem. This is the problem: It's where the problem starts, otherwise there would not be a need to sense :-) MODE_SENSE has nothing to do with it. A short MODE_SENSE response is perfectly valid, and the log shows it was handled correctly and subsequent commands worked just fine. It's not until the TUR fails that we get the problem. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver P: Nine more messages in admin.policy. M: I know, I'm typing as fast as I can! -- Pitr and Mike User Friendly, 11/27/97 pgpW4yRSsBzaD.pgp Description: PGP signature
Re: Add the infamous Huawei E220 to option.c
On Thu, Nov 29, 2007 at 09:14:47AM +0100, Oliver Neukum wrote: > Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev: > > On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote: > > > 3. Make sure usbcore doesn't probe the devices in the wrong mode with the > > > option driver > > > > This fixes duplication. And to take it further, why don't we turn this > > idea around and let usb-storage fail to attach with some "ignore" quirk? > > I suspect that someone put the initializer into usb-storage in order > > to let the generic usb serial to work, but this simply was a bad idea. > > Yes, you are right. That's the correct approach. Changing the unusual_devs.h flag to IGNORE_DEVICE should accomplish what you want. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: Like the Furby? DP: He gives me the creeps. Think the SPCA will take him? -- Cobb and Dust Puppy User Friendly, 1/2/1999 pgppfYfR7ex3G.pgp Description: PGP signature
Re: Add the infamous Huawei E220 to option.c
On Thu, Nov 29, 2007 at 09:14:47AM +0100, Oliver Neukum wrote: Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev: On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum [EMAIL PROTECTED] wrote: 3. Make sure usbcore doesn't probe the devices in the wrong mode with the option driver This fixes duplication. And to take it further, why don't we turn this idea around and let usb-storage fail to attach with some ignore quirk? I suspect that someone put the initializer into usb-storage in order to let the generic usb serial to work, but this simply was a bad idea. Yes, you are right. That's the correct approach. Changing the unusual_devs.h flag to IGNORE_DEVICE should accomplish what you want. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: Like the Furby? DP: He gives me the creeps. Think the SPCA will take him? -- Cobb and Dust Puppy User Friendly, 1/2/1999 pgppfYfR7ex3G.pgp Description: PGP signature
Re: 2.6.24-rc2-mm1
On Wed, Nov 14, 2007 at 10:23:09AM +0100, Gabriel C wrote: > Matthew Dharm wrote: > > On Wed, Nov 14, 2007 at 06:33:39AM +0100, Gabriel C wrote: > >> Matthew Dharm wrote: > >>> On Tue, Nov 13, 2007 at 07:49:24PM -0800, Greg KH wrote: > >>>> Matt, are these the errors you were worried about with the patch we were > >>>> just talking about tha tis in my tree? > >>> I can't tell from these logs. > >> There is the dmesg with CONFIG_USB_STORAGE_DEBUG : > >> > >> http://194.231.229.228/dmesg-2.6.24-rc2-mm1 > > > > Good news: This isn't the bug Greg was worried about. > > > > Bad news: Something is seriously strange here. Note the following from the > > logs: > > > > Nov 14 06:07:43 lara [ 41.890614] usb-storage: Bulk Status S 0x53425355 T > > 0xd R 0 Stat 0x0 > > Nov 14 06:07:43 lara [ 41.890616] usb-storage: -- unexpectedly short > > transfer > > > > Note the 'R' value of zero -- this is the residue value. It indicates a > > complete transfer, and that matches the log lines immediately previous > > which indicate a 4K transfer which completed properly. > > > > If residue is zero, then srb->resid should be zero. Take a look in > > linux/usb/storage/transport.c in usb_stor_Bulk_transport() > > > > If srb->resid is zero, then you should NEVER get the "unexpectedly short > > transfer" message. Look at usb_stor_invoke_transport() in the same file. > > That code got replaced recently but I have no idea about it. > > ( http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=shortlog > see the patches from Boaz Harrosh) > > srb->resid got replaced by scsi_get_resid() it I see that right. > > I'm CC'ing the author , he will know I think. The replacement looks, to my eye, to be logically correct. The patch was pretty clean. Then again, I haven't looked at what is "under the hood" of the accessor functions. Perhaps there is a side-effect somewhere in there? Perhaps a quick debugging test -- print the value of scsi_get_resid(srb) just after it's initialized to zero at the top of usb_stor_invoke_transport(), and then just after the call to us->transport(). The first print should show a value of zero. The debug log says that the transport should have left it as zero. If it's actually coming back from us->transport() as a non-zero value, then we'll need to check all the modifications to usb_stor_Bulk_transport to see where srb->resid is being changed. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver A: The most ironic oxymoron wins ... DP: "Microsoft Works" A: Uh, okay, you win. -- A.J. & Dust Puppy User Friendly, 1/18/1998 pgpevTltZyZry.pgp Description: PGP signature
Re: 2.6.24-rc2-mm1
On Wed, Nov 14, 2007 at 10:23:09AM +0100, Gabriel C wrote: Matthew Dharm wrote: On Wed, Nov 14, 2007 at 06:33:39AM +0100, Gabriel C wrote: Matthew Dharm wrote: On Tue, Nov 13, 2007 at 07:49:24PM -0800, Greg KH wrote: Matt, are these the errors you were worried about with the patch we were just talking about tha tis in my tree? I can't tell from these logs. There is the dmesg with CONFIG_USB_STORAGE_DEBUG : http://194.231.229.228/dmesg-2.6.24-rc2-mm1 Good news: This isn't the bug Greg was worried about. Bad news: Something is seriously strange here. Note the following from the logs: Nov 14 06:07:43 lara [ 41.890614] usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x0 Nov 14 06:07:43 lara [ 41.890616] usb-storage: -- unexpectedly short transfer Note the 'R' value of zero -- this is the residue value. It indicates a complete transfer, and that matches the log lines immediately previous which indicate a 4K transfer which completed properly. If residue is zero, then srb-resid should be zero. Take a look in linux/usb/storage/transport.c in usb_stor_Bulk_transport() If srb-resid is zero, then you should NEVER get the unexpectedly short transfer message. Look at usb_stor_invoke_transport() in the same file. That code got replaced recently but I have no idea about it. ( http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=shortlog see the patches from Boaz Harrosh) srb-resid got replaced by scsi_get_resid() it I see that right. I'm CC'ing the author , he will know I think. The replacement looks, to my eye, to be logically correct. The patch was pretty clean. Then again, I haven't looked at what is under the hood of the accessor functions. Perhaps there is a side-effect somewhere in there? Perhaps a quick debugging test -- print the value of scsi_get_resid(srb) just after it's initialized to zero at the top of usb_stor_invoke_transport(), and then just after the call to us-transport(). The first print should show a value of zero. The debug log says that the transport should have left it as zero. If it's actually coming back from us-transport() as a non-zero value, then we'll need to check all the modifications to usb_stor_Bulk_transport to see where srb-resid is being changed. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver A: The most ironic oxymoron wins ... DP: Microsoft Works A: Uh, okay, you win. -- A.J. Dust Puppy User Friendly, 1/18/1998 pgpevTltZyZry.pgp Description: PGP signature
Re: 2.6.24-rc2-mm1
On Wed, Nov 14, 2007 at 06:33:39AM +0100, Gabriel C wrote: > Matthew Dharm wrote: > > On Tue, Nov 13, 2007 at 07:49:24PM -0800, Greg KH wrote: > >> Matt, are these the errors you were worried about with the patch we were > >> just talking about tha tis in my tree? > > > > I can't tell from these logs. > > There is the dmesg with CONFIG_USB_STORAGE_DEBUG : > > http://194.231.229.228/dmesg-2.6.24-rc2-mm1 Good news: This isn't the bug Greg was worried about. Bad news: Something is seriously strange here. Note the following from the logs: Nov 14 06:07:43 lara [ 41.890614] usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x0 Nov 14 06:07:43 lara [ 41.890616] usb-storage: -- unexpectedly short transfer Note the 'R' value of zero -- this is the residue value. It indicates a complete transfer, and that matches the log lines immediately previous which indicate a 4K transfer which completed properly. If residue is zero, then srb->resid should be zero. Take a look in linux/usb/storage/transport.c in usb_stor_Bulk_transport() If srb->resid is zero, then you should NEVER get the "unexpectedly short transfer" message. Look at usb_stor_invoke_transport() in the same file. In fact, every transfer I look at shows this error. I didn't exhaustivly check every single one in the log, but a quick scan suggests that they all are bogus; good transfer, CSW residue of 0, and "unexpectedly short" message. Maybe I'm too tired at this hour, but I just don't see how this is possible. Then again, I'm looking at 2.6.22 codebase (it's what I have handy). Hrm... does this tree have the "srb accessor" patches in it? I'm wondering if somewhere the init srb->resid to 0 before invoking the transport got lost Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Somebody call an exorcist! -- Dust Puppy User Friendly, 5/16/1998 pgpgO1qpqm0lH.pgp Description: PGP signature
Re: 2.6.24-rc2-mm1
On Wed, Nov 14, 2007 at 06:33:39AM +0100, Gabriel C wrote: Matthew Dharm wrote: On Tue, Nov 13, 2007 at 07:49:24PM -0800, Greg KH wrote: Matt, are these the errors you were worried about with the patch we were just talking about tha tis in my tree? I can't tell from these logs. There is the dmesg with CONFIG_USB_STORAGE_DEBUG : http://194.231.229.228/dmesg-2.6.24-rc2-mm1 Good news: This isn't the bug Greg was worried about. Bad news: Something is seriously strange here. Note the following from the logs: Nov 14 06:07:43 lara [ 41.890614] usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x0 Nov 14 06:07:43 lara [ 41.890616] usb-storage: -- unexpectedly short transfer Note the 'R' value of zero -- this is the residue value. It indicates a complete transfer, and that matches the log lines immediately previous which indicate a 4K transfer which completed properly. If residue is zero, then srb-resid should be zero. Take a look in linux/usb/storage/transport.c in usb_stor_Bulk_transport() If srb-resid is zero, then you should NEVER get the unexpectedly short transfer message. Look at usb_stor_invoke_transport() in the same file. In fact, every transfer I look at shows this error. I didn't exhaustivly check every single one in the log, but a quick scan suggests that they all are bogus; good transfer, CSW residue of 0, and unexpectedly short message. Maybe I'm too tired at this hour, but I just don't see how this is possible. Then again, I'm looking at 2.6.22 codebase (it's what I have handy). Hrm... does this tree have the srb accessor patches in it? I'm wondering if somewhere the init srb-resid to 0 before invoking the transport got lost Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Somebody call an exorcist! -- Dust Puppy User Friendly, 5/16/1998 pgpgO1qpqm0lH.pgp Description: PGP signature
Re: 2.6.24-rc2-mm1
On Tue, Nov 13, 2007 at 07:49:24PM -0800, Greg KH wrote: > > Matt, are these the errors you were worried about with the patch we were > just talking about tha tis in my tree? I can't tell from these logs. The key question (in relation to the allow_restart patch) is this: Was everything working fine until a START_STOP was sent to the device? The SCSI layers used to send devices START_STOP to almost every device as part of initialization. I think we switched all of that to use TEST_UNIT_READY instead. The patch you've got should re-enable START_STOP to be sent. The SCSI layers (I'm told, but haven't verified myself) only send START_STOP if the device reports that it needs a startup command. CONFIG_USB_STORAGE_DEBUG will generate a *lot* of debug output. But, it should be pretty easy to see if START_STOP was sent at all, and if it caused the problems. Matt P.S. Worst case, the issue we're talking about here would only cause the device firmware to crash, which would eventually lead to a disconnect. That shouldn't have caused the much more severe problems shown in the log you sent. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver DP: And judging from the scores, Stef has the sma... T: LET'S NOT GO THERE! -- Dust Puppy and Tanya User Friendly, 12/11/1997 pgpIQ12NeBsnh.pgp Description: PGP signature
Re: 2.6.24-rc2-mm1
On Tue, Nov 13, 2007 at 07:49:24PM -0800, Greg KH wrote: Matt, are these the errors you were worried about with the patch we were just talking about tha tis in my tree? I can't tell from these logs. The key question (in relation to the allow_restart patch) is this: Was everything working fine until a START_STOP was sent to the device? The SCSI layers used to send devices START_STOP to almost every device as part of initialization. I think we switched all of that to use TEST_UNIT_READY instead. The patch you've got should re-enable START_STOP to be sent. The SCSI layers (I'm told, but haven't verified myself) only send START_STOP if the device reports that it needs a startup command. CONFIG_USB_STORAGE_DEBUG will generate a *lot* of debug output. But, it should be pretty easy to see if START_STOP was sent at all, and if it caused the problems. Matt P.S. Worst case, the issue we're talking about here would only cause the device firmware to crash, which would eventually lead to a disconnect. That shouldn't have caused the much more severe problems shown in the log you sent. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver DP: And judging from the scores, Stef has the sma... T: LET'S NOT GO THERE! -- Dust Puppy and Tanya User Friendly, 12/11/1997 pgpIQ12NeBsnh.pgp Description: PGP signature
Re: [linux-usb-devel] usb+sysfs: duplicate filename 'bInterfaceNumber'
On Tue, Oct 16, 2007 at 02:04:43PM -0400, Alan Stern wrote: > On Tue, 16 Oct 2007, Matthew Dharm wrote: > > > I haven't looked at this code at all, but neither approach feels right to > > me. > > > > How does this work at all? Even if you load a driver later, wouldn't it > > call usb_set_interface(), which would call usb_create_sysfs_intf_files() > > and hit the same issue? > > usb_set_interface() is smart enough to remove the old interface files > before creating new ones, since it expects them to exist already. > Hence there's no problem in that scenario. > > But usb_set_configuration doesn't expect there to be any pre-existing > interface files, because there isn't even an interface until the > registration is performed. And I'm guessing that you can't call usb_create_sysfs_intf_files() until registration is performed, right? > The most important reason has to do with the endpoint pseudo-devices. > Different altsettings can have different endpoints, so those have to be > removed and re-created whenever the altsetting changes. Right, altsettings. I forgot about those. I only ever think in terms of multiple configurations. *grumble* If usb_set_interface() has to be smart enough to remove existing files first already, then I guess it's reasonably symmetric to have usb_set_configuration() have the same smarts. Maybe they can share some common code, even. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: Why are you upgrading to NT? AJ: It must be the sick, sadistic streak that runs through me. -- Chief and A.J. User Friendly, 5/12/1998 pgpyl02DsudZG.pgp Description: PGP signature
Re: [linux-usb-devel] usb+sysfs: duplicate filename 'bInterfaceNumber'
On Tue, Oct 16, 2007 at 10:55:54AM -0400, Alan Stern wrote: > On Tue, 16 Oct 2007, Dave Young wrote: > > > > I finally duplicated this on one of my machines here at boot time, with > > > USB built into the kernel. I'll work tomorrow on tracking this down > > > further... > > Hi, > > I add some printk messages, dump_stack and some others, here is the > > dmesg dump with debug info(lines begin with "hidave"): > > Okay, good, the extra printk messages show exactly where the problem > lies. > > In usb_set_configuration(), each new interfaces is registered and then > usb_create_sysfs_intf_files() gets called for that interface. This > makes sense, because obviously we can't create sysfs files for an > interface before it is registered. > > The problem is that during registration drivers get probed, and drivers > sometimes call usb_set_interface() from their probe method. This > routine also calls usb_create_sysfs_intf_files(), and the result is > that the sysfs files get created twice: > > First by usb_set_interface, from the driver probe; > > Then by usb_set_configuration, when registration is > finished. > > I can think of two possible ways around the problem. One is to add a > bit to the usb_interface structure, recording whether the sysfs files > have been created. The other is always to remove the files just before > trying to create them. I haven't looked at this code at all, but neither approach feels right to me. How does this work at all? Even if you load a driver later, wouldn't it call usb_set_interface(), which would call usb_create_sysfs_intf_files() and hit the same issue? Heck, why do both call usb_create_sysfs_intf_file()? I would guess if you're *changing* the active configuration you would need to do that, but why in usb_set_interface() at all? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I say, what are all those naked people doing? -- Big client to Stef User Friendly, 12/14/1997 pgpUQw629YoXR.pgp Description: PGP signature
Re: [linux-usb-devel] usb+sysfs: duplicate filename 'bInterfaceNumber'
On Tue, Oct 16, 2007 at 10:55:54AM -0400, Alan Stern wrote: On Tue, 16 Oct 2007, Dave Young wrote: I finally duplicated this on one of my machines here at boot time, with USB built into the kernel. I'll work tomorrow on tracking this down further... Hi, I add some printk messages, dump_stack and some others, here is the dmesg dump with debug info(lines begin with hidave): Okay, good, the extra printk messages show exactly where the problem lies. In usb_set_configuration(), each new interfaces is registered and then usb_create_sysfs_intf_files() gets called for that interface. This makes sense, because obviously we can't create sysfs files for an interface before it is registered. The problem is that during registration drivers get probed, and drivers sometimes call usb_set_interface() from their probe method. This routine also calls usb_create_sysfs_intf_files(), and the result is that the sysfs files get created twice: First by usb_set_interface, from the driver probe; Then by usb_set_configuration, when registration is finished. I can think of two possible ways around the problem. One is to add a bit to the usb_interface structure, recording whether the sysfs files have been created. The other is always to remove the files just before trying to create them. I haven't looked at this code at all, but neither approach feels right to me. How does this work at all? Even if you load a driver later, wouldn't it call usb_set_interface(), which would call usb_create_sysfs_intf_files() and hit the same issue? Heck, why do both call usb_create_sysfs_intf_file()? I would guess if you're *changing* the active configuration you would need to do that, but why in usb_set_interface() at all? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I say, what are all those naked people doing? -- Big client to Stef User Friendly, 12/14/1997 pgpUQw629YoXR.pgp Description: PGP signature
Re: [linux-usb-devel] usb+sysfs: duplicate filename 'bInterfaceNumber'
On Tue, Oct 16, 2007 at 02:04:43PM -0400, Alan Stern wrote: On Tue, 16 Oct 2007, Matthew Dharm wrote: I haven't looked at this code at all, but neither approach feels right to me. How does this work at all? Even if you load a driver later, wouldn't it call usb_set_interface(), which would call usb_create_sysfs_intf_files() and hit the same issue? usb_set_interface() is smart enough to remove the old interface files before creating new ones, since it expects them to exist already. Hence there's no problem in that scenario. But usb_set_configuration doesn't expect there to be any pre-existing interface files, because there isn't even an interface until the registration is performed. And I'm guessing that you can't call usb_create_sysfs_intf_files() until registration is performed, right? The most important reason has to do with the endpoint pseudo-devices. Different altsettings can have different endpoints, so those have to be removed and re-created whenever the altsetting changes. Right, altsettings. I forgot about those. I only ever think in terms of multiple configurations. *grumble* If usb_set_interface() has to be smart enough to remove existing files first already, then I guess it's reasonably symmetric to have usb_set_configuration() have the same smarts. Maybe they can share some common code, even. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: Why are you upgrading to NT? AJ: It must be the sick, sadistic streak that runs through me. -- Chief and A.J. User Friendly, 5/12/1998 pgpyl02DsudZG.pgp Description: PGP signature
Re: [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6
odd number of
> sectors then it must be wrong, but this turns out not to be true.
>
> Why doesn't Windows need this? For all we know, it does. Has anybody
> ever tried forcing Windows to read the sector beyond the end of one of
> these buggy devices?
As far as I know, Windows doesn't need this because of the way FAT and NTFS
work. They never use the end of the disk (by more than a few sectors, or
so I'm told).
> There's a straightforward solution: Never try to use the last sector --
> in effect, assume every device has the FIX_CAPACITY flag set. Doing
> this universally could cause data loss, however, so again I have been
> opposed to it.
I agree here.
> > - US_FL_SINGLE_LUN:
> > At least a few of these seem to indicate that the real problem
> > could be detected dynamically ("device reports Sub=ff") rather
> > than with a quirk. Quirks are unmaintainable (and change), but
> > noticing when devices return impossible values and going into a
> > "safe mode" is just defensive programming.
>
> This is almost certainly a case where lots of the entries are no longer
> needed. But it isn't easy to tell which ones can safely be removed.
I've been meaning to start sending e-mails to see if we can get rid of
these. Most of the devices which required it were UFI, which reports "LUN
not present" in a goofy way. We fixed the code to detect it properly, but
there are still quite a few devices out there that don't implement the
correct (if goofy) method.
Most of those entries (which are for UFI devices) can go, if we get a
volunteer to take the e-mail addresses listed in unusual_devs.h and work
the list.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed
suction darts!
-- Salesperson to Greg
User Friendly, 12/30/1997
pgpEZykmzYxa5.pgp
Description: PGP signature
Re: [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6
solution: Never try to use the last sector -- in effect, assume every device has the FIX_CAPACITY flag set. Doing this universally could cause data loss, however, so again I have been opposed to it. I agree here. - US_FL_SINGLE_LUN: At least a few of these seem to indicate that the real problem could be detected dynamically (device reports Sub=ff) rather than with a quirk. Quirks are unmaintainable (and change), but noticing when devices return impossible values and going into a safe mode is just defensive programming. This is almost certainly a case where lots of the entries are no longer needed. But it isn't easy to tell which ones can safely be removed. I've been meaning to start sending e-mails to see if we can get rid of these. Most of the devices which required it were UFI, which reports LUN not present in a goofy way. We fixed the code to detect it properly, but there are still quite a few devices out there that don't implement the correct (if goofy) method. Most of those entries (which are for UFI devices) can go, if we get a volunteer to take the e-mail addresses listed in unusual_devs.h and work the list. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed suction darts! -- Salesperson to Greg User Friendly, 12/30/1997 pgpEZykmzYxa5.pgp Description: PGP signature
Re: [2.6 patch] usbat_check_status(): fix check-after-use
Signed-off-by: Matthew Dharm <[EMAIL PROTECTED]> On Tue, Jul 31, 2007 at 12:28:22AM +0200, Adrian Bunk wrote: > The Coverity checker spotted that we have already oops'ed if "us" > was NULL. > > Since "us" can't be NULL in the only caller this patch removes the > NULL check. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > --- > --- linux-2.6.23-rc1-mm1/drivers/usb/storage/shuttle_usbat.c.old > 2007-07-30 16:56:34.0 +0200 > +++ linux-2.6.23-rc1-mm1/drivers/usb/storage/shuttle_usbat.c 2007-07-30 > 16:57:24.0 +0200 > @@ -190,9 +190,6 @@ static int usbat_check_status(struct us_ > unsigned char *reply = us->iobuf; > int rc; > > - if (!us) > - return USB_STOR_TRANSPORT_ERROR; > - > rc = usbat_get_status(us, reply); > if (rc != USB_STOR_XFER_GOOD) > return USB_STOR_TRANSPORT_FAILED; -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I need a computer? -- Customer User Friendly, 2/19/1998 pgpfw0F2z8IIs.pgp Description: PGP signature
Re: [2.6 patch] usbat_check_status(): fix check-after-use
Signed-off-by: Matthew Dharm [EMAIL PROTECTED] On Tue, Jul 31, 2007 at 12:28:22AM +0200, Adrian Bunk wrote: The Coverity checker spotted that we have already oops'ed if us was NULL. Since us can't be NULL in the only caller this patch removes the NULL check. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- --- linux-2.6.23-rc1-mm1/drivers/usb/storage/shuttle_usbat.c.old 2007-07-30 16:56:34.0 +0200 +++ linux-2.6.23-rc1-mm1/drivers/usb/storage/shuttle_usbat.c 2007-07-30 16:57:24.0 +0200 @@ -190,9 +190,6 @@ static int usbat_check_status(struct us_ unsigned char *reply = us-iobuf; int rc; - if (!us) - return USB_STOR_TRANSPORT_ERROR; - rc = usbat_get_status(us, reply); if (rc != USB_STOR_XFER_GOOD) return USB_STOR_TRANSPORT_FAILED; -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I need a computer? -- Customer User Friendly, 2/19/1998 pgpfw0F2z8IIs.pgp Description: PGP signature
Re: [Linux-usb-users] Possible bug in usb storage (2.6.11 kernel)
On Thu, Sep 08, 2005 at 02:28:09PM -0600, Jim Ramsay wrote: > On 9/8/05, Jim Ramsay <[EMAIL PROTECTED]> wrote: > > On 9/8/05, Matthew Dharm <[EMAIL PROTECTED]> wrote: > > > On Thu, Sep 08, 2005 at 11:14:36AM -0600, Jim Ramsay wrote: > > > > I think I have found a possible bug: > > > > [...] > > > > I suppose the scsi code could be changed to guarantee that > > > > srb->request_buffer is page-aligned or cache-aligned, but that seems > > > > like the wrong solution for this bug. > > > > > > Fixing the SCSI layer is -exactly- the correct solution. The SCSI layer > > > is > > > supposed to guarantee us that those buffers are suitable for DMA'ing, and > > > apparently it's violating that promise. > > > > Thanks, I'll check on what buffer I'm actually getting, where it's > > allocated, and post back what I find, or how I fixed it. > > More information: > > The error only occurrs during device sensing when the > srb->request_buffer is assigned as follows, by usb/storage/transport.c > in the routine usb_stor_invoke_transport: > > old_request_buffer = srb->request_buffer; > srb->request_buffer = srb->sense_buffer; > > Now, this is a problem because srb->sense_buffer is defined as follows > in the struct scsi_cmnd: > > #define SCSI_SENSE_BUFFERSIZE 96 > unsigned char sense_buffer[SCSI_SENSE_BUFFERSIZE]; > > Since it is not allocated at runtime there is NO WAY the SCSI layer > can possibly guarantee it is page- or cache-aligned and ready for DMA. > > Any suggestions on best fix for this? Is it still a SCSI-layer issue? > Or should USB step up in this case and ensure this buffer is dma-safe > itself? Ah, that buffer doesn't come from SCSI (tho I've long thought they should provide us with a sense data buffer). So this is a real usb-storage bug. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 pgpQzpGy1JW4Y.pgp Description: PGP signature
Re: [Linux-usb-users] Possible bug in usb storage (2.6.11 kernel)
On Thu, Sep 08, 2005 at 11:14:36AM -0600, Jim Ramsay wrote: > I think I have found a possible bug: > [...] > I suppose the scsi code could be changed to guarantee that > srb->request_buffer is page-aligned or cache-aligned, but that seems > like the wrong solution for this bug. Fixing the SCSI layer is -exactly- the correct solution. The SCSI layer is supposed to guarantee us that those buffers are suitable for DMA'ing, and apparently it's violating that promise. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 pgph1LFD78sjm.pgp Description: PGP signature
Re: [Linux-usb-users] Possible bug in usb storage (2.6.11 kernel)
On Thu, Sep 08, 2005 at 11:14:36AM -0600, Jim Ramsay wrote: I think I have found a possible bug: [...] I suppose the scsi code could be changed to guarantee that srb-request_buffer is page-aligned or cache-aligned, but that seems like the wrong solution for this bug. Fixing the SCSI layer is -exactly- the correct solution. The SCSI layer is supposed to guarantee us that those buffers are suitable for DMA'ing, and apparently it's violating that promise. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 pgph1LFD78sjm.pgp Description: PGP signature
Re: [Linux-usb-users] Possible bug in usb storage (2.6.11 kernel)
On Thu, Sep 08, 2005 at 02:28:09PM -0600, Jim Ramsay wrote: On 9/8/05, Jim Ramsay [EMAIL PROTECTED] wrote: On 9/8/05, Matthew Dharm [EMAIL PROTECTED] wrote: On Thu, Sep 08, 2005 at 11:14:36AM -0600, Jim Ramsay wrote: I think I have found a possible bug: [...] I suppose the scsi code could be changed to guarantee that srb-request_buffer is page-aligned or cache-aligned, but that seems like the wrong solution for this bug. Fixing the SCSI layer is -exactly- the correct solution. The SCSI layer is supposed to guarantee us that those buffers are suitable for DMA'ing, and apparently it's violating that promise. Thanks, I'll check on what buffer I'm actually getting, where it's allocated, and post back what I find, or how I fixed it. More information: The error only occurrs during device sensing when the srb-request_buffer is assigned as follows, by usb/storage/transport.c in the routine usb_stor_invoke_transport: old_request_buffer = srb-request_buffer; srb-request_buffer = srb-sense_buffer; Now, this is a problem because srb-sense_buffer is defined as follows in the struct scsi_cmnd: #define SCSI_SENSE_BUFFERSIZE 96 unsigned char sense_buffer[SCSI_SENSE_BUFFERSIZE]; Since it is not allocated at runtime there is NO WAY the SCSI layer can possibly guarantee it is page- or cache-aligned and ready for DMA. Any suggestions on best fix for this? Is it still a SCSI-layer issue? Or should USB step up in this case and ensure this buffer is dma-safe itself? Ah, that buffer doesn't come from SCSI (tho I've long thought they should provide us with a sense data buffer). So this is a real usb-storage bug. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 pgpQzpGy1JW4Y.pgp Description: PGP signature
Re: [linux-usb-devel] Genesys USB 2.0 enclosures
On Sat, Sep 03, 2005 at 09:53:19PM -0400, Alan Stern wrote: > On Sat, 3 Sep 2005, Jan De Luyck wrote: > > > I've posted in the past about problems with these enclosures - increasing > > the > > delay seems to fix it, albeit temporarily. The further you go in using the > > disk in such an enclosure, the higher the udelay() had to be - atleast > > that's > > what I'm seeing here (I've got two of these now :/ ) > > > > One permanent fix is adding a powered USB-hub in between the drive > > enclosures > > and the computer. Since I've done that, I've no longer seen any of the > > problems (i've attached the 'fault' log). Weird but true, since the drives > > come with their own powersupply. > > > > Hope this helps anyone in the future running into the same problem. > > This one certainly goes into the Bizarro file. > > Just out of curiosity -- when you use the powered hub, does the drive work > even if you remove that delay completely? Aren't USB 2.0 hubs more "intelligent" as part of the requirement to support 1.1 and 2.0 devices? I wonder if it's really a 2.0 drive, and if the timing is different enough with the hub to make a difference. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver THEY CASTRATED MY QUAKE BITS! I WANT THEM BACK -- Greg User Friendly, 3/27/1998 pgpBpRkEQySEG.pgp Description: PGP signature
Re: [linux-usb-devel] Genesys USB 2.0 enclosures
On Sat, Sep 03, 2005 at 09:53:19PM -0400, Alan Stern wrote: On Sat, 3 Sep 2005, Jan De Luyck wrote: I've posted in the past about problems with these enclosures - increasing the delay seems to fix it, albeit temporarily. The further you go in using the disk in such an enclosure, the higher the udelay() had to be - atleast that's what I'm seeing here (I've got two of these now :/ ) One permanent fix is adding a powered USB-hub in between the drive enclosures and the computer. Since I've done that, I've no longer seen any of the problems (i've attached the 'fault' log). Weird but true, since the drives come with their own powersupply. Hope this helps anyone in the future running into the same problem. This one certainly goes into the Bizarro file. Just out of curiosity -- when you use the powered hub, does the drive work even if you remove that delay completely? Aren't USB 2.0 hubs more intelligent as part of the requirement to support 1.1 and 2.0 devices? I wonder if it's really a 2.0 drive, and if the timing is different enough with the hub to make a difference. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver THEY CASTRATED MY QUAKE BITS! I WANT THEM BACK -- Greg User Friendly, 3/27/1998 pgpBpRkEQySEG.pgp Description: PGP signature
Re: mmap() and ioctl()
On Mon, Apr 04, 2005 at 03:02:26PM -0400, Richard B. Johnson wrote: > On Mon, 4 Apr 2005, Matthew Dharm wrote: > > >This probably is a silly question, but > > > >Is is possible to open a file, mmap() it into memory, then pass the address > >of that map via an ioctl() call to the kernel, which will copy_from_user() > >that data? > > > > Yes. A user-mode pointer, passed via ioctl() is valid in the kernel > in the context of the user, i.e., during read() write() ioctl(). > > However, it is not valid if it is accessed by some other process or > an interrupt. In other words, you can't store it somewhere and > access it later in some other context. Right, I've got that part. The plan has been to mmap(), ioctl(), and inside the ioctl do a copy_from_user() into a kernel-context buffer. > >Yeah, that's an odd concept, I know... I could always malloc() some > >memory, read the file in, and then ioctl() it. But, if I could get away > >with a direct mmap(), that would be much better for me. > > Since you need to copy anyway, you could mmap() your kernel > data (impliment mmap in your driver). Then you mmap both > "files" the same way and copy to/from in user-mode. That's an interesting concept, and one I'm not familiar with. Any useful pointers (beyond UTSL)? I'll admit to being much more familiar with SCSI and USB internals than I am with something like device-layer interfacing. It sounds like you're saying that my driver can implement an mmap() method (similar to the ioctl method), and then I can just mmap the source file and the driver /dev node and do a memcpy() between them. That's an interesting idea, but potentially not what I need. The data needs to go with some command information and a buffer to stuff the results in. This is basically a co-processor device I'm talking to. The basic data path here is from a file, through the driver, to a custom piece of hardware (and back again). Tho, anything that allows me to move the data from the disk up to a place where I can pci_map_single() it faster is a Good Thing(tm). Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed suction darts! -- Salesperson to Greg User Friendly, 12/30/1997 pgplo8XgKAdOM.pgp Description: PGP signature
mmap() and ioctl()
This probably is a silly question, but Is is possible to open a file, mmap() it into memory, then pass the address of that map via an ioctl() call to the kernel, which will copy_from_user() that data? Yeah, that's an odd concept, I know... I could always malloc() some memory, read the file in, and then ioctl() it. But, if I could get away with a direct mmap(), that would be much better for me. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I say, what are all those naked people doing? -- Big client to Stef User Friendly, 12/14/1997 pgpvU4zFwKbOy.pgp Description: PGP signature
mmap() and ioctl()
This probably is a silly question, but Is is possible to open a file, mmap() it into memory, then pass the address of that map via an ioctl() call to the kernel, which will copy_from_user() that data? Yeah, that's an odd concept, I know... I could always malloc() some memory, read the file in, and then ioctl() it. But, if I could get away with a direct mmap(), that would be much better for me. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I say, what are all those naked people doing? -- Big client to Stef User Friendly, 12/14/1997 pgpvU4zFwKbOy.pgp Description: PGP signature
Re: mmap() and ioctl()
On Mon, Apr 04, 2005 at 03:02:26PM -0400, Richard B. Johnson wrote: On Mon, 4 Apr 2005, Matthew Dharm wrote: This probably is a silly question, but Is is possible to open a file, mmap() it into memory, then pass the address of that map via an ioctl() call to the kernel, which will copy_from_user() that data? Yes. A user-mode pointer, passed via ioctl() is valid in the kernel in the context of the user, i.e., during read() write() ioctl(). However, it is not valid if it is accessed by some other process or an interrupt. In other words, you can't store it somewhere and access it later in some other context. Right, I've got that part. The plan has been to mmap(), ioctl(), and inside the ioctl do a copy_from_user() into a kernel-context buffer. Yeah, that's an odd concept, I know... I could always malloc() some memory, read the file in, and then ioctl() it. But, if I could get away with a direct mmap(), that would be much better for me. Since you need to copy anyway, you could mmap() your kernel data (impliment mmap in your driver). Then you mmap both files the same way and copy to/from in user-mode. That's an interesting concept, and one I'm not familiar with. Any useful pointers (beyond UTSL)? I'll admit to being much more familiar with SCSI and USB internals than I am with something like device-layer interfacing. It sounds like you're saying that my driver can implement an mmap() method (similar to the ioctl method), and then I can just mmap the source file and the driver /dev node and do a memcpy() between them. That's an interesting idea, but potentially not what I need. The data needs to go with some command information and a buffer to stuff the results in. This is basically a co-processor device I'm talking to. The basic data path here is from a file, through the driver, to a custom piece of hardware (and back again). Tho, anything that allows me to move the data from the disk up to a place where I can pci_map_single() it faster is a Good Thing(tm). Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed suction darts! -- Salesperson to Greg User Friendly, 12/30/1997 pgplo8XgKAdOM.pgp Description: PGP signature
Re: sizeof(ptr) or sizeof(*ptr)?
On Sun, Feb 27, 2005 at 08:25:04PM +, [EMAIL PROTECTED] wrote:
> I decided to tweak sparse to give warnings on sizeof(pointer), so that I could
> check for other cases like this. The tweak was a very crude hack that I'm not
> proud of, and I am still trying to make it more reliable.
>
> So far I found 2 interesting cases (in 2.6.11-rc5). I'm not sure they are
> bugs,
> but they sure look suspicious.
>
> 1: drivers/usb/storage/usb.c:788
>
> /*
>* Since this is a new device, we need to register a SCSI
>* host definition with the higher SCSI layers.
>*/
> us->host = scsi_host_alloc(_stor_host_template, sizeof(us));
> if (!us->host) {
> printk(KERN_WARNING USB_STORAGE
> "Unable to allocate the scsi host\n");
> return -EBUSY;
> }
>
> "us" is a "struct us_data *". It seems pretty weird that we're allocating
> something the size of a pointer, and then waste a pointer to keep the address
> where it is allocated. So maybe this should be:
>
> us->host = scsi_host_alloc(_stor_host_template, sizeof(*us));
This is actually correct as-is. We're allocating a host, and asking for
the sizeof(pointer) in the 'extra storage' section. We then store the
pointer (not what it points to) in the extra storage section a few lines down.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
S: Another stupid question?
G: There's no such thing as a stupid question, only stupid people.
-- Stef and Greg
User Friendly, 7/15/1998
pgpkrUwIFp8xT.pgp
Description: PGP signature
Re: sizeof(ptr) or sizeof(*ptr)?
On Sun, Feb 27, 2005 at 08:25:04PM +, [EMAIL PROTECTED] wrote:
I decided to tweak sparse to give warnings on sizeof(pointer), so that I could
check for other cases like this. The tweak was a very crude hack that I'm not
proud of, and I am still trying to make it more reliable.
So far I found 2 interesting cases (in 2.6.11-rc5). I'm not sure they are
bugs,
but they sure look suspicious.
1: drivers/usb/storage/usb.c:788
/*
* Since this is a new device, we need to register a SCSI
* host definition with the higher SCSI layers.
*/
us-host = scsi_host_alloc(usb_stor_host_template, sizeof(us));
if (!us-host) {
printk(KERN_WARNING USB_STORAGE
Unable to allocate the scsi host\n);
return -EBUSY;
}
us is a struct us_data *. It seems pretty weird that we're allocating
something the size of a pointer, and then waste a pointer to keep the address
where it is allocated. So maybe this should be:
us-host = scsi_host_alloc(usb_stor_host_template, sizeof(*us));
This is actually correct as-is. We're allocating a host, and asking for
the sizeof(pointer) in the 'extra storage' section. We then store the
pointer (not what it points to) in the extra storage section a few lines down.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
S: Another stupid question?
G: There's no such thing as a stupid question, only stupid people.
-- Stef and Greg
User Friendly, 7/15/1998
pgpkrUwIFp8xT.pgp
Description: PGP signature
Re: [BK] upgrade will be needed
On Mon, Feb 14, 2005 at 07:54:14PM +0100, Juergen Stuber wrote: > Hi Larry, > > [EMAIL PROTECTED] (Larry McVoy) writes: > > The protection we need is that people don't get to > > > > - use BK > > - stop using BK so they can go work on another system > > - start using BK again > > - stop using BK so they can go work on another system > > ... > > > > We could say that if you stop using BK and work on another system then > > you can't ever use it again. We're not going to do that, we've already > > had to calm the fears of people who found themselves in that situation > > for their job. > > how about something akin to > 'You can only use the non-paying version of BK > if you haven't worked on another SCM-system in the last year.' A year seems long. Perhaps 6 months? That should be high enough to prevent the ping-pong that Larry wants to stop, but not so high that I can't be employable. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998 pgp1wkO9mpN1X.pgp Description: PGP signature
Re: [BK] upgrade will be needed
On Mon, Feb 14, 2005 at 07:54:14PM +0100, Juergen Stuber wrote: Hi Larry, [EMAIL PROTECTED] (Larry McVoy) writes: The protection we need is that people don't get to - use BK - stop using BK so they can go work on another system - start using BK again - stop using BK so they can go work on another system ... We could say that if you stop using BK and work on another system then you can't ever use it again. We're not going to do that, we've already had to calm the fears of people who found themselves in that situation for their job. how about something akin to 'You can only use the non-paying version of BK if you haven't worked on another SCM-system in the last year.' A year seems long. Perhaps 6 months? That should be high enough to prevent the ping-pong that Larry wants to stop, but not so high that I can't be employable. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998 pgp1wkO9mpN1X.pgp Description: PGP signature
Re: your mail
It's basically just like the code says. A lot of devices choke if you access them too quickly after enumeration. The 5 second delay seems to be enough for most devices. But we made it adjustable exactly for people like you. Matt On Wed, Feb 02, 2005 at 04:17:13PM -0800, Aleksey Gorelov wrote: > Hi Matt, Alan, > > Could you please tell me (link would do) why it makes default > delay_use=5 > really necessary (from the patch below)? > https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074 > 7.html > > It makes USB boot really painfull and slow :( > > I understand there should be a good reason for it. I've tried to find > an answer in > archives, without much success though. > > Thanks, > Aleks. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Now payink attention, please. This is mouse. Click-click. Easy to use, da? Now you try... -- Pitr to Miranda User Friendly, 10/11/1998 pgpDzPywIhFwy.pgp Description: PGP signature
Re: your mail
It's basically just like the code says. A lot of devices choke if you access them too quickly after enumeration. The 5 second delay seems to be enough for most devices. But we made it adjustable exactly for people like you. Matt On Wed, Feb 02, 2005 at 04:17:13PM -0800, Aleksey Gorelov wrote: Hi Matt, Alan, Could you please tell me (link would do) why it makes default delay_use=5 really necessary (from the patch below)? https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074 7.html It makes USB boot really painfull and slow :( I understand there should be a good reason for it. I've tried to find an answer in archives, without much success though. Thanks, Aleks. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Now payink attention, please. This is mouse. Click-click. Easy to use, da? Now you try... -- Pitr to Miranda User Friendly, 10/11/1998 pgpDzPywIhFwy.pgp Description: PGP signature
Re: Memory Stick read-only in 2.6.10
Did you turn on CONFIG_USB_STORAGE_RW_DETECT? Matt On Tue, Feb 01, 2005 at 09:28:45AM -0500, Bill Davidsen wrote: > I upgraded a system from 2.4.19 (or so) to 2.6.10. Using a USB memory > stick reader one, and only one, stick is now read-only. > - I can't go back, this was a backup/reinstall upgrade > - it doesn't happen on Win98 > - it doesn't happen on WinXPhome > - it doesn't happen on OSX > - it doesn't happen in the camera > - it doesn't happen with four other sticks bought at the same time >and used in the same camera > > Out of the box FC2 + 2.6.10 built from kernel.org source. > > Before I start playing with the drivers and all, is there a known oddity > in this area which I missed searching? > > -- >-bill davidsen ([EMAIL PROTECTED]) > "The secret to procrastination is to put things off until the > last possible moment - but no longer" -me > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver We can customize our colonels. -- Tux User Friendly, 12/1/1998 pgpChANPyJevc.pgp Description: PGP signature
Re: Memory Stick read-only in 2.6.10
Did you turn on CONFIG_USB_STORAGE_RW_DETECT? Matt On Tue, Feb 01, 2005 at 09:28:45AM -0500, Bill Davidsen wrote: I upgraded a system from 2.4.19 (or so) to 2.6.10. Using a USB memory stick reader one, and only one, stick is now read-only. - I can't go back, this was a backup/reinstall upgrade - it doesn't happen on Win98 - it doesn't happen on WinXPhome - it doesn't happen on OSX - it doesn't happen in the camera - it doesn't happen with four other sticks bought at the same time and used in the same camera Out of the box FC2 + 2.6.10 built from kernel.org source. Before I start playing with the drivers and all, is there a known oddity in this area which I missed searching? -- -bill davidsen ([EMAIL PROTECTED]) The secret to procrastination is to put things off until the last possible moment - but no longer -me - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver We can customize our colonels. -- Tux User Friendly, 12/1/1998 pgpChANPyJevc.pgp Description: PGP signature
Re: RFC: [2.6 patch] let BLK_DEV_UB depend on USB_STORAGE=n
On Wed, Jan 19, 2005 at 02:07:07PM -0800, Greg KH wrote: > On Thu, Dec 23, 2004 at 03:40:31AM +0100, Adrian Bunk wrote: > > On Sun, Dec 19, 2004 at 04:31:46PM -0800, Greg KH wrote: > > > On Mon, Dec 20, 2004 at 01:16:44AM +0100, Adrian Bunk wrote: > > > > I've already seen people crippling their usb-storage driver with > > > > enabling BLK_DEV_UB - and I doubt the warning in the help text added > > > > after 2.6.9 will fix all such problems. > > > > > > > > Is there except for kernel size any good reason for using BLK_DEV_UB > > > > instead of USB_STORAGE? > > > > > > You don't want to use the scsi layer? You like the stability of it at > > > times? :) > > > > > > > If not, I'd suggest the patch below to let BLK_DEV_UB depend > > > > on EMBEDDED. > > > > > > No, it's good for non-embedded boxes too. > > > > > > My current understanding is: > > - BLK_DEV_UB supports a subset of what USB_STORAGE can support > > - for an average user, there's no reason to enable BLK_DEV_UB > > - if you really know what you are doing, there might be several reasons > > why you might want to use BLK_DEV_UB > > I have been running with just the code portion of this patch for a while > now, with good results (no Kconfig changes.) > > Pete and Matt, do you mind me applying the following portion of the > patch to the kernel tree? I have no objection. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver E: You run this ship with Windows?! YOU IDIOT! L: Give me a break, it came bundled with the computer! -- ESR and Lan Solaris User Friendly, 12/8/1998 pgp7YGciMjT7c.pgp Description: PGP signature
Re: RFC: [2.6 patch] let BLK_DEV_UB depend on USB_STORAGE=n
On Wed, Jan 19, 2005 at 02:07:07PM -0800, Greg KH wrote: On Thu, Dec 23, 2004 at 03:40:31AM +0100, Adrian Bunk wrote: On Sun, Dec 19, 2004 at 04:31:46PM -0800, Greg KH wrote: On Mon, Dec 20, 2004 at 01:16:44AM +0100, Adrian Bunk wrote: I've already seen people crippling their usb-storage driver with enabling BLK_DEV_UB - and I doubt the warning in the help text added after 2.6.9 will fix all such problems. Is there except for kernel size any good reason for using BLK_DEV_UB instead of USB_STORAGE? You don't want to use the scsi layer? You like the stability of it at times? :) If not, I'd suggest the patch below to let BLK_DEV_UB depend on EMBEDDED. No, it's good for non-embedded boxes too. My current understanding is: - BLK_DEV_UB supports a subset of what USB_STORAGE can support - for an average user, there's no reason to enable BLK_DEV_UB - if you really know what you are doing, there might be several reasons why you might want to use BLK_DEV_UB I have been running with just the code portion of this patch for a while now, with good results (no Kconfig changes.) Pete and Matt, do you mind me applying the following portion of the patch to the kernel tree? I have no objection. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver E: You run this ship with Windows?! YOU IDIOT! L: Give me a break, it came bundled with the computer! -- ESR and Lan Solaris User Friendly, 12/8/1998 pgp7YGciMjT7c.pgp Description: PGP signature
ACPI in 2.4.6 detects power button twice
I just installed 2.4.6, and turned ACPI on (and APM off). On startup, APCI reports "Power button: found" twice. Also, in /proc/acpi/button there are two directories named "power". acpid is able to see the events properly, tho, and shutdown the computer. This is a Tyan 1598S motherboard running an AMD K6-II 500MHz. Will test code to help get this fixed. :) Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Somebody call an exorcist! -- Dust Puppy User Friendly, 5/16/1998 PGP signature
ACPI in 2.4.6 detects power button twice
I just installed 2.4.6, and turned ACPI on (and APM off). On startup, APCI reports Power button: found twice. Also, in /proc/acpi/button there are two directories named power. acpid is able to see the events properly, tho, and shutdown the computer. This is a Tyan 1598S motherboard running an AMD K6-II 500MHz. Will test code to help get this fixed. :) Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Somebody call an exorcist! -- Dust Puppy User Friendly, 5/16/1998 PGP signature
Re: Simple example of using slab allocator?
Well, if it's really that simple
Another aspect of this, tho, is that I'd like to be able to profile my
memory usage. Does the SA have any ability to report (easily) the number
of pages allocated and how full each one is?
Matt Dharm
On Mon, Jun 18, 2001 at 10:56:36AM -0600, Andreas Dilger wrote:
> Matthew Dharm writes:
> > For 2.5, I'm planning on switching my driver over to the slab allocator,
> > for a variety of reasons. Does anyone have a _dead_ simple example of how
> > to use such a beast? I've seen the various web pages and document
> > explaining the API, but I love to see working examples for reference (and
> > to fill in the blanks).
>
> The slab allocator IS dead simple to use, basically:
>
> - driver global variable:
>
> kmem_cache_t *usb_mass_cachep;
>
> - in the driver init function:
>
> usb_mass_cachep = kmem_cache_create("usb_mass_cache",
> sizeof(struct whatever),
> 0, SLAB_HWCACHE_ALIGN,
> NULL, NULL);
> (check for NULL usb_mass_slab)
>
> - in the driver cleanup function:
>
> if (usb_mass_cachep && kmem_cache_destroy(usb_mass_cachep))
> printk(KERN_ERR "usb_mass_cache: not all structures freed\n");
>
> - wherever you need an item from the slab cache:
>
> whateverp = kmem_cache_alloc(usb_mass_cachep, GFP_KERNEL);
> (check for NULL whateverp)
>
> - when you are done with it:
>
> kmem_cache_free(usb_mass_cachep, whateverp);
>
> Notes:
> - if you have a slab leak and you don't free all of the items (hence the slab
> cache is not removed), you will probably get an oops when you reload the
> driver. You can only have one slab cache per name ("usb_mass_cache" here).
> - You may need different alignment (SLAB_HWCACHE_ALIGN), or not
> - You may need different allocation policy (GFP_KERNEL), or not
>
> Cheers, Andreas
> --
> Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
> \ would they cancel out, leaving him still hungry?"
> http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
God, root, what is difference?
-- Pitr
User Friendly, 11/11/1999
PGP signature
Re: Simple example of using slab allocator?
Well, if it's really that simple Another aspect of this, tho, is that I'd like to be able to profile my memory usage. Does the SA have any ability to report (easily) the number of pages allocated and how full each one is? Matt Dharm On Mon, Jun 18, 2001 at 10:56:36AM -0600, Andreas Dilger wrote: Matthew Dharm writes: For 2.5, I'm planning on switching my driver over to the slab allocator, for a variety of reasons. Does anyone have a _dead_ simple example of how to use such a beast? I've seen the various web pages and document explaining the API, but I love to see working examples for reference (and to fill in the blanks). The slab allocator IS dead simple to use, basically: - driver global variable: kmem_cache_t *usb_mass_cachep; - in the driver init function: usb_mass_cachep = kmem_cache_create(usb_mass_cache, sizeof(struct whatever), 0, SLAB_HWCACHE_ALIGN, NULL, NULL); (check for NULL usb_mass_slab) - in the driver cleanup function: if (usb_mass_cachep kmem_cache_destroy(usb_mass_cachep)) printk(KERN_ERR usb_mass_cache: not all structures freed\n); - wherever you need an item from the slab cache: whateverp = kmem_cache_alloc(usb_mass_cachep, GFP_KERNEL); (check for NULL whateverp) - when you are done with it: kmem_cache_free(usb_mass_cachep, whateverp); Notes: - if you have a slab leak and you don't free all of the items (hence the slab cache is not removed), you will probably get an oops when you reload the driver. You can only have one slab cache per name (usb_mass_cache here). - You may need different alignment (SLAB_HWCACHE_ALIGN), or not - You may need different allocation policy (GFP_KERNEL), or not Cheers, Andreas -- Andreas Dilger \ If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry? http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver God, root, what is difference? -- Pitr User Friendly, 11/11/1999 PGP signature
Re: Snowhite and the Seven Dwarfs - The REAL story!
No kidding... getting this once was funny enough on this mailing list... but twice in the same day? I am just rolling in the asiles here... Matt On Sat, Jun 16, 2001 at 01:34:59AM +0200, Tobias Ringstrom wrote: > On Fri, 15 Jun 2001, Hahaha wrote: > > > Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and > > polite with Snowhite. When they go out work at mornign, they promissed a > > *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven > > Dwarfs enter... > > Ah... the joy of reading mail using non-MS software, on a non-MS OS... > > Hahaha, indeed! > > /Tobias > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver S: Another stupid question? G: There's no such thing as a stupid question, only stupid people. -- Stef and Greg User Friendly, 7/15/1998 PGP signature
Simple example of using slab allocator?
For 2.5, I'm planning on switching my driver over to the slab allocator, for a variety of reasons. Does anyone have a _dead_ simple example of how to use such a beast? I've seen the various web pages and document explaining the API, but I love to see working examples for reference (and to fill in the blanks). Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Okay, this isn't funny anymore! Let me down! I'll tell Bill on you!! -- Microsoft Salesman User Friendly, 4/1/1998 PGP signature
Simple example of using slab allocator?
For 2.5, I'm planning on switching my driver over to the slab allocator, for a variety of reasons. Does anyone have a _dead_ simple example of how to use such a beast? I've seen the various web pages and document explaining the API, but I love to see working examples for reference (and to fill in the blanks). Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Okay, this isn't funny anymore! Let me down! I'll tell Bill on you!! -- Microsoft Salesman User Friendly, 4/1/1998 PGP signature
Re: Snowhite and the Seven Dwarfs - The REAL story!
No kidding... getting this once was funny enough on this mailing list... but twice in the same day? I am just rolling in the asiles here... Matt On Sat, Jun 16, 2001 at 01:34:59AM +0200, Tobias Ringstrom wrote: On Fri, 15 Jun 2001, Hahaha wrote: Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and polite with Snowhite. When they go out work at mornign, they promissed a *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven Dwarfs enter... Ah... the joy of reading mail using non-MS software, on a non-MS OS... Hahaha, indeed! /Tobias - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver S: Another stupid question? G: There's no such thing as a stupid question, only stupid people. -- Stef and Greg User Friendly, 7/15/1998 PGP signature
Re: USB-storage and 2.4.2
Try 2.4.5, which has some assorted fixes that should solve this problem. Matt On Sun, Jun 03, 2001 at 08:08:25PM -0500, Jerry Frana wrote: > Hi, i've been having a problem with my usb zip drive (older 100mb model) > > it's 100% repeateble: > > copy a large file to anywhere, and within a minute or so: > copy stops dead. > and the following appears in the syslog: > > Jun 3 21:10:56 int-21h kernel: uhci: host controller process error. something bad >happened > Jun 3 21:10:56 int-21h kernel: uhci: host controller halted. very bad > > my machine is a K6-3/350, kernel 2.4.2, via mvp3 chipset > > if you need any more info, please let me know, > > Thanks > David F. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Senior Software Designer, Momentum Computer C: Why are you upgrading to NT? AJ: It must be the sick, sadistic streak that runs through me. -- Chief and A.J. User Friendly, 5/12/1998 PGP signature
Re: USB-storage and 2.4.2
Try 2.4.5, which has some assorted fixes that should solve this problem. Matt On Sun, Jun 03, 2001 at 08:08:25PM -0500, Jerry Frana wrote: Hi, i've been having a problem with my usb zip drive (older 100mb model) it's 100% repeateble: copy a large file to anywhere, and within a minute or so: copy stops dead. and the following appears in the syslog: Jun 3 21:10:56 int-21h kernel: uhci: host controller process error. something bad happened Jun 3 21:10:56 int-21h kernel: uhci: host controller halted. very bad my machine is a K6-3/350, kernel 2.4.2, via mvp3 chipset if you need any more info, please let me know, Thanks David F. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Senior Software Designer, Momentum Computer C: Why are you upgrading to NT? AJ: It must be the sick, sadistic streak that runs through me. -- Chief and A.J. User Friendly, 5/12/1998 PGP signature
Re: mount /dev/hdb2 /usr; swapon /dev/hdb2 keeps flooding
I was under the impression that you need to call swapon on swap partitions, and not on mounted filesystems. Matt On Sun, May 13, 2001 at 01:00:39AM +0200, BERECZ Szabolcs wrote: > Hi! > > root@kama3:/home/szabi# cat /proc/mounts > ... > /dev/hdb2 /usr ext2 rw 0 0 > ... > root@kama3:/home/szabi# swapon /dev/hdb2 > set_blocksize: b_count 1, dev ide0(3,66), block 2, from c0126b48 > set_blocksize: b_count 1, dev ide0(3,66), block 3, from c0126b48 > set_blocksize: b_count 1, dev ide0(3,66), block 4, from c0126b48 > set_blocksize: b_count 1, dev ide0(3,66), block 5, from c0126b48 > set_blocksize: b_count 1, dev ide0(3,66), block 6, from c0126b48 > set_blocksize: b_count 1, dev ide0(3,66), block 7, from c0126b48 > set_blocksize: b_count 1, dev ide0(3,66), block 8, from c0126b48 > set_blocksize: b_count 1, dev ide0(3,66), block 1, from c0126b48 > Unable to find swap-space signature > swapon: /dev/hdb2: Invalid argument > root@kama3:/home/szabi# > > and then set_blocksize keeps flooding the console, not continuously, > but 20-40 lines at a time, then it sleeps a bit, sometimes half a > minute (caused by kupdated?) > > root@kama3:/home/szabi# mount -o remount,ro /usr > ll_rw_block: device 03:42: only 4096-char blocks implemented (1024) > root@kama3:/home/szabi# > > once I got these: > ll_rw_block: device 03:42: only 4096-char blocks implemented (1024) > EXT2-fs error (device ide0(3,66)): ext2_write_inode: unable to read inode block > - inode=2084, block=8207 > ll_rw_block: device 03:42: only 4096-char blocks implemented (1024) > EXT2-fs error (device ide0(3,66)): ext2_write_inode: unable to read inode block > - inode=6328, block=24609 > ... > > szabi@kama3:/hdc1/kernel/linux-2.4.4-ac6# gdb vmlinux > (gdb) disas 0xc0126b48 > ... > 0xc0126b43 :call 0xc012bcc0 > 0xc0126b48 :mov0xe8(%edi),%edi > 0xc0126b4e :mov%edi,0xffd0(%ebp) > ... > > I tried it on several partitions, and it worked on /dev/hdc, > and did not work on /dev/hdb > on /dev/hdb all the filesystems are ext2 > on /dev/hdc one fs is a new, clean ext2, the others are reiserfs > > so I really don't know what's the problem. > > do you need any other information? > > Bye, > Szabi > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: Like the Furby? DP: He gives me the creeps. Think the SPCA will take him? -- Cobb and Dust Puppy User Friendly, 1/2/1999 PGP signature
Re: mount /dev/hdb2 /usr; swapon /dev/hdb2 keeps flooding
I was under the impression that you need to call swapon on swap partitions, and not on mounted filesystems. Matt On Sun, May 13, 2001 at 01:00:39AM +0200, BERECZ Szabolcs wrote: Hi! root@kama3:/home/szabi# cat /proc/mounts ... /dev/hdb2 /usr ext2 rw 0 0 ... root@kama3:/home/szabi# swapon /dev/hdb2 set_blocksize: b_count 1, dev ide0(3,66), block 2, from c0126b48 set_blocksize: b_count 1, dev ide0(3,66), block 3, from c0126b48 set_blocksize: b_count 1, dev ide0(3,66), block 4, from c0126b48 set_blocksize: b_count 1, dev ide0(3,66), block 5, from c0126b48 set_blocksize: b_count 1, dev ide0(3,66), block 6, from c0126b48 set_blocksize: b_count 1, dev ide0(3,66), block 7, from c0126b48 set_blocksize: b_count 1, dev ide0(3,66), block 8, from c0126b48 set_blocksize: b_count 1, dev ide0(3,66), block 1, from c0126b48 Unable to find swap-space signature swapon: /dev/hdb2: Invalid argument root@kama3:/home/szabi# and then set_blocksize keeps flooding the console, not continuously, but 20-40 lines at a time, then it sleeps a bit, sometimes half a minute (caused by kupdated?) root@kama3:/home/szabi# mount -o remount,ro /usr ll_rw_block: device 03:42: only 4096-char blocks implemented (1024) root@kama3:/home/szabi# once I got these: ll_rw_block: device 03:42: only 4096-char blocks implemented (1024) EXT2-fs error (device ide0(3,66)): ext2_write_inode: unable to read inode block - inode=2084, block=8207 ll_rw_block: device 03:42: only 4096-char blocks implemented (1024) EXT2-fs error (device ide0(3,66)): ext2_write_inode: unable to read inode block - inode=6328, block=24609 ... szabi@kama3:/hdc1/kernel/linux-2.4.4-ac6# gdb vmlinux (gdb) disas 0xc0126b48 ... 0xc0126b43 sys_swapon+371:call 0xc012bcc0 set_blocksize 0xc0126b48 sys_swapon+376:mov0xe8(%edi),%edi 0xc0126b4e sys_swapon+382:mov%edi,0xffd0(%ebp) ... I tried it on several partitions, and it worked on /dev/hdc, and did not work on /dev/hdb on /dev/hdb all the filesystems are ext2 on /dev/hdc one fs is a new, clean ext2, the others are reiserfs so I really don't know what's the problem. do you need any other information? Bye, Szabi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: Like the Furby? DP: He gives me the creeps. Think the SPCA will take him? -- Cobb and Dust Puppy User Friendly, 1/2/1999 PGP signature
Re: OnStream USB
I'm the owner of that first URL. The driver works for me. Make sure you enable the "Freecom USB/ATAPI" support under the USB Mass Storage option in the kernel configuration. Note that this is only supported for 2.4.x series kernels. Matt On Tue, May 01, 2001 at 02:58:59PM -0400, Geoffrey Gallaway wrote: > Hello, > > I am considering getting an OnStream USB tape backup drive. I want the > USB version because I have about 4 machines all on different networks > that need to be backed up. Using USB would allow me to move the unit > from one machine to another without rebooting the machine. > > I see that the SCSI version of the drive seems to be supported in linux > but I can only find tidbits of information that don't confirm or deny > this. Listed below are two sites that have some information which seem > to confirm that the drive does indeed work, but I simply want to be > sure. > > http://www2.one-eyed-alien.net/~mdharm/linux-usb/ > http://linux1.onstream.nl/test/ > > Thank you, > Geoff > > -- > Geoffrey Gallaway || > [EMAIL PROTECTED] || Clones are people two. > D e v o r z h u n || > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 PGP signature
Re: OnStream USB
I'm the owner of that first URL. The driver works for me. Make sure you enable the Freecom USB/ATAPI support under the USB Mass Storage option in the kernel configuration. Note that this is only supported for 2.4.x series kernels. Matt On Tue, May 01, 2001 at 02:58:59PM -0400, Geoffrey Gallaway wrote: Hello, I am considering getting an OnStream USB tape backup drive. I want the USB version because I have about 4 machines all on different networks that need to be backed up. Using USB would allow me to move the unit from one machine to another without rebooting the machine. I see that the SCSI version of the drive seems to be supported in linux but I can only find tidbits of information that don't confirm or deny this. Listed below are two sites that have some information which seem to confirm that the drive does indeed work, but I simply want to be sure. http://www2.one-eyed-alien.net/~mdharm/linux-usb/ http://linux1.onstream.nl/test/ Thank you, Geoff -- Geoffrey Gallaway || [EMAIL PROTECTED] || Clones are people two. D e v o r z h u n || - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 PGP signature
Re: Sony Memory stick format funnies...
I've seen something similar with USB memory stick devices... they don't seem to report a media change in a way that the VFS layer will understand. I think this deserves some _serious_ debugging, personally, as this is going to come back to haunt us over and over again with some types of memory stick (and possibly other) media devices. I'd do it, but I don't have a memory stick reader. Rogier, can you volunteer some time for this? Matt On Sun, Apr 29, 2001 at 10:45:41PM +0200, Rogier Wolff wrote: > H. Peter Anvin wrote: > > > Rogier Wolff wrote: > > > > The image of the disk (including partition table) is at: > > > > > > ftp://ftp.bitwizard.nl/misc_junk/formatted.img.gz > > > > > > It's 63kb and uncompresses to the 64Mb (almost) that it's sold as. > > > > > > > And on at least this kernel (2.4.0) there is nothing funny about it: > > > > : tazenda 13 ; ls -l /mnt > > total 0 > > -r-xr-xr-x1 root root0 May 23 2000 memstick.ind* > > : tazenda 14 ; > > > > Mounting msdos, vfat or umsdos, no change. > > OK. I rebooted the laptop: > > Linux version 2.2.13 ([EMAIL PROTECTED]) (gcc version > egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Nov 8 > 15:37:25 CET 1999 > > which seems to have cleared it. Somehow that directory was still > cached somewhere (not in the buffer cache) from when there were images > on the memory stick. > > So, I'm suspecting a dcache bug, that allows something to stay over > after swapping a removable media device And all this is irrelevant > as this was on a very old kernel. Sorry to have been wasting your > time. > > Roger. > > -- > ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** > *-- BitWizard writes Linux device drivers for any device you may have! --* > * There are old pilots, and there are bold pilots. > * There are also old, bald pilots. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver S: Another stupid question? G: There's no such thing as a stupid question, only stupid people. -- Stef and Greg User Friendly, 7/15/1998 PGP signature
Re: Dane-Elec PhotoMate Combo
I would seriously argue with the "works beautifully" part of that. The DPCM code relies on the SDDR09 code, which is horrendously buggy. It's also being actively worked on. I can crash it at will with relatively simple operations. Matt On Sun, Apr 29, 2001 at 02:21:11PM +0200, [EMAIL PROTECTED] wrote: > From: Matthew Dharm <[EMAIL PROTECTED]> > > > (ii) this card needs usb/storage/dpcm.c which is compiled when > > CONFIG_USB_STORAGE_DPCM is set, but this variable is missing > > from usb/Config.in. Add it. > > This config option is considered so immature that it's not ready for the > kernel config, even as an EXPERIMENTAL. Use it at your own risk. > > Of course. But the choice is simple. Without it, one has a non-functional > device. With it, one has a device that works beautifully. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998 PGP signature
Re: Mounting an external USB host-powered ZIP 250 drive hangs in mount()
I see you're using the alternate uhci driver... are hte results the same
with the other UHCI driver?
Can you turn on usb mass storage verbose debuggig (compile option) and then
send me the logs?
Matt
On Sun, Apr 29, 2001 at 07:58:56AM +0200, [EMAIL PROTECTED] wrote:
> I cannot seem to mount my external USB host-powered 250 Mb zip-drive in
> Linux-2.4.3-ac12. This is a freshly rebooted machine, rebooted with the
> zip-drive attached and a zip-disk inside that Windows-2000 will read
> without problems.
>
> dmesg:
> uhci.c: USB UHCI at I/O 0xc400, IRQ 7
> usb.c: new USB bus registered, assigned bus number 1
> hub.c: USB hub found
> hub.c: 2 ports detected
> uhci.c: USB UHCI at I/O 0xc800, IRQ 7
> usb.c: new USB bus registered, assigned bus number 2
> hub.c: USB hub found
> hub.c: 2 ports detected
> Initializing USB Mass Storage driver...
> usb.c: registered new driver usb-storage
> USB Mass Storage support registered.
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMP
> IP: routing cache hash table of 4096 buckets, 32Kbytes
> TCP: Hash tables configured (established 32768 bind 32768)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 240k freed
> hub.c: USB new device connect on bus1/1, assigned device number 2
> scsi1 : SCSI emulation for USB Mass Storage devices
> Vendor: IOMEGAModel: ZIP 250 Rev: 61.T
> Type: Direct-Access ANSI SCSI revision: 02
> Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0
> sda : READ CAPACITY failed.
> sda : status = 1, message = 00, host = 0, driver = 08
> sda : extended sense code = 2
> sda : block size assumed to be 512 bytes, disk size 1GB.
> sda: I/O error: dev 08:00, sector 0
> unable to read partition table
> WARNING: USB Mass Storage data integrity not assured
> USB Mass Storage device found at 2
> ==
> IRQ 7 is an unshared IRQ.
> I've read that the 'READ CAPACITY failed' indicates there is no disk
> in the drive - but there is.
>
>
> /proc/scsi/usb-storage-0/1:
>Host scsi1: usb-storage
>Vendor: Iomega
> Product: USB Zip 250
> Serial Number: 003240BCC4D11622
> Protocol: Transparent SCSI
> Transport: Bulk
> GUID: 059b0032003240bcc4d11622
>
> All seems fine, but when I do
>
> mount /dev/sda4 /mnt
>
> the whole kernel hangs, including the keyboard and the network.
> Windows-2000 on the same hardware can access the device. If I strace the
> mount progress, it hangs in
>
> mount("/dev/sda4", "/mnt", "vfat", 0xc0ed000, 0
>
> I've searched the web, searched the mailing lists at usb/sourceforge,
> and I seem to be alone in this.
>
> Hardware:
>
> Abit VP6, dual P3/866
> 512 Mb memory
> gcc-2.95.3
> SuSE 7.1 basis
> linux-2.4.3-ac12
>
> Kernel config:
>
> CONFIG_USB=y
> CONFIG_USB_UHCI_ALT=y
> CONFIG_USB_STORAGE=y
> CONFIG_SCSI=y
> CONFIG_SCSI_DEBUG_QUEUES=y
> CONFIG_SCSI_MULTI_LUN=y
> CONFIG_SCSI_CONSTANTS=y
> CONFIG_SCSI_SYM53C8XX=y
> CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4
> CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
> CONFIG_SCSI_NCR53C8XX_SYNC=20
> CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT=y
>
> I thought that would do the trick?
>
> Thanks for any help that prevents me from rebooting into Windows-2000
> every time!
>
> Jurriaan
> --
> I have transcended that phase in my intellectual growth where I discover
> humour in simple freakishness. What exists is real, therefore it is tragic,
> since whatever lives must die. Only fantasy, the vapors rising from sheer
> nonsense, can now excite my laughter.
> Jack Vance - Lyonesse II - The Green Pearl
> GNU/Linux 2.4.3-ac12 SMP/ReiserFS 2x1743 bogomips load av: 0.05 0.03 0.00
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Way to go, lava boy.
-- Stef to Greg
User Friendly, 3/26/1998
PGP signature
Re: Mounting an external USB host-powered ZIP 250 drive hangs in mount()
I see you're using the alternate uhci driver... are hte results the same with the other UHCI driver? Can you turn on usb mass storage verbose debuggig (compile option) and then send me the logs? Matt On Sun, Apr 29, 2001 at 07:58:56AM +0200, [EMAIL PROTECTED] wrote: I cannot seem to mount my external USB host-powered 250 Mb zip-drive in Linux-2.4.3-ac12. This is a freshly rebooted machine, rebooted with the zip-drive attached and a zip-disk inside that Windows-2000 will read without problems. dmesg: uhci.c: USB UHCI at I/O 0xc400, IRQ 7 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected uhci.c: USB UHCI at I/O 0xc800, IRQ 7 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage USB Mass Storage support registered. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 32768) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 240k freed hub.c: USB new device connect on bus1/1, assigned device number 2 scsi1 : SCSI emulation for USB Mass Storage devices Vendor: IOMEGAModel: ZIP 250 Rev: 61.T Type: Direct-Access ANSI SCSI revision: 02 Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0 sda : READ CAPACITY failed. sda : status = 1, message = 00, host = 0, driver = 08 sda : extended sense code = 2 sda : block size assumed to be 512 bytes, disk size 1GB. sda: I/O error: dev 08:00, sector 0 unable to read partition table WARNING: USB Mass Storage data integrity not assured USB Mass Storage device found at 2 == IRQ 7 is an unshared IRQ. I've read that the 'READ CAPACITY failed' indicates there is no disk in the drive - but there is. /proc/scsi/usb-storage-0/1: Host scsi1: usb-storage Vendor: Iomega Product: USB Zip 250 Serial Number: 003240BCC4D11622 Protocol: Transparent SCSI Transport: Bulk GUID: 059b0032003240bcc4d11622 All seems fine, but when I do mount /dev/sda4 /mnt the whole kernel hangs, including the keyboard and the network. Windows-2000 on the same hardware can access the device. If I strace the mount progress, it hangs in mount(/dev/sda4, /mnt, vfat, 0xc0ed000, 0 I've searched the web, searched the mailing lists at usb/sourceforge, and I seem to be alone in this. Hardware: Abit VP6, dual P3/866 512 Mb memory gcc-2.95.3 SuSE 7.1 basis linux-2.4.3-ac12 Kernel config: CONFIG_USB=y CONFIG_USB_UHCI_ALT=y CONFIG_USB_STORAGE=y CONFIG_SCSI=y CONFIG_SCSI_DEBUG_QUEUES=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_SYM53C8XX=y CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4 CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32 CONFIG_SCSI_NCR53C8XX_SYNC=20 CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT=y I thought that would do the trick? Thanks for any help that prevents me from rebooting into Windows-2000 every time! Jurriaan -- I have transcended that phase in my intellectual growth where I discover humour in simple freakishness. What exists is real, therefore it is tragic, since whatever lives must die. Only fantasy, the vapors rising from sheer nonsense, can now excite my laughter. Jack Vance - Lyonesse II - The Green Pearl GNU/Linux 2.4.3-ac12 SMP/ReiserFS 2x1743 bogomips load av: 0.05 0.03 0.00 -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Way to go, lava boy. -- Stef to Greg User Friendly, 3/26/1998 PGP signature
Re: Sony Memory stick format funnies...
I've seen something similar with USB memory stick devices... they don't seem to report a media change in a way that the VFS layer will understand. I think this deserves some _serious_ debugging, personally, as this is going to come back to haunt us over and over again with some types of memory stick (and possibly other) media devices. I'd do it, but I don't have a memory stick reader. Rogier, can you volunteer some time for this? Matt On Sun, Apr 29, 2001 at 10:45:41PM +0200, Rogier Wolff wrote: H. Peter Anvin wrote: Rogier Wolff wrote: The image of the disk (including partition table) is at: ftp://ftp.bitwizard.nl/misc_junk/formatted.img.gz It's 63kb and uncompresses to the 64Mb (almost) that it's sold as. And on at least this kernel (2.4.0) there is nothing funny about it: : tazenda 13 ; ls -l /mnt total 0 -r-xr-xr-x1 root root0 May 23 2000 memstick.ind* : tazenda 14 ; Mounting msdos, vfat or umsdos, no change. OK. I rebooted the laptop: Linux version 2.2.13 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Nov 8 15:37:25 CET 1999 which seems to have cleared it. Somehow that directory was still cached somewhere (not in the buffer cache) from when there were images on the memory stick. So, I'm suspecting a dcache bug, that allows something to stay over after swapping a removable media device And all this is irrelevant as this was on a very old kernel. Sorry to have been wasting your time. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver S: Another stupid question? G: There's no such thing as a stupid question, only stupid people. -- Stef and Greg User Friendly, 7/15/1998 PGP signature
Re: Dane-Elec PhotoMate Combo
I would seriously argue with the works beautifully part of that. The DPCM code relies on the SDDR09 code, which is horrendously buggy. It's also being actively worked on. I can crash it at will with relatively simple operations. Matt On Sun, Apr 29, 2001 at 02:21:11PM +0200, [EMAIL PROTECTED] wrote: From: Matthew Dharm [EMAIL PROTECTED] (ii) this card needs usb/storage/dpcm.c which is compiled when CONFIG_USB_STORAGE_DPCM is set, but this variable is missing from usb/Config.in. Add it. This config option is considered so immature that it's not ready for the kernel config, even as an EXPERIMENTAL. Use it at your own risk. Of course. But the choice is simple. Without it, one has a non-functional device. With it, one has a device that works beautifully. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998 PGP signature
Re: Dane-Elec PhotoMate Combo
On Sat, Apr 28, 2001 at 05:02:21PM +0200, [EMAIL PROTECTED] wrote: > I just got a Dane-Elec PhotoMate Combo SmartMedia/CompactFlash reader > manufactured by SCM Microsystems. It is a USB device with ID 04e6:0005. > > The http://www.qbik.ch/usb/devices/ list of supported devices > calls this thing unsupported, and [EMAIL PROTECTED] writes: > "I want this to work ! I'll help testing." > > I think the status can be changed to fully supported, at least > it works fine in my first tests. > > Changes required: > (i) in sd.c there is a peculiar code fragment that assumes > that a removable disk is write protected in case the status is unknown; > reversing this default allows writing to the flash card. This is an unsafe assumption. The code fragment you call "peculiar" is definately necessary. > (ii) this card needs usb/storage/dpcm.c which is compiled when > CONFIG_USB_STORAGE_DPCM is set, but this variable is missing > from usb/Config.in. Add it. This config option is considered so immature that it's not ready for the kernel config, even as an EXPERIMENTAL. Use it at your own risk. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver A female who groks UNIX? My universe is collapsing. -- Mike User Friendly, 10/11/1998 PGP signature
Re: Dane-Elec PhotoMate Combo
On Sat, Apr 28, 2001 at 05:02:21PM +0200, [EMAIL PROTECTED] wrote: I just got a Dane-Elec PhotoMate Combo SmartMedia/CompactFlash reader manufactured by SCM Microsystems. It is a USB device with ID 04e6:0005. The http://www.qbik.ch/usb/devices/ list of supported devices calls this thing unsupported, and [EMAIL PROTECTED] writes: I want this to work ! I'll help testing. I think the status can be changed to fully supported, at least it works fine in my first tests. Changes required: (i) in sd.c there is a peculiar code fragment that assumes that a removable disk is write protected in case the status is unknown; reversing this default allows writing to the flash card. This is an unsafe assumption. The code fragment you call peculiar is definately necessary. (ii) this card needs usb/storage/dpcm.c which is compiled when CONFIG_USB_STORAGE_DPCM is set, but this variable is missing from usb/Config.in. Add it. This config option is considered so immature that it's not ready for the kernel config, even as an EXPERIMENTAL. Use it at your own risk. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver A female who groks UNIX? My universe is collapsing. -- Mike User Friendly, 10/11/1998 PGP signature
Re: usb-storage log verbosity
Umm.. all the printk's are inclosed with the ifdef, courtsey of a little bit of #define magic. I use it all the time (after all, I'm the maintainer), and when I want it to shut up, it shuts up. Are you sure you recompiled and installed properly? Re-ran 'make dep'? I've had reports of this before -- every one of them was solved by a proper recompilation. Matt On Mon, Mar 05, 2001 at 04:55:02PM +0100, J . A . Magallon wrote: > Hi, > > I have recently started to use an USB cd toaster and have a little problem. > Writer is driven by usb-storage and scsi-cdrom and scsi-generic drivers. > Burning works fine. > > The problem is that the usb-storage module spits so many info-debug > messages (even if I configured no debug in kernel config) that after > a cd burn I end up with a 25 MB file in /var/log/messages and other 25MB > in /var/log/kernel/info, so it fills my / partition. > > If someone know a fast way to shut up usb-storage, I'll be gratefull. > If not, I will try to make a patch to enclose all that printk's into > #ifdef CONFIG_USB_STORAGE_DEBUG. > > -- > J.A. Magallon $> cd pub > mailto:[EMAIL PROTECTED] $> more beer > > Linux werewolf 2.4.2-ac11 #1 SMP Sat Mar 3 22:18:57 CET 2001 i686 > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver We've made a business out of making money from annoying and stupid people. I think you fall under that category. -- Chief User Friendly, 7/11/1998 PGP signature
Re: usb-storage log verbosity
Umm.. all the printk's are inclosed with the ifdef, courtsey of a little bit of #define magic. I use it all the time (after all, I'm the maintainer), and when I want it to shut up, it shuts up. Are you sure you recompiled and installed properly? Re-ran 'make dep'? I've had reports of this before -- every one of them was solved by a proper recompilation. Matt On Mon, Mar 05, 2001 at 04:55:02PM +0100, J . A . Magallon wrote: Hi, I have recently started to use an USB cd toaster and have a little problem. Writer is driven by usb-storage and scsi-cdrom and scsi-generic drivers. Burning works fine. The problem is that the usb-storage module spits so many info-debug messages (even if I configured no debug in kernel config) that after a cd burn I end up with a 25 MB file in /var/log/messages and other 25MB in /var/log/kernel/info, so it fills my / partition. If someone know a fast way to shut up usb-storage, I'll be gratefull. If not, I will try to make a patch to enclose all that printk's into #ifdef CONFIG_USB_STORAGE_DEBUG. -- J.A. Magallon $ cd pub mailto:[EMAIL PROTECTED] $ more beer Linux werewolf 2.4.2-ac11 #1 SMP Sat Mar 3 22:18:57 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver We've made a business out of making money from annoying and stupid people. I think you fall under that category. -- Chief User Friendly, 7/11/1998 PGP signature
Re: dropcopyright script
Same here. While it's a nice script and all, I personally want the copyright and associated contact information in a clear and easy-to-find place. In other words, if you get Linus to patch the kernel to do this, then I'm just going to try to get him to patch it back. Matt On Wed, Feb 14, 2001 at 07:55:03AM +, Russell King wrote: > Rick Hohensee writes: > > ... > > ## drop copyright notices to the bottoms of C files in current dir and > > # subs. > > Please don't run this on any files maintained by myself. I want the > copyright notices to be prominently displayed at the top of the file > so it can't be missed. > > Thanks. > > -- > Russell King ([EMAIL PROTECTED])The developer of ARM Linux > http://www.arm.linux.org.uk/personal/aboutme.html > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 PGP signature
Re: dropcopyright script
Same here. While it's a nice script and all, I personally want the copyright and associated contact information in a clear and easy-to-find place. In other words, if you get Linus to patch the kernel to do this, then I'm just going to try to get him to patch it back. Matt On Wed, Feb 14, 2001 at 07:55:03AM +, Russell King wrote: Rick Hohensee writes: ... ## drop copyright notices to the bottoms of C files in current dir and # subs. Please don't run this on any files maintained by myself. I want the copyright notices to be prominently displayed at the top of the file so it can't be missed. Thanks. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 PGP signature
Re: Linux Post codes during runtime, possibly OT
Isn't that always the way in the Open Source world? :) Seriously, tho... does anyone have some list of who is using what ports? At least, in general? Matt On Thu, Jan 25, 2001 at 02:32:41PM -0800, H. Peter Anvin wrote: > Matthew Dharm wrote: > > > > It occurs to me that it might be a good idea to pick a different port for > > these things. I know a lot of people who want to use port 80h for > > debugging data, especially in embedded x86 systems. > > > > Find a safe port, make sure it is tested the hell out of, and we'll > consider it. > > -hpa > > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver P: How about "Web Designer"? DP: I'd like a name that people won't laugh at. -- Pitr and Dust Puppy User Friendly, 12/6/1997 PGP signature
Re: Linux Post codes during runtime, possibly OT
It occurs to me that it might be a good idea to pick a different port for these things. I know a lot of people who want to use port 80h for debugging data, especially in embedded x86 systems. Matt On Thu, Jan 25, 2001 at 02:26:36PM -0800, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:"Ian S. Nelson" <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > I'm curious. Why does Linux make that friendly 98/9a/88 looking > > postcode pattern when it's running? DOS and DOS95 don't do that. > > > > I'm begining to feel like I can tell the system health by observing it, > > kind of like "seeing the matrix." > > > > It output garbage to the 80h port in order to enforce I/O delays. > It's one of the safe ports to issue outs to. > > -hpa > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I say, what are all those naked people doing? -- Big client to Stef User Friendly, 12/14/1997 PGP signature
Re: Linux Post codes during runtime, possibly OT
It occurs to me that it might be a good idea to pick a different port for these things. I know a lot of people who want to use port 80h for debugging data, especially in embedded x86 systems. Matt On Thu, Jan 25, 2001 at 02:26:36PM -0800, H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:"Ian S. Nelson" [EMAIL PROTECTED] In newsgroup: linux.dev.kernel I'm curious. Why does Linux make that friendly 98/9a/88 looking postcode pattern when it's running? DOS and DOS95 don't do that. I'm begining to feel like I can tell the system health by observing it, kind of like "seeing the matrix." It output garbage to the 80h port in order to enforce I/O delays. It's one of the safe ports to issue outs to. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I say, what are all those naked people doing? -- Big client to Stef User Friendly, 12/14/1997 PGP signature
Re: Linux Post codes during runtime, possibly OT
Isn't that always the way in the Open Source world? :) Seriously, tho... does anyone have some list of who is using what ports? At least, in general? Matt On Thu, Jan 25, 2001 at 02:32:41PM -0800, H. Peter Anvin wrote: Matthew Dharm wrote: It occurs to me that it might be a good idea to pick a different port for these things. I know a lot of people who want to use port 80h for debugging data, especially in embedded x86 systems. Find a safe port, make sure it is tested the hell out of, and we'll consider it. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver P: How about "Web Designer"? DP: I'd like a name that people won't laugh at. -- Pitr and Dust Puppy User Friendly, 12/6/1997 PGP signature
Re: USB Mass Storage in 2.4.0
Do you have an OHCI controller or an UHCI controller? I noticed that you're using the "alternate" UHCI driver... can you try this with the standard UHCI driver? Matt On Fri, Jan 12, 2001 at 03:34:41PM -0800, Robert J. Bell wrote: > Unfortunately I lost everything on my system (the one that worked) and I > don't believe I ever looked in /proc/scsi/scsi because It was working > and I didn't feel the need to go poking around. I had this problem > initially the first time I compiled 2.4.0 but I went back and added SCSI > Generic "on" and that seemed to fix it. I am just confused why it > thinks this is a scanner. IS there any way to force it to detect it as a > scsi disk? > > I must have recompiled this kernel 50 times trying to recreate the the > scenario where this worked. I can send you my .config if you think that > will help. > > Robert > > > > > > Matthew Dharm wrote: > > > Hrm... from these logs, everything looks okay, except for the fact that the > > device refuses to return any INQUIRY data. > > > > Can you reproduce the conditions under which it was working and send logs > > from that? Or at least remember what the /proc/scsi/scsi info looked like? > > > > Matt > > > > On Fri, Jan 12, 2001 at 03:19:36PM -0800, Robert J. Bell wrote: > > > >> Matthew here is the info you requested, thanks for your help. > >> > >> -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 PGP signature
Re: USB Mass Storage in 2.4.0
Hrm... from these logs, everything looks okay, except for the fact that the device refuses to return any INQUIRY data. Can you reproduce the conditions under which it was working and send logs from that? Or at least remember what the /proc/scsi/scsi info looked like? Matt On Fri, Jan 12, 2001 at 03:19:36PM -0800, Robert J. Bell wrote: > Matthew here is the info you requested, thanks for your help. > > -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What the hell are you? -- Pitr to Dust Puppy User Friendly, 12/3/1997 PGP signature
Re: USB Mass Storage in 2.4.0
Please turn on USB Mass Storage debugging and send me the dmesg output from when you attach the device and load the drivers. Matt On Fri, Jan 12, 2001 at 02:46:46PM -0800, Robert J. Bell wrote: > I know there has been some talk arround this topic on this list so If I > missed the answer I apologize, i just joined the list today. I read > through the archive and all I could find relative to mass storage is the > scsi dependancy, which I am aware of. Here is my situation. > > I have a Fujufilm FX-1400 digital camera that uses the USB Mass Storage > driver. I know it works because I had it working in 2.4.0-test12, and in > 2.4.0 however I had a major system failure and lost my new kernel. This > time arround I can not get USB Mass Storage to work. I have tried > various combinations of the scsi and usb options. I thought maybe I > needed SCSI Disk support as well but it didnt seem to matter. I have > tried with scsi and usb mass storage as modules and as part of the > kernel, still no luck. Here is what happens when I connect the camera : > > Jan 10 18:49:05 t20 kernel: hub.c: USB new device connect on bus1/1, > assigned device number 3 > Jan 10 18:49:05 t20 kernel: Product: USB Mass Storage > Jan 10 18:49:05 t20 kernel: SerialNumber: Y-170^000810X003005237 > Jan 10 18:49:06 t20 kernel: scsi0 : SCSI emulation for USB Mass Storage > devices > Jan 10 18:49:06 t20 kernel: Vendor: `.À ÀòÏ Model: \206 Ø\177.À¡# > À ÝòÏ Rev: > Jan 10 18:49:06 t20 kernel: Type: Scanner > ANSI SCSI revision: 02 > > Now this used to detect a scsi disk and all I had to do was mount it. I > am sure there must be other conflicting config options but I just dont > know what it could be. Any help would be greatly appreciated. > > Robert. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Oh great modem, why hast thou forsaken me? -- Dust Puppy User Friendly, 3/2/1998 PGP signature
Re: USB Mass Storage in 2.4.0
Please turn on USB Mass Storage debugging and send me the dmesg output from when you attach the device and load the drivers. Matt On Fri, Jan 12, 2001 at 02:46:46PM -0800, Robert J. Bell wrote: I know there has been some talk arround this topic on this list so If I missed the answer I apologize, i just joined the list today. I read through the archive and all I could find relative to mass storage is the scsi dependancy, which I am aware of. Here is my situation. I have a Fujufilm FX-1400 digital camera that uses the USB Mass Storage driver. I know it works because I had it working in 2.4.0-test12, and in 2.4.0 however I had a major system failure and lost my new kernel. This time arround I can not get USB Mass Storage to work. I have tried various combinations of the scsi and usb options. I thought maybe I needed SCSI Disk support as well but it didnt seem to matter. I have tried with scsi and usb mass storage as modules and as part of the kernel, still no luck. Here is what happens when I connect the camera : Jan 10 18:49:05 t20 kernel: hub.c: USB new device connect on bus1/1, assigned device number 3 Jan 10 18:49:05 t20 kernel: Product: USB Mass Storage Jan 10 18:49:05 t20 kernel: SerialNumber: Y-170^000810X003005237 Jan 10 18:49:06 t20 kernel: scsi0 : SCSI emulation for USB Mass Storage devices Jan 10 18:49:06 t20 kernel: Vendor: `. Model: \206 \177.# Rev: Jan 10 18:49:06 t20 kernel: Type: Scanner ANSI SCSI revision: 02 Now this used to detect a scsi disk and all I had to do was mount it. I am sure there must be other conflicting config options but I just dont know what it could be. Any help would be greatly appreciated. Robert. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Oh great modem, why hast thou forsaken me? -- Dust Puppy User Friendly, 3/2/1998 PGP signature
Re: USB Mass Storage in 2.4.0
Hrm... from these logs, everything looks okay, except for the fact that the device refuses to return any INQUIRY data. Can you reproduce the conditions under which it was working and send logs from that? Or at least remember what the /proc/scsi/scsi info looked like? Matt On Fri, Jan 12, 2001 at 03:19:36PM -0800, Robert J. Bell wrote: Matthew here is the info you requested, thanks for your help. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What the hell are you? -- Pitr to Dust Puppy User Friendly, 12/3/1997 PGP signature
Re: USB Mass Storage in 2.4.0
Do you have an OHCI controller or an UHCI controller? I noticed that you're using the "alternate" UHCI driver... can you try this with the standard UHCI driver? Matt On Fri, Jan 12, 2001 at 03:34:41PM -0800, Robert J. Bell wrote: Unfortunately I lost everything on my system (the one that worked) and I don't believe I ever looked in /proc/scsi/scsi because It was working and I didn't feel the need to go poking around. I had this problem initially the first time I compiled 2.4.0 but I went back and added SCSI Generic "on" and that seemed to fix it. I am just confused why it thinks this is a scanner. IS there any way to force it to detect it as a scsi disk? I must have recompiled this kernel 50 times trying to recreate the the scenario where this worked. I can send you my .config if you think that will help. Robert Matthew Dharm wrote: Hrm... from these logs, everything looks okay, except for the fact that the device refuses to return any INQUIRY data. Can you reproduce the conditions under which it was working and send logs from that? Or at least remember what the /proc/scsi/scsi info looked like? Matt On Fri, Jan 12, 2001 at 03:19:36PM -0800, Robert J. Bell wrote: Matthew here is the info you requested, thanks for your help. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 PGP signature
Re: [linux-usb-devel] Re: Announce: modutils 2.4.0 is available
On Thu, Jan 04, 2001 at 08:54:33PM -0800, David Brownell wrote: > Miles had a suggestion for a "linux-hotplug" mailing list; this > could have been a good issue to coordinate on such a smaller > (lower traffic?) list. Given that I (and many people on linux-scsi, it seems) are looking to "hotplugging" as one of the major enhancements for 2.5.x development, this is probably a good idea. Can vger.kernel.org host this list? Who do we conatct about this? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It's not that hard. No matter what the problem is, tell the customer to reinstall Windows. -- Nurse User Friendly, 3/22/1998 PGP signature
Re: Announce: modutils 2.4.0 is available
Well, I'll be the one to fall on my sword... This is probably my fault. The matching code was pretty much broken for a non-trivial subset of usb devices. I'd submitted the patch to Linus before the holdiays, but it was rejected for various reasons. After some back and forth, Linus finally accepted it on about the 2st of the year. It's pretty much the same patch (functionally) as I posted to the linux-usb-devel mailing list, which I presumed would inform the hotplugging people. Mea culpa, I seem to have been in error there. Tho, that was several weeks ago, so it may have just fallen out of people's heads in the interim time. Keith, if you need any info on what the new structure means, please let me know and I can fill you in on all the details. Matt On Fri, Jan 05, 2001 at 02:56:29PM +1100, Keith Owens wrote: > On Fri, 05 Jan 2001 13:59:12 +1100, > Keith Owens <[EMAIL PROTECTED]> wrote: > >modutils-2.4.0.tar.gz Source tarball, includes RPM spec file > > I have just found out that there was an incompatible change to struct > usb_device_id during 2.4.0-prerelease :(((. That means that all > versions of depmod will break on kernel 2.4.0 if you have any modules > that use MODULE_DEVICE_TABLE(usb). Incompatible changes to an ABI > structure without notification immediately prior to a major kernel > release, yech! > > If you have usb modules then stay on kernel 2.4.0-prerelease or compile > usb without modules or wait until I can test and release modutils > 2.4.1. The usb hotplug utilities will also have to change to handle > the new table layout. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver A: The most ironic oxymoron wins ... DP: "Microsoft Works" A: Uh, okay, you win. -- A.J. & Dust Puppy User Friendly, 1/18/1998 PGP signature
Re: [linux-usb-devel] Re: Announce: modutils 2.4.0 is available
On Thu, Jan 04, 2001 at 08:54:33PM -0800, David Brownell wrote: Miles had a suggestion for a "linux-hotplug" mailing list; this could have been a good issue to coordinate on such a smaller (lower traffic?) list. Given that I (and many people on linux-scsi, it seems) are looking to "hotplugging" as one of the major enhancements for 2.5.x development, this is probably a good idea. Can vger.kernel.org host this list? Who do we conatct about this? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It's not that hard. No matter what the problem is, tell the customer to reinstall Windows. -- Nurse User Friendly, 3/22/1998 PGP signature
Re: Camera as a USB mass storage / SCSI device
On Sun, Dec 31, 2000 at 03:25:25PM -0500, Alastair Foster wrote: > Unfortunately, my camera does not get recognised on bootup. This is hardly > surprising, given that the kernel has no way of determining the camera as a > USB mass storage device. However, I'm curious as to how others have managed > to get away with this by doing nothing more than compiling their kernel with > the above options. Not quite true... USB devices carry a ClassID, which (for most mass storage devices) indicates that it is compliant to the USB Mass Storage Specification. So, the database is only for devices that are slightly out of spec or have descriptors that are not truthful. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 PGP signature
Re: [patchlet] enable HP 8200e USB CDRW
Um, I'm not sure that this driver is even ready for the EXPERIMENTAL label. What does the driver's author say? Matt On Sun, Dec 31, 2000 at 11:50:14AM -0600, Oliver Xymoron wrote: > This patchlet lets me use my HP CDRW. > > --- linux/drivers/usb/Config.in~ Mon Nov 27 20:10:35 2000 > +++ linux/drivers/usb/Config.in Tue Dec 19 12:21:56 2000 > @@ -32,6 +32,9 @@ > if [ "$CONFIG_USB_STORAGE" != "n" ]; then >bool 'USB Mass Storage verbose debug' CONFIG_USB_STORAGE_DEBUG >bool 'Freecom USB/ATAPI Bridge support' CONFIG_USB_STORAGE_FREECOM > + if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then > + bool 'HP8200e support (EXPERIMENTAL)' CONFIG_USB_STORAGE_HP8200e > + fi > fi > dep_tristate ' USB Modem (CDC ACM) support' CONFIG_USB_ACM $CONFIG_USB > dep_tristate ' USB Printer support' CONFIG_USB_PRINTER $CONFIG_USB > > -- > "Love the dolphins," she advised him. "Write by W.A.S.T.E.." > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver G: Let me guess, you started on the 'net with AOL, right? C: WOW! d00d! U r leet! -- Greg and Customer User Friendly, 2/12/1999 PGP signature
Re: Camera as a USB mass storage / SCSI device
On Sun, Dec 31, 2000 at 03:25:25PM -0500, Alastair Foster wrote: Unfortunately, my camera does not get recognised on bootup. This is hardly surprising, given that the kernel has no way of determining the camera as a USB mass storage device. However, I'm curious as to how others have managed to get away with this by doing nothing more than compiling their kernel with the above options. Not quite true... USB devices carry a ClassID, which (for most mass storage devices) indicates that it is compliant to the USB Mass Storage Specification. So, the database is only for devices that are slightly out of spec or have descriptors that are not truthful. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 PGP signature
Re: set_rtc_mmss: can't update from 0 to 59
Honestly, this is the best solution I've heard. It seems that the message is somewhat bogus, anyway, seeing as how this message is somewhat "normal" and just represents the occasional occurance of a fast cmos clock with xntpd and running the code near the top of the hour. Matt On Mon, Dec 18, 2000 at 02:10:32PM +0100, [EMAIL PROTECTED] wrote: > From [EMAIL PROTECTED] Mon Dec 18 04:47:51 2000 > > > so if your cmos time is 0.001 sec ahead of your system time > > then around the hour you'll see > > set_rtc_mmss: can't update from 0 to 59 > > but, the question is, how do we fix this? > > Put #if 0 ... #endif around the printk. > > Andries -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Oh BAY-bee. -- Dust Puppy to Greg User Friendly, 12/13/1997 PGP signature
