From: Joe Perches [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 15:38:54 -0800
Change IPV4 specific macros LOOPBACK MULTICAST LOCAL_MCAST BADCLASS and
ZERONET
macros to inline functions ipv4_is_type(__be32 addr)
Adds type safety and arguably some readability.
Changes since last submission:
Rene Herman wrote:
Well, I suppose. With stuff inline, constantly reloading dx also bloats
things up a bit but yes, out of line who cares. Do you think this
version is better?
It probably comes down to which version is bigger (you probably also
want to try uninlining.)
In the boot
Ingo Molnar wrote:
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Pavel Machek wrote:
this is also something for v2.6.24 merging.
As much as I like this patch, I do not think it is suitable for
.24. Too risky, I'd say.
No kidding! We're talking about removing a hack that has been
successful on
From: Joe Perches [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 15:39:01 -0800
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Applied, thanks for doing this work Joe.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Sun, 16 Dec 2007 14:46:36 +0100 (CET) Krzysztof Oledzki [EMAIL PROTECTED]
wrote:
Which filesystem, which mount options
- ext3 on RAID1 (MD): / - rootflags=data=journal
It wouldn't surprise me if this is specific to data=journal: that
journalling mode is pretty complex wrt
On Monday 10 December 2007, Theodore Tso wrote:
On Tue, Nov 20, 2007 at 06:00:12PM -0500, Theodore Tso wrote:
Basically, the only way to solve this problem 100% in userspace would
be with a userspace daemon running as a privileged user, and some kind
of Unix domain socket.
Patches to
On Sun, Dec 16, 2007 at 01:15:58PM -0800, Randy Dunlap wrote:
btw., if anyone feels so inclined, this file has quite a number of
coding style issues, as per scripts/checkpatch.pl output:
total: 28 errors, 54 warnings, 1221 lines checked
Cleanup umem driver: fix all checkpatch
Just using cp to read the file is enough to cause problems but I included
a very basic program below that produces the BUG_ON checks. Is this a known
issue or am I using the interface incorrectly?
I'd say you're using it correctly but you've found a hitherto unknown bug.
On i386 highmem
On (14/12/07 13:07), Mark Lord didst pronounce:
SNIP
That (also) works for me here, regularly generating 64KB I/O segments with
SLAB.
Brilliant. Thanks a lot Mark.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick
On Sun, Dec 16, 2007 at 10:50:17PM +0100, Rafael J. Wysocki wrote:
Hi,
IMHO, something like the patch below is needed to fix builds with make O=,
since after commit 18c32dac75b187d1a4e858f3cfdf03e844129f5e
kbuild: fix building with O=.. options the top-level Makefile is no longer
created
On Sun, Dec 16, 2007 at 05:32:51PM +, Adrian McMenamin wrote:
On Sun, 2007-12-16 at 18:50 +0900, Paul Mundt wrote:
+ for (count = 0xa000; count 0xa020; count += 4)
+ ctrl_inl(count);
Er? This ranged dummy reading of the P2 space needs some explanation. The
GD-ROM
From: Andrew Morton [EMAIL PROTECTED]
Date: Fri, 14 Dec 2007 15:36:33 -0800
The networking bug looks to be around sock_i_ino()'s taking of
sk_callback_lock with softirq's enabled. Perhaps this will fix it.
One should be suspicious of any case where write_lock is performed
on
From: Herbert Xu [EMAIL PROTECTED]
Date: Sun, 16 Dec 2007 11:41:20 +0800
[PACKET]: Fix /proc/net/packet crash due to bogus private pointer
The seq_open_net patch changed the meaning of seq-private.
Unfortunately it missed two spots in AF_PACKET, which still
used the old way of dereferencing
On Sun, 16 Dec 2007 06:55:51 -0800 jeffunit [EMAIL PROTECTED] wrote:
At 03:05 AM 12/16/2007, Andrew Morton wrote:
On Fri, 07 Dec 2007 19:49:52 -0800 jeffunit [EMAIL PROTECTED] wrote:
I am running linux kernel 2.6.23.1, which I compiled.
The base system was mandriva 2008.
I have a
If someone can get in touch with the kerneltrap.org folks, I had to
unsubscribe them site-wide because they are bouncing with:
- 550 5.7.1 [EMAIL PROTECTED]: Recipient address rejected: Spam
prevention (C1214)
for pretty much every list posting on every mailing list.
Thanks.
--
To
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Fri, 14 Dec 2007 22:14:29 +0200 (EET)
Could you either drop my recent patches (+one fix to them from Herbert
Xu == [TCP]: Fix crash in tcp_advance_send_head), all mine after [TCP]:
Abstract tp-highest_sack accessing point to next skb from
On Sun, 16 Dec 2007 15:10:14 -0500 Miles Lane [EMAIL PROTECTED] wrote:
On Dec 16, 2007 3:19 AM, Herbert Xu [EMAIL PROTECTED] wrote:
On Sat, Dec 15, 2007 at 11:56:04PM -0800, Andrew Morton wrote:
On Sun, 16 Dec 2007 01:37:01 -0500 Miles Lane [EMAIL PROTECTED] wrote:
On Sun, Dec 16,
Hi folks,
Is there a way to replace the system beep by something more
melodic?
I remember some 10 years ago there was a patch for the kernel
to call an external beep daemon playing an audio file instead
(no kidding). But it never worked very well. Sometimes there
was a huge delay, and some
David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 11:12:32 +1100
[INET]: Export non-blocking flags to proto connect call
Previously we made connect(2) block on IPsec SA resolution. This is
good in general but not desirable for non-blocking sockets.
To fix this
On Sun, Dec 16, 2007 at 05:01:17PM -0300, Rafael Sisto wrote:
Thank you for the quick answer, but It's a college project, and I must
share user level memory. I also must build my own system calls...
But I can look what is already done and make something similar. Do you
think shmget would do?
On Dec 16 2007 23:25, Harald Dunkel wrote:
Hi folks,
Is there a way to replace the system beep by something more
melodic?
I remember some 10 years ago there was a patch for the kernel
to call an external beep daemon playing an audio file instead
(no kidding). But it never worked very
On Saturday December 15, [EMAIL PROTECTED] wrote:
On Dec 14, 2007 7:26 AM, NeilBrown [EMAIL PROTECTED] wrote:
Given an fd on a block device, returns a string like
/block/sda/sda1
which can be used to find related information in /sys.
As pointed out to when you came up
Tetsuo Handa wrote:
Hello.
Matti Aarnio wrote:
Does vger.kernel.org have spam filter and automatically drop spams?
Yes. Yes. And even worse: SILENTLY drop it. The reason was:
global taboo header: m!OJFS!
I don't recall why that was declared taboo, but it apparently bites
on
Ingo Molnar wrote:
* Harvey Harrison [EMAIL PROTECTED] wrote:
No differences except for the defintion of local_add_return on X86_64.
The X86_32 version is just fine as it is protected with ifdef
CONFIG_M386 so use it directly.
thanks, i've applied your 4 patches to x86.git.
btw., now that
On Fri, Dec 14, 2007 at 04:12:15PM -0500, Jon Dufresne wrote:
Hmm, I found more strange behavior with the bars that may or may not be
related. I wrote a function that does another sanity check. It does an
ioremap on one of the working bars, then reads one address for
correctness. This is just
Markus wrote:
Well, now some windows vanished, but no additional messages were
produced by kernel. When somebody could tell what I exactly need to
do... would be nice.
Or a hit, in what direction I should look. Because its really nasty to
not being able to use a current kernel.
I already
The process of safely making delicate changes here is beyond my
responsibility as just a user - believe me, I'm not suggesting that a
risky fix be put in .24. I can patch my own kernels, and I can even
share an unofficial patch with others for now, or suggest that Fedora
and Ubuntu add it to
Rene Herman wrote:
David: I've plugged in your DMI values in this. Could you perhaps test
this to confirm that it works for you?
Will test it by tomorrow morning.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
From: Bill Davidsen [EMAIL PROTECTED]
Date: Sun, 16 Dec 2007 17:47:24 -0500
David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 11:12:32 +1100
[INET]: Export non-blocking flags to proto connect call
Previously we made connect(2) block on IPsec SA resolution.
Hello,
I'm trying to get my HighPoint RocketRaid Controller working with the
sata_mv drivers.
But something is not working correctly :(
Kernel version 2.6.23.11 (also tried 2.6.24-rc5 with same results)
Controller in lspci: Marvell Technology Group Ltd. MV88SX6081 8-port
SATA II PCI-X
Hi!
The process of safely making delicate changes here is beyond my
responsibility as just a user - believe me, I'm not suggesting that a risky
fix be put in .24. I can patch my own kernels, and I can even share an
unofficial patch with others for now, or suggest that Fedora and Ubuntu
On Dec 16 2007 23:37, Jan Engelhardt wrote:
On Dec 16 2007 23:25, Harald Dunkel wrote:
Hi folks,
Is there a way to replace the system beep by something more
melodic?
I remember some 10 years ago there was a patch for the kernel
to call an external beep daemon playing an audio file instead
Pavel Machek wrote:
Hi!
The process of safely making delicate changes here is beyond my
responsibility as just a user - believe me, I'm not suggesting that a risky
fix be put in .24. I can patch my own kernels, and I can even share an
unofficial patch with others for now, or suggest that
On Sun, 16 Dec 2007, Fengguang Wu wrote:
Here are the mmap read-around related patches initiated by Linus.
They are for linux-2.6.24-rc4-mm1. The one major new feature -
auto detection and early readahead for mmap sequential reads - runs
as expected on my desktop :-)
Just out of interest
I've just released Linux 2.4.36-rc1.
It fixes several vulnerabilities, some of them discovered in 2.6.
Among them, we find 2 ISDN overflows, one case of insufficient
permissions checking on core dumps, the ability for a process to
escape ptrace-based syscall policy checking, and the possibility
On Sun, 2007-12-16 at 14:48 -0800, H. Peter Anvin wrote:
Ingo Molnar wrote:
* Harvey Harrison [EMAIL PROTECTED] wrote:
No differences except for the defintion of local_add_return on X86_64.
The X86_32 version is just fine as it is protected with ifdef
CONFIG_M386 so use it directly.
On Saturday, 15 of December 2007, Greg KH wrote:
On Sat, Dec 15, 2007 at 03:55:40AM +0100, Rafael J. Wysocki wrote:
On Saturday, 15 of December 2007, Rafael J. Wysocki wrote:
On Saturday, 15 of December 2007, Chuck Ebbert wrote:
On 12/14/2007 08:52 PM, Rafael J. Wysocki wrote:
On
I've just released Linux 2.4.35.5.
It simply gets up to date with 2.4.36-rc1. One important thing to
keep in mind is that I explicitly disabled the possibility to build
with GCC 4.2 because several users (me included) encountered silent
mis-compilations.
So if you think that you have built your
Harvey Harrison wrote:
Do you have a stylistic preference between these two options:
Option 1) Rely on CPP string constant concatenation
// possibly include trailing space here to avoid remembering
// leading space on the register names
# define _ASM_INC incl
static inline void
thanks a lot!!
On Dec 16, 2007 7:30 PM, Luciano Rocha [EMAIL PROTECTED] wrote:
On Sun, Dec 16, 2007 at 05:01:17PM -0300, Rafael Sisto wrote:
Thank you for the quick answer, but It's a college project, and I must
share user level memory. I also must build my own system calls...
But I can
On Sun, 2007-12-16 at 15:48 -0800, H. Peter Anvin wrote:
Harvey Harrison wrote:
Do you have a stylistic preference between these two options:
Option 1) Rely on CPP string constant concatenation
// possibly include trailing space here to avoid remembering
// leading space on the
On Mon, 2007-12-17 at 06:59 +0900, Paul Mundt wrote:
While I realize that this is all undocumented and based entirely on
reverse engineering, you should at least verify that that's precisely
what is going on, and that this is not just a precaution for flushing
posted writes. You can test
Harvey Harrison wrote:
#define _ASM_INC incl
_ASM_INC %0
Not sure if you were just tossing a space on the end of my example,
but do you also put a leading space on the incl in addition to
the trailing space?
That is what I have, again, just to make mistakes harder.
On Saturday, 15 of December 2007, Ingo Molnar wrote:
* Pavel Machek [EMAIL PROTECTED] wrote:
Linux never uses that register. The only user is suspend
save/restore, but that' bogus because it wasn't ever initialized by
Linux in the first place. It could be probably all safely
On Sun, Dec 16, 2007 at 10:53:19PM +0100, Helge Deller wrote:
FYI, we are currently discussing and testing this proposed patch to e2fsprogs
off-list in Red Hat's bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=233471
Note that this bug is currently not publically visible. (You need
/*
* We try to avoid enabling the hardware if it's not
* there, but we don't know how to test. But we do know
* that the PC110 is not a PCI system. So if we find any
* PCI devices in the machine, we don't have a PC110.
*/
The pc110 pad device is ISA. Its an ISA bus 486 box
Alan
--
To
On Sun, 16 Dec 2007 22:26:33 +0100
Pavel Machek [EMAIL PROTECTED] wrote:
On Fri 2007-12-14 15:33:28, Ingo Molnar wrote:
* Alan Cox [EMAIL PROTECTED] wrote:
There is another reason we can't just do a dumb changeover - two
actually
#1: Some drivers are using inb_p/outb_p in
On Mon 2007-12-17 01:27:29, Rafael J. Wysocki wrote:
On Saturday, 15 of December 2007, Ingo Molnar wrote:
* Pavel Machek [EMAIL PROTECTED] wrote:
Linux never uses that register. The only user is suspend
save/restore, but that' bogus because it wasn't ever initialized by
On Mon 2007-12-17 00:03:01, Alan Cox wrote:
On Sun, 16 Dec 2007 22:26:33 +0100
Pavel Machek [EMAIL PROTECTED] wrote:
On Fri 2007-12-14 15:33:28, Ingo Molnar wrote:
* Alan Cox [EMAIL PROTECTED] wrote:
There is another reason we can't just do a dumb changeover - two
Greg KH writes:
Ok, sorry, it wasn't blindingly obvious that this was for pci sysfs
devices that are mmaped, that makes a bit more sense.
But I'd like to see what ioctl is wanted here first.
I believe the ioctl would be to set whether the mapping goes to I/O or
memory space, and whether
trash can wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Success!
I downloaded kernel-2.6.24-0.81.rc4.git7.fc9.src.rpm from the Fedora
development tree. Went through rpm dependecy hell and solved all
dependencies by installing other fc9 rpms. I used
config-2.6.23.1-42.fc8 as my starting
On Sun, Dec 16, 2007 at 07:38:14PM +0100, Eric Dumazet wrote:
Adrian Bunk a ??crit :
On Sun, Dec 16, 2007 at 06:42:57PM +0100, Eric Dumazet wrote:
Adrian Bunk a ??crit :
...
And even more funny, with gcc 4.2 and CONFIG_CC_OPTIMIZE_FOR_SIZE=y your
patch doesn't seem to make any space
On Monday, 17 of December 2007, Pavel Machek wrote:
On Mon 2007-12-17 01:27:29, Rafael J. Wysocki wrote:
On Saturday, 15 of December 2007, Ingo Molnar wrote:
* Pavel Machek [EMAIL PROTECTED] wrote:
Linux never uses that register. The only user is suspend
save/restore, but
Hello.
Indan Zupancic wrote:
What prevents them from mounting tmpfs on top of /dev, bypassing your fs?
Mandatory access control (MAC) prevents them from mounting tmpfs on top of /dev
.
MAC mediates namespace manipulation requests such as mount()/umount().
Also, if they have root there are
On Mon, 17 Dec 2007 00:55:00 +0300 Alexey Dobriyan wrote:
static void check_batteries(struct cardinfo *card);
/*
--- get_userbit
David P. Reed wrote:
PS: If I have time, I may try to build Rene's port 80 test for Windows
and run it under WinXP on this machine (I still have a crappy little
partition that boots it). If it freezes the same way, it's almost
certain a design feature, and if it doesn't freeze, we might
Common prefix from both files moved to local.h
Change __inline__ to inline
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
Ingo, this is the revised series with fixed asm incorporating
HPA's comments.
include/asm-x86/local.h| 19 +--
include/asm-x86/local_32.h | 34
Use the shorter +m form rather than =m and m.
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
include/asm-x86/local_64.h | 30 ++
1 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/include/asm-x86/local_64.h b/include/asm-x86/local_64.h
index
Handle the use of long on X86_32 and quad on X86_64
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
include/asm-x86/asm.h | 12
include/asm-x86/local.h|2 ++
include/asm-x86/local_32.h | 18 +-
include/asm-x86/local_64.h | 18
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
include/asm-x86/local.h| 148 ++-
include/asm-x86/local_32.h | 150
include/asm-x86/local_64.h | 134 ---
3 files
Ingo Molnar wrote:
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Pavel Machek wrote:
this is also something for v2.6.24 merging.
As much as I like this patch, I do not think it is suitable for
.24. Too risky, I'd say.
No kidding! We're talking about removing a hack that has been
successful on
Hi,
This looks to be a regression between 2.6.23 and 2.6.24-rc5, I'll try
to bi-sect this and report more on it. Basically, when I bootup, I
get a ton of errors in the dmesg log along the lines of:
[ 215.007701] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[ 215.008145]
On Dec 14, 2007 11:44 PM, Alan Stern [EMAIL PROTECTED] wrote:
On Fri, 14 Dec 2007, Dave Young wrote:
Hi,
The behaviour of my mp3 player (also act as usb-storage device) seems
changed from rc5 to rc5-mm1.
This can't be considered a bug, right?
I'm not sure.
It's just that the player
On 16.12.2007 02:39, Matthias Schniedermeyer wrote:
Hi
It appears i found my culprit. Knocking on wood :-)
I have a ISDN-controller which is driven by the HFC-PCI-driver and it
appears to not be 64bit-safe.
I will test more thorough after i have relocated the card to another
computer.
On 16-12-07 16:22, Ingo Molnar wrote:
looks good to me. Could you please also provide three more controls that
i suggested earlier:
- a boot option enabling/disabling the udelay based code
- a .config method of enabling/disabling the udelay based code
- a sysctl to toggle it
if we want to
The current do_div() implementation has a bogus pointer compare to
generate build warnings on mismatch on 32-bit, unfortunately this not
only triggers for size mismatch, but also _any_ type mismatch, even on
reasonable 64-bit values:
In file included from kernel/sched.c:869:
kernel/sched_debug.c:
On 16-12-07 22:42, H. Peter Anvin wrote:
It probably comes down to which version is bigger (you probably also
want to try uninlining.)
slow_down_io() sort of needs to stay inline due to the REALLY_SLOW_IO thing.
That stuff could use a cleanup, but that would be a diferent patch.
Thanks for
On 16-12-07 22:43, H. Peter Anvin wrote:
Again, 24 is right out. 25 is a maybe, IMO. Rene's fix could be an
exception, since it is a DMI-keyed workaround for a specific machine and
doesn't change behaviour in general.
I've not much opinion on the schedule as I've not the problem but yes,
Rene Herman wrote:
Do you expect a BIOS update to be able to fix it? If so, I guess any DMI
hack should take BIOS version into account.
Hard to know without knowing what it is.
-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Mostly space after comma, one space after if.
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
include/asm-x86/local.h | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/include/asm-x86/local.h b/include/asm-x86/local.h
index f5677e2..f852c62 100644
---
On 17-12-07 00:12, David P. Reed wrote:
Rene Herman wrote:
David: I've plugged in your DMI values in this. Could you perhaps test
this to confirm that it works for you?
Will test it by tomorrow morning.
Might as well test the new version then. Ingo Molnar requested a few changes
and this
On Fri, 2007-12-14 at 17:01 +0100, Peter Zijlstra wrote:
Subject: lib: proportion: fix underflow in prop_norm_percpu()
Zhe Jiang noticed that its possible to underflow pl-events in
prop_norm_percpu() when the value returned by percpu_counter_read() is less
than the error on that read and the
Rene Herman wrote:
On 17-12-07 00:12, David P. Reed wrote:
Rene Herman wrote:
David: I've plugged in your DMI values in this. Could you perhaps
test this to confirm that it works for you?
Will test it by tomorrow morning.
Might as well test the new version then. Ingo Molnar requested a
Rene Herman wrote:
On 16-12-07 16:22, Ingo Molnar wrote:
looks good to me. Could you please also provide three more controls
that i suggested earlier:
- a boot option enabling/disabling the udelay based code
- a .config method of enabling/disabling the udelay based code
- a sysctl to
On Sun, 2007-12-09 at 23:02 -0500, Mike Houston wrote:
On Mon, 10 Dec 2007 10:31:27 +0800
Shaohua Li [EMAIL PROTECTED] wrote:
This should exist in previous kernel (before we remove acpi
motherboard driver) too. Basically it's a broken BIOS. Could below
patch work around it?
Thanks,
On Mon, 2007-12-17 at 09:43 +1100, Neil Brown wrote:
On Saturday December 15, [EMAIL PROTECTED] wrote:
On Dec 14, 2007 7:26 AM, NeilBrown [EMAIL PROTECTED] wrote:
Given an fd on a block device, returns a string like
/block/sda/sda1
which can be used to find related
On Sun, Dec 16, 2007 at 08:10:10PM +0100, Mariusz Kozlowski wrote:
Can you change line 710 of fs/proc/proc_misc.c to:
ppage = NULL;
Sure.
..and see if it still breaks?
Yes it does - the same way as eariler. Box is locked, processes stuck in D
state
and after a
Tetsuo Handa writes:
When I attended at Security Stadium 2003 as a defense side,
I was using devfs for /dev directory. The files in /dev directory
were deleted by attckers and the administrator was unable to login.
If the attacker gets full administrator-level access on your machine,
there are a
On Dec 15, 2007 7:38 AM, [EMAIL PROTECTED] wrote:
I'll build latest wireless git without ipv6 late tonight.
Ok, built and tested, and it's actually faster! Although still not as
fast as bcm43xx or softmac or whatever the problem is, I was getting a
steady 200 kB/s (as opposed to 500 kB/s for
On 17-12-07 03:04, H. Peter Anvin wrote:
Rene Herman wrote:
On 17-12-07 00:12, David P. Reed wrote:
Rene Herman wrote:
David: I've plugged in your DMI values in this. Could you perhaps
test this to confirm that it works for you?
Will test it by tomorrow morning.
Might as well test the
On 17-12-07 03:05, H. Peter Anvin wrote:
Incidentally, I had the thought earlier today that port 0xf0 might be a
suitable delay port. It is used only by the 387-emulating-a-287 hack
for IRQ 13, which Linux doesn't use on 486+.
[EMAIL PROTECTED]:~/src/port80$ su -c ./port80
cycles: out 2400,
This API has the power_supply drivers device their own device_attribute
list; I find this to be a lot more flexible and cleaner. For example,
rather than having a function with a huge switch statement (as olpc_battery
currently has), we have separate callback functions. We're not limited
to
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
drivers/power/pda_power.c | 40
1 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
index c058f28..4012a2f 100644
---
On Sun, 16 Dec 2007 20:05:51 -0500
John Stoffel [EMAIL PROTECTED] wrote:
[ 215.007701] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[ 215.008145] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[ 215.008678] sym1: SCSI parity error detected: SCR1=1
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
drivers/power/olpc_battery.c | 413 +
1 files changed, 252 insertions(+), 161 deletions(-)
diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
index af7a231..419aca2 100644
---
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
drivers/power/power_supply_core.c | 17 +---
drivers/power/power_supply_leds.c | 30 ++-
drivers/power/power_supply_sysfs.c | 158 +---
include/linux/power_supply.h | 47 ---
4 files
This allows us to share the uevent callback code w/ the dynamic attrib
stuff.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
drivers/power/power_supply_sysfs.c | 50
include/linux/power_supply.h |9 ++
2 files changed, 20 insertions(+),
On Sun, 2007-12-16 at 21:24 -0500, Andres Salomon wrote:
This API has the power_supply drivers device their own device_attribute
list; I find this to be a lot more flexible and cleaner. For example,
rather than having a function with a huge switch statement (as olpc_battery
currently has), we
Convert handmade 'max' to max().
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
---
msg.c |2 +-
sem.c |2 +-
shm.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index fdf3db5..74d0709 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -473,7
Convert m_ts (message text size) from int to size_t.
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
---
Remove some trailing spaces, since we are in the neighborhood.
diff --git a/include/linux/msg.h b/include/linux/msg.h
index 10a3d5a..7a61952 100644
--- a/include/linux/msg.h
+++
Convert handmade 'min' to min().
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
---
Dependent on 'msg-m_ts' being changed from int to size_t.
diff --git a/ipc/msg.c b/ipc/msg.c
index fdf3db5..74d0709 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -920,7 +920,7 @@ out_unlock:
if
At 04:15 07/12/15, Zach Brown wrote:
If anyone has a testcase - I can take a look at the problem again.
I can try and throw something together..
- z
I did a test by using fsstress.
I modified the dio write() of fsstress to check return value, and input
following command;
# fsstress -d
On Sat, Dec 15, 2007 at 04:49:05PM +0100, Stefan Richter wrote:
Reports about tainted kernels have arguably less value. It would be
good to hide such reports until a report of the same oops in an
untainted kernel was found.
I disagree with this. It's useful to have a we've seen this
In my quest to get the wake-ups from idle per second down to bare minimum,
I noticed 3 places in the kernel that could benefit from
using init_timer_deferrable() instead of init_timer() -
a) drivers/net/sky2.c - watchdog_timer. This was showing up high on
Powertop's list of things that cause
On Mon, 17 Dec 2007 10:48:05 +0900 Paul Mundt [EMAIL PROTECTED] wrote:
The current do_div() implementation has a bogus pointer compare to
generate build warnings on mismatch on 32-bit, unfortunately this not
only triggers for size mismatch, but also _any_ type mismatch, even on
reasonable
(Adding Ingo to CC regarding kernel/lockdep_proc.c..)
On Sun, Dec 16, 2007 at 07:04:18PM -0800, Andrew Morton wrote:
On Mon, 17 Dec 2007 10:48:05 +0900 Paul Mundt [EMAIL PROTECTED] wrote:
The options are to either 'fix' all callers of do_div() to make sure
they're using a uint64_t
Rene Herman wrote:
On 17-12-07 03:05, H. Peter Anvin wrote:
Incidentally, I had the thought earlier today that port 0xf0 might be
a suitable delay port. It is used only by the 387-emulating-a-287
hack for IRQ 13, which Linux doesn't use on 486+.
[EMAIL PROTECTED]:~/src/port80$ su -c
On Sun, 2007-12-16 at 13:48 -0800, David Miller wrote:
From: Joe Perches [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 15:39:01 -0800
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Applied, thanks for doing this work Joe.
I broke the parisc build. Bad Joe...
Here's the patch:
Signed-off-by: Joe
Rene Herman wrote:
On 17-12-07 03:05, H. Peter Anvin wrote:
Incidentally, I had the thought earlier today that port 0xf0 might be
a suitable delay port. It is used only by the 387-emulating-a-287
hack for IRQ 13, which Linux doesn't use on 486+.
[EMAIL PROTECTED]:~/src/port80$ su -c
Hi,
On Sunday 16 December 2007, Geert Uytterhoeven wrote:
--- a/init/main.c
+++ b/init/main.c
@@ -598,9 +598,9 @@ asmlinkage void __init start_kernel(void
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start !initrd_below_start_ok
- initrd_start min_low_pfn
1 - 100 of 508 matches
Mail list logo
