Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hi Mikie, > Do you have any news regarding my case of slow transfers via > Speedtouch USB modem on linux ? I found my old speedtouch modem and tested here. I got 2.1 Mbaud bulk downspeed, and 3 Mbaud isoc downspeed. This last is half the speed my line supports, so something is wrong [*]. Unfortunately I'm not very motivated to try to find out what, because I don't use this modem myself anymore. It looks like someone needs to do some more reverse engineering work on the windows driver. Ciao, Duncan. [*] I got the same numbers the last time I tested isoc support, but at that time 3 Mbaud was slightly less than the maximum speed of my line, which explains why I didn't realize that there is a problem. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hi Mikie, Do you have any news regarding my case of slow transfers via Speedtouch USB modem on linux ? I found my old speedtouch modem and tested here. I got 2.1 Mbaud bulk downspeed, and 3 Mbaud isoc downspeed. This last is half the speed my line supports, so something is wrong [*]. Unfortunately I'm not very motivated to try to find out what, because I don't use this modem myself anymore. It looks like someone needs to do some more reverse engineering work on the windows driver. Ciao, Duncan. [*] I got the same numbers the last time I tested isoc support, but at that time 3 Mbaud was slightly less than the maximum speed of my line, which explains why I didn't realize that there is a problem. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hello Duncan, Do you have any news regarding my case of slow transfers via Speedtouch USB modem on linux ? -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hello Duncan, Do you have any news regarding my case of slow transfers via Speedtouch USB modem on linux ? -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/11, Duncan Sands <[EMAIL PROTECTED]>: Hi, > Actually I had to mount it (I hope that not having it mounted does > not change a lot in this matter). probably not. Not having sysfs mounted can cause hotplug to fail, but I think not having /proc/bus/usb mounted shouldn't cause any trouble nowadays. > I:* If#= 1 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch > E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=87(I) Atr=01(Isoc) MxPS= 960 Ivl=1ms The * means that this altsetting is being used - this is the altsetting when using isochronous mode. So it looks to me like isochronous mode is being used. > I have CONFIG_USB_DEBUG=y set in kernel. However I do not see any of > the messages you are referring to. It does not say that it tried isoc > and falls to bulk, nothing like that. Also nothing about "setting > interface to ?? failed". Most likely it is using isochronous transfer. The question then is: why is it slow? I will look in my cupboard to see if I have the same modem, and if so see what speed I can get out of it. > Which debug option should I switch to see these? Something like this IIRC: echo 7 > /proc/sys/kernel/printk Then it should turn up in dmesg. I made a more advanced testing. I used one computer only to be absolutely sure that this is not a hardware issue. So I took a laptop (P4 1.8GHz, OHCI usb host), and booted into Knoppix LiveCD. It was running kernel 2.6.19 and the version of speedtch module was 1.10. First I did something like rmmod speedtch; rmmod ohci-hcd to be sure that I start with a fresh environment. I also did: echo 7 > /proc/sys/kernel/printk which caused the usual debug messages being printed directly in the console. Then I did modprobe ohci-hcd;modprobe speedtch enable_isoc=1 Certainly I've put the same firmware in the /lib/firmware so that udev found it correctly and loaded it up to the modem. The ADSL link went up with the same values (7456 downlink). PPPd started (I use pppoatm.so, if that is important). In this setup I achieved transfer rates of around 480...500 kbyte/s. Then I did the similar thing, but speedtch without enable_isoc, and the result was exactly the same. In both cases I still could not see the messages from the speedtch driver about enabling isochronous mode, or falling back to bulk, nothing like that. Right after that, to minimize the risk of any outside network being overloaded (I doubt that anyway), I switched to Windows Xp. Transfers were up to 730 kbyte/s. So this proves definitely that it is not a hardware related issue. The transfers were so fast that the LED (marked usb led) on the modem, which usually blinks where any transfers are in process, it went completely off, and only blinked once a few seconds... So there is a small progress when compared to my server box (celeron 633 to remind you), where I can get only 400kbyte/s (on this laptop it went 100kbyte/s faster). I still cannot get the full 6mbit/s that my ADSL service runs at on the linux system. -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hi, > Actually I had to mount it (I hope that not having it mounted does > not change a lot in this matter). probably not. Not having sysfs mounted can cause hotplug to fail, but I think not having /proc/bus/usb mounted shouldn't cause any trouble nowadays. > I:* If#= 1 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch > E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=87(I) Atr=01(Isoc) MxPS= 960 Ivl=1ms The * means that this altsetting is being used - this is the altsetting when using isochronous mode. So it looks to me like isochronous mode is being used. > I have CONFIG_USB_DEBUG=y set in kernel. However I do not see any of > the messages you are referring to. It does not say that it tried isoc > and falls to bulk, nothing like that. Also nothing about "setting > interface to ?? failed". Most likely it is using isochronous transfer. The question then is: why is it slow? I will look in my cupboard to see if I have the same modem, and if so see what speed I can get out of it. > Which debug option should I switch to see these? Something like this IIRC: echo 7 > /proc/sys/kernel/printk Then it should turn up in dmesg. Ciao, Duncan. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/11, Duncan Sands <[EMAIL PROTECTED]>: Hi Mikie, > I begin to think that the isochronous mode is not working. I tried the > speedtch module with disabled and enabled isoc and there is no > difference in transfer speeds at all. > > All I checked was : > [EMAIL PROTECTED]:~# cat /sys/module/speedtch/parameters/enable_isoc > Y > > which as I now believe only means what options have been specified, > but does not confirm the actual mode being in use. > Especially that I do not see anything like "isoc support enabled" in > any of the logs. > > Are there any requirements for UHCI hardware to support isoc mode ? > Mine is: > USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 > Controller (rev 08) (prog-if 00 [UHCI]) > > Or maybe I am missing something else? I am sure the isoc mode is > supported by my modem, now I only have doubts if my hardware on server > box supports this ? can you please send the part of /proc/bus/usb/devices concerning the modem, while the modem is plugged in and (supposedly) using isoc mode. If /proc/bus/usb isn't mounted, you can mount it like this IIRC: mount -t usbfs usbfs /proc/bus/usb/ Actually I had to mount it (I hope that not having it mounted does not change a lot in this matter). Here is the cat of "devices" from /proc/bus/usb T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=06b9 ProdID=4061 Rev= 2.00 S: Manufacturer=ALCATEL S: Product=Speed Touch 330 S: SerialNumber=0090D0AA28CD C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=50ms I: If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch I: If#= 1 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I: If#= 1 Alt= 2 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=87(I) Atr=01(Isoc) MxPS= 640 Ivl=1ms I:* If#= 1 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=87(I) Atr=01(Isoc) MxPS= 960 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=05(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms Also, looking in the driver I see that if isoc mode is disabled you should see one of the following messages: - setting interface to ?? failed (??)! - isochronous transfer not supported - using bulk The first one may be a debug message, so you will not necessarily see it depend on which level of kernel debug messages you have turned on. (I have made some changes in my tree so that if you asked for isoc transfer but get bulk then a message is printed). I have CONFIG_USB_DEBUG=y set in kernel. However I do not see any of the messages you are referring to. It does not say that it tried isoc and falls to bulk, nothing like that. Also nothing about "setting interface to ?? failed". Which debug option should I switch to see these? -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hi Mikie, > I begin to think that the isochronous mode is not working. I tried the > speedtch module with disabled and enabled isoc and there is no > difference in transfer speeds at all. > > All I checked was : > [EMAIL PROTECTED]:~# cat /sys/module/speedtch/parameters/enable_isoc > Y > > which as I now believe only means what options have been specified, > but does not confirm the actual mode being in use. > Especially that I do not see anything like "isoc support enabled" in > any of the logs. > > Are there any requirements for UHCI hardware to support isoc mode ? > Mine is: > USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 > Controller (rev 08) (prog-if 00 [UHCI]) > > Or maybe I am missing something else? I am sure the isoc mode is > supported by my modem, now I only have doubts if my hardware on server > box supports this ? can you please send the part of /proc/bus/usb/devices concerning the modem, while the modem is plugged in and (supposedly) using isoc mode. If /proc/bus/usb isn't mounted, you can mount it like this IIRC: mount -t usbfs usbfs /proc/bus/usb/ Also, looking in the driver I see that if isoc mode is disabled you should see one of the following messages: - setting interface to ?? failed (??)! - isochronous transfer not supported - using bulk The first one may be a debug message, so you will not necessarily see it depend on which level of kernel debug messages you have turned on. (I have made some changes in my tree so that if you asked for isoc transfer but get bulk then a message is printed). Ciao, Duncan. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/10, mikie <[EMAIL PROTECTED]>: 2007/7/10, Duncan Sands <[EMAIL PROTECTED]>: > On Tuesday 10 July 2007 11:13:09 mikie wrote: > > 2007/7/10, Duncan Sands <[EMAIL PROTECTED]>: > > > > I also tried a couple of other firmwares available on the net, and > > > > also the one from Windows XP install (which works and achieves speeds > > > > of up to 720kbyte/sec downlink). Some of the firmwares did not work > > > > either, and some worked the same way - it means not more than 3mbit/s > > > > (around 400kbyte/s) could be achieved. > > > > > > I'm pretty sure you won't get anything faster out of a revision 2 modem. > > > > Too bad to hear that :/ > > Especially that windows does this with the same modem without a hitch. > > Really? In that case I take it back, the hardware can clearly do it :) Presumably > you are using the firmware that came with windows? Which kernel version? Also, what > synchronization speed is reported? Yes, the hardware in the modem can do it for sure. I have a laptop with a pentium4 CPU, USB2.0, windows XP installed. I attach the same modem to this laptop and I can go up to 730..740 kbyte/s (the same phone line of course). Windows XP had to be modified with a registry tweak (from thomson website) to switch to isochronous mode and it works. However my server running linux is on a ECS motherboard (P6BAP as I remember), Celeron 633 CPU, USB1.1. I have compiled quite fresh kernel 2.6.21.5 I am 100% sure that I use the same firmware for the modem, because I copied it directly from windows XP from laptop. Now since the modem itself can go as fast as 6mbit/s, I am only concerned if the _computer_ hardware on my linux server box can do it via USB ? I can see the usb reporting it to be at 12Mbit/s, which should be enough to reach 6mbit/s teoretically. CPU load is normal even during transfers. I would have to install windows xp on that machine to be 100% sure that both modem and computer hardware can go up to 6mbit/s via USB... By the way, I just tried to switch sw_buffering in the speedtch module but that did not help. I begin to think that the isochronous mode is not working. I tried the speedtch module with disabled and enabled isoc and there is no difference in transfer speeds at all. All I checked was : [EMAIL PROTECTED]:~# cat /sys/module/speedtch/parameters/enable_isoc Y which as I now believe only means what options have been specified, but does not confirm the actual mode being in use. Especially that I do not see anything like "isoc support enabled" in any of the logs. Are there any requirements for UHCI hardware to support isoc mode ? Mine is: USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 08) (prog-if 00 [UHCI]) Or maybe I am missing something else? I am sure the isoc mode is supported by my modem, now I only have doubts if my hardware on server box supports this ? -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/10, mikie [EMAIL PROTECTED]: 2007/7/10, Duncan Sands [EMAIL PROTECTED]: On Tuesday 10 July 2007 11:13:09 mikie wrote: 2007/7/10, Duncan Sands [EMAIL PROTECTED]: I also tried a couple of other firmwares available on the net, and also the one from Windows XP install (which works and achieves speeds of up to 720kbyte/sec downlink). Some of the firmwares did not work either, and some worked the same way - it means not more than 3mbit/s (around 400kbyte/s) could be achieved. I'm pretty sure you won't get anything faster out of a revision 2 modem. Too bad to hear that :/ Especially that windows does this with the same modem without a hitch. Really? In that case I take it back, the hardware can clearly do it :) Presumably you are using the firmware that came with windows? Which kernel version? Also, what synchronization speed is reported? Yes, the hardware in the modem can do it for sure. I have a laptop with a pentium4 CPU, USB2.0, windows XP installed. I attach the same modem to this laptop and I can go up to 730..740 kbyte/s (the same phone line of course). Windows XP had to be modified with a registry tweak (from thomson website) to switch to isochronous mode and it works. However my server running linux is on a ECS motherboard (P6BAP as I remember), Celeron 633 CPU, USB1.1. I have compiled quite fresh kernel 2.6.21.5 I am 100% sure that I use the same firmware for the modem, because I copied it directly from windows XP from laptop. Now since the modem itself can go as fast as 6mbit/s, I am only concerned if the _computer_ hardware on my linux server box can do it via USB ? I can see the usb reporting it to be at 12Mbit/s, which should be enough to reach 6mbit/s teoretically. CPU load is normal even during transfers. I would have to install windows xp on that machine to be 100% sure that both modem and computer hardware can go up to 6mbit/s via USB... By the way, I just tried to switch sw_buffering in the speedtch module but that did not help. I begin to think that the isochronous mode is not working. I tried the speedtch module with disabled and enabled isoc and there is no difference in transfer speeds at all. All I checked was : [EMAIL PROTECTED]:~# cat /sys/module/speedtch/parameters/enable_isoc Y which as I now believe only means what options have been specified, but does not confirm the actual mode being in use. Especially that I do not see anything like isoc support enabled in any of the logs. Are there any requirements for UHCI hardware to support isoc mode ? Mine is: USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 08) (prog-if 00 [UHCI]) Or maybe I am missing something else? I am sure the isoc mode is supported by my modem, now I only have doubts if my hardware on server box supports this ? -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hi Mikie, I begin to think that the isochronous mode is not working. I tried the speedtch module with disabled and enabled isoc and there is no difference in transfer speeds at all. All I checked was : [EMAIL PROTECTED]:~# cat /sys/module/speedtch/parameters/enable_isoc Y which as I now believe only means what options have been specified, but does not confirm the actual mode being in use. Especially that I do not see anything like isoc support enabled in any of the logs. Are there any requirements for UHCI hardware to support isoc mode ? Mine is: USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 08) (prog-if 00 [UHCI]) Or maybe I am missing something else? I am sure the isoc mode is supported by my modem, now I only have doubts if my hardware on server box supports this ? can you please send the part of /proc/bus/usb/devices concerning the modem, while the modem is plugged in and (supposedly) using isoc mode. If /proc/bus/usb isn't mounted, you can mount it like this IIRC: mount -t usbfs usbfs /proc/bus/usb/ Also, looking in the driver I see that if isoc mode is disabled you should see one of the following messages: - setting interface to ?? failed (??)! - isochronous transfer not supported - using bulk The first one may be a debug message, so you will not necessarily see it depend on which level of kernel debug messages you have turned on. (I have made some changes in my tree so that if you asked for isoc transfer but get bulk then a message is printed). Ciao, Duncan. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/11, Duncan Sands [EMAIL PROTECTED]: Hi Mikie, I begin to think that the isochronous mode is not working. I tried the speedtch module with disabled and enabled isoc and there is no difference in transfer speeds at all. All I checked was : [EMAIL PROTECTED]:~# cat /sys/module/speedtch/parameters/enable_isoc Y which as I now believe only means what options have been specified, but does not confirm the actual mode being in use. Especially that I do not see anything like isoc support enabled in any of the logs. Are there any requirements for UHCI hardware to support isoc mode ? Mine is: USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 08) (prog-if 00 [UHCI]) Or maybe I am missing something else? I am sure the isoc mode is supported by my modem, now I only have doubts if my hardware on server box supports this ? can you please send the part of /proc/bus/usb/devices concerning the modem, while the modem is plugged in and (supposedly) using isoc mode. If /proc/bus/usb isn't mounted, you can mount it like this IIRC: mount -t usbfs usbfs /proc/bus/usb/ Actually I had to mount it (I hope that not having it mounted does not change a lot in this matter). Here is the cat of devices from /proc/bus/usb T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=06b9 ProdID=4061 Rev= 2.00 S: Manufacturer=ALCATEL S: Product=Speed Touch 330 S: SerialNumber=0090D0AA28CD C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=50ms I: If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch I: If#= 1 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I: If#= 1 Alt= 2 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=87(I) Atr=01(Isoc) MxPS= 640 Ivl=1ms I:* If#= 1 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=87(I) Atr=01(Isoc) MxPS= 960 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=05(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms Also, looking in the driver I see that if isoc mode is disabled you should see one of the following messages: - setting interface to ?? failed (??)! - isochronous transfer not supported - using bulk The first one may be a debug message, so you will not necessarily see it depend on which level of kernel debug messages you have turned on. (I have made some changes in my tree so that if you asked for isoc transfer but get bulk then a message is printed). I have CONFIG_USB_DEBUG=y set in kernel. However I do not see any of the messages you are referring to. It does not say that it tried isoc and falls to bulk, nothing like that. Also nothing about setting interface to ?? failed. Which debug option should I switch to see these? -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hi, Actually I had to mount it (I hope that not having it mounted does not change a lot in this matter). probably not. Not having sysfs mounted can cause hotplug to fail, but I think not having /proc/bus/usb mounted shouldn't cause any trouble nowadays. I:* If#= 1 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=87(I) Atr=01(Isoc) MxPS= 960 Ivl=1ms The * means that this altsetting is being used - this is the altsetting when using isochronous mode. So it looks to me like isochronous mode is being used. I have CONFIG_USB_DEBUG=y set in kernel. However I do not see any of the messages you are referring to. It does not say that it tried isoc and falls to bulk, nothing like that. Also nothing about setting interface to ?? failed. Most likely it is using isochronous transfer. The question then is: why is it slow? I will look in my cupboard to see if I have the same modem, and if so see what speed I can get out of it. Which debug option should I switch to see these? Something like this IIRC: echo 7 /proc/sys/kernel/printk Then it should turn up in dmesg. Ciao, Duncan. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/11, Duncan Sands [EMAIL PROTECTED]: Hi, Actually I had to mount it (I hope that not having it mounted does not change a lot in this matter). probably not. Not having sysfs mounted can cause hotplug to fail, but I think not having /proc/bus/usb mounted shouldn't cause any trouble nowadays. I:* If#= 1 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=87(I) Atr=01(Isoc) MxPS= 960 Ivl=1ms The * means that this altsetting is being used - this is the altsetting when using isochronous mode. So it looks to me like isochronous mode is being used. I have CONFIG_USB_DEBUG=y set in kernel. However I do not see any of the messages you are referring to. It does not say that it tried isoc and falls to bulk, nothing like that. Also nothing about setting interface to ?? failed. Most likely it is using isochronous transfer. The question then is: why is it slow? I will look in my cupboard to see if I have the same modem, and if so see what speed I can get out of it. Which debug option should I switch to see these? Something like this IIRC: echo 7 /proc/sys/kernel/printk Then it should turn up in dmesg. I made a more advanced testing. I used one computer only to be absolutely sure that this is not a hardware issue. So I took a laptop (P4 1.8GHz, OHCI usb host), and booted into Knoppix LiveCD. It was running kernel 2.6.19 and the version of speedtch module was 1.10. First I did something like rmmod speedtch; rmmod ohci-hcd to be sure that I start with a fresh environment. I also did: echo 7 /proc/sys/kernel/printk which caused the usual debug messages being printed directly in the console. Then I did modprobe ohci-hcd;modprobe speedtch enable_isoc=1 Certainly I've put the same firmware in the /lib/firmware so that udev found it correctly and loaded it up to the modem. The ADSL link went up with the same values (7456 downlink). PPPd started (I use pppoatm.so, if that is important). In this setup I achieved transfer rates of around 480...500 kbyte/s. Then I did the similar thing, but speedtch without enable_isoc, and the result was exactly the same. In both cases I still could not see the messages from the speedtch driver about enabling isochronous mode, or falling back to bulk, nothing like that. Right after that, to minimize the risk of any outside network being overloaded (I doubt that anyway), I switched to Windows Xp. Transfers were up to 730 kbyte/s. So this proves definitely that it is not a hardware related issue. The transfers were so fast that the LED (marked usb led) on the modem, which usually blinks where any transfers are in process, it went completely off, and only blinked once a few seconds... So there is a small progress when compared to my server box (celeron 633 to remind you), where I can get only 400kbyte/s (on this laptop it went 100kbyte/s faster). I still cannot get the full 6mbit/s that my ADSL service runs at on the linux system. -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/10, Duncan Sands <[EMAIL PROTECTED]>: On Tuesday 10 July 2007 11:13:09 mikie wrote: > 2007/7/10, Duncan Sands <[EMAIL PROTECTED]>: > > > I also tried a couple of other firmwares available on the net, and > > > also the one from Windows XP install (which works and achieves speeds > > > of up to 720kbyte/sec downlink). Some of the firmwares did not work > > > either, and some worked the same way - it means not more than 3mbit/s > > > (around 400kbyte/s) could be achieved. > > > > I'm pretty sure you won't get anything faster out of a revision 2 modem. > > Too bad to hear that :/ > Especially that windows does this with the same modem without a hitch. Really? In that case I take it back, the hardware can clearly do it :) Presumably you are using the firmware that came with windows? Which kernel version? Also, what synchronization speed is reported? Yes, the hardware in the modem can do it for sure. I have a laptop with a pentium4 CPU, USB2.0, windows XP installed. I attach the same modem to this laptop and I can go up to 730..740 kbyte/s (the same phone line of course). Windows XP had to be modified with a registry tweak (from thomson website) to switch to isochronous mode and it works. However my server running linux is on a ECS motherboard (P6BAP as I remember), Celeron 633 CPU, USB1.1. I have compiled quite fresh kernel 2.6.21.5 I am 100% sure that I use the same firmware for the modem, because I copied it directly from windows XP from laptop. Now since the modem itself can go as fast as 6mbit/s, I am only concerned if the _computer_ hardware on my linux server box can do it via USB ? I can see the usb reporting it to be at 12Mbit/s, which should be enough to reach 6mbit/s teoretically. CPU load is normal even during transfers. I would have to install windows xp on that machine to be 100% sure that both modem and computer hardware can go up to 6mbit/s via USB... By the way, I just tried to switch sw_buffering in the speedtch module but that did not help. -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On Tuesday 10 July 2007 11:13:09 mikie wrote: > 2007/7/10, Duncan Sands <[EMAIL PROTECTED]>: > > > I also tried a couple of other firmwares available on the net, and > > > also the one from Windows XP install (which works and achieves speeds > > > of up to 720kbyte/sec downlink). Some of the firmwares did not work > > > either, and some worked the same way - it means not more than 3mbit/s > > > (around 400kbyte/s) could be achieved. > > > > I'm pretty sure you won't get anything faster out of a revision 2 modem. > > Too bad to hear that :/ > Especially that windows does this with the same modem without a hitch. Really? In that case I take it back, the hardware can clearly do it :) Presumably you are using the firmware that came with windows? Which kernel version? Also, what synchronization speed is reported? > Anyway thanks for all your help. No problem. Duncan. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/10, Duncan Sands <[EMAIL PROTECTED]>: > I also tried a couple of other firmwares available on the net, and > also the one from Windows XP install (which works and achieves speeds > of up to 720kbyte/sec downlink). Some of the firmwares did not work > either, and some worked the same way - it means not more than 3mbit/s > (around 400kbyte/s) could be achieved. I'm pretty sure you won't get anything faster out of a revision 2 modem. Too bad to hear that :/ Especially that windows does this with the same modem without a hitch. Anyway thanks for all your help. -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
> I also tried a couple of other firmwares available on the net, and > also the one from Windows XP install (which works and achieves speeds > of up to 720kbyte/sec downlink). Some of the firmwares did not work > either, and some worked the same way - it means not more than 3mbit/s > (around 400kbyte/s) could be achieved. I'm pretty sure you won't get anything faster out of a revision 2 modem. Sorry, Duncan. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/9, Duncan Sands <[EMAIL PROTECTED]>: > One more thing - when the modem finally runs in isochronous mode, yet > I cannot get high transfer rates. I can't get nothing more than > 3Mbits/s. When I used kernel 2.4 with bulk mode I had only 2.5 Mbit/s. > So there is a little progress, but still not too much. Is it possible > that weak and old hardware (Celeron 633 on a VIA chipset motherboard) > is causing this ? Is it actually running in isochronous mode? (It prints some messages about this). You may need new firmware (I've attached some recent firmware that was made available by Thomson UK without any licence conditions). Unfortunatelly this firmware does not work with my modem. I get this thing in the debug log: Jul 10 09:26:27 srv kernel: speedtch 1-2:1.0: speedtch_upload_firmware entered Jul 10 09:26:27 srv kernel: speedtch 1-2:1.0: speedtch_upload_firmware: BLOCK1 uploaded (935 bytes) Jul 10 09:26:29 srv kernel: usb 1-2: speedtch timed out on ep5in len=0/512 And it hangs at this point for a couple of minutes, so I have to manually remove the speedtch module. As far as I can see my modem is revision 2.00 (kernel searches for firmware speedtch-1.bin.2.00). I also tried a couple of other firmwares available on the net, and also the one from Windows XP install (which works and achieves speeds of up to 720kbyte/sec downlink). Some of the firmwares did not work either, and some worked the same way - it means not more than 3mbit/s (around 400kbyte/s) could be achieved. -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/9, Duncan Sands [EMAIL PROTECTED]: One more thing - when the modem finally runs in isochronous mode, yet I cannot get high transfer rates. I can't get nothing more than 3Mbits/s. When I used kernel 2.4 with bulk mode I had only 2.5 Mbit/s. So there is a little progress, but still not too much. Is it possible that weak and old hardware (Celeron 633 on a VIA chipset motherboard) is causing this ? Is it actually running in isochronous mode? (It prints some messages about this). You may need new firmware (I've attached some recent firmware that was made available by Thomson UK without any licence conditions). Unfortunatelly this firmware does not work with my modem. I get this thing in the debug log: Jul 10 09:26:27 srv kernel: speedtch 1-2:1.0: speedtch_upload_firmware entered Jul 10 09:26:27 srv kernel: speedtch 1-2:1.0: speedtch_upload_firmware: BLOCK1 uploaded (935 bytes) Jul 10 09:26:29 srv kernel: usb 1-2: speedtch timed out on ep5in len=0/512 And it hangs at this point for a couple of minutes, so I have to manually remove the speedtch module. As far as I can see my modem is revision 2.00 (kernel searches for firmware speedtch-1.bin.2.00). I also tried a couple of other firmwares available on the net, and also the one from Windows XP install (which works and achieves speeds of up to 720kbyte/sec downlink). Some of the firmwares did not work either, and some worked the same way - it means not more than 3mbit/s (around 400kbyte/s) could be achieved. -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
I also tried a couple of other firmwares available on the net, and also the one from Windows XP install (which works and achieves speeds of up to 720kbyte/sec downlink). Some of the firmwares did not work either, and some worked the same way - it means not more than 3mbit/s (around 400kbyte/s) could be achieved. I'm pretty sure you won't get anything faster out of a revision 2 modem. Sorry, Duncan. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/10, Duncan Sands [EMAIL PROTECTED]: I also tried a couple of other firmwares available on the net, and also the one from Windows XP install (which works and achieves speeds of up to 720kbyte/sec downlink). Some of the firmwares did not work either, and some worked the same way - it means not more than 3mbit/s (around 400kbyte/s) could be achieved. I'm pretty sure you won't get anything faster out of a revision 2 modem. Too bad to hear that :/ Especially that windows does this with the same modem without a hitch. Anyway thanks for all your help. -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On Tuesday 10 July 2007 11:13:09 mikie wrote: 2007/7/10, Duncan Sands [EMAIL PROTECTED]: I also tried a couple of other firmwares available on the net, and also the one from Windows XP install (which works and achieves speeds of up to 720kbyte/sec downlink). Some of the firmwares did not work either, and some worked the same way - it means not more than 3mbit/s (around 400kbyte/s) could be achieved. I'm pretty sure you won't get anything faster out of a revision 2 modem. Too bad to hear that :/ Especially that windows does this with the same modem without a hitch. Really? In that case I take it back, the hardware can clearly do it :) Presumably you are using the firmware that came with windows? Which kernel version? Also, what synchronization speed is reported? Anyway thanks for all your help. No problem. Duncan. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/10, Duncan Sands [EMAIL PROTECTED]: On Tuesday 10 July 2007 11:13:09 mikie wrote: 2007/7/10, Duncan Sands [EMAIL PROTECTED]: I also tried a couple of other firmwares available on the net, and also the one from Windows XP install (which works and achieves speeds of up to 720kbyte/sec downlink). Some of the firmwares did not work either, and some worked the same way - it means not more than 3mbit/s (around 400kbyte/s) could be achieved. I'm pretty sure you won't get anything faster out of a revision 2 modem. Too bad to hear that :/ Especially that windows does this with the same modem without a hitch. Really? In that case I take it back, the hardware can clearly do it :) Presumably you are using the firmware that came with windows? Which kernel version? Also, what synchronization speed is reported? Yes, the hardware in the modem can do it for sure. I have a laptop with a pentium4 CPU, USB2.0, windows XP installed. I attach the same modem to this laptop and I can go up to 730..740 kbyte/s (the same phone line of course). Windows XP had to be modified with a registry tweak (from thomson website) to switch to isochronous mode and it works. However my server running linux is on a ECS motherboard (P6BAP as I remember), Celeron 633 CPU, USB1.1. I have compiled quite fresh kernel 2.6.21.5 I am 100% sure that I use the same firmware for the modem, because I copied it directly from windows XP from laptop. Now since the modem itself can go as fast as 6mbit/s, I am only concerned if the _computer_ hardware on my linux server box can do it via USB ? I can see the usb reporting it to be at 12Mbit/s, which should be enough to reach 6mbit/s teoretically. CPU load is normal even during transfers. I would have to install windows xp on that machine to be 100% sure that both modem and computer hardware can go up to 6mbit/s via USB... By the way, I just tried to switch sw_buffering in the speedtch module but that did not help. -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hi, > > Is it actually running in isochronous mode? (It prints some messages > > about this). > > This is what I get: > [EMAIL PROTECTED]:/# cat /sys/module/speedtch/parameters/enable_isoc > Y > > I think it means it confirms the isochronous mode is working. > Especially that I modified the source of the speedtch.c so that the > enable_isoc is on by default. if you turn on isochronous mode, but there is some reason it can't be used you get the message: "isochronous transfer not supported - using bulk". Ciao, Duncan. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/9, Duncan Sands <[EMAIL PROTECTED]>: > One more thing - when the modem finally runs in isochronous mode, yet > I cannot get high transfer rates. I can't get nothing more than > 3Mbits/s. When I used kernel 2.4 with bulk mode I had only 2.5 Mbit/s. > So there is a little progress, but still not too much. Is it possible > that weak and old hardware (Celeron 633 on a VIA chipset motherboard) > is causing this ? Is it actually running in isochronous mode? (It prints some messages about this). This is what I get: [EMAIL PROTECTED]:/# cat /sys/module/speedtch/parameters/enable_isoc Y I think it means it confirms the isochronous mode is working. Especially that I modified the source of the speedtch.c so that the enable_isoc is on by default. You may need new firmware (I've attached some recent firmware that was made available by Thomson UK without any licence conditions). Many thanks for your great support. I will try the new firmware tomorrow, as this is a remote machine and I would now risk loosing it for an entire evening and night in case something goes wrong (usually it just does go wrong :) -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/9, Indan Zupancic <[EMAIL PROTECTED]>: On Mon, July 9, 2007 16:40, mikie wrote: > 2007/7/9, Kay Sievers <[EMAIL PROTECTED]>: >> On 7/9/07, mikie <[EMAIL PROTECTED]> wrote: >> > 2007/7/9, Indan Zupancic <[EMAIL PROTECTED]>: >> > > On Mon, July 9, 2007 10:49, mikie wrote: >> > > > 2007/7/6, Indan Zupancic <[EMAIL PROTECTED]>: >> > > >> On Fri, July 6, 2007 16:20, Duncan Sands wrote: >> > > >> > On Friday 6 July 2007 14:54:18 mikie wrote: >> > > >> >> Hi, >> > > >> >> >> > > >> >> I experience some problems with the speedtch.c module, especially in >> > > >> >> regards to its firmware loader. >> > > >> >> I am not quite sure if this module is going to load the firmware >> > > >> >> itself or does it use some external software to do that ? >> > > >> > >> > > >> > It loads it itself, using some external software! >> > > >> >> > > >> For information, it generates a hotplug event and the kernel calls the >> > > >> program written at /proc/sys/kernel/hotplug with certain information. >> > > >> That used to be /sbin/hotplug, became later udev, but today in general >> > > >> udev reads the uevents generated by the kernel. >> > > > >> > > > On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. >> > > > I copied your script to /sbin/hotplug and also added simple logging, >> > > > so I can see whenever the script is being started. It turns out that >> > > > the script is not started at all by the kernel... >> > > > >> > > > I am afraid that the kernel generates uevents only, could this be true? >> > > >> > > Not really, it would break backward compatibility, and if it were true, >> > > they're remove the /proc/sys/kernel/hotplug setting too. As far as I know, >> > > if it's set, that program will be executed, and if zero is written to it, only >> > > uevents are generated. >> > > >> > > Make sure that the script is executable (chmod +x) >> > >> > Yes I have set it to be executable: >> > [EMAIL PROTECTED]:/sbin# ls -lah hotplug >> > -rwxr-xr-x1 root root 934 Jul 9 09:13 hotplug >> > >> > > and has "#!/bin/sh" >> > > at the top, or else it won't work. If that's already the case, I've no idea. >> > >> > [EMAIL PROTECTED]:/sbin# head hotplug >> > #!/bin/sh >> > set -e >> > >> > >> > Everything looks OK, but still it does not fire up the script... >> >> It should run, if the kernel creates events. Can you run "udevmonitor >> --env" while loading the driver? That way we can see if events are >> generated by the kernel (if you don't have it, no need to install >> udev, just download the udev tarball, type "make" and run >> "./udevmonitor --env"). > > It seems that uevents are generated: What if you run a very simple script like #!/bin/sh echo "test" >> /tmp/test is it called at all? I tried that. I modified the script so it writes to /tmp/bla a simple line that the script was started. Now, when I start it manually by simply typing /sbin/hotplug in the bash, then the log shows that the script got started (as expected). However, when I do modprobe speedtch the kernel never runs this script... Certainly, I removed the speedtch module earlier (rmmod speedtch) and checked that it was removed with lsmod. What I tried to do is manually find the firmware directory in /sys/ after inserting the speedtch. Then I manually did the echo 1>loading, cat speedtch-1.bin > data, echo 0>loading. And it worked. Everything after that went fine. So all I am missing is the hotplug script not being started by kernel at all. If it is then it's probably something with the other script. Try removing the set -e and/or run it manually with the right parameters set and see if anything goes wrong. Or use a minimal udev and let it do the hotplugging, having only rules for speedtouch and firmware loading (attached, but make sure the paths and pppd call is correct for your system). /dev can stay static, just change udev.conf to handle /udev or something. Thanks for your support and the attached rules. If I can't find other solution I will have to use the minimal udev environment that you provided. One more thing - when the modem finally runs in isochronous mode, yet I cannot get high transfer rates. I can't get nothing more than 3Mbits/s. When I used kernel 2.4 with bulk mode I had only 2.5 Mbit/s. So there is a little progress, but still not too much. Is it possible that weak and old hardware (Celeron 633 on a VIA chipset motherboard) is causing this ? -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On Mon, 2007-07-09 at 16:40 +0200, mikie wrote: > 2007/7/9, Kay Sievers <[EMAIL PROTECTED]>: > > On 7/9/07, mikie <[EMAIL PROTECTED]> wrote: > > > 2007/7/9, Indan Zupancic <[EMAIL PROTECTED]>: > > > > On Mon, July 9, 2007 10:49, mikie wrote: > > > > > 2007/7/6, Indan Zupancic <[EMAIL PROTECTED]>: > > > > >> On Fri, July 6, 2007 16:20, Duncan Sands wrote: > > > > >> > On Friday 6 July 2007 14:54:18 mikie wrote: > > > > >> >> Hi, > > > > >> >> > > > > >> >> I experience some problems with the speedtch.c module, especially > > > > >> >> in > > > > >> >> regards to its firmware loader. > > > > >> >> I am not quite sure if this module is going to load the firmware > > > > >> >> itself or does it use some external software to do that ? > > > > >> > > > > > >> > It loads it itself, using some external software! > > > > >> > > > > >> For information, it generates a hotplug event and the kernel calls > > > > >> the > > > > >> program written at /proc/sys/kernel/hotplug with certain information. > > > > >> That used to be /sbin/hotplug, became later udev, but today in > > > > >> general > > > > >> udev reads the uevents generated by the kernel. > > > > > > > > > > On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. > > > > > I copied your script to /sbin/hotplug and also added simple logging, > > > > > so I can see whenever the script is being started. It turns out that > > > > > the script is not started at all by the kernel... > > > > > > > > > > I am afraid that the kernel generates uevents only, could this be > > > > > true? > > > > > > > > Not really, it would break backward compatibility, and if it were true, > > > > they're remove the /proc/sys/kernel/hotplug setting too. As far as I > > > > know, > > > > if it's set, that program will be executed, and if zero is written to > > > > it, only > > > > uevents are generated. > > > > > > > > Make sure that the script is executable (chmod +x) > > > > > > Yes I have set it to be executable: > > > [EMAIL PROTECTED]:/sbin# ls -lah hotplug > > > -rwxr-xr-x1 root root 934 Jul 9 09:13 hotplug > > > > > > > and has "#!/bin/sh" > > > > at the top, or else it won't work. If that's already the case, I've no > > > > idea. > > > > > > [EMAIL PROTECTED]:/sbin# head hotplug > > > #!/bin/sh > > > set -e > > > > > > > > > Everything looks OK, but still it does not fire up the script... > > > > It should run, if the kernel creates events. Can you run "udevmonitor > > --env" while loading the driver? That way we can see if events are > > generated by the kernel (if you don't have it, no need to install > > udev, just download the udev tarball, type "make" and run > > "./udevmonitor --env"). > > It seems that uevents are generated: > > UEVENT[1183991915.577581] add /class/firmware/1-2:1.0 (firmware) > ACTION=add Using /sbin/hotplug works without any problems here: $ uname -a Linux lov 2.6.22-dirty #68 SMP Mon Jul 9 03:43:51 CEST 2007 x86_64 x86_64 x86_64 GNU/Linux $ cat /proc/sys/kernel/hotplug /sbin/hotplug $ ls -l /sbin/hotplug -rwxr-xr-x 1 root root 39 2007-07-09 17:02 /sbin/hotplug $ cat /sbin/hotplug #!/bin/sh set | logger -t "hotplug $$" $ tail -50 /var/log/messages ... Jul 9 17:04:33 lov hotplug 15589: ACTION=add Jul 9 17:04:33 lov hotplug 15589: BASH=/bin/sh Jul 9 17:04:33 lov hotplug 15589: BASH_ARGC=([0]="1") Jul 9 17:04:33 lov hotplug 15589: BASH_ARGV=([0]="usb_endpoint") Jul 9 17:04:33 lov hotplug 15589: BASH_LINENO=([0]="0") Jul 9 17:04:33 lov hotplug 15589: BASH_SOURCE=([0]="/sbin/hotplug") Jul 9 17:04:33 lov hotplug 15589: MAJOR=254 Jul 9 17:04:33 lov hotplug 15589: MINOR=11 Jul 9 17:04:33 lov hotplug 15589: SUBSYSTEM=usb_endpoint ... Kay - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On Mon, July 9, 2007 16:40, mikie wrote: > 2007/7/9, Kay Sievers <[EMAIL PROTECTED]>: >> On 7/9/07, mikie <[EMAIL PROTECTED]> wrote: >> > 2007/7/9, Indan Zupancic <[EMAIL PROTECTED]>: >> > > On Mon, July 9, 2007 10:49, mikie wrote: >> > > > 2007/7/6, Indan Zupancic <[EMAIL PROTECTED]>: >> > > >> On Fri, July 6, 2007 16:20, Duncan Sands wrote: >> > > >> > On Friday 6 July 2007 14:54:18 mikie wrote: >> > > >> >> Hi, >> > > >> >> >> > > >> >> I experience some problems with the speedtch.c module, especially >> > > >> >> in >> > > >> >> regards to its firmware loader. >> > > >> >> I am not quite sure if this module is going to load the firmware >> > > >> >> itself or does it use some external software to do that ? >> > > >> > >> > > >> > It loads it itself, using some external software! >> > > >> >> > > >> For information, it generates a hotplug event and the kernel calls the >> > > >> program written at /proc/sys/kernel/hotplug with certain information. >> > > >> That used to be /sbin/hotplug, became later udev, but today in general >> > > >> udev reads the uevents generated by the kernel. >> > > > >> > > > On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. >> > > > I copied your script to /sbin/hotplug and also added simple logging, >> > > > so I can see whenever the script is being started. It turns out that >> > > > the script is not started at all by the kernel... >> > > > >> > > > I am afraid that the kernel generates uevents only, could this be true? >> > > >> > > Not really, it would break backward compatibility, and if it were true, >> > > they're remove the /proc/sys/kernel/hotplug setting too. As far as I >> > > know, >> > > if it's set, that program will be executed, and if zero is written to >> > > it, only >> > > uevents are generated. >> > > >> > > Make sure that the script is executable (chmod +x) >> > >> > Yes I have set it to be executable: >> > [EMAIL PROTECTED]:/sbin# ls -lah hotplug >> > -rwxr-xr-x1 root root 934 Jul 9 09:13 hotplug >> > >> > > and has "#!/bin/sh" >> > > at the top, or else it won't work. If that's already the case, I've no >> > > idea. >> > >> > [EMAIL PROTECTED]:/sbin# head hotplug >> > #!/bin/sh >> > set -e >> > >> > >> > Everything looks OK, but still it does not fire up the script... >> >> It should run, if the kernel creates events. Can you run "udevmonitor >> --env" while loading the driver? That way we can see if events are >> generated by the kernel (if you don't have it, no need to install >> udev, just download the udev tarball, type "make" and run >> "./udevmonitor --env"). > > It seems that uevents are generated: What if you run a very simple script like #!/bin/sh echo "test" >> /tmp/test is it called at all? If it is then it's probably something with the other script. Try removing the set -e and/or run it manually with the right parameters set and see if anything goes wrong. Or use a minimal udev and let it do the hotplugging, having only rules for speedtouch and firmware loading (attached, but make sure the paths and pppd call is correct for your system). /dev can stay static, just change udev.conf to handle /udev or something. Regards, Indan speedtch.rules Description: Binary data
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/9, Kay Sievers <[EMAIL PROTECTED]>: On 7/9/07, mikie <[EMAIL PROTECTED]> wrote: > 2007/7/9, Indan Zupancic <[EMAIL PROTECTED]>: > > On Mon, July 9, 2007 10:49, mikie wrote: > > > 2007/7/6, Indan Zupancic <[EMAIL PROTECTED]>: > > >> On Fri, July 6, 2007 16:20, Duncan Sands wrote: > > >> > On Friday 6 July 2007 14:54:18 mikie wrote: > > >> >> Hi, > > >> >> > > >> >> I experience some problems with the speedtch.c module, especially in > > >> >> regards to its firmware loader. > > >> >> I am not quite sure if this module is going to load the firmware > > >> >> itself or does it use some external software to do that ? > > >> > > > >> > It loads it itself, using some external software! > > >> > > >> For information, it generates a hotplug event and the kernel calls the > > >> program written at /proc/sys/kernel/hotplug with certain information. > > >> That used to be /sbin/hotplug, became later udev, but today in general > > >> udev reads the uevents generated by the kernel. > > > > > > On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. > > > I copied your script to /sbin/hotplug and also added simple logging, > > > so I can see whenever the script is being started. It turns out that > > > the script is not started at all by the kernel... > > > > > > I am afraid that the kernel generates uevents only, could this be true? > > > > Not really, it would break backward compatibility, and if it were true, > > they're remove the /proc/sys/kernel/hotplug setting too. As far as I know, > > if it's set, that program will be executed, and if zero is written to it, only > > uevents are generated. > > > > Make sure that the script is executable (chmod +x) > > Yes I have set it to be executable: > [EMAIL PROTECTED]:/sbin# ls -lah hotplug > -rwxr-xr-x1 root root 934 Jul 9 09:13 hotplug > > > and has "#!/bin/sh" > > at the top, or else it won't work. If that's already the case, I've no idea. > > [EMAIL PROTECTED]:/sbin# head hotplug > #!/bin/sh > set -e > > > Everything looks OK, but still it does not fire up the script... It should run, if the kernel creates events. Can you run "udevmonitor --env" while loading the driver? That way we can see if events are generated by the kernel (if you don't have it, no need to install udev, just download the udev tarball, type "make" and run "./udevmonitor --env"). It seems that uevents are generated: UEVENT[1183991915.577581] add /class/firmware/1-2:1.0 (firmware) ACTION=add DEVPATH=/class/firmware/1-2:1.0 SUBSYSTEM=firmware SEQNUM=949 PHYSDEVPATH=/devices/pci:00/:00:07.2/usb1/1-2/1-2:1.0 PHYSDEVBUS=usb PHYSDEVDRIVER=speedtch FIRMWARE=speedtch-1.bin.2.00 TIMEOUT=60 UEVENT[1183991975.599358] add /class/firmware/1-2:1.0 (firmware) ACTION=add DEVPATH=/class/firmware/1-2:1.0 SUBSYSTEM=firmware SEQNUM=951 PHYSDEVPATH=/devices/pci:00/:00:07.2/usb1/1-2/1-2:1.0 PHYSDEVBUS=usb PHYSDEVDRIVER=speedtch FIRMWARE=speedtch-1.bin.2 TIMEOUT=60 -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On 7/9/07, mikie <[EMAIL PROTECTED]> wrote: 2007/7/9, Indan Zupancic <[EMAIL PROTECTED]>: > On Mon, July 9, 2007 10:49, mikie wrote: > > 2007/7/6, Indan Zupancic <[EMAIL PROTECTED]>: > >> On Fri, July 6, 2007 16:20, Duncan Sands wrote: > >> > On Friday 6 July 2007 14:54:18 mikie wrote: > >> >> Hi, > >> >> > >> >> I experience some problems with the speedtch.c module, especially in > >> >> regards to its firmware loader. > >> >> I am not quite sure if this module is going to load the firmware > >> >> itself or does it use some external software to do that ? > >> > > >> > It loads it itself, using some external software! > >> > >> For information, it generates a hotplug event and the kernel calls the > >> program written at /proc/sys/kernel/hotplug with certain information. > >> That used to be /sbin/hotplug, became later udev, but today in general > >> udev reads the uevents generated by the kernel. > > > > On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. > > I copied your script to /sbin/hotplug and also added simple logging, > > so I can see whenever the script is being started. It turns out that > > the script is not started at all by the kernel... > > > > I am afraid that the kernel generates uevents only, could this be true? > > Not really, it would break backward compatibility, and if it were true, > they're remove the /proc/sys/kernel/hotplug setting too. As far as I know, > if it's set, that program will be executed, and if zero is written to it, only > uevents are generated. > > Make sure that the script is executable (chmod +x) Yes I have set it to be executable: [EMAIL PROTECTED]:/sbin# ls -lah hotplug -rwxr-xr-x1 root root 934 Jul 9 09:13 hotplug > and has "#!/bin/sh" > at the top, or else it won't work. If that's already the case, I've no idea. [EMAIL PROTECTED]:/sbin# head hotplug #!/bin/sh set -e Everything looks OK, but still it does not fire up the script... It should run, if the kernel creates events. Can you run "udevmonitor --env" while loading the driver? That way we can see if events are generated by the kernel (if you don't have it, no need to install udev, just download the udev tarball, type "make" and run "./udevmonitor --env"). Kay - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/9, Indan Zupancic <[EMAIL PROTECTED]>: On Mon, July 9, 2007 10:49, mikie wrote: > 2007/7/6, Indan Zupancic <[EMAIL PROTECTED]>: >> On Fri, July 6, 2007 16:20, Duncan Sands wrote: >> > On Friday 6 July 2007 14:54:18 mikie wrote: >> >> Hi, >> >> >> >> I experience some problems with the speedtch.c module, especially in >> >> regards to its firmware loader. >> >> I am not quite sure if this module is going to load the firmware >> >> itself or does it use some external software to do that ? >> > >> > It loads it itself, using some external software! >> >> For information, it generates a hotplug event and the kernel calls the >> program written at /proc/sys/kernel/hotplug with certain information. >> That used to be /sbin/hotplug, became later udev, but today in general >> udev reads the uevents generated by the kernel. > > On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. > I copied your script to /sbin/hotplug and also added simple logging, > so I can see whenever the script is being started. It turns out that > the script is not started at all by the kernel... > > I am afraid that the kernel generates uevents only, could this be true? Not really, it would break backward compatibility, and if it were true, they're remove the /proc/sys/kernel/hotplug setting too. As far as I know, if it's set, that program will be executed, and if zero is written to it, only uevents are generated. Make sure that the script is executable (chmod +x) Yes I have set it to be executable: [EMAIL PROTECTED]:/sbin# ls -lah hotplug -rwxr-xr-x1 root root 934 Jul 9 09:13 hotplug and has "#!/bin/sh" at the top, or else it won't work. If that's already the case, I've no idea. [EMAIL PROTECTED]:/sbin# head hotplug #!/bin/sh set -e Everything looks OK, but still it does not fire up the script... Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/9, Duncan Sands <[EMAIL PROTECTED]>: Hi, > On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. > I copied your script to /sbin/hotplug and also added simple logging, > so I can see whenever the script is being started. It turns out that > the script is not started at all by the kernel... did you turn hotplug on in your kernel's .config? Yes: cat /usr/src/linux/.config |grep HOTPLUG CONFIG_HOTPLUG=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # CONFIG_HOTPLUG_PCI is not set Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hi, > On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. > I copied your script to /sbin/hotplug and also added simple logging, > so I can see whenever the script is being started. It turns out that > the script is not started at all by the kernel... did you turn hotplug on in your kernel's .config? Ciao, D. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On Mon, July 9, 2007 10:49, mikie wrote: > 2007/7/6, Indan Zupancic <[EMAIL PROTECTED]>: >> On Fri, July 6, 2007 16:20, Duncan Sands wrote: >> > On Friday 6 July 2007 14:54:18 mikie wrote: >> >> Hi, >> >> >> >> I experience some problems with the speedtch.c module, especially in >> >> regards to its firmware loader. >> >> I am not quite sure if this module is going to load the firmware >> >> itself or does it use some external software to do that ? >> > >> > It loads it itself, using some external software! >> >> For information, it generates a hotplug event and the kernel calls the >> program written at /proc/sys/kernel/hotplug with certain information. >> That used to be /sbin/hotplug, became later udev, but today in general >> udev reads the uevents generated by the kernel. > > On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. > I copied your script to /sbin/hotplug and also added simple logging, > so I can see whenever the script is being started. It turns out that > the script is not started at all by the kernel... > > I am afraid that the kernel generates uevents only, could this be true? Not really, it would break backward compatibility, and if it were true, they're remove the /proc/sys/kernel/hotplug setting too. As far as I know, if it's set, that program will be executed, and if zero is written to it, only uevents are generated. Make sure that the script is executable (chmod +x) and has "#!/bin/sh" at the top, or else it won't work. If that's already the case, I've no idea. Good luck, Indan - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/6, Indan Zupancic <[EMAIL PROTECTED]>: On Fri, July 6, 2007 16:20, Duncan Sands wrote: > On Friday 6 July 2007 14:54:18 mikie wrote: >> Hi, >> >> I experience some problems with the speedtch.c module, especially in >> regards to its firmware loader. >> I am not quite sure if this module is going to load the firmware >> itself or does it use some external software to do that ? > > It loads it itself, using some external software! For information, it generates a hotplug event and the kernel calls the program written at /proc/sys/kernel/hotplug with certain information. That used to be /sbin/hotplug, became later udev, but today in general udev reads the uevents generated by the kernel. On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. I copied your script to /sbin/hotplug and also added simple logging, so I can see whenever the script is being started. It turns out that the script is not started at all by the kernel... I am afraid that the kernel generates uevents only, could this be true? The timeout value in /sys/class/firmware/timeout is 60 and it seems to be working correctly (see logs with exactly 1 minute delay before next find_firmware event) As I check the debug log I can see some uevents : Jul 9 09:03:19 srv kernel: speedtch 1-2:1.0: usbatm_usb_probe: using 3392 byte buffer for rx channel 0xc5577ca0 Jul 9 09:03:19 srv kernel: speedtch 1-2:1.0: usbatm_usb_probe: using 3392 byte buffer for tx channel 0xc5577ce8 Jul 9 09:03:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin.2.00 Jul 9 09:03:19 srv kernel: DEV: registering device: ID = '1-2:1.0' Jul 9 09:03:19 srv kernel: PM: Adding info for No Bus:1-2:1.0 Jul 9 09:03:19 srv kernel: dev_uevent: class uevent() returned -19 Jul 9 09:03:19 srv kernel: bound device '1-2:1.0' to driver 'speedtch' Jul 9 09:03:19 srv kernel: usb: Bound Device 1-2:1.0 to Driver speedtch Jul 9 09:04:07 srv kernel: drivers/usb/atm/speedtch.c: speedtch_usb_cleanup Jul 9 09:04:07 srv kernel: bus usb: remove driver speedtch Jul 9 09:04:07 srv kernel: speedtch 1-2:1.0: usbatm_usb_disconnect entered Jul 9 09:04:19 srv kernel: DEV: Unregistering device. ID = '1-2:1.0' Jul 9 09:04:19 srv kernel: PM: Removing info for No Bus:1-2:1.0 Jul 9 09:04:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin.2 Jul 9 09:04:19 srv kernel: DEV: registering device: ID = '1-2:1.0' Jul 9 09:04:19 srv kernel: PM: Adding info for No Bus:1-2:1.0 Jul 9 09:04:19 srv kernel: dev_uevent: class uevent() returned -19 Jul 9 09:05:19 srv kernel: DEV: Unregistering device. ID = '1-2:1.0' Jul 9 09:05:19 srv kernel: PM: Removing info for No Bus:1-2:1.0 Jul 9 09:05:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin Jul 9 09:05:19 srv kernel: DEV: registering device: ID = '1-2:1.0' Jul 9 09:05:19 srv kernel: PM: Adding info for No Bus:1-2:1.0 Jul 9 09:05:19 srv kernel: dev_uevent: class uevent() returned -19 Jul 9 09:06:19 srv kernel: DEV: Unregistering device. ID = '1-2:1.0' Jul 9 09:06:19 srv kernel: PM: Removing info for No Bus:1-2:1.0 Jul 9 09:06:19 srv kernel: speedtch 1-2:1.0: speedtch_unbind entered Jul 9 09:06:19 srv kernel: speedtch 1-2:1.1: usbatm_usb_disconnect entered Jul 9 09:06:19 srv kernel: speedtch 1-2:1.1: usbatm_usb_disconnect: NULL instance! Mostly I think I should be worried about "dev_uevent: class uevent() returned -19". It sounds like the uevent failed? I do not have udevd, but still I thought that in such case the kernel will use the script from /proc/sys/kernel/hotplug but apparently it does not. Is there any config option to choose between udev or hotplug in the kernel source ? Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/6, Indan Zupancic [EMAIL PROTECTED]: On Fri, July 6, 2007 16:20, Duncan Sands wrote: On Friday 6 July 2007 14:54:18 mikie wrote: Hi, I experience some problems with the speedtch.c module, especially in regards to its firmware loader. I am not quite sure if this module is going to load the firmware itself or does it use some external software to do that ? It loads it itself, using some external software! For information, it generates a hotplug event and the kernel calls the program written at /proc/sys/kernel/hotplug with certain information. That used to be /sbin/hotplug, became later udev, but today in general udev reads the uevents generated by the kernel. On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. I copied your script to /sbin/hotplug and also added simple logging, so I can see whenever the script is being started. It turns out that the script is not started at all by the kernel... I am afraid that the kernel generates uevents only, could this be true? The timeout value in /sys/class/firmware/timeout is 60 and it seems to be working correctly (see logs with exactly 1 minute delay before next find_firmware event) As I check the debug log I can see some uevents : Jul 9 09:03:19 srv kernel: speedtch 1-2:1.0: usbatm_usb_probe: using 3392 byte buffer for rx channel 0xc5577ca0 Jul 9 09:03:19 srv kernel: speedtch 1-2:1.0: usbatm_usb_probe: using 3392 byte buffer for tx channel 0xc5577ce8 Jul 9 09:03:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin.2.00 Jul 9 09:03:19 srv kernel: DEV: registering device: ID = '1-2:1.0' Jul 9 09:03:19 srv kernel: PM: Adding info for No Bus:1-2:1.0 Jul 9 09:03:19 srv kernel: dev_uevent: class uevent() returned -19 Jul 9 09:03:19 srv kernel: bound device '1-2:1.0' to driver 'speedtch' Jul 9 09:03:19 srv kernel: usb: Bound Device 1-2:1.0 to Driver speedtch Jul 9 09:04:07 srv kernel: drivers/usb/atm/speedtch.c: speedtch_usb_cleanup Jul 9 09:04:07 srv kernel: bus usb: remove driver speedtch Jul 9 09:04:07 srv kernel: speedtch 1-2:1.0: usbatm_usb_disconnect entered Jul 9 09:04:19 srv kernel: DEV: Unregistering device. ID = '1-2:1.0' Jul 9 09:04:19 srv kernel: PM: Removing info for No Bus:1-2:1.0 Jul 9 09:04:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin.2 Jul 9 09:04:19 srv kernel: DEV: registering device: ID = '1-2:1.0' Jul 9 09:04:19 srv kernel: PM: Adding info for No Bus:1-2:1.0 Jul 9 09:04:19 srv kernel: dev_uevent: class uevent() returned -19 Jul 9 09:05:19 srv kernel: DEV: Unregistering device. ID = '1-2:1.0' Jul 9 09:05:19 srv kernel: PM: Removing info for No Bus:1-2:1.0 Jul 9 09:05:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin Jul 9 09:05:19 srv kernel: DEV: registering device: ID = '1-2:1.0' Jul 9 09:05:19 srv kernel: PM: Adding info for No Bus:1-2:1.0 Jul 9 09:05:19 srv kernel: dev_uevent: class uevent() returned -19 Jul 9 09:06:19 srv kernel: DEV: Unregistering device. ID = '1-2:1.0' Jul 9 09:06:19 srv kernel: PM: Removing info for No Bus:1-2:1.0 Jul 9 09:06:19 srv kernel: speedtch 1-2:1.0: speedtch_unbind entered Jul 9 09:06:19 srv kernel: speedtch 1-2:1.1: usbatm_usb_disconnect entered Jul 9 09:06:19 srv kernel: speedtch 1-2:1.1: usbatm_usb_disconnect: NULL instance! Mostly I think I should be worried about dev_uevent: class uevent() returned -19. It sounds like the uevent failed? I do not have udevd, but still I thought that in such case the kernel will use the script from /proc/sys/kernel/hotplug but apparently it does not. Is there any config option to choose between udev or hotplug in the kernel source ? Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On Mon, July 9, 2007 10:49, mikie wrote: 2007/7/6, Indan Zupancic [EMAIL PROTECTED]: On Fri, July 6, 2007 16:20, Duncan Sands wrote: On Friday 6 July 2007 14:54:18 mikie wrote: Hi, I experience some problems with the speedtch.c module, especially in regards to its firmware loader. I am not quite sure if this module is going to load the firmware itself or does it use some external software to do that ? It loads it itself, using some external software! For information, it generates a hotplug event and the kernel calls the program written at /proc/sys/kernel/hotplug with certain information. That used to be /sbin/hotplug, became later udev, but today in general udev reads the uevents generated by the kernel. On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. I copied your script to /sbin/hotplug and also added simple logging, so I can see whenever the script is being started. It turns out that the script is not started at all by the kernel... I am afraid that the kernel generates uevents only, could this be true? Not really, it would break backward compatibility, and if it were true, they're remove the /proc/sys/kernel/hotplug setting too. As far as I know, if it's set, that program will be executed, and if zero is written to it, only uevents are generated. Make sure that the script is executable (chmod +x) and has #!/bin/sh at the top, or else it won't work. If that's already the case, I've no idea. Good luck, Indan - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hi, On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. I copied your script to /sbin/hotplug and also added simple logging, so I can see whenever the script is being started. It turns out that the script is not started at all by the kernel... did you turn hotplug on in your kernel's .config? Ciao, D. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/9, Duncan Sands [EMAIL PROTECTED]: Hi, On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. I copied your script to /sbin/hotplug and also added simple logging, so I can see whenever the script is being started. It turns out that the script is not started at all by the kernel... did you turn hotplug on in your kernel's .config? Yes: cat /usr/src/linux/.config |grep HOTPLUG CONFIG_HOTPLUG=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # CONFIG_HOTPLUG_PCI is not set Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/9, Indan Zupancic [EMAIL PROTECTED]: On Mon, July 9, 2007 10:49, mikie wrote: 2007/7/6, Indan Zupancic [EMAIL PROTECTED]: On Fri, July 6, 2007 16:20, Duncan Sands wrote: On Friday 6 July 2007 14:54:18 mikie wrote: Hi, I experience some problems with the speedtch.c module, especially in regards to its firmware loader. I am not quite sure if this module is going to load the firmware itself or does it use some external software to do that ? It loads it itself, using some external software! For information, it generates a hotplug event and the kernel calls the program written at /proc/sys/kernel/hotplug with certain information. That used to be /sbin/hotplug, became later udev, but today in general udev reads the uevents generated by the kernel. On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. I copied your script to /sbin/hotplug and also added simple logging, so I can see whenever the script is being started. It turns out that the script is not started at all by the kernel... I am afraid that the kernel generates uevents only, could this be true? Not really, it would break backward compatibility, and if it were true, they're remove the /proc/sys/kernel/hotplug setting too. As far as I know, if it's set, that program will be executed, and if zero is written to it, only uevents are generated. Make sure that the script is executable (chmod +x) Yes I have set it to be executable: [EMAIL PROTECTED]:/sbin# ls -lah hotplug -rwxr-xr-x1 root root 934 Jul 9 09:13 hotplug and has #!/bin/sh at the top, or else it won't work. If that's already the case, I've no idea. [EMAIL PROTECTED]:/sbin# head hotplug #!/bin/sh set -e Everything looks OK, but still it does not fire up the script... Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On 7/9/07, mikie [EMAIL PROTECTED] wrote: 2007/7/9, Indan Zupancic [EMAIL PROTECTED]: On Mon, July 9, 2007 10:49, mikie wrote: 2007/7/6, Indan Zupancic [EMAIL PROTECTED]: On Fri, July 6, 2007 16:20, Duncan Sands wrote: On Friday 6 July 2007 14:54:18 mikie wrote: Hi, I experience some problems with the speedtch.c module, especially in regards to its firmware loader. I am not quite sure if this module is going to load the firmware itself or does it use some external software to do that ? It loads it itself, using some external software! For information, it generates a hotplug event and the kernel calls the program written at /proc/sys/kernel/hotplug with certain information. That used to be /sbin/hotplug, became later udev, but today in general udev reads the uevents generated by the kernel. On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. I copied your script to /sbin/hotplug and also added simple logging, so I can see whenever the script is being started. It turns out that the script is not started at all by the kernel... I am afraid that the kernel generates uevents only, could this be true? Not really, it would break backward compatibility, and if it were true, they're remove the /proc/sys/kernel/hotplug setting too. As far as I know, if it's set, that program will be executed, and if zero is written to it, only uevents are generated. Make sure that the script is executable (chmod +x) Yes I have set it to be executable: [EMAIL PROTECTED]:/sbin# ls -lah hotplug -rwxr-xr-x1 root root 934 Jul 9 09:13 hotplug and has #!/bin/sh at the top, or else it won't work. If that's already the case, I've no idea. [EMAIL PROTECTED]:/sbin# head hotplug #!/bin/sh set -e Everything looks OK, but still it does not fire up the script... It should run, if the kernel creates events. Can you run udevmonitor --env while loading the driver? That way we can see if events are generated by the kernel (if you don't have it, no need to install udev, just download the udev tarball, type make and run ./udevmonitor --env). Kay - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/9, Kay Sievers [EMAIL PROTECTED]: On 7/9/07, mikie [EMAIL PROTECTED] wrote: 2007/7/9, Indan Zupancic [EMAIL PROTECTED]: On Mon, July 9, 2007 10:49, mikie wrote: 2007/7/6, Indan Zupancic [EMAIL PROTECTED]: On Fri, July 6, 2007 16:20, Duncan Sands wrote: On Friday 6 July 2007 14:54:18 mikie wrote: Hi, I experience some problems with the speedtch.c module, especially in regards to its firmware loader. I am not quite sure if this module is going to load the firmware itself or does it use some external software to do that ? It loads it itself, using some external software! For information, it generates a hotplug event and the kernel calls the program written at /proc/sys/kernel/hotplug with certain information. That used to be /sbin/hotplug, became later udev, but today in general udev reads the uevents generated by the kernel. On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. I copied your script to /sbin/hotplug and also added simple logging, so I can see whenever the script is being started. It turns out that the script is not started at all by the kernel... I am afraid that the kernel generates uevents only, could this be true? Not really, it would break backward compatibility, and if it were true, they're remove the /proc/sys/kernel/hotplug setting too. As far as I know, if it's set, that program will be executed, and if zero is written to it, only uevents are generated. Make sure that the script is executable (chmod +x) Yes I have set it to be executable: [EMAIL PROTECTED]:/sbin# ls -lah hotplug -rwxr-xr-x1 root root 934 Jul 9 09:13 hotplug and has #!/bin/sh at the top, or else it won't work. If that's already the case, I've no idea. [EMAIL PROTECTED]:/sbin# head hotplug #!/bin/sh set -e Everything looks OK, but still it does not fire up the script... It should run, if the kernel creates events. Can you run udevmonitor --env while loading the driver? That way we can see if events are generated by the kernel (if you don't have it, no need to install udev, just download the udev tarball, type make and run ./udevmonitor --env). It seems that uevents are generated: UEVENT[1183991915.577581] add /class/firmware/1-2:1.0 (firmware) ACTION=add DEVPATH=/class/firmware/1-2:1.0 SUBSYSTEM=firmware SEQNUM=949 PHYSDEVPATH=/devices/pci:00/:00:07.2/usb1/1-2/1-2:1.0 PHYSDEVBUS=usb PHYSDEVDRIVER=speedtch FIRMWARE=speedtch-1.bin.2.00 TIMEOUT=60 UEVENT[1183991975.599358] add /class/firmware/1-2:1.0 (firmware) ACTION=add DEVPATH=/class/firmware/1-2:1.0 SUBSYSTEM=firmware SEQNUM=951 PHYSDEVPATH=/devices/pci:00/:00:07.2/usb1/1-2/1-2:1.0 PHYSDEVBUS=usb PHYSDEVDRIVER=speedtch FIRMWARE=speedtch-1.bin.2 TIMEOUT=60 -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On Mon, July 9, 2007 16:40, mikie wrote: 2007/7/9, Kay Sievers [EMAIL PROTECTED]: On 7/9/07, mikie [EMAIL PROTECTED] wrote: 2007/7/9, Indan Zupancic [EMAIL PROTECTED]: On Mon, July 9, 2007 10:49, mikie wrote: 2007/7/6, Indan Zupancic [EMAIL PROTECTED]: On Fri, July 6, 2007 16:20, Duncan Sands wrote: On Friday 6 July 2007 14:54:18 mikie wrote: Hi, I experience some problems with the speedtch.c module, especially in regards to its firmware loader. I am not quite sure if this module is going to load the firmware itself or does it use some external software to do that ? It loads it itself, using some external software! For information, it generates a hotplug event and the kernel calls the program written at /proc/sys/kernel/hotplug with certain information. That used to be /sbin/hotplug, became later udev, but today in general udev reads the uevents generated by the kernel. On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. I copied your script to /sbin/hotplug and also added simple logging, so I can see whenever the script is being started. It turns out that the script is not started at all by the kernel... I am afraid that the kernel generates uevents only, could this be true? Not really, it would break backward compatibility, and if it were true, they're remove the /proc/sys/kernel/hotplug setting too. As far as I know, if it's set, that program will be executed, and if zero is written to it, only uevents are generated. Make sure that the script is executable (chmod +x) Yes I have set it to be executable: [EMAIL PROTECTED]:/sbin# ls -lah hotplug -rwxr-xr-x1 root root 934 Jul 9 09:13 hotplug and has #!/bin/sh at the top, or else it won't work. If that's already the case, I've no idea. [EMAIL PROTECTED]:/sbin# head hotplug #!/bin/sh set -e Everything looks OK, but still it does not fire up the script... It should run, if the kernel creates events. Can you run udevmonitor --env while loading the driver? That way we can see if events are generated by the kernel (if you don't have it, no need to install udev, just download the udev tarball, type make and run ./udevmonitor --env). It seems that uevents are generated: What if you run a very simple script like #!/bin/sh echo test /tmp/test is it called at all? If it is then it's probably something with the other script. Try removing the set -e and/or run it manually with the right parameters set and see if anything goes wrong. Or use a minimal udev and let it do the hotplugging, having only rules for speedtouch and firmware loading (attached, but make sure the paths and pppd call is correct for your system). /dev can stay static, just change udev.conf to handle /udev or something. Regards, Indan speedtch.rules Description: Binary data
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On Mon, 2007-07-09 at 16:40 +0200, mikie wrote: 2007/7/9, Kay Sievers [EMAIL PROTECTED]: On 7/9/07, mikie [EMAIL PROTECTED] wrote: 2007/7/9, Indan Zupancic [EMAIL PROTECTED]: On Mon, July 9, 2007 10:49, mikie wrote: 2007/7/6, Indan Zupancic [EMAIL PROTECTED]: On Fri, July 6, 2007 16:20, Duncan Sands wrote: On Friday 6 July 2007 14:54:18 mikie wrote: Hi, I experience some problems with the speedtch.c module, especially in regards to its firmware loader. I am not quite sure if this module is going to load the firmware itself or does it use some external software to do that ? It loads it itself, using some external software! For information, it generates a hotplug event and the kernel calls the program written at /proc/sys/kernel/hotplug with certain information. That used to be /sbin/hotplug, became later udev, but today in general udev reads the uevents generated by the kernel. On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. I copied your script to /sbin/hotplug and also added simple logging, so I can see whenever the script is being started. It turns out that the script is not started at all by the kernel... I am afraid that the kernel generates uevents only, could this be true? Not really, it would break backward compatibility, and if it were true, they're remove the /proc/sys/kernel/hotplug setting too. As far as I know, if it's set, that program will be executed, and if zero is written to it, only uevents are generated. Make sure that the script is executable (chmod +x) Yes I have set it to be executable: [EMAIL PROTECTED]:/sbin# ls -lah hotplug -rwxr-xr-x1 root root 934 Jul 9 09:13 hotplug and has #!/bin/sh at the top, or else it won't work. If that's already the case, I've no idea. [EMAIL PROTECTED]:/sbin# head hotplug #!/bin/sh set -e Everything looks OK, but still it does not fire up the script... It should run, if the kernel creates events. Can you run udevmonitor --env while loading the driver? That way we can see if events are generated by the kernel (if you don't have it, no need to install udev, just download the udev tarball, type make and run ./udevmonitor --env). It seems that uevents are generated: UEVENT[1183991915.577581] add /class/firmware/1-2:1.0 (firmware) ACTION=add Using /sbin/hotplug works without any problems here: $ uname -a Linux lov 2.6.22-dirty #68 SMP Mon Jul 9 03:43:51 CEST 2007 x86_64 x86_64 x86_64 GNU/Linux $ cat /proc/sys/kernel/hotplug /sbin/hotplug $ ls -l /sbin/hotplug -rwxr-xr-x 1 root root 39 2007-07-09 17:02 /sbin/hotplug $ cat /sbin/hotplug #!/bin/sh set | logger -t hotplug $$ $ tail -50 /var/log/messages ... Jul 9 17:04:33 lov hotplug 15589: ACTION=add Jul 9 17:04:33 lov hotplug 15589: BASH=/bin/sh Jul 9 17:04:33 lov hotplug 15589: BASH_ARGC=([0]=1) Jul 9 17:04:33 lov hotplug 15589: BASH_ARGV=([0]=usb_endpoint) Jul 9 17:04:33 lov hotplug 15589: BASH_LINENO=([0]=0) Jul 9 17:04:33 lov hotplug 15589: BASH_SOURCE=([0]=/sbin/hotplug) Jul 9 17:04:33 lov hotplug 15589: MAJOR=254 Jul 9 17:04:33 lov hotplug 15589: MINOR=11 Jul 9 17:04:33 lov hotplug 15589: SUBSYSTEM=usb_endpoint ... Kay - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/9, Indan Zupancic [EMAIL PROTECTED]: On Mon, July 9, 2007 16:40, mikie wrote: 2007/7/9, Kay Sievers [EMAIL PROTECTED]: On 7/9/07, mikie [EMAIL PROTECTED] wrote: 2007/7/9, Indan Zupancic [EMAIL PROTECTED]: On Mon, July 9, 2007 10:49, mikie wrote: 2007/7/6, Indan Zupancic [EMAIL PROTECTED]: On Fri, July 6, 2007 16:20, Duncan Sands wrote: On Friday 6 July 2007 14:54:18 mikie wrote: Hi, I experience some problems with the speedtch.c module, especially in regards to its firmware loader. I am not quite sure if this module is going to load the firmware itself or does it use some external software to do that ? It loads it itself, using some external software! For information, it generates a hotplug event and the kernel calls the program written at /proc/sys/kernel/hotplug with certain information. That used to be /sbin/hotplug, became later udev, but today in general udev reads the uevents generated by the kernel. On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. I copied your script to /sbin/hotplug and also added simple logging, so I can see whenever the script is being started. It turns out that the script is not started at all by the kernel... I am afraid that the kernel generates uevents only, could this be true? Not really, it would break backward compatibility, and if it were true, they're remove the /proc/sys/kernel/hotplug setting too. As far as I know, if it's set, that program will be executed, and if zero is written to it, only uevents are generated. Make sure that the script is executable (chmod +x) Yes I have set it to be executable: [EMAIL PROTECTED]:/sbin# ls -lah hotplug -rwxr-xr-x1 root root 934 Jul 9 09:13 hotplug and has #!/bin/sh at the top, or else it won't work. If that's already the case, I've no idea. [EMAIL PROTECTED]:/sbin# head hotplug #!/bin/sh set -e Everything looks OK, but still it does not fire up the script... It should run, if the kernel creates events. Can you run udevmonitor --env while loading the driver? That way we can see if events are generated by the kernel (if you don't have it, no need to install udev, just download the udev tarball, type make and run ./udevmonitor --env). It seems that uevents are generated: What if you run a very simple script like #!/bin/sh echo test /tmp/test is it called at all? I tried that. I modified the script so it writes to /tmp/bla a simple line that the script was started. Now, when I start it manually by simply typing /sbin/hotplug in the bash, then the log shows that the script got started (as expected). However, when I do modprobe speedtch the kernel never runs this script... Certainly, I removed the speedtch module earlier (rmmod speedtch) and checked that it was removed with lsmod. What I tried to do is manually find the firmware directory in /sys/ after inserting the speedtch. Then I manually did the echo 1loading, cat speedtch-1.bin data, echo 0loading. And it worked. Everything after that went fine. So all I am missing is the hotplug script not being started by kernel at all. If it is then it's probably something with the other script. Try removing the set -e and/or run it manually with the right parameters set and see if anything goes wrong. Or use a minimal udev and let it do the hotplugging, having only rules for speedtouch and firmware loading (attached, but make sure the paths and pppd call is correct for your system). /dev can stay static, just change udev.conf to handle /udev or something. Thanks for your support and the attached rules. If I can't find other solution I will have to use the minimal udev environment that you provided. One more thing - when the modem finally runs in isochronous mode, yet I cannot get high transfer rates. I can't get nothing more than 3Mbits/s. When I used kernel 2.4 with bulk mode I had only 2.5 Mbit/s. So there is a little progress, but still not too much. Is it possible that weak and old hardware (Celeron 633 on a VIA chipset motherboard) is causing this ? -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/9, Duncan Sands [EMAIL PROTECTED]: One more thing - when the modem finally runs in isochronous mode, yet I cannot get high transfer rates. I can't get nothing more than 3Mbits/s. When I used kernel 2.4 with bulk mode I had only 2.5 Mbit/s. So there is a little progress, but still not too much. Is it possible that weak and old hardware (Celeron 633 on a VIA chipset motherboard) is causing this ? Is it actually running in isochronous mode? (It prints some messages about this). This is what I get: [EMAIL PROTECTED]:/# cat /sys/module/speedtch/parameters/enable_isoc Y I think it means it confirms the isochronous mode is working. Especially that I modified the source of the speedtch.c so that the enable_isoc is on by default. You may need new firmware (I've attached some recent firmware that was made available by Thomson UK without any licence conditions). Many thanks for your great support. I will try the new firmware tomorrow, as this is a remote machine and I would now risk loosing it for an entire evening and night in case something goes wrong (usually it just does go wrong :) -- Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hi, Is it actually running in isochronous mode? (It prints some messages about this). This is what I get: [EMAIL PROTECTED]:/# cat /sys/module/speedtch/parameters/enable_isoc Y I think it means it confirms the isochronous mode is working. Especially that I modified the source of the speedtch.c so that the enable_isoc is on by default. if you turn on isochronous mode, but there is some reason it can't be used you get the message: isochronous transfer not supported - using bulk. Ciao, Duncan. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/6, Duncan Sands <[EMAIL PROTECTED]>: Hi, you should keep this discussion on the lkml so it will be archived - that way it may help others too. I was sure I copied lkml, but obviously something went wrong. On Friday 6 July 2007 19:06:14 mikie wrote: > 2007/7/6, Duncan Sands <[EMAIL PROTECTED]>: > > On Friday 6 July 2007 14:54:18 mikie wrote: > > > Hi, > > > > > > I experience some problems with the speedtch.c module, especially in > > > regards to its firmware loader. > > > I am not quite sure if this module is going to load the firmware > > > itself or does it use some external software to do that ? > > > > It loads it itself, using some external software! > > OK, so probably I don't have anything external. Could you please point > me to the specific helper-program takes care of this process? As I > understand it is not done entirely by kernel itself? The external helper is the firmware.agent script! The modem driver calls the kernel's firmware subsystem, the firmware subsystem creates a user space thread and calls whatever program is specified in /proc/sys/kernel/hotplug At the same time the firmware subsystem creates the "data" and "loading" files. The hotplug program is supposed to write the firmware into "data". Thanks for the explanation. Now I get the overall picture of what whould be done to load the firmware. I will try playing around with the firmware.agent script, although I do not havfe the entire hotplug package on my system, but probably this should work with a bit of manual bash scripting. See Documentation/firmware_class in the kernel source for details. More recent systems fire off a "uevent" and have udev take care of loading the firmware. What do you mean by "recent systems" ? Is it distro dependent or kernel dependent ? In any case, the external helper is not specific to this modem - it is part of the general hotplug infrastructure. If you have hotplug or udev installed, probably they are looking for the firmware in the wrong place. Actually I don't have hotplug/udev. That is why I am thinking of some basic manual firmware loading. I switched from 2.4.33.3 kernel, where such toold were not needed (I guess). > > > All I get is : > > > > > > Jul 6 13:41:37 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: > > > looking for speedtch-1.bin.2.00 > > > [...] > > > Jul 6 13:42:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: > > > looking for speedtch-1.bin.2 > > > [...] > > > Jul 6 13:43:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: > > > looking for speedtch-1.bin > > > > > > And nothing more happens. The firmware does not get loaded to the > > > modem. There is also no information in the logs that the firmware > > > loading failed... > > > > It should either print: > > no stage 1 firmware found! > > or > > found stage 1 firmware > > Does it really print neither? If so, that must mean that the > > firmware loader got stuck. > > I don't have anything about stage 1. This probably is done by some > helper program, as I understood. No, the modem prints one of these two messages when the user space helper returns, or a timeout occurs. The fact it isn't printed suggests that the timeout is infinite. The timeout is in /sys/class/firmware/timeout I will take a closer look at the timeout value. It is quite uncomfortable for me right now to switch to the new kernel, because I loose internet connectivity at that time :) > But I don't know which one is that. > Perhaps I could do it manually ? Like copying the firmware to the > "data" ? Actually you could. All the firmware.agent does (or did, maybe it got more sophisticated) is use "cat" to write the firmware file to "data". I tried some basic copy, but received permission denied even though I was root. Perhaps I was trying at the wrong location. I'll get back with more info on Monday. Thanks for your help. Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On Fri, July 6, 2007 16:20, Duncan Sands wrote:
> On Friday 6 July 2007 14:54:18 mikie wrote:
>> Hi,
>>
>> I experience some problems with the speedtch.c module, especially in
>> regards to its firmware loader.
>> I am not quite sure if this module is going to load the firmware
>> itself or does it use some external software to do that ?
>
> It loads it itself, using some external software!
For information, it generates a hotplug event and the kernel calls the
program written at /proc/sys/kernel/hotplug with certain information.
That used to be /sbin/hotplug, became later udev, but today in general
udev reads the uevents generated by the kernel.
>> I have read and checked the firmware.agent script from some hotplug
>> package, and noticed that it makes something like simple file copy of
>> the firmware to the "data" and echoing 1 or 0 to the "loading" file.
>> But what is the location of these data/loading ? Also the firmware is
>> split into 2 parts -- should I upload them one after another? Is that
>> all that should be done to get the firmware loaded?
>
> You need to write the file that was asked for: the modem starts by asking
> for the first file, uploads it, then asks for the second file and uploads it.
> The file is written to the "data" file, but note that the data file is created
> on the fly when the modem requests a firmware load so you can't write to it
> at some random time.
If you really don't want to use udevd, you could use the below script I wrote
(not really tested, it's an bash version of the Udev rules I've have, more or
less.)
Echo the script pathname to /proc/sys/kernel/hotplug early at bootup and all
should work, assuming your pppd is setup correctly and the script isn't buggy.
#!/bin/sh
set -e
p()
{
# For debugging/logging, edit for your needs.
echo "$*"
echo "$*" > /dev/vc/1;
echo "$*" >> /tmp/bla;
}
if [ "$SUBSYSTEM" = "firmware" ]; then
p "Loading firmware..."
cd /sys/$DEVPATH
if [ -f "/lib/firmware/$FIRMWARE" ]; then
echo 1 > loading
cat "/lib/firmware/$FIRMWARE" > data
echo 0 > loading
p "Done."
else
echo -1 > loading
p "$FIRMWARE not found."
fi
elif [ "$SUBSYSTEM" = "atm" ]; then
if [[ "$KERNEL" != speedtch* ]]; then
exit
fi
if [ "$ACTION" = "add" ]; then
p "Starting pppd."
pppd call adsl
elif [ "$ACTION" = "remove" ]; then
p "Stopping pppd."
pkill pppd
fi
fi
Greetings,
Indan
-
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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On Friday 6 July 2007 14:54:18 mikie wrote: > Hi, > > I experience some problems with the speedtch.c module, especially in > regards to its firmware loader. > I am not quite sure if this module is going to load the firmware > itself or does it use some external software to do that ? It loads it itself, using some external software! > All I get is : > > Jul 6 13:41:37 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: > looking for speedtch-1.bin.2.00 > [...] > Jul 6 13:42:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: > looking for speedtch-1.bin.2 > [...] > Jul 6 13:43:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: > looking for speedtch-1.bin > > And nothing more happens. The firmware does not get loaded to the > modem. There is also no information in the logs that the firmware > loading failed... It should either print: no stage 1 firmware found! or found stage 1 firmware Does it really print neither? If so, that must mean that the firmware loader got stuck. > I have read and checked the firmware.agent script from some hotplug > package, and noticed that it makes something like simple file copy of > the firmware to the "data" and echoing 1 or 0 to the "loading" file. > But what is the location of these data/loading ? Also the firmware is > split into 2 parts -- should I upload them one after another? Is that > all that should be done to get the firmware loaded? You need to write the file that was asked for: the modem starts by asking for the first file, uploads it, then asks for the second file and uploads it. The file is written to the "data" file, but note that the data file is created on the fly when the modem requests a firmware load so you can't write to it at some random time. Ciao, Duncan. - 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/
understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hi, I experience some problems with the speedtch.c module, especially in regards to its firmware loader. I am not quite sure if this module is going to load the firmware itself or does it use some external software to do that ? All I get is : Jul 6 13:41:37 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin.2.00 [...] Jul 6 13:42:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin.2 [...] Jul 6 13:43:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin And nothing more happens. The firmware does not get loaded to the modem. There is also no information in the logs that the firmware loading failed... It is worth noting that I use slackware distro, that was installed long time ago with 8.1 (or 9.0) CD version, and I only make package upgrades. I used to work with kernel 2.4.33.3 (I compile the kernel myself), but now decided I switch to the new 2.6 series. The old distro means that I do not use hotplug nor udevd in my system (and would like to stick with that scenario, if possible). I have read and checked the firmware.agent script from some hotplug package, and noticed that it makes something like simple file copy of the firmware to the "data" and echoing 1 or 0 to the "loading" file. But what is the location of these data/loading ? Also the firmware is split into 2 parts -- should I upload them one after another? Is that all that should be done to get the firmware loaded? Regards, MK - 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/
understanding firmware loader for speedtouch (kernel 2.6.21.5)
Hi, I experience some problems with the speedtch.c module, especially in regards to its firmware loader. I am not quite sure if this module is going to load the firmware itself or does it use some external software to do that ? All I get is : Jul 6 13:41:37 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin.2.00 [...] Jul 6 13:42:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin.2 [...] Jul 6 13:43:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin And nothing more happens. The firmware does not get loaded to the modem. There is also no information in the logs that the firmware loading failed... It is worth noting that I use slackware distro, that was installed long time ago with 8.1 (or 9.0) CD version, and I only make package upgrades. I used to work with kernel 2.4.33.3 (I compile the kernel myself), but now decided I switch to the new 2.6 series. The old distro means that I do not use hotplug nor udevd in my system (and would like to stick with that scenario, if possible). I have read and checked the firmware.agent script from some hotplug package, and noticed that it makes something like simple file copy of the firmware to the data and echoing 1 or 0 to the loading file. But what is the location of these data/loading ? Also the firmware is split into 2 parts -- should I upload them one after another? Is that all that should be done to get the firmware loaded? Regards, MK - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On Friday 6 July 2007 14:54:18 mikie wrote: Hi, I experience some problems with the speedtch.c module, especially in regards to its firmware loader. I am not quite sure if this module is going to load the firmware itself or does it use some external software to do that ? It loads it itself, using some external software! All I get is : Jul 6 13:41:37 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin.2.00 [...] Jul 6 13:42:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin.2 [...] Jul 6 13:43:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin And nothing more happens. The firmware does not get loaded to the modem. There is also no information in the logs that the firmware loading failed... It should either print: no stage 1 firmware found! or found stage 1 firmware name Does it really print neither? If so, that must mean that the firmware loader got stuck. I have read and checked the firmware.agent script from some hotplug package, and noticed that it makes something like simple file copy of the firmware to the data and echoing 1 or 0 to the loading file. But what is the location of these data/loading ? Also the firmware is split into 2 parts -- should I upload them one after another? Is that all that should be done to get the firmware loaded? You need to write the file that was asked for: the modem starts by asking for the first file, uploads it, then asks for the second file and uploads it. The file is written to the data file, but note that the data file is created on the fly when the modem requests a firmware load so you can't write to it at some random time. Ciao, Duncan. - 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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
On Fri, July 6, 2007 16:20, Duncan Sands wrote:
On Friday 6 July 2007 14:54:18 mikie wrote:
Hi,
I experience some problems with the speedtch.c module, especially in
regards to its firmware loader.
I am not quite sure if this module is going to load the firmware
itself or does it use some external software to do that ?
It loads it itself, using some external software!
For information, it generates a hotplug event and the kernel calls the
program written at /proc/sys/kernel/hotplug with certain information.
That used to be /sbin/hotplug, became later udev, but today in general
udev reads the uevents generated by the kernel.
I have read and checked the firmware.agent script from some hotplug
package, and noticed that it makes something like simple file copy of
the firmware to the data and echoing 1 or 0 to the loading file.
But what is the location of these data/loading ? Also the firmware is
split into 2 parts -- should I upload them one after another? Is that
all that should be done to get the firmware loaded?
You need to write the file that was asked for: the modem starts by asking
for the first file, uploads it, then asks for the second file and uploads it.
The file is written to the data file, but note that the data file is created
on the fly when the modem requests a firmware load so you can't write to it
at some random time.
If you really don't want to use udevd, you could use the below script I wrote
(not really tested, it's an bash version of the Udev rules I've have, more or
less.)
Echo the script pathname to /proc/sys/kernel/hotplug early at bootup and all
should work, assuming your pppd is setup correctly and the script isn't buggy.
#!/bin/sh
set -e
p()
{
# For debugging/logging, edit for your needs.
echo $*
echo $* /dev/vc/1;
echo $* /tmp/bla;
}
if [ $SUBSYSTEM = firmware ]; then
p Loading firmware...
cd /sys/$DEVPATH
if [ -f /lib/firmware/$FIRMWARE ]; then
echo 1 loading
cat /lib/firmware/$FIRMWARE data
echo 0 loading
p Done.
else
echo -1 loading
p $FIRMWARE not found.
fi
elif [ $SUBSYSTEM = atm ]; then
if [[ $KERNEL != speedtch* ]]; then
exit
fi
if [ $ACTION = add ]; then
p Starting pppd.
pppd call adsl
elif [ $ACTION = remove ]; then
p Stopping pppd.
pkill pppd
fi
fi
Greetings,
Indan
-
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/
Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
2007/7/6, Duncan Sands [EMAIL PROTECTED]: Hi, you should keep this discussion on the lkml so it will be archived - that way it may help others too. I was sure I copied lkml, but obviously something went wrong. On Friday 6 July 2007 19:06:14 mikie wrote: 2007/7/6, Duncan Sands [EMAIL PROTECTED]: On Friday 6 July 2007 14:54:18 mikie wrote: Hi, I experience some problems with the speedtch.c module, especially in regards to its firmware loader. I am not quite sure if this module is going to load the firmware itself or does it use some external software to do that ? It loads it itself, using some external software! OK, so probably I don't have anything external. Could you please point me to the specific helper-program takes care of this process? As I understand it is not done entirely by kernel itself? The external helper is the firmware.agent script! The modem driver calls the kernel's firmware subsystem, the firmware subsystem creates a user space thread and calls whatever program is specified in /proc/sys/kernel/hotplug At the same time the firmware subsystem creates the data and loading files. The hotplug program is supposed to write the firmware into data. Thanks for the explanation. Now I get the overall picture of what whould be done to load the firmware. I will try playing around with the firmware.agent script, although I do not havfe the entire hotplug package on my system, but probably this should work with a bit of manual bash scripting. See Documentation/firmware_class in the kernel source for details. More recent systems fire off a uevent and have udev take care of loading the firmware. What do you mean by recent systems ? Is it distro dependent or kernel dependent ? In any case, the external helper is not specific to this modem - it is part of the general hotplug infrastructure. If you have hotplug or udev installed, probably they are looking for the firmware in the wrong place. Actually I don't have hotplug/udev. That is why I am thinking of some basic manual firmware loading. I switched from 2.4.33.3 kernel, where such toold were not needed (I guess). All I get is : Jul 6 13:41:37 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin.2.00 [...] Jul 6 13:42:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin.2 [...] Jul 6 13:43:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware: looking for speedtch-1.bin And nothing more happens. The firmware does not get loaded to the modem. There is also no information in the logs that the firmware loading failed... It should either print: no stage 1 firmware found! or found stage 1 firmware name Does it really print neither? If so, that must mean that the firmware loader got stuck. I don't have anything about stage 1. This probably is done by some helper program, as I understood. No, the modem prints one of these two messages when the user space helper returns, or a timeout occurs. The fact it isn't printed suggests that the timeout is infinite. The timeout is in /sys/class/firmware/timeout I will take a closer look at the timeout value. It is quite uncomfortable for me right now to switch to the new kernel, because I loose internet connectivity at that time :) But I don't know which one is that. Perhaps I could do it manually ? Like copying the firmware to the data ? Actually you could. All the firmware.agent does (or did, maybe it got more sophisticated) is use cat to write the firmware file to data. I tried some basic copy, but received permission denied even though I was root. Perhaps I was trying at the wrong location. I'll get back with more info on Monday. Thanks for your help. Regards, MK - 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/
