On 30-12-07 17:48, Alan Cox wrote:
For processors with TSC I think we should aim for 2.6.25 to do this and
to have the major other _p fixups done. I pity whoever does stuff like
the scc drivers but most of the rest isn't too bad.
I'm by the way looking at drivers/net/wd.c which my 386 uses fo
> do you remember which old systems/chipsets were affected by this
> problem? We had many - meanwhile fixed - PIC related problems, maybe
> it's a red herring and the delay just papered it over.
Some old VIA chipsets at least iirc. Might be more.
-Andi
--
To unsubscribe from this list: send the
Ingo Molnar wrote:
* Alan Cox <[EMAIL PROTECTED]> wrote:
i dont get your last point. Firstly, we do an "outb $0x80" not an
inb.
outb not inb sorry yes
Secondly, outb $0x80 has no PCI posting side-effects AFAICS.
Thirdly,
It does. The last mmio write cycle to the bridge gets pushed out
befor
I am running kernel 2.6.23.9
last night I had a crash.
This was all that was in the /var/log/messages.
I run centos 5.1 with the above kernel.
This was late at night noone was using the machine.
The machine is an AMD 6400+ X2, NVIDIA (with nvidia drivers). Software
RAID with 2 seagate 500GIG driv
[Ingo Molnar - Sun, Dec 30, 2007 at 06:22:50PM +0100]
|
| * Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
|
| > orig:
| > mbr_base = (buf_base+sector_size-1) & ~(sector_size-1);
| > new (could be):
| > mbr_base = (buf_base + sector_size - 1) & ~(sector_size - 1);
| >
| > Is a new version that bad?
> So the current plan is to go with an io_delay=udelay default in v2.6.25,
> to give this a migration window, and io_delay=none in v2.6.26 [and a
> complete removal of arch/x86/kernel/io_delay.c], once the _p() uses are
> fixed up. This is gradual enough to notice any regressions we care about
"Russell Leidich" <[EMAIL PROTECTED]> writes:
Not sure you have addressed any of my feedback; don't see many changes.
When you repost stuff can you please add a changelog or if you decide
to not address some review comment say why at least.
Also the patch changelog description is missing anyways
> A 2.6.26 plan for io_delay=none is very very foolish indeed. We don't burn
It also seems quite risky to me; at least if not paired with a DMI
year master switch.
Switching to udelay() by default should be probably ok though.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe
On Sun, 30 Dec 2007, Rene Herman wrote:
>
> [EMAIL PROTECTED]:~/src/port80$ su -c ./port80
> cycles: out 2400, in 2401
> [EMAIL PROTECTED]:~/src/port80$ su -c ./port3cc
> cycles: out 459, in 394
>
> As stated a few dozen times by now already, port 0x80 is _decidedly_ _non_
> _random_
Oh, I agr
On Sun, 30 Dec 2007 19:14:40 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 30-12-07 17:48, Alan Cox wrote:
>
> > For processors with TSC I think we should aim for 2.6.25 to do this and
> > to have the major other _p fixups done. I pity whoever does stuff like
> > the scc drivers but most of
There are many places where these functions would be useful.
(just look at: grep -r 'cpu_to_[ble12346]*([ble12346]*_to_cpu.*[-+]' linux-src/)
What do you think?
ps: this patch depends on http://lkml.org/lkml/2007/12/25/35
--
add inline functions which add native byte order variable to
little/big
Adrian Bunk wrote:
> On Thu, Dec 27, 2007 at 02:18:58PM -0800, David Brownell wrote:
> > Also, looking at this in xconfig shows some oddness. That "core"
> > submenu holds stuff that would logically be part of the toplevel
> > menu for host side USB. While that toplevel menu has the USS720
> > dr
On Sun, Dec 30, 2007 at 08:06:34PM +0100, Marcin Slusarz wrote:
> There are many places where these functions would be useful.
> (just look at: grep -r 'cpu_to_[ble12346]*([ble12346]*_to_cpu.*[-+]'
> linux-src/)
> What do you think?
>
> ps: this patch depends on http://lkml.org/lkml/2007/12/25/35
On Sun 2007-12-30 14:30:07, Rafael J. Wysocki wrote:
> On Sunday, 30 of December 2007, Pavel Machek wrote:
> > Hi!
> >
> > > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > >
> > > Document the fact that __save_processor_state() has to save all CPU
> > > registers referred to by the kernel in cas
On Sun, Dec 30, 2007 at 03:01:16PM +0100, Ingo Molnar wrote:
>
> * Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > Index: linux-2.6/arch/x86/mm/pgtable_32.c
> > ===
> > --- linux-2.6.orig/arch/x86/mm/pgtable_32.c 2007-12-26 12:55:
On 30-12-07 19:39, Alan Cox wrote:
On Sun, 30 Dec 2007 19:14:40 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
I'm by the way looking at drivers/net/wd.c which my 386 uses for its dual
mode NE2000/WD8013 clone ISA NIC and while it specifically needs no delay at
all it seems, the mixed use of o
On Sun, 30 Dec 2007, Rene Herman wrote:
>
> I also just now dug up a "WDC (C) 1987" WD8003EBT and a "Novell, Inc (C) 1990"
> NE1000, both 8-bit ISA NICs and the ownership of which, I would suggest, makes
> me a really cool person.
.. I'm also told that mentioning this is a really good way to pi
Ingo Molnar wrote:
> * Masami Hiramatsu <[EMAIL PROTECTED]> wrote:
>
>> Indeed.
>> By the way, flush_cache_page() is defined as a do-while(0) on x86.
>> Would it better to define fix_riprel() as a do-while(0) on x86-32?
>> I think this obviously indicates that function has no effect.
>
> NOPs sho
Hi !
i build a kernel with allmodconfig and didn`t get my system to boot with that.
after some investigation i found that it was due to udev:
udevd[1226]: init_udev_socket: error getting socket: Address family not
supported by protocol
this was missing support UNIX DOMAIN SOCKETS at boot time
On 30-12-07 21:00, Linus Torvalds wrote:
On Sun, 30 Dec 2007, Rene Herman wrote:
I also just now dug up a "WDC (C) 1987" WD8003EBT and a "Novell, Inc (C) 1990"
NE1000, both 8-bit ISA NICs and the ownership of which, I would suggest, makes
me a really cool person.
.. I'm also told that mention
On Dec 30 2007 21:11, [EMAIL PROTECTED] wrote:
>
>i build a kernel with allmodconfig and didn`t get my system to boot with that.
>
>after some investigation i found that it was due to udev:
>
>udevd[1226]: init_udev_socket: error getting socket: Address family not
>supported by protocol
>
>this
On Sun, 30 Dec 2007, Ingo Molnar wrote:
> * Andreas Mohr <[EMAIL PROTECTED]> wrote:
>
> > (yes, that's all there is, despite CONFIG_USB_DEBUG being set)
> >
> > The LED of a usb stick isn't active either, for obvious reasons.
> >
> > And keep in mind that this is a (relatively old) OHCI-only ma
On Sun, Dec 30, 2007 at 09:18:38PM +0100, Jan Engelhardt wrote:
>
> On Dec 30 2007 21:11, [EMAIL PROTECTED] wrote:
> >
> >i build a kernel with allmodconfig and didn`t get my system to boot with
> >that.
> >
> >after some investigation i found that it was due to udev:
> >
> >udevd[1226]: init_ude
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> So even if that "port 80" access will also cause PCI postings to be
> flushed, so would the actual IO access that accompanies it, so I don't
> think that is a very strong argument.
>
> With all that said: it is certainly possible that the 1us timin
On Sunday, 30 of December 2007, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Document the fact that __save_processor_state() has to save all CPU
> > registers referred to by the kernel in case a different kernel
On 29-12-07 10:09, Richard Harman wrote:
Anyway, I'm extremely open to getting to the bottom of working around
the quirks on this hardware. If I havn't mentioned it previously, this
laptop is an HP dv6408nr, with an amd turion tl-56 cpu and nVidia MCP51
chipset.
What can I do to help? It h
On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
> > please check if you can replace the one in the x86-mm
> >
> > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76
> >
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > But i'm wondering - are we really ever resuming to a different
> > kernel version, for this to be an issue?
>
> The boot kernel may be different from the kernel within the image, if
> that's what you're asking for.
how different can it be, fo
Juergen Beisert wrote:
On Sunday 30 December 2007 16:38, Alan Cox wrote:
do you have any memories about the outb_p() use of misc_32.c:
pos = (x + cols * y) * 2; /* Update cursor position */
outb_p(14, vidport);
outb_p(0xff & (pos >> 9), vidport+1);
outb_p(1
Bodo Eggert wrote:
I've never seen code which would do that, and it was not suggested by any
tutorial I ever saw. I'd expect any machine to break on all kinds of software
if it required this. The only thing I remember being warned about is writing
the index and the data register at the same time
* Alan Cox <[EMAIL PROTECTED]> wrote:
> > So the current plan is to go with an io_delay=udelay default in v2.6.25,
> > to give this a migration window, and io_delay=none in v2.6.26 [and a
> > complete removal of arch/x86/kernel/io_delay.c], once the _p() uses are
> > fixed up. This is gradual
Ingo Molnar wrote:
* Bodo Eggert <[EMAIL PROTECTED]> wrote:
BTW: The error function in
linux-2.6.23/arch/i386/boot/compressed/misc.c uses while(1) without
cpu_relax() in order to halt the machine. Is this fixed? Should it be
fixed?
this is early bootup so there's no need to be "nice" to oth
[Ingo Molnar - Sun, Dec 30, 2007 at 06:22:50PM +0100]
|
| * Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
|
| > orig:
| > mbr_base = (buf_base+sector_size-1) & ~(sector_size-1);
| > new (could be):
| > mbr_base = (buf_base + sector_size - 1) & ~(sector_size - 1);
| >
| > Is a new version that bad?
Eduard-Gabriel Munteanu wrote:
On Sun, 30 Dec 2007 03:49:21 +0200
Note that this problem is only related to AMD64 multi-core laptops. As
far as I can see, devs might not invest much coding effort into this
and instead say "Go buy an Intel laptop!", as this really is a hardware
quirk. And if Andi
On 30-12-07 21:46, Ingo Molnar wrote:
* Alan Cox <[EMAIL PROTECTED]> wrote:
So the current plan is to go with an io_delay=udelay default in v2.6.25,
to give this a migration window, and io_delay=none in v2.6.26 [and a
complete removal of arch/x86/kernel/io_delay.c], once the _p() uses are
fix
On Sun, Dec 30, 2007 at 04:06:02PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > Combine the 32 and 64 bit specific Makefiles in one file. While
> > > doing so link order was (almost) preserved on 32 bit but on 64 bit
> > > link order changed a lot.
> > >
> > >
* Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> This patch eliminates checkpatch.pl complains on bootflag.c
thanks, applied this to x86.git, to the v2.6.25 queue. See the finalized
patch below. (I added two more small cleanups that checkpatch did not
warn about but which were obvious)
On Sun, 30 Dec 2007 15:42:17 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> Eduard-Gabriel Munteanu <[EMAIL PROTECTED]> writes:
> >
> > Other kernel developers, as discussed previously in this thread, are
> > working on a HPET-driven dynticks (as opposed to the current
> > LAPIC-driven one), but th
On Sun, Dec 30, 2007 at 05:10:41PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > i've added your full patch meanwhile - maybe we can get away with it.
>
> i needed the trivial fix below. You did not test-build it on 32-bit it
> appears :-)
Had CONFIG_X86_GENERICA
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> * Bodo Eggert <[EMAIL PROTECTED]> wrote:
>>
>>> BTW: The error function in linux-2.6.23/arch/i386/boot/compressed/misc.c
>>> uses while(1) without cpu_relax() in order to halt the machine. Is this
>>> fixed? Should it be fixed?
On Sun, 30 Dec 2007 15:57:59 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
> I think I may have a monkey wrench to throw into this, I finally got
> around to testing the C1E patch, and the port80 patch. End result:
> port80 patch has zero effect on this laptop, and the C1E patch makes
> it st
I am so happy that there will be a way for people who don't build their
own kernels to run Linux on their HP and Compaq laptops that have
problems with gazillions of writes to port 80, and I'm also happy that
some of the strange driver code will be cleaned up over time. Thank you
all. Some th
> But that does't mean that other ports won't have the same timings. Also,
> it doesn't mean that we really need to have exactly *those* timings.
For ISA bus you want "at least" those timings. That is an easy case
anyway - ISA bus boxes, old processors and generally no TSC so we can
fall back to
On Fri, Dec 28, 2007 at 03:07:46PM -0800, Andrew Morton wrote:
> On Fri, 28 Dec 2007 23:53:49 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
>
> > On Dec 23, 2007 5:27 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> > > On Dec 23, 2007 8:30 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > >
>
[PATCH] x86_64: fix section warning about enable_IO_APIC and setup_local_APIC
clear IO_APIC before enabing apic error vector cause link warning
use function call in setup_local_APIC to avoid that.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Index: linux-2.6/arch/x86/kernel/smpboot_64.c
==
On Sunday, 30 of December 2007, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > But i'm wondering - are we really ever resuming to a different
> > > kernel version, for this to be an issue?
> >
> > The boot kernel may be different from the kernel within the image,
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> [PATCH] x86_64: fix section warning about enable_IO_APIC and setup_local_APIC
>
> clear IO_APIC before enabing apic error vector cause link warning
>
> use function call in setup_local_APIC to avoid that.
as i said, this just works around the link warn
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > how different can it be, for resume to work? I mean, we'll have
> > deeply kernel version dependent variables in RAM. Am i missing
> > something obvious?
>
> On x86-64 it can be almost totally different (by restoring a
> hibernation image we
* Rene Herman <[EMAIL PROTECTED]> wrote:
> On 30-12-07 21:46, Ingo Molnar wrote:
>> * Alan Cox <[EMAIL PROTECTED]> wrote:
>>
So the current plan is to go with an io_delay=udelay default in v2.6.25,
to give this a migration window, and io_delay=none in v2.6.26 [and a
complete remo
On Sun, 30 Dec 2007, Ingo Molnar wrote:
> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> > Ingo Molnar wrote:
> >> * Bodo Eggert <[EMAIL PROTECTED]> wrote:
> >>> BTW: The error function in linux-2.6.23/arch/i386/boot/compressed/misc.c
> >>> uses while(1) without cpu_relax() in order to halt the ma
On Dec 30, 2007 10:24 PM, J. Bruce Fields <[EMAIL PROTECTED]> wrote:
>
> On Fri, Dec 28, 2007 at 03:07:46PM -0800, Andrew Morton wrote:
> > On Fri, 28 Dec 2007 23:53:49 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Dec 23, 2007 5:27 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote
Eduard-Gabriel Munteanu wrote:
On Sun, 30 Dec 2007 15:57:59 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
I think I may have a monkey wrench to throw into this, I finally got
around to testing the C1E patch, and the port80 patch. End result:
port80 patch has zero effect on this laptop, an
> fact even io_delay=udelay would be wrong because any problem will be
> less clearly triggerable and thus less bisectable/debuggable.
And if this eats someones disk because you drive the hardware out of spec
you are going to sit there and tell them to bisect it ? Lovely.
Ingo - put the christm
On Sun, 30 Dec 2007 21:46:50 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> well, using io_delay=udelay is not 'blindly disabling'. io_delay=none
> would be the end goal, once all _p() API uses are eliminated by
> transformation.
io_delay = none is not the end goal. Correctness is the end goal
On Sun, 30 Dec 2007 12:53:02 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Bodo Eggert wrote:
> >
> > I've never seen code which would do that, and it was not suggested by any
> > tutorial I ever saw. I'd expect any machine to break on all kinds of
> > software
> > if it required this. The
Teach git to ignore generated files in
arch/x86/vdso/*
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Roland McGrath <[EMAIL PROTECTED]>
Cc: "H. Peter Anvin" <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
---
arch/x86/vdso/.gitignore|
> ok. Like the patch below?
Not quite - you still need the loop in case you NMI and then run off into
oblivion
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Cyrill Gorcunov wrote:
Thanks Ingo, you're quite right! Next time i'll appear in list with real
(and hope usefull) patch ;)
Wonderful! I also *really* have to apologize for my short fuse earlier,
it was uncalled for.
-hpa
--
To unsubscribe from this list: send the line "unsubscrib
Ingo Molnar wrote:
It probably should actually HLT, to avoid sucking power, and stressing
the thermal system. We're dead at this point, and the early 486's
which had problems with HLT will lock up - we don't care.
ok. Like the patch below?
Don't need the cli; we're already running with i
> Now what's interesting is that the outb to port 80 is *faster* than an
> outb to an unused port, on my machine. So there's something there -
> actually accepting the bus transaction. In the ancient 5150 PC, 80 was
Yes and I even told you a while back how to verify where it is. From the
tim
On Sun, Dec 30, 2007 at 07:18:25PM +, Christoph Hellwig wrote:
> On Sun, Dec 30, 2007 at 08:06:34PM +0100, Marcin Slusarz wrote:
> > There are many places where these functions would be useful.
> > (just look at: grep -r 'cpu_to_[ble12346]*([ble12346]*_to_cpu.*[-+]'
> > linux-src/)
> > What do
On Sunday, 30 of December 2007, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > how different can it be, for resume to work? I mean, we'll have
> > > deeply kernel version dependent variables in RAM. Am i missing
> > > something obvious?
> >
> > On x86-64 it can b
On Dec 30, 2007 1:29 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
> > [PATCH] x86_64: fix section warning about enable_IO_APIC and
> > setup_local_APIC
> >
> > clear IO_APIC before enabing apic error vector cause link warning
> >
> > use function call in
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Document the fact that __save_processor_state() has to save all CPU
registers referred to by the kernel in case a different kernel is
used to load and restore a hibernation image containing it.
Sigend-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
On Sat, Dec 22, 2007 at 11:28:11AM -0800, Joe Perches wrote:
> On Sat, 2007-12-22 at 15:31 +0100, Sam Ravnborg wrote:
> > I looked at how inflate was used:
> >
> > $ grep inflate */boot/Makefile
> > alpha/boot/Makefile:$(obj)/misc.o: lib/inflate.c
> > => redundandt dependency, can be deleted
> >
On 30-12-07 22:44, H. Peter Anvin wrote:
Ingo Molnar wrote:
It probably should actually HLT, to avoid sucking power, and
stressing the thermal system. We're dead at this point, and the
early 486's which had problems with HLT will lock up - we don't care.
ok. Like the patch below?
Don't
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > what's exactly in the hibernation image? Dirty data i suppose
>
> No, everything, including the kernel code, page tables etc. :-)
>
> > - but what about kernel-internal pages. What if we go from SLAB to
> > SLUB? What if the size of a structur
* Alan Cox <[EMAIL PROTECTED]> wrote:
> You won't bisect obscure timing triggered problems, and the _p users
> are almost all for hardware where performance doesn't matter one iota
> (eg CMOS).
actually, people have, and i have too. But i agree that io_delay=none
would be stupid now, and woul
* Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sun, 30 Dec 2007 21:46:50 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > well, using io_delay=udelay is not 'blindly disabling'. io_delay=none
> > would be the end goal, once all _p() API uses are eliminated by
> > transformation.
>
> io_delay
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> Teach git to ignore generated files in
> arch/x86/vdso/*
thanks Sam, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ker
Greetings!
Some of the keys on my USB-HID keyboard generate scancodes which are
bound to big keycodes in `drivers/hid/hid-input.c` and
`include/linux/input.h`, like 418, 419 or 432. Is there any possibility
to change it (in runtime, without editing `input.h` and recompiling the
kernel)? Should `se
On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote:
> On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * Yinghai Lu <[EMAIL PROTECTED]> wrote:
> >
> > > please check if you can replace the one in the x86-mm
> > >
> > > http://git.kernel.org/?p=linux/kernel/git/x86/lin
rmmod capidrv never returns
this is 2.6.24-rc6 with allmodconfig
gcc version 4.2.1 (SUSE Linux)
also see https://bugzilla.novell.com/show_bug.cgi?id=350850
[ 1807.666763] capidrv: Rev 1.1.2.2: loaded
[ 1810.803450] capidrv: Rev 1.1.2.2 : unloaded
[ 1810.808417] BUG: unable to handle kernel NULL
* Alan Cox <[EMAIL PROTECTED]> wrote:
> > ok. Like the patch below?
>
> Not quite - you still need the loop in case you NMI and then run off
> into oblivion
yes indeed. Updated patch below.
Ingo
-->
Subject: x86: hlt on early crash
From: Ingo Molnar <[EMAIL PROTECTED]>
H
On Sunday, 30 of December 2007, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > what's exactly in the hibernation image? Dirty data i suppose
> >
> > No, everything, including the kernel code, page tables etc. :-)
> >
> > > - but what about kernel-internal pages. W
Hi Kim,
On Fri, Aug 17, 2007 at 11:34:37AM -0700, K Naru wrote:
> From: Kim Naru ([EMAIL PROTECTED])
>
> Added support to offload TCP/UDP/IP checksum to the
> VIA Technologies VT6105M chip.
> Firstly, let the stack know this chip is capable of
> doing its own checksum(IPV4 only).
> Secondly offlo
Hi everyone. I'm sorry but I'm not currently subscribed to this list (I've
been sent here by the listmaster), so please CC me all your
answers/comments. Thanks in advance.
SHORT QUESTION :
In a Debian-controlled RAID array, is there a parameter that handles the
timeout before a non-responding driv
On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote:
> > On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > >
> > > * Yinghai Lu <[EMAIL PROTECTED]> wrote:
> > >
> > > > please check if you can replace the one
Jose de la Mancha wrote:
Hi everyone. I'm sorry but I'm not currently subscribed to this list (I've
been sent here by the listmaster), so please CC me all your
answers/comments. Thanks in advance.
SHORT QUESTION :
In a Debian-controlled RAID array, is there a parameter that handles the
timeout b
Alan Cox wrote:
Now what's interesting is that the outb to port 80 is *faster* than an
outb to an unused port, on my machine. So there's something there -
actually accepting the bus transaction. In the ancient 5150 PC, 80 was
Yes and I even told you a while back how to verify where it
On Dec 30 2007 23:42, Jose de la Mancha wrote:
>SHORT QUESTION :
>In a Debian-controlled RAID array, is there a parameter that handles the
>timeout before a non-responding drive is dropped from the array ? Can this
>timeout become user-adjustable in a future build ?
Not sure about Debian,
but pe
On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote:
> On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote:
> > > On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > > >
> > > > * Yinghai Lu <[EMAIL PR
On Sun, 30 Dec 2007 08:36:26 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
> The C1E patch, which permits the lapic to function *does* make my
> system stable. My previous method of testing (using USB peripherals)
> and checking /proc/interrupts for ERRor interrupts so far hasn't
> caused the s
Mostly just stylistic comments from me here.
On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote:
> From: Alex Dubov <[EMAIL PROTECTED]>
>
> Sony MemoryStick cards are used in many products manufactured by Sony. They
> are available both as storage and as IO expansion cards. Currently, onl
On Dec 30, 2007 3:23 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote:
> > On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote:
> > > > On Dec 30, 2007 6:51 AM, Ingo
On Sun, 2007-12-30 at 23:00 +0100, Sam Ravnborg wrote:
> Can you please remind me what problem you are actually trying to solve here.
> Your current approach it not good - we do not want .c code in include/*
> And what is wrong with the current include path?
It's not a bit deal.
inflate.c is #inc
> In fs/cifs/cifssmb.c, in CIFSSMBSetEA (...) function wrong counting of
> var exists.
>
> EXISTING CODE:
> pSMB->DataCount = sizeof(*parm_data) + ea_value_len + name_len + 1;
>
> MUST BE:
> pSMB->DataCount = sizeof(*parm_data) + ea_value_len + name_len;
>
> REASON:
> "sizeof(*parm_data)" counts
David P. Reed wrote:
Alan Cox wrote:
Now what's interesting is that the outb to port 80 is *faster* than
an outb to an unused port, on my machine. So there's something there
- actually accepting the bus transaction. In the ancient 5150 PC,
80 was
Yes and I even told you a while back
On Sun, Dec 30, 2007 at 04:01:39PM -0800, Yinghai Lu wrote:
> On Dec 30, 2007 3:23 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote:
> > > On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > > On Sun, Dec 30, 2007 at 12:
Richard Harman wrote:
I think I may have a monkey wrench to throw into this, I finally got
around to testing the C1E patch, and the port80 patch. End result:
port80 patch has zero effect on this laptop, and the C1E patch makes
it stable.
Stating that your system is "stable" is not very
On Dec 31 2007 00:01, Carlos Corbacho wrote:
>On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote:
>> From: Alex Dubov <[EMAIL PROTECTED]>
>>
>> Sony MemoryStick cards are used in many products manufactured by Sony. They
>> are available both as storage and as IO expansion cards. Currently
Very simple time limit on the realtime scheduling classes.
Allow the rq's realtime class to consume sched_rt_ratio of every
sched_rt_period slice. If the class exceeds this quota the fair class
will preempt the realtime class.
TODO:
- rt limit vs load-balance
- proper interface
Signed-off-by:
I spend xmas implementing group scheduling for the realtime scheduling classes.
Its a tad raw, but seems to work for the trivial test cases I threw at it.
The hrtick stuff is unrelated but was still stuck in my sched queue.
Patches against .26-rc6-mm1
--
--
To unsubscribe from this list: send t
Extend group scheduling to also cover the realtime classes. It uses the time
limiting introduced by the previous patch to allow multiple realtime groups.
The hard time limit is required to keep behaviour deterministic.
The algorithms used make the realtime scheduler O(tg), linear scaling wrt the
Use HR-timers (when available) to deliver an accurate preemption tick.
The regular scheduler tick that runs at 1/HZ can be too coarse when nice
level are used. The fairness system will still keep the cpu utilisation 'fair'
by then delaying the task that got an excessive amount of CPU time but try
On Monday 31 December 2007 00:31:12 Jan Engelhardt wrote:
> On Dec 31 2007 00:01, Carlos Corbacho wrote:
> >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote:
> >> From: Alex Dubov <[EMAIL PROTECTED]>
> >>
> >> Sony MemoryStick cards are used in many products manufactured by Sony.
> >> Th
On Dec 30, 2007 4:28 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> On Sun, Dec 30, 2007 at 04:01:39PM -0800, Yinghai Lu wrote:
> > On Dec 30, 2007 3:23 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >
> > > On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote:
> > > > On Dec 30, 2007 2:06 PM
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Dec 31 2007 00:01, Carlos Corbacho wrote:
> >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote:
> >> From: Alex Dubov <[EMAIL PROTECTED]>
> >>
> >> Sony MemoryStick cards are used in many products manufactured by Sony. They
> >> are
> However, my only concerns are that:
>
> 1) tifm_ms was not autoloaded
> 2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not.
>
> Although, whether this is an issue with userspace (ie. udev) not dealing with
> the modules properly, I don't know.
>
This is exactly the sam
On Dec 30, 2007 4:28 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> On Sun, Dec 30, 2007 at 04:01:39PM -0800, Yinghai Lu wrote:
> > On Dec 30, 2007 3:23 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >
> > > On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote:
> > > > On Dec 30, 2007 2:06 PM
101 - 200 of 221 matches
Mail list logo
