Hi all,
I have a problem using GPRS inet vi my Siemens S55 attached with USB
cable since kernel version 2.4.27-pre5, the link is established well,
but then no packets get received, looking with tcpdump shows outgoing
ping packets and just few per several minutes received back. I'm unable
to ping, do nslookup, etc.
The problem started when i switched from kernel 2.4.26 (linux slackware
10.0) to 2.4.28-pre3. None of ppp otions haven't changed and all the
same options were set during kerenel config. So i decided to test all
kernels between 2.4.26 and 2.4.28-pre4 (also not working). Link works
well in 2.4.27-pre5 and stop working in 2.4.27-pre6. No "strange"
messages or errors in the logs. firewall is disabled (ACCEPT for all).
i'm using:
pppd-2.4.2
Siemens S55 mobile
USB cable (PL2303 conroller)
USB drivers:
ehci_hcd
uhci.c
pl2303.c
Thanks.
--
Oleksiy
http://voodoo.com.ua
Hi,
No, i haven't changed anything: the same cable, the same modules.
I was compiling new kernels (-pre1, -pre2 ... all patches ) and just
after boot running pppd to test connection.
2.4.26 and all 2.4.27-preX works fine till -pre6. All after -pre6
including 2.4.28-pre4 are not working for me...
Hardware: Dell Inspiron 1100 notebook
Marcelo Tosatti wrote:
>Pete,
>
>I bet this has been caused by your USB changes?
>
>Can you take a look at this please?
>
>On Mon, Oct 11, 2004 at 02:22:32PM +0300, Oleksiy wrote:
>
>
>>Hi all,
>>
>>I have a problem using GPRS inet vi my Siemens S55 attached with USB
>>cable since kernel version 2.4.27-pre5, the link is established well,
>>but then no packets get received, looking with tcpdump shows outgoing
>>ping packets and just few per several minutes received back. I'm unable
>>to ping, do nslookup, etc.
>>The problem started when i switched from kernel 2.4.26 (linux slackware
>>10.0) to 2.4.28-pre3. None of ppp otions haven't changed and all the
>>same options were set during kerenel config. So i decided to test all
>>kernels between 2.4.26 and 2.4.28-pre4 (also not working). Link works
>>well in 2.4.27-pre5 and stop working in 2.4.27-pre6. No "strange"
>>messages or errors in the logs. firewall is disabled (ACCEPT for all).
>>
>>i'm using:
>>
>>pppd-2.4.2
>>Siemens S55 mobile
>>USB cable (PL2303 conroller)
>>
>>USB drivers:
>>
>>ehci_hcd
>>uhci.c
>>pl2303.c
>>
>>
>>
--
Oleksiy
http://voodoo.com.ua
Pete,
I bet this has been caused by your USB changes?
Can you take a look at this please?
On Mon, Oct 11, 2004 at 02:22:32PM +0300, Oleksiy wrote:
> Hi all,
>
> I have a problem using GPRS inet vi my Siemens S55 attached with USB
> cable since kernel version 2.4.27-pre5, the link is established well,
> but then no packets get received, looking with tcpdump shows outgoing
> ping packets and just few per several minutes received back. I'm unable
> to ping, do nslookup, etc.
> The problem started when i switched from kernel 2.4.26 (linux slackware
> 10.0) to 2.4.28-pre3. None of ppp otions haven't changed and all the
> same options were set during kerenel config. So i decided to test all
> kernels between 2.4.26 and 2.4.28-pre4 (also not working). Link works
> well in 2.4.27-pre5 and stop working in 2.4.27-pre6. No "strange"
> messages or errors in the logs. firewall is disabled (ACCEPT for all).
>
> i'm using:
>
> pppd-2.4.2
> Siemens S55 mobile
> USB cable (PL2303 conroller)
>
> USB drivers:
>
> ehci_hcd
> uhci.c
> pl2303.c
>
On Mon, Oct 11, 2004 at 02:22:32PM +0300, Oleksiy wrote:
> Hi all,
>
> I have a problem using GPRS inet vi my Siemens S55 attached with USB
> cable since kernel version 2.4.27-pre5, the link is established well,
> but then no packets get received, looking with tcpdump shows outgoing
> ping packets and just few per several minutes received back. I'm unable
> to ping, do nslookup, etc.
> The problem started when i switched from kernel 2.4.26 (linux slackware
> 10.0) to 2.4.28-pre3. None of ppp otions haven't changed and all the
> same options were set during kerenel config. So i decided to test all
> kernels between 2.4.26 and 2.4.28-pre4 (also not working). Link works
> well in 2.4.27-pre5 and stop working in 2.4.27-pre6. No "strange"
> messages or errors in the logs. firewall is disabled (ACCEPT for all).
Can you enable CONFIG_DEBUG?
There were no pl2303 driver changes between 2.4.27-pre5 and pre6, so I
don't think it's that driver...
thanks,
greg k-h
On Mon, 11 Oct 2004 08:36:09 -0300
Marcelo Tosatti <[email protected]> wrote:
> Pete,
>
> I bet this has been caused by your USB changes?
> > [...] So i decided to test all
> > kernels between 2.4.26 and 2.4.28-pre4 (also not working). Link works
> > well in 2.4.27-pre5 and stop working in 2.4.27-pre6.
I'm afraid you're right, because Oleksiy did the bisection. However,
I cannot see how this is possible. In fact, it fixed ppp for a few
people...
This may be something pl2303 specific. I'll work with Oleksiy to get
to the bottom of it.
-- Pete
On Tuesday 12 October 2004 17:48, Pete Zaitcev wrote:
> On Mon, 11 Oct 2004 08:36:09 -0300
>
> Marcelo Tosatti <[email protected]> wrote:
> > Pete,
> >
> > I bet this has been caused by your USB changes?
> >
> > > [...] So i decided to test all
> > > kernels between 2.4.26 and 2.4.28-pre4 (also not working). Link works
> > > well in 2.4.27-pre5 and stop working in 2.4.27-pre6.
>
> I'm afraid you're right, because Oleksiy did the bisection. However,
> I cannot see how this is possible. In fact, it fixed ppp for a few
> people...
>
> This may be something pl2303 specific. I'll work with Oleksiy to get
> to the bottom of it.
>
> -- Pete
May I add that I have some problems with a pl2303 GPS device which causes
kernel panics when I pull it out of the USB port.
I don't know if it can be related, the device works fine until I unplug it.
Cheers
Alexander Wigen
--
Homepage: http://www.wigen.net Mail: [email protected]
If you don't believe in oral sex, keep your mouth shut.
On Wed, Oct 13, 2004 at 07:32:28PM +0000, Alexander Wigen wrote:
>
> May I add that I have some problems with a pl2303 GPS device which causes
> kernel panics when I pull it out of the USB port.
>
> I don't know if it can be related, the device works fine until I unplug it.
On what kernel version do you have these problems?
thanks,
greg k-h
On Wednesday 13 October 2004 17:42, Greg KH wrote:
> On Wed, Oct 13, 2004 at 07:32:28PM +0000, Alexander Wigen wrote:
> > May I add that I have some problems with a pl2303 GPS device which causes
> > kernel panics when I pull it out of the USB port.
> >
> > I don't know if it can be related, the device works fine until I unplug
> > it.
>
> On what kernel version do you have these problems?
I had the problem on two laptops and a stationary machine running 2.4.20. I
dug out the old gps device and am happy to say the problem is gone on
2.6.8.1. I don't have a 2.4 kernel handy so I can't say if the problem is
still present in the 2.4 branch.
Cheers
Alexander Wigen
--
Homepage: http://www.wigen.net Mail: [email protected]
Why is the time of day with the slowest traffic called rush hour?
On Thu, 2004-10-14 14:06:58 +0000, Alexander Wigen <[email protected]>
wrote in message <[email protected]>:
> On Wednesday 13 October 2004 17:42, Greg KH wrote:
> > On Wed, Oct 13, 2004 at 07:32:28PM +0000, Alexander Wigen wrote:
> I had the problem on two laptops and a stationary machine running 2.4.20. I
> dug out the old gps device and am happy to say the problem is gone on
> 2.6.8.1. I don't have a 2.4 kernel handy so I can't say if the problem is
> still present in the 2.4 branch.
2.4.20 is quite old; additionally, the pl2303 driver has known problems
(Oops on device removal while the device node is opened for example...).
2.6.x just works (last famous words, I know...) but I suggest you just
upgrade to 2.6.x. I'm using this driver basically each day (for GPS
receiver and a number of serial links for serial console) and never
had a problem with it (except on 2.4.x).
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Sat, 2004-10-23 at 13:06, Marcelo Tosatti wrote:
> On Tue, Oct 12, 2004 at 10:10:04AM -0700, Greg KH wrote:
> > On Mon, Oct 11, 2004 at 02:22:32PM +0300, Oleksiy wrote:
> > > Hi all,
> > >
> > > I have a problem using GPRS inet vi my Siemens S55 attached with USB
> > > cable since kernel version 2.4.27-pre5, the link is established well,
> > > but then no packets get received, looking with tcpdump shows outgoing
> > > ping packets and just few per several minutes received back. I'm unable
> > > to ping, do nslookup, etc.
> > > The problem started when i switched from kernel 2.4.26 (linux slackware
> > > 10.0) to 2.4.28-pre3. None of ppp otions haven't changed and all the
> > > same options were set during kerenel config. So i decided to test all
> > > kernels between 2.4.26 and 2.4.28-pre4 (also not working). Link works
> > > well in 2.4.27-pre5 and stop working in 2.4.27-pre6. No "strange"
> > > messages or errors in the logs. firewall is disabled (ACCEPT for all).
> >
> > Can you enable CONFIG_DEBUG?
> >
> > There were no pl2303 driver changes between 2.4.27-pre5 and pre6, so I
> > don't think it's that driver...
--- linux-2.4.27-pre5/drivers/usb/serial/pl2303.c 2004-04-14 08:05:35.000000000 -0500
+++ linux-2.4.27-pre6/drivers/usb/serial/pl2303.c 2004-10-23 17:47:34.000000000 -0500
@@ -107,6 +107,7 @@ MODULE_DEVICE_TABLE (usb, id_table);
#define VENDOR_READ_REQUEST 0x01
#define UART_STATE 0x08
+#define UART_STATE_TRANSIENT_MASK 0x74
#define UART_DCD 0x01
#define UART_DSR 0x02
#define UART_BREAK_ERROR 0x04
@@ -198,6 +199,9 @@ static int pl2303_write (struct usb_seri
dbg("%s - port %d, %d bytes", __FUNCTION__, port->number, count);
+ if (!count)
+ return count;
+
if (port->write_urb->status == -EINPROGRESS) {
dbg("%s - already writing", __FUNCTION__);
return 0;
@@ -678,6 +682,7 @@ static void pl2303_read_int_callback (st
struct pl2303_private *priv = usb_get_serial_port_data(port);
unsigned char *data = urb->transfer_buffer;
unsigned long flags;
+ u8 uart_state;
dbg("%s (%d)", __FUNCTION__, port->number);
@@ -708,8 +713,10 @@ static void pl2303_read_int_callback (st
return;
/* Save off the uart status for others to look at */
+ uart_state = data[UART_STATE];
spin_lock_irqsave(&priv->lock, flags);
- priv->line_status = data[UART_STATE];
+ uart_state |= (priv->line_status & UART_STATE_TRANSIENT_MASK);
+ priv->line_status = uart_state;
spin_unlock_irqrestore(&priv->lock, flags);
wake_up_interruptible (&priv->delta_msr_wait);
@@ -767,7 +774,9 @@ static void pl2303_read_bulk_callback (s
spin_lock_irqsave(&priv->lock, flags);
status = priv->line_status;
+ priv->line_status &= ~UART_STATE_TRANSIENT_MASK;
spin_unlock_irqrestore(&priv->lock, flags);
+ wake_up_interruptible (&priv->delta_msr_wait); //AF from 2.6
/* break takes precedence over parity, */
/* which takes precedence over framing errors */
--
Paul Fulghum
[email protected]
On Tue, Oct 12, 2004 at 10:10:04AM -0700, Greg KH wrote:
> On Mon, Oct 11, 2004 at 02:22:32PM +0300, Oleksiy wrote:
> > Hi all,
> >
> > I have a problem using GPRS inet vi my Siemens S55 attached with USB
> > cable since kernel version 2.4.27-pre5, the link is established well,
> > but then no packets get received, looking with tcpdump shows outgoing
> > ping packets and just few per several minutes received back. I'm unable
> > to ping, do nslookup, etc.
> > The problem started when i switched from kernel 2.4.26 (linux slackware
> > 10.0) to 2.4.28-pre3. None of ppp otions haven't changed and all the
> > same options were set during kerenel config. So i decided to test all
> > kernels between 2.4.26 and 2.4.28-pre4 (also not working). Link works
> > well in 2.4.27-pre5 and stop working in 2.4.27-pre6. No "strange"
> > messages or errors in the logs. firewall is disabled (ACCEPT for all).
>
> Can you enable CONFIG_DEBUG?
>
> There were no pl2303 driver changes between 2.4.27-pre5 and pre6, so I
> don't think it's that driver...
Oleksy?
On Sat, 2004-10-23 at 18:00, Paul Fulghum wrote:
> On Sat, 2004-10-23 at 13:06, Marcelo Tosatti wrote:
> > On Tue, Oct 12, 2004 at 10:10:04AM -0700, Greg KH wrote:
> > > On Mon, Oct 11, 2004 at 02:22:32PM +0300, Oleksiy wrote:
> > > > Hi all,
> > > >
> > > > I have a problem using GPRS inet vi my Siemens S55 attached with USB
> > > > cable since kernel version 2.4.27-pre5, the link is established well,
> > > > but then no packets get received, looking with tcpdump shows outgoing
> > > > ping packets and just few per several minutes received back. I'm unable
> > > > to ping, do nslookup, etc.
> > > > The problem started when i switched from kernel 2.4.26 (linux slackware
> > > > 10.0) to 2.4.28-pre3. None of ppp otions haven't changed and all the
> > > > same options were set during kerenel config. So i decided to test all
> > > > kernels between 2.4.26 and 2.4.28-pre4 (also not working). Link works
> > > > well in 2.4.27-pre5 and stop working in 2.4.27-pre6. No "strange"
> > > > messages or errors in the logs. firewall is disabled (ACCEPT for all).
> > >
> > > Can you enable CONFIG_DEBUG?
> > >
> > > There were no pl2303 driver changes between 2.4.27-pre5 and pre6, so I
> > > don't think it's that driver...
>
> --- linux-2.4.27-pre5/drivers/usb/serial/pl2303.c 2004-04-14 08:05:35.000000000 -0500
> +++ linux-2.4.27-pre6/drivers/usb/serial/pl2303.c 2004-10-23 17:47:34.000000000 -0500
> @@ -107,6 +107,7 @@ MODULE_DEVICE_TABLE (usb, id_table);
> #define VENDOR_READ_REQUEST 0x01
>
> #define UART_STATE 0x08
> +#define UART_STATE_TRANSIENT_MASK 0x74
> #define UART_DCD 0x01
> #define UART_DSR 0x02
> #define UART_BREAK_ERROR 0x04
> @@ -198,6 +199,9 @@ static int pl2303_write (struct usb_seri
>
> dbg("%s - port %d, %d bytes", __FUNCTION__, port->number, count);
>
> + if (!count)
> + return count;
> +
> if (port->write_urb->status == -EINPROGRESS) {
> dbg("%s - already writing", __FUNCTION__);
> return 0;
> @@ -678,6 +682,7 @@ static void pl2303_read_int_callback (st
> struct pl2303_private *priv = usb_get_serial_port_data(port);
> unsigned char *data = urb->transfer_buffer;
> unsigned long flags;
> + u8 uart_state;
>
> dbg("%s (%d)", __FUNCTION__, port->number);
>
> @@ -708,8 +713,10 @@ static void pl2303_read_int_callback (st
> return;
>
> /* Save off the uart status for others to look at */
> + uart_state = data[UART_STATE];
> spin_lock_irqsave(&priv->lock, flags);
> - priv->line_status = data[UART_STATE];
> + uart_state |= (priv->line_status & UART_STATE_TRANSIENT_MASK);
> + priv->line_status = uart_state;
> spin_unlock_irqrestore(&priv->lock, flags);
> wake_up_interruptible (&priv->delta_msr_wait);
>
> @@ -767,7 +774,9 @@ static void pl2303_read_bulk_callback (s
>
> spin_lock_irqsave(&priv->lock, flags);
> status = priv->line_status;
> + priv->line_status &= ~UART_STATE_TRANSIENT_MASK;
> spin_unlock_irqrestore(&priv->lock, flags);
> + wake_up_interruptible (&priv->delta_msr_wait); //AF from 2.6
>
> /* break takes precedence over parity, */
> /* which takes precedence over framing errors */
This change fits the reported symptom (loss of receive data).
The change preserves line status errors
across multiple read interrupt callbacks until the error
can be applied to the contents of the next read bulk callback.
What looks wrong to me is that the line status error,
which should be associated with an individual character,
is applied to the entire contents of the next bulk read.
Wouldn't this potentially invalidate good data?
I'm not familiar with the operation of USB-serial converters,
so I don't know exactly how the flow of read interrupt and
read bulk callbacks are implemented to handle character errors.
If I was to guess, before the change, errors were lost
(overwritten by the next read interrupt callback)
so the mask was added to preserve the error.
But the error is applied to more data than it should,
causing loss of valid receive data.
Someone slap me down if I'm totally off base here.
--
Paul Fulghum
[email protected]
On Sat, 2004-10-23 at 19:14, Paul Fulghum wrote:
> This change fits the reported symptom (loss of receive data).
>
> The change preserves line status errors
> across multiple read interrupt callbacks until the error
> can be applied to the contents of the next read bulk callback.
>
> What looks wrong to me is that the line status error,
> which should be associated with an individual character,
> is applied to the entire contents of the next bulk read.
> Wouldn't this potentially invalidate good data?
>
> I'm not familiar with the operation of USB-serial converters,
> so I don't know exactly how the flow of read interrupt and
> read bulk callbacks are implemented to handle character errors.
>
> If I was to guess, before the change, errors were lost
> (overwritten by the next read interrupt callback)
> so the mask was added to preserve the error.
> But the error is applied to more data than it should,
> causing loss of valid receive data.
USB CDC 1.1 does not specify how these error indications
relate to subsequent bulk data packets. I could not find
manufacturer info that helps. BSD drivers don't do
error processing at all.
Here is a patch that applies the error only to the
next receive byte instead of all bytes in the
next read bulk packet.
Greg: Any comment?
Oleksiy: Can you try this patch?
Thanks,
Paul
--
Paul Fulghum
[email protected]
--- linux-2.4.28-pre4/drivers/usb/serial/pl2303.c 2004-08-07 18:26:05.000000000 -0500
+++ linux-2.4.28-pre4-mg/drivers/usb/serial/pl2303.c 2004-10-27 15:09:09.000000000 -0500
@@ -799,6 +799,7 @@ static void pl2303_read_bulk_callback (s
tty_flip_buffer_push(tty);
}
tty_insert_flip_char (tty, data[i], tty_flag);
+ tty_flag = TTY_NORMAL;
}
tty_flip_buffer_push (tty);
}
On Fri, 2004-10-29 at 22:49, Greg KH wrote:
> On Wed, Oct 27, 2004 at 03:16:46PM -0500, Paul Fulghum wrote:
> > Here is a patch that applies the error only to the
> > next receive byte instead of all bytes in the
> > next read bulk packet.
> >
> > Greg: Any comment?
>
> Your patch looks sane, thanks.
>
> > Oleksiy: Can you try this patch?
>
> Let us know if this works or not. If so, Paul, care to resend this for
> 2.6 also?
Sure, I'm just waiting for word from Oleksiy.
--
Paul Fulghum
[email protected]
On Wed, Oct 27, 2004 at 03:16:46PM -0500, Paul Fulghum wrote:
> On Sat, 2004-10-23 at 19:14, Paul Fulghum wrote:
> > This change fits the reported symptom (loss of receive data).
> >
> > The change preserves line status errors
> > across multiple read interrupt callbacks until the error
> > can be applied to the contents of the next read bulk callback.
> >
> > What looks wrong to me is that the line status error,
> > which should be associated with an individual character,
> > is applied to the entire contents of the next bulk read.
> > Wouldn't this potentially invalidate good data?
> >
> > I'm not familiar with the operation of USB-serial converters,
> > so I don't know exactly how the flow of read interrupt and
> > read bulk callbacks are implemented to handle character errors.
> >
> > If I was to guess, before the change, errors were lost
> > (overwritten by the next read interrupt callback)
> > so the mask was added to preserve the error.
> > But the error is applied to more data than it should,
> > causing loss of valid receive data.
>
> USB CDC 1.1 does not specify how these error indications
> relate to subsequent bulk data packets. I could not find
> manufacturer info that helps. BSD drivers don't do
> error processing at all.
>
> Here is a patch that applies the error only to the
> next receive byte instead of all bytes in the
> next read bulk packet.
>
> Greg: Any comment?
Your patch looks sane, thanks.
> Oleksiy: Can you try this patch?
Let us know if this works or not. If so, Paul, care to resend this for
2.6 also?
thanks,
greg k-h
On Sat, 2004-10-30 at 17:05, Oleksiy wrote:
> I've tried the patch, it didn't work :( The same problem...
> Also, 2.6.9 works ok ( i haven't tried other 2.6.x kernels)
OK, I'm confused.
You reported that everything works in kernel
versions up to and including 2.4.27-pre5.
It breaks with 2.4.27-pre6.
It works again with 2.6.9
The only changes to pl2303.c between
2.4.27-pre5 and 2.4.27-pre6 are also present in 2.6.9
If all of the above this is correct, then the changes
to pl2303.c have nothing to do with your problem...
and my wonderful little theory is total crap.
Greg KH suggested enabling CONFIG_DEBUG.
Did you try that and get any output?
Thanks,
Paul
--
Paul Fulghum
[email protected]