Re: SATA Harddisk speed drop of 100 MB/s
Carlo Wood wrote: > Just one kernel version? The problem here is in every > kernel revision after 551c012d7eea3dc5ec063c7ff9c718d39e77634f > > 2.6.20-rc2,rc3,rc4,rc5,rc6,rc7 ... 2.6.20 ... 2.6.21 ... 2.6.22-rc5 > > noop: > Timing buffered disk reads: 254 MB in 3.00 seconds = 84.66 MB/sec > > anticipatory: > Timing buffered disk reads: 252 MB in 3.02 seconds = 83.43 MB/sec > > deadline: > Timing buffered disk reads: 258 MB in 3.02 seconds = 85.41 MB/sec > > cfq: > Timing buffered disk reads: 194 MB in 3.03 seconds = 64.06 MB/sec > > The normal value is cfq. So, all other schedulars are somewhat faster, > but still far from the correct 165 MB/s. You may want to play with /sys/block/*/queue/max_sectors_kb and read_ahead_kb. On my system, setting them to 192 gives best performance, but cfq is always slower. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] trivial: the memset operation on a automatic array variable should be optimized out by data initialization
From: Denis Cheng <[EMAIL PROTECTED]>
the explicit memset call could be optimized out by data initialization,
thus all the fill working can be done by the compiler implicitly.
and C standard guaranteed all the unspecified data field initialized to zero.
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
After comments in the former threads:
http://lkml.org/lkml/2007/6/18/119
http://lkml.org/lkml/2007/6/18/48
On 6/18/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> The cost is the same. "= {0}" is transformed into a bunch of movs,
> or a rep mov, (At least for x86), so is equivalent to memset (which
> will get transformed to __builtin_memset anyway). So I wonder
> what this really buys.
>
> And, you do not even need the zero. Just write
> ...[MAX_NR_ZONES] = {};
> Jan
I also think this style of zero initialization would be better.
so the patch is little different:
--- arch/x86_64/mm/init.c.orig 2007-06-07 10:08:04.0 +0800
+++ arch/x86_64/mm/init.c 2007-06-23 13:12:26.0 +0800
@@ -406,8 +406,8 @@ void __cpuinit zap_low_mappings(int cpu)
#ifndef CONFIG_NUMA
void __init paging_init(void)
{
- unsigned long max_zone_pfns[MAX_NR_ZONES];
- memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
+ unsigned long max_zone_pfns[MAX_NR_ZONES] = {};
+
max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
max_zone_pfns[ZONE_DMA32] = MAX_DMA32_PFN;
max_zone_pfns[ZONE_NORMAL] = end_pfn;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 0/6] Convert all tasklets to workqueues
On Fri, 22 Jun 2007 00:00:14 -0400 Steven Rostedt <[EMAIL PROTECTED]> wrote: > > There's a very nice paper by Matthew Willcox that describes Softirqs, > Tasklets, Bottom Halves, Task Queues, Work Queues and Timers[1]. > In the paper it describes the history of these items. Softirqs and > tasklets were created to replace bottom halves after a company (Mindcraft) > showed that Microsoft on a 4x SMP box would out do Linux. It was discovered > that this was due to a bottle neck caused by the design of Bottom Halves. > So Alexey Kuznetsov and Dave Miller [1] (and I'm sure others) created > softirqs and tasklets to multithread the bottom halves. > > This worked well, and for the time it shut-up Microsoft^WMindcraft from > saying Linux was slow at networking. > > Time passed, and Linux developed other nifty tools, like kthreads and > work queues. These run in a process context and are not as menacing to > latencies as softirqs and tasklets are. Specifically, a tasklet, > acts as a task by only being able to run the function on one CPU > at a time. The same tasklet can not run on multiple CPUS. So in that > aspect it is like a task (a task can only exist on one CPU at a time). > But a tasklet is much harder on the rest of the system because it > runs in interrupt context. This means that if a higher priority process > wants to run, it must wait for the tasklet to finish before doing so. > > The most part, tasklets today are not used for time critical functions. > Running tasklets in thread context is not harmful to performance of > the overall system. But running them in interrupt context is, since > they increase the overall latency for high priority tasks. > You will need to search and convert all network drivers that are using tasklets. Drivers like the ipw2200, will need to be converted to NAPI, and you probably have to fix a couple of places in the ieee80211 stack as well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Chinese translation of Documentation/HOWTO
On Fri, Jun 22, 2007 at 03:11:45PM -0400, Rob Landley wrote: >On Friday 22 June 2007 13:02:26 Linus Torvalds wrote: >> In fact, I suspect pretty much any documentation (whether technical or >> about processes and/or style) makes sense to have translated if the energy >> and ability to do that exists. I suspect the "policies and processes" >> kinds of docs make _more_ sense to translate initially, simply because >> they are approachable on their own - but I certainly would never >> discourage anybody from translating anything at all. >> >> That said, I don't think that merging the result into the standard kernel >> makes sense - like it or not, right now English ends up being required >> to be part of actually getting things into the "standard" kernel, and as >> such, at _some_ point there has to be a connection point that switches >> over to English, and trying to make the translations be an in-kernel thing >> is thus kind of pointless. >> >> But as part of some "documentation site", it makes 100% sense. > >Ok, I've got some documentation site, specifically http://kernel.org/doc (and >I'll be completely redoing it as soon as I've recovered from my recent laptop >crash and OLS). > >Send me translations (preferably in HTML format), and I'll put 'em up. (I've >already got the one that started this thread.) > >Thanks, > Please also send a copy of HTML format to me, I will put them to http://www.kerneltravel.net (A Chinese website about Linux kernel). Thanks! WANG Cong - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 7/12] acpi: fix another compile warning
On Fri, 22 Jun 2007 20:55:30 -0700 Andrew Morton wrote: > > On Wed, 20 Jun 2007 11:25:48 -0700 Ravikiran G Thirumalai <[EMAIL > > PROTECTED]> wrote: > > Paper over 'select' inadequacies. > > > > Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]> > > > > Index: linux-2.6.22-rc5/arch/x86_64/Kconfig > > === > > --- linux-2.6.22-rc5.orig/arch/x86_64/Kconfig 2007-06-18 > > 16:02:19.571323415 -0700 > > +++ linux-2.6.22-rc5/arch/x86_64/Kconfig2007-06-20 11:34:29.845354250 > > -0700 > > @@ -366,6 +366,7 @@ config X86_64_ACPI_NUMA > > depends on NUMA > > select ACPI > > select PCI > > + select PM > > select ACPI_NUMA > > default y > > help > > argh. (and not just argh-at-your-email-client). > > I went through some hair-tearing a few months ago working out why it is so > damn hard to make CONFIG_PM go away and then I fixed it. And now you're > proposing a change which would reinstate the obnoxious old behaviour. > > Is the "bug" which you're "fixing" here caused by the randconfig > inadequacies? Because randconfig is just busted and simply should auto-run > oldconfig. Running oldconfig won't fix randconfigs that have busted "select" chains (i.e., select does not follow chains like "depends on" does). However, lots of this bustage isn't due to randconfig at all. It's due to Jan E.'s menuconfig changes (yes, which I supported). It seems that Jan didn't realize that a transition of a tristate symbol to a boolean converts y or m to y (and n to n) and all (?) of the new menuconfig symbols that control whether a menu is displayed or not are boolean. One simple "fix" (or workaround) is to make them tristate. Now that seems a little odd for a symbol that just controls whether a menu is displayed or not, so Satyam Sharma has made some other suggestions, and of course Andreas Herrmann has produced lots of patches to fix various issues that he has run into. I can't tell you the final answer (I proposed the tristate fix). I don't particularly like some of the patches that change depends on XYZ to depends on XYZ && ksymbol in many lines of kconfig entries. Not that it answers your question, but we should have hit this in -mm, not in mainline, but it appears that our testing was a bit insufficient. And of course, if someone would fix kconfig to follow "select" chains, we should bestow an award on them. :) (however, I don't know if Roman would merge that patch) --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: 2.6 patch] schedule BLK_DEV_IDE_SATA for removal
Paul Mackerras wrote: Alan Cox writes: On Fri, 22 Jun 2007 11:39:45 +0800 David Woodhouse <[EMAIL PROTECTED]> wrote: On Fri, 2007-06-22 at 01:52 +0200, Adrian Bunk wrote: Users should use the libata based drivers for SATA drives. NAK. Not all IDE drivers are converted yet. Not even all the relatively common ones. All the common SATA ones are. Just the PowerPC people are falling behind. Really we should obsolete powerpc instead ;) What SATA drive uses a non-libata driver on PowerPC? In fact the sata_svw driver used for SATA drives on G5s was one of the early libata drivers. Or are you talking about PATA? This entire thread is confused :) Going back to $subject, it is relevant only to the scant few old-IDE drivers that do indeed successfully probe and talk to SATA drives, from SATA controllers. The vast majority have always used libata for SATA, but another option did indeed exist before libata appeared, for a few controllers. Alan was just having a bit of fun at dwmw2's expense, since we do indeed want to see libata drivers for PowerPC PATA as well :) 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: scripts/checkpatch.pl refers to non-existent Documentation/Documentation/volatile-considered-harmful.txt
> On Wed, 20 Jun 2007 23:03:44 +0200 "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > On 20/06/07, Roland Dreier <[EMAIL PROTECTED]> wrote: > > Commit 4a0df2ef added the following to scripts/checkpatch.pl: > > > > print "Use of volatile is usually wrong: see > > Documentation/volatile-considered-harmful.txt\n"; > > > > but Linus's tree has no such file. not sure what the right thing to > > do here is, since I assume we do ultimately want something of the sort > > in Documentation... > > > > That document is in the -mm kernel currently. As soon as it hits > mainline from there checkpatch.pl will be right :-) > oops. I queued volatile-considered-harmful-take-3.patch for 2.6.22, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] update checkpatch.pl to version 0.06
Dave Hansen writes: > Several of our on-disk filesystems have an ioctl function that already > has indented goto labels. I don't think it's quite worth churning all > of these (working) filesystems to make a style checker happy. I agree. > I think it's worse style to be mixing label indentation in a file as it > is to create new "correct" indentation labels. That's why I suggested > using context in the file to determine it rather than absolute rules. I don't think indentation of labels is something one can or should be too prescriptive about. As you say, it depends on the context. Having a script being fascist about such things makes it useless, because I for one will just start ignoring the script totally. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: 2.6 patch] schedule BLK_DEV_IDE_SATA for removal
Alan Cox writes: > On Fri, 22 Jun 2007 11:39:45 +0800 > David Woodhouse <[EMAIL PROTECTED]> wrote: > > > On Fri, 2007-06-22 at 01:52 +0200, Adrian Bunk wrote: > > > Users should use the libata based drivers for SATA drives. > > > > NAK. Not all IDE drivers are converted yet. Not even all the relatively > > common ones. > > All the common SATA ones are. Just the PowerPC people are falling behind. > Really we should obsolete powerpc instead ;) What SATA drive uses a non-libata driver on PowerPC? In fact the sata_svw driver used for SATA drives on G5s was one of the early libata drivers. Or are you talking about PATA? Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 7/12] acpi: fix another compile warning
> On Wed, 20 Jun 2007 11:25:48 -0700 Ravikiran G Thirumalai <[EMAIL PROTECTED]> > wrote: > Paper over 'select' inadequacies. > > Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]> > > Index: linux-2.6.22-rc5/arch/x86_64/Kconfig > === > --- linux-2.6.22-rc5.orig/arch/x86_64/Kconfig 2007-06-18 16:02:19.571323415 > -0700 > +++ linux-2.6.22-rc5/arch/x86_64/Kconfig 2007-06-20 11:34:29.845354250 > -0700 > @@ -366,6 +366,7 @@ config X86_64_ACPI_NUMA > depends on NUMA > select ACPI > select PCI > + select PM > select ACPI_NUMA > default y > help argh. (and not just argh-at-your-email-client). I went through some hair-tearing a few months ago working out why it is so damn hard to make CONFIG_PM go away and then I fixed it. And now you're proposing a change which would reinstate the obnoxious old behaviour. Is the "bug" which you're "fixing" here caused by the randconfig inadequacies? Because randconfig is just busted and simply should auto-run oldconfig. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA RAID5 speed drop of 100 MB/s
For what it's worth... I tried applying --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -516,6 +516,8 @@ static void ahci_save_initial_config(struct pci_dev *pdev, * reset. Values without are used for driver operation. */ hpriv->saved_cap = cap = readl(mmio + HOST_CAP); + hpriv->saved_cap &= ( (1<<28) | (1<<17) ); + hpriv->saved_cap |= (1 << 27); hpriv->saved_port_map = port_map = readl(mmio + HOST_PORTS_IMPL); /* some chips lie about 64bit support */ to 2.6.22-rc5, but it had no effect :*) I'll await any comments from a kernel developer for now. Please let me know if you want me to test something. -- Carlo Wood <[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: JIT emulator needs
On Jun 19, 2007, at 11:08:24, William Lee Irwin III wrote:
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
c. open() flag to unlink a file before returning the fd
You probably want a tmpfile(3) -like affair which never has a
pathname to begin with. It could be useful for security purposes
more generally.
maybe this: open("/some/dir", O_TMPFILE);
and this? open("/some/dir", O_TMPFILE|O_DIRECTORY);
The former would return a filehandle to a new anonymous file
somewhere on whatever filesystem backs the specified path. The
latter would do the same, except create an anonymous directory where
you could use "openat()" or something. Presumably "lsof" and "/proc"
should show either type of handle as referring to either "/some/
filesystem/" or "/some/filesystem/ (anonymous temp file)" or something.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 -rss] Make RSS accounting display more user friendly
On 6/22/07, Paul Menage <[EMAIL PROTECTED]> wrote: On 6/21/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote: > > Nothing wrong, but currently they are shown in "natural" points, i.e. in > those that the controller accounts them in. For RSS controller the natural > point is "page", but auto-converting them from pages to bytes is wrong, as > not all the controllers account in pages. This exposes more implementation detail than I think is good. Something like a memory controller should use a more abstract interface like bytes, and do the conversion to/from its internal "natural" units like pages internally. E.g. the example cpu accounting controller that I included with my patch set reports usage in milliseconds, even though it counts internally in jiffies. Hi, Paul, Bytes are too fine grained. Do we also accept the input in bytes? kB are probably the best, but then with the limit set to LONG_MAX, kB wrap around (if the input is in units of pages) on 64 bit machines (the sameapplies to bytes as well). The problem with input in bytes is that the user will have to ensure that the input is a multiple of page size, which implies that she would need to use the calculator every time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: rtc_cmos: error after first write to wakealarm
[ please don't edit folk off the cc list unless you *know* they are getting duplicates ... ] > > It's got as much documentation in the kernel tree as that > > old /proc/acpi/alarm thing. More, in fact, since the GIT > > comment for the putback creating /sys/rtc/.../wakealarm > > files has lots of info about how to use it. > > What GIT comment are you referring to? What "git log drivers/rtc/rtc-sysfs.c" shows ... date Feb 12. The web interface shows it too. > > One theory: it's an RTC that doesn't support all the fields, > > so its driver is returning "-1" in fields like "year" or "month". > > With the old /proc/acpi/alarm, the year 2007 became 0007. Maybe this is > the culprit? That's essentially the same issue. It needs some sort of generic fix at the rtc_read_alarm() level. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA Harddisk speed drop of 100 MB/s
On Fri, Jun 22, 2007 at 10:31:32PM -0300, Henrique de Moraes Holschuh wrote: > for i in /sys/block/sd*/queue/scheduler ; do echo -n "scheduler for $i was:" > ; cat $i ; echo anticipatory > $i ; done > > Should show you the scheduler for all libata/scsi discs, and switch to > anticipatory. It probably works for hd* as well, but I don't have any > around to test. > > I had ridiculous md raid performance (on resync) using cfq at least once. > Unfortunately I never bothered trying to track it down, and I didn't check > the throughput after the resync was done either. Also, I don't recall the > kernel version, but it was either 2.6.18 or 2.6.20. Just one kernel version? The problem here is in every kernel revision after 551c012d7eea3dc5ec063c7ff9c718d39e77634f 2.6.20-rc2,rc3,rc4,rc5,rc6,rc7 ... 2.6.20 ... 2.6.21 ... 2.6.22-rc5 noop: Timing buffered disk reads: 254 MB in 3.00 seconds = 84.66 MB/sec anticipatory: Timing buffered disk reads: 252 MB in 3.02 seconds = 83.43 MB/sec deadline: Timing buffered disk reads: 258 MB in 3.02 seconds = 85.41 MB/sec cfq: Timing buffered disk reads: 194 MB in 3.03 seconds = 64.06 MB/sec The normal value is cfq. So, all other schedulars are somewhat faster, but still far from the correct 165 MB/s. -- Carlo Wood <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86-64: disable the GART in shutdown
[PATCH] x86-64: disable the GART in shutdown
For K8 system: 4G RAM with memory hole remapping enabled, or more than 4G RAM
installed. when mem is allocated for GART, it will do the memset for clear.
and for kexec case, the first kernel already enable that, the memset in second
kernel will cause the system restart. solution will be:
in second kernel: disable that at first before we try to allocate mem for it.
or in the first kernel: do disable that before shutdown.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
arch/x86_64/kernel/pci-dma.c |7 +++
arch/x86_64/kernel/pci-gart.c | 20
arch/x86_64/kernel/reboot.c |4
include/asm-x86_64/proto.h|2 ++
4 files changed, 33 insertions(+)
diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index ae091cd..4904d5f 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -571,6 +571,26 @@ static const struct dma_mapping_ops gart_dma_ops = {
.unmap_sg = gart_unmap_sg,
};
+void gart_iommu_shutdown(void)
+{
+ struct pci_dev *dev;
+ int i;
+
+ if (dma_ops != _dma_ops)
+ return;
+
+ for (i = 0; i < num_k8_northbridges; i++) {
+ u32 ctl;
+
+ dev = k8_northbridges[i];
+ pci_read_config_dword(dev, 0x90, );
+
+ ctl &= ~1;
+
+ pci_write_config_dword(dev, 0x90, ctl);
+ }
+}
+
void __init gart_iommu_init(void)
{
struct agp_kern_info info;
diff --git a/arch/x86_64/kernel/pci-dma.c b/arch/x86_64/kernel/pci-dma.c
index 9f80aad..64f2ab3 100644
--- a/arch/x86_64/kernel/pci-dma.c
+++ b/arch/x86_64/kernel/pci-dma.c
@@ -322,6 +322,13 @@ static int __init pci_iommu_init(void)
return 0;
}
+void pci_iommu_shutdown(void)
+{
+#ifdef CONFIG_IOMMU
+ gart_iommu_shutdown();
+#endif
+}
+
#ifdef CONFIG_PCI
/* Many VIA bridges seem to corrupt data for DAC. Disable it here */
diff --git a/arch/x86_64/kernel/reboot.c b/arch/x86_64/kernel/reboot.c
index 7503068..e6e65c2 100644
--- a/arch/x86_64/kernel/reboot.c
+++ b/arch/x86_64/kernel/reboot.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
/*
* Power off function, if any
@@ -81,6 +82,7 @@ static inline void kb_wait(void)
void machine_shutdown(void)
{
unsigned long flags;
+
/* Stop the cpus and apics */
#ifdef CONFIG_SMP
int reboot_cpu_id;
@@ -111,6 +113,8 @@ void machine_shutdown(void)
disable_IO_APIC();
local_irq_restore(flags);
+
+ pci_iommu_shutdown();
}
void machine_emergency_restart(void)
diff --git a/include/asm-x86_64/proto.h b/include/asm-x86_64/proto.h
index 85255db..fb9f73e 100644
--- a/include/asm-x86_64/proto.h
+++ b/include/asm-x86_64/proto.h
@@ -85,11 +85,13 @@ extern int exception_trace;
extern unsigned cpu_khz;
extern unsigned tsc_khz;
+extern void pci_iommu_shutdown(void);
extern void no_iommu_init(void);
extern int force_iommu, no_iommu;
extern int iommu_detected;
#ifdef CONFIG_IOMMU
extern void gart_iommu_init(void);
+extern void gart_iommu_shutdown(void);
extern void __init gart_parse_options(char *);
extern void iommu_hole_init(void);
extern int fallback_aper_order;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: JIT emulator needs
On 6/22/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > > > and these methods also destroy yourself on any machine with a looser > > > > cache coherency between I and D-cache > > > > > > > > for all but x86 you pretty much have to do the mprotect() between the > > > > two states to deal with the cache flushing properly... > > > > > > If the instructions to force data write-back and/or to > > > invalidate the instruction cache are priveleged, yes. > > > AFAIK, only ARM is that lame. > > > > and your program executes this on all the cpus in the system? no I meant that you had to call your userspace instruction on all cpus, so on all-but-arm (from the Intel side I know IA64 needs such a flush, but I'm pretty sure PPC does too) I understood. AFAIK, it is common to propagate this via a special bus cycle. Section 5.1.5.2.1 of the PowerPC manual states that this is so. Secion 5.1.5.2 lists the requirements for both uniprocessor and multiprocessor. Note that Linux uses the coherent memory model for PowerPC SMP. See also the "icbi" instruction description, where the use of an address-only broadcast is mentioned. > I don't recall seeing such code in the libgcc tranpoline > setup for PowerPC. Either it's not required, or this is > a rather popular bug. I suspect it'll be playing under the assumption that going from "no code" to "code" is fine since the icache is cold. A previous trampoline would ruin that. Fortunately, PowerPC is not as brain-dead as ARM and IA64. (not that I'm writing code for any of these) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA Harddisk speed drop of 100 MB/s
Hi Carlo! On Fri, 22 Jun 2007, Carlo Wood wrote: > On Fri, Jun 22, 2007 at 06:17:46PM -0300, Henrique de Moraes Holschuh wrote: > > On Fri, 22 Jun 2007, Carlo Wood wrote: > > > So far I found out that it's RAID only. > > > > If you change the IO schedulers, does it help? > > How do I do that? for i in /sys/block/sd*/queue/scheduler ; do echo -n "scheduler for $i was:" ; cat $i ; echo anticipatory > $i ; done Should show you the scheduler for all libata/scsi discs, and switch to anticipatory. It probably works for hd* as well, but I don't have any around to test. I had ridiculous md raid performance (on resync) using cfq at least once. Unfortunately I never bothered trying to track it down, and I didn't check the throughput after the resync was done either. Also, I don't recall the kernel version, but it was either 2.6.18 or 2.6.20. Since it is a very simple test... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 signalfd interaction with thread-private signals
On Fri, 2007-06-22 at 17:12 -0700, Davide Libenzi wrote: > On Fri, 22 Jun 2007, Nicholas Miell wrote: > > > You could just get rid of the process/sighand/whatever reference > > entirely and just make reads on a signalfd always dequeue signals for > > the current thread. > > Duh?! ... > > > You'd lose the ability to pass signalfds around to other processes, but > > I'm not convinced that is even useful. (But I'm sure somebody smarter > > than me has a valid use case and would love to share :-) > > Wasn't it you that bitched (just a few days ago) because multiple threads > could not use the same signalfd and they (by your initial thought) had to > create one per thread? Nevermind, I wasn't entirely clear on the reason why signalfd_ctx had a tsk pointer. (I wrongly thought it was a vestige of the mechanism for the original delivery semantics.) -- Nicholas Miell <[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: Question about fair schedulers
On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote: Let's say I have a HD video that uses ~70% CPU. Let's say I want to watch it while I encode my music to vorbis (or rip a DVD). This is the only reasonable scenario I can imagine on a normal desktop, since most desktops have the CPU idle or under 10% usage during 95% of the time and a CPU scheduler makes no difference (maybe people on this list compile a few kernels every day, but that's not what most normal users like me do). Ok, so what will a fair scheduler do in this case? It is my understanding that it would give 50% CPU to each task, resulting in the video dropping frames. Is this correct? Yes, that's correct. What this *actually* means is that you want the media player to have higher priority than the DVD ripping program. Ergo you should run "nice +20 my_dvd_burner" or "nice +20 my_vorbis_encoder" under CFS or other fair schedulers. (Although you might not need to nice the dvd burner) The key difference is this: With the older scheduler your DVD ripping process would have had buffer underrun problems; even though it doesn't require much CPU at all (and can slow down burning if it doesn't get enough) it wouldn't get a chance to run at appropriate times to keep the buffer full. If you were encoding vorbis files you would *definitely* want to renice it as it will consume all available CPU. With CFS, your HD video player would get the 70% of the CPU that it needs (exactly), and the rest would be allocated to the DVD ripper and other processes. In addition, the DVD ripper gets certain latency guarantees even though it's *LOWER* priority than the media player (which also gets latency guarantees). Now, the _ideal_ solution for this situation would be to give ~70% to the video and the rest (~30%) to the encoder. But this goes against fairness, doesn't it? Yet most reports I've read about these two fair schedulers say that videos play smoother under load. What am I missing? Well, typically your video player *doesn't* chew up all of the CPU, so the fairness helps. Here's another scenario for you: You are running un-niced HD video player and recoding processes side-by-side, so that the HD video player only gets 50% of the CPU. Under older schedulers the video player would not get uniformly allocated CPU, it would get it in fits and spurts, causing more _visibly_dropped_ frames (IE: render 30 frames, drop 8, render 15, drop 2, etc). Under the new CFS scheduler it will get evenly allocated CPU and so while you *will* get dropped frames, they will be less visible (IE: Render 7 frames, drop 1, render 7 frames, drop 1, render 7 frames, drop 1). If I ask this question is because today I tested it and found that using the -ck kernel (with SD scheduler) the video would drop frames, while with the mainline kernel it played fine. Basically you are telling the kernel that your video player is no more important than your re-encoder process which, judging by your email, is completely untrue. If you really want it to treat the video player as specially important (or alternatively treat the reencoder process and specially unimportant) then you must tell it so with "nice" or "renice". My conclusion is that SD behaves as expected: it's more fair. But for a desktop, shouldn't an "intelligently unfair" scheduler be better? Well, it is "intelligently unfair", but you the user have to tell it what is more important for *YOU*. If I _really_ have to get some music recoded quickly then I may be willing to deal with some dropped frames in order to let that happen appropriately. P.S: As a second thought, a fair scheduler could behave really good in other scenarios, like a server running a busy forum on apache +mysql+php. Besides, this is a more real world scenario (and easier to benchmark). Why aren't people testing these schedulers under this kind of load? That kind of load is boring precisely because it doesn't care about interactivity. CFS/SD aren't a whole lot different from mainline- without-interactivity in that respect, precisely because the latency of the network is between ten and a hundred times more than the latency of the scheduler. The only time it really matters is with desktops where users care about smoothness. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
> current I only test kexec only. So clean shut GART in first kernel will help. > > where is hook for shutdown? add one in dma_ops? The low level code could just register its own shutdown handler. No need to go through dma_ops I think. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH for 2.6.22] [2/3] x86_64: Fix only make Macintosh drivers default on Macs
From: Olaf Hering <[EMAIL PROTECTED]> Include PPC_MAC in the default too, not only MAC which only covers m68k MACs. Signed-off-by: Olaf Hering <[EMAIL PROTECTED]> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- drivers/macintosh/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/drivers/macintosh/Kconfig === --- linux.orig/drivers/macintosh/Kconfig +++ linux/drivers/macintosh/Kconfig @@ -2,7 +2,7 @@ menuconfig MACINTOSH_DRIVERS bool "Macintosh device drivers" depends on PPC || MAC || X86 - default y if MAC + default y if (PPC_PMAC || MAC) if MACINTOSH_DRIVERS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 for 2.6.22] [1/3] i386: Make CMPXCHG64 only dependent on PAE
It is only used for PAE kernels in set_64bit. The problem is that due to a old Windows bug many CPUs need magic MSRs to enable CMPXCHG64, and we can't do that nicely early enough before it is potentially used. But since we only need it in PAE kernels so only force the checking for CMPXCHG65 with PAE. This fixes a boot failure on Transmeta Crusoe Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- arch/i386/Kconfig.cpu |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/arch/i386/Kconfig.cpu === --- linux.orig/arch/i386/Kconfig.cpu +++ linux/arch/i386/Kconfig.cpu @@ -299,7 +299,7 @@ config X86_POPAD_OK config X86_CMPXCHG64 bool - depends on !M386 && !M486 + depends on X86_PAE default y config X86_ALIGNMENT_16 Index: linux/arch/i386/Kconfig === --- linux.orig/arch/i386/Kconfig +++ linux/arch/i386/Kconfig @@ -541,7 +541,7 @@ config HIGHMEM4G config HIGHMEM64G bool "64GB" - depends on X86_CMPXCHG64 + depends on !M386 && !M486 help Select this if you have a 32-bit processor and more than 4 gigabytes of physical RAM. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 for 2.6.22] [3/3] x86_64: Ignore compat mode SYSCALL when IA32_EMULATION is not defined
Previously a program could switch to a compat mode segment and then
execute SYSCALL and it would jump to an uninitialized MSR and crash
the kernel.
Instead supply a dummy target for this case.
Pointed out by Jan Beulich
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/entry.S |7 +++
arch/x86_64/kernel/setup64.c |3 +++
2 files changed, 10 insertions(+)
Index: linux/arch/x86_64/kernel/entry.S
===
--- linux.orig/arch/x86_64/kernel/entry.S
+++ linux/arch/x86_64/kernel/entry.S
@@ -1163,3 +1163,10 @@ ENTRY(call_softirq)
ret
CFI_ENDPROC
ENDPROC(call_softirq)
+
+KPROBE_ENTRY(ignore_sysret)
+ CFI_STARTPROC
+ mov $-ENOSYS,%eax
+ sysret
+ CFI_ENDPROC
+ENDPROC(ignore_sysret)
Index: linux/arch/x86_64/kernel/setup64.c
===
--- linux.orig/arch/x86_64/kernel/setup64.c
+++ linux/arch/x86_64/kernel/setup64.c
@@ -150,6 +150,8 @@ void pda_init(int cpu)
char boot_exception_stacks[(N_EXCEPTION_STACKS - 1) * EXCEPTION_STKSZ +
DEBUG_STKSZ]
__attribute__((section(".bss.page_aligned")));
+extern asmlinkage void ignore_sysret(void);
+
/* May not be marked __init: used by software suspend */
void syscall_init(void)
{
@@ -160,6 +162,7 @@ void syscall_init(void)
*/
wrmsrl(MSR_STAR, ((u64)__USER32_CS)<<48 | ((u64)__KERNEL_CS)<<32);
wrmsrl(MSR_LSTAR, system_call);
+ wrmsrl(MSR_CSTAR, ignore_sysret);
#ifdef CONFIG_IA32_EMULATION
syscall32_cpu_init ();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
Andi Kleen wrote: On Saturday 23 June 2007 00:19:51 Alan Cox wrote: The kdump kernel should be normally all <4GB anyways. You won't need any IOMMU for its IO unless you O_DIRECT/sendfile out of /proc/kcore. Just don't do that (but I suspect it won't work anyways) If it's not then swiotlb will also not work because it won't get any memory <4GB. But I doubt this was YH's problem - the panic kernel memory is always reserved and there shouldn't be any ongoing DMAs in this area anyways. And what happens outside the kdump kernel shouldn't matter. I suspect he rather saw problems with non kdump kexec where we can just shut down the GART properly beforehand. current I only test kexec only. So clean shut GART in first kernel will help. where is hook for shutdown? add one in dma_ops? YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Sat, 23 Jun 2007, Satyam Sharma wrote: > But why? Let it do just one thing, and do it well. Is their > any requirement anywhere that requires us to give a dual > meaning to these menuconfig objects -- i.e. to also control > the inclusion / exclusion of code from the kernel as well as > also for the presentation + user interface purpose that it > currently serves? This getting ridiculous. :-( You're the one who is attaching a new meaning to it. Any config symbol has multiple meanings depending on the context, the menu property only changes _one_ of them, you want to drastically redefine it and that's not going to happen. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
On Saturday 23 June 2007 00:19:51 Alan Cox wrote: > > YH do you think you can look at simply reserving a portion of the iommu? > > And having the kexec on panic kernel use the reserved portion? > > How about simply reserving all of it for the base kernel and using soft > iommu for the panic kernel, its hardly high performance criticial at this > point. The kdump kernel should be normally all <4GB anyways. You won't need any IOMMU for its IO unless you O_DIRECT/sendfile out of /proc/kcore. Just don't do that (but I suspect it won't work anyways) If it's not then swiotlb will also not work because it won't get any memory <4GB. But I doubt this was YH's problem - the panic kernel memory is always reserved and there shouldn't be any ongoing DMAs in this area anyways. And what happens outside the kdump kernel shouldn't matter. I suspect he rather saw problems with non kdump kexec where we can just shut down the GART properly beforehand. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
* Chris Mason ([EMAIL PROTECTED]) wrote: > I'm sure people there will have a different versions of events. The > one part that was discussed was if pathname based security was > useful, and a number of the people in the room (outside of > novell) said it was. Now, it could be that nobody wanted to argue > anymore, since most opinions had come out on one list or another by > then. Indeed. The trouble is that's too high level compared with the actual implementation details. AA is stalled because it has failed to get VFS support for it's model. I don't see a nice way out unless it changes it's notion of policy language (globbing is the tough one) or gets traction to pass dentry/vfsmount all the way down. Paths are completely relevant for security, esp. when considering the parent dir and the leaf (as in forward lookup case). Retroactively creating the full path is at the minimum ugly, and in the worst case can be insecure (yes AA has taken many measures to mitigate that insecurity). > But as someone who doesn't use either SElinux or AA, I really hope > we can get past the part of the debate where: > > while(1) > AA) we think we're making users happy with pathname security > SELINUX) pathname security sucks Yes. Please. Both parties are miserably failing the sanity test. Doing the same thing over and over and expecting different results. AA folks: deal with the VFS issues that your patchset have in a palatable way (which does not include passing NULL when it's inconvenient to do otherwise). You've already missed an opportunity with Christoph's suggestions for changes in NFS. I know you've considered many alternative approaches and consistently hit dead ends. But please note, if you have coded yourself into a corner because of your policy language, that's your issue to solve, not ours. SELinux folks: do something useful rather than quibbling over the TCSEC definition of MAC and AA's poor taste in marketing literature. Here's some suggestions: 1) Make SELinux usable (it's *still* the number one complaint). While this is a bit of a cheap shot, it really is one of the core reasons AA advocates exist. 2) Work on a variant of Kyle's suggestion to squash the relevancy of AA. 3) Write an effective exploit against AA that demonstrates the fundamental weakness of the model (better make sure it's not also an issue for targetted policy). thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 signalfd interaction with thread-private signals
On Fri, 22 Jun 2007, Nicholas Miell wrote: > You could just get rid of the process/sighand/whatever reference > entirely and just make reads on a signalfd always dequeue signals for > the current thread. Duh?! ... > You'd lose the ability to pass signalfds around to other processes, but > I'm not convinced that is even useful. (But I'm sure somebody smarter > than me has a valid use case and would love to share :-) Wasn't it you that bitched (just a few days ago) because multiple threads could not use the same signalfd and they (by your initial thought) had to create one per thread? - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] inetdevice.h must include sysctl.h
From: "Satyam Sharma" <[EMAIL PROTECTED]> Date: Sat, 23 Jun 2007 05:26:52 +0530 > [PATCH] include sysctl.h from inetdevice.h > > When CONFIG_INET=y and CONFIG_SYSCTL=n: > > In file included from net/core/netpoll.c:16: > include/linux/inetdevice.h:15: error: > '__NET_IPV4_CONF_MAX' undeclared here (not in a function) > make[2]: *** [net/core/netpoll.o] Error 1 > make[1]: *** [net/core] Error 2 > make: *** [net] Error 2 > > So #include sysctl.h from inetdevice.h. > > Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> Patch applied, thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 signalfd interaction with thread-private signals
On Sat, 2007-06-23 at 09:19 +1000, Benjamin Herrenschmidt wrote: > On Sat, 2007-06-23 at 09:16 +1000, Benjamin Herrenschmidt wrote: > > On Fri, 2007-06-22 at 15:47 -0700, Linus Torvalds wrote: > > > Quite frankly, it strikes me that if we want to do this, then we > > > shouldn't > > > save the _process_ information at all, we should save the "sighand" > > > instead. > > > > > > So either we save the process info, or we save the sighand, but saving > > > the > > > "group_leader" seems totally bogus. Especially as the group leader can > > > change (by execve()). > > > > > > One thing that strikes me as I look at that function is that the whole > > > signalfd thing doesn't seem to do any reference counting. Ie it looks > > > totally buggy wrt passing the resulting fd off to somebody else, and then > > > exiting in the original process. > > > > > > What did I miss? > > > > Probably nothing... doesn't look good. What are the lifetime rules of a > > struct sighand tho ? > > Ah got it, signalfd_detach() in include/linux/signalfd.h from > exit_signal plus some rcu bits in signalfd lock/unlock. You could just get rid of the process/sighand/whatever reference entirely and just make reads on a signalfd always dequeue signals for the current thread. You'd lose the ability to pass signalfds around to other processes, but I'm not convinced that is even useful. (But I'm sure somebody smarter than me has a valid use case and would love to share :-) -- Nicholas Miell <[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: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On 6/23/07, Roman Zippel <[EMAIL PROTECTED]> wrote: Hi, On Sat, 23 Jun 2007, Satyam Sharma wrote: > Yup, so how / why am I wrong? I was making the point that a > "menuconfig" does not have code associated with it. Which is wrong, it's not and will not be limited to this. But why? Let it do just one thing, and do it well. Is their any requirement anywhere that requires us to give a dual meaning to these menuconfig objects -- i.e. to also control the inclusion / exclusion of code from the kernel as well as also for the presentation + user interface purpose that it currently serves? Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Sat, 23 Jun 2007, Satyam Sharma wrote: > Yup, so how / why am I wrong? I was making the point that a > "menuconfig" does not have code associated with it. Which is wrong, it's not and will not be limited to this. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 4/6] Make DRM use the tasklet is-sched API
> > The drm_locked_tasklet() function seems to have multiple bugs anyway, > so getting rid of it can only help, and it avoids exporting a new > tasklet_is_scheduled() interface. That's exactly what I though when looking over this code. There's some really crappy in code in that area, and it should simply be rewritten. Can someone submit a patch or even a better review? btw removing the core stuff and putting it i915 isn't acceptable, I'll have support for this feature for other hw coming up so the generic code needs to be available... 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/
Re: [RFC PATCH 4/6] Make DRM use the tasklet is-sched API
On Sat, 2007-06-23 at 00:38 +0200, Ingo Molnar wrote: > * Daniel Walker <[EMAIL PROTECTED]> wrote: > > > > The two patches have two different objectives, even though they are > > > related and currently on a 1 to 1 basis. The patches regardless, > > > should stay separate. > > > > I'm not convinced yet .. One more stab? > > uhm, i dont think Steve needs to 'convince' you. You have been (once > again ...) given extensive explanations about a really trivial topic, > but you keep pushing and demanding very agressively without apparently > reading the answers. If you dont want to or cannot understand it's > really your problem to solve, not Steve's ... Your right Steven doesn't need to convince me. He requested comments and I gave them, if he or you want to ignore them that's your prerogative. How can you say I didn't read the answers .. I said "I read this 5 times" ! It doesn't get much more explicit than that .. In fact, my response was mainly cause I thought his explanation was confusing.. How can you fault _me_ for that, it's the medium we're using. It seems like you assume all my emails are "demanding" and "aggressive", where I'm just asking questions and making comments .. Who am I to be making demands of anyone ? I DEMAND you do what I say! You better do it or else! I'll force Linus to ignore you, so you better do it. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/6] Convert all tasklets to workqueues
On Sat, 2007-06-23 at 00:44 +0200, Ingo Molnar wrote: > * Daniel Walker <[EMAIL PROTECTED]> wrote: > > > > remember, these changes have been in use in -rt for a while. there's > > > reason to believe that they aren't going to cause drastic problems. > > > > Since I've been working with -rt (~2 years now I think) it's clear > > that the number of testers of the patch isn't all that high compared > > to the stable kernel . [...] > > You havent been watching it too closely i guess :-) The -rt kernel often > pops up regressions before mainline does, especially when it comes to > arcane hardware often used by embedded vendors [ =B-) ]. It even > triggers certain high-end scalability and race bugs before the mainline > kernel does, due to its unique scheduling behavior. Don't assume anything Ingo ;) > So yes, -rt obviously does not have as wide of a tester basis as the > mainline kernel (but it's by no means small), it nevertheless has a > tester base that is partly orthogonal to the mainline kernel. > > Furthermore, -rt has a wide enough tester base for it to know that if > something has not caused problems in it for years is certainly at least > a good indicator that something isnt going to cause drastic problems ... > which was the point to begin with. As I said, it's a plus but not a silver bullet ? Are you saying I was wrong ? Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inotify and /proc?
On Fri, Jun 22, 2007 at 06:51:10PM -0400, C. Scott Ananian wrote: > No, clearly inotify on all files in /proc is not the right thing to > do. But I'm writing support for "RDNSS in RA" -- IPv6 Router > Advertisement messages can include a DNS server specification, which > makes IPv6 completely autoconfiguring. Why the hell do you need idiotify on it? Just make poll(2) work and be done with that; see e.g. how /proc//mounts does it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On 6/23/07, Roman Zippel <[EMAIL PROTECTED]> wrote: On Sat, 23 Jun 2007, Satyam Sharma wrote: > 1. Kconfig symbols will always have code associated with them. > That's the entire purpose of Kconfig, is it not? A possible counter example: CONFIG_SCSI. (RAID_ATTRS is currently a little misplaced). It's optional for any config symbol to have any code attached to it, menuconfig doesn't change anything. CONFIG_SCSI _does_ have code associated with it. (so does CONFIG_RAID_ATTRS) [ I was expecting you to give the counter-example of various config symbols that control the assignment of some value to some variable, actually, but then I would've countered back with the fact that a variable is also "code" and not something that is only about presentation / user interface :-) ] > 2. "menuconfig" symbols, otoh, were _invented_ for another reason > entirely: presentation and user interface i.e. so that users are able > to disable entire menus (and all the options contained therein) > without having to enter into the menu first, and without having to > disable all options individually (which was the situation that existed > before the introduction of these menuconfig objects). Since I'm the one who _invented_ it, I can tell you you're wrong. :) This functionality isn't limited to menuconfig symbols. The menu option simply changes how the child symbols can be displayed. Yup, so how / why am I wrong? I was making the point that a "menuconfig" does not have code associated with it. Why else _was_ it invented then, if not only for presentation / user interface purposes? I really don't see what role it plays as a "config symbol" in Kconfig (other than the fact that that is how it got implemented to do its thing). Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PROBLEM: PCI setup hangs on Asus Notebook (nolapic helps)
> On Fri, 22 Jun 2007 19:43:34 +0200 Malte Cornils <[EMAIL PROTECTED]> wrote: > Hello Andrew, > > On Thursday, 21. Juni 2007 14:27 Andrew Morton wrote: > > > Booting with nolapic helps, but makes the SATAized IDE controller buggy > > > [...] There have been other reports of the problem on Asus notebooks. I've > > > collected some links:[...] > > > Are any of these problems new behaviour, or has it always done this? > > > > If there _is_ new behaviour here, are you able to identify which earlier > > kernel versions did not exhibit it? > > The patch causing that behaviour went in between 2.6.18 and 2.6.19rc-1. I > have > some 100 patches to go bisecting the bug, but it's slow work due to > difficulties in getting physical access to the machine for extended periods > of time. > > I'll be sure to let you know when I have the exact commit. That may be at any > time from tomorrow to beginning of July, I'm not sure yet what my free time > allows. > OK, thanks. There's no rush but please do persist... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 signalfd interaction with thread-private signals
On Sat, 2007-06-23 at 09:16 +1000, Benjamin Herrenschmidt wrote: > On Fri, 2007-06-22 at 15:47 -0700, Linus Torvalds wrote: > > Quite frankly, it strikes me that if we want to do this, then we shouldn't > > save the _process_ information at all, we should save the "sighand" > > instead. > > > > So either we save the process info, or we save the sighand, but saving the > > "group_leader" seems totally bogus. Especially as the group leader can > > change (by execve()). > > > > One thing that strikes me as I look at that function is that the whole > > signalfd thing doesn't seem to do any reference counting. Ie it looks > > totally buggy wrt passing the resulting fd off to somebody else, and then > > exiting in the original process. > > > > What did I miss? > > Probably nothing... doesn't look good. What are the lifetime rules of a > struct sighand tho ? Ah got it, signalfd_detach() in include/linux/signalfd.h from exit_signal plus some rcu bits in signalfd lock/unlock. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix signalfd interaction with thread-private signals
On Fri, 2007-06-22 at 15:47 -0700, Linus Torvalds wrote: > Quite frankly, it strikes me that if we want to do this, then we shouldn't > save the _process_ information at all, we should save the "sighand" > instead. > > So either we save the process info, or we save the sighand, but saving the > "group_leader" seems totally bogus. Especially as the group leader can > change (by execve()). > > One thing that strikes me as I look at that function is that the whole > signalfd thing doesn't seem to do any reference counting. Ie it looks > totally buggy wrt passing the resulting fd off to somebody else, and then > exiting in the original process. > > What did I miss? Probably nothing... doesn't look good. What are the lifetime rules of a struct sighand tho ? Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
Alan Cox <[EMAIL PROTECTED]> writes: > On Fri, 22 Jun 2007 15:57:08 -0700 > Yinghai Lu <[EMAIL PROTECTED]> wrote: > >> Alan Cox wrote: >> >> > Don't disable it, just don't touch it or any of its mappings. Leave it >> > *alone*, and use swiotlb. That'll maximise the ability to recover stuff >> > from the kexec kernel (since for one you may want to dump the gart when a >> > 3d app goes kerblam) >> >> How about LinuxBIOS + Kernel ===> Final kernel path? >> someday EFI(PEI) + Kernel ===> Final kernel path need that too. >> >> or the normal kexec path still could have clean shutdown. > > The kexec path for kdump should be swiotlb and leave the GART alone as > you are dumping as much state as you can and leaving stuff as is when > possible. The new-kernel case you shut everything down so you can shut > down the GART in the old kernel and re-initialise it in the new one Agreed. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Sat, 23 Jun 2007, Satyam Sharma wrote: > 1. Kconfig symbols will always have code associated with them. > That's the entire purpose of Kconfig, is it not? A possible counter example: CONFIG_SCSI. (RAID_ATTRS is currently a little misplaced). It's optional for any config symbol to have any code attached to it, menuconfig doesn't change anything. > 2. "menuconfig" symbols, otoh, were _invented_ for another reason > entirely: presentation and user interface i.e. so that users are able > to disable entire menus (and all the options contained therein) > without having to enter into the menu first, and without having to > disable all options individually (which was the situation that existed > before the introduction of these menuconfig objects). Since I'm the one who _invented_ it, I can tell you you're wrong. :) This functionality isn't limited to menuconfig symbols. The menu option simply changes how the child symbols can be displayed. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] CFS scheduler, -v18
On Friday 22 June 2007, Ingo Molnar wrote: >i'm pleased to announce release -v18 of the CFS scheduler patchset. > >The rolled-up CFS patch against today's -git kernel, v2.6.22-rc5, >v2.6.22-rc4-mm2, v2.6.21.5 or v2.6.20.14 can be downloaded from the >usual place: > > http://people.redhat.com/mingo/cfs-scheduler/ > >The biggest change in -v18 are various performance related improvements. >Thomas Gleixner has eliminated expensive 64-bit divisions by converting >the arithmetics to scaled math (without impacting the quality of >calculations). Srivatsa Vaddagiri and Dmitry Adamushko have continued >the abstraction and cleanup work. Srivatsa Vaddagiri and Christoph >Lameter fixed the NUMA balancing bug reported by Paul McKenney. There >were also a good number of other refinements to the CFS code. (No >reproducible behavioral regressions were reported against -v17 so far, >so the 'behavioral' bits are mostly unchanged.) > >Changes since -v17: > > - implement scaled math speedups for CFS. (Thomas Gleixner) > > - lots of core code updates, cleanups and streamlining. > (Srivatsa Vaddagiri, Dmitry Adamushko, me.) > > - bugfix: fix NUMA balancing. (Srivatsa Vaddagiri, Christoph Lameter, > Paul E. McKenney) > > - feature: SCHED_IDLE now also implies block-scheduler (CFQ) > idle-IO-priority. (suggested by Thomas Sattler, picked up from -ck) > > - build fix for ppc32. (reported, tested and confirmed fixed by > Art Haas) > > - ARM fix. (reported and debugged by Thomas Gleixner) > > - cleanup: implemented idle_sched_class in kernel/sched_idletask.c as a > way to separate out rq->idle handling out of the core scheduler. This > made a good deal of idle-task related special-cases go away. > > - debug: make the sysctls safer by introducing high and low limits. > > - cleanup: move some of the debug counters to under CONFIG_SCHEDSTATS. > > - speedup: various micro-optimizations > > - various other small updates. > >As usual, any sort of feedback, bugreport, fix and suggestion is more >than welcome! > Humm, problem methinks. Applying the patch, with 2.6.22-rc5 applied to 2.6.21 completed, from my script: now applying patch sched-cfs-v2.6.22-rc5-v18.patch patching file Documentation/kernel-parameters.txt patching file Documentation/sched-design-CFS.txt patching file Makefile patching file arch/i386/kernel/smpboot.c patching file arch/i386/kernel/tsc.c patching file arch/ia64/kernel/setup.c patching file arch/mips/kernel/smp.c patching file arch/sparc/kernel/smp.c patching file arch/sparc64/kernel/smp.c patching file block/cfq-iosched.c patching file fs/proc/array.c patching file fs/proc/base.c patching file include/asm-generic/bitops/sched.h patching file include/linux/hardirq.h patching file include/linux/sched.h patching file include/linux/topology.h patching file init/main.c patching file kernel/delayacct.c patching file kernel/exit.c patching file kernel/fork.c patching file kernel/posix-cpu-timers.c patching file kernel/sched.c patching file kernel/sched_debug.c patching file kernel/sched_fair.c patching file kernel/sched_idletask.c patching file kernel/sched_rt.c patching file kernel/sched_stats.h patching file kernel/softirq.c patching file kernel/sysctl.c The next patch would delete the file l/kernel/sched.c, which does not exist! Assume -R? [n] How to proceed? -- 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) Even more amazing was the realization that God has Internet access. I wonder if He has a full newsfeed? -- Matt Welsh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 to tell linux (on x86) to ignore 1M or memory
On 06/23/2007 01:00 AM, Bodo Eggert wrote: The real mode on i386+ can actually access the whole 4GB address range due to a former-bug-now-feature in the i386+. Generally called "unreal mode". Yes, sure. Just a hack though. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question about fair schedulers
Hi, First I'd like to say I'm not a programmer or even a geek, just a normal user, so my question might be very basic or even stupid. If so, please excuse me. I've been reading about CFS and SD schedulers here on the list and my basic understanding is that they try to improve interactivity by being completely fair, i.e., giving the same amount of CPU time to each task running at a given time. There is something I don't get about this, so today I tried a little test with the -ck kernel comparing it to mainline. Let's say I have a HD video that uses ~70% CPU. Let's say I want to watch it while I encode my music to vorbis (or rip a DVD). This is the only reasonable scenario I can imagine on a normal desktop, since most desktops have the CPU idle or under 10% usage during 95% of the time and a CPU scheduler makes no difference (maybe people on this list compile a few kernels every day, but that's not what most normal users like me do). Ok, so what will a fair scheduler do in this case? It is my understanding that it would give 50% CPU to each task, resulting in the video dropping frames. Is this correct? Now, the _ideal_ solution for this situation would be to give ~70% to the video and the rest (~30%) to the encoder. But this goes against fairness, doesn't it? Yet most reports I've read about these two fair schedulers say that videos play smoother under load. What am I missing? If I ask this question is because today I tested it and found that using the -ck kernel (with SD scheduler) the video would drop frames, while with the mainline kernel it played fine. My conclusion is that SD behaves as expected: it's more fair. But for a desktop, shouldn't an "intelligently unfair" scheduler be better? Thanks for any insights. P.S: As a second thought, a fair scheduler could behave really good in other scenarios, like a server running a busy forum on apache+mysql+php. Besides, this is a more real world scenario (and easier to benchmark). Why aren't people testing these schedulers under this kind of load? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/6] Convert all tasklets to workqueues
On Fri, 2007-06-22 at 23:59 +0200, Ingo Molnar wrote: > * Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > If the numbers say that there is no performance difference (or even > > better: that the new code performs better or fixes some latency issue > > or whatever), I'll be very happy. But if the numbers say that it's > > worse, no amount of cleanliness really changes that. > > Most of the tasklet uses are in rarely used or arcane drivers - in fact > none of my 10 test-boxes utilizes _any_ tasklet in any way that could > even get close to mattering to performance. In other words: i just > cannot test this, nor do i think that others will really test this. This is exactly why I included that CONFIG option in the first series. Because, I only have a handful of hardware that actually uses tasklets. And all those pr_debugs I had where turned on on most of my boxes. I was not flooded with prints either (every function including tasklet_schedule had a print). So, basically, I can't do benchmarks. I was hoping to get this into -mm with a easy way for people, who have hardware that uses tasklets extensively, to run it with tasklets on and off to see if there is a difference. My fear of not having a config option to switch between the two (for -mm only) is that we may lose benchmarking from those that are not comfortable at removing this patch from -mm. There are people out there that download and test the -mm tree straight from kernel.org. Just because someone compiles their own kernel doesn't mean they can (or will) patch it. -- 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: how to tell linux (on x86) to ignore 1M or memory
Rene Herman <[EMAIL PROTECTED]> wrote: > The point was that real mode could only access the first 1M, not > the first 16... :-) The real mode on i386+ can actually access the whole 4GB address range due to a former-bug-now-feature in the i386+. This "bug" causes the segment limit to not be reset on return to real mode, but only on subsequent assigns to the segment registers/selectors. Using a rarely used segment register like GS, you could use extended memory in your program. Obviously this needs 1) Entering and returning from protected mode, 2) all programs to agree not to clobber GS and 3) not using v86 mode (EMM386.exe). Therefore and because it was discovered in the late days of DOS it was not in widespread use. Some DOS extenders were reported to use it ... http://www.programmersheaven.com/mb/x86_asm/344953/344953/readmessage.aspx -- The programmer's National Anthem is '' Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [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: Fix signalfd interaction with thread-private signals
On Fri, 22 Jun 2007, Linus Torvalds wrote: > Quite frankly, it strikes me that if we want to do this, then we shouldn't > save the _process_ information at all, we should save the "sighand" > instead. > > So either we save the process info, or we save the sighand, but saving the > "group_leader" seems totally bogus. Especially as the group leader can > change (by execve()). > > One thing that strikes me as I look at that function is that the whole > signalfd thing doesn't seem to do any reference counting. Ie it looks > totally buggy wrt passing the resulting fd off to somebody else, and then > exiting in the original process. > > What did I miss? We intercept the sighand going out of business, and we do not access it anymore after that (by the mean of signalfd_lock() returning zero). I'd be OK with Oleg patch, although I really prefer signalfd being more flexible (that is, with sync signals disabled in signalfd, and with Ben's patch reverted). Unless clear point of breakage are shown with such approach. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
On Fri, 22 Jun 2007 15:57:08 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote: > Alan Cox wrote: > > > Don't disable it, just don't touch it or any of its mappings. Leave it > > *alone*, and use swiotlb. That'll maximise the ability to recover stuff > > from the kexec kernel (since for one you may want to dump the gart when a > > 3d app goes kerblam) > > How about LinuxBIOS + Kernel ===> Final kernel path? > someday EFI(PEI) + Kernel ===> Final kernel path need that too. > > or the normal kexec path still could have clean shutdown. The kexec path for kdump should be swiotlb and leave the GART alone as you are dumping as much state as you can and leaving stuff as is when possible. The new-kernel case you shut everything down so you can shut down the GART in the old kernel and re-initialise it in the new one Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Broadcom (bnx2) on PE1950/2950 failure
Fortier,Vincent [Montreal] wrote: Here is the output of the dmesg with now the appropriate order: [EMAIL PROTECTED] /etc]# dmesg | grep -i eth [ 120.685696] Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v1.5.8.1 (May 7, 2007) [ 120.703846] eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f800, IRQ 17, node addr 0019b9c8eedc [ 120.735350] eth1: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f400, IRQ 16, node addr 0019b9c8eede [ 120.921403] e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection [ 121.069025] e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection [ 267.720475] bnx2: eth0: using MSI [ 270.832235] bnx2: eth0 NIC Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON But still, there is a problem with the second Broadcom port (eth1): [EMAIL PROTECTED] /etc]# mii-tool eth0: negotiated 100baseTx-FD flow-control, link ok SIOCGMIIPHY on 'eth1' failed: Resource temporarily unavailable eth2: negotiated 100baseTx-FD flow-control, link ok eth3: negotiated 100baseTx-FD flow-control, link ok I don't get it? Help appreciated. Is that interface down? mii-tool probably doesn't work in that case.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
Alan Cox wrote: Don't disable it, just don't touch it or any of its mappings. Leave it *alone*, and use swiotlb. That'll maximise the ability to recover stuff from the kexec kernel (since for one you may want to dump the gart when a 3d app goes kerblam) How about LinuxBIOS + Kernel ===> Final kernel path? someday EFI(PEI) + Kernel ===> Final kernel path need that too. or the normal kexec path still could have clean shutdown. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/6] Convert all tasklets to workqueues
> As a second example, msr_seek() in arch/i386/kernel/msr.c... is the > inode semaphore enough or not? Who understands the implications well > enough to say? lseek is one of the nasty remaining cases. tty is another real horror that needs further work but we slowly get closer - drivers/char is almost but not entirely lock_kernel free now and several users look quite easy to swat (everyone but tty_io.c) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Oops in a driver while using SLUB as a SLAB allocator
On Fri, 22 Jun 2007, Hugh Dickins wrote: > On Fri, 22 Jun 2007, Christoph Lameter wrote: > > > > We need to fix any remaining weird slab object uses right now. Your check > > leaves a lot of holes open. 2.6.22 removes all other such strange slab > > uses in other arches. It would be inconsistent if we left these things in > > ARM (and maybe PA-RISC). > > As I understand it, that driver used to work right with SLAB, then > oopsed with SLUB, and now works okay again with the page_mapping patch? Try to enable debugging then it may fail again despite your patch. You just scratched the surface with this and are enabling a dangerous usage mode with SLUB that we explicitly did not want to support anymore. > I'm unclear how it comes about that you removed "all other such strange > slab uses in other arches", yet missed this? That suggests there may > be further unexpected uses. There could be other uses that were missed. I looked for slabs created by kmem_cache_create. The trouble is that any kmalloc could also be used for engineer these weird things (as seen here) and there are gazillions of kmallocs. That is why a VM_BUG_ON is useful. However, it requires some effort even with SLAB to create these things and--given that we have tested extensively on lots of arches--I am hopeful that we have caught everything. > It worries me that any use which catches you by surprise has to be > fixed up in the caller, rather than in slub itself: slab/slub is a > service, not a master. But I'm rather repeating myself. SLUB used to implement the same special casing as SLAB did (which results in the fragile scenarios in which the above is possible). But we made the decision to clean up the slab interface and we dropped the emulation of the SLAB frills from SLUB. Messy and problematic code like this should be removed. That improves the quality of the kernel. The removal is a straightfoward process. And the cases that we are discussing here are in remote corners of the 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/5 v2] Convert the RCU tasklet into a softirq
On Fri, Jun 22, 2007 at 02:20:52PM -0400, Steven Rostedt wrote:
> I believe this was originally done by Dipankar Sarma. I pulled these
> changes from the -rt kernel.
>
> For better preformance, RCU should use a softirq instead of a
> tasklet.
>
> From: Dipankar Sarma <[EMAIL PROTECTED]>
> Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Acked-by: Paul E. McKenney <[EMAIL PROTECTED]>
> Index: linux-2.6-test/include/linux/interrupt.h
> ===
> --- linux-2.6-test.orig/include/linux/interrupt.h
> +++ linux-2.6-test/include/linux/interrupt.h
> @@ -245,6 +245,9 @@ enum
> #ifdef CONFIG_HIGH_RES_TIMERS
> HRTIMER_SOFTIRQ,
> #endif
> + RCU_SOFTIRQ,/* Preferable RCU should always be the last softirq */
> + /* Entries after this are ignored in split softirq mode */
> + MAX_SOFTIRQ,
> };
>
> /* softirq mask and active fields moved to irq_cpustat_t in
> Index: linux-2.6-test/kernel/rcupdate.c
> ===
> --- linux-2.6-test.orig/kernel/rcupdate.c
> +++ linux-2.6-test/kernel/rcupdate.c
> @@ -67,7 +67,6 @@ DEFINE_PER_CPU(struct rcu_data, rcu_data
> DEFINE_PER_CPU(struct rcu_data, rcu_bh_data) = { 0L };
>
> /* Fake initialization required by compiler */
> -static DEFINE_PER_CPU(struct tasklet_struct, rcu_tasklet) = {NULL};
> static int blimit = 10;
> static int qhimark = 1;
> static int qlowmark = 100;
> @@ -253,7 +252,7 @@ static void rcu_do_batch(struct rcu_data
> if (!rdp->donelist)
> rdp->donetail = >donelist;
> else
> - tasklet_schedule(_cpu(rcu_tasklet, rdp->cpu));
> + raise_softirq(RCU_SOFTIRQ);
> }
>
> /*
> @@ -405,7 +404,6 @@ static void rcu_offline_cpu(int cpu)
> _cpu(rcu_bh_data, cpu));
> put_cpu_var(rcu_data);
> put_cpu_var(rcu_bh_data);
> - tasklet_kill_immediate(_cpu(rcu_tasklet, cpu), cpu);
> }
>
> #else
> @@ -417,7 +415,7 @@ static void rcu_offline_cpu(int cpu)
> #endif
>
> /*
> - * This does the RCU processing work from tasklet context.
> + * This does the RCU processing work from softirq context.
> */
> static void __rcu_process_callbacks(struct rcu_ctrlblk *rcp,
> struct rcu_data *rdp)
> @@ -462,7 +460,7 @@ static void __rcu_process_callbacks(stru
> rcu_do_batch(rdp);
> }
>
> -static void rcu_process_callbacks(unsigned long unused)
> +static void rcu_process_callbacks(struct softirq_action *unused)
> {
> __rcu_process_callbacks(_ctrlblk, &__get_cpu_var(rcu_data));
> __rcu_process_callbacks(_bh_ctrlblk, &__get_cpu_var(rcu_bh_data));
> @@ -526,7 +524,7 @@ void rcu_check_callbacks(int cpu, int us
> rcu_bh_qsctr_inc(cpu);
> } else if (!in_softirq())
> rcu_bh_qsctr_inc(cpu);
> - tasklet_schedule(_cpu(rcu_tasklet, cpu));
> + raise_softirq(RCU_SOFTIRQ);
> }
>
> static void rcu_init_percpu_data(int cpu, struct rcu_ctrlblk *rcp,
> @@ -549,7 +547,7 @@ static void __devinit rcu_online_cpu(int
>
> rcu_init_percpu_data(cpu, _ctrlblk, rdp);
> rcu_init_percpu_data(cpu, _bh_ctrlblk, bh_rdp);
> - tasklet_init(_cpu(rcu_tasklet, cpu), rcu_process_callbacks, 0UL);
> + open_softirq(RCU_SOFTIRQ, rcu_process_callbacks, NULL);
> }
>
> static int __cpuinit rcu_cpu_notify(struct notifier_block *self,
>
> --
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [REGRESSION 2.6-git] possible circular locking dependency detected with XFS
Hi Oliver,
On 22/06/07, Oliver Pinter <[EMAIL PROTECTED]> wrote:
Hi all!
I found this info:
===
[ INFO: possible circular locking dependency detected ]
2.6.22-rc5-wifi1 #2
---
mount/2209 is trying to acquire lock:
(&(>i_lock)->mr_lock/1){--..}, at: [] xfs_ilock+0x66/0x90
but task is already holding lock:
(&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x66/0x90
AFAIR it is not a regression. It is a known bug (harmless).
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: inotify and /proc?
On 6/21/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
On Thursday 21 June 2007, C. Scott Ananian wrote:
> I'd like to make a read-only /proc file which supports inotify -- that
> is, the kernel can send change notifications to userland via the
> inotify mechanism. I've found fsnotify_modify() (in
> include/linux/fsnotify.h) which seems to do what I want, but it takes
> a struct dentry * -- how can I get a dentry from a struct
> proc_dir_entry and increment its ref count to keep it around? Any
> help would be appreciated. Thanks!
It sounds a little fishy to want that in the first place. If we wanted
inotify on /proc, it should work on all files I guess, but that's
an immense amount of work.
No, clearly inotify on all files in /proc is not the right thing to
do. But I'm writing support for "RDNSS in RA" -- IPv6 Router
Advertisement messages can include a DNS server specification, which
makes IPv6 completely autoconfiguring.
Side note for a second: glibc's resolver is really brain dead! Only
reading /etc/resolv.conf once at startup is clearly the Wrong Thing
for any sort of mobile application, where applications can easily
persist across suspend/resume into multiple networks. Glibc should
use inotify on /etc/resolv.conf and re-read the DNS configuration when
network-manager (say) updates it.
Back to kernel-land: in an IPv6 only world, it might make sense to
export a /proc file compatible with the format of /etc/resolv.conf,
with one DNS server address per line. If glibc uses/used inotify on
/etc/resolv.conf, then symlinking /etc/resolv.conf to
/proc/net/ipv6_dns allows glibc to get kernel DNS autoconfiguration
updates without a special case. [Assuming that glibc was smart enough
to watch the referenced file and not the symlink...]
A draft patch to implement /proc/net/ipv6_dns is attached, just to
make the discussion concrete. [Not guaranteed to apply cleanly, as I'm
not sure that gmail won't munge the whitespace. But it should be
readable at least.]
--scott
--
( http://cscott.net/ )
-
diff -ruHpN -X dontdiff linux-2.6.22-rc5-orig/include/net/ip6_fib.h
linux-2.6.22-rc5/include/net/ip6_fib.h
--- linux-2.6.22-rc5-orig/include/net/ip6_fib.h 2007-06-16
22:09:12.0 -0400
+++ linux-2.6.22-rc5/include/net/ip6_fib.h 2007-06-20 14:17:58.0
-0400
@@ -79,6 +79,7 @@ struct rt6key
};
struct fib6_table;
+struct rdns6_info;
struct rt6_info
{
@@ -105,6 +106,8 @@ struct rt6_info
struct rt6key rt6i_src;
u8 rt6i_protocol;
+
+struct rdns6_info *rt6i_rdnss;
};
static inline struct inet6_dev *ip6_dst_idev(struct dst_entry *dst)
diff -ruHpN -X dontdiff linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h
linux-2.6.22-rc5/include/net/ip6_rdnss.h
--- linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.22-rc5/include/net/ip6_rdnss.h2007-06-21 18:16:33.0
-0400
@@ -0,0 +1,58 @@
+#ifndef _NET_IP6_RDNSS_H
+#define _NET_IP6_RDNSS_H
+
+#ifdef __KERNEL__
+
+#include
+
+struct nd_opt_rdnss {
+ __u8type;
+ __u8length;
+#if defined(__BIG_ENDIAN_BITFIELD)
+ __u8priority:4,
+ open:1,
+ reserved1:3;
+#elif defined(__LITTLE_ENDIAN_BITFIELD)
+ __u8reserved1:3,
+ open:1,
+ priority:4;
+#else
+# error not little or big endian
+#endif
+ __u8reserved2;
+ __be32 lifetime;
+ struct in6_addr rdnss[1]; /* 1 or more */
+};
+
+struct rdns6_entry {
+ struct rdns6_entry *next;
+ struct in6_addr rdnss;
+ __u8priority;
+ __u8open;
+ __u32 lifetime;
+ unsigned long expires;
+};
+
+struct rdns6_info {
+ rwlock_tlock;
+ struct timer_list expiry_timer;
+ struct rdns6_entry *rdnss_list;
+ struct inet6_dev * in6_dev; /* back pointer for netlink notify */
+ int expire_all : 1, /* remove entries on ifdown */
+ free_me : 1; /* safely free this struct */
+};
+
+/* Receive and process an RA message with the given RDNSS options. */
+extern voidrdns6_ra_rcv(struct inet6_dev *dev, struct rt6_info *rt,
+struct nd_opt_rdnss **opts, int opt_cnt);
+/* Expire all of the dns server info from a route (as on an ifdown). */
+extern voidrdns6_info_expire_all(struct rt6_info *rt);
+/* Delete the DNS list information from a struct rt6_info. */
+extern voidrdns6_info_del(struct rt6_info *rt);
+
+/* Generate the /proc/net/ipv6_dns file. */
+extern int rdns6_proc_info(char *buffer, char **start,
+
Re: [PATCH] x86-64: disable the GART before allocate aperture
On Fri, 22 Jun 2007 15:43:00 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote: > Eric W. Biederman wrote: > > The original design came from thinking about systems where using the iommu > > was mandatory. I think we almost always reserve memory below 1G for the > > kexec > > on panic kernel so it really shouldn't be an issue in that case. Except > > we need to pass an option to force not using the iommu. I don't think > > noiommu or swiotlb is going to make any real difference. > > > > So I'm totally in favor of turning off features if we don't need them and we > > don't take a tremendous performance hit. (People get grumpy when writing > > all of memory to disk takes completely unreasonable amounts of time). > > > So you prefer to > add diable_gart in shutdown or suspend func and let kexec to use swiotlb > comand line? Don't disable it, just don't touch it or any of its mappings. Leave it *alone*, and use swiotlb. That'll maximise the ability to recover stuff from the kexec kernel (since for one you may want to dump the gart when a 3d app goes kerblam) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 signalfd interaction with thread-private signals
On Sat, 23 Jun 2007, Benjamin Herrenschmidt wrote: > > > > > It does exactly so, please note this chunk > > > > @@ -330,7 +339,7 @@ asmlinkage long sys_signalfd(int ufd, si > > > > init_waitqueue_head(>wqh); > > ctx->sigmask = sigmask; > > - ctx->tsk = current; > > + ctx->tsk = current->group_leader; > > > > > It might well be that signalfd's concept of context is wrong in the > > > first place and it should be attached to processes rather than threads > > > and that made more explicit in the first place... > > Yup, looks like I was looking at a wrong patch... I think it's the right > thing to do indeed. Quite frankly, it strikes me that if we want to do this, then we shouldn't save the _process_ information at all, we should save the "sighand" instead. So either we save the process info, or we save the sighand, but saving the "group_leader" seems totally bogus. Especially as the group leader can change (by execve()). One thing that strikes me as I look at that function is that the whole signalfd thing doesn't seem to do any reference counting. Ie it looks totally buggy wrt passing the resulting fd off to somebody else, and then exiting in the original process. What did I miss? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/6] Convert all tasklets to workqueues
* Daniel Walker <[EMAIL PROTECTED]> wrote: > > remember, these changes have been in use in -rt for a while. there's > > reason to believe that they aren't going to cause drastic problems. > > Since I've been working with -rt (~2 years now I think) it's clear > that the number of testers of the patch isn't all that high compared > to the stable kernel . [...] You havent been watching it too closely i guess :-) The -rt kernel often pops up regressions before mainline does, especially when it comes to arcane hardware often used by embedded vendors [ =B-) ]. It even triggers certain high-end scalability and race bugs before the mainline kernel does, due to its unique scheduling behavior. So yes, -rt obviously does not have as wide of a tester basis as the mainline kernel (but it's by no means small), it nevertheless has a tester base that is partly orthogonal to the mainline kernel. Furthermore, -rt has a wide enough tester base for it to know that if something has not caused problems in it for years is certainly at least a good indicator that something isnt going to cause drastic problems ... which was the point to begin with. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/6] Convert all tasklets to workqueues
> > [ and on a similar notion, i still havent given up on seeing all BKL > > use gone from the kernel. I expect it to happen any decade now ;-) ] > 2.6.21 had 476 lock_kernel() calls. 2.6.22-git has 473 lock_kernel() > calls currently. With that kind of flux we'll see the BKL gone in about > 40 years =B-) > 'struct semaphore' use on the other hand has gone down by 10% in this > release, which is a good rate. I guess the lack of lockdep coverage for > semaphores might be one of the driving forces? ;-) The problem with removing uses of the BKL is that a "lock_kernel()" gives no clue about what it is protecting against, and so it requires a lot of very difficult auditing to replace with appropriate locking. To take a couple of examples at random: fs/ext4/ioctl.c takes the BKL in ext4_compat_ioctl() around the call to ext4_ioctl(). Kind of sad that a "next-generation" FS still uses the BKL, but who understands things well enough to say how all the cases in ext4_ioctl() are relying on being called with the BKL held? As a second example, msr_seek() in arch/i386/kernel/msr.c... is the inode semaphore enough or not? Who understands the implications well enough to say? Most semaphores on the other hand can be replaced by mutexes or completions in a fairly straightforward way. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
Eric W. Biederman wrote: The original design came from thinking about systems where using the iommu was mandatory. I think we almost always reserve memory below 1G for the kexec on panic kernel so it really shouldn't be an issue in that case. Except we need to pass an option to force not using the iommu. I don't think noiommu or swiotlb is going to make any real difference. So I'm totally in favor of turning off features if we don't need them and we don't take a tremendous performance hit. (People get grumpy when writing all of memory to disk takes completely unreasonable amounts of time). So you prefer to add diable_gart in shutdown or suspend func and let kexec to use swiotlb comand line? YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 4/6] Make DRM use the tasklet is-sched API
* Daniel Walker <[EMAIL PROTECTED]> wrote: > > The two patches have two different objectives, even though they are > > related and currently on a 1 to 1 basis. The patches regardless, > > should stay separate. > > I'm not convinced yet .. One more stab? uhm, i dont think Steve needs to 'convince' you. You have been (once again ...) given extensive explanations about a really trivial topic, but you keep pushing and demanding very agressively without apparently reading the answers. If you dont want to or cannot understand it's really your problem to solve, not Steve's ... Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix signalfd interaction with thread-private signals
> > It does exactly so, please note this chunk > > @@ -330,7 +339,7 @@ asmlinkage long sys_signalfd(int ufd, si > > init_waitqueue_head(>wqh); > ctx->sigmask = sigmask; > - ctx->tsk = current; > + ctx->tsk = current->group_leader; > > > It might well be that signalfd's concept of context is wrong in the > > first place and it should be attached to processes rather than threads > > and that made more explicit in the first place... Yup, looks like I was looking at a wrong patch... I think it's the right thing to do indeed. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi Roman, On 6/23/07, Roman Zippel <[EMAIL PROTECTED]> wrote: On Sat, 23 Jun 2007, Satyam Sharma wrote: > > menuconfig is really a type of config symbol, rather than a type of menu. > > Well, I'd have to disagree here. A config symbol has code associated > with it (at least _all_ config symbols in the kernel originally did, till > when these "menuconfig" things got introduced, which is precisely > what made them "special"). Only because it's currently used mostly like this, it doesn't add any "special" meaning. But this will always be true (not just currently): 1. Kconfig symbols will always have code associated with them. That's the entire purpose of Kconfig, is it not? 2. "menuconfig" symbols, otoh, were _invented_ for another reason entirely: presentation and user interface i.e. so that users are able to disable entire menus (and all the options contained therein) without having to enter into the menu first, and without having to disable all options individually (which was the situation that existed before the introduction of these menuconfig objects). The fact that these menuconfig objects are similar to "config symbols" is only because of the way they got implemented, and has nothing to do with their original purpose or the problem they try to solve. Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
Alan Cox <[EMAIL PROTECTED]> writes: >> YH do you think you can look at simply reserving a portion of the iommu? >> And having the kexec on panic kernel use the reserved portion? > > How about simply reserving all of it for the base kernel and using soft > iommu for the panic kernel, its hardly high performance criticial at this > point. The original design came from thinking about systems where using the iommu was mandatory. I think we almost always reserve memory below 1G for the kexec on panic kernel so it really shouldn't be an issue in that case. Except we need to pass an option to force not using the iommu. I don't think noiommu or swiotlb is going to make any real difference. So I'm totally in favor of turning off features if we don't need them and we don't take a tremendous performance hit. (People get grumpy when writing all of memory to disk takes completely unreasonable amounts of time). Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Sat, 23 Jun 2007, Satyam Sharma wrote: > > menuconfig is really a type of config symbol, rather than a type of menu. > > Well, I'd have to disagree here. A config symbol has code associated > with it (at least _all_ config symbols in the kernel originally did, till > when these "menuconfig" things got introduced, which is precisely > what made them "special"). Only because it's currently used mostly like this, it doesn't add any "special" meaning. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] CFS scheduler, -v18
* S.Çağlar Onur <[EMAIL PROTECTED]> wrote: > > kernel/sched.c:745:28: sched_idletask.c: No such file or directory > > Ahh and this happens with [1], grabbing sched_idletask.c from .18 one solves > the problem... oops, indeed - i've fixed up the -git patch: http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-v2.6.22-git-v18.patch Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/6] Convert all tasklets to workqueues
On Fri, 2007-06-22 at 15:09 -0700, [EMAIL PROTECTED] wrote: > On Fri, 22 Jun 2007, Daniel Walker wrote: > > > > > On Fri, 2007-06-22 at 22:40 +0200, Ingo Molnar wrote: > > > >> > >> - tasklets have certain fairness limitations. (they are executed in > >>softirq context and thus preempt everything, even if there is some > >>potentially more important, high-priority task waiting to be > >>executed.) > > > > Since -rt has been executing tasklets in process context for a long > > time, I'm not sure this change would cause to many regressions. However, > > it seems like implicit dependencies on "tasklets preempt everything" > > might crop up. The other issue is if they don't "preempt > > everything" (most of the time), what default priority do we give them > > (all of the time)? It seems like Christoph's suggestion of converting > > all the tasklets individually might be a better option, to deal with > > specific pitfalls. > > that would be the safe way to do it, but it will take a lot of time and a > lot of testing. > > it's probably better to try the big-bang change and only if you see > problames go back and break things down. For testing I'd agree, but not for a kernel that is suppose to be stable. > remember, these changes have been in use in -rt for a while. there's > reason to believe that they aren't going to cause drastic problems. Since I've been working with -rt (~2 years now I think) it's clear that the number of testers of the patch isn't all that high compared to the stable kernel . There are tons of drivers which get no coverage by -rt patch users. So the fact that something similar is in -rt is good, but it's not a silver bullet .. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v18
23 Haz 2007 Cts tarihinde, S.Çağlar Onur şunları yazmıştı:
> Hi Ingo;
>
> 23 Haz 2007 Cts tarihinde, Ingo Molnar şunları yazmıştı:
> > As usual, any sort of feedback, bugreport, fix and suggestion is more
> > than welcome!
>
> [EMAIL PROTECTED] linux-2.6 $ LC_ALL=C make
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALLscripts/checksyscalls.sh
> CHK include/linux/compile.h
> CC kernel/sched.o
> kernel/sched.c:745:28: sched_idletask.c: No such file or directory
Ahh and this happens with [1], grabbing sched_idletask.c from .18 one solves
the problem...
Index: linux/kernel/sched_idletask.c
===
--- /dev/null
+++ linux/kernel/sched_idletask.c
@@ -0,0 +1,68 @@
+/*
+ * idle-task scheduling class.
+ *
+ * (NOTE: these are not related to SCHED_IDLE tasks which are
+ * handled in sched_fair.c)
+ */
+
+/*
+ * Idle tasks are unconditionally rescheduled:
+ */
+static void check_preempt_curr_idle(struct rq *rq, struct task_struct *p)
+{
+ resched_task(rq->idle);
+}
+
+static struct task_struct *pick_next_task_idle(struct rq *rq, u64 now)
+{
+ schedstat_inc(rq, sched_goidle);
+
+ return rq->idle;
+}
+
+/*
+ * It is not legal to sleep in the idle task - print a warning
+ * message if some code attempts to do it:
+ */
+static void
+dequeue_task_idle(struct rq *rq, struct task_struct *p, int sleep, u64 now)
+{
+ spin_unlock_irq(>lock);
+ printk(KERN_ERR "bad: scheduling from the idle thread!\n");
+ dump_stack();
+ spin_lock_irq(>lock);
+}
+
+static void put_prev_task_idle(struct rq *rq, struct task_struct *prev, u64
now)
+{
+}
+
+static struct task_struct *load_balance_start_idle(struct rq *rq)
+{
+ return NULL;
+}
+
+static void task_tick_idle(struct rq *rq, struct task_struct *curr)
+{
+}
+
+/*
+ * Simple, special scheduling class for the per-CPU idle tasks:
+ */
+struct sched_class idle_sched_class __read_mostly = {
+ /* no enqueue/yield_task for idle tasks */
+
+ /* dequeue is not valid, we print a debug message there: */
+ .dequeue_task = dequeue_task_idle,
+
+ .check_preempt_curr = check_preempt_curr_idle,
+
+ .pick_next_task = pick_next_task_idle,
+ .put_prev_task = put_prev_task_idle,
+
+ .load_balance_start = load_balance_start_idle,
+ /* no .load_balance_next for idle tasks */
+
+ .task_tick = task_tick_idle,
+ /* no .task_new for idle tasks */
+};
[1]
http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-v2.6.22-git-v18.patch
Cheers
--
S.Çağlar Onur <[EMAIL PROTECTED]>
http://cekirdek.pardus.org.tr/~caglar/
Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
signature.asc
Description: This is a digitally signed message part.
Re: [RFC PATCH 0/6] Convert all tasklets to workqueues
* Daniel Walker <[EMAIL PROTECTED]> wrote: > > - tasklets have certain fairness limitations. (they are executed in > >softirq context and thus preempt everything, even if there is > >some potentially more important, high-priority task waiting to be > >executed.) > > Since -rt has been executing tasklets in process context for a long > time, I'm not sure this change would cause to many regressions. > However, it seems like implicit dependencies on "tasklets preempt > everything" might crop up. The other issue is if they don't "preempt > everything" (most of the time), what default priority do we give them > (all of the time)? [...] there is no such guarantee at all (of 'instant preemption'), even with current, softirq-based tasklets. A tasklet might be 'stolen' by another CPU. It might be delayed to the next timer tick (or other softirq execution). Or it might be delayed into a ksoftirqd context, which currently runs at nice +19. So your worry of implicit execution dependencies is unfounded, because, if they existed, they would be bad (and triggerable) bugs today too. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
> YH do you think you can look at simply reserving a portion of the iommu? > And having the kexec on panic kernel use the reserved portion? How about simply reserving all of it for the base kernel and using soft iommu for the panic kernel, its hardly high performance criticial at this point. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/6] Convert all tasklets to workqueues
On Fri, 22 Jun 2007, Daniel Walker wrote: On Fri, 2007-06-22 at 22:40 +0200, Ingo Molnar wrote: - tasklets have certain fairness limitations. (they are executed in softirq context and thus preempt everything, even if there is some potentially more important, high-priority task waiting to be executed.) Since -rt has been executing tasklets in process context for a long time, I'm not sure this change would cause to many regressions. However, it seems like implicit dependencies on "tasklets preempt everything" might crop up. The other issue is if they don't "preempt everything" (most of the time), what default priority do we give them (all of the time)? It seems like Christoph's suggestion of converting all the tasklets individually might be a better option, to deal with specific pitfalls. that would be the safe way to do it, but it will take a lot of time and a lot of testing. it's probably better to try the big-bang change and only if you see problames go back and break things down. remember, these changes have been in use in -rt for a while. there's reason to believe that they aren't going to cause drastic problems. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
On Jun 23 2007 02:50, Satyam Sharma wrote: > > Ok, so we add this as solution 2.(c) to the reply I just sent to Jan :-) > > But I still prefer 2.(b) -- making the config scripts intelligent so that if a > given "menuconfig FOO depends on BAR", then all the "config BAZ"s > inside this menuconfig also automatically "depend on" BAR too. > This is simpler in the long run because it requires least amount > (actually none) of redundant typing and would continue to work in > the future if/when the: > > menuconfig FOO > if FOO > ... > endif # FOO > > idiom is converted to an: > > configmenu FOO > ... > endconfigmenu # FOO > > kind of idiom ... Of course *this* *is* *the preferred* thing. (I think even Sam liked that one better than the current menuconfig menuconfig confusion.) But, as always, you need someone to code it, etc. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/6] Convert all tasklets to workqueues
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > [ and on a similar notion, i still havent given up on seeing all BKL > use gone from the kernel. I expect it to happen any decade now ;-) ] 2.6.21 had 476 lock_kernel() calls. 2.6.22-git has 473 lock_kernel() calls currently. With that kind of flux we'll see the BKL gone in about 40 years =B-) 'struct semaphore' use on the other hand has gone down by 10% in this release, which is a good rate. I guess the lack of lockdep coverage for semaphores might be one of the driving forces? ;-) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v18
Hi Ingo; 23 Haz 2007 Cts tarihinde, Ingo Molnar şunları yazmıştı: > As usual, any sort of feedback, bugreport, fix and suggestion is more > than welcome! [EMAIL PROTECTED] linux-2.6 $ LC_ALL=C make CHK include/linux/version.h CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh CHK include/linux/compile.h CC kernel/sched.o kernel/sched.c:745:28: sched_idletask.c: No such file or directory kernel/sched.c: In function `init_idle_bootup_task': kernel/sched.c:4659: error: `idle_sched_class' undeclared (first use in this function) kernel/sched.c:4659: error: (Each undeclared identifier is reported only once kernel/sched.c:4659: error: for each function it appears in.) kernel/sched.c: In function `init_idle': kernel/sched.c:4698: error: `idle_sched_class' undeclared (first use in this function) kernel/sched.c: In function `sched_init': kernel/sched.c:6196: error: `idle_sched_class' undeclared (first use in this function) make[1]: *** [kernel/sched.o] Error 1 make: *** [kernel] Error 2 Cheers -- S.Çağlar Onur <[EMAIL PROTECTED]> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! signature.asc Description: This is a digitally signed message part.
Re: Please release a stable kernel Linux 3.0
On Friday, 22 June 2007 19:11, Chuck Ebbert wrote: > On 06/22/2007 11:00 AM, Rafael J. Wysocki wrote: > > On Friday, 22 June 2007 00:34, Chuck Ebbert wrote: > >> On 06/21/2007 06:29 PM, Jesper Juhl wrote: > >>> I myself have argued that we should be focusing more on stability and > >>> regression fixing, but I'm not so sure that a 2.6.7 devel branch would > >>> solve this. In general the 2.6.x.y -stable kernels seem to be doing > >>> the job pretty good. > >>> > >> > >> Even the good ones that get lots of fixes aren't all that good. The > >> biggest problem ATM is that suspend is badly broken and keeps getting > >> worse... > > > > Can you please provide me with any links to suspend-related bug reports from > > you? > > > > I get so many suspend/resume bug reports that I've given up trying > to get them fixed. And there are so many bugs that are even worse, > like crashes during normal use, data corruption, etc. that suspend > bugs don't get much attention. But here are the ones for Fedora 6; > the list would be much longer if I included Fedora 5 and 7: Well, thanks. I'll have a look at these, perhaps I can figure out which patches are needed to fix them (if there are any). Also, please add my address to the CC lists of any new hibernation/suspend-related bug reports, so that I'm aware of them. FYI, I've started to cherry pick patches related to suspend and hibernation that I think are relevant for each -rc kernel (at http://www.sisk.pl/kernel/hibernation_and_suspend/). [However, I don't backport patches because of the lack of time, so when the next -rc is out, I rediff the patchset against this one and don't add new patches for the previous kernels any more.] There also is the Hibernation/Suspend subcategory in "Power Management" in the kernel bugizlla. Please ask your users to file bug reports in there if that helps. Also, all of the currently tracked (with the bugzilla) problems related to hibernation and suspend are linked to this entry: http://bugzilla.kernel.org/show_bug.cgi?id=7216 Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] CFS scheduler, -v18
i'm pleased to announce release -v18 of the CFS scheduler patchset. The rolled-up CFS patch against today's -git kernel, v2.6.22-rc5, v2.6.22-rc4-mm2, v2.6.21.5 or v2.6.20.14 can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ The biggest change in -v18 are various performance related improvements. Thomas Gleixner has eliminated expensive 64-bit divisions by converting the arithmetics to scaled math (without impacting the quality of calculations). Srivatsa Vaddagiri and Dmitry Adamushko have continued the abstraction and cleanup work. Srivatsa Vaddagiri and Christoph Lameter fixed the NUMA balancing bug reported by Paul McKenney. There were also a good number of other refinements to the CFS code. (No reproducible behavioral regressions were reported against -v17 so far, so the 'behavioral' bits are mostly unchanged.) Changes since -v17: - implement scaled math speedups for CFS. (Thomas Gleixner) - lots of core code updates, cleanups and streamlining. (Srivatsa Vaddagiri, Dmitry Adamushko, me.) - bugfix: fix NUMA balancing. (Srivatsa Vaddagiri, Christoph Lameter, Paul E. McKenney) - feature: SCHED_IDLE now also implies block-scheduler (CFQ) idle-IO-priority. (suggested by Thomas Sattler, picked up from -ck) - build fix for ppc32. (reported, tested and confirmed fixed by Art Haas) - ARM fix. (reported and debugged by Thomas Gleixner) - cleanup: implemented idle_sched_class in kernel/sched_idletask.c as a way to separate out rq->idle handling out of the core scheduler. This made a good deal of idle-task related special-cases go away. - debug: make the sysctls safer by introducing high and low limits. - cleanup: move some of the debug counters to under CONFIG_SCHEDSTATS. - speedup: various micro-optimizations - various other small updates. As usual, any sort of feedback, bugreport, fix and suggestion is more than welcome! Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/6] Convert all tasklets to workqueues
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > If the numbers say that there is no performance difference (or even > better: that the new code performs better or fixes some latency issue > or whatever), I'll be very happy. But if the numbers say that it's > worse, no amount of cleanliness really changes that. Most of the tasklet uses are in rarely used or arcane drivers - in fact none of my 10 test-boxes utilizes _any_ tasklet in any way that could even get close to mattering to performance. In other words: i just cannot test this, nor do i think that others will really test this. I.e. if we dont approach this problem in some other way, nothing will happen and Steve's patch will be stalled forever and will live in -rt forever. (which might be a correct end result too, but i'm just not giving up this easily :-) so how about the following, different approach: anyone who has a tasklet in any performance-sensitive codepath, please yell now. We'll also do a proactive search for such places. We can convert those places to softirqs, or move them back into hardirq context. Once this is done - and i doubt it will go beyond 1-2 places - we can just mass-convert the other 110 places to the lame but compatible solution of doing them in a global thread context. [ and on a similar notion, i still havent given up on seeing all BKL use gone from the kernel. I expect it to happen any decade now ;-) ] Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
On 6/22/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote: Alan Cox <[EMAIL PROTECTED]> writes: For a normal kexec we should shut everything down before the kernel transition so it should not be an issue. YH do you think you can look at simply reserving a portion of the iommu? And having the kexec on panic kernel use the reserved portion? two copy region: one for first kernel, and one for second kernel? it should work. first kernel is using [64M, 128M), and the second will get assign to [64M,128M) again. when it try to memset to clear that region it will cause restart. in that region, only first 256K can not touched, even read. rest could be accessed. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi Roman, On 6/23/07, Roman Zippel <[EMAIL PROTECTED]> wrote: Hi, On Sat, 23 Jun 2007, Satyam Sharma wrote: > given "menuconfig FOO depends on BAR", then all the "config BAZ"s > inside this menuconfig also automatically "depend on" BAR too. > This is simpler in the long run because it requires least amount > (actually none) of redundant typing I don't like this, as this would attach special meaning to a menuconfig. But "menuconfig" _is_ special ... menuconfig is really a type of config symbol, rather than a type of menu. Well, I'd have to disagree here. A config symbol has code associated with it (at least _all_ config symbols in the kernel originally did, till when these "menuconfig" things got introduced, which is precisely what made them "special"). These "menuconfig" things are (or were supposed to be, at least :-) just a _presentation_ thing. Potentially this could also be written as: config FOO option menu ... I'm not sure why anybody would prefer such a syntax / idiom. I know that "de gustibus non est disputandum", but personally I find such usage *horribly* unclear. Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/6] Convert all tasklets to workqueues
On Fri, 2007-06-22 at 22:40 +0200, Ingo Molnar wrote: > > - tasklets have certain fairness limitations. (they are executed in >softirq context and thus preempt everything, even if there is some >potentially more important, high-priority task waiting to be >executed.) Since -rt has been executing tasklets in process context for a long time, I'm not sure this change would cause to many regressions. However, it seems like implicit dependencies on "tasklets preempt everything" might crop up. The other issue is if they don't "preempt everything" (most of the time), what default priority do we give them (all of the time)? It seems like Christoph's suggestion of converting all the tasklets individually might be a better option, to deal with specific pitfalls. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA RAID5 speed drop of 100 MB/s
The dmesg output of 33480a0ede8dcc7e6483054279008f972bd56fd3 (thus "before") is: == Linux version 2.6.20-rc1-bisect-33480a0ede8dcc7e6483054279008f972bd56fd3-amd64 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Jun 22 22:13:01 CEST 2007 Command line: root=/dev/md2 ro agp=off single BIOS-provided physical RAM map: BIOS-e820: - 0009ec00 (usable) BIOS-e820: 0009ec00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 7ff9 (usable) BIOS-e820: 7ff9 - 7ff9e000 (ACPI data) BIOS-e820: 7ff9e000 - 7ffe (ACPI NVS) BIOS-e820: 7ffe - 8000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) BIOS-e820: 0001 - 00018000 (usable) Entering add_active_range(0, 0, 158) 0 entries of 3200 used Entering add_active_range(0, 256, 524176) 1 entries of 3200 used Entering add_active_range(0, 1048576, 1572864) 2 entries of 3200 used end_pfn_map = 1572864 DMI 2.4 present. ACPI: RSDP (v002 ACPIAM) @ 0x000fae40 ACPI: XSDT (v001 ÿÿ 0x03000709 MSFT 0x0097) @ 0x7ff90100 ACPI: FADT (v003 MSTEST OEMFACP 0x03000709 MSFT 0x0097) @ 0x7ff90290 ACPI: MADT (v001 MSTEST OEMAPIC 0x03000709 MSFT 0x0097) @ 0x7ff90390 ACPI: MCFG (v001 MSTEST OEMMCFG 0x03000709 MSFT 0x0097) @ 0x7ff90400 ACPI: SLIC (v001 ÿÿ 0x03000709 MSFT 0x0097) @ 0x7ff90440 ACPI: OEMB (v001 MSTEST AMI_OEM 0x03000709 MSFT 0x0097) @ 0x7ff9e040 ACPI: HPET (v001 MSTEST OEMHPET 0x03000709 MSFT 0x0097) @ 0x7ff99440 ACPI: DSDT (v001 A0483 A0483035 0x0035 INTL 0x20060113) @ 0x No NUMA configuration found Faking a node at -00018000 Entering add_active_range(0, 0, 158) 0 entries of 3200 used Entering add_active_range(0, 256, 524176) 1 entries of 3200 used Entering add_active_range(0, 1048576, 1572864) 2 entries of 3200 used Bootmem setup node 0 -00018000 Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1572864 early_node_map[3] active PFN ranges 0:0 -> 158 0: 256 -> 524176 0: 1048576 -> 1572864 On node 0 totalpages: 1048366 DMA zone: 56 pages used for memmap DMA zone: 972 pages reserved DMA zone: 2970 pages, LIFO batch:0 DMA32 zone: 14280 pages used for memmap DMA32 zone: 505800 pages, LIFO batch:31 Normal zone: 7168 pages used for memmap Normal zone: 517120 pages, LIFO batch:31 ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) Processor #2 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) Processor #3 ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 4, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to physical flat ACPI: HPET id: 0x8086a202 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Nosave address range: 0009e000 - 0009f000 Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000e4000 Nosave address range: 000e4000 - 0010 Nosave address range: 7ff9 - 7ff9e000 Nosave address range: 7ff9e000 - 7ffe Nosave address range: 7ffe - 8000 Nosave address range: 8000 - fee0 Nosave address range: fee0 - fee01000 Nosave address range: fee01000 - ffb0 Nosave address range: ffb0 - 0001 Allocating PCI resources starting at 8800 (gap: 8000:7ee0) SMP: Allowing 4 CPUs, 0 hotplug CPUs PERCPU: Allocating 36992 bytes of per cpu data Built 1 zonelists. Total pages: 1025890 Kernel command line: root=/dev/md2 ro agp=off single Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Checking aperture... Calgary: Unable to locate Rio Grande Table in EBDA - bailing! PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Placing software IO TLB between 0x1655000 - 0x5655000 Memory: 4024892k/6291456k available (1963k kernel
Re: Rules on how to use sysfs in userspace programs
On Friday 08 June 2007 16:36:37 Greg KH wrote: > Over time there have been a number of problems when sysfs has changed in > "unexpected" ways. Here's a document that Kay wrote a while ago that > I'd like to add to the kernel Documentation directory to help userspace > programmers out. > > Any comments or critique of this is greatly appreciated. Still catching up from my laptop dying. I find the explanation of /sys/subsystem almost unintelligible. What will the new one actually look like? If I want to find all block devices in the system, it looks like I should now look at /sys/subsystem/block. (And "subsystem" is not a variable here but the actual directory name? I presume it moved for Feng Shui reasons.) If I want to find char devices, where do I look? /sys/subsystem... char? class? Is a char device now anything under /sys/subsystem that is _not_ in /sys/subsystem/block? (Minus bus devices?) Is there a specific directory for these? This document is highly polluted with what NOT to do. I'm looking for a clear "what SHOULD I do", and it takes some wading to find it. (Historical cruft about what not to do is potentially a separate document, it's not useful for people learning this stuff now who weren't playing with the legacy mechanisms.) The description of /sys/subsystem spends so much time talking about old legacy issues it never gives a clear description of the new way of doing things, which is theoretically what this document is about... Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
On Fri, Jun 22, 2007 at 03:32:53PM -0600, Eric W. Biederman wrote: > Alan Cox <[EMAIL PROTECTED]> writes: > > > You've got mapped live gart pages from the previous kernel. Even > > if you disable the gart before a memset you may well have the > > video card using gart translations and possibly live IOMMU > > mappings for devices using it via bus mastering - and those will > > cause you MCE exceptions with a corrupt cpu context flag (ie not > > nicely recoverable). > > The original plan (which we have not followed up on). Was to > reserve a chunk of any iommu for the kexec on panic kernel. Then to > just have the second kernel use that unused chunk. This is how we > treat the normal memory space and it seems a nice and simple > approach to this kind of problem. > > For a normal kexec we should shut everything down before the kernel > transition so it should not be an issue. > > YH do you think you can look at simply reserving a portion of the > iommu? And having the kexec on panic kernel use the reserved > portion? How would this work with an isolation capable IOMMU which has different address spaces for different devices? (e.g., Calgary which is in mainline, Intel's VT-d which is coming soon, etc). Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Cpuidle task list
Sorry about the noise. Below mail came here by mistake.. Thanks, Venki >-Original Message- >From: Pallipadi, Venkatesh >Sent: Friday, June 22, 2007 2:45 PM >To: LKML >Subject: RE: Cpuidle task list > > >I sent a mail to Adam to look at these... >Max_cstate is what I observed once. I don't have more data. >Sysfs output issue has below details. About the third wraparound issue >Adam knows the bug and can probably fix it faster. > >Thanks, >Venki > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Sat, 23 Jun 2007, Satyam Sharma wrote: > given "menuconfig FOO depends on BAR", then all the "config BAZ"s > inside this menuconfig also automatically "depend on" BAR too. > This is simpler in the long run because it requires least amount > (actually none) of redundant typing I don't like this, as this would attach special meaning to a menuconfig. menuconfig is really a type of config symbol, rather than a type of menu. Potentially this could also be written as: config FOO option menu ... bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Cpuidle task list
I sent a mail to Adam to look at these... Max_cstate is what I observed once. I don't have more data. Sysfs output issue has below details. About the third wraparound issue Adam knows the bug and can probably fix it faster. Thanks, Venki -Original Message- From: Li, Shaohua Sent: Tuesday, June 19, 2007 12:30 AM To: Pallipadi, Venkatesh Subject: RE: Cpuidle task list I didn't follow cpuidle issue closely recently, are there links for below issues? >-Original Message- >From: Pallipadi, Venkatesh >Sent: Tuesday, June 19, 2007 9:12 AM >To: Li, Shaohua >Subject: Cpuidle task list > > >I could not call you today. Will try to do it tomorrow morning your time. > >Here are the cpuidle stuff that needs fixing: > >1) /sys output issues like one below. > >2) echo 1 > /sys/.../max_cstate hangs by system > >3) bm logic is wrapping around in the latest version of menu governor. Adam >said he will fix it earlier, but I haven't seen any patches from him yet. > >Thanks, >Venki > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Monday, June 18, 2007 1:07 PM >To: Thomas Gleixner >Cc: LKML; Andrew Morton; Ingo Molnar; Andi Kleen; Chris Wright; Arjan van >de Ven; Pallipadi, Venkatesh >Subject: Re: [patch-mm 00/25] High resolution timer updates and x86_64 >support - V2 > >On Sat, 16 Jun 2007 10:36:00 -, Thomas Gleixner said: >> The following patch series contains: >> >> - dyntick bugfixes for -mm (caused by the cpuidle changes in ACPI) >> >> - updates and improvements to high resolution timer / dynticks >> >> - high resolution timer / dynticks support for x86_64 > >Am running with the 22-rc4-mm2-hrt4 patch on my Latitude D820. Mostly >seems >to work, but for some reason the Intel 'powertop' util thinks it's 100% >busy: > > PowerTOP version 1.7 (C) 2007 Intel Corporation > >Cn Avg residency (5s) P-states (frequencies) >C0 (cpu running)(100.0%) >C10.0ms ( 0.0%) 2.00 Ghz 0.0% >C20.0ms ( 0.0%) 1.67 Ghz 0.0% >C30.0ms ( 0.0%) 1333 Mhz 0.0% >1000 Mhz 100.0% > >In reality: > >[/sys/devices/system/cpu/cpu0/cpuidle] for i in */*; do echo -n "$i: "; cat >$i; done >state0/latency: 1 >state0/power: 1000 >state0/time: 0 >state0/usage: 3 >state1/latency: 1 >state1/power: 500 >state1/time: 1756017623 >state1/usage: 1837402 >state2/latency: 57 >state2/power: 100 >state2/time: -159524787 >state2/usage: 15007443 > >I think we have a 32/64 bit issue on state2/time which is probably borking >things up - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
Andi Kleen <[EMAIL PROTECTED]> writes: > On Friday 22 June 2007 22:33, Alan Cox wrote: >> You've got mapped live gart pages from the previous kernel. Even if you >> disable the gart before a memset > > It's probably too late then. It could also interfere with other operations. > If anything the GART should be disabled during kexec shutdown. Perhaps we > just > need a suitable suspend function that does that. Eric, any preferences? Well it would be a shutdown method not a suspend method. The authors of the suspend code thought sharing code with the reboot and the rmmod case didn't make sense. For a normal kexec into another kernel I think this makes sense. >> you may well have the video card using >> gart translations and possibly live IOMMU mappings for devices using it >> via bus mastering - and those will cause you MCE exceptions with a >> corrupt cpu context flag (ie not nicely recoverable). > > We disable those machine checks on K8 because they're not fully reliable. For the kexec on panic not shutting the hardware down if at all possible is the ideal. There I think we need a mode to not touch a chunk of the iommu and reserve it for the kexec on panic kernel (or perhaps just use the swiotlb code if we need bounce buffers at all). Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [RC][PATCH -mm] PM: Prevent frozen user mode helpers from failing the freezing of tasks
On Friday, 22 June 2007 23:07, Pavel Machek wrote:
> Hi!
>
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > At present, if a user mode helper is running while
> > usermodehelper_pm_callback()
> > is executed, the helper may be frozen and the completion in
> > call_usermodehelper_exec() won't be completed until user space processes are
> > thawed. As a result, the freezing of kernel threads may fail, which is not
> > desirable.
> >
> > Prevent this from happening by introducing a counter of running user mode
> > helpers and allowing usermodehelper_pm_callback() to succeed for
> > action = PM_HIBERNATION_PREPARE or action = PM_SUSPEND_PREPARE only if there
> > are no helpers running. [Namely, usermodehelper_pm_callback() waits for at
> > most
> > RUNNING_HELPERS_TIMEOUT for the number of running helpers to become zero and
> > fails if that doesn't happen.]
> >
> > Special thanks to Uli Luckas <[EMAIL PROTECTED]> for reviewing the previous
> > versions of this patch and for very useful comments.
> ...
> > Reviewed-by: Pavel Machek <[EMAIL PROTECTED]>
>
> Eh, not sure this header is worth anything. Sometimes I'm lazy and
> stop when I see first problem.
>
> > switch (action) {
> > case PM_HIBERNATION_PREPARE:
> > case PM_SUSPEND_PREPARE:
> > usermodehelper_disabled = 1;
> > - return NOTIFY_OK;
> > + retval = wait_event_timeout(running_helpers_waitq,
> > + atomic_read(_helpers) == 0,
>
> Are you sure here? What happens when atomic variable changes between
> the atomic_read and the function call?
Er, this is a macro. :-)
In fact we rely only on atomic_read(_helpers) being still zero after
helper_finished() has woken us up, but I think that's acceptable.
IOW, if the wait_event_timeout() returns with retval different from zero, this
means that atomic_read(_helpers) returned zero at one point after
we'd set usermodehelper_disabled, which is enough. OTOH, if it doesn't
return with retval different from zero, this means that either one or more
helpers are waited for to finish or they are coming and going very quickly,
which would be suspicious enough to cancel the suspend, IMHO.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[BUG] Linux 2.6.21.5 - Radeon NMI lockup
Hi, I experienced this BUG while playing World of Warcraft with a Radeon 9200 AGPx8 video card and FC7: BUG: NMI Watchdog detected LOCKUP on CPU3, eip c019f98f, registers: Modules linked in: snd_rtctimer snd_seq_midi radeon drm cpufreq_ondemand p4_clockmod speedstep_lib nfsd exportfs autofs4 eeprom nfs lockd sunrpc af_packet ipv6 binfmt_misc video1394 raw1394 eth1394 thermal processor fan button ac lp nvram loop snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 firmware_class snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_usb_audio snd_pcm_oss snd_mixer_oss snd_usb_lib pwc snd_pcm snd_rawmidi snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep compat_ioctl32 snd e7xxx_edac videodev ohci1394 v4l2_common edac_mc v4l1_compat ieee1394 serio_raw e1000 i2c_i801 parport_pc soundcore pcspkr sata_sil psmouse parport intel_agp agpgart i2c_core sr_mod cdrom sg dm_snapshot dm_zero dm_mirror dm_mod ata_piix libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd usbcore CPU:3 EIP:0060:[]Not tainted VLI EFLAGS: 00200297 (2.6.21.5 #1) EIP is at delay_tsc+0xb/0x13 eax: 0487b218 ebx: 0a4e ecx: 0487ab54 edx: 2707 esi: 0080 edi: 00484af1 ebp: esp: ce02bea8 ds: 007b es: 007b fs: 00d8 gs: 003b ss: 0068 Process WoW.exe (pid: 4977, ti=ce02b000 task=f7fd8070 task.ti=ce02b000) Stack: f7b506c8 c019f9c0 f8e2d6c7 0001 ce02bee0 f5a4c0ec 1fdb f5a4c0ec f6d4d578 f8e2edf4 0182 c02c58ac ce02bf28 c0336120 0003 ed06ff24 0003 Call Trace: [] __delay+0x6/0x7 [] radeon_freelist_get+0xde/0x11d [radeon] [] radeon_cp_buffers+0xff/0x17c [radeon] [] radeon_cp_buffers+0x0/0x17c [radeon] [] drm_ioctl+0x146/0x18f [drm] [] do_ioctl+0x4c/0x62 [] vfs_ioctl+0x23f/0x251 [] sys_ioctl+0x33/0x4d [] sysenter_past_esp+0x5f/0x85 [] cookie_v4_check+0x19a/0x3d3 === Code: 26 00 00 00 00 8d bc 27 00 00 00 00 eb 0e 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 48 79 fd c3 53 89 c3 0f 31 89 c1 f3 90 0f 31 <29> c8 39 d8 72 f6 5b c3 c7 05 6c d1 2c c0 84 f9 19 c0 c3 89 c1 Cheers, Chris ___ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/6] Convert all tasklets to workqueues
On Fri, 22 Jun 2007, Ingo Molnar wrote: > > * Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > Whether we actually then want to do 6 is another matter. I think we'd > > need some measuring and discussion about that. > > basically tasklets have a number of limitations: I'm not disputing that they aren't pretty. But none of your arguments really touch on the deeper issue: - Is the new code *technically*better*? Don't get me wrong. I like cleanups as much as the next guy. I have no problem at all with the first four patches in the series, because those are cleanups that have no technical impact apart from that "cleanup-ness". The reason I ask about patch #6 is simply that in the end "clean code" matters less than "good results". I'm a _huge_ believer in "clean code", but the fact is, I'm an even bigger believer in "reality bites". I'd really like to see some numbers. If the numbers say that there is no performance difference (or even better: that the new code performs better or fixes some latency issue or whatever), I'll be very happy. But if the numbers say that it's worse, no amount of cleanliness really changes that. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
Andi Kleen wrote: It's probably too late then. It could also interfere with other operations. If anything the GART should be disabled during kexec shutdown. Perhaps we just need a suitable suspend function that does that. Eric, any preferences? how about kdump? do we have chance to call that suspend func? YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
Alan Cox <[EMAIL PROTECTED]> writes: > You've got mapped live gart pages from the previous kernel. Even if you > disable the gart before a memset you may well have the video card using > gart translations and possibly live IOMMU mappings for devices using it > via bus mastering - and those will cause you MCE exceptions with a > corrupt cpu context flag (ie not nicely recoverable). The original plan (which we have not followed up on). Was to reserve a chunk of any iommu for the kexec on panic kernel. Then to just have the second kernel use that unused chunk. This is how we treat the normal memory space and it seems a nice and simple approach to this kind of problem. For a normal kexec we should shut everything down before the kernel transition so it should not be an issue. YH do you think you can look at simply reserving a portion of the iommu? And having the kexec on panic kernel use the reserved portion? Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART before allocate aperture
On Friday 22 June 2007 22:33, Alan Cox wrote: > On Fri, 22 Jun 2007 12:31:24 -0700 > > Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 22, 2007 at 12:19:15PM -0700, Yinghai Lu wrote: > > > [PATCH] x86-64: disable the GART before allocate aperture > > > > > > For K8 system: 4G RAM with memory hole remapping enabled, or more > > > than 4G RAM installed. when mem is allocated for GART, it will do > > > the memset for clear. and for kexec case, the first kernel already > > > enable that, the memset in second kernel will cause the system > > > restart. So disable that at first before we try to allocate mem for > > > it. > > > > Why does the memset in the second kernel cause a system restart? > > You've got mapped live gart pages from the previous kernel. Even if you > disable the gart before a memset It's probably too late then. It could also interfere with other operations. If anything the GART should be disabled during kexec shutdown. Perhaps we just need a suitable suspend function that does that. Eric, any preferences? > you may well have the video card using > gart translations and possibly live IOMMU mappings for devices using it > via bus mastering - and those will cause you MCE exceptions with a > corrupt cpu context flag (ie not nicely recoverable). We disable those machine checks on K8 because they're not fully reliable. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] doc/oops-tracing: add Code: decode info
> Why 3 times? Why not just (1) everything before marker and > (2) everything at and after marker? 2 times would probably work too, i was just thinking of a marker around it; but you're right just before would be also ok. > > - It won't handle multiline Code:s which i386 likes to generate now I > > think > > I don't see the code in arch/i386/kernel/traps.c generating multiline > Code:s, just very long single lines. Yes I must have mislooked. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?
> > It's this simple, those who chose the GPLv2 for Linux and their > > contributions to it don't want people to create derivative > > works of their > > works that can't be Tivoized. They see this as a feature, and it's the > Untrue. Many of us think (and the lawyers are unsure) that it is covered > by GPLv2 anyway. Some drivers actually make this clear in their comments > about intepretation I didn't mean to speak for every single contributor to Linux. I apologize if I gave that impression. Lawyers are almost always unsure of things that aren't well-settled. It's practically a job requirement. However, I think that view is so incredibly bizarre that I can't imagine anyone taking it seriously. Not even the FSF agrees with it, and they have taken insanely expansive views of the scope of the GPL. If the GPLv2 says you can't Tivoize, then Linus is violating the GPL by withholding the keys he uses to sign the Linux kernel source release. No rational argument would defend one point and not the other (unless you add crazy ad-hocery with no support in law or common sense). If you are one of those people, please be consistent and condemn Linus' refusal to release his signing keys and thus "Tivoizing" the Linux kernel. Don't even try to make some kind of counter-argument about signatures that are or aren't functional. Functionality would *exempt* things from copyright coverage, not subject them to it. (And Linus' signature *is* functional. People use it to decide whether or not to run the code. It serves no other purpose than that. Some people will only run kernel code signed by Linus, and my not having his signing key means that my changes can't be run on machines controlled by those people.) DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI Regression on Dell E1501
Tim Gardner <[EMAIL PROTECTED]> writes: > Thomas Renninger wrote: >> On Fri, 2007-06-22 at 07:18 -0600, Tim Gardner wrote: >>> Tim Gardner wrote: Thomas Gleixner wrote: > On Thu, 2007-06-21 at 17:47 -0400, Chuck Ebbert wrote: >> On 06/21/2007 05:04 PM, Tim Gardner wrote: >>> Hi, >>> >>> Commit e9e2cdb412412326c4827fc78ba27f410d837e6e breaks boot on a Dell >>> E1501 unless 'acpi=off' is specified (also tried nolapic and nohpet but >>> it made no substantive difference). This laptop is an 'AMD Turion(tm) 64 >>> X2 Mobile Technology TL-50' CPU, but its booting 32 bit SMP (make >>> defconfig). No kernel built after this commit works for this platform. >>> >>> There is no crash output, it just wedges after 'NET: Registered protocol >>> family 2'. >>> >>> How can I debug this problem? >> That'll be fun. >> >> That's: >> >> [PATCH] clockevents: i386 drivers >> >> [Author cc: added] > I'm going nuts on this. > > Tim, > > 1.) are you booting a 32bit or a 64 bit kernel ? > > 2.) Can you please try 2.6.22-rc5 + > http://www.tglx.de/projects/hrtimers/2.6.22-rc5/patch-2.6.22-rc5-hrt1.patch > whether this makes any difference > > Thanks, > > tglx > Thomas, Your patch (large though it is) did not make any outward difference. As usual, adding 'acpi=off' allows it to boot. rtg >>> Perhaps I was too hasty. Adding 'acpi=off' did not allow it to boot. The >>> IDE drive was detected, but I did not see any partitions detected. >>> Eventually it dropped to the initrd shell when it could not find a root >>> filesystem. Anyways, this is likely a side issue. >> >> I am seeing the same with an ACER F5000. >> >> pci=nomsi let the machine still boot. >> >> I tried a bit and I think I got it, for me it's this one: >> >> commit 78b7611c4a1e3ff008abc4751b566cb533d68f3d >> Author: Eric W. Biederman <[EMAIL PROTECTED]> >> Date: Fri Jun 1 00:46:33 2007 -0700 >> >> My problem: The laptop does not have an serial output device, I try to >> set up a fire wire console, but might have cable/HW problems. >> >> What else can I do to help? >> What do you need? >> >> Thanks, >> >>Thomas >> > > pci=nomsi has no effect, nor does CONFIG_SMP. Furthermore, I positively > confirmed that this is the offending commit. If I reset HEAD to the > commit just prior, then everything works OK. To confirm you commit: e9e2cdb412412326c4827fc78ba27f410d837e6e "[PATCH] clockevents: i386 drivers" is the problem commit you are referring to. Thomas suggested a different commit else having to do with MSI... I'm just trying to keep the conversation straight. Thanks, Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA Harddisk speed drop of 100 MB/s
On Fri, Jun 22, 2007 at 06:17:46PM -0300, Henrique de Moraes Holschuh wrote: > On Fri, 22 Jun 2007, Carlo Wood wrote: > > So far I found out that it's RAID only. > > If you change the IO schedulers, does it help? How do I do that? -- Carlo Wood <[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: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi Trent, On 6/23/07, Trent Piepho <[EMAIL PROTECTED]> wrote: [...] What you have is tristate depends on bool depends on tristate. The bool between the two tristates "promotes" the first tristate from m to y. [...] Or another way, add the dependencies of the menuconfig to the if statement: diff -r dfbe7cc4e21e drivers/media/video/Kconfig --- a/drivers/media/video/Kconfig Thu Jun 21 16:02:50 2007 -0700 +++ b/drivers/media/video/Kconfig Fri Jun 22 13:10:43 2007 -0700 @@ -691,7 +691,7 @@ menuconfig V4L_USB_DRIVERS depends on USB default y -if V4L_USB_DRIVERS +if V4L_USB_DRIVERS && USB source "drivers/media/video/pvrusb2/Kconfig" Now all the usb drivers will gain USB as a dependency directly and can't be set to something higher than USB. Ok, so we add this as solution 2.(c) to the reply I just sent to Jan :-) But I still prefer 2.(b) -- making the config scripts intelligent so that if a given "menuconfig FOO depends on BAR", then all the "config BAZ"s inside this menuconfig also automatically "depend on" BAR too. This is simpler in the long run because it requires least amount (actually none) of redundant typing and would continue to work in the future if/when the: menuconfig FOO if FOO ... endif # FOO idiom is converted to an: configmenu FOO ... endconfigmenu # FOO kind of idiom ... Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
