Am Donnerstag, 29. November 2007 19:53:39 schrieb Jaime Velasco Juan:
> Hi,
>
> El jue. 29 de nov. de 2007, a las 15:05:50 +0100, Johann Wilhelm escribió:
> > If everything's working please also add code to also support the other
> > E220 device... so both PID 0x1003 and 0x1004 should be treaded
Oliver Neukum wrote:
> Am Donnerstag 29 November 2007 schrieb Rui Santos:
>
Just to remember that that specific flag was one SET and, was removed,
in part, because of what I state. Of course we aim at perfection but, if
the benefits are only for a few situations and, will cause
Hi,
El jue. 29 de nov. de 2007, a las 15:05:50 +0100, Johann Wilhelm escribió:
> If everything's working please also add code to also support the other E220
> device... so both PID 0x1003 and 0x1004 should be treaded the same way...
>
> to test the device with the 0x1004-PID maybe Jaime Velasco
On Thu, Nov 29, 2007 at 12:01:49AM -0800, Pete Zaitcev wrote:
> On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > 3. Make sure usbcore doesn't probe the devices in the wrong mode with the
> > option driver
>
> This fixes duplication. And to take it further, why
Am Donnerstag 29 November 2007 schrieb Kristoffer Ericson:
> I'll give it a go later today, still on 2.6.22.4.
>
> Any logs of interest except for obvious behavior?
dmesg
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
I'll give it a go later today, still on 2.6.22.4.
Any logs of interest except for obvious behavior?
On Thu, 29 Nov 2007 15:05:50 +0100
Johann Wilhelm <[EMAIL PROTECTED]> wrote:
> If everything's working please also add code to also support the other
> E220 device... so both PID 0x1003 and
On Do, 29 Nov 2007, preining wrote:
> So to be clear: kernl 2.6.24-rc3 + your patch gives me permanent cycles
> and an error:
> option_start_huawei: HUAWEI E220 setup failed (1)
> I attach the syslog part which exhibits the behaviour.
Now really attached.
Best wishes
Norbert
Hi Pete, hi all,
On Mi, 28 Nov 2007, Pete Zaitcev wrote:
> It looks like the Huawei E220 saga is not over yet. A collegue of mine,
> David Russll, reported that the modem does not work reliably on Fedora 8,
> which does have the initializer in usb-storage.
That is what I said.
> it's random
If everything's working please also add code to also support the other
E220 device... so both PID 0x1003 and 0x1004 should be treaded the
same way...
to test the device with the 0x1004-PID maybe Jaime Velasco
<[EMAIL PROTECTED]> could be asked.. he initialy added the lines
for this
Am Donnerstag 29 November 2007 schrieb Rui Santos:
> >> Just to remember that that specific flag was one SET and, was removed,
> >> in part, because of what I state. Of course we aim at perfection but, if
> >> the benefits are only for a few situations and, will cause all this
> >> problems for
Oliver Neukum wrote:
> Am Donnerstag, 29. November 2007 11:01:34 schrieb Rui Santos:
>
>>> Changing the unusual_devs.h flag to IGNORE_DEVICE should accomplish what
>>> you want.
>>>
>>>
>> If the IGNORE_DEVICE flag is set, access to the device's virtual-cd is
>> no longer possible, and
Am Donnerstag, 29. November 2007 11:01:34 schrieb Rui Santos:
> > Changing the unusual_devs.h flag to IGNORE_DEVICE should accomplish what
> > you want.
> >
>
> If the IGNORE_DEVICE flag is set, access to the device's virtual-cd is
> no longer possible, and might not be the correct approach.
Matthew Dharm wrote:
> On Thu, Nov 29, 2007 at 09:14:47AM +0100, Oliver Neukum wrote:
>
>> Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev:
>>
>>> On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>>>
3. Make sure usbcore doesn't probe
On Thu, Nov 29, 2007 at 09:14:47AM +0100, Oliver Neukum wrote:
> Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev:
> > On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > 3. Make sure usbcore doesn't probe the devices in the wrong mode with the
> > >
Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev:
> On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > 3. Make sure usbcore doesn't probe the devices in the wrong mode with the
> > option driver
>
> This fixes duplication. And to take it further, why
On Thu, 29 Nov 2007 09:04:28 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > Isn't it possible to fix this in option's module table?
> >
> > At first thought it'll need adding a field to struct usb_serial to save
> > the driver_info from the ID table in usb_serial_probe. It's something I'd
Am Donnerstag, 29. November 2007 08:52:37 schrieb Pete Zaitcev:
> On Thu, 29 Nov 2007 08:38:59 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
> > > The problem stems from the fact that both option and usb-storage can
> > > bind
On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> 3. Make sure usbcore doesn't probe the devices in the wrong mode with the
> option driver
This fixes duplication. And to take it further, why don't we turn this
idea around and let usb-storage fail to attach with
Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev:
On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum [EMAIL PROTECTED] wrote:
3. Make sure usbcore doesn't probe the devices in the wrong mode with the
option driver
This fixes duplication. And to take it further, why don't we
On Thu, 29 Nov 2007 09:04:28 +0100, Oliver Neukum [EMAIL PROTECTED] wrote:
Isn't it possible to fix this in option's module table?
At first thought it'll need adding a field to struct usb_serial to save
the driver_info from the ID table in usb_serial_probe. It's something I'd
Why? It
On Thu, Nov 29, 2007 at 09:14:47AM +0100, Oliver Neukum wrote:
Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev:
On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum [EMAIL PROTECTED] wrote:
3. Make sure usbcore doesn't probe the devices in the wrong mode with the
option driver
Matthew Dharm wrote:
On Thu, Nov 29, 2007 at 09:14:47AM +0100, Oliver Neukum wrote:
Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev:
On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum [EMAIL PROTECTED] wrote:
3. Make sure usbcore doesn't probe the devices in the
Am Donnerstag, 29. November 2007 11:01:34 schrieb Rui Santos:
Changing the unusual_devs.h flag to IGNORE_DEVICE should accomplish what
you want.
If the IGNORE_DEVICE flag is set, access to the device's virtual-cd is
no longer possible, and might not be the correct approach. Just as an
Oliver Neukum wrote:
Am Donnerstag, 29. November 2007 11:01:34 schrieb Rui Santos:
Changing the unusual_devs.h flag to IGNORE_DEVICE should accomplish what
you want.
If the IGNORE_DEVICE flag is set, access to the device's virtual-cd is
no longer possible, and might not be the
Am Donnerstag 29 November 2007 schrieb Rui Santos:
Just to remember that that specific flag was one SET and, was removed,
in part, because of what I state. Of course we aim at perfection but, if
the benefits are only for a few situations and, will cause all this
problems for all other,
Hi Pete, hi all,
On Mi, 28 Nov 2007, Pete Zaitcev wrote:
It looks like the Huawei E220 saga is not over yet. A collegue of mine,
David Russll, reported that the modem does not work reliably on Fedora 8,
which does have the initializer in usb-storage.
That is what I said.
it's random which
On Do, 29 Nov 2007, preining wrote:
So to be clear: kernl 2.6.24-rc3 + your patch gives me permanent cycles
and an error:
option_start_huawei: HUAWEI E220 setup failed (1)
I attach the syslog part which exhibits the behaviour.
Now really attached.
Best wishes
Norbert
If everything's working please also add code to also support the other
E220 device... so both PID 0x1003 and 0x1004 should be treaded the
same way...
to test the device with the 0x1004-PID maybe Jaime Velasco
[EMAIL PROTECTED] could be asked.. he initialy added the lines
for this device
I'll give it a go later today, still on 2.6.22.4.
Any logs of interest except for obvious behavior?
On Thu, 29 Nov 2007 15:05:50 +0100
Johann Wilhelm [EMAIL PROTECTED] wrote:
If everything's working please also add code to also support the other
E220 device... so both PID 0x1003 and 0x1004
Am Donnerstag 29 November 2007 schrieb Kristoffer Ericson:
I'll give it a go later today, still on 2.6.22.4.
Any logs of interest except for obvious behavior?
dmesg
Regards
Oliver
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Thu, Nov 29, 2007 at 12:01:49AM -0800, Pete Zaitcev wrote:
On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum [EMAIL PROTECTED] wrote:
3. Make sure usbcore doesn't probe the devices in the wrong mode with the
option driver
This fixes duplication. And to take it further, why don't we
Hi,
El jue. 29 de nov. de 2007, a las 15:05:50 +0100, Johann Wilhelm escribió:
If everything's working please also add code to also support the other E220
device... so both PID 0x1003 and 0x1004 should be treaded the same way...
to test the device with the 0x1004-PID maybe Jaime Velasco
Oliver Neukum wrote:
Am Donnerstag 29 November 2007 schrieb Rui Santos:
Just to remember that that specific flag was one SET and, was removed,
in part, because of what I state. Of course we aim at perfection but, if
the benefits are only for a few situations and, will cause all this
Am Donnerstag, 29. November 2007 19:53:39 schrieb Jaime Velasco Juan:
Hi,
El jue. 29 de nov. de 2007, a las 15:05:50 +0100, Johann Wilhelm escribió:
If everything's working please also add code to also support the other
E220 device... so both PID 0x1003 and 0x1004 should be treaded the same
On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum [EMAIL PROTECTED] wrote:
3. Make sure usbcore doesn't probe the devices in the wrong mode with the
option driver
This fixes duplication. And to take it further, why don't we turn this
idea around and let usb-storage fail to attach with some
Am Donnerstag, 29. November 2007 08:52:37 schrieb Pete Zaitcev:
On Thu, 29 Nov 2007 08:38:59 +0100, Oliver Neukum [EMAIL PROTECTED] wrote:
Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
The problem stems from the fact that both option and usb-storage can
bind to the modem
On Thu, 29 Nov 2007 08:38:59 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
> > The problem stems from the fact that both option and usb-storage can bind
> > to the modem when in storage mode: the former binds because of the
Am Donnerstag, 29. November 2007 07:33:03 schrieb Johann Wilhelm:
> But in my opinion the the modul-load-order should be forced by udev...
> this should work and we only have 1 position to keep in mind if we eg.
> get a new E220, support for the E270 or something else...
No, udev cannot help
Hi there,
Well your code basically looks nice... but keep in mind that there are
several different E220-devices (in fact i know of 2 different PIDs...
and I would be really surprised if they only use 2 of them...). So you
should check all possible PIDs...
But in my opinion the the
Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
> The problem stems from the fact that both option and usb-storage can bind
> to the modem when in storage mode: the former binds because of the storage
> class, the latter binds because of VID/PID match. The modprobe loads both,
Hi, All:
It looks like the Huawei E220 saga is not over yet. A collegue of mine,
David Russll, reported that the modem does not work reliably on Fedora 8,
which does have the initializer in usb-storage.
The problem stems from the fact that both option and usb-storage can bind
to the modem when
Hi, All:
It looks like the Huawei E220 saga is not over yet. A collegue of mine,
David Russll, reported that the modem does not work reliably on Fedora 8,
which does have the initializer in usb-storage.
The problem stems from the fact that both option and usb-storage can bind
to the modem when
Hi there,
Well your code basically looks nice... but keep in mind that there are
several different E220-devices (in fact i know of 2 different PIDs...
and I would be really surprised if they only use 2 of them...). So you
should check all possible PIDs...
But in my opinion the the
Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
The problem stems from the fact that both option and usb-storage can bind
to the modem when in storage mode: the former binds because of the storage
class, the latter binds because of VID/PID match. The modprobe loads both,
Isn't
On Thu, 29 Nov 2007 08:38:59 +0100, Oliver Neukum [EMAIL PROTECTED] wrote:
Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
The problem stems from the fact that both option and usb-storage can bind
to the modem when in storage mode: the former binds because of the storage
Am Donnerstag, 29. November 2007 07:33:03 schrieb Johann Wilhelm:
But in my opinion the the modul-load-order should be forced by udev...
this should work and we only have 1 position to keep in mind if we eg.
get a new E220, support for the E270 or something else...
No, udev cannot help
46 matches
Mail list logo
