Hi,
On 6/4/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> This is probably rather related to something in input. Some CCs added and
> original message preserved below.
>
> I think that struct input_dev passed from hidinput_disconnect() should not
> be the corrupted one, as it is dereferenced sooner
This is probably rather related to something in input. Some CCs added and
original message preserved below.
I think that struct input_dev passed from hidinput_disconnect() should not
be the corrupted one, as it is dereferenced sooner on the codepath and it
doesn't go oops.
Thanks.
On Sun, 3 J
Am Montag, 12. März 2007 18:44 schrieb Dirk Schoebel:
> something new already?
Did you test the patch I sent you last week?
Regards
Oliver
-
Take Surveys. Earn Cash. Influence the Future of IT
Join So
something new already?
dirk.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn
Am Mittwoch, 7. März 2007 16:26 schrieb Dirk Schoebel:
> Mar 7 16:23:59 emerald [ cut here ]
> Mar 7 16:23:59 emerald kernel BUG at drivers/usb/serial/mos7720.c:465!
OK, it bombs because no interrupt endpoint is detected. Please send me
the output of "lsusb -v".
Mar 7 16:23:59 emerald [ cut here ]
Mar 7 16:23:59 emerald kernel BUG at drivers/usb/serial/mos7720.c:465!
Mar 7 16:23:59 emerald invalid opcode: [1] SMP
Mar 7 16:23:59 emerald CPU 0
Mar 7 16:23:59 emerald Modules linked in: mos7720 snd_rtctimer snd_seq_midi
snd_em
Am Dienstag, 6. März 2007 16:31 schrieb Dirk Schoebel:
> new trace
> (if i should activate some kernel debugging optioons just mention it)
OK, here's an alternative debugging patch.
Regards
Oliver
--- linux-2.6.21-rc3/drivers/usb/serial/mos7720.c.alt 2007-03-07 15:53:00.00
...btw...
another usb serial adapter (single port ftdi) works well, no OOPSes
so.. maybe the error is less to search within usb-serial itself but more the
interaction or the driver itself...
Dirk.
-
Take Surveys. Earn Cash.
new trace
(if i should activate some kernel debugging optioons just mention it)
Mar 6 16:28:02 emerald usbcore: registered new interface driver moschip7720
Mar 6 16:28:12 emerald Unable to handle kernel NULL pointer dereference at
0070 RIP:
Mar 6 16:28:12 emerald
[] :mos7720:mos7720
Am Dienstag, 6. März 2007 15:52 schrieb Dirk Schoebel:
> hmm, applied these patches, still crashes
Please apply the attached debugging patch.
Regards
Oliver
--- a/drivers/usb/serial/mos7720.c 2007-03-06 16:16:16.0 +0100
+++ b/drivers/usb/serial/mos7720.c 2007-03-0
Oliver Neukum wrote:
> Am Dienstag, 6. März 2007 11:33 schrieb Dirk Schoebel:
>> when trying to access /dev/ttyUSB0, which is a port on a dual port
>> usb-serial cable (mos7720 based) an kernel OOPS happens
>> the driver loads ok, first access via minicom -> OOPS
>
> Please apply:
>
ftp://ftp.ke
Am Dienstag, 6. März 2007 11:33 schrieb Dirk Schoebel:
> when trying to access /dev/ttyUSB0, which is a port on a dual port
> usb-serial cable (mos7720 based) an kernel OOPS happens
> the driver loads ok, first access via minicom -> OOPS
> (config.gz attached)
Please apply:
ftp://ftp.kernel.org/li
> > At a quick glance, I suspect the more correct fix is to make
> > the "goto out1;" after init fails be a "goto out3;" ...
> >
> > - Dave
> >
> >
>
> Nah. We shouldn't need to call unbind() if bind() fails.
True, but we SHOULD do that if a fault shows up after it succeeds...
unlikely though t
On 12/13/06, David Brownell <[EMAIL PROTECTED]> wrote:
> This cleans up some unlikely error handling paths in usbnet device probing.
>
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
>
> Index: g26/drivers/usb/net/usbnet.c
> ===
>
On 12/12/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > David, would you please look and let me know if it's something you have
> > > > under control, or is it something for me to look into.
> > > >
> > > > Synopsys: Oops when connection nokia S60 series phone
> > > > https://bugzilla.redha
On 12/12/06, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> On Tue, 12 Dec 2006 10:29:43 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> > On Tuesday 12 December 2006 9:50 am, Pete Zaitcev wrote:
>
> > > David, would you please look and let me know if it's something you have
> > > under control, or i
> > > David, would you please look and let me know if it's something you have
> > > under control, or is it something for me to look into.
> > >
> > > Synopsys: Oops when connection nokia S60 series phone
> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217488
> > >
> > > A double free
If it helps at all, this use to work with previous kernel versions, not
quite sure when it started to fail? I can try to find that out, if it
helps.
I don't really know if it really works under linux, I'm running Wincrap
XP Prof under vmware hosted by FC5, and this USB device worked just find
in
On Tue, 12 Dec 2006 10:29:43 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 12 December 2006 9:50 am, Pete Zaitcev wrote:
> > David, would you please look and let me know if it's something you have
> > under control, or is it something for me to look into.
> >
> > Synopsys: Oops wh
On Tuesday 12 December 2006 9:50 am, Pete Zaitcev wrote:
> David, would you please look and let me know if it's something you have
> under control, or is it something for me to look into.
>
> Synopsys: Oops when connection nokia S60 series phone
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi
> > > Apparently, there's a window when OHCI is shut down, when we shut the
> > > controller down and freed hcca, but did not release the IRQ. On a shared
> > > IRQ, some other device interrupts, and we oops referring to hcca.
> > >
> > > The attached patch looks like a ham-fisted way to fix this .
On Thu, 07 Sep 2006 23:49:48 -0700, David Brownell <[EMAIL PROTECTED]> wrote:
> > Apparently, there's a window when OHCI is shut down, when we shut the
> > controller down and freed hcca, but did not release the IRQ. On a shared
> > IRQ, some other device interrupts, and we oops referring to hcca.
> Apparently, there's a window when OHCI is shut down, when we shut the
> controller down and freed hcca, but did not release the IRQ. On a shared
> IRQ, some other device interrupts, and we oops referring to hcca.
>
> The attached patch looks like a ham-fisted way to fix this ...
Indeed. Did you
On Fri, 23 Jun 2006 21:57:57 +0200 (CEST)
Guennadi Liakhovetski <[EMAIL PROTECTED]> wrote:
| On Fri, 23 Jun 2006, Luiz Fernando N. Capitulino wrote:
|
| > Actually, I'm afraid the switch will not happen anymore [1]. :(
|
| Well, there's a problem, but there should be a solution too, so, I don't
On Sat, 2006-06-24 at 13:13 +0200, Guennadi Liakhovetski wrote:
> Without my patch this is the first call to set_termios in pl2303 and the
> termios struct is overwritten with defaults (anybody has an idea why?) and
> the baudrate is set to 9600. AFAIU set_termios is called normally from
> ->ope
On Fri, 23 Jun 2006, Paul Fulghum wrote:
> On Fri, 2006-06-23 at 19:02 -0700, Greg KH wrote:
> > That's all you have done here. Just moved the init to open, but this
> > didn't change the logic at all as:
> >
> > > pl2303_set_termios (port, &tmp_termios);
> >
> > You then still call p
On Fri, 2006-06-23 at 19:02 -0700, Greg KH wrote:
> That's all you have done here. Just moved the init to open, but this
> didn't change the logic at all as:
>
> > pl2303_set_termios (port, &tmp_termios);
>
> You then still call pl2303_set_termios(). How did this fix anything?
It i
On Fri, Jun 23, 2006 at 11:12:35PM +0200, Guennadi Liakhovetski wrote:
> > As for the initial console rate mismatch on pl2303:
> >
> > pl2303_set_termios requires a private initialization flag
> > to be set (priv->termios_initialized) or it will
> > default to 9600 N81 instead of using the termios
Guennadi Liakhovetski wrote:
> The patch we are talking about is not pretty, and I am not sure it is
> correct. But if you think it is I would appreciate your "Acked-by" under
> it:-)
The module locking may not be a big deal (if the driver
is used as a console then it is in kernel anyways?), but
On Fri, 23 Jun 2006, Paul Fulghum wrote:
> Your patch is necessary to be correct because
> it locks the module on the first normal open.
> (even if pl2303 can run without it)
>
> I believe the original problem was that the lines
>
>tty->driver_data = port;
>port->tty = tty;
>
> were ori
On Fri, 23 Jun 2006, Luiz Fernando N. Capitulino wrote:
> Actually, I'm afraid the switch will not happen anymore [1]. :(
Well, there's a problem, but there should be a solution too, so, I don't
think it's a final verdict yet. I think, it's just a matter of finding a
proper solution to it.
>
> On Thu, 22 Jun 2006 22:50:23 +0200 (CEST)
> Guennadi Liakhovetski <[EMAIL PROTECTED]> wrote:
>
> | On Tue, 9 May 2006, Guennadi Liakhovetski wrote:
> |
> | > On Mon, 8 May 2006, Guennadi Liakhovetski wrote:
> | >
> | > > Yes. I put a WARN_ON(1) next to ++open_count in both files and I still
>
Hi Guennadi,
On Thu, 22 Jun 2006 22:50:23 +0200 (CEST)
Guennadi Liakhovetski <[EMAIL PROTECTED]> wrote:
| On Tue, 9 May 2006, Guennadi Liakhovetski wrote:
|
| > On Mon, 8 May 2006, Guennadi Liakhovetski wrote:
| >
| > > Yes. I put a WARN_ON(1) next to ++open_count in both files and I still
s
On Tue, 9 May 2006, Guennadi Liakhovetski wrote:
> On Mon, 8 May 2006, Guennadi Liakhovetski wrote:
>
> > Yes. I put a WARN_ON(1) next to ++open_count in both files and I still see
> > it every time I log in and out.
>
> Below is my current version of the patch. No idea in how far it is
> gene
On Thu, 11 May 2006, Sean Bruno wrote:
> Kind of interesting behaviour in the 'dummy_hcd' device under
> 2.6.16.4 ... If I load, then unload the g_file_storage module, I get
> either a lock-up or an Oops on my i386 box.
>
> I executed 'modprobe dummy_hcd', 'modprobe g_file_storage
> file=/var/t
On Mon, 8 May 2006, Guennadi Liakhovetski wrote:
> Yes. I put a WARN_ON(1) next to ++open_count in both files and I still see
> it every time I log in and out.
Below is my current version of the patch. No idea in how far it is
generically acceptable... Works for me.
Guennadi
---
Guennadi Liakh
On Mon, 8 May 2006, Paul Fulghum wrote:
> Guennadi Liakhovetski wrote:
> > > Now that usb_console does not increase open_count,
> > > what happens if open_count goes to zero after
> > > being used by getty? Is the hardware shutdown
> > > such that no more console output is accepted?
> >
> > You m
Guennadi Liakhovetski wrote:
Now that usb_console does not increase open_count,
what happens if open_count goes to zero after
being used by getty? Is the hardware shutdown
such that no more console output is accepted?
You mean what happens if I log out? Nothing bad - I can login again.
More p
On Mon, 8 May 2006, Paul Fulghum wrote:
> Guennadi Liakhovetski wrote:
> > Re-opening the old thread - I did manage to get both console output and a
> > working terminal. I removed open_count++ from usb_console_setup() and made
> > the following code, calling serial->type->open() unconditional. Th
Guennadi Liakhovetski wrote:
Re-opening the old thread - I did manage to get both console output and a
working terminal. I removed open_count++ from usb_console_setup() and made
the following code, calling serial->type->open() unconditional. This sort
of assumes, that console_setup is called on
On Sat, 22 Apr 2006, Guennadi Liakhovetski wrote:
> On Sat, 22 Apr 2006, Paul Fulghum wrote:
>
> > Guennadi Liakhovetski wrote:
> > > Emn, Paul, correct me if I am wrong. The only (regular) place I found
> > > where
> > > console->setup() is called is in kernel/printk.c in register_console()...
On Mon, 24 Apr 2006, Greg KH wrote:
> On Fri, Apr 14, 2006 at 01:10:45PM +0200, Guennadi Liakhovetski wrote:
> > On Thu, 13 Apr 2006, Paul Fulghum wrote:
> >
> > > Guennadi Liakhovetski wrote:
> > > > Well, looked through the code again - I think, you are right. An updated
> > > > version below.
On Fri, Apr 14, 2006 at 01:10:45PM +0200, Guennadi Liakhovetski wrote:
> On Thu, 13 Apr 2006, Paul Fulghum wrote:
>
> > Guennadi Liakhovetski wrote:
> > > Well, looked through the code again - I think, you are right. An updated
> > > version below. I just used your initial (slightly modified to my
On Sat, 22 Apr 2006, Paul Fulghum wrote:
> Guennadi Liakhovetski wrote:
> > Emn, Paul, correct me if I am wrong. The only (regular) place I found where
> > console->setup() is called is in kernel/printk.c in register_console()...
>
> Yes
So, it doesn't make sense to change it there - register_co
Guennadi Liakhovetski wrote:
Emn, Paul, correct me if I am wrong. The only (regular) place I found
where console->setup() is called is in kernel/printk.c in
register_console()...
Yes
Anyway, I did check it (I just changed the if() that
follows to if(1), because without ++open_count the test
On Sat, 22 Apr 2006, Paul Fulghum wrote:
> What I was looking for is to execute the ftdi_open (with
> the actual tty struct) when getty opens the device.
Emn, Paul, correct me if I am wrong. The only (regular) place I found
where console->setup() is called is in kernel/printk.c in
register_cons
On Sat, 2006-04-22 at 18:05 +0200, Guennadi Liakhovetski wrote:
> On Sat, 22 Apr 2006, Paul Fulghum wrote:
>
> > As you say, back to looking at the code...
> >
> > Just as a quick hack/test, what happens if you don't
> > increment port->open_count in console.c:usb_console_setup() ?
>
> Hm, what
On Sat, 22 Apr 2006, Paul Fulghum wrote:
> As you say, back to looking at the code...
>
> Just as a quick hack/test, what happens if you don't
> increment port->open_count in console.c:usb_console_setup() ?
Hm, what I see here (without the proposed modification) is that getty is
started, the pr
On Sat, 2006-04-22 at 12:14 +0200, Guennadi Liakhovetski wrote:
> Do you mean something like the patch below? If yes, then it doesn't
> help:-( Any idea why?.. I'll try to have a better look too...
That is what I meant, but I was wrong.
My suggestion was pointless as port->tty should
always be N
On Tue, 18 Apr 2006, Paul Fulghum wrote:
> I think setting tty to NULL is just a reflection
> of the code assuming that the console open happens
> only at system startup, before the usb serial port
> is opened for other reasons.
>
> usb_console_setup() should be changed to use the
> current tty v
On Fri, 2006-04-14 at 17:48 +0200, Guennadi Liakhovetski wrote:
> Heh, so it happened:-) I did see that input didn't work, and thought if I
> should try to think about it, but then I decided, since somebody disabled
> it, maybe there was a reason for it, and since I don't need it...
>
> Well, I
On 4/14/06, Guennadi Liakhovetski <[EMAIL PROTECTED]> wrote:
> (your chances for a quick reply were higher if you used reply-to-all)
>
> Heh, so it happened:-) I did see that input didn't work, and thought if I
> should try to think about it, but then I decided, since somebody disabled
> it, maybe
(your chances for a quick reply were higher if you used reply-to-all)
On Fri, 14 Apr 2006, Gyorgy Szekely wrote:
> hi,
> i began to use the usb serial console for debugging purposes recenty,
> and ran into the same problems as Guennadi. I followed the thread on
> this list, and applied/tested the
hi,
i began to use the usb serial console for debugging purposes recenty,
and ran into the same problems as Guennadi. I followed the thread on
this list, and applied/tested the patches. Most things work fine now
(thanks to you), but i still have a few questions.
Until now we used the first serial p
On Thu, 13 Apr 2006, Paul Fulghum wrote:
> Guennadi Liakhovetski wrote:
> > Well, looked through the code again - I think, you are right. An updated
> > version below. I just used your initial (slightly modified to my tastes:-))
> > approach - calling usb_serial_console_exit() from
> > usb_serial_
Guennadi Liakhovetski wrote:
Well, looked through the code again - I think, you are right. An updated
version below. I just used your initial (slightly modified to my
tastes:-)) approach - calling usb_serial_console_exit() from
usb_serial_console_disconnect().
Looks good to me. Have you teste
On Thu, 13 Apr 2006, Paul Fulghum wrote:
> On Thu, 2006-04-13 at 22:25 +0200, Guennadi Liakhovetski wrote:
> > +void usb_serial_console_disconnect(struct usb_serial *serial)
> > +{
> > + if (serial && serial->port && serial->port[0] && serial->port[0] ==
> > usbcons_info.port) {
> > +
On Thu, 2006-04-13 at 22:25 +0200, Guennadi Liakhovetski wrote:
> +void usb_serial_console_disconnect(struct usb_serial *serial)
> +{
> + if (serial && serial->port && serial->port[0] && serial->port[0] ==
> usbcons_info.port) {
> + usbcons_info.port->open_count--;
> +
Patch #4/4.
(Now let's see how much I've messed up...)
Thanks
Guennadi
---
Guennadi Liakhovetski
Prevent ENODEV on a /dev/ttyUSBx, used as a USB-serial console.
Original author: Paul Fulghum <[EMAIL PROTECTED]>
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
diff -u a/drivers/usb/seri
Patch #3/4.
Thanks
Guennadi
---
Guennadi Liakhovetski
Prevent NULL dereference when used as a USB-serial console.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
diff -u a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
--- a/drivers/usb/serial/ftdi_sio.c 30 Mar 2006
Patch #2/4.
Thanks
Guennadi
---
Guennadi Liakhovetski
Append Carriage-Returns after Line-Feeds, analogous to the serial driver.
Original author: Paul Fulghum <[EMAIL PROTECTED]>
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
diff -u a/drivers/usb/serial/console.c b/drivers/usb/serial/
On Wed, 12 Apr 2006, Greg KH wrote:
> So, care to break the patches out into different parts so I can apply
> them?
Ok, below is #1. #2, 3, and 4 will follow.
Tnanks
Guennadi
---
Guennadi Liakhovetski
Prevent sending further output to a USB-serial console after the dongle is
disconnected.
Sign
On Wed, 12 Apr 2006 15:14:54 -0700 Greg KH wrote:
> On Thu, Apr 13, 2006 at 12:06:55AM +0200, Guennadi Liakhovetski wrote:
> > This is the uncertain part. It also addresses several problems, so, could
> > also be further splitted, but this is just a draft anyway... I am not even
> > signing-off
On Wed, Apr 12, 2006 at 07:08:17PM -0500, Paul Fulghum wrote:
> On Wed, 2006-04-12 at 16:59 -0700, Greg KH wrote:
> > 2.6.17-rc1 doesn't have a serial8250_console_write() that looks for LF
> > characters and replace them like I think your patch did...
>
> For 2.6.16-rc1, that logic moved to driver
On Wed, 2006-04-12 at 16:59 -0700, Greg KH wrote:
> 2.6.17-rc1 doesn't have a serial8250_console_write() that looks for LF
> characters and replace them like I think your patch did...
For 2.6.16-rc1, that logic moved to drivers/serial/serial_core.c
in the function uart_console_write().
--
Paul
On Wed, 2006-04-12 at 16:59 -0700, Greg KH wrote:
> 2.6.17-rc1 doesn't have a serial8250_console_write() that looks for LF
> characters and replace them like I think your patch did...
I've been working against 2.6.16
I'll take a look at 2.6.17-rc1 and see what changed.
--
Paul
---
On Thu, 2006-04-13 at 00:37 +0200, Guennadi Liakhovetski wrote:
> On Wed, 12 Apr 2006, Greg KH wrote:
>
> > > Problem 3. Recursive error-messages on dongle-unplug, which render the
> > > system unusable. Here again, the proper solution would be to implement
> > > some usb_serial_console_disconne
On Wed, Apr 12, 2006 at 06:41:16PM -0500, Paul Fulghum wrote:
> On Wed, 2006-04-12 at 16:33 -0700, Greg KH wrote:
> > On Wed, Apr 12, 2006 at 06:19:59PM -0500, Paul Fulghum wrote:
> > > Greg KH wrote:
> > > >Does the serial console driver have this logic in it?
> > >
> > > Yes, that is where I too
On Wed, 2006-04-12 at 16:33 -0700, Greg KH wrote:
> On Wed, Apr 12, 2006 at 06:19:59PM -0500, Paul Fulghum wrote:
> > Greg KH wrote:
> > >Does the serial console driver have this logic in it?
> >
> > Yes, that is where I took it from.
> > drivers/serial/8250.c
>
> Ok, I must be blind, but what fu
On Wed, Apr 12, 2006 at 06:19:59PM -0500, Paul Fulghum wrote:
> Greg KH wrote:
> >Does the serial console driver have this logic in it?
>
> Yes, that is where I took it from.
> drivers/serial/8250.c
Ok, I must be blind, but what function in that file does this?
thanks,
greg k-h
--
Greg KH wrote:
Does the serial console driver have this logic in it?
Yes, that is where I took it from.
drivers/serial/8250.c
--
Paul
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications
On Thu, Apr 13, 2006 at 12:37:07AM +0200, Guennadi Liakhovetski wrote:
> On Wed, 12 Apr 2006, Greg KH wrote:
>
> > On Thu, Apr 13, 2006 at 12:06:55AM +0200, Guennadi Liakhovetski wrote:
> > > Problem 2. Missing carriage-returns on line-feeds in
> > > /drivers/usb/serial/console.c, this fix is com
On Wed, 12 Apr 2006, Greg KH wrote:
> On Thu, Apr 13, 2006 at 12:06:55AM +0200, Guennadi Liakhovetski wrote:
> > Problem 2. Missing carriage-returns on line-feeds in
> > /drivers/usb/serial/console.c, this fix is completely from Paul.
>
> I don't see why this is needed. The driver should not be
On Thu, Apr 13, 2006 at 12:06:55AM +0200, Guennadi Liakhovetski wrote:
> This is the uncertain part. It also addresses several problems, so, could
> also be further splitted, but this is just a draft anyway... I am not even
> signing-off for it.
>
> Problem 1. Oops with ftdi_sio and "console=tty
This is the uncertain part. It also addresses several problems, so, could
also be further splitted, but this is just a draft anyway... I am not even
signing-off for it.
Problem 1. Oops with ftdi_sio and "console=ttyUSB0." This is caused by 2
NULL-pointer dereferences - port->tty in ftdi_open()
Hi
I splitted this one out as it is small, simple, and pretty much obviously
correct. To remind - it prevents an Oops if booted with "console=ttyUSB0"
but without a USB-serial dongle, and plugged one in afterwards. Originally
from Paul. (Paul, would you like to sign-off for it?)
It might even
On Tue, 11 Apr 2006, Paul Fulghum wrote:
> Guennadi Liakhovetski wrote:
> > Ok, I found it. It's the ->write() call from usb_console_write() - obvious,
> > isn't it. So, now it works without a single attempt to bring out a message
> > on a disconnected console. At the bottom my current version. Ce
Guennadi Liakhovetski wrote:
Ok, I found it. It's the ->write() call from usb_console_write() -
obvious, isn't it. So, now it works without a single attempt to bring out
a message on a disconnected console. At the bottom my current version.
Certainly, it is not final, but, I think, we may use i
Ok, I found it. It's the ->write() call from usb_console_write() -
obvious, isn't it. So, now it works without a single attempt to bring out
a message on a disconnected console. At the bottom my current version.
Certainly, it is not final, but, I think, we may use it as a starting
point. It con
On Mon, 10 Apr 2006, Paul Fulghum wrote:
> Try this all-in-one patch.
>
> Included:
> * usb serial_open fix (fix ENODEV)
> * usb_console_write fix (fix CR after LF)
> * ftdi patch (fix oops on tty struct == NULL)
> * ftdi uninitialized tmp_termios fix
> * remove __init from usb_console_setup (oop
Try this all-in-one patch.
Included:
* usb serial_open fix (fix ENODEV)
* usb_console_write fix (fix CR after LF)
* ftdi patch (fix oops on tty struct == NULL)
* ftdi uninitialized tmp_termios fix
* remove __init from usb_console_setup (oops on late device install)
* add usb_serial_console_disconn
On Sun, 2006-04-09 at 23:31 +0200, Guennadi Liakhovetski wrote:
> Good guess. It hangs then.
I can't see what would cause
a lock if calling ftdi_set_termios() twice.
My guess is calling it twice is creating
some interrupt or status event that ends
up trying to operate on the dummy tty.
Using your
On Sat, 8 Apr 2006, Paul Fulghum wrote:
> On Sat, 2006-04-08 at 23:16 +0200, Guennadi Liakhovetski wrote:
> > On Sat, 8 Apr 2006, Paul Fulghum wrote:
> > > OK, this one backs out my usb_console_setup change
> > > that uses the temp tty structure for the device specific open.
> > >
> > > Included
On Sat, 2006-04-08 at 23:16 +0200, Guennadi Liakhovetski wrote:
> On Sat, 8 Apr 2006, Paul Fulghum wrote:
> > OK, this one backs out my usb_console_setup change
> > that uses the temp tty structure for the device specific open.
> >
> > Included is:
> > * improved usb serial_open fix (fix ENODEV)
>
On Sat, 8 Apr 2006, Paul Fulghum wrote:
> On Sat, 2006-04-08 at 21:34 +0200, Guennadi Liakhovetski wrote:
> > On Fri, 7 Apr 2006, Paul Fulghum wrote:
> > It hung exactly as with the previous big one. Don't think it is important,
> > I am testing it on a SMP.
>
> OK, this one backs out my usb_con
On Sat, 8 Apr 2006, Paul Fulghum wrote:
> On Sat, 2006-04-08 at 21:34 +0200, Guennadi Liakhovetski wrote:
> > On Fri, 7 Apr 2006, Paul Fulghum wrote:
> > It hung exactly as with the previous big one. Don't think it is important,
> > I am testing it on a SMP.
>
> OK, this one backs out my usb_con
On Sat, 2006-04-08 at 21:34 +0200, Guennadi Liakhovetski wrote:
> On Fri, 7 Apr 2006, Paul Fulghum wrote:
> It hung exactly as with the previous big one. Don't think it is important,
> I am testing it on a SMP.
OK, this one backs out my usb_console_setup change
that uses the temp tty structure fo
Guennadi Liakhovetski wrote:
Secondly, the kernel hung after:
drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB
Serial Device
ftdi_sio 4-2:1.0: FTDI USB Serial Device converter detected
drivers/usb/serial/ftdi_sio.c: Detected FT232BM
usb 4-2: FTDI USB Serial Device con
On Fri, 7 Apr 2006, Paul Fulghum wrote:
> On Fri, 2006-04-07 at 22:10 +0200, Guennadi Liakhovetski wrote:
> > Yep, that would work, I first didn't look at that code too attentively as
> > I didn't want to do any such "intrusive" changes. Would you then remove
> > the call to serial->type->set_te
On Fri, 2006-04-07 at 22:10 +0200, Guennadi Liakhovetski wrote:
> Yep, that would work, I first didn't look at that code too attentively as
> I didn't want to do any such "intrusive" changes. Would you then remove
> the call to serial->type->set_termios(port, NULL);? Do all usb-serial
> drivers
On Fri, 7 Apr 2006, Paul Fulghum wrote:
> Guennadi Liakhovetski wrote:
> > Yep, the patch helps against both bugs! Thanks! Are you going to submit it
> > to the mainline?
>
> I would like to refine it a bit if you
> are willing to try another patch.
> The first patch was a brute force test,
> and
Guennadi Liakhovetski wrote:
Yep, the patch helps against both bugs! Thanks! Are you going to submit it
to the mainline?
I would like to refine it a bit if you
are willing to try another patch.
The first patch was a brute force test,
and I don't have the equipment to test is myself.
usb_consol
On Fri, 7 Apr 2006, Paul Fulghum wrote:
> On Thu, 2006-04-06 at 23:48 +0200, Guennadi Liakhovetski wrote:
> > The patch below fixes the Oops, and gets some output with
> > "console=ttyUSB0". But it is not perfect - newlines are not accompanied by
> > carriage returns, and funnily, although in dm
On Thu, 2006-04-06 at 23:48 +0200, Guennadi Liakhovetski wrote:
> The patch below fixes the Oops, and gets some output with
> "console=ttyUSB0". But it is not perfect - newlines are not accompanied by
> carriage returns, and funnily, although in dmesg it says:
>
> usb 4-2: FTDI USB Serial Device
On Sun, 19 Mar 2006, Guennadi Liakhovetski wrote:
> Booted 2.6.15.6 on a powerpc embedded board with "console=ttyUSB0,38400"
> and got the following Oops:
>
> usbcore: registered new driver usbserial_generic
> drivers/usb/serial/usb-serial.c: USB Serial Driver core
> drivers/usb/serial/usb-seria
Hi Sergey,
>...
>> Looks like a problem which was fixed in 2.6.16.1:
>
> http://kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commitdiff;h=048eb7e760ef41bcfef09bbd223f18379d260c2c
>
> (and you are apparently looking at the source where this bug is already
> fixed).
it looks li
On Thu, Mar 30, 2006 at 01:37:35AM +0200, Duncan Sands wrote:
> Hi Pete,
> > This looks like something may be of interest for you. In the fresh kernel
> > we shipped (2.6.15 with no relevant patches), modem cannot get its firmware,
> > and eventually ends with this:
> >
> > EIP is at firmware_data
Hi Pete,
> This looks like something may be of interest for you. In the fresh kernel
> we shipped (2.6.15 with no relevant patches), modem cannot get its firmware,
> and eventually ends with this:
>
> EIP is at firmware_data_write+0xfe/0x152
> Process nash-hotplug (pid: 307, threadinfo=c1678000 t
On Wed, 15 Mar 2006, Marc Singer wrote:
> On Wed, Mar 15, 2006 at 05:47:05PM -0500, Alan Stern wrote:
> > I don't know why g_ether would have a configuration with no interfaces.
> > A good question to ask the maintainer. Dave?
>
> I found out what the problem is. The ether.c file has explicit
On Wed, 15 Mar 2006, Marc Singer wrote:
> On Wed, Mar 15, 2006 at 05:47:05PM -0500, Alan Stern wrote:
> > On Wed, 15 Mar 2006, Marc Singer wrote:
> >
> > > > > Isn't that the responsibility of the gadget itself and not the UDC?
> > > >
> > > > Yes, it is. What gadget driver were you using for y
1 - 100 of 316 matches
Mail list logo
