2007/6/28, Jiri Kosina <[EMAIL PROTECTED]>:
On Thu, 28 Jun 2007, Antonino Ingargiola wrote:
> $ cat /sys/bus/usb/devices/1-1.2/idVendor
> 046d
> $ cat /sys/bus/usb/devices/1-1.2/idProduct
> c311
Please try the patch below (against any post-2.6.22-rc1 kernel)
Tried o
2007/6/27, Jiri Kosina <[EMAIL PROTECTED]>:
On Wed, 27 Jun 2007, Antonino Ingargiola wrote:
> I'm using a logitech USB keyboard, I think it's one of the most cheap
> and diffuse logitech keyboard models.
> I have an inconsistent led state. During boot the NumLock led blinks
2007/6/27, Jiri Kosina [EMAIL PROTECTED]:
On Wed, 27 Jun 2007, Antonino Ingargiola wrote:
I'm using a logitech USB keyboard, I think it's one of the most cheap
and diffuse logitech keyboard models.
I have an inconsistent led state. During boot the NumLock led blinks
several times
2007/6/28, Jiri Kosina [EMAIL PROTECTED]:
On Thu, 28 Jun 2007, Antonino Ingargiola wrote:
$ cat /sys/bus/usb/devices/1-1.2/idVendor
046d
$ cat /sys/bus/usb/devices/1-1.2/idProduct
c311
Please try the patch below (against any post-2.6.22-rc1 kernel)
Tried on 2.6.22-rc6-cfs18 and it works
Dear Kernel Developers,
I'm using a logitech USB keyboard, I think it's one of the most cheap
and diffuse logitech keyboard models.
I have an inconsistent led state. During boot the NumLock led blinks
several times and is on as boot finishes. However the numeric keypad
works as it was off (no
Dear Kernel Developers,
I'm using a logitech USB keyboard, I think it's one of the most cheap
and diffuse logitech keyboard models.
I have an inconsistent led state. During boot the NumLock led blinks
several times and is on as boot finishes. However the numeric keypad
works as it was off (no
2007/6/24, Ingo Molnar <[EMAIL PROTECTED]>:
* Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
> Anyway, I've discovered with great pleasure that CFS has also the
> SCHED_ISO priority. I may have missed something, but I don't remember
> to have read this in any of
2007/6/24, Ingo Molnar [EMAIL PROTECTED]:
* Antonino Ingargiola [EMAIL PROTECTED] wrote:
Anyway, I've discovered with great pleasure that CFS has also the
SCHED_ISO priority. I may have missed something, but I don't remember
to have read this in any of the CFS release notes :). For me
2007/6/23, Ingo Molnar <[EMAIL PROTECTED]>:
* Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
> 2007/6/23, Ingo Molnar <[EMAIL PROTECTED]>:
> >
> >i'm pleased to announce release -v18 of the CFS scheduler patchset.
>
> I'm running -v18 on 2.6.22-rc
2007/6/23, Ingo Molnar [EMAIL PROTECTED]:
* Antonino Ingargiola [EMAIL PROTECTED] wrote:
2007/6/23, Ingo Molnar [EMAIL PROTECTED]:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
I'm running -v18 on 2.6.22-rc5, no problems so far. How can I change a
task
Hi,
2007/6/23, Ingo Molnar <[EMAIL PROTECTED]>:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
I'm running -v18 on 2.6.22-rc5, no problems so far. How can I change a
task to SCHED_IDLE or SCHED_BATCH priority under CFS?
Thanks,
~ Antonio
-
To unsubscribe from this
Hi,
2007/6/23, Ingo Molnar [EMAIL PROTECTED]:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
I'm running -v18 on 2.6.22-rc5, no problems so far. How can I change a
task to SCHED_IDLE or SCHED_BATCH priority under CFS?
Thanks,
~ Antonio
-
To unsubscribe from this
2007/5/29, Antonino Ingargiola <[EMAIL PROTECTED]>:
[cut]
Swap Prefetch OFF
# ./sp_tester
Ram 776388000 Swap 51404
Total ram to be malloced: 1033408000 bytes
Starting first malloc of 516704000 bytes
Starting 1st read of first malloc
Touching this much ram takes 1642 milliseconds
St
Hi,
2007/5/27, Con Kolivas <[EMAIL PROTECTED]>:
New test release:
http://ck.kolivas.org/patches/pre-releases/2.6.22-rc3/2.6.22-rc3-ck1/
This is a resync with newer -rc and contains the updated swap prefetch code.
With this patch there is a stunning difference with the no swap
prefetch case
Hi,
2007/5/27, Con Kolivas [EMAIL PROTECTED]:
New test release:
http://ck.kolivas.org/patches/pre-releases/2.6.22-rc3/2.6.22-rc3-ck1/
This is a resync with newer -rc and contains the updated swap prefetch code.
With this patch there is a stunning difference with the no swap
prefetch case on
2007/5/29, Antonino Ingargiola [EMAIL PROTECTED]:
[cut]
Swap Prefetch OFF
# ./sp_tester
Ram 776388000 Swap 51404
Total ram to be malloced: 1033408000 bytes
Starting first malloc of 516704000 bytes
Starting 1st read of first malloc
Touching this much ram takes 1642 milliseconds
Starting
Hi,
2007/5/23, Romano Giannetti <[EMAIL PROTECTED]>:
[cut]
Uf, I will try to find the time. I am on my way to try to compile
2.6.21.2 now. Problem is that a kernel compile "the ubuntu way" last
hours here. If there is an expert on make-kpkg here, I could use some
advise. I'd prefer to test
Hi,
2007/5/23, Romano Giannetti [EMAIL PROTECTED]:
[cut]
Uf, I will try to find the time. I am on my way to try to compile
2.6.21.2 now. Problem is that a kernel compile the ubuntu way last
hours here. If there is an expert on make-kpkg here, I could use some
advise. I'd prefer to test patches
2007/5/21, Ingo Molnar <[EMAIL PROTECTED]>:
* Con Kolivas <[EMAIL PROTECTED]> wrote:
> > A suggestion for improvement: right now swap-prefetch does a small
> > bit of swapin every 5 seconds and stays idle inbetween. Could this
> > perhaps be made more agressive (optionally perhaps), if the
2007/5/21, Ingo Molnar [EMAIL PROTECTED]:
* Con Kolivas [EMAIL PROTECTED] wrote:
A suggestion for improvement: right now swap-prefetch does a small
bit of swapin every 5 seconds and stays idle inbetween. Could this
perhaps be made more agressive (optionally perhaps), if the system
is
Hi Jean,
2007/5/14, Jean Delvare <[EMAIL PROTECTED]>:
[cut]
> I've not found an obvious way to set it in sensors.conf. Could you
> point me to some doumentation, thanks.
sensors.conf supposedly _is_ the the documentation ;)
Search for the following line in /etc/sensors.conf:
chip "via686a-*"
Hi Jean!
2007/5/14, Jean Delvare <[EMAIL PROTECTED]>:
> Sure. On 2.6.21.1:
>
> via686a-isa-6000
> Adapter: ISA adapter
> CPU core: +1.63 V (min = +0.06 V, max = +3.10 V)
> +2.5V: +2.45 V (min = +0.06 V, max = +3.10 V)
> I/O: +3.52 V (min = +3.12 V, max = +3.45 V) ALARM
>
Hi Jean,
2007/5/14, Jean Delvare <[EMAIL PROTECTED]>:
[cut]
This is a rather bad idea to build the abituguru and hdaps drivers into
your kernel if you don't have these devices. Especially abituguru, as
it does arbitrary port probing.
My bad. I have an abit motherboard and in doubt I selected
2007/5/14, Jean Delvare <[EMAIL PROTECTED]>:
[cut]
I am not familiar with the gnome sensors applet. Does it say where it
is getting the data (driver name, device name...)?
The applet settings show a list of sensors under the libsensors name.
Those are the sensors that work on 2.6.21.1.
2007/5/14, Jean Delvare [EMAIL PROTECTED]:
[cut]
I am not familiar with the gnome sensors applet. Does it say where it
is getting the data (driver name, device name...)?
The applet settings show a list of sensors under the libsensors name.
Those are the sensors that work on 2.6.21.1.
However
Hi Jean,
2007/5/14, Jean Delvare [EMAIL PROTECTED]:
[cut]
This is a rather bad idea to build the abituguru and hdaps drivers into
your kernel if you don't have these devices. Especially abituguru, as
it does arbitrary port probing.
My bad. I have an abit motherboard and in doubt I selected
Hi Jean!
2007/5/14, Jean Delvare [EMAIL PROTECTED]:
Sure. On 2.6.21.1:
via686a-isa-6000
Adapter: ISA adapter
CPU core: +1.63 V (min = +0.06 V, max = +3.10 V)
+2.5V: +2.45 V (min = +0.06 V, max = +3.10 V)
I/O: +3.52 V (min = +3.12 V, max = +3.45 V) ALARM
+5V:
Hi Jean,
2007/5/14, Jean Delvare [EMAIL PROTECTED]:
[cut]
I've not found an obvious way to set it in sensors.conf. Could you
point me to some doumentation, thanks.
sensors.conf supposedly _is_ the the documentation ;)
Search for the following line in /etc/sensors.conf:
chip via686a-*
Hi,
2007/5/13, Linus Torvalds <[EMAIL PROTECTED]>:
On Sun, 13 May 2007, Antonino Ingargiola wrote:
>
> On my desktop pc with Debian Etch and 2.6.22-rc1 the gnome panel
> applet "Sensors Applet" give an error message "No chip detected".
> Works fin
2007/5/13, Linus Torvalds <[EMAIL PROTECTED]>:
Ok, the merge window has closed, and 2.6.22-rc1 is out there.
[cut]
So give it a good testing. We'll see how the regression tracking ends up
working, but in order to actually track that, we want people actively
testing -rc1 and making good
2007/5/13, Linus Torvalds [EMAIL PROTECTED]:
Ok, the merge window has closed, and 2.6.22-rc1 is out there.
[cut]
So give it a good testing. We'll see how the regression tracking ends up
working, but in order to actually track that, we want people actively
testing -rc1 and making good
Hi,
2007/5/13, Linus Torvalds [EMAIL PROTECTED]:
On Sun, 13 May 2007, Antonino Ingargiola wrote:
On my desktop pc with Debian Etch and 2.6.22-rc1 the gnome panel
applet Sensors Applet give an error message No chip detected.
Works fine on 2.6.21.1 (it show cpu temperature) with the same
2007/5/6, Antonino Ingargiola <[EMAIL PROTECTED]>:
2007/5/5, Oliver Neukum <[EMAIL PROTECTED]>:
> Am Samstag, 5. Mai 2007 20:08 schrieb Antonino Ingargiola:
> > Now I don't want to abuse your kindness, but I (personally) would be
> > *really* interested in a similar
2007/5/6, Antonino Ingargiola [EMAIL PROTECTED]:
2007/5/5, Oliver Neukum [EMAIL PROTECTED]:
Am Samstag, 5. Mai 2007 20:08 schrieb Antonino Ingargiola:
Now I don't want to abuse your kindness, but I (personally) would be
*really* interested in a similar fix for the FTDI usb-serial driver
2007/5/6, Alan Stern <[EMAIL PROTECTED]>:
On Sun, 6 May 2007, Alan Cox wrote:
> > However, whatever policy the buffer uses, the fundamental point it's that
> > when I flush the input buffer I should be sure that each byte read
> > after the flush is *new* (current) data and not old one. This
2007/5/6, Alan Stern [EMAIL PROTECTED]:
On Sun, 6 May 2007, Alan Cox wrote:
However, whatever policy the buffer uses, the fundamental point it's that
when I flush the input buffer I should be sure that each byte read
after the flush is *new* (current) data and not old one. This because
2007/5/6, Alan Cox <[EMAIL PROTECTED]>:
> However, whatever policy the buffer uses, the fundamental point it's that
> when I flush the input buffer I should be sure that each byte read
> after the flush is *new* (current) data and not old one. This because
Define "new" and "old" in this case. I
2007/5/5, Con Kolivas <[EMAIL PROTECTED]>:
[cut]
Here's a better swap prefetch tester. Instructions in file.
The system should be leaved totally inactive for the test duration (10m) right?
Regards,
~ Antonio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
2007/5/5, Alan Cox <[EMAIL PROTECTED]>:
On Sat, 5 May 2007 20:07:15 +0200
Oliver Neukum <[EMAIL PROTECTED]> wrote:
[cut]
> should I understand this so that, if tty_buffer_request_room() returns
> less than requested, the rest of the data should be dropped on the
> floor?
If it returns NULL
2007/5/5, Oliver Neukum <[EMAIL PROTECTED]>:
Am Samstag, 5. Mai 2007 20:08 schrieb Antonino Ingargiola:
> Now I don't want to abuse your kindness, but I (personally) would be
> *really* interested in a similar fix for the FTDI usb-serial driver,
> because many measurements I
2007/5/5, Oliver Neukum [EMAIL PROTECTED]:
Am Samstag, 5. Mai 2007 20:08 schrieb Antonino Ingargiola:
Now I don't want to abuse your kindness, but I (personally) would be
*really* interested in a similar fix for the FTDI usb-serial driver,
because many measurements I do use an FTDI device
2007/5/5, Alan Cox [EMAIL PROTECTED]:
On Sat, 5 May 2007 20:07:15 +0200
Oliver Neukum [EMAIL PROTECTED] wrote:
[cut]
should I understand this so that, if tty_buffer_request_room() returns
less than requested, the rest of the data should be dropped on the
floor?
If it returns NULL then
2007/5/5, Con Kolivas [EMAIL PROTECTED]:
[cut]
Here's a better swap prefetch tester. Instructions in file.
The system should be leaved totally inactive for the test duration (10m) right?
Regards,
~ Antonio
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
2007/5/6, Alan Cox [EMAIL PROTECTED]:
However, whatever policy the buffer uses, the fundamental point it's that
when I flush the input buffer I should be sure that each byte read
after the flush is *new* (current) data and not old one. This because
Define new and old in this case. I don't
2007/5/5, Paul Fulghum <[EMAIL PROTECTED]>:
On Sat, 2007-05-05 at 18:58 +0200, Antonino Ingargiola wrote:
> This patch does not solve the problem with the cdc_acd driver. I still
> need to flush two times to really flush the input. And the "secondary
> buffer" still
On 5/5/07, Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
> Antonino:
>
> Can you try two tests (with my patch applied):
>
> 1. comment out the tty_flush_buffer() call in tty_ldisc_flush() and test
>
> 2. un
Forgot to include the links in the previous mail:
[0] http://www.lammertbies.nl/comm/info/RS-232_null_modem.html
[1] http://pyserial.sourceforge.net/
~ Antonio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
2007/5/5, Paul Fulghum <[EMAIL PROTECTED]>:
On Sat, 2007-05-05 at 18:46 +0200, Oliver Neukum wrote:
> Am Samstag, 5. Mai 2007 18:08 schrieb Paul Fulghum:
> > I would argue that cdc-acm should do the same as the serial driver.
>
> Has this been tested?
> If so we could reduce the complexity of
2007/5/5, Antonino Ingargiola <[EMAIL PROTECTED]>:
2007/5/5, Paul Fulghum <[EMAIL PROTECTED]>:
> On Sat, 2007-05-05 at 11:08 -0500, Paul Fulghum wrote:
> > I would argue that cdc-acm should do the same as the serial driver.
>
> Try this patch for the usb ports.
2007/5/5, Paul Fulghum <[EMAIL PROTECTED]>:
On Sat, 2007-05-05 at 11:08 -0500, Paul Fulghum wrote:
> I would argue that cdc-acm should do the same as the serial driver.
Try this patch for the usb ports. (I don't have that hardware)
Building... thanks.
The HW is a cypress demo-board for their
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
Antonino:
Can you try two tests (with my patch applied):
1. comment out the tty_flush_buffer() call in tty_ldisc_flush() and test
2. uncomment (reenable) the above call and comment out the
tty_flush_buffer() call in tty_ioctl() and test
I
2007/5/5, Paul Fulghum <[EMAIL PROTECTED]>:
On Fri, 2007-05-04 at 17:30 -0600, Paul Fulghum wrote:
> OK, this behavior is so unexpected I must be missing
> something basic.
And so I was. Try this patch.
--- a/drivers/char/tty_io.c 2007-05-04 05:46:55.0 -0500
+++
2007/5/5, Paul Fulghum [EMAIL PROTECTED]:
On Fri, 2007-05-04 at 17:30 -0600, Paul Fulghum wrote:
OK, this behavior is so unexpected I must be missing
something basic.
And so I was. Try this patch.
--- a/drivers/char/tty_io.c 2007-05-04 05:46:55.0 -0500
+++ b/drivers/char/tty_io.c
On 5/4/07, Paul Fulghum [EMAIL PROTECTED] wrote:
Antonino:
Can you try two tests (with my patch applied):
1. comment out the tty_flush_buffer() call in tty_ldisc_flush() and test
2. uncomment (reenable) the above call and comment out the
tty_flush_buffer() call in tty_ioctl() and test
I
2007/5/5, Paul Fulghum [EMAIL PROTECTED]:
On Sat, 2007-05-05 at 11:08 -0500, Paul Fulghum wrote:
I would argue that cdc-acm should do the same as the serial driver.
Try this patch for the usb ports. (I don't have that hardware)
Building... thanks.
The HW is a cypress demo-board for their
2007/5/5, Antonino Ingargiola [EMAIL PROTECTED]:
2007/5/5, Paul Fulghum [EMAIL PROTECTED]:
On Sat, 2007-05-05 at 11:08 -0500, Paul Fulghum wrote:
I would argue that cdc-acm should do the same as the serial driver.
Try this patch for the usb ports. (I don't have that hardware)
Building
2007/5/5, Paul Fulghum [EMAIL PROTECTED]:
On Sat, 2007-05-05 at 18:46 +0200, Oliver Neukum wrote:
Am Samstag, 5. Mai 2007 18:08 schrieb Paul Fulghum:
I would argue that cdc-acm should do the same as the serial driver.
Has this been tested?
If so we could reduce the complexity of the
Forgot to include the links in the previous mail:
[0] http://www.lammertbies.nl/comm/info/RS-232_null_modem.html
[1] http://pyserial.sourceforge.net/
~ Antonio
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
On 5/5/07, Antonino Ingargiola [EMAIL PROTECTED] wrote:
On 5/4/07, Paul Fulghum [EMAIL PROTECTED] wrote:
Antonino:
Can you try two tests (with my patch applied):
1. comment out the tty_flush_buffer() call in tty_ldisc_flush() and test
2. uncomment (reenable) the above call and comment out
2007/5/5, Paul Fulghum [EMAIL PROTECTED]:
On Sat, 2007-05-05 at 18:58 +0200, Antonino Ingargiola wrote:
This patch does not solve the problem with the cdc_acd driver. I still
need to flush two times to really flush the input. And the secondary
buffer still seems 26 bytes (as before).
I
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
On Fri, 2007-05-04 at 21:06 +0200, Antonino Ingargiola wrote:
> Filling with echo console-screen.sh I've found that the blocking command is:
>
> unicode_start 2> /dev/null || true
>
> or at least the echo before
On 5/4/07, Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
[cut]
I'm quite confident the system blocks on "Setting consoles fonts and
modes.", and thus during the boot script console-screen.h. I'll try to
see which commands blocks...
Filling with echo console-scre
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
On Fri, 2007-05-04 at 19:25 +0200, Antonino Ingargiola wrote:
> No. Ehmm ... I've an usb keybord and vga monitor on a standard desktop pc.
OK, I'm stumped.
I don't see how my patch could cause the machine to not boot
and I'm n
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
On Fri, 2007-05-04 at 19:13 +0200, Antonino Ingargiola wrote:
> On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
> > Antonino Ingargiola wrote:
> > > The system blocks during booting. I can unblock it with SysR
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
Antonino Ingargiola wrote:
> The system blocks during booting. I can unblock it with SysReq+K but
> then I'm unable to log into X.
Hmmm, it tests here with no problem.
Does reversing the patch and rebuilding the kernel
On 5/4/07, Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
> Here is a patch against 2.6.21 which flushes the tty flip buffer
> on ioctl(TCFLSH) for input.
>
> --- a/drivers/char/tty_io.c 2007-04-25 22:08:32.000
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
Here is a patch against 2.6.21 which flushes the tty flip buffer
on ioctl(TCFLSH) for input.
--- a/drivers/char/tty_io.c 2007-04-25 22:08:32.0 -0500
+++ b/drivers/char/tty_io.c 2007-05-04 09:30:01.0 -0500
Thanks! I've
Accidentally I've replied privately, sorry. Forwarding to ML...
-- Forwarded message --
From: Antonino Ingargiola <[EMAIL PROTECTED]>
Date: May 4, 2007 11:29 AM
Subject: Re: [SOLVED] Serial buffer corruption [was Re: FTDI
usb-serial possible bug]
To: Oliver Neukum &
Hi,
On 4/14/07, Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
Hi to the list,
I report a problem found with a device that use the FTDI chip to
communicate data to pc.
The scenario is: a serial device streams data continuously toward the
pc. The application requires the data be rea
Hi,
On 4/14/07, Antonino Ingargiola [EMAIL PROTECTED] wrote:
Hi to the list,
I report a problem found with a device that use the FTDI chip to
communicate data to pc.
summary of snipped problem description
The scenario is: a serial device streams data continuously toward the
pc
Accidentally I've replied privately, sorry. Forwarding to ML...
-- Forwarded message --
From: Antonino Ingargiola [EMAIL PROTECTED]
Date: May 4, 2007 11:29 AM
Subject: Re: [SOLVED] Serial buffer corruption [was Re: FTDI
usb-serial possible bug]
To: Oliver Neukum [EMAIL PROTECTED
On 5/4/07, Paul Fulghum [EMAIL PROTECTED] wrote:
Here is a patch against 2.6.21 which flushes the tty flip buffer
on ioctl(TCFLSH) for input.
--- a/drivers/char/tty_io.c 2007-04-25 22:08:32.0 -0500
+++ b/drivers/char/tty_io.c 2007-05-04 09:30:01.0 -0500
snip
Thanks!
On 5/4/07, Antonino Ingargiola [EMAIL PROTECTED] wrote:
On 5/4/07, Paul Fulghum [EMAIL PROTECTED] wrote:
Here is a patch against 2.6.21 which flushes the tty flip buffer
on ioctl(TCFLSH) for input.
--- a/drivers/char/tty_io.c 2007-04-25 22:08:32.0 -0500
+++ b/drivers/char
On 5/4/07, Paul Fulghum [EMAIL PROTECTED] wrote:
Antonino Ingargiola wrote:
The system blocks during booting. I can unblock it with SysReq+K but
then I'm unable to log into X.
Hmmm, it tests here with no problem.
Does reversing the patch and rebuilding the kernel fix the boot?
The kernel
On 5/4/07, Paul Fulghum [EMAIL PROTECTED] wrote:
On Fri, 2007-05-04 at 19:13 +0200, Antonino Ingargiola wrote:
On 5/4/07, Paul Fulghum [EMAIL PROTECTED] wrote:
Antonino Ingargiola wrote:
The system blocks during booting. I can unblock it with SysReq+K but
then I'm unable to log into X
On 5/4/07, Paul Fulghum [EMAIL PROTECTED] wrote:
On Fri, 2007-05-04 at 19:25 +0200, Antonino Ingargiola wrote:
No. Ehmm ... I've an usb keybord and vga monitor on a standard desktop pc.
OK, I'm stumped.
I don't see how my patch could cause the machine to not boot
and I'm not seeing
On 5/4/07, Antonino Ingargiola [EMAIL PROTECTED] wrote:
[cut]
I'm quite confident the system blocks on Setting consoles fonts and
modes., and thus during the boot script console-screen.h. I'll try to
see which commands blocks...
Filling with echo console-screen.sh I've found that the blocking
On 5/4/07, Paul Fulghum [EMAIL PROTECTED] wrote:
On Fri, 2007-05-04 at 21:06 +0200, Antonino Ingargiola wrote:
Filling with echo console-screen.sh I've found that the blocking command is:
unicode_start 2 /dev/null || true
or at least the echo before this command is the last shown.
I
Hi to the list,
I'm forwarding to lkml this mail that got no answer on linux-usb.
It describes a nasty behavior of the ftdi usb-serial linux driver.
-- Forwarded message --
From: Antonino Ingargiola <[EMAIL PROTECTED]>
Date: Apr 14, 2007 4:47 PM
Subject: FTDI usb-serial po
Hi to the list,
I'm forwarding to lkml this mail that got no answer on linux-usb.
It describes a nasty behavior of the ftdi usb-serial linux driver.
-- Forwarded message --
From: Antonino Ingargiola [EMAIL PROTECTED]
Date: Apr 14, 2007 4:47 PM
Subject: FTDI usb-serial possible
80 matches
Mail list logo
