[PATCH -mm -v2] EFI : Split EFI tables parsing code from EFI runtime service support code

[Huang, Ying]

This patch split EFI tables parsing code from EFI runtime service
support code. This makes ACPI support and DMI support on EFI platform
not depend on EFI runtime service support. Both EFI32 and EFI64 tables
parsing functions are provided on i386 and x86_64. This makes it
possible to use EFI information in i386 kernel on x86_64 with EFI64
firmware or in x86_64 kernel on x86_64 with EFI32 firmware.

This patch is based on 2.6.24-rc5-mm1 and has been tested for
following combinations:

i386   kernel on EFI 32
i386   kernel on EFI 64
x86_64 kernel on EFI 32
x86_64 kernel on EFI 64
ia64   kernel on EFI 64


ChangeLog

v2:

- Change EXPORT_SYMBOL to EXPORT_SYMBOL_GPL.


Signed-off-by: Huang Ying <[EMAIL PROTECTED]>

---
 arch/ia64/kernel/acpi.c  |6 -
 arch/ia64/kernel/efi.c   |   30 
 arch/ia64/kernel/setup.c |2 
 arch/ia64/sn/kernel/setup.c  |4 -
 arch/x86/Kconfig |4 -
 arch/x86/kernel/Makefile_32  |3 
 arch/x86/kernel/Makefile_64  |2 
 arch/x86/kernel/efi.c|  115 --
 arch/x86/kernel/efi_tables.c |  144 +++
 arch/x86/kernel/setup_32.c   |9 ++
 arch/x86/kernel/setup_64.c   |9 ++
 drivers/acpi/osl.c   |   11 +--
 drivers/firmware/dmi_scan.c  |7 +-
 drivers/firmware/efivars.c   |   53 ---
 drivers/firmware/pcdp.c  |6 -
 include/asm-ia64/setup.h |5 +
 include/asm-ia64/sn/sn_sal.h |2 
 include/asm-x86/efi.h|7 ++
 include/asm-x86/setup.h  |9 ++
 include/linux/efi.h  |   64 ---
 20 files changed, 333 insertions(+), 159 deletions(-)

--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -212,6 +212,16 @@ typedef struct {
unsigned long table;
 } efi_config_table_t;
 
+struct efi_config_table64 {
+   efi_guid_t guid;
+   u64 table;
+};
+
+struct efi_config_table32 {
+   efi_guid_t guid;
+   u32 table;
+};
+
 #define EFI_SYSTEM_TABLE_SIGNATURE ((u64)0x5453595320494249ULL)
 
 typedef struct {
@@ -230,6 +240,39 @@ typedef struct {
unsigned long tables;
 } efi_system_table_t;
 
+struct efi_system_table64 {
+   efi_table_hdr_t hdr;
+   u64 fw_vendor;
+   u32 fw_revision;
+   u32 _pad1;
+   u64 con_in_handle;
+   u64 con_in;
+   u64 con_out_handle;
+   u64 con_out;
+   u64 stderr_handle;
+   u64 stderr;
+   u64 runtime;
+   u64 boottime;
+   u64 nr_tables;
+   u64 tables;
+};
+
+struct efi_system_table32 {
+   efi_table_hdr_t hdr;
+   u32 fw_vendor;
+   u32 fw_revision;
+   u32 con_in_handle;
+   u32 con_in;
+   u32 con_out_handle;
+   u32 con_out;
+   u32 stderr_handle;
+   u32 stderr;
+   u32 runtime;
+   u32 boottime;
+   u32 nr_tables;
+   u32 tables;
+};
+
 struct efi_memory_map {
void *phys_map;
void *map;
@@ -246,14 +289,6 @@ struct efi_memory_map {
  */
 extern struct efi {
efi_system_table_t *systab; /* EFI system table */
-   unsigned long mps;  /* MPS table */
-   unsigned long acpi; /* ACPI table  (IA64 ext 0.71) */
-   unsigned long acpi20;   /* ACPI table  (ACPI 2.0) */
-   unsigned long smbios;   /* SM BIOS table */
-   unsigned long sal_systab;   /* SAL system table */
-   unsigned long boot_info;/* boot info table */
-   unsigned long hcdp; /* HCDP table */
-   unsigned long uga;  /* UGA table */
efi_get_time_t *get_time;
efi_set_time_t *set_time;
efi_get_wakeup_time_t *get_wakeup_time;
@@ -266,6 +301,19 @@ extern struct efi {
efi_set_virtual_address_map_t *set_virtual_address_map;
 } efi;
 
+struct efi_tables {
+   unsigned long mps;  /* MPS table */
+   unsigned long acpi; /* ACPI table  (IA64 ext 0.71) */
+   unsigned long acpi20;   /* ACPI table  (ACPI 2.0) */
+   unsigned long smbios;   /* SM BIOS table */
+   unsigned long sal_systab;   /* SAL system table */
+   unsigned long boot_info;/* boot info table */
+   unsigned long hcdp; /* HCDP table */
+   unsigned long uga;  /* UGA table */
+};
+
+extern struct efi_tables efi_tables;
+
 static inline int
 efi_guidcmp (efi_guid_t left, efi_guid_t right)
 {
--- /dev/null
+++ b/arch/x86/kernel/efi_tables.c
@@ -0,0 +1,144 @@
+/*
+ * EFI tables parsing functions
+ *
+ * Copyright (C) 2007 Intel Co.
+ * Huang Ying <[EMAIL PROTECTED]>
+ *
+ * This file is released under the GPLv2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct efi_tables efi_tables;
+EXPORT_SYMBOL_GPL(efi_tables);
+
+#define EFI_TABLE_PARSE(bt)\
+static void __init efi_tables_parse ## bt(void)
\
+{

Re: [PATCH] PROC_FS: get and set the smp affinity of tasks by read-write /proc//smp_affinity

[Paul Jackson]

Denis wrote:
> + length += sprintf(page + length, "\n");

Could that overrun the 'page' buffer by one byte?

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214
--
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/

Re: [patch 2/2] Add the end-of-trace marker and the module list to WARN_ON()

[Ingo Molnar]

* Arjan van de Ven <[EMAIL PROTECTED]> wrote:

> + printk(KERN_WARNING "[ cut here ]\n");
>   printk(KERN_WARNING "WARNING: at %s:%d %s()\n", file,
>   line, function);
> + print_modules();
>   dump_stack();
> + print_oops_end_marker();

another thing: could we also put the marker into dump_stack(), and 
attach the marker to the Call Trace line?

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

Re: [patch 1/2] move WARN_ON() out of line

[Ingo Molnar]

* Arjan van de Ven <[EMAIL PROTECTED]> wrote:

> This patch build on top of Olof's patch that introduces __WARN, and 
> places the slowpath out of line. It also uses Ingo's suggestion to not 
> use __FUNCTION__ but to use kallsyms to do the lookup; this saves a 
> ton of extra space since gcc doesn't need to store the function string 
> twice now:
>
> 3936367  833603  624736 5394706  525112 vmlinux.before
> 3917508  833603  624736 5375847  520767 vmlinux-slowpath
>
> 15Kb savings...

hey, cool!

Acked-by: Ingo Molnar <[EMAIL PROTECTED]>

i'm wondering how we could put this into x86.git to get it tested some 
more. Olof's patch touches other architectures so it's not really 
appropriate. Maybe a portion of Olof's patch could be applied to make 
your patch apply cleanly?

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

Re: [2.6.22] circular lock detected

[Simon Arlott]

On 25/09/07 09:46, Jan Kara wrote:
> On Tue 25-09-07 10:02:43, Peter Zijlstra wrote:
>> On Mon, 3 Sep 2007 16:01:35 +0200 Jan Kara <[EMAIL PROTECTED]> wrote:
>> 
>> > On Mon 03-09-07 05:49:59, Andrew Morton wrote:
>> > > > On Mon, 3 Sep 2007 14:27:02 +0200 Jan Kara <[EMAIL PROTECTED]> wrote:
>> > > > > > On Fri, 24 Aug 2007 23:00:33 +0200 Folkert van Heusden <[EMAIL 
>> > > > > > PROTECTED]> wrote:
>> 
>> > > > > Has been reported before, but I don't recall whether we fixed it.  
>> > > > > Jan,
>> > > > > do you know>?
>> > > >   I think we at least found a solution: Teach lockdep that I_MUTEX for
>> > > > different filesystems is different. Peter Zilstra wrote a patch for 
>> > > > that
>> > > > and Folkert even confirmed that it fixes the problem for him. I'm not
>> > > > sure what happened with the patch afterwards though. Adding Peter to CC
>> > > > :).
>> > > 
>> > > But this is a tty_lock-versus-dqptr_sem ranking error.  Unrelated to 
>> > > i_mutex?
>> >   The final report is for this ranking but the locking chain (if I 
>> > understand it
>> > right) is:
>> > tty_mutex (con_close) -> i_mutex (sysfs: remove_subdir)
>> > i_mutex (do_truncate) -> i_alloc_sem (notify_change) -> truncate_mutex 
>> > (ext3_truncate)
>> > truncate_mutex (ext3_get_blocks_handle) -> dqptr_sem (dquot_alloc_space)
>> > 
>> > So it complains about tty_mutex vs dqptr_sem (I don't know why it does not
>> > complain about tty_mutex vs i_mutex) but the wrong link in the chain is
>> > that i_mutex from remove_subdir() [sysfs] and i_mutex from do_truncate()
>> > [ext3] are different and should never depend on each other...
>> > 
>> 
>> Found it again.
>   Cool, thanks Peter. Andrew, would you put it into -mm? This should take 
> care of
> the false lockdep warnings from the quota code. If I recall correctly, one
> of the reporters even confirmed it fixes the problem for him.
>   The patch looks fine. You can add:
> Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
> 
>   Honza
> 
>> Give each filesystem its own inode lock class. The various filesystems have
>> different locking order wrt the inode locks; esp. the pseudo filesystems
>> differ from the rest.
>> 
>> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>

This patch still doesn't exist in 2.6.23.9 and the warning isn't fixed...

03 00:31:34 [1905219.899008] 
===
03 00:31:34 [1905219.907136] [ INFO: possible circular locking dependency 
detected ]
03 00:31:34 [1905219.913569] 2.6.23.9-git #43
03 00:31:34 [1905219.916624] 
---
03 00:31:34 [1905219.923059] bacula-sd/32639 is trying to acquire lock:
03 00:31:34 [1905219.928364]  (tty_mutex){--..}, at: [<80389fd7>] 
mutex_lock+0x1c/0x1f
03 00:31:34 [1905219.935047]
03 00:31:34 [1905219.935049] but task is already holding lock:
03 00:31:34 [1905219.941238]  (>s_dquot.dqptr_sem){}, at: [<801839bf>] 
dquot_alloc_space+0x42/0x15b
03 00:31:34 [1905219.949646]
03 00:31:34 [1905219.949649] which lock already depends on the new lock.
03 00:31:34 [1905219.949652]
03 00:31:34 [1905219.958367]
03 00:31:34 [1905219.958369] the existing dependency chain (in reverse order) 
is:
03 00:31:34 [1905219.966204]
03 00:31:34 [1905219.966206] -> #4 (>s_dquot.dqptr_sem){}:
03 00:31:34 [1905219.972714][<80131c5b>] __lock_acquire+0x9ba/0xb96
03 00:31:34 [1905219.978511][<80132200>] lock_acquire+0x5d/0x75
03 00:31:34 [1905219.983957][<8012ac3c>] down_read+0x3a/0x4b
03 00:31:34 [1905219.989252][<801839bf>] dquot_alloc_space+0x42/0x15b
03 00:31:34 [1905219.995217][<801920e1>] ext3_new_blocks+0x83/0x5ba
03 00:31:34 [1905220.001009][<80195111>] 
ext3_get_blocks_handle+0x386/0x822
03 00:31:34 [1905220.007495][<80195889>] ext3_get_block+0xac/0xc5
03 00:31:34 [1905220.013113][<80174e54>] 
__block_prepare_write+0x151/0x3c6
03 00:31:34 [1905220.019603][<801750ed>] block_prepare_write+0x24/0x32
03 00:31:34 [1905220.025654][<80196a43>] ext3_prepare_write+0x98/0x153
03 00:31:34 [1905220.031705][<8013cbbe>] 
generic_file_buffered_write+0x219/0x57c
03 00:31:34 [1905220.038630][<8013d384>] 
__generic_file_aio_write_nolock+0x463/0x4b3
03 00:31:34 [1905220.045894][<8013d42a>] 
generic_file_aio_write+0x56/0xb4
03 00:31:34 [1905220.052292][<8019311b>] ext3_file_write+0x27/0x99
03 00:31:34 [1905220.057996][<80157742>] do_sync_write+0xc4/0x101
03 00:31:34 [1905220.063615][<80157f03>] vfs_write+0xaf/0x138
03 00:31:34 [1905220.068885][<8015840f>] sys_write+0x3d/0x61
03 00:31:34 [1905220.074071][<80102702>] sysenter_past_esp+0x5f/0x99
03 00:31:34 [1905220.080046][] 0x
03 00:31:34 [1905220.084456]
03 00:31:34 [1905220.084458] -> #3 (>truncate_mutex){--..}:
03 00:31:34 [1905220.090781][<80131c5b>] __lock_acquire+0x9ba/0xb96
03 00:31:34 

Re: [PATCH] PROC_FS: get and set the smp affinity of tasks by read-write /proc//smp_affinity

[Paul Jackson]

Could you also update the file 'Documentation/filesystems/proc.txt' as
part of this patch?  It should document /proc//* files.  Thanks.

(Don't tell anyone that this file doesn't mention /proc//cpuset ;).

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214
--
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/

Re: [PATCH 0 of 8] x86: unify asm/page.h

[Ingo Molnar]

* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:

> Hi Ingo,
> 
> Here's a series which concentrates on unifying and cleaning up 
> asm-86/page*.h.  Each patch in the series restricts itself to doing 
> one thing fairly simply, so it should be fairly low-risk and easy to 
> bisect.

thanks Jeremy, i have applied your patches to x86.git.

> The early version of this patch got rid of asm/page_32|64.h entirely, 
> but I decided the resulting #ifdef hell was too hard to deal with, so 
> I moved purely 32/64-bit specific stuff into their own files.

agreed - and the result certainly looks clean.

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

Re: [PATCH][BUG 3879] add some check before scsi_cmd_ioctl

[Dave Young]

On Fri, Jan 04, 2008 at 03:28:26PM +0800, Dave Young wrote:
> The behaviour of eject/lock_door ioctl is not consistent, so add some check 
> before scsi_cmd_ioctl.
> 
> Signed-off-by: Dave Young <[EMAIL PROTECTED]> 
> 
> ---
> drivers/cdrom/cdrom.c |   42 --
> 1 file changed, 36 insertions(+), 6 deletions(-)
> 
Sorry, should be this one:

The behaviour of eject/lock_door ioctl is not consistent, so add some check 
before scsi_cmd_ioctl.

Signed-off-by: Dave Young <[EMAIL PROTECTED]> 

---
drivers/cdrom/cdrom.c |   47 ++-
1 file changed, 38 insertions(+), 9 deletions(-)

diff -upr linux/drivers/cdrom/cdrom.c linux.new/drivers/cdrom/cdrom.c
--- linux/drivers/cdrom/cdrom.c 2008-01-04 15:32:09.0 +0800
+++ linux.new/drivers/cdrom/cdrom.c 2008-01-04 15:34:00.0 +0800
@@ -2236,14 +2236,22 @@ static int cdrom_ioctl_multisession(stru
return 0;
 }
 
-static int cdrom_ioctl_eject(struct cdrom_device_info *cdi)
+static int cdrom_eject_check(struct cdrom_device_info *cdi)
 {
-   cdinfo(CD_DO_IOCTL, "entering CDROMEJECT\n");
-
if (!CDROM_CAN(CDC_OPEN_TRAY))
return -ENOSYS;
if (cdi->use_count != 1 || keeplocked)
return -EBUSY;
+   return 0;
+}
+
+static int cdrom_ioctl_eject(struct cdrom_device_info *cdi)
+{
+   cdinfo(CD_DO_IOCTL, "entering CDROMEJECT\n");
+
+   /*
+* cdrom_eject_check is done in cdrom_ioctl.
+*/
if (CDROM_CAN(CDC_LOCK)) {
int ret = cdi->ops->lock_door(cdi, 0);
if (ret)
@@ -2392,22 +2400,31 @@ static int cdrom_ioctl_reset(struct cdro
return cdi->ops->reset(cdi);
 }
 
-static int cdrom_ioctl_lock_door(struct cdrom_device_info *cdi,
+static int cdrom_lock_door_check(struct cdrom_device_info *cdi,
unsigned long arg)
 {
-   cdinfo(CD_DO_IOCTL, "%socking door.\n", arg ? "L" : "Unl");
-
if (!CDROM_CAN(CDC_LOCK))
return -EDRIVE_CANT_DO_THIS;
-
-   keeplocked = arg ? 1 : 0;
-
/*
 * Don't unlock the door on multiple opens by default, but allow
 * root to do so.
 */
if (cdi->use_count != 1 && !arg && !capable(CAP_SYS_ADMIN))
return -EBUSY;
+
+   return 0;
+}
+
+
+static int cdrom_ioctl_lock_door(struct cdrom_device_info *cdi,
+   unsigned long arg)
+{
+   cdinfo(CD_DO_IOCTL, "%socking door.\n", arg ? "L" : "Unl");
+
+   /*
+* cdrom_lock_door_check is done in cdrom_ioctl.
+*/
+   keeplocked = arg ? 1 : 0;
return cdi->ops->lock_door(cdi, arg);
 }
 
@@ -2701,6 +2718,18 @@ int cdrom_ioctl(struct file * file, stru
int ret;
struct gendisk *disk = ip->i_bdev->bd_disk;
 
+   if (cmd == CDROMEJECT) {
+   ret = cdrom_eject_check(cdi);
+   if (ret)
+   return ret;
+   }
+
+   if (cmd == CDROM_LOCKDOOR) {
+   ret = cdrom_lock_door_check(cdi, arg);
+   if (ret)
+   return ret;
+   }
+
/*
 * Try the generic SCSI command ioctl's first.
 */
--
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/

Re: Error returns not handled correctly by sysfs.c:subsys_attr_store()

[Andrey Borzenkov]

On Friday 04 January 2008, Andrew Patterson wrote:
> On Thu, 2008-01-03 at 17:17 -0700, Andrew Patterson wrote:
> > On Fri, 2008-01-04 at 09:07 +0900, Tejun Heo wrote:
> > > Hello,
> > > 
> > > Andrew Patterson wrote:
> > > > It looks like this is a shell issue.  After looking through the sysfs
> > > > code, I realized that this problem seems to be driven from user-land.
> > > > So I performed some experiments:
> > > > 
> > > >  1. Wrote a simple program that just used write(2) to write to the
> > > > sysfs entry. This works fine.
> > > >  2. Used /bin/echo instead of the built-in echo command.  This too
> > > > works fine.
> > > >  3. Tried several shells.  Zsh and Bash both fail.  Csh works fine.
> > > > 
> > > > I then ran strace on the following shell-script:
> > > > 
> > > > #!/bin/bash
> > > > 
> > > > echo x > allow_restart
> > > > echo y > allow_restart
> > > > echo z > allow_restart
> > > > 
> > > > and got:
> > > > 
> > > > # strace -e trace=write ~/tmp/tester.sh 
> > > > write(1, "x\n", 2)  = -1 EINVAL (Invalid argument)
> > > > write(1, "x\n", 2)  = -1 EINVAL (Invalid argument)
> > > > write(2, "/home/andrew/tmp/tester.sh: line"..., 
72/home/andrew/tmp/tester.sh: line 4: echo: write error: Invalid argument
> > > > ) = 72
> > > > write(1, "x\ny\n", 4)   = -1 EINVAL (Invalid argument)
> > > > write(1, "x\ny\n", 4)   = -1 EINVAL (Invalid argument)
> > > > write(2, "/home/andrew/tmp/tester.sh: line"..., 
72/home/andrew/tmp/tester.sh: line 5: echo: write error: Invalid argument
> > > > ) = 72
> > > > write(1, "x\ny\nz\n", 6)= -1 EINVAL (Invalid argument)
> > > > write(1, "x\ny\nz\n", 6)= -1 EINVAL (Invalid argument)
> > > > write(2, "/home/andrew/tmp/tester.sh: line"..., 
72/home/andrew/tmp/tester.sh: line 6: echo: write error: Invalid argument
> > > > ) = 72
> > > > write(1, "x\ny\nz\n", 6x
> > > > y
> > > > z
> > > > )= 6
> > > > Process 3800 detached
> > > 
> > > Eeee That's scary.  Which distro are you using and what does
> > > 'bash --version' say?
> > 
> > IA64 Debian lenny.  
> > 
> > # bash --version
> > GNU bash, version 3.1.17(1)-release (ia64-unknown-linux-gnu)
> > 
> > # zsh --version 
> > zsh 4.3.4 (ia64-unknown-linux-gnu)
> > 
> > # csh --version
> > tcsh 6.14.00 (Astron) 2005-03-25 (ia64-unknown-linux) options
> > wide,nls,dl,al,kan,rh,nd,color,filec
> > 
> > I suppose I should try this an ia32 box again, and perhaps with some
> > other distros.  I am not sure what the kernel can do about this, but it
> > might be nice to report it to the shell maintainers.
> 
> Some further tests:
> 
> AMD running Debian lenny with i686 kernel -- fails.  
> Bash version = 3.1.17(1)
> 
> Intel running Ubuntu/gutsy with i686 kernel -- fails.
> Bash version = 3.2.25(1)
> 
> Itanium running SLES10 with ia64 kernel -- succeeds.
> Bash version = 3.1.17(1)
> 
> BTW, I found a way to reproduce this without modifying the kernel.
> The /sys/class/scsi_host/*/state sysfs store routine returns EINVAL if
> an invalid state is written. So just echo 2 bad values to the the state
> sysfs entry while running strace.
> 

I can't reproduce it using zsh either 4.3.4 as shipped by Mandriva or zsh CVS 
head. In both cases it echoes correct argument. Nor do I see double writes's in 
strace.

{pts/0}% sudo strace -e trace=write /tmp/foo # zsh 4.3.4
write(1, "x\n", 2)  = -1 EINVAL (Invalid argument)
write(2, "/tmp/foo:echo:3: write error: \320\235"..., 72/tmp/foo:echo:3: write 
error: Недопустимый аргумент
) = 72
write(1, "y\n", 2)  = -1 EINVAL (Invalid argument)
write(2, "/tmp/foo:echo:4: write error: \320\235"..., 72/tmp/foo:echo:4: write 
error: Недопустимый аргумент
) = 72
write(1, "z\n", 2)  = -1 EINVAL (Invalid argument)
write(2, "/tmp/foo:echo:5: write error: \320\235"..., 72/tmp/foo:echo:5: write 
error: Недопустимый аргумент
) = 72
{pts/0}% sudo strace -e trace=write /tmp/foo # zsh CVS head
write(1, "x\n", 2)  = -1 EINVAL (Invalid argument)
write(2, "/tmp/foo:echo:3: write error: \320\235"..., 72/tmp/foo:echo:3: write 
error: Недопустимый аргумент
) = 72
write(1, "y\n", 2)  = -1 EINVAL (Invalid argument)
write(2, "/tmp/foo:echo:4: write error: \320\235"..., 72/tmp/foo:echo:4: write 
error: Недопустимый аргумент
) = 72
write(1, "z\n", 2)  = -1 EINVAL (Invalid argument)
write(2, "/tmp/foo:echo:5: write error: \320\235"..., 72/tmp/foo:echo:5: write 
error: Недопустимый аргумент
) = 72

{pts/0}% cat /tmp/foo
#!/home/bor/pkg/bin/zsh -f

echo x > state
echo y > state
echo z > state

where state is /sys/power/state


{pts/1}% zsh --version
zsh 4.3.4 (i586-mandriva-linux-gnu)
{pts/1}% ~/pkg/bin/zsh --version
zsh 4.3.4-dev-6 (i686-pc-linux-gnu)

-andrey


signature.asc
Description: This is a digitally signed message part.

[PATCH][BUG 3879] add some check before scsi_cmd_ioctl

[Dave Young]

The behaviour of eject/lock_door ioctl is not consistent, so add some check 
before scsi_cmd_ioctl.

Signed-off-by: Dave Young <[EMAIL PROTECTED]> 

---
drivers/cdrom/cdrom.c |   42 --
1 file changed, 36 insertions(+), 6 deletions(-)

diff -upr linux/drivers/cdrom/cdrom.c linux.new/drivers/cdrom/cdrom.c
--- linux/drivers/cdrom/cdrom.c 2008-01-04 15:06:50.0 +0800
+++ linux.new/drivers/cdrom/cdrom.c 2008-01-04 15:05:06.0 +0800
@@ -2236,6 +2236,15 @@ static int cdrom_ioctl_multisession(stru
return 0;
 }
 
+static int cdrom_eject_check(struct cdrom_device_info *cdi)
+{
+   if (!CDROM_CAN(CDC_OPEN_TRAY))
+   return -ENOSYS;
+   if (cdi->use_count != 1 || keeplocked)
+   return -EBUSY;
+   return 0;
+}
+
 static int cdrom_ioctl_eject(struct cdrom_device_info *cdi)
 {
cdinfo(CD_DO_IOCTL, "entering CDROMEJECT\n");
@@ -2392,22 +2401,31 @@ static int cdrom_ioctl_reset(struct cdro
return cdi->ops->reset(cdi);
 }
 
-static int cdrom_ioctl_lock_door(struct cdrom_device_info *cdi,
+static int cdrom_lock_door_check(struct cdrom_device_info *cdi,
unsigned long arg)
 {
-   cdinfo(CD_DO_IOCTL, "%socking door.\n", arg ? "L" : "Unl");
-
if (!CDROM_CAN(CDC_LOCK))
return -EDRIVE_CANT_DO_THIS;
-
-   keeplocked = arg ? 1 : 0;
-
/*
 * Don't unlock the door on multiple opens by default, but allow
 * root to do so.
 */
if (cdi->use_count != 1 && !arg && !capable(CAP_SYS_ADMIN))
return -EBUSY;
+
+   return 0;
+}
+
+
+static int cdrom_ioctl_lock_door(struct cdrom_device_info *cdi,
+   unsigned long arg)
+{
+   cdinfo(CD_DO_IOCTL, "%socking door.\n", arg ? "L" : "Unl");
+
+   /*
+* cdrom_lock_door_check is done in cdrom_ioctl.
+*/
+   keeplocked = arg ? 1 : 0;
return cdi->ops->lock_door(cdi, arg);
 }
 
@@ -2701,6 +2719,18 @@ int cdrom_ioctl(struct file * file, stru
int ret;
struct gendisk *disk = ip->i_bdev->bd_disk;
 
+   if (cmd == CDROMEJECT) {
+   ret = cdrom_eject_check(cdi);
+   if (ret)
+   return ret;
+   }
+
+   if (cmd == CDROM_LOCKDOOR) {
+   ret = cdrom_lock_door_check(cdi, arg);
+   if (ret)
+   return ret;
+   }
+
/*
 * Try the generic SCSI command ioctl's first.
 */
--
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/

[PATCH] PROC_FS: get and set the smp affinity of tasks by read-write /proc//smp_affinity

[Denis Cheng]

this adds a read-write /proc//smp_affinity entry,
just like what /proc/irq//smp_affinity does,
so now we can get and set the affinity of tasks by procfs,
this is especially useful used in shell scripts.

this also adds a read-write /proc//tasks//smp_affinity
for the same purpose.

Cc: Eli M Dow <[EMAIL PROTECTED]>
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
 fs/proc/base.c |   57 
 1 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 7411bfb..ca0cbc2 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1083,6 +1083,57 @@ static const struct file_operations 
proc_pid_sched_operations = {
 
 #endif
 
+#ifdef CONFIG_SMP
+static ssize_t smp_affinity_read(struct file *file,
+   char __user *buf, size_t count, loff_t *ppos)
+{
+   cpumask_t mask;
+   char *page;
+   ssize_t length;
+   pid_t pid = pid_nr(proc_pid(file->f_dentry->d_inode));
+
+   length = sched_getaffinity(pid, );
+   if (length < 0)
+   return length;
+
+   if (count > PROC_BLOCK_SIZE)
+   count = PROC_BLOCK_SIZE;
+
+   page = (char *)__get_free_page(GFP_TEMPORARY);
+   if (!page)
+   return -ENOMEM;
+
+   length = cpumask_scnprintf(page, count, mask);
+   length += sprintf(page + length, "\n");
+   length = simple_read_from_buffer(buf, count, ppos, page, length);
+   free_page((unsigned long) page);
+
+   return length;
+}
+
+static ssize_t smp_affinity_write(struct file *file,
+   const char __user *buf, size_t count, loff_t *ppos)
+{
+   cpumask_t mask;
+   int ret;
+   pid_t pid = pid_nr(proc_pid(file->f_dentry->d_inode));
+
+   ret = cpumask_parse_user(buf, count, mask);
+   if (ret < 0)
+   return ret;
+   ret = sched_setaffinity(pid, mask);
+   if (ret < 0)
+   return ret;
+
+   return count;
+}
+
+static const struct file_operations proc_smp_affinity_operations = {
+   .read  = smp_affinity_read,
+   .write = smp_affinity_write,
+};
+#endif
+
 static void *proc_pid_follow_link(struct dentry *dentry, struct nameidata *nd)
 {
struct inode *inode = dentry->d_inode;
@@ -2230,6 +2281,9 @@ static const struct pid_entry tgid_base_stuff[] = {
 #ifdef CONFIG_SCHEDSTATS
INF("schedstat",  S_IRUGO, pid_schedstat),
 #endif
+#ifdef CONFIG_SMP
+   REG("smp_affinity", S_IRUGO|S_IWUSR, smp_affinity),
+#endif
 #ifdef CONFIG_PROC_PID_CPUSET
REG("cpuset", S_IRUGO, cpuset),
 #endif
@@ -2555,6 +2609,9 @@ static const struct pid_entry tid_base_stuff[] = {
 #ifdef CONFIG_SCHEDSTATS
INF("schedstat", S_IRUGO, pid_schedstat),
 #endif
+#ifdef CONFIG_SMP
+   REG("smp_affinity", S_IRUGO|S_IWUSR, smp_affinity),
+#endif
 #ifdef CONFIG_PROC_PID_CPUSET
REG("cpuset",S_IRUGO, cpuset),
 #endif
-- 
1.5.3.5

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

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

[Richard Knutsson]

Sorry for the late response, have been away during the holidays.

Andrew Morton wrote:

On Mon, 17 Dec 2007 03:35:55 +0100 (MET) Richard Knutsson <[EMAIL PROTECTED]> 
wrote:

  

Convert handmade 'max' to max().

...

--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -473,7 +473,7 @@ asmlinkage long sys_msgctl(int msqid, int cmd, struct 
msqid_ds __user *buf)
up_read(_ids(ns).rw_mutex);
if (copy_to_user(buf, , sizeof(struct msginfo)))
return -EFAULT;
-   return (max_id < 0) ? 0 : max_id;
+   return max(max_id, 0);



I don't think I like that much.

I tend to think of max() as being an arithmetic sort of thing: pick the
largest of two scalars.

But the code which you're changing is a _logical_ operation.  It says "if
ipc_get_maxid() returned an error, then return zero.  Otherwise return
whatever ipc_get_maxid() returned".

Yes, max() will do the right thing here, but I think it's a bit of weird
trick?


I mean, if ipc_get_maxid() were a better function, it would return a -ve
errno when something failed rather than the present dopey hard-coded -1. 
In which case the code would read 


return IS_ERR_VALUE(max_id) ? 0 : max_id;

in which case, converting it to max() would be even less appropriate.  If
you see what I mean...
  

Yes, have to agree. Were too quick with the changing...

Thanks
Richard Knutsson

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

Re: [RFC PATCH 00/11] mcount tracing utility

[Frank Ch. Eigler]

Steven Rostedt <[EMAIL PROTECTED]> writes:

> The following patch series brings to vanilla Linux a bit of the RT kernel
> trace facility. This incorporates the "-pg" profiling option of gcc
> that will call the "mcount" function for all functions called in
> the kernel.
> [...]
> [Future:] SystemTap:
> --
> One thing that Arnaldo and I discussed last year was using systemtap to
> add hooks into the kernel to start and stop tracing.  

Sure.  The dual of this makes sense too: letting systemtap scripts
hook up to the mcount callback itself, for purposes beyond just
tracing the function calls.

> kprobes is too heavy to do on all funtion calls, but it would be
> perfect to add to non hot paths to start the tracer and stop the
> tracer.

(Note that kprobes are not the only event sources systemtap can use:
markers, timers, procfs control files, and some others.  Any
combination of these can be used in a script to express start/stop
decisions.)


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

Re: [PATCH] x86: kprobes change kprobe_handler flow

[Abhishek Sagar]

On 1/4/08, Masami Hiramatsu <[EMAIL PROTECTED]> wrote:
> > + case KPROBE_HIT_SS:
> > + if (*p->ainsn.insn == BREAKPOINT_INSTRUCTION) {
> > + regs->flags &= ~TF_MASK;
> > + regs->flags |= kcb->kprobe_saved_flags;
> > + return 0;
> > + } else {
> > + recursive_singlestep(p, regs, kcb);
> > + }
> > + break;
> > + default:
> > + /* impossible cases */
> > + WARN_ON(1);
>
> WARN_ON() does not call panic(). Since the kernel doesn't stop,
> we need to prepare singlestep after that.

We shouldn't panic in 'default'. First, we'll never hit this case, and
if we do then we can be sure that the fault is not due to a probe. So
instead of singlestepping we'll let the kernel handle it. If it cant,
it'll panic/die() for us. I'll try to cleanup this case and
incorporate these suggestions in a separate patch, as u suggested.

> Masami Hiramatsu
>
> Software Engineer
> Hitachi Computer Products (America) Inc.
> Software Solutions Division
>
> e-mail: [EMAIL PROTECTED], [EMAIL PROTECTED]

--
Thanks,
Abhishek Sagar
--
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/

Re: [PATCH] x86: kprobes change kprobe_handler flow

[Abhishek Sagar]

On 1/4/08, Masami Hiramatsu <[EMAIL PROTECTED]> wrote:
> I could understand what the original code did at last.
> If a kprobe is inserted on a breakpoint which other debugger inserts,
> it single step inline instead of out-of-line.(this is done in 
> prepare_singlestep)
> In this case, (p && kprobe_running() && kcb->kprobe_status==KPROBE_HIT_SS)
> is true and we need pass the control to the debugger.
> And if (*p->ainsn.insn != BREAKPOINT_INSTRUCTION) (or (p != 
> kprobe_running())) in
> that case, there may be some bugs.

Yes, we can only fault while singlestepping for a unique case, which
is when we're singlestepping (in-line) a breakpoint because a probe
was installed on it. All other scenarios are a BUG . That's also
assuming that no exception will preempt singlestepping, whose codepath
has a probe on it.

> Now I think your original suggestion is correct.
> Please fix it in another patch.

Ok.

> --
> Masami Hiramatsu
>
> Software Engineer
> Hitachi Computer Products (America) Inc.
> Software Solutions Division
>
> e-mail: [EMAIL PROTECTED], [EMAIL PROTECTED]

Thanks,
Abhishek Sagar
--
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/

Improve hackbench

[Zhang, Yanmin]

hackbench is to test Linux scheduler. The original program is at 
http://devresources.linux-foundation.org/craiger/hackbench/src/hackbench.c
Based on this multi-process version, a nice person created a multi-thread
version. Pls. see
http://www.bullopensource.org/posix/pi-futex/hackbench_pth.c

When I integrated them into my automation testing system, I found
a couple of issues and did some improvements.

1) Merge hackbench: I integrated hackbench_pth.c into hackbench and added a
new parameter which can be used to choose process mode or thread mode. The
default mode is process.

2) It runs too fast and ends in a couple of seconds. Sometimes it's too hard to 
debug
the issues. On my ia64 Montecito machines, the result looks weird when comparing
process mode and thread mode.
I want a stable result and hope the testing could run for a stable longer time, 
so I
might use performance tools to debug issues.
I added another new parameter,`loops`, which can be used to change variable 
loops,
so more messages will be passed from writers to receivers. Parameter 'loops' is 
equal to
100 by default.

For example on my 8-core x86_64:
[EMAIL PROTECTED] hackbench]$ uname -a
Linux lkp-st01-x8664 2.6.24-rc6 #1 SMP Fri Dec 21 08:32:31 CST 2007 x86_64 
x86_64 x86_64 GNU/Linux
[EMAIL PROTECTED] hackbench]$ ./hackbench 
Usage: hackbench [-pipe]  [process|thread] [loops]
[EMAIL PROTECTED] hackbench]$ ./hackbench 150 process 1000
Time: 151.533
[EMAIL PROTECTED] hackbench]$ ./hackbench 150 thread 1000
Time: 153.666


With the same new parameters, I did captured the SLUB issue discussed on LKML 
recently.

3) hackbench_pth.c will fail on ia64 machine because pthread_attr_setstacksize 
always
fails if the stack size is less than 196*1024. I moved this statement within a 
__ia64__ check.


This new program could be compiled with command line:
#gcc -g -Wall  -o hackbench hackbench.c -lpthread


Thank Ingo for his great comments!

-yanmin

---

/* Test groups of 20 processes spraying to 20 receivers */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define DATASIZE 100
static unsigned int loops = 100;
/*
 * 0 means thread mode and others mean process (default)
 */
static unsigned int process_mode = 1;

static int use_pipes = 0;

struct sender_context {
unsigned int num_fds;
int ready_out;
int wakefd;
int out_fds[0];
};

struct receiver_context {
unsigned int num_packets;
int in_fds[2];
int ready_out;
int wakefd;
};


static void barf(const char *msg)
{
fprintf(stderr, "%s (error: %s)\n", msg, strerror(errno));
exit(1);
}

static void print_usage_exit()
{
printf("Usage: hackbench [-pipe]  [process|thread] 
[loops]\n");
exit(1);
}

static void fdpair(int fds[2])
{
if (use_pipes) {
if (pipe(fds) == 0)
return;
} else {
if (socketpair(AF_UNIX, SOCK_STREAM, 0, fds) == 0)
return;
}
barf("Creating fdpair");
}

/* Block until we're ready to go */
static void ready(int ready_out, int wakefd)
{
char dummy;
struct pollfd pollfd = { .fd = wakefd, .events = POLLIN };

/* Tell them we're ready. */
if (write(ready_out, , 1) != 1)
barf("CLIENT: ready write");

/* Wait for "GO" signal */
if (poll(, 1, -1) != 1)
barf("poll");
}

/* Sender sprays loops messages down each file descriptor */
static void *sender(struct sender_context *ctx)
{
char data[DATASIZE];
unsigned int i, j;

ready(ctx->ready_out, ctx->wakefd);

/* Now pump to every receiver. */
for (i = 0; i < loops; i++) {
for (j = 0; j < ctx->num_fds; j++) {
int ret, done = 0;

again:
ret = write(ctx->out_fds[j], data + done, 
sizeof(data)-done);
if (ret < 0)
barf("SENDER: write");
done += ret;
if (done < sizeof(data))
goto again;
}
}

return NULL;
}


/* One receiver per fd */
static void *receiver(struct receiver_context* ctx)
{
unsigned int i;

if (process_mode)
close(ctx->in_fds[1]);

/* Wait for start... */
ready(ctx->ready_out, ctx->wakefd);

/* Receive them all */
for (i = 0; i < ctx->num_packets; i++) {
char data[DATASIZE];
int ret, done = 0;

again:
ret = read(ctx->in_fds[0], data + done, DATASIZE - done);
if (ret < 0)
barf("SERVER: read");
done += ret;
if (done < DATASIZE)
goto again;
}

return NULL;
}

pthread_t create_worker(void *ctx, void *(*func)(void 

[PATCH 5/5] CONNECTOR: return proper error code in cn_call_callback()

[Li Zefan]

Error code should be set to EINVAL instead of ENODEV if !queue_work().
There's another call of queue_work() which may set err to EINVAL.

Signed-off-by: Li Zefan <[EMAIL PROTECTED]>

---
 drivers/connector/connector.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index 865303b..37976dc 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -146,6 +146,8 @@ static int cn_call_callback(struct cn_msg *msg, void 
(*destruct_data)(void *), v
if (queue_work(dev->cbdev->cn_queue,
&__cbq->work))
err = 0;
+   else
+   err = -EINVAL;
} else {
struct cn_callback_data *d;

-- 
1.5.3.rc7

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

[PATCH 4/5] CONNECTOR: cleanup struct cn_callback_entry

[Li Zefan]

- 'cb' is a fake struct member. In a previous patch struct cn_callback
was renamed to cn_callback_id, so 'cb' should have been deleted at that
time.

- 'nls' isn't used and is redundant, we can retrieve this data through
cn_callback_entry.pdev->nls.

- 'seq' and 'group' should be u32, as they are declared to be u32 in
other places.

Signed-off-by: Li Zefan <[EMAIL PROTECTED]>

---
 drivers/connector/cn_queue.c |1 -
 include/linux/connector.h|4 +---
 2 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/connector/cn_queue.c b/drivers/connector/cn_queue.c
index 75122cb..23cc87a 100644
--- a/drivers/connector/cn_queue.c
+++ b/drivers/connector/cn_queue.c
@@ -104,7 +104,6 @@ int cn_queue_add_callback(struct cn_queue_dev *dev, char 
*name, struct cb_id *id
return -EINVAL;
}
 
-   cbq->nls = dev->nls;
cbq->seq = 0;
cbq->group = cbq->id.id.idx;
 
diff --git a/include/linux/connector.h b/include/linux/connector.h
index 7e18311..da6dd95 100644
--- a/include/linux/connector.h
+++ b/include/linux/connector.h
@@ -132,15 +132,13 @@ struct cn_callback_data {
 
 struct cn_callback_entry {
struct list_head callback_entry;
-   struct cn_callback *cb;
struct work_struct work;
struct cn_queue_dev *pdev;
 
struct cn_callback_id id;
struct cn_callback_data data;
 
-   int seq, group;
-   struct sock *nls;
+   u32 seq, group;
 };
 
 struct cn_ctl_entry {
-- 
1.5.3.rc7

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

[PATCH 3/5] CONNECTOR: cleanup struct cn_queue_dev

[Li Zefan]

Struct member netlink_groups is never used, and I don't see how it
can be useful.

Signed-off-by: Li Zefan <[EMAIL PROTECTED]>

---
 drivers/connector/cn_queue.c |1 -
 include/linux/connector.h|1 -
 2 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/connector/cn_queue.c b/drivers/connector/cn_queue.c
index 296f510..75122cb 100644
--- a/drivers/connector/cn_queue.c
+++ b/drivers/connector/cn_queue.c
@@ -146,7 +146,6 @@ struct cn_queue_dev *cn_queue_alloc_dev(char *name, struct 
sock *nls)
spin_lock_init(>queue_lock);
 
dev->nls = nls;
-   dev->netlink_groups = 0;
 
dev->cn_queue = create_workqueue(dev->name);
if (!dev->cn_queue) {
diff --git a/include/linux/connector.h b/include/linux/connector.h
index 13fc454..7e18311 100644
--- a/include/linux/connector.h
+++ b/include/linux/connector.h
@@ -112,7 +112,6 @@ struct cn_queue_dev {
struct list_head queue_list;
spinlock_t queue_lock;
 
-   int netlink_groups;
struct sock *nls;
 };
 
-- 
1.5.3.rc7

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

[PATCH 1/5] CONNECTOR: add a missing break in cn_netlink_send()

[Li Zefan]

Each entry in the list has a unique id, so just break out of the
loop if the matched id is found.

Signed-off-by: Li Zefan <[EMAIL PROTECTED]>

---
 drivers/connector/connector.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index 6883fcb..6e70963 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -88,6 +88,7 @@ int cn_netlink_send(struct cn_msg *msg, u32 __group, gfp_t 
gfp_mask)
if (cn_cb_equal(&__cbq->id.id, >id)) {
found = 1;
group = __cbq->group;
+   break;
}
}
spin_unlock_bh(>cbdev->queue_lock);
-- 
1.5.3.rc7

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

[PATCH 2/5] CONNECTOR: clean up {,__}cn_rx_skb()

[Li Zefan]

- __cn_rx_skb() does nothing but calls cn_call_callback(), it doesn't
check skb and msg sizes as the comment suggests, but cn_rx_skb() checks
those sizes.

- In cn_rx_skb() Local variable 'len' is not used. 'len' is probably
intended to be passed to skb_pull(), but here skb_pull() is not needed,
instead skb_free() is called.

Signed-off-by: Li Zefan <[EMAIL PROTECTED]>

---
 drivers/connector/connector.c |   30 --
 1 files changed, 4 insertions(+), 26 deletions(-)

diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index 6e70963..865303b 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -180,33 +180,14 @@ static int cn_call_callback(struct cn_msg *msg, void 
(*destruct_data)(void *), v
 }
 
 /*
- * Skb receive helper - checks skb and msg size and calls callback
- * helper.
- */
-static int __cn_rx_skb(struct sk_buff *skb, struct nlmsghdr *nlh)
-{
-   u32 pid, uid, seq, group;
-   struct cn_msg *msg;
-
-   pid = NETLINK_CREDS(skb)->pid;
-   uid = NETLINK_CREDS(skb)->uid;
-   seq = nlh->nlmsg_seq;
-   group = NETLINK_CB((skb)).dst_group;
-   msg = NLMSG_DATA(nlh);
-
-   return cn_call_callback(msg, (void (*)(void *))kfree_skb, skb);
-}
-
-/*
  * Main netlink receiving function.
  *
- * It checks skb and netlink header sizes and calls the skb receive
- * helper with a shared skb.
+ * It checks skb, netlink header and msg sizes, and calls callback helper.
  */
 static void cn_rx_skb(struct sk_buff *__skb)
 {
+   struct cn_msg *msg;
struct nlmsghdr *nlh;
-   u32 len;
int err;
struct sk_buff *skb;
 
@@ -222,11 +203,8 @@ static void cn_rx_skb(struct sk_buff *__skb)
return;
}
 
-   len = NLMSG_ALIGN(nlh->nlmsg_len);
-   if (len > skb->len)
-   len = skb->len;
-
-   err = __cn_rx_skb(skb, nlh);
+   msg = NLMSG_DATA(nlh);
+   err = cn_call_callback(msg, (void (*)(void *))kfree_skb, skb);
if (err < 0)
kfree_skb(skb);
}
-- 
1.5.3.rc7

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

Re: sata_nv + ADMA + Samsung disk problem

[Benjamin Herrenschmidt]

On Thu, 2008-01-03 at 19:43 -0600, Robert Hancock wrote:
> Benjamin Herrenschmidt wrote:
> >> Another thing about the PacDigi core:  one has to be very careful
> >> to avoid sequential accesses to sequential PCI locations when
> >> programming the chip -- it cannot handle merged register writes.
> >>
> >> So for any group of sequentially laid out registers, the code has
> >> to ensure it never writes two adjacent registers in sequence..
> > 
> > Ugh ? Write combining isn't permitted on normal registers afaik...
> > 
> > Ben.
> 
> Byte merging can be done by the chipset on MMIO writes (merging multiple 
> 8 or 16-bit writes into a single 32-bit cycle).

That is true, if they are consecutive. You mean that this HW is f*cked
up enough to actually have separate 8/16 bits registers that are
contiguous ? Yuck... I'm afraid you -have- to add reads in between to
guarantee that no merging will occur.

Cheers,

Ben.


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

Re: [2.6.24 patch] let EXT4DEV_FS depend on BROKEN

[Valdis . Kletnieks]

On Wed, 02 Jan 2008 13:51:32 PST, Eric Anopolsky said:

> their own kernels in the first place. IMHO, it's reasonable to expect
> the small minority of Linux users who want to compile their own kernels
> to learn that "EXPERIMENTAL" means something.

And what, exactly, does it mean, given that there's a bunch of stuff that's
tagged EXPERIMENTAL that's more solid/tested than a lot of stuff that *isn't*
marked with it?


pgpGGzBanjjNt.pgp
Description: PGP signature

[PATCH 6 of 8] x86: page.h: move remaining bits and pieces

[Jeremy Fitzhardinge]

# HG changeset patch
# User Jeremy Fitzhardinge <[EMAIL PROTECTED]>
# Date 1199319657 28800
# Node ID bba9287641ff90e836d090d80b5c0a846aab7162
# Parent  d617b72a0cc9d14bde2087d065c36d4ed3265761
x86: page.h: move remaining bits and pieces

Move the remaining odds and ends into page.h.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

---
 include/asm-x86/page.h|   23 +++
 include/asm-x86/page_32.h |   17 -
 include/asm-x86/page_64.h |   13 -
 3 files changed, 23 insertions(+), 30 deletions(-)

diff --git a/include/asm-x86/page.h b/include/asm-x86/page.h
--- a/include/asm-x86/page.h
+++ b/include/asm-x86/page.h
@@ -80,6 +80,10 @@ void clear_page(void *page);
 void clear_page(void *page);
 void copy_page(void *to, void *from);
 
+extern unsigned long end_pfn;
+extern unsigned long end_pfn_map;
+extern unsigned long phys_base;
+
 extern unsigned long __phys_addr(unsigned long);
 #define __phys_reloc_hide(x)   (x)
 
@@ -97,6 +101,8 @@ typedef struct { pteval_t pte; } pte_t;
 
 #define native_pte_val(x)  ((x).pte)
 #define native_make_pte(x) ((pte_t) { (x) } )
+
+#define vmemmap ((struct page *)VMEMMAP_START)
 
 #endif /* !__ASSEMBLY__ */
 
@@ -183,6 +189,19 @@ static inline pte_t native_make_pte(unsi
 #ifdef CONFIG_FLATMEM
 #define pfn_valid(pfn) ((pfn) < max_mapnr)
 #endif /* CONFIG_FLATMEM */
+
+extern int nx_enabled;
+
+/*
+ * This much address space is reserved for vmalloc() and iomap()
+ * as well as fixmap mappings.
+ */
+extern unsigned int __VMALLOC_RESERVE;
+extern int sysctl_legacy_va_layout;
+extern int page_is_ram(unsigned long pagenr);
+
+#define VMALLOC_RESERVE((unsigned long)__VMALLOC_RESERVE)
+#define MAXMEM (-__PAGE_OFFSET-__VMALLOC_RESERVE)
 
 #ifdef CONFIG_X86_USE_3DNOW
 #include 
@@ -325,6 +344,10 @@ static inline pmdval_t native_pmd_val(pm
 
 #endif /* __ASSEMBLY__ */
 
+#include 
+#include 
+
+#define __HAVE_ARCH_GATE_AREA 1
 
 #ifdef CONFIG_X86_32
 # include "page_32.h"
diff --git a/include/asm-x86/page_32.h b/include/asm-x86/page_32.h
--- a/include/asm-x86/page_32.h
+++ b/include/asm-x86/page_32.h
@@ -7,7 +7,6 @@
 /*
  * These are used to make use of C type-checking..
  */
-extern int nx_enabled;
 
 #endif /* !__ASSEMBLY__ */
 
@@ -15,26 +14,10 @@ extern int nx_enabled;
 
 struct vm_area_struct;
 
-/*
- * This much address space is reserved for vmalloc() and iomap()
- * as well as fixmap mappings.
- */
-extern unsigned int __VMALLOC_RESERVE;
-
-extern int sysctl_legacy_va_layout;
-
-extern int page_is_ram(unsigned long pagenr);
-
 #endif /* __ASSEMBLY__ */
 
-#define VMALLOC_RESERVE((unsigned long)__VMALLOC_RESERVE)
-#define MAXMEM (-__PAGE_OFFSET-__VMALLOC_RESERVE)
 
 
-#include 
-#include 
-
-#define __HAVE_ARCH_GATE_AREA 1
 #endif /* __KERNEL__ */
 
 #endif /* _I386_PAGE_H */
diff --git a/include/asm-x86/page_64.h b/include/asm-x86/page_64.h
--- a/include/asm-x86/page_64.h
+++ b/include/asm-x86/page_64.h
@@ -4,25 +4,12 @@
 #ifdef __KERNEL__
 #ifndef __ASSEMBLY__
 
-extern unsigned long end_pfn;
-extern unsigned long end_pfn_map;
-
-
-extern unsigned long phys_base;
-
 #endif /* !__ASSEMBLY__ */
 
 #ifndef __ASSEMBLY__
 
-#include 
 
 #endif /* __ASSEMBLY__ */
-
-#define __HAVE_ARCH_GATE_AREA 1
-#define vmemmap ((struct page *)VMEMMAP_START)
-
-#include 
-#include 
 
 #endif /* __KERNEL__ */
 


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

[PATCH 7 of 8] x86: page.h: move things back to their own files

[Jeremy Fitzhardinge]

# HG changeset patch
# User Jeremy Fitzhardinge <[EMAIL PROTECTED]>
# Date 1199321648 28800
# Node ID 22f6a5902285b58bfc1fbbd9e183498c9017bd78
# Parent  bba9287641ff90e836d090d80b5c0a846aab7162
x86: page.h: move things back to their own files

Oops, asm/page.h has turned into an #ifdef hellhole.  Move
32/64-specific things back to their own headers to make it somewhat
comprehensible...

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

---
 include/asm-x86/page.h|  212 +
 include/asm-x86/page_32.h |  123 +++---
 include/asm-x86/page_64.h |   74 ++-
 3 files changed, 187 insertions(+), 222 deletions(-)

diff --git a/include/asm-x86/Kbuild b/include/asm-x86/Kbuild
--- a/include/asm-x86/Kbuild
+++ b/include/asm-x86/Kbuild
@@ -15,8 +15,7 @@ unifdef-y += mce.h
 unifdef-y += mce.h
 unifdef-y += msr.h
 unifdef-y += mtrr.h
-unifdef-y += page_32.h
-unifdef-y += page_64.h
+unifdef-y += page.h
 unifdef-y += posix_types_32.h
 unifdef-y += posix_types_64.h
 unifdef-y += ptrace.h
diff --git a/include/asm-x86/page.h b/include/asm-x86/page.h
--- a/include/asm-x86/page.h
+++ b/include/asm-x86/page.h
@@ -7,6 +7,8 @@
 #define PAGE_SHIFT 12
 #define PAGE_SIZE  (_AC(1,UL) << PAGE_SHIFT)
 #define PAGE_MASK  (~(PAGE_SIZE-1))
+
+#ifdef __KERNEL__
 
 #define PHYSICAL_PAGE_MASK (PAGE_MASK & __PHYSICAL_MASK)
 #define PTE_MASK   PHYSICAL_PAGE_MASK
@@ -30,207 +32,10 @@
 #endif
 
 #ifdef CONFIG_X86_64
-#define PAGETABLE_LEVELS   4
-
-#define THREAD_ORDER   1
-#define THREAD_SIZE  (PAGE_SIZE << THREAD_ORDER)
-#define CURRENT_MASK (~(THREAD_SIZE-1))
-
-#define EXCEPTION_STACK_ORDER 0
-#define EXCEPTION_STKSZ (PAGE_SIZE << EXCEPTION_STACK_ORDER)
-
-#define DEBUG_STACK_ORDER (EXCEPTION_STACK_ORDER + 1)
-#define DEBUG_STKSZ (PAGE_SIZE << DEBUG_STACK_ORDER)
-
-#define IRQSTACK_ORDER 2
-#define IRQSTACKSIZE (PAGE_SIZE << IRQSTACK_ORDER)
-
-#define STACKFAULT_STACK 1
-#define DOUBLEFAULT_STACK 2
-#define NMI_STACK 3
-#define DEBUG_STACK 4
-#define MCE_STACK 5
-#define N_EXCEPTION_STACKS 5  /* hw limit: 7 */
-
-#define __PAGE_OFFSET   _AC(0x8100, UL)
-
-#define __PHYSICAL_START   CONFIG_PHYSICAL_START
-#define __KERNEL_ALIGN 0x20
-
-/*
- * Make sure kernel is aligned to 2MB address. Catching it at compile
- * time is better. Change your config file and compile the kernel
- * for a 2MB aligned address (CONFIG_PHYSICAL_START)
- */
-#if (CONFIG_PHYSICAL_START % __KERNEL_ALIGN) != 0
-#error "CONFIG_PHYSICAL_START must be a multiple of 2MB"
-#endif
-
-#define __START_KERNEL (__START_KERNEL_map + __PHYSICAL_START)
-#define __START_KERNEL_map _AC(0x8000, UL)
-
-/* See Documentation/x86_64/mm.txt for a description of the memory map. */
-#define __PHYSICAL_MASK_SHIFT  46
-#define __VIRTUAL_MASK_SHIFT   48
-
-#define KERNEL_TEXT_SIZE  (40*1024*1024)
-#define KERNEL_TEXT_START _AC(0x8000, UL)
-
-#ifndef __ASSEMBLY__
-void clear_page(void *page);
-void copy_page(void *to, void *from);
-
-extern unsigned long end_pfn;
-extern unsigned long end_pfn_map;
-extern unsigned long phys_base;
-
-extern unsigned long __phys_addr(unsigned long);
-#define __phys_reloc_hide(x)   (x)
-
-/*
- * These are used to make use of C type-checking..
- */
-typedef unsigned long  pteval_t;
-typedef unsigned long  pmdval_t;
-typedef unsigned long  pudval_t;
-typedef unsigned long  pgdval_t;
-typedef unsigned long  pgprotval_t;
-typedef unsigned long  phys_addr_t;
-
-typedef struct { pteval_t pte; } pte_t;
-
-#define native_pte_val(x)  ((x).pte)
-#define native_make_pte(x) ((pte_t) { (x) } )
-
-#define vmemmap ((struct page *)VMEMMAP_START)
-
-#endif /* !__ASSEMBLY__ */
-
+#include 
+#else
+#include 
 #endif /* CONFIG_X86_64 */
-
-#ifdef CONFIG_X86_32
-
-/*
- * This handles the memory map.
- *
- * A __PAGE_OFFSET of 0xC000 means that the kernel has
- * a virtual address space of one gigabyte, which limits the
- * amount of physical memory you can use to about 950MB.
- *
- * If you want more physical memory than this then see the CONFIG_HIGHMEM4G
- * and CONFIG_HIGHMEM64G options in the kernel configuration.
- */
-#define __PAGE_OFFSET  _AC(CONFIG_PAGE_OFFSET, UL)
-
-#ifdef CONFIG_X86_PAE
-#define __PHYSICAL_MASK_SHIFT  36
-#define __VIRTUAL_MASK_SHIFT   32
-#define PAGETABLE_LEVELS   3
-
-#ifndef __ASSEMBLY__
-typedef u64pteval_t;
-typedef u64pmdval_t;
-typedef u64pudval_t;
-typedef u64pgdval_t;
-typedef u64pgprotval_t;
-typedef u64phys_addr_t;
-
-typedef struct { unsigned long pte_low, pte_high; } pte_t;
-
-static inline unsigned long long native_pte_val(pte_t pte)
-{
-   return pte.pte_low | ((unsigned long long)pte.pte_high << 32);
-}
-
-static inline pte_t native_make_pte(unsigned long long val)
-{
-   return (pte_t) { .pte_low = val, .pte_high = (val >> 32) } ;
-}
-
-#endif /* __ASSEMBLY__
- */
-#else  /* !CONFIG_X86_PAE */
-#define 

[PATCH 0 of 8] x86: unify asm/page.h

[Jeremy Fitzhardinge]

Hi Ingo,

Here's a series which concentrates on unifying and cleaning up
asm-86/page*.h.  Each patch in the series restricts itself to doing
one thing fairly simply, so it should be fairly low-risk and easy to
bisect.

The early version of this patch got rid of asm/page_32|64.h entirely,
but I decided the resulting #ifdef hell was too hard to deal with, so
I moved purely 32/64-bit specific stuff into their own files.

Thanks,
J


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

[PATCH 8 of 8] x86/efi: fix improper use of lvalue

[Jeremy Fitzhardinge]

# HG changeset patch
# User Jeremy Fitzhardinge <[EMAIL PROTECTED]>
# Date 1199391030 28800
# Node ID 5d35c92fdf0e2c52edbb6fc4ccd06c7f65f25009
# Parent  22f6a5902285b58bfc1fbbd9e183498c9017bd78
x86/efi: fix improper use of lvalue

pgd_val is no longer valid as an lvalue, so don't try to assign to it.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

---
 arch/x86/kernel/efi_64.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/efi_64.c b/arch/x86/kernel/efi_64.c
--- a/arch/x86/kernel/efi_64.c
+++ b/arch/x86/kernel/efi_64.c
@@ -84,7 +84,7 @@ void __init efi_call_phys_prelog(void)
local_irq_save(efi_flags);
early_runtime_code_mapping_set_exec(1);
vaddress = (unsigned long)__va(0x0UL);
-   pgd_val(save_pgd) = pgd_val(*pgd_offset_k(0x0UL));
+   save_pgd = *pgd_offset_k(0x0UL);
set_pgd(pgd_offset_k(0x0UL), *pgd_offset_k(vaddress));
__flush_tlb_all();
 }


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

[PATCH 4 of 8] x86: page.h: move and unify types for pagetable entry definitions

[Jeremy Fitzhardinge]

# HG changeset patch
# User Jeremy Fitzhardinge <[EMAIL PROTECTED]>
# Date 1199319654 28800
# Node ID 3bd7db6e85e66e7f3362874802df26a82fcb2d92
# Parent  f7e7db3facd9406545103164f9be8f9ba1a2b549
x86: page.h: move and unify types for pagetable entry definitions

This patch:

1. Defines arch-specific types for the contents of a pagetable entry.
That is, 32-bit entries for 32-bit non-PAE, and 64-bit entries for
32-bit PAE and 64-bit.  However, even though the latter two are the
same size, they're defined with different types in order to retain
compatibility with printk format strings, etc.

2. Defines arch-specific pte_t.  This is different because 32-bit PAE
defines it in two halves, whereas 32-bit PAE and 64-bit define it as a
single entry.  All the other pagetable levels can be defined in a
common way.  This also defines arch-specific pte_val/make_pte functions.

3. Define PAGETABLE_LEVELS for each architecture variation, for later use.

4. Define common pagetable entry accessors in a paravirt-compatible
way. (64-bit does not yet use paravirt-ops in any way).

5. Convert a few instances of using a *_val() as an lvalue where it is
no longer a macro.  There are still places in the 64-bit code which
use pte_val() as an lvalue.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

---
 include/asm-x86/page.h   |  139 +-
 include/asm-x86/page_32.h|   83 -
 include/asm-x86/page_64.h|   22 --
 include/asm-x86/pgtable_64.h |6 -
 4 files changed, 141 insertions(+), 109 deletions(-)

diff --git a/include/asm-x86/page.h b/include/asm-x86/page.h
--- a/include/asm-x86/page.h
+++ b/include/asm-x86/page.h
@@ -9,6 +9,7 @@
 #define PAGE_MASK  (~(PAGE_SIZE-1))
 
 #define PHYSICAL_PAGE_MASK (PAGE_MASK & __PHYSICAL_MASK)
+#define PTE_MASK   PHYSICAL_PAGE_MASK
 
 #define LARGE_PAGE_SIZE(_AC(1,UL) << PMD_SHIFT)
 #define LARGE_PAGE_MASK(~(LARGE_PAGE_SIZE-1))
@@ -21,11 +22,16 @@
 /* to align the pointer to the (next) page boundary */
 #define PAGE_ALIGN(addr)   (((addr)+PAGE_SIZE-1)_MASK)
 
-#define __PHYSICAL_MASK((_AC(1,UL) << __PHYSICAL_MASK_SHIFT) - 
1)
+#define __PHYSICAL_MASK_AT(phys_addr_t, (_AC(1,ULL) << 
__PHYSICAL_MASK_SHIFT) - 1)
 #define __VIRTUAL_MASK ((_AC(1,UL) << __VIRTUAL_MASK_SHIFT) - 1)
 
+#ifndef __ASSEMBLER__
+#include 
+#endif
 
 #ifdef CONFIG_X86_64
+#define PAGETABLE_LEVELS   4
+
 #define THREAD_ORDER   1
 #define THREAD_SIZE  (PAGE_SIZE << THREAD_ORDER)
 #define CURRENT_MASK (~(THREAD_SIZE-1))
@@ -73,6 +79,22 @@
 #ifndef __ASSEMBLY__
 void clear_page(void *page);
 void copy_page(void *to, void *from);
+
+/*
+ * These are used to make use of C type-checking..
+ */
+typedef unsigned long  pteval_t;
+typedef unsigned long  pmdval_t;
+typedef unsigned long  pudval_t;
+typedef unsigned long  pgdval_t;
+typedef unsigned long  pgprotval_t;
+typedef unsigned long  phys_addr_t;
+
+typedef struct { pteval_t pte; } pte_t;
+
+#define native_pte_val(x)  ((x).pte)
+#define native_make_pte(x) ((pte_t) { (x) } )
+
 #endif /* !__ASSEMBLY__ */
 
 #endif /* CONFIG_X86_64 */
@@ -94,9 +116,57 @@ void copy_page(void *to, void *from);
 #ifdef CONFIG_X86_PAE
 #define __PHYSICAL_MASK_SHIFT  36
 #define __VIRTUAL_MASK_SHIFT   32
+#define PAGETABLE_LEVELS   3
+
+#ifndef __ASSEMBLY__
+typedef u64pteval_t;
+typedef u64pmdval_t;
+typedef u64pudval_t;
+typedef u64pgdval_t;
+typedef u64pgprotval_t;
+typedef u64phys_addr_t;
+
+typedef struct { unsigned long pte_low, pte_high; } pte_t;
+
+static inline unsigned long long native_pte_val(pte_t pte)
+{
+   return pte.pte_low | ((unsigned long long)pte.pte_high << 32);
+}
+
+static inline pte_t native_make_pte(unsigned long long val)
+{
+   return (pte_t) { .pte_low = val, .pte_high = (val >> 32) } ;
+}
+
+#endif /* __ASSEMBLY__
+ */
 #else  /* !CONFIG_X86_PAE */
 #define __PHYSICAL_MASK_SHIFT  32
 #define __VIRTUAL_MASK_SHIFT   32
+#define PAGETABLE_LEVELS   2
+
+#ifndef __ASSEMBLY__
+typedef unsigned long  pteval_t;
+typedef unsigned long  pmdval_t;
+typedef unsigned long  pudval_t;
+typedef unsigned long  pgdval_t;
+typedef unsigned long  pgprotval_t;
+typedef unsigned long  phys_addr_t;
+
+typedef struct { pteval_t pte_low; } pte_t;
+typedef pte_t boot_pte_t;
+
+static inline unsigned long native_pte_val(pte_t pte)
+{
+   return pte.pte_low;
+}
+
+static inline pte_t native_make_pte(unsigned long val)
+{
+   return (pte_t) { .pte_low = val };
+}
+
+#endif /* __ASSEMBLY__ */
 #endif /* CONFIG_X86_PAE */
 
 #ifdef CONFIG_HUGETLB_PAGE
@@ -159,6 +229,76 @@ static void inline copy_user_page(void *
alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr)
 #define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE
 
+typedef struct { pgdval_t pgd; } pgd_t;
+typedef struct { pgprotval_t pgprot; } pgprot_t;
+
+static inline pgd_t native_make_pgd(pgdval_t 

[PATCH 1 of 8] x86: page.h: unify constants

[Jeremy Fitzhardinge]

# HG changeset patch
# User Jeremy Fitzhardinge <[EMAIL PROTECTED]>
# Date 1199317360 28800
# Node ID ba0ec40a50a7aef1a3153cea124c35e261f5a2df
# Parent  c45c263179cb78284b6b869c574457df088027d1
x86: page.h: unify constants

There are many constants which are shared by 32 and 64-bit.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

---
 include/asm-x86/page.h|  130 +
 include/asm-x86/page_32.h |   46 ---
 include/asm-x86/page_64.h |   73 -
 3 files changed, 119 insertions(+), 130 deletions(-)

diff --git a/include/asm-x86/page.h b/include/asm-x86/page.h
--- a/include/asm-x86/page.h
+++ b/include/asm-x86/page.h
@@ -1,13 +1,116 @@
-#ifdef __KERNEL__
-# ifdef CONFIG_X86_32
-#  include "page_32.h"
-# else
-#  include "page_64.h"
-# endif
+#ifndef _ASM_X86_PAGE_H
+#define _ASM_X86_PAGE_H
+
+#include 
+
+/* PAGE_SHIFT determines the page size */
+#define PAGE_SHIFT 12
+#define PAGE_SIZE  (_AC(1,UL) << PAGE_SHIFT)
+#define PAGE_MASK  (~(PAGE_SIZE-1))
+
+#define PHYSICAL_PAGE_MASK (PAGE_MASK & __PHYSICAL_MASK)
+
+#define LARGE_PAGE_SIZE(_AC(1,UL) << PMD_SHIFT)
+#define LARGE_PAGE_MASK(~(LARGE_PAGE_SIZE-1))
+
+#define HPAGE_SHIFTPMD_SHIFT
+#define HPAGE_SIZE (_AC(1,UL) << HPAGE_SHIFT)
+#define HPAGE_MASK (~(HPAGE_SIZE - 1))
+#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
+
+/* to align the pointer to the (next) page boundary */
+#define PAGE_ALIGN(addr)   (((addr)+PAGE_SIZE-1)_MASK)
+
+#define __PHYSICAL_MASK((_AC(1,UL) << __PHYSICAL_MASK_SHIFT) - 
1)
+#define __VIRTUAL_MASK ((_AC(1,UL) << __VIRTUAL_MASK_SHIFT) - 1)
+
+
+#ifdef CONFIG_X86_64
+#define THREAD_ORDER   1
+#define THREAD_SIZE  (PAGE_SIZE << THREAD_ORDER)
+#define CURRENT_MASK (~(THREAD_SIZE-1))
+
+#define EXCEPTION_STACK_ORDER 0
+#define EXCEPTION_STKSZ (PAGE_SIZE << EXCEPTION_STACK_ORDER)
+
+#define DEBUG_STACK_ORDER (EXCEPTION_STACK_ORDER + 1)
+#define DEBUG_STKSZ (PAGE_SIZE << DEBUG_STACK_ORDER)
+
+#define IRQSTACK_ORDER 2
+#define IRQSTACKSIZE (PAGE_SIZE << IRQSTACK_ORDER)
+
+#define STACKFAULT_STACK 1
+#define DOUBLEFAULT_STACK 2
+#define NMI_STACK 3
+#define DEBUG_STACK 4
+#define MCE_STACK 5
+#define N_EXCEPTION_STACKS 5  /* hw limit: 7 */
+
+#define __PAGE_OFFSET   _AC(0x8100, UL)
+
+#define __PHYSICAL_START   CONFIG_PHYSICAL_START
+#define __KERNEL_ALIGN 0x20
+
+/*
+ * Make sure kernel is aligned to 2MB address. Catching it at compile
+ * time is better. Change your config file and compile the kernel
+ * for a 2MB aligned address (CONFIG_PHYSICAL_START)
+ */
+#if (CONFIG_PHYSICAL_START % __KERNEL_ALIGN) != 0
+#error "CONFIG_PHYSICAL_START must be a multiple of 2MB"
+#endif
+
+#define __START_KERNEL (__START_KERNEL_map + __PHYSICAL_START)
+#define __START_KERNEL_map _AC(0x8000, UL)
+
+/* See Documentation/x86_64/mm.txt for a description of the memory map. */
+#define __PHYSICAL_MASK_SHIFT  46
+#define __VIRTUAL_MASK_SHIFT   48
+
+#define KERNEL_TEXT_SIZE  (40*1024*1024)
+#define KERNEL_TEXT_START _AC(0x8000, UL)
+
+#endif /* CONFIG_X86_64 */
+
+#ifdef CONFIG_X86_32
+
+/*
+ * This handles the memory map.
+ *
+ * A __PAGE_OFFSET of 0xC000 means that the kernel has
+ * a virtual address space of one gigabyte, which limits the
+ * amount of physical memory you can use to about 950MB.
+ *
+ * If you want more physical memory than this then see the CONFIG_HIGHMEM4G
+ * and CONFIG_HIGHMEM64G options in the kernel configuration.
+ */
+#define __PAGE_OFFSET  _AC(CONFIG_PAGE_OFFSET, UL)
+
+#ifdef CONFIG_X86_PAE
+#define __PHYSICAL_MASK_SHIFT  36
+#define __VIRTUAL_MASK_SHIFT   32
+#else  /* !CONFIG_X86_PAE */
+#define __PHYSICAL_MASK_SHIFT  32
+#define __VIRTUAL_MASK_SHIFT   32
+#endif /* CONFIG_X86_PAE */
+
+#ifdef CONFIG_HUGETLB_PAGE
+#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
+#endif
+
+#endif /* CONFIG_X86_32 */
+
+#define PAGE_OFFSET((unsigned long)__PAGE_OFFSET)
+
+#define VM_DATA_DEFAULT_FLAGS \
+   (((current->personality & READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \
+VM_READ | VM_WRITE | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
+
+
+#ifdef CONFIG_X86_32
+# include "page_32.h"
 #else
-# ifdef __i386__
-#  include "page_32.h"
-# else
-#  include "page_64.h"
-# endif
+# include "page_64.h"
 #endif
+
+#endif /* _ASM_X86_PAGE_H */
diff --git a/include/asm-x86/page_32.h b/include/asm-x86/page_32.h
--- a/include/asm-x86/page_32.h
+++ b/include/asm-x86/page_32.h
@@ -1,13 +1,5 @@
 #ifndef _I386_PAGE_H
 #define _I386_PAGE_H
-
-/* PAGE_SHIFT determines the page size */
-#define PAGE_SHIFT 12
-#define PAGE_SIZE  (1UL << PAGE_SHIFT)
-#define PAGE_MASK  (~(PAGE_SIZE-1))
-
-#define LARGE_PAGE_MASK (~(LARGE_PAGE_SIZE-1))
-#define LARGE_PAGE_SIZE (1UL << PMD_SHIFT)
 
 #ifdef __KERNEL__
 #ifndef __ASSEMBLY__
@@ -111,7 +103,6 @@ static inline 

[PATCH 5 of 8] x86: page.h: move pa and va related things

[Jeremy Fitzhardinge]

# HG changeset patch
# User Jeremy Fitzhardinge <[EMAIL PROTECTED]>
# Date 1199319656 28800
# Node ID d617b72a0cc9d14bde2087d065c36d4ed3265761
# Parent  3bd7db6e85e66e7f3362874802df26a82fcb2d92
x86: page.h: move pa and va related things

Move and unify the virtual<->physical address space conversion
functions.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

---
 include/asm-x86/page.h|   24 
 include/asm-x86/page_32.h |   11 ---
 include/asm-x86/page_64.h |   13 -
 3 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/include/asm-x86/page.h b/include/asm-x86/page.h
--- a/include/asm-x86/page.h
+++ b/include/asm-x86/page.h
@@ -79,6 +79,9 @@
 #ifndef __ASSEMBLY__
 void clear_page(void *page);
 void copy_page(void *to, void *from);
+
+extern unsigned long __phys_addr(unsigned long);
+#define __phys_reloc_hide(x)   (x)
 
 /*
  * These are used to make use of C type-checking..
@@ -174,6 +177,13 @@ static inline pte_t native_make_pte(unsi
 #endif
 
 #ifndef __ASSEMBLY__
+#define __phys_addr(x) ((x)-PAGE_OFFSET)
+#define __phys_reloc_hide(x)   RELOC_HIDE((x), 0)
+
+#ifdef CONFIG_FLATMEM
+#define pfn_valid(pfn) ((pfn) < max_mapnr)
+#endif /* CONFIG_FLATMEM */
+
 #ifdef CONFIG_X86_USE_3DNOW
 #include 
 
@@ -299,6 +309,20 @@ static inline pmdval_t native_pmd_val(pm
 
 #endif /* CONFIG_PARAVIRT */
 
+#define __pa(x)__phys_addr((unsigned long)(x))
+/* __pa_symbol should be used for C visible symbols.
+   This seems to be the official gcc blessed way to do such arithmetic. */
+#define __pa_symbol(x) __pa(__phys_reloc_hide((unsigned long)(x)))
+
+#define __va(x)((void *)((unsigned 
long)(x)+PAGE_OFFSET))
+
+#define __boot_va(x)   __va(x)
+#define __boot_pa(x)   __pa(x)
+
+#define virt_to_page(kaddr)pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
+#define pfn_to_kaddr(pfn)  __va((pfn) << PAGE_SHIFT)
+#define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
+
 #endif /* __ASSEMBLY__ */
 
 
diff --git a/include/asm-x86/page_32.h b/include/asm-x86/page_32.h
--- a/include/asm-x86/page_32.h
+++ b/include/asm-x86/page_32.h
@@ -29,18 +29,7 @@ extern int page_is_ram(unsigned long pag
 
 #define VMALLOC_RESERVE((unsigned long)__VMALLOC_RESERVE)
 #define MAXMEM (-__PAGE_OFFSET-__VMALLOC_RESERVE)
-#define __pa(x)((unsigned long)(x)-PAGE_OFFSET)
-/* __pa_symbol should be used for C visible symbols.
-   This seems to be the official gcc blessed way to do such arithmetic. */
-#define __pa_symbol(x)  __pa(RELOC_HIDE((unsigned long)(x),0))
-#define __va(x)((void *)((unsigned 
long)(x)+PAGE_OFFSET))
-#define pfn_to_kaddr(pfn)  __va((pfn) << PAGE_SHIFT)
-#ifdef CONFIG_FLATMEM
-#define pfn_valid(pfn) ((pfn) < max_mapnr)
-#endif /* CONFIG_FLATMEM */
-#define virt_to_page(kaddr)pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
 
-#define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
 
 #include 
 #include 
diff --git a/include/asm-x86/page_64.h b/include/asm-x86/page_64.h
--- a/include/asm-x86/page_64.h
+++ b/include/asm-x86/page_64.h
@@ -16,20 +16,7 @@ extern unsigned long phys_base;
 
 #include 
 
-extern unsigned long __phys_addr(unsigned long);
-
 #endif /* __ASSEMBLY__ */
-
-#define __pa(x)__phys_addr((unsigned long)(x))
-#define __pa_symbol(x) __phys_addr((unsigned long)(x))
-
-#define __va(x)((void *)((unsigned 
long)(x)+PAGE_OFFSET))
-#define __boot_va(x)   __va(x)
-#define __boot_pa(x)   __pa(x)
-
-#define virt_to_page(kaddr)pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
-#define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
-#define pfn_to_kaddr(pfn)  __va((pfn) << PAGE_SHIFT)
 
 #define __HAVE_ARCH_GATE_AREA 1
 #define vmemmap ((struct page *)VMEMMAP_START)


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

[PATCH 3 of 8] x86: add _AT() macro to conditionally cast

[Jeremy Fitzhardinge]

# HG changeset patch
# User Jeremy Fitzhardinge <[EMAIL PROTECTED]>
# Date 1199317452 28800
# Node ID f7e7db3facd9406545103164f9be8f9ba1a2b549
# Parent  4d9a413a0f4c1d98dbea704f0366457b5117045d
x86: add _AT() macro to conditionally cast

Define _AT(type, value) to conditionally cast a value when compiling C
code, but not when used in assembler.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

---
 include/linux/const.h |5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/const.h b/include/linux/const.h
--- a/include/linux/const.h
+++ b/include/linux/const.h
@@ -7,13 +7,18 @@
  * C code.  Therefore we cannot annotate them always with
  * 'UL' and other type specifiers unilaterally.  We
  * use the following macros to deal with this.
+ *
+ * Similarly, _AT() will cast an expression with a type in C, but
+ * leave it unchanged in asm.
  */
 
 #ifdef __ASSEMBLY__
 #define _AC(X,Y)   X
+#define _AT(T,X)   X
 #else
 #define __AC(X,Y)  (X##Y)
 #define _AC(X,Y)   __AC(X,Y)
+#define _AT(T,X)   ((T)(X))
 #endif
 
 #endif /* !(_LINUX_CONST_H) */


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

[PATCH 2 of 8] x86: page.h: unify page copying and clearing

[Jeremy Fitzhardinge]

# HG changeset patch
# User Jeremy Fitzhardinge <[EMAIL PROTECTED]>
# Date 1199317362 28800
# Node ID 4d9a413a0f4c1d98dbea704f0366457b5117045d
# Parent  ba0ec40a50a7aef1a3153cea124c35e261f5a2df
x86: page.h: unify page copying and clearing

Move, and to some extent unify, the various page copying and clearing
functions.  The only unification here is that both architectures use
the same function for copying/clearing user and kernel pages.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

---
 include/asm-x86/page.h|   55 +
 include/asm-x86/page_32.h |   53 ---
 include/asm-x86/page_64.h |   20 
 3 files changed, 55 insertions(+), 73 deletions(-)

diff --git a/include/asm-x86/page.h b/include/asm-x86/page.h
--- a/include/asm-x86/page.h
+++ b/include/asm-x86/page.h
@@ -70,6 +70,11 @@
 #define KERNEL_TEXT_SIZE  (40*1024*1024)
 #define KERNEL_TEXT_START _AC(0x8000, UL)
 
+#ifndef __ASSEMBLY__
+void clear_page(void *page);
+void copy_page(void *to, void *from);
+#endif /* !__ASSEMBLY__ */
+
 #endif /* CONFIG_X86_64 */
 
 #ifdef CONFIG_X86_32
@@ -98,6 +103,34 @@
 #define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
 #endif
 
+#ifndef __ASSEMBLY__
+#ifdef CONFIG_X86_USE_3DNOW
+#include 
+
+static inline void clear_page(void *page)
+{
+   mmx_clear_page(page);
+}
+
+static inline void copy_page(void *to, void *from)
+{
+   mmx_copy_page(to, from);
+}
+#else  /* !CONFIG_X86_USE_3DNOW */
+#include 
+
+static inline void clear_page(void *page)
+{
+   memset(page, 0, PAGE_SIZE);
+}
+
+static inline void copy_page(void *to, void *from)
+{
+   memcpy(to, from, PAGE_SIZE);
+}
+#endif /* CONFIG_X86_3DNOW */
+#endif /* !__ASSEMBLY__ */
+
 #endif /* CONFIG_X86_32 */
 
 #define PAGE_OFFSET((unsigned long)__PAGE_OFFSET)
@@ -107,6 +140,28 @@
 VM_READ | VM_WRITE | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
 
 
+#ifndef __ASSEMBLY__
+struct page;
+
+static void inline clear_user_page(void *page, unsigned long vaddr,
+   struct page *pg)
+{
+   clear_page(page);
+}
+
+static void inline copy_user_page(void *to, void *from, unsigned long vaddr,
+   struct page *topage)
+{
+   copy_page(to, from);
+}
+
+#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \
+   alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr)
+#define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE
+
+#endif /* __ASSEMBLY__ */
+
+
 #ifdef CONFIG_X86_32
 # include "page_32.h"
 #else
diff --git a/include/asm-x86/page_32.h b/include/asm-x86/page_32.h
--- a/include/asm-x86/page_32.h
+++ b/include/asm-x86/page_32.h
@@ -3,59 +3,6 @@
 
 #ifdef __KERNEL__
 #ifndef __ASSEMBLY__
-
-#include 
-
-#ifdef CONFIG_X86_USE_3DNOW
-
-#include 
-
-static inline void clear_page(void *page)
-{
-   mmx_clear_page(page);
-}
-
-static inline void copy_page(void *to, void *from)
-{
-   mmx_copy_page(to, from);
-}
-
-#else
-
-/*
- * On older X86 processors it's not a win to use MMX here it seems.
- * Maybe the K6-III ?
- */
- 
-static inline void clear_page(void *page)
-{
-   memset(page, 0, PAGE_SIZE);
-}
-
-static inline void copy_page(void *to, void *from)
-{
-   memcpy(to, from, PAGE_SIZE);
-}
-
-#endif
-
-struct page;
-
-static void inline clear_user_page(void *page, unsigned long vaddr,
-   struct page *pg)
-{
-   clear_page(page);
-}
-
-static void inline copy_user_page(void *to, void *from, unsigned long vaddr,
-   struct page *topage)
-{
-   copy_page(to, from);
-}
-
-#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \
-   alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr)
-#define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE
 
 /*
  * These are used to make use of C type-checking..
diff --git a/include/asm-x86/page_64.h b/include/asm-x86/page_64.h
--- a/include/asm-x86/page_64.h
+++ b/include/asm-x86/page_64.h
@@ -7,26 +7,6 @@ extern unsigned long end_pfn;
 extern unsigned long end_pfn;
 extern unsigned long end_pfn_map;
 
-void clear_page(void *page);
-void copy_page(void *to, void *from);
-
-struct page;
-
-static void inline clear_user_page(void *page, unsigned long vaddr,
-   struct page *pg)
-{
-   clear_page(page);
-}
-
-static void inline copy_user_page(void *to, void *from, unsigned long vaddr,
-   struct page *topage)
-{
-   copy_page(to, from);
-}
-
-#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \
-   alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr)
-#define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE
 /*
  * These are used to make use of C type-checking..
  */


--
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: [ofa-general] [PATCH] IB/ehca: Forward event client-reregister-required to registered clients

[Roland Dreier]

thanks, applied.
--
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/

Re: [PATCH] procfs: provide slub's /proc/slabinfo

[Matt Mackall]

On Fri, 2008-01-04 at 03:45 +0100, Andi Kleen wrote:
> > I still have trouble to see that SLOB still has much to offer. An embedded 
> > allocator that in many cases has more allocation overhead than the default 
> > one? Ok you still have advantages if allocations are rounded up to the 
> > next power of two for a kmalloc and because of the combining of different 
> > types of allocations in a single slab if there are an overall small number 
> > of allocations. If one would create a custom slab for the worst problems 
> > there then this may also go away.
> 
> I suspect it would be a good idea anyways to reevaluate the power of two
> slabs. Perhaps a better distribution can be found based on some profiling?
> I did profile kmalloc using a systemtap script some time ago but don't
> remember the results exactly, but iirc it looked like it could be improved.

We can roughly group kmalloced objects into two classes:

a) intrinsically variable-sized (strings, etc.)
b) fixed-sized objects that nonetheless don't have their own caches

For (a), we can expect the size distribution to be approximately a
scale-invariant power distribution. So buckets of the form n**x make a
fair amount of sense. We might consider n less than 2 though.

For objects of type (b) that occur in significant numbers, well, we
might just want to add more caches. SLUB's merging of same-sized caches
will reduce the pain here.

> A long time ago i also had some code to let the network stack give hints
> about its MMUs to slab to create fitting slabs for packets. But that
> was never really pushed forward because it turned out it didn't help
> much for the most common 1.5K MTU -- always only two packets fit into
> a page.

Yes, that and task_struct kinda make you want to cry. Large-order
SLAB/SLUB/SLOB would go a long way to fix that, but has its own problems
of course.

One could imagine restructuring things so that the buddy allocator only
extended down to 64k or so and below that, gfp and friends called
through SLAB/SLUB/SLOB.

-- 
Mathematics is the supreme nostalgia of our time.

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

Re: [PATCH x86] [11/16] Compile apm and voyager module only when selected in Kconfig

[Stephen Rothwell]

On Thu,  3 Jan 2008 16:42:25 +0100 (CET) Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> +++ linux/arch/x86/Kconfig
> @@ -1219,6 +1219,11 @@ source "kernel/power/Kconfig"
>  
>  source "drivers/acpi/Kconfig"
>  
> +config X86_APM_BOOT
> + bool
> + default y
> + depends on APM

Does this want to be
depends on APM || APM_MODULE

> +++ linux/arch/x86/boot/apm.c
> @@ -19,8 +19,6 @@
>  
>  #include "boot.h"
>  
> -#if defined(CONFIG_APM) || defined(CONFIG_APM_MODULE)

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgp8aWGZLKsNh.pgp
Description: PGP signature

Re: [PATCH] procfs: provide slub's /proc/slabinfo

[Matt Mackall]

On Thu, 2008-01-03 at 18:21 -0800, Christoph Lameter wrote:
> On Thu, 3 Jan 2008, Matt Mackall wrote:
> 
> > There are three downsides with the slab-like approach: internal
> > fragmentation, under-utilized slabs, and pinning.
> > 
> > The first is the situation where we ask for a kmalloc of 33 bytes and
> > get 64. I think the average kmalloc wastes about 30% trying to fit into
> > power-of-two buckets. We can tune our buckets a bit, but I think in
> > general trying to back kmalloc with slabs is problematic. SLOB has a
> > 2-byte granularity up to the point where it just hands things off to the
> > page allocator.
> 
> The 2 byte overhead of SLOB becomes a liability when it comes to correctly 
> aligning power of two sized object. SLOB has to add two bytes and then 
> align the combined object (argh!).

It does no such thing. Only kmallocs have 2-byte headers and kmalloc is
never aligned. RTFS, it's quite short.

>  SLUB can align these without a 2 byte 
> overhead. In some configurations this results in SLUB using even less 
> memory than SLOB. See f.e. Pekka's test at 
> http://marc.info/?l=linux-kernel=118405559214029=2

Available memory after boot is not a particularly stable measurement and
not valid if there's memory pressure. At any rate, I wasn't able to
reproduce this.

> > If we tried to add more slabs to fill the gaps, we'd exacerbate the
> > second problem: because only one type of object can go on a slab, a lot
> > of slabs are half-full. SLUB's automerging of slabs helps some here, but
> > is still restricted to objects of the same size.
> 
> The advantage of SLOB is to be able to put objects of multiple sizes into 
> the same slab page. That advantage goes away once we have more than a few 
> objects per slab because SLUB can store object in a denser way than SLOB.

Ugh, Christoph. Can you please stop repeating this falsehood? I'm sick
and tired of debunking it. There is no overhead for any objects with
externally-known size. So unless SLUB actually has negative overhead,
this just isn't true.

> > And finally, there's the whole pinning problem: we can have a cache like
> > the dcache grow very large and then contract, but still have most of its
> > slabs used by pinned dentries. Christoph has some rather hairy patches
> > to address this, but SLOB doesn't have much of a problem here - those
> > pages are still available to allocate other objects on.
> 
> Well if you just have a few dentries then they are likely all pinned. A 
> large number of dentries will typically result in reclaimable slabs.
> The slab defrag patchset not only deals with the dcache issue but provides 
> similar solutions for inode and buffer_heads. Support for other slabs that
> defragment can be added by providing two hooks per slab.

What's your point? Slabs have a inherent pinning problem that's ugly to
combat. SLOB doesn't.

>  > By comparison, SLOB's big downsides are that it's not O(1) and it has a
> > single lock. But it's currently fast enough to keep up with SLUB on
> > kernel compiles on my 2G box and Nick had an allocator benchmark where
> > scalability didn't fall off until beyond 4 CPUs.
> 
> Both SLOB and SLAB suffer from the single lock problem. SLOB does it for 
> every item allocated. SLAB does it for every nth item allocated. Given 
> a fast allocation from multiple processors both will generate a bouncing 
> cacheline. SLUB can take pages from the page allocator pools and allocate 
> all objects from it without taking a lock.

That's very nice, but SLOB already runs lockless on most of its target
machines by virtue of them being UP. Lock contention just isn't
interesting to SLOB. 

> > > right now we are far away from it - SLUB has an order of
> magnitude 
> > > larger .o than SLOB, even on UP. I'm wondering why that is so -
> SLUB's 
> > > data structures _are_ quite compact and could in theory be used in
> a 
> > > SLOB-alike way. Perhaps one problem is that much of SLUB's
> debugging 
> > > code is always built in?
> > 
> > I think we should probably just accept that it makes sense to have
> more
> > than one allocator. A 64MB single CPU machine is very, very
> different
> > than a 64TB 4096-CPU machine. On one of those, it probably makes
> some
> > sense to burn some memory for maximum scalability.
> 
> I still have trouble to see that SLOB still has much to offer. An
> embedded 
> allocator that in many cases has more allocation overhead than the
> default 
> one?

For the benefit of anyone who didn't read this the last few times I
rehashed this with you:

SLOB:
- internal overhead for kmalloc is 2 bytes (or 3 for odd-sized objects)
- internal overhead for kmem_cache_alloc is 0 bytes (or 1 for odd-sized
objects)
- any unused space down to 2 bytes on any SLOB page can be allocated by
any object that will fit

SLAB/SLUB
- internal overhead for kmalloc averages about 30%
- internal overhead for kmem_cache_alloc is (slab-size % object-size) /
objects-per-slab, which can be quite large for things 

Re: [PATCH 2/3] Rework arch specific Makefiles to use mkubootimg

[Bryan Wu]

On Jan 4, 2008 6:58 AM, Josh Boyer <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Jan 2008 22:41:40 +
> Ben Dooks <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Jan 03, 2008 at 04:04:06PM -0600, Josh Boyer wrote:
> > > Rework the architecture specific Makefiles to use the in-kernel version of
> > > the mkubootimg tool.
> > >
> > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
> >
> > A CC: to RMK and any other arch maintainers being touched by this
> > would have useful too.
>
> D'oh.  I thought I had fixed that in this round.  Bit late now, but
> CC'd.
>

It is OK for Blackfin, Thanks.
But Mike is still discussing with you about the first Patch of this series.

Acked-by: Bryan Wu <[EMAIL PROTECTED]>
--
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/

Re: [PATCH 2/3] Rework arch specific Makefiles to use mkubootimg

[Paul Mundt]

On Thu, Jan 03, 2008 at 04:58:54PM -0600, Josh Boyer wrote:
> On Thu, 3 Jan 2008 22:41:40 +
> Ben Dooks <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, Jan 03, 2008 at 04:04:06PM -0600, Josh Boyer wrote:
> > > Rework the architecture specific Makefiles to use the in-kernel version of
> > > the mkubootimg tool.
> > > 
> > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
> > 
> > A CC: to RMK and any other arch maintainers being touched by this
> > would have useful too.
> 
> D'oh.  I thought I had fixed that in this round.  Bit late now, but
> CC'd.
> 
Looks fine to me.

Acked-by: Paul Mundt <[EMAIL PROTECTED]>
--
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/

Re: forcedeth: MAC-address reversed on resume from suspend

[Björn Steinbrink]

On 2008.01.03 01:42:09 +0200, Adrian Bunk wrote:
> [ original bug report: http://lkml.org/lkml/2008/1/2/253 ]
> 
> On Wed, Jan 02, 2008 at 10:48:43PM +0100, Andreas Mohr wrote:
> > Hi,
> > 
> > On Wed, Jan 02, 2008 at 10:04:49PM +0100, Richard Jonsson wrote:
> > > Bugreport regarding forcedeth driver.
> > >
> > > When returning from suspend-to-RAM the MAC-address byteorder is
> > > reversed.  After another suspend-resume cycle the MAC-address is
> > > again correct. This brings a great deal of pain since the NIC is
> > > assigned a random MAC-address when it is detected as invalid.
> > >
> > > I cannot say if this issue appeared recently or if it's been in
> > > the kernel for a while, as I've been using wireless until
> > > recently.
> > >
> > > I read somewhere on lkml that the mac is read from the device,
> > > then reversed and finally written back to the device. Can it be
> > > that it is read again on resume and reversed, and then again
> > > written to the device? This would explain why it's ok every other
> > > resume cycle.
> > 
> > Uh, Use The Source, Luke?
> > 
> > But no, I think it's simply driver dainbreadness, not a matter of
> > complicated writing and reading back in reversed order.
> > 
> > drivers/net/forcedeth.c has a nice DEV_HAS_CORRECT_MACADDR flag
> > which is being enabled for certain cards (those which need this) and
> > disabled for others.
> > 
> > The nv_probe() function then nicely obeys this flag by reversing the
> > address if needed, _however_ there's another function,
> > nv_copy_mac_to_hw(), which does _NOT_ obey it and simply copies the
> > _raw_ netdev dev_addr to the card register (NvRegMacAddrA etc.).

nv_copy_mac_to_hw() is called from nv_probe() _after_ the MAC address
has been fixed, and from nv_set_mac_address() which is supposed to get a
correct MAC address anyway. So I don't see any problem there.


After some digging, I guess it's related to
5070d3408405ae1941f259acac7a9882045c3be4

That introduced a flag in a register to signal if the MAC address has
been corrected, so that for example kexec won't reverse the adddress
again, when calling nv_probe() again.

As I know neither the suspend nor the kexec code well enough, I'll have
to make a few smart guesses (let's hope that that works out *g*):

a) suspend manages to reverse the MAC address again, so it must call
nv_probe. And we have lost the flag that stops us from reversing the
address. We cannot have lost the fixed MAC address, because then we'd
always get the reversed address, and not go back and forth. I'll assume
that it will also call nv_remove during suspend, because it's nicely
symmetrical then :-)

b) kexec does not call nv_remove, because otherwise, it would see a
reversed address on its nv_probe call anyway, and the flag wouldn't be
necessary.

Now the commit that introduced the flag did also introduce an indirect
change to nv_remove. Although it still says that it writes back the
broken MAC address, that's no longer true, because orig_mac now also
gets the correct address in nv_probe.

Smart guessing time again: That was required because otherwise a "rmood
forcedeth && modprobe forcedeth" would have produced a reversed MAC
address.

But that also causes the problem that we get when we loose either the
flag, we start reversing the fixed address. If we instead return the
card to its initial state in nv_remove, ie. unset the flag and write
back the reversed address, then everyone going through nv_remove _and_
nv_probe should be happy. And kexec, which only goes through nv_probe
again and doesn't loose the flag should be happy, too.

Richard, could you give this a spin? And then we'd likely need someone
to test that with kexec...

thanks,
Björn
---
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index a96583c..f84c752 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -5199,10 +5199,6 @@ static int __devinit nv_probe(struct pci_dev *pci_dev, 
const struct pci_device_i
dev->dev_addr[3] = (np->orig_mac[0] >> 16) & 0xff;
dev->dev_addr[4] = (np->orig_mac[0] >>  8) & 0xff;
dev->dev_addr[5] = (np->orig_mac[0] >>  0) & 0xff;
-   /* set permanent address to be correct aswell */
-   np->orig_mac[0] = (dev->dev_addr[0] << 0) + (dev->dev_addr[1] 
<< 8) +
-   (dev->dev_addr[2] << 16) + (dev->dev_addr[3] << 24);
-   np->orig_mac[1] = (dev->dev_addr[4] << 0) + (dev->dev_addr[5] 
<< 8);
writel(txreg|NVREG_TRANSMITPOLL_MAC_ADDR_REV, base + 
NvRegTransmitPoll);
}
memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
@@ -5414,6 +5410,8 @@ static void __devexit nv_remove(struct pci_dev *pci_dev)
 */
writel(np->orig_mac[0], base + NvRegMacAddrA);
writel(np->orig_mac[1], base + NvRegMacAddrB);
+   writel(readl(base + NvRegTransmitPoll) & 
~NVREG_TRANSMITPOLL_MAC_ADDR_REV,
+  base + NvRegTransmitPoll);
 
/* 

Re: [2.6 patch] mthca: the scheduled MSI support removal

[Roland Dreier]

thanks for keeping on top of the schedule, applied for 2.6.25.
--
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/

[2.6.24-rc minor bugfix] IB/srp: release transport before removing host

[Dave Dillow]

The documented call sequence for removing a host is to call the
transport xxx_remove_host() prior to scsi_remove_host(). The SRP
transport used to crash when that order was followed, but as it is now
fixed, use the documented order.

Signed-off-by: David Dillow <[EMAIL PROTECTED]>
Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---

On Fri, 2008-01-04 at 11:54 +0900, FUJITA Tomonori wrote:
> Linus has already merged your previous patch:
[snip]
> So please resend a patch to move srp_remove_host before
> scsi_remove_host instead of adding srp_remove_host.
[snip]
> > Not sure if your Acked-by was for this one as well, so I left it off.
> 
> Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]>

diff --git a/drivers/infiniband/ulp/srp/ib_srp.c 
b/drivers/infiniband/ulp/srp/ib_srp.c
index 77e8b90..bdb6f85 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -2053,8 +2053,8 @@ static void srp_remove_one(struct ib_device *device)
 
list_for_each_entry_safe(target, tmp_target,
 >target_list, list) {
-   scsi_remove_host(target->scsi_host);
srp_remove_host(target->scsi_host);
+   scsi_remove_host(target->scsi_host);
srp_disconnect_target(target);
ib_destroy_cm_id(target->cm_id);
srp_free_target_ib(target);

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

Re: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree

[Mark Lord]

Venki Pallipadi wrote:

Reintroduce run time configurable max_cstate for !CPU_IDLE case.

Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>

Index: linux-2.6.24-rc/drivers/acpi/processor_idle.c
===
--- linux-2.6.24-rc.orig/drivers/acpi/processor_idle.c
+++ linux-2.6.24-rc/drivers/acpi/processor_idle.c
@@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea
 #define PM_TIMER_TICKS_TO_US(p)(((p) * 
1000)/(PM_TIMER_FREQUENCY/1000))
 
 static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER;

+#ifdef CONFIG_CPU_IDLE
 module_param(max_cstate, uint, );
+#else
+module_param(max_cstate, uint, 0644);
+#endif
 static unsigned int nocst __read_mostly;
 module_param(nocst, uint, );
 

..

I'll try and re-test with this on Friday.

Meanwhile, can you give a short summary of how behaviour differs
between CONFIG_CPU_IDLE and !CONFIG_CPU_IDLE  ??

I'm not at all clear on how this really affects things.

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

Re: [PATCH] aio: partial write should not return error code.

[Rusty Russell]

On Friday 04 January 2008 07:04:30 Zach Brown wrote:
> Rusty Russell wrote:
> > When an AIO write gets an error after writing some data (eg. ENOSPC),
> > it should return the amount written already, not the error.  Just like
> > write() is supposed to.
>
> Andrew, please don't queue this fix.  I think the bug is valid but the
> patch is subtly dangerous.
>
> > diff -r 18802689361a fs/aio.c
> > --- a/fs/aio.c  Thu Jan 03 15:22:24 2008 +1100
> > +++ b/fs/aio.c  Thu Jan 03 18:05:25 2008 +1100
> > @@ -1346,6 +1350,13 @@ static ssize_t aio_rw_vect_retry(struct
> > /* This means we must have transferred all that we could */
> > /* No need to retry anymore */
> > if ((ret == 0) || (iocb->ki_left == 0))
> > +   ret = iocb->ki_nbytes - iocb->ki_left;
> > +
> > +   /* If we managed to write some out we return that, rather than
> > +* the eventual error. */
> > +   if (opcode == IOCB_CMD_PWRITEV
> > +   && ret < 0
> > +   && iocb->ki_nbytes - iocb->ki_left)
> > ret = iocb->ki_nbytes - iocb->ki_left;
>
> This doesn't account for the (sigh) -EIOCB* error codes.  They must be
> returned to the caller so that it can properly handle the iocb reference
> counting.  Failure to do so can lead to oopses.
>
> To be fair, I think you'll have a really hard time finding an
> ->aio_write() implementation which would return partial progress and
> *then* one of the magical errnos.  But the infrastructure does allow it.

Erk, thanks.

> So maybe we could get a helper in aio.h that abstracts out the
>
>   (ret < 0 && ret != -EIOCBQUEUED && ret != -EIOCBRETRY)
>
> condition.  Then I think this patch would be fine.
>
> I assigned a bug to remind myself to revisit this if you aren't excited
> by continuing with the patch:
>
>   http://bugzilla.kernel.org/show_bug.cgi?id=9681

No, that's fine, here is the new one:

When an AIO write gets a non-retry error after writing some data
(eg. ENOSPC), it should return the amount written already, not the
error.  Just like write() is supposed to.

This was found by the libaio test suite.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
 fs/aio.c |7 +++
 1 file changed, 7 insertions(+)

diff -r 18802689361a fs/aio.c
--- a/fs/aio.c  Thu Jan 03 15:22:24 2008 +1100
+++ b/fs/aio.c  Thu Jan 03 18:05:25 2008 +1100
@@ -1346,6 +1350,13 @@ static ssize_t aio_rw_vect_retry(struct 
/* This means we must have transferred all that we could */
/* No need to retry anymore */
if ((ret == 0) || (iocb->ki_left == 0))
+   ret = iocb->ki_nbytes - iocb->ki_left;
+
+   /* If we managed to write some out we return that, rather than
+* the eventual error. */
+   if (opcode == IOCB_CMD_PWRITEV
+   && ret < 0 && ret != -EIOCBQUEUED && ret != -EIOCBRETRY
+   && iocb->ki_nbytes - iocb->ki_left)
ret = iocb->ki_nbytes - iocb->ki_left;
 
return ret;


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

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Robert Hancock]

Linda Walsh wrote:

Robert Hancock wrote:


Looks like the drive reports ERR/ABRT (command aborted), meaning it 
likely doesn't support those commands.



---
   Except the PATA version of the drive does (same capacity, & other 
specs).  Seagate would
disable "advanced" features for SATA but leave them for the older 
technology?  Possible,

but doesn't seem likely.


If this is a Seagate, I believe that they don't have AAM enabled on any 
of their newer drives (something about a lawsuit for patent infringement 
on that feature, or something). Quite likely they don't support that 
power management command, either.

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

Re: [2.6.24-rc BUGFIX] IB/srp: release transport when removing host

[FUJITA Tomonori]

On Thu, 03 Jan 2008 21:39:19 -0500
Dave Dillow <[EMAIL PROTECTED]> wrote:

> When removing the ib_srp module, srp_remove_one() does not release the
> SRP transport class when it is releasing the SCSI host. This leads to
> dangling references to kfree()'d memory, and an eventual oops.
> 
> Signed-off-by: David Dillow <[EMAIL PROTECTED]>

Thanks again!

Linus has already merged your previous patch:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b0e47c8b79154772a436f25bf7646733e1d6194c

So please resend a patch to move srp_remove_host before
scsi_remove_host instead of adding srp_remove_host.


> ---
> On Fri, 2008-01-04 at 09:47 +0900, FUJITA Tomonori wrote:
> > I think that this is the root problem and the patch fixes it in the
> > right way. Please send this patch to [EMAIL PROTECTED] and a
> > patch to move srp_remove_host before scsi_remove_host in
> > srp_remove_one to Roland.
> > 
> > Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> 
> Not sure if your Acked-by was for this one as well, so I left it off.

Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]>

> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c 
> b/drivers/infiniband/ulp/srp/ib_srp.c
> index 950228f..bdb6f85 100644
> --- a/drivers/infiniband/ulp/srp/ib_srp.c
> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> @@ -2053,6 +2053,7 @@ static void srp_remove_one(struct ib_device *device)
>  
>   list_for_each_entry_safe(target, tmp_target,
>>target_list, list) {
> + srp_remove_host(target->scsi_host);
>   scsi_remove_host(target->scsi_host);
>   srp_disconnect_target(target);
>   ib_destroy_cm_id(target->cm_id);
> 
--
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/

Re: [2.6.24-rc BUGFIX] SRP transport: only remove our own entries

[FUJITA Tomonori]

On Thu, 03 Jan 2008 21:34:49 -0500
Dave Dillow <[EMAIL PROTECTED]> wrote:

> The SCSI SRP transport class currently iterates over all children
> devices of the host that is being removed in srp_remove_host(). However,
> not all of those children were created by the SRP transport, and
> removing them will cause corruption and an oops when their creator tries
> to remove them.
> 
> Signed-off-by: David Dillow <[EMAIL PROTECTED]>
> Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> ---

Thanks!

James, please put this patch into scsi-rc-fixes.

> On Fri, 2008-01-04 at 09:47 +0900, FUJITA Tomonori wrote:
> > On Thu, 03 Jan 2008 15:51:25 -0500
> > I think that this is the root problem and the patch fixes it in the
> > right way. Please send this patch to [EMAIL PROTECTED] and a
> > patch to move srp_remove_host before scsi_remove_host in
> > srp_remove_one to Roland.
> > 
> > Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> 
> diff --git a/drivers/scsi/scsi_transport_srp.c 
> b/drivers/scsi/scsi_transport_srp.c
> index 44a340b..65c584d 100644
> --- a/drivers/scsi/scsi_transport_srp.c
> +++ b/drivers/scsi/scsi_transport_srp.c
> @@ -265,7 +265,8 @@ EXPORT_SYMBOL_GPL(srp_rport_del);
>  
>  static int do_srp_rport_del(struct device *dev, void *data)
>  {
> - srp_rport_del(dev_to_rport(dev));
> + if (scsi_is_srp_rport(dev))
> + srp_rport_del(dev_to_rport(dev));
>   return 0;
>  }
>  
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/

Re: sata_nv + ADMA + Samsung disk problem

[Robert Hancock]

Allen Martin wrote:
 

Dunno about the NVidia version.
Theirs works rather differently - the GO bit is there, but there's 
another append register which is used to tell the controller 
that a new 
tag has been added to the CPB list.


The only thing we currently use the GO bit for is to switch 
between ADMA 
and port register mode. Could be there's something we need to 
do there, 
though, who knows..




You shouldn't ever need to touch GO other than the ADMA / legacy mode
switch as you say.

The NVIDIA ADMA hw is not based on the Pacific Digital core.


That answers that question, I guess. Still guessing at why the 
controller would get stuck in IDLE state with no interrupt raised, then..

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

Re: Believed resolved: SATA kern-buffRd read slow: based on promise driver bug

[Robert Hancock]

Linda Walsh wrote:

   I seem to remember reading about some problems with Promise SATA & ACPI.
Does this address that or is that a separate issue?  (Am using no-acpi for
now, but would like to try acpi again if it may be fixed (last time I tried
it with this card, "sdb" went "offline" (once it unmounted itself and
refused to be remounted (no error...just nothing), and another it stayed
mounted, but gave an I/O Error...so have been using no-acpi since).
An ACPI error in bootup said:
ACPI Exception (utmutex-0263): AE_BAD_PARAMETER, Thread EFFC2000 could 
not acquire Mutex [3] [20070126]


Have you tried 2.6.24-rc6? If the problem still occurs there, you should 
post the full bootup log.




   Is the above bug mentioned/discussed in the linux-ide archives?  That
and I'd like to find out why TCQ/NCQ doesn't work with the Seagate 
drives --

my guess, since they say queuedepth of 0/32, is that they are blacklisted
as being drives that don't follow normal protocol or implement their
own proprietary extensions?  Sigh.  Really a lame move (if that's the case)
for Seagate, considering they usage they could likely get in server
configs.  Maybe they want to push their SCSI/SAS drives?


Queue depth 0/32 means the drive supports a queue depth of 32 but the 
controller/driver don't support NCQ.



   BTW, can SATA have DPO or FUA or are those limited to SCSI?
Would it be a desirable future addition to remove the
"doesn't support DPO or FUA" error message" on SATA drives if they are
specific to SCSI?


ATA disks can have FUA support, but the support is disabled in libata by 
default. (There's a fua parameter on libata module to enable it I believe.)

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

Re: [PATCH] procfs: provide slub's /proc/slabinfo

[Andi Kleen]

> I still have trouble to see that SLOB still has much to offer. An embedded 
> allocator that in many cases has more allocation overhead than the default 
> one? Ok you still have advantages if allocations are rounded up to the 
> next power of two for a kmalloc and because of the combining of different 
> types of allocations in a single slab if there are an overall small number 
> of allocations. If one would create a custom slab for the worst problems 
> there then this may also go away.

I suspect it would be a good idea anyways to reevaluate the power of two
slabs. Perhaps a better distribution can be found based on some profiling?
I did profile kmalloc using a systemtap script some time ago but don't
remember the results exactly, but iirc it looked like it could be improved.

A long time ago i also had some code to let the network stack give hints
about its MMUs to slab to create fitting slabs for packets. But that
was never really pushed forward because it turned out it didn't help
much for the most common 1.5K MTU -- always only two packets fit into
a page.

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

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Robert Hancock wrote:


Looks like the drive reports ERR/ABRT (command aborted), meaning it 
likely doesn't support those commands.



---
   Except the PATA version of the drive does (same capacity, & other 
specs).  Seagate would
disable "advanced" features for SATA but leave them for the older 
technology?  Possible,

but doesn't seem likely.


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

Re:Believed resolved: SATA kern-buffRd read slow: based on promise driver bug

[Linda Walsh]

Mikael Pettersson wrote:

Linda Walsh writes:
 > Robert Hancock wrote:
 > > Linda Walsh wrote:
 >  read rate began falling; at 128k block-reads-at-a-time or larger, it 
 >  drops below 20MB/s (only on buffered SATA).
 > 
 > But more importantly -- I notice a chronic error message associate

 > with this drive that may be causing some or all of the problem:
 > ---
 > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
 > ata1.00: port_status 0x2008
 > ata1.00: cmd c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
 >  res 50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
 > ata1: limiting SATA link speed to 1.5 Gbps


Looks like the Promise ASIC SG bug. Apply

and let us know if things improve.

/Mikael
  

---
   Yep!  Hope that's making it into a patch soon or, at least 2.6.24.
   Kernel buffered

   I seem to remember reading about some problems with Promise SATA & ACPI.
Does this address that or is that a separate issue?  (Am using no-acpi for
now, but would like to try acpi again if it may be fixed (last time I tried
it with this card, "sdb" went "offline" (once it unmounted itself and
refused to be remounted (no error...just nothing), and another it stayed
mounted, but gave an I/O Error...so have been using no-acpi since).
An ACPI error in bootup said:
ACPI Exception (utmutex-0263): AE_BAD_PARAMETER, Thread EFFC2000 could 
not acquire Mutex [3] [20070126]


   Is the above bug mentioned/discussed in the linux-ide archives?  That
and I'd like to find out why TCQ/NCQ doesn't work with the Seagate drives --
my guess, since they say queuedepth of 0/32, is that they are blacklisted
as being drives that don't follow normal protocol or implement their
own proprietary extensions?  Sigh.  Really a lame move (if that's the case)
for Seagate, considering they usage they could likely get in server
configs.  Maybe they want to push their SCSI/SAS drives?

   BTW, can SATA have DPO or FUA or are those limited to SCSI?
Would it be a desirable future addition to remove the
"doesn't support DPO or FUA" error message" on SATA drives if they are
specific to SCSI?





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

Re: [PATCHv3] powerpc: DBox2 Board Support

[David Gibson]

On Thu, Jan 03, 2008 at 12:46:23PM +0100, Jochen Friedrich wrote:
> Hi David,
> 
> >> +/ {
> >> +  model = "unknown,dbox2"; // boot wrapper fills in correct manufacturer
> > 
> > Probably better just to leave model out of the dts and let the
> > bootwrapper add it.
> 
> Unfortunately, dtc requires a model:
> 
> $ dtc arch/powerpc/boot/dts/dbox2.dts
> DTC: dts->dts  on file "arch/powerpc/boot/dts/dbox2.dts"
> ERROR: Missing "model" property in /

Ah.  That should be gone in newer dtc versions.  I'm pretty sure I got
rid of all checks that enforced the presence of particular properties,
precisely because they give frequent spurious errors when things are
supposed to be filled in by the bootloader.

[snip]
> >> +  label = "Flash without bootloader";
> >> +  reg = <2 7e>;
> >> +  };
> >> +  [EMAIL PROTECTED] {
> >> +  label = "Complete Flash";
> >> +  reg = <0 80>;
> >> +  read-only;
> >> +  };
> >> +  };
> >> +  };
> 
> MTD handles this correctly. dbox2 uses "Flash without bootloader"
> for flashing image updates and "Complete Flash" for creating a
> backup of everything.  OpenWRT also uses overlapping partitions BTW
> (and also for flashing updates).

Heh.  Wow.  Safely?  i.e. if you access one partition then later an
overlapping partition, is mtd guaranteed to get the necessary
synchronization right?

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
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/

[2.6.24-rc BUGFIX] IB/srp: release transport when removing host

[Dave Dillow]

When removing the ib_srp module, srp_remove_one() does not release the
SRP transport class when it is releasing the SCSI host. This leads to
dangling references to kfree()'d memory, and an eventual oops.

Signed-off-by: David Dillow <[EMAIL PROTECTED]>
---
On Fri, 2008-01-04 at 09:47 +0900, FUJITA Tomonori wrote:
> I think that this is the root problem and the patch fixes it in the
> right way. Please send this patch to [EMAIL PROTECTED] and a
> patch to move srp_remove_host before scsi_remove_host in
> srp_remove_one to Roland.
> 
> Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]>

Not sure if your Acked-by was for this one as well, so I left it off.

diff --git a/drivers/infiniband/ulp/srp/ib_srp.c 
b/drivers/infiniband/ulp/srp/ib_srp.c
index 950228f..bdb6f85 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -2053,6 +2053,7 @@ static void srp_remove_one(struct ib_device *device)
 
list_for_each_entry_safe(target, tmp_target,
 >target_list, list) {
+   srp_remove_host(target->scsi_host);
scsi_remove_host(target->scsi_host);
srp_disconnect_target(target);
ib_destroy_cm_id(target->cm_id);

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

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Robert Hancock]

Linda Walsh wrote:

Robert Hancock wrote:

Linda Walsh wrote:

Alan Cox wrote:
rate began falling; at 128k block-reads-at-a-time or larger, it 
drops below

20MB/s (only on buffered SATA).

Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.

http://linux-ata.org/faq.html#ncq

---
   When drive initializes, dmesg says it has NCQ (depth 0/32)
   Reading the queue_depth under /sys, shows a queuedepth of "1".


Looks like your controller (or at least the Linux driver) doesn't 
actually support NCQ.



2) Drive Advanced Power Management setting("-B") (write-only):
"HDIO_DRIVE_CMD failed: Input/output error"
3) Drive Acoustic ("-M"), read = " acoustic  = not supported",
write = " HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error"


Not sure about these ones.. Does anything show up in dmesg when you do 
this?

---
   Yes:
   (for "-B", power-management)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: port_status 0x2020
ata1.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


  (for "-M" acoustic management):
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: port_status 0x2020
ata1.00: cmd ef/42:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


Looks like the drive reports ERR/ABRT (command aborted), meaning it 
likely doesn't support those commands.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

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

[2.6.24-rc BUGFIX] SRP transport: only remove our own entries

[Dave Dillow]

The SCSI SRP transport class currently iterates over all children
devices of the host that is being removed in srp_remove_host(). However,
not all of those children were created by the SRP transport, and
removing them will cause corruption and an oops when their creator tries
to remove them.

Signed-off-by: David Dillow <[EMAIL PROTECTED]>
Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
On Fri, 2008-01-04 at 09:47 +0900, FUJITA Tomonori wrote:
> On Thu, 03 Jan 2008 15:51:25 -0500
> I think that this is the root problem and the patch fixes it in the
> right way. Please send this patch to [EMAIL PROTECTED] and a
> patch to move srp_remove_host before scsi_remove_host in
> srp_remove_one to Roland.
> 
> Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]>

diff --git a/drivers/scsi/scsi_transport_srp.c 
b/drivers/scsi/scsi_transport_srp.c
index 44a340b..65c584d 100644
--- a/drivers/scsi/scsi_transport_srp.c
+++ b/drivers/scsi/scsi_transport_srp.c
@@ -265,7 +265,8 @@ EXPORT_SYMBOL_GPL(srp_rport_del);
 
 static int do_srp_rport_del(struct device *dev, void *data)
 {
-   srp_rport_del(dev_to_rport(dev));
+   if (scsi_is_srp_rport(dev))
+   srp_rport_del(dev_to_rport(dev));
return 0;
 }
 

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

Re: [PATCH] Exporting capability code/name pairs

[KaiGai Kohei]

James Morris wrote:
> On Wed, 2 Jan 2008, KaiGai Kohei wrote:
> 
>>> Another issue is that securityfs depends on CONFIG_SECURITY, which might be
>>> undesirable, given that capabilities are a standard feature.
>> We can implement this feature on another pseudo filesystems.
>> Do you think what filesystem is the best candidate?
>> I prefer procfs or sysfs instead.
> 
> Sysfs makes more sense, as this information is system-wide and does not 
> relate to specific processes.

The following patch enables to export any capabilities which are supported
on the working kernel, under the /sys/kernel/capability.
You can obtain the code/name pairs of capabilities with scanning this directory.

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
--
 kernel/Makefile   |9 +
 kernel/capability.c   |   36 
 scripts/mkcapnames.sh |   45 +
 3 files changed, 90 insertions(+), 0 deletions(-)

diff --git a/kernel/Makefile b/kernel/Makefile
index dfa9695..29cd3ac 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -80,3 +80,12 @@ quiet_cmd_ikconfiggz = IKCFG   $@
 targets += config_data.h
 $(obj)/config_data.h: $(obj)/config_data.gz FORCE
$(call if_changed,ikconfiggz)
+
+# cap_names.h contains the code/name pair of capabilities.
+# It is generated using include/linux/capability.h automatically.
+$(obj)/capability.o: $(obj)/cap_names.h
+quiet_cmd_cap_names  = CAPS$@
+  cmd_cap_names  = /bin/sh $(src)/../scripts/mkcapnames.sh > $@
+targets += cap_names.h
+$(obj)/cap_names.h: $(src)/../scripts/mkcapnames.sh 
$(src)/../include/linux/capability.h FORCE
+   $(call if_changed,cap_names)
diff --git a/kernel/capability.c b/kernel/capability.c
index efbd9cd..14b4f4b 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -245,3 +245,39 @@ int capable(int cap)
return __capable(current, cap);
 }
 EXPORT_SYMBOL(capable);
+
+/*
+ * Export the list of capabilities on /sys/kernel/capability
+ */
+#define SYSFS_CAPABILITY_ENTRY(_name, _fmt, ...)   \
+   static ssize_t _name##_show(struct kset *kset, char *buffer)\
+   {   \
+   return scnprintf(buffer, PAGE_SIZE, _fmt, __VA_ARGS__); \
+   }   \
+   static struct subsys_attribute _name##_attr = __ATTR_RO(_name)
+
+/*
+ * capability_attrs[] is generated automatically by scripts/mkcapnames.sh
+ * This script parses include/linux/capability.h
+ */
+#include "cap_names.h"
+
+static struct attribute_group capability_attr_group = {
+   .name = "capability",
+   .attrs = capability_attrs,
+};
+
+static int __init capability_export_names(void)
+{
+   int rc;
+
+   rc = sysfs_create_group(_subsys.kobj,
+   _attr_group);
+   if (rc) {
+   printk(KERN_ERR "Unable to export capabilities\n");
+   return rc;
+   }
+
+   return 0;
+}
+__initcall(capability_export_names);
diff --git a/scripts/mkcapnames.sh b/scripts/mkcapnames.sh
index e69de29..c1c8b1f 100644
--- a/scripts/mkcapnames.sh
+++ b/scripts/mkcapnames.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+#
+# generate a cap_names.h file from include/linux/capability.h
+#
+
+BASEDIR=`dirname $0`
+
+echo '#ifndef CAP_NAMES_H'
+echo '#define CAP_NAMES_H'
+echo
+echo '#ifndef SYSFS_CAPABILITY_ENTRY'
+echo '#error cap_names.h should be included from kernel/capability.c'
+echo '#else'
+
+echo 'SYSFS_CAPABILITY_ENTRY(version, "0x%08x\n", _LINUX_CAPABILITY_VERSION);'
+
+cat ${BASEDIR}/../include/linux/capability.h   \
+| egrep '^#define CAP_[A-Z_]+[ ]+[0-9]+$'  \
+| awk 'BEGIN {
+max_code = -1;
+}
+{
+if ($3 > max_code)
+max_code = $3;
+printf("\tSYSFS_CAPABILITY_ENTRY(%s, \"%%u\\n\", %s);\n", 
tolower($2), $2);
+}
+END {
+printf("\tSYSFS_CAPABILITY_ENTRY(index, \"%%u\\n\", %u);\n", 
max_code);
+}'
+
+echo
+echo 'static struct attribute *capability_attrs[] = {'
+echo '_attr.attr,'
+echo '_attr.attr,'
+
+cat ${BASEDIR}/../include/linux/capability.h\
+| egrep '^#define CAP_[A-Z_]+[ ]+[0-9]+$'   \
+| awk '{ printf ("&%s_attr.attr,\n", tolower($2)); }'
+
+echo 'NULL,'
+echo '};'
+
+echo '#endif   /* SYSFS_CAPABILITY_ENTRY */'
+echo '#endif   /* CAP_NAMES_H */'
--
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/

Re: [PATCH] procfs: provide slub's /proc/slabinfo

[Christoph Lameter]

On Thu, 3 Jan 2008, Matt Mackall wrote:

> There are three downsides with the slab-like approach: internal
> fragmentation, under-utilized slabs, and pinning.
> 
> The first is the situation where we ask for a kmalloc of 33 bytes and
> get 64. I think the average kmalloc wastes about 30% trying to fit into
> power-of-two buckets. We can tune our buckets a bit, but I think in
> general trying to back kmalloc with slabs is problematic. SLOB has a
> 2-byte granularity up to the point where it just hands things off to the
> page allocator.

The 2 byte overhead of SLOB becomes a liability when it comes to correctly 
aligning power of two sized object. SLOB has to add two bytes and then 
align the combined object (argh!). SLUB can align these without a 2 byte 
overhead. In some configurations this results in SLUB using even less 
memory than SLOB. See f.e. Pekka's test at 
http://marc.info/?l=linux-kernel=118405559214029=2

> If we tried to add more slabs to fill the gaps, we'd exacerbate the
> second problem: because only one type of object can go on a slab, a lot
> of slabs are half-full. SLUB's automerging of slabs helps some here, but
> is still restricted to objects of the same size.

The advantage of SLOB is to be able to put objects of multiple sizes into 
the same slab page. That advantage goes away once we have more than a few 
objects per slab because SLUB can store object in a denser way than SLOB.
 
> And finally, there's the whole pinning problem: we can have a cache like
> the dcache grow very large and then contract, but still have most of its
> slabs used by pinned dentries. Christoph has some rather hairy patches
> to address this, but SLOB doesn't have much of a problem here - those
> pages are still available to allocate other objects on.

Well if you just have a few dentries then they are likely all pinned. A 
large number of dentries will typically result in reclaimable slabs.
The slab defrag patchset not only deals with the dcache issue but provides 
similar solutions for inode and buffer_heads. Support for other slabs that
defragment can be added by providing two hooks per slab.

 > By comparison, SLOB's big downsides are that it's not O(1) and it has a
> single lock. But it's currently fast enough to keep up with SLUB on
> kernel compiles on my 2G box and Nick had an allocator benchmark where
> scalability didn't fall off until beyond 4 CPUs.

Both SLOB and SLAB suffer from the single lock problem. SLOB does it for 
every item allocated. SLAB does it for every nth item allocated. Given 
a fast allocation from multiple processors both will generate a bouncing 
cacheline. SLUB can take pages from the page allocator pools and allocate 
all objects from it without taking a lock.

> > right now we are far away from it - SLUB has an order of magnitude 
> > larger .o than SLOB, even on UP. I'm wondering why that is so - SLUB's 
> > data structures _are_ quite compact and could in theory be used in a 
> > SLOB-alike way. Perhaps one problem is that much of SLUB's debugging 
> > code is always built in?
> 
> I think we should probably just accept that it makes sense to have more
> than one allocator. A 64MB single CPU machine is very, very different
> than a 64TB 4096-CPU machine. On one of those, it probably makes some
> sense to burn some memory for maximum scalability.

I still have trouble to see that SLOB still has much to offer. An embedded 
allocator that in many cases has more allocation overhead than the default 
one? Ok you still have advantages if allocations are rounded up to the 
next power of two for a kmalloc and because of the combining of different 
types of allocations in a single slab if there are an overall small number 
of allocations. If one would create a custom slab for the worst problems 
there then this may also go away.
--
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/

Re: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree

[Venki Pallipadi]

Reintroduce run time configurable max_cstate for !CPU_IDLE case.

Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>

Index: linux-2.6.24-rc/drivers/acpi/processor_idle.c
===
--- linux-2.6.24-rc.orig/drivers/acpi/processor_idle.c
+++ linux-2.6.24-rc/drivers/acpi/processor_idle.c
@@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea
 #define PM_TIMER_TICKS_TO_US(p)(((p) * 
1000)/(PM_TIMER_FREQUENCY/1000))
 
 static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER;
+#ifdef CONFIG_CPU_IDLE
 module_param(max_cstate, uint, );
+#else
+module_param(max_cstate, uint, 0644);
+#endif
 static unsigned int nocst __read_mostly;
 module_param(nocst, uint, );
 
--
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/

Re: [agp-mm][PATCH 1/4][intel_iommu] explicit export current graphics dmar status

[Zhenyu Wang]

On 2007.12.19 13:26:08 +, Zhenyu Wang wrote:
> 
> [agp-mm] [intel_iommu] explicit export current graphics dmar status
> 
> To make it possbile to tell other modules about curent
> graphics dmar engine status, that could decide if graphics
> driver should remap physical address to dma address.
> 
> Also this one trys to make dmar_disabled really present
> current status of DMAR, which would be used for completely
> express graphics dmar engine is active or not.
> 
> Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]>
> ---
>  drivers/pci/intel-iommu.c |   18 --
>  include/linux/dmar.h  |6 ++
>  2 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
> index e079a52..81a0abc 100644
> --- a/drivers/pci/intel-iommu.c
> +++ b/drivers/pci/intel-iommu.c
> @@ -53,7 +53,7 @@
>  static void domain_remove_dev_info(struct dmar_domain *domain);
>  
>  static int dmar_disabled;
> -static int __initdata dmar_map_gfx = 1;
> +static int dmar_map_gfx = 1;
>  static int dmar_forcedac;
>  
>  #define DUMMY_DEVICE_DOMAIN_INFO ((struct device_domain_info *)(-1))
> @@ -86,6 +86,16 @@ static int __init intel_iommu_setup(char *str)
>  }
>  __setup("intel_iommu=", intel_iommu_setup);
>  
> +int intel_iommu_gfx_remapping(void)
> +{
> +#ifndef CONFIG_DMAR_GFX_WA
> + if (!dmar_disabled && iommu_detected && dmar_map_gfx)
> + return 1;
> +#endif
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(intel_iommu_gfx_remapping);
> +
>  static struct kmem_cache *iommu_domain_cache;
>  static struct kmem_cache *iommu_devinfo_cache;
>  static struct kmem_cache *iommu_iova_cache;
> @@ -2189,8 +2199,12 @@ static void __init iommu_exit_mempool(void)
>  
>  void __init detect_intel_iommu(void)
>  {
> - if (swiotlb || no_iommu || iommu_detected || dmar_disabled)
> + if (dmar_disabled)
> + return;
> + if (swiotlb || no_iommu || iommu_detected) {
> + dmar_disabled = 1;
>   return;
> + }
>   if (early_dmar_detect()) {
>   iommu_detected = 1;
>   }
> diff --git a/include/linux/dmar.h b/include/linux/dmar.h
> index ffb6439..8ae435e 100644
> --- a/include/linux/dmar.h
> +++ b/include/linux/dmar.h
> @@ -47,6 +47,8 @@ extern int intel_iommu_init(void);
>  extern int dmar_table_init(void);
>  extern int early_dmar_detect(void);
>  
> +extern int intel_iommu_gfx_remapping(void);
> +
>  extern struct list_head dmar_drhd_units;
>  extern struct list_head dmar_rmrr_units;
>  
> @@ -81,6 +83,10 @@ static inline int intel_iommu_init(void)
>  {
>   return -ENODEV;
>  }
> +static inline int intel_iommu_gfx_remapping(void)
> +{
> + return 0;
> +}
>  
>  #endif /* !CONFIG_DMAR */
>  #endif /* __DMAR_H__ */
> -- 
> 1.5.3.4
> 

Any comments to this one? Is it ok to push this iommu patch with
agp dma remapping patches to next -mm?

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

Re: [PATCH] Exporting capability code/name pairs

[KaiGai Kohei]

> There is also the issue of compiled code which explicitly raises and
> lowers capabilities around critical code sections (ie., as they were
> intended to be used) is also not well served by this change.
> 
> That is, unless the code was compiled with things like CAP_MAC_ADMIN
> being #define'd then it won't be able to do things like cap_set_flag()
> appropriately.

A new function will be necessary, like:
cap_value_t cap_get_value_by_name(const char *cap_name);

If a program tries to use specific capabilities explicitly, it can
apply pre-defined capability code like CAP_MAC_ADMIN.

However, when we implement a program which can deal with arbitrary
capabilities, it should obtain codes of them dynamically, because
it enables to work itself on the feature kernel.

Thanks,

> Cheers
> 
> Andrew
> 
> KaiGai Kohei wrote:
>> Andrew Morgan wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> KaiGai Kohei wrote:
 Remaining issues:
 - We have to mount securityfs explicitly, or use /etc/fstab.
   It can cause a matter when we want to use this feature on
   very early phase on boot. (like /sbin/init)
>>> I'm not altogether clear how you intend this to work.
>>>
>>> Are you saying that some future version of libcap will require that
>>> securityfs be mounted before it (libcap) will work?
>> Yes, but implementing this feature on securityfs might be not good
>> idea as as James said. If this feature is on procfs or sysfs, it is
>> not necessary to mount securityfs explicitly.
>>
>> Thanks,
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHfD7n+bHCR3gb8jsRAsgcAKDY6qXBR3JV2addHUg5sxyZHJEkDQCfdLOL
> zJlf3T4SQsUNENr3kwR5pr8=
> =v8C5
> -END PGP SIGNATURE-
> 
> 

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

Re: sata_nv + ADMA + Samsung disk problem

[Robert Hancock]

Benjamin Herrenschmidt wrote:

Another thing about the PacDigi core:  one has to be very careful
to avoid sequential accesses to sequential PCI locations when
programming the chip -- it cannot handle merged register writes.

So for any group of sequentially laid out registers, the code has
to ensure it never writes two adjacent registers in sequence..


Ugh ? Write combining isn't permitted on normal registers afaik...

Ben.


Byte merging can be done by the chipset on MMIO writes (merging multiple 
8 or 16-bit writes into a single 32-bit cycle).

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

Re: [patch 2.6.24-rc6-mm 8/9] gpiolib: pca9539 i2c gpio expander support

[David Brownell]

Le 02 Janvier 2008, Jean Delvare a écrit:
> 
> Hi David, hi Eric,
> 
> Le 29/12/2007, "David Brownell" <[EMAIL PROTECTED]> a écrit:
> >From: eric miao <[EMAIL PROTECTED]>
> >
> >This adds a new-style I2C driver with basic support for the sixteen
> >bit PCA9539 GPIO expanders.
> >
> > ... 
> 
> Random comments:
> 
> >+static int pca9539_gpio_get_value(struct gpio_chip *gc, unsigned off)
> >+{
> >+...
> >+
> >+ret = pca9539_read_reg(chip, PCA9539_INPUT, _val);
> >+if (ret < 0) {
> >+/* NOTE:  diagnostic already omitted; that's the
> >+ * best we can do here.
> >+ */
> >+return 0;
> >+}
> 
> I guess that you really mean "emitted" here, not "omitted"?

Yeah, typo.


> More importantly, I don't agree that it's the best we can do here.
> Maybe it was already discussed before and there's a good reason to not
> report errors from "get" functions at the gpio-core level,

Yes there is.  It's by explicit request.  Expecting drivers to cope
with per-bit errors is at best unrealistic.  This was decided well
over a year ago ... nobody wants to see bit-banging code that spends
more time trying to figure out how to recover from "can't happen"
errors than getting real work done.  (None of the SOC-specific GPIO
interfaces being replaced by this generic one returned errors either.)

That said, with things like I2C there actually *could* be errors;
which are impossible with valid parameters to SOC-level GPIOs.
That might argue for gpio_{get,set}_value_cansleep() calls being
able to return fault codes that would be nonsense on the more
widely used gpio_{get,set}_value() alls.

But such a change would be for a different set of patches.  This
set does not change *any* driver programming interface.  At all.


> >+static int __devinit pca9539_probe(struct i2c_client *client)
> >+{
> >+ (...)
> >+if (pdata->setup) {
> >+ret = pdata->setup(client, chip->gpio_chip.base,
> >+chip->gpio_chip.ngpio, pdata->context);
> >+if (ret < 0)
> >+dev_dbg(>dev, "setup failed, %d\n", ret);
> 
> Should be at least dev_warn() and maybe even dev_err().

It's not treated as an error (i.e. abort the probe); warning
is right.

Hmm, I thought both this issue and the previous one had been
fixed already ... oh, it was the pcf857x driver that fixed that.
Never mind.  ;)


> >+}
> >+ (...)
> >+}
> >+
> >+static int pca9539_remove(struct i2c_client *client)
> >+{
> >+ (...)
> >+if (pdata->teardown) {
> >+ret = pdata->teardown(client, chip->gpio_chip.base,
> >+chip->gpio_chip.ngpio, pdata->context);
> >+if (ret < 0)
> >+dev_dbg(>dev, "teardown failed, %d\n", ret);
> 
> Same thing here.

That was supposed to be dev_err() then "return ret" !


> >+}
> >+
> >+ret = gpiochip_remove(>gpio_chip);
> >+if (ret) {
> >+dev_err(>dev, "failed remove gpio_chip\n");
> 
> This error message could certainly be reworded to sound better. Also, for
> consistency you should include the value of "ret" in the message.

Right.  So, pretty much like the appended.  (Which I'll merge into
refreshed version of this patch.)


--- a/drivers/gpio/pca9539.c
+++ b/drivers/gpio/pca9539.c
@@ -118,7 +118,7 @@ static int pca9539_gpio_get_value(struct
 
ret = pca9539_read_reg(chip, PCA9539_INPUT, _val);
if (ret < 0) {
-   /* NOTE:  diagnostic already omitted; that's the
+   /* NOTE:  diagnostic already emitted; that's the
 * best we can do here.
 */
return 0;
@@ -205,7 +205,7 @@ static int __devinit pca9539_probe(struc
ret = pdata->setup(client, chip->gpio_chip.base,
chip->gpio_chip.ngpio, pdata->context);
if (ret < 0)
-   dev_dbg(>dev, "setup failed, %d\n", ret);
+   dev_warn(>dev, "setup failed, %d\n", ret);
}
 
i2c_set_clientdata(client, chip);
@@ -225,13 +225,17 @@ static int pca9539_remove(struct i2c_cli
if (pdata->teardown) {
ret = pdata->teardown(client, chip->gpio_chip.base,
chip->gpio_chip.ngpio, pdata->context);
-   if (ret < 0)
-   dev_dbg(>dev, "teardown failed, %d\n", ret);
+   if (ret < 0) {
+   dev_err(>dev, "%s failed, %d\n",
+   "teardown", ret);
+   return ret;
+   }
}
 
ret = gpiochip_remove(>gpio_chip);
if (ret) {
-   dev_err(>dev, "failed remove gpio_chip\n");
+   dev_err(>dev, "%s failed, %d\n",
+   "gpiochip_remove()", ret);
return ret;
}
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

[PATCH] checkpatch: clear the report buffer after processing a file

[Li Zefan]

When checking multiple files, the report buffer is not cleared
after processing a file, thus the report will be printed again
and again, mixing up with other reports.

Signed-off-by: Li Zefan <[EMAIL PROTECTED]>

---
 scripts/checkpatch.pl |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 579f50f..a88f7a1 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -624,16 +624,15 @@ sub possible {
 
 my $prefix = '';
 
-my @report = ();
 sub report {
my $line = $prefix . $_[0];
 
$line = (split('\n', $line))[0] . "\n" if ($terse);
 
-   push(@report, $line);
+   push(our @report, $line);
 }
 sub report_dump {
-   @report;
+   our @report;
 }
 sub ERROR {
report("ERROR: $_[0]\n");
@@ -670,6 +669,7 @@ sub process {
my $signoff = 0;
my $is_patch = 0;
 
+   our @report = ();
our $cnt_lines = 0;
our $cnt_error = 0;
our $cnt_warn = 0;
-- 
1.5.3.rc7


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

Re: forcedeth: MAC-address reversed on resume from suspend

[Richard Jonsson]

I don't know, this all looks a bit dirty to me, MAC reading/writing
should have been implemented in a more central way, then those people
wouldn't have confused heaven and hell with MAC address fiddling.

And yeah, this certainly looks like a bug that should be fixed ASAP,
unless my short analysis somehow happened to be wrong.
(I could probably fix it, but then the forcedeth people
most likely know better how they would like to see it implemented)

Thank you for your report!

Thank you for looking into this, it's a major pain for me. If I knew how 
to, I would have submitted a patch along with the report, if I had the 
know-how. I'd be happy to help in any way I can.



Now the only thing remaining would be: is there a specific way to
contact forcedeth-related people? I didn't find anything within a short
search.

Andreas Mohr


Well, I did search the maintainers file, and did some googling, but 
didn't find any contact info.


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

Re: [PATCH] pda-power: only register available psu

[Dmitry]

Hi, Anton,

2008/1/4, Anton Vorontsov <[EMAIL PROTECTED]>:
> Hi Dmitry,
>
> On Thu, Jan 03, 2008 at 03:53:19AM +0300, Dmitry Baryshkov wrote:
> > Currently pda-power adds both ac and usb power supply units.
> > This patch fixes it so that psu are added only if they are enabled.
>
> Thanks for the patch, this should be fixed of course. A comment
> though...
>
> > Signed-off-by: Dmitry Baryshkov <[EMAIL PROTECTED]>
> >
> > diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
> > index c058f28..42eac09 100644
> > --- a/drivers/power/pda_power.c
> > +++ b/drivers/power/pda_power.c
> [...]
> >   if (ac_irq) {
> > + ret = power_supply_register(>dev, 
> > _power_supplies[0]);
>
> I don't think we should check for IRQs when determining which one
> of power supplies to register. Better use is_{ac,usb}_online
> callbacks, this will not produce an obstacle to implement polling --
> when irqs aren't mandatory. I'll send my two pending patches to show
> the idea.
>
> For this particular issue, I think something like that should work.
> If it works for you, I'll commit that version, preserving your
> authorship, of course.

Yes, it works. Thank you very much!

-- 
With best wishes
Dmitry
--
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/

Re: [RFC] PCIE ASPM support

[Shaohua Li]

On Thu, 2008-01-03 at 11:33 -0800, Kok, Auke wrote:
> Shaohua Li wrote:
> > PCI Express ASPM defines a protocol for PCI Express components in the D0
> > state to reduce Link power by placing their Links into a low power state
> > and instructing the other end of the Link to do likewise. This
> > capability allows hardware-autonomous, dynamic Link power reduction
> > beyond what is achievable by software-only controlled power management.
> > However, The device should be configured by software appropriately.
> > Enabling ASPM will save power, but will introduce device latency.
> > 
> > This patch adds ASPM support in Linux. It introduces a global policy for
> > ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control
> > it. The interface can be used as a boot option too. Currently we have
> > below setting:
> > -default, BIOS default setting
> > -powersave, highest power saving mode, enable all available ASPM state
> > and clock power management
> > -performance, highest performance, disable ASPM and clock power
> > management
> > By default, the 'default' policy is used currently.
> > 
> > In my test, power difference between powersave mode and performance mode
> > is about 1.3w in a system with 3 PCIE links.
> > 
> > please review, any comments will be appreciated.
> 
> 
> quickly glanced this over since I recently disabled l1 ASPM for the 
> e1000/e1000e
> driven 82573 device which has issues with l1 ASPM. that immediately gives me 
> the
> question: how can I continue to disable 1l aspm by default for this device 
> using
> this infrastructure?
I used to have a per-device interface, but thought the interface might
be hard to use for users. If we really need the per-device interface, I
can re-add it.

> I do like the fact that there is a generic way to re-enable it for the users 
> who
> want to use it. Can this change be done when the device is already active?
Yes, at least in my test.

> Can you
> change this parameter per device/module?
Another way is to provide a helper for driver, and driver disables
specific ASPM states. It sounds better to let driver do the disabling,
as users haven't the knowledge?

Thanks,
Shaohua

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

Re: [RESEND PATCH 10/10] ide-floppy: replace ntoh{s,l} and hton{s,l} calls with the generic byteorder macros

[Bartlomiej Zolnierkiewicz]

On Thursday 03 January 2008, Borislav Petkov wrote:
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>

minor thing:

WARNING: line over 80 characters
#88: FILE: drivers/ide/ide-floppy.c:759:
+   put_unaligned(cpu_to_be16(blocks), (unsigned short *) 
>c[7]);

seems like it can be fixed by removing space between '(unsigned short *)'
and '>c[7]'

otherwise looks good, please move it at the beginning of the patch series

PS I need some sleep so the rest of patches have to wait till tomorrow...
--
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/

Re: [RESEND PATCH 07/10] ide-floppy: remove unnecessary ->handler != NULL check

[Bartlomiej Zolnierkiewicz]

On Thursday 03 January 2008, Borislav Petkov wrote:
> This BUG_ON is unneeded since the ->handler != NULL check is performed in
> ide_set_handler().
> 
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>

looks good, please move it at the beginning of the patch series
--
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/

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Robin Getz]

On Thu 3 Jan 2008 12:04, Richard D pondered:
> Does all USB Host controller hardware have the ability to disable PING?

I think they do. (or at least should)...

http://www.intel.com/technology/usb/download/ehci-r10.pdf
==
4.11 Ping Control (page 88)

USB 2.0 defines an addition to the protocol for high-speed devices called 
Ping. Ping is required for all USB 2.0 High-speed bulk and control endpoints. 
Ping is not allowed for a split-transaction stream. This extension to the 
protocol eliminates the bad side-effects of Naking OUT endpoints. The Status 
field has a Ping State bit, which the host controller uses to determine the 
next actual PID it will use in the next transaction to the endpoint (see 
Table 3-16).

Table 4–12 illustrates the state transition table for the host controller's 
responsibility for maintaining the PING protocol. 

Refer to Chapter 8 in the USB Specification Revision 2.0 for detailed 
description on the Ping protocol.

===

I think the musb is just missing the PING/OUT State table, as described in 
table 4-12.

I think this is controlled in the ehci driver with:

host/ehci.h:#define QTD_STS_PING(1 << 0)/* issue PING? */

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

Re: [RESEND PATCH 04/10] ide-floppy: cleanup debugging macros

[Bartlomiej Zolnierkiewicz]

On Thursday 03 January 2008, Borislav Petkov wrote:
> There should be no functional change resulting from this patch.

the patch is fine but the description is a bit inaccurate:

* some debug_log() calls were not using "ide-floppy: " prefix

* a few used printk levels different than KERN_INFO (KERN_NOTICE
  and KERN_ERR, which is the default one if no level is given)

please fix the description and move the patch at the beggining of
the patch series

> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
> ---
>  drivers/ide/ide-floppy.c |   58 +
>  drivers/ide/ide-floppy.h |3 +-
>  2 files changed, 29 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
> index 4fb6128..196a697 100644
> --- a/drivers/ide/ide-floppy.c
> +++ b/drivers/ide/ide-floppy.c
> @@ -105,7 +105,7 @@ static int idefloppy_do_end_request(ide_drive_t *drive, 
> int uptodate, int nsecs)
>   struct request *rq = HWGROUP(drive)->rq;
>   int error;
>  
> - debug_log(KERN_INFO "Reached idefloppy_end_request\n");
> + debug_log("Reached %s\n", __FUNCTION__);
>  
>   switch (uptodate) {
>   case 0: error = IDEFLOPPY_ERROR_GENERAL; break;
> @@ -257,13 +257,12 @@ static void idefloppy_analyze_error (ide_drive_t *drive,
>   floppy->progress_indication = result->sksv[0] & 0x80 ?
>   (u16)get_unaligned((u16 *)(result->sksv+1)):0x1;
>   if (floppy->failed_pc)
> - debug_log(KERN_INFO "ide-floppy: pc = %x, sense key = %x, "
> - "asc = %x, ascq = %x\n", floppy->failed_pc->c[0],
> - result->sense_key, result->asc, result->ascq);
> + debug_log("pc = %x, sense key = %x, asc = %x, ascq = %x\n",
> + floppy->failed_pc->c[0], result->sense_key,
> + result->asc, result->ascq);
>   else
> - debug_log(KERN_INFO "ide-floppy: sense key = %x, asc = %x, "
> - "ascq = %x\n", result->sense_key,
> - result->asc, result->ascq);
> + debug_log("sense key = %x, asc = %x, ascq = %x\n",
> + result->sense_key, result->asc, result->ascq);
>  }
>  
>  static void idefloppy_request_sense_callback (ide_drive_t *drive)
> @@ -271,7 +270,7 @@ static void idefloppy_request_sense_callback (ide_drive_t 
> *drive)
>   idefloppy_t *floppy = drive->driver_data;
>   u8 *buf = floppy->pc->buffer;
>  
> - debug_log(KERN_INFO "ide-floppy: Reached %s\n", __FUNCTION__);
> + debug_log("Reached %s\n", __FUNCTION__);
>  
>   if (!floppy->pc->error) {
>   idefloppy_analyze_error(drive, (rq_sense_res_t *) buf);
> @@ -291,7 +290,7 @@ static void idefloppy_pc_callback (ide_drive_t *drive)
>  {
>   idefloppy_t *floppy = drive->driver_data;
>  
> - debug_log(KERN_INFO "ide-floppy: Reached %s\n", __FUNCTION__);
> + debug_log("Reached %s\n", __FUNCTION__);
>  
>   idefloppy_do_end_request(drive, floppy->pc->error ? 0 : 1, 0);
>  }
> @@ -351,8 +350,7 @@ static ide_startstop_t idefloppy_pc_intr (ide_drive_t 
> *drive)
>   struct request *rq = pc->rq;
>   unsigned int temp;
>  
> - debug_log(KERN_INFO "ide-floppy: Reached %s interrupt handler\n",
> - __FUNCTION__);
> + debug_log("Reached %s interrupt handler\n", __FUNCTION__);
>  
>   if (test_bit(PC_DMA_IN_PROGRESS, >flags)) {
>   if (HWIF(drive)->ide_dma_end(drive)) {
> @@ -361,23 +359,23 @@ static ide_startstop_t idefloppy_pc_intr (ide_drive_t 
> *drive)
>   pc->actually_transferred = pc->request_transfer;
>   idefloppy_update_buffers(drive, pc);
>   }
> - debug_log(KERN_INFO "ide-floppy: DMA finished\n");
> + debug_log("%s: DMA finished\n", __FUNCTION__);
>   }
>  
>   /* Clear the interrupt */
>   status.all = HWIF(drive)->INB(IDE_STATUS_REG);
>  
>   if (!status.b.drq) {/* No more interrupts */
> - debug_log(KERN_INFO "Packet command completed, %d bytes "
> - "transferred\n", pc->actually_transferred);
> + debug_log("Packet command completed, %d bytes transferred\n",
> + pc->actually_transferred);
> +
>   clear_bit(PC_DMA_IN_PROGRESS, >flags);
>  
>   local_irq_enable_in_hardirq();
>  
>   if (status.b.check || test_bit(PC_DMA_ERROR, >flags)) {
>   /* Error detected */
> - debug_log(KERN_INFO "ide-floppy: %s: I/O error\n",
> - drive->name);
> + debug_log("%s: I/O error\n", drive->name);
>   rq->errors++;
>   if (pc->c[0] == GPCMD_REQUEST_SENSE) {
>   printk(KERN_ERR "ide-floppy: I/O error in "
> @@ -438,9 +436,8 @@ static 

Re: [RESEND PATCH 01/10] move ide-floppy historical changelog to Documentation/ide/ChangeLog.ide-floppy.1996-2002;

[Bartlomiej Zolnierkiewicz]

On Thursday 03 January 2008, Borislav Petkov wrote:
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>

applied with two minor fixes (and sorry for being such a pedant ;):

* Summary line moved to patch description and "ide-floppy: cleanup header"
  used instead.  Please try to keep summary line within 80-columns limit,
  otherwise it makes git-log output etc ugly.

* I don't know why scripts/checkpatch.pl doesn't complain but quilt did:

  Warning: trailing whitespace in lines 44,46,61,62 of 
Documentation/ide/ChangeLog.ide-floppy.1996-2002

  so I fixed it manually.
--
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/

Re: [RESEND PATCH 03/10] ide-floppy: convert to generic packet commands

[Bartlomiej Zolnierkiewicz]

On Thursday 03 January 2008, Borislav Petkov wrote:
> Replace the ide-floppy packet commands opcode defines with the generic ones.
> Add a missing GPCMD_WRITE_12 (opcode 0xaa) to the generic ones in cdrom.h. The
> last one can be found in the current version of INF-8090, p.905.
> 
> CC: Jens Axboe <[EMAIL PROTECTED]>
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>

please move this patch at the beggining of the patch series so it can be
applied immediately (patch #2 needs some more work)

> ---
>  drivers/ide/ide-floppy.c |   26 +-
>  drivers/ide/ide-floppy.h |   21 -

Please also note that patch #2 moved these defines to ide-floppy.h and now
patch #3 removes them so by re-ordering patches you can make patch #2 simpler.

[ This is a general hint for optimizing patches to make them smaller and easier
  to maintain, it also makes reviewer's job easier. ]

[...]

> --- a/include/linux/cdrom.h
> +++ b/include/linux/cdrom.h
> @@ -480,6 +480,7 @@ struct cdrom_generic_command
>  #define GPCMD_TEST_UNIT_READY0x00
>  #define GPCMD_VERIFY_10  0x2f
>  #define GPCMD_WRITE_10   0x2a
> +#define GPCMD_WRITE_12   0xaa/* ide floppy */

0xaa is a generic SCSI opcode so the above comment is not necessary

>  #define GPCMD_WRITE_AND_VERIFY_100x2e
>  /* This is listed as optional in ATAPI 2.6, but is (curiously) 
>   * missing from Mt. Fuji, Table 57.  It _is_ mentioned in Mt. Fuji
--
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/

Re: [RESEND PATCH 0/10] ide-floppy redux p1

[Bartlomiej Zolnierkiewicz]

Hi,

On Thursday 03 January 2008, Borislav Petkov wrote:
> 
> Hi Bart,
> 
> here's the unfinished redux of ide-floppy which i'm REsending now so that we 
> could
> sinchronize trees. The original send got busted in vger's filters due to 
> syntax
> error in the Message-ID tag.
> 
>  Documentation/ide/ChangeLog.ide-floppy.1996-2002 |   64 ++
>  drivers/ide/ide-floppy.c | 1248 
> +++---
>  drivers/ide/ide-floppy.h |  351 ++
>  include/linux/cdrom.h|1 +
>  4 files changed, 819 insertions(+), 845 deletions(-)

I applied patch #1, patches #3, #4, #7 and #10 can be applied immediately
if you move them at the beggining of the patch series.  The rest requires
some more work but they are "almost there" (more comments in replies to
particular patches).

Thanks,
Bart
--
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/

Re: [Bluez-devel] Oops involving RFCOMM and sysfs

[Dave Young]

On Thu, Jan 03, 2008 at 02:16:21PM +0100, Gabor Gombas wrote:
> On Wed, Jan 02, 2008 at 04:16:42PM +0100, Gabor Gombas wrote:
> 
> > So the patch referenced above does not help. But I've found a very easy
> > way to trigger the bug:
> > 
> > - do a "cat /dev/zero > /dev/rfcomm0"
> > - switch the phone off
> > - switch the phone on, and the kernel oopses
> 
> FYI I also remember having oopses with 2.6.22. but I do not
> have those logs anymore. Also I now booted 2.6.20.7 and it did not oops.

Could you try the patch (on 2.6.24-rc6) following and check the debug messages? 

diff -upr linux/net/bluetooth/rfcomm/tty.c linux.new/net/bluetooth/rfcomm/tty.c
--- linux/net/bluetooth/rfcomm/tty.c2008-01-04 08:58:48.0 +0800
+++ linux.new/net/bluetooth/rfcomm/tty.c2008-01-04 09:01:01.0 
+0800
@@ -313,6 +313,7 @@ static void rfcomm_dev_del(struct rfcomm
 {
BT_DBG("dev %p", dev);
 
+   dump_stack();
set_bit(RFCOMM_TTY_RELEASED, >flags);
rfcomm_dev_put(dev);
 }
--
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/

Re: Error returns not handled correctly by sysfs.c:subsys_attr_store()

[Andrew Patterson]

On Thu, 2008-01-03 at 17:17 -0700, Andrew Patterson wrote:
> On Fri, 2008-01-04 at 09:07 +0900, Tejun Heo wrote:
> > Hello,
> > 
> > Andrew Patterson wrote:
> > > It looks like this is a shell issue.  After looking through the sysfs
> > > code, I realized that this problem seems to be driven from user-land.
> > > So I performed some experiments:
> > > 
> > >  1. Wrote a simple program that just used write(2) to write to the
> > > sysfs entry. This works fine.
> > >  2. Used /bin/echo instead of the built-in echo command.  This too
> > > works fine.
> > >  3. Tried several shells.  Zsh and Bash both fail.  Csh works fine.
> > > 
> > > I then ran strace on the following shell-script:
> > > 
> > > #!/bin/bash
> > > 
> > > echo x > allow_restart
> > > echo y > allow_restart
> > > echo z > allow_restart
> > > 
> > > and got:
> > > 
> > > # strace -e trace=write ~/tmp/tester.sh 
> > > write(1, "x\n", 2)  = -1 EINVAL (Invalid argument)
> > > write(1, "x\n", 2)  = -1 EINVAL (Invalid argument)
> > > write(2, "/home/andrew/tmp/tester.sh: line"..., 
> > > 72/home/andrew/tmp/tester.sh: line 4: echo: write error: Invalid argument
> > > ) = 72
> > > write(1, "x\ny\n", 4)   = -1 EINVAL (Invalid argument)
> > > write(1, "x\ny\n", 4)   = -1 EINVAL (Invalid argument)
> > > write(2, "/home/andrew/tmp/tester.sh: line"..., 
> > > 72/home/andrew/tmp/tester.sh: line 5: echo: write error: Invalid argument
> > > ) = 72
> > > write(1, "x\ny\nz\n", 6)= -1 EINVAL (Invalid argument)
> > > write(1, "x\ny\nz\n", 6)= -1 EINVAL (Invalid argument)
> > > write(2, "/home/andrew/tmp/tester.sh: line"..., 
> > > 72/home/andrew/tmp/tester.sh: line 6: echo: write error: Invalid argument
> > > ) = 72
> > > write(1, "x\ny\nz\n", 6x
> > > y
> > > z
> > > )= 6
> > > Process 3800 detached
> > 
> > Eeee That's scary.  Which distro are you using and what does
> > 'bash --version' say?
> 
> IA64 Debian lenny.  
> 
> # bash --version
> GNU bash, version 3.1.17(1)-release (ia64-unknown-linux-gnu)
> 
> # zsh --version 
> zsh 4.3.4 (ia64-unknown-linux-gnu)
> 
> # csh --version
> tcsh 6.14.00 (Astron) 2005-03-25 (ia64-unknown-linux) options
> wide,nls,dl,al,kan,rh,nd,color,filec
> 
> I suppose I should try this an ia32 box again, and perhaps with some
> other distros.  I am not sure what the kernel can do about this, but it
> might be nice to report it to the shell maintainers.

Some further tests:

AMD running Debian lenny with i686 kernel -- fails.  
Bash version = 3.1.17(1)

Intel running Ubuntu/gutsy with i686 kernel -- fails.
Bash version = 3.2.25(1)

Itanium running SLES10 with ia64 kernel -- succeeds.
Bash version = 3.1.17(1)

BTW, I found a way to reproduce this without modifying the kernel.
The /sys/class/scsi_host/*/state sysfs store routine returns EINVAL if
an invalid state is written. So just echo 2 bad values to the the state
sysfs entry while running strace.

Andrew

-- 
Andrew Patterson
Hewlett-Packard Company

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

Re: [ofa-general] Re: list corruption on ib_srp load in v2.6.24-rc5

[FUJITA Tomonori]

On Thu, 03 Jan 2008 15:51:25 -0500
David Dillow <[EMAIL PROTECTED]> wrote:

> 
> On Thu, 2008-01-03 at 15:09 -0500, David Dillow wrote:
> > As for a better fix, I'm not sure.
> 
> Here's a better way than the strncmp. If this meets everyone's approval,
> then I can roll up a proper commit.

Thanks! I really apprecate it.

I think that this is the root problem and the patch fixes it in the
right way. Please send this patch to [EMAIL PROTECTED] and a
patch to move srp_remove_host before scsi_remove_host in
srp_remove_one to Roland.

Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]>

> diff --git a/drivers/scsi/scsi_transport_srp.c 
> b/drivers/scsi/scsi_transport_srp.c
> index 44a340b..65c584d 100644
> --- a/drivers/scsi/scsi_transport_srp.c
> +++ b/drivers/scsi/scsi_transport_srp.c
> @@ -265,7 +265,8 @@ EXPORT_SYMBOL_GPL(srp_rport_del);
>  
>  static int do_srp_rport_del(struct device *dev, void *data)
>  {
> - srp_rport_del(dev_to_rport(dev));
> + if (scsi_is_srp_rport(dev))
> + srp_rport_del(dev_to_rport(dev));
>   return 0;
>  }
>  
> 
--
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/

[PATCH 2/2] pda_power: implement polling

[Anton Vorontsov]

Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---

Untested, just to show the idea.

 drivers/power/pda_power.c |   40 
 include/linux/pda_power.h |1 +
 2 files changed, 41 insertions(+), 0 deletions(-)

diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
index 153e3b1..8e9aec3 100644
--- a/drivers/power/pda_power.c
+++ b/drivers/power/pda_power.c
@@ -32,6 +32,8 @@ static struct pda_power_pdata *pdata;
 static struct resource *ac_irq, *usb_irq;
 static struct timer_list charger_timer;
 static struct timer_list supply_timer;
+static struct timer_list polling_timer;
+static int polling;
 
 enum {
PDA_PSY_OFFLINE = 0,
@@ -166,6 +168,28 @@ static irqreturn_t power_changed_isr(int irq, void 
*power_supply)
return IRQ_HANDLED;
 }
 
+static void polling_timer_func(unsigned long unused)
+{
+   int changed = 0;
+
+   dev_vdbg(dev, "polling...\n");
+
+   update_status();
+
+   if (!ac_irq && new_ac_status != ac_status) {
+   ac_status = PDA_PSY_TO_CHANGE;
+   changed = 1;
+   }
+
+   if (!usb_irq && new_usb_status != usb_status) {
+   usb_status = PDA_PSY_TO_CHANGE;
+   changed = 1;
+   }
+
+   if (changed)
+   psy_changed();
+}
+
 static int pda_power_probe(struct platform_device *pdev)
 {
int ret = 0;
@@ -190,6 +214,9 @@ static int pda_power_probe(struct platform_device *pdev)
if (!pdata->wait_for_charger)
pdata->wait_for_charger = 500;
 
+   if (!pdata->polling_interval)
+   pdata->polling_interval = 2000;
+
setup_timer(_timer, charger_timer_func, 0);
setup_timer(_timer, supply_timer_func, 0);
 
@@ -219,6 +246,8 @@ static int pda_power_probe(struct platform_device *pdev)
dev_err(dev, "request ac irq failed\n");
goto ac_irq_failed;
}
+   } else {
+   polling = 1;
}
}
 
@@ -238,9 +267,18 @@ static int pda_power_probe(struct platform_device *pdev)
dev_err(dev, "request usb irq failed\n");
goto usb_irq_failed;
}
+   } else {
+   polling = 1;
}
}
 
+   if (polling) {
+   dev_dbg(dev, "will poll for status\n");
+   setup_timer(_timer, polling_timer_func, 0);
+   mod_timer(_timer,
+ jiffies + msecs_to_jiffies(pdata->polling_interval));
+   }
+
return 0;
 
 usb_irq_failed:
@@ -264,6 +302,8 @@ static int pda_power_remove(struct platform_device *pdev)
if (pdata->is_ac_online && ac_irq)
free_irq(ac_irq->start, _psy_ac);
 
+   if (polling)
+   del_timer_sync(_timer);
del_timer_sync(_timer);
del_timer_sync(_timer);
 
diff --git a/include/linux/pda_power.h b/include/linux/pda_power.h
index 1375f15..225beb1 100644
--- a/include/linux/pda_power.h
+++ b/include/linux/pda_power.h
@@ -26,6 +26,7 @@ struct pda_power_pdata {
 
unsigned int wait_for_status; /* msecs, default is 500 */
unsigned int wait_for_charger; /* msecs, default is 500 */
+   unsigned int polling_interval; /* msecs, default is 2000 */
 };
 
 #endif /* __PDA_POWER_H__ */
-- 
1.5.2.4
--
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/

[PATCH 1/2] pda_power: various cleanups

[Anton Vorontsov]

- handle spurious interrupts correctly;
- get rid of pda_power_supplies array, use two variables instead;
- factor out psy_changed() function, it will be used for polling.

Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---

Untested, just to show the idea.

 drivers/power/pda_power.c |  152 -
 1 files changed, 94 insertions(+), 58 deletions(-)

diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
index d98622f..153e3b1 100644
--- a/drivers/power/pda_power.c
+++ b/drivers/power/pda_power.c
@@ -33,6 +33,16 @@ static struct resource *ac_irq, *usb_irq;
 static struct timer_list charger_timer;
 static struct timer_list supply_timer;
 
+enum {
+   PDA_PSY_OFFLINE = 0,
+   PDA_PSY_ONLINE = 1,
+   PDA_PSY_TO_CHANGE,
+};
+static int new_ac_status = -1;
+static int new_usb_status = -1;
+static int ac_status = -1;
+static int usb_status = -1;
+
 static int pda_power_get_property(struct power_supply *psy,
  enum power_supply_property psp,
  union power_supply_propval *val)
@@ -61,36 +71,43 @@ static char *pda_power_supplied_to[] = {
"backup-battery",
 };
 
-static struct power_supply pda_power_supplies[] = {
-   {
-   .name = "ac",
-   .type = POWER_SUPPLY_TYPE_MAINS,
-   .supplied_to = pda_power_supplied_to,
-   .num_supplicants = ARRAY_SIZE(pda_power_supplied_to),
-   .properties = pda_power_props,
-   .num_properties = ARRAY_SIZE(pda_power_props),
-   .get_property = pda_power_get_property,
-   },
-   {
-   .name = "usb",
-   .type = POWER_SUPPLY_TYPE_USB,
-   .supplied_to = pda_power_supplied_to,
-   .num_supplicants = ARRAY_SIZE(pda_power_supplied_to),
-   .properties = pda_power_props,
-   .num_properties = ARRAY_SIZE(pda_power_props),
-   .get_property = pda_power_get_property,
-   },
+static struct power_supply pda_psy_ac = {
+   .name = "ac",
+   .type = POWER_SUPPLY_TYPE_MAINS,
+   .supplied_to = pda_power_supplied_to,
+   .num_supplicants = ARRAY_SIZE(pda_power_supplied_to),
+   .properties = pda_power_props,
+   .num_properties = ARRAY_SIZE(pda_power_props),
 };
 
+static struct power_supply pda_psy_usb = {
+   .name = "usb",
+   .type = POWER_SUPPLY_TYPE_USB,
+   .supplied_to = pda_power_supplied_to,
+   .num_supplicants = ARRAY_SIZE(pda_power_supplied_to),
+   .properties = pda_power_props,
+   .num_properties = ARRAY_SIZE(pda_power_props),
+   .get_property = pda_power_get_property,
+};
+
+static void update_status(void)
+{
+   if (pdata->is_ac_online)
+   new_ac_status = !!pdata->is_ac_online();
+
+   if (pdata->is_usb_online)
+   new_usb_status = !!pdata->is_usb_online();
+}
+
 static void update_charger(void)
 {
if (!pdata->set_charge)
return;
 
-   if (pdata->is_ac_online && pdata->is_ac_online()) {
+   if (new_ac_status > 0) {
dev_dbg(dev, "charger on (AC)\n");
pdata->set_charge(PDA_POWER_CHARGE_AC);
-   } else if (pdata->is_usb_online && pdata->is_usb_online()) {
+   } else if (new_usb_status > 0) {
dev_dbg(dev, "charger on (USB)\n");
pdata->set_charge(PDA_POWER_CHARGE_USB);
} else {
@@ -99,31 +116,53 @@ static void update_charger(void)
}
 }
 
-static void supply_timer_func(unsigned long power_supply_ptr)
+static void psy_changed(void)
 {
-   void *power_supply = (void *)power_supply_ptr;
+   update_charger();
 
-   power_supply_changed(power_supply);
+   /*
+* Okay, charger set. Now wait a bit before notifying supplicants,
+* charge power should stabilize.
+*/
+   mod_timer(_timer,
+ jiffies + msecs_to_jiffies(pdata->wait_for_charger));
 }
 
-static void charger_timer_func(unsigned long power_supply_ptr)
+static void supply_timer_func(unsigned long unused)
 {
-   update_charger();
+   if (ac_status == PDA_PSY_TO_CHANGE) {
+   ac_status = new_ac_status;
+   power_supply_changed(_psy_ac);
+   }
 
-   /* Okay, charger set. Now wait a bit before notifying supplicants,
-* charge power should stabilize. */
-   supply_timer.data = power_supply_ptr;
-   mod_timer(_timer,
- jiffies + msecs_to_jiffies(pdata->wait_for_charger));
+   if (usb_status == PDA_PSY_TO_CHANGE) {
+   usb_status = new_usb_status;
+   power_supply_changed(_psy_usb);
+   }
+}
+
+static void charger_timer_func(unsigned long unused)
+{
+   update_status();
+   psy_changed();
 }
 
 static irqreturn_t power_changed_isr(int irq, void *power_supply)
 {
-   /* Wait a bit before reading ac/usb line status and setting charger,
-* because 

RE: sata_nv + ADMA + Samsung disk problem

[Allen Martin]

 
> > Dunno about the NVidia version.
> 
> Theirs works rather differently - the GO bit is there, but there's 
> another append register which is used to tell the controller 
> that a new 
> tag has been added to the CPB list.
> 
> The only thing we currently use the GO bit for is to switch 
> between ADMA 
> and port register mode. Could be there's something we need to 
> do there, 
> though, who knows..
> 

You shouldn't ever need to touch GO other than the ADMA / legacy mode
switch as you say.

The NVIDIA ADMA hw is not based on the Pacific Digital core.
---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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/

Re: [PATCH] md: Fix data corruption when a degraded raid5 array is reshaped.

[Neil Brown]

On Thursday January 3, [EMAIL PROTECTED] wrote:
> 
> On closer look the safer test is:
> 
>   !test_bit(STRIPE_OP_COMPUTE_BLK, >ops.pending).
> 
> The 'req_compute' field only indicates that a 'compute_block' operation
> was requested during this pass through handle_stripe so that we can
> issue a linked chain of asynchronous operations.
> 
> ---
> 
> From: Neil Brown <[EMAIL PROTECTED]>

Technically that should probably be
  From: Dan Williams <[EMAIL PROTECTED]>

now, and then I add
  Acked-by: NeilBrown <[EMAIL PROTECTED]>

because I completely agree with your improvement.

We should keep an eye out for then Andrew commits this and make sure
the right patch goes in...

Thanks,
NeilBrown

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

Re: [PATCH] pda-power: only register available psu

[Anton Vorontsov]

Hi Dmitry,

On Thu, Jan 03, 2008 at 03:53:19AM +0300, Dmitry Baryshkov wrote:
> Currently pda-power adds both ac and usb power supply units.
> This patch fixes it so that psu are added only if they are enabled.

Thanks for the patch, this should be fixed of course. A comment
though...

> Signed-off-by: Dmitry Baryshkov <[EMAIL PROTECTED]>
> 
> diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
> index c058f28..42eac09 100644
> --- a/drivers/power/pda_power.c
> +++ b/drivers/power/pda_power.c
[...]
>   if (ac_irq) {
> + ret = power_supply_register(>dev, _power_supplies[0]);

I don't think we should check for IRQs when determining which one
of power supplies to register. Better use is_{ac,usb}_online
callbacks, this will not produce an obstacle to implement polling --
when irqs aren't mandatory. I'll send my two pending patches to show
the idea.

For this particular issue, I think something like that should work.
If it works for you, I'll commit that version, preserving your
authorship, of course.

--- 

diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
index c058f28..d98622f 100644
--- a/drivers/power/pda_power.c
+++ b/drivers/power/pda_power.c
@@ -168,66 +168,74 @@ static int pda_power_probe(struct platform_device *pdev)
pda_power_supplies[1].num_supplicants = pdata->num_supplicants;
}
 
-   ret = power_supply_register(>dev, _power_supplies[0]);
-   if (ret) {
-   dev_err(dev, "failed to register %s power supply\n",
-   pda_power_supplies[0].name);
-   goto supply0_failed;
-   }
+   if (pdata->is_ac_online) {
+   ret = power_supply_register(>dev, _power_supplies[0]);
+   if (ret) {
+   dev_err(dev, "failed to register %s power supply\n",
+   pda_power_supplies[0].name);
+   goto ac_supply_failed;
+   }
 
-   ret = power_supply_register(>dev, _power_supplies[1]);
-   if (ret) {
-   dev_err(dev, "failed to register %s power supply\n",
-   pda_power_supplies[1].name);
-   goto supply1_failed;
+   if (ac_irq) {
+   ret = request_irq(ac_irq->start, power_changed_isr,
+ get_irq_flags(ac_irq), ac_irq->name,
+ _power_supplies[0]);
+   if (ret) {
+   dev_err(dev, "request ac irq failed\n");
+   goto ac_irq_failed;
+   }
+   }
}
 
-   if (ac_irq) {
-   ret = request_irq(ac_irq->start, power_changed_isr,
- get_irq_flags(ac_irq), ac_irq->name,
- _power_supplies[0]);
+   if (pdata->is_usb_online) {
+   ret = power_supply_register(>dev, _power_supplies[1]);
if (ret) {
-   dev_err(dev, "request ac irq failed\n");
-   goto ac_irq_failed;
+   dev_err(dev, "failed to register %s power supply\n",
+   pda_power_supplies[1].name);
+   goto usb_supply_failed;
}
-   }
 
-   if (usb_irq) {
-   ret = request_irq(usb_irq->start, power_changed_isr,
- get_irq_flags(usb_irq), usb_irq->name,
- _power_supplies[1]);
-   if (ret) {
-   dev_err(dev, "request usb irq failed\n");
-   goto usb_irq_failed;
+   if (usb_irq) {
+   ret = request_irq(usb_irq->start, power_changed_isr,
+ get_irq_flags(usb_irq),
+ usb_irq->name,
+ _power_supplies[1]);
+   if (ret) {
+   dev_err(dev, "request usb irq failed\n");
+   goto usb_irq_failed;
+   }
}
}
 
-   goto success;
+   return 0;
 
 usb_irq_failed:
-   if (ac_irq)
+   if (pdata->is_usb_online)
+   power_supply_unregister(_power_supplies[1]);
+usb_supply_failed:
+   if (pdata->is_ac_online && ac_irq)
free_irq(ac_irq->start, _power_supplies[0]);
 ac_irq_failed:
-   power_supply_unregister(_power_supplies[1]);
-supply1_failed:
-   power_supply_unregister(_power_supplies[0]);
-supply0_failed:
+   if (pdata->is_ac_online)
+   power_supply_unregister(_power_supplies[0]);
+ac_supply_failed:
 noirqs:
 wrongid:
-success:
return ret;
 }
 
 static int pda_power_remove(struct platform_device *pdev)
 {
-   if (usb_irq)
+   if (pdata->is_usb_online && usb_irq)

Re: Error returns not handled correctly by sysfs.c:subsys_attr_store()

[Andrew Patterson]

On Fri, 2008-01-04 at 09:07 +0900, Tejun Heo wrote:
> Hello,
> 
> Andrew Patterson wrote:
> > It looks like this is a shell issue.  After looking through the sysfs
> > code, I realized that this problem seems to be driven from user-land.
> > So I performed some experiments:
> > 
> >  1. Wrote a simple program that just used write(2) to write to the
> > sysfs entry. This works fine.
> >  2. Used /bin/echo instead of the built-in echo command.  This too
> > works fine.
> >  3. Tried several shells.  Zsh and Bash both fail.  Csh works fine.
> > 
> > I then ran strace on the following shell-script:
> > 
> > #!/bin/bash
> > 
> > echo x > allow_restart
> > echo y > allow_restart
> > echo z > allow_restart
> > 
> > and got:
> > 
> > # strace -e trace=write ~/tmp/tester.sh 
> > write(1, "x\n", 2)  = -1 EINVAL (Invalid argument)
> > write(1, "x\n", 2)  = -1 EINVAL (Invalid argument)
> > write(2, "/home/andrew/tmp/tester.sh: line"..., 
> > 72/home/andrew/tmp/tester.sh: line 4: echo: write error: Invalid argument
> > ) = 72
> > write(1, "x\ny\n", 4)   = -1 EINVAL (Invalid argument)
> > write(1, "x\ny\n", 4)   = -1 EINVAL (Invalid argument)
> > write(2, "/home/andrew/tmp/tester.sh: line"..., 
> > 72/home/andrew/tmp/tester.sh: line 5: echo: write error: Invalid argument
> > ) = 72
> > write(1, "x\ny\nz\n", 6)= -1 EINVAL (Invalid argument)
> > write(1, "x\ny\nz\n", 6)= -1 EINVAL (Invalid argument)
> > write(2, "/home/andrew/tmp/tester.sh: line"..., 
> > 72/home/andrew/tmp/tester.sh: line 6: echo: write error: Invalid argument
> > ) = 72
> > write(1, "x\ny\nz\n", 6x
> > y
> > z
> > )= 6
> > Process 3800 detached
> 
> Eeee That's scary.  Which distro are you using and what does
> 'bash --version' say?

IA64 Debian lenny.  

# bash --version
GNU bash, version 3.1.17(1)-release (ia64-unknown-linux-gnu)

# zsh --version 
zsh 4.3.4 (ia64-unknown-linux-gnu)

# csh --version
tcsh 6.14.00 (Astron) 2005-03-25 (ia64-unknown-linux) options
wide,nls,dl,al,kan,rh,nd,color,filec

I suppose I should try this an ia32 box again, and perhaps with some
other distros.  I am not sure what the kernel can do about this, but it
might be nice to report it to the shell maintainers.

-- 
Andrew Patterson
Hewlett-Packard Company

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

[PATCH] printk: Coding style fixes

[Paolo Ciarrocchi]

This patch to printk.c fixes a few errors reported by checkpatch.pl

Before:
total: 18 errors, 17 warnings, 1306 lines checked

After:
total: 1 errors, 17 warnings, 1305 lines checked

This new version includes a fix suggested by Jesper Juhl

Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
---

Adrian, I'm sending this patch to you because according to git shortlog -e
you are the most active modifier of this file.


 kernel/printk.c |   25 -
 1 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/kernel/printk.c b/kernel/printk.c
index 89011bf..8d131c6 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -100,8 +100,7 @@ static unsigned long log_end;   /* Index into log_buf: 
most-recently-written-char
 /*
  * Array of consoles built from command line options (console=)
  */
-struct console_cmdline
-{
+struct console_cmdline {
charname[8];/* Name of the driver   */
int index;  /* Minor dev. to use*/
char*options;   /* Options for the driver   */
@@ -323,7 +322,7 @@ int do_syslog(int type, char __user *buf, int len)
c = LOG_BUF(log_start);
log_start++;
spin_unlock_irq(_lock);
-   error = __put_user(c,buf);
+   error = __put_user(c, buf);
buf++;
i++;
cond_resched();
@@ -368,7 +367,7 @@ int do_syslog(int type, char __user *buf, int len)
break;
c = LOG_BUF(j);
spin_unlock_irq(_lock);
-   error = __put_user(c,[count-1-i]);
+   error = __put_user(c, [count-1-i]);
cond_resched();
spin_lock_irq(_lock);
}
@@ -380,8 +379,8 @@ int do_syslog(int type, char __user *buf, int len)
int offset = count-error;
/* buffer overflow during copy, correct user buffer. */
for (i = 0; i < error; i++) {
-   if (__get_user(c,[i+offset]) ||
-   __put_user(c,[i])) {
+   if (__get_user(c, [i+offset]) ||
+   __put_user(c, [i])) {
error = -EFAULT;
break;
}
@@ -556,7 +555,7 @@ static void zap_locks(void)
 #if defined(CONFIG_PRINTK_TIME)
 static int printk_time = 1;
 #else
-static int printk_time = 0;
+static int printk_time ;
 #endif
 module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
 
@@ -659,7 +658,7 @@ asmlinkage int vprintk(const char *fmt, va_list args)
 */
for (p = printk_buf; *p; p++) {
if (log_level_unknown) {
-/* log_level_unknown signals the start of a new line */
+   /* log_level_unknown signals the start of a new line */
if (printk_time) {
int loglev_char;
char tbuf[50], *tp;
@@ -671,7 +670,7 @@ asmlinkage int vprintk(const char *fmt, va_list args)
 * force the log level token to be
 * before the time output.
 */
-   if (p[0] == '<' && p[1] >='0' &&
+   if (p[0] == '<' && p[1] >= '0' &&
   p[1] <= '7' && p[2] == '>') {
loglev_char = p[1];
p += 3;
@@ -1176,16 +1175,16 @@ EXPORT_SYMBOL(register_console);
 
 int unregister_console(struct console *console)
 {
-struct console *a, *b;
+   struct console *a, *b;
int res = 1;
 
acquire_console_sem();
if (console_drivers == console) {
-   console_drivers=console->next;
+   console_drivers = console->next;
res = 0;
} else if (console_drivers) {
-   for (a=console_drivers->next, b=console_drivers ;
-a; b=a, a=b->next) {
+   for (a = console_drivers->next, b = console_drivers;
+a; b = a, a = b->next) {
if (a == console) {
b->next = a->next;
res = 0;
-- 
1.5.4.rc2.17.g257f

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

Re: INITIO scsi driver fails to work properly

[Filippos Papadopoulos]

First of all let me wish a happy new year.
I come back from the vacations and i compiled the initio driver with

#define DEBUG_INTERRUPT 1
#define DEBUG_QUEUE 1
#define DEBUG_STATE 1
#define INT_DISC1

I used the sources from 2.6.24-rc6-git9 kernel. At kernel boot time the initio
driver prints the following:

" scsi: Initio INI-9X00U/UW SCSI device driver
Find scb at c0c0
Append pend scb c0c0;"

After 3 seconds the whole system freezes there and i have to reboot.



P.S  here is the info from 'lspci -vv' running 2.6.16.13 kernel:

"00:08.0 SCSI storage controller: Initio Corporation 360P (rev 02)
Subsystem: Unknown device 9292:0202
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- SERR- http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86: reboot_{32|64}.c unification

[Miguel Botón]

reboot_{32|64}.c unification patch.

This patch unifies the code from the reboot_32.c and reboot_64.c files.

It has been tested in computers with X86_32 and X86_64 kernels and it
looks like all reboot modes work fine (EFI restart system hasn't been
tested yet).

Probably I made some mistakes (like I usually do) so I hope
we can identify and fix them soon.

Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 0903bbf..0cd4085 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -30,8 +30,8 @@ obj-y += step.o
 obj-$(CONFIG_STACKTRACE)   += stacktrace.o
 obj-y  += cpu/
 obj-y  += acpi/
-obj-$(CONFIG_X86_BIOS_REBOOT)  += reboot_32.o
-obj-$(CONFIG_X86_64)+= reboot_64.o
+obj-$(CONFIG_X86_BIOS_REBOOT)  += reboot.o
+obj-$(CONFIG_X86_64)   += reboot.o
 obj-$(CONFIG_MCA)  += mca_32.o
 obj-$(CONFIG_X86_MSR)  += msr.o
 obj-$(CONFIG_X86_CPUID)+= cpuid.o
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
new file mode 100644
index 000..bf9b106
--- /dev/null
+++ b/arch/x86/kernel/reboot.c
@@ -0,0 +1,441 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_X86_32
+# include 
+# include 
+# include 
+# include 
+#else
+# include 
+#endif
+
+/*
+ * Power off function, if any
+ */
+void (*pm_power_off)(void);
+EXPORT_SYMBOL(pm_power_off);
+
+static long no_idt[3];
+static int reboot_mode;
+enum reboot_type reboot_type = BOOT_KBD;
+int reboot_force;
+
+#if defined(CONFIG_X86_32) && defined(CONFIG_SMP)
+static int reboot_cpu = -1;
+#endif
+
+/* reboot=b[ios] | s[mp] | t[riple] | k[bd] | e[fi] [, [w]arm | [c]old]
+   warm   Don't set the cold reboot flag
+   cold   Set the cold reboot flag
+   bios   Reboot by jumping through the BIOS (only for X86_32)
+   smpReboot by executing reset on BSP or other CPU (only for X86_32)
+   triple Force a triple fault (init)
+   kbdUse the keyboard controller. cold reset (default)
+   acpi   Use the RESET_REG in the FADT
+   efiUse efi reset_system runtime service
+   force  Avoid anything that could hang.
+ */
+static int __init reboot_setup(char *str)
+{
+   for (;;) {
+   switch (*str) {
+   case 'w':
+   reboot_mode = 0x1234;
+   break;
+
+   case 'c':
+   reboot_mode = 0;
+   break;
+
+#ifdef CONFIG_X86_32
+#ifdef CONFIG_SMP
+   case 's':
+   if (isdigit(*(str+1))) {
+   reboot_cpu = (int) (*(str+1) - '0');
+   if (isdigit(*(str+2)))
+   reboot_cpu = reboot_cpu*10 + 
(int)(*(str+2) - '0');
+   }
+   /* we will leave sorting out the final value
+  when we are ready to reboot, since we might 
not
+  have set up boot_cpu_id or smp_num_cpu */
+   break;
+#endif /* CONFIG_SMP */
+
+   case 'b':
+#endif
+   case 'a':
+   case 'k':
+   case 't':
+   case 'e':
+   reboot_type = *str;
+   break;
+
+   case 'f':
+   reboot_force = 1;
+   break;
+   }
+
+   str = strchr(str, ',');
+   if (str)
+   str++;
+   else
+   break;
+   }
+   return 1;
+}
+
+__setup("reboot=", reboot_setup);
+
+
+#ifdef CONFIG_X86_32
+/*
+ * Reboot options and system auto-detection code provided by
+ * Dell Inc. so their systems "just work". :-)
+ */
+
+/*
+ * Some machines require the "reboot=b"  commandline option,
+ * this quirk makes that automatic.
+ */
+static int __init set_bios_reboot(const struct dmi_system_id *d)
+{
+   if (reboot_type != BOOT_BIOS) {
+   reboot_type = BOOT_BIOS;
+   printk(KERN_INFO "%s series board detected. Selecting 
BIOS-method for reboots.\n", d->ident);
+   }
+   return 0;
+}
+
+static struct dmi_system_id __initdata reboot_dmi_table[] = {
+   {   /* Handle problems with rebooting on Dell E520's */
+   .callback = set_bios_reboot,
+   .ident = "Dell E520",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Dell DM061"),
+   },
+   },
+   {   /* Handle problems with rebooting on Dell 1300's */
+   .callback = set_bios_reboot,
+   .ident = "Dell PowerEdge 1300",
+   .matches = {
+   

Re: kernel BUG at fs/buffer.c:1245!

[Parag Warudkar]

  nokia.com> writes:

> 
> 
> Hi
> 
> I am running 2.6.23 kernel on i386. Sometimes during reboot or file read
> write
> I get this kernel crash. .config attached. 
> 
> kernel BUG at fs/buffer.c:1245!
> invalid opcode:  [#1]
> SMP
> Modules linked in: sfpacket(PF) e1000 adm1026 hwmon_vid noksf pld_drv
> CPU:2
> EIP:0060:[]Tainted: PF   VLI
   ^^^   
Is this OOPS reproducible with a non-tainted kernel (Do not force load any
proprietary modules and try to reproduce it - if you do, please post a bug
report over at http://bugzilla.kernel.org.)

Thanks  

Parag

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

Re: Error returns not handled correctly by sysfs.c:subsys_attr_store()

[Tejun Heo]

Hello,

Andrew Patterson wrote:
> It looks like this is a shell issue.  After looking through the sysfs
> code, I realized that this problem seems to be driven from user-land.
> So I performed some experiments:
> 
>  1. Wrote a simple program that just used write(2) to write to the
> sysfs entry. This works fine.
>  2. Used /bin/echo instead of the built-in echo command.  This too
> works fine.
>  3. Tried several shells.  Zsh and Bash both fail.  Csh works fine.
> 
> I then ran strace on the following shell-script:
> 
> #!/bin/bash
> 
> echo x > allow_restart
> echo y > allow_restart
> echo z > allow_restart
> 
> and got:
> 
> # strace -e trace=write ~/tmp/tester.sh 
> write(1, "x\n", 2)  = -1 EINVAL (Invalid argument)
> write(1, "x\n", 2)  = -1 EINVAL (Invalid argument)
> write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: 
> line 4: echo: write error: Invalid argument
> ) = 72
> write(1, "x\ny\n", 4)   = -1 EINVAL (Invalid argument)
> write(1, "x\ny\n", 4)   = -1 EINVAL (Invalid argument)
> write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: 
> line 5: echo: write error: Invalid argument
> ) = 72
> write(1, "x\ny\nz\n", 6)= -1 EINVAL (Invalid argument)
> write(1, "x\ny\nz\n", 6)= -1 EINVAL (Invalid argument)
> write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: 
> line 6: echo: write error: Invalid argument
> ) = 72
> write(1, "x\ny\nz\n", 6x
> y
> z
> )= 6
> Process 3800 detached

Eeee That's scary.  Which distro are you using and what does
'bash --version' say?

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

Re: [PATCH] proc: advertise new restrictions on /proc/*/maps & /proc/*/smaps

[Al Viro]

On Fri, Jan 04, 2008 at 12:51:50AM +0100, Guillaume Chazarain wrote:
> Now that strangers are kept out of /proc//maps, let's welcome them
> with -EPERM instead of a blank file.

NAK

The whole point is that we have to reject it at read() time, not open()
time.  Checks in open() are
a) useless (since conditions can change later)
and
b) actually broken, since CAP_SYS_PTRACE != CAP_DAC_OVERRIDE
--
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/

[PATCH] proc: advertise new restrictions on /proc/*/maps & /proc/*/smaps

[Guillaume Chazarain]

Now that strangers are kept out of /proc//maps, let's welcome them
with -EPERM instead of a blank file.

Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---

 fs/proc/base.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)


diff --git a/fs/proc/base.c b/fs/proc/base.c
index 7411bfb..c824b23 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2207,7 +2207,7 @@ static const struct pid_entry tgid_base_stuff[] = {
INF("cmdline",S_IRUGO, pid_cmdline),
INF("stat",   S_IRUGO, tgid_stat),
INF("statm",  S_IRUGO, pid_statm),
-   REG("maps",   S_IRUGO, maps),
+   REG("maps",   S_IRUSR, maps),
 #ifdef CONFIG_NUMA
REG("numa_maps",  S_IRUGO, numa_maps),
 #endif
@@ -2219,7 +2219,7 @@ static const struct pid_entry tgid_base_stuff[] = {
REG("mountstats", S_IRUSR, mountstats),
 #ifdef CONFIG_MMU
REG("clear_refs", S_IWUSR, clear_refs),
-   REG("smaps",  S_IRUGO, smaps),
+   REG("smaps",  S_IRUSR, smaps),
 #endif
 #ifdef CONFIG_SECURITY
DIR("attr",   S_IRUGO|S_IXUGO, attr_dir),
@@ -2533,7 +2533,7 @@ static const struct pid_entry tid_base_stuff[] = {
INF("cmdline",   S_IRUGO, pid_cmdline),
INF("stat",  S_IRUGO, tid_stat),
INF("statm", S_IRUGO, pid_statm),
-   REG("maps",  S_IRUGO, maps),
+   REG("maps",  S_IRUSR, maps),
 #ifdef CONFIG_NUMA
REG("numa_maps", S_IRUGO, numa_maps),
 #endif
@@ -2544,7 +2544,7 @@ static const struct pid_entry tid_base_stuff[] = {
REG("mounts",S_IRUGO, mounts),
 #ifdef CONFIG_MMU
REG("clear_refs", S_IWUSR, clear_refs),
-   REG("smaps", S_IRUGO, smaps),
+   REG("smaps", S_IRUSR, smaps),
 #endif
 #ifdef CONFIG_SECURITY
DIR("attr",  S_IRUGO|S_IXUGO, attr_dir),

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

PIT clocksource makes invalid assumptions

[Dan Hecht]

Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT 
clocksource code assumes that the PIT CH0 is in periodic mode.  With 
clockevents, this assumption is no longer valid.  There are at least two 
places that make this assumption:


1) The calculation at the end of pit_read() assumes that the PIT is in 
periodic mode.  This isn't true unless the PIT is the current clockevent 
and nohz is inactive.  (Though #2 can end up forcing the PIT to be 
reprogrammed).


2) The PIT clockevent is shutdown by using PIT mode 0 (interrupt on 
terminal count) -- doesn't the PIT counter continue to count (even 
though it won't be raising an interrupt)?  If so, the test in pit_read() 
under the VIA686a comment can succeed after the PIT clockevent has been 
shutdown, and the PIT hardware may be reprogrammed to start firing 
interrupts again.  This doesn't seem intentional, and can defeat nohz 
since now the PIT is firing periodically.


Seems these problems can happen when the PIT is used as the clocksource 
or even just the clocksource watchdog.  It looks like there is some code 
in clocksource.c that checks for CLOCK_SOURCE_IS_CONTINUOUS, which is 
not set for the PIT clocksource, but it doesn't seem to be strong enough 
to prevent these problematic scenarios (and it's not clear if that is 
the intent of IS_CONTINUOUS anyway).


To verify this really can happen, when I boot a kernel, I can see this 
sequence:


  init_pit_timer (with mode==CLOCK_EVT_MODE_PERIODIC)
  init_pit_timer (with mode==CLOCK_EVT_MODE_UNUSED)
  init_pit_timer (with mode==CLOCK_EVT_MODE_SHUTDOWN)
  pit_read() and count > LATCH (I believe the PIT is the watchdog at 
this point), which causes the PIT to raise periodic interrupts.


(Shortly after, the acpi pm clocksource is registered and replaces the 
PIT as the watchdog.  Later, the PIT clockevent is used as the broadcast 
clockevent and reprogrammed into one-shot mode, stopping the PIT 
interrupts.)


Also, the user could force the PIT clocksource to be current_clocksource 
even though the PIT is in one-shot mode (and therefore the calculation 
in pit_read is bogus).


Of course, all this can only happen for 32-bit UP.  I'm not sure what 
the preferred fix for this is...


Dan

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

Re: Error returns not handled correctly by sysfs.c:subsys_attr_store()

[Andrew Patterson]

On Mon, 2007-12-03 at 14:15 -0700, Andrew Patterson wrote:
> On Thu, 2007-11-29 at 10:07 +0900, Tejun Heo wrote:
> > Andrew Patterson wrote:
> > > I tried with clean 2.6.24-rc3 and get the same bad behavior.  This is on
> > > an ia64 box, so maybe that is an issue. I can try on an x86 box as well.
> > > Oh, one other thing.  I tried a "uname -r" to make sure I had the
> > > correct kernel booted and got:
> > > 
> > > # uname -r
> > > 2.6.24-rc3
> > > x
> > > y
> > > z
> > > #
> > 
> > Yeah, please try it on another machine from clean tree.  sysfs code is
> > definitely not endian dependent and is 64 bit clean.  Heck, all my test
> > machines run 64 bit these days.  I would be surprised if it's something
> > architecture dependent but please try on a different machine with
> > different userland with kernel built from fresh source tree.
> > 
> > Thanks.
> 
> I tried this on a AMD system running an i386 kernel. I get the same bad
> behavior.  This is from a 2.6.24-rc3 kernel downloaded from kernel.org.
> I ran "make mrproper" followed by "make oldconfig" and accepted all the
> defaults for the config.
> 
> There is one slight change with this experiment.  Other nodes are not
> getting corrupted, i.e., uname -r is getting the correct value.

It looks like this is a shell issue.  After looking through the sysfs
code, I realized that this problem seems to be driven from user-land.
So I performed some experiments:

 1. Wrote a simple program that just used write(2) to write to the
sysfs entry. This works fine.
 2. Used /bin/echo instead of the built-in echo command.  This too
works fine.
 3. Tried several shells.  Zsh and Bash both fail.  Csh works fine.

I then ran strace on the following shell-script:

#!/bin/bash

echo x > allow_restart
echo y > allow_restart
echo z > allow_restart

and got:

# strace -e trace=write ~/tmp/tester.sh 
write(1, "x\n", 2)  = -1 EINVAL (Invalid argument)
write(1, "x\n", 2)  = -1 EINVAL (Invalid argument)
write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: 
line 4: echo: write error: Invalid argument
) = 72
write(1, "x\ny\n", 4)   = -1 EINVAL (Invalid argument)
write(1, "x\ny\n", 4)   = -1 EINVAL (Invalid argument)
write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: 
line 5: echo: write error: Invalid argument
) = 72
write(1, "x\ny\nz\n", 6)= -1 EINVAL (Invalid argument)
write(1, "x\ny\nz\n", 6)= -1 EINVAL (Invalid argument)
write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: 
line 6: echo: write error: Invalid argument
) = 72
write(1, "x\ny\nz\n", 6x
y
z
)= 6
Process 3800 detached

As you can see, subsequent echo commands have their arguments appended
to the previous command. So it seems that the shell is not resetting the
buffer between failed echo commands.  

-- 
Andrew Patterson
Hewlett-Packard Company

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

Re: [PATCH] This patch to printk.c fixes a few errors reported by checkpatch.pl

[Randy Dunlap]

On Fri, 4 Jan 2008 00:14:46 +0100 Paolo Ciarrocchi wrote:

> This patch to printk.c fixes a few errors reported by checkpatch.pl
> 
> Before:
> total: 18 errors, 17 warnings, 1306 lines checked
> 
> After:
> total: 1 errors, 17 warnings, 1305 lines checked
> 
> 
> Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
> ---
> 
> Adrian, I'm sending this patch to you because according to git shortlog -e
> you are the most active modifier of this file.
> 
> 
>  kernel/printk.c |   25 -
>  1 files changed, 12 insertions(+), 13 deletions(-)
> 
> diff --git a/kernel/printk.c b/kernel/printk.c
> index 89011bf..00f784f 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c

Hi,

Please read Andrew's "The Perfect Patch," especially the section
about Subject: lines.

http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt

---
~Randy
desserts:  http://www.xenotime.net/linux/recipes/
--
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/

Re: [PATCH] This patch to printk.c fixes a few errors reported by checkpatch.pl

[Jesper Juhl]

On 04/01/2008, Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote:
> This patch to printk.c fixes a few errors reported by checkpatch.pl
>
[...]
> -   for (a=console_drivers->next, b=console_drivers ;
> -a; b=a, a=b->next) {
> +   for (a = console_drivers->next, b = console_drivers ;

I would say that if you are modifying this line anyway you should make it read

   for (a = console_drivers->next, b = console_drivers;

(the change is the removal of the space before the ';' at the end of the line)

otherwise I think it looks sane enough as a small style cleanup.

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
--
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/

Re: [PATCH] md: Fix data corruption when a degraded raid5 array is reshaped.

[Dan Williams]

On Thu, 2008-01-03 at 16:00 -0700, Williams, Dan J wrote:
> On Thu, 2008-01-03 at 15:46 -0700, NeilBrown wrote:
> > This patch fixes a fairly serious bug in md/raid5 in 2.6.23 and
> 24-rc.
> > It would be great if it cold get into 23.13 and 24.final.
> > Thanks.
> > NeilBrown
> >
> > ### Comments for Changeset
> >
> > We currently do not wait for the block from the missing device
> > to be computed from parity before copying data to the new stripe
> > layout.
> >
> > The change in the raid6 code is not techincally needed as we
> > don't delay data block recovery in the same way for raid6 yet.
> > But making the change now is safer long-term.
> >
> > This bug exists in 2.6.23 and 2.6.24-rc
> >
> > Cc: [EMAIL PROTECTED]
> > Cc: Dan Williams <[EMAIL PROTECTED]>
> > Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
> >
> Acked-by: Dan Williams <[EMAIL PROTECTED]>
> 

On closer look the safer test is:

!test_bit(STRIPE_OP_COMPUTE_BLK, >ops.pending).

The 'req_compute' field only indicates that a 'compute_block' operation
was requested during this pass through handle_stripe so that we can
issue a linked chain of asynchronous operations.

---

From: Neil Brown <[EMAIL PROTECTED]>

md: Fix data corruption when a degraded raid5 array is reshaped.

We currently do not wait for the block from the missing device
to be computed from parity before copying data to the new stripe
layout.

The change in the raid6 code is not techincally needed as we
don't delay data block recovery in the same way for raid6 yet.
But making the change now is safer long-term.

This bug exists in 2.6.23 and 2.6.24-rc

Cc: [EMAIL PROTECTED]
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---

 drivers/md/raid5.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index a5aad8c..e8c8157 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2865,7 +2865,8 @@ static void handle_stripe5(struct stripe_head *sh)
md_done_sync(conf->mddev, STRIPE_SECTORS, 1);
}
 
-   if (s.expanding && s.locked == 0)
+   if (s.expanding && s.locked == 0 &&
+   !test_bit(STRIPE_OP_COMPUTE_BLK, >ops.pending))
handle_stripe_expansion(conf, sh, NULL);
 
if (sh->ops.count)
@@ -3067,7 +3068,8 @@ static void handle_stripe6(struct stripe_head *sh, struct 
page *tmp_page)
md_done_sync(conf->mddev, STRIPE_SECTORS, 1);
}
 
-   if (s.expanding && s.locked == 0)
+   if (s.expanding && s.locked == 0 &&
+   !test_bit(STRIPE_OP_COMPUTE_BLK, >ops.pending))
handle_stripe_expansion(conf, sh, );
 
spin_unlock(>lock);

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

Re: [PATCH] This patch to profile.c fixes a few errors reported by checkpatch.pl

[Jesper Juhl]

On 04/01/2008, Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote:
> Before:
> total: 25 errors, 13 warnings, 602 lines checked
>
> After:
> total: 3 errors, 13 warnings, 602 lines checked
>
>
> Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>

Looks sane to me.

Reviewed-by: Jesper Juhl <[EMAIL PROTECTED]>

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
--
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/

[PATCH] This patch to profile.c fixes a few errors reported by checkpatch.pl

[Paolo Ciarrocchi]

Before:
total: 25 errors, 13 warnings, 602 lines checked

After:
total: 3 errors, 13 warnings, 602 lines checked


Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
---
Ingo, I'm sending this patch to you since according to git shortlog -e
you are the most active modifier of this file


 kernel/profile.c |   70 +++---
 1 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/kernel/profile.c b/kernel/profile.c
index 5e95330..c99153b 100644
--- a/kernel/profile.c
+++ b/kernel/profile.c
@@ -52,7 +52,7 @@ static DEFINE_PER_CPU(int, cpu_profile_flip);
 static DEFINE_MUTEX(profile_flip_mutex);
 #endif /* CONFIG_SMP */
 
-static int __init profile_setup(char * str)
+static int __init profile_setup(char *str)
 {
static char __initdata schedstr[] = "schedule";
static char __initdata sleepstr[] = "sleep";
@@ -104,27 +104,27 @@ __setup("profile=", profile_setup);
 
 void __init profile_init(void)
 {
-   if (!prof_on) 
+   if (!prof_on)
return;
- 
+
/* only text is profiled */
prof_len = (_etext - _stext) >> prof_shift;
prof_buffer = alloc_bootmem(prof_len*sizeof(atomic_t));
 }
 
 /* Profile event notifications */
- 
+
 #ifdef CONFIG_PROFILING
- 
+
 static BLOCKING_NOTIFIER_HEAD(task_exit_notifier);
 static ATOMIC_NOTIFIER_HEAD(task_free_notifier);
 static BLOCKING_NOTIFIER_HEAD(munmap_notifier);
- 
-void profile_task_exit(struct task_struct * task)
+
+void profile_task_exit(struct task_struct *task)
 {
blocking_notifier_call_chain(_exit_notifier, 0, task);
 }
- 
+
 int profile_handoff_task(struct task_struct * task)
 {
int ret;
@@ -137,48 +137,48 @@ void profile_munmap(unsigned long addr)
blocking_notifier_call_chain(_notifier, 0, (void *)addr);
 }
 
-int task_handoff_register(struct notifier_block * n)
+int task_handoff_register(struct notifier_block *n)
 {
return atomic_notifier_chain_register(_free_notifier, n);
 }
 
-int task_handoff_unregister(struct notifier_block * n)
+int task_handoff_unregister(struct notifier_block *n)
 {
return atomic_notifier_chain_unregister(_free_notifier, n);
 }
 
-int profile_event_register(enum profile_type type, struct notifier_block * n)
+int profile_event_register(enum profile_type type, struct notifier_block *n)
 {
int err = -EINVAL;
- 
+
switch (type) {
-   case PROFILE_TASK_EXIT:
-   err = blocking_notifier_chain_register(
-   _exit_notifier, n);
-   break;
-   case PROFILE_MUNMAP:
-   err = blocking_notifier_chain_register(
-   _notifier, n);
-   break;
+   case PROFILE_TASK_EXIT:
+   err = blocking_notifier_chain_register(
+   _exit_notifier, n);
+   break;
+   case PROFILE_MUNMAP:
+   err = blocking_notifier_chain_register(
+   _notifier, n);
+   break;
}
- 
+
return err;
 }
 
- 
-int profile_event_unregister(enum profile_type type, struct notifier_block * n)
+
+int profile_event_unregister(enum profile_type type, struct notifier_block *n)
 {
int err = -EINVAL;
- 
+
switch (type) {
-   case PROFILE_TASK_EXIT:
-   err = blocking_notifier_chain_unregister(
-   _exit_notifier, n);
-   break;
-   case PROFILE_MUNMAP:
-   err = blocking_notifier_chain_unregister(
-   _notifier, n);
-   break;
+   case PROFILE_TASK_EXIT:
+   err = blocking_notifier_chain_unregister(
+   _exit_notifier, n);
+   break;
+   case PROFILE_MUNMAP:
+   err = blocking_notifier_chain_unregister(
+   _notifier, n);
+   break;
}
 
return err;
@@ -475,7 +475,7 @@ read_profile(struct file *file, char __user *buf, size_t 
count, loff_t *ppos)
 {
unsigned long p = *ppos;
ssize_t read;
-   char * pnt;
+   char *pnt;
unsigned int sample_step = 1 << prof_shift;
 
profile_flip_buffers();
@@ -486,12 +486,12 @@ read_profile(struct file *file, char __user *buf, size_t 
count, loff_t *ppos)
read = 0;
 
while (p < sizeof(unsigned int) && count > 0) {
-   if (put_user(*((char *)(_step)+p),buf))
+   if (put_user(*((char *)(_step)+p), buf))
return -EFAULT;
buf++; p++; count--; read++;
}
pnt = (char *)prof_buffer + p - sizeof(atomic_t);
-   if (copy_to_user(buf,(void *)pnt,count))
+   if (copy_to_user(buf, (void *)pnt, count))
return -EFAULT;
read += count;
*ppos 

Re: [GIT PULL] please pull infiniband.git for-linus

[Dave Dillow]

On Thu, 2008-01-03 at 18:11 -0500, Rik van Riel wrote:
> On Thu, 03 Jan 2008 15:20:09 -0500
> David Dillow <[EMAIL PROTECTED]> wrote:
> 
> > diff --git a/drivers/infiniband/ulp/srp/ib_srp.c 
> > b/drivers/infiniband/ulp/srp/ib_srp.c
> > index 950228f..6e7e3c8 100644
> > --- a/drivers/infiniband/ulp/srp/ib_srp.c
> > +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> > @@ -423,8 +423,8 @@ static void srp_remove_work(struct work_struct *work)
> > list_del(>list);
> > spin_unlock(>srp_host->target_lock);
> >  
> > -   srp_remove_host(target->scsi_host);
> > scsi_remove_host(target->scsi_host);
> > +   srp_remove_host(target->scsi_host);
> > ib_destroy_cm_id(target->cm_id);
> > srp_free_target_ib(target);
> > scsi_host_put(target->scsi_host);
> 
> These last two look suspicious.  Are you freeing target before
> freeing target->scsi_host or does the code simply not do what
> it looks like it's doing? :)
> 
> (no, I haven't looked at the IB code - I'm probably wrong)

srp_free_target_ib() just frees the buffers for the target, and
scsi_host_put() does the actual cleanup once the refcount drops to zero.

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

[PATCH] This patch to printk.c fixes a few errors reported by checkpatch.pl

[Paolo Ciarrocchi]

This patch to printk.c fixes a few errors reported by checkpatch.pl

Before:
total: 18 errors, 17 warnings, 1306 lines checked

After:
total: 1 errors, 17 warnings, 1305 lines checked


Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
---

Adrian, I'm sending this patch to you because according to git shortlog -e
you are the most active modifier of this file.


 kernel/printk.c |   25 -
 1 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/kernel/printk.c b/kernel/printk.c
index 89011bf..00f784f 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -100,8 +100,7 @@ static unsigned long log_end;   /* Index into log_buf: 
most-recently-written-char
 /*
  * Array of consoles built from command line options (console=)
  */
-struct console_cmdline
-{
+struct console_cmdline {
charname[8];/* Name of the driver   */
int index;  /* Minor dev. to use*/
char*options;   /* Options for the driver   */
@@ -323,7 +322,7 @@ int do_syslog(int type, char __user *buf, int len)
c = LOG_BUF(log_start);
log_start++;
spin_unlock_irq(_lock);
-   error = __put_user(c,buf);
+   error = __put_user(c, buf);
buf++;
i++;
cond_resched();
@@ -368,7 +367,7 @@ int do_syslog(int type, char __user *buf, int len)
break;
c = LOG_BUF(j);
spin_unlock_irq(_lock);
-   error = __put_user(c,[count-1-i]);
+   error = __put_user(c, [count-1-i]);
cond_resched();
spin_lock_irq(_lock);
}
@@ -380,8 +379,8 @@ int do_syslog(int type, char __user *buf, int len)
int offset = count-error;
/* buffer overflow during copy, correct user buffer. */
for (i = 0; i < error; i++) {
-   if (__get_user(c,[i+offset]) ||
-   __put_user(c,[i])) {
+   if (__get_user(c, [i+offset]) ||
+   __put_user(c, [i])) {
error = -EFAULT;
break;
}
@@ -556,7 +555,7 @@ static void zap_locks(void)
 #if defined(CONFIG_PRINTK_TIME)
 static int printk_time = 1;
 #else
-static int printk_time = 0;
+static int printk_time ;
 #endif
 module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
 
@@ -659,7 +658,7 @@ asmlinkage int vprintk(const char *fmt, va_list args)
 */
for (p = printk_buf; *p; p++) {
if (log_level_unknown) {
-/* log_level_unknown signals the start of a new line */
+   /* log_level_unknown signals the start of a new line */
if (printk_time) {
int loglev_char;
char tbuf[50], *tp;
@@ -671,7 +670,7 @@ asmlinkage int vprintk(const char *fmt, va_list args)
 * force the log level token to be
 * before the time output.
 */
-   if (p[0] == '<' && p[1] >='0' &&
+   if (p[0] == '<' && p[1] >= '0' &&
   p[1] <= '7' && p[2] == '>') {
loglev_char = p[1];
p += 3;
@@ -1176,16 +1175,16 @@ EXPORT_SYMBOL(register_console);
 
 int unregister_console(struct console *console)
 {
-struct console *a, *b;
+   struct console *a, *b;
int res = 1;
 
acquire_console_sem();
if (console_drivers == console) {
-   console_drivers=console->next;
+   console_drivers = console->next;
res = 0;
} else if (console_drivers) {
-   for (a=console_drivers->next, b=console_drivers ;
-a; b=a, a=b->next) {
+   for (a = console_drivers->next, b = console_drivers ;
+a; b = a, a = b->next) {
if (a == console) {
b->next = a->next;
res = 0;
-- 
1.5.4.rc2.17.g257f

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

Re: [PATCH] teach checkpatch.pl about list_for_each

[Christer Weinigel]

On Thu, 03 Jan 2008 17:17:29 +0200
Benny Halevy <[EMAIL PROTECTED]> wrote:

> On Jan. 03, 2008, 14:30 +0200, Arnaldo Carvalho de Melo
> > Agreed, CodingStyle is not about mindless consistency such as "for
> > (" is the right thing, so "list_for_each (" is consistent with it,
> > it is about codifying practice contributors got used to over the
> > years.
> > 
> 
> Why mindless?
> Coding style is also about giving the coding language logic a
> graphical representation.  Following a convention that flow control
> keywords such as "if", "for", or "while" are distinguished from
> function calls by use of a space after the keyword really helps the
> code readability regardless of how people used to code it in the
> past... The for_each_* macros are clearly not function calls but
> rather translate to for () flow control constructs hence they should
> follow the same convention. FWIW, I think that changing the existing
> convention is worth it in this case.

Definite agreement here, since _for_each is used for flow control, that
space should be there.  

And some people seem to take checkpatch.pl as the gospel, and won't
apply code with checkpatch warnings.

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

Re: [GIT PULL] please pull infiniband.git for-linus

[Rik van Riel]

On Thu, 03 Jan 2008 15:20:09 -0500
David Dillow <[EMAIL PROTECTED]> wrote:

> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c 
> b/drivers/infiniband/ulp/srp/ib_srp.c
> index 950228f..6e7e3c8 100644
> --- a/drivers/infiniband/ulp/srp/ib_srp.c
> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> @@ -423,8 +423,8 @@ static void srp_remove_work(struct work_struct *work)
>   list_del(>list);
>   spin_unlock(>srp_host->target_lock);
>  
> - srp_remove_host(target->scsi_host);
>   scsi_remove_host(target->scsi_host);
> + srp_remove_host(target->scsi_host);
>   ib_destroy_cm_id(target->cm_id);
>   srp_free_target_ib(target);
>   scsi_host_put(target->scsi_host);

These last two look suspicious.  Are you freeing target before
freeing target->scsi_host or does the code simply not do what
it looks like it's doing? :)

(no, I haven't looked at the IB code - I'm probably wrong)

-- 
All Rights Reversed
--
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/