On Fri, January 18, 2008 20:16, Mingming Cao wrote:
> On Sat, 2008-01-12 at 21:35 +0100, Indan Zupancic wrote:
>> i_file_acl and i_dir_acl aren't always needed.
>>
>> With certain configs this makes 10 ext3_inode_cache objects fit in
>> one slab instead of the current
On Fri, January 18, 2008 20:16, Mingming Cao wrote:
On Sat, 2008-01-12 at 21:35 +0100, Indan Zupancic wrote:
i_file_acl and i_dir_acl aren't always needed.
With certain configs this makes 10 ext3_inode_cache objects fit in
one slab instead of the current 9, as the size shrinks from 416
i_file_acl and i_dir_acl aren't always needed.
With certain configs this makes 10 ext3_inode_cache objects fit in
one slab instead of the current 9, as the size shrinks from 416 to
408 bytes for 32 bit, !POSIX_ACL and !EXT3_FS_XATTR configs.
Signed-off-by: Indan Zupancic <[EMAIL PROTEC
i_file_acl and i_dir_acl aren't always needed.
With certain configs this makes 10 ext3_inode_cache objects fit in
one slab instead of the current 9, as the size shrinks from 416 to
408 bytes for 32 bit, !POSIX_ACL and !EXT3_FS_XATTR configs.
Signed-off-by: Indan Zupancic [EMAIL PROTECTED
Hi,
On Fri, January 11, 2008 09:46, Tetsuo Handa wrote:
> It depends.
> Some users have to continue using brain dead legacy applications
> without modification because ...
>
>the application's source code is not available.
Source isn't needed, as long as the vendor has it.
>the
Hi,
On Fri, January 11, 2008 09:46, Tetsuo Handa wrote:
It depends.
Some users have to continue using brain dead legacy applications
without modification because ...
the application's source code is not available.
Source isn't needed, as long as the vendor has it.
the distributor no
On Thu, January 10, 2008 05:57, Tetsuo Handa wrote:
> It seems to me that the alternatives you are proposing include
> modification of userland applications. But my assumption is
> that "Don't require modification of userland applications".
If you want a secure system it isn't that unreasonable
On Thu, January 10, 2008 00:08, Serge E. Hallyn wrote:
> These emails again are getting really long, but I think the gist of
> Indan's suggestion can be concisely summarized:
No worry, I wasn't planning on extending it, I've said what I've to say.
Except...
>
> "To confine process P3 to
Hello,
On Wed, January 9, 2008 05:39, Tetsuo Handa wrote:
> Hello.
>
> Indan Zupancic wrote:
>> I think you focus too much on your way of enforcing filename/attributes
>> pairs.
> So?
So that you miss alternatives and don't see the bigger picture.
>
>> The
Hello,
On Wed, January 9, 2008 05:39, Tetsuo Handa wrote:
Hello.
Indan Zupancic wrote:
I think you focus too much on your way of enforcing filename/attributes
pairs.
So?
So that you miss alternatives and don't see the bigger picture.
The same can be achieved by creating the device nodes
On Thu, January 10, 2008 00:08, Serge E. Hallyn wrote:
These emails again are getting really long, but I think the gist of
Indan's suggestion can be concisely summarized:
No worry, I wasn't planning on extending it, I've said what I've to say.
Except...
To confine process P3 to
files are present, the MAC system used doesn't have to have special
device nodes attributes support. Protecting those files is enough to
guarantee filename/attributes pairs.
On Tue, January 8, 2008 14:50, Tetsuo Handa wrote:
> Hello.
>
>
> Indan Zupancic wrote:
>> > I want t
files are present, the MAC system used doesn't have to have special
device nodes attributes support. Protecting those files is enough to
guarantee filename/attributes pairs.
On Tue, January 8, 2008 14:50, Tetsuo Handa wrote:
Hello.
Indan Zupancic wrote:
I want to use this filesystem in case
Hello,
Some questions:
On Sun, January 6, 2008 16:20, Tetsuo Handa wrote:
> I want to use this filesystem in case where a process with root privilege was
> hijacked but the behavior of the hijacked process is still restricted by MAC.
1) If the behaviour can be controlled, why can't the process
Hello,
Some questions:
On Sun, January 6, 2008 16:20, Tetsuo Handa wrote:
I want to use this filesystem in case where a process with root privilege was
hijacked but the behavior of the hijacked process is still restricted by MAC.
1) If the behaviour can be controlled, why can't the process be
Hi,
On Mon, December 17, 2007 01:40, Tetsuo Handa wrote:
> Hello.
>
> Indan Zupancic wrote:
>> What prevents them from mounting tmpfs on top of /dev, bypassing your fs?
> Mandatory access control (MAC) prevents them from mounting tmpfs on top of
> /dev .
> MAC mediate
Hi,
On Mon, December 17, 2007 01:40, Tetsuo Handa wrote:
Hello.
Indan Zupancic wrote:
What prevents them from mounting tmpfs on top of /dev, bypassing your fs?
Mandatory access control (MAC) prevents them from mounting tmpfs on top of
/dev .
MAC mediates namespace manipulation requests
Hi,
On Sun, December 16, 2007 13:03, Tetsuo Handa wrote:
> Hello.
>
> David Newall wrote:
>> > You won't be able to login to the system because /sbin/mingetty
>> > fails to "chown/chmod" /dev/tty* if /dev is mounted for read-only mode.
>>
>> Good point. So, if only root can modify files in /dev,
Hi,
On Sun, December 16, 2007 13:03, Tetsuo Handa wrote:
Hello.
David Newall wrote:
You won't be able to login to the system because /sbin/mingetty
fails to chown/chmod /dev/tty* if /dev is mounted for read-only mode.
Good point. So, if only root can modify files in /dev, what's the
On Thu, September 27, 2007 09:00, Arnd Bergmann wrote:
> Assuming that we want to go down that road, I think you can do better with
> more evil macro magic, by using something along the lines of
>
> #define KERN_NOTICE "<5>",
>
> #define PRINTK_CONTINUED "",
>
> #define printk(level, str, ...) \
On Thu, September 27, 2007 09:00, Arnd Bergmann wrote:
Assuming that we want to go down that road, I think you can do better with
more evil macro magic, by using something along the lines of
#define KERN_NOTICE 5,
#define PRINTK_CONTINUED ,
#define printk(level, str, ...) \
do { \
On Fri, September 21, 2007 01:18, Rob Landley wrote:
> On Thursday 20 September 2007 4:26:13 pm Indan Zupancic wrote:
>> A quick scroll through a vmlinux binary shows that there are quite a
>> lot areas consisting only of some repeated pattern. Mostly 0x00, but
>> also 0x90 a
On Thu, September 20, 2007 22:38, Rob Landley wrote:
> I've been playing with an idea for a while to improve the printk() situation,
> but it's a more intrusive change than I've had time to bang on.
>
> Right now, the first argument to printk() is a loglevel, but it's handled via
> string
On Thu, September 20, 2007 22:38, Rob Landley wrote:
I've been playing with an idea for a while to improve the printk() situation,
but it's a more intrusive change than I've had time to bang on.
Right now, the first argument to printk() is a loglevel, but it's handled via
string
On Fri, September 21, 2007 01:18, Rob Landley wrote:
On Thursday 20 September 2007 4:26:13 pm Indan Zupancic wrote:
A quick scroll through a vmlinux binary shows that there are quite a
lot areas consisting only of some repeated pattern. Mostly 0x00, but
also 0x90 and .GCC: (GNU) 4.2.1
Hi,
Just added an old network card, RTL-8029(AS), ne2k-pci driver, and tried to
expand the network (failed because I didn't use a cross-over cable).
The code snippet that spat the thing:
/*
* IRQ resend
*
* Is called with interrupts disabled and desc->lock held.
*/
void
Hi,
Just added an old network card, RTL-8029(AS), ne2k-pci driver, and tried to
expand the network (failed because I didn't use a cross-over cable).
The code snippet that spat the thing:
/*
* IRQ resend
*
* Is called with interrupts disabled and desc-lock held.
*/
void
On Tue, August 7, 2007 08:05, Arjan van de Ven wrote:
> On Tue, 2007-08-07 at 00:40 -0400, Kyle Moffett wrote:
>> On Aug 01, 2007, at 11:06:00, Indan Zupancic wrote:
>> > Different programs, different keys "stuck", so hard to tell. The
>> > amount the pres
On Tue, August 7, 2007 08:05, Arjan van de Ven wrote:
On Tue, 2007-08-07 at 00:40 -0400, Kyle Moffett wrote:
On Aug 01, 2007, at 11:06:00, Indan Zupancic wrote:
Different programs, different keys stuck, so hard to tell. The
amount the pressed key is repeated differs too, from double
On Mon, August 6, 2007 19:46, Rene Herman wrote:
> On 08/06/2007 05:19 PM, Indan Zupancic wrote:
>
> [ Yes, OT, I'll shelve it after this ]
Me too, and I wonder if we should've dropped a bunch of CCs...
>
>> Anyway, if you want to experience a shock, try enabling xcomposite a
On Mon, August 6, 2007 19:16, H. Peter Anvin wrote:
> Indan Zupancic wrote:
>>
>> Does executing unicode_start, unicode_stop fixes it?
>>
>
> Does that seem likely, since his display isn't even in text mode?
No idea, just thought it would be worth a try. My co
On Mon, August 6, 2007 18:06, Jeff Chua wrote:
> On 8/6/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
>> >���
>> That looks pretty much like all-one-bits (� = 255).
>> What about vcsa1 (use hexdump -C)?
>
> # hexdump -C /dev/vcsa1
> 19 50 00 18 ff ff
On Mon, August 6, 2007 15:10, Rene Herman wrote:
> On 08/06/2007 09:12 AM, Ingo Molnar wrote:
>
>> * Indan Zupancic <[EMAIL PROTECTED]> wrote:
>>
>>> All right, how would you debug it? Give us some insight in how to
>>> solve hard to trigger, happens at
On Mon, August 6, 2007 15:10, Rene Herman wrote:
On 08/06/2007 09:12 AM, Ingo Molnar wrote:
* Indan Zupancic [EMAIL PROTECTED] wrote:
All right, how would you debug it? Give us some insight in how to
solve hard to trigger, happens at most only a few times a day,
annoying input bug? I
On Mon, August 6, 2007 18:06, Jeff Chua wrote:
On 8/6/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
���
That looks pretty much like all-one-bits (� = 255).
What about vcsa1 (use hexdump -C)?
# hexdump -C /dev/vcsa1
19 50 00 18 ff ff ff ff ff ff
On Mon, August 6, 2007 19:16, H. Peter Anvin wrote:
Indan Zupancic wrote:
Does executing unicode_start, unicode_stop fixes it?
Does that seem likely, since his display isn't even in text mode?
No idea, just thought it would be worth a try. My console is garbled
too, doing that unicode stuff
On Mon, August 6, 2007 19:46, Rene Herman wrote:
On 08/06/2007 05:19 PM, Indan Zupancic wrote:
[ Yes, OT, I'll shelve it after this ]
Me too, and I wonder if we should've dropped a bunch of CCs...
Anyway, if you want to experience a shock, try enabling xcomposite and
run xcompmgr
On Thu, August 2, 2007 14:22, Rene Herman wrote:
> On 08/02/2007 09:11 AM, S�bastien Dugu� wrote:
>
>> This reminds me I had something similar happening about a year or so ago
>> running with Debian's unstable xorg and gnome.
>>
>> The keys would stick for a short time (no, no coffee spilled on
On Thu, August 2, 2007 14:22, Rene Herman wrote:
On 08/02/2007 09:11 AM, S�bastien Dugu� wrote:
This reminds me I had something similar happening about a year or so ago
running with Debian's unstable xorg and gnome.
The keys would stick for a short time (no, no coffee spilled on the
On Wed, August 1, 2007 17:09, Ingo Molnar wrote:
>
> * Indan Zupancic <[EMAIL PROTECTED]> wrote:
>
>> We could have independent problems with more or less the same
>> symptoms, at least Teresa's problem seems much worse than ours, and if
>> you and Ingo only experi
On Wed, August 1, 2007 15:58, Rene Herman wrote:
> On 08/01/2007 03:33 PM, <:::.. TeresaII ..:::> wrote:
>
>> Problem is, that i can't reproduce it after last reboot.
>> Can this be different on each reboot ? Any idea ?
>>
>> About another kernel: i only had -ck kernels since last year or more, i
On Wed, August 1, 2007 14:50, Rene Herman wrote:
> On 08/01/2007 02:34 PM, Indan Zupancic wrote:
>
>> On Wed, August 1, 2007 13:01, Rene Herman wrote:
>
>>> Teresa was already using 2.6.22.1, with CFS (v19.1) patched in, so reverting
>>> that would be a matter o
On Wed, August 1, 2007 13:01, Rene Herman wrote:
> On 08/01/2007 01:31 PM, Andi Kleen wrote:
>
>> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
>>> another reaction below in this thread reported kbd problems in vanilla
>>> 2.6.22.1 as well. What is the X versions, etc.? Does the problem go away
>>> if
On Wed, August 1, 2007 13:01, Rene Herman wrote:
On 08/01/2007 01:31 PM, Andi Kleen wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
another reaction below in this thread reported kbd problems in vanilla
2.6.22.1 as well. What is the X versions, etc.? Does the problem go away
if the X kbd
On Wed, August 1, 2007 14:50, Rene Herman wrote:
On 08/01/2007 02:34 PM, Indan Zupancic wrote:
On Wed, August 1, 2007 13:01, Rene Herman wrote:
Teresa was already using 2.6.22.1, with CFS (v19.1) patched in, so reverting
that would be a matter of patching it out again. She said she wasn't
On Wed, August 1, 2007 17:09, Ingo Molnar wrote:
* Indan Zupancic [EMAIL PROTECTED] wrote:
We could have independent problems with more or less the same
symptoms, at least Teresa's problem seems much worse than ours, and if
you and Ingo only experience a stuck delete key, it might
On Wed, August 1, 2007 15:58, Rene Herman wrote:
On 08/01/2007 03:33 PM, :::.. TeresaII ..::: wrote:
Problem is, that i can't reproduce it after last reboot.
Can this be different on each reboot ? Any idea ?
About another kernel: i only had -ck kernels since last year or more, i
can
On Sun, July 29, 2007 05:50, Dmitry Torokhov wrote:
> Hi Indan,
>
> On Friday 27 July 2007 19:28, Indan Zupancic wrote:
>> Hi,
>>
>> Not real feedback, just some nitpicks.
>>
>> On Tue, July 24, 2007 06:45, Dmitry Torokhov wrote:
>> > +static int in
On Sun, July 29, 2007 05:38, Dmitry Torokhov wrote:
> Hi Indan,
>
> On Friday 27 July 2007 18:25, Indan Zupancic wrote:
>> Sorry for the babbling, just wanted to say that I've tested these
>> patches and that they seem to fix real problems.
>>
>
> Thank you for te
On Sun, July 29, 2007 05:38, Dmitry Torokhov wrote:
Hi Indan,
On Friday 27 July 2007 18:25, Indan Zupancic wrote:
Sorry for the babbling, just wanted to say that I've tested these
patches and that they seem to fix real problems.
Thank you for testing the patches.
Unfortunately I spoke too
On Sun, July 29, 2007 05:50, Dmitry Torokhov wrote:
Hi Indan,
On Friday 27 July 2007 19:28, Indan Zupancic wrote:
Hi,
Not real feedback, just some nitpicks.
On Tue, July 24, 2007 06:45, Dmitry Torokhov wrote:
+static int input_defuzz_abs_event(int value, int old_val, int fuzz
On Sat, July 28, 2007 01:34, grundig wrote:
> El Fri, 27 Jul 2007 15:06:14 -0700, Arjan van de Ven <[EMAIL PROTECTED]>
> escribi�:
>
>> how do you know there will be other activity? You start the IO and that
>> basically blacks out the disk for 5 to 10 ms. If the "real" IO gets
>> submitted in
Hi,
Not real feedback, just some nitpicks.
On Tue, July 24, 2007 06:45, Dmitry Torokhov wrote:
> +static int input_defuzz_abs_event(int value, int old_val, int fuzz)
> +{
> + if (fuzz) {
> + if (value > old_val - fuzz / 2 && value < old_val + fuzz / 2)
> +
On Tue, July 24, 2007 06:45, Dmitry Torokhov wrote:
> Hi everyone,
>
> I finally managed to put together some patches implementing
> locking in input core and main input handles. Please look
> over them and give them a spin.
Since kernel 2.6.21 or so I was annoyed by a warping mouse, and
one
On Sat, July 28, 2007 00:06, Arjan van de Ven wrote:
> On Fri, 2007-07-27 at 23:51 +0200, Indan Zupanci
>> > also, they take up seek time (5 to 10 msec), so if you were to read
>> > something else at the time you get additional latency.
>>
>> If there's other disk activity swap prefetch shouldn't
On Fri, July 27, 2007 22:34, Arjan van de Ven wrote:
> On Fri, July 27, 2007 21:43, Al Boldi wrote:
>> IMHO, what everybody agrees on, is that swap-prefetch has a positive effect
>> in some cases, and nobody can prove an adverse effect (excluding power
>> consumption). The reason for this
On Fri, July 27, 2007 22:34, Arjan van de Ven wrote:
On Fri, July 27, 2007 21:43, Al Boldi wrote:
IMHO, what everybody agrees on, is that swap-prefetch has a positive effect
in some cases, and nobody can prove an adverse effect (excluding power
consumption). The reason for this positive
On Sat, July 28, 2007 00:06, Arjan van de Ven wrote:
On Fri, 2007-07-27 at 23:51 +0200, Indan Zupanci
also, they take up seek time (5 to 10 msec), so if you were to read
something else at the time you get additional latency.
If there's other disk activity swap prefetch shouldn't do much, so
On Tue, July 24, 2007 06:45, Dmitry Torokhov wrote:
Hi everyone,
I finally managed to put together some patches implementing
locking in input core and main input handles. Please look
over them and give them a spin.
Since kernel 2.6.21 or so I was annoyed by a warping mouse, and
one kernel
Hi,
Not real feedback, just some nitpicks.
On Tue, July 24, 2007 06:45, Dmitry Torokhov wrote:
+static int input_defuzz_abs_event(int value, int old_val, int fuzz)
+{
+ if (fuzz) {
+ if (value old_val - fuzz / 2 value old_val + fuzz / 2)
+ return
On Sat, July 28, 2007 01:34, grundig wrote:
El Fri, 27 Jul 2007 15:06:14 -0700, Arjan van de Ven [EMAIL PROTECTED]
escribi�:
how do you know there will be other activity? You start the IO and that
basically blacks out the disk for 5 to 10 ms. If the real IO gets
submitted in that time you
On Sun, July 22, 2007 18:28, Theodore Tso wrote:
> On Sun, Jul 22, 2007 at 07:10:31AM +0300, Al Boldi wrote:
>> Sounds great, but it may be advisable to hook this into the partition
>> modification routines instead of mkfs/fsck. Which would mean that the
>> partition manager could ask the kernel
On Sun, July 22, 2007 18:28, Theodore Tso wrote:
On Sun, Jul 22, 2007 at 07:10:31AM +0300, Al Boldi wrote:
Sounds great, but it may be advisable to hook this into the partition
modification routines instead of mkfs/fsck. Which would mean that the
partition manager could ask the kernel to
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:
>
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 prob
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
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
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
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
On Mon, July 2, 2007 13:51, Andi Kleen wrote:
> On Monday 02 July 2007 13:43:23 Indan Zupancic wrote:
>> On Mon, July 2, 2007 01:59, Andi Kleen wrote:
>> > Well only those that could be already hung from user space
>> > with setleds (that was also confirmed). Actually
On Mon, July 2, 2007 01:59, Andi Kleen wrote:
> Well only those that could be already hung from user space
> with setleds (that was also confirmed). Actually I thought
> they didn't hang completely, but just stopped reacting to
> the keyboard (which is actually pretty bad for every user
> to be
On Mon, July 2, 2007 01:59, Andi Kleen wrote:
Well only those that could be already hung from user space
with setleds (that was also confirmed). Actually I thought
they didn't hang completely, but just stopped reacting to
the keyboard (which is actually pretty bad for every user
to be able
On Mon, July 2, 2007 13:51, Andi Kleen wrote:
On Monday 02 July 2007 13:43:23 Indan Zupancic wrote:
On Mon, July 2, 2007 01:59, Andi Kleen wrote:
Well only those that could be already hung from user space
with setleds (that was also confirmed). Actually I thought
they didn't hang
On Sat, June 16, 2007 05:34, Dmitry Torokhov wrote:
> On Friday 15 June 2007 22:04, Indan Zupancic wrote:
>> On Fri, June 15, 2007 07:41, Dmitry Torokhov wrote:
>> > /*
>> > + * Schedule switch for execution. We need to throttle requests,
>> > + * otherw
On Sat, June 16, 2007 05:34, Dmitry Torokhov wrote:
On Friday 15 June 2007 22:04, Indan Zupancic wrote:
On Fri, June 15, 2007 07:41, Dmitry Torokhov wrote:
/*
+ * Schedule switch for execution. We need to throttle requests,
+ * otherwise keyboard may become unresponsive.
+ */
+static
On Fri, June 15, 2007 07:41, Dmitry Torokhov wrote:
> Does the patch below help?
Didn't try it yet, but will tomorrow.
> Input: atkbd - throttle LED switching
>
> On some boxes keyboard controllers are too slow to withstand
> continuous flow of requests to turn keyboard LEDs on and off
> and
On Fri, June 15, 2007 07:41, Dmitry Torokhov wrote:
Does the patch below help?
Didn't try it yet, but will tomorrow.
Input: atkbd - throttle LED switching
On some boxes keyboard controllers are too slow to withstand
continuous flow of requests to turn keyboard LEDs on and off
and start
On Wed, June 13, 2007 10:18, Pavel Machek wrote:
>> Well, as I said before, I've the "stuck key"/repeated output too (as well
>> as a warping PS/2 mouse), but no blinking led problem, so I believe the
>> two things are totally unrelated.
>
> Well, after turning off CONFIG_BLINK, my problems went
On Wed, June 13, 2007 10:18, Pavel Machek wrote:
Well, as I said before, I've the stuck key/repeated output too (as well
as a warping PS/2 mouse), but no blinking led problem, so I believe the
two things are totally unrelated.
Well, after turning off CONFIG_BLINK, my problems went away, and
On Tue, June 12, 2007 07:42, Dmitry Torokhov wrote:
> For what it worth I finally tried that setleds loop on my laptop. I am
> not getting any lost keypresses/releases. But then I don't have EC
> (or at least it is not exported via ACPI). This is an old Dell notebook.
Well, as I said before, I've
On Tue, June 12, 2007 07:42, Dmitry Torokhov wrote:
For what it worth I finally tried that setleds loop on my laptop. I am
not getting any lost keypresses/releases. But then I don't have EC
(or at least it is not exported via ACPI). This is an old Dell notebook.
Well, as I said before, I've
On Mon, June 4, 2007 15:12, Jiri Kosina wrote:
> Are you sure that it's this dummy blink driver that makes the kernel
> stuck? I can't see how it could be causing any hogs - see commit f038f9.
To make it clear, I'm not using the blink driver and get the stuck
key problem too. (And also a warpy
On Mon, June 4, 2007 14:38, Jiri Kosina wrote:
> On Mon, 4 Jun 2007, Indan Zupancic wrote:
>
>> > I also get some stuck keys I was not getting before. I hope my
>> > userland did not go crazy...
>> I get that too, and wasn't sure about it either. It happens irregul
On Mon, June 4, 2007 13:24, Pavel Machek wrote:
> I also get some stuck keys I was not getting before. I hope my
> userland did not go crazy...
I get that too, and wasn't sure about it either. It happens irregularly,
so it's hard to debug, but often enough to be annoying.
My mouse pointer tends
On Mon, June 4, 2007 13:24, Pavel Machek wrote:
I also get some stuck keys I was not getting before. I hope my
userland did not go crazy...
I get that too, and wasn't sure about it either. It happens irregularly,
so it's hard to debug, but often enough to be annoying.
My mouse pointer tends to
On Mon, June 4, 2007 14:38, Jiri Kosina wrote:
On Mon, 4 Jun 2007, Indan Zupancic wrote:
I also get some stuck keys I was not getting before. I hope my
userland did not go crazy...
I get that too, and wasn't sure about it either. It happens irregularly,
so it's hard to debug, but often
On Mon, June 4, 2007 15:12, Jiri Kosina wrote:
Are you sure that it's this dummy blink driver that makes the kernel
stuck? I can't see how it could be causing any hogs - see commit f038f9.
To make it clear, I'm not using the blink driver and get the stuck
key problem too. (And also a warpy PS/2
On Sat, June 2, 2007 00:17, Olaf Dietsche wrote:
> It doesn't work. I tried all options "s2ram -f (-s, -p, -m, -r, -a 1, -a 2,
> -a 3)" one after the other.
>
> Since the screen (or any other device) works without problems, when I
> skip acpi_enter_sleep_state(), I don't think it's screen related.
On Sat, June 2, 2007 00:17, Olaf Dietsche wrote:
It doesn't work. I tried all options s2ram -f (-s, -p, -m, -r, -a 1, -a 2,
-a 3) one after the other.
Since the screen (or any other device) works without problems, when I
skip acpi_enter_sleep_state(), I don't think it's screen related.
I use
On Mon, May 21, 2007 17:11, Sam Ravnborg wrote:
> On Mon, May 21, 2007 at 02:52:39PM +0100, Jeremy Fitzhardinge wrote:
>> Sam Ravnborg wrote:
>> > There was another patch that removed the __init marker to _fix_ section
>> > mismatch errors.
>> > I have lost the actual mail but I asked the
On Mon, May 21, 2007 17:11, Sam Ravnborg wrote:
On Mon, May 21, 2007 at 02:52:39PM +0100, Jeremy Fitzhardinge wrote:
Sam Ravnborg wrote:
There was another patch that removed the __init marker to _fix_ section
mismatch errors.
I have lost the actual mail but I asked the submitter to send
On Sun, May 20, 2007 19:17, Tejun Heo wrote:
> Indan Zupancic wrote:
>> So over all it takes half a second longer to detect the disk, but
>> because everything waits on it, it takes more than three seconds
>> longer to resume.
>
> Eeeek. Extra three secs doesn't sound
Hello Tejun,
On Sun, May 20, 2007 19:09, Tejun Heo wrote:
> Indan Zupancic wrote:
>> Don't controllers support spread spin up of disks, to avoid the peak load?
>> I think I saw something about that in the SiI 3512 spec I downloaded. So
>> maybe something like a special spi
On Sun, May 20, 2007 11:54, Tejun Heo wrote:
> Indan Zupancic wrote:
>> On Sat, May 19, 2007 21:04, Tejun Heo wrote:
>>> Tejun Heo wrote:
>>>> Yeah, if SCR registers are accessible, 0xff doesn't indicate the device
>>>> isn't there, so the whol
On Sun, May 20, 2007 12:19, Tejun Heo wrote:
> Indan Zupancic wrote:
>> On Sun, May 20, 2007 00:03, Jeff Garzik wrote:
>>> Indan Zupancic wrote:
>>>> This patch seems to work with my SiI 3512, though I don't notice any
>>>> difference, neither a spee
Hello Tejun,
Thanks for your answers.
On Sun, May 20, 2007 11:50, Tejun Heo wrote:
> Indan Zupancic wrote:
>>> 1. We dropped libata specific suspend/resume implementation in favor of
>>> sd driven one. Unfortunately, the new implementation currently can't do
>>>
Hello Tejun,
Thanks for your answers.
On Sun, May 20, 2007 11:50, Tejun Heo wrote:
Indan Zupancic wrote:
1. We dropped libata specific suspend/resume implementation in favor of
sd driven one. Unfortunately, the new implementation currently can't do
background spinup, so that's probably why
On Sun, May 20, 2007 12:19, Tejun Heo wrote:
Indan Zupancic wrote:
On Sun, May 20, 2007 00:03, Jeff Garzik wrote:
Indan Zupancic wrote:
This patch seems to work with my SiI 3512, though I don't notice any
difference, neither a speedup, nor a slowdown. Hdparm gives the same
speeds (-tT
On Sun, May 20, 2007 11:54, Tejun Heo wrote:
Indan Zupancic wrote:
On Sat, May 19, 2007 21:04, Tejun Heo wrote:
Tejun Heo wrote:
Yeah, if SCR registers are accessible, 0xff doesn't indicate the device
isn't there, so the whole skip-0xff logic probably shouldn't apply in
such cases, but we
Hello Tejun,
On Sun, May 20, 2007 19:09, Tejun Heo wrote:
Indan Zupancic wrote:
Don't controllers support spread spin up of disks, to avoid the peak load?
I think I saw something about that in the SiI 3512 spec I downloaded. So
maybe something like a special spin up method which can
1 - 100 of 181 matches
Mail list logo
