| From | Subject | Date |
|---|---|---|
| Bartlomiej Zolnierki ... | [git patches] IDE updates (part 5)
Hi,
This is the final part, contains:
* important bugfix from Adrian Bunk for sis5513 host driver
(for the bug introduced in one of the previous updates)
* more small fixups/cleanups
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6.git/
to receive the following updates:
drivers/ide/Kconfig | 3 +
drivers/ide/arm/bast-ide.c | 2 +-
drivers/ide/arm/icside.c | 62 +++--------
drivers/ide/arm/ide_arm.c ...
| Oct 19, 3:48 pm 2007 |
| Robert Hancock | Re: Kernel configuration of a two dual core processor - ...
Quite likely you didn't enable whatever driver your system needs to
access the hard drive..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
-
| Oct 19, 4:28 pm 2007 |
| Randy Dunlap | [PATCH] xconfig: set title bar
From: Randy Dunlap <randy.dunlap@oracle.com>
menuconfig and gconfig already place a title (or caption) on the top
bar of their window (or whatever that is properly called). However,
qconf (xconfig) just says "qconf". I tried to find a Qt API to set
the title but did not find one, so set the program title (caption)
by using the "-title <caption>" command line option instead.
This can be useful when someone has multiple qconf instances running,
to help differentiate which one is ...
| Oct 19, 2:55 pm 2007 |
| Jordan Crouse | Re: [PATCH 1/4 resend] [x86] Add generic GPIO support to x86
Its reasonable to expect that the API will expand over time as it is
thrust into new situations. There is nothing wrong with the existing API,
it does an admirable job of simple GPIO frobbing. But on the Geode, GPIOs
can do much more then just simple input and output. We can cause events,
use input filtering for debouncing, set various drain options, and more.
And these are not bullet points from the datasheet that we want to
implement for completeness; these functions are actually being used ...
| Oct 19, 2:32 pm 2007 |
| Ursula Braun | [patch 0/1] remove header_ops bug in qeth driver
--
Remove qeth driver bug introduced by this commit:
commit 3b04ddde02cf1b6f14f2697da5c20eca5715017f
Author: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Tue Oct 9 01:40:57 2007 -0700
[NET]: Move hardware header operations out of netdevice.
-
| Oct 19, 2:55 pm 2007 |
| Linus Torvalds | Re: [Git pull] arch/x86 updates
While I think this is good otherwise, why does it do
printk(".. comm: %.*s .."
TASK_COMM_LEN, current->comm,
instead of just using "%s" and "current->comm"? I only noticed because
there was an unrelated conflict around that thing.
That "current->comm" had better be NUL-terminated already, we use it as
such all over the place. And if it's not, *that* should be fixed.
I'm editing it back to the simpler pure string.
Linus
-
| Oct 19, 3:04 pm 2007 |
| Ingo Molnar | Re: [Git pull] arch/x86 updates
it might make some marginal sense to get an oops message out when
there's stack overflow/corruption that damages task->comm. I've seen a
good number of traces that printed out task->comm as an overlength
string - which obscured other, possibly more important info that could
have been printed until the system became so hosed that it would not
print anything.
but ... this is really splitting hairs and even when the stack and hence
the task struct is corrupted, an accidental NIL ...
| Oct 19, 4:14 pm 2007 |
| Thomas Gleixner | Re: [Git pull] arch/x86 updates
Fair enough. Did not notice.
tglx
-
| Oct 19, 3:19 pm 2007 |
| Thomas Gleixner | [Git pull] arch/x86 updates
Linus,
please pull from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git
This tree contains
- another chunk of the -mm/ak pending patches
- some unification patches
- merge fallout fixups
- bugfixes fallout from automated testing
- trivial cleanups
A full log, including the patches is available here:
http://userweb.kernel.org/~tglx/git-x86-changes
Thanks
tglx
---
Adrian Knoth (1):
Kconfig: Missing line breaks in ...
| Oct 19, 2:46 pm 2007 |
| Jeff Garzik | [2.6.23] tasks stuck in running state?
On my main devel box, vanilla 2.6.23 on x86-64/Fedora-7, I'm seeing a
certain behavior at least once a day. I'll start a kernel build (make
Specifically, the symptom is a process, often a simple one like cat(1)
or rm(1) or somewhere in check-headers, will stay in the running state,
accumulating CPU time.
If I Ctrl-C the build, and start over, the build will normally -not- get
stuck at the same point, but proceed to chew through one of a bazillion
allmodconfig builds.
I also see this ...
| Oct 19, 2:39 pm 2007 |
| Jeff Garzik | Re: [2.6.23] tasks stuck in running state?
[sits there, chewing up CPU grepping a 47-line header file]
-
| Oct 19, 3:03 pm 2007 |
| Chuck Ebbert | Re: [2.6.23] tasks stuck in running state?
Can you try to strace the hanging task?
-
| Oct 19, 2:53 pm 2007 |
| Chuck Ebbert | Re: [2.6.23] tasks stuck in running state?
And sysrq-p is pretty useless unless you can force the keyboard
interrupt and the spinning process onto the same CPU.
-
| Oct 19, 3:18 pm 2007 |
| Will Schmidt | [bug] block subsystem related crash on Legacy iSeries v ...
Hi Jens, Stephen, and Everyone else.
I am seeing this crash on a legacy iSeries box. Bisect points at
70eb8040dc81212c884a464b75e37dca8014f3ad (Add chained sg support to
linux/scatterlist.h).
I see there were some related troubles discussed a couple days back.
I've refreshed my tree, so believe I should have pulled in all the
changes that fixed those issues by now, so this is an additional problem
(viodasd funkyness), or I've screwed something up in my pulls, or fixes
(from ...
| Oct 19, 2:33 pm 2007 |
| Trond Myklebust | [GIT] NFS client fixes for 2.6.23++
Hi Linus,
Please pull from the repository at
git pull git://git.linux-nfs.org/pub/linux/nfs-2.6.git
This will update the following files through the appended changesets.
Cheers,
Trond
----
fs/nfs/delegation.c | 3 +-
fs/nfs/dir.c | 14 +++++-
fs/nfs/file.c | 2 +-
fs/nfs/inode.c | 25 +++++++++--
fs/nfs/nfs4_fs.h | 3 +-
fs/nfs/nfs4proc.c | 19 ++++++--
fs/nfs/nfs4state.c | 14 +++++-
fs/nfs/unlink.c | ...
| Oct 19, 2:23 pm 2007 |
| Bart Trojanowski | [BUG] 2.6.23.1 host freezes when running kvm
I am running 2.6.23.1 with kvm built from that tree as a module. My
system is running Debian/testing on a Tyan board with two dual-core
Opteron 2216 processors; each socket has 4G of RAM. I have attached the
serial console dump including a bunch of output from SysRq (gzipped,
because it was 300k otherwise).
I have ran multiple passes of memtest, and I can build the kernel with
-j8, but when I run kvm the host freezes.
A bit about the system:
quark# cat /proc/version
Linux version ...
| Oct 19, 1:20 pm 2007 |
| Maciej W. Rozycki | [PATCH] MAINTAINERS: Add self for the dz serial driver
Now that I have got the necessary piece of hardware (thanks, Thiemo!), I
may well offer myself as the maintainer for the dz serial driver. I hope
nobody objects.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
Please apply,
Maciej
patch-mips-2.6.23-rc5-20070904-dz-maint-0
diff -up --recursive --new-file linux-mips-2.6.23-rc5-20070904.macro/MAINTAINERS linux-mips-2.6.23-rc5-20070904/MAINTAINERS
--- linux-mips-2.6.23-rc5-20070904.macro/MAINTAINERS 2007-09-04 ...
| Oct 19, 1:55 pm 2007 |
| Maciej W. Rozycki | [PATCH] dz: Handle special conditions on reception correctly
Handle the read and ignore status masks correctly. Handle the BREAK
condition as expected: a framing error with a null character is a BREAK,
any other framing error is a framing error indeed.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
Tested with checkpatch.pl and at the run-time -- MIPS/Linux on a
DECstation 5000/200.
Please apply,
Maciej
patch-mips-2.6.23-rc5-20070904-dz-receive-8
diff -up --recursive --new-file ...
| Oct 19, 1:51 pm 2007 |
| Gabriel C | Re: some kernel headers broken in current git ?
Is what I did before latest pull.
Maybe this whole tree got broken. I'll try a fresh one and report back.
Regards ,
Gabriel
-
| Oct 19, 2:19 pm 2007 |
| Jiri Kosina | Re: some kernel headers broken in current git ?
Trying 'make mrproper' first has high chances of fixing this I'd guess.
--
Jiri Kosina
-
| Oct 19, 2:08 pm 2007 |
| Gabriel C | Re: some kernel headers broken in current git ?
Actually I try to get VirtualBox-1.5.2_OSE to compile but I get a lot errors from
include/asm-generic/atomic.h and other headers.
and looks like some are missing ?
...
/lib/modules/2.6.23-rc0/build/include/asm/irq_32.h:15:25: error: irq_vectors.h: No such file or directory
/lib/modules/2.6.23-rc0/build/include/asm/smp_32.h:154:26: error: mach_apicdef.h: No such file or directory
...
this is fresh cloned tree and pulled once to get your x86 updates:
#-- git rev-parse --verify ...
| Oct 19, 4:43 pm 2007 |
| Gabriel C | Re: some kernel headers broken in current git ?
I get the same on fresh cloned git tree
#-- git rev-parse --verify HEAD
c4ec20717313daafba59225f812db89595952b83
Regards,
Gabriel
-
| Oct 19, 3:23 pm 2007 |
| Maciej W. Rozycki | [PATCH] dz.c: Fix locking issues
The ->start_tx(), ->stop_tx() and ->stop_rx() backends are called with
the port's lock already taken. Remove locking from within them and wrap
around calls as necessary.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
Tested with checkpatch.pl and at the run-time -- MIPS/Linux on a
DECstation 5000/200.
Please apply,
Maciej
patch-mips-2.6.23-rc5-20070904-dz-lock-1
diff -up --recursive --new-file linux-mips-2.6.23-rc5-20070904.macro/drivers/serial/dz.c ...
| Oct 19, 1:44 pm 2007 |
| Thomas Gleixner | Re: some kernel headers broken in current git ?
Hmm. The kernel itself compiles fine ?
What external thing breaks ?
tglx
-
| Oct 19, 3:49 pm 2007 |
| Gabriel C | some kernel headers broken in current git ?
Hi,
usually I'll wait for rc1 and test compile external module to see which are broken and what need fixing
but while I need virtualbox for some tests I test compile it on current git and it failed badly.
Maybe something is missing from x86 merge ?
Here is what I get :
...
/linux/memobj-r0drv-linux.c
In file included from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/atomic_32.h:265,
from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/atomic.h:2,
...
| Oct 19, 1:44 pm 2007 |
| Sam Ravnborg | [GI:wqT PULL] kbuild updates - second round
Following are the accumulated kbuild updates.
A mixture of new stuff and fixes.
The cc-cross-prefix is new and developed on request from Geert Uytterhoeven.
With cc-cross-prefix it is now much easier to have a few default
cross compile prefixes and defaulting to none - if none of them were present.
ARCH maintainers are expected to pick up this feature soon.
The other noteworthy change is the move of the mailing list for kbuild/kconfig.
Subscribe to the new list like this:
Send a mail to ...
| Oct 19, 1:44 pm 2007 |
| Maciej W. Rozycki | [PATCH] dz.c: Rename the serial console structure
Rename the serial console structure so that `modpost' does not complain
about a reference to an "init" section -- "_console" is magic.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
Tested with checkpatch.pl and at the run-time -- MIPS/Linux on a
DECstation 5000/200.
Please apply,
Maciej
patch-mips-2.6.23-rc5-20070904-serial-dz-console-0
diff -up --recursive --new-file linux-mips-2.6.23-rc5-20070904.macro/drivers/serial/dz.c ...
| Oct 19, 1:38 pm 2007 |
| Serge E. Hallyn | [PATCH RFC] capabilities: remove STRICT_CAP_T_TYPECHECKS
Here is the second alternative, simply removing the
STRICT_CAP_T_TYPECHECKS option.
thanks,
-serge
From 141626df6eaba12f5566f6bce7e72c1c3e627364 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <serue@us.ibm.com>
Date: Wed, 17 Oct 2007 10:00:49 -0400
Subject: [PATCH 1/1] capabilities: remove STRICT_CAP_T_TYPECHECKS
It appears STRICT_CAP_T_TYPECHECKS was introduced in 1998 - and
always undefined since then - because the STRICT_CAP_T_TYPECHECKS
behavior is broken. (See ...
| Oct 19, 1:36 pm 2007 |
| Serge E. Hallyn | [PATCH RFC] capabilities: fix compilation with strict ty ...
From cd7c384f76d2c0f6b12a1c0936d54ae9c5e7cb4c Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <serue@us.ibm.com>
Date: Fri, 19 Oct 2007 15:39:10 -0400
Subject: [PATCH RFC] capabilities: fix compilation with strict type checking (v2)
Since at least 1998 the code under STRICT_CAP_T_TYPECHECKS option has
not been used. (See
http://www.uwsg.iu.edu/hypermail/linux/kernel/9810.2/0705.html)
There are two options - we can remove this option altogether
or, as this patch attempts to do, fix ...
| Oct 19, 1:35 pm 2007 |
| Maciej W. Rozycki | [PATCH] dz: Update Kconfig description
Reformat the Kconfig entries and update descriptions for accuracy.
Select the driver by default for configurations of interest. For the
curious: 32BIT means only 32-bit DECstations support the device, not that
the driver is not 64-bit clean; I have not checked that either though.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
Please apply,
Maciej
patch-mips-2.6.18-20060920-dz-kconfig-2
diff -up --recursive --new-file ...
| Oct 19, 1:34 pm 2007 |
| Maciej W. Rozycki | [PATCH] dz.c: Add and reorder inclusions, remove unneeded ones
Sort the header inclusions, add a few that are needed but pulled
indirectly only and remove ones that are not really used.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
Tested with checkpatch.pl and at the run-time -- MIPS/Linux on a
DECstation 5000/200.
Please apply,
Maciej
patch-mips-2.6.18-20060920-dz-include-4
diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/drivers/serial/dz.c linux-mips-2.6.18-20060920/drivers/serial/dz.c
--- ...
| Oct 19, 1:28 pm 2007 |
| Wiesner Thomas | "CIFS VFS: server not responding" with some client/serve ...
I have the following, very strange problem, which I'll try to describe now.
I've already sent this to the samba mailing list (about a week ago),
but haven't got a reply. As it might be kernel related and others
may be affected too, I decided to send it to this list, too.
A Samba server running Debian Etch with latest updates.
Different clients one running Etch with latest updates, too. The other one
runs
either Ubuntu (don't know which version because it's not my installation,
but ...
| Oct 19, 12:29 pm 2007 |
| Maciej W. Rozycki | [PATCH] dz.c: Don't panic() when request_irq() fails
Well, panic() is a little bit undue if request_irq() fails; there is
probably no need to justify it any further. Handle the case gracefully,
by unregistering the driver.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
Tested with checkpatch.pl and at the run-time -- MIPS/Linux on a
DECstation 5000/200.
Please apply,
Maciej
patch-mips-2.6.18-20060920-dz-init-0
diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/drivers/serial/dz.c ...
| Oct 19, 1:24 pm 2007 |
| Maciej W. Rozycki | [PATCH] dz.c: Always check if it is safe to console_putchar()
Polled transmission is tricky enough with the DZ11 design. While "loop"
is set to a high value, conceptually you are not allowed to transmit
without checking whether the device offers the right transmission line
(yes, it is the device that selects the line -- the driver has no control
over it other than disabling the transmitter offered if it is the wrong
one), so the loop has to be run at least once.
Well, the '1977 or PDP11 view of how serial lines should be handled...
Except that ...
| Oct 19, 1:18 pm 2007 |
| Maciej W. Rozycki | [PATCH] dz.h: Remove useless unused module junk
Remove unused module function prototypes that would not even build if
enabled.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
Please apply under the obviously-correct rule.
Maciej
patch-mips-2.6.18-20060920-dz-junk-0
diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/drivers/serial/dz.h linux-mips-2.6.18-20060920/drivers/serial/dz.h
--- linux-mips-2.6.18-20060920.macro/drivers/serial/dz.h 2003-06-11 23:26:46.000000000 +0000
+++ ...
| Oct 19, 12:57 pm 2007 |
| Zan Lynx | Re: 2.6.23-rc8-mm2 ACPI Battery Info in /sys but not /pr ...
This was the problem. Thank you.
What confused me was that *only* the battery information seemed to be
missing. If all the ACPI info in /proc had been missing I would have
suspected something like this right away.
--=20
Zan Lynx <zlynx@acm.org>
| Oct 19, 12:53 pm 2007 |
| Andrew Morton | Re: [PATCH 7/8] drivers-edac-add freescale mpc85xx driver
On Fri, 19 Oct 2007 13:18:43 -0600
I can't tell whether this should have had static scope because nothing uses
it ;)
-
| Oct 19, 2:16 pm 2007 |
| dougthompson | [PATCH 7/8] drivers-edac-add freescale mpc85xx driver
From: Dave Jiang <djiang@mvista.com>
EDAC chip driver support for Freescale MPC85xx platforms. PPC based.
Signed-off-by: Dave Jiang <djiang@mvista.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk
Signed-off-by: Doug Thompson <dougthompson@xmission.com>
---
Kconfig | 7
Makefile | 1
mpc85xx_edac.c | 1043 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
mpc85xx_edac.h | 162 ++++++++
4 files changed, 1213 insertions(+)
Index: ...
| Oct 19, 12:18 pm 2007 |
| dougthompson | [PATCH 8/8] drivers-edac-add marvell mv64x60 driver
From: Dave Jiang <djiang@mvista.com>
Marvell mv64x60 SoC support for EDAC. Used on PPC and MIPS platforms.
Development and testing done on PPC Motorola prpmc2800 ATCA board.
Signed-off-by: Dave Jiang <djiang@mvista.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk
Signed-off-by: Douglas Thompson <dougthompson@xmission.com>
---
Kconfig | 7
Makefile | 1
mv64x60_edac.c | 855 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
mv64x60_edac.h | 114 +++++++
4 files ...
| Oct 19, 12:19 pm 2007 |
| dougthompson | [PATCH 4/8] drivers-edac-add Cell MC driver
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Adds driver for the Cell memory controller when used without a
Hypervisor such as on the IBM Cell blades. There might still
be some improvements to do to this such as finding if it's
possible to properly obtain more details about the address
of the error but it's good enough already to report CE counts
which is our main priority at the moment.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Alan Cox ...
| Oct 19, 12:17 pm 2007 |
| Andrew Morton | Re: [PATCH 4/8] drivers-edac-add Cell MC driver
On Fri, 19 Oct 2007 13:17:43 -0600
The (void) cast isn't particularly popular practice. Did you find that it
What's this here for? It could do with a more usful comment.
If it's trying to perform some synchronisation of device register access
then I suspect it didn't work. Or maybe it happens to work because of how
ppc implements mb(), in which case a direct use of the appropriate ppc
-
| Oct 19, 2:09 pm 2007 |
| dougthompson | [PATCH 5/8] drivers-edac-i3000 code tidying
From: Jason Uhlenkott <juhlenko@akamai.com>
Style cleanup, mostly just 80-column fixes.
Signed-off-by: Jason Uhlenkott <juhlenko@akamai.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk
Signed-off-by: Doug Thompson <dougthompson@xmission.com>
---
drivers/edac/i3000_edac.c | 207 ++++++++++++++++++++++++----------------------
1 files changed, 110 insertions(+), 97 deletions(-)
Index: edac/drivers/edac/i3000_edac.c
===================================================================
--- ...
| Oct 19, 12:18 pm 2007 |
| Doug Thompson | Re: [PATCH 6/8] drivers-edac-i3000 replace macros with f ...
Jason,
Can you provide some information on this?
doug t
W1DUG
-
| Oct 19, 4:58 pm 2007 |
| dougthompson | [PATCH 6/8] drivers-edac-i3000 replace macros with functions
From: Jason Uhlenkott <juhlenko@akamai.com>
Replace function-like macros with functions.
Signed-off-by: Jason Uhlenkott <juhlenko@akamai.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk
Signed-off-by: Doug Thompson <dougthompson@xmission.com>
---
drivers/edac/i3000_edac.c | 50 ++++++++++++++++++++++++++++++++--------------
1 files changed, 35 insertions(+), 15 deletions(-)
Index: edac/drivers/edac/i3000_edac.c
===================================================================
--- ...
| Oct 19, 12:18 pm 2007 |
| Andrew Morton | Re: [PATCH 6/8] drivers-edac-i3000 replace macros with f ...
On Fri, 19 Oct 2007 13:18:23 -0600
The types here look a bit confused. Implicit conversions of
u32s into unsigned longs.
-
| Oct 19, 2:11 pm 2007 |
| dougthompson | [PATCH 2/8] drivers-edac-use round_jiffies_relative
From: Anton Blanchard <anton@samba.org>
When rounding a relative timeout we need to use round_jiffies_relative().
Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Arjan van de Ven <arjan@linux.intel.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk
Signed-off-by: Doug Thompson <dougthompson@xmission.com>
---
Index: linux-2.6.23/drivers/edac/edac_device.c
===================================================================
--- linux-2.6.23.orig/drivers/edac/edac_device.c
+++ ...
| Oct 19, 12:17 pm 2007 |
| dougthompson | [PATCH 0/8] EDAC fixes and new drivers
From: Doug Thompson <dougthompson@xmission.com>
This EDAC patch set was applied against: 2.6.23
1) Enable logging on edac_device class devices
2) round_jiffies_relative instead of round_jiffies
3) New XDR memory and Cell memory controller driver
4) i3000 code tidying
5) freescale driver
6) marvell driver
Signed-off-by: Doug Thompson <dougthompson@xmission.com>
-
| Oct 19, 12:16 pm 2007 |
| dougthompson | [PATCH 3/8] drivers-edac-add Cell XDR memory types
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This patch adds the definitions for the Rambus XDR memory type
used by the Cell processor. It's a pre-requisite for the followup
Cell EDAC patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk
Signed-off-by: Doug Thompson <dougthompson@xmission.com>
---
drivers/edac/edac_core.h | 2 ++
drivers/edac/edac_mc_sysfs.c | 3 ++-
2 files changed, 4 insertions(+), 1 ...
| Oct 19, 12:17 pm 2007 |
| dougthompson | [PATCH 1/8] drivers-edac-turnon edac device error logging
From: Doug Thompson <dougthompson@xmission.com>
This patch ENABLES the 'logging' of CE and UE events for the
EDAC_DEVICE class of error harvester in EDAC
CC: Alan Cox <alan@lxorguk.ukuu.org.uk
Signed-off-by: Doug Thompson <dougthompson@xmission.com>
---
edac_device.c | 4 ++++
1 file changed, 4 insertions(+)
Index: linux-2.6.23/drivers/edac/edac_device.c
===================================================================
--- linux-2.6.23.orig/drivers/edac/edac_device.c
+++ ...
| Oct 19, 12:16 pm 2007 |
| Larry Finger | Re: Network failure with 2.6.23-git14
My network also fails - my interface is a BCM4311 using b43 as the driver.
Upon bisecting, I find that d3904b739928edd83d117f1eb5bfa69f18d6f046 is first bad commit
commit d3904b739928edd83d117f1eb5bfa69f18d6f046
Author: Pavel Emelyanov <xemul@openvz.org>
Date: Wed Oct 17 21:22:17 2007 -0700
[NET]: Cleanup the error path in sk_attach_filter
The sk_filter_uncharge is called for error handling and
for releasing the former filter, but this will have to
be done in a bit ...
| Oct 19, 12:37 pm 2007 |
| Justin Piszcz | Intel PCI-e x1 1Gbps NIC support in 2.6.23?
http://www.tigerdirect.com/applications/searchtools/item-details.asp?EdpNo=2276643&...
REVIEW BY: tesseract Reviewed Jun 26, 2007
Due to a bug in the hardware of this card it doesn't work with Linux. The
card does works at 100mb/s speed but when put to gigabit speeds it gets TX
Unit Hang messages. Further information can be found at
http://e1000.sourceforge.net/wiki/index.php/Issues . The drivers haven't
be able to work around the issue yet, its been over a year. Just as a ...
| Oct 19, 12:22 pm 2007 |
| Justin Piszcz | Re: Intel PCI-e x1 1Gbps NIC support in 2.6.23?
There is the EEPROM flip/script at the bottom -- can anyone confirmed that
it fixed their issues if they had problems?
Justin.
-
| Oct 19, 12:24 pm 2007 |
| Ingo Molnar | [git pull] scheduler accounting fix
Linus, please pull the latest scheduler git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git
it contains a single onliner fix: Christian Borntraeger noticed a
guest-cputime over-accounting bug (introduced via the recent v2.6.24
scheduler merge).
Thanks!
Ingo
------------------>
Christian Borntraeger (1):
sched: fix guest time accounting going faster than user time accounting
array.c | 2 +-
1 file changed, 1 insertion(+), 1 ...
| Oct 19, 12:00 pm 2007 |
| Németh Márton | [PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
From: Márton Németh <nm127@freemail.hu>
The driver supports the mail LED commonly found on different Clevo notebooks.
The driver access the LED through the i8042 hardware and implements the support for
hardware accelerated blink function.
Signed-off-by: Márton Németh <nm127@freemail.hu>
---
diff -uprN linux-2.6.23.orig/drivers/leds/Kconfig linux-2.6.23/drivers/leds/Kconfig
--- linux-2.6.23.orig/drivers/leds/Kconfig 2007-10-09 22:31:38.000000000 +0200
+++ ...
| Oct 19, 11:52 am 2007 |
| Randy Dunlap | Re: [PATCH 3/3] leds-clevo-mail: driver for Clevo mail LED
?:
Kbuild provides KBUILD_BASENAME and KBUILD_MODNAME. Can you use
/** introduces kernel-doc, but there is no following kernel-doc....,
We prefer to have clevo_mail_led_susped() and _resume() defined
all the time, so that the above ifdef & endif can go away, so
do more like:
#ifdef CONFIG_PM
/* those functions as you have them */
#else
#define clevo_mail_led_suspend NULL
#define clevo_mail_led_resume NULL
---
~Randy
-
| Oct 19, 1:36 pm 2007 |
| Németh Márton | [PATCH 2/3] leds-clevo-mail: hw accelerated LED blink ex ...
From: Márton Németh <nm127@freemail.hu>
Extends the leds subsystem with a blink_set() callback function which can
be optionally implemented by a LED driver. If implemented, the driver can use
the hardware acceleration for blinking a LED.
Signed-off-by: Márton Németh <nm127@freemail.hu>
---
diff -uprN linux-2.6.23.orig/Documentation/leds-class.txt linux-2.6.23/Documentation/leds-class.txt
--- linux-2.6.23.orig/Documentation/leds-class.txt 2007-10-09 22:31:38.000000000 +0200
+++ ...
| Oct 19, 11:52 am 2007 |
| Németh Márton | [PATCH 1/3] leds-clevo-mail: export i8042_command()
From: Márton Németh <nm127@freemail.hu>
Export the i8042_command() function which manages the mutual exclusion
with the help of the i8042_lock spinlock. This lets possible to use the
i8042 hardware safely from other part of the kernel, too.
Signed-off-by: Márton Németh <nm127@freemail.hu>
---
diff -uprN linux-2.6.23.orig/drivers/input/serio/i8042.c linux-2.6.23/drivers/input/serio/i8042.c
--- linux-2.6.23.orig/drivers/input/serio/i8042.c 2007-10-09 22:31:38.000000000 +0200
+++ ...
| Oct 19, 11:52 am 2007 |
| Charles R Harris | Re: [PATCH] i386: fix TSC clock source calibration error
This may be related to bug
https://bugzilla.redhat.com/show_bug.cgi?id=270321 at Redhat bugzilla.
It has been easily reproducible on my machine.
Chuck
-
| Oct 19, 11:45 am 2007 |
| Steven Rostedt | [patch 8/8] disable CFS RT load balancing.
Since we now take an active approach to load balancing, we don't need to
balance RT tasks via CFS. In fact, this code was found to pull RT tasks
away from CPUS that the active movement performed, resulting in
large latencies.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/sched_rt.c | 90 +-----------------------------------------------------
1 file changed, 2 insertions(+), 88 deletions(-)
Index: ...
| Oct 19, 11:43 am 2007 |
| Steven Rostedt | [patch 1/8] Add rt_nr_running accounting
This patch adds accounting to keep track of the number of RT tasks running
on a runqueue. This information will be used in later patches.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/sched.c | 2 ++
kernel/sched_rt.c | 18 ++++++++++++++++++
2 files changed, 20 insertions(+)
Index: linux-test.git/kernel/sched.c
===================================================================
--- linux-test.git.orig/kernel/sched.c 2007-10-19 12:32:39.000000000 -0400
+++ ...
| Oct 19, 11:42 am 2007 |
| Steven Rostedt | [patch 5/8] Move prototypes together.
A later patch uses some of the functions that were declared, and
this patch is used to move those prototypes up with other prototypes
that were declared.
This patch is mainly for prettiness.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/sched_rt.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Index: linux-test.git/kernel/sched_rt.c
===================================================================
--- linux-test.git.orig/kernel/sched_rt.c 2007-10-19 ...
| Oct 19, 11:42 am 2007 |
| Steven Rostedt | [patch 0/8] New RT Task Balancing
Currently in mainline the balancing of multiple RT threads is quite broken.
That is to say that a high priority thread that is scheduled on a CPU
with a higher priority thread, may need to unnecessarily wait while it
can easily run on another CPU that's running a lower priority thread.
Balancing (or migrating) tasks in general is an art. Lots of considerations
must be taken into account. Cache lines, NUMA and more. This is true
with general processes which expect high through put and migration ...
| Oct 19, 11:42 am 2007 |
| Steven Rostedt | [patch 6/8] pull RT tasks
This patch adds the algorithm to pull tasks from RT overloaded runqueues.
When a pull RT is initiated, all overloaded runqueues are examined for
a RT task that is higher in prio than the highest prio task queued on the
target runqueue. If another runqueue holds a RT task that is of higher
prio than the highest prio task on the target runqueue is found it is pulled
to the target runqueue.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/sched.c | 8 ++
...
| Oct 19, 11:43 am 2007 |
| Steven Rostedt | Re: [patch 6/8] pull RT tasks
--
That sounds like a good idea. RT balancing on >64 CPUs should be limited.
Having a bounding cpuset would help.
I'll try to come up with something.
Thanks!
-- Steve
-
| Oct 19, 12:43 pm 2007 |
| Peter Zijlstra | Re: [patch 6/8] pull RT tasks
This seems to be the only usage of rt_overload. I'm not sure its worth
-
| Oct 19, 12:24 pm 2007 |
| Peter Zijlstra | Re: [patch 6/8] pull RT tasks
Ingo just brought up a good point. With large smp (where large is >64)
this will all suck chunks.
rt_overload will bounce around the system, and the rto_cpumask updates
might already hurt.
The idea would be to do this per cpuset, these naturally limit the
migraiton posibilities of tasks and would thus be the natural locality
-
| Oct 19, 12:35 pm 2007 |
| Steven Rostedt | [patch 2/8] track highest prio queued on runqueue
This patch adds accounting to each runqueue to keep track of the
highest prio task queued on the run queue. We only care about
RT tasks, so if the run queue does not contain any active RT tasks
its priority will be considered MAX_RT_PRIO.
This information will be used for later patches.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/sched.c | 7 +++++++
kernel/sched_rt.c | 25 +++++++++++++++++++++++++
2 files changed, 32 insertions(+)
Index: ...
| Oct 19, 11:42 am 2007 |
| Steven Rostedt | Re: [patch 2/8] track highest prio queued on runqueue
--
I thought about that too, but thought it was also too -rt base. But I
That's what I meant to do. (/me had another confusion between > and < for
That wasn't planned. I wanted to only recalc if the priority was >= the
the rq priority, which would have been. p->prio <= rq->highest_prio.
Yes, I thought to myself (that should never be higher!) but I was
I'll add that with a switch to WARN_ON.
-- Steve
-
| Oct 19, 12:57 pm 2007 |
| Steven Rostedt | Re: [patch 2/8] track highest prio queued on runqueue
Sorry, I forgot to test this on UP. Seems to be missing a
#define rq_prio_remove_task(rq, p) do { } while(0)
#define rq_prio_add(rq, p) do { } while(0)
for the !CONFIG_SMP case.
Will fix.
-- Steve
-
| Oct 19, 12:19 pm 2007 |
| Gregory Haskins | Re: [patch 2/8] track highest prio queued on runqueue
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
We are better off doing this in enqueue_task() or PI boosting will fail
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
<=3D ?
We only need to recalc if the task being removed was the highest prio
(or higher, if that were possible but it shouldnt be).
I think this logic will technically work as-is because every task is
always >=3D highest in a properly accounted system, so you will ...
| Oct 19, 12:45 pm 2007 |
| Steven Rostedt | [patch 3/8] push RT tasks
This patch adds an algorithm to push extra RT tasks off a run queue to
other CPU runqueues.
When more than one RT task is added to a run queue, this algorithm takes
an assertive approach to push the RT tasks that are not running onto other
run queues that have lower priority. The way this works is that the highest
RT task that is not running is looked at and we examine the runqueues on
the CPUS for that tasks affinity mask. We find the runqueue with the lowest
prio in the CPU affinity of the ...
| Oct 19, 11:42 am 2007 |
| Steven Rostedt | [patch 7/8] wake up balance RT
This patch adds pushing of overloaded RT tasks from a runqueue that is
having tasks (most likely RT tasks) added to the run queue.
TODO: We don't cover the case of waking of new RT tasks (yet).
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/sched.c | 1 +
kernel/sched_rt.c | 12 ++++++++++++
2 files changed, 13 insertions(+)
Index: linux-test.git/kernel/sched_rt.c
===================================================================
--- ...
| Oct 19, 11:43 am 2007 |
| Steven Rostedt | [patch 4/8] RT overloaded runqueues accounting
This patch adds an RT overload accounting system. When a runqueue has
more than one RT task queued, it is marked as overloaded. That is that it
is a candidate to have RT tasks pulled from it.
Along with the rt_overload counter (number of overloaded runqueues) a
bit mask of overloaded runqueues with RT tasks is set.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/sched_rt.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
Index: ...
| Oct 19, 11:42 am 2007 |
| Erez Zadok | Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockde ...
Yeah, I guess around that time. If you want, I could go back and test each
Neat. Curious, but where does "mtd0" come from then? It's not in my /dev
See below.
> J
| Oct 19, 1:04 pm 2007 |
| Jörn | Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockde ...
Side note: you don't need mtdblock:
# cp jffs2-empty.img /tmp/foo
# losetup /dev/loop0 /tmp/foo
# modprobe block2mtd block2mtd=/dev/loop0,128ki
# mount -t jffs2 mtd0 /n/lower/b0
Could be my problem. I'll see if I can reproduce it. Can you send me
your .config or a link to it?
Jörn
--
/* Keep these two variables together */
int bar;
-
| Oct 19, 12:14 pm 2007 |
| Peter Zijlstra | Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockde ...
Someone stuck a key object in non static storage. That breaks lockdep,
don't do that :-)
Is the mutex_init() done from a function tagged with __init?
-
| Oct 19, 11:31 am 2007 |
| Erez Zadok | [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockdep_in ...
I've been having this problem for some time with mtd, which I use to mount
jffs2 images (for unionfs testing). I've seen it in several recent major
kernels, including 2.6.24. Here's the sequence of ops I perform:
# cp jffs2-empty.img /tmp/foo
# losetup /dev/loop0 /tmp/foo
# modprobe mtdblock
# modprobe block2mtd block2mtd=/dev/loop0,128ki
# mount -t jffs2 /dev/mtdblock0 /n/lower/b0
The jffs2-empty.img is a small jffs2 image, of an empty directory, created
w/ the jffs2 utils. At the point ...
| Oct 19, 10:53 am 2007 |
| Erez Zadok | Re: [BLOCK2MTD] WARNING: at kernel/lockdep.c:2331 lockde ...
I was able to verify that the same lockdep warning comes up in every major
kernel all the way back to 2.6.18. Of course the line number in lockdep.c
that causes the warning is slightly different from kernel to kernel, but the
stack trace is the same.
Hope this helps.
Erez.
-
| Oct 19, 1:37 pm 2007 |
| Samuel Tardieu | Re: [PATCH] eccbuf is statically defined and always eval ...
On 19/10, Jörn Engel wrote:
| I assume you don't actually use this driver and just ran make
| randconfig or allyesconfig or so..
I tried the latest svn tip of GCC and it looks like this warning is
quite recent (and I happened to have this driver enabled as a module
in my kernel):
drivers/mtd/devices/doc2000.c: In function ‘doc_read’:
drivers/mtd/devices/doc2000.c:635: warning: the address of ‘eccbuf’ will always evaluate as ‘true’
drivers/mtd/devices/doc2000.c: In function ...
| Oct 19, 12:58 pm 2007 |
| Jörn | Re: [PATCH] eccbuf is statically defined and always eval ...
Acked-by: Joern Engel <joern@logfs.org>
I assume you don't actually use this driver and just ran make
randconfig or allyesconfig or so..
Jörn
--
Science is like sex: sometimes something useful comes out,
but that is not the reason we are doing it.
-- Richard Feynman
-
| Oct 19, 12:06 pm 2007 |
| Samuel Tardieu | [PATCH] eccbuf is statically defined and always evaluate ...
---
drivers/mtd/devices/doc2000.c | 4 ++--
drivers/mtd/devices/doc2001plus.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/devices/doc2000.c b/drivers/mtd/devices/doc2000.c
index c73e96b..e9ce241 100644
--- a/drivers/mtd/devices/doc2000.c
+++ b/drivers/mtd/devices/doc2000.c
@@ -632,7 +632,7 @@ static int doc_read(struct mtd_info *mtd, loff_t from, size_t len,
len = ((from | 0x1ff) + 1) - from;
/* The ECC will not be calculated ...
| Oct 19, 10:26 am 2007 |
| Samuel Tardieu | Re: [PATCH] eccbuf is statically defined and always eval ...
Off course, there should be the required
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
on this patch.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
-
| Oct 19, 11:17 am 2007 |
| Rodolfo Giometti | [RFC] LinuxPPS (pre)patch
Hello,
here my last patch of LinuxPPS.
Main differences from old versions is that now (finally) each PPS
source is a dedicated char device!
This thanks to an agreement with NTP people who suggested to me how to
interpret RFC 2783 in such a way even a dedicated char device is now
RFC complain.
Please, take a look at the code and report all suggestions and/or
needed modifications for kernel inclusion so I can provide a final
patch.
Ciao,
Rodolfo
--
GNU/Linux Solutions ...
| Oct 19, 10:41 am 2007 |
| Rodolfo Giometti | Oops: [RFC] LinuxPPS (pre)patch
Sorry... attached. :)
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@gnudd.com
Embedded Systems giometti@linux.it
UNIX programming phone: +39 349 2432127
| Oct 19, 10:53 am 2007 |
| Timur Tabi | request_firmware() and in-kernel modules
If my driver is compiled in-kernel (and I have module support turned
off), can I still use request_firmware()? If my driver is loaded before
the file system drivers are loaded, how can a user process copy the
firmware to the /sys/class/firwmare/.../data device?
-
| Oct 19, 10:35 am 2007 |
| Martin Schwidefsky | [patch 09/10] Cleanup page table definitions.
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
- De-confuse the defines for the address-space-control-elements
and the segment/region table entries.
- Create out of line functions for page table allocation / freeing.
- Simplify get_shadow_xxx functions.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
arch/s390/mm/Makefile | 2
arch/s390/mm/init.c | 26 +---
arch/s390/mm/pgtable.c | 96 +++++++++++++++++
arch/s390/mm/vmem.c ...
| Oct 19, 10:19 am 2007 |
| Martin Schwidefsky | [patch 02/10] Add per-cpu idle time / idle count sysfs a ...
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Add two new sysfs entries per cpu: idle_count and idle_time.
idle_count contains the number of times a cpu went into idle state.
idle_time contains the time a cpu spent in idle state in microseconds.
This can be used e.g. by powertop to tell how often idle state is
entered and left.
# cat /sys/devices/system/cpu/cpu0/idle_count
504
# cat /sys/devices/system/cpu/cpu0/idle_time
469734037 us
Cc: Arjan van de Ven ...
| Oct 19, 10:18 am 2007 |
| Martin Schwidefsky | [patch 10/10] 4level-fixup cleanup
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
Get independent from asm-generic/4level-fixup.h
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
arch/s390/lib/uaccess_pt.c | 7 ++
arch/s390/mm/init.c | 6 +-
arch/s390/mm/vmem.c | 34 ++++++++++--
include/asm-s390/page.h | 4 +
include/asm-s390/pgalloc.h | 32 ++++++++---
include/asm-s390/pgtable.h | 123 ++++++++++++++++++++++-----------------------
include/asm-s390/tlb.h | 2
7 ...
| Oct 19, 10:19 am 2007 |
| Martin Schwidefsky | [patch 00/10] 2nd batch of s390 patches for 2.6.24.
The latest and greatest for 2.6.24. This patch set includes the tlb flush
fix that has been discussed back in June/July and a cleanup of the mm
related definitions for s390. I have three more patches in the works that
go on top of the cleanup. These three patches add two new features:
1) dynamic number of page table levels and 2) 1K/2K sized page tables.
For both features common code changes are required. I'll apply a bit more
polish to the patches and then send them for review.
The shortlog ...
| Oct 19, 10:18 am 2007 |
| Martin Schwidefsky | [patch 03/10] cio: Use to_channelpath() for device to ch ...
From: Cornelia Huck <cornelia.huck@de.ibm.com>
We already have a macro for that, so let's use it consistently...
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
drivers/s390/cio/chp.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Index: quilt-2.6/drivers/s390/cio/chp.c
===================================================================
--- quilt-2.6.orig/drivers/s390/cio/chp.c
+++ ...
| Oct 19, 10:19 am 2007 |
| Martin Schwidefsky | [patch 08/10] Introduce follow_table in uaccess_pt.c
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
Define and use follow_table inline in uaccess_pt.c to simplify
the code.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
arch/s390/lib/uaccess_pt.c | 85 +++++++++++----------------------------------
1 file changed, 22 insertions(+), 63 deletions(-)
Index: quilt-2.6/arch/s390/lib/uaccess_pt.c
===================================================================
--- quilt-2.6.orig/arch/s390/lib/uaccess_pt.c
+++ ...
| Oct 19, 10:19 am 2007 |
| Martin Schwidefsky | [patch 06/10] tlb flush fix.
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
The current tlb flushing code for page table entries violates the
s390 architecture in a small detail. The relevant section from the
principles of operation (SA22-7832-02 page 3-47):
"A valid table entry must not be changed while it is attached
to any CPU and may be used for translation by that CPU except to
(1) invalidate the entry by using INVALIDATE PAGE TABLE ENTRY or
INVALIDATE DAT TABLE ENTRY, (2) alter bits 56-63 of a ...
| Oct 19, 10:19 am 2007 |
| Martin Schwidefsky | [patch 07/10] Remove unused user_seg from thread structure.
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
arch/s390/kernel/process.c | 2 --
include/asm-s390/processor.h | 14 +++-----------
2 files changed, 3 insertions(+), 13 deletions(-)
Index: quilt-2.6/arch/s390/kernel/process.c
===================================================================
--- quilt-2.6.orig/arch/s390/kernel/process.c
+++ quilt-2.6/arch/s390/kernel/process.c
@@ -270,14 +270,12 @@ int ...
| Oct 19, 10:19 am 2007 |
| Martin Schwidefsky | [patch 04/10] cio: Fix incomplete commit for uevent supp ...
From: Cornelia Huck <cornelia.huck@de.ibm.com>
Commit fa1a8c23eb7d3ded8a3c6d0e653339a2bc7fca9e intended to
introduce uevent suppression for subchannels, but half of it was
lost somewhere. Now, we end up with two uevents for every registered
subchannel :( So we should better add the missing part from
http://marc.info/?l=linux-kernel&m=117515953113974&w=2.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
...
| Oct 19, 10:19 am 2007 |
| Martin Schwidefsky | [patch 05/10] struct class_device -> struct device conversion.
From: Cornelia Huck <cornelia.huck@de.ibm.com>
Convert struct class_device users under drivers/s390/char to use
struct device.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
drivers/s390/char/raw3270.c | 26 +++++++++++---------------
drivers/s390/char/tape_class.c | 19 +++++++------------
drivers/s390/char/tape_class.h | 4 ++--
drivers/s390/char/vmlogrdr.c | 15 ++++++---------
4 files changed, 26 ...
| Oct 19, 10:19 am 2007 |
| Martin Schwidefsky | [patch 01/10] Update default configuration.
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
arch/s390/defconfig | 108 ++++++++++++++++++++++++++++++++++++----------------
1 file changed, 75 insertions(+), 33 deletions(-)
Index: quilt-2.6/arch/s390/defconfig
===================================================================
--- quilt-2.6.orig/arch/s390/defconfig
+++ quilt-2.6/arch/s390/defconfig
@@ -1,8 +1,9 @@
#
# Automatically generated make config: don't ...
| Oct 19, 10:18 am 2007 |
| Russell King | Re: PCMCIA driver resource allocation
That's from around the time that I handed PCMCIA over to Dominik, and was
a to-do item. I had some drivers converted over - mainly the few that I
was using, those being serial and pcnet_cs (serial is converted over but
the patch I had for pcnet_cs is below.)
However, in spite of me pointing Dominik at my remaining patch sets several
times, as far as I could tell they got ignored. So essentially I all lost
Wrong function. release_resource() doesn't pair with ...
| Oct 19, 3:40 pm 2007 |
| Bjorn Helgaas | PCMCIA driver resource allocation
Question 1: Does the linux-pcmcia list still exist? It's in MAINTAINERS:
PCMCIA SUBSYSTEM
P: Linux PCMCIA Team
L: linux-pcmcia@lists.infradead.org
L: http://lists.infradead.org/mailman/listinfo/linux-pcmcia
T: git kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
S: Maintained
but the archive: http://lists.infradead.org/mailman/listinfo/linux-pcmcia
seems dead.
Question 2: Documentation/pcmcia/driver-changes.txt says drivers should
now claim ...
| Oct 19, 9:51 am 2007 |
| Roopesh | MMC: CRC Errors with 2GB cards
Hi,
I am seeing a lot of CRC errors happening with CMD25 on a couple
of Transcend 2GB cards (specifiation version 1.1). However, if
I apply the following patch, I see no errors being reported
--- linux-2.6.22/drivers/mmc/card/block.c 2007-09-27 14:59:44.000000000 +0530
+++ linux-tao/drivers/mmc/card/block.c 2007-10-19 20:53:52.000000000 +0530
@@ -298,6 +298,7 @@
}
if (rq_data_dir(req) != READ) {
+ /* Wait for the card to to be in transfer state*/
do {
int ...
| Oct 19, 9:17 am 2007 |
| Larry Finger | Re: Locking problem in usbserial with 2.6.23-git 5a34417f
Yes, this patch did fix the locking problem.
Thanks,
Larry
-
| Oct 19, 2:29 pm 2007 |
| Larry Finger | Re: Locking problem in usbserial with 2.6.23-git 5a34417f
As I said earlier, the lock problem went away; however, I get the following two kernel warnings:
WARNING: at kernel/sched.c:3475 sub_preempt_count()
Call Trace:
[<ffffffff8022df50>] sub_preempt_count+0x7e/0x91
[<ffffffff80237eb9>] local_bh_enable_ip+0x91/0xf5
[<ffffffff803eaaa8>] _spin_unlock_bh+0x39/0x3e
[<ffffffff88405409>] :ppp_generic:ppp_channel_push+0x72/0xad
[<ffffffff88406528>] :ppp_generic:ppp_write+0x10f/0x121
[<ffffffff8028f75d>] vfs_write+0xae/0x137
[<ffffffff8028fcc6>] ...
| Oct 19, 2:36 pm 2007 |
| Larry Finger | Re: Locking problem in usbserial with 2.6.23-git 5a34417f
It does work better. With it, I was able to make a dial-up connection and send pings over it.
Larry
-
| Oct 19, 3:19 pm 2007 |
| Jiri Kosina | Re: Locking problem in usbserial with 2.6.23-git 5a34417f
I guess this one is needed.
From: Jiri Kosina <jkosina@suse.cz>
USB: usbserial - fix potential deadlock between write() and irq
usb_serial_generic_write() doesn't disable interrupts when taking port->lock,
and could therefore deadlock with usb_serial_generic_read_bulk_callback()
being called from interrupt, taking the same lock. Fix it.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 88a2c7d..6f8d712 ...
| Oct 19, 2:06 pm 2007 |
| Jiri Kosina | Re: Locking problem in usbserial with 2.6.23-git 5a34417f
That's because I messed up the patch, sorry. The one below should work
better.
From: Jiri Kosina <jkosina@suse.cz>
USB: usbserial - fix potential deadlock between write() and IRQ
usb_serial_generic_write() doesn't disable interrupts when taking port->lock,
and could therefore deadlock with usb_serial_generic_read_bulk_callback()
being called from interrupt, taking the same lock. Fix it.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
diff --git a/drivers/usb/serial/generic.c ...
| Oct 19, 3:05 pm 2007 |
| Larry Finger | Locking problem in usbserial with 2.6.23-git 5a34417f
While attempting to configure a new USB modem, the following locking problem occurred. In addition,
shortly after this problem occurred, the computer froze. The log data starts at the point that
usbserial was loaded and contains everything that was written to disk before the machine locked up.
Some info may be missing from the end of the stack dump.
The system is an HP laptop running an x86_64 system. NetworkManager was used to initiate the modem
connection.
Dump Contents:
usbcore: ...
| Oct 19, 8:59 am 2007 |
| Samuel Tardieu | Re: OOM notifications
>>>>> "Pavel" == Pavel Machek <pavel@ucw.cz> writes:
Pavel> That works okay on a PC, but try cellphone one day.
Pavel> You want management app to close the least used
Pavel> application. You do not want _kernel_ to select "who to send
Pavel> SIGTERM to".
That's why I would prefer that *all* processes receive the
SIGDANGER/whatever (and of course ignore it by default). Only the
management app would handle it in the case you describe and would
select one or more applications to unload to ...
| Oct 19, 8:18 am 2007 |
| Chris Friesen | Re: OOM notifications
It's still helpful to have two stages...one that all apps can listen to
(and try to reduce their footprint if possible), and a second one that
only the manager would handle (and would kill some suitable target).
Finally, if all that fails then the kernel starts whacking things.
Chris
-
| Oct 19, 9:58 am 2007 |
| Bernhard Walle | [PATCH] Add additional argument to bootmem reservation
This patch adds the additional bootmem reservation argument to all other
architectures which didn't compile after
kexec-introduce-bootmem_exclusive.patch has been merged [1].
It also adds a flags argument to reserve_bootmem_node().
I tested compilation on i386, x86_64 and ia64 with different memory
configurations. I hope that all other architectures work again, if not, drop me
a note with the compiler error and I'll create a patch that fixes it.
[1] Andrew, I thought it was clear from ...
| Oct 19, 8:07 am 2007 |
| Bernhard Walle | [PATCH] Use BOOTMEM_EXCLUSIVE for crashkernel reservation
This patch implements the usage of BOOTMEM_EXCLUSIVE for crashkernel
reservation on other architectures. The only architecture that applies
is sh.
The patch is based on current git tree plus
kexec-introduce-bootmem_exclusive.patch from -mm tree.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
---
arch/sh/kernel/setup.c | 29 ++++++++++++++++++-----------
1 file changed, 18 insertions(+), 11 deletions(-)
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -140,19 +140,26 ...
| Oct 19, 7:52 am 2007 |
| ericvh | [PATCH] 9p: add virtio transport
From: Eric Van Hensbergen <ericvh@gmail.com>
This adds a transport to 9p for communicating between guests and a host
using a virtio based transport.
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
---
Documentation/filesystems/9p.txt | 8 +-
include/linux/virtio_9p.h | 10 +
net/9p/Kconfig | 7 +
net/9p/Makefile | 4 +
net/9p/trans_virtio.c | 354 ++++++++++++++++++++++++++++++++++++++
5 files changed, 380 ...
| Oct 19, 7:20 am 2007 |
| ericvh | [PATCH] lguest: add 9p socket gateway to launcher
From: Eric Van Hensbergen <ericvh@gmail.com>
This adds code to setup a gateway between virtio and a 9p server on the other
side of a TCP/IP socket. I looked into trying to come up with more of a
"plug-in" model for such lguest launcher extensions, but wasn't happy with
any of the alternatives I had initially come up with.
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
---
Documentation/lguest/lguest.c | 127 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 127 ...
| Oct 19, 7:21 am 2007 |
| kyle | Re: Syba 8-Port Serial Card Unidentified By Kernel
I also have an 8 port PCI serial card with the 8871 chip on it and a
breakout cable. It is identified as such on my machine:
01:02.0 Serial controller: PLX Technology, Inc. Unknown device 9016 (rev 01)
(prog-if 02 [16550])
Subsystem: Unknown device 544e:0008
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: ...
| Oct 19, 7:17 am 2007 |
| David Gaarenstroom | Fwd: [patch] PCI: disable MSI on more ATI NorthBridges
"Here" as in "here at AMD"?! I'm stunned...
Both AMD and the former ATI should have quite some experience?!
-
| Oct 19, 7:10 am 2007 |
| Adrian Bunk | [2.6 patch] fs/9p/v9fs.c: memleak fix
This patch fixes a memory leak introduced by
commit ba17674fe02909fef049fd4b620a2805bdb8c693.
Spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
--- linux-2.6/fs/9p/v9fs.c.old 2007-10-19 15:56:06.000000000 +0200
+++ linux-2.6/fs/9p/v9fs.c 2007-10-19 15:57:00.000000000 +0200
@@ -152,26 +152,27 @@ static void v9fs_parse_options(struct v9
case Opt_access:
s = match_strdup(&args[0]);
v9ses->flags &= ~V9FS_ACCESS_MASK;
if (strcmp(s, "user") == ...
| Oct 19, 7:05 am 2007 |
| Adrian Bunk | [2.6 patch] fix mm/util.c:krealloc()
Commit ef8b4520bd9f8294ffce9abd6158085bde5dc902 added one NULL check for
"p" in krealloc(), but that doesn't seem to be enough since there
doesn't seem to be any guarantee that memcpy(ret, NULL, 0) works
(spotted by the Coverity checker).
For making it clearer what happens this patch also removes the
pointless min().
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
--- linux-2.6/mm/util.c.old 2007-10-19 15:10:43.000000000 +0200
+++ linux-2.6/mm/util.c 2007-10-19 15:32:01.000000000 ...
| Oct 19, 7:05 am 2007 |
| Christoph Lameter | Re: [2.6 patch] fix mm/util.c:krealloc()
Acked-by: Chriustoph Lameter <clameter@sgi.com>
-
| Oct 19, 10:42 am 2007 |
| Miklos Szeredi | Re: [2.6 patch] fuse_file_alloc(): fix NULL dereferences
Thanks!
Miklos
-
| Oct 19, 7:14 am 2007 |
| Adrian Bunk | [2.6 patch] fuse_file_alloc(): fix NULL dereferences
This patch fixes obvious NULL dereferences spotted by the Coverity
checker.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
53b7c67ef9b6c26a0c7f554fef43021633a48ab7
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 0fcdba9..535b373 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -55,9 +55,10 @@ struct fuse_file *fuse_file_alloc(void)
if (!ff->reserved_req) {
kfree(ff);
ff = NULL;
+ } else {
+ INIT_LIST_HEAD(&ff->write_entry);
+ atomic_set(&ff->count, 0);
...
| Oct 19, 7:05 am 2007 |
| Bartlomiej Zolnierki ... | Oct 19, 2:00 pm 2007 | |
| Adrian Bunk | [2.6 patch] ide/pci/sis5513.c: add missing "else"
This patch adds a missing "else" that was missing in
commit c77a89cd98d99819f23a4a08e5e17ee1f13f6e4d.
Spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
2e4b8d4f58ea45e55c87ba5563b0d0e135cac2b4
diff --git a/drivers/ide/pci/sis5513.c b/drivers/ide/pci/sis5513.c
index c1d280b..1680926 100644
--- a/drivers/ide/pci/sis5513.c
+++ b/drivers/ide/pci/sis5513.c
@@ -264,7 +264,7 @@ static void sis_ata133_program_timings(ide_drive_t *drive, const u8 mode)
if (mode ...
| Oct 19, 7:04 am 2007 |
| Adrian Bunk | fs/buffer.c:nobh_write_end(): NULL dereference
Commit 03158cd7eb3374843de68421142ca5900df845d9 introcduced the
following NULL dereference:
<-- snip -->
...
int nobh_write_end(struct file *file, struct address_space *mapping,
loff_t pos, unsigned len, unsigned copied,
struct page *page, void *fsdata)
{
struct inode *inode = page->mapping->host;
struct buffer_head *head = NULL;
struct buffer_head *bh;
if (!PageMappedToDisk(page)) {
if ...
| Oct 19, 6:43 am 2007 |
| Linas Vepstas | Re: [patch] PCI: disable MSI on more ATI NorthBridges
As someone else pointed out, AMD should have *lots* of people with
pci and msi experience on the payroll. (Folks here buy AMD-designed
Not sure. Sounds like the device driver needs a quirk for this part.
The over-worked Jeff Garzik is the maintainer for that driver.
You should probably provide the pci device id for this beast.
--linas
-
| Oct 19, 12:57 pm 2007 |
| Shane Huang | RE: [patch] PCI: disable MSI on more ATI NorthBridges
Yes, you are right, to find out the root cause is better. Thank you
for all your suggestion and information to us.
Since we have little experience on PCI and MSI here, we had to try to
disable MSI before we find a better solution. But as you are giving
I'm using kernel 2.6.23-rc5 to debug this MSI problem, which can NOT
boot on our Trevally board(RS690+SB700) without any kernel modification.
But if I comment out all the pci_intx() function calls in
drivers/pci/msi.c, it can boot now with ...
| Oct 19, 6:17 am 2007 |
| Jeff Garzik | Re: [patch] PCI: disable MSI on more ATI NorthBridges
Take a look at tg3.c net driver change
2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar situation.
However, it may turn out that removing the pci_intx() stuff as a general
rule is easier than quirking these devices, if enough of them turn out
to have this hardware bug.
The tg3.c change should illustrate how to fix immediately, though.
Jeff
-
| Oct 19, 1:21 pm 2007 |
| Christoph Hellwig | [PATCH] clean up vmtruncate
vmtruncate is a twisted maze of gotos, this patch cleans it up to
have a proper if else for the two major cases of extending and
truncating truncate and thus makes it a lot more readable while
keeping exactly the same functinality.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/mm/memory.c
===================================================================
--- linux-2.6.orig/mm/memory.c 2007-09-14 13:51:55.000000000 +0200
+++ linux-2.6/mm/memory.c 2007-09-14 ...
| Oct 19, 6:11 am 2007 |
| Joerg Roedel | [PATCH 0/2] x86: MCE optimization and cleanups
This patchset includes two patches.
1. Checks for the MCA fetures as early as possible and signedness fixup.
2. Minor coding style cleanup.
-
| Oct 19, 5:54 am 2007 |
| Joerg Roedel | [PATCH 1/2] x86: MCE optimization/refactoring
MCG_CAP never reports a negative count of available error-reporting banks.
Therefore, make nr_mce_banks unsigned.
Check for MCE feature bit as early as possible and clean up the extra _MCE
checks in the various cpu init type functions per request from Thomas Gleixner.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
---
arch/x86/kernel/cpu/mcheck/k7.c | 6 +-----
arch/x86/kernel/cpu/mcheck/mce.c | 12 ++++++++++--
...
| Oct 19, 5:54 am 2007 |
| Joerg Roedel | [PATCH 2/2] x86: mce minor indent cleanup
remove one indent level
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
---
arch/x86/kernel/cpu/mcheck/mce.c | 40 +++++++++++++++++++-------------------
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index c7246cc..e418c2f 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -45,26 +45,26 @@ void ...
| Oct 19, 5:54 am 2007 |
| Adrian Bunk | sound/pci/hda/patch_via.c: array overflow
sound/pci/hda/patch_via.c contains the following code:
<-- snip -->
...
struct via_spec {
...
hda_nid_t private_dac_nids[4];
... ^^^
};
...
static int vt1709_auto_fill_dac_nids(struct via_spec *spec,
const struct auto_pin_cfg *cfg)
{
...
spec->multiout.dac_nids = spec->private_dac_nids;
if (cfg->line_outs == 4) { /* 10 channels */ <------------------
for (i = 0; i < ...
| Oct 19, 5:57 am 2007 |
| Joerg Roedel | Re: [PATCH] x86: rename iommu.h to gart.h
Right. The exported function and variable names need also a rename in
some cases. I'll prepare a new patch for that to keep the patches small.
Joerg
--
| AMD Saxony Limited Liability Company & Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
...
| Oct 19, 5:46 am 2007 |
| Joerg Roedel | [PATCH] x86: rename iommu.h to gart.h
This patch renames the include file asm-x86/iommu.h to asm-x86/gart.h to make
clear to which IOMMU implementation it belongs. The patch also adds "GART" to
the Kconfig line.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
---
arch/x86/kernel/aperture_64.c | 2 +-
arch/x86/kernel/early-quirks_64.c | 2 +-
arch/x86/kernel/pci-calgary_64.c | 2 +-
arch/x86/kernel/pci-dma_64.c | 2 +-
arch/x86/kernel/pci-gart_64.c | 2 +-
arch/x86/kernel/pci-nommu_64.c ...
| Oct 19, 5:38 am 2007 |
| Muli Ben-Yehuda | Re: [PATCH] x86: rename iommu.h to gart.h
Long overdue IMHO. How about also renaming the config option to
CONFIG_GART_IOMMU while you're at it?
Cheers,
Muli
--
SYSTOR 2007 --- 1st Annual Haifa Systems and Storage Conference 2007
http://www.haifa.il.ibm.com/Workshops/systor2007/
Virtualization workshop: Oct 29th, 2007 | Storage workshop: Oct 30th, 2007
-
| Oct 19, 5:40 am 2007 |
| Alessandro Suardi | Re: 2.6.23-git10 make bzImage problem
Same here - but it -git13 seems to be back to proper behavior...
[asuardi@sandman boot]$ file vmlinuz-2.6.23-git? vmlinuz-2.6.23-git??
vmlinuz-2.6.23-git3: Linux kernel x86 boot executable RO-rootFS,
root_dev 0x807, swap_dev 0x1, Normal VGA
vmlinuz-2.6.23-git6: Linux kernel x86 boot executable RO-rootFS,
root_dev 0x807, swap_dev 0x1, Normal VGA
vmlinuz-2.6.23-git10: Linux kernel x86 boot executable zImage, version
2.6.23-git10 (asuardi@sandman) , RO-rootFS, root_dev 0x807, swap_dev
0x1, ...
| Oct 19, 5:26 am 2007 |
| Jan Engelhardt | Missing kconfig help for P54_COMMON
Hi,
'would be nice to have some help text for
Softmac Prism54 support (P54_COMMON) [N/m] (NEW)
Prism54 USB support (P54_USB) [N/m] (NEW)
Prism54 USB support (P54_USB) [N/m] (NEW)
Prism54 PCI support (P54_PCI) [N/m] (NEW)
Sorry, no help available for this option yet.
thanks,
j
-
| Oct 19, 4:44 am 2007 |
| Aurelien Jarno | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Carsten Otte a
| Oct 19, 4:31 am 2007 |
| Laurent Vivier | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
How do you know the problem has been introduced by kvm ?
Laurent
--
---------------- Laurent.Vivier@bull.net -----------------
"Given enough eyeballs, all bugs are shallow" E. S. Raymond
-
| Oct 19, 4:42 am 2007 |
| Christian Borntraeger | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
no, we have nvidia, so its sata_nv.
-
| Oct 19, 7:48 am 2007 |
| Carsten Otte | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
I don't. In fact I think it has not been introduced by kvm. All I
stated, is that we experienced the problem when running the kvm.git
kernel after the 2.6.23 update that has not been present in the
kvm.git -rc8 as of last thursday.
-
| Oct 19, 4:49 am 2007 |
| Carsten Otte | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Oh, that's a couple of patches in question. Git-bisect seems to be a
loong way once you loose your installation every time you try.
First thing we do, is figure whether or not 2.6.23.1 as released
breaks our system too. This way, we can either focus on differences
between Linus and Avi, or turn on the big red warning sign saying
"regression".
-
| Oct 19, 5:21 am 2007 |
| Carsten Otte | Re: severe bug in 2.6.23+ kvm.git
Actually, the working version was 2.6.23-rc6, git-head of kvm.git as
of October 11.
-
| Oct 19, 4:55 am 2007 |
| Mike Lampard | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
There was a commit ab9c232286c2b77be78441c2d8396500b045777e regarding libata
on linus's master tree that happened on Friday, that was pulled into kvm git
over the weekend.. I dont know if that may be affecting you.. there is/was
also chatter on LKML regarding some problems with s/g, you may want to check
there.
Cheers
Mike
-
| Oct 19, 4:57 am 2007 |
| Avi Kivity | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
kvm.git is actually 2.6.24-rc, pulled from -linus at a random point in
time, so it's not at all surprising if something is broken.
One option is for you to pull -linus to get the latest and hopefully
greatest and see if the bug is fixed.
Another is to use the external module capability to build kvm.git
against 2.6.23.1.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
-
| Oct 19, 8:13 am 2007 |
| Jan Engelhardt | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Well, do you happen to use sata_mv?
-
| Oct 19, 7:18 am 2007 |
| Christian Borntraeger | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Looks promising.
I pulled this fix by pulling the latest Linus-git into the kvm.git. I also
enabled some debug options in the kernel hacking section. This resulting
kernel seems to be stable so far. We will see in the next days if the problem
is really gone.
Thanks to all for your ideas.
Christian
-
| Oct 19, 11:49 am 2007 |
| Luca Tettamanti | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
linus-git has at least one bug with SG chaining, but usually it just
hangs the machine. Patch is here:
http://lkml.org/lkml/2007/10/17/269
Luca
-
| Oct 19, 8:43 am 2007 |
| Christian Borntraeger | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
No, we dont have an marvel chipset.
kvm:~# lspci
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a4)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev b1)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a4)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f3)
00:07.0 IDE interface: nVidia ...
| Oct 19, 4:58 am 2007 |
| Carsten Otte | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
As stated, we actually did not run any guests and did not load the kvm
kernel modules.
The host root file system gets corrupted to an extend not correctable
by the file system checker (we gave it 24h to repair, then interrupted
it), and it's very easy to reproduce: a simple kernel make on the
hosts lets us reinstall the entire host operating system.
-
| Oct 19, 4:37 am 2007 |
| Laurent Vivier | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Perhaps 2.6.23.1 corrects this ?
http://lkml.org/lkml/2007/10/12/302
Laurent
--
---------------- Laurent.Vivier@bull.net -----------------
"Given enough eyeballs, all bugs are shallow" E. S. Raymond
-
| Oct 19, 4:53 am 2007 |
| Carsten Otte | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Looks like 2.6.23.1 works fine on that box. We'll leave it running over
the weekend with "while true; do make; make clean; done".
-
| Oct 19, 6:44 am 2007 |
| Laurent Vivier | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Did you patch kvm.git with patch-2.6.23.1.bz2 or did you download
linux-2.6.23.1.tar.bz2 ?
2.6.23.1 corrects nothing except sata_mv...
Laurent
--
---------------- Laurent.Vivier@bull.net -----------------
"Given enough eyeballs, all bugs are shallow" E. S. Raymond
-
| Oct 19, 7:57 am 2007 |
| Christian Borntraeger | Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Yes I know. The question we tried to answer was: is the bug in 2.6.23 or was
it introduced after 2.6.23, as kvm.git already contains lots of post 2. 6.23
stuff.
Current state is:
kvm.git with tag 2.6.23-rc6 works for days without a problem.
2.6.23.1 vanilla has survived and is currently still under test.
kvm.git tag master killed our filesystem at least three times.since monday.
I will continue to bang on 2.6.23.1 to see if its really fine. After that,
maybe I will try to bisect on ...
| Oct 19, 8:23 am 2007 |
| Carsten Otte | severe bug in 2.6.23+ kvm.git
Hi list,
we've experienced a severe bug in current kvm.git, that may have been
introduced to the git tree quite recently around last weekend. 2.6.23
is broken, 2.6.23-rc8 works for us. The symptom is, that our operon
kvm test machine shredders its hard disk content to a state that is
not correctably by the file system checker. We use raid1 md mirrored
ext3 file systems on 4 sata hard disks on it, and we've verified
correct operation of the hardware via badblocks and memtest86.
The ...
| Oct 19, 4:22 am 2007 |
| Romano Giannetti | [REGRESSION] locks with v2.6.23-5734-gd85714d (suspend- ...
Hi,
I was testing yesterday release of kernel, and I have had a lot of
problem with the new kernel. It boots ok, the first time it
suspend/resume ok, and then at the second or third attempt to suspend,
the suspend process will not go though (I suspend using s2ram -f
-p -m); it will just lock the screen (I think that's in Ubuntu
scripts) and nothing more. Coming back, there is a message of
the style "DBUS locked up, but recovered" (if you need more
precise information tell me and I'll ...
| Oct 19, 4:20 am 2007 |
| Ingo Molnar | [git pull] x86: fix global_flush_tlb() bug
find a fix for a pretty serious global_flush_tlb() x86-64 bug below,
-stable candidate too i think.
Linus, please pull this fix from the x86 git tree:
ssh://master.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git
|
| Ingo Molnar (1):
| x86: fix global_flush_tlb() bug
thanks,
Ingo
------------------>
Subject: x86: fix global_flush_tlb() bug
From: Ingo Molnar <mingo@elte.hu>
While we were reviewing pageattr_32/64.c for unification,
Thomas Gleixner ...
| Oct 19, 3:48 am 2007 |
| Andi Kleen | Re: [git pull] x86: fix global_flush_tlb() bug
global_flush_tlb() is not very common in the big scheme of things. In a normal
system it only happens single threaded during X server startup and when
the system starts.
So while it's nasty it's unlikely to really hit people in practice.
BTW while looking I noticed this code in the vermilion driver is also
surely not correct:
/*
* Change caching policy of the linear kernel map to avoid
* mapping type conflicts with user-space mappings.
* The first ...
| Oct 19, 5:05 am 2007 |
| Jeff Garzik | Re: Network failure with 2.6.23-git14
What are your network devices? Is your problem with eth0, forcedeth, or
as this traceback implies, eth1?
What is eth1? (driver, bus, ...)
Can you bisect?
Jeff
-
| Oct 19, 9:28 am 2007 |
| Chris Holvenstot | Re: Network failure with 2.6.23-git14
Jeff -
You are correct, it is eth1 - which is the only hardware interface I
have available on the system. It is implemented on the motherboard
using the Nvidia CK804 chip set. My motherboard is an MSI product.
Attached at the end of this is an extract from an lshal command which I
hope will provide what you are looking for.
Bisect - I am willing to give it a try, but I see two problems.
First, git12 was a dead dog on my system. so what ever happened there
is not much of a spread ...
| Oct 19, 11:28 am 2007 |
| Chris Holvenstot | Network failure with 2.6.23-git14
I built 2.6.23-git14 this morning - when booted I can not access the
network via my Ethernet connection. Fallback to 2.6.23-git11 works OK.
One interesting message during boot:
sysctl table check failed: /net/token-ring .3.14 procname does not match
binary path procname
Complete dmesg output follows
[ 0.000000] Linux version 2.6.23-git14 (root@popeye) (gcc version
4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #1 SMP Fri Oct 19 04:31:31 CDT 2007
[ 0.000000] BIOS-provided physical RAM map:
[ ...
| Oct 19, 3:49 am 2007 |
| Mauro Carvalho Chehab | Re: [Fwd: [PATCH 1/4] fix not-and/or errors]
Roel,
Regarding to pvrusb2 driver:
--
Cheers,
Mauro
-
| Oct 19, 3:34 am 2007 |
| Ilpo Järvinen | [PATCH] Fix if (...) \n #if... cases missing semicolons ...
A good candidate to checkpatch.pl's check list, btw.
Signed-off-by: Ilpo J
| Oct 19, 2:06 am 2007 |
| Tim Shimmin | [GIT PULL] XFS update for 2.6.24-rc1
Hi Linus,
A couple of Christoph patches for XFS ...
A fid one for nfs exports which akpm is waiting for.
Thanks.
Please pull from the for-linus branch:
git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus
This will update the following files:
fs/xfs/linux-2.6/xfs_export.c | 6 +++---
fs/xfs/linux-2.6/xfs_export.h | 6 +++---
fs/xfs/linux-2.6/xfs_ioctl.c | 24 ++++++++++++------------
fs/xfs/xfs_dmops.c | 21 ++++-----------------
fs/xfs/xfs_fs.h ...
| Oct 19, 1:30 am 2007 |
| Eric W. Biederman | Re: [PATCH 1/9] irq-remove: core
Good question. At first glance I think the call sites are ok, that
is where we have the information now. Non-genirq architectures needs
work of course.
However given the weird poll case etc that either we need to take this
slow and delay this change until all of the drivers are fixed up, to
not need an irq parameter (as you suggested). Or that we need to
allow both forms of irq handler to coexist temporarily.
Eric
-
| Oct 19, 12:50 pm 2007 |
| Ingo Molnar | Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
the get_irq_regs() approach worked out really well. We should do a
get_irq_nr() and be done with it?
(Then once the mechanic conversion has been done we could eliminate all
uses of get_irq_nr() and remove the small overhead it takes to maintain
this per-cpu value in the irq entry layer.)
full ACK on the concept from me too. Please go ahead! :)
Ingo
-
| Oct 19, 12:07 pm 2007 |
| Eric W. Biederman | Re: [PATCH 1/9] irq-remove: core
Sounds good. That was my impression when I was looking at this kind of stuff.
Just so long as this doesn't slow us down so much we don't actually drop the
ball on this.
Eric
-
| Oct 19, 4:13 pm 2007 |
| Jeff Garzik | [PATCH 2/9] irq-remove: arch non-trivial
commit 8d45690dd90b18daaa21b981ab20caf393220bf0
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 00:46:23 2007 -0400
[IRQ ARG REMOVAL] various non-trivial arch updates
arch/x86/kernel/vm86_32.c | 3 ++-
include/asm-x86/irq_regs_32.h | 25 +++++++++++++++++++++++++
2 files changed, 27 insertions(+), 1 deletion(-)
8d45690dd90b18daaa21b981ab20caf393220bf0
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index 157e4be..18aae9e 100644
--- ...
| Oct 19, 12:55 am 2007 |
| Eric W. Biederman | Re: [PATCH 2/9] irq-remove: arch non-trivial
In this case we can easily pass the irqno into request_irq, allowing
us to do "unsigned int intno = (unsigned int)dev_id;".
I suspect this is the case for the majority of the non-trivial users
as well.
Eric
-
| Oct 19, 10:11 am 2007 |
| Jeff Garzik | Re: [PATCH 1/9] irq-remove: core
'irq' argument is gone from the entire tree, save for
drivers/char/tpm/tpm_tis.c
drivers/scsi/sym53c416.c
drivers/scsi/NCR53C9x.c
drivers/scsi/NCR5380.c
drivers/net/hamradio/scc.c
drivers/ide/ide-io.c
So I'd say the task is within reach :)
All the irq handler cleanups have been checked into branch
'irq-cleanups', and 'irq-remove' branch is rebased on top of that.
Jeff
-
| Oct 19, 4:53 pm 2007 |
| Jeff Garzik | Re: [PATCH 2/9] irq-remove: arch non-trivial
Not that easy, alas :) Save for weirdos like the mac drivers I
highlighted, it seems like most drivers in the non-trivial already pass
a useful pointer to request_irq().
But as I mentioned, most of the "non-trivial" uses are actually trivial
-- just not as simple as removing the 'int irq' argument. Most of the
time the irq number is used in non-critical ways like printk's. A few
times its used to index into a structure (something dev_id could replace).
Jeff
-
| Oct 19, 10:16 am 2007 |
| Jeff Garzik | Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
er, s/error/irq/
the perils of a multi-threaded brain...
-
| Oct 19, 12:02 pm 2007 |
| Eric W. Biederman | Re: [PATCH 2/9] irq-remove: arch non-trivial
I was talking about vm86_32.c in particular. Where we allow user space
Yes.
Eric
-
| Oct 19, 12:38 pm 2007 |
| Jeff Garzik | Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
This is why I'm taking it slow, and not rushing to get this upstream :)
I am finding a ton of bugs in each get_irqfunc_irq() driver, so I would
rather patiently sift through them, and push fixes and cleanups upstream.
Once that effort is done, everything should be in the 'trivial' pile and
not have the logic that you are worried about (and thus there would be
no need to add an additional branch to the error handling path).
Jeff
-
| Oct 19, 11:57 am 2007 |
| Eric W. Biederman | Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
Yes. keeping this alive is good.
The practical question is how do we make this change without breaking
There are two problems with that suggestion.
- We don't have all of the architectures converted.
- We don't have a solid plan for how to keep drivers that are
using the irq parameter today working.
I don't think the irq argument is something we want to keep
around forever, and I certainly don't see the need to do
the error prone get_irqfunc_irq and set_irqfunc_irq logic.
How ...
| Oct 19, 11:38 am 2007 |
| Jeff Garzik | Re: [PATCH 4/9] irq-remove: driver non-trivial
thanks for the comments! I'll work through these.
There are definitely plenty of open issues I haven't yet tackled in the
driver area, as you are seeing. As you noted, a lot of these are with
drivers doing weird things like calling their own interrupt function
with (-1, NULL) or (0, NULL), which triggers some magic "I'm polling"
those two parport changes were bogus, and actually got fixed up in patch #9
-
| Oct 19, 11:36 am 2007 |
| Jeff Garzik | Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
I would prefer to simply clean up the drivers such that
get_irqfunc_irq() and set_irqfunc_irq() are not needed.
One of the many reasons why I'm explicitly not pushing it upstream yet :)
Jeff
-
| Oct 19, 12:55 pm 2007 |
| Jeff Garzik | [PATCH 9/9] irq-remove: misc fixes and cleanups
commit 497cd0c681f0d7144a240af45f5d5eaf5aea75ae
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 01:27:46 2007 -0400
[IRQ ARG REMOVAL] x86-64 build fixes, cleanups
arch/x86/kernel/time_64.c | 2 +-
drivers/atm/horizon.c | 2 +-
drivers/input/touchscreen/ucb1400_ts.c | 2 +-
drivers/mtd/onenand/onenand_base.c | 2 +-
drivers/net/cxgb3/adapter.h | 2 +-
drivers/net/netxen/netxen_nic_main.c | 2 +-
...
| Oct 19, 12:59 am 2007 |
| Jeff Garzik | [PATCH 6/9] irq-remove: sound driver trivial
commit 6348eaa5c5320cc3c4fac5ca1d41b587388e74d9
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 00:48:10 2007 -0400
[IRQ ARG REMOVAL] trivial sound driver updates
sound/aoa/core/snd-aoa-gpio-feature.c | 2 +-
sound/aoa/soundbus/i2sbus/i2sbus-core.c | 2 +-
sound/aoa/soundbus/i2sbus/i2sbus-pcm.c | 4 ++--
sound/aoa/soundbus/i2sbus/i2sbus.h | 4 ++--
sound/arm/aaci.c | 2 +-
sound/arm/pxa2xx-ac97.c | 2 +-
...
| Oct 19, 12:57 am 2007 |
| Jeff Garzik | [PATCH 5/9] irq-remove: net driver trivial
commit 93e93ce573545b3702477088cba8650b565fd60e
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 00:47:56 2007 -0400
[IRQ ARG REMOVAL] trivial net driver updates
drivers/net/3c501.c | 3 +--
drivers/net/3c501.h | 2 +-
drivers/net/3c505.c | 2 +-
drivers/net/3c507.c | 4 ++--
drivers/net/3c509.c | 6 +++---
drivers/net/3c515.c ...
| Oct 19, 12:57 am 2007 |
| Jeff Garzik | [PATCH 8/9] irq-remove: driver trivial
commit 52afddf59be0049d4118b21bdb1ef6bd1c5a9165
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 00:48:47 2007 -0400
[IRQ ARG REMOVAL] trivial driver updates
drivers/acpi/osl.c | 2 +-
drivers/ata/ahci.c | 2 +-
drivers/ata/libata-core.c | 2 +-
drivers/ata/pdc_adma.c | 2 +-
drivers/ata/sata_inic162x.c | 2 +-
drivers/ata/sata_mv.c | 2 ...
| Oct 19, 12:58 am 2007 |
| Salyzyn, Mark | RE: [PATCH 7/9] irq-remove: scsi driver trivial
ACK with comment ...
This API changed in 2.4.23 switching to irqreturn_t, and 2.6.19 dropping
the struct_pt_regs argument, this is yet another API change in the same
function. The last one came with no clues to differentiate except kernel
version (for those of us that are required to produce updated
back-ported driver modules once this patch becomes a legacy). I am
*praying* that this API change is clean across 2.6.24 and add my voice
to all to ACK this clearly!
-
| Oct 19, 6:00 am 2007 |
| Eric W. Biederman | Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
The problem are some drivers today pass in 0 for their irq number
to flag that they are calling the interrupt handler in a polling
mode (not from interrupt context?) so the same logic doesn't quite apply.
Do what you suggest would likely break those drivers.
Eric
-
| Oct 19, 12:35 pm 2007 |
| Jeff Garzik | [PATCH 1/9] irq-remove: core
commit 008b5fcf3c1d8456005de26ddd4256b1369225e8
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 00:45:51 2007 -0400
[IRQ ARG REMOVAL] core interrupt delivery infrastructure updates
include/asm-generic/irq_regs.h | 25 +++++++++++++++++++++++++
include/linux/interrupt.h | 4 ++--
kernel/irq/handle.c | 5 +++--
kernel/irq/manage.c | 4 ++--
kernel/irq/spurious.c | 3 ++-
lib/irq_regs.c | 5 +++++
6 files ...
| Oct 19, 12:55 am 2007 |
| Jeff Garzik | [PATCH 3/9] irq-remove: arch trivial
commit bbf90280966a9661e1a5357f9ee8a94450132d71
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 00:46:37 2007 -0400
[IRQ ARG REMOVAL] trivial arch updates
arch/frv/kernel/dma.c | 2 +-
arch/frv/kernel/irq-mb93091.c | 2 +-
arch/frv/kernel/irq-mb93093.c | 2 +-
arch/frv/kernel/irq-mb93493.c | 2 +-
arch/frv/kernel/time.c | 4 ++--
arch/ia64/kernel/irq_ia64.c ...
| Oct 19, 12:56 am 2007 |
| Jeff Garzik | [PATCH 4/9] irq-remove: driver non-trivial
commit 654f4a242cac0148ffe98ce288c9116e65b08e44
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 00:47:17 2007 -0400
[IRQ ARG REMOVAL] non-trivial driver updates
drivers/atm/ambassador.c | 5 +++--
drivers/bluetooth/btuart_cs.c | 2 +-
drivers/bluetooth/dtl1_cs.c | 2 +-
drivers/char/cyclades.c | 21 +++------------------
drivers/char/ip2/ip2main.c | 10 +++++-----
drivers/char/mwave/tp3780i.c | 10 ...
| Oct 19, 12:56 am 2007 |
| Jeff Garzik | [PATCH 7/9] irq-remove: scsi driver trivial
commit fb66571c6fde956fb8bddacf11d64101f8df8bf8
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 00:48:35 2007 -0400
[IRQ ARG REMOVAL] trivial scsi driver updates
drivers/scsi/3w-9xxx.c | 2 +-
drivers/scsi/3w-xxxx.c | 2 +-
drivers/scsi/53c700.c | 2 +-
drivers/scsi/53c700.h | 2 +-
drivers/scsi/BusLogic.c | 2 +-
drivers/scsi/BusLogic.h | 2 +-
drivers/scsi/NCR5380.h ...
| Oct 19, 12:58 am 2007 |
| Jeff Garzik | Re: [PATCH 1/9] irq-remove: core
Duh. Thanks for pointing out an obvious mistake :)
Fixed and checked into 'irq-remove' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git
-
| Oct 19, 10:48 am 2007 |
| Jeff Garzik | Re: [PATCH 2/9] irq-remove: arch non-trivial
Answering the latter question -- that's the way
include/asm-generic/irq_regs.h was written, and I simply followed their
lead.
One attribute of this method is to avoid preemption, which is probably
necessary in the bowels of irq handling.
Jeff
-
| Oct 19, 10:50 am 2007 |
| Eric W. Biederman | Re: [PATCH 4/9] irq-remove: driver non-trivial
Ok. You have some random cleanups as buried in this patch
as well as the necessary changes to remove the irq argument
Ok. This is to detect to see if we are being called from the poll
Bug because now we don't know if we are being called from the poll
Bug because we can't detect if we are being called from the poll
Hmm. The corresponding change to prototype is missing and
the change to the parport code is missing.
Eric
-
| Oct 19, 11:19 am 2007 |
| Jeff Garzik | Re: [PATCH 1/9] irq-remove: core
Do you think set_irqfunc_irq() should be called at all the callsites of
set_irq_regs(), or one the fix you mention is applied, do you think
current model is sufficient?
Jeff
-
| Oct 19, 11:21 am 2007 |
| Eric W. Biederman | Re: [PATCH 1/9] irq-remove: core
The above two hunks need to call set_irqfunc_irq in your model.
Eric
-
| Oct 19, 10:27 am 2007 |
| Jeff Garzik | Re: [PATCH 2/9] irq-remove: arch non-trivial
Why the pointer? Honestly, I cannot recall. Its most likely due to my
ignorance of the per-cpu API, which always seemed more complicated than
I wished :)
This code was carried from the original days when pt_regs was removed
from the irq handler arguments, so that's probably why x86_write_percpu
was not employed.
I'll make note to fix that up...
Jeff
-
| Oct 19, 10:31 am 2007 |
| Jeff Garzik | [PATCH 0/9] Remove 'irq' argument from all irq handlers
WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE
This posting is just to demonstrate something that I have been keeping
alive in the background. I have no urge to push it upstream anytime
soon.
The overwhelming majority of drivers do not ever bother with the 'irq'
argument that is passed to each driver's irq handler.
Of the minority of drivers that do use the arg, the majority of those
have the irq number stored in their private-info structure somewhere.
There are a ...
| Oct 19, 12:54 am 2007 |
| Eric W. Biederman | Re: [PATCH 1/9] irq-remove: core
Please look at handle_IRQ_event. Local irqs are enabled so irq
recursion can happen. So not handling old_irq is a big nasty
bug.
Eric
-
| Oct 19, 11:04 am 2007 |
| Jeff Garzik | Re: [PATCH 1/9] irq-remove: core
After diving in, in the past couple of hours, I'm pretty confident we
simply do not need {get,set}_irqfunc_irq()
Jeff
-
| Oct 19, 12:58 pm 2007 |
| Jeff Garzik | Re: [PATCH 1/9] irq-remove: core
Hey I'm the one who has kept the ball rolling since the day pt_regs were
removed... :)
Jeff
-
| Oct 19, 4:46 pm 2007 |
| Thomas Gleixner | Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
Jeff,
thanks for doing this.
Full ACK.
We should do this right at the edge of -rc1. And let's do this right
now in .24 and not drag it out for no good reason.
Thanks,
tglx
-
| Oct 19, 7:53 am 2007 |
| Jeremy Fitzhardinge | Re: [PATCH 2/9] irq-remove: arch non-trivial
x86_write_percpu(__irqfunc_irqs, new_irq) would be slightly more
efficient here. Any why the pointer anyway?
J
-
| Oct 19, 9:54 am 2007 |
| Thomas Gleixner | Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
How many of them do we have ? This is a wilful abuse of the API, so
its not a big damage if they break.
tglx
-
| Oct 19, 12:41 pm 2007 |
| Mark Gross | Oct 19, 11:45 am 2007 | |
| Jeff Garzik | [PATCH] atm/stallion/ucb1400_ts: remove needless use of ...
commit aeb16d7836f97576218fae6f3959c415b0fd09f0
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 03:19:08 2007 -0400
[ATM, CHAR, TOUCHSCREEN] remove needless use of irq handler first arg
Like the vast majority of other drivers, these drivers do not need to
reference their 'irq' function argument at all.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
drivers/atm/ambassador.c | 2 +-
drivers/char/stallion.c | 2 +-
...
| Oct 19, 12:34 am 2007 |
| Jeff Garzik | [PATCH] lib82596, netxen: delete pointless tests from ir ...
commit e96888518af94d9f607b996f8b90873330dbfc32
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 03:14:03 2007 -0400
[NETDRVR] lib82596, netxen: delete pointless tests from irq handler
Remove always-false tests in irq handler.
Also a few other minor cleanups.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
drivers/net/lib82596.c | 8 +-------
drivers/net/netxen/netxen_nic_main.c | 11 ++---------
2 files changed, 3 ...
| Oct 19, 12:33 am 2007 |
| Jeff Garzik | [PATCH] aha152x: delete pointless test in irq handler
commit c8f14a99beb85918935334a8374e47db12608d8e
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 03:17:14 2007 -0400
[SCSI] aha152x: delete pointless test in irq handler
Remove always-false test in interrupt handler.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
drivers/scsi/aha152x.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
c8f14a99beb85918935334a8374e47db12608d8e
diff --git a/drivers/scsi/aha152x.c ...
| Oct 19, 12:33 am 2007 |
| Jeremy Fitzhardinge | Oct 19, 12:54 am 2007 | |
| Jeff Garzik | [PATCH] sparc/xen/cxgb3: use irq_handler_t where appropriate
commit 21b1f26bf54a2ba1e4072db6dd01da128b1f66ef
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 03:12:20 2007 -0400
[SPARC, XEN, NET/CXGB3] use irq_handler_t where appropriate
Rather than hand-rolling our own prototype, make the code more
future-proof by using the standard irq_handler_t typedef.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
arch/sparc/kernel/irq.c | 4 ++--
arch/x86/xen/events.c | 4 ++--
drivers/net/cxgb3/adapter.h ...
| Oct 19, 12:33 am 2007 |
| Jeff Garzik | [PATCH] Eliminate pointless casts from void* in a few dr ...
commit 9739eb5090cc136ab50f2b323b83894c38d1ecb9
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 03:10:11 2007 -0400
Eliminate pointless casts from void* in a few driver irq handlers.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
drivers/atm/horizon.c | 5 +++--
drivers/char/tpm/tpm_tis.c | 4 ++--
drivers/mtd/onenand/onenand_base.c | 2 +-
drivers/net/typhoon.c | 2 +-
drivers/net/ucc_geth.c | 2 +-
...
| Oct 19, 12:31 am 2007 |
| Jeff Garzik | [PATCH] bluetooth: Eliminate checks for impossible condi ...
commit 1c8073a42f133bf5780099c1e6efd9e48468cd29
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 03:07:30 2007 -0400
[BLUETOOTH] Eliminate checks for impossible conditions in irq handler
Our info structure and info->hdev is always passed to the irq handler,
so we don't have to worry about these checks in every interrupt.
Leave a BUG_ON() just to help unwary programmers, but these could
probably be removed as well.
Signed-off-by: Jeff Garzik ...
| Oct 19, 12:31 am 2007 |
| Jeff Garzik | [PATCH 3/3] parport: Remove unused 'irq' argument from p ...
commit ed58d6e0a6e1ad61a7dde232de7a4891ebc99f61
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 02:54:26 2007 -0400
[PARPORT] Remove unused 'irq' argument from parport irq functions
None of the drivers with a struct pardevice's ->irq_func() hook ever
used the 'irq' argument passed to it, so remove it.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
drivers/char/ppdev.c | 4 ++--
drivers/input/serio/parkbd.c | 2 +-
...
| Oct 19, 12:30 am 2007 |
| Jeff Garzik | [PATCH 2/3] parport: Kill useless 'irq' arg from parport ...
commit 69a4a1aad140a3d9e17d3e313a3633445a7934fe
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 01:56:02 2007 -0400
[PARPORT] Kill useless 'irq' arg from parport_{generic_irq,ieee1284_interrupt}
parport_ieee1284_interrupt() was not using its first arg at all.
Delete.
parport_generic_irq()'s second arg makes its first arg completely
redundant. Delete, and use port->irq in the one place where we actually
need it.
Also, ...
| Oct 19, 12:30 am 2007 |
| Jeff Garzik | [PATCH 1/3] parport: Consolidate code copies into a sing ...
commit 73ae204aa2b83cee2a9156ff72ef1da99612074e
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 01:42:14 2007 -0400
[PARPORT] Consolidate code copies into a single generic irq handler
Several arches used the exact same code for their parport irq handling.
Make that code generic, in parport_irq_handler().
Also, s/__inline__/inline/ in include/linux/parport.h.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
drivers/parport/parport_amiga.c | ...
| Oct 19, 12:29 am 2007 |
| Shreyansh Jain | Query about Bio submission / Direct IO
Hi List,
I have tried this on kernelnewbies
<http://article.gmane.org/gmane.linux.kernel.kernelnewbies/23166> but it seems
I am not good at explaining well. trying here again.
Question:
Is there a limitation (some kind of caveat) when direct IO pages are added to
a bio (multiple pages per bio) and if the total length or offset of some of
the vectors is not aligned (PAGE_SIZE or sector size)?
My scenario:
1. I have a filesystem in which I create bio for submission to a SCSI disk
...
| Oct 18, 11:17 pm 2007 |
| Thomas Gleixner | Re: [PATCH] x86: mostly merge types.h
Sorry, your patch is late:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9d256ff51c...
And we really want to eliminate the _32/64 variants completely when
ever it is possible.
Thanks,
tglx
-
| Oct 19, 12:02 am 2007 |
| Chris Snook | [PATCH] x86: mostly merge types.h
From: Chris Snook <csnook@redhat.com>
Most of types_32.h and types_64.h are the same. Merge the common definitions
into types.h, keeping the differences in their own files. Also #error if
types_{32,64}.h is included directly. Tested with allmodconfig on x86_64.
Signed-off-by: Chris Snook <csnook@redhat.com>
types.h | 45 +++++++++++++++++++++++++++++++++++++++++++++
types_32.h | 48 ++++++------------------------------------------
types_64.h | 47 ...
| Oct 18, 11:09 pm 2007 |
| Nick Piggin | Re: BUG at mm/filemap.c:1749 (2.6.24, jffs2, unionfs)
Hmm, looks like jffs2_write_end is writing more than we actually ask it
to, and returns that back.
unsigned aligned_start = start & ~3;
and
if (end == PAGE_CACHE_SIZE) {
/* When writing out the end of a page, write out the
_whole_ page. This helps to reduce the number of
nodes in files which have many short writes, like
syslog files. */
start = aligned_start = 0;
}
These ...
| Oct 19, 12:16 am 2007 |
| Erez Zadok | Re: BUG at mm/filemap.c:1749 (2.6.24, jffs2, unionfs)
In message <200710191716.53470.nickpiggin@yahoo.com.au>, Nick Piggin writes:
Nick, the patch worked. All of my unionfs-over-jffs2 tests passed.
Thanks,
Erez.
-
| Oct 19, 10:38 am 2007 |
| Nick Piggin | Re: BUG at mm/filemap.c:1749 (2.6.24, jffs2, unionfs)
It's had quite a lot of recent changes in that area -- the "new aops"
patches.
They've been getting quite a bit of testing in -mm and no such problems,
but I doubt anyone was doing much unionfs over jffs2, or even much jffs2
testing with -mm.
The bug smells like jffs2 is actually passing back a "written" length
greater than the length we passed into it.
The following might show what's happening.
| Oct 19, 12:03 am 2007 |
| Erez Zadok | BUG at mm/filemap.c:1749 (2.6.24, jffs2, unionfs)
David,
I'm testing unionfs on top of jffs2, using 2.6.24 as of linus's commit
4fa4d23fa20de67df919030c1216295664866ad7. All of my unionfs tests pass when
unionfs is stacked on top of jffs2, other than my truncate test -- whic
tries to truncate files up/down (through the union, which then is passed
through to the lower jffs2 f/s). The same truncate test passes on all other
file systems I've tried unionfs/2.6.24 with, as well as all of the earlier
kernels that unionfs runs on (2.6.9--2.6.23). ...
| Oct 18, 11:05 pm 2007 |
| Trond Myklebust | Re: nfsv2 ref leak in 2.6.24?
Let me get this straight:
1) You create the file on the server
2) You readdir the file from the client
3) You stat the file from the client
....with the result that the file disappears from sight on the server?
That would indicate some dcache issues with the server code. What export
I doubt the new patches fix the problem if I did indeed get your method
right.
Cheers
Trond
-
| Oct 19, 2:52 pm 2007 |
| Erez Zadok | nfsv2 ref leak in 2.6.24?
I'm testing unionfs on top of nfsv2/3/4, using 2.6.24 as of linus's commit
4fa4d23fa20de67df919030c1216295664866ad7. A lot of my unionfs regression
tests are failing on nfs2, b/c files that should be deleted, aren't. It
feels like there may be a ref leak that prevents the files from being
deleted, or maybe an unlink issue. It doesn't happen in all of my previous
kernels w/ identical unionfs (code 2.6.9--2.6.23). And in 2.6.24 it happens
only w/ nfs2 -- nfs3/4 are fine.
I'm not sure if this ...
| Oct 18, 10:49 pm 2007 |
| Erez Zadok | Re: nfsv2 ref leak in 2.6.24?
export it to localhost and mount it locally as nfs2. I go and touch a new
file in the ext2 directory. Then I readdir the export point to find the new
file indeed. Then I stat(1) the new file, and get the appropriate stat
output. Now the strange thing is that right after the stat through the
export point, the file DISAPPEARS from the lower ext2 dir, but REAPPEARS a
few seconds later.
It doesn't happen all the time, so it feels like some sort of a race or
timing-related bug. And it only ...
| Oct 19, 2:40 pm 2007 |
| Erez Zadok | Re: nfsv2 ref leak in 2.6.24?
The explicit command I use is:
exportfs -o no_root_squash,rw localhost:/n/export/b0
The options recorded in exportfs -v:
/n/export/b0 localhost.localdomain(rw,wdelay,no_root_squash,no_subtree_check,anonuid=65534,anongid=65534)
Erez.
-
| Oct 19, 3:59 pm 2007 |
| Trond Myklebust | Re: nfsv2 ref leak in 2.6.24?
A couple of questions:
* Are these files being sillyrenamed?
* Are they shown as being removed by the server?
Cheers
Trond
-
| Oct 19, 6:41 am 2007 |
| Greg Ungerer | [M68KNOMMU]: cleanup m68knommu timer code
Reduce the function pointer mess of the m68knommu timer code.
Call direct to the local hardware's timer setup, and expose the local
common timer interrupt handler to the lower level hardware timer.
Ultimately this will save definitions of all these functions across
all the platform code to setup the function pointers (which for
any given m68knommu CPU family member can be only one set of hardware
timer functions).
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diffstat (relative to ...
| Oct 18, 10:29 pm 2007 |
| Nick Piggin | [patch] x86: lock bitops
I missed an obvious one!
x86 CPUs are defined not to reorder stores past earlier loads, so there is
no hardware memory barrier required to implement a release-consistent store
(all stores are, by definition).
So ditch the generic lock bitops, and implement optimised versions for x86,
which removes the mfence from __clear_bit_unlock (which is already a useful
primitive for SLUB).
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: ...
| Oct 18, 10:13 pm 2007 |
| Stephen Rothwell | [PATCH] Make advansys depend on CONFIG_VIRT_TO_BUS
At least for now.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/scsi/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 30905ce..325533c 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -523,6 +523,7 @@ config SCSI_ADVANSYS
tristate "AdvanSys SCSI support"
depends on SCSI
depends on ISA || EISA ...
| Oct 18, 10:04 pm 2007 |
| Andrew Morton | Re: [PATCH] Make advansys depend on CONFIG_VIRT_TO_BUS
My version of this patch does that. I'll be sending it into Linus in an
hour or so.
-
| Oct 18, 10:30 pm 2007 |
| Stephen Rothwell | Re: [PATCH] Make advansys depend on CONFIG_VIRT_TO_BUS
Thanks.
--=20
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
| Oct 18, 11:33 pm 2007 |
| David Miller | Re: [PATCH] Make advansys depend on CONFIG_VIRT_TO_BUS
From: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: David S. Miller <davem@davemloft.net>
-
| Oct 18, 10:07 pm 2007 |
| Randy Dunlap | Re: [PATCH] Make advansys depend on CONFIG_VIRT_TO_BUS
Please explain "why" in the changelog (what changelog?).
E.g.:
so that make allmodconfig on powerpc will have a better chance
of building.
---
~Randy
-
| Oct 18, 10:20 pm 2007 |
| Dave Young | [PATCH] bluetooth: hidp core debug code wrong argument fix
In the debug code of the hidp_queue_report function, the "device" variable does not exist, replace it with "session->hid"
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
---
net/bluetooth/hidp/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -upr linux/net/bluetooth/hidp/core.c linux.new/net/bluetooth/hidp/core.c
--- linux/net/bluetooth/hidp/core.c 2007-10-15 14:05:23.000000000 +0800
+++ linux.new/net/bluetooth/hidp/core.c 2007-10-15 14:06:38.000000000 +0800
@@ ...
| Oct 18, 10:00 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: fix syscall tracing
From: Matt Waddel <Matt.Waddel@freescale.com>
Fix the system call code for handling syscall tracing, so strace
and gdbserver work properly.
This fix originally developed by Philippe De Muyter and Stuart Hughes.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/arch/m68knommu/platform/5307/entry.S linux-2.6.23-uc0/arch/m68knommu/platform/5307/entry.S
--- linux-2.6.23/arch/m68knommu/platform/5307/entry.S 2007-10-19 10:30:55.000000000 +1000
+++ ...
| Oct 18, 9:50 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: fix syscall restart handling
Fix system call restart handling. We can call directly to the
restart handler, no need to back track through trap that isn't
even implemented on m68knommu.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/arch/m68knommu/kernel/signal.c linux-2.6.23-uc0/arch/m68knommu/kernel/signal.c
--- linux-2.6.23/arch/m68knommu/kernel/signal.c 2007-10-19 10:30:55.000000000 +1000
+++ linux-2.6.23-uc0/arch/m68knommu/kernel/signal.c 2007-10-19 10:35:40.000000000 +1000
@@ -781,15 ...
| Oct 18, 9:39 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: no separate stack region to report at startup
There is no separate stack region addresses to print at startup time,
so remove it from the debug listing
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/arch/m68knommu/kernel/setup.c linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c
--- linux-2.6.23/arch/m68knommu/kernel/setup.c 2007-10-19 10:30:54.000000000 +1000
+++ linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c 2007-10-19 10:35:38.000000000 +1000
@@ -188,11 +173,9 @@ void setup_arch(char **cmdline_p)
...
| Oct 18, 9:36 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: remove use of undefined symbols in setup.c
Remove use of undefined symbols CONFIG_TELOS, CONFIG_M68EZ328ADS
and CONFIG_ALMA_ANS.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/arch/m68knommu/kernel/setup.c linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c
--- linux-2.6.23/arch/m68knommu/kernel/setup.c 2007-10-19 10:30:54.000000000 +1000
+++ linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c 2007-10-19 10:35:38.000000000 +1000
@@ -151,27 +148,15 @@ void setup_arch(char **cmdline_p)
#ifdef CONFIG_ELITE
...
| Oct 18, 9:33 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: add make support for Savant/Rosie1 board
From: Wilson Callan <wcallan@savantav.com>
Add make support for the Savant/Rosie1 board.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/arch/m68knommu/Makefile linux-2.6.23-uc0/arch/m68knommu/Makefile
--- linux-2.6.23/arch/m68knommu/Makefile 2007-10-19 10:30:58.000000000 +1000
+++ linux-2.6.23-uc0/arch/m68knommu/Makefile 2007-10-19 10:35:41.000000000 +1000
@@ -48,6 +48,7 @@ board-$(CONFIG_SNEHA) := SNEHA
board-$(CONFIG_M5208EVB) := M5208EVB
...
| Oct 18, 9:30 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: add config support for Savant/Rosie1 board
From: Wilson Callan <wcallan@savantav.com>
Add configure support for the Savant/Rosie1 board.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/arch/m68knommu/Kconfig linux-2.6.23-uc0/arch/m68knommu/Kconfig
--- linux-2.6.23/arch/m68knommu/Kconfig 2007-10-19 10:30:57.000000000 +1000
+++ linux-2.6.23-uc0/arch/m68knommu/Kconfig 2007-10-19 10:35:41.000000000 +1000
@@ -451,6 +451,12 @@ config MOD5272
help
Support for the Netburner MOD-5272 board.
+config ...
| Oct 18, 9:30 pm 2007 |
| Avuton Olrich | In function sysctl_check_lookup: undef ref to sysctl_head_next
Good Day,
My randconfig just caught an error on:
kernel/built-in.o: In function `sysctl_check_lookup':
sysctl_check.c:(.text+0x17db1): undefined reference to `sysctl_head_next'
sysctl_check.c:(.text+0x17dc7): undefined reference to `sysctl_head_finish'
Git bisect was unsuccessful due to too many unrelated errors trying to
track down the issue. I also couldn't track down the offending
function. Any idea of the issue?
Against this config: ...
| Oct 18, 9:27 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: define __clear_user macro
From: Matt Waddel <Matt.Waddel@freescale.com>
Define __clear_user macro, consistent with other architectures.
fs/signalfd.c won't compile without it.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/include/asm-m68knommu/uaccess.h linux-2.6.23-uc0/include/asm-m68knommu/uaccess.h
--- linux-2.6.23/include/asm-m68knommu/uaccess.h 2007-10-19 10:21:31.000000000 +1000
+++ linux-2.6.23-uc0/include/asm-m68knommu/uaccess.h 2007-10-19 10:32:28.000000000 +1000
@@ -170,10 ...
| Oct 18, 9:07 pm 2007 |
| Hirokazu Takata | [GIT PULL] m32r: updates to add missing syscalls
Hello, Linus,
Please pull from:
git://www.linux-m32r.org/git/takata/linux-2.6_dev.git for-linus
This patchset adds missing m32r syscalls for 2.6.23 kernel.
It has been included in 2.6.23-mm1 kernel and tested for a while.
-- Takata
Hirokazu Takata (3):
m32r: Add missing syscalls
m32r: Ignore warnings for unused syscalls
m32r: Update sys_rt_sigsuspend
arch/m32r/kernel/signal.c | 17 ++++------
arch/m32r/kernel/syscall_table.S | 40 ...
| Oct 18, 9:01 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: remove use of undefined symbol CONFIG_DISKt ...
Remove use of undefined symbol CONFIG_DISKtel.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/include/asm-m68knommu/system.h linux-2.6.23-uc0/include/asm-m68knommu/system.h
--- linux-2.6.23/include/asm-m68knommu/system.h 2007-10-19 10:21:31.000000000 +1000
+++ linux-2.6.23-uc0/include/asm-m68knommu/system.h 2007-10-19 10:32:28.000000000 +1000
@@ -253,8 +253,7 @@ cmpxchg(volatile int *p, int old, int ne
"); \
})
#elif defined(CONFIG_NETtel) || ...
| Oct 18, 8:55 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: local module/elf definitions
Up to now m68knommu has been using the asm-m68k/module.h instead of
defining its own. There are recent changes there that we don't need
(fixups specifically). We don't need much support here so it makes
sense to have an m68knommu specific one now.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/include/asm-m68knommu/module.h linux-2.6.23-uc0/include/asm-m68knommu/module.h
--- linux-2.6.23/include/asm-m68knommu/module.h 2007-10-19 10:21:30.000000000 +1000
+++ ...
| Oct 18, 8:54 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: remove use of undefined symbol CONFIG_DISKtel
Remove use of undefined symbol CONFIG_DISKtel.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/include/asm-m68knommu/mcfuart.h linux-2.6.23-uc0/include/asm-m68knommu/mcfuart.h
--- linux-2.6.23/include/asm-m68knommu/mcfuart.h 2007-10-19 10:21:30.000000000 +1000
+++ linux-2.6.23-uc0/include/asm-m68knommu/mcfuart.h 2007-10-19 10:32:26.000000000 +1000
@@ -12,7 +12,6 @@
#define mcfuart_h
...
| Oct 18, 8:51 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: improve code formating FEC driver
From: Philippe De Muyter <phdm@macqel.be>
Indent all the `else' the same way.
Remove some unecesary white space.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/drivers/net/fec.c linux-2.6.23-uc0/drivers/net/fec.c
--- linux-2.6.23/drivers/net/fec.c 2007-10-19 10:25:49.000000000 +1000
+++ linux-2.6.23-uc0/drivers/net/fec.c 2007-10-19 10:34:22.000000000 +1000
@@ -753,13 +753,11 @@ mii_queue(struct net_device ...
| Oct 18, 8:46 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: improve mii_do_cmd code in FEC driver
From: Philippe De Muyter <phdm@macqel.be>
Improve the readability of mii_do_cmd().
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/drivers/net/fec.c linux-2.6.23-uc0/drivers/net/fec.c
--- linux-2.6.23/drivers/net/fec.c 2007-10-19 10:25:49.000000000 +1000
+++ linux-2.6.23-uc0/drivers/net/fec.c 2007-10-19 10:34:22.000000000 +1000
@@ -770,14 +768,11 @@ mii_queue(struct net_device *dev, int re
static void ...
| Oct 18, 8:46 pm 2007 |
| Thomas Gleixner | Re: [PATCH] x86: Fix resume for nVidia and force_hpet
Yep, noticed it when I pushed it into the queue. Fixed it up
already. Please be more careful next time.
Btw, I'm happy to take a follow up patch for platforms which you can
not test and stick them into -mm for a while.
Thanks,
tglx
-
| Oct 19, 11:15 am 2007 |
| Carlos Corbacho | nVidia HPET force enable - merge requirements? (resend)
(Resend with CC's fixed)
Back in April, Mikko posted a patch to force enable the HPET on some nVidia
chipsets:
v2:
http://lkml.org/lkml/2007/4/16/46
v3:
http://lkml.org/lkml/2007/4/17/354
What would need to be done to this patch to get it into x86 now (besides i386/
x86_64 -> x86 conversion), given that:
A) There is now a force_hpet boot parameter in the x86 tree (mm branch)
(rather than relying on the solution in the earlier patches of a config
option).
B) On the other hand, ...
| Oct 18, 8:23 pm 2007 |
| Carlos Corbacho | [PATCH] x86: Fix resume for nVidia and force_hpet
From: Carlos Corbacho <cathectic@gmail.com>
Actually set force_hpet_resume_type.
---
Whoops, just noticed I forgot to re-add this to the patch before submitting it.
arch/x86/kernel/quirks.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index cb21bcb..df01a1e 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -344,6 +344,7 @@ static void nvidia_force_enable_hpet(struct pci_dev *dev)
...
| Oct 19, 11:07 am 2007 |
| Thomas Gleixner | Re: nVidia HPET force enable - merge requirements? (resend)
Yes, looks good. It is just missing the resume part, which is
Don't worry. If HPET is enabled in the BIOS, then we have an
hpet_address already before we come into the force enable
quirk. That's why we check for hpet_address in the quirk code.
tglx
-
| Oct 19, 9:19 am 2007 |
| Carlos Corbacho | x86: Add HPET force support for MCP55 (nForce 5) chipsets
From: Carlos Corbacho <cathectic@gmail.com>
Add support to force_hpet for all known MCP55 (nForce 5) chipset
LPC bridges.
---
These are the untested nForce 5 chips (taken from Mikko's original
patch, and checked against pci.ids).
arch/x86/kernel/quirks.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index df01a1e..8f72148 100644
--- a/arch/x86/kernel/quirks.c
+++ ...
| Oct 19, 11:34 am 2007 |
| Carlos Corbacho | [PATCH] x86: Force enable HPET for CK804 (nForce 4) chipsets
From: Carlos Corbacho <cathectic@gmail.com>
This patch adds a quirk from LinuxBIOS to force enable HPET on
the nVidia CK804 (nForce 4) chipset.
This quirk can very likely support more than just nForce 4
(LinuxBIOS use the same code for nForce 5), and possibly nForce 3,
but I don't have those chipsets, so cannot add and test them.
Tested on an Abit KN9 (CK804).
Signed-off-by: Carlos Corbacho <cathectic@gmail.com>
---
Thomas,
I've rewritten the code based on what LinuxBIOS does, since ...
| Oct 19, 10:51 am 2007 |
| Thomas Gleixner | Re: nVidia HPET force enable - merge requirements? (resend)
There is still a config option for hpet. the hpet=force boot param is
It's not necessary to scan in early_quirks.c at all. The force hpet
code handles the late DECLARE_PCI_FIXUP_HEADER() based detection just
fine.
So if there are working quirks, please refactor them analogous to the
existing ones in quirks.c.
All undocumented chipset poking needs to be protected by the
hpet=force boot option, so the default is not to do scan for it.
Thanks,
tglx
-
| Oct 18, 11:50 pm 2007 |
| Carlos Corbacho | Re: nVidia HPET force enable - merge requirements? (resend)
Thomas,
Would the following patch be more acceptable then? I've limited the device
id's to just the nForce 4 chipset, because that's the only one I have here
to test with at the moment - it appears to work fine:
hpet clockevent registered
hpet0: at MMIO 0xfefff000, IRQs 2, 8, 31
hpet0: 3 32-bit timers, 25000000 Hz
Time: hpet clocksource has been installed.
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
At the moment, I'm not clear on how to detect ...
| Oct 19, 8:29 am 2007 |
| Thomas Gleixner | Re: [PATCH] x86: Force enable HPET for CK804 (nForce 4) ...
Applied. Thanks,
tglx
-
| Oct 19, 10:58 am 2007 |
| Pavel Emelyanov | Re: [PATCH 0/4] Fix race between sk_filter reassign and ...
Yes. The NULL filter is a valid case, when there are no
filters attached at all. So this fix is correct.
-
| Oct 19, 12:37 am 2007 |
| David Miller | Re: [PATCH 0/4] Fix race between sk_filter reassign and ...
From: Pavel Emelyanov <xemul@openvz.org>
No worries, thanks for reviewing.
-
| Oct 19, 12:52 am 2007 |
| Olof Johansson | Re: [PATCH 0/4] Fix race between sk_filter reassign and ...
On Wed, Oct 17, 2007 at 09:23:02PM -0700, David Miller wrote:
Looks like this might be causing problems, at least for me on ppc. This
happened during a normal boot, right around first interface config/dhcp
run..
cpu 0x0: Vector: 300 (Data Access) at [c00000000147b820]
pc: c000000000435e5c: .sk_filter_delayed_uncharge+0x1c/0x60
lr: c0000000004360d0: .sk_attach_filter+0x170/0x180
sp: c00000000147baa0
msr: 9000000000009032
dar: 4
dsisr: 40000000
current = ...
| Oct 18, 7:29 pm 2007 |
| David Miller | Re: [PATCH 0/4] Fix race between sk_filter reassign and ...
From: Olof Johansson <olof@lixom.net>
I've applied this for now to my net-2.6 tree, thanks Olof
for tracking this down.
Pavel please take a look at this and let me know if it should
fixed in some other way.
Thanks!
-
| Oct 18, 9:55 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: fix make archclean
Remove build reference to arch/m68knommu/boot directory, it doesn't
exist.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/arch/m68knommu/Makefile linux-2.6.23-uc0/arch/m68knommu/Makefile
--- linux-2.6.23/arch/m68knommu/Makefile 2007-10-19 10:30:58.000000000 +1000
+++ linux-2.6.23-uc0/arch/m68knommu/Makefile 2007-10-19 10:35:41.000000000 +1000
@@ -117,4 +118,4 @@ core-y += arch/m68knommu/kernel/ \
libs-y += arch/m68knommu/lib/
archclean:
- $(Q)$(MAKE) ...
| Oct 18, 7:03 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: updated defconfig
Updated defconfig with new options for m68knommu.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/arch/m68knommu/defconfig linux-2.6.23-uc0/arch/m68knommu/defconfig
--- linux-2.6.23/arch/m68knommu/defconfig 2007-10-19 10:30:58.000000000 +1000
+++ linux-2.6.23-uc0/arch/m68knommu/defconfig 2007-10-19 10:35:41.000000000 +1000
@@ -1,41 +1,48 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.17
-# Tue Jun 27 12:57:06 2006
+# ...
| Oct 18, 6:46 pm 2007 |
| Greg Ungerer | [M68KNOMMU]: new style ColdFire UART driver
A new style serial driver for the Freescale ColdFire UART to replace
the old style one currently in the tree (drivers/serial/mcfserial.c).
Currently this UART is only found in the ColdFire CPU family of parts
(thus I prefixed this patch [M68KNOMMU]).
This has been around for a long while now, tested on all available
platforms.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff -Naurp linux-2.6.23/drivers/serial/mcf.c linux-2.6.23-uc0/drivers/serial/mcf.c
--- ...
| Oct 18, 6:42 pm 2007 |
| Nick Piggin | Re: SLUB: Avoid atomic operation for slab_unlock
I'm not sure, I had an idea it was relatively expensive on ia64,
but I didn't really test with a good workload (a microbenchmark
probably isn't that good because it won't generate too much out
Infrastructure in -mm, starting at bitops-introduce-lock-ops.patch.
bit_spin_lock-use-lock-bitops.patch and ia64-lock-bitops.patch are
ones to look at.
The rest of the patches I have queued here, apart from the SLUB patch,
I guess aren't so interesting to you (they don't do anything fancy
like ...
| Oct 18, 7:12 pm 2007 |
| Christoph Lameter | [IA64] Reduce __clear_bit_unlock overhead
ia64-lock-bitops.patch defines:
static __inline__ void
clear_bit_unlock (int nr, volatile void *addr)
{
__u32 mask, old, new;
volatile __u32 *m;
CMPXCHG_BUGCHECK_DECL
m = (volatile __u32 *) addr + (nr >> 5);
mask = ~(1 << (nr & 31));
do {
CMPXCHG_BUGCHECK(m);
old = *m;
new = old & mask;
} while (cmpxchg_rel(m, old, new) != old);
}
/**
* __clear_bit_unlock - Non-atomically clear a bit ...
| Oct 18, 8:26 pm 2007 |
| Christoph Lameter | Re: SLUB: Avoid atomic operation for slab_unlock
Yes that is what I attempted to do with the write barrier. To my knowledge
there are no reads that could bleed out and I wanted to avoid a full fence
Good. Andrew: Drop my patch when this goes in.
-
| Oct 18, 6:21 pm 2007 |
| Christoph Lameter | Re: SLUB: Avoid atomic operation for slab_unlock
Acked-by: Christoph Lameter <clameter@sgi.com>
Slub can use the non-atomic version to unlock because other flags will not
get modified with the lock held.
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
mm/slub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c
+++ linux-2.6/mm/slub.c
@@ -1185,7 +1185,7 @@ static __always_inline void slab_lock(st
...
| Oct 19, 4:20 am 2007 |
| Nick Piggin | Re: SLUB: Avoid atomic operation for slab_unlock
Oh, OK. Bit risky ;) You might be right, but anyway I think it
should be just as fast with the optimised bit_unlock on most
architectures.
Which reminds me, it would be interesting to test the ia64
implementation I did. For the non-atomic unlock, I'm actually
doing an atomic operation there so that it can use the release
barrier rather than the mf. Maybe it's faster the other way around
though? Will be useful to test with something that isn't a trivial
loop, so the slub case would be a good ...
| Oct 18, 6:56 pm 2007 |
| Christoph Lameter | Re: SLUB: Avoid atomic operation for slab_unlock
How expensive is the fence? An store with release semantics would be safer
Lets avoid mf (too expensive) and just use a store with release semantics.
Where can I find your patchset? I looked through lkml but did not see it.
-
| Oct 18, 7:01 pm 2007 |
| eric miao | Re: PDA Suspend SA1100
I don't think so. Unless a driver feels it necessary to take some
action, no suspend/resume
will not cause the whole system to fail. However,
1) if any driver suspend code returns error, the whole procedure will stop
2) and instable wake-up source (like glitch on wake-up GPIO pin) or
incorrect setting (like
wake up from RTC but set the interval to be 0) will also cause the
immediate resume
check "sa11x0_suspend" print out won't work since the console has already been
suspended, try ...
| Oct 18, 5:56 pm 2007 |
| Kristoffer Ericson | PDA Suspend SA1100
Greetings,
I've been trying to implement proper suspend on my jornada 720 machine. But as far as I can see it never reaches
the sa11x0_suspend code.
I've linked power button event to produce APM_SUSPEND and I can see that it says "Stopping TASKS ======". It then
blanks screen but keeps LCD powerd. I know it goes into resume again since removing backlight code in resume function
effectivly turns off the LCD.
Im assuming that it tries to suspend but fails at some point and tries to return into ...
| Oct 19, 1:37 am 2007 |
| Shannon Nelson | [PATCH] I/OAT: Add support for version 2 of ioatdma device
Add support for version 2 of the ioatdma device. This device handles
the descriptor chain and DCA services slightly differently:
- Instead of moving the dma descriptors between a busy and an idle chain,
this new version uses a single circular chain so that we don't have
rewrite the next_descriptor pointers as we add new requests, and the
device doesn't need to re-read the last descriptor.
- The new device has the DCA tags defined internally instead of needing
them defined ...
| Oct 19, 12:20 am 2007 |
| Arjan van de Ven | Re: [PATCH 1/5] Use wake_up_locked() in eventpoll
On Thu, 18 Oct 2007 18:25:58 -0400
Matthew Wilcox <matthew@wil.cx> wrote:
Have you tested this patch with LOCKDEP enabled? eventpoll is... tricky
in what it does with waitqueues and locks.... and some of this stuff is
there, afaik, to deal with that. You're now changing this ... call me
chicken :)
-
| Oct 18, 8:56 pm 2007 |
| Matthew Wilcox | Re: [PATCH 1/5] Use wake_up_locked() in eventpoll
I haven't tested it, but it's a simple textual substitution:
#define wake_up_locked(x) __wake_up_locked((x),
TASK_UNINTERRUPTIBLE | TASK_INTERRUPTIBLE)
so it should be identical in effect.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
| Oct 19, 9:28 am 2007 |
| Denys Vlasenko | Re: [PATCH] ia64 vDSO vs --build-id
I wonder why we bother having --build-id.
--
vda
-
| Oct 19, 3:28 am 2007 |
| Pavel Machek | Re: [RFC][PATCH -mm] Freezer: Do not allow freezing proc ...
ACK. We want this in 2.6.24.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
| Oct 19, 12:55 am 2007 |
| Rafael J. Wysocki | Re: [RFC][PATCH -mm] Freezer: Do not allow freezing proc ...
Sure, we do.
Greetings,
Rafael
-
| Oct 19, 2:34 pm 2007 |
| Erez Zadok | Re: broken PCNET32 in 2.6.24 requires experimental PCNET ...
Thanks. Now, with more patches that Linus committed, I get a different oops
when I try to configure the interface (ifup eth0). I'm using:
CONFIG_PCNET32=m
And I tried with and without CONFIG_PCNET32_NAPI.
Cheers,
Erez.
------------------------------------------------------------------------------
pcnet32: PCnet/PCI II 79C970A at 0x1080, 00 0c 29 f0 e5 15 assigned IRQ 9.
eth0: registered as PCnet/PCI II 79C970A
pcnet32: 1 cards_found.
EXT3 FS on hda1, internal journal
Adding ...
| Oct 18, 9:33 pm 2007 |
| David Miller | Re: broken PCNET32 in 2.6.24 requires experimental PCNET ...
From: Erez Zadok <ezk@cs.sunysb.edu>
This fix from Olof Johnson should fix it.
I'll merge this tonight.
diff --git a/net/core/filter.c b/net/core/filter.c
index 1f0068e..e0a0694 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -447,7 +447,8 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
rcu_assign_pointer(sk->sk_filter, fp);
rcu_read_unlock_bh();
- sk_filter_delayed_uncharge(sk, old_fp);
+ if (old_fp)
+ sk_filter_delayed_uncharge(sk, old_fp);
...
| Oct 18, 9:41 pm 2007 |
| Al Viro | Re: [RFC PATCH 0/5] Shadow directories
FVO"relatively recently" exceeding a decade and half. In any case,
it's _trivial_ to get fs corruption on any system with such links -
play with rename() races a bit and you'll get it. And yes, it does
include 4.4BSD and quite a chunk of even later history.
Anyway, you are quite welcome to propose a sane locking scheme capable
of dealing with that mess.
As for the posted patch, AFAICS it's FUBAR in handling of .. in such
directories. Moreover, how are you going to keep that shadow ...
| Oct 18, 10:37 pm 2007 |
| David Newall | Re: [RFC PATCH 0/5] Shadow directories
I did read the claim and it is ambiguous, in that it can reasonably be
read to mean that most UNIX systems never allowed such links, which is
wrong. All UNIX systems allowed it until relatively recently.
-
| Oct 18, 7:57 pm 2007 |
| Chris Friesen | Re: OOM notifications
I disagree. From an embedded viewpoint it would be nice to have a
"please free up memory", then a "we really need memory NOW", then
finally the kernel oom killer.
The advantage of the middle message is that it allows userspace to do
smarter things if it wants to (for instance, if there is an overall
system manager or some such thing, it could do a better job of
restarting tasks than the kernel oom killer since it knows the relative
importance of tasks).
Chris
-
| Oct 18, 10:15 pm 2007 |
| Pavel Machek | Re: OOM notifications
That works okay on a PC, but try cellphone one day.
You want management app to close the least used application. You do
not want _kernel_ to select "who to send SIGTERM to".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
| Oct 19, 3:17 am 2007 |
| Martin Schwidefsky | Re: 2.6.23-mm1 s390 driver problem
See http://marc.info/?l=linux-kernel&m=119270398931208&w=2
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
-
| Oct 19, 2:20 am 2007 |
| Cedric Le Goater | Re: 2.6.23-mm1 s390 driver problem
hmm, that doesn't fix the oops.
/me looking.
Thanks,
C.
-
| Oct 19, 4:06 am 2007 |
| Cedric Le Goater | Re: 2.6.23-mm1 s390 driver problem
thanks martin,
that helped going a little further in the boot process but we then have
a network issue when bringing the network interface up :
Bringing up interface eth0: ------------Ý cut here ¨------------
Kernel BUG at 0000000000000002 Ýverbose debug info unavailable¨
illegal operation: 0001 Ý#1¨
Modules linked in:
CPU: 0 Not tainted
Process ip (pid: 1167, task: 0000000001d46038, ksp: 00000000025efb28)
Krnl PSW : 0704200180000000 0000000000000002 (0x2)
R:0 ...
| Oct 19, 2:16 am 2007 |
| Martin Schwidefsky | Re: 2.6.23-mm1 s390 driver problem
This is the vmlinux.lds.S problem. The cleanup patch from Sam Ravnborg
moved the __initramfs_start and __initramfs_end symbols into
the .init.ramfs section. This is in itself not a problem, but it
surfaced a bug: there is no *(.init.initramfs), that needs to be
*(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has
the older one that still causes the "Cannot open root device". For
2.6.23-mm1 use the patch below.
--
blue skies,
Martin.
"Reality continues to ruin my ...
| Oct 19, 12:47 am 2007 |
| Martin Schwidefsky | Re: 2.6.23-mm1 s390 driver problem
This is definitly a problem with the header_ops in the qeth network
driver. I've asked our network team to take care of it. Stay tuned..
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
-
| Oct 19, 4:25 am 2007 |
| Andrew Morton | Re: 2.6.23-mm1 s390 driver problem
I have a feeling that we fixed this. But there's no BUG at 2.6.23-mm1's
include/linux/netdevice.h:819. How about setting
CONFIG_DEBUG_BUGVERBOSE=y?
-
| Oct 19, 2:27 am 2007 |
| Cedric Le Goater | Re: 2.6.23-mm1 s390 driver problem
it is set :(
C.
-
| Oct 19, 4:17 am 2007 |
| Denys Vlasenko | Re: [PATCH] ia64: check-segrel.lds vs --build-id
It's fixed in newer ld (not released yet IIRC), but why
are we shooting ourself in the foot by adding --build-id,
and then suffering from --build-id related problems?
--
vda
-
| Oct 19, 3:33 am 2007 |
| Paul Mundt | Re: [PATCH / HP6XX] : Add Timer values into HD64461.h
There's nothing that uses these, so why are you adding them? If you plan
on hooking these up in the hd64461 or TMU code, submit these definitions
along with the code that uses them.
-
| Oct 18, 8:49 pm 2007 |
| Kristoffer Ericson | [PATCH / HP6XX] : Add Timer values into HD64461.h
Greetings,
Shortlog:
This patch adds HD64461 Timer adresses & registers to the HD64461 header file (/include/asm-sh/hd64461.h).
The timers (TMU0 & TMU1) can hold 16bit values and auto loads the counter constant when it
reaches zero. Upon reaching zero it generates an interrupt.
Signed-off-by: Kristoffer Ericson <kristoffer.ericson@gmail.com>
diff --git a/include/asm-sh/hd64461.h b/include/asm-sh/hd64461.h
index 342ca55..52fcb7e 100644
--- a/include/asm-sh/hd64461.h
+++ ...
| Oct 18, 9:39 pm 2007 |
| Jan Dittmer | Re: libata crash
I could add that to the service at http://l4x.org/k/ if there is
sufficient (>1) interest.
Jan
-
| Oct 19, 12:05 am 2007 |
| Ingo Molnar | Re: libata crash
where can i pick the latest sg patchset up from? These build failures
are ruining my make randconfig build tests :)
Ingo
-
| Oct 18, 11:48 pm 2007 |
| Denys Vlasenko | Re: libata crash
Wow.
When you click on Ok/Fail, you get a build log. One part of it
(make oldconfig output) is not usable much, verbatim .config would be more useful.
But this is a minor nitpicking. Overall looks awesome.
--
vda
-
| Oct 19, 3:12 am 2007 |
| Kay Sievers | Re: BUG in: Driver core: convert block from raw kobjects ...
Sure, I have, and tried a lot of times, and all seemed correct here with
the final put. I don't say that it's the right fix, but without it, the
disk device object is never released here, it only gets removed from
sysfs.
Kay
-
| Oct 19, 7:15 am 2007 |
| Kay Sievers | Re: BUG in: Driver core: convert block from raw kobjects ...
Here is what I see, the error handler hangs without the final put and
the kobject never gets cleaned up. Note the missing:
kobject sdb: cleaning up
What is your CONFIG_SYSFS_DEPRECATED option? I have it unset, and that
may be the difference in the behavior if you have it set.
Thanks,
Kay
With device_put() - add sequence:
sd_probe: call add_disk
start of register_disk: 1
kobject block: registering. parent: 9:0:0:0, set: <NULL>
unset subsytem caused the event to drop!
...
| Oct 19, 4:06 pm 2007 |
| Alan Stern | Re: BUG in: Driver core: convert block from raw kobjects ...
Well, attached is a testing patch. It should apply to 2.6.23 together
with gregkh-all-2.6.23. Here's the output on my system using your
original code:
Plug in USB drive:
[ 75.555077] usb-storage: device found at 3
[ 75.558052] scsi 0:0:0:0: Direct-Access UDISK PDU01_1G 65G2.0 0.00 PQ: 0 ANSI: 2
[ 75.568248] usb-storage: device scan complete
[ 75.917139] sd 0:0:0:0: [sda] 1967616 512-byte hardware sectors (1007 MB)
[ 75.918463] sd 0:0:0:0: [sda] Write Protect is off
[ ...
| Oct 19, 10:11 am 2007 |
| Kay Sievers | Re: BUG in: Driver core: convert block from raw kobjects ...
Hmm, do you have kobject debugging enabled? Do you ever see something
like: "kobject sdb: cleaning up" when you remove the put_device()?
Kay
-
| Oct 18, 6:27 pm 2007 |
| Alan Stern | Re: BUG in: Driver core: convert block from raw kobjects ...
I didn't enable kobject debugging, but I did put a printk statement in
drivers/scsi/sd.c:scsi_disk_release(), which is the release routine for
the scsi_disk structure. It does the final put_disk() call -- or at
least, this is _supposed_ to be the final call.
With my patch, just before the call to put_disk the value of
disk->dev.kobj.kref.refcount is 1. Without my patch, the value is
garbage (probably a slab poison value, but I printed it in decimal
rather than hex so I can't be ...
| Oct 19, 7:09 am 2007 |
| Artem Bityutskiy | Re: is the inode an orphan?
Well, in the mail I called files like open/unlink the last link/do some I/O
orphans. Let me shortly describe the problem I'm trying to solve.
In our FS when we're in ->unlink() and i_nlink becomes 0, we have to record
this inode in the table of orphans, and remove it from there in
->delete_inode(). This is needed to be able to dispose of orphans in case of an
unclean reboot on the next mount. AFAIK, ext3 has something similar. I just
figured that this could be optimized - in most cases ...
| Oct 19, 12:07 am 2007 |
| Lennart Sorensen | Re: New CD/DVD drive - 80-wire cable detection failure
Well older DVD drives often only did udma33 so they would even care if
you had an 80 wire cable or not. Newer once often require more than
udma33 for full operation. I got a new drive about a year ago, and
burning dvd+rw at 4x worked great, but all dvd-r at 8x failed.
Eventually I realized I had to change the 40wire cable to an 80 wire,
and all problems disappeared. The drive works fine in udma4 mode
(whatever speed that is). My previous DVD-ROM drive had no problems
--
Len Sorensen
-
| Oct 19, 3:12 pm 2007 |
| Nick Warne | Re: New CD/DVD drive - 80-wire cable detection failure
Yes, Len's advice has me wondering now. Do I have a dodgy cable? I will have
to change that tomorrow.
But more info. The old drive played DVD movies etc. OK, but slowly it became
worse until I couldn't read any one of them 9 times out of 10. CD play
back/burning was OK 100% all the time though - so I guessed the dvd laser
(whatever it does) was dead - hence why I bought a new one.
The new drive works perfectly, but for the udma33 issue. If it was the cable,
why would it read/burn ...
| Oct 19, 3:04 pm 2007 |
| Nick Warne | Re: New CD/DVD drive - 80-wire cable detection failure
No help anyone? Did I buy a taboo drive?
nick@linuxamd:nick$ /usr/sbin/hdparm -i /dev/hdd
/dev/hdd:
Model=TSSTcorp CDDVDW SH-S202J, FwRev=SB00, SerialNo=
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=yes, tPIO={min:383,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 ...
| Oct 19, 12:49 pm 2007 |
| Bartlomiej Zolnierki ... | Re: New CD/DVD drive - 80-wire cable detection failure
It should have been hdparm --Istdout (sorry, once again).
[ It is definitevely not my day, or rather trying to debug the problem
while preparing the next IDE pull request is not a such good idea... ]
From identify data we should be able to deduce whether this is a kernel
problem or rather a hardware/configuration one.
Thanks,
Bart
-
| Oct 19, 3:28 pm 2007 |
| Nick Warne | Re: New CD/DVD drive - 80-wire cable detection failure
Hi Bart,
Thanks for assistance.
No change:
ide_setup: hdd=ide-cd
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive
hdd: drive side 80-wire cable detection failed, limiting max speed to UDMA33
hdd: selected mode 0x42
hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Nick
--
Free Software Foundation Associate Member 5508
-
| Oct 19, 2:03 pm 2007 |
| Bartlomiej Zolnierki ... | Re: New CD/DVD drive - 80-wire cable detection failure
Hi,
Please try:
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/broken-ou...
or the latest kernel snapshot from kernel.org.
Thanks,
Bart
-
| Oct 19, 1:28 pm 2007 |
| Bartlomiej Zolnierki ... | Re: New CD/DVD drive - 80-wire cable detection failure
Ah, so the patch won't help (sorry, I didn't pay enough attention).
Len's advices are worth the try, also please send the output
of hdparm -I /dev/hdd.
Thanks,
Bart
-
| Oct 19, 2:44 pm 2007 |
| Lennart Sorensen | Re: New CD/DVD drive - 80-wire cable detection failure
Did you try another cable? DId you try using both the old IDE drivers
and the new PATA libata drivers? What is the hdd=ide-cd supposed to
do? Do you have a device present as hdc and if not, then why not?
(Hint: ATA spec requires a master before you can have a slave, even
though it frequently does work with just a slave. Of course cable
select seems even nicer since then the device at the end of an 80 wire
cable is automatically master, and any additional device added to the
middle connector ...
| Oct 19, 2:07 pm 2007 |
| Nick Warne | Re: New CD/DVD drive - 80-wire cable detection failure
I have (since 2.6.15 at least) hda, hdb, hdc, and hdd.
hda and hdb are mounted at boot. hdc is not mounted, as I leave that drive
for backups and mount as needed.
All I done was replace a duff cd/dvd drive (hdd) with a new one.
Nick
--
Free Software Foundation Associate Member 5508
-
| Oct 19, 2:12 pm 2007 |
| Florian Fainelli | Re: [PATCH 1/4 resend] [x86] Add generic GPIO support to x86
Hi Andres,
This one was discussed mostly on the ARM mailing-list and finally made his way
to the mainline kernel. Though it lacks some functions to change for instance
a entire GPIO line and not a single bit, it is used on ARM and MIPS systems
so I would conform with this one for now because it is used by at least two
or more architectures.
-
| Oct 19, 5:01 am 2007 |
| Jeremy Fitzhardinge | Re: [patch 1/3] Add BSS to resource tree
Yes, I generally prefer char[] - but only because gcc irritatingly
rejects void []...
J
-
| Oct 18, 5:27 pm 2007 |
| Bernhard Walle | Re: [patch 1/3] Add BSS to resource tree
It's already ... the problem just was that IA64 uses _bss instead of
__bss_start. So I think we should change this. I verified that the
kernel still compiles with the patch below.
Thanks,
Bernhard
---
[PATCH] Rename _bss to __bss_start
Rename _bss to __bss_start as on other architectures. That makes it possible to
use the <linux/sections.h> instead of own declarations. Also add __bss_stop
because that symbol exists on other architectures.
That patch applies to current git plus ...
| Oct 19, 7:48 am 2007 |
| Bernhard Walle | Re: [patch 1/3] Add BSS to resource tree
It's different on every architectures. Some don't have it at all (like
PPC64), and most of them have code_resource and data_resource static.
Instead of making the data on all architectures (that have it) global,
I'd like to make it static on x86.
See my attached patch.
Thanks,
Bernhard
---
[PATCH] Remove extern declarations for code/data/bss resource
This patch removes the extern struct resource declarations for
data_resource, code_resource and bss_resource on x86 and ...
| Oct 19, 5:52 am 2007 |
| James Smart | Re: [2.6 patch] scsi/lpfc/lpfc_debugfs.c: fix typo
ACK
-- james s
-
| Oct 19, 5:23 am 2007 |
| Daniel Barkalow | Re: [patch] PCI: disable MSI on more ATI NorthBridges
And the same SATA controller could show up behind a different northbridge.
It would be unfortunate to hit the same device bug independantly on each
system and work around it by doing something that won't help the next
Have we gotten around to having a device quirk for this? I bet it won't be
too long before we see a system where the SATA controller doesn't work
with INTX disabled and the ethernet controller doesn't work with it
enabled, since we've seen devices with each of these ...
| Oct 19, 10:42 am 2007 |
| Thomas Gleixner | Re: [RFC] [PATCH -mm] ASIC3 driver
We obviously never removed the big fat warning, which was valid before
the ARM to generic irq conversion.
tglx
-
| Oct 19, 11:17 am 2007 |
| Samuel Ortiz | Re: [RFC] [PATCH -mm] ASIC3 driver
Well, now I am :-)
I fixed all the errors, there are only a couple lines being more than 80
It doesn't build as a module, since we need the irq.h symbols.
I changed MFD_ASIC3 to bool. I somehow feel that this is not the cleanest
solution, but OTOH I think that dynamically adding IRQs and GPIOs to an
As I explained to Thomas, asic3 defines an additional range of IRQs for the
board, so we really need to access the irq API.
No, I think you're right, the lock should be taken with local ...
| Oct 19, 3:53 am 2007 |
| Andrew Morton | Re: [RFC] [PATCH -mm] ASIC3 driver
We seem to have miscommunicated here. <linux/irq.h> contains references to
things which only some architectures actually implement. I don't know
which architectures those are, but it includes common ones like x86, so
it's a real trap. I recall it does not include arm, so your code might
break on arm.
At least, that's what's _supposed_ to happen: I just compiled and linked
this driver into an ARM kernel with no problems so now I'm all confused as
to what the problem was.
Oh well, we'll ...
| Oct 19, 11:00 am 2007 |
| pHilipp Zabel | Re: [RFC] [PATCH -mm] ASIC3 driver
I'd love to see this converted to use the GPIO API before all the
drivers are going in.
Any chance we can use this as an opportunity to look at David
Brownell's gpiolib again? (http://lkml.org/lkml/2007/4/15/127).
I want to do the same for a similar chip (a GPIO/IRQ extender
implemented in a Xilinx CPLD used on several HTC phones), but I
couldn't figure out how to do GPIO<->IRQ conversion properly with
gpiolib and how to handle the CPU's internal GPIOs, which are more
than ARCH_GPIOS_PER_CHIP ...
| Oct 19, 5:02 am 2007 |
| Randy Dunlap | Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pul ...
Yes, that's bad. Sam has asked me to fix some dontdiff problems.
I'll try to get to it soon. Other people can also update it....
---
~Randy
-
| Oct 19, 8:34 am 2007 |
| Samuel Thibault | Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pul ...
Just to make sure, could you check in System.map that accent_table is
correctly 256*3*4=3072 bytes long?
Samuel
-
| Oct 19, 1:55 am 2007 |
| Mike Galbraith | Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pul ...
Weeeell now, that skepticism is indeed well founded. It's dontdiff. A
diff of trees where defkeymap.c_shipped has been modified produces no
output. Once a working tree has been afflicted by using diff+dontdiff
to update it, even overwriting the entire tree via git-archive doesn't
lead to a good build unless you also touch defkeymap.c_shipped
afterward. In my case, the working tree remained buildable yet
thoroughly busted through a lengthy bisect and beyond. That bisect
positively ...
| Oct 19, 3:18 am 2007 |
| Mike Galbraith | Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pul ...
That didn't break my box. However, removing your test patch and
re-applying the revert I generated between git tree and working tree
brought it right back. With the below applied, diff says there is no
difference between working tree and git tree (except for
vsyscall_32.lds, which is a generated file kbuild leaves lying around).
Per gitk, the git repository is at
d85714d81cc0408daddb68c10f7fd69eafe7c213
diff -uprNX /root/dontdiff git/linux-2.6/drivers/acorn/char/defkeymap-l7200.c ...
| Oct 18, 7:48 pm 2007 |
| Mike Galbraith | Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pul ...
See mail I just sent. A day a half wasted here. Sorry for however much
time you wasted on this.
-Mike
-
| Oct 19, 3:20 am 2007 |
| Mark Lord | Re: [Pcihpd-discuss] [PATCH 1/3] pciehp: hotplug: deal w ...
Not true. Once pciehp is loaded, it automatically detects and handles
inserted and removed cards just fine. Until after the next suspend/resume.
Cheers
-
| Oct 18, 8:09 pm 2007 |
| Kenji Kaneshige | Re: [Pcihpd-discuss] [PATCH 1/3] pciehp: hotplug: deal w ...
According to pciehp_debug output from you, your slot doesn't
have software programmable power controller. So your hardware
automatically power on the slot. I think this is why the value
of "power" file is already "1". (But I'm not sure if it is
correct, especially because your firmware doesn't have _OSC.)
On the other hand, my slot has software programmable power
Ok. I think your patch is trying to solve the following two
problems. Right?
- When the card is inserted *after* modprobing ...
| Oct 18, 7:38 pm 2007 |
| Kenji Kaneshige | Re: [Pcihpd-discuss] [PATCH 1/3] pciehp: hotplug: deal w ...
This is because your slot is surprise remove capable. On my slot,
which is not surprise remove capable, the card is not enabled
even after pciehp is loaded.
Thanks,
Kenji Kaneshige
-
| Oct 18, 8:27 pm 2007 |
| Linus Torvalds | Re: LSM conversion to static interface
I'd like to note that I asked people who were actually affected, and had
examples of their real-world use to step forward and explain their use,
and that I explicitly mentioned that this is something we can easily
re-visit.
But I also note that you did no such thing, neither has anybody else.
The fact is, security people *are* insane. You just argue all the time,
instead fo doing anything productive. So please don't include me in the Cc
on your insane arguments - instead do ...
| Oct 19, 1:40 pm 2007 |
| James Morris | Re: LSM conversion to static interface
Can you provide an example of a real LSM which can be safely unloaded and
also needs to be unloaded?
Why should we maintain infrastructure and extra complexity in the kernel
for theoretical or unknown modules ?
Linus has asked for any valid out of tree users who need a dynamic
interface to step forward. Where are they?
As one of the people who actually maintains LSM (rather than simply
speculates about it), I object to maintaining infrastructure which, to the
best of my knowledge, ...
| Oct 19, 2:07 pm 2007 |
| Andreas Gruenbacher | Re: LSM conversion to static interface
The patch doesn't hurt AppArmor, but it's still a step in the wrong direction.
This is idiotic. Just because there is no safe way to unload SELinux
- doesn't mean there is no safe way to unload other LSMs: if nothing
but that, unloading is handy during development.
- doesn't mean that module *loading* is unsafe. The patch removes module
loading as well, which hurts more than removing module unloading.
LSM can be abused ... so what, this doesn't mean the interface is bad. ...
| Oct 19, 1:26 pm 2007 |
| Benjamin Herrenschmidt | Re: [PATCH] synchronize_irq needs a barrier
Well, we are generally safer here. That is, unless action is a store,
it will not pass spin_lock, at least not on powerpc afaik.
In fact, if action, as it is in our case, is something like
if (foo)
return;
We cant execute the store inside spin_lock() without having loaded
foo, there is an implicit dependency here.
But anyway, Linus patch fixes that too if it was a problem. Now if
we grep for while (test_bit and while (!test_bit I'm sure we'll find
other similar surprises.
That's ...
| Oct 18, 9:35 pm 2007 |
| Herbert Xu | Re: [PATCH] synchronize_irq needs a barrier
Good point.
Although in this case we're still safe because in the worst
cases:
CPU0 CPU1
irq_sync = 1
synchronize_irq
spin lock
load IRQ_INPROGRESS
irq_sync sync is visible
spin unlock
spin lock
load irq_sync
while (IRQ_INPROGRESS)
wait
return
set IRQ_INPROGRESS
spin unlock
tg3_msi
ack IRQ
if (irq_sync)
return
spin lock
clear IRQ_INPROGRESS
spin ...
| Oct 18, 8:28 pm 2007 |
| Benjamin Herrenschmidt | Re: [PATCH] synchronize_irq needs a barrier
Good for me.
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cheers,
Ben.
-
| Oct 18, 9:58 pm 2007 |
| Benjamin Herrenschmidt | Re: [PATCH] synchronize_irq needs a barrier
Note that napi_synchronize needs a slightly different treatement.
Here, the situation boils down to:
one CPU does:
foo = 1;
while(test_bit(bar))
barrier();
and the other:
if (!test_and_set_bit(bar)) {
read & use foo
smp_mb__before_clear_bit();
clear_bit(bar);
}
The good thing here is that read & use foo is part of the critical
section (I hate hand-made locks ...) defined by bar which makes
things somewhat easier than the synchronize_irq() case.
I think a simple ...
| Oct 18, 9:26 pm 2007 |
| Peter Zijlstra | Re: [NET]: Fix possible dev_deactivate race condition
Ouch!, is there really no sane locking alternative? Hashed waitqueues
-
| Oct 19, 12:35 am 2007 |
| Linus Torvalds | Re: [PATCH] synchronize_irq needs a barrier
I'm starting to doubt this.
One of the issues is that we still need the smp_mb() in front of the loop
(because we want to serialize the loop with any writes in the caller).
The other issue is that I don't think it's enough that we saw the
descriptor lock unlocked, and then the IRQ_INPROGRESS bit clear. It might
have been unlocked *while* the IRQ was in progress, but the interrupt
handler is now in its last throes, and re-takes the spinlock and clears
the IRQ_INPROGRESS thing. But ...
| Oct 18, 8:26 pm 2007 |
| Herbert Xu | Re: [PATCH] synchronize_irq needs a barrier
OK, here is the patch again with a changelog:
[IRQ]: Fix synchronize_irq races with IRQ handler
As it is some callers of synchronize_irq rely on memory barriers
to provide synchronisation against the IRQ handlers. For example,
the tg3 driver does
tp->irq_sync = 1;
smp_mb();
synchronize_irq();
and then in the IRQ handler:
if (!tp->irq_sync)
netif_rx_schedule(dev, &tp->napi);
Unfortunately memory barriers only work well when they come in
pairs. Because we don't actually ...
| Oct 18, 9:48 pm 2007 |
| Nick Piggin | Re: [PATCH] synchronize_irq needs a barrier
Not unless you mean a pair of spin lock/unlock as in
2 spin lock/unlock pairs (4 operations).
*X = 10;
spin_lock(&lock);
/* *Y speculatively loaded here */
/* store to *X leaves CPU store queue here */
spin_unlock(&lock);
I don't use the sparc barriers, so they don't come naturally to
me ;)
I think both loads and stores can pass into the critical section
by having the spin_lock pass earlier ops, or by having spin_unlock
-
| Oct 18, 7:52 pm 2007 |
| David Miller | Re: [NET]: Fix possible dev_deactivate race condition
From: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert!
-
| Oct 18, 10:38 pm 2007 |
| Herbert Xu | Re: [PATCH] synchronize_irq needs a barrier
Thinking about this again and checking code I have come to the
conclusion that
1) There is a race (in some drivers) even with the full mb.
2) Linus's patch fixes it.
3) It's difficult to fix it elegantly in the driver.
In other words I think this patch is great :)
First of all let's agree on some basic assumptions:
* A pair of spin lock/unlock subsumes the effect of a full mb.
* A spin lock in general only equates to (SS/SL/LL).
* A spin unlock in general only equates to ...
| Oct 18, 7:32 pm 2007 |
| Nick Piggin | Re: [PATCH] synchronize_irq needs a barrier
Yeah, if you've got the lock on both sides there, then I
agree it will be correct.
-
| Oct 18, 9:49 pm 2007 |
| Benjamin Herrenschmidt | Re: [PATCH] synchronize_irq needs a barrier
Paulus and I convinced ourselves that this would work. If we call our
variable that gets set before synchronize_irq and read in the IRQ
handler "foo", we get to:
- writing foo can travel down at most to just before the unlock in the
code above
- reading foo can travel up out of the IRQ handler at most just after
the lock in the code that sets IRQ_INPROGRESS.
The whole lock/set IRQ_INPROGRESS/unlock path can then only happen
before the locked section above, in which case we see and wait ...
| Oct 18, 9:11 pm 2007 |
| Herbert Xu | Re: [NET]: Fix possible dev_deactivate race condition
Well if we ever moved the transmission to full process context
then we'll gladly accept your patch :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
| Oct 19, 2:29 am 2007 |
| Herbert Xu | Re: [PATCH] synchronize_irq needs a barrier
Right. I think if we accept the definition of a spin lock/unlock
that Nick outlined earlier, then we can see that on the IRQ path
there simply isn't a memory barrier between the changing of the
status field and the execution of the action:
spin_lock
set IRQ_INPROGRESS
spin_unlock
action
spin_lock
clear IRQ_INPROGRESS
spin_unlock
What may happen is that action can either float upwards to give
spin_lock
action
set IRQ_INPROGRESS
spin_unlock
spin_lock
clear ...
| Oct 18, 9:20 pm 2007 |
| Herbert Xu | [NET]: Fix possible dev_deactivate race condition
OK here is the fix for that case.
[NET]: Fix possible dev_deactivate race condition
The function dev_deactivate is supposed to only return when
all outstanding transmissions have completed. Unfortunately
it is possible for store operations in the driver's transmit
function to only become visible after dev_deactivate returns.
This patch fixes this by taking the queue lock after we see
the end of the queue run. This ensures that all effects of
any previous transmit calls are ...
| Oct 18, 10:36 pm 2007 |
| Linus Torvalds | Re: [PATCH] synchronize_irq needs a barrier
Hey, I appreciate it, but I do think that the "spinlock only to
immediately unlock it again" is pretty horrid.
I'm convinced that there should be some way to do this without actually
taking the lock. I *think* it should work with something like
for (;;) {
smp_rmb();
if (!spin_is_locked(&desc->lock)) {
smp_rmb();
if (!(desc->status & IRQ_INPROGRESS)
break;
}
cpu_relax();
}
instead. Which basically requires that we see the descriptor lock being
not held, ...
| Oct 18, 7:55 pm 2007 |
| Herbert Xu | Re: [PATCH] synchronize_irq needs a barrier
Yes I think you're right. In this case we do have barriers
everywhere else so this should work.
Although if you want napi_synchronize to have the property that
when it returns all NAPI processing effects are visible then
you'd need another smp_mb() after the loop.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
| Oct 18, 10:53 pm 2007 |
| Benjamin Herrenschmidt | Re: [PATCH] synchronize_irq needs a barrier
The network stack always made be nervous with it's bitops use as locks.
Any loop of test_bit() alone as a synchronisation method, without locks
or barriers is, imho, inherently buggy.
Ben.
-
| Oct 18, 9:29 pm 2007 |
| Jean Delvare | Re: [lm-sensors] hwmon/f75375s.c: buggy if()
Hi Mark, hi Riku,
BTW, that's the wrong way to do it. If the F75373S doesn't support
changing the PWM mode, then the sysfs attribute in question should be
read-only for this chip type. Making it writable and returning an error
on write is confusing.
Riku, can you please submit a patch fixing this? The attribute should
be declared read-only, and then you can use sysfs_chmod_file() to
change it to read-write where supported. Take a look at the w83781d
driver for an example.
Thanks,
-- ...
| Oct 19, 5:37 am 2007 |
| Jean Delvare | Re: [PATCH] ibmpex: Change printk to dev_{info,err} macros
Hi Darrick,
This message might be misleading, as there are other reasons why
Other than that, the patch looks OK:
Acked-by: Jean Delvare <khali@linux-fr.org>
--
Jean Delvare
-
| Oct 19, 1:54 am 2007 |
| Darrick J. Wong | [PATCH v2] ibmpex: Change printk to dev_{info,err} macros
Ok, I'll change the message to be a bit more accurate.
---
Clean up printk use in ibmpex.
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
---
drivers/hwmon/ibmpex.c | 48 +++++++++++++++++++++++-------------------------
1 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/hwmon/ibmpex.c b/drivers/hwmon/ibmpex.c
index c462824..9c9cdb0 100644
--- a/drivers/hwmon/ibmpex.c
+++ b/drivers/hwmon/ibmpex.c
@@ -140,10 +140,10 @@ static int ibmpex_send_message(struct ...
| Oct 19, 4:35 pm 2007 |
| FUJITA Tomonori | Re: [bug] ata subsystem related crash with latest -git
On Thu, 18 Oct 2007 19:14:29 +0200
I can take care of IOMMU stuff when I'll send IOMMU merging fix
patchset:
http://marc.info/?l=linux-scsi&m=119079718126157&w=2
-
| Oct 19, 1:59 am 2007 |
| Mark Lord | Re: PROBLEM: 2.6.23.1 Freezes on GB data transfers
I believe this is now the forth report of blinking-leds lockup with 2.6.23.1.
I wonder what's causing it?
My system has this as well, totally random, once every day or so.
New behaviour since 2.6.23-rc9 (I posted previously about this).
Cheers
-
| Oct 19, 9:30 am 2007 |
| Ray Lee | Re: PROBLEM: 2.6.23.1 Freezes on GB data transfers
The blinking Caps lock LED means that your system is Oopsing. Please
try your test again from a console (not from X), and see if an oops
message is printed out. If it is, you'll need to either copy it down
or take a photograph of it with a digital camera, then post the text
of it or post a link to the image.
Ray
-
| Oct 19, 8:58 am 2007 |
| Mark Lord | Re: PROBLEM: 2.6.23.1 Freezes on GB data transfers
Yeah, I looked at the changes and it's all very innocent looking.
More likely in my case, I suppose, is that the bug was there earlier
and then some timing changed somewhere and now it triggers more often.
One supporting evidence of that, is that with the powertop patches applied,
it crashes much less often. And all that those do is adjust timings in
It seems to happen most often here on resume from suspend (RAM),
and when hotplugging hardware. But it's infrequent enough that this
may ...
| Oct 19, 10:35 am 2007 |
| Ray Lee | Re: PROBLEM: 2.6.23.1 Freezes on GB data transfers
Boy, there's just not a lot between 2.6.23-rc9 and 2.6.23 proper.
There are two things that kinda pop out, but this is at best a WAG.
First, are you on x86-32 and happen to have CONFIG_HIGHPTE set?
Second is another memory thing, where in filemap_fault we now do a
page_cache_release where we didn't before, but that appears to only be
in a case where we send a sigbus, so I wouldn't expect that to be
hitting.
Everything else looks to be for uncommon hardware or relatively safe
(such as a ...
| Oct 19, 10:18 am 2007 |
| Ahmed S. Darwish | Re: [PATCH] Version 8 (2.6.23) Smack: Simplified Mandato ...
My fault. I sent to Casey a one-liner patch to make "smack_cipso_count++"
be protected by the smk_cipsolock spinlock.
We don't need a lock in the reading side since we don't do a write operation
depending on that read, right ?.
--
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com
-
| Oct 19, 5:39 am 2007 |
| Mauro Carvalho Chehab | Re: suspicious ALSA empty commit
with stgit, you should add stg clean on your workflow. This will remove the
empty commits.
--
Cheers,
Mauro
-
| Oct 19, 12:19 pm 2007 |
| Takashi Iwai | Re: [alsa-devel] hda-intel: no soundcard with current li ...
At Thu, 18 Oct 2007 18:19:25 +0200,
Try model=fujitsu or model=laptop. This will activate the
auto-muting.
If it works, let me know the PCI SSID (from the output of lspci -vv).
thanks,
Takashi
-
| Oct 18, 10:05 pm 2007 |
| Takashi Iwai | Re: [alsa-devel] hda-intel: no soundcard with current li ...
At Fri, 19 Oct 2007 12:46:34 +0200,
Thanks. With the patch below, the driver should work without option.
Give it a try.
Takashi
diff -r 7cf5e23f804e sound/pci/hda/patch_conexant.c
--- a/sound/pci/hda/patch_conexant.c Fri Oct 19 08:23:00 2007 +0200
+++ b/sound/pci/hda/patch_conexant.c Fri Oct 19 12:56:13 2007 +0200
@@ -765,6 +765,7 @@ static struct snd_pci_quirk cxt5045_cfg_
SND_PCI_QUIRK(0x103c, 0x30d9, "HP Spartan", CXT5045_LAPTOP),
SND_PCI_QUIRK(0x1734, 0x10ad, "Fujitsu Si1520", ...
| Oct 19, 3:02 am 2007 |
| Jan-Simon | Re: [alsa-devel] hda-intel: no soundcard with current linus'
I did already, here's the copy:
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 03)
Subsystem: Fujitsu Siemens Computer GmbH Unknown device 110e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 22
...
| Oct 19, 3:46 am 2007 |
| Krzysztof Halasa | Re: VIA VT6307 OHCI version?
BTW: I've looked at it a bit closer and it seems the EEPROM lines
are controlled by VT6307 I/O ports (region #1) 0x0 and 0x20:
01:04.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev 80) (prog-if 10 [OHCI])
Memory at feafe800 (32-bit, non-prefetchable) [size=2K]
I/O ports at d480 [size=128]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
port 0x20 R/O bit 8 is set in 93c46 mode and reset in I^2C mode
port 0x20 bit 4 must be set to drive CS, CLK and ...
| Oct 19, 3:42 pm 2007 |
| Dave Johnson | [PATCH] i386: fix TSC clock source calibration error [part 2]
From: Dave Johnson <djohnson@sw.starentnetworks.com>
The previous patch wasn't correctly handling the 'count' variable. If
a CPU gave bad results on the 1st or 2nd run but good results on the
3rd, it wouldn't do the correct thing. No idea if any such CPU
exists, but the patch below handles that case by discarding the bad
runs.
If a bad result (too quick, or too slow) occurs on any of the 3 runs
it will be discarded.
Also updated some comments to explain what's going ...
| Oct 19, 10:16 am 2007 |
| Dave Johnson | Re: [PATCH] i386: fix TSC clock source calibration error
Xeon LV (Sossaman) based custom board. BIOS is GenSW.
--
Dave Johnson
Starent Networks
-
| Oct 19, 10:31 am 2007 |
| Hiroshi Shimamoto | Re: [PATCH] i386: fix TSC clock source calibration error ...
It's a really rare case, but if SMI interrupt takes CPU here, just after
prepare and before rdtscll, it makes delta64 shorter than expected one.
Thanks
Hiroshi Shimamoto
-
| Oct 19, 11:01 am 2007 |
| Dave Johnson | Re: [PATCH] i386: fix TSC clock source calibration error ...
Yep, rare indeed (about 1 instruction). Moving the start read before
the prepare call should solve that one too providing the setup doesn't
take any real measurable time.
--
Dave Johnson
Starent Networks
-
| Oct 19, 11:34 am 2007 |
| Dmitry Torokhov | Re: Power button policy and mechanism
Hi Richard,
I think power.c as it was is not a good idea. Generic code does not know
the best way of shutting down/suspending a certain box. However having an
arch- (or even board-) specific version of power.c that pligs directl
and poperly into appropriate PM mechanism makes more sense. If certain
platforms need it I don't see a reason to prevent them from doing so.
--
Dmitry
-
| Oct 19, 8:04 am 2007 |
| Richard Purdie | Re: Power button policy and mechanism
There was a long discussion thread about this a while back. There were a
lot of differing views but in the end no patch to fix up power.c to do
anything was accepted. The Zaurus was the reason I raised the issue.
The proposed changes to power.c were to hook it into things like APM as
a "user" event so the power button triggered a suspend event but
Currently I still patch this functionality into the Zaurus kernels
(basically by resurrecting power.c with the patches I used to apply to
it ...
| Oct 19, 2:54 am 2007 |
| Christopher Li | [PATCH] Re: sparse breakage triggered by rcu_read_lock() ...
[Empty message]
| Oct 19, 2:08 pm 2007 |
| Chris Li | Re: sparse breakage triggered by rcu_read_lock() lockdep ...
Err,
Sparse does not support the local label syntax yet. It just treats the
second label "x:" as the same as the first one. Then the linearize
code gets serious confused when it saw one label get define in two
places.
The fix seems not trivial from the first look.
Chris
-
| Oct 19, 12:44 pm 2007 |
| Gautham R Shenoy | Re: [RFC PATCH 2/4] Rename lock_cpu_hotplug to get_online_cpus
Okay. But other than pseries_add_processor and pseries_remove_processor,
are there any other places where we _change_ the cpu_present_map ?
I agree that we need some kind of synchronization for threads which read
One of the primary reasons to move away from the mutex semantics for
cpu-hotplug protection, was that there were a lot of places where
lock_cpu_hotplug() was used for protecting local data structures too,
when they had nothing to do with cpu-hotplug as such, and it resulted
in a ...
| Oct 18, 10:04 pm 2007 |
| Phillip Susi | Re: Problem: CPU sleep when calling a function in anoth ...
That is exactly what is happening. Pages in the code segment are only
loaded on demand.
-
| Oct 19, 12:58 pm 2007 |
| Russell King | Re: [PATCH 0/21] KGDB: Request to merge KGDB
Given that not all architecture maintainers read lkml, and they are
patches affecting all *architectures*, wouldn't it have been a good
idea if they'd copied linux-arch?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
| Oct 19, 12:47 am 2007 |
| Jean Delvare | Re: [PATCH] Blackfin I2C/TWI driver: update for 2.6.24 m ...
I probably had not been clear about it so far. I've added it to my
"Linux 2.6 I2C development FAQ" now.
--
Jean Delvare
-
| Oct 19, 3:19 am 2007 |
| Bryan Wu | Re: [PATCH] Blackfin I2C/TWI driver: update for 2.6.24 m ...
I see. Actually this is the first time I was told about it.
I know it missed the merge window.
Thanks again
-Bryan Wu
-
| Oct 19, 2:23 am 2007 |
| Manu Abraham | Re: [PATCH] Blackfin I2C/TWI driver: update for 2.6.24 m ...
Why ? The statement would have made sense if the i2c list was not CC 'd,
but stating that if LK is CC 'd additionally sounds ...
-
| Oct 19, 5:49 am 2007 |
| Andrew Morton | Re: [PATCH] Blackfin I2C/TWI driver: update for 2.6.24 m ...
Disagree. I don't think there's any benefit to anyone for developers to
hide their stuff on remote mailing lists. Copying lkml increases the
changes that someone will spot a bug or some improvement and it generally
keeps people informed as to what's going on.
yeah, 120,000 messages/year. But a lot of them are just noise. Patches
are important.
And I really don't understand this huffy attitude and putting more
roadblocks in the way of our contributors. People like Bryan are doing ...
| Oct 19, 2:23 am 2007 |
| Jean Delvare | Re: [PATCH] Blackfin I2C/TWI driver: update for 2.6.24 m ...
Hi Bryan,
I'm pretty busy these days, I don't have much spare time for reviews.
BTW, as a rule of thumb, I am ignoring patches that are sent to the
LKML in addition to the i2c list. If you think that your patch is so
important that it has to be send to a list with over 4500 subscribers
that sees 120.000 messages each year, then who am I to dare to comment
on it?
If you want me to consider your patches as something that needs my
attention, send them to the i2c list only, do not add LKML. ...
| Oct 19, 2:07 am 2007 |
| Jean Delvare | Re: [PATCH] Blackfin I2C/TWI driver: update for 2.6.24 m ...
Hi Andrew,
Sending spam to millions of people increases the chances than someone
Lot of noise, yes. Counting 1 second on average to process posts you're
not interested in, that's 33 hours a year. This is completely insane
and that's why I unsubscribed from LKML long ago. And the situation is
only getting worse every year. You may fail to realize the problem just
Quite on the contrary, I am trying to educate people into targeting
their posts to the right lists so that they get more ...
| Oct 19, 4:52 am 2007 |
| Eric W. Biederman | [PATCH] rd: Use a private inode for backing storage
Currently the ramdisk tries to keep the block device page cache pages
from being marked clean and dropped from memory. That fails for
filesystems that use the buffer cache because the buffer cache is not
an ordinary buffer cache user and depends on the generic block device
address space operations being used.
To fix all of those associated problems this patch allocates a private
inode to store the ramdisk pages in.
The result is slightly more memory used for metadata, an extra ...
| Oct 19, 3:51 pm 2007 |
| Eric W. Biederman | Re: [PATCH] rd: Mark ramdisk buffers heads dirty
Looking at it. If we don't get carried away using our own private
inode is barely more difficult then stomping on release_page and
in a number of ways a whole lot more subtle. At least for 2.6.24 I
think it makes a sane fix, and quite possibly as a back port as well.
Eric
-
| Oct 19, 3:46 pm 2007 |
| Eric W. Biederman | Re: [RFC][PATCH] block: Isolate the buffer cache in it's ...
From the perspective of the ramdisk it expects the buffer cache to
simply be a user of the page cache, and thus the buffer cache
is horribly buggy.
From the perspective of the buffer cache it still the block device
cache in the kernel and it the way it works are the rules for how
caching should be done in the kernel, and it doesn't give any
There are certainly implementation issues in various filesystems
to overcome before remounting read-write after doing a fsck
on a read-only filesystem ...
| Oct 19, 2:35 pm 2007 |
| Eric W. Biederman | Re: [RFC][PATCH] block: Isolate the buffer cache in it's ...
We broke coherence between the fs and /dev/hda1 when we introduced
the page cache years ago, and weird hacky cases like
unmap_underlying_metadata don't change that. Currently only
Well I took a look at ext3. For online resize all of the writes are
done by the fs not by the user space tool. For e2fsck of a read-only
filesystem currently we do cache the buffers for the super block and
reexamine those blocks when we mount read-only.
Which makes my patch by itself unsafe. If however ext3 ...
| Oct 19, 2:27 pm 2007 |
| Vitaliy Ivanov | Re: [2.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Hi all,
Didn't here anything on this? What is our final decision here?
Thanks,
Vitaliy
-
| Oct 19, 8:26 am 2007 |
| Vitaliy Ivanov | Re: [2.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Probably I'm not trying to do what you want. I analyzed locks for other
usb drivers in 2.4 tree and used same ideas.
Static lock minor_table_mutex is used for minor table structure.
And dev->sem for dev manipulations and that's why for open_count.
If you will simply browse /drivers/usb dir for 2.4 you will see that
such approach is widely used there.
What's not right?
Let's do everything correctly for 2.4.
V.
-
| Oct 19, 10:40 am 2007 |
| Pete Zaitcev | Re: [2.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
It's gotten worse, not better. Apparently, you aren't getting the
concept of protecting the open count with a static lock and my
explanations are just not vivid enough or something. So I decided
to fix it myself. Maybe then the patch in C will explain it better
than English. But I didn't have time to do it.
Also, there's an outright bug in the latest version. Your purge
of the wrong lock was incomplete and so there was an unbalanced up().
But this is moot.
So, the version before the latest ...
| Oct 19, 9:53 am 2007 |
| Rogier Wolff | Re: OOM killer gripe (was Re: What still uses the block ...
Not really. They are talking about doing this for the page
cache. That's where filesystem files are cached in memory. I'm talking
about the memory that programs use while they are running.
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous ...
| Oct 19, 12:21 am 2007 |
| Rob Landley | Re: OOM killer gripe (was Re: What still uses the block ...
I believe that was more or less the topic of this paper:
http://kernel.org/doc/ols/2006/ols2006v2-pages-73-78.pdf
Although these seem sort of tangentially related:
http://kernel.org/doc/ols/2006/ols2006v1-pages-369-384.pdf
http://kernel.org/doc/ols/2006/ols2006v2-pages-125-130.pdf
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
-
| Oct 18, 11:49 pm 2007 |
| Andy Whitcroft | Re: latest checkpatch
Indeed so. checkpatch uses all the context it can when making a
decision. Often 3 lines carries enough history to figure this out.
-apw
-
| Oct 19, 2:01 am 2007 |
| Ilpo Järvinen | Re: latest checkpatch
Should probably detect these as well (if not yet being done):
if (abc)
#if...
def();
ghi();
#e...
...plus this one:
if (abc)
#if...
def();
#endif
ghi();
...Both of them are clearly bugs.
...and this where either indentation has to be fixed or the bug corrected:
if (abc)
def();
--
i.
-
| Oct 19, 2:12 am 2007 |
| Olaf Hering | Re: apm system does not power off anymore
CONFIG_APM was changed from =y to =m.
'modprobe -v apm power_off=1' fixed it.
-
| Oct 19, 2:36 am 2007 |
| Jiri Kosina | PIE randomization (was Re: 2.6.23-mm1)
Thanks a lot, it works flawlessly. I will rebase the patch after
2.6.24-rc1 is released and will send it to Andrew's queue, hopefully for
2.6.25.
Thanks!
--
Jiri Kosina
-
| Oct 19, 2:07 am 2007 |
| Jiri Kosina | Re: 2.6.23-mm1
Andrew,
below is a fixed version with patch from Kamezawa Hiroyuki incorporated.
It fixes the small regression Kamezawa found just at the time you sent
merge request for this patch to Linus -- that ia32 ELF binaires on x86_64
were able to allocate only about 2/3 of memory they were able to allocate
without this patch. Apart from this fix, the patch is the same as it has
been in -mm tree for quite some time.
It'd be great if it could make it for 2.6.24, if feasible. Thanks.
From: ...
| Oct 19, 2:54 pm 2007 |
| Paul Menage | Re: 2.6.23-mm1 - list_add corruption in cgroup
This is a crash on
list_add(&child->cg_list, &child->cgroups->tasks);
in cgroup_post_fork(). So it looks like child->cgroups->tasks.next is
a deleted list element. But there are no places that modify that list
outside of write_lock(&css_set_lock) as far as I can see, so I'm a bit
confused as to what the problem could be. I'll try to reproduce this.
Paul
-
| Oct 19, 3:11 pm 2007 |
| David Brownell | Re: [PATCH 02/10] Blackfin SPI driver: use new GPIO API ...
I'm still not quite sure why the patches you sent didn't apply
Yes, various cleanup patches. Missing newlines in dev_*() calls,
class_device removal, remove extra includes, and so forth. They
might conflict with your patches (I suspect they won't).
That's a big part of why you should arrange to submit patches well
in advance of the merge window opening. As a rule, maintainers
won't have/make extra time during that window to review and/or fix
nontrivial issues, or address conflicts with ...
| Oct 19, 10:57 am 2007 |
| Olof Johansson | [PATCH v2] [2/2] powerpc: Switch to generic WARN_ON()/BUG_ON()
[POWERPC] Switch to generic WARN_ON()/BUG_ON()
Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
4K text on a ppc64_defconfig. The main reason seems to be that prepping
the arguments to the conditional trap instructions is more work than
just doing a compare and branch.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: k.org/include/asm-powerpc/bug.h
===================================================================
--- k.org.orig/include/asm-powerpc/bug.h
+++ ...
| Oct 18, 7:03 pm 2007 |
| Olof Johansson | [PATCH v2] [1/2] bug.h: Remove HAVE_ARCH_BUG.* / HAVE_AR ...
No need to have the HAVE_ARCH_BUG.* / HAVE_ARCH_WARN.* defines, when
the generic implementation can just use #ifndef on the macros themselves.
Also, introduce __WARN() in the generic case, so the generic WARN_ON()
can use arch-specific code for when the condition is true.
Built on powerpc, i386, sh and sparc64.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: k.org/include/asm-generic/bug.h
===================================================================
--- ...
| Oct 18, 7:03 pm 2007 |
| Phillip Susi | Re: [PATCH 0/2 -mm] kexec based hibernation -v5
Why is a third kernel needed? Why can't kernel B be used for this as
well? In fact, if kernel A has been compiled to be relocatable and
crash dump enabled, why wouldn't it suffice for all 3 instances?
-
| Oct 19, 12:53 pm 2007 |
| Rob Landley | Re: [PATCH] Make m68k cross compile like every other arc ...
Searching for common cross compiler prefixes. Cool.
What do you do if you want to use gcc as your host compiler, but m68k-pcc or
arm-tcc as your target compiler? (I have no idea, CROSS_COMPILE=m68k- CC=pcc
HOSTCC=gcc perhaps? Where does CC get set right now, anyway... Ah, top
level Makefile:
CC = $(CROSS_COMPILE)gcc
Other query:
If CROSS_COMPILE isn't set, and we iterate through all the standard prefixes
but don't find a compiler, what's the right "fall off the ...
| Oct 18, 11:38 pm 2007 |
| Sam Ravnborg | Re: [PATCH] Make m68k cross compile like every other arc ...
No - that would be a bug. One may set up PATH sp gcc point to the
I do not see why thats a problem - you just need to set both CC and HOSTCC.
Sam
-
| Oct 19, 8:10 am 2007 |
| Jason.V.Mock | RE: [NFS] Kernel Oops in NFS
Thanks Trond. The Tainted flag is *probably* due to the NVIDIA driver,
but I'd also have to check the realtime-lsm. Either way we'll get that
built up and see...
Thanks again!!
- Jason Mock
-
| Oct 19, 11:30 am 2007 |
| Chuck Ebbert | Re: x86_64 and AMD with C1E
How are you disabling C1E?
-
| Oct 19, 9:39 am 2007 |
| Jeff Garzik | Re: [PATCH] sata_nv,ahci: add the ahci legacy mode suppo ...
hmmm is that the correct URL? That one updates sata_nv to support AHCI
controllers?.
I would think you would want to add the RAID class code to ahci.c
instead? And just some regular PCI IDs?
Jeff
-
| Oct 19, 12:25 am 2007 |
| Jeff Garzik | Re: [PATCH] sata_nv,ahci: add the ahci legacy mode suppo ...
Unfortunately I do not feel like this is the right course of action.
Experience from Intel platforms tells us that our users get very unhappy
when their silicon supports AHCI mode, but they are forced into using a
less-performant mode. A popular example is an <unnamed> OEM whose BIOS
had no method whatsoever for enabling AHCI -- didn't even program the
PCI BAR -- even though tests showed the AHCI mode worked just fine when
manually programmed.
AHCI is more likely to provide a /stable/ ...
| Oct 18, 7:56 pm 2007 |
| peer chen | Re: [PATCH] sata_nv,ahci: add the ahci legacy mode suppo ...
Ok,I agree to use AHCI driver for our AHCI controllers no matter their
class codes are IDE/RAID/AHCI. But for those new or upcoming AHCI
controller which DIDs are not included in ahci.c and also IDE/RAID
mode being set in BIOS, no driver will be loaded currently, so I hope
the first patch http://lkml.org/lkml/2007/10/8/93 can be appied for
this case. Any comments?
-
| Oct 18, 11:58 pm 2007 |
| Jarek Poplawski | Re: [PATCH] flush_work_sync vs. flush_scheduled_work Re: ...
On Fri, Oct 19, 2007 at 09:50:14AM +0200, Jarek Poplawski wrote:
...But, not much less...
Jarek P.
-
| Oct 19, 1:01 am 2007 |
| Maciej W. Rozycki | Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
Well, I have now recalled what the issue is -- we just plainly and simply
want to avoid a hardirq spinlock for the very reason we do not do all the
processing in the hardirq handler. The thing is we make accesses to the
MDIO bus with the phydev lock held and it may take ages until these
accesses will have completed. And we cannot afford keeping interrupts
disabled for so long.
So the only way is to make the check for the HALTED state lockless and
make sure any race condition is ...
| Oct 19, 4:38 am 2007 |
| Johannes Berg | Re: [PATCH] flush_work_sync vs. flush_scheduled_work Re: ...
3. Add lockdep annotation like the other API. :) Andrew just sent my
patch (used to be two patches by somebody's request but that's fine)
titled "workqueue: debug flushing deadlocks with lockdep" to Linus.
johannes
| Oct 19, 1:00 am 2007 |
| Benjamin Herrenschmidt | Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
My main problem is time :-) But I need to do the change to mutex if I am
to use phylib for emac. I can't tell when I'll have time to do it tho.
Ben.
-
| Oct 19, 2:46 pm 2007 |
| Jarek Poplawski | Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
Actually I'm not convinced with this explanation. It seems to me that
since there are such serious locking problems (especially with rntl),
there could be once more considered a private workqueue. You've
written earlier about being a lonely user of this code. But, since
Benjamin offered his help with changing to mutexes, which looks like
very reasonable idea to me (probably I miss most of the points...),
maybe it's very good opportunity to both: make this code better and
double the user base! ...
| Oct 19, 7:39 am 2007 |
| Maciej W. Rozycki | Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
Well, this will change eventually when I submit the patch for Broadcom
SiByte platforms so that sb1250-mac.c will be able to request an interrupt
for the PHYs. All the infrastructure is in place except from platform
code to configure the SOC's GPIO line used for the interrupt input (when
I do not object and can certainly cooperate, but cannot make it a high
priority work for me at the moment -- sorry.
Maciej
-
| Oct 19, 10:58 am 2007 |
| Maciej W. Rozycki | Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
That's because free_irq() does not disable the interrupt in the correct
manner. The scenario is more or less like this:
phy_interrupt() [depth == 0]
disable_irq()
depth++; status |= IRQ_DISABLED;
...
free_irq() [depth == 1]
status |= IRQ_DISABLED;
...
phy_change() [depth == 1]
enable_irq()
depth--; status &= ~IRQ_DISABLED;
oops!
Now if free_irq() correctly incremented the depth counter, then the last
enable_irq() would still decrement it, but with its initial ...
| Oct 19, 5:57 am 2007 |
| Jarek Poplawski | Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
But then... your patch seems to make it possible, because it enables
irq to the initial state of the counter. Of course, this could happen
on closing only.
Jarek P.
-
| Oct 19, 1:17 am 2007 |
| Jarek Poplawski | Re: [PATCH] flush_work_sync vs. flush_scheduled_work Re: ...
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOPS!
Of course, we can't!!! I remembered there was this issue long time
ago, but then I've had some break in tracking net & workqueue. So,
while reading this patch I was alarmed at first, and self-misled
later. I think, there is definitely needed some warning about
locking (or unlocking) during these flush_ & cancel_ functions.
(Btw, I've very much wondered now, why I didn't notice at that 'old'
time, that you added such a ...
| Oct 19, 12:50 am 2007 |
| Jiri Kosina | Re: [PATCH] [RESEND] i386 and x86_64: randomize brk()
... back to this a week old thread about already dropped patch.
I am thinking about going back to the original idea of just simply
defining ARCH_HAS_RANDOMIZE_BRK and not caring for the ELF crap any more
for now. This way the patch is as small as possible, and doesn't interfere
with the ELF cross-arch craziness at all.
Here I posted such version of the patch:
http://lkml.org/lkml/2007/8/22/254 and here you asked me to put empty
stubs into elf.h, which turned out to be too headache for ...
| Oct 19, 3:10 pm 2007 |
| Hollis Blanchard | Re: [kvm-devel] Use virtual cpu accounting if available ...
I don't understand. Should kvm_guest_exit() be calling
account_user_vtime() (instead of account_system_vtime())?
--
Hollis Blanchard
IBM Linux Technology Center
-
| Oct 19, 9:57 am 2007 |
| Hollis Blanchard | Re: [kvm-devel] Use virtual cpu accounting if available ...
Never mind; the tree I was looking at didn't have the
account_guest_time() stuff in account_system_time().
--
Hollis Blanchard
IBM Linux Technology Center
-
| Oct 19, 10:18 am 2007 |
| Olof Johansson | [PATCH v3] pcmcia: Convert io_req_t to use unsigned int
[PCMCIA] Convert some internal-only ioaddr_t to unsigned int
Convert the io_req_t members to unsigned int, to allow use on machines
with more than 16 bits worth of IO ports (i.e. secondary busses on
ppc64, etc).
There was only a couple of places in drivers where a change was needed. I
left printk formats alone (there are lots of %04x-style formats in there),
mostly to not change the format on the platforms that only have 16-bit
io addresses, but also because the padding doesn't really add all ...
| Oct 19, 1:17 pm 2007 |
| Mingming Cao | Re: [PATCH 2/2] ext2: Avoid rec_len overflow with 64KB b ...
Just to clarify this is only changes the directory entries format on
ext2/3/4 fs with 64k block size. But currently without kernel changes
The e2fsprogs needs to be changed to sync up with this change.
Ted has a paper a while back to show ext2 disk format
http://web.mit.edu/tytso/www/linux/ext2intro.html
The Documentation/filesystems/ext2.txt doesn't have the ext2 format
documented. That document is out-dated need to be reviewed and cleaned
Without the first patch in this series: ext2 ...
| Oct 18, 7:05 pm 2007 |
| Paul Rolland | Re: [2.6.22.5] irq X: nobody cared but X is successfully ...
Hi Tejun,
On Fri, 19 Oct 2007 12:23:15 +0900
Not tested yet, will do so during the WE.
Regards,
Paul
-
| Oct 19, 5:14 am 2007 |
| Tejun Heo | Re: [2.6.22.5] irq X: nobody cared but X is successfully ...
Does this still happen with 2.6.23? If so, please post boot log. Thanks.
--
tejun
-
| Oct 18, 8:23 pm 2007 |
| Bjoern Olausson | Re: [2.6.22.5] irq X: nobody cared but X is successfully ...
No it does not.
I have nearly the same setup (ASUS P5W-DH-Deluxe, Core2, 2GB RAM, 3
SATA and 2IDE)
And a "dmesg | grep irqpoll does not show up with results.
dmsg | grep 23 comes up with:
wifi0: Atheros 5212: mem=0xeb9f0000, irq=23
And I no longer use IRQPOLL (I dropped it somwhere between 2.6.22.?
and 2.6.23) as Kernel option.
kernel (hd0,0)/vmlinuz root=/dev/sda3 video=nvidiafb:1280x1024-32@85,mtrr,ywrap
All SATA Ports are working (except the the PMP... it "works" but I
would not ...
| Oct 19, 6:52 am 2007 |
| Simon Horman | Re: [PATCH 2/3] [kexec-tools] Pass vmcoreinfo's address ...
Thanks, applied.
-
| Oct 18, 8:38 pm 2007 |
| Sam Ravnborg | Re: [PATCH v3] kconfig: update kconfig-language text
Thanks Randy - applied.
Sam
-
| Oct 19, 12:59 pm 2007 |
| Randy Dunlap | [PATCH v3] kconfig: update kconfig-language text
From: Randy Dunlap <randy.dunlap@oracle.com>
Add kconfig-language docs for mainmenu, def_bool, and def_tristate.
Remove "requires" as a synonym of "depends on" since it was removed
from the parser in commit 247537b9a270b52cc0375adcb0fb2605a160cba5.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
Documentation/kbuild/kconfig-language.txt | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
--- ...
| Oct 19, 10:53 am 2007 |
| previous day | today | next day |
|---|---|---|
| October 18, 2007 | October 19, 2007 | October 20, 2007 |
