Vivek Goyal <[EMAIL PROTECTED]> writes:
> Hi Eric,
>
> This .text.head section is not part of vmlinux. This is part of uncompressed
> portion in bzImage. arch/i386/boot/compressed/head.S.
>
> Hence, arch/i386/boot/compressed/vmlinux.lds should take care of it which
> already has entry for linking
Sam Ravnborg wrote:
> Hi Andres.
>
[...]
>
> The above code should be redone to use list based assignement.
> Something like this:
>
> psmouse-y := psmouse-base.o
> psmouse-$(CONFIG_MOUSE_PS2_ALPS) += alps.o
> psmouse-$(CONFIG_MOUSE_PS2_LOGIPS2PP) += logips2pp.o
> psmouse-$(CONFIG_MOUSE_P
Len Brown schrieb:
The bigger question is why you get "tons of these" --
as EC events are usually infrequent.
Do you have a big number next to "acpi" in /proc/interrupts?
If so, at what rate is it growing?
maybe tons were a bit to overstated... After a fresh reboot, i count 110
_q10 and
From: Oleg Nesterov <[EMAIL PROTECTED]>
Add rcutorture test for qrcu.
Works for me!
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Signed-off-by: Josh Triplett <[EMAIL PROTECTED]>
Acked-by: Paul E. McKenney <[EMAIL PROTECTED]>
Acked-by: Jens Axboe <[EMAIL PROTECTED]>
---
include/linux/srcu.h
From: Oleg Nesterov <[EMAIL PROTECTED]>
Very much based on ideas, corrections, and patient explanations from
Alan and Paul.
The current srcu implementation is very good for readers, lock/unlock
are extremely cheap. But for that reason it is not possible to avoid
synchronize_sched() and polling in
This series of 4 patches switch the block layer to use explicit
plugging instead of the implicit plugging that takes place now when io
is queued against an empty queue.
The first three patches update RCU to include a QRCU method similar to
SRCU. QRCU is a bit heavier on the reader side, but a _lot
On Sat, Dec 30, 2006 at 12:19:40PM +0100, Ingo Molnar wrote:
> your patch looks pretty ok to me in principle. A couple of suggestions
> to make it more mergable:
>
> - instead of BUG_ON()s please use DEBUG_LOCKS_WARN_ON() and make sure
>the code is never entered again if one assertion has b
Hi Andres.
> diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
> index 21a1de6..e7c7fbb 100644
> --- a/drivers/input/mouse/Makefile
> +++ b/drivers/input/mouse/Makefile
> @@ -14,4 +14,24 @@ obj-$(CONFIG_MOUSE_SERIAL) += sermouse.o
> obj-$(CONFIG_MOUSE_HIL) += h
Vivek Goyal schrieb:
What's your ld version. I don't remember but some particular versions
of ld will have this problem. These ld versions do some optimizations
and if a section size is zero then linker gets rid of that section and
any symbol defined w.r.t removed section, ld makes that symbol ab
On Wed, Dec 27 2006, Ingo Molnar wrote:
> Subject: [patch] block: remove BKL dependency from drivers/block/loop.c
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> the block loopback device is protected by lo->lo_ctl_mutex and it does
> not need to hold the BKL anywhere. Convert its ioctl to unlocked_i
Andres Salomon wrote:
> Andres Salomon wrote:
>> Dmitry Torokhov wrote:
>>> On 12/13/06, Andres Salomon <[EMAIL PROTECTED]> wrote:
Alright, I guess we're down to a matter of taste then. I'll change the
patch to still have a monolithic psmouse that allows protocols to be
enabled/disa
Andres Salomon wrote:
> Dmitry Torokhov wrote:
>> On 12/13/06, Andres Salomon <[EMAIL PROTECTED]> wrote:
>>> Alright, I guess we're down to a matter of taste then. I'll change the
>>> patch to still have a monolithic psmouse that allows protocols to be
>>> enabled/disabled via Kconfig.
>>>
>> That
On Wed, Dec 27, 2006 at 09:08:56PM +0530, Suparna Bhattacharya wrote:
> (2) Most of these other applications need the ability to process both
> network events (epoll) and disk file AIO in the same loop. With POSIX AIO
> they could at least sort of do this using signals (yeah, and all
> ass
On Tue, Jan 02, 2007 at 01:45:05PM -0800, Greg KH wrote:
> On Mon, Dec 25, 2006 at 01:08:31AM -0700, Grant Grundler wrote:
> > On Mon, Dec 25, 2006 at 01:06:35AM -0700, Grant Grundler wrote:
> > > On Sat, Dec 23, 2006 at 11:07:26PM -0700, Grant Grundler wrote:
> > > > "final" patch v7 and commit lo
Dmitry Torokhov wrote:
> On 12/13/06, Andres Salomon <[EMAIL PROTECTED]> wrote:
>>
>> Alright, I guess we're down to a matter of taste then. I'll change the
>> patch to still have a monolithic psmouse that allows protocols to be
>> enabled/disabled via Kconfig.
>>
>
> That'd be great. Thanks!
>
On Tue, Jan 02, 2007 at 11:44:34PM -0700, Eric W. Biederman wrote:
> Vivek Goyal <[EMAIL PROTECTED]> writes:
>
> > o i386 kernel reboots instantly if compiled with binutils older than
> > 2.6.15.
> >
> > o Older binutils required explicit flags to mark a section allocatable
> > and executable(
Vivek Goyal <[EMAIL PROTECTED]> writes:
> o i386 kernel reboots instantly if compiled with binutils older than
> 2.6.15.
>
> o Older binutils required explicit flags to mark a section allocatable
> and executable(AX). Newer binutils automatically mark a section AX if
> the name starts with .
Zach Brown wrote on Tuesday, January 02, 2007 6:06 PM
> > In the example you
> > gave earlier, task with min_nr of 2 will be woken up after 4 completed
> > events.
>
> I only gave 2 ios/events in that example.
>
> Does that clear up the confusion?
It occurs to me that people might not be aware h
On Sat, 30 Dec 2006, Denis Vlasenko wrote:
> I was experimenting with SSE[2] clear_page() which uses
> non-temporal stores. That one requires 16 byte alignment.
>
> BTW, it worked ~300% faster than memset. But Andi Kleen
> insists that cache eviction caused by NT stores will make it
> slower in m
Please check the latest version. ( 01/02/2007)
YH
[PATCH] x86_64: check_timer with io apic setup before try_apic_pin
In the check_timer, it forget to set up the io apic before try_apic_pin for
timer. So add set_try_apic_pin to set up the io apic pin. otherwise the
try_apic_pin will not work.
a
> ..same problem with 2.6.20-rc3. Last worked with
> 2.6.19-rc6-git12, so it was 2.6.19 where it failed.
> Attaching both case1 normal, case2 acpi=noirq. With acpi=noirq ethernet
> doesn't get configured, route -n says it's an Unsupported operation,
> ifconfig only shows for localhost, ifconf
On Sat, Dec 23, 2006 at 12:40:27AM -0500, Len Brown wrote:
>
> > WARNING: vmlinux - Section mismatch: reference to
> > .init.data:acpi_sci_flags from .text between 'acpi_sci_ioapic_setup' (at
> > offset 0xc010e020) and 'acpi_unmap_lsapic'
> > WARNING: vmlinux - Section mismatch: reference to
> > .
On Fri, Dec 22, 2006 at 09:47:10AM -0800, Randy Dunlap wrote:
> On Fri, 22 Dec 2006 15:24:41 +0100 Thomas Meyer wrote:
>
> > Hello.
> >
> > What kind of problem is this:
> > 1.) the one that should be fixed, but also can be ignored or
> > 2.) the one that have to be fixed and ignorance is a bad id
On Wed, Jan 03, 2007 at 03:12:13AM +0100, Mikael Pettersson wrote:
> On Tue, 2 Jan 2007 17:43:00 -0800 (PST), Linus Torvalds wrote:
> > > The suggestions I've had so far which I have not yet tried:
> > >
> > > - Select a different x86 CPU in the config.
> > > - Unfortunately the C3
On Tue, 02 Jan 2007 15:01:56 PST, David Schwartz said:
> There is simply no way you can argue that McDonald's failed to warn people
> about the risks. The cup says "hot" on it,
Actually, the "HOT" on the cup and the sticker in the drive-through that
says "Warning: Coffee is served very hot" were a
On Fri, Dec 22, 2006 at 03:33:12PM +0100, Thomas Meyer wrote:
> More warnings on current git head:
>
> OBJCOPY arch/i386/boot/compressed/vmlinux.bin
> RELOCS arch/i386/boot/compressed/vmlinux.relocs
> WARNING: Absolute relocations present
> Offset Info Type Sym.Value Sym.Name
> c010
On Tue, 02 Jan 2007 12:14:54 PST, David Schwartz said:
>
> > The recommendet _serving_ temperature for coffe is 55 °C or below.
>
> Nonsense! 55C (100F) is ludicrously low for coffee.
>
> 70C (125F) is the *minimum* recommended serving temperature. 165-190F is the
100F == 37C
125F == 52C
55C =
> In fact, the 'ok' prompt is an ENORMOUS pain in the ass to support
> on machines with USB keyboards, because sharing the USB host
> controller is beyond non-trivial. I've never implemented support
> for that on sparc64 and I frankly have no desire to do the work
> necessary to support that. It
On Tue, Jan 02, 2007 at 03:56:09PM -0800, Zach Brown wrote:
> Sorry for the delay, I'm finally back from the holiday break :)
Welcome back !
>
> >(1) The filesystem AIO patchset, attempts to address one part of
> >the problem
> >which is to make regular file IO, (without O_DIRECT)
> >asynchr
From: Daniel Jacobowitz <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 21:02:28 -0500
> On Thu, Apr 06, 2006 at 10:18:07PM -0700, David S. Miller wrote:
> > How about something like the following patch? If it's executable
> > and not written to, skip it. This would skip the main executable
> > image
On Tue, Jan 02, 2007 at 12:05:18PM +0100, Rene Herman wrote:
> Good day.
>
> A while ago it was remarked on list here that keeping the kernel 4M
> aligned physically might be a performance win if the added 1M (it
> normally loads at 1M) meant it would fit on one 4M aligned hugepage
> instead of 2
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 02:13:39 +0100 (MET)
>
> On Jan 3 2007 01:52, Segher Boessenkool wrote:
> >> > Leaving aside the issue of in-memory or not, I don't think
> >> > it is realistic to think any completely common implementation
> >> > will work for this -
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 02:14:34 +0100
> [snipping a bit for now]
>
> > and then, "fix"
> > that so that it works on x86 :-)
>
> That works, if the goal is to just add x86/OLPC to the list of
> platforms that have a device tree fs. I thought the plan w
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 01:52:06 +0100
> >> Leaving aside the issue of in-memory or not, I don't think
> >> it is realistic to think any completely common implementation
> >> will work for this -- it might for current SPARC+PowerPC+OLPC,
> >> but more stu
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 01:48:02 +0100
> > therefore you can't let multiple CPUs call
> > into OFW at one time. You must use some kind of locking mechanism,
> > and that locking mechanism is not simple because it has to not just
> > stop the other cpus,
Joel Soete wrote:
> Hello Alan, Jeff,
>
> Reading a paper on this new libata, I just want to try but failled yet
> for what said this thread "ATAPI CDROM" ;_(.
>
> I first test the latest stable 2.6.19.1 without luck, so I also want to
> try latest 2.6.20-rc2 unfortunately without more success.
o i386 kernel reboots instantly if compiled with binutils older than
2.6.15.
o Older binutils required explicit flags to mark a section allocatable
and executable(AX). Newer binutils automatically mark a section AX if
the name starts with .text.
o While defining a new section using assem
bbee wrote:
>> Yeap, I have major issues with SDB FISes which contains spurious
>> completions but most other spurious interrupts shouldn't be dangerous
>> and I haven't seen spurious completions for quite some time, so I was
>> thinking either removing the message or printing it only on SDB FIS
>>
On Wed, 3 Jan 2007, Tejun Heo wrote:
bbee wrote:
Tejun Heo gmail.com> writes:
Andrew Lyon wrote:
ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0)
Is this condition dangerous?
Not usually. Might indicate something is going wrong in some really
rare cases. I think ve
> > The bigger question is why you get "tons of these" --
> > as EC events are usually infrequent.
> > Do you have a big number next to "acpi" in /proc/interrupts?
> > If so, at what rate is it growing?
>
> maybe tons were a bit to overstated... After a fresh reboot, i count 110
> _q10 and one _
Hi Voipio,
Yes, the patch you sent (switching to "method 3" to work around the
evident bug in the i2c-ixp3xx driver) works on the platform I was
using too (after unrelated tweaks).
Here's an updated patch, using "method 3". If it still behaves
for you, it'd seem ready to merge...
- Dave
=
On Tue, 2 Jan 2007, Mariusz Kozlowski wrote:
> Hello,
>
> > This patch removes redundant argument check for kfree().
> >
> > drivers/media/video/pvrusb2/pvrusb2-hdw.c | 16
> > 1 file changed, 8 insertions(+), 8 deletions(-)
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL
Thanks for the review.
I will resubmit the patch.
Regards,
Sumant
-Original Message-
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
Sent: Friday, December 29, 2006 1:38 PM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.or
There is a basic problem in the way snd/core is handling the removal
of devices. If I unplug a USB audio device snd/core will end up in:
snd_card_free_when_closed. This isn't good because some desktop app
(don't know which one) keeps the sound device open until it exits.
This is not a good state t
Zach Brown wrote on Tuesday, January 02, 2007 6:06 PM
> On Jan 2, 2007, at 5:50 PM, Chen, Kenneth W wrote:
> > Zach Brown wrote on Tuesday, January 02, 2007 5:24 PM
> >>> That is not possible because when multiple tasks waiting for
> >>> events, they
> >>> enter the wait queue in FIFO order, prepar
[cc'ing linux-ide]
bbee wrote:
> Tejun Heo gmail.com> writes:
>> Andrew Lyon wrote:
>>> My system is gigabyte ds3 motherboard with onboard SATA JMicron
>>> 20360/20363 AHCI Controller (rev 02), drive connected is WDC
>>> WD740ADFD-00 20.0, I am running 2.6.18.6 32 bit, under heavy i/o I get
>>> t
Rename the variable "sum" in the __range_ok macros to avoid name
collisions causing lots of "symbol shadows an earlier one" warnings
by sparse.
Signed-off-by: Tilman Schmidt <[EMAIL PROTECTED]>
---
asm-arm/uaccess.h |4 ++--
asm-arm26/uaccess-asm.h |4 ++--
asm-i386/uaccess.h
On Tue, 2 Jan 2007 17:43:00 -0800 (PST), Linus Torvalds wrote:
> > The suggestions I've had so far which I have not yet tried:
> >
> > - Select a different x86 CPU in the config.
> > - Unfortunately the C3-2 flags seem to simply tell GCC
> > to schedule for
On Wednesday 03 January 2007 02:12, Mikael Pettersson wrote:
> On Tue, 2 Jan 2007 17:43:00 -0800 (PST), Linus Torvalds wrote:
> > > The suggestions I've had so far which I have not yet tried:
> > >
> > > - Select a different x86 CPU in the config.
> > > - Unfortunately the C3-2 flag
buffer index there. By then, most of you would probably veto the
patch anyway ;-)
haha, touche :)
I still think it'd be the right thing, though. We can let the patch
speak for itself :).
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
D. Hazelton <[EMAIL PROTECTED]> wrote:
[...]
> None. I didn't file a report on this because I didn't find the big, just
> noted a problem that appears to occur. In this case the call's generated
> seem to wrap loops - something I've never heard of anyone doing.
Example code showing this weirdnes
On Jan 2, 2007, at 5:50 PM, Chen, Kenneth W wrote:
Zach Brown wrote on Tuesday, January 02, 2007 5:24 PM
That is not possible because when multiple tasks waiting for
events, they
enter the wait queue in FIFO order, prepare_to_wait_exclusive() does
__add_wait_queue_tail(). So first io_getevent
[Please CC, I am not subscribed to lkml.]
On Thu, Apr 06, 2006 at 10:18:07PM -0700, David S. Miller wrote:
> How about something like the following patch? If it's executable
> and not written to, skip it. This would skip the main executable
> image and all text segments of the shared libraries m
Adrian Bunk wrote:
> This patch contains the scheduled IEEE1394_OUI_DB removal.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> Documentation/feature-removal-schedule.txt |8
> drivers/ieee1394/Kconfig | 14
> drivers/ieee1394/Makefile |
Zach Brown wrote on Tuesday, January 02, 2007 5:06 PM
> To: Chen, Kenneth W
> > Given the previous patch "aio: add per task aio wait event condition"
> > that we properly wake up event waiting process knowing that we have
> > enough events to reap, it's just plain waste of time to insert itself
> >
Zach Brown wrote on Tuesday, January 02, 2007 5:24 PM
> > That is not possible because when multiple tasks waiting for
> > events, they
> > enter the wait queue in FIFO order, prepare_to_wait_exclusive() does
> > __add_wait_queue_tail(). So first io_getevents() with min_nr of 2
> > will be wok
Tejun Heo gmail.com> writes:
> Andrew Lyon wrote:
> > My system is gigabyte ds3 motherboard with onboard SATA JMicron
> > 20360/20363 AHCI Controller (rev 02), drive connected is WDC
> > WD740ADFD-00 20.0, I am running 2.6.18.6 32 bit, under heavy i/o I get
> > the following messaegs:
> >
> > ata
Hi all,
I wrote a small utility which works similar to lspci, lsscsi, and lsusb:
http://me.in-berlin.de/~s5r6/linux1394/ls1394/
Usage: ls1394 [options]
List FireWire devices
Options:
-h, --help
Show this help
-v, --verbose
Increase verbosity
-s [[bus]:][node]
Sho
On Tue, 2 Jan 2007, Alistair John Strachan wrote:
>
> eax: 0008 ebx: ecx: 0008 edx:
> esi: f70f3e9c edi: f7017c00 ebp: f70f3c1c esp: f70f3c0c
>
> Code: 58 01 00 00 0f 4f c2 09 c1 89 c8 83 c8 08 85 db 0f 44 c8 8b 5d f4 89 c8
> 8b 75 f8 8b 7d fc 89 ec 5d c3 89
Hello!
An update to the long-standing need for priority boosting of RCU readers
in -rt kernels. This patch passes moderate testing, considerably more
severe than that faced by previous versions. Known shortcomings:
o This patch has not yet been subjected to enterprise-level
stress
On Tue, Jan 02, 2007 at 07:16:54PM +0100, Rainer Weikusat wrote:
> At least the Keyspan USA-19HS USB-to-serial converter supports
> two different configurations, one where the input endpoints
> have interrupt transfer type and one where they are bulk endpoints.
> The default UHCI configuration uses
I had that changes earlier, but dropped it to make the patch smaller.
Still have it kicking around?
Making this stuff more consistent would be nice, I agree, I'm just
not sure it's worth the risk of running into some subtle bugs.
- z
-
To unsubscribe from this list: send the line "unsubscr
Zach Brown wrote on Tuesday, January 02, 2007 5:14 PM
> To: Chen, Kenneth W
> > --- ./include/linux/aio.h.orig 2006-12-24 22:31:55.0 -0800
> > +++ ./include/linux/aio.h 2006-12-24 22:41:28.0 -0800
> > @@ -165,7 +165,7 @@ struct aio_ring_info {
> >
> > struct page
That is not possible because when multiple tasks waiting for
events, they
enter the wait queue in FIFO order, prepare_to_wait_exclusive() does
__add_wait_queue_tail(). So first io_getevents() with min_nr of 2
will
be woken up when 2 ops completes.
So switch the order of the two sleepers
On Jan 3 2007 01:52, Segher Boessenkool wrote:
>> > Leaving aside the issue of in-memory or not, I don't think
>> > it is realistic to think any completely common implementation
>> > will work for this -- it might for current SPARC+PowerPC+OLPC,
>> > but more stuff will be added over time...
>>
>
> Any details?
Well, one path I tried I couldn't help but post a blog entry about
for my friends. I'm not sure it's the direction I'll take with linux-
kernel, but the fundamentals are there: the api should be the
syscall interface, and there should be no difference between sync and
async behav
Zach Brown wrote on Tuesday, January 02, 2007 4:49 PM
> On Dec 29, 2006, at 6:31 PM, Chen, Kenneth W wrote:
> > This patch adds a wait condition to the wait queue and only wake-up
> > process when that condition meets. And this condition is added on a
> > per task base for handling multi-threaded
--- ./include/linux/aio.h.orig 2006-12-24 22:31:55.0 -0800
+++ ./include/linux/aio.h 2006-12-24 22:41:28.0 -0800
@@ -165,7 +165,7 @@ struct aio_ring_info {
struct page **ring_pages;
spinlock_t ring_lock;
- long
[snipping a bit for now]
It's easier to start merging powerpc and sparc I reckon
Well it won't hurt to merge and clean up these two first, sure.
and then, "fix"
that so that it works on x86 :-)
That works, if the goal is to just add x86/OLPC to the list of
platforms that have a device tree
This makes the modulo of ring->head into local variable head
unnecessary.
This patch removes that bogus code.
Looks fine to me:
Acked-by: Zach Brown <[EMAIL PROTECTED]>
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Wed, Jan 03, 2007 at 01:47:36AM +0100, Bodo Eggert wrote:
> Dave Jones <[EMAIL PROTECTED]> wrote:
>
> > Shrink the held_lock struct by using bitfields.
> > This shrinks task_struct on lockdep enabled kernels by 480 bytes.
>
> > * The following field is used to detect when we cross into
Given the previous patch "aio: add per task aio wait event condition"
that we properly wake up event waiting process knowing that we have
enough events to reap, it's just plain waste of time to insert itself
into a wait queue, and then immediately remove itself from the wait
queue for *every* even
Alan wrote:
Once combined mode is fixed not to abuse resources (and it originally
did it that way for a good reason I grant and am not criticising that) the
entire management for legacy mode, mixed mode and native mode resources
for an ATA device (including 0x170, 0x3F6 and other wacky magic) bec
On Tue, Jan 02, 2007 at 02:50:53PM +0100, Jens Axboe wrote:
> Yep, I suspect this patch is long overdue. Jeremy, is this enough to fix
> it for you?
Yes, the 7 second timeout is fine. It actually takes about 6.7 seconds.
I guess if "another popular OS" has a 7 second timeout that we won't find
mu
Adrian Bunk wrote:
> Documentation/feature-removal-schedule.txt |8 ---
> drivers/ieee1394/Kconfig |7 --
> drivers/ieee1394/ieee1394_core.c | 22 -
> 3 files changed, 37 deletions(-)
>
> --- linux-2.6.20-rc2-mm1/Documentation/feat
Dave Jones <[EMAIL PROTECTED]> wrote:
> Shrink the held_lock struct by using bitfields.
> This shrinks task_struct on lockdep enabled kernels by 480 bytes.
> * The following field is used to detect when we cross into an
> * interrupt context:
> */
> - int irq_co
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
I see nothing supporting this IMHO bogus claim.
Please keep in mind
On Dec 29, 2006, at 6:31 PM, Chen, Kenneth W wrote:
The AIO wake-up notification from aio_complete is really inefficient
in current AIO implementation in the presence of process waiting in
io_getevents().
Yeah, it's a real deficiency. Thanks for taking a stab at it.
This patch adds a wait
Not single thread -- but a "global OF lock" yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits, or
> The biggest problem is the huge collection of workarounds we have
> for PowerPC alone already -- if that can be moved into some
> quirk collection thing, where certain quirks are only run on some
> systems, it might scale.
Well, if you notice, I've been moving most of such workarounds to
prom_i
> On Tue, 2007-01-02 at 12:14 -0800, David Schwartz wrote:
> > > The recommendet _serving_ temperature for coffe is 55 °C or below.
> >
> > Nonsense! 55C (100F) is ludicrously low for coffee.
> >
> > 70C (125F) is the *minimum* recommended serving temperature.
> 165-190F is the
> > preferred se
Older versions of the iBase FWA7304 BIOS have a bug that causes the
system to use way too much power when you run 'init 0', causing
the power brick to burn out after about 3 hours.
The fix for this is to get an updated BIOS from the manufacturer:
IB798F-T2-CP1A-1229
The problem still happens if
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
And ? I don't see why a mostly common implementations wouldn't work,
p
> Thus, if you avoid calling pci_request_regions (as your patch does), you
> must manually provide the same guarantees that pci_request_regions
> provides to its callers.
pci_request_regions reserves only BAR4/BAR5 in legacy mode because of the
fact the resources are mashed and eventually cleaar
On Sat, 30 Dec 2006 19:10:31 +0300
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> "[PATCH 1/2] reimplement flush_workqueue()" fixed one race when CPU goes down
> while flush_cpu_workqueue() plays with it. But there is another problem, CPU
> can die before flush_workqueue() has a chance to call flush_c
> 1) Programmatically reserve /all/ resources associated with
> our PCI device
> 2) Manually reserve resources associated with our PCI device,
> but are not listed in struct pci_dev.
Which it doesn't actually do. You reserve 0x1F0-0x1F7 but forget the
other register.
> The 32bit and 64bit PARISC Linux kernels suffers from the problem, that the
> gettimeofday() call sometimes returns non-monotonic times.
This certainly needs to be fixed. I see stuff like this from ping:
64 bytes from 132.246.100.193: icmp_seq=19 ttl=255 time=0.4 ms
64 bytes from 132.246.100.
The comment used to be inside the "if" block, is this
change correct?
You'd prefer an empty line in there?
Obviously, you should change the comment to include the
conditional, if that is what is needed.
[And, do we want all these changes anyway? I don't care
either way, both sides have thei
From: James Bottomley <[EMAIL PROTECTED]>
Date: Tue, 02 Jan 2007 17:34:18 -0600
> Erm ... for a device driver, if we're preparing to do I/O on the page
> something must have made the user caches coherent ... that can't be
> kmap, because the driver might elect to DMA on the page ... unless
> anoth
from: Frithiof Jensen <[EMAIL PROTECTED]>
This patch is meant for Kernel version 2.6.19
This is a first, naive, attempt of providing an interface for memory
scrubbing in EDAC.
The following things are still outstanding:
- Only the K8 driver has been refactored with a HW scrub functio
from: Brian Pomerantz <[EMAIL PROTECTED]>
Source: MontaVista Software, Inc.
MR: 17525
Type: Defect Fix
Disposition: local
Description:
The reading of the DRA registers should be a byte at a time (one
register at a time) instead of 4 bytes at a time (four registers).
Reading a dword at
from: Frithiof Jensen <[EMAIL PROTECTED]>
This patch is meant for Kernel version 2.6.19
This is a first, naive, attempt of providing an interface for memory
scrubbing in EDAC.
The following things are still outstanding:
- Only the K8 driver has been refactored with a HW scrub functio
from: Brian Pomerantz <[EMAIL PROTECTED]>
Description:
The fatal vs. non-fatal mask for the sysbus FERR status is
incorrect
according to the E7520 datasheet. This patch corrects the mask to
correctly
handle fatal and non-fatal errors.
Signed-off-by: Brian Pomerantz <[EMAIL PROTECTED]
02.01.2007 22:57, Adrian Bunk wrote/a écrit:
This patch contains the scheduled removal of the eepro100 driver.
Hi, I've been using e100 for years with no problem, however more by
curiosity than necessity I'd like to know how will be handled the
devices which are (supposedly) supported by eepr
On Tue, 2007-01-02 at 12:14 -0800, David Schwartz wrote:
> > The recommendet _serving_ temperature for coffe is 55 °C or below.
>
> Nonsense! 55C (100F) is ludicrously low for coffee.
>
> 70C (125F) is the *minimum* recommended serving temperature. 165-190F is the
> preferred serving range. I can
I am posting this because my kernel told me so...
The attached file contains dmesg's with and without pci-assign-busses.
My hardware is a Samsung Q35 Pro. Feel free to contact me
if you need any further information.
--Michael
dmesg.bz2
Description: Binary data
Across different boots using the same 2.6.19 kernel on a quad-core xeon
I see huge variance in the migration_cost being reported during boot.
-migration_cost=39,3940
+migration_cost=25,4941
This CPU has a very large cache which could be key here...
L1 Instruction cache: 32KB, 8-way associative.
Sorry for the delay, I'm finally back from the holiday break :)
(1) The filesystem AIO patchset, attempts to address one part of
the problem
which is to make regular file IO, (without O_DIRECT)
asynchronous (mainly
the case of reads of uncached or partially cached files, and
O_SYNC
Hello Segher,
> The comment used to be inside the "if" block, is this
> change correct?
You'd prefer an empty line in there?
> [And, do we want all these changes anyway? I don't care
> either way, both sides have their pros and their cons --
> just asking :-) ]
You know my opinion already :-)
Or maybe this rephrase helps:
Regardless of how the IDE quirks have configured the PCI BARs, libata is
written to assume that /all/ struct pci_dev resources for a single PCI
device are reserved to the libata driver.
Thus, if you avoid calling pci_request_regions (as your patch does), you
mus
1 - 100 of 386 matches
Mail list logo
