Fawad Lateef is still waiting to hear from you to join their mobile friends
community.
Guess what? You now have 1 friend that have invited you to their mobile network!
These friend are waiting for you to accept:
Fawad Lateef
Click the link below to see your friend? photos and accept their
Hello,
This patch add function called "Live patching" which is defined on
OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7 kernel.
The live patching allows process to patch on-line (without restarting
process) on i386 and x86_64 architectures, by overwriting jump
Ralf Hildebrandt <[EMAIL PROTECTED]> wrote:
> Most UNIX variants disable core dumps in programs that have changed their
> uid or euid during operation. This includes Solaris and Linux.
>
> Well, squid does exactly that. How can I still get a coredump? I really
> need one. Kernel 2.6.11.7
It
Jean-Luc Cooke wrote:
>The part which suggests choosing an irreducible poly and a value "a" in the
>preprocessing stage ... last I checked the value for a and the poly need to
>be secret. How do you generate poly and a, Catch-22? Perhaps I'm missing
>something and someone can point it out.
I
linux wrote:
>Thank you for pointing out the paper; Appendix A is particularly
>interesting. And the [BST03] reference looks *really* nice! I haven't
>finished it yet, but based on what I've read so far, I'd like to
>*strongly* recommnd that any would-be /dev/random hackers read it
>carefully.
linux wrote:
>3) Fortuna's design doesn't actually *work*. The authors' analysis
> only works in the case that the entropy seeds are independent, but
> forgot to state the assumption. Some people reviewing the design
> don't notice the omission.
Ok, now I understand your objection. Yup,
> NO! DO NOT use pci_find_device(). It is broken for systems with pci
> hotplug (which means any pci system). Please use the way the driver
> currently works, that is correct.
But its not an LPC driver, it only uses a small piece of the LPC, we
really do need some sort of bridge driver layer
Hacksaw wrote:
>What I would expect the kernel to do is this:
>
>system_call_data_prep (userdata, size){ [...]
> for each page from userdata to userdata+size
> {
> if the page is swapped out, swap it in
> if the page is not owned by the user process, return
linux wrote:
>David Wagner wrote:
>>linux wrote:
>>> First, a reminder that the design goal of /dev/random proper is
>>> information-theoretic security. That is, it should be secure against
>>> an attacker with infinite computational power.
>
>> I am skeptical.
>> I have never seen any convincing
Matt M. Valites wrote:
Hail List,
I've been banging my head against this for a few days, and I wanted to
see if anyone here could lend a hand.
I have the following configuration:
P4 3.x Ghz
2GB Ram;
2 x 36GB WD Raptors; in a RAID1 (sda)
2 x 74GB WD Raptor (those 10K RPM SATA drives) in a
Ralf Hildebrandt wrote:
I found this while trying to find out why squid doesn't produce a core
file:
http://lists.samba.org/archive/samba-technical/2002-August/023576.html
Most UNIX variants disable core dumps in programs that have changed their
uid or euid during operation. This includes Solaris
> stack. (There exists also NIST written Linux version at that site,
> and it seems to be "BSD with advertisement clause" licensed...)
>
Sorry to interrupt but I wanted to mention that if the code you are refering to
was writtent by a NIST researcher it should be copyright free (aka public
hi, everyone,
Recently, I program a script like NAT, but I have no idea how to let it
possess more cpu resource?
you know, in user space process is a small unit which possess the cpu
and is controlled by schedule function. but in kernel space, it seems
not the same thing as it in user
-
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
Please read the FAQ at http://www.tux.org/lkml/
>Have you edit the build-initrd.sh script to fit your needs?
Yeah.. but it shouldn't matter much since I've not been able to load the initrd
yet?
>Does
> http://featherlinux.berlios.de/usb-instructions.htm or
> http://www.ussg.iu.edu/hypermail/linux/kernel/0211.1/0551.html help?)
I thought
>I don't think syslinux digs the "/" in the initrd filename. Did you try
>it with initrd=initrd.gz?
Yep no difference.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sat, 16 Apr 2005, Hacksaw wrote:
> >if you want actual concrete examples, let me know.
> I'd love a few, but maybe privately?
>
>
> I can certainly see where always copying is simpler; I certainly consider this
> to be an optimization, which must be looked at carefully, lest you end up with
>
On Sat, Apr 16, 2005 at 05:16:22PM -, [EMAIL PROTECTED] wrote:
> > "How does the entropy estimator measure entropy of the event?" becomes a
> > crucial concern here. What if, by your leading example, there is 1/2 bit
> > of entropy in each event? Will the estimator even account for 1/2 bits?
On Sat, Apr 16, 2005 at 10:05:55AM -, [EMAIL PROTECTED] wrote:
> MErging e-mails, first from [EMAIL PROTECTED]:
> > You really ought to look at the _current_ implementation. There is no
> > SHA1 code in random.c.
>
> So I'm imagining the call to sha_transform() in 2.6.12-rc2's
>
--- Rajesh Shah <[EMAIL PROTECTED]> wrote:
> > Is p2p hotplug in your roadmap (for i386) ?
>
> I believe others are already working on it. I expect to free up
> a bit more in a couple of weeks. If I don't see any patches or
> indication of activity by then, I'll work on adding this support
>
All,
[EMAIL PROTECTED] said:
>> Thanks for that info! I'm starting to suspect media too. I'll try to
>> wreste that firmware upgrade into it. Which firmware version are you
>> using?
>
> I've got version R1.07 of the firmware.
Through a very painful procedure I got w98 installed and bumped my
* jamal <[EMAIL PROTECTED]> 2005-04-16 12:04
> The rule of "optimize for the common" fails miserably in this case
> because this is not a common case/usage of qdiscs.
I tend to agree. OTOH, I use exactly such setups... ;->
> I have a feeling though that the patch went in due to
>
I found this while trying to find out why squid doesn't produce a core
file:
http://lists.samba.org/archive/samba-technical/2002-August/023576.html
Most UNIX variants disable core dumps in programs that have changed their
uid or euid during operation. This includes Solaris and Linux.
Well,
I usually never complain, or give negative motivation, but this is a
reality.
Now, what's wrong with that ?
Well, the fact is that new hardware is only supported by latest kernel,
so at the end, you have to upgrade, and so you get more and more complexity
whether you like it or not.
As an
you should have a look at http://linux.chapter7.ch/touchkit/
it contains a howto and a calibration progam. it's centered around
touchscreens with eGalax controllers but the info there is valid for
about every touchscreen as long as the driver uses the linux input
subsystem (it really should).
Hi David,
On Fri, 15 Apr 2005 15:45:02 +0100 David Howells <[EMAIL PROTECTED]> wrote:
>
> @@ -746,10 +747,79 @@ static void *do_smb_super_data_conv(void
> return raw_data;
> }
>
> +struct compat_nfs_string {
> + compat_uint_t len;
> + compat_uptr_t __user data;
Hail List,
I've been banging my head against this for a few days, and I wanted to
see if anyone here could lend a hand.
I have the following configuration:
P4 3.x Ghz
2GB Ram;
2 x 36GB WD Raptors; in a RAID1 (sda)
2 x 74GB WD Raptor (those 10K RPM SATA drives) in a RAID1(sdb)
Two free PCI-X
> Yes I saw that the first time, just struck me as "why? why did I have to sit
> here and add a that to the litany of things to remember when it's so easy to
> just do it right?"
Huh? Why? Because it's faster and less code, that's why.
In what conceivable way is it NOT right?
On little-endian
On Sat, 16 Apr 2005, Hubert Tonneau wrote:
I just have to second some of the problems you have run into.
. There is still a memory leak trouble (probably in tigon3 driver since others
reported so on kernel mailing list, and tigon3 is not a geek hardware since
most nowdays lowend servers use
I started to move production servers to kernel 2.6 a year ago, but the
strange situation is that one year later, most of them are back to 2.4
This did not append with 2.0 -> 2.2 or 2.2 -> 2.4 upgrade.
Here are the factual technical reasons:
Right from the beginning, the core 2.6 kernel was rock
On Sat, Apr 16, 2005 at 06:47:13PM +1000, Dave Airlie wrote:
> >
> > The AGP and DRM modules load fine, but when xdm starts, I have no
> > direct rendering.
> >
> > The machine is an ASUS A7V8x-x with VIA chipset KT400. The video card
> > is a Matrox G400 DualHead. I've had the exact
Hi
(please cc me)
The sata_nv patch[1] (merged in 2.6.11-rc4) to enable future NVIDIA SATA
pci ids catches all NVIDIA pci devices with the ide class. This breaks
automatic module loading for e.g. nForce2 ide controllers and thereby
renders nForce systems loading modules already in
> Correct me if I'm wrong here, but uniformity of the linear function isn't
> sufficent even if we implemented like this (right now it's more a+X than
> a X).
>
> The part which suggests choosing an irreducible poly and a value "a" in the
> preprocessing stage ... last I checked the value for a
This patch removes a redundant NULL check before kfree() - kfree handles
NULL pointers just fine so there's no need to check first.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/macintosh/adbhid.c |3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
---
On Sat, 2005-16-04 at 13:34 +0200, Thomas Graf wrote:
> * Herbert Xu <[EMAIL PROTECTED]> 2005-04-16 21:23
> > On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
> > >
> > > It's not completely useless, it speeds up the deletion classful
> > > qdiscs having some depth. However, it's not
This patch removes redundant NULL pointer checks before kfree() in all of
drivers/ieee1394/
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/ieee1394/nodemgr.c |3 +--
drivers/ieee1394/ohci1394.c |2 +-
drivers/ieee1394/video1394.c | 29 -
3
On Sat, Apr 16, 2005 at 10:05:55AM -, [EMAIL PROTECTED] wrote:
> Anyway, back to the long-suffering [EMAIL PROTECTED]:
;)
> >> something? Because it makes zero difference, and reduces the code
> >> size and execution time. Which is obviously a Good Thing.)
>
> > It just bugged me when I
On Sat, Apr 16, 2005 at 06:47:13PM +1000, Dave Airlie wrote:
> You didn't load the agp chipset module..
> it would be nice if it happened automatically...
Spot on - thanks man. Will update rc scripts from 2.4. Thanks!
--
Ross Vandegrift
[EMAIL PROTECTED]
"The good Christian should beware of
On Sat, Apr 16, 2005 at 11:10:33AM -, [EMAIL PROTECTED] wrote:
> Thank you for pointing out the paper; Appendix A is particularly
> interesting. And the [BST03] reference looks *really* nice! I haven't
> finished it yet, but based on what I've read so far, I'd like to
> *strongly* recommnd
Steven Rostedt wrote:
On Sat, 2005-04-16 at 09:05 -0400, john cooper wrote:
Sven Dietrich wrote:
[...]
This one probably should be a raw_spinlock.
This lock is only held to protect access to the queues.
Since the queues are already priority ordered, there is
little benefit to ordering -the order
On Sat, 2005-04-16 at 14:56 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > This patch fixes a couple more issues with the management of the GPIOs
> > dealing with headphone and line out mute on the G5. It should fix the
> > remaining problems of people not
On Sat, 2005-04-16 at 09:05 -0400, john cooper wrote:
> Sven Dietrich wrote:
[...]
> > This one probably should be a raw_spinlock.
> > This lock is only held to protect access to the queues.
> > Since the queues are already priority ordered, there is
> > little benefit to ordering -the order of
hello,
I am checking some conditions in packet after IP
header is removed and based on that want network stack
to discard skbuff so i add it in ip_input.c .
But it gives oops message that
Warning: kfree_skb passed an skb still on a list and
then prints oops
Please help how to
On Fri, 15 Apr 2005, Ingo Molnar wrote:
>
> * Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> > As per this patch perhaps? :
> >
> > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
>
> this is still not enough (there was one more comparison to cover). Also,
> it's a bit cleaner to just cast the
Sven Dietrich wrote:
/** A fuqueue, a prioritized wait queue usable from
kernel space. */
struct fuqueue {
spinlock_t lock;
struct plist wlist;
struct fuqueue_ops *ops;
};
Would the above spinlock_t be a raw_spinlock_t? This goes
back to my first question.
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> This patch fixes a couple more issues with the management of the GPIOs
> dealing with headphone and line out mute on the G5. It should fix the
> remaining problems of people not getting any sound out of the headphone
> jack.
There's still a
>> /dev/urandom depends on the strength of the crypto primitives.
>> /dev/random does not. All it needs is a good uniform hash.
>
> That's not at all clear. I'll go farther: I think it is unlikely
> to be true.
>
> If you want to think about cryptographic primitives being arbitrarily
> broken,
* Herbert Xu <[EMAIL PROTECTED]> 2005-04-16 21:23
> On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
> >
> > It's not completely useless, it speeds up the deletion classful
> > qdiscs having some depth. However, it's not worth the locking
> > troubles I guess.
>
> RCU is meant to
On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
>
> It's not completely useless, it speeds up the deletion classful
> qdiscs having some depth. However, it's not worth the locking
> troubles I guess.
RCU is meant to optimise the common reader path. In this case
that's the packet
On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
>
> qdisc_destroy can still be invoked without qdisc_tree_lock via the
> deletion of a class when it calls qdisc_destroy to destroy its
> leaf qdisc.
Indeed. Fortuantely HTB seems to be safe as it calls sch_tree_lock
which is another
Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
>
> What about the use of atomic operations on frv? Are they more lightweight
> than a semaphore, making for a better fastpath?
What do you mean? Atomic ops don't compare to semaphores.
On FRV atomic ops don't disable interrupts; they reserve one
>> First, a reminder that the design goal of /dev/random proper is
>> information-theoretic security. That is, it should be secure against
>> an attacker with infinite computational power.
> I am skeptical.
> I have never seen any convincing evidence for this claim,
> and I suspect that there
Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> AFAICS You grab the wait_queue_t lock once in down()/__mutex_lock()
> order to try to take the lock (or queue the waiter if that fails), then
> once more in order to pass the mutex on to the next waiter on
> up()/mutex_unlock(). That is more or less
* Herbert Xu <[EMAIL PROTECTED]> 2005-04-16 11:49
> On Fri, Apr 15, 2005 at 10:54:22PM +, Thomas Graf wrote:
> >
> > Another case were it's not locked is upon a deletion of a class where
> > the class deletes its inner qdisc, although there is only one case
> > how this can happen and that's
Bodo Eggert <[EMAIL PROTECTED]> wrote:
Bodo Eggert <[EMAIL PROTECTED]> wrote:
Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
Is there a way to check what firmware a drive has
The obvious one: hdparm
Or, since hdparm doesn't work for SCSI devices,
cat /sys/block/sd$n/device/rev
(might depend on
On Fri, 2005-04-15 at 18:26 -0400, Kyle Moffett wrote:
> I've been getting the following message in syslog on a couple of my
> servers
> recently:
>
> > Apr 15 16:41:18 king kernel: scsi: unknown opcode 0x80
I now am seeing the same error messages on my 3ware 9000 controller
running kernel
MErging e-mails, first from [EMAIL PROTECTED]:
> You really ought to look at the _current_ implementation. There is no
> SHA1 code in random.c.
So I'm imagining the call to sha_transform() in 2.6.12-rc2's
extract_buf()? The SHA1 code has been moved to lib/sha1.c, so there's
no SHA1 code
> Looks like Andrew's patch bomb script needs some rate limiting ;-)
sendpatchset has that, already builtin ;)
http://www.speakeasy.org/~pj99/sgi/sendpatchset
Though the 5 second delay might not be enough for someone
publishing at the rate Andrew does.
--
I won't
Andrew wrote:
> I never got around to setting that up, plus the Subject:s pretty quickly
> become invisible when they're indented 198 columns in GUI MUAs.
My sendpatchset tool should be good for this. It sends all but the
first message are sent in "Reference" to, and "In-Reply-To" the first
>
> The AGP and DRM modules load fine, but when xdm starts, I have no
> direct rendering.
>
> The machine is an ASUS A7V8x-x with VIA chipset KT400. The video card
> is a Matrox G400 DualHead. I've had the exact same video card working
> with different motherboards.
>
> Here is the only DRM
> "merge" does a better job than "diff3" since it can resolve the
The merge command I know of is part of Tichy's RCS tools,
and calls diff3, and has no inherent superior abilities.
Is this the merge command you have in mind here?
--
I won't rest till it's the best ...
>if you want actual concrete examples, let me know.
I'd love a few, but maybe privately?
I can certainly see where always copying is simpler; I certainly consider this
to be an optimization, which must be looked at carefully, lest you end up with
that which speed things up a little, but adds a
On Sat, Apr 16, 2005 at 04:38:52AM +0200, Adrian Bunk wrote:
> In the Linux kernel, it's more common to put such header dependencies
> for header files into the C files, but if the ACPI people agree a patch
> to add the #include to acpi_bus.h is the other possble
> correct solution for this
Hello everyone,
I recently upgraded to 2.6.11.5 (back when it came out) from 2.4.
One of the reasons I upgraded was to get DRM working with my computer
again.
The AGP and DRM modules load fine, but when xdm starts, I have no
direct rendering.
The machine is an ASUS A7V8x-x with VIA chipset
Hello everyone,
I recently upgraded to 2.6.11.5 (back when it came out) from 2.4.
One of the reasons I upgraded was to get DRM working with my computer
again.
The AGP and DRM modules load fine, but when xdm starts, I have no
direct rendering.
The machine is an ASUS A7V8x-x with VIA chipset
On Sat, Apr 16, 2005 at 04:38:52AM +0200, Adrian Bunk wrote:
In the Linux kernel, it's more common to put such header dependencies
for header files into the C files, but if the ACPI people agree a patch
to add the #include linux/config.h to acpi_bus.h is the other possble
correct solution
if you want actual concrete examples, let me know.
I'd love a few, but maybe privately?
I can certainly see where always copying is simpler; I certainly consider this
to be an optimization, which must be looked at carefully, lest you end up with
that which speed things up a little, but adds a
merge does a better job than diff3 since it can resolve the
The merge command I know of is part of Tichy's RCS tools,
and calls diff3, and has no inherent superior abilities.
Is this the merge command you have in mind here?
--
I won't rest till it's the best ...
The AGP and DRM modules load fine, but when xdm starts, I have no
direct rendering.
The machine is an ASUS A7V8x-x with VIA chipset KT400. The video card
is a Matrox G400 DualHead. I've had the exact same video card working
with different motherboards.
Here is the only DRM output
Andrew wrote:
I never got around to setting that up, plus the Subject:s pretty quickly
become invisible when they're indented 198 columns in GUI MUAs.
My sendpatchset tool should be good for this. It sends all but the
first message are sent in Reference to, and In-Reply-To the first
message.
Looks like Andrew's patch bomb script needs some rate limiting ;-)
sendpatchset has that, already builtin ;)
http://www.speakeasy.org/~pj99/sgi/sendpatchset
Though the 5 second delay might not be enough for someone
publishing at the rate Andrew does.
--
I won't rest
MErging e-mails, first from [EMAIL PROTECTED]:
You really ought to look at the _current_ implementation. There is no
SHA1 code in random.c.
So I'm imagining the call to sha_transform() in 2.6.12-rc2's
extract_buf()? The SHA1 code has been moved to lib/sha1.c, so there's
no SHA1 code
On Fri, 2005-04-15 at 18:26 -0400, Kyle Moffett wrote:
I've been getting the following message in syslog on a couple of my
servers
recently:
Apr 15 16:41:18 king kernel: scsi: unknown opcode 0x80
I now am seeing the same error messages on my 3ware 9000 controller
running kernel 2.6.11
Bodo Eggert [EMAIL PROTECTED] wrote:
Bodo Eggert [EMAIL PROTECTED] wrote:
Tomasz Chmielewski [EMAIL PROTECTED] wrote:
Is there a way to check what firmware a drive has
The obvious one: hdparm
Ingrid
Or, since hdparm doesn't work for SCSI devices,
cat /sys/block/sd$n/device/rev
(might depend on
* Herbert Xu [EMAIL PROTECTED] 2005-04-16 11:49
On Fri, Apr 15, 2005 at 10:54:22PM +, Thomas Graf wrote:
Another case were it's not locked is upon a deletion of a class where
the class deletes its inner qdisc, although there is only one case
how this can happen and that's under rtnl
Trond Myklebust [EMAIL PROTECTED] wrote:
AFAICS You grab the wait_queue_t lock once in down()/__mutex_lock()
order to try to take the lock (or queue the waiter if that fails), then
once more in order to pass the mutex on to the next waiter on
up()/mutex_unlock(). That is more or less the
First, a reminder that the design goal of /dev/random proper is
information-theoretic security. That is, it should be secure against
an attacker with infinite computational power.
I am skeptical.
I have never seen any convincing evidence for this claim,
and I suspect that there are cases
Benjamin LaHaise [EMAIL PROTECTED] wrote:
What about the use of atomic operations on frv? Are they more lightweight
than a semaphore, making for a better fastpath?
What do you mean? Atomic ops don't compare to semaphores.
On FRV atomic ops don't disable interrupts; they reserve one of the
On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
qdisc_destroy can still be invoked without qdisc_tree_lock via the
deletion of a class when it calls qdisc_destroy to destroy its
leaf qdisc.
Indeed. Fortuantely HTB seems to be safe as it calls sch_tree_lock
which is another name
On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
It's not completely useless, it speeds up the deletion classful
qdiscs having some depth. However, it's not worth the locking
troubles I guess.
RCU is meant to optimise the common reader path. In this case
that's the packet
* Herbert Xu [EMAIL PROTECTED] 2005-04-16 21:23
On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
It's not completely useless, it speeds up the deletion classful
qdiscs having some depth. However, it's not worth the locking
troubles I guess.
RCU is meant to optimise the
/dev/urandom depends on the strength of the crypto primitives.
/dev/random does not. All it needs is a good uniform hash.
That's not at all clear. I'll go farther: I think it is unlikely
to be true.
If you want to think about cryptographic primitives being arbitrarily
broken, I think
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
This patch fixes a couple more issues with the management of the GPIOs
dealing with headphone and line out mute on the G5. It should fix the
remaining problems of people not getting any sound out of the headphone
jack.
There's still a minor
Sven Dietrich wrote:
/** A fuqueue, a prioritized wait queue usable from
kernel space. */
struct fuqueue {
spinlock_t lock;
struct plist wlist;
struct fuqueue_ops *ops;
};
Would the above spinlock_t be a raw_spinlock_t? This goes
back to my first question.
On Fri, 15 Apr 2005, Ingo Molnar wrote:
* Jesper Juhl [EMAIL PROTECTED] wrote:
As per this patch perhaps? :
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
this is still not enough (there was one more comparison to cover). Also,
it's a bit cleaner to just cast the left side to
hello,
I am checking some conditions in packet after IP
header is removed and based on that want network stack
to discard skbuff so i add it in ip_input.c .
But it gives oops message that
Warning: kfree_skb passed an skb still on a list and
then prints oops
Please help how to
On Sat, 2005-04-16 at 09:05 -0400, john cooper wrote:
Sven Dietrich wrote:
[...]
This one probably should be a raw_spinlock.
This lock is only held to protect access to the queues.
Since the queues are already priority ordered, there is
little benefit to ordering -the order of insertion-
On Sat, 2005-04-16 at 14:56 +0200, Andreas Schwab wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
This patch fixes a couple more issues with the management of the GPIOs
dealing with headphone and line out mute on the G5. It should fix the
remaining problems of people not getting
Steven Rostedt wrote:
On Sat, 2005-04-16 at 09:05 -0400, john cooper wrote:
Sven Dietrich wrote:
[...]
This one probably should be a raw_spinlock.
This lock is only held to protect access to the queues.
Since the queues are already priority ordered, there is
little benefit to ordering -the order
On Sat, Apr 16, 2005 at 11:10:33AM -, [EMAIL PROTECTED] wrote:
Thank you for pointing out the paper; Appendix A is particularly
interesting. And the [BST03] reference looks *really* nice! I haven't
finished it yet, but based on what I've read so far, I'd like to
*strongly* recommnd that
On Sat, Apr 16, 2005 at 06:47:13PM +1000, Dave Airlie wrote:
You didn't load the agp chipset module..
it would be nice if it happened automatically...
Spot on - thanks man. Will update rc scripts from 2.4. Thanks!
--
Ross Vandegrift
[EMAIL PROTECTED]
The good Christian should beware of
On Sat, Apr 16, 2005 at 10:05:55AM -, [EMAIL PROTECTED] wrote:
Anyway, back to the long-suffering [EMAIL PROTECTED]:
;)
something? Because it makes zero difference, and reduces the code
size and execution time. Which is obviously a Good Thing.)
It just bugged me when I was reading
This patch removes redundant NULL pointer checks before kfree() in all of
drivers/ieee1394/
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/ieee1394/nodemgr.c |3 +--
drivers/ieee1394/ohci1394.c |2 +-
drivers/ieee1394/video1394.c | 29 -
3
On Sat, 2005-16-04 at 13:34 +0200, Thomas Graf wrote:
* Herbert Xu [EMAIL PROTECTED] 2005-04-16 21:23
On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
It's not completely useless, it speeds up the deletion classful
qdiscs having some depth. However, it's not worth the
This patch removes a redundant NULL check before kfree() - kfree handles
NULL pointers just fine so there's no need to check first.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/macintosh/adbhid.c |3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
---
Correct me if I'm wrong here, but uniformity of the linear function isn't
sufficent even if we implemented like this (right now it's more a+X than
a dot X).
The part which suggests choosing an irreducible poly and a value a in the
preprocessing stage ... last I checked the value for a and
Hi
(please cc me)
The sata_nv patch[1] (merged in 2.6.11-rc4) to enable future NVIDIA SATA
pci ids catches all NVIDIA pci devices with the ide class. This breaks
automatic module loading for e.g. nForce2 ide controllers and thereby
renders nForce systems loading modules already in
On Sat, Apr 16, 2005 at 06:47:13PM +1000, Dave Airlie wrote:
The AGP and DRM modules load fine, but when xdm starts, I have no
direct rendering.
The machine is an ASUS A7V8x-x with VIA chipset KT400. The video card
is a Matrox G400 DualHead. I've had the exact same video card
I started to move production servers to kernel 2.6 a year ago, but the
strange situation is that one year later, most of them are back to 2.4
This did not append with 2.0 - 2.2 or 2.2 - 2.4 upgrade.
Here are the factual technical reasons:
Right from the beginning, the core 2.6 kernel was rock
On Sat, 16 Apr 2005, Hubert Tonneau wrote:
I just have to second some of the problems you have run into.
. There is still a memory leak trouble (probably in tigon3 driver since others
reported so on kernel mailing list, and tigon3 is not a geek hardware since
most nowdays lowend servers use
1 - 100 of 127 matches
Mail list logo
