Re: [PATCH 1/5] power: RFC: introduce a new power API

On Mon, 17 Dec 2007 08:51:23 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote: > Hello Andres, David, > > Firstly, Andres, thank you for the efforts. > > I quite foreseen what exactly you had in mind when we were > discussing the idea. With patches it's indeed easier to show > flaws of this

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

On Dec 17, 2007 1:52 AM, Larry Finger <[EMAIL PROTECTED]> wrote: > > One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the > former always used a fixed > rate; whereas mac80211 tries to adjust the bit rate according to the > transmission conditions. > Perhaps it isn't working

[PATCH] scripts/checkpatch.pl: add a check for the patch level (patch -p)

Being bitten by this several times myself here's a quick hack for checking the patch level of the diffs in a patch file. It works only when checkpatch.pl is called from within the kernel tree. --- Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> -- scripts/checkpatch.pl | 18

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[EMAIL PROTECTED] wrote: > 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

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

Hello. David Wagner wrote: > If the attacker gets full administrator-level access on your machine, > there are a gazillion ways the attacker can prevent other admins from > logging on. This patch can't prevent that. It sounds like this patch > is trying to solve a fundamentally unsolveable

Re: 2.6.24-rc5-mm1: problems with cat /proc/kpageflags

On Sun, 16 Dec 2007 20:26:11 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > From: Matt Mackall <[EMAIL PROTECTED]> > Date: Sun, 16 Dec 2007 20:11:49 -0600 > > > But as the function doesn't actually show up in your stack trace, > > something else is probably wrong. So I'd also try

Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c

[ Updated according to Jean's suggestion, thanks ] >From 5b4d907da17d57ec168643ebd847278e8d7267f9 Mon Sep 17 00:00:00 2001 From: eric miao <[EMAIL PROTECTED]> Date: Sat, 15 Dec 2007 12:07:26 +0800 Subject: [PATCH] gpiolib: obsolete drivers/i2c/chips/pca9539.c and related files for the following

Re: [PATCH 2.6.24-rc5-mm 2/3] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander

[updated according to David's suggestion to handle the error of I2C transfer] >From c9b78718488dadc702f40789bd532d1f1765d76e Mon Sep 17 00:00:00 2001 From: eric miao <[EMAIL PROTECTED]> Date: Mon, 10 Dec 2007 17:24:36 +0800 Subject: [PATCH] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO

Re: [PATCH 2.6.24-rc5-mm 1/3] gpiolib: basic support for 16-bit PCA9539 GPIO expander

[ forget about the previous patch, sorry for my carelessness not to free the chip structure, below is the correct one ] >From c4be69e8dad28dc75e80b393f9c60f740cca7047 Mon Sep 17 00:00:00 2001 From: eric miao <[EMAIL PROTECTED]> Date: Mon, 10 Dec 2007 17:19:12 +0800 Subject: [PATCH] gpiolib: basic

Re: [PATCH 2.6.24-rc5-mm 1/3] gpiolib: basic support for 16-bit PCA9539 GPIO expander

[ Yup, it's an issue, patch updated as below:] >From 8de0246423cbbd0c6bb03a20baf61d360930c350 Mon Sep 17 00:00:00 2001 From: eric miao <[EMAIL PROTECTED]> Date: Mon, 10 Dec 2007 17:19:12 +0800 Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander 1. use 16-bit register access

Re: [PATCH 1/5] power: RFC: introduce a new power API

Hello Andres, David, Firstly, Andres, thank you for the efforts. I quite foreseen what exactly you had in mind when we were discussing the idea. With patches it's indeed easier to show flaws of this approach. On Sun, Dec 16, 2007 at 09:36:24PM -0500, David Woodhouse wrote: > On Sun, 2007-12-16

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

Tetsuo Handa wrote: If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...] Bob can't do that. Only root can. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at

RE: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.

Thanks Stephen for your comments. I have gone through them. Shall incorporate them and repost the patch. Sorry for late reply as I was on leave for the last week. With Regards Poonam -Original Message- From: Stephen Rothwell [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11,

Re: 1.0.0.0 DNS replies for many domain names (network)

I fixed this by installing bind9 which has named server. After installing bind9, I used the default configuration, which understands DNS type queries and uses the root name servers and other servers for resolution. On Dec 17, 2007 10:21 AM, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote:

[PATCH] ecryptfs: fix fsx data corruption problems

ecryptfs in 2.6.24-rc3 wasn't surviving fsx for me at all, dying after 4 ops. Generally, encountering problems with stale data and improperly zeroed pages. An extending truncate + write for example would expose stale data. With the changes below I got to a million ops and beyond with all mmap

/sys/block [was: [PATCH 007 of 7] md: Get name for block device in sysfs]

Kay Sievers wrote: > 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

Re: [PATCH] lib: proportion: fix underflow in prop_norm_percpu()

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

[PATCH] NET: ns83820.c remove fastcall macro

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> --- Dave, this is the remainder of the FASTCALL/fastcall removal patch that is not already in your tree. Generated against net-2.6.25.git drivers/net/ns83820.c |9 - 1 files changed, 4 insertions(+), 5 deletions(-) diff --git

Re: div64: Rework 64-bit type safety checks in do_div().

On Mon, Dec 17, 2007 at 12:20:19PM +0900, Paul Mundt wrote: > (Adding Ingo to CC regarding kernel/lockdep_proc.c..) > That seems to be an accurate asessment, yes. If do_div(s64, ...) is buggy > behaviour, then the current check is fine, and the callsites should be > corrected. Though if there's

Re: 1.0.0.0 DNS replies for many domain names (network)

* Amogh Hooshdar <[EMAIL PROTECTED]> [2007-12-14 17:20:17]: > I am having a strange problem with Debian Etch 4.0 (both 64-bit and > 32-bit) using 2.6.18 kernel. Most websites do not open with browser, > Pidgin and most other GUI applicatoins. but I am able to ping them > fine. I am also able to

kconfig: Obey KCONFIG_ALLCONFIG choices with randconfig.

Currently when using KCONFIG_ALLCONFIG with randconfig the choice options are clobbered. As recommended by Roman, this adds an is_new test to see whether to select a new option or obey the existing one. This is a resend of the earlier patch a couple of weeks ago, since there was no reply.

Re: [PATCH] [NET]: Remove FASTCALL/fastcall macros

From: Harvey Harrison <[EMAIL PROTECTED]> Date: Sun, 16 Dec 2007 20:16:25 -0800 > X86_32 was the last user of the FASTCALL/fastcall macros, now that it > uses regparm(3) by default, these macros expand to nothing. > > Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> > --- > Dave, this is a

Re: [PATCH net-2.6.25 8/8] Remove unused IPV4TYPE macros

From: Joe Perches <[EMAIL PROTECTED]> Date: Sun, 16 Dec 2007 20:01:06 -0800 > 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

Re: 2.6.24-rc5-mm1: problems with cat /proc/kpageflags

From: Matt Mackall <[EMAIL PROTECTED]> Date: Sun, 16 Dec 2007 20:11:49 -0600 > But as the function doesn't actually show up in your stack trace, > something else is probably wrong. So I'd also try commenting out > pieces of that function until it started working. Some piece of state is being

[PATCH] [NET]: Remove FASTCALL/fastcall macros

X86_32 was the last user of the FASTCALL/fastcall macros, now that it uses regparm(3) by default, these macros expand to nothing. Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> --- Dave, this is a wrap-up of my patch in your net-2.6.25.git with the build breakage fix from Andrew Morton

Re: [PATCH] initrd: Fix virtual/physical mix-up in overwrite test

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 <

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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

Re: [PATCH net-2.6.25 8/8] Remove unused IPV4TYPE macros

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:

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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

Re: div64: Rework 64-bit type safety checks in do_div().

(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

Re: div64: Rework 64-bit type safety checks in do_div().

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 >

init_timer_deferrable conversion

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

Re: Top kernel oopses/warnings this week

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

Re: [PATCH] dio: falling through to buffered I/O when invalidationof a page fails

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

[PATCH 3/3] ipc: Convert handmade 'min' to min().

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

[PATCH 1/3] ipc: Convert handmade 'max' to max().

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 @@

[PATCH 2/3] msg.h: Convert m_ts from int to size_t.

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 +++

Re: [PATCH 1/5] power: RFC: introduce a new power API

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

[PATCH 5/5] power: convert power_supply static attribs to new API

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

[PATCH 3/5] power: convert olpc_battery to new API

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 ---

[PATCH 4/5] power: drop support for old API

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

Re: 2.6.24-rc5: tape drive not responding

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

[PATCH 2/5] power: convert pda_power to the new API

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 ---

[PATCH 1/5] power: RFC: introduce a new power API

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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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,

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

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

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

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

Re: [PATCH 007 of 7] md: Get name for block device in sysfs

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

Re: 2.6.24-rc5-mm1: problems with cat /proc/kpageflags

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 > >

Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails

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? > >

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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

Re: [PATCH] lib: proportion: fix underflow in prop_norm_percpu()

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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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

[PATCH 5/4] x86: local.h fix checkpatch warnings

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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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

div64: Rework 64-bit type safety checks in do_div().

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:

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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

Re: Strange Memory Corruption Problem with Core2Duo E6700, P965 Chipset MB and >=4GB RAM

On 16.12.2007 02:39, Matthias Schniedermeyer wrote: > Hi It appears i found my culprit. :-) 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. Bis denn --

Re: 2.6.24-rc5-mm1

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

Re: 2.6.24-rc5: tape drive not responding

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]

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

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

[PATCH 4/4] x86: Unify local_{32|64}.h

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

[PATCH 2/4] x86: fix asm memory constraints in local_64.h

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

[PATCH 3/4] x86: Introduce asm helpers in local_{32|64}.h

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

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

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

[PATCH 1/4] x86: clean up local_{32|64}.h

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 |

Re: [PATCH] umem nvram driver: clean up style

On Mon, 17 Dec 2007 00:55:00 +0300 Alexey Dobriyan wrote: > > static void check_batteries(struct cardinfo *card); > > > > /* > > > > --- get_userbit > >

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

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

Re: [PATCH 4/8] unify paravirt parts of system.h

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 > >

Re: [RANDOM] Move two variables to read_mostly section to save memory

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

Re: Iomega ZIP-100 drive unsupported with jmicron JMB361 chip?

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

Re: [RFC PATCH 08/12] PAT 64b: coherent mmap and sysfs bin ioctl

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

Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

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

Re: [PATCH 4/8] unify paravirt parts of system.h

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

Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

> /* > * 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

Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

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

Re: [e2fsprogs PATCH] Userspace solution to time-based UUID without duplicates

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

Re: [PATCH 4/4] x86: Final unification of local_{32|64}.h

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.

Re: [PATCH 4/8] unify paravirt parts of system.h

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

Re: [PATCH 2/3] Add GD-Rom support to the SEGA Dreamcast

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

Re: [PATCH 4/4] x86: Final unification of local_{32|64}.h

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

Re: shared memory

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... > >

Re: [PATCH 4/4] x86: Final unification of local_{32|64}.h

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

Linux 2.4.35.5

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

Re: [stable] Linux 2.6.23.10

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:

Re: [PATCH 4/4] x86: Final unification of local_{32|64}.h

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

Linux 2.4.36-rc1

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

Re: [PATCH 0/9] mmap read-around and readahead

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

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

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

Re: howto get a melodic system beep?

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

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

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

sata_mv not working with a RocketRaid 2220

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

Re: sockets affected by IPsec always block (2.6.23)

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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

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

Re: programs vanish with 2.6.22+

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

  1   2   3   4   5   6   >