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/ -

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 ...

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 -

Fair enough. Did not notice. tglx -

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 ...

Can you try to strace the hanging task? -

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 ...

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 ...

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 ...

Trying 'make mrproper' first has high chances of fixing this I'd guess. -- Jiri Kosina -

I get the same on fresh cloned git tree #-- git rev-parse --verify HEAD c4ec20717313daafba59225f812db89595952b83 Regards, Gabriel -

Hmm. The kernel itself compiles fine ? What external thing breaks ? tglx -

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 ...

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 ...

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 ...

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 ...

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 ...

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>

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: ...

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 ...

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 =================================================================== --- ...

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 =================================================================== --- ...

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 +++ ...

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 ...

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 ...

There is the EEPROM flip/script at the bottom -- can anyone confirmed that it fixed their issues if they had problems? Justin. -

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 +++ ...

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 +++ ...

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 -

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 +++ ...

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 ...

-- 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 -

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 -

-- 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 -

=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 ...

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 =================================================================== --- ...

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

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? -

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. -

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 -

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/ -

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

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 ...

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 ...

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 +++ ...

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 ...

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> --- ...

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 ...

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 ...

Yes, this patch did fix the locking problem. Thanks, Larry -

It does work better. With it, I was able to make a dial-up connection and send pings over it. Larry -

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 ...

>>>>> "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 ...

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 ...

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 ...

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: ...

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") == ...

Acked-by: Chriustoph Lameter <clameter@sgi.com> -

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); ...

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 ...

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 -

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 -

This patchset includes two patches. 1. Checks for the MCA fetures as early as possible and signedness fixup. 2. Minor coding style 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 ...

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) ...

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 -

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 -

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 -

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. -

Actually, the working version was 2.6.23-rc6, git-head of kvm.git as of October 11. -

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. -

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 -

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 ...

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 -

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 -

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 ...

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 ...

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 -

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: [ ...

A good candidate to checkpatch.pl's check list, btw. Signed-off-by: Ilpo J

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 -

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 -

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 -

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 -

I was talking about vm86_32.c in particular. Where we allow user space Yes. Eric -

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 ...

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 -

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 +- ...

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 ...

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 -

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 ...

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 ...

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 -

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 -

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 -

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 -

Hey I'm the one who has kept the ball rolling since the day pt_regs were removed... :) Jeff -

x86_write_percpu(__irqfunc_irqs, new_irq) would be slightly more efficient here. Any why the pointer anyway? J -

why not? -

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 ...

-

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 +- ...

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 +- ...

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 | ...

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 -

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 ...

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.

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 -

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 ...

A couple of questions: * Are these files being sillyrenamed? * Are they shown as being removed by the server? Cheers Trond -

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: ...

My version of this patch does that. I'll be sending it into Linus in an hour or so. -

From: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: David S. Miller <davem@davemloft.net> -

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 @@ ...

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 ...

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 ...

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 ...

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 ...

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) || ...

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 ...

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 ...

(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, ...

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 -

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 ...

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 ...

Yes. The NULL filter is a valid case, when there are no filters attached at all. So this fix is correct. -

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 = ...

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) ...

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 --- ...

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 ...

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 ...

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. -

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 ...

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 :) -

I wonder why we bother having --build-id. -- vda -

Sure, we do. Greetings, Rafael -

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); ...

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. -

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 -

hmm, that doesn't fix the oops. /me looking. Thanks, C. -

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 ...

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? -

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 -

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 +++ ...

where can i pick the latest sg patchset up from? These build failures are ruining my make randconfig build tests :) Ingo -

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 -

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 [ ...

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 ...

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 -

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 ...

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 -

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 -

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 -

Yes, I generally prefer char[] - but only because gcc irritatingly rejects void []... J -

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 ...

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 ...

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 ...

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 ...

Just to make sure, could you check in System.map that accent_table is correctly 256*3*4=3072 bytes long? Samuel -

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 ...

Not true. Once pciehp is loaded, it automatically detects and handles inserted and removed cards just fine. Until after the next suspend/resume. Cheers -

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 -

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, ...

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 ...

Good for me. Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cheers, Ben. -

Ouch!, is there really no sane locking alternative? Hashed waitqueues -

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 ...

From: Herbert Xu <herbert@gondor.apana.org.au> Applied, thanks Herbert! -

Yeah, if you've got the lock on both sides there, then I agree it will be correct. -

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 -

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 ...

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 -

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, -- ...

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 ...

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 -

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 ...

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 -

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 -

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 ...

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 ...

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 -

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 -

[Empty message]

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 ...

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: -

I see. Actually this is the first time I was told about it. I know it missed the merge window. Thanks again -Bryan Wu -

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 ...

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 ...

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 -

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 ...

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. -

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 ...

Indeed so. checkpatch uses all the context it can when making a decision. Often 3 lines carries enough history to figure this out. -apw -

CONFIG_APM was changed from =y to =m. 'modprobe -v apm power_off=1' fixed it. -

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: ...

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 ...

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 =================================================================== --- ...

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 ...

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 -

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 -

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? -

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 ...

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. -

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 -

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. -

... 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 ...

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 -

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 ...

Does this still happen with 2.6.23? If so, please post boot log. Thanks. -- tejun -

Thanks, applied. -

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(-) --- ...