On Wed, 2007-01-31 at 10:34 +0100, Ingo Molnar wrote:
> a rating change can occur due to other things as well, not only due to
> 'tsc unstable' events. So keeping an API around that changes the rating
> (and propagates all related changes), makes more sense to me.
>
> also, a pure function call
On Fri, Jan 26, 2007 at 07:52:49PM +0100, Eric Piel wrote:
> >>user "vatsa"user "guest"
> >>(make -s -j4 bzImage) (make -s -j20 bzImage)
> >>
> >>2.6.20-rc5 472.07s (real) 257.48s (real)
> >>2.6.20-rc5+fairsched76
On Wed, 2007-01-31 at 10:59 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > This is something Thomas already dropped, [...]
>
> (i think you forgot to Cc: Thomas here, nor is this something that
> Thomas' change dropped.)
Yes your right .
> > [...] and I'm just sti
On Fri, Jan 26, 2007 at 12:41:27PM -0600, Chris Friesen wrote:
> As Kirill brought up, why does it take so much more time? Are you
> thrashing the cache?
Yes, the default 1-sec control window I had was causing lot of
thrashing. See http://lkml.org/lkml/2007/1/31/142
> Presumably this would be m
Extends the numa=fake x86_64 command-line option to allow for configurable
node sizes. These nodes can be used in conjunction with cpusets for
coarse memory resource management.
The old command-line option is still supported:
numa=fake=32 gives 32 fake NUMA nodes, ignoring the NUMA setup of th
Extends the numa=fake x86_64 command-line option to split the remaining
system memory into equal-sized nodes.
For example:
numa=fake=2*512,4* gives two 512M nodes and the remaining system
memory is split into four approximately equal
chunks.
Th
Create a document to explain how to use numa=fake in conjunction with
cpusets for coarse memory resource management.
An attempt to get more awareness and testing for this feature.
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: David Rientjes <[EMAIL PROTECTED]>
---
Documentation/x86_64/fake-n
Extends the numa=fake x86_64 command-line option to split the remaining
system memory into nodes of fixed size. Any leftover memory is allocated
to a final node unless the command-line ends with a comma.
For example:
numa=fake=2*512,*128 gives two 512M nodes and the remaining system
Exports the struct bootnode array globally so that the physical mapping
can be saved when NUMA emulation is used. This is then copied and stored
for later reference so that there exists a mapping between fake nodes and
the real nodes they reside on through the get_phys_node() function.
physical_n
Disables using alien cache for slab when NUMA emulation is being used.
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
Signed-off-by: David Rientjes <[EMAIL PROTECTED]>
---
arch/x86_64/mm/numa.c |2 ++
mm/slab.c |2 +-
2 files changed, 3 inser
Exports the physical NUMA node to fake NUMA node mapping to user-space via
sysfs. The information is now accessible via the 'physnode' file.
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Rohit Seth <[EMAIL PROTECTED]>
Signed-off-by: David Rientjes <[EMAIL PROTECTED]>
---
drivers/base/node.c
On Tue, 30 Jan 2007, Robert Hancock wrote:
> Alan Stern wrote:
>
> > The log revealed that the phone's firmware returns garbage values in the
> > Residue field for some WRITEs. This patch should take care of it.
> >
> > Alan Stern
>
> Is it just me, or should some of these device quirk entrie
Eddie Pettis wrote:
Short question: Is it possible to locate the struct file * associated
with a bio? If so, how?
Longer version: I am working on a project that requires measuring the
popularity of each file in a filesystem. I have made several attempts
to locate all the file reads by greppi
On Wed, 2007-01-31 at 11:17 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > Adds a call back interface for register/rating change events. This is
> > also used later in this series to signal other interesting events.
>
> This patch adds:
>
> > +#define CLOCKSOURCE_N
Ingo Molnar wrote:
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
Easy to name an example, as they are pretty generic. When sharing
irqs -- usually ATA is configured to PCI native (IO-APIC-fasteoi) --
any interrupt storm causes the other devices sharing that irq to crap
themselves (kernel turns of
atomic.h : standardizing atomic primitives
It mainly adds support for missing 64 bits cmpxchg and 64 bits atomic add
unless. Therefore, principally 64 bits architectures are targeted by these
patches. It also adds the complete list of atomic operations on the atomic_long
type.
build tested on:
On Wed, 2007-01-31 at 11:46 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > Uses the block notifier to replace the functionality of
> > update_callback(). update_callback() was a special case specifically
> > for the tsc, but including it in the clocksource structure
On Wed, 31 Jan 2007, Rafael J. Wysocki wrote:
> On Tuesday, 30 January 2007 23:32, Rafael J. Wysocki wrote:
> > [Added linux-pm to the Cc list, because I'm going to talk about things that
> > I know only from reading the code.]
> >
> > On Tuesday, 30 January 2007 17:50, Oliver Neukum wrote:
> > >
On Wed, 31 Jan 2007, Pavel Machek wrote:
> Hi!
>
> > > Yes, it will. The process freezer can only return success if there are
> > > no more
> > > TASK_UNINTERRUPTIBLE tasks. Otherwise it fails (after a timeout).
> >
> > So, this means, on suspend():
> >
> > 1. Don't worry about TASK_UNINTERR
On Wed, 2007-01-31 at 12:07 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > Modifies the way clocks are switched to in the timekeeping code. The
> > original code would constantly monitor the clocksource list checking
> > for newly added clocksources. I modified this
On Wed, 31 Jan 2007, PaweÅ Sikora wrote:
>
> The 2.6.20-rcX have the same nasty bug as 2.6.19.x.
>
> [ an oops inside kmem_get_pages ]
> http://bugzilla.kernel.org/show_bug.cgi?id=7889
Pabel, can you detail more exactly which kernels don't work, and which do?
>From bugzilla:
- 2.6.18.x does
Am Mittwoch, 31. Januar 2007 16:54 schrieb Alan Stern:
> On Wed, 31 Jan 2007, Pavel Machek wrote:
> > "cease IO"? No, I believe it is enough not to start new I/O. Userspace
> > is frozen at that point, it can't ask you to do I/O.
>
> There may be I/O requests sitting in a queue, already submitted
When you say newbie? Do you mean coding newbie? Or... just someone who
hasn't done a driver before?
either way I'd like to be somewhat involved in the process so I see how
things are done.
--martin
Andi Kleen wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>> What? Throw a fresh-faced newbie ins
Hi Peter,
Thanks for testing Andrew's fixes. I am wondering about what happened to
the Powerpc recursive include problems Andrew experienced. Quoting him :
"OK, I fixed eight separate compile errors in this patch series and
now powerpc is being very ugly with a twisty maze of include
dependencies
On Wed, 31 Jan 2007, Oliver Neukum wrote:
> Am Mittwoch, 31. Januar 2007 16:54 schrieb Alan Stern:
> > On Wed, 31 Jan 2007, Pavel Machek wrote:
>
> > > "cease IO"? No, I believe it is enough not to start new I/O. Userspace
> > > is frozen at that point, it can't ask you to do I/O.
> >
> > There
On Wed, 2007-01-31 at 11:25 -0500, Mathieu Desnoyers wrote:
> Hi Peter,
>
> Thanks for testing Andrew's fixes.
I haven't actually taken any from him. I just started afresh.
> I am wondering about what happened to
> the Powerpc recursive include problems Andrew experienced. Quoting him :
>
> "O
On Wed, 2007-01-31 at 12:46 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > One new API call clocksource_get_clock() which allows clocks to be
> > selected based on their name, or if the name is null the highest rated
> > clock is returned.
>
> this one (and the dep
On Wed, 2007-01-31 at 12:50 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > -module_init(init_acpi_pm_clocksource);
> > +/*
> > + * This clocksource is removed from the clocksource_initcall
> > + * macro since it's mandatory for it to be in fs_initcall as the
> > + * h
Going over the bugs and warnings I found this one left over. The other
changes have already been correctly done for this driver but the actual
switch to pci_get_device that they assume has not.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/excl
Another mtd driver, another set of 32bit assumptions. Please compile mtd
stuff on 64bit now and then, or if stuff is for 32bit only systems then
add the right CONFIG rules.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.
Perhaps Adrian would care to simply delete the pci_module_init ancient compat
code so nobody else can inadvertently merge a driver that uses it.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.20-rc6-mm3/drivers/net/at
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.20-rc6-mm3/drivers/video/pm3fb.c
linux-2.6.20-rc6-mm3/drivers/video/pm3fb.c
--- linux.vanilla-2.6.20-rc6-mm3/drivers/video/pm3fb.c 2007-01-31
14:20:10.0 +
++
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.20-rc6-mm3/drivers/ata/pata_atiixp.c
linux-2.6.20-rc6-mm3/drivers/ata/pata_atiixp.c
--- linux.vanilla-2.6.20-rc6-mm3/drivers/ata/pata_atiixp.c 2007-01-31
14:20:10.00
David Chinner wrote:
On Wed, Jan 31, 2007 at 08:02:37AM +0100, Adrian Bunk wrote:
On Tue, Jan 30, 2007 at 06:36:48PM -0800, Linus Torvalds wrote:
The issue was somewhat confused by people certainly *reporting* it for
older kernels. Also, as part of the dirty bit cleanups and sanity
ch
On Wed, 31 Jan 2007, Adrian Bunk wrote:
>
> Regarding the longstanding CIFS/reiserfs/XFS problems, it seems the
> status is:
>
> CIFS:
> commit cb876f451455b6187a7d69de2c112c45ec4b7f99
> Fix up CIFS for "test_clear_page_dirty()" removal
> queued for 2.6.19.3
> applies and compiles against 2.
> When I telnet my board and run the following command:
> root:~> stty -F /dev/ttyS0 -crtscts
>
> I got the following result from the console of my board:
> root:~>new_termios flag: 0x1cb1, old_termios flag: 0x80001cb1
>
> That's correct. CRTSCTS flag is clear
>
> But when I type "ENTE
The 8237S was added to the chipsets but not to the comments. Fix this
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.20-rc6-mm3/drivers/ata/pata_via.c
linux-2.6.20-rc6-mm3/drivers/ata/pata_via.c
--- linux.vanilla-2.6.
Jeff Garzik wrote:
> Roland Dreier wrote:
>> And I seem to recall there's more SATA chipset documentation than Jeff
>> Garzik has time to implement support for.
>
> I seriously doubt you can come up with even a single concrete example here.
Not trying to slight Jeff here in any way, but I thought
On Wed, 2007-01-31 at 17:02 +, Alan wrote:
> Another mtd driver, another set of 32bit assumptions. Please compile mtd
> stuff on 64bit now and then, or if stuff is for 32bit only systems then
> add the right CONFIG rules.
We've been building MTD stuff on 64-bit machines since about 1999, when
Eric Sandeen wrote:
Jeff Garzik wrote:
Roland Dreier wrote:
And I seem to recall there's more SATA chipset documentation than Jeff
Garzik has time to implement support for.
I seriously doubt you can come up with even a single concrete example here.
Not trying to slight Jeff here in any way,
On Wed, 2007-01-31 at 13:43 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > I've included this as another user of the clocksource interface. I
> > don't see a usage for this across all achitectures. So a fully generic
> > version isn't needed.
>
> well, this impleme
The old Cyrix 5520 CPU detection code relied upon the PCI layer setup
being done earlier than the CPU setup, which is no longer true.
Fortunately we know that if the processor is a MediaGX we can do type 1
pci config accesses to check the companion chip. We thus do those
directly and from this find
Jeff Garzik wrote:
> Eric Sandeen wrote:
>> Jeff Garzik wrote:
>>> Roland Dreier wrote:
And I seem to recall there's more SATA chipset documentation than Jeff
Garzik has time to implement support for.
>>> I seriously doubt you can come up with even a single concrete example here.
>> Not t
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
include/asm-x86_64/io.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-x86_64/io.h b/include/asm-x86_64/io.h
index 6ee9fad..7d0b568 100644
--- a/include/asm-x86_64/io.h
+++ b/include/asm-x86_64/io.h
@@
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-01-31 at 12:50 +0100, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > -module_init(init_acpi_pm_clocksource);
> > > +/*
> > > + * This clocksource is removed from the clocksource_initcall
> > > + * macro since
On Jan 31, 2007, at 12:58 AM, Andi Kleen wrote:
Do you have any numbers how this compares cycle wise to just doing
clone+syscall+exit in user space?
Not yet, no. Release early, release often, and all that. I'll throw
something together.
- z
-
To unsubscribe from this list: send the line
> When looking for a sata controller I came across several inexpensive
> ones based on an Initio chipset, and at first glance it seems that they
> have docs out there*: http://www.initio.com/products/sata.htm
>
> but no drivers yet. Just in case anyone is interested :)
2.6.20-mm, although it can
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-01-31 at 11:46 +0100, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > Uses the block notifier to replace the functionality of
> > > update_callback(). update_callback() was a special case specifically
> > > f
> 1) does the scheduler know enough to try to spread tasks
> equally over both the pairs to make best use of the 16MB total
> cache? (i.e. given cpu bound processes "1" and "2", if they
> are both on CPU "A", then the "C-D" cache remains unused, but
> keeping "1" on "a" and "2" on "C" would tend t
> No amount of carefulness will prevent vendors stick arbitrarily
> damaging values of stack and mmap base randomisation, severely reducing
> the usefullness of MAP_FIXED.
MAP_FIXED is useful still. The only safe way is to use addresses you got
from mmap(), eg you overmap something.
Anything else
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > I see little difference between your and John's code: both poll
> > something - you poll an atomic "did a new clocksource arrive" flag
> > in the timer interrupt, John takes the clocksource_lock spinlock and
> > checks a "did a new clocksource arr
> -#if defined(__KERNEL__) && __x86_64__
> +#if defined(__KERNEL__) && defined(__x86_64__)
Undefined symbols are replaced with 0, so the old line was already ok.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > if (is_registered_source(c)) {
> > printk("register_clocksource: Cannot register %s. "
> > "Already registered!", c->name);
> > ret = -EBUSY;
> >
> > and Thomas' change keeps that pr
On Wednesday 31 January 2007 18:15, Zach Brown wrote:
>
> On Jan 31, 2007, at 12:58 AM, Andi Kleen wrote:
>
> > Do you have any numbers how this compares cycle wise to just doing
> > clone+syscall+exit in user space?
>
> Not yet, no. Release early, release often, and all that. I'll throw
> s
On Wed, 2007-01-31 at 09:02 -0800, Daniel Walker wrote:
> > well, this implementation is buggy in at least two ways:
> >
> > firstly, it allows a circular verification dependency in highres+dyntick
> > mode between the jiffies and tsc clocksources.
>
> In the current implementation, it's only ha
On Wed, 2007-01-31 at 18:10 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-01-31 at 12:50 +0100, Ingo Molnar wrote:
> > > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> > >
> > > > -module_init(init_acpi_pm_clocksource);
> > > > +/*
> > > > + * This clocks
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > secondly, CLOCKSOURCE_NOTIFY_REGISTER is only used by the core
> > clocksource code and no register-notifier interface is exposed: this
> > makes the whole thing an expensive NOP.
>
> I don't know what you mean when you say "no register-notifier
On Wed, Jan 31, 2007 at 11:08:14AM +0100, Andi Kleen wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
> >
> > What? Throw a fresh-faced newbie instantly into the tar-pit of despair
> > that floppy.c is? Do you want everyone just to run screaming from
> > kernel development never to be seen again?
>
Somehow the sis_info133 external definition ended up in libata.h and that
was included by both drivers. However libata.h contains libata-* specific
internals and clashing defines like DRV_NAME so this makes a mess. Move
the extern into the C file and remove the warnings
Signed-off-by: Alan Cox <[E
On Wed, 2007-01-31 at 17:00 +, Alan wrote:
> Going over the bugs and warnings I found this one left over. The other
> changes have already been correctly done for this driver but the actual
> switch to pci_get_device that they assume has not.
>
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Ap
On Wed, 2007-01-31 at 09:20 -0800, Daniel Walker wrote:
> The purpose of clocksource_initcall is so the initcall can be increased
> without changing all the individual clocksources .. So I have to
> disconnect that from the acpi_pm because it can't tolerate it.
Each clocksource has to decide on it
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > firstly, it allows a circular verification dependency in
> > highres+dyntick mode between the jiffies and tsc clocksources.
>
> In the current implementation, it's only happens if the only clocks
> that exist are "tsc" and "jiffies" which makes ve
- We would now have some measure of task_struct concurrency. Read
that twice,
it's scary.
That's the one scaring me in fact ... Maybe it will end up being an
easy
one but I don't feel too comfortable...
Indeed, that was my first reaction too. I dismissed the idea for a
good six months
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >ok. Can you suggest any way for me to reproduce such a bug
> >artificially on a test system? [i have both old and new systems, so
> >if you can think of a way for me to trigger this i'd be happy to try]
>
> Should be pretty easy. With either the old
On Wed, Jan 31, 2007 at 06:16:02PM +0100, Andi Kleen wrote:
>
> > -#if defined(__KERNEL__) && __x86_64__
> > +#if defined(__KERNEL__) && defined(__x86_64__)
>
> Undefined symbols are replaced with 0, so the old line was already ok.
Fair enough, however sparse is not very happy about underfined s
Greg KH <[EMAIL PROTECTED]> writes:
[...]
>> And there are plenty of documented devices that no one cares enough
>> about to submit a driver for.
>
> Any specific examples? I have a long list of people who wish to write
> new drivers but just don't know which hardware is not yet supported.
Maybe
It works on i386 only by accident, and doesn't work at all with UML.
start_thread, which is called from inside the set_fs(USER_DS) -
set_fs(oldfs) does set_fs(USER_DS). That is then blown away by the
set_fs(oldfs).
A one-line fix might be
Index: linux-2.6.17/fs/exec.c
==
What do these kind of errors mean???
WARNING: Can't handle masks in drivers/ide/pci/atiixp:05
WARNING: drivers/mvp/ibb.o - Section mismatch: reference to .exit.data:
from .data between 'ibb_driver' (at offset 0x94) and
'__mod_pci_device_table'
WARNING: drivers/mvp/ibb3d.o - Section mismatch: r
Does that mean that we might not have some cases where we'd need to
make
sure we do things differently? Of course not. Something migt show up.
Might, and has. For a good time, take journal_info out of
per_call_chain() in the patch set and watch it helpfully and loudly
wet itself. There r
I'm looking for assistance with a wifi device I can't find a driver for,
the Intel Wireless 3945.
I"m getting this:
:0c:00.0 Network controller: Intel Corporation: Unknown device 4222
(rev 02)
on a new Dell Latitude D820. Anyone know if there will be an open source
driver for this any time s
On Wed, Jan 31, 2007 at 09:38:11AM -0800, Zach Brown wrote:
> Indeed, that was my first reaction too. I dismissed the idea for a
> good six months after initially realizing that it implied sharing
> journal_info, etc.
>
> But when I finally sat down and started digging through the
> task_st
On Jan 30 2007 14:00, Roland Dreier wrote:
>
>An uncharitable vendor might decide it's not worth publishing specs,
>since the Linux guys can reverse engineer the Windows driver just as
>fast anyway.
And ndiswrapper gives fire to just releasing the Windows one :(
Jan
--
-
To unsubscribe from th
Ingo Molnar wrote:
19:2413090 0 IO-APIC-fasteoi uhci_hcd:usb2, libata
Yep, that's a good candidate for such experiments :)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
On Wed, 2007-01-31 at 09:39 -0800, Daniel Walker wrote:
> > please read my reply above! To repeat: such flags tend to get forgotten,
> > resulting in a less safe default behavior. Clock hardware and thus
> > clocksources are fundamentally fragile so we want to default to the
> > safest behavior.
Jan Engelhardt wrote:
On Jan 30 2007 14:00, Roland Dreier wrote:
An uncharitable vendor might decide it's not worth publishing specs,
since the Linux guys can reverse engineer the Windows driver just as
fast anyway.
And ndiswrapper gives fire to just releasing the Windows one :(
Logically th
On Wed, Jan 31, 2007 at 11:30:23AM -0600, Scott Lockwood wrote:
> on a new Dell Latitude D820. Anyone know if there will be an open source
> driver for this any time soon, or if there is one now?
Intel have a mix of open source kernel module and binary daemon for
some bits. Hopefully we'll get a
Btw, this is also something where we should just disallow certain
system
calls from being done through the asynchronous method.
Yeah. Maybe just a bitmap built from __NR_ constants? I don't know
if we can do it in a way that doesn't require arch maintainer's
attention.
It seems like it
On Jan 31 2007 08:34, David Hollis wrote:
>Conversely, I've seen many cases of drivers that are developed by the
>community, but kept out-of-kernel forever due to various reasons. Some
>of them are due to the code quality and the developers not accepting the
>feedback to get the drivers into shap
> Couldn't the cxacru instance pointer to the proc_read function be set to NULL
> before unloading?
The problem is reads that started (on some other CPU) before you started
shutting things down
(eg: but setting this to null or whatever other method you like) and only
finish after you have
finis
On Wed, 2007-01-31 at 11:30 -0600, Scott Lockwood wrote:
> I'm looking for assistance with a wifi device I can't find a driver for,
> the Intel Wireless 3945.
>
> I"m getting this:
>
> :0c:00.0 Network controller: Intel Corporation: Unknown device 4222
> (rev 02)
>
> on a new Dell Latitude D
On Wed, 2007-01-31 at 18:55 +0100, Thomas Gleixner wrote:
> On Wed, 2007-01-31 at 09:39 -0800, Daniel Walker wrote:
> > > please read my reply above! To repeat: such flags tend to get forgotten,
> > > resulting in a less safe default behavior. Clock hardware and thus
> > > clocksources are fundam
On 1/31/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
It's in good enough shape that I'd probably have been happy to just
release it as 2.6.20, but since I want 2.6.20 to be a stability release, I
didn't want to risk any stupid bugs while the regressions got fixed, so
here's a final -rc7.
It's
> I've had it polling every 200ms on a dual ppro200 since november,
> and it has never failed to poll the status.
Great, that's certainly better than the speedtouch ;)
I can't help feeling that polling twice a second is overkill.
How about changing it to poll every 5 seconds if the line is
up, an
On 31/01/07 14:27, Duncan Sands wrote:
>> The device is only polled for status every 5 seconds yet status updates
>> occur as often as every second - when the line is down the status changes
>> between "down" and "attempting to activate" every 2 seconds.
>
> How much overhead does polling involv
On 31/01/07 14:48, Duncan Sands wrote:
>> usbatm only outputs basic information via the per-device /proc/net/atm/ file,
>> this patch allows the device specific USB ATM drivers to replace the
>> atm_proc_read function with their own.
>
> I'm still meditating on this. The reason I didn't do this
> Again you misunderstood the question. The driver must start queued
I/O
> when its resume() method is called. It should then be okay for the
driver
> to call wake_up_interruptible(), even before tasks are unfrozen.
I kind of like the way MontaVista worked around this in some 2.4 drivers
where
The only thing I saw in Zach's post against the use of threads is that
some kernel API would change. But surely if this is the showstopper
then
there must be some better argument than sys_getpid()?!
Haha, yeah, that's the silly example I keep throwing around :). I
guess it does leave a lit
On Wed, 31 Jan 2007, Jan Engelhardt wrote:
On Jan 30 2007 14:00, Roland Dreier wrote:
An uncharitable vendor might decide it's not worth publishing specs,
since the Linux guys can reverse engineer the Windows driver just as
fast anyway.
And ndiswrapper gives fire to just releasing the Windo
On Jan 31 2007 18:24, Adrian Bunk wrote:
>On Wed, Jan 31, 2007 at 11:08:14AM +0100, Andi Kleen wrote:
>> Greg KH <[EMAIL PROTECTED]> writes:
>> >
>> > What? Throw a fresh-faced newbie instantly into the tar-pit of despair
>> > that floppy.c is? Do you want everyone just to run screaming from
>>
On Jan 31 2007 09:58, alan wrote:
> On Wed, 31 Jan 2007, Jan Engelhardt wrote:
>> On Jan 30 2007 14:00, Roland Dreier wrote:
>> >
>> > An uncharitable vendor might decide it's not worth publishing specs,
>> > since the Linux guys can reverse engineer the Windows driver just as
>> > fast anyway.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 31 January 2007 15:49, Alan wrote:
> > Well, I have a long standing issue with pata_ali not detecting CD-ROM in
> > DMA mode. When I rarely watch DVD I rather boot into legacy IDE kernel
> > ...
>
> There is a general problem with some ATA
Putting the "codingstyle" control aside, often it's because things look
too hackish.
Also sometimes the authors know it's hackish, or just don't expect it
to be generally useful to the world. I happen to own an out-of-tree
filesystem which I have little desire to have reviewed for mainline:
onl
Scott Lockwood wrote:
I'm looking for assistance with a wifi device I can't find a driver for,
the Intel Wireless 3945.
I"m getting this:
:0c:00.0 Network controller: Intel Corporation: Unknown device 4222
(rev 02)
on a new Dell Latitude D820. Anyone know if there will be an open source
dr
On Wed, Jan 31, 2007 at 11:54:35AM +0100, Duncan Sands wrote:
> Can read_proc still be executing when remove_proc_entry returns?
>
> In my driver [*] I allocate some data and create a proc entry using
> create_proc_entry. My read method reads from my allocated data. When
> shutting down, I call r
On Jan 31 2007 16:18, Helge Hafting wrote:
> Eddie Pettis wrote:
>> Longer version: I am working on a project that requires measuring the
>> popularity of each file in a filesystem. I have made several attempts
>> to locate all the file reads by grepping for ->readpage() and
>> ->readpages() cal
On Wednesday, 31 January 2007 16:48, Alan Stern wrote:
> On Wed, 31 Jan 2007, Rafael J. Wysocki wrote:
>
> > On Tuesday, 30 January 2007 23:32, Rafael J. Wysocki wrote:
> > > [Added linux-pm to the Cc list, because I'm going to talk about things
> > > that
> > > I know only from reading the code.
On 1/31/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
Eddie Pettis wrote:
> Short question: Is it possible to locate the struct file * associated
> with a bio? If so, how?
>
Looks like you do this the wrong way.
Agreed. It was a bad hack based on something I had done previously.
Why don't
On Wed, Jan 31, 2007 at 07:24:54PM +0100, Jan Engelhardt wrote:
> How much different hardware does the (old)floppy.c do? I imagine that
> today, where floppies phase out, there will be, in descending order:
>
> * USB floppy drives (atm handled by sd.c, could be better to have sf.c)
> * FDCs on m
On Sun, Jan 28, 2007 at 04:24:35PM +0100, Ingo Molnar wrote:
>
> * Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Jan 28, 2007 at 12:51:21PM +0100, Peter Zijlstra wrote:
> > > This barrier thing is constructed so that it will not write in the
> > > sync() condition (the hot path) whe
On Wed, 31 Jan 2007, Jan Engelhardt wrote:
On Jan 31 2007 09:58, alan wrote:
On Wed, 31 Jan 2007, Jan Engelhardt wrote:
On Jan 30 2007 14:00, Roland Dreier wrote:
An uncharitable vendor might decide it's not worth publishing specs,
since the Linux guys can reverse engineer the Windows drive
101 - 200 of 413 matches
Mail list logo
