Re: sched /HT processor
I looked at my "include/asm-i386/param.h" and the HZ value is 1000.So, I suppose the timer interrupt frequency is 1000 times per sec. or once every 1 millisec. So, is scheduler_tick() ( for resceduling) called only once every 1 ms?? I am measuring the time when 2 of my processes are scheduled in a HT processor.So, the possible timedifference of when my 2 processes are scheduled can be only the following: 1) 0 (if both of my processes are scheduled @ the same time since its a HT) 2) 1ms ( this is the min. possible time diff. 3) some value greater than 1 ms Is the above argument correct? Thanks From: Steven Rostedt <[EMAIL PROTECTED]> To: Arun Srinivas <[EMAIL PROTECTED]> CC: LKML Subject: Re: sched /HT processor Date: Sat, 02 Apr 2005 20:17:54 -0500 On Sun, 2005-04-03 at 06:07 +0530, Arun Srinivas wrote: > HI > > I have pentium4 hyperthreaded processor.I am using kernel 2.6.5 and i > rebuilt my kernel with CONFIG_SMP enabled (in this kernel source there is > nothing such as CONFIG_SMT...i noticed this only in recent 2.6.11). > I don't have a 2.6.5 available, but I do have a 2.6.9 to look at. > 1) So, after I rebulit it with CONFIG_SMP enabled does linux recogonize my > machine as hyperthreaded or as 2 seperate processor? Also, if it does not > recogonize it as hyperthreaded(but only as 2 seperate CPU's), does the > scheduler schedule instruction in the 2 cpu's independently? (does it > maintain 2 seperate runqueues? > I believe even HT on 2.6.11 maintains two different runqueues. But it doesn't care so much to jump from one runqueue to the next if it is HT. > 2) If it has indeed recogonized this as hyperthreaded processor...does the > scheduler use a common runqueue for the 2 logical processor? > No, you wouldn't want to. > (please read below) What do you want us to see? > * > (I am attaching the ouput of 'dmesg' (command) on my machine) > * > Apr 2 17:43:12 kulick2 kernel: Linux version 2.6.5-1.358custom > ([EMAIL PROTECTED]) (gcc version 3.3 > .3 20040412 (Red Hat Linux 3.3.3-7)) #133 SMP Wed Mar 30 12:16:27 CST 2005 > Apr 2 17:43:12 kulick2 kernel: BIOS-provided physical RAM map: > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: - > 000a (usable) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 000f - > 0010 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 0010 - > 1f77 (usable) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 1f77 - > 1f772000 (ACPI NVS) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 1f772000 - > 1f793000 (ACPI data) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 1f793000 - > 1f80 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fec0 - > fec1 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fecf - > fecf1000 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fed2 - > fed9 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fee0 - > fee1 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: ffb0 - > 0001 (reserved) > Apr 2 17:43:12 kulick2 kernel: 0MB HIGHMEM available. > Apr 2 17:43:12 kulick2 kernel: 503MB LOWMEM available. > Apr 2 17:43:12 kulick2 kernel: ACPI: S3 and PAE do not like each other for > now, S3 disabled. > Apr 2 17:43:12 kulick2 kernel: found SMP MP-table at 000fe710 > Apr 2 17:43:12 kulick2 kernel: On node 0 totalpages: 128880 > Apr 2 17:43:12 kulick2 kernel: DMA zone: 4096 pages, LIFO batch:1 > Apr 2 17:43:12 kulick2 kernel: Normal zone: 124784 pages, LIFO batch:16 > Apr 2 17:43:12 kulick2 kernel: HighMem zone: 0 pages, LIFO batch:1 > Apr 2 17:43:12 kulick2 kernel: DMI 2.3 present. > Apr 2 17:43:12 kulick2 kernel: Using APIC driver default > Apr 2 17:43:12 kulick2 kernel: ACPI: RSDP (v000 DELL >) @ > 0x000feba0 > Apr 2 17:43:12 kulick2 kernel: ACPI: RSDT (v001 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd192 > Apr 2 17:43:12 kulick2 kernel: ACPI: FADT (v001 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd1ca > Apr 2 17:43:12 kulick2 kernel: ACPI: SSDT (v001 DELLst_ex 0x1000 > MSFT 0x010d) @ > 0xfffd4eee > Apr 2 17:43:12 kulick2 irqbalance: irqbalance startup succeeded > Apr 2 17:43:12 kulick2 kernel: ACPI: MADT (v001 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd23e > Apr 2 17:43:12 kulick2 kernel: ACPI: BOOT (v001 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd2aa > Apr 2 17:43:12 kulick2 kernel: ACPI: ASF! (v016 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd2d2 > Apr 2 17:43:12 kulick2 kernel: ACPI: DSDT (v001 DELLdt_ex 0x1000 > MSFT 0x0100
Re: Linux 2.6.9 Adaptec 4 Port Starfire Sickness
I disabled the FIFO resetting code and am running tests. See what happens. I am on 2.6 not 2.4 so it could be a problem there. At any rate, I will see if the problem goes away. Jeff Willy Tarreau wrote: On Sat, Apr 02, 2005 at 11:58:44PM -0700, jmerkey wrote: It works fine with the Intel Dual Port Pro-1000 MT adapters without these problems. but unless I'm mistaken, there's no PCI bridge on this board, and it is possible that the two ports share the same IRQ, that's why I suggested trying a 4-port sun QFE or something which is more similar to the starfire. I am using testing scenarios with Jumbo Frames as well. I am guessing the PCI bus contention is high due to the disk I/O bandwidth and this is causing conditions the adapter does not normally see. As I said, I have been saturating this card for weeks during stress tests and although it spitted out lots of messages, it never hanged (at least on recent 2.4 kernels, because very early 2.4 were a real pain with this one). Documentation states that this message should be very rare, and not spool off into the logs at this rate. perhaps you have a mix of small and large frames which makes the driver constantly change the fifo size, and this part is not handled properly ? Willy See http://www.ibiblio.org/mdw/HOWTO/Ethernet-HOWTO-8.html Jeff Willy Tarreau wrote: Hi Jeff, I've also experienced those messages under 2.4, but they were harmless, and I never had a machine hang even after weeks of full load (the adapter was mounted on a stress test machine before being used in firewalls for months). So I wonder how you can be sure that it is this driver which finally locks the bus. Perhaps the system locks for any other reason (eg: race condition). Have you tried with any other 4-port NIC (tulip or sun for example) ? Sun QFE would be the most interesting to test as it also supports 64 bits / 66 MHz. Regards, Willy On Sat, Apr 02, 2005 at 09:41:28PM -0700, jmerkey wrote: With linux 2.6.9 running at 192 MB/S network loading and protocol splitting drivers routing packets out of a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4 ports, the adaptec starfire driver goes into constant Tx FIFO reconfiguration mode and after 3-4 days of constantly resetting the Tx FIFO window and generating a deluge of messages such as: ethX: PCI bus congestion, resetting Tx FIFO window to X bytes pouring into the system log file at a rate of a dozen per minute. After several days, the PCI bus totally locks up and hangs the system. Need a config option to allow the starfire to disable this feature. At very high bus loading rates, the starfire card will completely lock the bus after 3-4 days of constant Tx FIFO reconfiguration at very high data rates with protocol splitting and routing. Jeff - 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/ - 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
David Lang wrote: On Sat, 2 Apr 2005, Andreas Dilger wrote: given that this would let you get the same storage with about 1200 fewer drives (with corresponding savings in raid controllers, fiberchannel controllers and rack frames) it would be interesting to know how close it would be (for a lot of people the savings, which probably are within spitting distance of $1M could be work the decrease in performance) For benchmarks like these, the issue isn't the storage capacity, but rather the ability to have lots of heads seeking concurrently to access the many database tables. At one large site I used to work at, the database ran on hundreds of 1, 2, and 4GB disks long after they could be replaced by many fewer, larger disks... I can understand this to a point, but it seems to me that after you get beyond some point you stop gaining from this (simply becouse you run out of bandwidth to keep all the heads busy). I would have guessed that this happened somewhere in the hundreds of drives rather then the thousands, so going from 1500x73G to 400x300G (even if this drops you from 15Krpm to 10Krpm) would still saturate the interface bandwidth before the drives But in this case probably not - Ken increases IO capacity until the CPUs become saturated. So there probably isn't a very large margin for error, you might need 2000 of the slower SATA disks to achieve a similar IOPS capacity. - 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 2.6.9 Adaptec 4 Port Starfire Sickness
On Sat, Apr 02, 2005 at 11:58:44PM -0700, jmerkey wrote: > > It works fine with the Intel Dual Port Pro-1000 MT adapters without > these problems. but unless I'm mistaken, there's no PCI bridge on this board, and it is possible that the two ports share the same IRQ, that's why I suggested trying a 4-port sun QFE or something which is more similar to the starfire. > I am using testing scenarios > with Jumbo Frames as well. I am guessing the PCI bus contention is high > due to the disk I/O bandwidth and > this is causing conditions the adapter does not normally see. As I said, I have been saturating this card for weeks during stress tests and although it spitted out lots of messages, it never hanged (at least on recent 2.4 kernels, because very early 2.4 were a real pain with this one). > Documentation states that this message should be very > rare, and not spool off into the logs at this rate. perhaps you have a mix of small and large frames which makes the driver constantly change the fifo size, and this part is not handled properly ? Willy > See http://www.ibiblio.org/mdw/HOWTO/Ethernet-HOWTO-8.html > > Jeff > > Willy Tarreau wrote: > > >Hi Jeff, > > > >I've also experienced those messages under 2.4, but they were harmless, > >and I never had a machine hang even after weeks of full load (the adapter > >was mounted on a stress test machine before being used in firewalls for > >months). > > > >So I wonder how you can be sure that it is this driver which finally > >locks > >the bus. Perhaps the system locks for any other reason (eg: race > >condition). > >Have you tried with any other 4-port NIC (tulip or sun for example) ? Sun > >QFE would be the most interesting to test as it also supports 64 bits / > >66 MHz. > > > >Regards, > >Willy > > > >On Sat, Apr 02, 2005 at 09:41:28PM -0700, jmerkey wrote: > > > > > >>With linux 2.6.9 running at 192 MB/S network loading and protocol > >>splitting drivers routing packets out of > >>a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4 > >>ports, the adaptec starfire driver goes into > >>constant Tx FIFO reconfiguration mode and after 3-4 days of constantly > >>resetting the Tx FIFO window and > >>generating a deluge of messages such as: > >> > >>ethX: PCI bus congestion, resetting Tx FIFO window to X bytes > >> > >>pouring into the system log file at a rate of a dozen per minute. > >>After several days, the PCI bus totally locks up > >>and hangs the system. Need a config option to allow the starfire to > >>disable this feature. At very > >>high bus loading rates, the starfire card will completely lock the bus > >>after 3-4 days > >>of constant Tx FIFO reconfiguration at very high data rates with > >>protocol splitting and routing. > >> > >>Jeff > >>- > >>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: Linux 2.6.9 Adaptec 4 Port Starfire Sickness
Jeff Garzik wrote: jmerkey wrote: With linux 2.6.9 running at 192 MB/S network loading and protocol splitting drivers routing packets out of a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4 ports, the adaptec starfire driver goes into constant Tx FIFO reconfiguration mode and after 3-4 days of constantly resetting the Tx FIFO window and generating a deluge of messages such as: ethX: PCI bus congestion, resetting Tx FIFO window to X bytes pouring into the system log file at a rate of a dozen per minute. After several days, the PCI bus totally locks up and hangs the system. Need a config option to allow the starfire to disable this feature. At very high bus loading rates, the starfire card will completely lock the bus after 3-4 days of constant Tx FIFO reconfiguration at very high data rates with protocol splitting and routing. The feature doesn't need disabling; just modify the driver to stop the flapping. Jeff I am going to try to just turn off the Tx FIFO setting in the code completely and see if this helps, not just the message. See what happens ... Jeff - 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 2.6.9 Adaptec 4 Port Starfire Sickness
It works fine with the Intel Dual Port Pro-1000 MT adapters without these problems. I am using testing scenarios with Jumbo Frames as well. I am guessing the PCI bus contention is high due to the disk I/O bandwidth and this is causing conditions the adapter does not normally see. Documentation states that this message should be very rare, and not spool off into the logs at this rate. See http://www.ibiblio.org/mdw/HOWTO/Ethernet-HOWTO-8.html Jeff Willy Tarreau wrote: Hi Jeff, I've also experienced those messages under 2.4, but they were harmless, and I never had a machine hang even after weeks of full load (the adapter was mounted on a stress test machine before being used in firewalls for months). So I wonder how you can be sure that it is this driver which finally locks the bus. Perhaps the system locks for any other reason (eg: race condition). Have you tried with any other 4-port NIC (tulip or sun for example) ? Sun QFE would be the most interesting to test as it also supports 64 bits / 66 MHz. Regards, Willy On Sat, Apr 02, 2005 at 09:41:28PM -0700, jmerkey wrote: With linux 2.6.9 running at 192 MB/S network loading and protocol splitting drivers routing packets out of a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4 ports, the adaptec starfire driver goes into constant Tx FIFO reconfiguration mode and after 3-4 days of constantly resetting the Tx FIFO window and generating a deluge of messages such as: ethX: PCI bus congestion, resetting Tx FIFO window to X bytes pouring into the system log file at a rate of a dozen per minute. After several days, the PCI bus totally locks up and hangs the system. Need a config option to allow the starfire to disable this feature. At very high bus loading rates, the starfire card will completely lock the bus after 3-4 days of constant Tx FIFO reconfiguration at very high data rates with protocol splitting and routing. Jeff - 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: Linux 2.6.9 Adaptec 4 Port Starfire Sickness
jmerkey wrote: With linux 2.6.9 running at 192 MB/S network loading and protocol splitting drivers routing packets out of a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4 ports, the adaptec starfire driver goes into constant Tx FIFO reconfiguration mode and after 3-4 days of constantly resetting the Tx FIFO window and generating a deluge of messages such as: ethX: PCI bus congestion, resetting Tx FIFO window to X bytes pouring into the system log file at a rate of a dozen per minute. After several days, the PCI bus totally locks up and hangs the system. Need a config option to allow the starfire to disable this feature. At very high bus loading rates, the starfire card will completely lock the bus after 3-4 days of constant Tx FIFO reconfiguration at very high data rates with protocol splitting and routing. The feature doesn't need disabling; just modify the driver to stop the flapping. Jeff - 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 Sat, 2 Apr 2005, Andreas Dilger wrote: given that this would let you get the same storage with about 1200 fewer drives (with corresponding savings in raid controllers, fiberchannel controllers and rack frames) it would be interesting to know how close it would be (for a lot of people the savings, which probably are within spitting distance of $1M could be work the decrease in performance) For benchmarks like these, the issue isn't the storage capacity, but rather the ability to have lots of heads seeking concurrently to access the many database tables. At one large site I used to work at, the database ran on hundreds of 1, 2, and 4GB disks long after they could be replaced by many fewer, larger disks... I can understand this to a point, but it seems to me that after you get beyond some point you stop gaining from this (simply becouse you run out of bandwidth to keep all the heads busy). I would have guessed that this happened somewhere in the hundreds of drives rather then the thousands, so going from 1500x73G to 400x300G (even if this drops you from 15Krpm to 10Krpm) would still saturate the interface bandwidth before the drives David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - 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: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> Just so as no else wastes time repeating the little bit I've done so
> far, and so I don't waste time figuring out what is already known,
> here's what I have so far, trying out Ingo's "sched: auto-tune
> migration costs" on ia64 SN2:
>
> To get it to compile against 2.6.12-rc1-mm4, I did thus:
>
> 1. Manually edited "include/asm-x86_64/topology.h" to
> remove .cache_hot_time (patch failed due to conflicts
> with nearby changes to add some *_idx terms).
(next time you can ignore that hunk - we override the cache_hot_time
value anyway.)
> 2. Moved the 394 line block of new code in kernel/sched.c
> to _before_ the large #ifdef ARCH_HAS_SCHED_DOMAIN,
> #else, #endif block. The ia64 arch (only) defines
> ARCH_HAS_SCHED_DOMAIN, so was being denied use of Ingo's
> code when it was buried in the '#else-#endif' side of
> this large conditional block.
yeah, indeed. The place you moved it to is the right spot, as it's under
CONFIG_SMP. I've done this in my tree too.
> 3. Add "#include " to kernel/sched.c
ok, did this in my tree too.
> 4. Don't print cpu_khz in the cost matrix header, as cpu_khz
> is only in a few arch's (x86_64, ppc, i386, arm).
ok.
> Brought up 8 CPUs
> softlockup thread 7 started up.
> Total of 8 processors activated (15548.60 BogoMIPS).
> -
> migration cost matrix (max_cache_size: 33554432):
> -
> [00][01][02][03][04][05][06][07]
> [00]: -
> = end =
>
> Then it hung for 5 or 10 minutes, [...]
the default on ia64 (32MB) was way too large and caused the search to
start from 64MB. That can take a _long_ time.
i've attached a new patch with your changes included, and a couple of
new things added:
- removed the 32MB max_cache_size hack from ia64 - it should now fall
back to the default 5MB and do a search from 10MB downwards. This
should speed up the search.
- added a migration_debug boot option - use it to get verbose printouts
about the search for the migration cost.
- added a max_cache_size= boot option for debugging.
- a few cleanups
(in the next iteration of the patch i'll try a new method to further
speed up the search - but didnt want to change it too much in this
iteration.)
> [] schedule_work+0x30/0x60
> sp=e1b03a8d7910 bsp=e1b03a8d14c8
> [] blank_screen_t+0x30/0x60
> sp=e1b03a8d7910 bsp=e1b03a8d14b8
> [] run_timer_softirq+0x2d0/0x4a0
> sp=e1b03a8d7910 bsp=e1b03a8d1410
i think the crash is an unrelated bug: it seems the screen blanking
timer hit and has crashed the box - i suspect it didnt expect the bootup
to take that long.
Ingo
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include
#include
@@ -4639,6 +4640,438 @@ void __devinit init_sched_build_groups(s
last->next = first;
}
+/*
+ * Self-tuning task migration cost measurement between source and target CPUs.
+ *
+ * This is done by measuring the cost of manipulating buffers of varying
+ * sizes. For a given buffer-size here are the steps that are taken:
+ *
+ * 1) the source CPU reads a big buffer to flush caches
+ * 2) the source CPU reads+dirties a shared buffer
+ * 3) the target CPU reads+dirties the same shared buffer
+ * 4) the target CPU reads a big buffer to flush caches
+ *
+ * We measure how long steps #2 and #3 take (step #1 and #4 is not
+ * measured), in the following 4 scenarios:
+ *
+ * - source: CPU1, target: CPU2 | cost1
+ * - source: CPU2, target: CPU1 | cost2
+ * - source: CPU1, target: CPU1 | cost3
+ * - source: CPU2, target: CPU2 | cost4
+ *
+ * We then calculate the cost3+cost4-cost1-cost2 difference - this is
+ * the cost of migration.
+ *
+ * We then start off from a large buffer-size and iterate down to smaller
+ * buffer sizes, in 5% steps - measuring each buffer-size separately, and
+ * do a maximum search for the cost. The maximum cost for a migration
+ * occurs when the working set is just below the effective cache size.
+ */
+
+
+/*
+ * Flush the cache by reading a big buffer. (We want all writeback
+ * activities to subside. Works only if cache size is larger than
+ * 2*size, but that is good enough as the biggest migration effect
+ * is around cachesize size.)
+ */
+__init static void read_cache(void *__cache, unsigned long __size)
+{
+ unsigned long size = __size/sizeof(long);
+ unsigned long *cache = __cache;
+ volatile unsigned long data;
+ int i;
+
+ for (i = 0; i < 2*size; i += 4)
+ data = cache[i];
+}
+
+
+/*
+ * Dirty a big buffer in a hard-to-predict (for the L2 cache) way. This
+ * is the operation that is timed, s
Re: kernel stack size
Steven Rostedt wrote: Have you benchmarked your own memory manager? kmalloc(1024, GFP_KERNEL) is something like 17 instructions on i386 uniprocessor. Where did you get that? I'm looking at the assembly of it right now and it's much larger than 17 instructions. Not to mention that it calls the slab functions which might have to invoke the buddy system. Have you looked at kmem_cache_alloc? kmalloc(1024, GFP_KERNEL) is compile-time replaced with the appropriate kmem_cache_alloc call. And the fast path within kmem_cache_alloc is 17 instructions long. Best case: uniprocessor, no regparams. Unfortunately with cli and popfd, thus something like 35 cpu cycles on an Athlon 64. I haven't clocked the speed of sem compared to kmalloc. But I would think that the sem functions are still quicker. Yes - sem or spin locks are quicker as long as no cache line transfers are necessary. If the semaphore is accessed by multiple cpus, then kmalloc would be faster: slab tries hard to avoid taking global locks. I'm not speaking about contention, just the cache line ping pong for acquiring a free semaphore. -- Manfred - 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 Apr 02, 2005 22:36 -0800, David Lang wrote: > On Fri, 1 Apr 2005, Chen, Kenneth W wrote: > >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 > > Ken, given that you don't have the bandwidth to keep all of those disks > fully utilized, do you have any idea how big a performance hit you would > take going to larger, but slower SATA drives? > > given that this would let you get the same storage with about 1200 fewer > drives (with corresponding savings in raid controllers, fiberchannel > controllers and rack frames) it would be interesting to know how close it > would be (for a lot of people the savings, which probably are within > spitting distance of $1M could be work the decrease in performance) For benchmarks like these, the issue isn't the storage capacity, but rather the ability to have lots of heads seeking concurrently to access the many database tables. At one large site I used to work at, the database ran on hundreds of 1, 2, and 4GB disks long after they could be replaced by many fewer, larger disks... Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, 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] Fix comment in list.h that refers to nonexistent API
The hlist_for_each_entry_rcu() comment block refers to a nonexistent hlist_add_rcu() API, needs to change to hlist_add_head_rcu(). Signed-off-by: <[EMAIL PROTECTED]> --- diff -urpN -X dontdiff linux-2.6.12-rc1/include/linux/list.h linux-2.6.12-rc1-bettersk/include/linux/list.h --- linux-2.6.12-rc1/include/linux/list.h Tue Mar 1 23:38:10 2005 +++ linux-2.6.12-rc1-bettersk/include/linux/list.h Sat Apr 2 12:19:50 2005 @@ -692,7 +692,7 @@ static inline void hlist_add_after(struc * @member:the name of the hlist_node within the struct. * * This list-traversal primitive may safely run concurrently with - * the _rcu list-mutation primitives such as hlist_add_rcu() + * the _rcu list-mutation primitives such as hlist_add_head_rcu() * as long as the traversal is guarded by rcu_read_lock(). */ #define hlist_for_each_entry_rcu(tpos, pos, head, member) \ - 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 4/4] Update RCU documentation
Update the RCU documentation to allow for the new synchronize_rcu() and
synchronize_sched() primitives. Fix a few other nits as well.
Signed-off-by: <[EMAIL PROTECTED]>
---
Depends on the earlier "Deprecate synchronize_kernel, GPL replacement" patch.
RTFP.txt | 29 +++--
UP.txt|8
checklist.txt | 47 ++-
listRCU.txt | 13 +
rcu.txt |4 +++-
5 files changed, 77 insertions(+), 24 deletions(-)
diff -urpN -X dontdiff linux-2.6.12-rc1/Documentation/RCU/RTFP.txt
linux-2.6.12-rc1-bettersk/Documentation/RCU/RTFP.txt
--- linux-2.6.12-rc1/Documentation/RCU/RTFP.txt Tue Mar 1 23:38:13 2005
+++ linux-2.6.12-rc1-bettersk/Documentation/RCU/RTFP.txtSat Apr 2
12:03:29 2005
@@ -108,8 +108,9 @@ year saw a paper describing an RCU imple
2004 has seen a Linux-Journal article on use of RCU in dcache
[McKenney04a], a performance comparison of locking to RCU on several
different CPUs [McKenney04b], a dissertation describing use of RCU in a
-number of operating-system kernels [PaulEdwardMcKenneyPhD], and a paper
-describing how to make RCU safe for soft-realtime applications [Sarma04c].
+number of operating-system kernels [PaulEdwardMcKenneyPhD], a paper
+describing how to make RCU safe for soft-realtime applications [Sarma04c],
+and a paper describing SELinux performance with RCU [JamesMorris04b].
Bibtex Entries
@@ -341,6 +342,17 @@ Dipankar Sarma"
,pages="18-26"
}
[EMAIL PROTECTED]
+,author="Stuart A. Friedberg"
+,title="Lock-Free Wild Card Search Data Structure and Method"
+,institution="US Patent and Trademark Office"
+,address="Washington, DC"
+,year="2003"
+,number="US Patent 6,662,184 (contributed under GPL)"
+,month="December"
+,pages="112"
+}
+
@article{McKenney04a
,author="Paul E. McKenney and Dipankar Sarma and Maneesh Soni"
,title="Scaling dcache with {RCU}"
@@ -373,6 +385,9 @@ in Operating System Kernels"
,school="OGI School of Science and Engineering at
Oregon Health and Sciences University"
,year="2004"
+,note="Available:
+\url{http://www.rdrop.com/users/paulmck/RCU/RCUdissertation.2004.07.14e1.pdf}
+[Viewed October 15, 2004]"
}
@Conference{Sarma04c
@@ -384,4 +399,14 @@ Oregon Health and Sciences University"
,year="2004"
,month="June"
,pages="182-191"
+}
+
[EMAIL PROTECTED]
+,Author="James Morris"
+,Title="Recent Developments in {SELinux} Kernel Performance"
+,month="December"
+,year="2004"
+,note="Available:
+\url{http://www.livejournal.com/users/james_morris/2153.html}
+[Viewed December 10, 2004]"
}
diff -urpN -X dontdiff linux-2.6.12-rc1/Documentation/RCU/UP.txt
linux-2.6.12-rc1-bettersk/Documentation/RCU/UP.txt
--- linux-2.6.12-rc1/Documentation/RCU/UP.txt Tue Mar 1 23:37:54 2005
+++ linux-2.6.12-rc1-bettersk/Documentation/RCU/UP.txt Sat Apr 2 12:04:09 2005
@@ -2,11 +2,11 @@ RCU on Uniprocessor Systems
A common misconception is that, on UP systems, the call_rcu() primitive
-may immediately invoke its function, and that the synchronize_kernel
+may immediately invoke its function, and that the synchronize_rcu()
primitive may return immediately. The basis of this misconception
is that since there is only one CPU, it should not be necessary to
wait for anything else to get done, since there are no other CPUs for
-anything else to be happening on. Although this approach will sort of
+anything else to be happening on. Although this approach will -sort- -of-
work a surprising amount of the time, it is a very bad idea in general.
This document presents two examples that demonstrate exactly how bad an
idea this is.
@@ -44,14 +44,14 @@ its arguments would cause it to fail to
underlying RCU, namely that call_rcu() defers invoking its arguments until
all RCU read-side critical sections currently executing have completed.
-Quick Quiz: why is it -not- legal to invoke synchronize_kernel() in
+Quick Quiz: why is it -not- legal to invoke synchronize_rcu() in
this case?
Summary
Permitting call_rcu() to immediately invoke its arguments or permitting
-synchronize_kernel() to immediately return breaks RCU, even on a UP system.
+synchronize_rcu() to immediately return breaks RCU, even on a UP system.
So do not do it! Even on a UP system, the RCU infrastructure -must-
respect grace periods.
diff -urpN -X dontdiff linux-2.6.12-rc1/Documentation/RCU/checklist.txt
linux-2.6.12-rc1-bettersk/Documentation/RCU/checklist.txt
--- linux-2.6.12-rc1/Documentation/RCU/checklist.txtTue Mar 1 23:38:13 2005
+++ linux-2.6.12-rc1-bettersk/Documentation/RCU/checklist.txt Sat Apr 2
12:30:50 2005
@@ -32,7 +32,10 @@ over a rather long period of time, but i
them -- even x86 allows reads to be reordered), and be prepared
to explain why this added complexity is worthwhile. If you
choose #c, be prepared to explain how this single task does not
- become a major bottleneck on big multiprocessor machines.
+ become
RE: Industry db benchmark result on recent 2.6 kernels
On Fri, 1 Apr 2005, Chen, Kenneth W wrote: 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 Ken, given that you don't have the bandwidth to keep all of those disks fully utilized, do you have any idea how big a performance hit you would take going to larger, but slower SATA drives? given that this would let you get the same storage with about 1200 fewer drives (with corresponding savings in raid controllers, fiberchannel controllers and rack frames) it would be interesting to know how close it would be (for a lot of people the savings, which probably are within spitting distance of $1M could be work the decrease in performance) David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCH 1/4] Add deprecated_for_modules
On Sun, Apr 03, 2005 at 08:18:11AM +0200, Arjan van de Ven wrote:
> On Sat, 2005-04-02 at 22:11 -0800, Paul E. McKenney wrote:
> > Add a deprecated_for_modules macro that allows symbols to be
>
>
> > +#ifdef MODULE
> > +#define deprecated_for_modules __deprecated
> > +#else
> > +#define deprecated_for_modules
> > +#endif
> > +
>
> how about also starting it with __ like __deprecated is ?
Good point, how about the following? This changes patch 2/4 as well,
have included both below.
Thanx, Paul
Signed-off-by: <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.12-rc1/include/linux/module.h
linux-2.6.12-rc1-bettersk/include/linux/module.h
--- linux-2.6.12-rc1/include/linux/module.h Thu Mar 31 09:53:20 2005
+++ linux-2.6.12-rc1-bettersk/include/linux/module.hSat Apr 2 11:47:43 2005
@@ -195,6 +195,12 @@ void *__symbol_get_gpl(const char *symbo
#define EXPORT_SYMBOL_GPL(sym) \
__EXPORT_SYMBOL(sym, "_gpl")
+#ifdef MODULE
+#define __deprecated_for_modules __deprecated
+#else
+#define __deprecated_for_modules
+#endif
+
#endif
struct module_ref
diff -urpN -X dontdiff linux-2.6.12-rc1/include/linux/rcupdate.h
linux-2.6.12-rc1-bettersk/include/linux/rcupdate.h
--- linux-2.6.12-rc1/include/linux/rcupdate.h Tue Mar 1 23:37:50 2005
+++ linux-2.6.12-rc1-bettersk/include/linux/rcupdate.h Sat Apr 2 13:06:15 2005
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
/**
* struct rcu_head - callback structure for use with RCU
@@ -157,9 +158,9 @@ static inline int rcu_pending(int cpu)
/**
* rcu_read_lock - mark the beginning of an RCU read-side critical section.
*
- * When synchronize_kernel() is invoked on one CPU while other CPUs
+ * When synchronize_rcu() is invoked on one CPU while other CPUs
* are within RCU read-side critical sections, then the
- * synchronize_kernel() is guaranteed to block until after all the other
+ * synchronize_rcu() is guaranteed to block until after all the other
* CPUs exit their critical sections. Similarly, if call_rcu() is invoked
* on one CPU while other CPUs are within RCU read-side critical
* sections, invocation of the corresponding RCU callback is deferred
@@ -256,6 +257,21 @@ static inline int rcu_pending(int cpu)
(p) = (v); \
})
+/**
+ * synchronize_sched - block until all CPUs have exited any non-preemptive
+ * kernel code sequences.
+ *
+ * This means that all preempt_disable code sequences, including NMI and
+ * hardware-interrupt handlers, in progress on entry will have completed
+ * before this primitive returns. However, this does not guarantee that
+ * softirq handlers will have completed, since in some kernels
+ *
+ * This primitive provides the guarantees made by the (deprecated)
+ * synchronize_kernel() API. In contrast, synchronize_rcu() only
+ * guarantees that rcu_read_lock() sections will have completed.
+ */
+#define synchronize_sched() synchronize_rcu()
+
extern void rcu_init(void);
extern void rcu_check_callbacks(int cpu, int user);
extern void rcu_restart_cpu(int cpu);
@@ -265,7 +281,9 @@ extern void FASTCALL(call_rcu(struct rcu
void (*func)(struct rcu_head *head)));
extern void FASTCALL(call_rcu_bh(struct rcu_head *head,
void (*func)(struct rcu_head *head)));
-extern void synchronize_kernel(void);
+extern __deprecated_for_modules void synchronize_kernel(void);
+extern void synchronize_rcu(void);
+void synchronize_idle(void);
#endif /* __KERNEL__ */
#endif /* __LINUX_RCUPDATE_H */
diff -urpN -X dontdiff linux-2.6.12-rc1/kernel/rcupdate.c
linux-2.6.12-rc1-bettersk/kernel/rcupdate.c
--- linux-2.6.12-rc1/kernel/rcupdate.c Tue Mar 1 23:37:30 2005
+++ linux-2.6.12-rc1-bettersk/kernel/rcupdate.c Sat Apr 2 13:10:09 2005
@@ -444,15 +444,18 @@ static void wakeme_after_rcu(struct rcu_
}
/**
- * synchronize_kernel - wait until a grace period has elapsed.
+ * synchronize_rcu - wait until a grace period has elapsed.
*
* Control will return to the caller some time after a full grace
* period has elapsed, in other words after all currently executing RCU
* read-side critical sections have completed. RCU read-side critical
* sections are delimited by rcu_read_lock() and rcu_read_unlock(),
* and may be nested.
+ *
+ * If your read-side code is not protected by rcu_read_lock(), do -not-
+ * use synchronize_rcu().
*/
-void synchronize_kernel(void)
+void synchronize_rcu(void)
{
struct rcu_synchronize rcu;
@@ -464,7 +467,16 @@ void synchronize_kernel(void)
wait_for_completion(&rcu.completion);
}
+/*
+ * Deprecated, use synchronize_rcu() or synchronize_sched() instead.
+ */
+void synchronize_kernel(void)
+{
+ synchronize_rcu();
+}
+
module_param(maxbatch, int, 0);
EXPORT_SYMBOL(call_rcu);
EXPORT_SYMBOL(call_rcu_bh);
+EXPORT_SYMBOL_
[RFC,PATCH 3/4] Change synchronize_kernel to _rcu and _sched
This patch changes calls to synchronize_kernel(), deprecated in the
earlier "Deprecate synchronize_kernel, GPL replacement" patch to
instead call the new synchronize_rcu() and synchronize_sched() APIs.
Signed-off-by: <[EMAIL PROTECTED]>
---
arch/i386/oprofile/nmi_timer_int.c |2 +-
arch/ppc64/kernel/HvLpEvent.c |2 +-
arch/x86_64/kernel/mce.c |2 +-
drivers/acpi/processor_idle.c |2 +-
drivers/char/ipmi/ipmi_si_intf.c |4 ++--
drivers/input/keyboard/atkbd.c |2 +-
drivers/md/multipath.c |2 +-
drivers/md/raid1.c |2 +-
drivers/md/raid10.c|2 +-
drivers/md/raid5.c |2 +-
drivers/md/raid6main.c |2 +-
drivers/net/r8169.c|2 +-
drivers/s390/cio/airq.c|4 ++--
kernel/module.c|2 +-
kernel/profile.c |2 +-
mm/slab.c |2 +-
net/core/dev.c |2 +-
17 files changed, 19 insertions(+), 19 deletions(-)
diff -urpN -X dontdiff linux-2.6.12-rc1/arch/i386/oprofile/nmi_timer_int.c
linux-2.6.12-rc1-bettersk/arch/i386/oprofile/nmi_timer_int.c
--- linux-2.6.12-rc1/arch/i386/oprofile/nmi_timer_int.c Tue Mar 1 23:37:52 2005
+++ linux-2.6.12-rc1-bettersk/arch/i386/oprofile/nmi_timer_int.cFri Apr
1 21:03:57 2005
@@ -36,7 +36,7 @@ static void timer_stop(void)
{
enable_timer_nmi_watchdog();
unset_nmi_callback();
- synchronize_kernel();
+ synchronize_sched(); /* Allow already-started NMIs to complete. */
}
diff -urpN -X dontdiff linux-2.6.12-rc1/arch/ppc64/kernel/HvLpEvent.c
linux-2.6.12-rc1-bettersk/arch/ppc64/kernel/HvLpEvent.c
--- linux-2.6.12-rc1/arch/ppc64/kernel/HvLpEvent.c Tue Mar 1 23:38:09 2005
+++ linux-2.6.12-rc1-bettersk/arch/ppc64/kernel/HvLpEvent.c Fri Apr 1
20:54:40 2005
@@ -45,7 +45,7 @@ int HvLpEvent_unregisterHandler( HvLpEve
/* We now sleep until all other CPUs have scheduled.
This ensures that
* the deletion is seen by all other CPUs, and that the
deleted handler
* isn't still running on another CPU when we return. */
- synchronize_kernel();
+ synchronize_rcu();
}
}
return rc;
diff -urpN -X dontdiff linux-2.6.12-rc1/arch/x86_64/kernel/mce.c
linux-2.6.12-rc1-bettersk/arch/x86_64/kernel/mce.c
--- linux-2.6.12-rc1/arch/x86_64/kernel/mce.c Tue Mar 1 23:37:52 2005
+++ linux-2.6.12-rc1-bettersk/arch/x86_64/kernel/mce.c Fri Apr 1 21:03:01 2005
@@ -392,7 +392,7 @@ static ssize_t mce_read(struct file *fil
memset(mcelog.entry, 0, next * sizeof(struct mce));
mcelog.next = 0;
- synchronize_kernel();
+ synchronize_sched(); /* Allow all already-started MCEs to complete. */
/* Collect entries that were still getting written before the
synchronize. */
diff -urpN -X dontdiff linux-2.6.12-rc1/drivers/acpi/processor_idle.c
linux-2.6.12-rc1-bettersk/drivers/acpi/processor_idle.c
--- linux-2.6.12-rc1/drivers/acpi/processor_idle.c Tue Mar 1 23:38:25 2005
+++ linux-2.6.12-rc1-bettersk/drivers/acpi/processor_idle.c Sat Apr 2
10:57:37 2005
@@ -838,7 +838,7 @@ int acpi_processor_cst_has_changed (stru
/* Fall back to the default idle loop */
pm_idle = pm_idle_save;
- synchronize_kernel();
+ synchronize_sched(); /* Relies on interrupts forcing exit from idle. */
pr->flags.power = 0;
result = acpi_processor_get_power_info(pr);
diff -urpN -X dontdiff linux-2.6.12-rc1/drivers/char/ipmi/ipmi_si_intf.c
linux-2.6.12-rc1-bettersk/drivers/char/ipmi/ipmi_si_intf.c
--- linux-2.6.12-rc1/drivers/char/ipmi/ipmi_si_intf.c Thu Mar 31 09:53:02 2005
+++ linux-2.6.12-rc1-bettersk/drivers/char/ipmi/ipmi_si_intf.c Fri Apr 1
20:44:59 2005
@@ -2194,7 +2194,7 @@ static int init_one_smi(int intf_num, st
/* Wait until we know that we are out of any interrupt
handlers might have been running before we freed the
interrupt. */
- synchronize_kernel();
+ synchronize_sched();
if (new_smi->si_sm) {
if (new_smi->handlers)
@@ -2307,7 +2307,7 @@ static void __exit cleanup_one_si(struct
/* Wait until we know that we are out of any interrupt
handlers might have been running before we freed the
interrupt. */
- synchronize_kernel();
+ synchronize_sched();
/* Wait for the timer to stop. This avoids problems with race
conditions removing the timer here. */
diff -urpN -X dontdiff linux-2.6.12-rc1/drivers/input/keyboard/atkbd.c
linux-2.6.12-rc1-bettersk/drivers/input/keyboard/atkbd.c
--- linux-2.6.12-rc1/drivers/input/keyboard/atkbd.c Thu Mar 31 09:53:04 2005
+++ linux-2.6.12-rc1-bettersk/drivers/input/keyboard/atkbd.cFri Apr 1
21:18:07 200
[RFC,PATCH 2/4] Deprecate synchronize_kernel, GPL replacement
The synchronize_kernel() primitive is used for quite a few different
purposes: waiting for RCU readers, waiting for NMIs, waiting for interrupts,
and so on. This makes RCU code harder to read, since synchronize_kernel()
might or might not have matching rcu_read_lock()s. This patch creates
a new synchronize_rcu() that is to be used for RCU readers and a new
synchronize_sched() that is used for the rest. These two new primitives
currently have the same implementation, but this is might well change
with additional real-time support. Both new primitives are GPL-only,
the old primitive is deprecated.
Signed-off-by: <[EMAIL PROTECTED]>
---
Depends on earlier "Add deprecated_for_modules" patch.
include/linux/rcupdate.h | 24 +---
kernel/rcupdate.c| 16 ++--
2 files changed, 35 insertions(+), 5 deletions(-)
diff -urpN -X dontdiff linux-2.6.12-rc1/include/linux/rcupdate.h
linux-2.6.12-rc1-bettersk/include/linux/rcupdate.h
--- linux-2.6.12-rc1/include/linux/rcupdate.h Tue Mar 1 23:37:50 2005
+++ linux-2.6.12-rc1-bettersk/include/linux/rcupdate.h Sat Apr 2 13:06:15 2005
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
/**
* struct rcu_head - callback structure for use with RCU
@@ -157,9 +158,9 @@ static inline int rcu_pending(int cpu)
/**
* rcu_read_lock - mark the beginning of an RCU read-side critical section.
*
- * When synchronize_kernel() is invoked on one CPU while other CPUs
+ * When synchronize_rcu() is invoked on one CPU while other CPUs
* are within RCU read-side critical sections, then the
- * synchronize_kernel() is guaranteed to block until after all the other
+ * synchronize_rcu() is guaranteed to block until after all the other
* CPUs exit their critical sections. Similarly, if call_rcu() is invoked
* on one CPU while other CPUs are within RCU read-side critical
* sections, invocation of the corresponding RCU callback is deferred
@@ -256,6 +257,21 @@ static inline int rcu_pending(int cpu)
(p) = (v); \
})
+/**
+ * synchronize_sched - block until all CPUs have exited any non-preemptive
+ * kernel code sequences.
+ *
+ * This means that all preempt_disable code sequences, including NMI and
+ * hardware-interrupt handlers, in progress on entry will have completed
+ * before this primitive returns. However, this does not guarantee that
+ * softirq handlers will have completed, since in some kernels
+ *
+ * This primitive provides the guarantees made by the (deprecated)
+ * synchronize_kernel() API. In contrast, synchronize_rcu() only
+ * guarantees that rcu_read_lock() sections will have completed.
+ */
+#define synchronize_sched() synchronize_rcu()
+
extern void rcu_init(void);
extern void rcu_check_callbacks(int cpu, int user);
extern void rcu_restart_cpu(int cpu);
@@ -265,7 +281,9 @@ extern void FASTCALL(call_rcu(struct rcu
void (*func)(struct rcu_head *head)));
extern void FASTCALL(call_rcu_bh(struct rcu_head *head,
void (*func)(struct rcu_head *head)));
-extern void synchronize_kernel(void);
+extern deprecated_for_modules void synchronize_kernel(void);
+extern void synchronize_rcu(void);
+void synchronize_idle(void);
#endif /* __KERNEL__ */
#endif /* __LINUX_RCUPDATE_H */
diff -urpN -X dontdiff linux-2.6.12-rc1/kernel/rcupdate.c
linux-2.6.12-rc1-bettersk/kernel/rcupdate.c
--- linux-2.6.12-rc1/kernel/rcupdate.c Tue Mar 1 23:37:30 2005
+++ linux-2.6.12-rc1-bettersk/kernel/rcupdate.c Sat Apr 2 13:10:09 2005
@@ -444,15 +444,18 @@ static void wakeme_after_rcu(struct rcu_
}
/**
- * synchronize_kernel - wait until a grace period has elapsed.
+ * synchronize_rcu - wait until a grace period has elapsed.
*
* Control will return to the caller some time after a full grace
* period has elapsed, in other words after all currently executing RCU
* read-side critical sections have completed. RCU read-side critical
* sections are delimited by rcu_read_lock() and rcu_read_unlock(),
* and may be nested.
+ *
+ * If your read-side code is not protected by rcu_read_lock(), do -not-
+ * use synchronize_rcu().
*/
-void synchronize_kernel(void)
+void synchronize_rcu(void)
{
struct rcu_synchronize rcu;
@@ -464,7 +467,16 @@ void synchronize_kernel(void)
wait_for_completion(&rcu.completion);
}
+/*
+ * Deprecated, use synchronize_rcu() or synchronize_sched() instead.
+ */
+void synchronize_kernel(void)
+{
+ synchronize_rcu();
+}
+
module_param(maxbatch, int, 0);
EXPORT_SYMBOL(call_rcu);
EXPORT_SYMBOL(call_rcu_bh);
+EXPORT_SYMBOL_GPL(synchronize_rcu);
EXPORT_SYMBOL(synchronize_kernel);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCH 1/4] Add deprecated_for_modules
On Sat, 2005-04-02 at 22:11 -0800, Paul E. McKenney wrote: > Add a deprecated_for_modules macro that allows symbols to be > +#ifdef MODULE > +#define deprecated_for_modules __deprecated > +#else > +#define deprecated_for_modules > +#endif > + how about also starting it with __ like __deprecated 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/
[RFC,PATCH 1/4] Add deprecated_for_modules
Add a deprecated_for_modules macro that allows symbols to be deprecated only when used by modules, as suggested by Andrew Morton some months back. Signed-off-by: <[EMAIL PROTECTED]> --- diff -urpN -X dontdiff linux-2.6.12-rc1/include/linux/module.h linux-2.6.12-rc1-bettersk/include/linux/module.h --- linux-2.6.12-rc1/include/linux/module.h Thu Mar 31 09:53:20 2005 +++ linux-2.6.12-rc1-bettersk/include/linux/module.hSat Apr 2 11:47:43 2005 @@ -195,6 +195,12 @@ void *__symbol_get_gpl(const char *symbo #define EXPORT_SYMBOL_GPL(sym) \ __EXPORT_SYMBOL(sym, "_gpl") +#ifdef MODULE +#define deprecated_for_modules __deprecated +#else +#define deprecated_for_modules +#endif + #endif struct module_ref - 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 patch] kernel/rcupdate.c: make the exports EXPORT_SYMBOL_GPL
On Sun, Mar 27, 2005 at 04:34:54PM +0200, Adrian Bunk wrote: > Due to the patent situation at least in the USA, the exports of > kernel/rcupdate.c should be EXPORT_SYMBOL_GPL. Based on -what- line of reasoning??? The obvious ones do not apply to this situation. These need to be put back. Moving them to GPL -- but in a measured manner, as I proposed on this list some months ago -- is fine. Changing these particular exports precipitously is most definitely -not- fine. Here is my earlier proposal: http://marc.theaimsgroup.com/?l=linux-kernel&m=110520930301813&w=2 See below for a patch that puts the exports back, along with an updated version of my earlier patch that starts the process of moving them to GPL. I will also be following this message with RFC patches that introduce two (EXPORT_SYMBOL_GPL) interfaces to replace synchronize_kernel(), which then becomes deprecated. Andrew, please apply. Thanx, Paul Signed-off-by: <[EMAIL PROTECTED]> diff -urpN -X ../dontdiff linux-2.5-notyet/kernel/rcupdate.c linux-2.5/kernel/rcupdate.c --- linux-2.5-notyet/kernel/rcupdate.c Sat Apr 2 17:15:14 2005 +++ linux-2.5/kernel/rcupdate.c Sat Apr 2 07:54:30 2005 @@ -465,6 +465,6 @@ void synchronize_kernel(void) } module_param(maxbatch, int, 0); -EXPORT_SYMBOL_GPL(call_rcu); -EXPORT_SYMBOL_GPL(call_rcu_bh); -EXPORT_SYMBOL_GPL(synchronize_kernel); +EXPORT_SYMBOL(call_rcu); /* WARNING: GPL-only in April 2006. */ +EXPORT_SYMBOL(call_rcu_bh); /* WARNING: GPL-only in April 2006. */ +EXPORT_SYMBOL(synchronize_kernel); /* WARNING: GPL-only in April 2006. */ diff -urpN -X ../dontdiff linux-2.5-2005.04.02/Documentation/feature-removal-schedule.txt linux-2.5-2005.04.02-01/Documentation/feature-removal-schedule.txt --- linux-2.5-2005.04.02/Documentation/feature-removal-schedule.txt Sat Apr 2 07:48:46 2005 +++ linux-2.5-2005.04.02-01/Documentation/feature-removal-schedule.txt Sat Apr 2 21:16:24 2005 @@ -15,3 +15,16 @@ Why: It has been unmaintained for a numb against the LSB, and can be replaced by using udev. Who: Greg Kroah-Hartman <[EMAIL PROTECTED]> +What: RCU API moves to EXPORT_SYMBOL_GPL +When: April 2006 +Files: include/linux/rcupdate.h, kernel/rcupdate.c +Why: Outside of Linux, the only implementations of anything even + vaguely resembling RCU that I am aware of are in DYNIX/ptx, + VM/XA, Tornado, and K42. I do not expect anyone to port binary + drivers or kernel modules from any of these, since the first two + are owned by IBM and the last two are open-source research OSes. + So these will move to GPL after a grace period to allow + people, who might be using implementations that I am not aware + of, to adjust to this upcoming change. +Who: Paul E. McKenney <[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: linux-2.6.12-rc1-mm4-RT-V0.7.42-08
Hi Ingo,
I need the following two patches to keep my system alive and avoid
the BUGs in the log send to you earlier (private mail).
--- example BUG
BUG: using smp_processor_id() in preemptible [0001] code: java/16460
caller is icmp_send+0x9b/0x3d0
[] smp_processor_id+0x9b/0xb0 (8)
[] icmp_send+0x9b/0x3d0 (28)
[] check_wakeup_timing+0x47/0x160 (8)
[] _raw_spin_unlock+0xd/0x30 (40)
[] kmem_cache_free+0x39/0x120 (8)
[] _raw_spin_unlock+0xd/0x30 (12)
[] kmem_cache_free+0x39/0x120 (8)
[] _raw_spin_unlock+0xd/0x30 (24)
[] _raw_spin_unlock+0xd/0x30 (28)
[] rtl8139_start_xmit+0x86/0x1d0 (8)
[] _raw_spin_unlock+0xd/0x30 (40)
[] qdisc_restart+0x1b9/0x230 (8)
[] qdisc_restart+0x1b9/0x230 (36)
[] _raw_spin_unlock+0xd/0x30 (8)
[] rtl8139_start_xmit+0xce/0x1d0 (16)
[] _raw_spin_unlock+0xd/0x30 (32)
[] ip_fragment+0x663/0x7f0 (60)
[] rcu_read_unlock+0x5f/0x70 (32)
[] __ip_route_output_key+0xba/0xe0 (8)
[] ip_finish_output+0x0/0x2f0 (16)
[] ip_queue_xmit+0x263/0x590 (24)
[] ip_queue_xmit+0x263/0x590 (20)
[] tcp_transmit_skb+0x38b/0x750 (196)
[] tcp_write_xmit+0x10e/0x2f0 (56)
[] tcp_sendmsg+0xffb/0x1050 (52)
[] _raw_spin_unlock+0xd/0x30 (12)
[] unqueue_me+0x25/0x130 (8)
[] inet_sendmsg+0x4a/0x70 (92)
[] sock_aio_write+0x135/0x150 (24)
[] _raw_spin_unlock+0xd/0x30 (88)
[] do_sync_write+0xb9/0x110 (20)
[] _raw_spin_unlock+0xd/0x30 (44)
[] fget_light+0x62/0x90 (8)
[] _raw_spin_unlock+0xd/0x30 (44)
[] autoremove_wake_function+0x0/0x50 (8)
[] vfs_write+0xdb/0x170 (52)
[] sys_write+0x41/0x70 (24)
[] sysenter_past_esp+0x54/0x75 (28)
---
| preempt count: 0002 ]
| 2-level deep critical section nesting:
.. [] _raw_spin_lock+0x16/0x90
.[<>] .. ( <= 0x0)
.. [] _raw_spin_lock+0x16/0x90
.[<>] .. ( <= 0x0)
--
Peter Zijlstra <[EMAIL PROTECTED]>
Since there is no lock held yet we are still preemptable; and since
icmp_socket is a per cpu variable switching cpus gives weird results.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
--- /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp.c~ 2005-03-25 10:14:32.0 +0100
+++ /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp.c 2005-04-02 18:58:19.0 +0200
@@ -376,8 +376,8 @@
static void icmp_reply(struct icmp_bxm *icmp_param, struct sk_buff *skb)
{
- struct sock *sk = icmp_socket->sk;
- struct inet_sock *inet = inet_sk(sk);
+ struct sock *sk;
+ struct inet_sock *inet;
struct ipcm_cookie ipc;
struct rtable *rt = (struct rtable *)skb->dst;
u32 daddr;
@@ -388,6 +388,9 @@
if (icmp_xmit_lock())
return;
+ sk = icmp_socket->sk;
+ inet = inet_sk(sk);
+
icmp_param->data.icmph.checksum = 0;
icmp_out_count(icmp_param->data.icmph.type);
Since on PREEMPT_RT spinlocks allow preemption, it's possible to
change cpu at (almost) any point in time. Make sure we stick to
the per cpu variable we started with.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
--- /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp_orig.c 2005-04-03 00:09:08.0 +0200
+++ /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp.c 2005-04-03 00:20:22.0 +0200
@@ -228,27 +228,32 @@
*
* On SMP we have one ICMP socket per-cpu.
*/
-static DEFINE_PER_CPU(struct socket *, __icmp_socket) = NULL;
-#define icmp_socket __get_cpu_var(__icmp_socket)
+static DEFINE_PER_CPU_LOCKED(struct socket *, __icmp_socket) = NULL;
static __inline__ struct socket * icmp_xmit_lock(int cpu)
{
+ struct socket *icmp_socket;
+
local_bh_disable();
+ icmp_socket = get_cpu_var_locked(__icmp_socket, cpu);
if (unlikely(!spin_trylock(&icmp_socket->sk->sk_lock.slock))) {
/* This can happen if the output path signals a
* dst_link_failure() for an outgoing ICMP packet.
*/
+ put_cpu_var_locked(__icmp_socket, cpu);
local_bh_enable();
- return 1;
+ return NULL;
}
- return 0;
+ return icmp_socket;
}
static void icmp_xmit_unlock(int cpu)
{
+ struct socket *icmp_socket = __get_cpu_var_locked(__icmp_socket, cpu);
spin_unlock_bh(&icmp_socket->sk->sk_lock.slock);
+ put_cpu_var_locked(__icmp_socket, cpu);
}
/*
@@ -345,7 +350,8 @@
}
static void icmp_push_reply(struct icmp_bxm *icmp_param,
- struct ipcm_cookie *ipc, struct rtable *rt)
+ struct ipcm_cookie *ipc, struct rtable *rt,
+struct socket *icmp_socket)
{
struct sk_buff *skb;
@@ -377,16 +383,19 @@
static void icmp_reply(struct icmp_bxm *icmp_param, struct sk_buff *skb)
{
+ struct socket *icmp_socket;
struct sock *sk;
struct inet_sock *inet;
struct ipcm_cookie ipc;
struct rtable *rt = (struct rtable *)skb->dst;
u32 daddr;
+ int cpu;
if (ip_options_echo(&icmp_param->replyopts, skb))
goto out;
- if (icmp_xmit_lock())
+ cpu = _smp_processor_id();
+ if (!(icmp_socket = icmp_xmit_lock(cpu)))
return;
sk = icmp_socket->sk;
@@ -414,10 +423,10 @@
}
if (icmpv4_xr
Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
Just so as no else wastes time repeating the little bit I've done so far, and so I don't waste time figuring out what is already known, here's what I have so far, trying out Ingo's "sched: auto-tune migration costs" on ia64 SN2: To get it to compile against 2.6.12-rc1-mm4, I did thus: 1. Manually edited "include/asm-x86_64/topology.h" to remove .cache_hot_time (patch failed due to conflicts with nearby changes to add some *_idx terms). 2. Moved the 394 line block of new code in kernel/sched.c to _before_ the large #ifdef ARCH_HAS_SCHED_DOMAIN, #else, #endif block. The ia64 arch (only) defines ARCH_HAS_SCHED_DOMAIN, so was being denied use of Ingo's code when it was buried in the '#else-#endif' side of this large conditional block. 3. Add "#include " to kernel/sched.c 4. Don't print cpu_khz in the cost matrix header, as cpu_khz is only in a few arch's (x86_64, ppc, i386, arm). Note that (2) was just a superficial fix - it compiles, but the result could easily be insanely stupid and I'd have no clue. I need to read the code some more. Booting on an 8 CPU ia64 SN2, the console output got far enough to show: begin Brought up 8 CPUs softlockup thread 7 started up. Total of 8 processors activated (15548.60 BogoMIPS). - migration cost matrix (max_cache_size: 33554432): - [00][01][02][03][04][05][06][07] [00]: - = end = Then it hung for 5 or 10 minutes, and then it blurted out a panic and died. I'll quote the whole panic, including backtrace, in case someone happens to see something obvious. But I'm not asking anyone to think about this yet, unless it amuses them. I can usefully occupy myself reading the code and adding printk's for a while. Note the first 3 chars of the panic message "4.5". This looks like it might be the [00]-[01] entry of Ingo's table, flushed out when the newlines of the panic came through. begin 4.5(0)<1>Unable to handle kernel paging request at virtual address 00010008 swapper[1]: Oops 8813272891392 [1] Modules linked in: Pid: 1, CPU 0, comm: swapper psr : 101008026018 ifs : 8288 ip : []Not tainted ip is at queue_work+0xb0/0x1a0 unat: pfs : 0288 rsc : 0003 rnat: a00100ab2a50 bsps: 0010 pr : 5a6956996a65 ldrs: ccv : fpsr: 0009804c8a70033f csd : ssd : b0 : a001000d99b0 b6 : a0013320 b7 : a00100490200 f6 : 1003e9ff7 f7 : 1003e000418d3645db265 f8 : 1003e3b8186ed f9 : 1003e5f3b f10 : 1003e1000 f11 : 1003e0040 r1 : a00100c9de60 r2 : r3 : 0001 r8 : r9 : r10 : a00100969c50 r11 : 0004 r12 : e1b03a8d7910 r13 : e1b03a8d r14 : r15 : 00010008 r16 : e1b03a8d0dc0 r17 : 00010008 r18 : 0103 r19 : a00100c32048 r20 : a00100c32018 r21 : a00100aa92c8 r22 : e03003005d90 r23 : e03003005da8 r24 : a00100cf2098 r25 : e03003005db0 r26 : a00100ab4bf4 r27 : e03003005d81 r28 : 00010004b001 r29 : r30 : 00010004b000 r31 : a00100c32010 Call Trace: [] show_stack+0x80/0xa0 sp=e1b03a8d74d0 bsp=e1b03a8d1620 [] show_regs+0x860/0x880 sp=e1b03a8d76a0 bsp=e1b03a8d15b8 [] die+0x170/0x200 sp=e1b03a8d76b0 bsp=e1b03a8d1580 [] ia64_do_page_fault+0x200/0xa40 sp=e1b03a8d76b0 bsp=e1b03a8d1520 [] ia64_leave_kernel+0x0/0x290 sp=e1b03a8d7740 bsp=e1b03a8d1520 [] queue_work+0xb0/0x1a0 sp=e1b03a8d7910 bsp=e1b03a8d14e0 [] schedule_work+0x30/0x60 sp=e1b03a8d7910 bsp=e1b03a8d14c8 [] blank_screen_t+0x30/0x60 sp=e1b03a8d7910 bsp=e1b03a8d14b8 [] run_timer_softirq+0x2d0/0x4a0 sp=e1b03a8d7910 bsp=e1b03a8d1410 [] __do_softirq+0x220/0x260 sp=e1b03a8d7930 bsp=e1b03a8d1378 [] do_softirq+0x80/0xe0 sp=e1b03a8d7930 bsp=e1b03a8d1320 [] irq_exit+0x90/0xc0 sp=e1b03a8d7930 bsp=e1b03a8d1310 [] ia64_handle_irq+0x110/0x140 sp=e1b03a8d7930 bsp=e1b03a8d12d8 [] ia64_leave_kernel+0x0/0x290 sp=e1
Re: Linux 2.6.9 Adaptec 4 Port Starfire Sickness
Hi Jeff, I've also experienced those messages under 2.4, but they were harmless, and I never had a machine hang even after weeks of full load (the adapter was mounted on a stress test machine before being used in firewalls for months). So I wonder how you can be sure that it is this driver which finally locks the bus. Perhaps the system locks for any other reason (eg: race condition). Have you tried with any other 4-port NIC (tulip or sun for example) ? Sun QFE would be the most interesting to test as it also supports 64 bits / 66 MHz. Regards, Willy On Sat, Apr 02, 2005 at 09:41:28PM -0700, jmerkey wrote: > With linux 2.6.9 running at 192 MB/S network loading and protocol > splitting drivers routing packets out of > a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4 ports, > the adaptec starfire driver goes into > constant Tx FIFO reconfiguration mode and after 3-4 days of constantly > resetting the Tx FIFO window and > generating a deluge of messages such as: > > ethX: PCI bus congestion, resetting Tx FIFO window to X bytes > > pouring into the system log file at a rate of a dozen per minute. After > several days, the PCI bus totally locks up > and hangs the system. Need a config option to allow the starfire to > disable this feature. At very > high bus loading rates, the starfire card will completely lock the bus > after 3-4 days > of constant Tx FIFO reconfiguration at very high data rates with > protocol splitting and routing. > > Jeff > - > 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: ICS1883 LAN PHY not detected
Jeff Garzik wrote: David Liontooth wrote: :02:0b.0 Ethernet controller: Marvell Technology Group Ltd. Yukon Gigabit Ethernet 10/100/1000Base-T Adapter (rev 13) You want the sk98lin or skge drivers. Correct -- that one worked already in Debian-Installer. What was confusing is that the Gigabyte K8NS Ultra-939 board has a second gigabyte NIC, identified in the motherboard manual as a 100/10 ICS1883 LAN PHY, that is in fact an nforce gigabyte controller, part of the nforce3 250 chipset (cf. http://cogweb.net/owens/Images/Gigabyte-K8NS-Ultra-939.jpg line 5). For some reason the PCI ID 00E6 doesn't show up in lspci, so I thought it was not detected by the kernel. However, the forcedeth driver brought it to life. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.9 Adaptec 4 Port Starfire Sickness
With linux 2.6.9 running at 192 MB/S network loading and protocol splitting drivers routing packets out of a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4 ports, the adaptec starfire driver goes into constant Tx FIFO reconfiguration mode and after 3-4 days of constantly resetting the Tx FIFO window and generating a deluge of messages such as: ethX: PCI bus congestion, resetting Tx FIFO window to X bytes pouring into the system log file at a rate of a dozen per minute. After several days, the PCI bus totally locks up and hangs the system. Need a config option to allow the starfire to disable this feature. At very high bus loading rates, the starfire card will completely lock the bus after 3-4 days of constant Tx FIFO reconfiguration at very high data rates with protocol splitting and routing. Jeff - 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/
Linux 2.6.9 Adaptec Starfire sickness
With linux 2.6.9 running at 192 MB/S network loading and protocol splitting drivers routing packets out of a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4 ports, the adaptec starfire driver goes into constant Tx FIFO reconfiguration mode and after 3-4 days of constantly resetting the Tx FIFO window and generating a deluge of messages such as: ethX: PCI bus congestion, resetting Tx FIFO window to X bytes pouring into the system log file at a rate of a dozen per minute. After several days, the PCI bus totally locks up and hangs the system. Need a config option to allow the starfire to disable this feature. At very high bus loading rates, the starfire card will completely lock the bus after 3-4 days of constant Tx FIFO reconfiguration at very high data rates with protocol splitting and routing. Jeff - 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: Isn't there race issue during fput() and the dentry_open()?
On Sun, Apr 03, 2005 at 10:56:44AM +0900, Tomita, Haruo wrote:
> Isn't there race issue during fput() and the dentry_open()?
> When booting kernel, the following deadlocks are experienced.
> Stack traceback for pid 2130
> 0xf717f1b021301 1 0 R 0xf717f400 *irqbalance
> ESP EIP Function (args)
> 0xf75bfe38 0xc02d04b2 _spin_lock+0x2e (0xf7441a80)
> 0xf75bff34 0xc015667c file_move+0x14 (0xf63080e4, 0xf75bff58, 0x0, 0xf74bf000)
> 0xf75bff40 0xc0154e37 dentry_open+0xb9 (0xf63080e4, 0xf7f5ad80, 0xc02d00e6,
> 0x100100, 0x246)
> 0xf75bff58 0xc0154d78 filp_open+0x36
> 0xf75bffb4 0xc0155079 sys_open+0x31
> 0xf75bffc4 0xc02d196f syscall_call+0x7
>
> The patch was made. Is this patch right?
>
> diff -urN linux-2.6.12-rc1.orig/fs/file_table.c
> linux-2.6.12-rc1/fs/file_table.c
> --- linux-2.6.12-rc1.orig/fs/file_table.c 2005-03-02 16:37:47.0
> +0900
> +++ linux-2.6.12-rc1/fs/file_table.c 2005-03-31 17:50:46.323999320 +0900
> @@ -209,11 +209,11 @@
>
> void file_kill(struct file *file)
> {
> + file_list_lock();
> if (!list_empty(&file->f_list)) {
> - file_list_lock();
> list_del_init(&file->f_list);
> - file_list_unlock();
> }
> + file_list_unlock();
> }
This is absolutely useless. What are you trying to protect and how the
hell could keeping a lock around that check prevent any sort of deadlock?
Besides, who could possibly call fput() on struct file allocated by
dentry_open() and do that before the latter returns a reference to
that struct file?
-
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: ICS1883 LAN PHY not detected
Manfred Spraul wrote:
Gigabyte's K8NS Ultra-939 mobo has a 100/10 LAN PHY chip, ICS1883, which
isn't detected by the 2.6.12-rc1 kernel (and likely not previous
kernels).
The board is a nVidia nForce board, correct? Then please try the
forcedeth network driver ("Reverse Engineered nForce Ethernet support").
Works. It didn't work with the Debian Installer, and the motherboard
manual identifies the NIC as a ICS1883, but an nforce 100/10 it is,
taking the forcedeth driver. Appreciate the help.
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH] add rcu_read_lock in ItLpQueue_process()
Hello!
I believe that the synchronize_kernel() needs a matching
rcu_read_lock() and rcu_read_unlock() pair as shown below,
along with an rcu_dereference(). Without these, I believe
that the following sequence of events could occur:
o CPU 0 in ItLpQueue_process() tests the lpEventHandler
element, and finds it non-NULL, proceeding into the
"then" clause.
o CPU 1 in HvLpEvent_unregisterHandler() sets the element
to NULL.
o CPU 0 picks up the lpEventHandler once more, and does
a function call through the now-NULL pointer.
That said, there might be some higher-level locking that I missed
that prevents this...
Thanx, Paul
Signed-off-by: <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.12-rc1/arch/ppc64/kernel/ItLpQueue.c
linux-2.6.12-rc1-ppcfix/arch/ppc64/kernel/ItLpQueue.c
--- linux-2.6.12-rc1/arch/ppc64/kernel/ItLpQueue.c Tue Mar 1 23:37:48 2005
+++ linux-2.6.12-rc1-ppcfix/arch/ppc64/kernel/ItLpQueue.c Sat Apr 2
20:36:16 2005
@@ -107,6 +107,7 @@ unsigned ItLpQueue_process( struct ItLpQ
{
unsigned numIntsProcessed = 0;
struct HvLpEvent * nextLpEvent;
+ LpEventHandler func;
/* If we have recursed, just return */
if ( !set_inUse( lpQueue ) )
@@ -140,9 +141,12 @@ unsigned ItLpQueue_process( struct ItLpQ
*/
if ( nextLpEvent->xType < HvLpEvent_Type_NumTypes )
lpQueue->xLpIntCountByType[nextLpEvent->xType]++;
- if ( nextLpEvent->xType < HvLpEvent_Type_NumTypes &&
-lpEventHandler[nextLpEvent->xType] )
- lpEventHandler[nextLpEvent->xType](nextLpEvent,
regs);
+ if ( nextLpEvent->xType < HvLpEvent_Type_NumTypes )
+ rcu_read_lock();
+ func =
rcu_dereference(lpEventHandler[nextLpEvent->xType]);
+ if (func)
+ func(nextLpEvent, regs);
+ rcu_read_unlock();
else
printk(KERN_INFO "Unexpected Lp Event
type=%d\n", nextLpEvent->xType );
-
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/
$BNx?MC5$7(B
$B%"%J%?$N$?$a$K=PMh>e$,$j$^$7$?(B $B%^%8%a$J=P2q$$7O%5%$%H$G$9!#(B http://com.deai-pc.com/?num=20010 - 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: iomapping a big endian area
On Sat, 2005-04-02 at 20:08 -0800, David S. Miller wrote:
> > Did anyone have a preference for the API? I was thinking
> > ioread32_native, but ioread32be is fine too.
>
> I think doing foo{be,le}{8,16,32}() would be consistent with
> our byteorder.h interface names.
Thinking about this some more, I know of no case of a BE bus connected
to a LE system, nor do I think anyone would ever create such a beast, so
our only missing interface is for a BE bus on a BE system.
Thus, I think io{read,write}{16,32}_native are better interfaces ...
they basically mean pass memory operations without byte swaps, so
they're well defined on both BE and LE systems and correspond exactly to
our existing _raw_{read,write}{w,l} calls (principle of least surprise).
James
-
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: sched /HT processor
On Sun, 2005-04-03 at 07:46 +0530, Arun Srinivas wrote: > I attached the 'dmesg' output because there it shows that my kernel > recogonized 2 cpu's.As said earlier , are they treated as 2 physical cpu's > or logical cpu's? > As I said, they are logical [snip] > > > available > > > Apr 2 17:43:12 kulick2 kernel: CPU#1: Thermal monitoring enabled > > > Apr 2 17:43:12 kulick2 kernel: CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz > > > stepping 09 > > > Apr 2 17:43:12 kulick2 kernel: Total of 2 processors activated > >(11911.16 > > > BogoMIPS). > > > Apr 2 17:43:12 kulick2 kernel: cpu_sibling_map[0] = 1 > > > Apr 2 17:43:12 kulick2 kernel: cpu_sibling_map[1] = 0 > > > >Here you see that you have two CPUs. 0 is the sibling of 1 and 1 to 0. > >This just shows that you have HT. If you were to have a dual xeon, then > >you would see 4 CPUs and two pairs. > > > >-- Steve > > > I'll elaborate more. This says that you have a single CPU with hyperthreading. That's what the siblings mean. That they share a single physical CPU. -- Steve - 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: iomapping a big endian area
On Sat, 02 Apr 2005 21:40:39 -0600
James Bottomley <[EMAIL PROTECTED]> wrote:
> After all, the driver must know the card is BE, so the routines that
> make use of the feature are easily coded into the card, so there's no
> real need to add it to the iomem cookie.
Yes, I don't believe it needs to be in the cookie either.
> Did anyone have a preference for the API? I was thinking
> ioread32_native, but ioread32be is fine too.
I think doing foo{be,le}{8,16,32}() would be consistent with
our byteorder.h interface names.
-
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: x86 TSC time warp puzzle
At 3:13 AM -0500 4/2/05, Lee Revell wrote: On Fri, 2005-04-01 at 23:05 -0800, Pallipadi, Venkatesh wrote: 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. Nope, that sounds just about right. Buggy BIOSes that implement ACPI via SMM (or so I have been told) can stall the machine for over a millisecond, this is why some laptops lose timer ticks at HZ=1000. The issue is well known by Linux audio users, as it causes big problems for people who buy laptops for live audio use. This is a desktop board, and this is well after boot (hours). Also, ACPI is disabled in the BIOS. I suppose I can try to disable SMI via the APIC? -- /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: iomapping a big endian area
On Sun, 2005-04-03 at 04:10 +0100, Matthew Wilcox wrote: > > SPARC64 can do it in the PTEs, but we just use raw physical > > addresses in our I/O accessors, and in those load/store instructions > > we can specify the endianness. > > Ah right. So you'd prefer an ioread8be() interface? Actually, ioread8be is unnecessary, but I was planning to add ioread16/ioread32 and iowritexx be on be variants (equivalent to _raw_readw et al.) After all, the driver must know the card is BE, so the routines that make use of the feature are easily coded into the card, so there's no real need to add it to the iomem cookie. Did anyone have a preference for the API? I was thinking ioread32_native, but ioread32be is fine too. James - 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/
setting cpu affinity-help
hi can someone show me an example usage of sched_setaffinity().I do not know how to set the affinity mask for a process.please. thanks arun _ Marriages at Bharatmatriony.com http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74 Relationships that last forever. - 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: iomapping a big endian area
On Sat, Apr 02, 2005 at 06:38:05PM -0800, David S. Miller wrote: > > My thought on this is that we should encode the endianness of the > > registers in the ioremap cookie. Some architectures (sparc, I think?) can > > do this in their PTEs. The rest of us can do it in our ioread/writeN > > methods. I've planned for this in the parisc iomap implementation but > > not actually implemented it. > > SPARC64 can do it in the PTEs, but we just use raw physical > addresses in our I/O accessors, and in those load/store instructions > we can specify the endianness. Ah right. So you'd prefer an ioread8be() interface? > Be careful though. Endianness can be dealt with on a hardware > level. Consider a byte access to a 32-bit word sized config space > datum, the PCI controller on a big-endian system will likely byte-twist > the data lanes in order for this to work properly. Yup, PA-RISC PCI adapters (both Dino and Elroy) do the same thing. The 53c700 driver handles this lack of skewing by xoring the address with 3. -- "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/
[no subject]
Geachte dames en heren, Ergert u zich ook altijd over de hoge prijzen die voor software gevraagd worden? Daar komt nu een einde aan. Wij leveren u alle mogelijke software voor een fractie van de normale prijs. De software wordt vanuit het buitenland direct naar uw adres verzonden, omdat het daar minder kost dan in de winkels alhier. Originele versies met originele serienummers en de normale support voor weinig geld, bijvoorbeeld: Microsoft Windows XP prof. voor 50 USD in plaats van 270 USD Adobe Photoshop 80 USD in plaats van 650 USD Deze en andere topprodukten kunt u verwachten. Aarzel niet en bezoek onze winkel. De winkel is geheel Engelstalig, maar alle produkten kunnen in elke taal geinstalleerd worden. Veel winkelplezier. Met vriendelijke groet, ResellerNews - 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: iomapping a big endian area
On Sun, 3 Apr 2005 02:37:57 +0100 Matthew Wilcox <[EMAIL PROTECTED]> wrote: > My thought on this is that we should encode the endianness of the > registers in the ioremap cookie. Some architectures (sparc, I think?) can > do this in their PTEs. The rest of us can do it in our ioread/writeN > methods. I've planned for this in the parisc iomap implementation but > not actually implemented it. SPARC64 can do it in the PTEs, but we just use raw physical addresses in our I/O accessors, and in those load/store instructions we can specify the endianness. Be careful though. Endianness can be dealt with on a hardware level. Consider a byte access to a 32-bit word sized config space datum, the PCI controller on a big-endian system will likely byte-twist the data lanes in order for this to work properly. It's a subtle issue, and it's explained pretty well in some of the UltraSPARC PCI controller docs at: http://www.sun.com/processors/documentation.html In particular, "U2P UPA to PCI User's Manual", chapter 10 "Little-Endian Support", has some informative diagrams. - 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: sched /HT processor
I attached the 'dmesg' output because there it shows that my kernel recogonized 2 cpu's.As said earlier , are they treated as 2 physical cpu's or logical cpu's? From: Steven Rostedt <[EMAIL PROTECTED]> To: Arun Srinivas <[EMAIL PROTECTED]> CC: LKML Subject: Re: sched /HT processor Date: Sat, 02 Apr 2005 20:17:54 -0500 On Sun, 2005-04-03 at 06:07 +0530, Arun Srinivas wrote: > HI > > I have pentium4 hyperthreaded processor.I am using kernel 2.6.5 and i > rebuilt my kernel with CONFIG_SMP enabled (in this kernel source there is > nothing such as CONFIG_SMT...i noticed this only in recent 2.6.11). > I don't have a 2.6.5 available, but I do have a 2.6.9 to look at. > 1) So, after I rebulit it with CONFIG_SMP enabled does linux recogonize my > machine as hyperthreaded or as 2 seperate processor? Also, if it does not > recogonize it as hyperthreaded(but only as 2 seperate CPU's), does the > scheduler schedule instruction in the 2 cpu's independently? (does it > maintain 2 seperate runqueues? > I believe even HT on 2.6.11 maintains two different runqueues. But it doesn't care so much to jump from one runqueue to the next if it is HT. > 2) If it has indeed recogonized this as hyperthreaded processor...does the > scheduler use a common runqueue for the 2 logical processor? > No, you wouldn't want to. > (please read below) What do you want us to see? > * > (I am attaching the ouput of 'dmesg' (command) on my machine) > * > Apr 2 17:43:12 kulick2 kernel: Linux version 2.6.5-1.358custom > ([EMAIL PROTECTED]) (gcc version 3.3 > .3 20040412 (Red Hat Linux 3.3.3-7)) #133 SMP Wed Mar 30 12:16:27 CST 2005 > Apr 2 17:43:12 kulick2 kernel: BIOS-provided physical RAM map: > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: - > 000a (usable) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 000f - > 0010 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 0010 - > 1f77 (usable) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 1f77 - > 1f772000 (ACPI NVS) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 1f772000 - > 1f793000 (ACPI data) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 1f793000 - > 1f80 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fec0 - > fec1 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fecf - > fecf1000 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fed2 - > fed9 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fee0 - > fee1 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: ffb0 - > 0001 (reserved) > Apr 2 17:43:12 kulick2 kernel: 0MB HIGHMEM available. > Apr 2 17:43:12 kulick2 kernel: 503MB LOWMEM available. > Apr 2 17:43:12 kulick2 kernel: ACPI: S3 and PAE do not like each other for > now, S3 disabled. > Apr 2 17:43:12 kulick2 kernel: found SMP MP-table at 000fe710 > Apr 2 17:43:12 kulick2 kernel: On node 0 totalpages: 128880 > Apr 2 17:43:12 kulick2 kernel: DMA zone: 4096 pages, LIFO batch:1 > Apr 2 17:43:12 kulick2 kernel: Normal zone: 124784 pages, LIFO batch:16 > Apr 2 17:43:12 kulick2 kernel: HighMem zone: 0 pages, LIFO batch:1 > Apr 2 17:43:12 kulick2 kernel: DMI 2.3 present. > Apr 2 17:43:12 kulick2 kernel: Using APIC driver default > Apr 2 17:43:12 kulick2 kernel: ACPI: RSDP (v000 DELL >) @ > 0x000feba0 > Apr 2 17:43:12 kulick2 kernel: ACPI: RSDT (v001 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd192 > Apr 2 17:43:12 kulick2 kernel: ACPI: FADT (v001 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd1ca > Apr 2 17:43:12 kulick2 kernel: ACPI: SSDT (v001 DELLst_ex 0x1000 > MSFT 0x010d) @ > 0xfffd4eee > Apr 2 17:43:12 kulick2 irqbalance: irqbalance startup succeeded > Apr 2 17:43:12 kulick2 kernel: ACPI: MADT (v001 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd23e > Apr 2 17:43:12 kulick2 kernel: ACPI: BOOT (v001 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd2aa > Apr 2 17:43:12 kulick2 kernel: ACPI: ASF! (v016 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd2d2 > Apr 2 17:43:12 kulick2 kernel: ACPI: DSDT (v001 DELLdt_ex 0x1000 > MSFT 0x010d) @ > 0x > Apr 2 17:43:12 kulick2 kernel: ACPI: PM-Timer IO Port: 0x808 > Apr 2 17:43:12 kulick2 kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] > enabled) > Apr 2 17:43:12 kulick2 kernel: Processor #0 15:2 APIC version 20 > Apr 2 17:43:12 kulick2 kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] > enabled) > Apr 2 17:43:12 kulick2 kernel: Processor #1 15:2 APIC version 20 > Apr 2 17:43:12 kulick2 kernel: ACPI: LAPIC (
Isn't there race issue during fput() and the dentry_open()?
Isn't there race issue during fput() and the dentry_open()?
(BWhen booting kernel, the following deadlocks are experienced.
(B
(BStack traceback for pid 2130
(B0xf717f1b0 21301 1 0 R 0xf717f400 *irqbalance
(BESP EIP Function (args)
(B0xf75bfe38 0xc02d04b2 _spin_lock+0x2e (0xf7441a80)
(B0xf75bff34 0xc015667c file_move+0x14 (0xf63080e4, 0xf75bff58, 0x0, 0xf74bf000)
(B0xf75bff40 0xc0154e37 dentry_open+0xb9 (0xf63080e4, 0xf7f5ad80, 0xc02d00e6,
(B0x100100, 0x246)
(B0xf75bff58 0xc0154d78 filp_open+0x36
(B0xf75bffb4 0xc0155079 sys_open+0x31
(B0xf75bffc4 0xc02d196f syscall_call+0x7
(B
(BThe patch was made. Is this patch right?
(B
(Bdiff -urN linux-2.6.12-rc1.orig/fs/file_table.c linux-2.6.12-rc1/fs/file_table.c
(B--- linux-2.6.12-rc1.orig/fs/file_table.c 2005-03-02 16:37:47.0
(B+0900
(B+++ linux-2.6.12-rc1/fs/file_table.c2005-03-31 17:50:46.323999320 +0900
(B@@ -209,11 +209,11 @@
(B
(B void file_kill(struct file *file)
(B {
(B+ file_list_lock();
(Bif (!list_empty(&file->f_list)) {
(B- file_list_lock();
(Blist_del_init(&file->f_list);
(B- file_list_unlock();
(B}
(B+ file_list_unlock();
(B }
(B
(B int fs_may_remount_ro(struct super_block *sb)
(B
(B--
(BHaruo
(B
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at http://www.tux.org/lkml/
iomapping a big endian area
On Sat, Apr 02, 2005 at 02:52:14PM -0600, James Bottomley wrote: > This driver has had it's own different infrastructure for doing this for > ages, but it's time it used the common one. Thanks. I'd been looking at this for a while but hadn't got round tuit yet. > #ifdef CONFIG_53C700_LE_ON_BE > #define bE (hostdata->force_le_on_be ? 0 : 3) > #define bSWAP (hostdata->force_le_on_be) > +/* This is terrible, but there's no raw version of ioread32. That means > + * that on a be board we swap twice (once in ioread32 and once again to > + * get the value correct) */ > +#define bS_to_io(x) ((hostdata->force_le_on_be) ? (x) : cpu_to_le32(x)) I raised this with Linus back when he did the original iomap() stuff. Unfortunately, I think he ignored the question ;-) My thought on this is that we should encode the endianness of the registers in the ioremap cookie. Some architectures (sparc, I think?) can do this in their PTEs. The rest of us can do it in our ioread/writeN methods. I've planned for this in the parisc iomap implementation but not actually implemented it. It doesn't look too hard so I'll commit something to the parisc tree later that'll let you iomap a BE area. Do we have any cards that need to be accessed in a BE way on a LE machine? (ie x86) -- "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: ICS1883 LAN PHY not detected
David Liontooth wrote: :02:0b.0 Ethernet controller: Marvell Technology Group Ltd. Yukon Gigabit Ethernet 10/100/1000Base-T Adapter (rev 13) You want the sk98lin or skge drivers. Jeff - 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: sched /HT processor
On Sun, 2005-04-03 at 06:07 +0530, Arun Srinivas wrote: > HI > > I have pentium4 hyperthreaded processor.I am using kernel 2.6.5 and i > rebuilt my kernel with CONFIG_SMP enabled (in this kernel source there is > nothing such as CONFIG_SMT...i noticed this only in recent 2.6.11). > I don't have a 2.6.5 available, but I do have a 2.6.9 to look at. > 1) So, after I rebulit it with CONFIG_SMP enabled does linux recogonize my > machine as hyperthreaded or as 2 seperate processor? Also, if it does not > recogonize it as hyperthreaded(but only as 2 seperate CPU's), does the > scheduler schedule instruction in the 2 cpu's independently? (does it > maintain 2 seperate runqueues? > I believe even HT on 2.6.11 maintains two different runqueues. But it doesn't care so much to jump from one runqueue to the next if it is HT. > 2) If it has indeed recogonized this as hyperthreaded processor...does the > scheduler use a common runqueue for the 2 logical processor? > No, you wouldn't want to. > (please read below) What do you want us to see? > * > (I am attaching the ouput of 'dmesg' (command) on my machine) > * > Apr 2 17:43:12 kulick2 kernel: Linux version 2.6.5-1.358custom > ([EMAIL PROTECTED]) (gcc version 3.3 > .3 20040412 (Red Hat Linux 3.3.3-7)) #133 SMP Wed Mar 30 12:16:27 CST 2005 > Apr 2 17:43:12 kulick2 kernel: BIOS-provided physical RAM map: > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: - > 000a (usable) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 000f - > 0010 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 0010 - > 1f77 (usable) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 1f77 - > 1f772000 (ACPI NVS) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 1f772000 - > 1f793000 (ACPI data) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 1f793000 - > 1f80 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fec0 - > fec1 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fecf - > fecf1000 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fed2 - > fed9 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fee0 - > fee1 (reserved) > Apr 2 17:43:12 kulick2 kernel: BIOS-e820: ffb0 - > 0001 (reserved) > Apr 2 17:43:12 kulick2 kernel: 0MB HIGHMEM available. > Apr 2 17:43:12 kulick2 kernel: 503MB LOWMEM available. > Apr 2 17:43:12 kulick2 kernel: ACPI: S3 and PAE do not like each other for > now, S3 disabled. > Apr 2 17:43:12 kulick2 kernel: found SMP MP-table at 000fe710 > Apr 2 17:43:12 kulick2 kernel: On node 0 totalpages: 128880 > Apr 2 17:43:12 kulick2 kernel: DMA zone: 4096 pages, LIFO batch:1 > Apr 2 17:43:12 kulick2 kernel: Normal zone: 124784 pages, LIFO batch:16 > Apr 2 17:43:12 kulick2 kernel: HighMem zone: 0 pages, LIFO batch:1 > Apr 2 17:43:12 kulick2 kernel: DMI 2.3 present. > Apr 2 17:43:12 kulick2 kernel: Using APIC driver default > Apr 2 17:43:12 kulick2 kernel: ACPI: RSDP (v000 DELL >) @ > 0x000feba0 > Apr 2 17:43:12 kulick2 kernel: ACPI: RSDT (v001 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd192 > Apr 2 17:43:12 kulick2 kernel: ACPI: FADT (v001 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd1ca > Apr 2 17:43:12 kulick2 kernel: ACPI: SSDT (v001 DELLst_ex 0x1000 > MSFT 0x010d) @ > 0xfffd4eee > Apr 2 17:43:12 kulick2 irqbalance: irqbalance startup succeeded > Apr 2 17:43:12 kulick2 kernel: ACPI: MADT (v001 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd23e > Apr 2 17:43:12 kulick2 kernel: ACPI: BOOT (v001 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd2aa > Apr 2 17:43:12 kulick2 kernel: ACPI: ASF! (v016 DELLGX270 0x0007 > ASL 0x0061) @ > 0x000fd2d2 > Apr 2 17:43:12 kulick2 kernel: ACPI: DSDT (v001 DELLdt_ex 0x1000 > MSFT 0x010d) @ > 0x > Apr 2 17:43:12 kulick2 kernel: ACPI: PM-Timer IO Port: 0x808 > Apr 2 17:43:12 kulick2 kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] > enabled) > Apr 2 17:43:12 kulick2 kernel: Processor #0 15:2 APIC version 20 > Apr 2 17:43:12 kulick2 kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] > enabled) > Apr 2 17:43:12 kulick2 kernel: Processor #1 15:2 APIC version 20 > Apr 2 17:43:12 kulick2 kernel: ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] > disabled) > Apr 2 17:43:12 kulick2 kernel: ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] > disabled) > Apr 2 17:43:12 kulick2 kernel: ACPI: IOAPIC (id[0x02] address[0xfec0] > global_irq_base[0x0] > ) > Apr 2 17:43:12 kulick2 kernel: IOAPIC[0
Re: prepatch 2.6.12-rc1 does not apply cleanly to linux-2.6.11.6
On Saturday 02 April 2005 19:38, Joseph E. Sacco, Ph.D. wrote: >prepatch 2.6.12-rc1 [2005-03-18 02:52 UTC] does not apply cleanly to >linux-2.6.11.6: Its not supposed to, its against the bare 2.6.11.tar.gz output. [...] Its also the smoothest, snappiest kernel to come around in quite a while. Lots of stuff Just Works(TM). -- 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: prepatch 2.6.12-rc1 does not apply cleanly to linux-2.6.11.6
On Sat, 2 Apr 2005, Joseph E. Sacco, Ph.D. wrote: > prepatch 2.6.12-rc1 [2005-03-18 02:52 UTC] does not apply cleanly to > linux-2.6.11.6: > No, it does not, it applies to the base 2.6.11, *not* to 2.6.11.6 - first back out the 2.6.11.6 patch, then apply the 2.6.12-rc1 patch. -- Jesper Juhl - 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/
prepatch 2.6.12-rc1 does not apply cleanly to linux-2.6.11.6
prepatch 2.6.12-rc1 [2005-03-18 02:52 UTC] does not apply cleanly to linux-2.6.11.6: ./net/ipv4/fib_hash.c.rej ./net/ipv4/tcp_timer.c.rej ./net/netrom/nr_in.c.rej ./net/xfrm/xfrm_state.c.rej ./sound/pci/ac97/ac97_codec.c.rej ./drivers/pci/hotplug/pciehp_ctrl.c.rej ./drivers/net/wan/hd6457x.c.rej ./drivers/net/tun.c.rej ./drivers/net/amd8111e.c.rej ./drivers/net/via-rhine.c.rej ./drivers/net/ppp_async.c.rej ./drivers/net/r8169.c.rej ./drivers/net/sis900.c.rej ./drivers/media/video/saa7110.c.rej ./drivers/media/video/bt819.c.rej ./drivers/media/video/adv7170.c.rej ./drivers/media/video/adv7175.c.rej ./drivers/media/video/saa7114.c.rej ./drivers/media/video/saa7185.c.rej ./drivers/input/serio/i8042-x86ia64io.h.rej ./drivers/md/raid6altivec.uc.rej ./kernel/signal.c.rej ./fs/cramfs/inode.c.rej ./fs/isofs/rock.c.rej ./fs/isofs/inode.c.rej ./fs/eventpoll.c.rej ./fs/exec.c.rej ./arch/ppc/oprofile/op_model_fsl_booke.c.rej ./arch/ppc/platforms/4xx/ocotea.h.rej ./arch/ppc/platforms/4xx/ebony.h.rej ./arch/ppc/platforms/4xx/luan.h.rej ./Makefile.rej -Joseph -- joseph_sacco[at]comcast[dot]net - 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/
sched /HT processor
HI I have pentium4 hyperthreaded processor.I am using kernel 2.6.5 and i rebuilt my kernel with CONFIG_SMP enabled (in this kernel source there is nothing such as CONFIG_SMT...i noticed this only in recent 2.6.11). 1) So, after I rebulit it with CONFIG_SMP enabled does linux recogonize my machine as hyperthreaded or as 2 seperate processor? Also, if it does not recogonize it as hyperthreaded(but only as 2 seperate CPU's), does the scheduler schedule instruction in the 2 cpu's independently? (does it maintain 2 seperate runqueues? 2) If it has indeed recogonized this as hyperthreaded processor...does the scheduler use a common runqueue for the 2 logical processor? (please read below) * (I am attaching the ouput of 'dmesg' (command) on my machine) * Apr 2 17:43:12 kulick2 kernel: Linux version 2.6.5-1.358custom ([EMAIL PROTECTED]) (gcc version 3.3 .3 20040412 (Red Hat Linux 3.3.3-7)) #133 SMP Wed Mar 30 12:16:27 CST 2005 Apr 2 17:43:12 kulick2 kernel: BIOS-provided physical RAM map: Apr 2 17:43:12 kulick2 kernel: BIOS-e820: - 000a (usable) Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 000f - 0010 (reserved) Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 0010 - 1f77 (usable) Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 1f77 - 1f772000 (ACPI NVS) Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 1f772000 - 1f793000 (ACPI data) Apr 2 17:43:12 kulick2 kernel: BIOS-e820: 1f793000 - 1f80 (reserved) Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fec0 - fec1 (reserved) Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fecf - fecf1000 (reserved) Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fed2 - fed9 (reserved) Apr 2 17:43:12 kulick2 kernel: BIOS-e820: fee0 - fee1 (reserved) Apr 2 17:43:12 kulick2 kernel: BIOS-e820: ffb0 - 0001 (reserved) Apr 2 17:43:12 kulick2 kernel: 0MB HIGHMEM available. Apr 2 17:43:12 kulick2 kernel: 503MB LOWMEM available. Apr 2 17:43:12 kulick2 kernel: ACPI: S3 and PAE do not like each other for now, S3 disabled. Apr 2 17:43:12 kulick2 kernel: found SMP MP-table at 000fe710 Apr 2 17:43:12 kulick2 kernel: On node 0 totalpages: 128880 Apr 2 17:43:12 kulick2 kernel: DMA zone: 4096 pages, LIFO batch:1 Apr 2 17:43:12 kulick2 kernel: Normal zone: 124784 pages, LIFO batch:16 Apr 2 17:43:12 kulick2 kernel: HighMem zone: 0 pages, LIFO batch:1 Apr 2 17:43:12 kulick2 kernel: DMI 2.3 present. Apr 2 17:43:12 kulick2 kernel: Using APIC driver default Apr 2 17:43:12 kulick2 kernel: ACPI: RSDP (v000 DELL ) @ 0x000feba0 Apr 2 17:43:12 kulick2 kernel: ACPI: RSDT (v001 DELLGX270 0x0007 ASL 0x0061) @ 0x000fd192 Apr 2 17:43:12 kulick2 kernel: ACPI: FADT (v001 DELLGX270 0x0007 ASL 0x0061) @ 0x000fd1ca Apr 2 17:43:12 kulick2 kernel: ACPI: SSDT (v001 DELLst_ex 0x1000 MSFT 0x010d) @ 0xfffd4eee Apr 2 17:43:12 kulick2 irqbalance: irqbalance startup succeeded Apr 2 17:43:12 kulick2 kernel: ACPI: MADT (v001 DELLGX270 0x0007 ASL 0x0061) @ 0x000fd23e Apr 2 17:43:12 kulick2 kernel: ACPI: BOOT (v001 DELLGX270 0x0007 ASL 0x0061) @ 0x000fd2aa Apr 2 17:43:12 kulick2 kernel: ACPI: ASF! (v016 DELLGX270 0x0007 ASL 0x0061) @ 0x000fd2d2 Apr 2 17:43:12 kulick2 kernel: ACPI: DSDT (v001 DELLdt_ex 0x1000 MSFT 0x010d) @ 0x Apr 2 17:43:12 kulick2 kernel: ACPI: PM-Timer IO Port: 0x808 Apr 2 17:43:12 kulick2 kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Apr 2 17:43:12 kulick2 kernel: Processor #0 15:2 APIC version 20 Apr 2 17:43:12 kulick2 kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Apr 2 17:43:12 kulick2 kernel: Processor #1 15:2 APIC version 20 Apr 2 17:43:12 kulick2 kernel: ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] disabled) Apr 2 17:43:12 kulick2 kernel: ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] disabled) Apr 2 17:43:12 kulick2 kernel: ACPI: IOAPIC (id[0x02] address[0xfec0] global_irq_base[0x0] ) Apr 2 17:43:12 kulick2 kernel: IOAPIC[0]: Assigned apic_id 2 Apr 2 17:43:12 kulick2 kernel: IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 Apr 2 17:43:12 kulick2 kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) Apr 2 17:43:12 kulick2 kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Apr 2 17:43:12 kulick2 kernel: Enabling APIC mode: Flat. Using 1 I/O APICs Apr 2 17:43:12 kulick2 kernel: Using ACPI (MADT) for SMP configuration information Apr 2 17:43:12 kulick2 portmap: portmap startup succeeded
Re: [PATCH] kernel/module.c - fix warning and reduce stack usage - reintroduction of mistakenly dropped patch
On Sat, 2 Apr 2005, Andrew Morton wrote: > Jesper Juhl <[EMAIL PROTECTED]> wrote: > > > > However, it seems you did *not* roll > > figure-out-who-is-inserting-bogus-modules-warning-fix.patch into > > figure-out-who-is-inserting-bogus-modules.patch but instead just dropped > > the patch. > > I meant to drop it - it was just a debug thing, and we fixed the bug ages > ago and people kept on trying to fix the debug patch. > Ohh, I see. Then please disregard the mail I just send with an alternative version. -- Jesper - 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] kernel/module.c - fix warning and reduce stack usage - reintroduction of mistakenly dropped patch
On Sun, 3 Apr 2005, Jesper Juhl wrote:
>
> Hi Andrew,
>
> Reading your 2.6.12-rc1-mm4 announce text I see
>
> ...
> -figure-out-who-is-inserting-bogus-modules-warning-fix.patch
>
> Folded into figure-out-who-is-inserting-bogus-modules.patch
> ...
> figure-out-who-is-inserting-bogus-modules.patch
> Figure out who is inserting bogus modules
> ...
>
> However, it seems you did *not* roll
> figure-out-who-is-inserting-bogus-modules-warning-fix.patch into
> figure-out-who-is-inserting-bogus-modules.patch but instead just dropped
> the patch.
>
> It also turns out I had a small boundary error (off-by-one) in my original
> patch which Yum Rayan spotted and fixed in a patch he wrote that also
> reduces the stack usage of the function (by dynamically allocating the
> needed mem for 'args' instead of using a static 512 byte array - see the
> LKML thread with subject "[PATCH] Reduce stack usage in module.c"), so
> below you'll find an updated patch that reintroduce
> figure-out-who-is-inserting-bogus-modules-warning-fix.patch on top of
> 2.6.12-rc1-mm4 and includes Yum Rayan's fix for the off-by-one and also
> adopts his use of kmalloc() instead of large static array.
>
> Yum Rayan's patch does more than what I've included below, I've only
> included his changes to the who_is_doing_it() function, if you want the
> rest of his changes then please see the original thread for his full
> patch.
>
> Here's the updated figure-out-who-is-inserting-bogus-modules-warning-fix.patch
>
In case you prefer the static array, so the function will never fail due
to OOM, then here's an alternative version of my original patch /with/ the
static array but /without/ the off-by-one error :
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4-orig/kernel/module.c 2005-03-31 21:20:07.0
+0200
+++ linux-2.6.12-rc1-mm4/kernel/module.c2005-04-03 02:04:39.0
+0200
@@ -1400,9 +1400,12 @@ static void who_is_doing_it(void)
{
/* Print out all the args. */
char args[512];
- unsigned int i, len = current->mm->arg_end - current->mm->arg_start;
+ unsigned long i, len = current->mm->arg_end - current->mm->arg_start;
- copy_from_user(args, (void *)current->mm->arg_start, len);
+ if (len > 511)
+ len = 511;
+
+ len -= copy_from_user(args, (void *)current->mm->arg_start, len);
for (i = 0; i < len; i++) {
if (args[i] == '\0')
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/module.c - fix warning and reduce stack usage - reintroduction of mistakenly dropped patch
Jesper Juhl <[EMAIL PROTECTED]> wrote: > > However, it seems you did *not* roll > figure-out-who-is-inserting-bogus-modules-warning-fix.patch into > figure-out-who-is-inserting-bogus-modules.patch but instead just dropped > the patch. I meant to drop it - it was just a debug thing, and we fixed the bug ages ago and people kept on trying to fix the debug patch. - 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: How's the nforce4 support in Linux?
On Mar 26, 2005 7:32 PM, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
>
> On 2005-03-26, at 16:19, Arjan van de Ven wrote:
>
> > `
> >> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> >> hda: dma_intr: error=0x84 { DriveStatusError BadCRC
> >
> > BadCRC is 99% sure a cabling issue; either a bad/overheated cable or a
> > cable used at too high a speed for the cable.
>
> No. It is more likely that the timing programming between the disk and
> host controller
> are in a miss-match state. UDMA mode detection can come in to mind too.
> It makes sense to experiment with hdparm to see if the problem goes
> away in non
> Ultra DMA modes.
Do you mean "multiword dma modes" or "pio modes" ?
--
Julien
-
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] kernel/module.c - fix warning and reduce stack usage - reintroduction of mistakenly dropped patch
Hi Andrew,
Reading your 2.6.12-rc1-mm4 announce text I see
...
-figure-out-who-is-inserting-bogus-modules-warning-fix.patch
Folded into figure-out-who-is-inserting-bogus-modules.patch
...
figure-out-who-is-inserting-bogus-modules.patch
Figure out who is inserting bogus modules
...
However, it seems you did *not* roll
figure-out-who-is-inserting-bogus-modules-warning-fix.patch into
figure-out-who-is-inserting-bogus-modules.patch but instead just dropped
the patch.
It also turns out I had a small boundary error (off-by-one) in my original
patch which Yum Rayan spotted and fixed in a patch he wrote that also
reduces the stack usage of the function (by dynamically allocating the
needed mem for 'args' instead of using a static 512 byte array - see the
LKML thread with subject "[PATCH] Reduce stack usage in module.c"), so
below you'll find an updated patch that reintroduce
figure-out-who-is-inserting-bogus-modules-warning-fix.patch on top of
2.6.12-rc1-mm4 and includes Yum Rayan's fix for the off-by-one and also
adopts his use of kmalloc() instead of large static array.
Yum Rayan's patch does more than what I've included below, I've only
included his changes to the who_is_doing_it() function, if you want the
rest of his changes then please see the original thread for his full
patch.
Here's the updated figure-out-who-is-inserting-bogus-modules-warning-fix.patch
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4-orig/kernel/module.c 2005-03-31 21:20:07.0
+0200
+++ linux-2.6.12-rc1-mm4/kernel/module.c2005-04-03 01:54:30.0
+0200
@@ -1399,10 +1399,19 @@ static inline void add_kallsyms(struct m
static void who_is_doing_it(void)
{
/* Print out all the args. */
- char args[512];
- unsigned int i, len = current->mm->arg_end - current->mm->arg_start;
+ char *args;
+ unsigned long i, len = current->mm->arg_end - current->mm->arg_start;
- copy_from_user(args, (void *)current->mm->arg_start, len);
+ if (len > 512)
+ len = 512;
+
+ args = kmalloc(len + 1, GFP_KERNEL);
+ if (!args) {
+ printk(KERN_WARNING "Unable to allocate memory, can't print
who's inserting bogus modules\n");
+ return;
+ }
+
+ len -= copy_from_user(args, (void *)current->mm->arg_start, len);
for (i = 0; i < len; i++) {
if (args[i] == '\0')
@@ -1410,6 +1419,7 @@ static void who_is_doing_it(void)
}
args[i] = 0;
printk("ARGS: %s\n", args);
+ kfree(args);
}
/* Allocate and load the module: note that size of section 0 is always
-
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: Logitech MX1000 Horizontal Scrolling
Jeremy Nickurak <[EMAIL PROTECTED]> writes: > I'm playing with this under 2.6.11.4 I got 2.6.12-rc1 > The vertical cruise control buttons work properly, with the > exception of the extra button press. Yup, nice, I see the same > But the horizontal buttons are mapping to 6/7 as non-repeat buttons, > and adding simulateously the 4/5 events auto-repeated for as long as > the button is down. That is to say, pressing the the horizontal > scroll in a 2d scrolling area will scroll *diagonally* one step, > then vertically until the button is released. Yup, seeing exactly the same here. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:esben-stien.name - 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/
Oops in set_spdif_output in i810_audio
Hi, i got a new ahtec laptop and i get null pointer oops everytime i
load i810_audio on 2.4 and 2.6 (including 2.6.11.6) kernels.
*** These are init messages & oops:
i810_audio: Unknown symbol ac97_set_dac_rate
i810_audio: Unknown symbol ac97_release_codec
i810_audio: Unknown symbol ac97_set_adc_rate
i810_audio: Unknown symbol ac97_alloc_codec
i810_audio: Unknown symbol ac97_probe_codec
Intel 810 + AC97 Audio, version 1.01, 04:15:45 Jan 24 2005
ACPI: PCI interrupt :00:1f.5[B] -> GSI 10 (level, low) -> IRQ 10
i810: Intel ICH4 found at IO 0x18c0 and 0x1c00, MEM 0xe0100c00 and
0xe0100800, IRQ 10
i810: Intel ICH4 mmio at 0xde9f3c00 and 0xdea84800
i810_audio: Primary codec has ID 0
i810_audio: Audio Controller supports 6 channels.
i810_audio: Defaulting to base 2 channel mode.
i810_audio: Resetting connection 0
i810_audio: Connection 0 with codec id 0
ac97_codec: AC97 Modem codec, id: CXT48 (Unknown)
i810_audio: codec 0 is a softmodem - skipping.
...
EIP:0060:[]Not tainted
EFLAGS: 00010246 (2.6.8-2-686)
EIP is at i810_set_spdif_output+0x22/0x160 [i810_audio]
eax: ebx: ecx: d9c28400 edx: d9c28400
esi: edi: ebp: d6edfb80 esp: d7383e30
ds: 007b es: 007b ss: 0068
Process insmod (pid: 3358, threadinfo=d7382000 task=dca643b0)
Stack: 4461 ffce c011c7f4 d6edfb80 d6edfc18
dec4ff9f d6edfb80 dec51740 d7383e7c dda3c240
0a04
d9c28400 dec4fdb0 d6edfbb0 d9c28400 0001
0001
Call Trace:
[] release_console_sem+0xc4/0xd0
[] i810_configure_clocking+0xbf/0x4c0 [i810_audio]
[] i810_ac97_init+0x4a0/0x5d0 [i810_audio]
[] i810_probe+0x4af/0x690 [i810_audio]
*** This is my device:
:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
Subsystem: QUANTA Computer Inc: Unknown device 0707
Flags: bus master, medium devsel, latency 0, IRQ 10
I/O ports at 1c00 [size=256]
I/O ports at 18c0 [size=64]
Memory at e0100c00 (32-bit, non-prefetchable) [size=512]
Memory at e0100800 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
*** What happened in set_spdif_output:
struct ac97_codec *codec = state->card->ac97_codec[0];
// ... for some reason codec is NULL, and then
if(!codec->codec_ops->digital)
// ... oops
*** Why is that null?
Perhaps it is because the driver thinks that the card is a modem and
releases it. So no codecs are available, but some functions expect at
least one codec to exist.
if(codec->modem)
{
printk(KERN_WARNING "i810_audio: codec %d is a
softmodem - skipping.\n", ac97_id);
ac97_release_codec(codec);
And is detected as modem because of this condition (in ac97_codec.c):
/* Check for an AC97 1.0 soft modem (ID1) */
if(codec->codec_read(codec, AC97_RESET) & 2)
I don't know much about ac97, i also have an ac97 modem. Anybody knows
what is wrong?
Btw, Alsa snd-intel8x0 driver works, but as many distros still default
to Oss i think this bug should be hunt.
-
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 Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote: > > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a > > Grub option), and the system just locked up hard. I just was curious > > if this was from a different change. But at least in the latest it > > shows output, and not just a hard lockup. > > > > Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06. > > ok, so it's not the recent NFS changes. Here's an interesting trace I got today. It looks either the emu10k1 or USB irq handler left IRQ 10 disabled. This isn't a tracer bug because you can clearly see this leads to an xrun. Since I've been hacking the emu10k1 driver quite a bit, I suspect this is the problem. This trace also shows that my trigger callback for the emu10k1 multichannel device needs optimizing; it takes 300 usecs to stop all 16 voices, not acceptable for an ALSA irq handler which uses SA_INTERRUPT. I think I can improve this significantly by reordering the register settings and eliminating some function call overhead. Lee latency_trace.bz2 Description: application/bzip
Re: [PATCH] Automatically append a semi-random version for BK users
Sam, my patch to automatically include a random value based upon the
BitKeeper or CVS version in the kernel version had one, rather minor,
bug related to building in seperate object and source trees.
This patch fixes that up.
Signed-Off-By: Ryan Anderson <[EMAIL PROTECTED]>
Index: local-quilt/scripts/setlocalversion
===
--- local-quilt.orig/scripts/setlocalversion2005-04-02 18:29:21.0
-0500
+++ local-quilt/scripts/setlocalversion 2005-04-02 18:29:54.0 -0500
@@ -14,6 +14,7 @@ EOT
}
my ($srctree) = @ARGV;
+chdir($srctree);
my @LOCALVERSIONS = ();
@@ -39,7 +40,6 @@ my @LOCALVERSIONS = ();
# -BK and the above 8 characters to the end of the version.
sub do_bk_checks {
- chdir($srctree);
my $changeset = `bk changes -r+ -k`;
chomp $changeset; # strip trailing \n safely
my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
@@ -69,7 +69,6 @@ sub do_bk_checks {
# On this check, there is no real need for a MD5 hash, so
# the revision number is used directly.
sub do_cvs_checks {
- chdir($srctree);
my $status = `LANG=C cvs status -v ChangeSet`;
my @lines = split /\n/, $status;
--
Ryan Anderson
sometimes Pug Majere
-
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.11.6] Oops trying to remove module "bttv"
On Sun, 3 Apr 2005, Jose Luis Domingo Lopez wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all:
>
> I am getting the following stack dump in the logs when I try to unload the
> "bttv" kernel module ("rmmod bttv" ends with SIGSEGV). I have tried with
> other kernel versions keeping "module-init-tools" version the same (Debian
> 3.1-rel-2), and realized that:
> - - 2.6.10-rc3-bk15: OK
> - - 2.6.11-rc-bk3: OK
> - - 2.6.11-rc3: FAILS
> - - 2.6.11.6: FAILS
>
> So it seems the bug was introduced somewhere 2.6.11-rc-bk3 and 2.6.11-rc3.
Have you tried 2.6.12-rc1-bk5 or 2.6.12-rc1-mm4 to see if the bug has
already been fixed ?
--
Jesper Juhl
-
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.6] Oops trying to remove module "bttv"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all:
I am getting the following stack dump in the logs when I try to unload the
"bttv" kernel module ("rmmod bttv" ends with SIGSEGV). I have tried with
other kernel versions keeping "module-init-tools" version the same (Debian
3.1-rel-2), and realized that:
- - 2.6.10-rc3-bk15: OK
- - 2.6.11-rc-bk3: OK
- - 2.6.11-rc3: FAILS
- - 2.6.11.6: FAILS
So it seems the bug was introduced somewhere 2.6.11-rc-bk3 and 2.6.11-rc3.
Looking at the 2.6.11-rc2 to 2.6.11-rc3 Changelog there seems to be
several changesets related to video4linux, but apparently just one related
to the bttv.ko kernel module (changeset number 1.1966.2.154). I am,
however, not qualified to tell if the problem is there:
bttv0: unloading
Unable to handle kernel NULL pointer dereference at virtual address 0224
printing eip:
e0c3d95d
*pde =
Oops: [#1]
Modules linked in: md5 ipv6 snd_via82xx uhci_hcd usbcore i2c_viapro tuner
tvaudio bttv video_buf v4l2_common btcx_risc tveeprom videodev 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 skystar2 dvb_core mt352 stv0299 nxt2002 firmware_class mt312 8139too
8139cp mii via_agp agpgart reiserfs xfs exportfs dm_mod it87 i2c_sensor i2c_isa
rtc
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010206 (2.6.11.6)
EIP is at bttv_i2c_info+0x3d/0x80 [bttv]
eax: 01a0 ebx: df8df77c ecx: df8df6c0 edx: 0004
esi: e0c4dba0 edi: ebp: deaf7800 esp: de42be38
ds: 007b es: 007b ss: 0068
Process rmmod (pid: 2448, threadinfo=de42a000 task=df908a40)
Stack: e0c4da64 c01b3c70 c01b4719 deaf7800 df683920 e0c4d9e4 e0c3d2f4
e0c4d9e0 deaf7800 c024e89e deaf7800 deaf743c c0351350 c034e0e8
c034e100 df8df6e4 c034e0e8 0286 deaf7800 df683920 e0c4db44 e0c4d9e4
Call Trace:
[] kobject_release+0x0/0x10
[] kref_put+0x39/0xa0
[] detach_inform+0x24/0x30 [bttv]
[] i2c_detach_client+0x2e/0x100
[] tuner_detach+0x1d/0x40 [tuner]
[] i2c_del_adapter+0xd7/0x220
[] kobject_put+0x1e/0x30
[] kobject_put+0x1e/0x30
[] kobject_release+0x0/0x10
[] bttv_remove+0xa4/0x160 [bttv]
[] pci_device_remove+0x3b/0x40
[] device_release_driver+0x7f/0x90
[] driver_detach+0x20/0x30
[] bus_remove_driver+0x4c/0x90
[] driver_unregister+0x13/0x30
[] pci_unregister_driver+0x16/0x30
[] bttv_cleanup_module+0xf/0x1f [bttv]
[] sys_delete_module+0x167/0x1a0
[] do_munmap+0x118/0x150
[] sys_munmap+0x44/0x70
[] syscall_call+0x7/0xb
Code: 28 8b 98 c0 01 00 00 8b 13 0f 18 02 90 8d b0 c0 01 00 00 39 f3 74 2b 8d
b4 26 00 00 00 00 8d 8b 44 ff ff ff 8b 41 70 85 c0 74 09 <83> b8 84 00 00 00 00
75 1a 8b 02 89 d3 89 c2 0f 18 00 90 39 f3
Hope it helps, greetings,
- --
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Sid (Linux 2.6.11.6)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCTygRao1/w/yPYI0RAhpYAJ9mfzp3BqTYKFu7jk8n8denOqJyqQCdG+b4
8KvyhUg8GnOdnSQ3jspBqPs=
=ZaVX
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][1/7] cifs: dir.c cleanup - spaces
Jesper Juhl schrieb:
Cleanup spacing and trailing whitespace in fs/cifs/dir.c
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch1 2005-04-02
23:31:27.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-02 23:47:39.0 +0200
@@ -37,7 +37,7 @@ void renew_parental_timestamps(struct de
do {
direntry->d_time = jiffies;
direntry = direntry->d_parent;
- } while (!IS_ROOT(direntry));
+ } while (!IS_ROOT(direntry));
}
/* Note: caller must free return buffer */
@@ -47,27 +47,27 @@ char *build_path_from_dentry(struct dent
int namelen = 0;
char *full_path;
- if(direntry == NULL)
- return NULL; /* not much we can do if dentry is freed and
+ if (direntry == NULL)
+ return NULL;/* not much we can do if dentry is freed and
we need to reopen the file after it was closed implicitly
when the server crashed */
cifs_bp_rename_retry:
- for (temp = direntry; !IS_ROOT(temp);) {
+ for (temp = direntry; !IS_ROOT(temp); ) {
namelen += (1 + temp->d_name.len);
temp = temp->d_parent;
- if(temp == NULL) {
- cERROR(1,("corrupt dentry"));
+ if (temp == NULL) {
+ cERROR(1, ("corrupt dentry"));
return NULL;
}
}
- full_path = kmalloc(namelen+1, GFP_KERNEL);
- if(full_path == NULL)
+ full_path = kmalloc(namelen + 1, GFP_KERNEL);
+ if (full_path == NULL)
return full_path;
full_path[namelen] = 0; /* trailing null */
- for (temp = direntry; !IS_ROOT(temp);) {
+ for (temp = direntry; !IS_ROOT(temp); ) {
namelen -= 1 + temp->d_name.len;
if (namelen < 0) {
break;
@@ -78,16 +78,15 @@ cifs_bp_rename_retry:
cFYI(0, (" name: %s ", full_path + namelen));
}
temp = temp->d_parent;
- if(temp == NULL) {
- cERROR(1,("corrupt dentry"));
+ if (temp == NULL) {
+ cERROR(1, ("corrupt dentry"));
kfree(full_path);
return NULL;
}
}
if (namelen != 0) {
- cERROR(1,
- ("We did not end path lookup where we expected namelen is %d",
- namelen));
+ cERROR(1, ("We did not end path lookup where we expected "
+ "namelen is %d", namelen));
/* presumably this is only possible if we were racing with a rename
of one of the parent directories (we can not lock the dentries
above us to prevent this, but retrying should be harmless) */
@@ -106,30 +105,30 @@ char *build_wildcard_path_from_dentry(st
int namelen = 0;
char *full_path;
- if(direntry == NULL)
- return NULL; /* not much we can do if dentry is freed and
+ if (direntry == NULL)
+ return NULL;/* not much we can do if dentry is freed and
we need to reopen the file after it was closed implicitly
when the server crashed */
cifs_bwp_rename_retry:
- for (temp = direntry; !IS_ROOT(temp);) {
+ for (temp = direntry; !IS_ROOT(temp); ) {
namelen += (1 + temp->d_name.len);
temp = temp->d_parent;
- if(temp == NULL) {
- cERROR(1,("corrupt dentry"));
+ if (temp == NULL) {
+ cERROR(1, ("corrupt dentry"));
return NULL;
}
}
- full_path = kmalloc(namelen+3, GFP_KERNEL);
- if(full_path == NULL)
+ full_path = kmalloc(namelen + 3, GFP_KERNEL);
+ if (full_path == NULL)
return full_path;
full_path[namelen] = '\\';
- full_path[namelen+1] = '*';
- full_path[namelen+2] = 0; /* trailing null */
+ full_path[namelen + 1] = '*';
+ full_path[namelen + 2] = 0; /* trailing null */
- for (temp = direntry; !IS_ROOT(temp);) {
+ for (temp = direntry; !IS_ROOT(temp); ) {
namelen -= 1 + temp->d_name.len;
if (namelen < 0) {
break;
@@ -140,16 +139,15 @@ cifs_bwp_rename_retry:
cFYI(0, (" name: %s ", full_path + namelen));
}
temp = temp->d_parent;
- if(temp == NULL) {
- cERROR(1,("corrupt dentry"));
+ if (temp == NULL) {
+ cERROR(1, ("corrupt dentry"));
kfree(full_path);
return NULL;
}
}
if (namelen != 0) {
- cERROR(1,
- ("We did not end path lookup where we expected namelen is %d",
- namelen));
+ cERROR(1, ("We did not end path lookup where we expected "
+ "namelen is %d", namelen));
/* presumably this is only possible if we were racing with a rename
of one of the parent directories (we can not lock the dentries
above us to prevent this, but retrying should be harmless) */
@@ -173,10 +171,10 @@ int cifs_create(struct inode *inode, str
struct cifs_sb_info *cifs_sb;
struct cifsTconInfo *pTcon;
char *full_path = NULL;
- FILE_ALL_INFO * buf = NULL;
+ FILE_ALL_INFO *buf = NULL;
struct inode *newinode = NULL;
- struct cifsFileInf
Re: [PATCH][1/7] cifs: dir.c cleanup - spaces
On Sun, 3 Apr 2005, Matthias-Christian Ott wrote: > Jesper Juhl schrieb: > > > Cleanup spacing and trailing whitespace in fs/cifs/dir.c > > [snip] > > > The Subject is wrong it must be: "[PATCH][2/7] cifs: dir.c cleanup - spaces" > Yup, it is. Unfortunately I only saw that milliseconds *after* I had send the mail... -- Jesper - 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/7] cifs: dir.c cleanup - spaces
Labeled this one [1/7] initially, by mistake, it is of course [2/7] -
whoops.
Cleanup spacing and trailing whitespace in fs/cifs/dir.c
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch1 2005-04-02
23:31:27.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-02 23:47:39.0 +0200
@@ -37,7 +37,7 @@ void renew_parental_timestamps(struct de
do {
direntry->d_time = jiffies;
direntry = direntry->d_parent;
- } while (!IS_ROOT(direntry));
+ } while (!IS_ROOT(direntry));
}
/* Note: caller must free return buffer */
@@ -47,27 +47,27 @@ char *build_path_from_dentry(struct dent
int namelen = 0;
char *full_path;
- if(direntry == NULL)
- return NULL; /* not much we can do if dentry is freed and
+ if (direntry == NULL)
+ return NULL;/* not much we can do if dentry is freed and
we need to reopen the file after it was closed implicitly
when the server crashed */
cifs_bp_rename_retry:
- for (temp = direntry; !IS_ROOT(temp);) {
+ for (temp = direntry; !IS_ROOT(temp); ) {
namelen += (1 + temp->d_name.len);
temp = temp->d_parent;
- if(temp == NULL) {
- cERROR(1,("corrupt dentry"));
+ if (temp == NULL) {
+ cERROR(1, ("corrupt dentry"));
return NULL;
}
}
- full_path = kmalloc(namelen+1, GFP_KERNEL);
- if(full_path == NULL)
+ full_path = kmalloc(namelen + 1, GFP_KERNEL);
+ if (full_path == NULL)
return full_path;
full_path[namelen] = 0; /* trailing null */
- for (temp = direntry; !IS_ROOT(temp);) {
+ for (temp = direntry; !IS_ROOT(temp); ) {
namelen -= 1 + temp->d_name.len;
if (namelen < 0) {
break;
@@ -78,16 +78,15 @@ cifs_bp_rename_retry:
cFYI(0, (" name: %s ", full_path + namelen));
}
temp = temp->d_parent;
- if(temp == NULL) {
- cERROR(1,("corrupt dentry"));
+ if (temp == NULL) {
+ cERROR(1, ("corrupt dentry"));
kfree(full_path);
return NULL;
}
}
if (namelen != 0) {
- cERROR(1,
- ("We did not end path lookup where we expected namelen
is %d",
- namelen));
+ cERROR(1, ("We did not end path lookup where we expected "
+ "namelen is %d", namelen));
/* presumably this is only possible if we were racing with a
rename
of one of the parent directories (we can not lock the dentries
above us to prevent this, but retrying should be harmless) */
@@ -106,30 +105,30 @@ char *build_wildcard_path_from_dentry(st
int namelen = 0;
char *full_path;
- if(direntry == NULL)
- return NULL; /* not much we can do if dentry is freed and
+ if (direntry == NULL)
+ return NULL;/* not much we can do if dentry is freed and
we need to reopen the file after it was closed implicitly
when the server crashed */
cifs_bwp_rename_retry:
- for (temp = direntry; !IS_ROOT(temp);) {
+ for (temp = direntry; !IS_ROOT(temp); ) {
namelen += (1 + temp->d_name.len);
temp = temp->d_parent;
- if(temp == NULL) {
- cERROR(1,("corrupt dentry"));
+ if (temp == NULL) {
+ cERROR(1, ("corrupt dentry"));
return NULL;
}
}
- full_path = kmalloc(namelen+3, GFP_KERNEL);
- if(full_path == NULL)
+ full_path = kmalloc(namelen + 3, GFP_KERNEL);
+ if (full_path == NULL)
return full_path;
full_path[namelen] = '\\';
- full_path[namelen+1] = '*';
- full_path[namelen+2] = 0; /* trailing null */
+ full_path[namelen + 1] = '*';
+ full_path[namelen + 2] = 0; /* trailing null */
- for (temp = direntry; !IS_ROOT(temp);) {
+ for (temp = direntry; !IS_ROOT(temp); ) {
namelen -= 1 + temp->d_name.len;
if (namelen < 0) {
break;
@@ -140,16 +139,15 @@ cifs_bwp_rename_retry:
cFYI(0, (" name: %s ", full_path + namelen));
}
temp = temp->d_parent;
- if(temp == NULL) {
- cERROR(1,("corrupt dentry"));
+ if (temp == NULL) {
+ cERROR(1, ("corrupt dentry"));
kfree(full_path);
return
[PATCH][5/7] cifs: dir.c cleanup - cast
Don't cast the pointer returned from kmalloc()
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch4 2005-04-03
00:03:33.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-03 00:04:58.0 +0200
@@ -280,8 +280,8 @@ int cifs_create(struct inode *inode, str
/* mknod case - do not leave file open */
CIFSSMBClose(xid, pTcon, fileHandle);
} else if (newinode) {
- pCifsFile = (struct cifsFileInfo *)
- kmalloc(sizeof (struct cifsFileInfo), GFP_KERNEL);
+ pCifsFile = kmalloc(sizeof(struct cifsFileInfo),
+ GFP_KERNEL);
if (pCifsFile) {
memset((char *)pCifsFile, 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][6/7] cifs: dir.c cleanup - long lines 1
Lines should be <80 chars in length.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch5 2005-04-03
00:06:17.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-03 00:07:59.0 +0200
@@ -193,9 +193,9 @@ int cifs_create(struct inode *inode, str
}
if (nd) {
- if ((nd->intent.open.flags & O_ACCMODE) == O_RDONLY)
+ if ((nd->intent.open.flags & O_ACCMODE) == O_RDONLY) {
desiredAccess = GENERIC_READ;
- else if ((nd->intent.open.flags & O_ACCMODE) == O_WRONLY) {
+ } else if ((nd->intent.open.flags & O_ACCMODE) == O_WRONLY) {
desiredAccess = GENERIC_WRITE;
write_only = TRUE;
} else if ((nd->intent.open.flags & O_ACCMODE) == O_RDWR) {
@@ -205,15 +205,16 @@ int cifs_create(struct inode *inode, str
desiredAccess = GENERIC_READ | GENERIC_WRITE;
}
- if ((nd->intent.open.flags & (O_CREAT | O_EXCL)) == (O_CREAT |
O_EXCL))
+ if ((nd->intent.open.flags & (O_CREAT | O_EXCL)) ==
+ (O_CREAT | O_EXCL))
disposition = FILE_CREATE;
- else if ((nd->intent.open.flags & (O_CREAT | O_TRUNC)) ==
(O_CREAT | O_TRUNC))
+ else if ((nd->intent.open.flags & (O_CREAT | O_TRUNC)) ==
+(O_CREAT | O_TRUNC))
disposition = FILE_OVERWRITE_IF;
else if ((nd->intent.open.flags & O_CREAT) == O_CREAT)
disposition = FILE_OPEN_IF;
- else {
+ else
cFYI(1, ("Create flag not set in create function"));
- }
}
/* BB add processing to set equivalent of mode -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH][3/7] cifs: dir.c cleanup - comments
Beautify comments in fs/cifs/dir.c and make them style-wise consistent with
the other files.
Signed-of-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch2 2005-04-02
23:51:24.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-02 23:58:37.0 +0200
@@ -33,7 +33,8 @@
void renew_parental_timestamps(struct dentry *direntry)
{
- /* BB check if there is a way to get the kernel to do this or if we
really need this */
+ /* BB check if there is a way to get the kernel to do this or if we
+ really need this */
do {
direntry->d_time = jiffies;
direntry = direntry->d_parent;
@@ -49,9 +50,8 @@ char *build_path_from_dentry(struct dent
if (direntry == NULL)
return NULL;/* not much we can do if dentry is freed and
- we need to reopen the file after it was closed implicitly
- when the server crashed */
-
+ we need to reopen the file after it was
+ closed implicitly when the server crashed */
cifs_bp_rename_retry:
for (temp = direntry; !IS_ROOT(temp); ) {
namelen += (1 + temp->d_name.len);
@@ -87,9 +87,10 @@ cifs_bp_rename_retry:
if (namelen != 0) {
cERROR(1, ("We did not end path lookup where we expected "
"namelen is %d", namelen));
- /* presumably this is only possible if we were racing with a
rename
- of one of the parent directories (we can not lock the dentries
- above us to prevent this, but retrying should be harmless) */
+ /* presumably this is only possible if we were racing with a
+ rename of one of the parent directories (we can not lock the
+ dentries above us to prevent this, but retrying should be
+ harmless) */
kfree(full_path);
namelen = 0;
goto cifs_bp_rename_retry;
@@ -106,10 +107,9 @@ char *build_wildcard_path_from_dentry(st
char *full_path;
if (direntry == NULL)
- return NULL;/* not much we can do if dentry is freed and
- we need to reopen the file after it was closed implicitly
- when the server crashed */
-
+ return NULL;/* not much we can do if dentry is freed and we
+ need to reopen the file after it was closed
+ implicitly when the server crashed */
cifs_bwp_rename_retry:
for (temp = direntry; !IS_ROOT(temp); ) {
namelen += (1 + temp->d_name.len);
@@ -148,9 +148,10 @@ cifs_bwp_rename_retry:
if (namelen != 0) {
cERROR(1, ("We did not end path lookup where we expected "
"namelen is %d", namelen));
- /* presumably this is only possible if we were racing with a
rename
- of one of the parent directories (we can not lock the dentries
- above us to prevent this, but retrying should be harmless) */
+ /* presumably this is only possible if we were racing with a
+ rename of one of the parent directories (we can not lock the
+ dentries above us to prevent this, but retrying should be
+ harmless) */
kfree(full_path);
namelen = 0;
goto cifs_bwp_rename_retry;
@@ -159,7 +160,7 @@ cifs_bwp_rename_retry:
return full_path;
}
-/* Inode operations in similar order to how they appear in the Linux file fs.h
*/
+/* Inode operations in similar order to how they appear in Linux file fs.h */
int cifs_create(struct inode *inode, struct dentry *direntry, int mode,
struct nameidata *nd)
{
@@ -198,8 +199,8 @@ int cifs_create(struct inode *inode, str
desiredAccess = GENERIC_WRITE;
write_only = TRUE;
} else if ((nd->intent.open.flags & O_ACCMODE) == O_RDWR) {
- /* GENERIC_ALL is too much permission to request */
- /* can cause unnecessary access denied on create */
+ /* GENERIC_ALL is too much permission to request
+ can cause unnecessary access denied on create */
/* desiredAccess = GENERIC_ALL; */
desiredAccess = GENERIC_READ | GENERIC_WRITE;
}
@@ -215,7 +216,8 @@ int cifs_create(struct inode *inode, str
}
}
- /* BB add processing to set equivalent of mode - e.g. via CreateX with
ACLs */
+ /* BB add processing to set equivalent of mode -
+ e.g. via CreateX with ACLs */
if (oplockEnabled)
oplock = REQ_OPLOCK;
@@ -232,8 +234,8 @@ int cifs_create(struct inode *inode, s
[PATCH][7/7] cifs: dir.c cleanup - long lines 2
Lines should be less than 80chars, rework cifs_create() a bit to fit more
easily.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch6 2005-04-03
00:17:50.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-03 00:21:00.0 +0200
@@ -283,44 +283,45 @@ int cifs_create(struct inode *inode, str
} else if (newinode) {
pCifsFile = kmalloc(sizeof(struct cifsFileInfo),
GFP_KERNEL);
+ if (!pCifsFile)
+ goto no_file;
- if (pCifsFile) {
- memset((char *)pCifsFile, 0,
- sizeof(struct cifsFileInfo));
- pCifsFile->netfid = fileHandle;
- pCifsFile->pid = current->tgid;
- pCifsFile->pInode = newinode;
- pCifsFile->invalidHandle = FALSE;
- pCifsFile->closePend = FALSE;
- init_MUTEX(&pCifsFile->fh_sem);
- /* put the following in at open now */
- /* pCifsFile->pfile = file; */
- write_lock(&GlobalSMBSeslock);
- list_add(&pCifsFile->tlist,
-&pTcon->openFileList);
- pCifsInode = CIFS_I(newinode);
- if (pCifsInode) {
- /* if readable file instance put first in list
- */
- if (write_only == TRUE) {
- list_add_tail(&pCifsFile->flist,
-
&pCifsInode->openFileList);
- } else {
- list_add(&pCifsFile->flist,
-
&pCifsInode->openFileList);
- }
- if ((oplock & 0xF) == OPLOCK_EXCLUSIVE)
{
- pCifsInode->clientCanCacheAll =
TRUE;
- pCifsInode->clientCanCacheRead
= TRUE;
- cFYI(1, ("Exclusive Oplock
granted on inode %p",
- newinode));
- } else if ((oplock & 0xF) ==
OPLOCK_READ)
- pCifsInode->clientCanCacheRead
= TRUE;
- }
- write_unlock(&GlobalSMBSeslock);
+ memset((char *)pCifsFile, 0,
+ sizeof(struct cifsFileInfo));
+ pCifsFile->netfid = fileHandle;
+ pCifsFile->pid = current->tgid;
+ pCifsFile->pInode = newinode;
+ pCifsFile->invalidHandle = FALSE;
+ pCifsFile->closePend = FALSE;
+ init_MUTEX(&pCifsFile->fh_sem);
+ /* put the following in at open now */
+ /* pCifsFile->pfile = file; */
+ write_lock(&GlobalSMBSeslock);
+ list_add(&pCifsFile->tlist, &pTcon->openFileList);
+ pCifsInode = CIFS_I(newinode);
+ if (!pCifsInode)
+ goto no_inode;
+
+ /* if readable file instance put first in list */
+ if (write_only == TRUE) {
+ list_add_tail(&pCifsFile->flist,
+ &pCifsInode->openFileList);
+ } else {
+ list_add(&pCifsFile->flist,
+&pCifsInode->openFileList);
}
+ if ((oplock & 0xF) == OPLOCK_EXCLUSIVE) {
+ pCifsInode->clientCanCacheAll = TRUE;
+ pCifsInode->clientCanCacheRead = TRUE;
+ cFYI(1, ("Exclusive Oplock granted on inode"
+" %p", newinode));
+ } else if ((oplock & 0xF) == OPLOCK_READ)
+ pCifsInode->clientCanCacheRead = TRUE;
+no_inode:
+ write_unlock(&GlobalSMBSeslock);
}
}
+no_file:
kfree(buf);
kfree(full_path);
-
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
[PATCH][4/7] cifs: dir.c cleanup - kfree()
Remove redundant NULL pointer checks before kfree() in fs/cifs/dir.c
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch3 2005-04-03
00:02:22.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-03 00:02:24.0 +0200
@@ -321,12 +321,9 @@ int cifs_create(struct inode *inode, str
}
}
- if (buf)
- kfree(buf);
- if (full_path)
- kfree(full_path);
+ kfree(buf);
+ kfree(full_path);
FreeXid(xid);
-
return rc;
}
@@ -377,10 +374,8 @@ int cifs_mknod(struct inode *inode, stru
}
}
- if (full_path)
- kfree(full_path);
+ kfree(full_path);
FreeXid(xid);
-
return rc;
}
@@ -450,8 +445,7 @@ struct dentry *cifs_lookup(struct inode
if file exists or not but no access BB */
}
- if (full_path)
- kfree(full_path);
+ kfree(full_path);
FreeXid(xid);
return ERR_PTR(rc);
}
@@ -481,8 +475,7 @@ int cifs_dir_open(struct inode *inode, s
cFYI(1, ("inode = 0x%p and full path is %s", inode, full_path));
- if (full_path)
- kfree(full_path);
+ kfree(full_path);
FreeXid(xid);
return rc;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH][1/7] cifs: dir.c cleanup - spaces
Cleanup spacing and trailing whitespace in fs/cifs/dir.c
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4/fs/cifs/dir.c.with_patch1 2005-04-02
23:31:27.0 +0200
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-02 23:47:39.0 +0200
@@ -37,7 +37,7 @@ void renew_parental_timestamps(struct de
do {
direntry->d_time = jiffies;
direntry = direntry->d_parent;
- } while (!IS_ROOT(direntry));
+ } while (!IS_ROOT(direntry));
}
/* Note: caller must free return buffer */
@@ -47,27 +47,27 @@ char *build_path_from_dentry(struct dent
int namelen = 0;
char *full_path;
- if(direntry == NULL)
- return NULL; /* not much we can do if dentry is freed and
+ if (direntry == NULL)
+ return NULL;/* not much we can do if dentry is freed and
we need to reopen the file after it was closed implicitly
when the server crashed */
cifs_bp_rename_retry:
- for (temp = direntry; !IS_ROOT(temp);) {
+ for (temp = direntry; !IS_ROOT(temp); ) {
namelen += (1 + temp->d_name.len);
temp = temp->d_parent;
- if(temp == NULL) {
- cERROR(1,("corrupt dentry"));
+ if (temp == NULL) {
+ cERROR(1, ("corrupt dentry"));
return NULL;
}
}
- full_path = kmalloc(namelen+1, GFP_KERNEL);
- if(full_path == NULL)
+ full_path = kmalloc(namelen + 1, GFP_KERNEL);
+ if (full_path == NULL)
return full_path;
full_path[namelen] = 0; /* trailing null */
- for (temp = direntry; !IS_ROOT(temp);) {
+ for (temp = direntry; !IS_ROOT(temp); ) {
namelen -= 1 + temp->d_name.len;
if (namelen < 0) {
break;
@@ -78,16 +78,15 @@ cifs_bp_rename_retry:
cFYI(0, (" name: %s ", full_path + namelen));
}
temp = temp->d_parent;
- if(temp == NULL) {
- cERROR(1,("corrupt dentry"));
+ if (temp == NULL) {
+ cERROR(1, ("corrupt dentry"));
kfree(full_path);
return NULL;
}
}
if (namelen != 0) {
- cERROR(1,
- ("We did not end path lookup where we expected namelen
is %d",
- namelen));
+ cERROR(1, ("We did not end path lookup where we expected "
+ "namelen is %d", namelen));
/* presumably this is only possible if we were racing with a
rename
of one of the parent directories (we can not lock the dentries
above us to prevent this, but retrying should be harmless) */
@@ -106,30 +105,30 @@ char *build_wildcard_path_from_dentry(st
int namelen = 0;
char *full_path;
- if(direntry == NULL)
- return NULL; /* not much we can do if dentry is freed and
+ if (direntry == NULL)
+ return NULL;/* not much we can do if dentry is freed and
we need to reopen the file after it was closed implicitly
when the server crashed */
cifs_bwp_rename_retry:
- for (temp = direntry; !IS_ROOT(temp);) {
+ for (temp = direntry; !IS_ROOT(temp); ) {
namelen += (1 + temp->d_name.len);
temp = temp->d_parent;
- if(temp == NULL) {
- cERROR(1,("corrupt dentry"));
+ if (temp == NULL) {
+ cERROR(1, ("corrupt dentry"));
return NULL;
}
}
- full_path = kmalloc(namelen+3, GFP_KERNEL);
- if(full_path == NULL)
+ full_path = kmalloc(namelen + 3, GFP_KERNEL);
+ if (full_path == NULL)
return full_path;
full_path[namelen] = '\\';
- full_path[namelen+1] = '*';
- full_path[namelen+2] = 0; /* trailing null */
+ full_path[namelen + 1] = '*';
+ full_path[namelen + 2] = 0; /* trailing null */
- for (temp = direntry; !IS_ROOT(temp);) {
+ for (temp = direntry; !IS_ROOT(temp); ) {
namelen -= 1 + temp->d_name.len;
if (namelen < 0) {
break;
@@ -140,16 +139,15 @@ cifs_bwp_rename_retry:
cFYI(0, (" name: %s ", full_path + namelen));
}
temp = temp->d_parent;
- if(temp == NULL) {
- cERROR(1,("corrupt dentry"));
+ if (temp == NULL) {
+ cERROR(1, ("corrupt dentry"));
kfree(full_path);
return NULL;
}
}
if (namelen != 0) {
- cERR
[PATCH][1/7] cifs: dir.c cleanup - function defs
Whitespace cleanups of function definitions in fs/cifs/dir.c
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm4-orig/fs/cifs/dir.c 2005-03-02 08:38:12.0
+0100
+++ linux-2.6.12-rc1-mm4/fs/cifs/dir.c 2005-04-02 23:28:28.0 +0200
@@ -31,8 +31,7 @@
#include "cifs_debug.h"
#include "cifs_fs_sb.h"
-void
-renew_parental_timestamps(struct dentry *direntry)
+void renew_parental_timestamps(struct dentry *direntry)
{
/* BB check if there is a way to get the kernel to do this or if we
really need this */
do {
@@ -42,8 +41,7 @@ renew_parental_timestamps(struct dentry
}
/* Note: caller must free return buffer */
-char *
-build_path_from_dentry(struct dentry *direntry)
+char *build_path_from_dentry(struct dentry *direntry)
{
struct dentry *temp;
int namelen = 0;
@@ -102,8 +100,7 @@ cifs_bp_rename_retry:
}
/* Note: caller must free return buffer */
-char *
-build_wildcard_path_from_dentry(struct dentry *direntry)
+char *build_wildcard_path_from_dentry(struct dentry *direntry)
{
struct dentry *temp;
int namelen = 0;
@@ -165,10 +162,8 @@ cifs_bwp_rename_retry:
}
/* Inode operations in similar order to how they appear in the Linux file fs.h
*/
-
-int
-cifs_create(struct inode *inode, struct dentry *direntry, int mode,
- struct nameidata *nd)
+int cifs_create(struct inode *inode, struct dentry *direntry, int mode,
+ struct nameidata *nd)
{
int rc = -ENOENT;
int xid;
@@ -332,7 +327,8 @@ cifs_create(struct inode *inode, struct
return rc;
}
-int cifs_mknod(struct inode *inode, struct dentry *direntry, int mode, dev_t
device_number)
+int cifs_mknod(struct inode *inode, struct dentry *direntry, int mode,
+ dev_t device_number)
{
int rc = -EPERM;
int xid;
@@ -382,9 +378,8 @@ int cifs_mknod(struct inode *inode, stru
return rc;
}
-
-struct dentry *
-cifs_lookup(struct inode *parent_dir_inode, struct dentry *direntry, struct
nameidata *nd)
+struct dentry *cifs_lookup(struct inode *parent_dir_inode,
+ struct dentry *direntry, struct nameidata *nd)
{
int xid;
int rc = 0; /* to get around spurious gcc warning, set to zero here */
@@ -453,9 +448,9 @@ cifs_lookup(struct inode *parent_dir_ino
return ERR_PTR(rc);
}
-int
-cifs_dir_open(struct inode *inode, struct file *file)
-{ /* NB: currently unused since searches are
opened in readdir */
+int cifs_dir_open(struct inode *inode, struct file *file)
+{
+/* NB: currently unused since searches are opened in readdir */
int rc = 0;
int xid;
struct cifs_sb_info *cifs_sb;
@@ -484,8 +479,7 @@ cifs_dir_open(struct inode *inode, struc
return rc;
}
-static int
-cifs_d_revalidate(struct dentry *direntry, struct nameidata *nd)
+static int cifs_d_revalidate(struct dentry *direntry, struct nameidata *nd)
{
int isValid = 1;
-
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.6: Mach64 driver spams the console
Can someone please explain why I get this every time I switch in and out of X? And better yet how do I turn this off? debug atyfb: Mach64 non-shadow register values: debug atyfb: 0x2000: 004F0063 000C0052 01DF020C 000201EA debug atyfb: 0x2010: 016F 1400 0020 0B002200 debug atyfb: 0x2020: 005B04BC 0068048E 00382848 debug atyfb: 0x2030: 00200213 C001 debug atyfb: 0x2040: 0450098B debug atyfb: 0x2050: 04C506DB debug atyfb: 0x2060: AA0F 0007FE00 00300088 debug atyfb: 0x2070: 0030 3700 48833800 debug atyfb: 0x2080: 04900400 0F0B000C 00020002 debug atyfb: 0x2090: 00803003 0A000100 debug atyfb: 0x20A0: 7B23A050 0107 6001 E5000CF1 debug atyfb: 0x20B0: 00165A27 0001 0001 debug atyfb: 0x20C0: 00FF0010 86010182 debug atyfb: 0x20D0: 0100 007F0179 3F02 debug atyfb: 0x20E0: 65004752 00410096 debug atyfb: 0x20F0: F6FE FB8004F8 debug atyfb: Mach64 PLL register values: debug atyfb: 0x00: ADD51FE4 8103FFDA F500DA0A 801B debug atyfb: 0x10: 00CF4000 10ADAC10 400024FD 0002 debug atyfb: 0x20: 06AC0610 1424FD00 00195500 debug atyfb: 0x30: -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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][0/7] cifs: dir.c cleanup
Hi Steve, Here's yet another round of cleanups for fs/cifs/ - this time it's for dir.c. I believe this marks the end of the files you wanted done in a specific order, so now I'll be going through the remaining ones in arbitrary order. Just like for the previous files I've split the cleanups into chunks that do just one (or a few closely related) thing. The patches will be sent inline with explanations shortly, but are also available here : http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_dir-cleanup-functions.patch http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_dir-cleanup-spaces.patch http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_dir-cleanup-comments.patch http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_dir-cleanup-kfree.patch http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_dir-cleanup-cast.patch http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_dir-cleanup-long-lines-1.patch http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_dir-cleanup-long-lines-2.patch (listed in the order they apply) -- Jesper Juhl - 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 Saturday 02 April 2005 15:34, Ingo Molnar wrote:
>* Lee Revell <[EMAIL PROTECTED]> wrote:
>> It wasn't clear from your last mail whether you were using NFS.
>> If so I would be suspicious given the NFS changes in the new RT
>> patches. I'll try to reproduce the problem on a local fs.
>
>also, try to undo the fs/nfs/*.c and include/linux/*nfs*.h changes,
>those are latency breakers, so not strictly necessary.
>
> Ingo
Hi Ingo;
I just got done rebooting to 43-06, had problems with my heyu
startup scripts again, but I finally found a missing & in one
of them, and I can have it recycle itself from the cli like it
used to again.
So far, with *all* the 'logit' switches turned on and in full
preempt mode, there's nothing unusual in the log.
Here goes tvtime from a cli:
Audio only, blue screen video, this in the log:
---
Apr 2 17:12:48 coyote kernel: cx88[0]: video y / packed - dma channel status
dump
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: initial risc: 0x06b46000
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: cdt base: 0x00180440
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: cdt size: 0x000c
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq base : 0x00180400
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq size : 0x0010
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: risc pc : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq wr ptr : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq rd ptr : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: cdt current : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: pci target : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: line / byte : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: risc0: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: risc1: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: risc2: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: risc3: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 0: 0x80008000 [ sync resync
count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 1: 0x1c000500 [ write sol eol
count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 2: 0x06922000 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 3: 0x1c000500 [ write sol eol
count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 4: 0x06922a00 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 5: 0x1c000500 [ write sol eol
count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 6: 0x2dc68400 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 7: 0x18000200 [ write sol
count=512 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 8: 0x2dc68e00 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 9: 0x14000300 [ write eol
count=768 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq a: 0x2dc69000 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq b: 0x1c000500 [ write sol eol
count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq c: 0x2dc69800 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq d: 0x0031c040 [ INVALID 21 20 cnt0
resync 14 count=64 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq e: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq f: 0x0011 [ INVALID count=17 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: fifo: 0x00180c00 -> 0x183400
Apr 2 17:12:48 coyote kernel: cx88[0]: ctrl: 0x00180400 -> 0x180460
Apr 2 17:12:48 coyote kernel: cx88[0]: ptr1_reg: 0x00182118
Apr 2 17:12:48 coyote kernel: cx88[0]: ptr2_reg: 0x00180488
Apr 2 17:12:48 coyote kernel: cx88[0]: cnt1_reg: 0x0082
Apr 2 17:12:48 coyote kernel: cx88[0]: cnt2_reg: 0x
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d4da5940/0] timeout - dma=0x
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d4da5d40/1] timeout - dma=0x
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d417d960/2] timeout - dma=0x
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d4da5540/3] timeout - dma=0x06b46000
Apr 2 17:12:49 coyote kernel: cx88[0]: video y / packed - dma channel status
dump
[...]
followed by many repeats of the above as I let it run about
5-6 seconds. On exit, this:
Apr 2 17:12:57 coyote kernel: rtc latency histogram of {tvtime/5717, 232
samples}:
Apr 2 17:12:57 coyote kernel: 20 4
Apr 2 17:12:57 coyote kernel: 21 81
Apr 2 17:12:57 coyote kernel: 22 64
Apr 2 17:12:57 coyote kernel: 23 32
Apr 2 17:12:57 coyote kernel: 24 13
Apr 2 17:12:57 coyote kernel: 25 2
Apr 2 17:12:57 coyote kernel: 26 8
Apr 2 17:12:57 coyote kernel: 27 2
Apr 2 17:12:57 coyote kernel: 28 3
Apr 2 17:12:57 coyote kernel: 29 1
Apr 2 17:12:57 coyote kernel: 30 1
Apr 2 17:12:57 coyote kernel: 32 2
Apr 2 17:12:57 coyote kernel: 33 2
Apr 2 17:12:57 coyote kernel: 34 1
Apr 2 17:12:57 coyote kernel: 35 1
Apr 2 17:12:57 coyote kernel: 37 1
Apr 2 17:12:57 coyote kernel: 14
dma timeouts. I don't get these, and I do get good vi
Re: [2.6.12-rc1-mm4] swapped memset arguments
On Sat, 2 Apr 2005, Maciej Soltysiak wrote: > Hi, > > out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments. > I found one: > > # grep -nr "memset.*\,\(\ \|\)0\(\ \|\));" * > net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct > ieee80211_txb), 0); > And here's a patch : Fix swapped memset() arguments in net/ieee80211/ieee80211_tx.c found by Maciej Soltysiak. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- linux-2.6.12-rc1-mm4-orig/net/ieee80211/ieee80211_tx.c 2005-03-31 21:20:08.0 +0200 +++ linux-2.6.12-rc1-mm4/net/ieee80211/ieee80211_tx.c 2005-04-03 00:34:22.0 +0200 @@ -223,7 +223,7 @@ struct ieee80211_txb *ieee80211_alloc_tx if (!txb) return NULL; - memset(txb, sizeof(struct ieee80211_txb), 0); + memset(txb, 0, sizeof(struct ieee80211_txb)); txb->nr_frags = nr_frags; txb->frag_size = txb_size; - 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: kernel stack size
On Sat, 2005-04-02 at 22:14 +0200, Manfred Spraul wrote: > Steven Rostedt wrote: > > >I admit you really need to know what you're doing to use this method. If > >I believe that a kmalloc would be too expensive, then I use the locking > >of static variables. But each situation is different and I try to use > >the best method for the occasion. > > > > > Have you benchmarked your own memory manager? > kmalloc(1024, GFP_KERNEL) is something like 17 instructions on i386 > uniprocessor. Where did you get that? I'm looking at the assembly of it right now and it's much larger than 17 instructions. Not to mention that it calls the slab functions which might have to invoke the buddy system. Also, I don't use my own memory manager. My memory manager would be the statically allocated globals (allocated automatically when the kernel loads at boot up) and spin_locks (which are much smaller than kmalloc) or sems. Now if kmalloc didn't have a free slab available, and needed to go to the buddy list, this gets expensive, especially if you have to contend with other processes doing the same. With the static global variable method, you only have to worry about processes (and interrupts) that are contending for your data. This can be very efficient, especially if the data IS shared with an interrupt handler. And if you want to be more efficient, just use the normal spin_lock after disabling just your interrupt. Now you don't stop other interrupts coming in, and still can work with your own global data. Since the original poster was talking about local data, and I'm talking about global, I sometimes use global variables for just local use, but you need to lock the data so that on SMP, or PREEMPT you don't worry about reentry. I haven't clocked the speed of sem compared to kmalloc. But I would think that the sem functions are still quicker. Like I mentioned before, each case is different. I do use kmalloc when I find that there will be too much contention with the data, or that I would need to lock the data for long periods of time. Then again, a sem may work too. -- Steve - 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/
u32 vs. pm_message_t fixes for drivers/net
Hi!
This fixes remaining u32s in drivers/ net. [These patches are
independend].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/drivers/net/8139cp.c 2005-01-16 22:27:04.0 +0100
+++ linux-cvs/drivers/net/8139cp.c 2005-03-31 23:54:46.0 +0200
@@ -1824,7 +1824,7 @@
}
#ifdef CONFIG_PM
-static int cp_suspend (struct pci_dev *pdev, u32 state)
+static int cp_suspend (struct pci_dev *pdev, pm_message_t state)
{
struct net_device *dev;
struct cp_private *cp;
--- clean-cvs/drivers/net/bmac.c2005-01-21 23:03:20.0 +0100
+++ linux-cvs/drivers/net/bmac.c2005-03-31 23:54:46.0 +0200
@@ -455,7 +455,7 @@
}
#ifdef CONFIG_PM
-static int bmac_suspend(struct macio_dev *mdev, u32 state)
+static int bmac_suspend(struct macio_dev *mdev, pm_message_t state)
{
struct net_device* dev = macio_get_drvdata(mdev);
struct bmac_data *bp = netdev_priv(dev);
--- clean-cvs/drivers/net/irda/sa1100_ir.c 2004-12-14 20:42:26.0
+0100
+++ linux-cvs/drivers/net/irda/sa1100_ir.c 2005-03-31 23:54:46.0
+0200
@@ -291,7 +291,7 @@
/*
* Suspend the IrDA interface.
*/
-static int sa1100_irda_suspend(struct device *_dev, u32 state, u32 level)
+static int sa1100_irda_suspend(struct device *_dev, pm_message_t state, u32
level)
{
struct net_device *dev = dev_get_drvdata(_dev);
struct sa1100_irda *si;
--- clean-cvs/drivers/net/irda/stir4200.c 2005-03-29 13:30:09.0
+0200
+++ linux-cvs/drivers/net/irda/stir4200.c 2005-03-31 23:54:46.0
+0200
@@ -1129,7 +1129,7 @@
#ifdef CONFIG_PM
/* Power management suspend, so power off the transmitter/receiver */
-static int stir_suspend(struct usb_interface *intf, u32 state)
+static int stir_suspend(struct usb_interface *intf, pm_message_t state)
{
struct stir_cb *stir = usb_get_intfdata(intf);
--- clean-cvs/drivers/net/irda/vlsi_ir.c2005-03-29 13:30:09.0
+0200
+++ linux-cvs/drivers/net/irda/vlsi_ir.c2005-03-31 23:54:46.0
+0200
@@ -1744,7 +1744,7 @@
*/
-static int vlsi_irda_suspend(struct pci_dev *pdev, u32 state)
+static int vlsi_irda_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct net_device *ndev = pci_get_drvdata(pdev);
vlsi_irda_dev_t *idev;
--- clean-cvs/drivers/net/pci-skeleton.c2005-01-16 22:27:11.0
+0100
+++ linux-cvs/drivers/net/pci-skeleton.c2005-03-31 23:54:46.0
+0200
@@ -1897,7 +1897,7 @@
#ifdef CONFIG_PM
-static int netdrv_suspend (struct pci_dev *pdev, u32 state)
+static int netdrv_suspend (struct pci_dev *pdev, pm_message_t state)
{
struct net_device *dev = pci_get_drvdata (pdev);
struct netdrv_private *tp = dev->priv;
--- clean-cvs/drivers/net/r8169.c 2005-03-29 13:30:03.0 +0200
+++ linux-cvs/drivers/net/r8169.c 2005-03-31 23:54:46.0 +0200
@@ -1449,7 +1449,7 @@
#ifdef CONFIG_PM
-static int rtl8169_suspend(struct pci_dev *pdev, u32 state)
+static int rtl8169_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct net_device *dev = pci_get_drvdata(pdev);
struct rtl8169_private *tp = netdev_priv(dev);
--- clean-cvs/drivers/net/smc91x.c 2005-03-29 13:30:04.0 +0200
+++ linux-cvs/drivers/net/smc91x.c 2005-03-31 23:54:46.0 +0200
@@ -2278,7 +2278,7 @@
return 0;
}
-static int smc_drv_suspend(struct device *dev, u32 state, u32 level)
+static int smc_drv_suspend(struct device *dev, pm_message_t state, u32 level)
{
struct net_device *ndev = dev_get_drvdata(dev);
--- clean-cvs/drivers/net/tulip/de2104x.c 2005-03-29 13:30:11.0
+0200
+++ linux-cvs/drivers/net/tulip/de2104x.c 2005-03-31 23:54:46.0
+0200
@@ -2102,7 +2102,7 @@
#ifdef CONFIG_PM
-static int de_suspend (struct pci_dev *pdev, u32 state)
+static int de_suspend (struct pci_dev *pdev, pm_message_t state)
{
struct net_device *dev = pci_get_drvdata (pdev);
struct de_private *de = dev->priv;
--- clean-cvs/drivers/net/tulip/winbond-840.c 2005-01-21 23:03:30.0
+0100
+++ linux-cvs/drivers/net/tulip/winbond-840.c 2005-03-31 23:54:46.0
+0200
@@ -1620,7 +1620,7 @@
* Detach must occur under spin_unlock_irq(), interrupts from a detached
* device would cause an irq storm.
*/
-static int w840_suspend (struct pci_dev *pdev, u32 state)
+static int w840_suspend (struct pci_dev *pdev, pm_message_t state)
{
struct net_device *dev = pci_get_drvdata (pdev);
struct netdev_private *np = netdev_priv(dev);
--- clean-cvs/drivers/net/tulip/xircom_tulip_cb.c 2005-01-11
01:37:17.0 +0100
+++ linux-cvs/drivers/net/tulip/xircom_tulip_cb.c 2005-03-31
23:54:46.0 +0200
@@ -1655,7 +1655,7 @@
#ifdef CONFIG_PM
-static int xircom_suspend(struct pci_dev *pdev, u32 sta
Re: fs/partitions/msdos.c, scripts/packages/Makefile
On Fri, Apr 01, 2005 at 07:18:52PM +0200, Uwe Zybell wrote: > There is a line in fs/partitions/msdos.c that lets extended partitions > be max 1k (..."==1 ? 1 : 2"...). The comment explains it to protect > sysadmins from themselves. But now I have found a legitimate use > for extended partitions in their full length. Emulation. > Please remove this, or make it a config option. Config options are evil. Adding them is a bad form of bloat. Whatever you want to do, there are many ways to do it without changing this part of the kernel code. After all, any partition is just part of the entire disk. Note that there are aliasing problems - it is bad to access data both via a file system and via raw disk or partition. Andries - 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/
fix u32 vs. pm_message_t in PCI, PCIE
Hi!
This fixes drivers/pci (mostly pcie stuff). [These patches are
independend and change no object code; therefore not numbered].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/drivers/pci/hotplug/pciehp_core.c 2005-01-21 23:03:34.0
+0100
+++ linux-cvs/drivers/pci/hotplug/pciehp_core.c 2005-03-31 23:54:46.0
+0200
@@ -578,7 +578,7 @@
}
#ifdef CONFIG_PM
-static int pciehp_suspend (struct pcie_device *dev, u32 state)
+static int pciehp_suspend (struct pcie_device *dev, pm_message_t state)
{
printk("%s ENTRY\n", __FUNCTION__);
return 0;
--- clean-cvs/drivers/pci/pcie/portdrv.h2005-02-06 10:02:01.0
+0100
+++ linux-cvs/drivers/pci/pcie/portdrv.h2005-03-31 23:54:46.0
+0200
@@ -31,7 +31,7 @@
extern int pcie_port_device_probe(struct pci_dev *dev);
extern int pcie_port_device_register(struct pci_dev *dev);
#ifdef CONFIG_PM
-extern int pcie_port_device_suspend(struct pci_dev *dev, u32 state);
+extern int pcie_port_device_suspend(struct pci_dev *dev, pm_message_t state);
extern int pcie_port_device_resume(struct pci_dev *dev);
#endif
extern void pcie_port_device_remove(struct pci_dev *dev);
--- clean-cvs/drivers/pci/pcie/portdrv_bus.c2005-02-06 10:02:01.0
+0100
+++ linux-cvs/drivers/pci/pcie/portdrv_bus.c2005-03-31 23:54:46.0
+0200
@@ -15,7 +15,7 @@
#include
static int pcie_port_bus_match(struct device *dev, struct device_driver *drv);
-static int pcie_port_bus_suspend(struct device *dev, u32 state);
+static int pcie_port_bus_suspend(struct device *dev, pm_message_t state);
static int pcie_port_bus_resume(struct device *dev);
struct bus_type pcie_port_bus_type = {
@@ -46,7 +46,7 @@
return 1;
}
-static int pcie_port_bus_suspend(struct device *dev, u32 state)
+static int pcie_port_bus_suspend(struct device *dev, pm_message_t state)
{
struct pcie_device *pciedev;
struct pcie_port_service_driver *driver;
--- clean-cvs/drivers/pci/pcie/portdrv_core.c 2005-02-06 10:02:01.0
+0100
+++ linux-cvs/drivers/pci/pcie/portdrv_core.c 2005-03-31 23:54:46.0
+0200
@@ -61,7 +61,7 @@
static void pcie_port_shutdown_service(struct device *dev) {}
-static int pcie_port_suspend_service(struct device *dev, u32 state, u32 level)
+static int pcie_port_suspend_service(struct device *dev, pm_message_t state,
u32 level)
{
struct pcie_device *pciedev;
struct pcie_port_service_driver *driver;
@@ -76,7 +76,7 @@
return 0;
}
-static int pcie_port_resume_service(struct device *dev, u32 state)
+static int pcie_port_resume_service(struct device *dev, u32 level)
{
struct pcie_device *pciedev;
struct pcie_port_service_driver *driver;
@@ -317,7 +317,7 @@
}
#ifdef CONFIG_PM
-int pcie_port_device_suspend(struct pci_dev *dev, u32 state)
+int pcie_port_device_suspend(struct pci_dev *dev, pm_message_t state)
{
struct list_head*head, *tmp;
struct device *parent, *child;
--- clean-cvs/drivers/pci/pcie/portdrv_pci.c2005-03-29 13:30:18.0
+0200
+++ linux-cvs/drivers/pci/pcie/portdrv_pci.c2005-03-31 23:54:46.0
+0200
@@ -67,7 +67,7 @@
}
#ifdef CONFIG_PM
-static int pcie_portdrv_suspend (struct pci_dev *dev, u32 state)
+static int pcie_portdrv_suspend (struct pci_dev *dev, pm_message_t state)
{
return pcie_port_device_suspend(dev, state);
}
--- clean-cvs/include/linux/pcieport_if.h 2005-01-18 16:48:03.0
+0100
+++ linux-cvs/include/linux/pcieport_if.h 2005-03-31 23:54:51.0
+0200
@@ -59,7 +59,7 @@
int (*probe) (struct pcie_device *dev,
const struct pcie_port_service_id *id);
void (*remove) (struct pcie_device *dev);
- int (*suspend) (struct pcie_device *dev, u32 state);
+ int (*suspend) (struct pcie_device *dev, pm_message_t state);
int (*resume) (struct pcie_device *dev);
const struct pcie_port_service_id *id_table;
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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: fix u32 vs. pm_message_t in drivers/mmc,mtd,scsi
Hi! > > This is last of the series. I tried to submit patches through their > > mainainers (when they were easy to determine, our MAINTAINERS file > > sucks). > > You mean that there are patches in addition to these seven? Yes, there are 7 more. They were sent to l-k and maintainers. I'll bounce them to you. > This sort of thing is a pain all round whichever way we do it. Right now > the various subsystem trees are about as small as they ever get, so the > time is good to push all this in. > > You should go through the whole -mm, check to see whether there is work > pending in bk-*.patch which also needs conversion. Ok, I'll do some grepping (tommorow or monday). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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 Sat, 2005-04-02 at 15:44 -0500, Steven Rostedt wrote: > On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote: > > > > > > FYI > > > > > > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a > > > Grub option), and the system just locked up hard. I just was curious > > > if this was from a different change. But at least in the latest it > > > shows output, and not just a hard lockup. > > > > > > Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06. > > > > ok, so it's not the recent NFS changes. > > > > I may need to take this back. I forgot to open the serial, so it wasn't > accepting input. So it would just appear dead. And the console was > fighting against the RT tasks, so it too would seem to be dead. I've > reran the test on the latest, but this time I didn't have the NFS > mounted, and it's still running. > I tried the 2.6.12-rc1-RT-V0.7.43-06 kernel again, and I still have the serial, to do sysrq. The console is using X which locks (even all the ctrl-alt-X functions) and the ssh session that I run the test stops after the processes try to grab the locks. It doesn't reply to ping. But the sysrq from the serial shows constantly: stest3_rt: 2269 [cf304690, 89] (not blocked) stest3_rt: 2270 [cf304050, 88] (not blocked) stest3_rt: 2271 [cef86cb0, 87] (not blocked) stest3_rt: 2272 [cef86670, 86] (not blocked) Rtest3_rt: 2273 [cf28a050, 85] (not blocked) So it seems that it's in a deadlock somewhere. Since the 43-06 gets much further, this seems to be another problem. I'm not going to look at this problem anymore, since it doesn't show up in the lastest. I'll run a few more tests to see if I can narrow things down on 43-06. -- Steve - 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: [SCSI] Driver broken in 2.6.x?
On Sat, 2 Apr 2005, |TEcHNO| wrote: > Hi, > > > First of all, I don't have my X configured to work w/o that module, and I > don't think I can do it now. You should be able to just use the "nv" driver instead of the "nvidia" driver - that should be the only change you need to make in xorg.conf ... > Second of all, the 2.4.x kernel had this module too, and worked flawlessly. > It's probably unrelated to the problem, but being able to reproduce it without that module will make more people take the bugreport seriously and it will also eliminate the nvidia module as a potential cause... -- Jesper Juhl - 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/
fix u32 vs. pm_message_t in drivers/macintosh
Hi!
I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately
that turned out not to be the case as Russel King pointed out. Here
are fixes for drivers/macintosh. [These patches are independend and
change no object code; therefore not numbered].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/drivers/macintosh/macio_asic.c2005-03-29 13:29:52.0
+0200
+++ linux-cvs/drivers/macintosh/macio_asic.c2005-03-31 23:54:45.0
+0200
@@ -106,7 +106,7 @@
drv->shutdown(macio_dev);
}
-static int macio_device_suspend(struct device *dev, u32 state)
+static int macio_device_suspend(struct device *dev, pm_message_t state)
{
struct macio_dev * macio_dev = to_macio_device(dev);
struct macio_driver * drv = to_macio_driver(dev->driver);
--- clean-cvs/drivers/macintosh/mediabay.c 2005-03-29 13:29:52.0
+0200
+++ linux-cvs/drivers/macintosh/mediabay.c 2005-03-31 23:54:45.0
+0200
@@ -704,7 +704,7 @@
}
-static int __pmac media_bay_suspend(struct macio_dev *mdev, u32 state)
+static int __pmac media_bay_suspend(struct macio_dev *mdev, pm_message_t state)
{
struct media_bay_info *bay = macio_get_drvdata(mdev);
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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.12-rc1-mm4] swapped memset arguments
Hi, out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments. I found one: # grep -nr "memset.*\,\(\ \|\)0\(\ \|\));" * net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct ieee80211_txb), 0); I found none in Linus' bk. Regards, Maciej - 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/
fix u32 vs. pm_message_t in drivers/message
Hi!
This fixes u32 vs. pm_message_t in drivers/message. [These patches are
independend and change no object code; therefore not numbered].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/drivers/message/fusion/mptbase.c 2005-03-29 13:29:59.0
+0200
+++ linux-cvs/drivers/message/fusion/mptbase.c 2005-03-31 23:54:45.0
+0200
@@ -1429,7 +1429,7 @@
*
*/
static int
-mptbase_suspend(struct pci_dev *pdev, u32 state)
+mptbase_suspend(struct pci_dev *pdev, pm_message_t state)
{
u32 device_state;
MPT_ADAPTER *ioc = pci_get_drvdata(pdev);
--- clean-cvs/drivers/message/fusion/mptbase.h 2005-03-31 23:33:38.0
+0200
+++ linux-cvs/drivers/message/fusion/mptbase.h 2005-03-31 23:54:45.0
+0200
@@ -215,7 +215,7 @@
void (*shutdown) (struct device * dev);
#ifdef CONFIG_PM
int (*resume) (struct pci_dev *dev);
- int (*suspend) (struct pci_dev *dev, u32 state);
+ int (*suspend) (struct pci_dev *dev, pm_message_t state);
#endif
};
--- clean-cvs/drivers/message/fusion/mptscsih.c 2005-03-31 23:33:38.0
+0200
+++ linux-cvs/drivers/message/fusion/mptscsih.c 2005-03-31 23:54:45.0
+0200
@@ -220,7 +220,7 @@
static void mptscsih_remove(struct pci_dev *);
static void mptscsih_shutdown(struct device *);
#ifdef CONFIG_PM
-static int mptscsih_suspend(struct pci_dev *pdev, u32 state);
+static int mptscsih_suspend(struct pci_dev *pdev, pm_message_t state);
static int mptscsih_resume(struct pci_dev *pdev);
#endif
@@ -1389,7 +1389,7 @@
*
*/
static int
-mptscsih_suspend(struct pci_dev *pdev, u32 state)
+mptscsih_suspend(struct pci_dev *pdev, pm_message_t state)
{
mptscsih_shutdown(&pdev->dev);
return 0;
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
Ingo wrote: > in theory the code should work fine on ia64 as well, Nice. I'll try it on our SN2 Altix IA64 as well. Though I am being delayed a day or two in this by irrelevant problems. -- 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/
fix u32 vs. pm_message_t in drivers/mmc,mtd,scsi
Hi!
This fixes u32 vs. pm_message_t in drivers/mmc, drivers/mtd and
drivers/scsi. [These patches are independend and change no object
code; therefore not numbered].
This is last of the series. I tried to submit patches through their
mainainers (when they were easy to determine, our MAINTAINERS file
sucks). Unfortunately that probably means some patches will fail to
propagate and I'll have to fix up after -rc2 or something. Hopefully
diff will be fairly small by that time.
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/drivers/mmc/mmc.c 2005-01-04 11:40:44.0 +0100
+++ linux-cvs/drivers/mmc/mmc.c 2005-03-31 23:54:45.0 +0200
@@ -884,7 +884,7 @@
* @host: mmc host
* @state: suspend mode (PM_SUSPEND_xxx)
*/
-int mmc_suspend_host(struct mmc_host *host, u32 state)
+int mmc_suspend_host(struct mmc_host *host, pm_message_t state)
{
mmc_claim_host(host);
mmc_deselect_cards(host);
--- clean-cvs/drivers/mmc/mmci.c2005-01-11 01:37:06.0 +0100
+++ linux-cvs/drivers/mmc/mmci.c2005-03-31 23:54:46.0 +0200
@@ -603,7 +603,7 @@
}
#ifdef CONFIG_PM
-static int mmci_suspend(struct amba_device *dev, u32 state)
+static int mmci_suspend(struct amba_device *dev, pm_message_t state)
{
struct mmc_host *mmc = amba_get_drvdata(dev);
int ret = 0;
--- clean-cvs/drivers/mmc/pxamci.c 2005-03-29 13:29:59.0 +0200
+++ linux-cvs/drivers/mmc/pxamci.c 2005-03-31 23:54:46.0 +0200
@@ -558,7 +558,7 @@
}
#ifdef CONFIG_PM
-static int pxamci_suspend(struct device *dev, u32 state, u32 level)
+static int pxamci_suspend(struct device *dev, pm_message_t state, u32 level)
{
struct mmc_host *mmc = dev_get_drvdata(dev);
int ret = 0;
--- clean-cvs/drivers/mmc/wbsd.c2005-01-31 00:27:36.0 +0100
+++ linux-cvs/drivers/mmc/wbsd.c2005-03-31 23:54:46.0 +0200
@@ -1563,7 +1563,7 @@
*/
#ifdef CONFIG_PM
-static int wbsd_suspend(struct device *dev, u32 state, u32 level)
+static int wbsd_suspend(struct device *dev, pm_message_t state, u32 level)
{
DBGF("Not yet supported\n");
--- clean-cvs/drivers/mtd/maps/sa1100-flash.c 2004-11-19 12:19:52.0
+0100
+++ linux-cvs/drivers/mtd/maps/sa1100-flash.c 2005-03-31 23:54:46.0
+0200
@@ -403,7 +403,7 @@
}
#ifdef CONFIG_PM
-static int sa1100_mtd_suspend(struct device *dev, u32 state, u32 level)
+static int sa1100_mtd_suspend(struct device *dev, pm_message_t state, u32
level)
{
struct sa_info *info = dev_get_drvdata(dev);
int ret = 0;
--- clean-cvs/drivers/scsi/mesh.c 2004-12-09 21:46:11.0 +0100
+++ linux-cvs/drivers/scsi/mesh.c 2005-03-31 23:54:47.0 +0200
@@ -1757,7 +1757,7 @@
#ifdef CONFIG_PM
-static int mesh_suspend(struct macio_dev *mdev, u32 state)
+static int mesh_suspend(struct macio_dev *mdev, pm_message_t state)
{
struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev);
unsigned long flags;
--- clean-cvs/drivers/scsi/nsp32.c 2005-01-11 01:37:23.0 +0100
+++ linux-cvs/drivers/scsi/nsp32.c 2005-03-31 23:54:47.0 +0200
@@ -3435,7 +3435,7 @@
#ifdef CONFIG_PM
/* Device suspended */
-static int nsp32_suspend(struct pci_dev *pdev, u32 state)
+static int nsp32_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct Scsi_Host *host = pci_get_drvdata(pdev);
@@ -3443,7 +3443,7 @@
pci_save_state (pdev);
pci_disable_device (pdev);
- pci_set_power_state(pdev, state);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
return 0;
}
@@ -3457,8 +3457,8 @@
nsp32_msg(KERN_INFO, "pci-resume: pdev=0x%p, slot=%s, host=0x%p", pdev,
pci_name(pdev), host);
- pci_set_power_state(pdev, 0);
- pci_enable_wake(pdev, 0, 0);
+ pci_set_power_state(pdev, PCI_D0);
+ pci_enable_wake(pdev, PCI_D0, 0);
pci_restore_state (pdev);
reg = nsp32_read2(data->BaseAddress, INDEX_REG);
@@ -3479,7 +3479,7 @@
}
/* Enable wake event */
-static int nsp32_enable_wake(struct pci_dev *pdev, u32 state, int enable)
+static int nsp32_enable_wake(struct pci_dev *pdev, pci_power_t state, int
enable)
{
struct Scsi_Host *host = pci_get_drvdata(pdev);
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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/
fix u32 vs. pm_message_t in drivers/media
Hi!
Here are fixes for drivers/media. [These patches are independend and
change no object code; therefore not numbered].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/drivers/media/dvb/cinergyT2/cinergyT2.c 2005-03-29
13:29:54.0 +0200
+++ linux-cvs/drivers/media/dvb/cinergyT2/cinergyT2.c 2005-03-31
23:54:45.0 +0200
@@ -879,7 +879,7 @@
kfree(cinergyt2);
}
-static int cinergyt2_suspend (struct usb_interface *intf, u32 state)
+static int cinergyt2_suspend (struct usb_interface *intf, pm_message_t state)
{
struct cinergyt2 *cinergyt2 = usb_get_intfdata (intf);
--- clean-cvs/drivers/media/video/meye.c2005-03-29 13:29:56.0
+0200
+++ linux-cvs/drivers/media/video/meye.c2005-03-31 23:54:45.0
+0200
@@ -1768,7 +1768,7 @@
};
#ifdef CONFIG_PM
-static int meye_suspend(struct pci_dev *pdev, u32 state)
+static int meye_suspend(struct pci_dev *pdev, pm_message_t state)
{
pci_save_state(pdev);
meye.pm_mchip_mode = meye.mchip_mode;
--- clean-cvs/drivers/media/video/msp3400.c 2005-03-31 23:33:35.0
+0200
+++ linux-cvs/drivers/media/video/msp3400.c 2005-03-31 23:54:45.0
+0200
@@ -1426,7 +1426,7 @@
static int msp_probe(struct i2c_adapter *adap);
static int msp_command(struct i2c_client *client, unsigned int cmd, void *arg);
-static int msp_suspend(struct device * dev, u32 state, u32 level);
+static int msp_suspend(struct device * dev, pm_message_t state, u32 level);
static int msp_resume(struct device * dev, u32 level);
static void msp_wake_thread(struct i2c_client *client);
@@ -1834,7 +1834,7 @@
return 0;
}
-static int msp_suspend(struct device * dev, u32 state, u32 level)
+static int msp_suspend(struct device * dev, pm_message_t state, u32 level)
{
struct i2c_client *c = container_of(dev, struct i2c_client, dev);
--- clean-cvs/drivers/media/video/tda9887.c 2005-03-29 13:29:58.0
+0200
+++ linux-cvs/drivers/media/video/tda9887.c 2005-03-31 23:54:45.0
+0200
@@ -741,7 +741,7 @@
return 0;
}
-static int tda9887_suspend(struct device * dev, u32 state, u32 level)
+static int tda9887_suspend(struct device * dev, pm_message_t state, u32 level)
{
dprintk("tda9887: suspend\n");
return 0;
--- clean-cvs/drivers/media/video/tuner-core.c 2005-03-08 18:55:38.0
+0100
+++ linux-cvs/drivers/media/video/tuner-core.c 2005-03-31 23:54:45.0
+0200
@@ -378,7 +378,7 @@
return 0;
}
-static int tuner_suspend(struct device * dev, u32 state, u32 level)
+static int tuner_suspend(struct device * dev, pm_message_t state, u32 level)
{
struct i2c_client *c = container_of(dev, struct i2c_client, dev);
struct tuner *t = i2c_get_clientdata(c);
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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: fix u32 vs. pm_message_t in drivers/mmc,mtd,scsi
Pavel Machek <[EMAIL PROTECTED]> wrote: > > This is last of the series. I tried to submit patches through their > mainainers (when they were easy to determine, our MAINTAINERS file > sucks). You mean that there are patches in addition to these seven? > Unfortunately that probably means some patches will fail to > propagate and I'll have to fix up after -rc2 or something. Hopefully > diff will be fairly small by that time. This sort of thing is a pain all round whichever way we do it. Right now the various subsystem trees are about as small as they ever get, so the time is good to push all this in. You should go through the whole -mm, check to see whether there is work pending in bk-*.patch which also needs conversion. - 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.11.6 (x86_64) Scsi-detect Oops
On Saturday 02 April 2005 20:10, Andrew Walrond wrote: > > In the meantime, I'm going to remove this driver from the .config > Boots fine without this driver compiled in (SCSI_FUTURE_DOMAIN=n) Andrew Walrond - 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/
fix u32 vs. pm_message_t in pcmcia
Hi!
This fixes u32 vs. pm_message_t in pcmcia. [These patches are
independend and change no object code; therefore not numbered]. Please
apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/drivers/pcmcia/au1000_generic.c 2005-03-31 23:34:03.0
+0200
+++ linux-cvs/drivers/pcmcia/au1000_generic.c 2005-03-31 23:54:46.0
+0200
@@ -518,7 +518,7 @@
}
-static int au1x00_drv_pcmcia_suspend(struct device *dev, u32 state, u32 level)
+static int au1x00_drv_pcmcia_suspend(struct device *dev, pm_message_t state,
u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
--- clean-cvs/drivers/pcmcia/hd64465_ss.c 2005-03-31 23:34:04.0
+0200
+++ linux-cvs/drivers/pcmcia/hd64465_ss.c 2005-03-31 23:54:46.0
+0200
@@ -845,7 +845,7 @@
local_irq_restore(flags);
}
-static int hd64465_suspend(struct device *dev, u32 state, u32 level)
+static int hd64465_suspend(struct device *dev, pm_message_t state, u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
--- clean-cvs/drivers/pcmcia/m32r_cfc.c 2005-03-31 23:34:04.0 +0200
+++ linux-cvs/drivers/pcmcia/m32r_cfc.c 2005-03-31 23:54:46.0 +0200
@@ -743,7 +743,7 @@
/**/
-static int m32r_pcc_suspend(struct device *dev, u32 state, u32 level)
+static int m32r_pcc_suspend(struct device *dev, pm_message_t state, u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
--- clean-cvs/drivers/pcmcia/m32r_pcc.c 2005-03-31 23:34:04.0 +0200
+++ linux-cvs/drivers/pcmcia/m32r_pcc.c 2005-03-31 23:54:46.0 +0200
@@ -696,7 +696,7 @@
/**/
-static int m32r_pcc_suspend(struct device *dev, u32 state, u32 level)
+static int m32r_pcc_suspend(struct device *dev, pm_message_t state, u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
--- clean-cvs/drivers/pcmcia/pxa2xx_base.c 2004-12-25 16:29:34.0
+0100
+++ linux-cvs/drivers/pcmcia/pxa2xx_base.c 2005-03-31 23:54:46.0
+0200
@@ -205,7 +205,7 @@
}
EXPORT_SYMBOL(pxa2xx_drv_pcmcia_probe);
-static int pxa2xx_drv_pcmcia_suspend(struct device *dev, u32 state, u32 level)
+static int pxa2xx_drv_pcmcia_suspend(struct device *dev, pm_message_t state,
u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
--- clean-cvs/drivers/pcmcia/sa1100_generic.c 2004-11-19 12:20:08.0
+0100
+++ linux-cvs/drivers/pcmcia/sa1100_generic.c 2005-03-31 23:54:46.0
+0200
@@ -75,7 +75,7 @@
return ret;
}
-static int sa11x0_drv_pcmcia_suspend(struct device *dev, u32 state, u32 level)
+static int sa11x0_drv_pcmcia_suspend(struct device *dev, pm_message_t state,
u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
--- clean-cvs/drivers/pcmcia/sa_generic.c 2004-11-19 12:20:08.0
+0100
+++ linux-cvs/drivers/pcmcia/sa_generic.c 2005-03-31 23:54:46.0
+0200
@@ -158,7 +158,7 @@
return 0;
}
-static int pcmcia_suspend(struct sa_dev *dev, u32 state)
+static int pcmcia_suspend(struct sa_dev *dev, pm_message_t state)
{
return pcmcia_socket_dev_suspend(&dev->dev, state);
}
--- clean-cvs/drivers/pcmcia/vrc4171_card.c 2005-03-31 23:34:04.0
+0200
+++ linux-cvs/drivers/pcmcia/vrc4171_card.c 2005-03-31 23:54:47.0
+0200
@@ -774,7 +774,7 @@
__setup("vrc4171_card=", vrc4171_card_setup);
-static int vrc4171_card_suspend(struct device *dev, u32 state, u32 level)
+static int vrc4171_card_suspend(struct device *dev, pm_message_t state, u32
level)
{
int retval = 0;
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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] remove all kernel bugs
On Sat, 2005-04-02 23:03:14 +0200, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > On Fri, 1 Apr 2005, Jan-Benedict Glaw wrote: > > Well, the patch looks fine, but you forgot to also do the VAX-specific > > part. Withoug the BUGs, maybe the VAX kernel would be even faster? > > Perhaps it's a good idea to get Linux/VAX merged in mainline first? After that > people will start fixing all your bugs automagically ;-) Maybe we'll work on that, but first we need to get real, up-to-date userspace and not all this old stuff with uClibc. But we're working on this. (Currently tracking down an ICE. GCC is fun. A lot of fun and black magic...) MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier BÃrger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
fix u32 vs. pm_message_t in usb
Hi!
I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately
that turned out not to be the case as Russel King pointed out. Here
are remaining fixes for USB. [These patches are independend and change
no object code; therefore not numbered].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/drivers/usb/core/hcd-pci.c2005-03-31 23:34:27.0
+0200
+++ linux-cvs/drivers/usb/core/hcd-pci.c2005-03-31 23:54:47.0
+0200
@@ -186,7 +186,7 @@
#ifdef CONFIG_PM
-static char __attribute_used__ *pci_state(u32 state)
+static char __attribute_used__ *pci_state(pci_power_t state)
{
switch (state) {
case 0: return "D0";
@@ -205,11 +205,12 @@
*
* Store this function in the HCD's struct pci_driver as suspend().
*/
-int usb_hcd_pci_suspend (struct pci_dev *dev, u32 state)
+int usb_hcd_pci_suspend (struct pci_dev *dev, pm_message_t pmsg)
{
struct usb_hcd *hcd;
int retval = 0;
int has_pci_pm;
+ pci_power_t state;
hcd = pci_get_drvdata(dev);
@@ -218,8 +219,10 @@
* PM-sensitive HCDs may already have done this.
*/
has_pci_pm = pci_find_capability(dev, PCI_CAP_ID_PM);
- if (state > 4)
- state = 4;
+
+ state = pci_choose_state(dev, pmsg);
+ if (state > PCI_D3cold)
+ state = PCI_D3cold;
switch (hcd->state) {
@@ -291,9 +294,6 @@
break;
}
- /* update power_state **ONLY** to make sysfs happier */
- if (retval == 0)
- dev->dev.power.power_state = state;
return retval;
}
EXPORT_SYMBOL (usb_hcd_pci_suspend);
@@ -327,7 +327,7 @@
if (has_pci_pm)
pci_set_power_state (dev, 0);
- dev->dev.power.power_state = 0;
+ dev->dev.power.power_state = PMSG_ON;
retval = request_irq (dev->irq, usb_hcd_irq, SA_SHIRQ,
hcd->driver->description, hcd);
if (retval < 0) {
--- clean-cvs/drivers/usb/core/hcd.h2005-03-31 23:34:27.0 +0200
+++ linux-cvs/drivers/usb/core/hcd.h2005-03-31 23:54:47.0 +0200
@@ -18,6 +18,7 @@
#ifdef __KERNEL__
+#include
/* This file contains declarations of usbcore internals that are mostly
* used or exposed by Host Controller Drivers.
@@ -177,7 +178,7 @@
* a whole, not just the root hub; they're for bus glue.
*/
/* called after all devices were suspended */
- int (*suspend) (struct usb_hcd *hcd, u32 state);
+ int (*suspend) (struct usb_hcd *hcd, pm_message_t state);
/* called before any devices get resumed */
int (*resume) (struct usb_hcd *hcd);
@@ -226,7 +227,7 @@
extern void usb_hcd_pci_remove (struct pci_dev *dev);
#ifdef CONFIG_PM
-extern int usb_hcd_pci_suspend (struct pci_dev *dev, u32 state);
+extern int usb_hcd_pci_suspend (struct pci_dev *dev, pm_message_t state);
extern int usb_hcd_pci_resume (struct pci_dev *dev);
#endif /* CONFIG_PM */
--- clean-cvs/drivers/usb/core/hub.c2005-03-31 23:34:27.0 +0200
+++ linux-cvs/drivers/usb/core/hub.c2005-03-31 23:54:47.0 +0200
@@ -1456,7 +1456,7 @@
/* FIXME let caller ask to power down the port:
* - some devices won't enumerate without a VBUS power cycle
* - SRP saves power that way
-* - usb_suspend_device(dev,PM_SUSPEND_DISK)
+* - usb_suspend_device(dev, PMSG_SUSPEND)
* That's easy if this hub can switch power per-port, and
* khubd reactivates the port later (timer, SRP, etc).
* Powerdown must be optional, because of reset/DFU.
@@ -1531,7 +1531,7 @@
/*
* Devices on USB hub ports have only one "suspend" state, corresponding
- * to ACPI D2 (PM_SUSPEND_MEM), "may cause the device to lose some context".
+ * to ACPI D2, "may cause the device to lose some context".
* State transitions include:
*
* - suspend, resume ... when the VBUS power link stays live
--- clean-cvs/drivers/usb/core/usb.c2005-03-31 23:34:27.0 +0200
+++ linux-cvs/drivers/usb/core/usb.c2005-04-01 00:12:45.0 +0200
@@ -1382,7 +1382,7 @@
usb_pipein (pipe) ? DMA_FROM_DEVICE : DMA_TO_DEVICE);
}
-static int usb_generic_suspend(struct device *dev, u32 state)
+static int usb_generic_suspend(struct device *dev, pm_message_t state)
{
struct usb_interface *intf;
struct usb_driver *driver;
--- clean-cvs/drivers/usb/gadget/omap_udc.c 2005-03-29 13:30:37.0
+0200
+++ linux-cvs/drivers/usb/gadget/omap_udc.c 2005-03-31 23:54:47.0
+0200
@@ -2809,17 +2809,15 @@
return 0;
}
-/* suspend/resume/wakeup from sysfs (echo > power/state) */
-
-static int omap_udc_suspend(struct device *dev, u32 state, u32 level)
+static int omap_udc_suspend(s
Re: [SCSI] Driver broken in 2.6.x?
Hi, First of all, I don't have my X configured to work w/o that module, and I don't think I can do it now. Second of all, the 2.4.x kernel had this module too, and worked flawlessly. Non the less, I'll try to do it. -- pozdrawiam |"Help me master, I felt the burning twilight behind [EMAIL PROTECTED]|those gates of stell..." --Perihelion, Prophecy Sequence - 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/
Fix u32 vs. pm_message_t in x86-64
Hi!
I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately
that turned out not to be the case... Here are fixes x86-64. [These
patches are independend and change no object code; therefore not
numbered].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/arch/x86_64/kernel/apic.c 2005-03-29 13:29:28.0 +0200
+++ linux-cvs/arch/x86_64/kernel/apic.c 2005-03-31 23:54:43.0 +0200
@@ -457,7 +457,7 @@
unsigned int apic_thmr;
} apic_pm_state;
-static int lapic_suspend(struct sys_device *dev, u32 state)
+static int lapic_suspend(struct sys_device *dev, pm_message_t state)
{
unsigned long flags;
--- clean-cvs/arch/x86_64/kernel/i8259.c2005-03-31 23:32:33.0
+0200
+++ linux-cvs/arch/x86_64/kernel/i8259.c2005-03-31 23:54:43.0
+0200
@@ -409,7 +409,7 @@
return 0;
}
-static int i8259A_suspend(struct sys_device *dev, u32 state)
+static int i8259A_suspend(struct sys_device *dev, pm_message_t state)
{
save_ELCR(irq_trigger);
return 0;
--- clean-cvs/arch/x86_64/kernel/io_apic.c 2005-03-29 13:29:28.0
+0200
+++ linux-cvs/arch/x86_64/kernel/io_apic.c 2005-03-31 23:54:43.0
+0200
@@ -1712,7 +1712,7 @@
};
static struct sysfs_ioapic_data * mp_ioapic_data[MAX_IO_APICS];
-static int ioapic_suspend(struct sys_device *dev, u32 state)
+static int ioapic_suspend(struct sys_device *dev, pm_message_t state)
{
struct IO_APIC_route_entry *entry;
struct sysfs_ioapic_data *data;
--- clean-cvs/arch/x86_64/kernel/nmi.c 2005-01-31 00:26:51.0 +0100
+++ linux-cvs/arch/x86_64/kernel/nmi.c 2005-03-31 23:54:43.0 +0200
@@ -254,7 +254,7 @@
static int nmi_pm_active; /* nmi_active before suspend */
-static int lapic_nmi_suspend(struct sys_device *dev, u32 state)
+static int lapic_nmi_suspend(struct sys_device *dev, pm_message_t state)
{
nmi_pm_active = nmi_active;
disable_lapic_nmi_watchdog();
--- clean-cvs/arch/x86_64/kernel/time.c 2005-03-31 23:32:33.0 +0200
+++ linux-cvs/arch/x86_64/kernel/time.c 2005-03-31 23:54:43.0 +0200
@@ -957,7 +957,7 @@
static long clock_cmos_diff;
static unsigned long sleep_start;
-static int timer_suspend(struct sys_device *dev, u32 state)
+static int timer_suspend(struct sys_device *dev, pm_message_t state)
{
/*
* Estimate time zone so that set_time can update the clock
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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/
Fix u32 vs. pm_message_t in drivers/char
Hi!
Here are fixes for drivers/char. [These patches are independend and
change no object code; therefore not numbered].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/drivers/char/agp/efficeon-agp.c 2005-03-29 13:29:41.0
+0200
+++ linux-cvs/drivers/char/agp/efficeon-agp.c 2005-03-31 23:54:43.0
+0200
@@ -408,7 +408,7 @@
agp_put_bridge(bridge);
}
-static int agp_efficeon_suspend(struct pci_dev *dev, u32 state)
+static int agp_efficeon_suspend(struct pci_dev *dev, pm_message_t state)
{
return 0;
}
--- clean-cvs/drivers/char/s3c2410-rtc.c2005-03-29 13:29:40.0
+0200
+++ linux-cvs/drivers/char/s3c2410-rtc.c2005-03-31 23:54:43.0
+0200
@@ -515,7 +515,7 @@
static int ticnt_save;
-static int s3c2410_rtc_suspend(struct device *dev, u32 state, u32 level)
+static int s3c2410_rtc_suspend(struct device *dev, pm_message_t state, u32
level)
{
struct rtc_time tm;
struct timespec time;
--- clean-cvs/drivers/char/sonypi.c 2005-03-29 13:29:40.0 +0200
+++ linux-cvs/drivers/char/sonypi.c 2005-03-31 23:54:43.0 +0200
@@ -1103,7 +1103,7 @@
#ifdef CONFIG_PM
static int old_camera_power;
-static int sonypi_suspend(struct device *dev, u32 state, u32 level)
+static int sonypi_suspend(struct device *dev, pm_message_t state, u32 level)
{
if (level == SUSPEND_DISABLE) {
old_camera_power = sonypi_device.camera_power;
--- clean-cvs/drivers/char/tpm/tpm.c2005-03-31 23:33:09.0 +0200
+++ linux-cvs/drivers/char/tpm/tpm.c2005-03-31 23:54:43.0 +0200
@@ -567,7 +567,7 @@
* We are about to suspend. Save the TPM state
* so that it can be restored.
*/
-int tpm_pm_suspend(struct pci_dev *pci_dev, u32 pm_state)
+int tpm_pm_suspend(struct pci_dev *pci_dev, pm_message_t pm_state)
{
struct tpm_chip *chip = pci_get_drvdata(pci_dev);
if (chip == NULL)
--- clean-cvs/drivers/char/tpm/tpm.h2005-03-31 23:33:09.0 +0200
+++ linux-cvs/drivers/char/tpm/tpm.h2005-03-31 23:54:43.0 +0200
@@ -89,5 +89,5 @@
loff_t *);
extern ssize_t tpm_read(struct file *, char __user *, size_t, loff_t *);
extern void __devexit tpm_remove(struct pci_dev *);
-extern int tpm_pm_suspend(struct pci_dev *, u32);
+extern int tpm_pm_suspend(struct pci_dev *, pm_message_t);
extern int tpm_pm_resume(struct pci_dev *);
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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/
pm_message_t: more fixes in common and i386
Hi!
I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately
that turned out not to be the case as Russel King pointed out. Here
are fixes for Documentation and common code (mainly system
devices). [These patches are independend and change no object code;
therefore not numbered].
Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/include/linux/pci.h 2005-03-29 13:31:52.0 +0200
+++ linux-cvs/include/linux/pci.h 2005-03-31 23:54:51.0 +0200
@@ -501,6 +501,7 @@
#define PCI_D2 ((pci_power_t __force) 2)
#define PCI_D3hot ((pci_power_t __force) 3)
#define PCI_D3cold ((pci_power_t __force) 4)
+#define PCI_POWER_ERROR((pci_power_t __force) -1)
/*
* The pci_dev structure is used to describe PCI devices.
@@ -669,7 +670,7 @@
void (*remove) (struct pci_dev *dev); /* Device removed (NULL if not
a hot-plug capable driver) */
int (*suspend) (struct pci_dev *dev, pm_message_t state); /*
Device suspended */
int (*resume) (struct pci_dev *dev); /* Device woken
up */
- int (*enable_wake) (struct pci_dev *dev, u32 state, int enable); /*
Enable wake event */
+ int (*enable_wake) (struct pci_dev *dev, pci_power_t state, int
enable); /* Enable wake event */
struct device_driverdriver;
struct pci_dynids dynids;
@@ -952,7 +953,7 @@
static inline int pci_save_state(struct pci_dev *dev) { return 0; }
static inline int pci_restore_state(struct pci_dev *dev) { return 0; }
static inline int pci_set_power_state(struct pci_dev *dev, pci_power_t state)
{ return 0; }
-static inline pci_power_t pci_choose_state(struct pci_dev *dev, u32 state) {
return PCI_D0; }
+static inline pci_power_t pci_choose_state(struct pci_dev *dev, pm_message_t
state) { return PCI_D0; }
static inline int pci_enable_wake(struct pci_dev *dev, pci_power_t state, int
enable) { return 0; }
#defineisa_bridge ((struct pci_dev *)NULL)
--- clean-cvs/Documentation/driver-model/bus.txt2004-08-26
00:52:57.0 +0200
+++ linux-cvs/Documentation/driver-model/bus.txt2005-03-31
23:54:41.0 +0200
@@ -18,7 +18,7 @@
int (*match)(struct device * dev, struct device_driver *
drv);
int (*hotplug) (struct device *dev, char **envp,
int num_envp, char *buffer, int
buffer_size);
- int (*suspend)(struct device * dev, u32 state);
+ int (*suspend)(struct device * dev, pm_message_t state);
int (*resume)(struct device * dev);
};
--- clean-cvs/Documentation/driver-model/driver.txt 2003-05-17
03:31:10.0 +0200
+++ linux-cvs/Documentation/driver-model/driver.txt 2005-03-31
23:54:41.0 +0200
@@ -16,7 +16,7 @@
int (*probe)(struct device * dev);
int (*remove) (struct device * dev);
-int (*suspend) (struct device * dev, u32 state, u32 level);
+int (*suspend) (struct device * dev, pm_message_t state, u32
level);
int (*resume) (struct device * dev, u32 level);
void(*release) (struct device_driver * drv);
@@ -195,7 +195,7 @@
If the device is still present, it should quiesce the device and place
it into a supported low-power state.
- int (*suspend) (struct device * dev, u32 state, u32 level);
+ int (*suspend) (struct device * dev, pm_message_t state, u32
level);
suspend is called to put the device in a low power state. There are
several stages to successfully suspending a device, which is denoted in
--- clean-cvs/arch/i386/kernel/apic.c 2005-03-31 23:31:19.0 +0200
+++ linux-cvs/arch/i386/kernel/apic.c 2005-03-31 23:54:43.0 +0200
@@ -548,7 +548,7 @@
unsigned int apic_thmr;
} apic_pm_state;
-static int lapic_suspend(struct sys_device *dev, u32 state)
+static int lapic_suspend(struct sys_device *dev, pm_message_t state)
{
unsigned long flags;
--- clean-cvs/arch/i386/kernel/i8259.c 2005-03-15 23:27:33.0 +0100
+++ linux-cvs/arch/i386/kernel/i8259.c 2005-03-31 23:54:43.0 +0200
@@ -262,7 +262,7 @@
return 0;
}
-static int i8259A_suspend(struct sys_device *dev, u32 state)
+static int i8259A_suspend(struct sys_device *dev, pm_message_t state)
{
save_ELCR(irq_trigger);
return 0;
--- clean-cvs/arch/i386/kernel/io_apic.c2005-03-31 23:31:20.0
+0200
+++ linux-cvs/arch/i386/kernel/io_apic.c2005-03-31 23:54:43.0
+0200
@@ -2299,7 +2299,7 @@
};
static struct sysfs_ioapic_data * mp_ioapic_data[MAX_IO_APICS];
-static int ioapic_suspend(struct sys_device *dev, u32 state)
+static int ioapic_suspend(struct sys_device *dev, pm_message_t state)
{
struct IO_APIC_route_entry *entry;
Re: [SCSI] Driver broken in 2.6.x?
On Sat, 2 Apr 2005, |TEcHNO| wrote: > Hi, > > I've recently switched form 2.4.x kernel series to 2.6.x, and I've encourted a > problem with my old scanner card, > Apr 1 17:29:41 techno kernel: Modules linked in: nvidia ^^^ Very first thing to do is try it without the nvidia module loaded and then reproduce the problem and post the same info from your logs again. As long as the nvidia module is loaded most people will disregard the bugreport since the source for the module is not available so if it has anything to do with the problem at all it is more or less un-debugable. If the problem can be reproduced without the nvidia module loaded then the info is more useful. -- Jesper Juhl - 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: Fw: [SCSI] Driver broken in 2.6.x?
Hi, If you'r asking: $ uname -r 2.6.11.3 -- pozdrawiam |"Help me master, I felt the burning twilight behind [EMAIL PROTECTED]|those gates of stell..." --Perihelion, Prophecy Sequence - 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] remove all kernel bugs
On Fri, 1 Apr 2005, Jan-Benedict Glaw wrote:
> On Fri, 2005-04-01 01:07:44 -0800, Matt Mackall <[EMAIL PROTECTED]>
> wrote in message <[EMAIL PROTECTED]>:
> > I've been sitting on this patch for a while, figured it's high time I
> > shared it with the world. This patch eliminates all kernel bugs, trims
> > about 35k off the typical kernel, and makes the system slightly
> > faster. The patch is against the latest bk snapshot, please apply.
> >
> > Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
>
> Well, the patch looks fine, but you forgot to also do the VAX-specific
> part. Withoug the BUGs, maybe the VAX kernel would be even faster?
Perhaps it's a good idea to get Linux/VAX merged in mainline first? After that
people will start fixing all your bugs automagically ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote: > * Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote: > > > > > Here's the bug I get: > > > > > > > FYI > > > > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a > > Grub option), and the system just locked up hard. I just was curious > > if this was from a different change. But at least in the latest it > > shows output, and not just a hard lockup. > > > > Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06. > > ok, so it's not the recent NFS changes. > I may need to take this back. I forgot to open the serial, so it wasn't accepting input. So it would just appear dead. And the console was fighting against the RT tasks, so it too would seem to be dead. I've reran the test on the latest, but this time I didn't have the NFS mounted, and it's still running. -- Steve - 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: Something wrong with 2.6.12-rc1-RT-V0.7.43-05
Jacek Luczak napisaÅ(a): Matan Peled napisaÅ(a): Jacek Luczak wrote: Hi Early morning i made a 2.6.12-rc1 with RT-V0.7.43-05 and this is what I sow in dmesg after 6 hours of computers work: Hmm... A lot of that seems to involve ndiswrapper. Is there any way you could reproduce this without ndiswrapper loaded? I will try and send it back. It seems that everything is involve by ndiswrapper. Those errors reappear after module load. Without ndiswrapper kernel works OK. Jacek - 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/
