ioremap - simply question, big problem (to me)
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
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)
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
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
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
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
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
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()
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
* 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
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
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
** 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
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!
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
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
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!
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.
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
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.
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
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.
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
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
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
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
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!
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!
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
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
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
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
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
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
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 !!!.
> 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
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
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
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
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
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
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
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
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
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
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 <[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
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
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.
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
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
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
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
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.
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
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
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
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
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
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.
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()
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
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
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
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
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
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
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
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
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
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
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()
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
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.
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
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.
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
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
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
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.
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
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.
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
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
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/