Re: [2.6 patch] x86: make dump_pagetable() static
Adrian Bunk wrote: > On Wed, Feb 13, 2008 at 02:27:47PM -0800, Harvey Harrison wrote: >> On Wed, 2008-02-13 at 23:31 +0200, Adrian Bunk wrote: >>> dump_pagetable() can now become static. >>> >>> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> >>> >> I believe Andi Kleen wanted this kept global to make it easy to use when >> adding debugging code elsewhere. > > That's not a reason as long as his code isn't in the tree (and he anyway > has to patch the kernel for using it). It was originally needed for the old cpa patchkit which dumped the page tables when it detected an internal inconsistency with the reference counts. I think something like this would still make sense in a few cases, although there are no reference counts to check anymore currently. -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: 2.6.25-rc1 xen pvops regression
Joel Becker wrote: On Wed, Feb 13, 2008 at 10:59:33PM +1100, Jeremy Fitzhardinge wrote: I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day. Unfortunately, I didn't get very far very fast, as the domain just crashed immediately upon booting, without any direct feedback (I did have messages on the xen message buffer, which helped). This even with earlyprintk turned on. After a long, arduous journey, I managed to track this down to the following: -- commit 551889a6e2a24a9c06fd453ea03b57b7746ffdc0 I'm seeing the same problem, with no messages at all from xen other than "domain crashed, restart disabled" in xend.log. I got a different commit in my bisect, 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395 (i386 boot: replace boot_ioremap with enhanced bt_ioremap - enhance bt_ioremap). I started from yesterday's 96b5a46e2a72dc1829370c87053e0cd558d58bc0 (WMI: initialize wmi_blocks.list even if ACPI is disabled) and a known good 9b73e76f3cf63379dcf45fcd4f112f5812418d0a (Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6). Although I'm on vacation, I happened to download a recent copy of x86.git and found that it crashes early. Here's a couple of patches to apply; I don't know if they apply to current git, but I hope it helps. Subject: x86/early_ioremap: don't assume we're using swapper_pg_dir Subject: xen: unpin initial Xen pagetable once we're finished with it After my bisect was done, I re-pulled from Linus and discovered these patches. Searching for these emails, they certainly sound like my problem. But the kernel does not boot, commit 10270d4838bdc493781f5a1cf2e90e9c34c9142f (acpi: fix acpi_os_read_pci_configuration() misuse of raw_pci_read()). Still no output from Xen - pygrub selects the kernel, and then the domain just dies back to the dom0 shell. Attached are my latest .config and my bisect log. Is the domain ending up in the crashed state? Do you get a register dump with xm dmesg? That would be very useful in determining what went wrong. You may need to compile Xen with debug=y in Config.mk. J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] make mtd/nand/cs553x_nand.c:part_probes[] static
Ühel kenal päeval, K, 2008-02-13 kell 23:30, kirjutas Adrian Bunk: > This patch makes the needlessly global part_probes[] static. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Acked-by: Mart Raudsepp <[EMAIL PROTECTED]> Note that many other drivers in mtd/nand have the same part_probes array global instead of static. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stuck with 2.6.23.14 on x86_64
Alle mercoledì 13 febbraio 2008, Andrew Morton ha scritto: > > > Hardware: x86_64 AMD 2216HE > > > SCSI controller: HP Smart Array E200i Controller > > > Compiler: gcc (GCC) 4.1.1 > > > binutils: 2.16.1 > > > > > > On a x86 machine, Intel(R) Xeon(TM) CPU 3.20GHz > > > with a cciss0: HP Smart Array 6i Controller, > > > the 2.6.24.2 compiles just fine and works, so the cciss problems seems > > > related only to E200i controller. > > Fabio, Can you please post your boot messages in bug 9859. > > Let's cc him.. No problem, I'm subscribed to the list so I've already posted boot messages; thanks anyway :) -- Fabio "Cova" Coattihttp://members.ferrara.linux.it/cova Ferrara Linux Users Group http://ferrara.linux.it GnuPG fp:9765 A5B6 6843 17BC A646 BE8C FA56 373A 5374 C703 Old SysOps never die... they simply forget their password. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL?] Create and populate toplevel tests/ for kernel tests
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> {kernel => tests}/backtracetest.c |0
> {drivers/misc => tests}/lkdtm.c | 12 ++--
> {lib => tests}/locking-selftest-hardirq.h |0
> {lib => tests}/locking-selftest-mutex.h |0
> {lib => tests}/locking-selftest-rlock-hardirq.h |0
> {lib => tests}/locking-selftest-rlock-softirq.h |0
> {lib => tests}/locking-selftest-rlock.h |0
> {lib => tests}/locking-selftest-rsem.h |0
> {lib => tests}/locking-selftest-softirq.h |0
> {lib => tests}/locking-selftest-spin-hardirq.h |0
> {lib => tests}/locking-selftest-spin-softirq.h |0
> {lib => tests}/locking-selftest-spin.h |0
> {lib => tests}/locking-selftest-wlock-hardirq.h |0
> {lib => tests}/locking-selftest-wlock-softirq.h |0
> {lib => tests}/locking-selftest-wlock.h |0
> {lib => tests}/locking-selftest-wsem.h |0
> {lib => tests}/locking-selftest.c |0
> {kernel => tests}/rcutorture.c |0
> {kernel => tests}/rtmutex-tester.c |2 +-
> {kernel => tests}/test_kprobes.c|0
> 27 files changed, 99 insertions(+), 82 deletions(-)
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
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: [discuss] pci_get_device_reverse(), why does Calgary need this?
Greg KH <[EMAIL PROTECTED]> writes: > How does the patch below look? I didn't want to remove the whole config > option, as there is more to the logic than just the "reverse order" > stuff there. I think you miss Documentation - it's mentioned in ide.txt and kernel-parameters.txt, Andreas -- Andreas Jaeger, Director Platform / openSUSE, [EMAIL PROTECTED] SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpnl8pXxObM5.pgp Description: PGP signature
Re: vmsplice exploits, stack protector and Makefiles
> --- linux-2.6.24.2/arch/x86/kernel/Makefile_642008-01-24 > 23:58:37.0 > +0100 > +++ linux-2.6.24.2-pax/arch/x86/kernel/Makefile_642008-02-13 > 11:36:14.0 +0100 > @@ -42,4 +42,6 @@ obj-$(CONFIG_PCI) += early-quirks.o > obj-y+= topology.o > obj-y+= pcspeaker.o > > -CFLAGS_vsyscall_64.o := $(PROFILING) -g0 > +CFLAGS_vsyscall_64.o := $(PROFILING) -g0 -fno-stack-protector > +CFLAGS_hpet.o:= -fno-stack-protector > +CFLAGS_tsc_64.o := -fno-stack-protector We should use: nostackp := $(call cc-option, -fno-stack-protector) +CFLAGS_vsyscall_64.o := $(PROFILING) -g0 $(nostackp) +CFLAGS_hpet.o := $(nostackp) +CFLAGS_tsc_64.o:= $(nostackp) (or somthing similar) because we cannot rely on that all gcc versions has support for -fno-stack-protector Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1: volanoMark 45% regression
On Wed, 2008-02-13 at 17:37 +0530, Srivatsa Vaddagiri wrote: > On Wed, Feb 13, 2008 at 03:15:16PM +0530, Balbir Singh wrote: > > Zhang, Yanmin wrote: > > > volanoMark has 45% regression with kernel 2.6.25-rc1 on my both 8-core > > > stoakley and 16-core Tigerton. > > > > > > I used bisect to locate below patch. > > > > > > commit 58e2d4ca581167c2a079f4ee02be2f0bc52e8729 > > > Author: Srivatsa Vaddagiri <[EMAIL PROTECTED]> > > > Date: Fri Jan 25 21:08:00 2008 +0100 > > > > > > sched: group scheduling, change how cpu load is calculated > > > > > > > > > > > > hackbench has about 30% regression on 16-core tigerton, but has about 10% > > > improvement > > > on 8-core stoakley. > > > > > > In addition, tbench has about 6% regression on my 8-core stoakley and > > > 25% regression on 16-core stoakley. I verified tbench regression is not caused by the same patch. I am digging tbench now. > Some other benchmarks, like netperf/aim7 > > > also have some regression. I will verify if they are all related to the > > > patch. > > > > > > -yanmin > > > > Hi, Yamin, > > > > Thanks for reporting the issue? Any chance we could getthe Oprofile output > > for > > the run? I got oprofile data but it didn't show clear evidence. When doing volanoMark testing, vmstat showed the good kernel's context switch is about 110, but the bad kernel's context switch is 72. Good kernel's idle is about 1%, and bad kernel's idle is about 5%. > The exact commandline and .config being used would also help. I used some scripts to start volanoMark. Netperf loop UDP-RR-1/512's 10% regression on 16-core tigerton is also related to the patch. If I set CONFIG_FAIR_GROUP_SCHED=n, there is no the netperf regression. I bind the netserver process to a core and bind the client to another core in another processor. It's hard to debug into netperf regression if it's caused by scheduler. > > Yamin, > I would also like to know against which previous version is this > regression being compared with. Is it 2.6.24? Yes. > Did you have > CONFIG_FAIR_USER_SCHED enabled in both cases? Yes. CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y > It would also help to know if you > see the same regression with FAIR_GROUP_SCHED turned off. No regression if CONFIG_FAIR_GROUP_SCHED=n. -yanmin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 -mm v4 6/9] atmel_serial: Split the interrupt handler
Hi, Remy Bohmer wrote: Hello All, All works now for me with preempt-rt. The problem is using hrtimer. I think that hrtimer are executed with interrupts disabled so, if this happen when I must receive a char, i have an overrun. No, they share the same interrupt line... I think that the hrtimer use and other interrupt line. The AT91SAM9260_ID_TC2. So, while the timer interrupt handler is running, the serial handler has to wait until the timer interrupt handler has finished. Notice that the HRT interrupt handler is quite heavy and takes a long time to complete. The problem is the heavy of HRT interrupt handler of course. And, as I already mentioned, related to the 1 byte FIFO and a interrupt latency of about 85us (without HRT), it is logical that you can get an overrun at the higher serial speeds... (>=115200bps) I don't have the same problem without the hrtimer, I suppose the the timer latency is not so heavy. The only solution was the dma support to serial device. Or, use flow control? Yes :) Michael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vmsplice exploits, stack protector and Makefiles
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > was removed from arch/x86/kernel/process_64.c:__switch_to? that's
> > the only reason i can think of that would trigger this trace.
>
> I hand-ported your fixes [the patch was whitespace damaged] so i'm
> quite sure i got every bit of it - but find it below for reference. I
> think the percpu changes in .25 might have interfered somewhere. Will
> investigate.
ok, Arjan found the bug: it was that idle threads didnt have their
canary set up right.
[ note that this is still not complete because the initial idle thread
still has a zero canary. But it at least boots now. ]
Ingo
->
Subject: x86: setup stack canary for the idle threads
From: Arjan van de Ven <[EMAIL PROTECTED]>
The idle threads for non-boot CPUs are a bit special in how they
are created; the result is that these don't have the stack canary
set up properly in their PDA. Easiest fix is to just always set
the PDA up correctly when entering the idle thread; this is a NOP
for the boot cpu.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86/kernel/process_64.c |9 +
1 file changed, 9 insertions(+)
Index: linux-x86.q/arch/x86/kernel/process_64.c
===
--- linux-x86.q.orig/arch/x86/kernel/process_64.c
+++ linux-x86.q/arch/x86/kernel/process_64.c
@@ -166,6 +166,15 @@ static inline void play_dead(void)
void cpu_idle(void)
{
current_thread_info()->status |= TS_POLLING;
+
+#ifdef CONFIG_CC_STACKPROTECTOR
+ /*
+* If we're the non-boot CPU, nothing set the PDA stack
+* canary up for us. This is as good a place as any for
+* doing that.
+*/
+ write_pda(stack_canary, current->stack_canary);
+#endif
/* endless idle loop with no priority at all */
while (1) {
tick_nohz_stop_sched_tick();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] net: xfrm statistics depend on INET.
net/built-in.o: In function `xfrm_policy_init': /home/pmundt/devel/git/sh-2.6.25/net/xfrm/xfrm_policy.c:2338: undefined reference to `snmp_mib_init' snmp_mib_init() is only built in if CONFIG_INET is set. Signed-off-by: Paul Mundt <[EMAIL PROTECTED]> --- net/xfrm/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig index 8f9dbec..9201ef8 100644 --- a/net/xfrm/Kconfig +++ b/net/xfrm/Kconfig @@ -38,7 +38,7 @@ config XFRM_MIGRATE config XFRM_STATISTICS bool "Transformation statistics (EXPERIMENTAL)" - depends on XFRM && PROC_FS && EXPERIMENTAL + depends on INET && XFRM && PROC_FS && EXPERIMENTAL ---help--- This statistics is not a SNMP/MIB specification but shows statistics about transformation error (or almost error) factor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] markers: Fix build for MODULES=n.
CC kernel/marker.o
kernel/marker.c: In function 'marker_update_probes':
kernel/marker.c:627: error: too few arguments to function
'module_update_markers'
make[1]: *** [kernel/marker.o] Error 1
make: *** [kernel] Error 2
module_update_markers() doesn't take any arguments, update the MODULES=n
version of it to reflect that.
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
---
include/linux/module.h |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 330bec0..819c4e8 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -567,8 +567,7 @@ static inline void print_modules(void)
{
}
-static inline void module_update_markers(struct module *probe_module,
- int *refcount)
+static inline void module_update_markers(void)
{
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] media: tuner-xc2028 depends on FW_LOADER.
ERROR: "release_firmware" [drivers/media/video/tuner-xc2028.ko] undefined! ERROR: "request_firmware" [drivers/media/video/tuner-xc2028.ko] undefined! Signed-off-by: Paul Mundt <[EMAIL PROTECTED]> --- drivers/media/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 8f4a453..cb0b3fb 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -93,7 +93,7 @@ if VIDEO_TUNER_CUSTOMIZE config TUNER_XC2028 tristate "XCeive xc2028/xc3028 tuners" - depends on I2C + depends on I2C && FW_LOADER default m if VIDEO_TUNER_CUSTOMIZE help Say Y here to include support for the xc2028/xc3028 tuners. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Use menuconfig for CONFIG_UIO
Am Wed, 13 Feb 2008 23:28:19 +0100 schrieb Alessandro Guido <[EMAIL PROTECTED]>: > Signed-off-by: Alessandro Guido <[EMAIL PROTECTED]> Hi Alessandro, thanks, but this was already done by Denis Cheng: http://lkml.org/lkml/2008/2/2/60 I signed-off his patch, but AFAICS it hasn't been applied yet. BTW, please CC Greg Kroah-Hartman as well if you send patches for UIO. Thanks, Hans > > --- > > drivers/uio/Kconfig |8 ++-- > 1 files changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig > index b778ed7..dce4cae 100644 > --- a/drivers/uio/Kconfig > +++ b/drivers/uio/Kconfig > @@ -1,8 +1,6 @@ > -menu "Userspace I/O" > - depends on !S390 > - > -config UIO > +menuconfig UIO > tristate "Userspace I/O drivers" > + depends on !S390 > default n > help > Enable this to allow the userspace driver core code to be > @@ -25,5 +23,3 @@ config UIO_CIF > > To compile this driver as a module, choose M here: the > module will be called uio_cif. > - > -endmenu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] spufs support multiple probes markers
On Tue, Feb 12, 2008 at 06:56:50PM -0500, Mathieu Desnoyers wrote: > Update spufs to the new linux kernel markers API, which supports connecting > more than one probe to a single marker. Compiles and works for me. But saying I like the odd API would be lying. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] correct inconsistent ntp interval/tick_length usage
On Tue, 2008-02-12 at 15:36 +0100, Roman Zippel wrote: > On Mon, 11 Feb 2008, john stultz wrote: > > This fine grained error accounting is where the bug I'm trying to > > address is cropping up from. In order to have the comparison we need to > > have two values: > > A: The clocksource's notion of how long the fixed interval is. > > B: NTP's notion of how long the fixed interval is. > > > > When no NTP adjustment is being made, these two values should be equal, > > but currently they are not. This is what causes the 280ppm error seen on > > my test system. > > > > Part A is calculated in the following fashion: > > #define NTP_INTERVAL_LENGTH (NSEC_PER_SEC/NTP_INTERVAL_FREQ) > > > > Which is then functionally shifted up by TICK_LENGTH_SHIFT, but for the > > course of this discussion, lets ignore that. > > > > Part B is calculated in ntp_update_frequency() as: > > > > u64 second_length = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ) > > << TICK_LENGTH_SHIFT; > > second_length += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT; > > second_length += (s64)time_freq << (TICK_LENGTH_SHIFT - SHIFT_NSEC); > > > > tick_length_base = second_length; > > do_div(tick_length_base, NTP_INTERVAL_FREQ); > > > > > > If we're assuming there is no NTP adjustment, and avoiding the > > TICK_LENGTH_SHIFT, this can be shorted to: > > B = ((TICK_USEC * NSEC_PER_USEC * USER_HZ) > > + CLOCK_TICK_ADJUST)/NTP_ITNERVAL_FREQ > > > > > > The A vs B comparison can be shortened further to: > > NSEC_PER_SEC != (TICK_USEC * NSEC_PER_USEC * USER_HZ) > > + CLOCK_TICK_ADJUST > > > > So now on to what seems to be the point of contention: > > If A != B, which side do we fix? > > > > > > My patches fix the A side so that it matches B, which on its face isn't > > terribly complicated, but you seem to be suggesting we fix the B side > > instead (Now I'm assuming here, because there's no patch. So I can only > > speak to your emails, which were not clear to me). > > If we go from your base assumption above "there is no NTP adjustment", I > would actually agree with you and it wouldn't matter much on which side > to correct the equation. > > The question is now what happens, if there are NTP adjustments, i.e. when > the time_freq value isn't zero. Based on this initialization we tell the > NTP daemon the base frequency, although not directly but it knows the > length freq1 == 1 sec. If the clock now needs adjustment, the NTP daemon > tells the kernel via time_freq how to change the speed so that freq1 == > 1 sec + time_freq. > > The problem is now that by using CLOCK_TICK_ADJUST we are cheating and we > don't tell the NTP daemon the real frequency. We define 1 sec as freq2 + > tick_adjust and with the NTP adjustment we have freq2 + tick_adj == 1 sec > + time_freq. Above initialization now calcalutes the base time length for > an update interval of freq2 / NTP_INTERVAL_FREQ, this means the requested > time_freq adjustment isn't applied to (freq2 + tick_adj) cycles but to > freq2 cycles, so this finally means any adjustment made by the NTP daemon > is slightly off. Oh! So your issue is that since time_freq is stored in ppm, or in effect a usecs per sec offset, when we add it to something other then 1 second we mis-apply what NTP tells us to. Is that right? > To demonstrate this let's look at some real values and let's use the PIT > for it (as this is where this originated and on which CLOCK_TICK_ADJUST is > based on). With freq1=1193182 and HZ=1000 we program the timer with 1193 > cycles and the actual update frequency is freq2=1193000. To adjust for > this difference we change the length of a timer tick: > > (NSEC_PER_SEC + CLOCK_TICK_ADJUST) / NTP_INTERVAL_FREQ > > or > > (10^9 nsec - 152533 nsec) / 1000 > > This way every 1000 interrupts or 1193000 cycles the clock is advanced by > 999847467 nsec, so that we advance time according to freq1, but any > further adjustments aren't applied to an interval of what the NTP daemon > thinks is 1 sec but 999847467 nsec instead. Right, so if NTP has us apply a 10ppm adjustment, instead of doing: NSEC_PER_SEC + 10,000 We're doing: NSEC_PER_SEC + CLOCK_TICK_ADJUST + 10,000 Which, if I'm doing my math right, results in a 10.002ppm adjustment (using the 999847467ns number above), instead of just a 10ppm adjustment. Now, true, this is an error, but it is a pretty small one. Even at the maximum 500ppm value, it only results in an error of 76 parts per billion. As you'll see below, that tends to be less error then what we get from the clock granularity. Is there something else I'm missing here or is this really the core issue you're concerned with? If not, I'll agree that we may need to tune the "B" side of the equation, but can we also agree that the very large error caused, even without NTP adjustments, being involved by the A != B can be
Re: [REGRESSION] 2.6.25-rc1 does not boot on Alpha
Ivan Kokshaysky wrote: > On Wed, Feb 13, 2008 at 11:14:43AM -0600, Bob Tracy wrote: > > Ivan Kokshaysky wrote: > > > No SMP, no PRINTK_TIMESTAMPS in my case. Looks like it dies trying to > > > to switch to vga console, but I had no time to debug this yet... > > > > Same basic configuration as Ivan. Concur with the observation that > > death seems to happen during the console switch. Using the radeonfb > > driver (built-in, default graphics mode 80x30). > > As Peter pointed out in other mail, this is fixed by > > http://lkml.org/lkml/2008/1/28/100 Confirmed. This fixes 2.6.25-rc1 for me. I'm running on it as I type this. -- Bob Tracy | "I was a beta tester for dirt. They never did [EMAIL PROTECTED] | get all the bugs out." - Steve McGrew on /. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Module loading/unloading and "The Stop Machine"
Hello, Max. Max Krasnyansky wrote: > I was hopping you could answer a couple of questions about module > loading/unloading > and the stop machine. > There was a recent discussion on LKML about CPU isolation patches I'm working > on. > One of the patches makes stop machine ignore the isolated CPUs. People of > course had > questions about that. So I started looking into more details and got this > silly, crazy > idea that maybe we do not need the stop machine any more :) > > As far as I can tell the stop machine is basically a safety net in case some > locking > and recounting mechanisms aren't bullet proof. In other words if a subsystem > can actually > handle registration/unregistration in a robust way, module loader/unloader > does not > necessarily have to halt entire machine in order to load/unload a module that > belongs > to that subsystem. I may of course be completely wrong on that. Nope, it's integral part of module reference counting. When using refcnt for object lifetime management, the last put should be atomic against initial get of the object. This is usually achieved by acquiring the lock used for object lookup before putting or using atomic_dec_and_lock(). For module reference counts, this means that try_module_get() and try_stop_module() should be atomic. Note that modules don't use simple refcnt so the latter part isn't module_put() but the analogy still works. There are two ways to synchronize try_module_get() against try_stop_module() - the traditional is to grab lock in try_module_get() and use atomic_dec_and_lock() in try_stop_module(), which works but performance-wise bad because try_module_get() is used way much more than try_stop_module() is. For example, an IO command can go through several try_module_get()'s. So, all the burden of synchronization is put onto try_stop_module(). Because all of the cpus on the machine are stopped and none of them has been stopped in the middle of non-preemptible code, __try_stop_module() is synchronized from try_module_get() even though all the synchronization try_module_get() does is get_cpu(). > The problem with the stop machine is that it's a very very big gun :). In a > sense that > it totally kills all the latencies and stuff since the entire machine gets > halted while > module is being (un)loaded. Which is a major issue for any realtime apps. > Specifically > for CPU isolation the issue is that high-priority rt user-space thread > prevents stop > machine threads from running and entire box just hangs waiting for it. > I'm kind of surprised that folks who use monster boxes with over 100 CPUs > have not > complained. It's must be a huge hit for those machines to halt the entire > thing. > > It seems that over the last few years most subsystems got much better at > locking and > refcounting. And I'm hopping that we can avoid halting the entire machine > these days. > For CPU isolation in particular the solution is simple. We can just ignore > isolated CPUs. > What I'm trying to figure out is how safe it is and whether we can avoid full > halt > altogether. Without the stop_machine call, there's no synchronization between initial get and final put. Things will break. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sysv: [bl]e*_add_cpu conversion
On Wed, Feb 13, 2008 at 12:06:21AM +0100, [EMAIL PROTECTED] wrote: > From: Marcin Slusarz <[EMAIL PROTECTED]> > > replace all: > big/little_endian_variable = > cpu_to_[bl]eX([bl]eX_to_cpu(big/little_endian_variable) + > expression_in_cpu_byteorder); > with: > [bl]eX_add_cpu(/little_endian_variable, > expression_in_cpu_byteorder); > generated with semantic patch The patch looks correct to me, so ACK. > diff --git a/fs/sysv/sysv.h b/fs/sysv/sysv.h > index 42d51d1..38ebe3f 100644 > --- a/fs/sysv/sysv.h > +++ b/fs/sysv/sysv.h > @@ -217,9 +217,9 @@ static inline __fs32 fs32_add(struct sysv_sb_info *sbi, > __fs32 *n, int d) > if (sbi->s_bytesex == BYTESEX_PDP) > *(__u32*)n = PDP_swab(PDP_swab(*(__u32*)n)+d); > else if (sbi->s_bytesex == BYTESEX_LE) > - *(__le32*)n = cpu_to_le32(le32_to_cpu(*(__le32*)n)+d); > + le32_add_cpu((__le32 *)n, d); > else > - *(__be32*)n = cpu_to_be32(be32_to_cpu(*(__be32*)n)+d); > + be32_add_cpu((__be32 *)n, d); > return *n; but now that you've named the be and le primitives *_add_cpu it would be nice if you could submit a second patch to sysv to rename fs*_add to fs*_add_cpu aswell. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUGFIX 2/2] gdth: bugfix for the Timer at exit crash
On Wed, Feb 13, 2008 at 11:03:45AM -0600, James Bottomley wrote: > > I don't understand please explain. > > What does a driver need to do if it needs a consistent shutdown retine? > > module or built in? unload or shutdown? > > It needs to register a reboot notifier, which gdth does. Well, for crappy legacy driver that's the way, but it's not really recommended. As soon as a driver uses the proper driver models, e.g. gdth for pci using Jeff's pci hotplug patches it can just implement the ->shutdown method that is called before shutdown/kexec and can do the right thing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 panics on boot
On Thu, Feb 14, 2008 at 12:06:31PM +0530, Dhaval Giani wrote: > On Wed, Feb 13, 2008 at 10:32:02PM -0800, Yinghai Lu wrote: > > On Wed, Feb 13, 2008 at 10:20 PM, Dhaval Giani > > <[EMAIL PROTECTED]> wrote: > > > On Wed, Feb 13, 2008 at 01:08:42PM -0500, Chris Snook wrote: > > > > Dhaval Giani wrote: > > > >> I am getting the following oops on bootup on 2.6.25-rc1 > > > > ... > > > >> I am booting using kexec with maxcpus=1. It does not have any problems > > > >> with maxcpus=2 or higher. > > > > > > > > Sounds like another (the same?) kexec cpu numbering bug. Can you > > > post/link > > > > the entire dmesg from both a cold boot and a kexec boot so we can > > > compare? > > > > > > > > > > Don't think its a kexec bug. Get the same on cold boot. dmesg from kexec > > > boot. > > > > how about without "[EMAIL PROTECTED] nmi_watchdog=2" > > > > also does intel cpu support nmi_watchdog=2? > > > > Yes it does. I've used it to get some useful debug information. I will try > that out. > Panics at same point. -- regards, Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 panics on boot
On Wed, Feb 13, 2008 at 10:32:02PM -0800, Yinghai Lu wrote: > On Wed, Feb 13, 2008 at 10:20 PM, Dhaval Giani > <[EMAIL PROTECTED]> wrote: > > On Wed, Feb 13, 2008 at 01:08:42PM -0500, Chris Snook wrote: > > > Dhaval Giani wrote: > > >> I am getting the following oops on bootup on 2.6.25-rc1 > > > ... > > >> I am booting using kexec with maxcpus=1. It does not have any problems > > >> with maxcpus=2 or higher. > > > > > > Sounds like another (the same?) kexec cpu numbering bug. Can you > > post/link > > > the entire dmesg from both a cold boot and a kexec boot so we can > > compare? > > > > > > > Don't think its a kexec bug. Get the same on cold boot. dmesg from kexec > > boot. > > how about without "[EMAIL PROTECTED] nmi_watchdog=2" > > also does intel cpu support nmi_watchdog=2? > Yes it does. I've used it to get some useful debug information. I will try that out. > YH -- regards, Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 panics on boot
On Wed, Feb 13, 2008 at 10:20 PM, Dhaval Giani <[EMAIL PROTECTED]> wrote: > On Wed, Feb 13, 2008 at 01:08:42PM -0500, Chris Snook wrote: > > Dhaval Giani wrote: > >> I am getting the following oops on bootup on 2.6.25-rc1 > > ... > >> I am booting using kexec with maxcpus=1. It does not have any problems > >> with maxcpus=2 or higher. > > > > Sounds like another (the same?) kexec cpu numbering bug. Can you post/link > > the entire dmesg from both a cold boot and a kexec boot so we can compare? > > > > Don't think its a kexec bug. Get the same on cold boot. dmesg from kexec > boot. how about without "[EMAIL PROTECTED] nmi_watchdog=2" also does intel cpu support nmi_watchdog=2? 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] ide-floppy: merge callbacks
On Wed, Feb 13, 2008 at 11:04:23PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 13 February 2008, Borislav Petkov wrote:
> > commit d1f1f84f413ab00cb2fec48170d022fcd900e214
> > Author: Borislav Petkov <[EMAIL PROTECTED]>
> > Date: Wed Feb 13 20:26:56 2008 +0100
> >
> > ide-floppy: merge callbacks
> >
> > The appropriate functionality of the callback is established through
> > querying
> > the ATAPI packet command in pc->c[0].
> >
> > While at it, simplify if (floppy->failed_pc)-branch to be found in the
> > original
> > idefloppy_request_sense_callback().
> >
> > Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
> >
> > diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
> > index 5f133df..1365310 100644
> > --- a/drivers/ide/ide-floppy.c
> > +++ b/drivers/ide/ide-floppy.c
> > @@ -313,50 +313,39 @@ static struct request
> > *idefloppy_next_rq_storage(ide_drive_t *drive)
> > return (>rq_stack[floppy->rq_stack_index++]);
> > }
> >
> > -static void idefloppy_request_sense_callback(ide_drive_t *drive)
> > +static void ide_floppy_callback(ide_drive_t *drive)
> > {
> > idefloppy_floppy_t *floppy = drive->driver_data;
> > - u8 *buf = floppy->pc->buf;
> >
> > debug_log("Reached %s\n", __func__);
> >
> > - if (!floppy->pc->error) {
> > - floppy->sense_key = buf[2] & 0x0F;
> > - floppy->asc = buf[12];
> > - floppy->ascq = buf[13];
> > - floppy->progress_indication = buf[15] & 0x80 ?
> > - (u16)get_unaligned((u16 *)[16]) : 0x1;
> > + if (floppy->pc->c[0] == GPCMD_REQUEST_SENSE) {
> > + u8 *buf = floppy->pc->buf;
> >
> > - if (floppy->failed_pc)
> > - debug_log("pc = %x, sense key = %x, asc = %x,"
> > - " ascq = %x\n",
> > - floppy->failed_pc->c[0],
> > - floppy->sense_key,
> > - floppy->asc,
> > - floppy->ascq);
> > - else
> > - debug_log("sense key = %x, asc = %x, ascq = %x\n",
> > - floppy->sense_key,
> > - floppy->asc,
> > - floppy->ascq);
> > -
> > -
> > - idefloppy_end_request(drive, 1, 0);
> > - } else {
> > - printk(KERN_ERR "Error in REQUEST SENSE itself - Aborting"
> > - " request!\n");
> > - idefloppy_end_request(drive, 0, 0);
> > - }
> > -}
> > + if (!floppy->pc->error) {
> > + floppy->sense_key = buf[2] & 0x0F;
> > + floppy->asc = buf[12];
> > + floppy->ascq = buf[13];
> > + floppy->progress_indication = buf[15] & 0x80 ?
> > + (u16)get_unaligned((u16 *)[16]) : 0x1;
> >
> > -/* General packet command callback function. */
> > -static void idefloppy_pc_callback(ide_drive_t *drive)
> > -{
> > - idefloppy_floppy_t *floppy = drive->driver_data;
> > + if (floppy->failed_pc)
> > + debug_log("pc = %x, ", floppy->failed_pc->c[0]);
> >
> > - debug_log("Reached %s\n", __func__);
> > + debug_log("sense key = %x, asc = %x, ascq = %x\n",
> > + floppy->sense_key, floppy->asc, floppy->ascq);
> >
> > - idefloppy_end_request(drive, floppy->pc->error ? 0 : 1, 0);
> > + idefloppy_end_request(drive, 1, 0);
> > + } else {
> > + printk(KERN_ERR "Error in REQUEST SENSE itself - "
> > + "Aborting request!\n");
> > + idefloppy_end_request(drive, 0, 0);
> > + }
> > + } else if (floppy->pc->c[0] == GPCMD_READ_10 ||
> > + floppy->pc->c[0] == GPCMD_WRITE_10)
> > + idefloppy_end_request(drive, 1, 0);
> > + else
> > + idefloppy_end_request(drive, floppy->pc->error ? 0 : 1, 0);
> > }
> >
> > static void idefloppy_init_pc(struct ide_atapi_pc *pc)
> > @@ -367,7 +356,7 @@ static void idefloppy_init_pc(struct ide_atapi_pc *pc)
> > pc->req_xfer = 0;
> > pc->buf = pc->pc_buf;
> > pc->buf_size = IDEFLOPPY_PC_BUFFER_SIZE;
> > - pc->idefloppy_callback = _pc_callback;
> > + pc->idefloppy_callback = _floppy_callback;
> > }
> >
> > static void idefloppy_create_request_sense_cmd(struct ide_atapi_pc *pc)
> > @@ -376,7 +365,6 @@ static void idefloppy_create_request_sense_cmd(struct
> > ide_atapi_pc *pc)
> > pc->c[0] = GPCMD_REQUEST_SENSE;
> > pc->c[4] = 255;
> > pc->req_xfer = 18;
> > - pc->idefloppy_callback = _request_sense_callback;
> > }
> >
> > /*
> > @@ -697,14 +685,6 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t
> > *drive,
> > }
> > }
> >
> > -static void idefloppy_rw_callback(ide_drive_t
Re: [RFC PATCH] PCI: remove initial bios sort of PCI devices on x86
On Wed, Feb 13, 2008 at 11:07:53PM -0600, Matt Domsch wrote: > On Wed, Feb 13, 2008 at 03:40:29PM -0800, Greg KH wrote: > > Good plan. I'll be glad when the vestigal internal PCI device list is > gone too. With this patch, it's the last major step, I have a series of follow-up patches that will remove it entirely. I'll post them when they've been tested better. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE cdrom problem with PLEXTOR DVDR PX-608AL
On Thu, Feb 14, 2008 at 12:37:50AM +0100, Hans-Peter Jansen wrote: [Added Bart to CC] > Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov: > > On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote: > > > Hi, > > > > > > I suffer from unreliable cdrom operations (failing DAE and burn > > > sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel. > > > > > > Hi, > > > > can please you test this with a more recent kernel. Yours is almost > > ancient - from Sep. 2006. > > Sure, sorry. Here we go: > > Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused > (ireason = 0x01). > Trying to recover by ending request. > Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused > (ireason = 0x01). > Trying to recover by ending request. > > ~> uname -a > Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon i386 > GNU/Linux Actually the interrupt handler in ide-cd got rewritten and you're still using the old one (cdrom_pc_intr vs cdrom_newpc_intr). Those changes went into mainline before the 2.6.25-rc1 so we'll be able to test the new one only when you try out 2.6.25-rc1 or wait until 2.6.25 is released in case you don't want to try hazardous materials such as an -rc kernel[*] :). Bart? *. As a matter of fact it runs quite smoothly on my machines. -- Regards/Gruß, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 panics on boot
On Wed, Feb 13, 2008 at 01:08:42PM -0500, Chris Snook wrote: > Dhaval Giani wrote: >> I am getting the following oops on bootup on 2.6.25-rc1 > ... >> I am booting using kexec with maxcpus=1. It does not have any problems >> with maxcpus=2 or higher. > > Sounds like another (the same?) kexec cpu numbering bug. Can you post/link > the entire dmesg from both a cold boot and a kexec boot so we can compare? > Don't think its a kexec bug. Get the same on cold boot. dmesg from kexec boot. [0.00] Linux version 2.6.25-rc1 ([EMAIL PROTECTED]) (gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)) #5 SMP Thu Feb 14 06:46:02 IST 2008 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: 0100 - 0009dc00 (usable) [0.00] BIOS-e820: 0009dc00 - 000a (reserved) [0.00] BIOS-e820: 0010 - e97f5f00 (usable) [0.00] BIOS-e820: e97f5f00 - e97ff800 (ACPI data) [0.00] BIOS-e820: e97ff800 - e980 (reserved) [0.00] BIOS-e820: fec0 - 0001 (reserved) [0.00] BIOS-e820: 0001 - 00014000 (usable) [0.00] 4224MB HIGHMEM available. [0.00] 896MB LOWMEM available. [0.00] Scan SMP from c000 for 1024 bytes. [0.00] Scan SMP from c009fc00 for 1024 bytes. [0.00] Scan SMP from c00f for 65536 bytes. [0.00] Scan SMP from c009dc00 for 1024 bytes. [0.00] found SMP MP-table at [c009dd40] 0009dd40 [0.00] Reserving 64MB of memory at 16MB for crashkernel (System RAM: 5111MB) [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] Normal 4096 -> 229376 [0.00] HighMem229376 -> 1310720 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 -> 1310720 [0.00] DMI 2.3 present. [0.00] Using APIC driver default [0.00] ACPI: RSDP 000FDD90, 0014 (r0 IBM ) [0.00] ACPI: RSDT E97FF780, 0030 (r1 IBMSERONYXP 1000 IBM 45444F43) [0.00] ACPI: FACP E97FF700, 0074 (r1 IBMSERONYXP 1000 IBM 45444F43) [0.00] ACPI: DSDT E97F5F00, 962E (r1 IBMSERAVATR 1000 MSFT 10B) [0.00] ACPI: FACS E97FF5C0, 0040 [0.00] ACPI: APIC E97FF600, 00CA (r1 IBMSERONYXP 1000 IBM 45444F43) [0.00] ACPI: ASF! E97FF540, 004B (r16 IBMSERONYXP1 IBM 45444F43) [0.00] ACPI: PM-Timer IO Port: 0x488 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 15:2 APIC version 20 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) [0.00] Processor #2 15:2 APIC version 20 [0.00] WARNING: maxcpus limit of 1 reached. Processor ignored. [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) [0.00] Processor #4 15:2 APIC version 20 [0.00] WARNING: maxcpus limit of 1 reached. Processor ignored. [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled) [0.00] Processor #6 15:2 APIC version 20 [0.00] WARNING: maxcpus limit of 1 reached. Processor ignored. [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] enabled) [0.00] Processor #1 15:2 APIC version 20 [0.00] WARNING: maxcpus limit of 1 reached. Processor ignored. [0.00] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] enabled) [0.00] Processor #3 15:2 APIC version 20 [0.00] WARNING: maxcpus limit of 1 reached. Processor ignored. [0.00] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) [0.00] Processor #5 15:2 APIC version 20 [0.00] WARNING: maxcpus limit of 1 reached. Processor ignored. [0.00] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled) [0.00] Processor #7 15:2 APIC version 20 [0.00] WARNING: maxcpus limit of 1 reached. Processor ignored. [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x04] dfl dfl lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x06] dfl dfl lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x05] dfl dfl lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x07] dfl dfl lint[0x1]) [0.00] ACPI: IOAPIC (id[0x0e] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 14, version 17, address 0xfec0, GSI 0-15 [0.00] ACPI: IOAPIC (id[0x0d] address[0xfec01000] gsi_base[16]) [0.00] IOAPIC[1]: apic_id 13, version 17, address 0xfec01000, GSI 16-31 [0.00] ACPI: IOAPIC (id[0x0c] address[0xfec02000] gsi_base[32]) [0.00] IOAPIC[2]: apic_id 12, version 17, address 0xfec02000, GSI 32-47 [
Re: [PATCH 2/2] tc1100-wmi - Fail gracefully if ACPI is disabled
never mind -- linus fixed this in a more elegant way.
-len
On Thursday 14 February 2008 01:11, Len Brown wrote:
> applied.
>
> thanks,
> -len
>
> On Monday 11 February 2008 14:55, Carlos Corbacho wrote:
> > tc1100-wmi - Fail gracefully if ACPI is disabled
> >
> > From: Carlos Corbacho <[EMAIL PROTECTED]>
> >
> > WMI drivers, like their ACPI counterparts, should also check if ACPI is
> > disabled or not, and bail out if so, otherwise we cause a crash.
> >
> > Spotted by Ingo Molnar.
> >
> > Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]>
> > CC: Ingo Molnar <[EMAIL PROTECTED]>
> > CC: Linus Torvalds <[EMAIL PROTECTED]>
> > CC: Andrew Morton <[EMAIL PROTECTED]>
> > CC: Len Brown <[EMAIL PROTECTED]>
> > ---
> >
> > drivers/misc/tc1100-wmi.c |3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> >
> > diff --git a/drivers/misc/tc1100-wmi.c b/drivers/misc/tc1100-wmi.c
> > index f25e4c9..cb8f79f 100644
> > --- a/drivers/misc/tc1100-wmi.c
> > +++ b/drivers/misc/tc1100-wmi.c
> > @@ -263,6 +263,9 @@ static int __init tc1100_init(void)
> > {
> > int result = 0;
> >
> > + if (acpi_disabled)
> > + return -ENODEV;
> > +
> > if (!wmi_has_guid(GUID))
> > return -ENODEV;
> >
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: vmsplice exploits, stack protector and Makefiles
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > hm, had to pull it again because it crashed in testing: > > i've only tested .24, not .25 so maybe something changed. did you make > sure that > > write_pda(stack_canary, next_p->stack_canary); > > was removed from arch/x86/kernel/process_64.c:__switch_to? that's the > only reason i can think of that would trigger this trace. I hand-ported your fixes [the patch was whitespace damaged] so i'm quite sure i got every bit of it - but find it below for reference. I think the percpu changes in .25 might have interfered somewhere. Will investigate. Ingo ---> Subject: x86: fix stack protector and Makefiles From: [EMAIL PROTECTED] Date: Wed, 13 Feb 2008 15:38:45 +0200 there're so many problems with ssp here and in general. 1. despite the nice analysis in LWN, it unfortunately stopped half way where Jon declared that: And this turns the failure to read-verify the source array into a buffer overflow vulnerability within the kernel. Once that is in place, it is a relatively straightforward exercise for any suitably 31337 hacker to cause the kernel to jump into the code of his or her choice. Game over. fact of the matter is, it's far from game over at this point. and that's because despite all appearances, this is far from your run-of-the-mill stack buffer overflow. in particular, the overflow does *not* rely on overwriting any saved return address on the stack. the trickery with the fake compound page set up should have been a sign that something else is going on here and the lesson ain't over until you understand that part as well. 2. so why isn't this exploit about an overflowed return address? because before any potentially overflowed return address would be dereferenced, the kernel will attempt to release the page refcounts it acquired in get_user_pages (check splice_to_pipe, called from vmsplice_to_pipe where the overflowed buffer is). normally that wouldn't be a problem since even though the pages[PIPE_BUFFERS] array was overflowed, it was overflowed with valid struct page pointers, so releasing them should be fine. except there's a trick in the exploit that will cause a userland controlled struct page pointer to be released as well at which point the exploit takes matters into its own hands: previous to calling vmsplice, the exploit has prepared a specially constructed struct page array to fake a compound page. the point in using a compound page is that such a page has a destructor (read: function pointer) which is now under the direct control of the exploit and will result in ring-0 code execution of exploit code. *this* is the point where it becomes a trivial exercise to escalate privileges. 3. what's ssp got to do with all this? Arjan would have you believe that it would have caught this exploit in action, preventing the privilege escalation. nothing could be further from the truth though. for one if ssp were to kick into action, it could at most be at the time vmsplice_to_pipe returns. except it doesn't as explained above. but imagine for a second that vmsplice_to_pipe does return. would ssp detect anything? at least gentoo's gcc 4.2.2 doesn't at all instrument vmsplice_to_pipe with -fstack-protector, so no dice. let's go further and imagine we enable CONFIG_CC_STACKPROTECTOR_ALL (which in turn makes gcc use -fstack-protector-all). this will now properly instrument vmsplice_to_pipe. problem is, such a kernel doesn't boot. probably noone has ever tried it (why does it have a config option?). the fix isn't trivial and possibly incomplete, see the patches at the end. finally just imagine that ssp somehow caught this or another exploit in action. what will we learn about it? nothing. that's right, due to bad decisions made by certain developers (both gcc and kernel),__stack_chk_fail doesn't get passed any extra info (unlike Etoh's original ssp), nor does the kernel's version produce any actually useful output that, pray tell, could help identify the attacked function. instead it just panic's. a truly useful experience. it also bears a note here that the way ssp is currently implemented in the kernel is quite useless, a per-task static cookie is trivial to learn in a kernel info-leak exploit that in turn can be built into the actual attack payload to bypass any detection (a case that ssp was designed to protect against, this particular bug/exploit doesn't give direct control over the overflow content, hence even the current cookie method would have been fine, were it not irrelevant for reasons explained above). [...] > It would have made this exploit not possible for those kernels that > enable this feature (and that includes distros like Fedora) sadly for all those users living in a false sense of security, this has never been true. but long live
Re: vmsplice exploits, stack protector and Makefiles
* Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > > if you're merging this, please do the independent parts really > > > independenrly. For example, the above is a patch in its own right, > > > and probably worth doing regardless of anything else. > > > > yes. I wanted to have it tested for a bit, because the lack of use > > of the gcc flag means complete lack of testing coverage. The > > obligatory "please add a stackprotector self-test" debug feature > > request went to Arjan two days ago already. > > Do you think that the top-lvel Makefile change is OK to merge? I would > like to merge it separatly to have maximum bisectability. sure. Acked-by: Ingo Molnar <[EMAIL PROTECTED]> 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 2/2] tc1100-wmi - Fail gracefully if ACPI is disabled
applied.
thanks,
-len
On Monday 11 February 2008 14:55, Carlos Corbacho wrote:
> tc1100-wmi - Fail gracefully if ACPI is disabled
>
> From: Carlos Corbacho <[EMAIL PROTECTED]>
>
> WMI drivers, like their ACPI counterparts, should also check if ACPI is
> disabled or not, and bail out if so, otherwise we cause a crash.
>
> Spotted by Ingo Molnar.
>
> Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]>
> CC: Ingo Molnar <[EMAIL PROTECTED]>
> CC: Linus Torvalds <[EMAIL PROTECTED]>
> CC: Andrew Morton <[EMAIL PROTECTED]>
> CC: Len Brown <[EMAIL PROTECTED]>
> ---
>
> drivers/misc/tc1100-wmi.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
>
> diff --git a/drivers/misc/tc1100-wmi.c b/drivers/misc/tc1100-wmi.c
> index f25e4c9..cb8f79f 100644
> --- a/drivers/misc/tc1100-wmi.c
> +++ b/drivers/misc/tc1100-wmi.c
> @@ -263,6 +263,9 @@ static int __init tc1100_init(void)
> {
> int result = 0;
>
> + if (acpi_disabled)
> + return -ENODEV;
> +
> if (!wmi_has_guid(GUID))
> return -ENODEV;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Latency issues with x86.git
* Kevin Winchester <[EMAIL PROTECTED]> wrote: > Hi Ingo, > > I have encountered (a handful of times in the past few months) some > real interactivity problems on my system. Moving the mouse or typing > a key on the keyboard takes around a second to show any response. > Once I perform a reboot, the problem is gone again. I am currently > running x86.git mm branch, but I switch between that branch, mainline > git, and mm kernels, so I cannot guarantee on which trees I have or > have not seen the problem. please try sched-devel.git, which has both the latest scheduler fixes, and also the new "ftrace" latency tracing framework that can be used to trace various latency problems. You can pick up sched-devel.git via: http://people.redhat.com/mingo/sched-devel.git/README firstly, there's a chance that sched-devel.git solves the problem - in that case please report it. if it doesnt, then you can trace various latencies via these: CONFIG_FTRACE=y CONFIG_IRQSOFF_TRACER=y CONFIG_SCHED_TRACER=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_DYNAMIC_FTRACE=y just enable them, boot into the new kernel and mount debugfs: mount -t debugfs nodev /debug and then you can select one of the tracers (that have been enabled in the .config) via /debug/tracing/* files. The usage of these files should be self-explaining - if any of them wasnt then please let us know and we'll make the "first quick glance experience" better :) the one interesting to you would be the "wakeup" tracer. Enable it, and if you echo 0 into /debug/tracing/tracing_max_latency it starts tracking the worst-case delay experienced on your system and should start reporting them to the syslog. if you encounter any problems during these steps then please let us know - this code is quite fresh so expect some rough edges. 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] Add MS_BIND_FLAGS mount flag
On Tue, Feb 12, 2008 at 09:45:15PM -0800, Paul Menage wrote:
> From: Paul Menage <[EMAIL PROTECTED]>
>
> Add a new mount() flag, MS_BIND_FLAGS.
>
> MS_BIND_FLAGS indicates that a bind mount should take its per-mount flags
> from the arguments passed to mount() rather than from the source
> mountpoint.
>
> This flag allows you to create a bind mount with the desired per-mount
> flags in a single operation, rather than having to do a bind mount
> followed by a remount, which is fiddly and can block for non-trivial
> periods of time (on sb->s_umount?).
>
> For recursive bind mounts, only the root of the tree being bound
> inherits the per-mount flags from the mount() arguments; sub-mounts
> inherit their per-mount flags from the source tree as usual.
I think this concept is reasonable, but I don't think MS_BIND_FLAGS
is a descriptive name for this flag. MS_EXPLICIT_FLAGS might be better
but still isn't optimal.
> +static struct vfsmount *
> +__copy_tree(struct vfsmount *mnt, struct dentry *dentry,
> + int flag, int mnt_flags)
> +struct vfsmount *copy_tree(struct vfsmount *mnt, struct dentry *dentry,
> +int flag)
> +{
> + return __copy_tree(mnt, dentry, flag, mnt->mnt_flags);
> +}
Please just change copy_tree to have an additional parameter. There's
just four callers of it in the tree, and three of them want the new
parameter.
> + /* Use the source mount flags unless the user passed MS_BIND_FLAGS */
I think this comment could be made a little more explicit.
/*
* If MS_EXPLICIT_FLAGS is passed in we will take the paramters
* the user has specified. The default behaviour for bind
* mounts is however to take the flags from existing mount
* instances for the same superblock.
*/
> #define MS_RELATIME (1<<21) /* Update atime relative to mtime/ctime. */
> #define MS_KERNMOUNT (1<<22) /* this is a kern_mount call */
> #define MS_I_VERSION (1<<23) /* Update inode I_version field */
> +#define MS_BIND_FLAGS(1<<24) /* For MS_BIND, take mnt_flags from
> + * args, not from source mountpoint */
> #define MS_ACTIVE (1<<30)
> #define MS_NOUSER (1<<31)
this looks like whitespace damage to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh updates for 2.6.25-rc2
Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git Which contains: Adrian McMenamin (4): maple: fix up whitespace damage. maple: more robust device detection. maple: Drop unused prototypes from linux/maple.h. maple: improve detection of attached peripherals Alan Cox (1): sh: termios ioctl definitions Hideo Saito (1): sh: Fix multiple UTLB hit on UP SH-4. Kristoffer Ericson (1): sh: Tidy include/asm-sh/hp6xx.h Magnus Damm (18): sh: declared coherent memory support V2 fix sh: add sh7722 support to EARLY_SCIF_CONSOLE sh: add probe support for new sh7722 cut sh: break out unaligned sign extension code sh: migor board support sh: make copy_to/from_user() static inline sh: add byte support to the sign extension code sh: use opcode_t and enable unaligned code for sh2a sh: update r2d defconfigs with usb, spi and rtc sh: trapped io support V2 sh: trapped io support for r2d V2 sh: trapped io support for highlander V2 sh: fix ptrace copy_from/to_user() compilation error sh: remove maskreg irq code sh: add support for sh7366 processor sh: use ctrl_in/out for on chip pci access sh: fix ioreadN_rep and iowriteN_rep sh: fix pci io access for r2d boards Paul Mundt (19): sh: Wire up new timerfd syscalls. sh: Add mach-type entries for MigoR and SDK7780. sh: Use max_t in io_trapped. sh: Clean up whitespace damage in Kconfig.debug. sh: Symbol exports for trapped I/O. sh: Handle SH7366 CPU in check_bugs(). sh: Disable big endian for SH-5. sh: Fix up pte_mkhuge() build breakage for SH-5. sh: Fix up set_fixmap_nocache() for SH-5. sh: Update SH-5 flush_cache_sigtramp() for API changes. sh: Shut up some trivial build warnings. sh: asm/tlb.h needs linux/pagemap.h for CONFIG_SWAP=n. sh: Kill off bogus SH_SDK7780_STANDALONE symbol. maple: Fix up maple build failure. sh: Get SH-5 caches working again post-unification. serial: sh-sci: Fix up SH-5 build. sh: asm/irq.h needs asm/cpu/irq.h. sh: __uncached_start only on sh32. sh: Kill off more dead symbols. Peter Zijlstra (1): sh: fix xtime_lock deadlocking. Stephen Rothwell (1): sh: remove unneeded cast arch/sh/Kconfig | 19 + arch/sh/Kconfig.cpu |4 +- arch/sh/Kconfig.debug |3 +- arch/sh/Makefile |1 + arch/sh/boards/renesas/migor/Makefile |1 + arch/sh/boards/renesas/migor/setup.c | 61 ++ arch/sh/boards/renesas/r7780rp/setup.c| 47 +- arch/sh/boards/renesas/rts7751r2d/setup.c | 45 +- arch/sh/boards/renesas/sdk7780/Kconfig|7 - arch/sh/cchips/hd6446x/hd64465/setup.c| 47 +- arch/sh/configs/migor_defconfig | 824 +++ arch/sh/configs/rts7751r2d1_defconfig | 340 --- arch/sh/configs/rts7751r2dplus_defconfig | 340 --- arch/sh/configs/se7705_defconfig |1 - arch/sh/drivers/dma/dma-api.c |2 +- arch/sh/drivers/pci/fixups-lboxre2.c |4 +- arch/sh/drivers/pci/fixups-rts7751r2d.c |4 +- arch/sh/drivers/pci/ops-dreamcast.c | 44 +- arch/sh/drivers/pci/ops-rts7751r2d.c |3 +- arch/sh/drivers/pci/pci-sh4.h |4 +- arch/sh/drivers/pci/pci-sh7751.c | 16 +- arch/sh/drivers/pci/pci-sh7780.c |2 +- arch/sh/kernel/Makefile_32|1 + arch/sh/kernel/Makefile_64|1 + arch/sh/kernel/cpu/irq/Makefile |1 - arch/sh/kernel/cpu/irq/intc-sh5.c | 27 +- arch/sh/kernel/cpu/irq/maskreg.c | 93 --- arch/sh/kernel/cpu/sh4/probe.c|8 +- arch/sh/kernel/cpu/sh4a/Makefile |2 + arch/sh/kernel/cpu/sh4a/clock-sh7722.c| 10 +- arch/sh/kernel/cpu/sh4a/setup-sh7366.c| 177 + arch/sh/kernel/cpu/sh5/probe.c| 61 +- arch/sh/kernel/io.c |8 +- arch/sh/kernel/io_generic.c | 24 +- arch/sh/kernel/io_trapped.c | 276 arch/sh/kernel/irq.c |3 - arch/sh/kernel/process_64.c |9 +- arch/sh/kernel/ptrace_32.c|4 +- arch/sh/kernel/setup.c|2 +- arch/sh/kernel/syscalls_32.S |4 +- arch/sh/kernel/syscalls_64.S |4 +- arch/sh/kernel/time_32.c | 19 +- arch/sh/kernel/time_64.c | 31 +- arch/sh/kernel/timers/timer-mtu2.c|1 - arch/sh/kernel/traps_32.c | 164 +++--- arch/sh/kernel/traps_64.c |4 +- arch/sh/kernel/vmlinux_64.lds.S |2 +- arch/sh/mm/cache-sh5.c| 1019 -
Re: [2.6 patch] make secmark_tg_destroy() static
From: James Morris <[EMAIL PROTECTED]> Date: Thu, 14 Feb 2008 10:41:19 +1100 (EST) > On Wed, 13 Feb 2008, Paul Moore wrote: > > > On Wednesday 13 February 2008 4:29:40 pm Adrian Bunk wrote: > > > This patch makes the needlessly global secmark_tg_destroy() static. > > > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > > > Thanks for catching this. > > > > Acked-by: Paul Moore <[EMAIL PROTECTED]> > > > > Applied -- will push to Linus unless the netfilter folk do it first. I sucked it in, don't worry about 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/
[PATCH] video: Fix v4l2 build with CONFIG_I2C=n.
drivers/built-in.o: In function `v4l2_i2c_attach':
/home/pmundt/devel/git/sh-2.6.25/drivers/media/video/v4l2-common.c:1040:
undefined reference to `i2c_attach_client'
make: *** [.tmp_vmlinux1] Error 1
The v4l2-common code contains a number of i2c helpers which are built in
unconditionally, despite the fact that the i2c routines it references are
not. Move these under a CONFIG_I2C.
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
---
drivers/media/video/v4l2-common.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index c056ff6..0e00531 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -973,6 +973,7 @@ u32 v4l2_ctrl_next(const u32 * const * ctrl_classes, u32 id)
return **ctrl_classes;
}
+#ifdef CONFIG_I2C
int v4l2_chip_match_i2c_client(struct i2c_client *c, u32 match_type, u32
match_chip)
{
switch (match_type) {
@@ -984,6 +985,7 @@ int v4l2_chip_match_i2c_client(struct i2c_client *c, u32
match_type, u32 match_c
return 0;
}
}
+EXPORT_SYMBOL(v4l2_chip_match_i2c_client);
int v4l2_chip_ident_i2c_client(struct i2c_client *c, struct v4l2_chip_ident
*chip,
u32 ident, u32 revision)
@@ -1000,6 +1002,7 @@ int v4l2_chip_ident_i2c_client(struct i2c_client *c,
struct v4l2_chip_ident *chi
}
return 0;
}
+EXPORT_SYMBOL(v4l2_chip_ident_i2c_client);
int v4l2_chip_match_host(u32 match_type, u32 match_chip)
{
@@ -1010,6 +1013,7 @@ int v4l2_chip_match_host(u32 match_type, u32 match_chip)
return 0;
}
}
+EXPORT_SYMBOL(v4l2_chip_match_host);
/* - */
@@ -1038,6 +1042,8 @@ int v4l2_i2c_attach(struct i2c_adapter *adapter, int
address, struct i2c_driver
}
return err != -ENOMEM ? 0 : err;
}
+EXPORT_SYMBOL(v4l2_i2c_attach);
+#endif /* CONFIG_I2C */
/* - */
@@ -1062,12 +1068,6 @@ EXPORT_SYMBOL(v4l2_ctrl_query_menu);
EXPORT_SYMBOL(v4l2_ctrl_query_fill);
EXPORT_SYMBOL(v4l2_ctrl_query_fill_std);
-EXPORT_SYMBOL(v4l2_chip_match_i2c_client);
-EXPORT_SYMBOL(v4l2_chip_ident_i2c_client);
-EXPORT_SYMBOL(v4l2_chip_match_host);
-
-EXPORT_SYMBOL(v4l2_i2c_attach);
-
/*
* Local variables:
* c-basic-offset: 8
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] adfs: trivial sparse fix
On Wed, 13 Feb 2008 19:52:12 -0800 Harvey Harrison <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-02-13 at 19:39 -0800, Andrew Morton wrote:
> > On Wed, 13 Feb 2008 18:07:48 -0800 Harvey Harrison <[EMAIL PROTECTED]>
> > wrote:
> >
> > > fs/adfs/dir_f.c:126:4: warning: do-while statement is not a compound
> > > statement
> > >
> > > Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
> > > ---
> > > fs/adfs/dir_f.c |4 ++--
> > > 1 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/fs/adfs/dir_f.c b/fs/adfs/dir_f.c
> > > index b9b2b27..ea7df21 100644
> > > --- a/fs/adfs/dir_f.c
> > > +++ b/fs/adfs/dir_f.c
> > > @@ -122,9 +122,9 @@ adfs_dir_checkbyte(const struct adfs_dir *dir)
> > > ptr.ptr8 = bufoff(bh, i);
> > > end.ptr8 = ptr.ptr8 + last - i;
> > >
> > > - do
> > > + do {
> > > dircheck = *ptr.ptr8++ ^ ror13(dircheck);
> > > - while (ptr.ptr8 < end.ptr8);
> > > + } while (ptr.ptr8 < end.ptr8);
> > > }
> > >
> >
> > eh? It's sparse which needs fixing here, surely?
>
> Well, I only 'fixed' it this way to match the surrounding code. The
> warning is a little odd.
>
Yup, well, I changed the title to something sufficiently rude to get a
reaction from Linus when it crosses his desk. We'll see ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] x86: make dump_pagetable() static
* Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Wed, Feb 13, 2008 at 02:27:47PM -0800, Harvey Harrison wrote: > > On Wed, 2008-02-13 at 23:31 +0200, Adrian Bunk wrote: > > > dump_pagetable() can now become static. > > > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> thanks, applied. > > I believe Andi Kleen wanted this kept global to make it easy to use > > when adding debugging code elsewhere. > > That's not a reason as long as his code isn't in the tree (and he > anyway has to patch the kernel for using it). correct. There's also a new CONFIG_X86_PTDUMP=y pagetable dumping debug feature now in x86.git#mm that produces much nicer output. Arjan: i it might be nice to make the new pagetable dumper triggerable from a SysRq - could you try the kernel/time/timer_list.c's SEQ_printf() trick to make the dumping dual-purpose? [so that it printk()'s if it should dump to the console and seq_printf()'s if it should dump via /proc] 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: stuck with 2.6.23.14 on x86_64
On Wednesday 13 February 2008 04:21, Fabio Coatti wrote:
> Alle martedì 12 febbraio 2008, Rafael J. Wysocki ha scritto:
> > On Tuesday, 12 of February 2008, Fabio Coatti wrote:
> > > Alle martedì 12 febbraio 2008, Randy Dunlap ha scritto:
> > > > On Tue, 12 Feb 2008 15:03:41 +0100 Fabio Coatti wrote:
> > > > > Hi all,
> > > > > I'm stuck in a weird situation: I'm unable to go beyond 2.6.23.14, so
> > > > > to fix the splice bug I've had to apply by hand the patch. (x86_64)
> > > > >
> > > > > Basically, with 2.6.24.2 (the same with 2.6.24 and .1), tha machine
> > > > > won't boot due to a problem with cciss driver, that prevents to find
> > > > > the / partition. (bug described here: Kernel Bug Tracker Bug 9859
> > > > > http://bugzilla.kernel.org/show_bug.cgi?id=9859 );
> > > > >
> > > > > With kernels 2.6.23, the lastest that I can compile is 2.6.23.14;
> > > > > starting from .15 (and .16) I get this message:
> > > > >
> > > > > ==
> > > > > UPD include/linux/compile.h
> > > > > CC init/version.o
> > > > > LD init/built-in.o
> > > > > LD .tmp_vmlinux1
> > > > > drivers/built-in.o: In function `acpi_init':
> > > > > bus.c:(.init.text+0x1713): undefined reference to `pm_flags'
> > > > > bus.c:(.init.text+0x1756): undefined reference to `pm_flags'
> > > > > ==
> > > > >
> > > > > All .config are the same, (make oldconfig) beside the obvious
> > > > > differences between .23 and .24
> > > > >
> > > > > Hardware: x86_64 AMD 2216HE
> > > > > SCSI controller: HP Smart Array E200i Controller
> > > > > Compiler: gcc (GCC) 4.1.1
> > > > > binutils: 2.16.1
> > > > >
> > > > > On a x86 machine, Intel(R) Xeon(TM) CPU 3.20GHz
> > > > > with a cciss0: HP Smart Array 6i Controller,
> > > > > the 2.6.24.2 compiles just fine and works, so the cciss problems
> > > > > seems related only to E200i controller.
> > > > >
> > > > > Right now, on AMD64 machines, I'm forced to patch by hand the kernel,
> > > > > that's quite uncomfortable :)
> > > > >
> > > > > Can someone point me in the right direction to get out of this
> > > > > situation? Of course I can provide any further information. (.config
> > > > > not inlcuded now to avoid cluttering )
> > > > >
> > > > > Thanks for any answer.
> > > >
> > > > a/ send .config file for the build problem above
> > > > b/ How do you download and/or apply 2.6.23.{15,16} ?
> > > > Full tarball or base tarball + patches?
> > > > If patches, what base tree are they applied to?
> > >
> > > full tarball from kernel.org (.16), tried also applying patches to 2.6.23
> > > vanilla.(.15,.16) Same process leads to successful compilation for .14
> >
> > You're not supposed to have CONFIG_PM unset and CONFIG_ACPI set at the same
> > time. The oldconfig generation must have gone wrong at one point.
>
> Maybe it's not supposed to have this situation, but maybe you should tell
> this
> to the kernel itself :)
>
> # zcat /proc/config.gz | egrep "PM|ACPI"
> CONFIG_X86_64_ACPI_NUMA=y
> # CONFIG_PM is not set
> CONFIG_ACPI=y
> # CONFIG_ACPI_PROCFS is not set
>
> # uname -rv
> 2.6.23.12 #3 SMP Tue Feb 12 11:22:16 CET 2008
>
> And you can easily get this situation from menuconfig: just fire up make
> menuconfig without any .config, go to power management options and turn
> off "Power Management support". exit and look at .config:
>
> # CONFIG_PM is not set
> CONFIG_SUSPEND_SMP_POSSIBLE=y
> CONFIG_HIBERNATION_SMP_POSSIBLE=y
> CONFIG_ACPI=y
>
> Maybe if this is not supposed to be the right situation, some dependencies
> are
> not respected... (tested on .16)
I think this got fixed in 2.6.24 by the X86_64_ACPI_NUMA dependencies.
(in 2.6.23 it used to select ACPI, in 2.6.24 it depends on ACPI).
So I think in 2.6.24 you should not have this trouble.
thanks,
-Len
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Module loading/unloading and "The Stop Machine"
Jike Song wrote: > On 2/8/08, Max Krasnyansky <[EMAIL PROTECTED]> wrote: >> Hi Rusty, >> >> I was hopping you could answer a couple of questions about module >> loading/unloading >> and the stop machine. > > I'm curious to know why it is called `stop machine', which is a queer > name without any relationship with its function. I guess it's "stop the rest of the machine" and run this. Maybe it's misnamed but stop_machine is kind of cool. :-) -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI suspend: Execute _WAK with the right argument
applied
thanks for quickly finding and fixing this 2.6.25-rc1 regression.
-len
On Tuesday 12 February 2008 18:32, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> The _WAK global ACPI control method has to be called with the
> argument representing the sleep state being exited. Make it happen.
>
> Special thanks to Mirco Tischler <[EMAIL PROTECTED]> for reporting the
> problem and debugging.
>
> Reported-by: Mirco Tischler <[EMAIL PROTECTED]>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> ---
> drivers/acpi/hardware/hwsleep.c |1 +
> 1 file changed, 1 insertion(+)
>
> Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
> ===
> --- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
> +++ linux-2.6/drivers/acpi/hardware/hwsleep.c
> @@ -616,6 +616,7 @@ acpi_status acpi_leave_sleep_state(u8 sl
> return_ACPI_STATUS(status);
> }
>
> + arg.integer.value = sleep_state;
> status = acpi_evaluate_object(NULL, METHOD_NAME__WAK, _list, NULL);
> if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> ACPI_EXCEPTION((AE_INFO, status, "During Method _WAK"));
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
WARNING at x86 smp_32.c:561 native_smp_call_function_mask()
I noticed this WARNING fly by while booting 2.6.24.2. Everything seems to be working though. Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel Pentium III (Katmai) stepping 02 Total of 2 processors activated (1805.98 BogoMIPS). ExtINT not setup in hardware but reported by MP table ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0 WARNING: at arch/x86/kernel/smp_32.c:561 native_smp_call_function_mask() Pid: 1, comm: swapper Not tainted 2.6.24.2 #1 [] native_smp_call_function_mask+0x171/0x180 [] common_interrupt+0x23/0x28 [] enable_NMI_through_LVT0+0x0/0x30 [] enable_NMI_through_LVT0+0x0/0x30 [] smp_call_function+0x1c/0x20 [] on_each_cpu+0x21/0x40 [] setup_nmi+0x30/0x50 [] setup_IO_APIC+0xe15/0xf40 [] atomic_notifier_call_chain+0x17/0x20 [] notify_update+0x1d/0x30 [] native_smp_prepare_cpus+0x55e/0xac0 [] task_rq_lock+0x39/0x70 [] set_cpus_allowed+0x46/0xa0 [] kernel_init+0x0/0x300 [] kernel_init+0x52/0x300 [] schedule_tail+0x17/0x60 [] ret_from_fork+0x6/0x1c [] kernel_init+0x0/0x300 [] kernel_init+0x0/0x300 [] kernel_thread_helper+0x7/0x10 === APIC timer registered as dummy, due to nmi_watchdog=1! checking TSC synchronization [CPU#0 -> CPU#1]: passed. Brought up 2 CPUs 560:/* Can deadlock when called with interrupts disabled */ 561:WARN_ON(irqs_disabled()); -- Jeff DeFouw <[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: parisc compile error
On Wed, Feb 13, 2008 at 01:42:10PM +0100, rubisher wrote:
> - some lake of changes of kset to kobj:
thanks, i don't build this driver, somehow it made its way out of my
configs. patch looks correct though. applied.
> --- ./drivers/parisc/pdc_stable.c.Orig2008-01-28 07:09:26.0
> +
> +++ ./drivers/parisc/pdc_stable.c 2008-02-13 11:22:16.0 +
> @@ -829,7 +829,7 @@
> struct kobj_attribute *attr,
> const char *buf, size_t count)
> {
> - return pdcs_auto_write(kset, attr, buf, count, PF_AUTOBOOT);
> + return pdcs_auto_write(kobj, attr, buf, count, PF_AUTOBOOT);
> }
>
> /**
> @@ -845,7 +845,7 @@
>struct kobj_attribute *attr,
>const char *buf, size_t count)
> {
> - return pdcs_auto_write(kset, attr, buf, count, PF_AUTOSEARCH);
> + return pdcs_auto_write(kobj, attr, buf, count, PF_AUTOSEARCH);
> }
>
> /**
> @@ -1066,7 +1066,7 @@
> }
>
> /* Don't forget the root entries */
> - error = sysfs_create_group(stable_kobj, pdcs_attr_group);
> + error = sysfs_create_group(stable_kobj, _attr_group);
>
> /* register the paths kset as a child of the stable kset */
> paths_kset = kset_create_and_add("paths", NULL, stable_kobj);
> === <> ===
>
> And the kernel build, but I don't yet try to boot it...
>
> Hth,
> r.
> ---
> Scarlet One, ADSL 6 Mbps + Telephone, from EUR 29,95...
> http://www.scarlet.be/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/11] ata: fix sparse warnings in pata_legacy.c
Let's use ld for legacy_data instead of shadowing these static
int variables.
drivers/ata/pata_legacy.c:777:21: warning: symbol 'qdi' shadows an earlier one
drivers/ata/pata_legacy.c:128:12: originally declared here
drivers/ata/pata_legacy.c:811:21: warning: symbol 'qdi' shadows an earlier one
drivers/ata/pata_legacy.c:128:12: originally declared here
drivers/ata/pata_legacy.c:848:21: warning: symbol 'qdi' shadows an earlier one
drivers/ata/pata_legacy.c:128:12: originally declared here
drivers/ata/pata_legacy.c:882:21: warning: symbol 'qdi' shadows an earlier one
drivers/ata/pata_legacy.c:128:12: originally declared here
drivers/ata/pata_legacy.c:1040:21: warning: symbol 'winbond' shadows an earlier
one
drivers/ata/pata_legacy.c:129:12: originally declared here
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
drivers/ata/pata_legacy.c | 44 ++--
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
index 6c59969..1c598e5 100644
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -774,14 +774,14 @@ static struct ata_port_operations opti82c46x_port_ops = {
static void qdi6500_set_piomode(struct ata_port *ap, struct ata_device *adev)
{
struct ata_timing t;
- struct legacy_data *qdi = ap->host->private_data;
+ struct legacy_data *ld = ap->host->private_data;
int active, recovery;
u8 timing;
/* Get the timing data in cycles */
ata_timing_compute(adev, adev->pio_mode, , 30303, 1000);
- if (qdi->fast) {
+ if (ld->fast) {
active = 8 - FIT(t.active, 1, 8);
recovery = 18 - FIT(t.recover, 3, 18);
} else {
@@ -790,9 +790,9 @@ static void qdi6500_set_piomode(struct ata_port *ap, struct
ata_device *adev)
}
timing = (recovery << 4) | active | 0x08;
- qdi->clock[adev->devno] = timing;
+ ld->clock[adev->devno] = timing;
- outb(timing, qdi->timing);
+ outb(timing, ld->timing);
}
/**
@@ -808,14 +808,14 @@ static void qdi6500_set_piomode(struct ata_port *ap,
struct ata_device *adev)
static void qdi6580dp_set_piomode(struct ata_port *ap, struct ata_device *adev)
{
struct ata_timing t;
- struct legacy_data *qdi = ap->host->private_data;
+ struct legacy_data *ld = ap->host->private_data;
int active, recovery;
u8 timing;
/* Get the timing data in cycles */
ata_timing_compute(adev, adev->pio_mode, , 30303, 1000);
- if (qdi->fast) {
+ if (ld->fast) {
active = 8 - FIT(t.active, 1, 8);
recovery = 18 - FIT(t.recover, 3, 18);
} else {
@@ -824,12 +824,12 @@ static void qdi6580dp_set_piomode(struct ata_port *ap,
struct ata_device *adev)
}
timing = (recovery << 4) | active | 0x08;
- qdi->clock[adev->devno] = timing;
+ ld->clock[adev->devno] = timing;
- outb(timing, qdi->timing + 2 * ap->port_no);
+ outb(timing, ld->timing + 2 * ap->port_no);
/* Clear the FIFO */
if (adev->class != ATA_DEV_ATA)
- outb(0x5F, qdi->timing + 3);
+ outb(0x5F, ld->timing + 3);
}
/**
@@ -845,14 +845,14 @@ static void qdi6580dp_set_piomode(struct ata_port *ap,
struct ata_device *adev)
static void qdi6580_set_piomode(struct ata_port *ap, struct ata_device *adev)
{
struct ata_timing t;
- struct legacy_data *qdi = ap->host->private_data;
+ struct legacy_data *ld = ap->host->private_data;
int active, recovery;
u8 timing;
/* Get the timing data in cycles */
ata_timing_compute(adev, adev->pio_mode, , 30303, 1000);
- if (qdi->fast) {
+ if (ld->fast) {
active = 8 - FIT(t.active, 1, 8);
recovery = 18 - FIT(t.recover, 3, 18);
} else {
@@ -860,11 +860,11 @@ static void qdi6580_set_piomode(struct ata_port *ap,
struct ata_device *adev)
recovery = 15 - FIT(t.recover, 0, 15);
}
timing = (recovery << 4) | active | 0x08;
- qdi->clock[adev->devno] = timing;
- outb(timing, qdi->timing + 2 * adev->devno);
+ ld->clock[adev->devno] = timing;
+ outb(timing, ld->timing + 2 * adev->devno);
/* Clear the FIFO */
if (adev->class != ATA_DEV_ATA)
- outb(0x5F, qdi->timing + 3);
+ outb(0x5F, ld->timing + 3);
}
/**
@@ -879,12 +879,12 @@ static unsigned int qdi_qc_issue_prot(struct
ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
struct ata_device *adev = qc->dev;
- struct legacy_data *qdi = ap->host->private_data;
+ struct legacy_data *ld = ap->host->private_data;
- if (qdi->clock[adev->devno] != qdi->last) {
+ if (ld->clock[adev->devno] != ld->last) {
if (adev->pio_mode) {
- qdi->last = qdi->clock[adev->devno];
-
Re: [2.6.25-rc1 regression] Suspend to RAM (bisected)
Applied.
thanks,
-Len
On Monday 11 February 2008 18:20, Venki Pallipadi wrote:
> On Mon, Feb 11, 2008 at 12:06:50PM -0800, Venki Pallipadi wrote:
> > On Mon, Feb 11, 2008 at 05:37:04PM -0200, Carlos R. Mafra wrote:
> > > Pallipadi, Venkatesh wrote:
> > > >
> > > > Can you send me the output of acpidump and full dmesg to me. Looks like
> > > > it is a platform issue due to which we cannot use C1 mwait idle during
> > > > suspend resume, something similar to issue we had with using C2/C3 state
> > > > during idle.
> > >
> > > Full dmesg and acpidump outputs are attached.
> >
> > Above acpidump doesnt have all info, as it is loading some SSDT at run time.
> > Can you get the output of
> >
> > # acpidump --addr 0x7F6D8709 --length 0x04B7
> > # acpidump --addr 0x7F6D8BC0 --length 0x0092
> >
>
> Thanks for sending the dumps Carlos.
>
> The patch below (on top of rc1) should fix the problem. Can you please
> check it.
>
> Thanks,
> Venki
>
>
> Earlier patch (bc71bec91f9875ef825d12104acf3bf4ca215fa4) broke
> suspend resume on many laptops. The problem was reported by
> Carlos R. Mafra and Calvin Walton, who bisected the issue to above patch.
>
> The problem was because, C2 and C3 code were calling acpi_idle_enter_c1
> directly, with C2 or C3 as state parameter, while suspend/resume was in
> progress. The patch bc71bec started making use of that state information,
> assuming that it would always be referring to C1 state. This caused the
> problem with suspend-resume as we ended up using C2/C3 state indirectly.
>
> Fix this by adding acpi_idle_suspend check in enter_c1.
>
> Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
>
> Index: linux-2.6.25-rc1/drivers/acpi/processor_idle.c
> ===
> --- linux-2.6.25-rc1.orig/drivers/acpi/processor_idle.c
> +++ linux-2.6.25-rc1/drivers/acpi/processor_idle.c
> @@ -1420,6 +1420,14 @@ static int acpi_idle_enter_c1(struct cpu
> return 0;
>
> local_irq_disable();
> +
> + /* Do not access any ACPI IO ports in suspend path */
> + if (acpi_idle_suspend) {
> + acpi_safe_halt();
> + local_irq_enable();
> + return 0;
> + }
> +
> if (pr->flags.bm_check)
> acpi_idle_update_bm_rld(pr, cx);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/11] ata: fix sparse warning in pata_marvell.c
drivers/ata/pata_marvell.c:88:2: warning: returning void-valued expression
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
drivers/ata/pata_marvell.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/pata_marvell.c b/drivers/ata/pata_marvell.c
index 9afc8a3..a81f25d 100644
--- a/drivers/ata/pata_marvell.c
+++ b/drivers/ata/pata_marvell.c
@@ -85,8 +85,8 @@ static int marvell_cable_detect(struct ata_port *ap)
static void marvell_error_handler(struct ata_port *ap)
{
- return ata_bmdma_drive_eh(ap, marvell_pre_reset, ata_std_softreset,
- NULL, ata_std_postreset);
+ ata_bmdma_drive_eh(ap, marvell_pre_reset, ata_std_softreset, NULL,
+ ata_std_postreset);
}
/* No PIO or DMA methods needed for this device */
--
1.5.4.1.1278.gc75be
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 10/11] ata: fix sparse warning in pata_acpi.c
drivers/ata/pata_acpi.c:80:2: warning: returning void-valued expression
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
drivers/ata/pata_acpi.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/pata_acpi.c b/drivers/ata/pata_acpi.c
index 244098a..bdc3b9d 100644
--- a/drivers/ata/pata_acpi.c
+++ b/drivers/ata/pata_acpi.c
@@ -77,8 +77,8 @@ static int pacpi_cable_detect(struct ata_port *ap)
static void pacpi_error_handler(struct ata_port *ap)
{
- return ata_bmdma_drive_eh(ap, pacpi_pre_reset, ata_std_softreset,
- NULL, ata_std_postreset);
+ ata_bmdma_drive_eh(ap, pacpi_pre_reset, ata_std_softreset, NULL,
+ ata_std_postreset);
}
/**
--
1.5.4.1.1278.gc75be
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 08/11] ata: fix sparse warning in pata_jmicron.c
drivers/ata/pata_jmicron.c:118:2: warning: returning void-valued expression
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
drivers/ata/pata_jmicron.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c
index 5b8174d..00d 100644
--- a/drivers/ata/pata_jmicron.c
+++ b/drivers/ata/pata_jmicron.c
@@ -115,7 +115,8 @@ static int jmicron_pre_reset(struct ata_link *link,
unsigned long deadline)
static void jmicron_error_handler(struct ata_port *ap)
{
- return ata_bmdma_drive_eh(ap, jmicron_pre_reset, ata_std_softreset,
NULL, ata_std_postreset);
+ ata_bmdma_drive_eh(ap, jmicron_pre_reset, ata_std_softreset, NULL,
+ ata_std_postreset);
}
/* No PIO or DMA methods needed for this device */
--
1.5.4.1.1278.gc75be
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 06/11] ata: sparse fixes for pata_amd.c
drop return statement.
drivers/ata/pata_amd.c:149:2: warning: returning void-valued expression
Commit ce54d1616302117fa98513ae916bbe1c02ea pata_amd: update mode selection
for NV PATAs
added the initializer for nv_mode_filter but missed deleting the previously
set mode_filter
drivers/ata/pata_amd.c:509:3: warning: Initializer entry defined twice
drivers/ata/pata_amd.c:521:3: also defined here
drivers/ata/pata_amd.c:544:3: warning: Initializer entry defined twice
drivers/ata/pata_amd.c:556:3: also defined here
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
drivers/ata/pata_amd.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/ata/pata_amd.c b/drivers/ata/pata_amd.c
index ea567e2..4b8d9b5 100644
--- a/drivers/ata/pata_amd.c
+++ b/drivers/ata/pata_amd.c
@@ -146,9 +146,8 @@ static int amd_pre_reset(struct ata_link *link, unsigned
long deadline)
static void amd_error_handler(struct ata_port *ap)
{
- return ata_bmdma_drive_eh(ap, amd_pre_reset,
- ata_std_softreset, NULL,
- ata_std_postreset);
+ ata_bmdma_drive_eh(ap, amd_pre_reset, ata_std_softreset, NULL,
+ ata_std_postreset);
}
static int amd_cable_detect(struct ata_port *ap)
@@ -506,7 +505,6 @@ static struct ata_port_operations amd133_port_ops = {
static struct ata_port_operations nv100_port_ops = {
.set_piomode= nv100_set_piomode,
.set_dmamode= nv100_set_dmamode,
- .mode_filter= ata_pci_default_filter,
.tf_load= ata_tf_load,
.tf_read= ata_tf_read,
.check_status = ata_check_status,
@@ -541,7 +539,6 @@ static struct ata_port_operations nv100_port_ops = {
static struct ata_port_operations nv133_port_ops = {
.set_piomode= nv133_set_piomode,
.set_dmamode= nv133_set_dmamode,
- .mode_filter= ata_pci_default_filter,
.tf_load= ata_tf_load,
.tf_read= ata_tf_read,
.check_status = ata_check_status,
--
1.5.4.1.1278.gc75be
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 07/11] ata: fix sparse warning in pata_cs5536.c
Everybody passes in a u32...why fight it.
drivers/ata/pata_cs5536.c:124:26: warning: incorrect type in argument 3
(different signedness)
drivers/ata/pata_cs5536.c:124:26:expected int *val
drivers/ata/pata_cs5536.c:124:26:got unsigned int *
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
drivers/ata/pata_cs5536.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/pata_cs5536.c b/drivers/ata/pata_cs5536.c
index d753e56..c71505e 100644
--- a/drivers/ata/pata_cs5536.c
+++ b/drivers/ata/pata_cs5536.c
@@ -85,7 +85,7 @@ static const u8 pci_reg[4] = {
PCI_IDE_CFG, PCI_IDE_DTC, PCI_IDE_CAST, PCI_IDE_ETC,
};
-static inline int cs5536_read(struct pci_dev *pdev, int reg, int *val)
+static inline int cs5536_read(struct pci_dev *pdev, int reg, u32 *val)
{
if (unlikely(use_msr)) {
u32 dummy;
--
1.5.4.1.1278.gc75be
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 04/11] ata: fix sparse warnings in sata_mv.c
pp is never used again in this function, no need to declare a
new one.
drivers/ata/sata_mv.c:1545:24: warning: symbol 'pp' shadows an earlier one
drivers/ata/sata_mv.c:1501:22: originally declared here
drivers/ata/sata_mv.c:1553:24: warning: symbol 'pp' shadows an earlier one
drivers/ata/sata_mv.c:1501:22: originally declared here
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
drivers/ata/sata_mv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 04b5717..2ecd44d 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -1542,7 +1542,7 @@ static void mv_err_intr(struct ata_port *ap, struct
ata_queued_cmd *qc)
eh_freeze_mask = EDMA_EH_FREEZE_5;
if (edma_err_cause & EDMA_ERR_SELF_DIS_5) {
- struct mv_port_priv *pp = ap->private_data;
+ pp = ap->private_data;
pp->pp_flags &= ~MV_PP_FLAG_EDMA_EN;
ata_ehi_push_desc(ehi, "EDMA self-disable");
}
@@ -1550,7 +1550,7 @@ static void mv_err_intr(struct ata_port *ap, struct
ata_queued_cmd *qc)
eh_freeze_mask = EDMA_EH_FREEZE;
if (edma_err_cause & EDMA_ERR_SELF_DIS) {
- struct mv_port_priv *pp = ap->private_data;
+ pp = ap->private_data;
pp->pp_flags &= ~MV_PP_FLAG_EDMA_EN;
ata_ehi_push_desc(ehi, "EDMA self-disable");
}
--
1.5.4.1.1278.gc75be
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 05/11] ata: replace macro with static inline in libata.h
Avoid a metric ton of sparse warnings like:
drivers/ata/pata_ali.c:176:14: warning: symbol '__x' shadows an earlier one
drivers/ata/pata_ali.c:176:14: originally declared here
Due to nesting min_t macro inside max_t macro which both use a __x
identifier internally.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
include/linux/libata.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/linux/libata.h b/include/linux/libata.h
index bc5a8d0..2845983 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -764,7 +764,11 @@ struct ata_timing {
unsigned short udma;/* t2CYCTYP/2 */
};
-#define FIT(v, vmin, vmax) max_t(short, min_t(short, v, vmax), vmin)
+static inline short FIT(short v, short vmin, short vmax)
+{
+ short tmp = min_t(short, v, vmax);
+ return max_t(short, tmp, vmin);
+}
extern const unsigned long sata_deb_timing_normal[];
extern const unsigned long sata_deb_timing_hotplug[];
--
1.5.4.1.1278.gc75be
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 03/11] ata: fix sparse warning in sata_via.c
drivers/ata/sata_via.c:336:2: warning: returning void-valued expression
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
drivers/ata/sata_via.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/sata_via.c b/drivers/ata/sata_via.c
index 30caa03..0d03f44 100644
--- a/drivers/ata/sata_via.c
+++ b/drivers/ata/sata_via.c
@@ -333,8 +333,8 @@ static int vt6420_prereset(struct ata_link *link, unsigned
long deadline)
static void vt6420_error_handler(struct ata_port *ap)
{
- return ata_bmdma_drive_eh(ap, vt6420_prereset, ata_std_softreset,
- NULL, ata_std_postreset);
+ ata_bmdma_drive_eh(ap, vt6420_prereset, ata_std_softreset, NULL,
+ ata_std_postreset);
}
static int vt6421_pata_cable_detect(struct ata_port *ap)
--
1.5.4.1.1278.gc75be
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 02/11] ata: fix sparse warning in sata_promise.c
drivers/ata/sata_promise.c:546:15: warning: symbol 'len' shadows an earlier one
drivers/ata/sata_promise.c:538:6: originally declared here
len is set again immediately after the loop, so this is safe.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
drivers/ata/sata_promise.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/sata_promise.c b/drivers/ata/sata_promise.c
index a07d319..f251a5f 100644
--- a/drivers/ata/sata_promise.c
+++ b/drivers/ata/sata_promise.c
@@ -543,7 +543,7 @@ static void pdc_fill_sg(struct ata_queued_cmd *qc)
idx = 0;
for_each_sg(qc->sg, sg, qc->n_elem, si) {
u32 addr, offset;
- u32 sg_len, len;
+ u32 sg_len;
/* determine if physical DMA addr spans 64K boundary.
* Note h/w doesn't support 64-bit, so we unconditionally
--
1.5.4.1.1278.gc75be
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 01/11] ata: fix sparse warning in ata_piix.c
drivers/ata/ata_piix.c:1655:8: warning: symbol 'rc' shadows an earlier one
drivers/ata/ata_piix.c:1616:6: originally declared here
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
drivers/ata/ata_piix.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 9c2515f..752e7d2 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -1652,7 +1652,7 @@ static int __devinit piix_init_one(struct pci_dev *pdev,
u8 tmp;
pci_read_config_byte(pdev, PIIX_SCC, );
if (tmp == PIIX_AHCI_DEVICE) {
- int rc = piix_disable_ahci(pdev);
+ rc = piix_disable_ahci(pdev);
if (rc)
return rc;
}
--
1.5.4.1.1278.gc75be
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: parisc compile error
On Wed, Feb 13, 2008 at 07:49:12AM +0100, rubisher wrote:
> --- include/asm-parisc/pgtable.h.Orig 2007-10-22 08:19:20.0 +
> +++ include/asm-parisc/pgtable.h 2008-02-12 16:28:36.0 +
> +extern void *vmalloc_start;
> +#define PCXL_DMA_MAP_SIZE (8*1024*1024)
> +#define VMALLOC_START ((unsigned long)vmalloc_start)
> +/* this is a fixmap remnant, see fixmap.h */
> +#define VMALLOC_END (KERNEL_MAP_END)
> +
i moved this to fixmap.h, since i think it makes more sense there,
really.
> static inline void pte_free_kernel(struct mm_struct *mm, struct page *pte)
> {
> pgtable_page_dtor(pte);
> pte_free_kernel(page_address((pte));
> }
>
this is a stunning bit of ignorant patching courtesy of
2f569afd9ced9ebec9a6eb3dbf6f83429be0a7b4 which:
-#define pte_free(mm, page) pte_free_kernel(page_address(page))
+static inline void pte_free_kernel(struct mm_struct *mm, struct page
*pte)
+{
+ pgtable_page_dtor(pte);
+ pte_free_kernel(page_address((pte));
+}
only wrong on *two* counts.
anyway, fixed this up. sigh.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] PCI: remove initial bios sort of PCI devices on x86
On Wed, Feb 13, 2008 at 03:40:29PM -0800, Greg KH wrote: > We currently keep 2 lists of PCI devices in the system, one in the > driver core, and one all on its own. This second list is sorted at boot > time, in "BIOS" order, to try to remain compatible with older kernels > (2.2 and earlier days). There was also a "nosort" option to turn this > sorting off, to remain compatible with even older kernel versions, but > that just ends up being what we have been doing from 2.5 days... > > Unfortunately, the second list of devices is not really ever used to > determine the probing order of PCI devices or drivers[1]. That is done > using the driver core list instead. This change happened back in the > early 2.5 days. > > Relying on BIOS ording for the binding of drivers to specific device > names is problematic for many reasons, and userspace tools like udev > exist to properly name devices in a persistant manner if that is needed, > no reliance on the BIOS is needed. > > Matt Domsch and others at Dell noticed this back in 2006, and added a > boot option to sort the PCI device lists (both of them) in a > breadth-first manner to help remain compatible with the 2.4 order, if > needed for any reason. This option is not going away, as some systems > rely on them. > > This patch removes the sorting of the internal PCI device list in "BIOS" > mode, as it's not needed at all anymore, and hasn't for many years. > I've also removed the PCI flags for this from some other arches that for > some reason defined them, but never used them. > > This should not change the ordering of any drivers or device probing. Good plan. I'll be glad when the vestigal internal PCI device list is gone too. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Module loading/unloading and "The Stop Machine"
On 2/8/08, Max Krasnyansky <[EMAIL PROTECTED]> wrote: > Hi Rusty, > > I was hopping you could answer a couple of questions about module > loading/unloading > and the stop machine. I'm curious to know why it is called `stop machine', which is a queer name without any relationship with its function. Regards, Jike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pci_get_device_reverse(), why does Calgary need this?
On Thu, Feb 14, 2008 at 01:02:55AM +0100, Bartlomiej Zolnierkiewicz wrote: > On Thursday 14 February 2008, Greg KH wrote: > > On Wed, Feb 13, 2008 at 11:20:36PM +0100, Bartlomiej Zolnierkiewicz wrote: > > > On Wednesday 13 February 2008, Greg KH wrote: > > > > On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg KH wrote: > > > > > On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz > > > > > wrote: > > > > > > On Wednesday 13 February 2008, Greg KH wrote: > > > > > > > On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote: > > > > > > > > > Why does the calgary driver need this? Can we just use > > > > > > > > > pci_get_device() > > > > > > > > > instead? Why do you need to walk the device list backwards? > > > > > > > > > Do you get > > > > > > > > > false positives going forward? > > > > > > > > > > > > > > > > It doesn't look to be performance critical so the driver can > > > > > > > > pci_get_device until the end and use the final hit anyway. > > > > > > > > > > > > > > That would make more sense. > > > > > > > > > > > > > > > IDE reverse is more problematic but nobody seems to use it. > > > > > > > > > > > > > > I've seen two posters say they use it. I'm wondering what it is > > > > > > > really > > > > > > > solving if they use it, and why if it's really needed, scsi never > > > > > > > had to > > > > > > > implement such a hack... > > > > > > > > > > > > It is no longer solving anything, just adds more pain. ;) > > > > > > > > > > > > [ The option comes from 2.2.x (so long before LABEL=/ and > > > > > > /dev/disk/by-id/ > > > > > > became popular). Some "off-board" controllers integrated on > > > > > > motherboards > > > > > > used to appear before "on-board" IDE on PCI bus so this option > > > > > > was meant > > > > > > to preserve the legacy ordering. ] > > > > > > > > > > > > Since it is valid only when "Probe IDE PCI devices in the PCI bus > > > > > > order > > > > > > (DEPRECATED)" config option is used it is already on its way out > > > > > > (though > > > > > > marking it as obsoleted would make it more explicit). > > > > > > > > > > > > I think that removing "ide=reverse" in 2.6.26 would be OK... > > > > > > > > > > Great, thanks for your blessing. I'll make up a patch and send it to > > > > > you for approval. > > > > > > > > How does the patch below look? I didn't want to remove the whole config > > > > option, as there is more to the logic than just the "reverse order" > > > > stuff there. > > > > > > looks fine, > > > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> > > > > Thanks. > > > > > > If you don't mind, can I take this through the PCI tree so as to allow > > > > the removal of this pci function afterwards? > > > > > > [...] > > > > > > great, could you also: > > > - rebase it on top of the patch below > > > - forward the patch below to Linus for 2.6.25 > > > > Sure, you want this to go in for .25, but not the one I just posted > > removing this option, correct? That should wait for .26? > > Yes, lets give people the final call before actually removing this option > (unless of course there is some urgent reason for removing it in .25). No, no rush from me, I'll queue this up and send it to Linus in my next batch. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Handshaking on USB serial devices
On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote: > Consider a USB-attached serial port that is set to do RTS/CTS (or > DSR/DTR) handshaking: What stops the kernel sending more data to it when > the remote end lowers CTS (or DTR)? The tty layer should look at the proper flags and not send data on to the driver in this kind of instance. Is this not happening properly for you? If so, which USB serial driver? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SCSI] gdth: update deprecated pci_find_device
Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99109301d103fbf0de43fc5a580a406c12a501e0
Commit: 99109301d103fbf0de43fc5a580a406c12a501e0
Parent: 61c92814dc324b541391757062ff02fbf3b08086
Author: Sergio Luis <[EMAIL PROTECTED]>
AuthorDate: Tue Feb 12 20:48:03 2008 -0300
Committer: James Bottomley <[EMAIL PROTECTED]>
CommitDate: Wed Feb 13 09:33:10 2008 -0600
[SCSI] gdth: update deprecated pci_find_device
Fix compilation warning in gdth.c, which was using the deprecated
pci_find_device.
drivers/scsi/gdth.c:645: warning: 'pci_find_device' is deprecated (declared at include/linux/pci.h:495)
Changing it to use pci_get_device, instead.
Signed-off-by: Sergio Luis <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
drivers/scsi/Kconfig |2 +-
drivers/scsi/gdth.c |7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index a5f0aaa..a7a0813 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -722,7 +722,7 @@ config SCSI_FD_MCS
config SCSI_GDTH
tristate "Intel/ICP (former GDT SCSI Disk Array) RAID Controller
support"
- depends on (ISA || EISA || PCI) && SCSI && ISA_DMA_API && PCI_LEGACY
+ depends on (ISA || EISA || PCI) && SCSI && ISA_DMA_API
---help---
Formerly called GDT SCSI Disk Array Controller Support.
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 7079fef..6d67f5c 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -642,12 +642,15 @@ static void __init gdth_search_dev(gdth_pci_str *pcistr,
ushort *cnt,
*cnt, vendor, device));
pdev = NULL;
-while ((pdev = pci_find_device(vendor, device, pdev))
+while ((pdev = pci_get_device(vendor, device, pdev))
!= NULL) {
if (pci_enable_device(pdev))
continue;
-if (*cnt >= MAXHA)
+if (*cnt >= MAXHA) {
+pci_dev_put(pdev);
return;
+}
+
Why no pci_dev_put() in the module cleanup path?
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: Strange hang on ia64 with CONFIG_PRINTK_TIME=y
> I'll take a closer look at what is needed tomorrow. Hi Tony, Just curious -- can you reproduce the same problem with CONFIG_PRINTK_TIME as I'm seeing? If not I'm happy to test anything you want to try. The strange thing is that Ingo's patch to make cpu_clock() a NOP until after sched_init() didn't fix things for me... - 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/
dma engine drivers for 2.6.25?
Dan, What's going on with the dma engine drivers for 2.6.25? We had a Freescale dma driver from Zhang Wei queued up but seems to have been lost. - k -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] adfs: trivial sparse fix
On Wed, 2008-02-13 at 19:39 -0800, Andrew Morton wrote:
> On Wed, 13 Feb 2008 18:07:48 -0800 Harvey Harrison <[EMAIL PROTECTED]> wrote:
>
> > fs/adfs/dir_f.c:126:4: warning: do-while statement is not a compound
> > statement
> >
> > Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
> > ---
> > fs/adfs/dir_f.c |4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/adfs/dir_f.c b/fs/adfs/dir_f.c
> > index b9b2b27..ea7df21 100644
> > --- a/fs/adfs/dir_f.c
> > +++ b/fs/adfs/dir_f.c
> > @@ -122,9 +122,9 @@ adfs_dir_checkbyte(const struct adfs_dir *dir)
> > ptr.ptr8 = bufoff(bh, i);
> > end.ptr8 = ptr.ptr8 + last - i;
> >
> > - do
> > + do {
> > dircheck = *ptr.ptr8++ ^ ror13(dircheck);
> > - while (ptr.ptr8 < end.ptr8);
> > + } while (ptr.ptr8 < end.ptr8);
> > }
> >
>
> eh? It's sparse which needs fixing here, surely?
Well, I only 'fixed' it this way to match the surrounding code. The
warning is a little odd.
Harvey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] adfs: trivial sparse fix
On Wed, 13 Feb 2008 18:07:48 -0800 Harvey Harrison <[EMAIL PROTECTED]> wrote:
> fs/adfs/dir_f.c:126:4: warning: do-while statement is not a compound statement
>
> Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
> ---
> fs/adfs/dir_f.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/adfs/dir_f.c b/fs/adfs/dir_f.c
> index b9b2b27..ea7df21 100644
> --- a/fs/adfs/dir_f.c
> +++ b/fs/adfs/dir_f.c
> @@ -122,9 +122,9 @@ adfs_dir_checkbyte(const struct adfs_dir *dir)
> ptr.ptr8 = bufoff(bh, i);
> end.ptr8 = ptr.ptr8 + last - i;
>
> - do
> + do {
> dircheck = *ptr.ptr8++ ^ ror13(dircheck);
> - while (ptr.ptr8 < end.ptr8);
> + } while (ptr.ptr8 < end.ptr8);
> }
>
eh? It's sparse which needs fixing here, surely?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] add rcu_assign_index() if ever needed
On Thu, 14 Feb 2008 09:02:09 +0530 Gautham R Shenoy <[EMAIL PROTECTED]> wrote: > > /** > > + * rcu_assign_index - assign (publicize) a index of a newly > > + * initialized array elementg that will be dereferenced by RCU > > > I hope Andrew got that one while porting against the latest -mm :) I don't actually read the comments - I just like to make sure they're there ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] samples: build fix
The samples/ subdirectory contains only modules. But the only make run done there is in commands for vmlinux. I can't see why this was ever done in this nonstandard fashion. As things stand, the modules don't get built by 'make modules'. I didn't make the addition of the directory use core-$(CONFIG_SAMPLES) because there is no other conditional like that in the top-level Makefile and samples/Makefile already uses obj-$(CONFIG_SAMPLES) as if it expects always to be included. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> --- Makefile |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index c162370..9e9ce33 100644 --- a/Makefile +++ b/Makefile @@ -602,7 +602,7 @@ export mod_strip_cmd ifeq ($(KBUILD_EXTMOD),) -core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/ +core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/ samples/ vmlinux-dirs := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \ $(core-y) $(core-m) $(drivers-y) $(drivers-m) \ @@ -802,9 +802,6 @@ vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) vmlinux.o $(kallsyms.o) ifdef CONFIG_HEADERS_CHECK $(Q)$(MAKE) -f $(srctree)/Makefile headers_check endif -ifdef CONFIG_SAMPLES - $(Q)$(MAKE) $(build)=samples -endif $(call vmlinux-modpost) $(call if_changed_rule,vmlinux__) $(Q)rm -f .old_version -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange hang on ia64 with CONFIG_PRINTK_TIME=y
> That's right. I thought you guys had something that would handle that > early on, but looking at how the trick works in the vmlinux.lds.S ia64 > uses that isn't the case. We try to get things set up pertty early ... but I agree this is fragile. Adding code to printk() to not provide a timestamp before some safe point in boot is a workaround to the current problem. But it may come back to haunt us if other per-cpu data is added that needs to be accessed early during boot. There are some changes going on at the moment on how we allocate the space for the per-cpu area. It is likely that for a non-boot cpu we might be able to get everything that we need for per-cpu access to work done in head.S before we can get to any C code. Boot cpu may be harder unless we statically allocate space for its per-cpu area in vmlinux.lds.S I'll take a closer look at what is needed tomorrow. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] SCSI bug fixes for 2.6.25-rc1
On Wed, 13 Feb 2008 19:11:53 -0600 James Bottomley <[EMAIL PROTECTED]> wrote: > > mptbase-reset-ioc-initiator-during-pci-resume.patch > > > > Fixes suspend/resume on all of Darrick's MPT cards. I first merged it > > in September 2007. > > Patch presented by LSI but has gone back with comments Five months is too long to fix a bug when someone has already sent us a patch. If they insist on being this sluggish I'd suggest that you review the patch yourself then just merge it. That will get their attention. Maybe. > > dell-cerc-support-for-megaraid_mbox.patch > > I need megaraid to sign off (and test) this one. Two months, same story. > > scsi-qlogicptic-section-fixes.patch > > > > Fixes a reference from .text into .init.text and hence might fix a > > machine crash when this driver is build into vmlinux. Merged a week ago. > > This was the one we had the alternative fix for, wasn't it ... ? In current mainline, __devinit qpti_sbus_probe() still is calling __init qpti_chain_add() (for example). So in a CONFIG_HOTPLUG kernel, hotplugging a new device (on sbus, ok, bad example ;)) will crash. But Adrian has fixed six such bugs in there, maybe one of them can hit. I don't think we've fixed these by alternative means, unless we've disabled __devinit? Still, we can discuss specific patches all day. I think there is a _general_ problem getting bugfixes, warning fixes and cleanups into scsi drivers within reasonable amounts of 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: Feature Removals for 2.6.25
> > > Ping? > > What: sk98lin network driver > > When: Feburary 2008 > > Why:In kernel tree version of driver is unmaintained. Sk98lin driver > > replaced by the skge driver. > > Who:Stephen Hemminger <[EMAIL PROTECTED]> > > > > --- > > We have been over this several times, and I thought someone had taken > over the driver and was providing patches to put it in. Both skge and > sky2 have been proposed as the replacement, people have reported > problems with each. Suggest leaving this alone until the sk98lin > actually needs work, then take it out. Problems in my problem system > have been intermittent, take 4-40 hours to show and generate no errors, > other than the driver thinks it's sending packets and the sniffer doesn't. The vendor sk98lin driver will continue it's happy life out of tree. The version in 2.6.25 is ancient and unmaintained and only supports older hardware. There are no outstanding issues with skge driver (sky2 is prone to hardware problems, but then so is vendor driver). Unfortunately, removing sk98lin seems to be the only way to make die hard users report problems. The last time we removed it, some user's of old Genesis boards showed with issues, but those are now fixed. Jeff has scheduled sk98lin for removal in 2.6.26. (and it will probably be gone from -mm before that). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Problem with recording on hda-intel (sata_sil or hda-intel bug) - HP nx6325
Grzegorz Chwesewicz wrote: Hi. Problem description: I have a problem with recording on HP nx6325 notebook (hda-intel with AD1981HD codec). Playback works fine, but after 5-10 min. of recording microphone stops working (playback works all the time). Unloading and loading sound modules fixes problem, but only for another 5-10 minutes. This problem exists from more than a year (at least from 2.6.17.13 kernel). In [1] we came to conclusion that this problem is ralated to IRQ sharing [2] (HDA Intel is on the same IRQ as sata_sil). How to reproduce the problem: 1) on one console run arecord and see the output (You should see some garbage) 2) on another console run cat /etc/* 3) at once arecord on the first console gives no output So, doing lot of hdd I/O occurs problem with mic. I had problems a few years ago with USB stopping when the screen saver kicked in, just a wild thought. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rft] s2ram wakeup moves to .c, could fix few machines
H. Peter Anvin wrote: Rafael J. Wysocki wrote: The asm() for making beeps really need to be moved to a function and cleaned up (redone in C using inb()/outb()) if they are to be retained at all. Yes, they are. For some people they're the only tool to debug broken resume. That's fine, but they should get cleaned up. /me is tempted to provide a version which can send messages in Morse Code ;) Thought someone did that a while ago. Alan Cox, maybe. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Feature Removals for 2.6.25
Harvey Harrison wrote: What: CONFIG_FORCED_INLINING When: June 2006 Why:Config option is there to see if gcc is good enough. (in january 2006). If it is, the behavior should just be the default. If it's not, the option should just go away entirely. Who:Arjan van de Ven Patch submitted to Arjan, maybe 2.6.25? --- The "good enough" of gcc may be architecture dependent. Taking the option away where it works because somewhere else it doesn't may not be the optimal solution. Ping? What: eepro100 network driver When: January 2007 Why:replaced by the e100 driver Who:Adrian Bunk <[EMAIL PROTECTED]> --- The last time we discussed this the team working on e100 said there were still issues (IIRC). Have they all been resolved? Ping? What: sk98lin network driver When: Feburary 2008 Why:In kernel tree version of driver is unmaintained. Sk98lin driver replaced by the skge driver. Who:Stephen Hemminger <[EMAIL PROTECTED]> --- We have been over this several times, and I thought someone had taken over the driver and was providing patches to put it in. Both skge and sky2 have been proposed as the replacement, people have reported problems with each. Suggest leaving this alone until the sk98lin actually needs work, then take it out. Problems in my problem system have been intermittent, take 4-40 hours to show and generate no errors, other than the driver thinks it's sending packets and the sniffer doesn't. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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][I/OAT]: Remove duplicate assignation in dma_skb_copy_datagram_iovec
>-Original Message-
>From: Brice Goglin [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, February 13, 2008 1:05 PM
>To: Nelson, Shannon; Williams, Dan J
>Cc: Leech, Christopher; LKML
>Subject: [PATCH][I/OAT]: Remove duplicate assignation in
>dma_skb_copy_datagram_iovec
>
>[I/OAT]: Remove duplicate assignation in dma_skb_copy_datagram_iovec
>
>No need to compute copy twice in the frags loop in
>dma_skb_copy_datagram_iovec().
>
>Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
>---
> user_dma.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/net/core/user_dma.c b/net/core/user_dma.c
>index 0ad1cd5..c77aff9 100644
>--- a/net/core/user_dma.c
>+++ b/net/core/user_dma.c
>@@ -75,7 +75,7 @@ int dma_skb_copy_datagram_iovec(struct
>dma_chan *chan,
>
> end = start + skb_shinfo(skb)->frags[i].size;
> copy = end - offset;
>- if ((copy = end - offset) > 0) {
>+ if (copy > 0) {
> skb_frag_t *frag = _shinfo(skb)->frags[i];
> struct page *page = frag->page;
>
Acked-by: Shannon Nelson <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xtime_lock vs update_process_times
On Wed, Feb 13, 2008 at 09:33:16PM +0100, Peter Zijlstra wrote: > Subject: xtime_lock vs update_process_times > From: Peter Zijlstra <[EMAIL PROTECTED]> > > ( repost from: http://lkml.org/lkml/2008/1/28/101 ) > > Commit: d3d74453c34f8fd87674a8cf5b8a327c68f22e99 > Subject: hrtimer: fixup the HRTIMER_CB_IRQSAFE_NO_SOFTIRQ fallback > > Broke several archs, since only Russel bothered to merge the fix, > and Greg to ACK his arch, I'm sending this for merger. > > I have confirmation that the Alpha bit results in a booting kernel. > That leaves: blackfin, frv, sh and sparc untested. > > The deadlock in question was found by Russell: > > IRQ handle > -> timer_tick() - xtime seqlock held for write > -> update_process_times() > -> run_local_timers() > -> hrtimer_run_queues() > -> hrtimer_get_softirq_time() - tries to get a read lock > > Now, Thomas assures me the fix is trivial, only do_timer() needs to be > done under the xtime_lock, and update_process_times() can savely be removed > from under it. > The SH bits also work fine. I've already merged that part in to my tree. Thanks, Peter. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 xen pvops regression
On Wed, Feb 13, 2008 at 10:59:33PM +1100, Jeremy Fitzhardinge wrote: >> I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day. >> Unfortunately, I didn't get very far very fast, as the domain just crashed >> immediately upon booting, without any direct feedback (I did have messages >> on the xen message buffer, which helped). This even with earlyprintk turned >> on. >> >> After a long, arduous journey, I managed to track this down to the following: >> >> -- >> commit 551889a6e2a24a9c06fd453ea03b57b7746ffdc0 I'm seeing the same problem, with no messages at all from xen other than "domain crashed, restart disabled" in xend.log. I got a different commit in my bisect, 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395 (i386 boot: replace boot_ioremap with enhanced bt_ioremap - enhance bt_ioremap). I started from yesterday's 96b5a46e2a72dc1829370c87053e0cd558d58bc0 (WMI: initialize wmi_blocks.list even if ACPI is disabled) and a known good 9b73e76f3cf63379dcf45fcd4f112f5812418d0a (Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6). > Although I'm on vacation, I happened to download a recent copy of > x86.git and found that it crashes early. Here's a couple of patches to > apply; I don't know if they apply to current git, but I hope it helps. > Subject: x86/early_ioremap: don't assume we're using swapper_pg_dir > Subject: xen: unpin initial Xen pagetable once we're finished with it After my bisect was done, I re-pulled from Linus and discovered these patches. Searching for these emails, they certainly sound like my problem. But the kernel does not boot, commit 10270d4838bdc493781f5a1cf2e90e9c34c9142f (acpi: fix acpi_os_read_pci_configuration() misuse of raw_pci_read()). Still no output from Xen - pygrub selects the kernel, and then the domain just dies back to the dom0 shell. Attached are my latest .config and my bisect log. Joel -- "The real reason GNU ls is 8-bit-clean is so that they can start using ISO-8859-1 option characters." - Christopher Davis ([EMAIL PROTECTED]) Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc1 # Wed Feb 13 17:45:45 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="-bisectme" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y # CONFIG_TASK_XACCT is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y
Driver removals
Just a general thought on removing drivers in general, when a driver is removed because there's a better one, it would be good to have either a message which shows up at "make oldconfig" time, or a file listing the driver(s) which replace it. Half the resistance to removing drivers is finding what is supposed to replace the driver. For instance a list of all the drivers Adrian Bunk has suggested to replace sk98lin, so users have something better than searching the source code and/or LKML archive to find the next thing to try. In general, if a driver works and is being used, until it *needs* attention I see no reason to replace it. I don't agree that "it forces people to try the new driver" is a valid reason, being unmaintained is only a problem if it needs maintenance. I am not going to reopen that topic, I'm simply noting a general opposition to unfunded mandates, and requiring changes to kernel, module and/or rc.local config is just that. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] SCSI bug fixes for 2.6.25-rc1
On Wed, 2008-02-13 at 17:22 -0800, David Miller wrote: > From: James Bottomley <[EMAIL PROTECTED]> > Date: Wed, 13 Feb 2008 19:11:53 -0600 > > > > > On Wed, 2008-02-13 at 16:16 -0800, Andrew Morton wrote: > > > kill-warnings-in-mptbaseh-on-parisc64.patch > > > > > Warning fixes. > > > > Not sure ... LSI is supposed to be processing this. > > James, please don't push build warning fixes and the like back to the > driver maintainers. > > This is your domain as SCSI maintainer, and you should integrate these > kinds of things directly and as promptly as possible. > > This is doubly true if the "driver maintainer" can't be bothered > to ACK or fixup the patch for months. > > Otherwise this kind of stuff rots, and diligent people like Andrew > (and the patch submitter, whoever that might be) get extremely > frustrated. LSI did ask to merge through their patch process, but I agree this one's been hanging around for a bit long. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] adfs: trivial sparse fix
fs/adfs/dir_f.c:126:4: warning: do-while statement is not a compound statement
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
fs/adfs/dir_f.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/adfs/dir_f.c b/fs/adfs/dir_f.c
index b9b2b27..ea7df21 100644
--- a/fs/adfs/dir_f.c
+++ b/fs/adfs/dir_f.c
@@ -122,9 +122,9 @@ adfs_dir_checkbyte(const struct adfs_dir *dir)
ptr.ptr8 = bufoff(bh, i);
end.ptr8 = ptr.ptr8 + last - i;
- do
+ do {
dircheck = *ptr.ptr8++ ^ ror13(dircheck);
- while (ptr.ptr8 < end.ptr8);
+ } while (ptr.ptr8 < end.ptr8);
}
/*
--
1.5.4.1.1278.gc75be
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] x86: make struct efi_phys static
On Wed, 2008-02-13 at 23:29 +0200, Adrian Bunk wrote: > Thuis patch makes the needlessly global struct efi_phys static. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > --- > 3002c1d384e748f2928823ff4b10ed4d6082dceb > diff --git a/arch/x86/kernel/efi.c b/arch/x86/kernel/efi.c > index 1411324..1211ab2 100644 > --- a/arch/x86/kernel/efi.c > +++ b/arch/x86/kernel/efi.c > @@ -54,7 +54,7 @@ EXPORT_SYMBOL(efi); > > struct efi_memory_map memmap; > > -struct efi efi_phys __initdata; > +static struct efi efi_phys __initdata; > static efi_system_table_t efi_systab __initdata; > > static int __init setup_noefi(char *arg) Reviewed-by: Huang Ying <[EMAIL PROTECTED]> Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4 resend] [x86] Add generic GPIO support to x86
On Wednesday 13 February 2008, Andrew Morton wrote:
> It would be more modern to have a which takes care of
> cruddy details, but it's getting too late for that.
Sort of like this? For drivers that don't want to list themselves
in Kconfig as depending on GENERIC_GPIO (e.g. one NAND driver I heard
about), this lets them use ... existing code can't
break, and it won't hurt if new code uses this.
- Dave
== CUT HERE
Add a defining fail/warn stubs for GPIO calls on
platforms that don't support the GPIO programming interface. It
includes the arch-specific interface glue otherwise.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
include/linux/gpio.h | 93 +++
1 file changed, 93 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ g26/include/linux/gpio.h2008-02-13 17:40:06.0 -0800
@@ -0,0 +1,93 @@
+#ifndef __LINUX_GPIO_H
+#define __LINUX_GPIO_H
+
+#ifdef CONFIG_GENERIC_GPIO
+#include
+
+#else
+
+/*
+ * Some platforms don't support the GPIO programming interface.
+ *
+ * In case some driver uses it anyway (it should normally have
+ * depended on GENERIC_GPIO), these routines help the compiler
+ * optimize out much GPIO-related code ... or trigger a runtime
+ * warning when something is wrongly called.
+ */
+
+static inline int gpio_is_valid(int number)
+{
+ return 0;
+}
+
+static inline int gpio_request(unsigned gpio, const char *label)
+{
+ return -EINVAL;
+}
+
+static inline void gpio_free(unsigned gpio)
+{
+ /* GPIO can never have been requested */
+ WARN_ON(1);
+}
+
+static inline int gpio_direction_input(unsigned gpio)
+{
+ return -EINVAL;
+}
+
+static inline int gpio_direction_output(unsigned gpio, int value)
+{
+ return -EINVAL;
+}
+
+static inline int gpio_get_value(unsigned gpio)
+{
+ /* GPIO can never have been requested or set as {in,out}put */
+ WARN_ON(1);
+ return 0;
+}
+
+static inline void gpio_set_value(unsigned gpio, int value)
+{
+ /* GPIO can never have been requested or set as output */
+ WARN_ON(1);
+}
+
+static int gpio_cansleep(unsigned gpio)
+{
+ /* GPIO can never have been requested or set as {in,out}put */
+ WARN_ON(1);
+ return 0;
+}
+
+static inline int gpio_get_value_cansleep(unsigned gpio)
+{
+ /* GPIO can never have been requested or set as {in,out}put */
+ WARN_ON(1);
+ return 0;
+}
+
+static inline void gpio_set_value_cansleep(unsigned gpio, int value)
+{
+ /* GPIO can never have been requested or set as output */
+ WARN_ON(1);
+}
+
+static inline int gpio_to_irq(unsigned gpio)
+{
+ /* GPIO can never have been requested or set as input */
+ WARN_ON(1);
+ return -EINVAL;
+}
+
+static inline int irq_to_gpio(unsigned irq)
+{
+ /* irq can never have been returned from gpio_to_irq() */
+ WARN_ON(1);
+ return -EINVAL;
+}
+
+#endif
+
+#endif /* __LINUX_GPIO_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] inotify: make variables static in inotify_user.c
inotify_max_user_instances, inotify_max_user_watches, inotify_max_queued_events can all be made static. Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> --- fs/inotify_user.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/inotify_user.c b/fs/inotify_user.c index 3ab09a6..9ef4d21 100644 --- a/fs/inotify_user.c +++ b/fs/inotify_user.c @@ -41,9 +41,9 @@ static struct kmem_cache *event_cachep __read_mostly; static struct vfsmount *inotify_mnt __read_mostly; /* these are configurable via /proc/sys/fs/inotify/ */ -int inotify_max_user_instances __read_mostly; -int inotify_max_user_watches __read_mostly; -int inotify_max_queued_events __read_mostly; +static int inotify_max_user_instances __read_mostly; +static int inotify_max_user_watches __read_mostly; +static int inotify_max_queued_events __read_mostly; /* * Lock ordering: -- 1.5.4.1.1278.gc75be -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.24-rt1] SMC91x: Use special_lock when CONFIG_PREEMPT_[HARD|SOFT]IRQS
The smc_special_locks should also be used when either softIRQs or hard IRQs are preempted which may lead to the same problems as under SMP. Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]> --- drivers/net/smc91x.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c index f198c49..be62616 100644 --- a/drivers/net/smc91x.c +++ b/drivers/net/smc91x.c @@ -530,7 +530,8 @@ static inline void smc_rcv(struct net_device *dev) } } -#ifdef CONFIG_SMP +#if defined(CONFIG_SMP) || \ +defined(CONFIG_PREEMPT_SOFTIRQS) || defined(CONFIG_PREEMPT_HARDIRQS) /* * On SMP we have the following problem: * -- 1.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: EFI runtime code mapping enhancement
On Wed, 2008-02-13 at 12:32 +0100, Andi Kleen wrote: > Huang, Ying wrote: > > This patch enhances EFI runtime code memory mapping as following: > > > > - Move __supported_pte_mask & _PAGE_NX checking before invoking > > runtime_code_page_mkexec(). This makes it possible for compiler to > > eliminate runtime_code_page_mkexec() on machine without NX support. > > > > - Use set_memory_x/nx in early_mapping_set_exec(). This eliminates the > > duplicated implementation. > > It's a inefficiency because you split up the 2MB (or 1GB) pages > in the direct mapping, although that is not strictly needed. This > means everybody who happens to use memory in same 2M/1G region > will eat unnecessary TLB misses. > > It would be generally better to only execute your code in > ioremap_cache() because that won't affect anybody else. > > Eventually set_memory_x() will work correctly for ioremap() too > so that should work then. For EFI runtime service in virtual mode, using direct mapping is mainly for kexec, where EFI runtime memory area need to be mapped at same virtual address across kexec. For performance reason, it may be better to use fixmap only instead. But this will waste some fixmap space. But this patch is for EFI runtime service in physical mode (in 64 mode, this needs a direct mapping page table), there are two choice. - Use direct mapping of kernel, clean NX bit from kernel page table temporarily before/after EFI calling. This needs not split 2M page into 4K pages, because the region changed is aligned with 2M. And, because the changing is temporary, a little larger region is not a big issue. - Construct a direct mapping page table for EFI only. I think this is not good too. The code will be duplicated with kernel page table initialization code. An issue of this patch is that it does not work with 1G page. Aligning EFI runtime code region with 1G seems not a good idea too. I think a better method is adding a non-split mode to c_p_a(), where the region changed is enlarged if necessary to avoid page allocation. This can be used to implement early_set_memory_xx(). The early_set_memory_xx() instead of duplicated c_p_a() variant can be used by EFI code. Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] make secmark_tg_destroy() static
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 23:29:40 +0200 > This patch makes the needlessly global secmark_tg_destroy() static. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] printk: clean up recursion check related static variables
Make printk_recursion_bug_msg static, drop printk prefix from recurson
variables and move them into vprintk().
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
This is slightly modified version of the clean up part. I don't think
it's wise to pull out all static variables out of functions. Thanks.
kernel/printk.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
Index: work/kernel/printk.c
===
--- work.orig/kernel/printk.c
+++ work/kernel/printk.c
@@ -613,15 +613,13 @@ asmlinkage int printk(const char *fmt, .
return r;
}
-/* cpu currently holding logbuf_lock */
-static volatile unsigned int printk_cpu = UINT_MAX;
-
-const char printk_recursion_bug_msg [] =
- KERN_CRIT "BUG: recent printk recursion!\n";
-static int printk_recursion_bug;
-
asmlinkage int vprintk(const char *fmt, va_list args)
{
+ /* cpu currently holding logbuf_lock */
+ static volatile unsigned int printk_cpu = UINT_MAX;
+ static const char recursion_bug_msg [] =
+ KERN_CRIT "BUG: recent printk recursion!\n";
+ static int recursion_bug;
static int log_level_unknown = 1;
static char printk_buf[1024];
@@ -649,7 +647,7 @@ asmlinkage int vprintk(const char *fmt,
* it can be printed at the next appropriate moment:
*/
if (!oops_in_progress) {
- printk_recursion_bug = 1;
+ recursion_bug = 1;
goto out_restore_irqs;
}
zap_locks();
@@ -659,10 +657,10 @@ asmlinkage int vprintk(const char *fmt,
spin_lock(_lock);
printk_cpu = this_cpu;
- if (printk_recursion_bug) {
- printk_recursion_bug = 0;
- strcpy(printk_buf, printk_recursion_bug_msg);
- printed_len = sizeof(printk_recursion_bug_msg);
+ if (recursion_bug) {
+ recursion_bug = 0;
+ strcpy(printk_buf, recursion_bug_msg);
+ printed_len = sizeof(recursion_bug_msg);
}
/* Emit the output into the temporary buffer */
printed_len += vscnprintf(printk_buf + printed_len,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] unexport __inet_hash_connect
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 23:29:46 +0200 > This patch removes the unused EXPORT_SYMBOL_GPL(__inet_hash_connect). > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question on timekeeping subsystem
Hi, On Wednesday 13. February 2008, Francis Moreau wrote: > First I tried to find some documentation on the current implementation > but haven't found any thing really usefull. Specially there's nothing about > it in Documentation/ directory. Please correct me if I'm already wrong. > > Actually I read the implementation of update_wall_time() and I really fail > to understand how it works. This is probably because I don't know > what "xtime_nsec" and "error" fields in clocksource struct are for. > These fields are not documented anywhere in the source code so it > should be obvious but unfortunately not for me. These mails should help to understand, what this code does: http://lkml.org/lkml/2006/3/4/61 http://lkml.org/lkml/2006/4/3/205 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 1/2] remove rcu_assign_pointer(NULL) penalty with type/macro safety
On Wed, 13 Feb 2008 17:34:27 -0800
"Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 13, 2008 at 04:53:56PM -0800, Stephen Hemminger wrote:
> > On Wed, 13 Feb 2008 16:42:53 -0800
> > "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
> > > On Wed, Feb 13, 2008 at 04:27:00PM -0800, Stephen Hemminger wrote:
>
> [ . . . ]
>
> > > > That is heading towards ugly... Maybe not using the macro at all (for
> > > > this case) would be best:
> > > >
> > > > static inline void node_set_parent(struct node *node, struct tnode *ptr)
> > > > {
> > > > smp_wmb();
> > > > node->parent = (unsigned long)ptr | NODE_TYPE(node);
> > > > }
> > >
> > > Or, alternatively, the rcu_assign_index() patch sent earlier to avoid
> > > the bare memory barrier?
> > >
> > > Thanx, Paul
> >
> > I am fine with rcu_assign_index(), and add a comment in node_set_parent.
>
> OK, how about the following?
>
> Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
> ---
>
> fib_trie.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff -urpNa -X dontdiff linux-2.6.25-rc1/net/ipv4/fib_trie.c
> linux-2.6.25-rc1-fib_trie-warn.compile/net/ipv4/fib_trie.c
> --- linux-2.6.25-rc1/net/ipv4/fib_trie.c 2008-02-13 14:38:12.0
> -0800
> +++ linux-2.6.25-rc1-fib_trie-warn.compile/net/ipv4/fib_trie.c
> 2008-02-13 17:31:16.0 -0800
> @@ -96,6 +96,14 @@ typedef unsigned int t_key;
> #define IS_TNODE(n) (!(n->parent & T_LEAF))
> #define IS_LEAF(n) (n->parent & T_LEAF)
>
> +/*
> + * The "parent" fields in struct node and struct leaf are really pointers,
> + * but with the possibility that the T_LEAF bit is set. Therefore, both
> + * the C compiler and RCU see them as integers rather than pointers.
> + * This in turn means that rcu_assign_index() must be used to assign
> + * values to these fields, rather than the usual rcu_assign_pointer().
> + */
> +
> struct node {
> unsigned long parent;
> t_key key;
> @@ -179,8 +187,7 @@ static inline struct tnode *node_parent_
>
> static inline void node_set_parent(struct node *node, struct tnode *ptr)
> {
> - rcu_assign_pointer(node->parent,
> -(unsigned long)ptr | NODE_TYPE(node));
> + rcu_assign_index(node->parent, (unsigned long)ptr | NODE_TYPE(node));
> }
>
> static inline struct node *tnode_get_child(struct tnode *tn, unsigned int i)
Yes, thats great.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Use ELF_CORE_EFLAGS for kcore ELF header flags.
At Tue, 12 Feb 2008 14:34:23 +0100,
Edgar E. Iglesias wrote:
>
> ELF_CORE_EFLAGS is already used by the binfmt_elf coredumper to set correct
> arch specific ELF header flags on coredumps. Use it for kcore aswell.
> This corrects kcore files for the CRIS arch and I beleive it corrects
> ordinary coredumps for the H8/300.
>
> Signed-off-by: Edgar E. Iglesias <[EMAIL PROTECTED]>
>
> ---
>
> diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
> index e78c81f..c2370c7 100644
> --- a/fs/proc/kcore.c
> +++ b/fs/proc/kcore.c
> @@ -23,6 +23,10 @@
>
> #define CORE_STR "CORE"
>
> +#ifndef ELF_CORE_EFLAGS
> +#define ELF_CORE_EFLAGS 0
> +#endif
> +
> static int open_kcore(struct inode * inode, struct file * filp)
> {
> return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
> @@ -164,11 +168,7 @@ static void elf_kcore_store_hdr(char *bufp, int nphdr,
> int dataoff)
> elf->e_entry= 0;
> elf->e_phoff= sizeof(struct elfhdr);
> elf->e_shoff= 0;
> -#if defined(CONFIG_H8300)
> - elf->e_flags= ELF_FLAGS;
> -#else
> - elf->e_flags= 0;
> -#endif
> + elf->e_flags= ELF_CORE_EFLAGS;
> elf->e_ehsize = sizeof(struct elfhdr);
> elf->e_phentsize= sizeof(struct elf_phdr);
> elf->e_phnum= nphdr;
> diff --git a/include/asm-h8300/elf.h b/include/asm-h8300/elf.h
> index 26bfc7e..806f20b 100644
> --- a/include/asm-h8300/elf.h
> +++ b/include/asm-h8300/elf.h
> @@ -32,6 +32,8 @@ typedef unsigned long elf_fpregset_t;
> #define ELF_FLAGS 0x82
> #endif
>
> +#define ELF_CORE_EFLAGS ELF_FLAGS
> +
> #define ELF_PLAT_INIT(_r)_r->er1 = 0
>
> #define USE_ELF_CORE_DUMP
Hmm...
I think more simple.
--- include/asm-h8300/elf.h~2008-02-12 17:42:50.0 -0500
+++ include/asm-h8300/elf.h 2008-02-13 20:26:58.0 -0500
@@ -26,10 +26,10 @@
#define ELF_DATA ELFDATA2MSB
#define ELF_ARCH EM_H8_300
#if defined(__H8300H__)
-#define ELF_FLAGS 0x81
+#define ELF_CORE_FLAGS 0x81
#endif
#if defined(__H8300S__)
-#define ELF_FLAGS 0x82
+#define ELF_CORE_FLAGS 0x82
#endif
#define ELF_PLAT_INIT(_r) _r->er1 = 0
--
Yoshinori Sato
<[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] remove rcu_assign_pointer(NULL) penalty with type/macro safety
On Wed, Feb 13, 2008 at 04:53:56PM -0800, Stephen Hemminger wrote:
> On Wed, 13 Feb 2008 16:42:53 -0800
> "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 13, 2008 at 04:27:00PM -0800, Stephen Hemminger wrote:
[ . . . ]
> > > That is heading towards ugly... Maybe not using the macro at all (for
> > > this case) would be best:
> > >
> > > static inline void node_set_parent(struct node *node, struct tnode *ptr)
> > > {
> > > smp_wmb();
> > > node->parent = (unsigned long)ptr | NODE_TYPE(node);
> > > }
> >
> > Or, alternatively, the rcu_assign_index() patch sent earlier to avoid
> > the bare memory barrier?
> >
> > Thanx, Paul
>
> I am fine with rcu_assign_index(), and add a comment in node_set_parent.
OK, how about the following?
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
fib_trie.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff -urpNa -X dontdiff linux-2.6.25-rc1/net/ipv4/fib_trie.c
linux-2.6.25-rc1-fib_trie-warn.compile/net/ipv4/fib_trie.c
--- linux-2.6.25-rc1/net/ipv4/fib_trie.c2008-02-13 14:38:12.0
-0800
+++ linux-2.6.25-rc1-fib_trie-warn.compile/net/ipv4/fib_trie.c 2008-02-13
17:31:16.0 -0800
@@ -96,6 +96,14 @@ typedef unsigned int t_key;
#define IS_TNODE(n) (!(n->parent & T_LEAF))
#define IS_LEAF(n) (n->parent & T_LEAF)
+/*
+ * The "parent" fields in struct node and struct leaf are really pointers,
+ * but with the possibility that the T_LEAF bit is set. Therefore, both
+ * the C compiler and RCU see them as integers rather than pointers.
+ * This in turn means that rcu_assign_index() must be used to assign
+ * values to these fields, rather than the usual rcu_assign_pointer().
+ */
+
struct node {
unsigned long parent;
t_key key;
@@ -179,8 +187,7 @@ static inline struct tnode *node_parent_
static inline void node_set_parent(struct node *node, struct tnode *ptr)
{
- rcu_assign_pointer(node->parent,
- (unsigned long)ptr | NODE_TYPE(node));
+ rcu_assign_index(node->parent, (unsigned long)ptr | NODE_TYPE(node));
}
static inline struct node *tnode_get_child(struct tnode *tn, unsigned int i)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 UPDATED] printk: fix possible printk buffer overrun introduced with recursion check
printk recursion detection prepends message to printk_buf and offsets printk_buf when actual message is printed but it forgets to trim buffer length accordingly. This can result in buffer overrun in extreme cases. Fix it. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Acked-by: Ingo Molnar <[EMAIL PROTECTED]> --- Splitted out fix portion. kernel/printk.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/printk.c b/kernel/printk.c index bee3610..9adc2a4 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -666,7 +666,7 @@ asmlinkage int vprintk(const char *fmt, va_list args) } /* Emit the output into the temporary buffer */ printed_len += vscnprintf(printk_buf + printed_len, - sizeof(printk_buf), fmt, args); + sizeof(printk_buf) - printed_len, fmt, args); /* * Copy the output into log_buf. If the caller didn't provide -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] fix module_update_markers() compile error
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
> This patch fixes the following compile error with CONFIG_MODULES=n
> caused by commit fb40bd78b0f91b274879cf5db8facd1e04b6052e:
>
> <-- snip -->
>
> ...
> CC kernel/marker.o
> /home/bunk/linux/kernel-2.6/git/linux-2.6/kernel/marker.c: In function
> ‘marker_update_probes’:
> /home/bunk/linux/kernel-2.6/git/linux-2.6/kernel/marker.c:627: error: too few
> arguments to function ‘module_update_markers’
> make[2]: *** [kernel/marker.o] Error 1
>
> <-- snip -->
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
Thanks for spotting this.
Acked-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> ---
> 8d811a4160c6e2cb92391076e0e0b500e1b4a8a2 diff --git a/include/linux/module.h
> b/include/linux/module.h
> index 330bec0..819c4e8 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -567,8 +567,7 @@ static inline void print_modules(void)
> {
> }
>
> -static inline void module_update_markers(struct module *probe_module,
> - int *refcount)
> +static inline void module_update_markers(void)
> {
> }
>
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
eth0 changes to eth1 after initial boot; udev rules correct; modprobe.conf correct.
Since going to 2.6.24 my wired lan changed from eth0 to eth1. It starts
as eth0... but then changes to eth1.
udev rules hard sets it to eth0. For the heck of it I deleted
70...network... and it recreated it with eth1, I changed manually to
eth0. still have the problem.
modprobe.conf had an alias for eth1, changed it to eth0, no difference.
removed modprobe alias. no difference.
sysconfig as written by kudzu made it eth1, changed to eth0 and stopped
kudzu from running. still persists to becoming eth1.
THERE IS NO REFERENCE TO ETH1 in any file and yet upon boot... it
CHANGES from eth0 to eth1!!!
Where else in the system does something cause this effect?
I have googled "eth0 becomes eth1", "nic changes name" both with and
without 2.6.24. Every response referse to the udev rules in
70-presistent-net.rules.
Any ideas to resolve or debug this would be appreciated.
E
[EMAIL PROTECTED] ~]# dmesg | grep eth
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
eth0: Tigon3 [partno(BCM5752KFBG) rev 6002 PHY(5752)] (PCI Express)
10/100/1000Base-T Ethernet 00:18:8b:a5:2c:f5
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[7618] dma_mask[64-bit]
ADDRCONF(NETDEV_UP): eth1: link is not ready
bridge-eth0: peer interface eth0 not found, will wait for it to come up
bridge-eth0: attached
ADDRCONF(NETDEV_UP): eth1: link is not ready
[EMAIL PROTECTED] ~]# ifconfig -a
eth1 Link encap:Ethernet HWaddr 00:18:8B:A5:2C:F5 UP
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:18
loLink encap:Local Loopback inet addr:127.0.0.1
Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1309 errors:0 dropped:0 overruns:0 frame:0
TX packets:1309 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2366648 (2.2 MiB) TX bytes:2366648 (2.2 MiB)
vmnet8Link encap:Ethernet HWaddr 00:50:56:C0:00:08 inet
addr:192.168.232.1 Bcast:192.168.232.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
wlan0 Link encap:Ethernet HWaddr 00:1A:92:0E:40:1F inet
addr:10.1.1.5 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::21a:92ff:fe0e:401f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:17 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1838 (1.7 KiB) TX bytes:1900 (1.8 KiB)
wmaster0 Link encap:UNSPEC HWaddr
00-1A-92-0E-40-1F-00-00-00-00-00-00-00-00-00-00 UP BROADCAST
RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[EMAIL PROTECTED] ~]# more /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# PCI device 0x14e4:0x1600 (tg3) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:18:8b:a5:2c:f
5", ATTR{type}=="1", NAME="eth0"
# PCI device 0x14e4:0x4311 (b43-pci-bridge)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1a:92:0e:40:1
f", ATTR{type}=="1", NAME="wlan0"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] printk: implement printk_header() and merging printk, take #3
Hello, Andrew Morton wrote: > On Thu, 14 Feb 2008 09:40:51 +0900 > Tejun Heo <[EMAIL PROTECTED]> wrote: > >> Can you please take a look at ata_eh_link_report() in >> drivers/ata/libata-eh.c? > > I did. Punishment? Heh.. :-) >> Currently, it has some problems. > > Yes, and the patches do clean that up. Yeap, it does. > ho hum. What tends to happen with this sort of thing is that fi we merge > it, it ends up getting used more often than one expected... Hmmm... Okay. mprintk being printk, I'm not too sure how it can go over usual expectations but well, yeah, that actually is my expectation. > If you stand back and squint at it, there are quite a few places where we > do this sort of thing: allocate a buffer, squirt characters into it, > reallocating and/or flushing as we proceed. All sysfs and procfs read-side > code, for a start... printk is a special case, I think. It's the primary logging/debugging method which can't fail and as it's mostly interpreted by human beings (and developers in problematic cases), it has different maneuvering room on errors - ie. it's far better to print messages w/o header or proper log level than failing to print, which is quite different requirements from other components. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] SCSI bug fixes for 2.6.25-rc1
From: James Bottomley <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 19:11:53 -0600 > > On Wed, 2008-02-13 at 16:16 -0800, Andrew Morton wrote: > > kill-warnings-in-mptbaseh-on-parisc64.patch > > > Warning fixes. > > Not sure ... LSI is supposed to be processing this. James, please don't push build warning fixes and the like back to the driver maintainers. This is your domain as SCSI maintainer, and you should integrate these kinds of things directly and as promptly as possible. This is doubly true if the "driver maintainer" can't be bothered to ACK or fixup the patch for months. Otherwise this kind of stuff rots, and diligent people like Andrew (and the patch submitter, whoever that might be) get extremely frustrated. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
earlier ctrl-alt-del
Suggestion: ctrl-alt-del should be a working command earlier in the bootup process, so that reboots won't take so long because we have to wait. For example, I sometimes have to change something in BIOS and then must reboot, which means I have to go almost to the login stage before I can warm-reboot. I now use Fedora Core 4, with kernel 2.6.11-1.1369_FC4. I don't have the time to do much more than suggest, e.g., learn C and assembler -- I wish I did. And maybe earlier ctrl-alt-del would raise too many conflicts or can't be done. I don't know. Thanx. -- Nick (Please post the above to the linux.kernel newsgroup, and please CC me for any answers and comments in reply. Thank you.) Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git: kmap_atomic() WARN_ON()
On Wed, 13 Feb 2008, Rafael J. Wysocki wrote: > Hi Thomas, > > On Thursday, 7 of February 2008, Thomas Gleixner wrote: > > current mainline triggers: > > Has the issue been fixed in the meantime? Nope. Just for reference: http://lkml.org/lkml/2007/1/14/38 looks frighteningly similar. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Latency issues with x86.git
Hi Ingo, I have encountered (a handful of times in the past few months) some real interactivity problems on my system. Moving the mouse or typing a key on the keyboard takes around a second to show any response. Once I perform a reboot, the problem is gone again. I am currently running x86.git mm branch, but I switch between that branch, mainline git, and mm kernels, so I cannot guarantee on which trees I have or have not seen the problem. It seems to have started around the time that CFS came into being, but it might be something completely unrelated. When it happened this evening, I ran the cfs-debug-info.sh script to which you had referred me in another thread. I'm not sure if this helps to debug the problem, but it was all I could think to try. I have LatencyTOP in my kernel, so I guess I could try the userspace tool as well the next time. The output of the script is at: http://personal.nbnet.nb.ca/kwin/cfs-debug-info-2008.02.13-20.56.38 Unfortunately, I cannot reproduce the problem intentionally - it only happens once a month or so. If there is any other info you need, please let me know, or any suggestions for what to try the next time. Thanks, -- Kevin Winchester -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] SCSI bug fixes for 2.6.25-rc1
On Wed, 2008-02-13 at 16:16 -0800, Andrew Morton wrote: > On Wed, 13 Feb 2008 18:02:44 -0600 > James Bottomley <[EMAIL PROTECTED]> wrote: > > > This one's not too bad given the number of patches we had in the merge > > window. We have the advansys fix, a gdth severe problem fix (wouldn't > > scan any devices) a bug fix series for lpfc and a few other odds and > > ends. > > > > The patch is available here: > > > > master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git > > I have scsi patches! > > > > mptbase-reset-ioc-initiator-during-pci-resume.patch > > Fixes suspend/resume on all of Darrick's MPT cards. I first merged it > in September 2007. Patch presented by LSI but has gone back with comments > kill-warnings-in-mptbaseh-on-parisc64.patch > Warning fixes. Not sure ... LSI is supposed to be processing this. > dell-cerc-support-for-megaraid_mbox.patch I need megaraid to sign off (and test) this one. > Turns non-booting machiens into booting ones. Merged in -mm in > November 2007. > > 3w-raid-drivers-memset-not-needed-in-probe.patch > > Small optimisation > > scsi-aic94xx-cleanups.patch > > cleanups only. > > scsi-qlogicptic-section-fixes.patch > > Fixes a reference from .text into .init.text and hence might fix a > machine crash when this driver is build into vmlinux. Merged a week ago. This was the one we had the alternative fix for, wasn't it ... ? > megaraid-outb_p-extermination.patch > > Cleanup > > gdth-convert-to-pci-hotplug-api.patch > > Just merged That's not a bug fix necessarily ... We do have an outstanding gdth bug fix that did have a patch in your tree, though ... But we're arguing over doing it properly. > > So several of these patches address quite seriosu bugs, and have been > stuck in my tree for far too long. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
