ioremap - simply question, big problem (to me)

[Marcin Glogowski]

Hi everybody,
I have several questions about ioremap:
1) I have two 16 bit sram memory devices. To force it works I had to use 
ioremap with memorysize*2, because
I was able to write to the 1 and 2 byte, 5,6, 9,10, 13,14 and so on.
Please explain why my ioremap space is non-continous,
how to ioremap a 32 bit device that consists of 2 16 bit devices? (in 
another system I simply copied the 16 bits to first device and another 
16 bits
to the second device and I had a working system) and why in the remapped 
memory are holes?

2) In my another system to get a value of the register from a flash 
device I had to use "volatile u16 the_address_of_my_device".
How to get the value in the case when Linux has virtual remapped the 
physical address?

Thank you.
--
Startuj z INTERIA.PL! >>> http://link.interia.pl/f186c 

-
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] ppc: eliminate gcc warning in xmon.c

[Paul Mackerras]

This patch shuts up some more incorrect gcc warnings.

Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>

diff -urN linux-2.5/arch/ppc/xmon/xmon.c testpmac/arch/ppc/xmon/xmon.c
--- linux-2.5/arch/ppc/xmon/xmon.c  2004-10-21 07:17:18.0 +1000
+++ testpmac/arch/ppc/xmon/xmon.c   2005-04-02 17:23:19.0 +1000
@@ -1033,9 +1033,9 @@
extern unsigned long Hash_size;
unsigned *htab = Hash;
unsigned hsize = Hash_size;
-   unsigned v, hmask, va, last_va;
+   unsigned v, hmask, va, last_va = 0;
int found, last_found, i;
-   unsigned *hg, w1, last_w2, last_va0;
+   unsigned *hg, w1, last_w2 = 0, last_va0 = 0;
 
last_found = 0;
hmask = hsize / 64 - 1;
@@ -1492,7 +1492,7 @@
 {
int nr, dotted;
unsigned first_adr;
-   unsigned long inst, last_inst;
+   unsigned long inst, last_inst = 0;
unsigned char val[4];
 
dotted = 0;
@@ -1959,7 +1959,7 @@
 xmon_symbol_to_addr(char* symbol)
 {
char *p, *cur;
-   char *match;
+   char *match = NULL;
int goodness = 0;
int result = 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] Cleanup locking in sys_reboot() (was Re: [PATCH] Reduce stack usage in sys.c)

[Yum Rayan]

On Mar 31, 2005 12:29 AM, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Your "cleanup lock usage" increases the number of lock_kernel() calls
> quite a bit, which is not really a cleanup but simply bloat.

Yes, just looking at the patch, seem to indicate so. But let's take a
closer look at the original code from a run time perspective :

346  lock_kernel();
347  switch (cmd) {
...
355  case LINUX_REBOOT_CMD_CAD_ON:
356  C_A_D = 1;
357  break;

421  unlock_kernel();
422  return 0;

Why the lock_kernel() and unlock_kernel()? This happens for another
case as follows:

346  lock_kernel();
347  switch (cmd) {
...
358  case LINUX_REBOOT_CMD_CAD_OFF:
359  C_A_D = 0;
360  break;
...
421  unlock_kernel();
422  return 0;

Should'nt we be keeping the lock_kernel() and unlock_kernel() calls to
a minimum?

Again something sloppy happening here:

346  lock_kernel();
347  switch (cmd) {
...
361  case LINUX_REBOOT_CMD_HALT:
362  notifier_call_chain(_notifier_list, SYS_HALT, NULL);
...
376  unlock_kernel();
377  do_exit(0);
378  break;
...
421  unlock_kernel();
422  return 0;

The previous author shows deligence in having the "break;" after
"do_exit(0)", but why "unlock_kernel()" twice in the same path? What
if down the road, someone changes do_exit() to do something else and
actually return ?

Same style above, shown for this case as well:

370  case LINUX_REBOOT_CMD_POWER_OFF:

Some other kind of mess:

410  case LINUX_REBOOT_CMD_SW_SUSPEND:
411  {
412  int ret = software_suspend();
413  unlock_kernel();
414  return ret;
415  }
... << the switch...case ends at this line
421  unlock_kernel();
422  return 0;

Could'nt we just have a single "unlock_kernel()" above?

Some more:

417  default:
418  unlock_kernel();
419  return -EINVAL;
420  }
421  unlock_kernel();
422  return 0;

It would have been nice to have a single "unlock_kernel()" and single
point of exit. Also note that for "default" case, we are doing
lock_kernel() and unlock_kernel() for nothing?

And finally:
346  lock_kernel();
347  switch (cmd) {
...
379  case LINUX_REBOOT_CMD_RESTART2:
380  if (strncpy_from_user([0], arg,
sizeof(buffer) - 1) < 0) {
381  unlock_kernel();
382  return -EFAULT;
383  }

Does the "strncpy_from_user()" really need a lock_kernel()?

My attempt to reduce the stack usage needed to kmalloc buffer and
buffer was being used for the above case (LINUX_REBOOT_CMD_RESTART2)
only. I did not think it was good to have lock_kernel() for the
kmalloc and the subsequent NULL checking of the returned pointer. So I
ended up driving the lock_kernel() and matching unlock_kernel() calls
deeper, IMHO a cleanup. In some cases the unlock_kernel() calls are
provided for sake of completeness, just like the "break;" statements.
You might count the number of "lock_kernel()" to increase in the code,
but actually the patch minimizes the run time calls to
"lock_kernel()".

I assume a call like sys_reboot() is no big deal, but feedback will
always help going forward. I dropped the pick at the stack usage, just
the patch to move the locks around... (cleanup?)

Thanks,
Rayan

Signed-off-by: Yum Rayan <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4.a/kernel/sys.c 2005-03-31 16:51:30.0 -0800
+++ linux-2.6.12-rc1-mm4.b/kernel/sys.c 2005-04-01 22:46:53.0 -0800
@@ -385,14 +385,15 @@
magic2 != LINUX_REBOOT_MAGIC2C))
return -EINVAL;
 
-   lock_kernel();
switch (cmd) {
case LINUX_REBOOT_CMD_RESTART:
+   lock_kernel();
notifier_call_chain(_notifier_list, SYS_RESTART, NULL);
system_state = SYSTEM_RESTART;
device_shutdown();
printk(KERN_EMERG "Restarting system.\n");
machine_restart(NULL);
+   unlock_kernel();
break;
 
case LINUX_REBOOT_CMD_CAD_ON:
@@ -404,6 +405,7 @@
break;
 
case LINUX_REBOOT_CMD_HALT:
+   lock_kernel();
notifier_call_chain(_notifier_list, SYS_HALT, NULL);
system_state = SYSTEM_HALT;
device_shutdown();
@@ -414,6 +416,7 @@
break;
 
case LINUX_REBOOT_CMD_POWER_OFF:
+   lock_kernel();
notifier_call_chain(_notifier_list, SYS_POWER_OFF, NULL);
system_state = SYSTEM_POWER_OFF;
device_shutdown();
@@ -425,22 +428,24 @@
 
case LINUX_REBOOT_CMD_RESTART2:
   

RE: x86 TSC time warp puzzle

[Pallipadi, Venkatesh]

At what point are you seeing these delays? During early boot or after
boot? 
It can be SMI happening in the platform. Typically BIOS uses some SMI
polling 
to handle some devices during early boot. Though 500 microseconds sounds
a 
bit too high.

Thanks,
Venki

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of 
>Jonathan Lundell
>Sent: Friday, April 01, 2005 5:43 PM
>To: LKML
>Subject: x86 TSC time warp puzzle
>
>Well, not actually a time warp, though it feels like one.
>
>I'm doing some real-time bit-twiddling in a driver, using the TSC to 
>measure out delays on the order of hundreds of nanoseconds. Because I 
>want an upper limit on the delay, I disable interrupts around it.
>
>The logic is something like:
>
>   local_irq_save
>   out(set a bit)
>   t0 = TSC
>   wait while (t = (TSC - t0)) < delay_time
>   out(clear the bit)
>   local_irq_restore
>
> From time to time, when I exit the delay, t is *much* bigger than 
>delay_time. If delay_time is, say, 300ns, t is usually no more than 
>325ns. But every so often, t can be 2000, or 1, or even much 
>higher.
>
>The value of t seems to depend on the CPU involved, The worst case is 
>with an Intel 915GV chipset, where t approaches 500 microseconds (!).
>
>This is with ACPI and HT disabled, to avoid confounding interactions. 
>I suspected NMI, of course, but I monitored the nmi counter, and 
>mostly saw nothing (from time to time a random hit, but mostly not).
>
>The longer delay is real. I can see the bit being set/cleared in the 
>pseudocode above on a scope, and when the long delay happens, the bit 
>is set for a correspondingly long time.
>
>BTW, the symptom is independent of my IO. I wrote a test case that 
>does diddles nothing but reading TSC, and get the same result.
>
>Finally, on some CPUs, at least, the extra delay appears to be 
>periodic. The 500us delay happens about every second. On a different 
>machine (chipset) it happens at about 5 Hz. And the characteristic 
>delay on each type of machine seems consistent.
>
>Any ideas of where to look? Other lists to inquire on?
>
>Thanks.
>-- 
>/Jonathan Lundell.
>-
>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/
>
-
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: initramfs linus tree breakage in last day

[Andrew Morton]

Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> This will let me boot again. It is not obvious to me where the problem
>  is, it may have something to do with netlink or maybe memory
>  corruption?
> 
>  bk export -tpatch -r1.2326,1.2327 >../foo.patch
>  patch -p1 -R <../foo.patch
> 
>  # ChangeSet
>  #   2005/03/31 21:14:28-08:00 [EMAIL PROTECTED]
>  #   Merge bk://kernel.bkbits.net/acme/net-2.6
>  #   into sunset.davemloft.net:/home/davem/src/BK/net-2.6
>  #
>  # ChangeSet
>  #   2005/03/26 20:04:49-03:00 [EMAIL PROTECTED]
>  #   [NET] make all protos partially use sk_prot

Cute.  I assume you have all the memory debug options enabled?

You could try disabling net features in .config, see if you can work out
which one causes it.

-
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: initramfs linus tree breakage in last day

[Jon Smirl]

This will let me boot again. It is not obvious to me where the problem
is, it may have something to do with netlink or maybe memory
corruption?

bk export -tpatch -r1.2326,1.2327 >../foo.patch
patch -p1 -R <../foo.patch

# ChangeSet
#   2005/03/31 21:14:28-08:00 [EMAIL PROTECTED]
#   Merge bk://kernel.bkbits.net/acme/net-2.6
#   into sunset.davemloft.net:/home/davem/src/BK/net-2.6
#
# ChangeSet
#   2005/03/26 20:04:49-03:00 [EMAIL PROTECTED]
#   [NET] make all protos partially use sk_prot

-- 
Jon Smirl
[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: 2.6.11ac5 oops while reconstructing md array and moving volumegroup with pvmove

[Antti Salmela]

On Sat, Apr 02, 2005 at 09:37:07AM +1000, Neil Brown wrote:
> On Friday April 1, [EMAIL PROTECTED] wrote:
> > I had created a new raid1 array and started moving a volume group to it at 
> > the
> > same time while it was reconstructing. Got this oops after several hours,
> 
> The subject says 'md array' but the Opps seems to say 'dm raid1
> array'.

Subject is correct. Events went roughly like this:

% mdadm --create -l 1 -n 2 /dev/md2 /dev/hde /dev/hdg
% pvcreate /dev/md2
% vgextend vg1 /dev/md2
% pvmove /dev/hdf /dev/md2

All this while logical volumes on vg1 with ext3 filesystems were in light use.

I think pvmove needs dm mirror target to move underlying physical extents,
wouldn't this look like dm raid1?

Got some new ones while trying to finish the move.

 c028a7f6
 Modules linked in: esp6 ah6 nfsd exportfs via686a snd_ymfpci snd_ac97_codec 
snd_pcm_oss snd_mixer_oss snd_pcm snd_opl3_lib snd_timer snd_hwdep 
snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore 
uhci_hcd i2c_dev w83781d i2c_sensor i2c_viapro i2c_core
 CPU:0
 EIP:0060:[core_in_sync+6/32]Not tainted VLI
 EFLAGS: 00010246   (2.6.11ac5) 
 EIP is at core_in_sync+0x6/0x20
 eax: f8a3e000   ebx: c0407260   ecx: 0001   edx: a000
 esi: a000   edi: 0001   ebp: f5ece7c0   esp: f7c04ef4
 ds: 007b   es: 007b   ss: 0068
 Process kmirrord/0 (pid: 329, threadinfo=f7c04000 task=c1b670a0)
 Stack: c028aecb c9a2e9e0 f7c04f38 f5ece7cc c028b80e    
    f5ece7c0 c0407328 c049ad84  
c028b973     f5ece7c0 c028b9b7 0293 
 Call Trace:
  [rh_state+59/80] rh_state+0x3b/0x50
  [do_writes+126/384] do_writes+0x7e/0x180
  [do_mirror+99/112] do_mirror+0x63/0x70
  [do_work+55/112] do_work+0x37/0x70
  [worker_thread+353/512] worker_thread+0x161/0x200
  [activate_task+90/112] activate_task+0x5a/0x70
  [do_work+0/112] do_work+0x0/0x70
  [default_wake_function+0/16] default_wake_function+0x0/0x10
  [__wake_up_common+55/96] __wake_up_common+0x37/0x60
  [default_wake_function+0/16] default_wake_function+0x0/0x10
  [worker_thread+0/512] worker_thread+0x0/0x200
  [kthread+148/160] kthread+0x94/0xa0
  [kthread+0/160] kthread+0x0/0xa0
  [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18
 Code: 27 00 00 00 00 8b 40 04 8b 40 18 0f a3 10 19 d2 31 c0 85 d2 0f 95 c0 c3 
8d b6 00 00 00 00 8d bc 27 00 00 00 00 8b 40 04 8b 40 1c <0f> a3 10 19 d2 31 c0 
85 d2 0f 95 c0 c3 8d b6 00 00 00 00 8d bc 
  <1>Unable to handle kernel paging request at virtual address f8a3f560
 c028a7f6
 Modules linked in: esp6 ah6 nfsd exportfs via686a snd_ymfpci snd_ac97_codec 
snd_pcm_oss snd_mixer_oss snd_pcm snd_opl3_lib snd_timer snd_hwdep 
snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore 
uhci_hcd i2c_dev w83781d i2c_sensor i2c_viapro i2c_core
 CPU:0
 EIP:0060:[core_in_sync+6/32]Not tainted VLI
 EFLAGS: 00010246   (2.6.11ac5) 
 EIP is at core_in_sync+0x6/0x20
 eax: f8a3e000   ebx: c0407260   ecx:    edx: ab04
 esi: cb2df820   edi: f5ece7c0   ebp:    esp: cb056b70
 ds: 007b   es: 007b   ss: 0068
 Process ssh (pid: 16046, threadinfo=cb056000 task=c1b670a0)
 Stack: c028bf7c f7c05f60 f117559c cb2df820 f882a098 c027ffb0 02ac1130  
cb056bdc cb2df860 cb2df860 c0280367 0001 0008 c1b670a0 c01266e0 
f117559c 00036ed0  f882a098 cb2df860 cb056bdc cb2df860 cb056c3c 
 Call Trace:
  [mirror_map+76/192] mirror_map+0x4c/0xc0
  [__map_bio+64/256] __map_bio+0x40/0x100
  [__clone_and_map+551/576] __clone_and_map+0x227/0x240
  [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
  [__split_bio+142/256] __split_bio+0x8e/0x100
  [dm_request+100/144] dm_request+0x64/0x90
  [generic_make_request+326/480] generic_make_request+0x146/0x1e0
  [__find_get_block+66/160] __find_get_block+0x42/0xa0
  [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
  [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
  [bio_clone+160/176] bio_clone+0xa0/0xb0
  [__map_bio+64/256] __map_bio+0x40/0x100
  [__clone_and_map+551/576] __clone_and_map+0x227/0x240
  [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
  [__split_bio+142/256] __split_bio+0x8e/0x100
  [dm_request+100/144] dm_request+0x64/0x90
  [generic_make_request+326/480] generic_make_request+0x146/0x1e0
  [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
  [bh_lru_install+122/176] bh_lru_install+0x7a/0xb0
  [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
  [mempool_alloc+99/256] mempool_alloc+0x63/0x100
  [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
  [submit_bio+88/224] submit_bio+0x58/0xe0
  [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
  [ext3_getblk+131/576] ext3_getblk+0x83/0x240
  [bio_alloc+200/400] bio_alloc+0xc8/0x190
  [submit_bh+193/272] submit_bh+0xc1/0x110
  [ll_rw_block+91/128] 

Ihre Gutschrift: $500 Bonus

[Support]

Herzlichen Glückwünsch.

Sie sind einer der glücklichen Menschen denen wir folgendes Super-Angebot
unterbreiten können:
Spielen Sie mit beim Casino Royal Las Vegas und freuen Sie sich auf bis zu
500 $ Extra
beim ersten Kauf von Chips!!
Ja Sie lesen richtig - bei Ihrem ersten Chipkauf geben wir ihnen bis zu
500$ extra - geschenkt ohne Verpflichtungen.

Holen Sie sich das Casino-Game zum bequemen spielen von Zuhause. 

JETZT MIT TOLLEN NEUEN SPIELEN UND GEWINNCHANCEN

Sie können das Spiel auch ohne Geldeinsatz spielen - allerdings können Sie
dann auch nichts gewinnen. 
Aufladen können Sie ihr Konto auf den Verschiedensten Wegen - mit
Kreditkarte. Banküberweisung und und und.

Also worauf warten Sie noch - gehören auch Sie bald zu den glücklichen
Gewinnern...

http://www.yournews99.com/a22werde/



Mit freundlichem Gruß


Das Casino-Team


-
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.6.12-rc1-mm4] mips: warning fix audit_arch()

[Yoichi Yuasa]

This patch had fixed the following warning about audit_arch().

  ptrace.o
arch/mips/kernel/ptrace.c:305: warning: function declaration isn't a prototype

Yoichi

Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>

diff -urN -X dontdiff rc1-mm4-orig/arch/mips/kernel/ptrace.c 
rc1-mm4/arch/mips/kernel/ptrace.c
--- rc1-mm4-orig/arch/mips/kernel/ptrace.c  Fri Apr  1 21:22:15 2005
+++ rc1-mm4/arch/mips/kernel/ptrace.c   Sat Apr  2 13:30:09 2005
@@ -301,7 +301,7 @@
return ret;
 }
 
-static inline int audit_arch()
+static inline int audit_arch(void)
 {
 #ifdef CONFIG_CPU_LITTLE_ENDIAN
 #ifdef CONFIG_MIPS64
-
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] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00

[Ingo Molnar]

* Gene Heskett <[EMAIL PROTECTED]> wrote:

> Apr  1 18:05:20 coyote ieee1394.agent[6016]: ... no drivers for IEEE1394 
> product 0x/0x/0x
> Apr  1 18:05:24 coyote kernel:
> Apr  1 18:05:24 coyote kernel: ==
> Apr  1 18:05:24 coyote kernel: [ BUG: lock recursion deadlock detected! |
> Apr  1 18:05:24 coyote kernel: --
> Apr  1 18:05:24 coyote kernel: already locked:  [e4d17228] {(struct semaphore 
> *)(>complete_sem)}
> Apr  1 18:05:24 coyote kernel: .. held by:  kino: 6082 [e13ecbb0, 
> 118]
> Apr  1 18:05:24 coyote kernel: ... acquired at:  raw1394_read+0x104/0x110 
> [raw1394]

hm - does the patch below help? (or -43-06 which has the same patch)

Ingo

--- linux/drivers/ieee1394/raw1394-private.h.orig
+++ linux/drivers/ieee1394/raw1394-private.h
@@ -29,7 +29,7 @@ struct file_info {
 
 struct list_head req_pending;
 struct list_head req_complete;
-struct semaphore complete_sem;
+struct compat_semaphore complete_sem;
 spinlock_t reqlists_lock;
 wait_queue_head_t poll_wait_complete;
 
-
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] ppc: eliminate gcc warning in prom.c

[Paul Mackerras]

This patch shuts up a couple of gcc "variable may be used
uninitialized" warnings.  The warnings are invalid - the code is such
that the variables are in fact initialized before being used - but gcc
isn't smart enough to see that.  This patch eliminates the warnings.

Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>

diff -urN linux-2.5/arch/ppc/syslib/prom.c pmac-2.5/arch/ppc/syslib/prom.c
--- linux-2.5/arch/ppc/syslib/prom.c2005-01-22 09:25:41.0 +1100
+++ pmac-2.5/arch/ppc/syslib/prom.c 2005-01-30 18:54:26.0 +1100
@@ -308,7 +308,7 @@
struct device_node *p, *ipar;
unsigned int *imap, *imask, *ip;
int i, imaplen, match;
-   int newintrc, newaddrc;
+   int newintrc = 1, newaddrc = 1;
unsigned int *reg;
int naddrc;
 
-
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: AMD64 Machine hardlocks when using memset

[Robert Hancock]

Paul Jackson wrote:
The x86_64 memset(), both in user space and the kernel, for whatever gcc
I have, and for a current kernel, uses the "repz stos" or "rep stosq"
prefixed instruction for the bulk of the copy.  This combination is a
long running, interruptible Intel string instruction that loops on
itself until the CX register decrements to zero.
Was your windows app using "stos"?
I'll wager a nickel that the actual crash you see comes when the
processor has to handle an interrupt while in the middle of this
instruction.
I'll wager a dime it's hardware, though interrupt activity may be
required to provoke it.
I ended up making a test program which essentially did the same thing 
except not using memset (just moving an int* up repeatedly and setting 
the value there to 0). That worked fine on both Windows and Linux. I 
then tried such a program using a long* compiled as 64-bit on Linux, 
that also worked fine. It seems like I can only reproduce it when memset 
is actually used..

I don't remember exactly what the Windows memset was using, that was on 
my work machine - it was inline assembly though, and I do know that it 
had only one instruction for the whole set, so it was likely "repz stos" 
or something similar to that.

As it turns out, the memset in my version of glibc x86_64 is not using 
such a string instruction though - it seems to be using two different 
sets of instructions depending on the size of the memset (not sure 
exactly how they're calculating the threshold between these..) For sizes 
below the treshold, this is the inner loop - it's using normal mov 
instructions:

3:  /* Copy 64 bytes.  */
mov %r8,(%rcx)
mov %r8,0x8(%rcx)
mov %r8,0x10(%rcx)
mov %r8,0x18(%rcx)
mov %r8,0x20(%rcx)
mov %r8,0x28(%rcx)
mov %r8,0x30(%rcx)
mov %r8,0x38(%rcx)
add $0x40,%rcx
dec %rax
jne 3b
For sizes above the threshold though, this is the inner loop. It's using 
movnti which is an SSE cache-bypasssing store:

11: /* Copy 64 bytes without polluting the cache.  */
/* We could use movntdq%xmm0,(%rcx) here to further
   speed up for large cases but let's not use XMM registers.  */
movnti  %r8,(%rcx)
movnti  %r8,0x8(%rcx)
movnti  %r8,0x10(%rcx)
movnti  %r8,0x18(%rcx)
movnti  %r8,0x20(%rcx)
movnti  %r8,0x28(%rcx)
movnti  %r8,0x30(%rcx)
movnti  %r8,0x38(%rcx)
add $0x40,%rcx
dec %rax
jne 11b
I'm wondering if one does a ton of these cache-bypassing stores whether 
something gets hosed because of that. Not sure what that could be 
though. I don't imagine the chipset is involved with any of that on the 
Athlon 64 - either the CPU or RAM seems the most likely suspect to me

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

4/1/2005 Press release linux-kernel@vger.kernel.org

[Department of Communication]

**
linux-kernel@vger.kernel.org
**

Canadian Business Publications is pleased 
to announce the introduction of the 
Canadian Business Database
a high-performance database application
containing more than 900,000 Canadian 
businesses on cd-rom.

The Canadian Business Database 2005 is an 
easily mastered database application 
designed to provide precise marketing leads.

Features:
*100% exportable in .txt, .dbf, .wk1, .bas, .slk, .mer, .htm...
*Compatible with most popular softwares;
Avery label, Winfax, Exel, Filemaker, 
Act, Goldmine, MS office application 
or any other database software or spreadsheet..
*Advanced searching functions
*Advanced sorting functions
*Cross region reports

Promo version.$ 149.95

To obtain a copy, please call:
CANADIAN BUSINESS PUBLICATIONS
4865 hwy. 138
St-Andrews west
On,Canada
K0C 2A0

toll free : 866 322 3376 in North America
Elsewhere : 819 322 3376 (Canada country code)






To be removed from our mailing list 
email at: [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: 64bit build of tulip driver

[Jim Gifford]

With Grant's help I was able to get the tulip driver to work with 64 bit 
MIPS.

Again Thanx Grant. Attached is the patch I used.

diff -Naur linux-2.6.11.6/drivers/net/tulip/eeprom.c linux-2.6.11.6/drivers/net/tulip/eeprom.c
--- linux-2.6.11.6/drivers/net/tulip/eeprom.c	2005-03-25 19:28:37 -0800
+++ linux-2.6.11.6/drivers/net/tulip/eeprom.c	2005-04-01 09:13:39 -0800
@@ -63,6 +63,22 @@
 	 */
 	{ 0x1e00, 0x, 0x000b, 0x8f01, 0x0103, 0x0300, 0x0821, 0x000, 0x0001, 0x, 0x01e1 }
   },
+  {"Cobalt Microserver", 0, 0x10, 0xE0, {0x1e00, /* 0 == controller #, 1e == offset	*/
+	 0x, /* 0 == high offset, 0 == gap		*/
+	 0x0800, /* Default Autoselect			*/
+	 0x8001, /* 1 leaf, extended type, bogus len	*/
+	 0x0003, /* Type 3 (MII), PHY #0		*/
+	 0x0400, /* 0 init instr, 4 reset instr		*/
+	 0x0801, /* Set control mode, GP0 output	*/
+	 0x, /* Drive GP0 Low (RST is active low)	*/
+	 0x0800, /* control mode, GP0 input (undriven)	*/
+	 0x, /* clear control mode			*/
+	 0x7800, /* 100TX FDX + HDX, 10bT FDX + HDX	*/
+	 0x01e0, /* Advertise all above			*/
+	 0x5000, /* FDX all above			*/
+	 0x1800, /* Set fast TTM in 100bt modes		*/
+	 0x, /* PHY cannot be unplugged		*/
+  }},
   {NULL}};
 
 
diff -Naur linux-2.6.11.6/drivers/net/tulip/interrupt.c linux-2.6.11.6/drivers/net/tulip/interrupt.c
--- linux-2.6.11.6/drivers/net/tulip/interrupt.c	2005-03-25 19:28:40 -0800
+++ linux-2.6.11.6/drivers/net/tulip/interrupt.c	2005-04-01 08:59:41 -0800
@@ -26,7 +26,7 @@
 #define MIT_SIZE 15
 #define MIT_TABLE 15 /* We use 0 or max */
 
-unsigned int mit_table[MIT_SIZE+1] =
+static unsigned int mit_table[MIT_SIZE+1] =
 {
 /*  CRS11 21143 hardware Mitigation Control Interrupt
 We use only RX mitigation we other techniques for
diff -Naur linux-2.6.11.6/drivers/net/tulip/media.c linux-2.6.11.6/drivers/net/tulip/media.c
--- linux-2.6.11.6/drivers/net/tulip/media.c	2005-03-25 19:28:17 -0800
+++ linux-2.6.11.6/drivers/net/tulip/media.c	2005-04-01 08:57:20 -0800
@@ -44,8 +44,10 @@
 
 /* MII transceiver control section.
Read and write the MII registers using software-generated serial
-   MDIO protocol.  See the MII specifications or DP83840A data sheet
-   for details. */
+   MDIO protocol.
+   See IEEE 802.3-2002.pdf (Section 2, Chapter "22.2.4 Management functions")
+   or DP83840A data sheet for more details.
+   */
 
 int tulip_mdio_read(struct net_device *dev, int phy_id, int location)
 {
@@ -88,7 +90,7 @@
 		value = ioread32(ioaddr + CSR9);
 		iowrite32(value & 0xFFEF, ioaddr + CSR9);
 		
-		value = (phy_id << 21) | (location << 16) | 0x8000;
+		value = (phy_id << 21) | (location << 16) | 0x0800;
 		iowrite32(value, ioaddr + CSR10);
 		
 		while(--i > 0) {
@@ -166,7 +168,7 @@
 		value = ioread32(ioaddr + CSR9);
 		iowrite32(value & 0xFFEF, ioaddr + CSR9);
 		
-		value = (phy_id << 21) | (location << 16) | 0x4000 | (val & 0x);
+		value = (phy_id << 21) | (location << 16) | 0x0400 | (val & 0x);
 		iowrite32(value, ioaddr + CSR10);
 		
 		while(--i > 0) {
@@ -307,13 +309,29 @@
 int reset_length = p[2 + init_length];
 misc_info = (u16*)(reset_sequence + reset_length);
 if (startup) {
+	int timeout = 10;	/* max 1 ms */
 	iowrite32(mtable->csr12dir | 0x100, ioaddr + CSR12);
 	for (i = 0; i < reset_length; i++)
 		iowrite32(reset_sequence[i], ioaddr + CSR12);
+
+	/* flush posted writes */
+	ioread32(ioaddr + CSR12);
+
+	/* Sect 3.10.3 in DP83840A.pdf (p39) */
+	udelay(500);
+
+	/* Section 4.2 in DP83840A.pdf (p43) */
+	/* and IEEE 802.3 "22.2.4.1.1 Reset" */
+	while (timeout-- &&
+		(tulip_mdio_read (dev, phy_num, MII_BMCR) & BMCR_RESET))
+		udelay(100);
 }
 for (i = 0; i < init_length; i++)
 	iowrite32(init_sequence[i], ioaddr + CSR12);
+
+ioread32(ioaddr + CSR12);	/* flush posted writes */
 			}
+
 			tmp_info = get_u16(_info[1]);
 			if (tmp_info)
 tp->advertising[phy_num] = tmp_info | 1;
diff -Naur linux-2.6.11.6/drivers/net/tulip/tulip.h linux-2.6.11.6/drivers/net/tulip/tulip.h
--- linux-2.6.11.6/drivers/net/tulip/tulip.h	2005-03-25 19:28:36 -0800
+++ linux-2.6.11.6/drivers/net/tulip/tulip.h	2005-04-01 09:01:07 -0800
@@ -475,8 +475,11 @@
 			udelay(10);
 
 		if (!i)
-			printk(KERN_DEBUG "%s: tulip_stop_rxtx() failed\n",
-	tp->pdev->slot_name);
+			printk(KERN_DEBUG "%s: tulip_stop_rxtx() failed"
+	" (CSR5 0x%x CSR6 0x%x)\n",
+	pci_name(tp->pdev),
+	ioread32(ioaddr + CSR5),
+	ioread32(ioaddr + CSR6));
 	}
 }
 
diff -Naur linux-2.6.11.6/drivers/net/tulip/tulip_core.c linux-2.6.11.6/drivers/net/tulip/tulip_core.c
--- linux-2.6.11.6/drivers/net/tulip/tulip_core.c	2005-03-25 19:28:22 -0800
+++ linux-2.6.11.6/drivers/net/tulip/tulip_core.c	2005-04-01 09:01:54 -0800
@@ -22,7 +22,7 @@
 #else
 #define DRV_VERSION	"1.1.13"
 #endif
-#define DRV_RELDATE	"May 11, 2002"
+#define DRV_RELDATE	"December 15, 2004"
 
 
 

Re: [patch] sched: improve pinned task handling again!

[Nick Piggin]

Siddha, Suresh B wrote:
On Sat, Apr 02, 2005 at 01:11:20PM +1000, Nick Piggin wrote:
How important is this? Any application to real workloads? Even if
not, I agree it would be nice to improve this more. I don't know
if I really like this approach - I guess due to what it adds to
fastpaths.

Ken initially observed with older kernels(2.4 kernel with Ingo's sched), it was 
happening with few hundred processes. 2.6 is not that bad and it improved
with recent fixes. It is not very important. We want to raise the flag
and see if we can comeup with a decent solution.

OK.
We changed nr_running from "unsigned long" to "unsigned int". So on 64-bit
architectures, our change to fastpath is not a big deal.
Yeah I see. You are looking at data from remote runqueues a bit
more often too, although I think they're all places where the
remote cacheline would have already been touched recently.

Now presumably if the all_pinned logic is working properly in the
first place, and it is correctly causing balancing to back-off, you
could tweak that a bit to avoid livelocks? Perhaps the all_pinned
case should back off faster than the usual doubling of the interval,
and be allowed to exceed max_interval?

Coming up with that number(how much to exceed) will be a big task. It depends
on number of cpus and how fast they traverse the runqueue,...
Well we probably don't need to really fine tune it a great deal.
Just pick a lage number that should work OK on most CPU speeds
and CPU counts.
--
SUSE Labs, Novell Inc.
-
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/

LaCie Silverscreen Runs Linux, But No Source

[Michael Freeman]

The LaCie Silverscreen external hard drive / media player contains a
~4 MByte ROMFS image that has a gzipped Linux kernel, Busybox, and a
few other assorted things.  However, LaCie makes no mention of using
GPLed software, nor do they offer any source code for download.  Has
anyone ever noticed this before (and, if so, what's the status on
source)?
You can download this firmware from
http://www.lacie.com/download/drivers/SilverScreen.zip -- the file
called romfs.bin is a plain romfs volume.  I successfully mounted it
using Knoppix and was able to browse the contents of the image.

Please CC me directly, because I'm not subscribed to this list. 

I apologize if this was discovered before, but my archive searches
found no reference.

(if I had the source, I'd probably buy one of these things).

--Michael L. Freeman
-
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: AMD64 Machine hardlocks when using memset

[Paul Jackson]

Robert wrote:
> It does run visibly slower

The x86_64 memset(), both in user space and the kernel, for whatever gcc
I have, and for a current kernel, uses the "repz stos" or "rep stosq"
prefixed instruction for the bulk of the copy.  This combination is a
long running, interruptible Intel string instruction that loops on
itself until the CX register decrements to zero.

Was your windows app using "stos"?

I'll wager a nickel that the actual crash you see comes when the
processor has to handle an interrupt while in the middle of this
instruction.

I'll wager a dime it's hardware, though interrupt activity may be
required to provoke it.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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] sched: improve pinned task handling again!

[Siddha, Suresh B]

On Sat, Apr 02, 2005 at 01:11:20PM +1000, Nick Piggin wrote:
> How important is this? Any application to real workloads? Even if
> not, I agree it would be nice to improve this more. I don't know
> if I really like this approach - I guess due to what it adds to
> fastpaths.

Ken initially observed with older kernels(2.4 kernel with Ingo's sched), it was 
happening with few hundred processes. 2.6 is not that bad and it improved
with recent fixes. It is not very important. We want to raise the flag
and see if we can comeup with a decent solution.

We changed nr_running from "unsigned long" to "unsigned int". So on 64-bit
architectures, our change to fastpath is not a big deal.

> 
> Now presumably if the all_pinned logic is working properly in the
> first place, and it is correctly causing balancing to back-off, you
> could tweak that a bit to avoid livelocks? Perhaps the all_pinned
> case should back off faster than the usual doubling of the interval,
> and be allowed to exceed max_interval?

Coming up with that number(how much to exceed) will be a big task. It depends
on number of cpus and how fast they traverse the runqueue,...

thanks,
suresh
-
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: PCI: fix an oops in some pci devices on hotplug remove when their resources are being freed.

[Greg KH]

On Sat, Apr 02, 2005 at 04:53:30AM +0100, Matthew Wilcox wrote:
> 
> So yes, please revert this patch.  There is no way it can possibly
> affect anything.

Agreed.  It's now reverted and is queued for Linus to pull from.

Thanks for reviewing this.

greg k-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] sched: remove unnecessary sched domains

[Nick Piggin]

Siddha, Suresh B wrote:
On Sat, Apr 02, 2005 at 12:07:27PM +1000, Nick Piggin wrote:
I was thinking we could fix that by running balance on fork/exec multiple
times from top to bottom level domains. I'll have to measure the cost of
doing that, because it may be worthwhile.

Agreed.
BTW, why are we setting SD_BALANCE_FORK flag for NUMA domain on i386, ia64.
This should be set only on x86_64 and that too not for Intel systems.
Mainly to see whether anyone reports regressions, and to exercise
the code a bit.
--
SUSE Labs, Novell Inc.
-
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: PCI: fix an oops in some pci devices on hotplug remove when their resources are being freed.

[Matthew Wilcox]

On Fri, Apr 01, 2005 at 07:31:41PM -0800, Greg KH wrote:
> I agree.  However, SGI seems to have some majorly 
> hardware and drivers that cause this line to release a already released
> resource.  See the other part of this patch for the part where this
> resource is supposedly freed up.

That one's even more stupid:

+++ b/kernel/resource.c 2005-04-01 15:37:58 -08:00
@@ -505,6 +505,7 @@
*p = res->sibling;
write_unlock(_lock);
kfree(res);
+   res = NULL;
return;
}
p = >sibling;

This pointer is a local variable!  Setting it to null right before return
cannot possibly affect anything.

> I took the patch as it doesn't hurt anyone, and it gets them off of my
> back.  But if you so much as think this patch isn't needed, I'll gladly
> revert it, as I'm really not trusting any PCI hotplug patches coming out
> from them anymore...

I think the problem is that they have a majorly hacked tree they're
working from as well as some quite inexperienced people working on it.
They need to do more internal peer review ... and clearly I need to
start reviewing their patches more carefully.

So yes, please revert this patch.  There is no way it can possibly
affect anything.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain
-
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.12-rc1-mm3

[Reuben Farrelly]

Hi Dmitry and others,
At 06:41 a.m. 31/03/2005, Dmitry Torokhov wrote:
On Monday 28 March 2005 06:02, Russell King wrote:
> Looks like something in the input layer went bang.  The code in
> serport_ldisc_write_wakeup is:
>
>0:   8b 80 a8 09 00 00   mov0x9a8(%eax),%eax
>6:   8b 40 14mov0x14(%eax),%eax
>9:   8b 50 70mov0x70(%eax),%edx <
>c:   85 d2   test   %edx,%edx
>e:   74 09   je 0x19
>
> and the marked line exploded on you.  The above instructions correspond
> with:
>
> 0:  struct serport *sp = (struct serport *) tty->disc_data;
> 6:  serio_drv_write_wakeup(sp->serio);
> 9:  if (serio->drv
>
> So, "serio" was this strange 0xf3a6cdf8 value.  But why?  One for the
> input people I think.
Reuben, could you please try the patch below? Thanks!
Russell, could you please tell me if ldisc->write_wakeup (tty_wakwup) and
ldisc->read are allowed to be called from an IRQ context? IOW I wonder if
I can use spil_lock_bh instead of spil_lock_irqsave to protect serport
flags.
--
Dmitry
 serport.c |   98 
+++---
 1 files changed, 68 insertions(+), 30 deletions(-)

Index: dtor/drivers/input/serio/serport.c
===
--- dtor.orig/drivers/input/serio/serport.c
+++ dtor/drivers/input/serio/serport.c
@@ -27,11 +27,15 @@ MODULE_LICENSE("GPL");
 MODULE_ALIAS_LDISC(N_MOUSE);

I've done some testing this afternoon and it seems that this patch 
fixes the problem in -mm4.  I don't even have a serial 
mouse/keyboard, but do have a serial PCI card onboard.  The box has a 
USB connection to a Belkin KVM instead of directly attached input devices.

I also note that it is occurring on kernel-smp-2.6.11-1.1219_FC4 - so 
it is probably a problem in mainline as well as -mm.

Now I'm crashing a bit further through the shutdown, here's the stacktrace:
INIT: Sending processes the TERM signal
Stopping yum:  Disabling nightly yum update: [  OK  ]
[  OK  ]
Stopping cups-config-daemon: [  OK  ]
Stopping HAL daemon: [  OK  ]
Stopping system message bus: [  OK  ]
Stopping atd: [  OK  ]
Stopping cups: [  OK  ]
Shutting down xfs: [  OK  ]
[  OK  ] down console mouse services: [  OK  ]
Shutting down NFS mountd: [  OK  ]
Shutting down NFS daemon: nfsd: last server has exited
nfsd: unexporting all filesystems
RPC: error 5 connecting to server localhost
RPC: failed to contact portmap (errno -5).
Unable to handle kernel paging request at virtual address f2826d2c
 printing eip:
c01337a9
*pde = 
Oops:  [#1]
SMP DEBUG_PAGEALLOC
Modules linked in: nfsd exportfs md5 ipv6 lp snd_usb_audio 
snd_usb_lib pwc video
dev usb_storage autofs4 eeprom lm85 i2c_sensor rfcomm l2cap bluetooth nfs lockd
sunrpc dm_mod video button battery ac ohci1394 ieee1394 uhci_hcd 
ehci_hcd parpor
t_serial parport_pc parport hw_random i2c_i801 i2c_core emu10k1_gp 
gameport snd_
emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm_oss 
snd_mixer_oss snd_
pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore 
e100 mii flopp
y ext3 jbd ata_piix libata sd_mod scsi_mod
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010087   (2.6.12-rc1-mm4)
EIP is at worker_thread+0x149/0x230
eax: 0001   ebx: 0212   ecx: f7eb4018   edx: f2826d20
esi: f2826d24   edi: f7eb4000   ebp:    esp: f7e83f7c
ds: 007b   es: 007b   ss: 0068
Process events/0 (pid: 8, threadinfo=f7e83000 task=f7fefad0)
Stack: f7eb4028 f7eb4010 f7eb4018 f7e83000 f2826d20 c014f4b0 0001 
   000f41fa 0001   f7fefad0 c011ea50 00100100 00200200
     fffc f7e46f54 f7eb4000 c0133660 c0137694 
Call Trace:
 [] cache_reap+0x0/0x240
 [] default_wake_function+0x0/0x10
 [] worker_thread+0x0/0x230
 [] kthread+0x94/0xa0
 [] kthread+0x0/0xa0
 [] kernel_thread_helper+0x5/0x10
Code: 00 00 89 f8 e8 19 e3 1e 00 89 c3 8b 47 40 40 89 47 40 83 f8 03 
0f 8f bd 00
 00 00 8b 77 10 3b 74 24 04 74 71 8d 56 fc 89 54 24 10 <8b> 42 0c 89 
44 24 14 8b
 6a 10 8b 46 04 8b 16 89 10 89 36 89 42
 [  OK  ]
Shutting down NFS quotas: [FAILED]
Shutting down NFS services:  [  OK  ]
Stopping sshd: [  OK  ]
Stopping postfix:  Shutting down postfix: <3>BUG: soft lockup 
detected on CPU#0!

Pid: 3413, comm:  rpc.rquotad
EIP: 0060:[] CPU: 0
EIP is at _spin_lock_irqsave+0x20/0x50
 EFLAGS: 0286Not tainted  (2.6.12-rc1-mm4)
EAX: f7eb4000 EBX: 0246 ECX: f7eb4000 EDX: c22021a0
ESI: f7eb4000 EDI: c22021a0 EBP: c01335b0 DS: 007b ES: 007b
CR0: 8005003b CR2: 800147fc CR3: 37256d20 CR4: 06e0
 [] __queue_work+0xc/0x50
 [] run_timer_softirq+0xd7/0x1c0
 [] __do_softirq+0x80/0x100
 [] do_softirq+0x4b/0x50
 ===
 [] apic_timer_interrupt+0x1c/0x30
 [] kfree_skbmem+0x8/0x20
 [] cpufreq_governor+0x3b/0x50
 [] kfree+0x62/0x90
 [] kfree_skbmem+0x8/0x20
 [] __kfree_skb+0xdc/0x1a0
 [] netlink_recvmsg+0xf1/0x230
 [] 

Re: PCI: fix an oops in some pci devices on hotplug remove when their resources are being freed.

[Greg KH]

On Sat, Apr 02, 2005 at 02:10:23AM +0100, Matthew Wilcox wrote:
> On Fri, Apr 01, 2005 at 03:47:50PM -0800, Greg KH wrote:
> > PCI: fix an oops in some pci devices on hotplug remove when their resources 
> > are being freed.
> > 
> > As reported by Prarit Bhargava <[EMAIL PROTECTED]>
> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> > 
> > diff -Nru a/drivers/pci/remove.c b/drivers/pci/remove.c
> > for (i = 0; i < PCI_NUM_RESOURCES; i++) {
> > struct resource *res = dev->resource + i;
> > -   if (res->parent)
> > +   if (res && res->parent)
> > release_resource(res);
> 
> I can't believe this fixes anything.  How can res possibly be NULL here?
> It's a pointer into a pci_dev.

I agree.  However, SGI seems to have some majorly 
hardware and drivers that cause this line to release a already released
resource.  See the other part of this patch for the part where this
resource is supposedly freed up.

I took the patch as it doesn't hurt anyone, and it gets them off of my
back.  But if you so much as think this patch isn't needed, I'll gladly
revert it, as I'm really not trusting any PCI hotplug patches coming out
from them anymore...

thanks,

greg k-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] sched: remove unnecessary sched domains

[Siddha, Suresh B]

On Sat, Apr 02, 2005 at 12:07:27PM +1000, Nick Piggin wrote:
> Siddha, Suresh B wrote:
> > Appended patch removes the unnecessary scheduler domains(containing
> > only one sched group) setup during the sched-domain init.
> > 
> > For example on x86_64, we always have NUMA configured in. On Intel EM64T
> > systems, top most sched domain will be of NUMA and with only one 
> > sched_group in
> > it. 
> > 
> > With fork/exec balances(recent Nick's fixes in -mm tree), we always endup 
> > taking wrong decisions because of this topmost domain (as it contains only 
> > one group and find_idlest_group always returns NULL). We will endup loading 
> > HT package completely first, letting active load balance kickin and correct 
> > it.
> > 
> > In general, this patch also makes sense with out recent Nick's fixes
> > in -mm.
> > 
> 
> Yeah, this makes sense. We may want to add some other criteria on the
> removal of a domain as well (because some of the domain flags do things
> that don't use groups).
> 
> I don't like so much that we'd rely on it to fix the above problem.
> There are a general class of problems with the fork/exec balancing in
> that it only works on the top most domain, so it may not spread load over
> lower domains very well.
> 
> I was thinking we could fix that by running balance on fork/exec multiple
> times from top to bottom level domains. I'll have to measure the cost of
> doing that, because it may be worthwhile.

Agreed.

BTW, why are we setting SD_BALANCE_FORK flag for NUMA domain on i386, ia64.
This should be set only on x86_64 and that too not for Intel systems.

thanks,
suresh
-
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][rfc] optimise resched, idle task

[Nick Piggin]

Haven't finished (hardly started) the arch code for this yet (and probably
broke ppc64), so it is just an RFC at this stage.
The large CC list is because it is a reasonably big change, so I hope one
or two of you smart guys can see if it looks sound before I try to tackle
the rest of the arch code and start asking for testers.
This actually improves performance noticably (ie. a % or so) on schedule /
wakeup happy benchmarks (tbench, on a dual Xeon with HT using mwait idle).
--
SUSE Labs, Novell Inc.
Make some changes to the NEED_RESCHED and POLLING_NRFLAG to reduce
confusion, and make their semantics rigid. Also have preempt explicitly
disabled in idle routines. Improves efficiency of resched_task and some
cpu_idle routines.

* In resched_task:
- TIF_NEED_RESCHED is only cleared with the task's runqueue lock held,
  and as we hold it during resched_task, then there is no need for an
  atomic test and set there. (The only time this may prevent an IPI is
  when the task's quantum expires in the timer interrupt - this is a
  very rare race to bother with in comparison with the cost).

- If TIF_NEED_RESCHED is set, then we don't need to do anything. It
  won't get unset until the task get's schedule()d off.

- If we are running on the same CPU as the task we resched, then set
  TIF_NEED_RESCHED and no further action is required.

- If we are running on another CPU, and TIF_POLLING_NRFLAG is *not* set
  after TIF_NEED_RESCHED has been set, then we need to send an IPI.

Using these rules, we are able to remove the test and set operation in
resched_task, and make clear the previously vague semantics of POLLING_NRFLAG.

* In idle routines:
- Enter cpu_idle with preempt disabled. When the need_resched() condition
  becomes true, explicitly call schedule(). This makes things a bit clearer
  (IMO), but haven't updated all architectures yet.

- Many do a test and clear of TIF_NEED_RESCHED for some reason. According
  to the resched_task rules, this isn't needed (and actually breaks the
  assumption that TIF_NEED_RESCHED is only cleared with the runqueue lock
  held). So remove that. Generally one less locked memory op when switching
  to the idle thread.

- Many idle routines clear TIF_POLLING_NRFLAG, and only set it in the inner
  most polling idle loops. The above resched_task semantics allow it to be
  set until before the last time need_resched() is checked before going into
  a halt requiring interrupt wakeup.

  Many idle routines simply never enter such a halt, and so POLLING_NRFLAG
  can be always left set, completely eliminating resched IPIs when rescheduling
  the idle task.

  POLLING_NRFLAG width can be increased, to reduce the chance of resched IPIs.

Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c   2005-03-27 00:25:49.0 +1100
+++ linux-2.6/kernel/sched.c2005-03-27 00:27:30.0 +1100
@@ -796,21 +796,28 @@ static void deactivate_task(struct task_
 #ifdef CONFIG_SMP
 static void resched_task(task_t *p)
 {
-   int need_resched, nrpolling;
+   int cpu;
 
assert_spin_locked(_rq(p)->lock);
 
-   /* minimise the chance of sending an interrupt to poll_idle() */
-   nrpolling = test_tsk_thread_flag(p,TIF_POLLING_NRFLAG);
-   need_resched = test_and_set_tsk_thread_flag(p,TIF_NEED_RESCHED);
-   nrpolling |= test_tsk_thread_flag(p,TIF_POLLING_NRFLAG);
+   if (test_tsk_thread_flag(p, TIF_NEED_RESCHED))
+   return;
+   
+   set_tsk_thread_flag(p, TIF_NEED_RESCHED);
 
-   if (!need_resched && !nrpolling && (task_cpu(p) != smp_processor_id()))
-   smp_send_reschedule(task_cpu(p));
+   cpu = task_cpu(p);
+   if (cpu == smp_processor_id())
+   return;
+
+   /* NEED_RESCHED must be visible before we test POLLING_NRFLAG */
+   smp_mb();
+   if (!test_tsk_thread_flag(p, TIF_POLLING_NRFLAG))
+   smp_send_reschedule(cpu);
 }
 #else
 static inline void resched_task(task_t *p)
 {
+   assert_spin_locked(_rq(p)->lock);
set_tsk_need_resched(p);
 }
 #endif
Index: linux-2.6/arch/i386/kernel/process.c
===
--- linux-2.6.orig/arch/i386/kernel/process.c   2005-03-27 00:25:49.0 
+1100
+++ linux-2.6/arch/i386/kernel/process.c2005-03-27 00:27:30.0 
+1100
@@ -95,14 +95,19 @@ EXPORT_SYMBOL(enable_hlt);
  */
 void default_idle(void)
 {
+   local_irq_enable();
+
if (!hlt_counter && boot_cpu_data.hlt_works_ok) {
-   local_irq_disable();
-   if (!need_resched())
+   clear_thread_flag(TIF_POLLING_NRFLAG);
+   smp_mb__after_clear_bit();
+   while (!need_resched()) {
+   local_irq_disable();
safe_halt();
-   else
-   local_irq_enable();
+   }
+   

Re: initramfs linus tree breakage in last day

[Jon Smirl]

This is what I see on boot.

-- 
Jon Smirl
[EMAIL PROTECTED]

Linux version 2.6.12-rc1 ([EMAIL PROTECTED]) (gcc version
3.4.2 200410
17 (Red Hat 3.4.2-6.fc3)) #21 SMP Fri Apr 1 22:09:28 EST 2005
BIOS-provided physical RAM map:   
 BIOS-e820:  - 000a (usable)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 3ff74000 (usable)
 BIOS-e820: 3ff74000 - 3ff76000 (ACPI NVS)
 BIOS-e820: 3ff76000 - 3ff97000 (ACPI data)
 BIOS-e820: 3ff97000 - 4000 (
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fecf - fecf1000 (reserved)
 BIOS-e820: fed2 - fed9 (reserved)
 BIOS-e820: fee0 - fee1 (reserved)
 BIOS-e820: ffb0 - 0001 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.   
found SMP MP-table at 000fe710  
DMI 2.3 present.
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20 
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01]   
Processor #1 15:2 APIC version 20 
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] disabled)
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 4000
Built 1 zonelists 
Kernel command line: ro root=LABEL=/  console=ttyS0,115200n8
Initializing CPU#0  
CPU 0 irqstacks, hard=c03ad000 soft=c03ab000
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 2793.105 MHz processor.
Using tsc for high-res timesource 
Console: colour VGA+ 80x25  
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1034920k/1048016k available (1567k kernel code, 12372k
reserved, 955k da
ta, 184k init, 130
Checking if this processor honours the WP bit even in supervisor
mode... Ok.
Security Framework v1.0.0 initialized 
Mount-cache hash table entries: 512   
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K   
CPU: Physical Processor ID: 0 
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09
Booting processor 1/1 eip 3000
CPU 1 irqstacks, hard=c03ae000 soft=c03ac000
Initializing CPU#1
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09
Total of 2 processors activated (11091.96 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
checking if image is initramfs... it is
Freeing initrd memory: 318k freed
-
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] cleanup context switch locking

[Nick Piggin]

This went to linux-arch, but didn't get much response. Dave Miller
thought it looked fine, although I guess this was probably "in
concept" rather than a detailed review.
Andrew, would you care to put it in -mm, or would you rather we get
through the current scheduler patches first? (Note that this patch
is completely seperate to them, and shouldn't change behaviour nor
cause many patch conflicts, I hope).
Been tested on a few things, i386, x86-64, sparc64, ia64.
--
SUSE Labs, Novell Inc.
Instead of requiring architecture code to interact with the scheduler's
locking implementation, provide a couple of defines that can be used by
the architecture to request runqueue unlocked context switches, and ask
for interrupts to be enabled over the context switch.

Also replaces the "switch_lock" used by these architectures with an oncpu
flag (note, not a potentially slow bitflag). This eliminates one bus locked
memory operation when context switching, and simplifies the task_running
function.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c   2005-03-27 13:03:55.0 +1000
+++ linux-2.6/kernel/sched.c2005-03-27 13:04:10.0 +1000
@@ -269,14 +269,71 @@ static DEFINE_PER_CPU(struct runqueue, r
 #define task_rq(p) cpu_rq(task_cpu(p))
 #define cpu_curr(cpu)  (cpu_rq(cpu)->curr)
 
-/*
- * Default context-switch locking:
- */
 #ifndef prepare_arch_switch
-# define prepare_arch_switch(rq, next) do { } while (0)
-# define finish_arch_switch(rq, next)  spin_unlock_irq(&(rq)->lock)
-# define task_running(rq, p)   ((rq)->curr == (p))
+# define prepare_arch_switch(next) do { } while (0)
+#endif
+#ifndef finish_arch_switch
+# define finish_arch_switch(prev)  do { } while (0)
+#endif
+
+#ifndef __ARCH_WANT_UNLOCKED_CTXSW
+static inline int task_running(runqueue_t *rq, task_t *p)
+{
+   return rq->curr == p;
+}
+
+static inline void prepare_lock_switch(runqueue_t *rq, task_t *next)
+{
+}
+
+static inline void finish_lock_switch(runqueue_t *rq, task_t *prev)
+{
+   spin_unlock_irq(>lock);
+}
+
+#else /* __ARCH_WANT_UNLOCKED_CTXSW */
+static inline int task_running(runqueue_t *rq, task_t *p)
+{
+#ifdef CONFIG_SMP
+   return p->oncpu;
+#else
+   return rq->curr == p;
+#endif
+}
+
+static inline void prepare_lock_switch(runqueue_t *rq, task_t *next)
+{
+#ifdef CONFIG_SMP
+   /*
+* We can optimise this out completely for !SMP, because the
+* SMP rebalancing from interrupt is the only thing that cares
+* here.
+*/
+   next->oncpu = 1;
+#endif
+#ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
+   spin_unlock_irq(>lock);
+#else
+   spin_unlock(>lock);
 #endif
+}
+
+static inline void finish_lock_switch(runqueue_t *rq, task_t *prev)
+{
+#ifdef CONFIG_SMP
+   /*
+* After ->oncpu is cleared, the task can be moved to a different CPU.
+* We must ensure this doesn't happen until the switch is completely
+* finished.
+*/
+   smp_wmb();
+   prev->oncpu = 0;
+#endif
+#ifndef __ARCH_WANT_INTERRUPTS_ON_CTXSW
+   local_irq_enable();
+#endif
+}
+#endif /* __ARCH_WANT_UNLOCKED_CTXSW */
 
 /*
  * task_rq_lock - lock the runqueue a given task resides on and disable
@@ -1197,17 +1254,14 @@ void fastcall sched_fork(task_t *p)
p->state = TASK_RUNNING;
INIT_LIST_HEAD(>run_list);
p->array = NULL;
-   spin_lock_init(>switch_lock);
 #ifdef CONFIG_SCHEDSTATS
memset(>sched_info, 0, sizeof(p->sched_info));
 #endif
+#if defined(CONFIG_SMP) && defined(__ARCH_WANT_UNLOCKED_CTXSW)
+   p->oncpu = 0;
+#endif
 #ifdef CONFIG_PREEMPT
-   /*
-* During context-switch we hold precisely one spinlock, which
-* schedule_tail drops. (in the common case it's this_rq()->lock,
-* but it also can be p->switch_lock.) So we compensate with a count
-* of 1. Also, we want to start with kernel preemption disabled.
-*/
+   /* Want to start with kernel preemption disabled. */
p->thread_info->preempt_count = 1;
 #endif
/*
@@ -1389,22 +1443,40 @@ void fastcall sched_exit(task_t * p)
 }
 
 /**
+ * prepare_task_switch - prepare to switch tasks
+ * @rq: the runqueue preparing to switch
+ * @next: the task we are going to switch to.
+ *
+ * This is called with the rq lock held and interrupts off. It must
+ * be paired with a subsequent finish_task_switch after the context
+ * switch.
+ *
+ * prepare_task_switch sets up locking and calls architecture specific
+ * hooks.
+ */
+static inline void prepare_task_switch(runqueue_t *rq, task_t *next)
+{
+   prepare_lock_switch(rq, next);
+   prepare_arch_switch(next);
+}
+
+/**
  * finish_task_switch - clean up after a task-switch
  * @prev: the thread we just switched away from.
  *
- * We enter this with the runqueue still locked, and finish_arch_switch()
- 

Re: [patch] sched: improve pinned task handling again!

[Nick Piggin]

Siddha, Suresh B wrote:
This time Ken Chen brought up this issue -- No it has nothing to do with 
industry db benchmark ;-) 

Even with the above mentioned Nick's patch in -mm, I see system livelock's 
if for example I have 7000 processes pinned onto one cpu (this is on the 
fastest 8-way system I have access to). I am sure there will be other 
systems where this problem can be encountered even with lesser pin count.

Thanks for testing these patches in -mm, by the way.
We tried to fix this issue but as you know there is no good mechanism
in fixing this issue with out letting the regular paths know about this.
Our proposed solution is appended and we tried to minimize the affect on 
fast path.  It builds up on Nick's patch and once this situation is detected,
it will not do any more move_tasks as long as busiest cpu is always the 
same cpu and the queued processes on busiest_cpu, their
cpu affinity remain same(found out by runqueue's "generation_num")

7000 running processes pinned into one CPU. I guess that isn't a
great deal :(
How important is this? Any application to real workloads? Even if
not, I agree it would be nice to improve this more. I don't know
if I really like this approach - I guess due to what it adds to
fastpaths.
Now presumably if the all_pinned logic is working properly in the
first place, and it is correctly causing balancing to back-off, you
could tweak that a bit to avoid livelocks? Perhaps the all_pinned
case should back off faster than the usual doubling of the interval,
and be allowed to exceed max_interval?
Any thoughts Ingo?
--
SUSE Labs, Novell Inc.
-
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] sched: improve pinned task handling again!

[Siddha, Suresh B]

On  Wednesday, February 23, 2005 11:17 PM Nick Piggin wrote:
>John Hawkes explained the problem best:
>  A large number of processes that are pinned to a single CPU results
>  in every other CPU's load_balance() seeing this overloaded CPU as
>  "busiest", yet move_tasks() never finds a task to pull-migrate.  This
>  condition occurs during module unload, but can also occur as a
>  denial-of-service using sys_sched_setaffinity().  Several hundred
>  CPUs performing this fruitless load_balance() will livelock on the
>  busiest CPU's runqueue lock.  A smaller number of CPUs will livelock
>  if the pinned task count gets high.
>   
>Expanding slightly on John's patch, this one attempts to work out
>whether the balancing failure has been due to too many tasks pinned
>on the runqueue. This allows it to be basically invisible to the
>regular blancing paths (ie. when there are no pinned tasks). We can
>use this extra knowledge to shut down the balancing faster, and ensure
>the migration threads don't start running which is another problem
>observed in the wild.

This time Ken Chen brought up this issue -- No it has nothing to do with 
industry db benchmark ;-) 

Even with the above mentioned Nick's patch in -mm, I see system livelock's 
if for example I have 7000 processes pinned onto one cpu (this is on the 
fastest 8-way system I have access to). I am sure there will be other 
systems where this problem can be encountered even with lesser pin count.

We tried to fix this issue but as you know there is no good mechanism
in fixing this issue with out letting the regular paths know about this.

Our proposed solution is appended and we tried to minimize the affect on 
fast path.  It builds up on Nick's patch and once this situation is detected,
it will not do any more move_tasks as long as busiest cpu is always the 
same cpu and the queued processes on busiest_cpu, their
cpu affinity remain same(found out by runqueue's "generation_num")

Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>


--- linux-2.6.12-rc1-mm4/kernel/sched.c 2005-04-01 10:07:24.183605296 -0800
+++ linux/kernel/sched.c2005-04-01 18:40:21.120799664 -0800
@@ -205,9 +205,16 @@
/*
 * nr_running and cpu_load should be in the same cacheline because
 * remote CPUs use both these fields when doing load calculation.
+* generation_num also needs to be in the same cacheline as nr_running.
 */
-   unsigned long nr_running;
+   unsigned int nr_running;
 #ifdef CONFIG_SMP
+   /*
+* generation_num gets incremented in the following cases
+*  - a process moves to this runqueue
+*  - cpu affinity of a process on this runqueue is changed
+*/
+   unsigned int generation_num;
unsigned long cpu_load[3];
 #endif
unsigned long long nr_switches;
@@ -237,6 +244,8 @@
 
task_t *migration_thread;
struct list_head migration_queue;
+   runqueue_t *busiest_rq;
+   unsigned int busiest_generation_num;
 #endif
 
 #ifdef CONFIG_SCHEDSTATS
@@ -598,6 +607,9 @@
 {
enqueue_task(p, rq->active);
rq->nr_running++;
+#ifdef CONFIG_SMP
+   rq->generation_num++;
+#endif
 }
 
 /*
@@ -1670,6 +1682,7 @@
src_rq->nr_running--;
set_task_cpu(p, this_cpu);
this_rq->nr_running++;
+   this_rq->generation_num++;
enqueue_task(p, this_array);
p->timestamp = (p->timestamp - src_rq->timestamp_last_tick)
+ this_rq->timestamp_last_tick;
@@ -1998,6 +2011,14 @@
 
schedstat_add(sd, lb_imbalance[idle], imbalance);
 
+   /* if all tasks on busiest_cpu were pinned and can't be moved to 
+* this_cpu and from our last load_balance, there is no
+* changes to busiest_cpu's generation_num, then we are balanced
+*/ 
+   if (unlikely(this_rq->busiest_rq == busiest && 
+this_rq->busiest_generation_num == 
busiest->generation_num))
+   goto out_balanced;
+   
nr_moved = 0;
if (busiest->nr_running > 1) {
/*
@@ -2013,8 +2034,12 @@
spin_unlock(>lock);
 
/* All tasks on this runqueue were pinned by CPU affinity */
-   if (unlikely(all_pinned))
+   if (unlikely(all_pinned)) {
+   this_rq->busiest_rq = busiest;
+   this_rq->busiest_generation_num = 
busiest->generation_num;
goto out_balanced;
+   } else
+   this_rq->busiest_rq = NULL;
}
 
spin_unlock(_rq->lock);
@@ -4146,8 +4171,10 @@
 
p->cpus_allowed = new_mask;
/* Can the task run on the task's current CPU? If so, we're done */
-   if (cpu_isset(task_cpu(p), new_mask))
+   if (cpu_isset(task_cpu(p), new_mask)) {
+   rq->generation_num++;
goto out;
+   }
 
  

Re: Industry db benchmark result on recent 2.6 kernels

[Paul Jackson]

Kenneth wrote:
> I recommend buying the following:

ah so ... I think I'll skip running the industry db benchmark
for now, if that's all the same.

What sort of feedback are you looking for from my running this
patch?

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: AMD64 Machine hardlocks when using memset

[Robert Hancock]

Ray Lee wrote:
On Thu, 2005-03-31 at 22:37 -0600, Robert Hancock wrote:
This is getting pretty ridiculous.. I've tried memory timings down to 
the slowest possible, ran Memtest86 for 4 passes with no errors, and 
it's been stable in Windows for a few months now. Still something is 
blowing up in Linux with this test though..

Have you run the same memset test under windows?
I've traced a lot of oddball problems down to bad or marginal power
supplies.
I've now built a similar test program for Windows. I've let it run over 
2000 iterations of 512MB memsets with no problems. On Linux it usually 
blew up with under 200 iterations. It does run visibly slower than the 
Linux version though - this is after all 32 bit Windows and it was 
compiled with crufty old Visual C++ 6.0 so it is probably not that 
optimized for this CPU. I will see if I can get a more optimized build 
of this to try in Mingw32 or something.. after all if it's related to 
some instruction combination or something it may not show up in the 
build I have.

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

Re: 2.6.12-rc1 won't boot if SCSI drivers are selected as modules

[Jon Smirl]

On Apr 1, 2005 7:17 AM, K.R. Foley <[EMAIL PROTECTED]> wrote:
> I have an old Dell Precision 620 workstation with dual PIII 933's and
> 512 Mb memory. It also uses AIC-7899P U160/m SCSI controllers with one
> U160 drive (boot drive) and one slower 18 Gb. I have been running many
> different variants of the kernel on this system for quite some time with
> much success. However, no amount of gnashing of teeth or pulling of hair
> have been able to get this system to boot ANY 2.6.12-rc1 (including
> 2.6.12-rc1 vanilla, 2.6.12-rc1-mm3 and various RT patches) variant when
> the SCSI drivers are selected as modules (which is the way that I have
> always done it). Last night I built all of the necessary drivers into
> the kernel and the system boots fine.

I am also seeing this but not on every boot. My work around is to add
a 'sleep 2' to the nash script after the modules are loaded. Compling
everything in also worked.

This is discussed in the thread: "current linus bk, error mounting
root". I believe the answer is that it is not a kernel problem,
instead the init scripts have to be fixed.

-- 
Jon Smirl
[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] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00

[Gene Heskett]

On Friday 01 April 2005 20:45, Lee Revell wrote:
>On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote:
>> No one has commented about the loss of video in the
>> tvtime/pcHDTV-3000 card situation, am I on my own, basicly
>> reverting to the
>> pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff?
>
>You didn't really give much of a clue as to where to start looking.
>
>If you report a bug of the "hardware foo stopped working with kernel
>bar" type, and that's all the information you provide, the bug
> report is useless to anyone who does not have the exact same
> hardware.
>
>Lee

I did, in a previous incarnation of this thread 2-3 days ago, post the 
lsmod output and a section of the log showing (I believe) rampant dma 
failures.  It also didn't generate any comments.

FWIW, I have reinstalled the tarballs version of the drivers, but that 
was of no use, so its definitely something in the RT patch itself I 
believe.  2.6.12-rc1 works great.  By default.

As far as my being able to fix that, I'm afraid I'll have to plead 
NDI.  The last time I dealt with dma, was on an rca 1802 cpu, which 
had its own builtin dma controller that took care of everything but 
the pointer reload for the next 6 byte fetch, and which I used for 6 
bytes per field of video to feed a homebrewed character generator I 
made out of ttl chips, to generate the academy leader on a 
commercial.  The year was 1978.  A bit far back up the log for even 
me, altho I may still have a copy of the machine code I wrote that 
ran it at KRCR-TV in Redding CA for a decade that I know of, maybe 
longer.

That is neither here nor there now of course, just shining a light 
back up the calendar about 27 years for illustration.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
-
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: Industry db benchmark result on recent 2.6 kernels

[Nick Piggin]

Linus Torvalds wrote:
On Fri, 1 Apr 2005, Chen, Kenneth W wrote:
Paul, you definitely want to check this out on your large numa box.  I booted
a kernel with this patch on a 32-way numa box and it took a long  time
to produce the cost matrix.

Is there anything fundamentally wrong with the notion of just initializing
the cost matrix to something that isn't completely wrong at bootup, and
just lettign user space fill it in?
That's probably not a bad idea. You'd have to do things like
set RT scheduling for your user tasks, and not have any other
activity happening. So that effectively hangs your system for
a while anyway.
But if you run it once and dump the output to a config file...
Anyway we're faced with the immediate problem of crap performance
for 2.6.12 (for people with 1500 disks), so an in-kernel solution
might be better in the short term. I'll see if we can adapt Ingo's
thingy with something that is "good enough" and doesn't take years
to run on a 512 way.
Nick
--
SUSE Labs, Novell Inc.
-
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/

initramfs linus tree breakage in last day

[Jon Smirl]

When I boot the kernel is mistaking my initrd as an initramfs. Of
course this doesn't work. This broke in the last 24hrs on the linus bk
tree. I am using an up2date Fedora Core 3. Booting older kernels still
works.


-- 
Jon Smirl
[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: Can't use SYSFS for "Proprietry" driver modules !!!.

[David Schwartz]

> On Tue, Mar 29, 2005 at 11:00:30AM -0800, David Schwartz wrote:

> > Since the GPL permits their removal, removing them cannot
> > be circumventing
> > the GPL. Since the GPL is the only license and the license
> > permits you to
> > remove them, they cannot be a license enforcement mechanism. How can you
> > enforce a license that permits unrestricted functional modification?

> You misunderstand totally the EXPORT_GPL system.

No, I understand it perfectly.

> It does not mean
> "this is a technological system to prevent you to use it with non-gpl
> compatible code".

Right, which is precisely what I said. They are not a license 
enforcement
mechanism.

> It means "The author of that code consider that
> using this function makes your code so linux-specific that it must be
> a derivative work of the code implementing the function, so if you use
> it from non gpl-compatible code you'll be sued.  And since he's nice,
> he uses a technical method to prevent you from doing such a copyright
> violation by mistake.".

If the author of the code is not a lawyer, his opinion about what does 
or
does not constitute a derived work should really not be of any interest. I
do agree that this is much closer to an accurate understandinf of EXPORT_GPL
than that it's a license enforcement mechanism.

> See the subtle difference?  EXPORT_GPL is here to _help_ proprietary
> driver authors.  Your lawyers should _love_ it and skin you alive if
> you try to get around it.

Why would any competent lawyer perfer the opinion of a layperson on a
purely legal matter over his own opinion? That's totally absurd.

In any event, I wasn't talking about what EXPORT_GPL is, just about 
what it
isn't. And you seem to agree with me that it's not a license enforcement
mechanism and that you're not violating the GPL if you remove it and
distribute the results.

I hope you would further agree that the legality of distributing code 
not
under the GPL that uses EXPORT_GPL symbols hinges on whether the works
distributed actually *are* derivative works of the covered works and not on
the author's opinion. Neither the authors of GPL'd works nor the GPL can set
out the scope of the GPL's authority -- that comes from copyright law.

DS


-
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: Industry db benchmark result on recent 2.6 kernels

[Nick Piggin]

Chen, Kenneth W wrote:
Ingo Molnar wrote on Thursday, March 31, 2005 8:52 PM
the current defaults for cache_hot_time are 10 msec for NUMA domains,
and 2.5 msec for SMP domains. Clearly too low for CPUs with 9MB cache.
Are you increasing cache_hot_time in your experiment? If that solves
most of the problem that would be an easy thing to fix for 2.6.12.

Chen, Kenneth W wrote on Thursday, March 31, 2005 9:15 PM
Yes, we are increasing the number in our experiments.  It's in the queue
and I should have a result soon.

Hot of the press: bumping up cache_hot_time to 10ms on our db setup brings
2.6.11 performance on par with 2.6.9.  Theory confirmed.
OK, that's good. I'll look at whether we can easily use Ingo's
tool on the SMP domain only, to avoid the large O(n^2). That might
be an acceptable short term solution for 2.6.12.
If you get a chance to also look at those block layer patches that
would be good - if they give you a nice improvement, that would
justify getting them into -mm.
--
SUSE Labs, Novell Inc.
-
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: Industry db benchmark result on recent 2.6 kernels

[Chen, Kenneth W]

Paul Jackson wrote on Friday, April 01, 2005 5:45 PM
> Kenneth wrote:
> > Paul, you definitely want to check this out on your large numa box.
>
> Interesting - thanks.  I can get a kernel patched and booted on a big
> box easily enough.  I don't know how to run an "industry db benchmark",
> and benchmarks aren't my forte.

To run this "industry db benchmark", assuming you have a 32-way numa box,
I recommend buying the following:

512 GB memory
1500 73 GB 15k-rpm fiber channel disks
50 hardware raid controllers, make sure you get the top of the line model
   (the one has 1GB memory in the controller).
25 fiber channel controllers
4  gigabit ethernet controllers.
12 rack frames

Then you will be off to go.  Oh, get several 220 volt power outlets too,
probably some refrigeration unit will go along with that.  Sorry, I
haven't mention the mid-tier and the client machines yet.

;-)


-
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] sched: remove unnecessary sched domains

[Nick Piggin]

Siddha, Suresh B wrote:
Appended patch removes the unnecessary scheduler domains(containing
only one sched group) setup during the sched-domain init.
For example on x86_64, we always have NUMA configured in. On Intel EM64T
systems, top most sched domain will be of NUMA and with only one sched_group in
it. 

With fork/exec balances(recent Nick's fixes in -mm tree), we always endup 
taking wrong decisions because of this topmost domain (as it contains only 
one group and find_idlest_group always returns NULL). We will endup loading 
HT package completely first, letting active load balance kickin and correct it.

In general, this patch also makes sense with out recent Nick's fixes
in -mm.
Yeah, this makes sense. We may want to add some other criteria on the
removal of a domain as well (because some of the domain flags do things
that don't use groups).
I don't like so much that we'd rely on it to fix the above problem.
There are a general class of problems with the fork/exec balancing in
that it only works on the top most domain, so it may not spread load over
lower domains very well.
I was thinking we could fix that by running balance on fork/exec multiple
times from top to bottom level domains. I'll have to measure the cost of
doing that, because it may be worthwhile.
Thanks
--
SUSE Labs, Novell Inc.
-
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: Hangcheck problem

[Joseph Fannin]

On Wed, Mar 30, 2005 at 02:29:45PM -0800, Noah Silverman wrote:
> On Wed, 30 Mar 2005, Noah Silverman wrote:

> > I'm been experiencing a weird problem
> >
> > I get endlessly repeated hangcheck errors in my syslog with no
> explanation:
> >
> > Mar 30 12:41:43 db kernel: Hangcheck: hangcheck value past margin!

> Burton Windle wrote:
> > Kernel version?
> > 
> 
> 2.6.7

That's a really old kernel, and I'm sure anyone who could look
into this will ask you to upgrade to something recent and reproduce it
as the first step in tracking it down.

Is this an older box?  I've seen the hangcheck warnings on a
486 I was using as a firewall/router -- ultimately I applied a patch
to set HZ to 100 and the problem went away.  I *think*, once that patch
bitrotted, that I just turned off the hangcheck timer, but I can't
remember for sure.

   If you turn off the hangcheck timer, does the problem go away
(i.e. no more lockups)?

-- 
Joseph Fannin
[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] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00

[Lee Revell]

On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote:
> No one has commented about the loss of video in the tvtime/pcHDTV-3000 
> card situation, am I on my own, basicly reverting to the 
> pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff?

You didn't really give much of a clue as to where to start looking.  

If you report a bug of the "hardware foo stopped working with kernel
bar" type, and that's all the information you provide, the bug report is
useless to anyone who does not have the exact same hardware.

Lee

-
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: Industry db benchmark result on recent 2.6 kernels

[Paul Jackson]

Kenneth wrote:
> Paul, you definitely want to check this out on your large numa box.

Interesting - thanks.  I can get a kernel patched and booted on a big
box easily enough.  I don't know how to run an "industry db benchmark",
and benchmarks aren't my forte.

Should I rope in one of our guys who is benchmark savvy, or are there
some instructions you can point to for running an appropriate benchmark?

Or are we just interested, first of all, in what sort of values this
cost matrix gets initialized with (and how slow it is to compute)?

I can get time on a 64-cpu with a days notice, and time on a 512-cpu
with 2 or 3 days notice.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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] Direct IO async short read bug followup

[Daniel McNeil]

On Fri, 2005-04-01 at 17:27, Andrew Morton wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> >  >  --- linux-2.6.11.orig/fs/direct-io.c2005-04-01 15:33:11.0 
> > -0800
> >  >  +++ linux-2.6.11/fs/direct-io.c 2005-03-31 16:59:15.0 -0800
> >  >  @@ -66,6 +66,7 @@ struct dio {
> >  >  struct bio *bio;/* bio under assembly */
> >  >  struct inode *inode;
> >  >  int rw;
> >  >  +   ssize_t i_size; /* i_size when submitted */
> > 
> >  I'll change this to loff_t, OK?
> 
> And I think local variable `transferred' can remain ssize_t.  Agree?

Yes.

Daniel

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

[RFC] [PATCH] Set MS_ACTIVE bit before calling ->fill_super functions

[Russ Weight]

This patch changes all cases where the MS_ACTIVE bit gets set. This is
done to eliminate a race condition that can occur if an inode is
allocated and then released (using iput) during the ->fill_super
functions. The race condition is between kswapd and mount.

For most filesystems this can only happen in an error path when kswapd
is running concurrently. For isofs, however, the error can occur in a
more common code path (which is how the bug was found).

The changes are fairly straight forward. There are a couple of unique
cases:

ext3_orphan_cleanup() was setting MS_ACTIVE for the CONFIG_QUOTA case.
Since ext3_orphan_cleanup() is only called by ext3_fill_super(), this
is no longer necessary since the MS_ACTIVE will already be set.

Reiserfs:
For the CONFIG_QUOTA case, finish_unfinished() ensures that MS_ACTIVE
is set, and then conditionally turns it off depending on its initial
state.  finish_unfinished() is called by two functions: reiserfs_remount
and reiserfs_fill_super. The MS_ACTIVE flag was previously NOT set for
reiserfs_fill_super, but that has changed now - it will always be
set. The MS_ACTIVE flag is also set in the reiserfs_remount case, so
the manipulation of the MS_ACTIVE in finish_unfinished() is no longer
necessary.

Comments?

- Russ

--- linux-2.6.12-rc1/fs/afs/super.c 2005-03-17 17:34:09.0 -0800
+++ linux-2.6.12-rc1-fix2/fs/afs/super.c2005-04-01 16:31:54.803904510
-0800
@@ -339,15 +339,15 @@ static struct super_block *afs_get_sb(st
if (IS_ERR(sb))
goto error;
 
-   sb->s_flags = flags;
+   sb->s_flags = flags | MS_ACTIVE;
 
ret = afs_fill_super(sb, , flags & MS_VERBOSE ? 1 : 0);
if (ret < 0) {
+   sb->s_flags &= ~MS_ACTIVE;
up_write(>s_umount);
deactivate_super(sb);
goto error;
}
-   sb->s_flags |= MS_ACTIVE;
 
afs_put_volume(params.volume);
afs_put_cell(params.default_cell);
--- linux-2.6.12-rc1/fs/cifs/cifsfs.c   2005-03-17 17:34:13.0
-0800
+++ linux-2.6.12-rc1-fix2/fs/cifs/cifsfs.c  2005-04-01 16:14:26.0
-0800
@@ -422,15 +422,15 @@ cifs_get_sb(struct file_system_type *fs_
if (IS_ERR(sb))
return sb;
 
-   sb->s_flags = flags;
+   sb->s_flags = flags | MS_ACTIVE;
 
rc = cifs_read_super(sb, data, dev_name, flags & MS_VERBOSE ? 1 : 0);
if (rc) {
+   sb->s_flags &= ~MS_ACTIVE;
up_write(>s_umount);
deactivate_super(sb);
return ERR_PTR(rc);
}
-   sb->s_flags |= MS_ACTIVE;
return sb;
 }
 
--- linux-2.6.12-rc1/fs/ext3/super.c2005-03-17 17:34:57.0 -0800
+++ linux-2.6.12-rc1-fix2/fs/ext3/super.c   2005-04-01 16:17:05.0
-0800
@@ -1121,8 +1121,6 @@ static void ext3_orphan_cleanup (struct 
sb->s_flags &= ~MS_RDONLY;
}
 #ifdef CONFIG_QUOTA
-   /* Needed for iput() to work correctly and not trash data */
-   sb->s_flags |= MS_ACTIVE;
/* Turn on quotas so that they are updated correctly */
for (i = 0; i < MAXQUOTAS; i++) {
if (EXT3_SB(sb)->s_qf_names[i]) {
--- linux-2.6.12-rc1/fs/jffs2/super.c   2005-03-17 17:34:08.0
-0800
+++ linux-2.6.12-rc1-fix2/fs/jffs2/super.c  2005-04-01 15:41:06.0
-0800
@@ -141,18 +141,18 @@ static struct super_block *jffs2_get_sb_
  mtd->index, mtd->name));
 
sb->s_op = _super_operations;
-   sb->s_flags = flags | MS_NOATIME;
+   sb->s_flags = flags | MS_NOATIME | MS_ACTIVE;
 
ret = jffs2_do_fill_super(sb, data, (flags_VERBOSE)?1:0);
 
if (ret) {
/* Failure case... */
+   sb->s_flags &= ~MS_ACTIVE;
up_write(>s_umount);
deactivate_super(sb);
return ERR_PTR(ret);
}
 
-   sb->s_flags |= MS_ACTIVE;
return sb;
 
  out_put:
--- linux-2.6.12-rc1/fs/libfs.c 2005-03-17 17:33:48.0 -0800
+++ linux-2.6.12-rc1-fix2/fs/libfs.c2005-04-01 16:20:30.0 -0800
@@ -206,7 +206,7 @@ get_sb_pseudo(struct file_system_type *f
if (IS_ERR(s))
return s;
 
-   s->s_flags = MS_NOUSER;
+   s->s_flags = MS_NOUSER | MS_ACTIVE;
s->s_maxbytes = ~0ULL;
s->s_blocksize = 1024;
s->s_blocksize_bits = 10;
@@ -228,10 +228,10 @@ get_sb_pseudo(struct file_system_type *f
dentry->d_parent = dentry;
d_instantiate(dentry, root);
s->s_root = dentry;
-   s->s_flags |= MS_ACTIVE;
return s;
 
 Enomem:
+   s->s_flags &= ~MS_ACTIVE;
up_write(>s_umount);
deactivate_super(s);
return ERR_PTR(-ENOMEM);
--- linux-2.6.12-rc1/fs/nfs/inode.c 2005-03-17 17:34:27.0 -0800
+++ linux-2.6.12-rc1-fix2/fs/nfs/inode.c2005-04-01 15:34:39.0
-0800
@@ -1445,7 +1445,7 @@ static struct super_block *nfs_get_sb(st
return s;
  

x86 TSC time warp puzzle

[Jonathan Lundell]

Well, not actually a time warp, though it feels like one.
I'm doing some real-time bit-twiddling in a driver, using the TSC to 
measure out delays on the order of hundreds of nanoseconds. Because I 
want an upper limit on the delay, I disable interrupts around it.

The logic is something like:
local_irq_save
out(set a bit)
t0 = TSC
wait while (t = (TSC - t0)) < delay_time
out(clear the bit)
local_irq_restore
From time to time, when I exit the delay, t is *much* bigger than 
delay_time. If delay_time is, say, 300ns, t is usually no more than 
325ns. But every so often, t can be 2000, or 1, or even much 
higher.

The value of t seems to depend on the CPU involved, The worst case is 
with an Intel 915GV chipset, where t approaches 500 microseconds (!).

This is with ACPI and HT disabled, to avoid confounding interactions. 
I suspected NMI, of course, but I monitored the nmi counter, and 
mostly saw nothing (from time to time a random hit, but mostly not).

The longer delay is real. I can see the bit being set/cleared in the 
pseudocode above on a scope, and when the long delay happens, the bit 
is set for a correspondingly long time.

BTW, the symptom is independent of my IO. I wrote a test case that 
does diddles nothing but reading TSC, and get the same result.

Finally, on some CPUs, at least, the extra delay appears to be 
periodic. The 500us delay happens about every second. On a different 
machine (chipset) it happens at about 5 Hz. And the characteristic 
delay on each type of machine seems consistent.

Any ideas of where to look? Other lists to inquire on?
Thanks.
--
/Jonathan Lundell.
-
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] Direct IO async short read bug followup

[Daniel McNeil]

On Fri, 2005-04-01 at 17:20, Andrew Morton wrote:
> Daniel McNeil <[EMAIL PROTECTED]> wrote:
> >
> > I updated the patch to add an i_size element to the dio structure and
> >  sample i_size during i/o submission.  When i/o completes the result can
> >  be truncated to match the file size without using i_size_read(), thus
> >  the aio result now matches the number of bytes read to the end of file.
> > 
> 
> Can you provide the analysis of the bug, please?

The direct i/o code is mapping the read request to the file system
block.  If the file size was not on a block boundary, the result
would show the the read reading past EOF.  This was only happening
for the AIO case.  The non-AIO case truncates the result to match
file size (in direct_io_worker).  This patch does the same thing
for the AIO case, it truncates the result to match the file size
if the read reads past EOF.
> 
> > 
> >  Daniel
> > 
> >  --- linux-2.6.11.orig/fs/direct-io.c   2005-04-01 15:33:11.0 
> > -0800
> >  +++ linux-2.6.11/fs/direct-io.c2005-03-31 16:59:15.0 -0800
> >  @@ -66,6 +66,7 @@ struct dio {
> > struct bio *bio;/* bio under assembly */
> > struct inode *inode;
> > int rw;
> >  +  ssize_t i_size; /* i_size when submitted */
> 
> I'll change this to loff_t, OK?
> -

Yes.

Daniel

-
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] Direct IO async short read bug followup

[Andrew Morton]

Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>  >  --- linux-2.6.11.orig/fs/direct-io.c  2005-04-01 15:33:11.0 
> -0800
>  >  +++ linux-2.6.11/fs/direct-io.c   2005-03-31 16:59:15.0 -0800
>  >  @@ -66,6 +66,7 @@ struct dio {
>  >struct bio *bio;/* bio under assembly */
>  >struct inode *inode;
>  >int rw;
>  >  + ssize_t i_size; /* i_size when submitted */
> 
>  I'll change this to loff_t, OK?

And I think local variable `transferred' can remain ssize_t.  Agree?
-
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] Direct IO async short read bug followup

[Andrew Morton]

Daniel McNeil <[EMAIL PROTECTED]> wrote:
>
> I updated the patch to add an i_size element to the dio structure and
>  sample i_size during i/o submission.  When i/o completes the result can
>  be truncated to match the file size without using i_size_read(), thus
>  the aio result now matches the number of bytes read to the end of file.
> 

Can you provide the analysis of the bug, please?

> 
>  Daniel
> 
>  --- linux-2.6.11.orig/fs/direct-io.c 2005-04-01 15:33:11.0 -0800
>  +++ linux-2.6.11/fs/direct-io.c  2005-03-31 16:59:15.0 -0800
>  @@ -66,6 +66,7 @@ struct dio {
>   struct bio *bio;/* bio under assembly */
>   struct inode *inode;
>   int rw;
>  +ssize_t i_size; /* i_size when submitted */

I'll change this to loff_t, OK?
-
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] Direct IO async short read bug followup

[Daniel McNeil]

On Fri, 2005-03-25 at 06:59, Badari Pulavarty wrote:

> Andrew,
> 
> When I debugged the problem, the issue seems to be only for the last 
> block of the file. Filesize is not multiple of 4K blocks. (say 17K).
> So, on the disk we have a 4K block for the last block. The test is
> trying to read 20K.  Since we have a block on the disk, get_block()
> won't complain and we do the IO. Once the IO is done, we can truncate
> the result to match the filesize.
> 
> I tried fixing the problem by limiting the IO submits to the size of
> the file - which became really ugly (since I have to adjust the
> iovec[]).
> 
> Daniel McNeil wanted to take a stab at it. Dan what happend to the fix ?
> 
> Thanks,
> Badari

I updated the patch to add an i_size element to the dio structure and
sample i_size during i/o submission.  When i/o completes the result can
be truncated to match the file size without using i_size_read(), thus
the aio result now matches the number of bytes read to the end of file.

Here's the patch.  It applies to 2.6.11 and the latest bk.

Daniel

--- linux-2.6.11.orig/fs/direct-io.c2005-04-01 15:33:11.0 -0800
+++ linux-2.6.11/fs/direct-io.c 2005-03-31 16:59:15.0 -0800
@@ -66,6 +66,7 @@ struct dio {
struct bio *bio;/* bio under assembly */
struct inode *inode;
int rw;
+   ssize_t i_size; /* i_size when submitted */
int lock_type;  /* doesn't change */
unsigned blkbits;   /* doesn't change */
unsigned blkfactor; /* When we're using an alignment which
@@ -230,17 +231,29 @@ static void finished_one_bio(struct dio 
spin_lock_irqsave(>bio_lock, flags);
if (dio->bio_count == 1) {
if (dio->is_async) {
+   ssize_t transferred;
+   loff_t offset;
+
/*
 * Last reference to the dio is going away.
 * Drop spinlock and complete the DIO.
 */
spin_unlock_irqrestore(>bio_lock, flags);
-   dio_complete(dio, dio->block_in_file << dio->blkbits,
-   dio->result);
+
+   /* Check for short read case */
+   transferred = dio->result;
+   offset = dio->iocb->ki_pos;
+
+   if ((dio->rw == READ) &&
+   ((offset + transferred) > dio->i_size))
+   transferred = dio->i_size - offset;
+
+   dio_complete(dio, offset, transferred);
+
/* Complete AIO later if falling back to buffered i/o */
if (dio->result == dio->size ||
((dio->rw == READ) && dio->result)) {
-   aio_complete(dio->iocb, dio->result, 0);
+   aio_complete(dio->iocb, transferred, 0);
kfree(dio);
return;
} else {
@@ -951,6 +964,7 @@ direct_io_worker(int rw, struct kiocb *i
dio->page_errors = 0;
dio->result = 0;
dio->iocb = iocb;
+   dio->i_size = i_size_read(inode);
 
/*
 * BIO completion state.


-
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: PCI: fix an oops in some pci devices on hotplug remove when their resources are being freed.

[Matthew Wilcox]

On Fri, Apr 01, 2005 at 03:47:50PM -0800, Greg KH wrote:
> PCI: fix an oops in some pci devices on hotplug remove when their resources 
> are being freed.
> 
> As reported by Prarit Bhargava <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> 
> diff -Nru a/drivers/pci/remove.c b/drivers/pci/remove.c
>   for (i = 0; i < PCI_NUM_RESOURCES; i++) {
>   struct resource *res = dev->resource + i;
> - if (res->parent)
> + if (res && res->parent)
>   release_resource(res);

I can't believe this fixes anything.  How can res possibly be NULL here?
It's a pointer into a pci_dev.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain
-
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: Industry db benchmark result on recent 2.6 kernels

[Chen, Kenneth W]

Ingo Molnar wrote on Thursday, March 31, 2005 8:52 PM
> the current defaults for cache_hot_time are 10 msec for NUMA domains,
> and 2.5 msec for SMP domains. Clearly too low for CPUs with 9MB cache.
> Are you increasing cache_hot_time in your experiment? If that solves
> most of the problem that would be an easy thing to fix for 2.6.12.


Chen, Kenneth W wrote on Thursday, March 31, 2005 9:15 PM
> Yes, we are increasing the number in our experiments.  It's in the queue
> and I should have a result soon.

Hot of the press: bumping up cache_hot_time to 10ms on our db setup brings
2.6.11 performance on par with 2.6.9.  Theory confirmed.

- Ken


-
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] PCI: 80 column lines

[Greg KH]

ChangeSet 1.2181.16.11, 2005/03/17 14:31:08-08:00, [EMAIL PROTECTED]

[PATCH] PCI: 80 column lines

PCI 80-column lines

A couple of lines are >80 columns

Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/quirks.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


diff -Nru a/drivers/pci/quirks.c b/drivers/pci/quirks.c
--- a/drivers/pci/quirks.c  2005-04-01 15:36:44 -08:00
+++ b/drivers/pci/quirks.c  2005-04-01 15:36:44 -08:00
@@ -541,7 +541,7 @@
return;
pci_write_config_dword(dev, PCI_CB_LEGACY_MODE_BASE, 0);
 }
-DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID,PCI_ANY_ID, 
quirk_cardbus_legacy );
+DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_cardbus_legacy);
 
 /*
  * Following the PCI ordering rules is optional on the AMD762. I'm not
@@ -659,7 +659,7 @@
printk(KERN_INFO "PCI: Ignoring BAR%d-%d of IDE controller %s\n",
   first_bar, last_bar, pci_name(dev));
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID,   
  quirk_ide_bases );
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, quirk_ide_bases);
 
 /*
  * Ensure C0 rev restreaming is off. This is normally done by

-
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] arch/i386/pci/i386.c: Use new for_each_pci_dev macro

[Greg KH]

ChangeSet 1.2181.16.16, 2005/03/17 14:50:04-08:00, [EMAIL PROTECTED]

[PATCH] arch/i386/pci/i386.c: Use new for_each_pci_dev macro

From: Domen Puncer <[EMAIL PROTECTED]>

As requested by Christoph Hellwig I created a new macro called
for_each_pci_dev.  It is a wrapper for this common use of
pci_get/find_device:

(while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL))

This macro will return the pci_dev *for all pci devices.  Here is the first
patch I used to test this macro with.  Compiled and booted on my T23.
There will be 53 more patches using this new macro.

Signed-off-by: Hanna Linder <[EMAIL PROTECTED]>
Signed-off-by: Maximilian Attems <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 arch/i386/pci/i386.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


diff -Nru a/arch/i386/pci/i386.c b/arch/i386/pci/i386.c
--- a/arch/i386/pci/i386.c  2005-04-01 15:34:37 -08:00
+++ b/arch/i386/pci/i386.c  2005-04-01 15:34:37 -08:00
@@ -124,7 +124,7 @@
u16 command;
struct resource *r, *pr;
 
-   while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
+   for_each_pci_dev(dev) {
pci_read_config_word(dev, PCI_COMMAND, );
for(idx = 0; idx < 6; idx++) {
r = >resource[idx];
@@ -168,7 +168,7 @@
int idx;
struct resource *r;
 
-   while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
+   for_each_pci_dev(dev) {
int class = dev->class >> 8;
 
/* Don't touch classless devices and host bridges */

-
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] sort-out-pci_rom_address_enable-vs-ioresource_rom_enable.patch

[Greg KH]

ChangeSet 1.2181.16.15, 2005/03/17 14:49:28-08:00, [EMAIL PROTECTED]

[PATCH] sort-out-pci_rom_address_enable-vs-ioresource_rom_enable.patch

From: Jon Smirl <[EMAIL PROTECTED]>

This sorts out the usage of PCI_ROM_ADDRESS_ENABLE vs
IORESOURCE_ROM_ENABLE.  PCI_ROM_ADDRESS_ENABLE is for actually manipulating
the ROM's PCI config space.  IORESOURCE_ROM_ENABLE is for tracking the
IORESOURCE that the ROM is enabled.  Both are defined to 1 so code
shouldn't change.

Just to remind people, there are new PCI routines for enable/disable ROMs
so please call them instead of directly coding access in device drivers.
There are ten or so drivers that need to be converted to the new API.

Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 arch/frv/mb93090-mb00/pci-frv.c|6 +++---
 arch/i386/pci/i386.c   |4 ++--
 arch/mips/pmc-sierra/yosemite/ht.c |2 +-
 arch/ppc/kernel/pci.c  |4 ++--
 arch/sh/drivers/pci/pci.c  |2 +-
 arch/sh64/kernel/pcibios.c |2 +-
 arch/sparc64/kernel/pci_psycho.c   |2 +-
 arch/sparc64/kernel/pci_sabre.c|2 +-
 arch/sparc64/kernel/pci_schizo.c   |2 +-
 drivers/mtd/maps/pci.c |6 +++---
 10 files changed, 16 insertions(+), 16 deletions(-)


diff -Nru a/arch/frv/mb93090-mb00/pci-frv.c b/arch/frv/mb93090-mb00/pci-frv.c
--- a/arch/frv/mb93090-mb00/pci-frv.c   2005-04-01 15:35:02 -08:00
+++ b/arch/frv/mb93090-mb00/pci-frv.c   2005-04-01 15:35:02 -08:00
@@ -31,7 +31,7 @@
if (resource < 6) {
reg = PCI_BASE_ADDRESS_0 + 4*resource;
} else if (resource == PCI_ROM_RESOURCE) {
-   res->flags |= PCI_ROM_ADDRESS_ENABLE;
+   res->flags |= IORESOURCE_ROM_ENABLE;
new |= PCI_ROM_ADDRESS_ENABLE;
reg = dev->rom_base_reg;
} else {
@@ -170,11 +170,11 @@
}
if (!pass) {
r = >resource[PCI_ROM_RESOURCE];
-   if (r->flags & PCI_ROM_ADDRESS_ENABLE) {
+   if (r->flags & IORESOURCE_ROM_ENABLE) {
/* Turn the ROM off, leave the resource region, 
but keep it unregistered. */
u32 reg;
DBG("PCI: Switching off ROM of %s\n", 
pci_name(dev));
-   r->flags &= ~PCI_ROM_ADDRESS_ENABLE;
+   r->flags &= ~IORESOURCE_ROM_ENABLE;
pci_read_config_dword(dev, dev->rom_base_reg, 
);
pci_write_config_dword(dev, dev->rom_base_reg, 
reg & ~PCI_ROM_ADDRESS_ENABLE);
}
diff -Nru a/arch/i386/pci/i386.c b/arch/i386/pci/i386.c
--- a/arch/i386/pci/i386.c  2005-04-01 15:35:02 -08:00
+++ b/arch/i386/pci/i386.c  2005-04-01 15:35:02 -08:00
@@ -150,11 +150,11 @@
}
if (!pass) {
r = >resource[PCI_ROM_RESOURCE];
-   if (r->flags & PCI_ROM_ADDRESS_ENABLE) {
+   if (r->flags & IORESOURCE_ROM_ENABLE) {
/* Turn the ROM off, leave the resource region, 
but keep it unregistered. */
u32 reg;
DBG("PCI: Switching off ROM of %s\n", 
pci_name(dev));
-   r->flags &= ~PCI_ROM_ADDRESS_ENABLE;
+   r->flags &= ~IORESOURCE_ROM_ENABLE;
pci_read_config_dword(dev, dev->rom_base_reg, 
);
pci_write_config_dword(dev, dev->rom_base_reg, 
reg & ~PCI_ROM_ADDRESS_ENABLE);
}
diff -Nru a/arch/mips/pmc-sierra/yosemite/ht.c 
b/arch/mips/pmc-sierra/yosemite/ht.c
--- a/arch/mips/pmc-sierra/yosemite/ht.c2005-04-01 15:35:02 -08:00
+++ b/arch/mips/pmc-sierra/yosemite/ht.c2005-04-01 15:35:02 -08:00
@@ -361,7 +361,7 @@
 if (resource < 6) {
 reg = PCI_BASE_ADDRESS_0 + 4 * resource;
 } else if (resource == PCI_ROM_RESOURCE) {
-res->flags |= PCI_ROM_ADDRESS_ENABLE;
+   res->flags |= IORESOURCE_ROM_ENABLE;
 reg = dev->rom_base_reg;
 } else {
 /*
diff -Nru a/arch/ppc/kernel/pci.c b/arch/ppc/kernel/pci.c
--- a/arch/ppc/kernel/pci.c 2005-04-01 15:35:02 -08:00
+++ b/arch/ppc/kernel/pci.c 2005-04-01 15:35:02 -08:00
@@ -521,11 +521,11 @@
if (pass)
continue;
r = >resource[PCI_ROM_RESOURCE];
-   if (r->flags & PCI_ROM_ADDRESS_ENABLE) {
+   if (r->flags & IORESOURCE_ROM_ENABLE) {
/* Turn the ROM off, leave the resource region, but 
keep it unregistered. */
u32 reg;
DBG("PCI: Switching off 

PCI: fix an oops in some pci devices on hotplug remove when their resources are being freed.

[Greg KH]

ChangeSet 1.2181.16.7, 2005/03/17 10:30:46-08:00, [EMAIL PROTECTED]

PCI: fix an oops in some pci devices on hotplug remove when their resources are 
being freed.

As reported by Prarit Bhargava <[EMAIL PROTECTED]>

Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/remove.c |2 +-
 kernel/resource.c|1 +
 2 files changed, 2 insertions(+), 1 deletion(-)


diff -Nru a/drivers/pci/remove.c b/drivers/pci/remove.c
--- a/drivers/pci/remove.c  2005-04-01 15:37:58 -08:00
+++ b/drivers/pci/remove.c  2005-04-01 15:37:58 -08:00
@@ -19,7 +19,7 @@
pci_cleanup_rom(dev);
for (i = 0; i < PCI_NUM_RESOURCES; i++) {
struct resource *res = dev->resource + i;
-   if (res->parent)
+   if (res && res->parent)
release_resource(res);
}
 }
diff -Nru a/kernel/resource.c b/kernel/resource.c
--- a/kernel/resource.c 2005-04-01 15:37:58 -08:00
+++ b/kernel/resource.c 2005-04-01 15:37:58 -08:00
@@ -505,6 +505,7 @@
*p = res->sibling;
write_unlock(_lock);
kfree(res);
+   res = NULL;
return;
}
p = >sibling;

-
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] PCI Hotplug: remove code duplication in drivers/pci/hotplug/ibmphp_pci.c

[Greg KH]

ChangeSet 1.2181.16.9, 2005/03/17 13:54:33-08:00, [EMAIL PROTECTED]

[PATCH] PCI Hotplug: remove code duplication in drivers/pci/hotplug/ibmphp_pci.c

This patch removes some code duplication where if and else have the
same code at the beginning and the end of the branch.

Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/hotplug/ibmphp_pci.c |   36 ++--
 1 files changed, 10 insertions(+), 26 deletions(-)


diff -Nru a/drivers/pci/hotplug/ibmphp_pci.c b/drivers/pci/hotplug/ibmphp_pci.c
--- a/drivers/pci/hotplug/ibmphp_pci.c  2005-04-01 15:37:11 -08:00
+++ b/drivers/pci/hotplug/ibmphp_pci.c  2005-04-01 15:37:11 -08:00
@@ -1308,9 +1308,9 @@
/* ? DO WE NEED TO WRITE ANYTHING INTO THE PCI 
CONFIG SPACE BACK ?? */
} else {
/* This is Memory */
+   start_address &= PCI_BASE_ADDRESS_MEM_MASK;
if (start_address & PCI_BASE_ADDRESS_MEM_PREFETCH) {
/* pfmem */
-   start_address &= PCI_BASE_ADDRESS_MEM_MASK;
debug ("start address of pfmem is %x\n", 
start_address);
 
if (ibmphp_find_resource (bus, start_address, 
, PFMEM) < 0) {
@@ -1321,15 +1321,8 @@
debug ("pfmem->start = %x\n", 
pfmem->start);
 
ibmphp_remove_resource (pfmem);
-
-   if (tmp_address & PCI_BASE_ADDRESS_MEM_TYPE_64) 
{
-   /* takes up another dword */
-   count += 1;
-   }
-
} else {
/* regular memory */
-   start_address &= PCI_BASE_ADDRESS_MEM_MASK;
debug ("start address of mem is %x\n", 
start_address);
if (ibmphp_find_resource (bus, start_address, 
, MEM) < 0) {
err ("cannot find corresponding MEM 
resource to remove\n");
@@ -1339,11 +1332,10 @@
debug ("mem->start = %x\n", mem->start);
 
ibmphp_remove_resource (mem);
-
-   if (tmp_address & PCI_BASE_ADDRESS_MEM_TYPE_64) 
{
-   /* takes up another dword */
-   count += 1;
-   }
+   }
+   if (tmp_address & PCI_BASE_ADDRESS_MEM_TYPE_64) {
+   /* takes up another dword */
+   count += 1;
}
}   /* end of mem */
}   /* end of for */
@@ -1428,9 +1420,9 @@
/* ? DO WE NEED TO WRITE ANYTHING INTO THE PCI 
CONFIG SPACE BACK ?? */
} else {
/* This is Memory */
+   start_address &= PCI_BASE_ADDRESS_MEM_MASK;
if (start_address & PCI_BASE_ADDRESS_MEM_PREFETCH) {
/* pfmem */
-   start_address &= PCI_BASE_ADDRESS_MEM_MASK;
if (ibmphp_find_resource (bus, start_address, 
, PFMEM) < 0) {
err ("cannot find corresponding PFMEM 
resource to remove\n");
return -EINVAL;
@@ -1439,15 +1431,8 @@
debug ("pfmem->start = %x\n", 
pfmem->start);
 
ibmphp_remove_resource (pfmem);
-
-   if (tmp_address & PCI_BASE_ADDRESS_MEM_TYPE_64) 
{
-   /* takes up another dword */
-   count += 1;
-   }
-
} else {
/* regular memory */
-   start_address &= PCI_BASE_ADDRESS_MEM_MASK;
if (ibmphp_find_resource (bus, start_address, 
, MEM) < 0) {
err ("cannot find corresponding MEM 
resource to remove\n");
return -EINVAL;
@@ -1456,11 +1441,10 @@
debug ("mem->start = %x\n", mem->start);
 
ibmphp_remove_resource (mem);
-
-   if (tmp_address & PCI_BASE_ADDRESS_MEM_TYPE_64) 
{
-   /* takes up another dword */
-   count += 1;
-   }
+   }
+   if (tmp_address & 

[PATCH] PCI: trivial DBG tidy-up

[Greg KH]

ChangeSet 1.2181.16.8, 2005/03/17 13:50:00-08:00, [EMAIL PROTECTED]

[PATCH] PCI: trivial DBG tidy-up

Tidy-up a bunch of PCI DBG output to use pci_name() when possible,
add domain when appropriate, remove redundancy, settle on one
style (DBG vs DBGC), etc.

Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/hotplug.c   |   10 --
 drivers/pci/probe.c |   13 +++--
 drivers/pci/setup-bus.c |   25 -
 drivers/pci/setup-irq.c |8 
 drivers/pci/setup-res.c |   14 +++---
 5 files changed, 34 insertions(+), 36 deletions(-)


diff -Nru a/drivers/pci/hotplug.c b/drivers/pci/hotplug.c
--- a/drivers/pci/hotplug.c 2005-04-01 15:37:39 -08:00
+++ b/drivers/pci/hotplug.c 2005-04-01 15:37:39 -08:00
@@ -71,7 +71,8 @@
struct pci_dev_wrapped wrapped_dev;
int result = 0;
 
-   DBG("scanning bus %02x\n", wrapped_bus->bus->number);
+   DBG("PCI: Scanning bus %04x:%02x\n", pci_domain_nr(wrapped_bus->bus),
+   wrapped_bus->bus->number);
 
if (fn->pre_visit_pci_bus) {
result = fn->pre_visit_pci_bus(wrapped_bus, wrapped_parent);
@@ -106,8 +107,7 @@
struct pci_bus_wrapped wrapped_bus;
int result = 0;
 
-   DBG("scanning bridge %02x, %02x\n", PCI_SLOT(wrapped_dev->dev->devfn),
-   PCI_FUNC(wrapped_dev->dev->devfn));
+   DBG("PCI: Scanning bridge %s\n", pci_name(wrapped_dev->dev));
 
if (fn->visit_pci_dev) {
result = fn->visit_pci_dev(wrapped_dev, wrapped_parent);
@@ -153,8 +153,7 @@
return result;
break;
default:
-   DBG("scanning device %02x, %02x\n",
-   PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
+   DBG("PCI: Scanning device %s\n", pci_name(dev));
if (fn->visit_pci_dev) {
result = fn->visit_pci_dev (wrapped_dev,
wrapped_parent);
@@ -169,4 +168,3 @@
return result;
 }
 EXPORT_SYMBOL(pci_visit_dev);
-
diff -Nru a/drivers/pci/probe.c b/drivers/pci/probe.c
--- a/drivers/pci/probe.c   2005-04-01 15:37:39 -08:00
+++ b/drivers/pci/probe.c   2005-04-01 15:37:39 -08:00
@@ -422,7 +422,7 @@
 
pci_read_config_dword(dev, PCI_PRIMARY_BUS, );
 
-   DBG("Scanning behind PCI bridge %s, config %06x, pass %d\n",
+   DBG("PCI: Scanning behind PCI bridge %s, config %06x, pass %d\n",
pci_name(dev), buses & 0xff, pass);
 
/* Disable MasterAbortMode during probing to avoid reporting
@@ -559,8 +559,8 @@
dev->class = class;
class >>= 8;
 
-   DBG("Found %02x:%02x [%04x/%04x] %06x %02x\n", dev->bus->number,
-   dev->devfn, dev->vendor, dev->device, class, dev->hdr_type);
+   DBG("PCI: Found %s [%04x/%04x] %06x %02x\n", pci_name(dev),
+   dev->vendor, dev->device, class, dev->hdr_type);
 
/* "Unknown power state" */
dev->current_state = 4;
@@ -815,7 +815,7 @@
unsigned int devfn, pass, max = bus->secondary;
struct pci_dev *dev;
 
-   DBG("Scanning bus %02x\n", bus->number);
+   DBG("PCI: Scanning bus %04x:%02x\n", pci_domain_nr(bus), bus->number);
 
/* Go find them, Rover! */
for (devfn = 0; devfn < 0x100; devfn += 8)
@@ -825,7 +825,7 @@
 * After performing arch-dependent fixup of the bus, look behind
 * all PCI-to-PCI bridges on this bus.
 */
-   DBG("Fixups for bus %02x\n", bus->number);
+   DBG("PCI: Fixups for bus %04x:%02x\n", pci_domain_nr(bus), bus->number);
pcibios_fixup_bus(bus);
for (pass=0; pass < 2; pass++)
list_for_each_entry(dev, >devices, bus_list) {
@@ -841,7 +841,8 @@
 *
 * Return how far we've got finding sub-buses.
 */
-   DBG("Bus scan for %02x returning with max=%02x\n", bus->number, max);
+   DBG("PCI: Bus scan for %04x:%02x returning with max=%02x\n",
+   pci_domain_nr(bus), bus->number, max);
return max;
 }
 
diff -Nru a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
--- a/drivers/pci/setup-bus.c   2005-04-01 15:37:39 -08:00
+++ b/drivers/pci/setup-bus.c   2005-04-01 15:37:39 -08:00
@@ -29,9 +29,9 @@
 
 #define DEBUG_CONFIG 1
 #if DEBUG_CONFIG
-# define DBGC(args) printk args
+#define DBG(x...) printk(x)
 #else
-# define DBGC(args)
+#define DBG(x...)
 #endif
 
 #define ROUND_UP(x, a) (((x) + (a) - 1) & ~((a) - 1))
@@ -151,8 +151,7 @@
struct pci_bus_region region;
u32 l, io_upper16;
 
-   DBGC((KERN_INFO "PCI: Bus %d, bridge: %s\n",
-   bus->number, pci_name(bridge)));
+   DBG(KERN_INFO "PCI: Bridge: %s\n", pci_name(bridge));
 
/* Set up the top and bottom of the PCI I/O segment for this bus. */

Re: [PATCH] quiet ide-cd warning

[Matt Mackall]

On Sat, Apr 02, 2005 at 03:46:53AM +0400, Michael Tokarev wrote:
> Matt Mackall wrote:
> >This shuts up a potential uninitialized variable warning.
> 
> Potential warning or potential uninitialized use?
> The code was right before the change, and if the compiler
> generates such a warning on it, it's the compiler who
> should be fixed, not the code: it's obvious the variable
> can't be used uninitialized here, and moving the things
> around like that makes the code misleading and hard to
> understand...

It's a compiler problem.

With gcc 3.3.5:

drivers/ide/ide-cd.c: In function `cdrom_analyze_sense_data':
drivers/ide/ide-cd.c:433: warning: `s' might be used uninitialized in
this function

Looks like the compiler's being stupid about my earlier patch which
makes printk an inline (and it's the only thing in the tree to do so).
gcc-snapshot doesn't complain.

> /mjt
> 
> >Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
> >
> >Index: af/drivers/ide/ide-cd.c
> >===
> >--- af.orig/drivers/ide/ide-cd.c 2005-04-01 11:17:37.0 -0800
> >+++ af/drivers/ide/ide-cd.c  2005-04-01 11:55:09.0 -0800
> >@@ -430,7 +430,7 @@ void cdrom_analyze_sense_data(ide_drive_
> > #if VERBOSE_IDE_CD_ERRORS
> > {
> > int i;
> >-const char *s;
> >+const char *s = "bad sense key!";
> > char buf[80];
> > 
> > printk ("ATAPI device %s:\n", drive->name);
> >@@ -445,8 +445,6 @@ void cdrom_analyze_sense_data(ide_drive_
> > 
> > if (sense->sense_key < ARY_LEN(sense_key_texts))
> > s = sense_key_texts[sense->sense_key];
> >-else
> >-s = "bad sense key!";
> > 
> > printk("%s -- (Sense key=0x%02x)\n", s, sense->sense_key);
> > 
> >

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

[PATCH] PCI Hotplug: only call ibmphp_remove_resource() if argument is not NULL

[Greg KH]

ChangeSet 1.2181.16.10, 2005/03/17 13:54:51-08:00, [EMAIL PROTECTED]

[PATCH] PCI Hotplug: only call ibmphp_remove_resource() if argument is not NULL

If we call ibmphp_remove_resource() with a NULL argument it will write
a warning. We can avoid this here because we already look if the argument
will be NULL before (and we ignore the return code anyway).

Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/hotplug/ibmphp_pci.c |   20 
 1 files changed, 12 insertions(+), 8 deletions(-)


diff -Nru a/drivers/pci/hotplug/ibmphp_pci.c b/drivers/pci/hotplug/ibmphp_pci.c
--- a/drivers/pci/hotplug/ibmphp_pci.c  2005-04-01 15:36:56 -08:00
+++ b/drivers/pci/hotplug/ibmphp_pci.c  2005-04-01 15:36:56 -08:00
@@ -1317,10 +1317,11 @@
err ("cannot find corresponding PFMEM 
resource to remove\n");
return -EIO;
}
-   if (pfmem)
+   if (pfmem) {
debug ("pfmem->start = %x\n", 
pfmem->start);
 
-   ibmphp_remove_resource (pfmem);
+   ibmphp_remove_resource(pfmem);
+   }
} else {
/* regular memory */
debug ("start address of mem is %x\n", 
start_address);
@@ -1328,10 +1329,11 @@
err ("cannot find corresponding MEM 
resource to remove\n");
return -EIO;
}
-   if (mem)
+   if (mem) {
debug ("mem->start = %x\n", mem->start);
 
-   ibmphp_remove_resource (mem);
+   ibmphp_remove_resource(mem);
+   }
}
if (tmp_address & PCI_BASE_ADDRESS_MEM_TYPE_64) {
/* takes up another dword */
@@ -1427,20 +1429,22 @@
err ("cannot find corresponding PFMEM 
resource to remove\n");
return -EINVAL;
}
-   if (pfmem)
+   if (pfmem) {
debug ("pfmem->start = %x\n", 
pfmem->start);
 
-   ibmphp_remove_resource (pfmem);
+   ibmphp_remove_resource(pfmem);
+   }
} else {
/* regular memory */
if (ibmphp_find_resource (bus, start_address, 
, MEM) < 0) {
err ("cannot find corresponding MEM 
resource to remove\n");
return -EINVAL;
}
-   if (mem)
+   if (mem) {
debug ("mem->start = %x\n", mem->start);
 
-   ibmphp_remove_resource (mem);
+   ibmphp_remove_resource(mem);
+   }
}
if (tmp_address & PCI_BASE_ADDRESS_MEM_TYPE_64) {
/* takes up another dword */

-
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] PCI: Quirk for Asus M5N

[Greg KH]

ChangeSet 1.2181.16.19, 2005/03/28 15:09:51-08:00, [EMAIL PROTECTED]

[PATCH] PCI: Quirk for Asus M5N

One more Asus laptop which requires a PCI quirk to unhide the SMBus.
Contributed by Matthias Hensler through bugzilla (#4391).

Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/quirks.c |1 +
 1 files changed, 1 insertion(+)


diff -Nru a/drivers/pci/quirks.c b/drivers/pci/quirks.c
--- a/drivers/pci/quirks.c  2005-04-01 15:33:28 -08:00
+++ b/drivers/pci/quirks.c  2005-04-01 15:33:28 -08:00
@@ -787,6 +787,7 @@
if (dev->device == PCI_DEVICE_ID_INTEL_82855GM_HB)
switch (dev->subsystem_device) {
case 0x1751: /* M2N notebook */
+   case 0x1821: /* M5N notebook */
asus_hides_smbus = 1;
}
if (dev->device == PCI_DEVICE_ID_INTEL_82855PM_HB)

-
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] PCI: remove pci_find_device usage from pci sysfs code.

[Greg KH]

ChangeSet 1.2181.16.23, 2005/03/28 15:19:00-08:00, [EMAIL PROTECTED]

[PATCH] PCI: remove pci_find_device usage from pci sysfs code.

Greg KH wrote:
> On Sun, Mar 20, 2005 at 03:53:58PM +0100, Rolf Eike Beer wrote:
> > Greg KH wrote:
> > > ChangeSet 1.1998.11.23, 2005/02/25 08:26:11-08:00, [EMAIL PROTECTED]
> > >
> > > PCI: remove pci_find_device usage from pci sysfs code.

> > Any reasons why you are not using "for_each_pci_dev(pdev)" here?
>
> Nope, I forgot it was there :)

Patch is against 2.6.12-rc1-bk1 and does the same think like your one,
except it uses for_each_pci_dev()

Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/pci-sysfs.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)


diff -Nru a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
--- a/drivers/pci/pci-sysfs.c   2005-04-01 15:31:47 -08:00
+++ b/drivers/pci/pci-sysfs.c   2005-04-01 15:31:47 -08:00
@@ -481,7 +481,7 @@
struct pci_dev *pdev = NULL;

sysfs_initialized = 1;
-   while ((pdev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, pdev)) != NULL)
+   for_each_pci_dev(pdev)
pci_create_sysfs_dev_files(pdev);
 
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/

2.6.11, nfsd, log_do_checkpoint()

[John Madden]

I woke up to a mostly-dead PE1850 this morning: 

Message from [EMAIL PROTECTED] at Fri Apr  1 06:19:14 2005 ...
storage kernel: Assertion failure in log_do_checkpoint() at 
fs/jbd/checkpoint.c:365: "drop_count != 0 || cleanup_ret != 0"

Message from [EMAIL PROTECTED] at Fri Apr  1 06:19:14 2005 ...
storage kernel: invalid operand:  [1] SMP 

Full error:

Assertion failure in log_do_checkpoint() at fs/jbd/checkpoint.c:365: 
"drop_count != 0 || cleanup_ret != 0"
--- [cut here ] - [please bite here ] -
Kernel BUG at checkpoint:365
invalid operand:  [1] SMP
CPU 1
Modules linked in:
Pid: 212, comm: nfsd Not tainted 2.6.11-rc5
RIP: 0010:[] {log_do_checkpoint+357}
RSP: :81003e6e99a8  EFLAGS: 00010296
RAX: 006e RBX:  RCX: 803bbdc8
RDX: 803bbdc8 RSI: 0246 RDI: 803bbdc0
RBP:  R08:  R09: 03c8
R10: 81003f0ca4c0 R11:  R12: 
R13: 81003eef5e00 R14: 81002fee1f50 R15: 81003eef5f5c
FS:  () GS:8044d600() knlGS:
CS:  0010 DS: 002b ES: 002b CR0: 8005003b
CR2: 556b29e0 CR3: 3e263000 CR4: 06e0
Process nfsd (pid: 212, threadinfo 81003e6e8000, task 81003e6e77f0)
Stack: 0246 2f3260b0802e1b50 81001e1c09c0 
   ffe0  003b 802e0d99
   81003e6e9a8c 
Call Trace:{sock_alloc_send_pskb+121} 
{ip_append_data+871}
   {ext3_get_block_handle+220} 
{bh_lru_install+275}
   {__find_get_block+217} 
{__getblk+17}
   {ext3_getblk+200} 
{__log_wait_for_space+166}
   {start_this_handle+879} 
{journal_start+158}
   {ext3_create+49} {vfs_create+140}
   {nfsd_create_v3+869} 
{nfsd3_proc_create+332}
   {nfsd_dispatch+272} 
{svc_process+958}
   {nfsd+0} {nfsd+480}
   {schedule_tail+11} {child_rip+8}
   {nfsd+0} {nfsd+0}
   {child_rip+0}

Code: 0f 0b 0c 69 36 80 ff ff ff ff 6d 01 49 8b 75 60 48 3b 74 24
RIP {log_do_checkpoint+357} RSP 

nfsd was serving out a pretty heavily-used (2.5-million page web site) ext3 
partition on the 1850's built-in LSI/MPT controller.  I'm able to duplicate 
this somewhat consistently by putting nfsd under heavy load (say, by deleting 
20,000 files from a directory).

(Please Cc me on replies, I'm not subscribed.)

Thanks,
  John



-- 
# John Madden  [EMAIL PROTECTED]: http://www.nerdarium.com
# FreeLists: Free mailing lists for all: http://www.freelists.org
# Linux, Apache, Perl and C: All the best things in life are free!
-
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/

PCI: add CONFIG_PCI_NAMES to the feature-removal-schedule.txt file

[Greg KH]

ChangeSet 1.2181.16.3, 2005/03/16 23:56:39-08:00, [EMAIL PROTECTED]

PCI: add CONFIG_PCI_NAMES to the feature-removal-schedule.txt file

Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 Documentation/feature-removal-schedule.txt |9 +
 1 files changed, 9 insertions(+)


diff -Nru a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
--- a/Documentation/feature-removal-schedule.txt2005-04-01 15:38:29 
-08:00
+++ b/Documentation/feature-removal-schedule.txt2005-04-01 15:38:29 
-08:00
@@ -22,3 +22,12 @@
 Why:   Noone uses it, and it probably does not work, anyway. swsusp is
faster, more reliable, and people are actually using it.
 Who:   Pavel Machek <[EMAIL PROTECTED]>
+
+---
+
+What:  PCI Name Database (CONFIG_PCI_NAMES)
+When:  July 2005
+Why:   It bloats the kernel unnecessarily, and is handled by userspace better
+   (pciutils supports it.)  Will eliminate the need to try to keep the
+   pci.ids file in sync with the sf.net database all of the time.
+Who:   Greg Kroah-Hartman <[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/

[Patch] sched: remove unnecessary sched domains

[Siddha, Suresh B]

Appended patch removes the unnecessary scheduler domains(containing
only one sched group) setup during the sched-domain init.

For example on x86_64, we always have NUMA configured in. On Intel EM64T
systems, top most sched domain will be of NUMA and with only one sched_group in
it. 

With fork/exec balances(recent Nick's fixes in -mm tree), we always endup 
taking wrong decisions because of this topmost domain (as it contains only 
one group and find_idlest_group always returns NULL). We will endup loading 
HT package completely first, letting active load balance kickin and correct it.

In general, this patch also makes sense with out recent Nick's fixes
in -mm.

Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>


--- linux-2.6.12-rc1-mm4/kernel/sched.c 2005-04-01 10:07:24.183605296 -0800
+++ linux/kernel/sched.c2005-04-01 15:29:28.274896888 -0800
@@ -4748,6 +4748,21 @@
unsigned long flags;
runqueue_t *rq = cpu_rq(cpu);
int local = 1;
+   struct sched_domain *tmp = sd, *tmp1;
+
+   /* Remove the sched domains which has only one group
+*/
+   while (tmp) {
+   tmp1 = tmp->parent;
+   if (!tmp1)
+   break;
+   if (tmp1->groups == tmp1->groups->next)
+   tmp->parent = tmp1->parent;
+   tmp = tmp->parent;
+   }
+
+   if (sd->parent && sd->groups && sd->groups == sd->groups->next)
+   sd = sd->parent;
 
sched_domain_debug(sd, cpu);
 
-
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/5] ppc RT: Realtime preempt support for PPC

[Frank Rowand]

Ingo Molnar wrote:
* Frank Rowand <[EMAIL PROTECTED]> wrote:

< more stuff deleted >
I'm working on the architecture support for realtime on PPC64 now. If 
the lock field of struct raw_rwlock_t is a long instead of int then 
/proc/meminfo shows MemFree decreasing from 485608 kB to 485352 kB.

Do you have a preference for lock to be long instead of int?
Do you know if any of the other 64 bit architectures would have an 
issue with int?

that would be nice to know. I have no preference, other than if possible 
it should be unified, no #ifdefs or other conditionals.

	Ingo
I looked at all the architectures and found that the disparity of the
type of the "lock" field in struct rwlock_t is even larger than I had
indicated in my earlier email.  I am attaching a proof of concept patch
to handle this.  If this looks like a good method to you then I will
create a real patch against your current patch, and include i386,
mips, x86_64, and ppc.
Index: linux-2.6.10/include/linux/rt_lock.h
===
--- linux-2.6.10.orig/include/linux/rt_lock.h
+++ linux-2.6.10/include/linux/rt_lock.h
@@ -37,8 +37,9 @@ typedef struct {
  * but only one writer.
  */
 #ifdef CONFIG_SMP
+#include 
 typedef struct {
-   volatile unsigned long lock;
+   ARCH_RAW_RWLOCK_LOCK
 # ifdef CONFIG_DEBUG_SPINLOCK
unsigned magic;
 # endif
Index: linux-2.6.10/include/asm-ppc/raw_spinlock.h
===
--- /dev/null
+++ linux-2.6.10/include/asm-ppc/raw_spinlock.h
@@ -0,0 +1,6 @@
+#ifndef __ASM_RAW_SPINLOCK_H
+#define __ASM_RAW_SPINLOCK_H
+
+#define ARCH_RAW_RWLOCK_LOCK volatile signed int lock;
+
+#endif /* __ASM_RAW_SPINLOCK_H */
Index: linux-2.6.10/include/asm-i386/raw_spinlock.h
===
--- /dev/null
+++ linux-2.6.10/include/asm-i386/raw_spinlock.h
@@ -0,0 +1,6 @@
+#ifndef __ASM_RAW_SPINLOCK_H
+#define __ASM_RAW_SPINLOCK_H
+
+#define ARCH_RAW_RWLOCK_LOCK volatile unsigned int lock;
+
+#endif /* __ASM_RAW_SPINLOCK_H */

For the curious, the implementations of the "lock" field are listed
below:
rwlock_t lock implemented as a spinlock field and a counter field
   include/asm-parisc/spinlock.h
   include/asm-sh/spinlock.h
rwlock_t lock implemented as a 31 bit counter field and a 1 bit write lock field
   include/asm-ia64/spinlock.h
rwlock_t lock implemented as a 1 bit write lock field and a 31 bit counter field
   include/asm-alpha/spinlock.h
rwlock_t lock implemented as an unsigned int field
   include/asm-arm/spinlock.h
   include/asm-i386/spinlock.h
   include/asm-mips/spinlock.h
   include/asm-x86_64/spinlock.h
   include/asm-sparc/spinlock.h
   include/asm-sparc64/spinlock.h #ifdef CONFIG_DEBUG_SPINLOCK
rwlock_t lock implemented as a signed int field
   include/asm-m32r/spinlock.h
   include/asm-ppc64/spinlock.h
   include/asm-ppc/spinlock.h
rwlock_t lock implemented as an unsigned long field
   include/asm-s390/spinlock.h
rwlock_t lock implemented as an unsigned int (_not_ in a structure)
   include/asm-sparc64/spinlock.h #ifdef CONFIG_DEBUG_SPINLOCK
SMP rwlock_t not supported (no SMP support)
   include/asm-arm26/spinlock.h
   include/asm-frv/spinlock.h
   include/asm-h8300/spinlock.h
   include/asm-m68knommu/spinlock.h
   include/asm-m68k/spinlock.h
   include/asm-sh64/spinlock.h
-Frank
--
Frank Rowand <[EMAIL PROTECTED]>
MontaVista Software, Inc
-
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] PCI: handle multiple video cards on the same bus

[Greg KH]

ChangeSet 1.2181.16.22, 2005/03/28 15:10:57-08:00, [EMAIL PROTECTED]

[PATCH] PCI: handle multiple video cards on the same bus

From: Jon Smirl <[EMAIL PROTECTED]>

When detecting the boot video device, allow for the case of multiple
cards on the same bus. Check each candidate to make sure that the card
is active.

Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 arch/i386/pci/fixup.c |   20 +---
 1 files changed, 13 insertions(+), 7 deletions(-)


diff -Nru a/arch/i386/pci/fixup.c b/arch/i386/pci/fixup.c
--- a/arch/i386/pci/fixup.c 2005-04-01 15:32:11 -08:00
+++ b/arch/i386/pci/fixup.c 2005-04-01 15:32:11 -08:00
@@ -343,7 +343,7 @@
 /*
  * Fixup to mark boot BIOS video selected by BIOS before it changes
  *
- * From information provided by "Jon Smirl" <[EMAIL PROTECTED]>
+ * From information provided by "Jon Smirl" <[EMAIL PROTECTED]>
  *
  * The standard boot ROM sequence for an x86 machine uses the BIOS
  * to select an initial video card for boot display. This boot video 
@@ -354,12 +354,13 @@
  * See pci_map_rom() for use of this flag. IORESOURCE_ROM_SHADOW
  * is marked here since the boot video device will be the only enabled
  * video device at this point.
- *
- */static void __devinit pci_fixup_video(struct pci_dev *pdev)
+ */
+
+static void __devinit pci_fixup_video(struct pci_dev *pdev)
 {
struct pci_dev *bridge;
struct pci_bus *bus;
-   u16 l;
+   u16 config;
 
if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
return;
@@ -369,12 +370,17 @@
while (bus) {
bridge = bus->self;
if (bridge) {
-   pci_read_config_word(bridge, PCI_BRIDGE_CONTROL, );
-   if (!(l & PCI_BRIDGE_CTL_VGA))
+   pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
+   );
+   if (!(config & PCI_BRIDGE_CTL_VGA))
return;
}
bus = bus->parent;
}
-   pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
+   pci_read_config_word(pdev, PCI_COMMAND, );
+   if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
+   pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
+   printk(KERN_DEBUG "Boot video device is %s\n", pci_name(pdev));
+   }
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_video);

-
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] PCI: create PCI_DEBUG config option to make it easier for users to enable pci debugging

[Greg KH]

ChangeSet 1.2181.16.26, 2005/03/28 22:29:40-08:00, [EMAIL PROTECTED]

[PATCH] PCI: create PCI_DEBUG config option to make it easier for users to 
enable pci debugging

Now you don't have to dig through a file to change a #define, it's a real 
config option.

Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/Kconfig |   10 ++
 drivers/pci/Makefile|4 
 drivers/pci/hotplug.c   |   15 ---
 drivers/pci/pci.c   |   12 +++-
 drivers/pci/probe.c |   25 +
 drivers/pci/quirks.c|2 --
 drivers/pci/remove.c|8 
 drivers/pci/setup-irq.c |   10 +-
 drivers/pci/setup-res.c |   16 
 9 files changed, 35 insertions(+), 67 deletions(-)


diff -Nru a/drivers/pci/Kconfig b/drivers/pci/Kconfig
--- a/drivers/pci/Kconfig   2005-04-01 15:30:40 -08:00
+++ b/drivers/pci/Kconfig   2005-04-01 15:30:40 -08:00
@@ -47,3 +47,13 @@
 
  When in doubt, say Y.
 
+config PCI_DEBUG
+   bool "PCI Debugging"
+   depends on PCI && DEBUG_KERNEL
+   help
+ Say Y here if you want the PCI core to produce a bunch of debug
+ messages to the system log.  Select this if you are having a
+ problem with PCI support and want to see more of what is going on.
+
+ When in doubt, say N.
+
diff -Nru a/drivers/pci/Makefile b/drivers/pci/Makefile
--- a/drivers/pci/Makefile  2005-04-01 15:30:40 -08:00
+++ b/drivers/pci/Makefile  2005-04-01 15:30:40 -08:00
@@ -41,6 +41,10 @@
 obj-y += syscall.o
 endif
 
+ifeq ($(CONFIG_PCI_DEBUG),y)
+EXTRA_CFLAGS += -DDEBUG
+endif
+
 hostprogs-y := gen-devlist
 
 # Dependencies on generated files need to be listed explicitly
diff -Nru a/drivers/pci/hotplug.c b/drivers/pci/hotplug.c
--- a/drivers/pci/hotplug.c 2005-04-01 15:30:40 -08:00
+++ b/drivers/pci/hotplug.c 2005-04-01 15:30:40 -08:00
@@ -1,15 +1,8 @@
+#include 
 #include 
 #include 
 #include "pci.h"
 
-#undef DEBUG
-
-#ifdef DEBUG
-#define DBG(x...) printk(x)
-#else
-#define DBG(x...)
-#endif
-
 int pci_hotplug (struct device *dev, char **envp, int num_envp,
 char *buffer, int buffer_size)
 {
@@ -71,7 +64,7 @@
struct pci_dev_wrapped wrapped_dev;
int result = 0;
 
-   DBG("PCI: Scanning bus %04x:%02x\n", pci_domain_nr(wrapped_bus->bus),
+   pr_debug("PCI: Scanning bus %04x:%02x\n", 
pci_domain_nr(wrapped_bus->bus),
wrapped_bus->bus->number);
 
if (fn->pre_visit_pci_bus) {
@@ -107,7 +100,7 @@
struct pci_bus_wrapped wrapped_bus;
int result = 0;
 
-   DBG("PCI: Scanning bridge %s\n", pci_name(wrapped_dev->dev));
+   pr_debug("PCI: Scanning bridge %s\n", pci_name(wrapped_dev->dev));
 
if (fn->visit_pci_dev) {
result = fn->visit_pci_dev(wrapped_dev, wrapped_parent);
@@ -153,7 +146,7 @@
return result;
break;
default:
-   DBG("PCI: Scanning device %s\n", pci_name(dev));
+   pr_debug("PCI: Scanning device %s\n", pci_name(dev));
if (fn->visit_pci_dev) {
result = fn->visit_pci_dev (wrapped_dev,
wrapped_parent);
diff -Nru a/drivers/pci/pci.c b/drivers/pci/pci.c
--- a/drivers/pci/pci.c 2005-04-01 15:30:40 -08:00
+++ b/drivers/pci/pci.c 2005-04-01 15:30:40 -08:00
@@ -9,6 +9,7 @@
  * Copyright 1997 -- 2000 Martin Mares <[EMAIL PROTECTED]>
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -16,13 +17,6 @@
 #include 
 #include/* isa_dma_bridge_buggy */
 
-#undef DEBUG
-
-#ifdef DEBUG
-#define DBG(x...) printk(x)
-#else
-#define DBG(x...)
-#endif
 
 /**
  * pci_bus_max_busnr - returns maximum PCI bus number of given bus' children
@@ -633,7 +627,7 @@
 
pci_read_config_word(dev, PCI_COMMAND, );
if (! (cmd & PCI_COMMAND_MASTER)) {
-   DBG("PCI: Enabling bus mastering for device %s\n", 
pci_name(dev));
+   pr_debug("PCI: Enabling bus mastering for device %s\n", 
pci_name(dev));
cmd |= PCI_COMMAND_MASTER;
pci_write_config_word(dev, PCI_COMMAND, cmd);
}
@@ -711,7 +705,7 @@
 
pci_read_config_word(dev, PCI_COMMAND, );
if (! (cmd & PCI_COMMAND_INVALIDATE)) {
-   DBG("PCI: Enabling Mem-Wr-Inval for device %s\n", 
pci_name(dev));
+   pr_debug("PCI: Enabling Mem-Wr-Inval for device %s\n", 
pci_name(dev));
cmd |= PCI_COMMAND_INVALIDATE;
pci_write_config_word(dev, PCI_COMMAND, cmd);
}
diff -Nru a/drivers/pci/probe.c b/drivers/pci/probe.c
--- a/drivers/pci/probe.c   2005-04-01 15:30:40 -08:00
+++ b/drivers/pci/probe.c   2005-04-01 15:30:40 -08:00
@@ -2,6 +2,7 @@
  * probe.c - PCI detection and setup code
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -9,14 +10,6 @@
 #include 
 

Re: [Pcihpd-discuss] RE: [RFC/Patch 0/12] ACPI based root bridge hot-add

[Tom Duffy]

On Thu, 2005-03-31 at 14:03 -0800, Rajesh Shah wrote:
> Does this patch help?

YES!  I can now power down the slot, see it gone from pci list, reenable
it, etc.  Awesome.  Thank you.

[EMAIL PROTECTED] ~]# lspci -s 08:00
08:00.0 Ethernet controller: Intel Corp.: Unknown device 105f (rev 03)
08:00.1 Ethernet controller: Intel Corp.: Unknown device 105f (rev 03)
[EMAIL PROTECTED] ~]# cd /sys/bus/pci/slots/4/
[EMAIL PROTECTED] 4]# cat power
1
[EMAIL PROTECTED] 4]# echo 0 > power
[EMAIL PROTECTED] 4]# lspci -s 08:00
[EMAIL PROTECTED] 4]# cat power
0
[EMAIL PROTECTED] 4]# echo 1 > power
[EMAIL PROTECTED] 4]# lspci -s 08:00
08:00.0 Ethernet controller: Intel Corp.: Unknown device 105f (rev 03)
08:00.1 Ethernet controller: Intel Corp.: Unknown device 105f (rev 03)



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

Re: oom-killer disable for iscsi/lvm2/multipath userland critical sections

[Dmitry Yusupov]

Andrea,

I just successfully tested the patch on my environment. It actually
resolved OOM-killer problem for my iscsid.

Important note: daemon's parent must be init.

In my test, OOM-killer killed everything around but iscsid, and iscsid
successfully finished registration of new SCSI host in the middle of
crazy OOM-killer :)

Thanks!
Dima

On Sat, 2005-04-02 at 00:14 +0200, Andrea Arcangeli wrote:
> Hello,
> 
> some private discussion (that was continuing some kernel-summit-discuss
> thread) ended in the below patch. I also liked a textual "disable"
> instead of value "-17" (internally to the kernel it could be represented
> the same way, but the /proc parsing would be more complicated). If you
> prefer textual "disable" we can change this of course.
> 
> Comments welcome.
> 
> From: Andrea Arcangeli <[EMAIL PROTECTED]>
> Subject: oom killer protection
> 
> iscsi/lvm2/multipath needs guaranteed protection from the oom-killer.
> 
> Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
> 
> --- 2.6.12-seccomp/fs/proc/base.c.~1~ 2005-03-25 05:13:28.0 +0100
> +++ 2.6.12-seccomp/fs/proc/base.c 2005-04-01 23:47:22.0 +0200
> @@ -751,7 +751,7 @@ static ssize_t oom_adjust_write(struct f
>   if (copy_from_user(buffer, buf, count))
>   return -EFAULT;
>   oom_adjust = simple_strtol(buffer, , 0);
> - if (oom_adjust < -16 || oom_adjust > 15)
> + if ((oom_adjust < -16 || oom_adjust > 15) && oom_adjust != OOM_DISABLE)
>   return -EINVAL;
>   if (*end == '\n')
>   end++;
> --- 2.6.12-seccomp/include/linux/mm.h.~1~ 2005-03-25 05:13:28.0 
> +0100
> +++ 2.6.12-seccomp/include/linux/mm.h 2005-04-01 23:53:11.0 +0200
> @@ -856,5 +856,8 @@ int in_gate_area_no_task(unsigned long a
>  #define in_gate_area(task, addr) ({(void)task; in_gate_area_no_task(addr);})
>  #endif   /* __HAVE_ARCH_GATE_AREA */
>  
> +/* /proc//oom_adj set to -17 protects from the oom-killer */
> +#define OOM_DISABLE -17
> +
>  #endif /* __KERNEL__ */
>  #endif /* _LINUX_MM_H */
> --- 2.6.12-seccomp/mm/oom_kill.c.~1~  2005-03-08 01:02:30.0 +0100
> +++ 2.6.12-seccomp/mm/oom_kill.c  2005-04-01 23:46:18.0 +0200
> @@ -145,7 +145,7 @@ static struct task_struct * select_bad_p
>   do_posix_clock_monotonic_gettime();
>   do_each_thread(g, p)
>   /* skip the init task with pid == 1 */
> - if (p->pid > 1) {
> + if (p->pid > 1 && p->oomkilladj != OOM_DISABLE) {
>   unsigned long points;
>  
>   /*
> -
> 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/

-
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] pci_ids.h correction for Intel ICH7M

[Greg KH]

ChangeSet 1.2181.16.14, 2005/03/17 14:32:07-08:00, [EMAIL PROTECTED]

[PATCH] pci_ids.h correction for Intel ICH7M

This patch corrects the ICH7M LPC controller DID in pci_ids.h from x27B1
to x27B9.


Signed-off-by: Jason Gaston <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 include/linux/pci_ids.h |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)


diff -Nru a/include/linux/pci_ids.h b/include/linux/pci_ids.h
--- a/include/linux/pci_ids.h   2005-04-01 15:35:30 -08:00
+++ b/include/linux/pci_ids.h   2005-04-01 15:35:30 -08:00
@@ -2383,7 +2383,7 @@
 #define PCI_DEVICE_ID_INTEL_ICH6_180x266e
 #define PCI_DEVICE_ID_INTEL_ICH6_190x266f
 #define PCI_DEVICE_ID_INTEL_ICH7_0 0x27b8
-#define PCI_DEVICE_ID_INTEL_ICH7_1 0x27b1
+#define PCI_DEVICE_ID_INTEL_ICH7_1 0x27b9
 #define PCI_DEVICE_ID_INTEL_ICH7_2 0x27c0
 #define PCI_DEVICE_ID_INTEL_ICH7_3 0x27c1
 #define PCI_DEVICE_ID_INTEL_ICH7_4 0x27c2

-
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 Kernel Performance Testing

[Chen, Kenneth W]

Grecko OSCP wrote on Friday, April 01, 2005 10:22 AM
> I noticed yesterday a news article on Linux.org about more kernel
> performance testing being called for, and I decided it would be a nice
> project to try. I have 10 completely identical systems that can be
> used for this, and would like to get started while I know I have them
> for a while.
>
> However, I wanted to make sure I didn't waste time. My plan was to do
> all testing, prerelease, and release kernels from the 2.4, 2.5, and
> 2.6 trees, with both lmbench and the Linux Testing Project (LTP)
> benchmark suite. Will this help out? Is there anything else a person
> should do? With those two benchmarks, and all the kernels I mentioned,
> I could be done in about 25 days, at one kernel a machine a day. I
> assume it wouldn't matter what distribution was used, so long as its
> the same for all tests?

The 10 machines for running benchmarks is not a bad infrastructure to
start with.  However, it may not be sufficient to identify performance
regression.  The benchmarks that show regression in Linux kernel requires
huge infrastructure - lots of memory, disks, network and clients.  The
simple benchmarks sometime do not show regression and are usually well
covered by the community and OSDL.

As mentioned in another thread, we (as Intel) will take on the challenge
to do performance testing on a regular basis.  We have fairly extensive
hardware mix and infrastructure (large smp/numa box with lots of memory,
disk farm, network etc) to really stress the kernel, performance wise.


-
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] PCI: Patch for Serverworks chips in hotplug environment

[Greg KH]

ChangeSet 1.2181.16.6, 2005/03/17 10:23:26-08:00, [EMAIL PROTECTED]

[PATCH] PCI: Patch for Serverworks chips in hotplug environment

From: Kimball Murray <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/ide/pci/serverworks.c |8 
 drivers/pci/quirks.c  |2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)


diff -Nru a/drivers/ide/pci/serverworks.c b/drivers/ide/pci/serverworks.c
--- a/drivers/ide/pci/serverworks.c 2005-04-01 15:38:06 -08:00
+++ b/drivers/ide/pci/serverworks.c 2005-04-01 15:38:06 -08:00
@@ -341,7 +341,7 @@
return __ide_dma_end(drive);
 }
 
-static unsigned int __init init_chipset_svwks (struct pci_dev *dev, const char 
*name)
+static unsigned int __devinit init_chipset_svwks (struct pci_dev *dev, const 
char *name)
 {
unsigned int reg;
u8 btr;
@@ -508,7 +508,7 @@
 }
 
 #undef CAN_SW_DMA
-static void __init init_hwif_svwks (ide_hwif_t *hwif)
+static void __devinit init_hwif_svwks (ide_hwif_t *hwif)
 {
u8 dma_stat = 0;
 
@@ -556,7 +556,7 @@
 /*
  * We allow the BM-DMA driver to only work on enabled interfaces.
  */
-static void __init init_dma_svwks (ide_hwif_t *hwif, unsigned long dmabase)
+static void __devinit init_dma_svwks (ide_hwif_t *hwif, unsigned long dmabase)
 {
struct pci_dev *dev = hwif->pci_dev;
 
@@ -568,7 +568,7 @@
ide_setup_dma(hwif, dmabase, 8);
 }
 
-static int __init init_setup_svwks (struct pci_dev *dev, ide_pci_device_t *d)
+static int __devinit init_setup_svwks (struct pci_dev *dev, ide_pci_device_t 
*d)
 {
return ide_setup_pci_device(dev, d);
 }
diff -Nru a/drivers/pci/quirks.c b/drivers/pci/quirks.c
--- a/drivers/pci/quirks.c  2005-04-01 15:38:06 -08:00
+++ b/drivers/pci/quirks.c  2005-04-01 15:38:06 -08:00
@@ -700,7 +700,7 @@
 /*
  * Serverworks CSB5 IDE does not fully support native mode
  */
-static void __init quirk_svwks_csb5ide(struct pci_dev *pdev)
+static void __devinit quirk_svwks_csb5ide(struct pci_dev *pdev)
 {
u8 prog;
pci_read_config_byte(pdev, PCI_CLASS_PROG, );

-
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] PCI: shrink drivers/pci/proc.c::pci_seq_start()

[Greg KH]

ChangeSet 1.2181.16.21, 2005/03/28 15:10:34-08:00, [EMAIL PROTECTED]

[PATCH] PCI: shrink drivers/pci/proc.c::pci_seq_start()

this patch shrinks pci_seq_start by using for_each_pci_dev() macro instead
of explicitely using a loop and avoiding a goto.

Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/proc.c |9 +++--
 1 files changed, 3 insertions(+), 6 deletions(-)


diff -Nru a/drivers/pci/proc.c b/drivers/pci/proc.c
--- a/drivers/pci/proc.c2005-04-01 15:32:36 -08:00
+++ b/drivers/pci/proc.c2005-04-01 15:32:36 -08:00
@@ -313,13 +313,10 @@
struct pci_dev *dev = NULL;
loff_t n = *pos;
 
-   dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev);
-   while (n--) {
-   dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev);
-   if (dev == NULL)
-   goto exit;
+   for_each_pci_dev(dev) {
+   if (!n--)
+   break;
}
-exit:
return 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/

PCI: increase the size of the pci.ids strings

[Greg KH]

ChangeSet 1.2181.16.1, 2005/03/16 23:55:56-08:00, [EMAIL PROTECTED]

PCI: increase the size of the pci.ids strings

If we are going to waste memory, might as well do it right...

Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/gen-devlist.c |2 +-
 include/linux/pci.h   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


diff -Nru a/drivers/pci/gen-devlist.c b/drivers/pci/gen-devlist.c
--- a/drivers/pci/gen-devlist.c 2005-04-01 15:38:43 -08:00
+++ b/drivers/pci/gen-devlist.c 2005-04-01 15:38:43 -08:00
@@ -7,7 +7,7 @@
 #include 
 #include 
 
-#define MAX_NAME_SIZE 89
+#define MAX_NAME_SIZE 200
 
 static void
 pq(FILE *f, const char *c, int len)
diff -Nru a/include/linux/pci.h b/include/linux/pci.h
--- a/include/linux/pci.h   2005-04-01 15:38:43 -08:00
+++ b/include/linux/pci.h   2005-04-01 15:38:43 -08:00
@@ -561,7 +561,7 @@
int rom_attr_enabled;   /* has display of the rom attribute 
been enabled? */
struct bin_attribute *res_attr[DEVICE_COUNT_RESOURCE]; /* sysfs file 
for resources */
 #ifdef CONFIG_PCI_NAMES
-#define PCI_NAME_SIZE  96
+#define PCI_NAME_SIZE  255
 #define PCI_NAME_HALF  __stringify(43) /* less than half to handle slop */
charpretty_name[PCI_NAME_SIZE]; /* pretty name for 
users to see */
 #endif

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

Remove item from feature-removal-schedule.txt that was already removed from the kernel.

[Greg KH]

ChangeSet 1.2181.16.2, 2005/03/16 23:56:17-08:00, [EMAIL PROTECTED]

Remove item from feature-removal-schedule.txt that was already removed from the 
kernel.

my mistake...

Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 Documentation/feature-removal-schedule.txt |   15 ---
 1 files changed, 15 deletions(-)


diff -Nru a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
--- a/Documentation/feature-removal-schedule.txt2005-04-01 15:38:36 
-08:00
+++ b/Documentation/feature-removal-schedule.txt2005-04-01 15:38:36 
-08:00
@@ -17,21 +17,6 @@
 
 ---
 
-What:  /proc/sys/cpu/*, sysctl and /proc/cpufreq interfaces to cpufreq (2.4.x 
interfaces)
-When:  January 2005
-Files: drivers/cpufreq/: cpufreq_userspace.c, proc_intf.c
-Why:   /proc/sys/cpu/* has been deprecated since inclusion of cpufreq into
-   the main kernel tree. It bloats /proc/ unnecessarily and doesn't work
-   well with the "governor"-based design of cpufreq.
-   /proc/cpufreq/* has also been deprecated for a long time and was only
-   meant for usage during 2.5. until the new sysfs-based interface became
-   ready. It has an inconsistent interface which doesn't work well with
-   userspace setting the frequency. The output from /proc/cpufreq/* can
-   be emulated using "cpufreq-info --proc" (cpufrequtils).
-   Both interfaces are superseded by the cpufreq interface in
-   /sys/devices/system/cpu/cpu%n/cpufreq/.
-Who:   Dominik Brodowski <[EMAIL PROTECTED]>
-
 What:  ACPI S4bios support
 When:  May 2005
 Why:   Noone uses it, and it probably does not work, anyway. swsusp is

-
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] [PATCH] remove redundant devices list

[Greg KH]

ChangeSet 1.2181.16.12, 2005/03/17 14:31:26-08:00, [EMAIL PROTECTED]

[PATCH] [PATCH] remove redundant devices list

The RPA PCI Hotplug module creates and maintains a list of devices for
each slot.  This is redundant, because the PCI structures already
maintain such a list.  This patch changes the module to use the list
provided in the pci_bus structure.

Signed-off-by: John Rose <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/hotplug/rpaphp.h  |2 
 drivers/pci/hotplug/rpaphp_pci.c  |  105 +++---
 drivers/pci/hotplug/rpaphp_slot.c |   11 ---
 3 files changed, 22 insertions(+), 96 deletions(-)


diff -Nru a/drivers/pci/hotplug/rpaphp.h b/drivers/pci/hotplug/rpaphp.h
--- a/drivers/pci/hotplug/rpaphp.h  2005-04-01 15:36:22 -08:00
+++ b/drivers/pci/hotplug/rpaphp.h  2005-04-01 15:36:22 -08:00
@@ -94,7 +94,7 @@
/* dn has phb info */
struct pci_dev *bridge; /* slot's pci_dev in pci_devices */
union {
-   struct list_head pci_funcs; /* pci_devs in PCI slot */ 
+   struct list_head *pci_devs; /* pci_devs in PCI slot */
struct vio_dev *vio_dev; /* vio_dev in VIO slot */
} dev;
struct hotplug_slot *hotplug_slot;
diff -Nru a/drivers/pci/hotplug/rpaphp_pci.c b/drivers/pci/hotplug/rpaphp_pci.c
--- a/drivers/pci/hotplug/rpaphp_pci.c  2005-04-01 15:36:22 -08:00
+++ b/drivers/pci/hotplug/rpaphp_pci.c  2005-04-01 15:36:22 -08:00
@@ -130,11 +130,11 @@
*value = EMPTY;
}
else if (state == PRESENT) {
-   if (!is_init)
+   if (!is_init) {
/* at run-time slot->state can be changed by */
/* config/unconfig adapter */
*value = slot->state;
-   else {
+   } else {
child_dn = slot->dn->child;
if (child_dn)
child_dev = rpaphp_find_pci_dev(child_dn);
@@ -263,56 +263,17 @@

 }
 
-#ifdef DEBUG
 static void print_slot_pci_funcs(struct slot *slot)
 {
-   struct list_head *l;
+   struct pci_dev *dev;
 
if (slot->dev_type == PCI_DEV) {
-   printk("pci_funcs of slot[%s]\n", slot->name);
-   if (list_empty(>dev.pci_funcs))
-   printk("pci_funcs is EMPTY\n");
-
-   list_for_each (l, >dev.pci_funcs) {
-   struct rpaphp_pci_func *func =
-   list_entry(l, struct rpaphp_pci_func, sibling);
-   printk("FOUND dev=%s\n", 
pci_name(func->pci_dev));
-   }
+   dbg("%s: pci_devs of slot[%s]\n", __FUNCTION__, slot->name);
+   list_for_each_entry (dev, slot->dev.pci_devs, bus_list)
+   dbg("\t%s\n", pci_name(dev));
}
return;
 }
-#else
-static void print_slot_pci_funcs(struct slot *slot)
-{
-   return;
-}
-#endif
-
-static int init_slot_pci_funcs(struct slot *slot)
-{
-   struct device_node *child;
-
-   for (child = slot->dn->child; child != NULL; child = child->sibling) {
-   struct pci_dev *pdev = rpaphp_find_pci_dev(child);
-
-   if (pdev) {
-   struct rpaphp_pci_func *func;
-   func = kmalloc(sizeof(struct rpaphp_pci_func), 
GFP_KERNEL);
-   if (!func) 
-   return -ENOMEM;
-   memset(func, 0, sizeof(struct rpaphp_pci_func));
-   INIT_LIST_HEAD(>sibling);
-   func->pci_dev = pdev;
-   list_add_tail(>sibling, >dev.pci_funcs);
-   print_slot_pci_funcs(slot);
-   } else {
-   err("%s: dn=%s has no pci_dev\n", 
-   __FUNCTION__, child->full_name);
-   return -EIO;
-   }
-   }
-   return 0;
-}
 
 static int rpaphp_config_pci_adapter(struct slot *slot)
 {
@@ -335,13 +296,8 @@
err("%s: can't find any devices.\n", __FUNCTION__);
goto exit;
}
-   /* associate corresponding pci_dev */   
-   rc = init_slot_pci_funcs(slot);
-   if (rc)
-   goto exit;
print_slot_pci_funcs(slot);
-   if (!list_empty(>dev.pci_funcs)) 
-   rc = 0;
+   rc = 0;
} else {
/* slot is not enabled */
err("slot doesn't have pci_dev structure\n");
@@ -371,34 +327,16 @@
 
 int rpaphp_unconfig_pci_adapter(struct slot *slot)
 {
+   struct pci_dev *dev;
int retval = 0;
-   struct list_head *ln, *tmp;
 
-   dbg("Entry %s: slot[%s]\n", __FUNCTION__, slot->name);
-   if 

[PATCH] PCI Hotplug: add documentation about release pointer.

[Greg KH]

ChangeSet 1.2181.16.18, 2005/03/28 15:09:31-08:00, [EMAIL PROTECTED]

[PATCH] PCI Hotplug: add documentation about release pointer.

Adds "release" func pointer comments to nano-doc.

Signed-off-by: Prarit Bhargava <[EMAIL PROTECTED]>

Index: hp/drivers/pci/hotplug/pci_hotplug.h
===
RCS file: 
/usr/local/src/cvsroot/bk/linux-2.5/drivers/pci/hotplug/pci_hotplug.h,v
retrieving revision 1.1.1.1


 drivers/pci/hotplug/pci_hotplug.h |2 ++
 1 files changed, 2 insertions(+)


diff -Nru a/drivers/pci/hotplug/pci_hotplug.h 
b/drivers/pci/hotplug/pci_hotplug.h
--- a/drivers/pci/hotplug/pci_hotplug.h 2005-04-01 15:33:50 -08:00
+++ b/drivers/pci/hotplug/pci_hotplug.h 2005-04-01 15:33:50 -08:00
@@ -152,6 +152,8 @@
  * @ops: pointer to the  hotplug_slot_ops to be used for this slot
  * @info: pointer to the  hotplug_slot_info for the inital values for
  * this slot.
+ * @release: called during pci_hp_deregister to free memory allocated in a
+ * hotplug_slot structure.
  * @private: used by the hotplug pci controller driver to store whatever it
  * needs.
  */

-
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] PCI: Add PCI device ID for new Mellanox HCA

[Greg KH]

ChangeSet 1.2181.16.5, 2005/03/17 10:11:55-08:00, [EMAIL PROTECTED]

[PATCH] PCI: Add PCI device ID for new Mellanox HCA

Add PCI device IDs for new Mellanox "Sinai" InfiniHost III Lx HCA.

Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 include/linux/pci_ids.h |2 ++
 1 files changed, 2 insertions(+)


diff -Nru a/include/linux/pci_ids.h b/include/linux/pci_ids.h
--- a/include/linux/pci_ids.h   2005-04-01 15:38:14 -08:00
+++ b/include/linux/pci_ids.h   2005-04-01 15:38:14 -08:00
@@ -2115,6 +2115,8 @@
 #define PCI_DEVICE_ID_MELLANOX_TAVOR   0x5a44
 #define PCI_DEVICE_ID_MELLANOX_ARBEL_COMPAT 0x6278
 #define PCI_DEVICE_ID_MELLANOX_ARBEL   0x6282
+#define PCI_DEVICE_ID_MELLANOX_SINAI_OLD 0x5e8c
+#define PCI_DEVICE_ID_MELLANOX_SINAI   0x6274
 
 #define PCI_VENDOR_ID_PDC  0x15e9
 #define PCI_DEVICE_ID_PDC_1841 0x1841

-
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] drivers/pci/msi.c: fix a check after use

[Greg KH]

ChangeSet 1.2181.16.24, 2005/03/28 15:20:34-08:00, [EMAIL PROTECTED]

[PATCH] drivers/pci/msi.c: fix a check after use

This patch fixes a check after use found by the Coverity checker.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/msi.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletion(-)


diff -Nru a/drivers/pci/msi.c b/drivers/pci/msi.c
--- a/drivers/pci/msi.c 2005-04-01 15:31:25 -08:00
+++ b/drivers/pci/msi.c 2005-04-01 15:31:25 -08:00
@@ -703,11 +703,13 @@
  **/
 int pci_enable_msi(struct pci_dev* dev)
 {
-   int pos, temp = dev->irq, status = -EINVAL;
+   int pos, temp, status = -EINVAL;
u16 control;
 
if (!pci_msi_enable || !dev)
return status;
+
+   temp = dev->irq;
 
if ((status = msi_init()) < 0)
return status;

-
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] PCI busses are structs, not integers

[Greg KH]

ChangeSet 1.2181.16.13, 2005/03/17 14:31:48-08:00, [EMAIL PROTECTED]

[PATCH] PCI busses are structs, not integers

PCI busses are structs, not integers.  Fix pcibus_to_cpumask to take
a struct.  NB changing it from a macro to an inline function would
require serious include file surgery.

Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 arch/x86_64/kernel/pci-gart.c |2 +-
 drivers/pci/pci-sysfs.c   |2 +-
 drivers/pci/probe.c   |2 +-
 include/asm-i386/topology.h   |7 ---
 include/asm-x86_64/topology.h |3 +--
 5 files changed, 8 insertions(+), 8 deletions(-)


diff -Nru a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
--- a/arch/x86_64/kernel/pci-gart.c 2005-04-01 15:35:55 -08:00
+++ b/arch/x86_64/kernel/pci-gart.c 2005-04-01 15:35:55 -08:00
@@ -193,7 +193,7 @@
int node;
if (dev->bus == _bus_type) {
cpumask_t mask;
-   mask = pcibus_to_cpumask(to_pci_dev(dev)->bus->number);
+   mask = pcibus_to_cpumask(to_pci_dev(dev)->bus);
node = cpu_to_node(first_cpu(mask));
} else
node = numa_node_id();
diff -Nru a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
--- a/drivers/pci/pci-sysfs.c   2005-04-01 15:35:55 -08:00
+++ b/drivers/pci/pci-sysfs.c   2005-04-01 15:35:55 -08:00
@@ -46,7 +46,7 @@
 
 static ssize_t local_cpus_show(struct device *dev, char *buf)
 {  
-   cpumask_t mask = pcibus_to_cpumask(to_pci_dev(dev)->bus->number);
+   cpumask_t mask = pcibus_to_cpumask(to_pci_dev(dev)->bus);
int len = cpumask_scnprintf(buf, PAGE_SIZE-2, mask);
strcat(buf,"\n"); 
return 1+len;
diff -Nru a/drivers/pci/probe.c b/drivers/pci/probe.c
--- a/drivers/pci/probe.c   2005-04-01 15:35:55 -08:00
+++ b/drivers/pci/probe.c   2005-04-01 15:35:55 -08:00
@@ -80,7 +80,7 @@
  */
 static ssize_t pci_bus_show_cpuaffinity(struct class_device *class_dev, char 
*buf)
 {
-   cpumask_t cpumask = pcibus_to_cpumask((to_pci_bus(class_dev))->number);
+   cpumask_t cpumask = pcibus_to_cpumask(to_pci_bus(class_dev));
int ret;
 
ret = cpumask_scnprintf(buf, PAGE_SIZE, cpumask);
diff -Nru a/include/asm-i386/topology.h b/include/asm-i386/topology.h
--- a/include/asm-i386/topology.h   2005-04-01 15:35:55 -08:00
+++ b/include/asm-i386/topology.h   2005-04-01 15:35:55 -08:00
@@ -60,11 +60,12 @@
return first_cpu(mask);
 }
 
-/* Returns the number of the node containing PCI bus 'bus' */
-static inline cpumask_t pcibus_to_cpumask(int bus)
+/* Returns the number of the node containing PCI bus number 'busnr' */
+static inline cpumask_t __pcibus_to_cpumask(int busnr)
 {
-   return node_to_cpumask(mp_bus_id_to_node[bus]);
+   return node_to_cpumask(mp_bus_id_to_node[busnr]);
 }
+#define pcibus_to_cpumask(bus) __pcibus_to_cpumask(bus->number)
 
 /* sched_domains SD_NODE_INIT for NUMAQ machines */
 #define SD_NODE_INIT (struct sched_domain) {   \
diff -Nru a/include/asm-x86_64/topology.h b/include/asm-x86_64/topology.h
--- a/include/asm-x86_64/topology.h 2005-04-01 15:35:55 -08:00
+++ b/include/asm-x86_64/topology.h 2005-04-01 15:35:55 -08:00
@@ -35,8 +35,7 @@
cpus_and(res, busmask, online);
return res;
 }
-/* broken generic file uses #ifndef later on this */
-#define pcibus_to_cpumask(bus) __pcibus_to_cpumask(bus)
+#define pcibus_to_cpumask(bus) __pcibus_to_cpumask(bus->number)
 
 #ifdef CONFIG_NUMA
 /* sched_domains SD_NODE_INIT for x86_64 machines */

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

PCI Hotplug: enforce the rule that a hotplug slot needs a release function.

[Greg KH]

ChangeSet 1.2181.16.17, 2005/03/21 22:55:26-08:00, [EMAIL PROTECTED]

PCI Hotplug: enforce the rule that a hotplug slot needs a release function.

Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/hotplug/pci_hotplug_core.c |5 +
 1 files changed, 5 insertions(+)


diff -Nru a/drivers/pci/hotplug/pci_hotplug_core.c 
b/drivers/pci/hotplug/pci_hotplug_core.c
--- a/drivers/pci/hotplug/pci_hotplug_core.c2005-04-01 15:34:15 -08:00
+++ b/drivers/pci/hotplug/pci_hotplug_core.c2005-04-01 15:34:15 -08:00
@@ -567,6 +567,11 @@
return -ENODEV;
if ((slot->info == NULL) || (slot->ops == NULL))
return -EINVAL;
+   if (slot->release == NULL) {
+   dbg("Why are you trying to register a hotplug slot"
+   "without a proper release function?\n");
+   return -EINVAL;
+   }
 
kobject_set_name(>kobj, "%s", slot->name);
kobj_set_kset_s(slot, pci_hotplug_slots_subsys);

-
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] drivers/pci/hotplug/cpqphp_core.c: fix a check after use

[Greg KH]

ChangeSet 1.2181.16.20, 2005/03/28 15:10:15-08:00, [EMAIL PROTECTED]

[PATCH] drivers/pci/hotplug/cpqphp_core.c: fix a check after use

This patch fixes a check after use found by the Coverity checker.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/hotplug/cpqphp_core.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


diff -Nru a/drivers/pci/hotplug/cpqphp_core.c 
b/drivers/pci/hotplug/cpqphp_core.c
--- a/drivers/pci/hotplug/cpqphp_core.c 2005-04-01 15:33:05 -08:00
+++ b/drivers/pci/hotplug/cpqphp_core.c 2005-04-01 15:33:05 -08:00
@@ -577,10 +577,10 @@
 {
u8 hp_slot;
 
-   hp_slot = func->device - ctrl->slot_device_offset;
-
if (func == NULL)
return(1);
+
+   hp_slot = func->device - ctrl->slot_device_offset;
 
// Wait for exclusive access to hardware
down(>crit_sect);

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

PCI: clean up the dynamic id logic a little bit.

[Greg KH]

ChangeSet 1.2181.16.25, 2005/03/28 22:00:24-08:00, [EMAIL PROTECTED]

PCI: clean up the dynamic id logic a little bit.

Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 drivers/pci/pci-driver.c |   11 ++-
 1 files changed, 2 insertions(+), 9 deletions(-)


diff -Nru a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
--- a/drivers/pci/pci-driver.c  2005-04-01 15:31:02 -08:00
+++ b/drivers/pci/pci-driver.c  2005-04-01 15:31:02 -08:00
@@ -49,13 +49,6 @@
return error;
 }
 
-static inline void
-dynid_init(struct dynid *dynid)
-{
-   memset(dynid, 0, sizeof(*dynid));
-   INIT_LIST_HEAD(>node);
-}
-
 /**
  * store_new_id
  *
@@ -82,8 +75,9 @@
dynid = kmalloc(sizeof(*dynid), GFP_KERNEL);
if (!dynid)
return -ENOMEM;
-   dynid_init(dynid);
 
+   memset(dynid, 0, sizeof(*dynid));
+   INIT_LIST_HEAD(>node);
dynid->id.vendor = vendor;
dynid->id.device = device;
dynid->id.subvendor = subvendor;
@@ -167,7 +161,6 @@
 {
return -ENODEV;
 }
-static inline void dynid_init(struct dynid *dynid) {}
 static inline void pci_init_dynids(struct pci_dynids *dynids) {}
 static inline void pci_free_dynids(struct pci_driver *drv) {}
 static inline int pci_create_newid_file(struct pci_driver *drv)

-
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] quiet ide-cd warning

[Michael Tokarev]

Matt Mackall wrote:
This shuts up a potential uninitialized variable warning.
Potential warning or potential uninitialized use?
The code was right before the change, and if the compiler
generates such a warning on it, it's the compiler who
should be fixed, not the code: it's obvious the variable
can't be used uninitialized here, and moving the things
around like that makes the code misleading and hard to
understand...
/mjt
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: af/drivers/ide/ide-cd.c
===
--- af.orig/drivers/ide/ide-cd.c	2005-04-01 11:17:37.0 -0800
+++ af/drivers/ide/ide-cd.c	2005-04-01 11:55:09.0 -0800
@@ -430,7 +430,7 @@ void cdrom_analyze_sense_data(ide_drive_
 #if VERBOSE_IDE_CD_ERRORS
 	{
 		int i;
-		const char *s;
+		const char *s = "bad sense key!";
 		char buf[80];
 
 		printk ("ATAPI device %s:\n", drive->name);
@@ -445,8 +445,6 @@ void cdrom_analyze_sense_data(ide_drive_
 
 		if (sense->sense_key < ARY_LEN(sense_key_texts))
 			s = sense_key_texts[sense->sense_key];
-		else
-			s = "bad sense key!";
 
 		printk("%s -- (Sense key=0x%02x)\n", s, sense->sense_key);
 

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

[BK PATCH] PCI update for 2.6.12-rc1

[Greg KH]

Hi,

Here are some PCI and PCI Hotplug patches for 2.6.11.  All of these have
been in the past few -mm releases.

This includes an even bigger pci.ids update, as now we should be
completly synced up with the main sf.net database.  I've also marked
this feature as "will be deleted soon" as it's a waste of time and
space.

Please pull from:
bk://kernel.bkbits.net/gregkh/linux/pci-2.6

thanks,

greg k-h

p.s. I'll send these as patches in response to this email to lkml for
those who want to see them.


 Documentation/feature-removal-schedule.txt |   48 -
 arch/frv/mb93090-mb00/pci-frv.c|6 
 arch/i386/pci/fixup.c  |   20 
 arch/i386/pci/i386.c   |8 
 arch/mips/pmc-sierra/yosemite/ht.c |2 
 arch/ppc/kernel/pci.c  |8 
 arch/sh/drivers/pci/pci.c  |2 
 arch/sh64/kernel/pcibios.c |2 
 arch/sparc64/kernel/pci_psycho.c   |2 
 arch/sparc64/kernel/pci_sabre.c|2 
 arch/sparc64/kernel/pci_schizo.c   |2 
 arch/x86_64/kernel/pci-gart.c  |4 
 drivers/ide/pci/serverworks.c  |8 
 drivers/mtd/maps/pci.c |6 
 drivers/pci/Kconfig|   10 
 drivers/pci/Makefile   |4 
 drivers/pci/gen-devlist.c  |2 
 drivers/pci/hotplug.c  |   25 
 drivers/pci/hotplug/cpqphp_core.c  |4 
 drivers/pci/hotplug/ibmphp_pci.c   |   56 -
 drivers/pci/hotplug/pci_hotplug.h  |2 
 drivers/pci/hotplug/pci_hotplug_core.c |5 
 drivers/pci/hotplug/rpaphp.h   |2 
 drivers/pci/hotplug/rpaphp_pci.c   |  105 --
 drivers/pci/hotplug/rpaphp_slot.c  |   11 
 drivers/pci/msi.c  |8 
 drivers/pci/pci-driver.c   |   11 
 drivers/pci/pci-sysfs.c|4 
 drivers/pci/pci.c  |   24 
 drivers/pci/pci.ids| 1310 +
 drivers/pci/probe.c|   40 
 drivers/pci/proc.c |9 
 drivers/pci/quirks.c   |   43 
 drivers/pci/remove.c   |   10 
 drivers/pci/setup-bus.c|   25 
 drivers/pci/setup-irq.c|   18 
 drivers/pci/setup-res.c|   30 
 include/asm-i386/topology.h|7 
 include/asm-x86_64/topology.h  |3 
 include/linux/pci.h|2 
 include/linux/pci_ids.h|8 
 kernel/resource.c  |1 
 42 files changed, 1231 insertions(+), 668 deletions(-)
-


Adrian Bunk:
  o drivers/pci/msi.c: fix a check after use
  o drivers/pci/hotplug/cpqphp_core.c: fix a check after use

Bjorn Helgaas:
  o PCI: trivial DBG tidy-up

Domen Puncer:
  o arch/i386/pci/i386.c: Use new for_each_pci_dev macro

Greg Kroah-Hartman:
  o PCI: create PCI_DEBUG config option to make it easier for users to enable 
pci debugging
  o PCI: clean up the dynamic id logic a little bit
  o PCI Hotplug: enforce the rule that a hotplug slot needs a release function
  o PCI: fix an oops in some pci devices on hotplug remove when their resources 
are being freed
  o PCI: sync up with the latest pci.ids file from sf.net
  o PCI: add CONFIG_PCI_NAMES to the feature-removal-schedule.txt file
  o Remove item from feature-removal-schedule.txt that was already removed from 
the kernel
  o PCI: increase the size of the pci.ids strings

Jason Gaston:
  o pci_ids.h correction for Intel ICH7M

Jean Delvare:
  o PCI: Quirk for Asus M5N

John Rose:
  o [PATCH] remove redundant devices list

Jon Smirl:
  o PCI: handle multiple video cards on the same bus
  o sort-out-pci_rom_address_enable-vs-ioresource_rom_enable.patch

Kimball Murray:
  o PCI: Patch for Serverworks chips in hotplug environment

Matthew Wilcox:
  o PCI busses are structs, not integers
  o PCI: 80 column lines

Prarit Bhargava:
  o PCI Hotplug: add documentation about release pointer

Roland Dreier:
  o PCI: Add PCI device ID for new Mellanox HCA

Rolf Eike Beer:
  o PCI: remove pci_find_device usage from pci sysfs code
  o PCI: shrink drivers/pci/proc.c::pci_seq_start()
  o PCI Hotplug: only call ibmphp_remove_resource() if argument is not NULL
  o PCI Hotplug: remove code duplication in drivers/pci/hotplug/ibmphp_pci.c

-
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 patch drivers/serial/jsm/: make 2 functions static

[Adrian Bunk]

This patch makes two needlessly global functions static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/serial/jsm/jsm.h |1 -
 drivers/serial/jsm/jsm_neo.c |2 +-
 drivers/serial/jsm/jsm_tty.c |4 +++-
 3 files changed, 4 insertions(+), 3 deletions(-)

--- linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_neo.c.old  2005-04-02 
00:20:17.0 +0200
+++ linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_neo.c  2005-04-02 
00:20:34.0 +0200
@@ -688,7 +688,7 @@
 /*
  * No locks are assumed to be held when calling this function.
  */
-void neo_clear_break(struct jsm_channel *ch, int force)
+static void neo_clear_break(struct jsm_channel *ch, int force)
 {
u64 lock_flags;
 
--- linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm.h.old  2005-04-02 
00:20:44.0 +0200
+++ linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm.h  2005-04-02 
00:20:54.0 +0200
@@ -393,7 +393,6 @@
 int jsm_uart_port_init(struct jsm_board *);
 int jsm_remove_uart_port(struct jsm_board *);
 void jsm_input(struct jsm_channel *ch);
-void jsm_carrier(struct jsm_channel *ch);
 void jsm_check_queue_flow_control(struct jsm_channel *ch);
 
 #endif
--- linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_tty.c.old  2005-04-02 
00:21:02.0 +0200
+++ linux-2.6.12-rc1-mm4-full/drivers/serial/jsm/jsm_tty.c  2005-04-02 
00:21:18.0 +0200
@@ -31,6 +31,8 @@
 
 #include "jsm.h"
 
+static void jsm_carrier(struct jsm_channel *ch);
+
 static inline int jsm_get_mstat(struct jsm_channel *ch)
 {
unsigned char mstat;
@@ -760,7 +762,7 @@
jsm_printk(IOCTL, INFO, >ch_bd->pci_dev, "finish\n");
 }
 
-void jsm_carrier(struct jsm_channel *ch)
+static void jsm_carrier(struct jsm_channel *ch)
 {
struct jsm_board *bd;
 

-
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.11ac5 oops while reconstructing md array and moving volumegroup with pvmove

[Neil Brown]

On Friday April 1, [EMAIL PROTECTED] wrote:
> I had created a new raid1 array and started moving a volume group to it at the
> same time while it was reconstructing. Got this oops after several hours,

The subject says 'md array' but the Opps seems to say 'dm raid1
array'.

Could you please clarify exactly what the configuration is.

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] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00

[Gene Heskett]

On Friday 01 April 2005 14:22, K.R. Foley wrote:
>Gene Heskett wrote:
>> On Friday 01 April 2005 13:27, K.R. Foley wrote:
>>>Gene Heskett wrote:
>>>
>>>
It was up to 43-04 by the time I got there.

This one didn't go in cleanly Ingo.  From my build-src scripts
output: ---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching file lib/rwsem-spinlock.c
Hunk #5 FAILED at 133.
Hunk #6 FAILED at 160.
Hunk #7 FAILED at 179.
Hunk #8 FAILED at 194.
Hunk #9 FAILED at 204.
Hunk #10 FAILED at 231.
Hunk #11 FAILED at 250.
Hunk #12 FAILED at 265.
Hunk #13 FAILED at 274.
Hunk #14 FAILED at 293.
Hunk #15 FAILED at 314.
11 out of 15 hunks FAILED -- saving rejects to file
lib/rwsem-spinlock.c.rej
---
I doubt it would run, so I haven't built it.  Should I?
>>>
>>>Adding the attached patch on top of the above should resolve the
>>>failures, at least in the patching. Still working on building it.
>>
>> I assume you mean apply before the 43-04 patch?
>
>No actually I meant to apply it after the 43-04 patch. However, Ingo
> has a new patch that should cover this also.
>
>> I'll give it a go later today, right now I've got dirt to move in
>> the yard.

3 hrs later, rained out, or in as the case may be.  43-05 is building 
now, with lots of traceing turned on to see what sorts of grins I 
might get out of it.

No one has commented about the loss of video in the tvtime/pcHDTV-3000 
card situation, am I on my own, basicly reverting to the 
pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff?

--

2 friggin hours later, I'm finally rebooted.  I start heyu in my
rc.local file by launching a series of scripts to set that all up,
and my cm-11a interface decided, for the first time in a couple
of years, to not talk to the 'heyu setclock' command.  Boot hung,
but not of course until I'd used up half the boots per fsck on
100GB of disks.  Grwwff.

Anyway, now lets see what works.
tvtime doesn't, even if I re-install the drivers from the pcHDTV-2.0
archive.  No video, just a blue screen, sound so-so.
kino works
xsane works
spcagui works

But, I did get some odd stuff in the logs while doing this as I had
a lot of traceing stuff turned on over and above the defaults:

Warning, this IS lengthy
---
Apr  1 18:05:13 coyote gconfd (root-5947): starting (version 2.6.0), pid 5947 
user 'root'
Apr  1 18:05:13 coyote gconfd (root-5947): Resolved address 
"xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only config source at 
position 0
Apr  1 18:05:13 coyote gconfd (root-5947): Resolved address 
"xml:readwrite:/root/.gconf" to a writable config source at position 1
Apr  1 18:05:13 coyote gconfd (root-5947): Resolved address 
"xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only config source at 
position 2
Apr  1 18:05:19 coyote ieee1394.agent[6002]: ... no drivers for IEEE1394 
product 0x/0x/0x
Apr  1 18:05:20 coyote kernel: ieee1394: raw1394: /dev/raw1394 device 
initialized
Apr  1 18:05:20 coyote ieee1394.agent[6016]: ... no drivers for IEEE1394 
product 0x/0x/0x
Apr  1 18:05:24 coyote kernel:
Apr  1 18:05:24 coyote kernel: ==
Apr  1 18:05:24 coyote kernel: [ BUG: lock recursion deadlock detected! |
Apr  1 18:05:24 coyote kernel: --
Apr  1 18:05:24 coyote kernel: already locked:  [e4d17228] {(struct semaphore 
*)(>complete_sem)}
Apr  1 18:05:24 coyote kernel: .. held by:  kino: 6082 [e13ecbb0, 
118]
Apr  1 18:05:24 coyote kernel: ... acquired at:  raw1394_read+0x104/0x110 
[raw1394]
Apr  1 18:05:24 coyote kernel:
Apr  1 18:05:24 coyote kernel: --
Apr  1 18:05:24 coyote kernel: | showing all locks held by: |  (kino/6082 
[e13ecbb0, 118]):
Apr  1 18:05:24 coyote kernel: --
Apr  1 18:05:24 coyote kernel:
Apr  1 18:05:24 coyote kernel: #001: [e4d17228] {(struct semaphore 
*)(>complete_sem)}
Apr  1 18:05:24 coyote kernel: ... acquired at:  raw1394_read+0x104/0x110 
[raw1394]
Apr  1 18:05:24 coyote kernel:
Apr  1 18:05:24 coyote kernel: -{current task's backtrace}->
Apr  1 18:05:24 coyote kernel:  [] dump_stack+0x23/0x30 (20)
Apr  1 18:05:24 coyote kernel:  [] check_deadlock+0x2fe/0x320 (44)
Apr  1 18:05:24 coyote kernel:  [] task_blocks_on_lock+0x37/0xf0 (36)
Apr  1 18:05:24 coyote kernel:  [] __down_interruptible+0x257/0x4f0 
(88)
Apr  1 18:05:24 coyote kernel:  [] rt_down_interruptible+0xba/0x1f0 
(48)
Apr  1 18:05:24 coyote kernel:  [] raw1394_read+0x104/0x110 [raw1394] 
(32)
Apr  1 18:05:24 coyote kernel:  [] vfs_read+0xcd/0x140 (36)
Apr  1 18:05:24 coyote kernel:  [] sys_read+0x50/0x80 (44)
Apr  1 18:05:24 coyote kernel:  [] sysenter_past_esp+0x61/0x89 (-4028)
Apr  1 18:05:24 coyote kernel:
Apr  1 18:05:24 coyote kernel: showing all tasks:
Apr  1 18:05:24 coyote kernel: Sinit:1 

clock runs at double speed on x86_64 system w/ATI RS200 chipset

[Christopher Allen Wing]

I'm testing a system based on a ATI Radeon Xpress 200 motherboard.
(host bridge PCI device 1002:5950)

Something is causing the timer interrupt to be received twice as often as
desired; this makes the clock run at double normal speed.

I first noticed the problem when testing Red Hat 2.4 and 2.6 kernels;
however, I just reproduced it on the latest kernel.org release (2.6.11.6).


While messing around with the 2.4 kernel, I managed to make the problem go
away by getting the timer interrupt to be delivered via the XT-PIC instead
of the APIC. I don't know enough about how the interrupt routing/ACPI
works to figure out what's wrong.


At first I thought the problem seemed similar to the one discussed in June
2004 on lkml under the subject "linux-2.6.7-bk2 runs faster than
linux-2.6.7 ;)"; see:

http://marc.theaimsgroup.com/?w=2=1=linux-2.6.7-bk2+runs+faster=t


However the problem still exists in 2.6.11.6, as well as older Red Hat 2.4
and 2.6 kernels, so I'm guessing that it is an unrelated problem.

In short the timer interrupt gets received twice as many times as it
should:


$ cat /proc/interrupts; sleep 10; cat /proc/interrupts
  0:2812271IO-APIC-edge  timer
LOC:1405962

(only 5 seconds elapse; not 10)

  0:2822285IO-APIC-edge  timer
LOC:1410969



Note that this corresponds to 1000 local APIC timer ints/sec, but 2000
'timer' ints/second.



Here's the dmesg log from booting:

http://www-personal.engin.umich.edu/~wingc/code/dmesg-2.6.11.6

I also see messages from the kernel like:

APIC error on CPU0: 00(40)
APIC error on CPU0: 40(40)

so I'd guess that something is wrong in the way that the machine is set
up. Perhaps the BIOS or ACPI tables are just defective.


I'd appreciate it if anyone familiar with how ACPI and the interrupt
routing could suggest a way to figure out what's going on.


Thanks,

Chris Wing
[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 scsi-misc-2.6 07/13] scsi: move error handling out of scsi_init_io() into scsi_prep_fn()

[Tejun Heo]

 Greetings, James. :-)

On Fri, Apr 01, 2005 at 12:23:37PM -0600, James Bottomley wrote:
> On Thu, 2005-03-31 at 18:08 +0900, Tejun Heo wrote:
> > When scsi_init_io() returns BLKPREP_DEFER or BLKPREP_KILL,
> > it's supposed to free resources itself.  This patch
> > consolidates defer and kill handling into scsi_prep_fn().
> > This fixes a queue stall bug which occurred when sgtable
> > allocation failed and device_busy == 0.
> 
> This one I like, but I think it doesn't go far enough.  There are
> situations where a re-queue can also re-prepare, which means we leak sg
> lists and commands on BLKPREP_KILL because of SCSI state.

 With later request_fn() rewrite patch, all state checking are moved
to request_fn() and gets terminated with __scsi_done().  prep_fn()
only kills invalid (so, unprepped) requests.  It's in the fixed bugs
list of the request_fn() rewrite patch.  BTW, there's one more path
which leaks cmnd/sgtable, the end_that_request_*() on offline path of
request_fn() which is also fixed by request_fn() rewrite patch.

 I'm sorry about not mentioning that the bug is fixed in the later
patch.  Please review request_fn() rewrite patch.

> How about the attached.
> 
> Note, I've also altered the prepare function so req->special never gets
> altered if it points to a scsi_request. Previously it would be altered
> to point to the command, but now we couldn't put the command since the
> scsi_request we can't get to also has a copy of if.  So, if you can make
> your later REQ_SPECIAL removal work, we can dispense with sr_magic and
> simply use REQ_SPECIAL as the discriminator for the contents of req-
> >special.
> 
> James

 Yeah, I like not overwriting ->special, and removing magic is always
good. :-)

 Hmmm, I have another proposal.  What do you think about replacing
scsi_request with scsi_cmnd.  I've been looking into it and it doesn't
seem to be too much work and it won't cause problems.  The only
bothering thing is that scsi_cmnd is limited resource and should be
returned to the pool ASAP.  AFAIK, all current users of
scsi_allocate_request() releses the scsi_request as soon as they're
finished, and we can make the requirement clear in the comment
(i.e. do not cache or hold on to scsi_cmnd).  This will remove the
scsi_request/cmnd dance and make scsi midlayer slimmer in other
places.  What do you think?

 Thanks.

-- 
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: Industry db benchmark result on recent 2.6 kernels

[Chen, Kenneth W]

Linus Torvalds wrote on Tuesday, March 29, 2005 4:00 PM
> Also, it would be absolutely wonderful to see a finer granularity (which
> would likely also answer the stability question of the numbers). If you
> can do this with the daily snapshots, that would be great. If it's not
> easily automatable, or if a run takes a long time, maybe every other or
> every third day would be possible?
>
> Doing just release kernels means that there will be a two-month lag
> between telling developers that something pissed up performance. Doing it
> every day (or at least a couple of times a week) will be much more
> interesting.

Indeed, we agree that regular disciplined performance testing is important
and we (as Intel) will take on the challenge to support the Linux community.
I just got an approval to start this project.  We will report more detail
on how/where to publish the performance number, etc.

- Ken


-
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: Industry db benchmark result on recent 2.6 kernels

[Linus Torvalds]

On Fri, 1 Apr 2005, Chen, Kenneth W wrote:
> 
> Paul, you definitely want to check this out on your large numa box.  I booted
> a kernel with this patch on a 32-way numa box and it took a long  time
> to produce the cost matrix.

Is there anything fundamentally wrong with the notion of just initializing
the cost matrix to something that isn't completely wrong at bootup, and
just lettign user space fill it in?

Then you couple that with a program that can do so automatically (ie 
move the in-kernel heuristics into user-land), and something that can 
re-load it on demand.

Voila - you have something potentially expensive that you run once, and 
then you have a matrix that can be edited by the sysadmin later and just 
re-loaded at each boot.. That sounds pretty optimal, especially in the 
sense that it allows the sysadmin to tweak things depending on the use of 
the box is he really wants to.

Hmm? Or am I just totally on crack?

Linus
-
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] Show thread_info->flags in /proc/PID/status

[Andrew Morton]

Roland McGrath <[EMAIL PROTECTED]> wrote:
>
> It comes up as useful in debugging to be able to see task->thread_info->flags
> along with signal information and such.  There is no way currently to
> elicit these bits from the kernel via sysrq or /proc (AFAIK).
> This patch adds the field to /proc/PID/status.
> 
> ...
> 
> --- linux-2.6/fs/proc/array.c
> +++ linux-2.6/fs/proc/array.c
> @@ -287,6 +287,12 @@ static inline char *task_cap(struct task
>   cap_t(p->cap_effective));
>  }
>  
> +static inline char *task_tif(struct task_struct *p, char *buffer)
> +{
> + return buffer + sprintf(buffer, "ThreadInfoFlags:\t%lu\n",
> + (unsigned long) p->thread_info->flags);
> +}

Alas, thread_info.flags is an arch-specific thing and m68k doesn't
implement it.  All other architectures do, though.

Maybe we should show thread_info->flags in the sysrq-t output instead?

-
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] Show thread_info->flags in /proc/PID/status

[Roland McGrath]

It comes up as useful in debugging to be able to see task->thread_info->flags
along with signal information and such.  There is no way currently to
elicit these bits from the kernel via sysrq or /proc (AFAIK).
This patch adds the field to /proc/PID/status.


Thanks,
Roland

Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>


--- linux-2.6/fs/proc/array.c
+++ linux-2.6/fs/proc/array.c
@@ -287,6 +287,12 @@ static inline char *task_cap(struct task
cap_t(p->cap_effective));
 }
 
+static inline char *task_tif(struct task_struct *p, char *buffer)
+{
+   return buffer + sprintf(buffer, "ThreadInfoFlags:\t%lu\n",
+   (unsigned long) p->thread_info->flags);
+}
+
 int proc_pid_status(struct task_struct *task, char * buffer)
 {
char * orig = buffer;
@@ -294,6 +300,7 @@ int proc_pid_status(struct task_struct *
 
buffer = task_name(task, buffer);
buffer = task_state(task, buffer);
+   buffer = task_tif(task, buffer);
  
if (mm) {
buffer = task_mem(mm, buffer);
-
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: Industry db benchmark result on recent 2.6 kernels

[Chen, Kenneth W]

Ingo Molnar wrote on Thursday, March 31, 2005 10:46 PM
> before we get into complexities, i'd like to see whether it solves Ken's
> performance problem. The attached patch (against BK-curr, but should
> apply to vanilla 2.6.12-rc1 too) adds the autodetection feature. (For
> ia64 i've hacked in a cachesize of 9MB for Ken's testsystem.)

Very nice, it had a good estimate of 9ms on my test system.  Our historical
data showed that 12ms was the best on the same system for the db workload
(that was done on 2.6.8).  Scheduler dynamic has changed in 2.6.11 and this
old finding may not apply any more for the new kernel.

migration cost matrix (cache_size: 9437184, cpu: 1500 MHz):
[00]  [01]  [02]  [03]
[00]:9.1   8.5   8.5   8.5
[01]:8.5   9.1   8.5   8.5
[02]:8.5   8.5   9.1   8.5
[03]:8.5   8.5   8.5   9.1
min_delta: 8908106
using cache_decay nsec: 8908106 (8 msec)


Paul, you definitely want to check this out on your large numa box.  I booted
a kernel with this patch on a 32-way numa box and it took a long  time
to produce the cost matrix.


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

oom-killer disable for iscsi/lvm2/multipath userland critical sections

[Andrea Arcangeli]

Hello,

some private discussion (that was continuing some kernel-summit-discuss
thread) ended in the below patch. I also liked a textual "disable"
instead of value "-17" (internally to the kernel it could be represented
the same way, but the /proc parsing would be more complicated). If you
prefer textual "disable" we can change this of course.

Comments welcome.

From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: oom killer protection

iscsi/lvm2/multipath needs guaranteed protection from the oom-killer.

Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>

--- 2.6.12-seccomp/fs/proc/base.c.~1~   2005-03-25 05:13:28.0 +0100
+++ 2.6.12-seccomp/fs/proc/base.c   2005-04-01 23:47:22.0 +0200
@@ -751,7 +751,7 @@ static ssize_t oom_adjust_write(struct f
if (copy_from_user(buffer, buf, count))
return -EFAULT;
oom_adjust = simple_strtol(buffer, , 0);
-   if (oom_adjust < -16 || oom_adjust > 15)
+   if ((oom_adjust < -16 || oom_adjust > 15) && oom_adjust != OOM_DISABLE)
return -EINVAL;
if (*end == '\n')
end++;
--- 2.6.12-seccomp/include/linux/mm.h.~1~   2005-03-25 05:13:28.0 
+0100
+++ 2.6.12-seccomp/include/linux/mm.h   2005-04-01 23:53:11.0 +0200
@@ -856,5 +856,8 @@ int in_gate_area_no_task(unsigned long a
 #define in_gate_area(task, addr) ({(void)task; in_gate_area_no_task(addr);})
 #endif /* __HAVE_ARCH_GATE_AREA */
 
+/* /proc//oom_adj set to -17 protects from the oom-killer */
+#define OOM_DISABLE -17
+
 #endif /* __KERNEL__ */
 #endif /* _LINUX_MM_H */
--- 2.6.12-seccomp/mm/oom_kill.c.~1~2005-03-08 01:02:30.0 +0100
+++ 2.6.12-seccomp/mm/oom_kill.c2005-04-01 23:46:18.0 +0200
@@ -145,7 +145,7 @@ static struct task_struct * select_bad_p
do_posix_clock_monotonic_gettime();
do_each_thread(g, p)
/* skip the init task with pid == 1 */
-   if (p->pid > 1) {
+   if (p->pid > 1 && p->oomkilladj != OOM_DISABLE) {
unsigned long points;
 
/*
-
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 scsi-misc-2.6 01/13] scsi: don't use blk_insert_request() for requeueing

[Tejun Heo]

 Greetings, James.

On Fri, Apr 01, 2005 at 12:09:48PM -0600, James Bottomley wrote:
> On Fri, 2005-04-01 at 14:01 +0900, Tejun Heo wrote:
> > > Well, REQ_SPECIAL is the signal to the mid-layer that we've allocated
> > > the resources necessary to process the command, so in practice it will
> > > be turned on for every requeue request (because we set it when the
> > > command is prepared),
> > 
> >  Sorry, but where?  AFAICT, only blk_insert_request() and
> > scsi_init_io() on sgtable allocation failure set REQ_SPECIAL during
> > scsi midlayer processing.  This patch replaces blk_insert_request()
> > with blk_requeue_request() and the next patch removes REQ_SPECIAL
> > setting in scsi_init_io().
> > 
> >  REQ_SPECIAL is currently overloaded to mean two different things.
> > 
> >  * The request is a special request.
> >  * The request has been requeued using scsi_queue_insert().
> >i.e. It has been prepped.
> 
> But its true meaning is defined by the block layer (since it's a block
> flag).  It's supposed to mean that the ->special field of the request is
> in use to carry data meaningful to the underlying driver.  SCSI sets it
> on that basis.
>
> So, if I understand correctly, based on the fact that the current block
> code in fact never bothers with REQ_SPECIAL, but only checks req-
> >special, you're proposing that we need never actually set REQ_SPECIAL
> when making use of the ->special field?  Thus you want to use
> REQ_SPECIAL to distinguish between internally generated commands and
> external commands?  That sounds fine as long as the block API gets
> updated to reflect this (comments in linux/blkdev.h shoudl be fine).

 Yeap, That's what I'm proposing.  Block API never cares about
REQ_SPECIAL flag or ->special field except for when determining if
requests can be merged - both fields are independently checked in this
case.  And IDE driver already uses the flag regardless of ->special
field.  Do you want me to clear up the comment?

> > > The other reason I don't like this is that we've been trying hard to
> > > sweep excess block knowledge out of the mid-layer.  I don't think
> > > REQ_SOFTBARRIER is anything we really have to know about.
> > 
> >  We currently requeue using two different block functions.
> > 
> >  * blk_insert_request(): this function does two things
> > 1. enqueue special requests
> > 2. turn on REQ_SPECIAL|REQ_SOFTBARRIER and call
> >blk_requeue_request().  This is used only by scsi midlayer.
> >  * blk_requeue_request()
> > 
> >  REQ_SOFTBARRIER tells the request queue that other requests shouldn't
> > pass this one.  We need this to be set for prepped requests;
> > otherwise, it may, theoretically, deadlock (unprepped request waiting
> > for the prepped request back in the queue).  So, the current code
> > 
> >  * depends on blk_insert_request() sets REQ_SOFTBARRIER when
> >requeueing.  It works but nothing in the interface or semantics
> >is clear about it.  Why expect a request reinserted using
> >blk_insert_request() gets REQ_SOFTBARRIER turned on while a request
> >reinserted with blk_requeue_request() doesn't?  or why are there
> >two different paths doing mostly the same thing with slightly
> >different semantics?
> >  * requeueing using blk_requeue_request() in scsi_request_fn() doesn't
> >turn on either REQ_SPECIAL or REQ_SOFTBARRIER.  Missing REQ_SPECIAL
> >is okay, as we have the extra path in prep_fn (if it ever gets requeued
> >due to medium failure, so gets re-prepped), but missing
> >REQ_SOFTBARRIER can *theoretically* cause problem.
> > 
> >  So, it's more likely becoming less dependent on unobvious behavior of
> > block layer.  As we need the request to stay on top, we tell the block
> > layer to do so, instead of depending on blk_insert_request()
> > unobviously doing it for us.
> 
> But that's the point.  This is non obvious behaviour in the block layer,
> so SCSI doesn't want to know about it (and the block maintainer won't
> want to trawl through the SCSI and other block drivers altering it if it
> changes).

 Yes, it's non-obvious behavior of blk_insert_request() when used for
requeueing and, SCSI is the *only* user.  This patch removes the
unobvious path.

> If the bug is that the block layer isn't setting it on all
> our requeues where it should, then either we're using the wrong API or
> the block layer API is buggy.

 But block drivers in general don't have to inhibit reordering
requeued requests.  SCSI midlayer caches resources over requeueing, so
it's SCSI midlayer's requirement that requeued requests shouldn't be
passed.  IOW, it's SCSI midlayer's responsibility to tell the block
layer not to reschedule the request.  REQ_SOFTBARRIER has well-defined
meaning to tell just that.  It's not a block-layer internal thing.
It's a public interface.

 IOW, this patch uses well-defined flag to tell the block layer what
the SCSI midlayer wants.  I don't see any problem there.  If you're
uncomfortable 

Re: [RFC] CryptoAPI & Compression

[Herbert Xu]

On Fri, Apr 01, 2005 at 04:41:44PM +0100, Artem B. Bityuckiy wrote:
> 
> Suppose we compress 1 GiB of input, and have a 70K output buffer. We 

The question is what happens when you compress 1 1GiB input buffer into
a 1GiB output buffer.

> Surely I'll check. I'll even test the new implementation (which I didn't 
> actually do) with a large input before sending it next time.

It'd be a good idea to use /dev/urandom as your input.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] clean up kernel messages

[Richard B. Johnson]

On Fri, 1 Apr 2005, Steven Rostedt wrote:
On Fri, 2005-04-01 at 16:18 -0500, Steven Rostedt wrote:
On Fri, 2005-04-01 at 12:46 -0800, Matt Mackall wrote:
On Fri, Apr 01, 2005 at 12:26:41PM -0800, Andrew Morton wrote:
Matt Mackall <[EMAIL PROTECTED]> wrote:
This patch tidies up those annoying kernel messages. A typical kernel
 boot now looks like this:
 Loading Linux... Uncompressing kernel...
 #
 See? Much nicer. This patch saves about 375k on my laptop config and
 nearly 100k on minimal configs.
heh.  Please take a look at
http://www.uwsg.iu.edu/hypermail/linux/kernel/0004.2/0709.html, see if
Graham did anything which you missed.
He's got a bunch of stuff that's not strictly related in there and
stuff I've already dealt with (vprintk and the like) and stuff that's
still forthcoming (panic tweaks, etc.). I also leave in all the APIs
like dmesg, they just no longer do anything.
Looking at your other patches, I'm assuming that this is just another
April 1st type of patch. Is it?
Arg! I'm too tired.  I took another look at your other patches and they
look more legit now. On first glance, I thought you were just bluntly
removing BUGs and error messages to quiet things down. But after taking
another look, I see that they are more than that.  I wouldn't of thought
about that on any other day.
Sorry,
-- Steve
Methinks he still is kidding. We have "quiet" as a parameter now
to quiet things down on a boot. Now if he would just get rid
of the annoying...
 Loading Linux... Uncompressing kernel...
He'd have something.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: 64bit build of tulip driver

[Grant Grundler]

On Fri, Apr 01, 2005 at 12:23:25PM -0800, Jim Gifford wrote:
> Grant,
>Thank you, I took your driver as a reference and added in the cobalt 
> specifics to the eeprom.c file, works perfectly now.

Cool! very welcome.

Can you do me a favor and submit a diff of all the tulip changes
you have at this point back to lkml (and whatever other lists are cc'd)?

jgarzik might accept your bits and ignore the parts that have been
submitted/rejected before.  But whatever you post will get archived
with this thread for others to find in the future.

thanks,
grant
-
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/