[PATCH] x86: merge mmu{,_32,_64}.h
From: Chris Snook <[EMAIL PROTECTED]>
Merge mmu_32.h and mmu_64.h into mmu.h.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff -Nurp a/include/asm-x86/mmu_32.h b/include/asm-x86/mmu_32.h
--- a/include/asm-x86/mmu_32.h 2007-10-20 02:42:24.0 -0400
+++ b/include/asm-x86/mmu_32.h 1969-12-31 19:00:00.0 -0500
@@ -1,18 +0,0 @@
-#ifndef __i386_MMU_H
-#define __i386_MMU_H
-
-#include
-/*
- * The i386 doesn't have a mmu context, but
- * we put the segment information here.
- *
- * cpu_vm_mask is used to optimize ldt flushing.
- */
-typedef struct {
- int size;
- struct mutex lock;
- void *ldt;
- void *vdso;
-} mm_context_t;
-
-#endif
diff -Nurp a/include/asm-x86/mmu_64.h b/include/asm-x86/mmu_64.h
--- a/include/asm-x86/mmu_64.h 2007-10-20 02:42:24.0 -0400
+++ b/include/asm-x86/mmu_64.h 1969-12-31 19:00:00.0 -0500
@@ -1,21 +0,0 @@
-#ifndef __x86_64_MMU_H
-#define __x86_64_MMU_H
-
-#include
-#include
-
-/*
- * The x86_64 doesn't have a mmu context, but
- * we put the segment information here.
- *
- * cpu_vm_mask is used to optimize ldt flushing.
- */
-typedef struct {
- void *ldt;
- rwlock_t ldtlock;
- int size;
- struct mutex lock;
- void *vdso;
-} mm_context_t;
-
-#endif
diff -Nurp a/include/asm-x86/mmu.h b/include/asm-x86/mmu.h
--- a/include/asm-x86/mmu.h 2007-10-20 02:42:24.0 -0400
+++ b/include/asm-x86/mmu.h 2007-10-20 02:38:36.0 -0400
@@ -1,5 +1,23 @@
-#ifdef CONFIG_X86_32
-# include "mmu_32.h"
-#else
-# include "mmu_64.h"
+#ifndef _ASM_X86_MMU_H
+#define _ASM_X86_MMU_H
+
+#include
+#include
+
+/*
+ * The x86 doesn't have a mmu context, but
+ * we put the segment information here.
+ *
+ * cpu_vm_mask is used to optimize ldt flushing.
+ */
+typedef struct {
+ void *ldt;
+#ifdef CONFIG_X86_64
+ rwlock_t ldtlock;
#endif
+ int size;
+ struct mutex lock;
+ void *vdso;
+} mm_context_t;
+
+#endif /* _ASM_X86_MMU_H */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
sata sil3114 vs. certain seagate drives results in filesystem corruptions
Dear all, I finally managed to find a *reproducible* setup and way to trigger random corruptions using a sata sil 3114 controller connected to 4 seagate drives port 1: ST3400832AS sda port 2: ST3400620AS sdb port 3: ST3750640AS sdc port 4: ST3750640AS sdd sda & sdb form md0 via a raid1 setup followed by an additional devicemapper layer ( root ). sdc and sdb are separate and also have an additional device mapper layer ( public ) and ( backups ). Now when I write large files of zeros to root(sda&sdb) and read the file back in it contains a few nonzero entries: # dd if=/dev/zero of=/foo bs=1M count=2000 # hexdump /foo 000 * 1GB random parts, within large blocks of zeroes> I can reliably trigger this on the md0 / devmapper-root setup when I write about 2GB of data (note that this machine has 1.5G of memory - and still 1GB is often enough to see this problem). Here it does not matter where in the filesystem I do these writes. As a test I did the same on sdc / devmapper-public and sdd/devmapper-backups with even 30G of zeros. Nothing, no errors everything is perfectly OK. So I thought that this is also the the sil mod15write problem http://home-tj.org/wiki/index.php/Sil_m15w and applied patches 1 & 2 from http://lkml.org/lkml/2007/10/11/115 (adding my two disks) and rebooted. Now there was some MOD15 stuff in dmesg for the two disks but still apart from the disks being even slower it was of no use - the corruption problem was still there (I then also tried patch 3 from Bernd but that immediately caused oopses fs/errors). So it looks like the problem I am having is different... Now I remembered that this machine also has two idle promise pdc20376 sata ports where I first tried the ST3400832AS (sda) and ST3400620AS (sdb) on about a year ago http://lists.openwall.net/linux-kernel/2006/08/27/106 . At that time I just saw random error messages and then finally hangs - quoting Tejon Heo: "I see. your drive is reporting error for some reason and libata is failing to recover." Now promise_sata is converted to new EH, so I simply gave it a go, i.e. I attached ST3400832AS and ST3400620AS to the promise controller and rebooted and redid the experiments from above. No data corruptions whatsoever. I even ran the dd on all three devmapped mount points simultaneously with a size of 30GB each, still no corruption. However the error messages I've seen a year ago are back for the ST3400832AS and ST3400620AS attached to the promise controller (see below). Please find all the details below: - uname Linux 2.6.23.1 #3 PREEMPT Fri Oct 19 20:39:45 CEST 2007 i686 GNU/Linux - lspci 00:0e.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02) 00:0e.0 0104: 1095:3114 (rev 02) 00:08.0 RAID bus controller: Promise Technology, Inc. PDC20376 (FastTrak 376) (rev 02) 00:08.0 0104: 105a:3376 (rev 02) - proc interrupts 17:4434549 IO-APIC-fasteoi sata_promise, sata_sil, ohci1394 - dmesg sata_sil :00:0e.0: version 2.3 ACPI: PCI Interrupt :00:0e.0[A] -> GSI 17 (level, low) -> IRQ 17 sata_sil :00:0e.0: Applying R_ERR on DMA activate FIS errata fix scsi3 : sata_sil scsi4 : sata_sil scsi5 : sata_sil scsi6 : sata_sil ata4: SATA max UDMA/100 cmd 0xf882e080 ctl 0xf882e08a bmdma 0xf882e000 irq 17 ata5: SATA max UDMA/100 cmd 0xf882e0c0 ctl 0xf882e0ca bmdma 0xf882e008 irq 17 ata6: SATA max UDMA/100 cmd 0xf882e280 ctl 0xf882e28a bmdma 0xf882e200 irq 17 ata7: SATA max UDMA/100 cmd 0xf882e2c0 ctl 0xf882e2ca bmdma 0xf882e208 irq 17 ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata4.00: ATA-7: ST3400832AS, 3.01, max UDMA/133 ata4.00: 781422768 sectors, multi 16: LBA48 NCQ (depth 0/32) ata4.00: configured for UDMA/100 ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata5.00: ATA-7: ST3400620AS, 3.AAE, max UDMA/133 ata5.00: 781422768 sectors, multi 16: LBA48 NCQ (depth 0/32) ata5.00: configured for UDMA/100 ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata6.00: ATA-7: ST3750640AS, 3.AAE, max UDMA/133 ata6.00: 1465149168 sectors, multi 16: LBA48 NCQ (depth 0/32) ata6.00: configured for UDMA/100 ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata7.00: ATA-7: ST3750640AS, 3.AAC, max UDMA/133 ata7.00: 1465149168 sectors, multi 16: LBA48 NCQ (depth 0/32) ata7.00: configured for UDMA/100 scsi 3:0:0:0: Direct-Access ATA ST3400832AS 3.01 PQ: 0 ANSI: 5 sd 3:0:0:0: [sda] 781422768 512-byte hardware sectors (400088 MB) sd 3:0:0:0: [sda] Write Protect is off sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:0:0:0: [sda] 781422768 512-byte hardware sectors (400088 MB) sd 3:0:0:0: [sda] Write Protect is off sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: unknown partition table sd 3:0:0:0: [sda] Attached SCSI disk sd 3:0:0:0:
Re: VIA VT6307 OHCI version?
Krzysztof Halasa wrote: > OTOH, it's no magic - they claim OHCI 1.1 and they do it. We don't > only know how to enable it with (only) software. I suspect all those > VT6306 could be "upgraded" as well. What if we add a whitelisting in the driver which ignores the register contents which state OHCI 1.0 implementation level, and just treats these VIA chips as OHCI 1.1 implementations? -- Stefan Richter -=-=-=== =-=- =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synchronize_irq needs a barrier
On Sat, 2007-10-20 at 08:06 +0200, Maxim Levitsky wrote: > /* Disable interrupts, DMA, and rest of the chip*/ > saa_writel(SAA7134_IRQ1, 0); > saa_writel(SAA7134_IRQ2, 0); > saa_writel(SAA7134_MAIN_CTRL, 0); > dev->insuspend = 1; > synchronize_irq(pci_dev->irq); > > /* ACK pending interrupts just in case*/ > saa_writel(SAA7134_IRQ_REPORT,saa_readl(SAA7134_IRQ_REPORT)); > > .. > This should be bullet-proof. Hopefully :-) Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synchronize_irq needs a barrier
On Saturday 20 October 2007 07:46:24 Benjamin Herrenschmidt wrote: > > > I probably need to add this synchronize_irq() logic in dmfe.c too, but I > > probably do it later, > > I think I am overestimating this race, since most drivers don't do > > dev->insuspend checks in IRQ handler. > > Maybe even just use free_irq() after all > > Most drivers are probably underestimating the race :-) > > free_irq() would work provided that you did the masking on chip before > (and unmask only after request_irq on the way back in). But it's a bit > like using a 10 tons truck to crush an ant... Agreed. So, I will add synchronize_irq() to both saa7134, and dmfe, the two drivers that their .suspend/.resume routines were written by me. I already added a synchronize_irq() plus few more fixes to the driver , but those patches are still in v4l tree. I now has this: saa_writel(SAA7134_IRQ1, 0); saa_writel(SAA7134_IRQ2, 0); saa_writel(SAA7134_MAIN_CTRL, 0); synchronize_irq(pci_dev->irq); dev->insuspend = 1; and I will probably need (with the synchronize_irq patch applied) /* Disable interrupts, DMA, and rest of the chip*/ saa_writel(SAA7134_IRQ1, 0); saa_writel(SAA7134_IRQ2, 0); saa_writel(SAA7134_MAIN_CTRL, 0); dev->insuspend = 1; synchronize_irq(pci_dev->irq); /* ACK pending interrupts just in case*/ saa_writel(SAA7134_IRQ_REPORT,saa_readl(SAA7134_IRQ_REPORT)); .. This should be bullet-proof. > > Ben. > > > Best regards, Maxim Levitsky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] Locking problem in usbserial with 2.6.23-git 5a34417f
On Sat, Oct 20, 2007 at 12:05:19AM +0200, Jiri Kosina wrote: > On Fri, 19 Oct 2007, Larry Finger wrote: > > > As I said earlier, the lock problem went away; however, I get the > > following two kernel warnings: > > That's because I messed up the patch, sorry. The one below should work > better. > > > > From: Jiri Kosina <[EMAIL PROTECTED]> > > USB: usbserial - fix potential deadlock between write() and IRQ Jiri, thanks a lot for the fix, I'll queue it up. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
On Fri, Oct 19, 2007 at 03:54:43AM -0400, Jeff Garzik wrote: > > 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 tiny few -- a couple Mac drivers -- which do weird things > with that argument, but that's it. > > For the large sweeps through the tree, these patches are grouped into > "trivial" changes -- simply removing the unused irq arg -- or all other > changes. Very cool stuff, I like it :) greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-mm1 - autofs broken
On Sat, 20 Oct 2007 01:54:04 -0400 Rik van Riel <[EMAIL PROTECTED]> wrote: > On Fri, 19 Oct 2007 22:39:00 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel <[EMAIL PROTECTED]> > > wrote: > > > > > On Thu, 11 Oct 2007 21:31:26 -0700 > > > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > > > > > > > - I've been largely avoiding applying anything since rc8-mm2 in > > > > an attempt to stabilise things for the 2.6.23 merge. > > > > > > Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the > > > -mm kernel. > > > > > > Instead of mounting my home directory, I get these messages in > > > /var/log/messages: > > > > > > Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent > > > cache rwlock lock failed > > > Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error: > > > 11 at 65 in cache.c > > > > > > I am not sure if this is due to autofs changes or changes in some > > > other code that was merged. If you can think of any suspicious > > > change that I should test, please let me know. > > > > I don't think anything changed in autofs in that period. I'd be > > suspecting the r-o-bind-mounts patches, but they didn't change much > > in that time either. > > > > Does current mainline work OK? If so, pretty much the only thing in > > that area left unmerged is r-o-bind-mounts and hch's exportfs stuff. > > Yes, 2.6.23 mainline works fine. Let me clarify: 2.6.23 vanilla works. I have not yet tried the latest 2.6.23+ git tree. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
According to - http://www.samsungoms-europe.com/samsung.php?section=product&id=SH-S202&group=multi this drive only does UDMA2 and PIO4. Roger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-mm1 - autofs broken
On Fri, 19 Oct 2007 22:39:00 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel <[EMAIL PROTECTED]> > wrote: > > > On Thu, 11 Oct 2007 21:31:26 -0700 > > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > > > > > - I've been largely avoiding applying anything since rc8-mm2 in an > > > attempt to stabilise things for the 2.6.23 merge. > > > > Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the > > -mm kernel. > > > > Instead of mounting my home directory, I get these messages in > > /var/log/messages: > > > > Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache > > rwlock lock failed > > Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error: > > 11 at 65 in cache.c > > > > I am not sure if this is due to autofs changes or changes in some > > other code that was merged. If you can think of any suspicious > > change that I should test, please let me know. > > I don't think anything changed in autofs in that period. I'd be > suspecting the r-o-bind-mounts patches, but they didn't change much > in that time either. > > Does current mainline work OK? If so, pretty much the only thing in > that area left unmerged is r-o-bind-mounts and hch's exportfs stuff. Yes, 2.6.23 mainline works fine. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.23-git] toplevel Makefile/depmod bugfix
> > - if [ -r System.map -a -x $(DEPMOD) -a "$(SUBARCH)" == "$(ARCH)" ]; then > > \ > > + if [ -r System.map -a -x $(DEPMOD) -a "$(SUBARCH)" = "$(ARCH)" ]; then \ > > Took a look at 'man bash' here. > bash --version > GNU bash, version 3.2.9(1)-release (x86_64-redhat-linux-gnu) > Copyright (C) 2005 Free Software Foundation, Inc. > > Accoding to man bash "==" is used to test for equality and "=" is used for > assignmnet. "man test" shows that only "=" works ... that's for string equality, which is what's being tested there. And "==" is undefined (error). If "==" were to kick in that would be for an arithmetic expression; but "[" is (modulo wierdness) "test" not "expr". > I assume the above is a dash syntax error (dash is default on ubuntu IIRC). My $SHELL is /bin/bash: $ bash --version GNU bash, version 3.2.13(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. $ > Is it truly protable with "=" or do we need to be more clever? I don't know how you managed to get it to work wtih "==". String equality should be "=" in all /bin/sh versions. It's been that way since it was written in pseudo-Algol. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2 -mm] kexec based hibernation -v5
On 10/20/07, Phillip Susi <[EMAIL PROTECTED]> wrote: > Huang, Ying wrote: > > The hibernation procedure with the patch set is as follow: > > > > 1. Boot a kernel A > > > > 2. Work under kernel A > > > > 3. Kexec another kernel B (crash dump enabled) in kernel A. > > > > 4. Save the memory image of kernel A through crash dump (such as "cp > >/proc/vmcore ~"). Save the "jump back entry". > > Doesn't this also save the memory of kernel B? The memory area of kernel B is excluded from the elf header of /proc/vmcore. This is done in kexec-tools (/sbin/kexec) patches. > > 5. Shutdown or reboot > > > > > > The restore process with the patch set is as follow: > > > > 1. Boot a kernel C (crash dump enabled), the memory area used by > >kernel C must be a subset of memory area used by kernel B. > > 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? One kernel can be used for three situation. In fact, I use just one kernel for testing. Best Regards, Huang Ying - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synchronize_irq needs a barrier
> I probably need to add this synchronize_irq() logic in dmfe.c too, but I > probably do it later, > I think I am overestimating this race, since most drivers don't do > dev->insuspend checks in IRQ handler. > Maybe even just use free_irq() after all Most drivers are probably underestimating the race :-) free_irq() would work provided that you did the masking on chip before (and unmask only after request_irq on the way back in). But it's a bit like using a 10 tons truck to crush an ant... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.23-git] toplevel Makefile/depmod bugfix
> Accoding to man bash "==" is used to test for equality and "=" is used for > assignmnet. > I assume the above is a dash syntax error (dash is default on ubuntu IIRC). My bash man page says the following under "CONDITIONAL EXPRESSIONS": string1 == string2 True if the strings are equal. = may be used in place of == for strict POSIX compliance. This is bash 3.1 as packaged by Debian. So I think "=" is the correct thing to use for compatibility with dash or other non-bash shells, since as far as I know, there are no situations where a comparison with "=" will fail but "==" will succed. (ie "=" is strictly more compatible). - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-mm1 - autofs broken
On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel <[EMAIL PROTECTED]> wrote: > On Thu, 11 Oct 2007 21:31:26 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > > > - I've been largely avoiding applying anything since rc8-mm2 in an > > attempt to stabilise things for the 2.6.23 merge. > > Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the > -mm kernel. > > Instead of mounting my home directory, I get these messages in > /var/log/messages: > > Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache > rwlock lock failed > Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error: 11 at > 65 in cache.c > > I am not sure if this is due to autofs changes or changes in some other > code that was merged. If you can think of any suspicious change that > I should test, please let me know. I don't think anything changed in autofs in that period. I'd be suspecting the r-o-bind-mounts patches, but they didn't change much in that time either. Does current mainline work OK? If so, pretty much the only thing in that area left unmerged is r-o-bind-mounts and hch's exportfs stuff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synchronize_irq needs a barrier
On Saturday 20 October 2007 07:04:35 Benjamin Herrenschmidt wrote: > > > 1) some drivers use pci_disable_device(), and pci_enable_device(). > > should I use it too? > > I generally don't do the former, and I would expect the late to be done > by pci_restore_state() for you. pci_disable_device(), last I looked, > only cleared the bus master bit though, which might be a good idea to > do. > > People in ACPI/x86 land, are there more good reasons to do one or the > other ? > > That reminds me that I volunteered to write a documentation on how > drivers should do all that stuff at KS and didn't get to actually doing > it yet. shame ... I'll try to start something asap. > > > 2) I accidentally did this: > > pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state)); > > pci_save_state(pci_dev); > > > > I somehow thought that this is correct, that I should save the pci config > > state > > after the power-down, but now I know that it isn't correct. > > Right, you need to do the save_state before the power down. You need to > avoid pretty much any access to the device after the save state other > than the pending set_power_state on resume. > > > I now need to send a patch for dmfe.c network driver that has the same > > commands written by me. > > (but it works perfectly anyway) > > On x86 desktop... might have surprises on others. > > > Is it possible to access pci configuration space in D3? > > It's only really safe to access the PM register itself, though I suppose > you should be able to walk the capability chain to do that. But I > wouldnt recommend doing anything else. > > > And lastly speaking of network drivers, one issue came to my mind: > > most network drivars has a packet queue and in case of dmfe it is located > > in main memory, > > and card does dma from it. > > Note that the network stack nowadays does a fair bit of cleaning up for > you before your suspend routine is called > > > > in .suspend I ignore that some packets may be in that queue, and I want > > to ask, whenever there are better ways to do that. > > > > > > this is my dmfe .suspend routine. > > > > /* Disable upper layer interface */ > > netif_device_detach(dev); > > > Looks allright on a quick glance appart from the bits we already > discussed. > > > I guess, everybody makes mistakes... :-) > > > > Other network drivers has a bit more complicated .suspend/.resume routines, > > but I didn't see a driver waiting for output queue to finish > > I think the network stack does that nowadays but we'll have to double > check, that's based on what DaveM told me at KS. > > Ben. > > Hi, Thanks a lot. I fix the order of calls in dmfe.c and in saa7134-core.c. I probably need to add this synchronize_irq() logic in dmfe.c too, but I probably do it later, I think I am overestimating this race, since most drivers don't do dev->insuspend checks in IRQ handler. Maybe even just use free_irq() after all Best regards, Maxim Levitsky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]
On Sat, 20 Oct 2007 13:57:54 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote: > On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > Hey there!! > fails to boot here with this friendly oops: > http://oioio.altervista.org/linux/dsc01702.jpg > > .config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1 > > 2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet > (no s2ram with mysql running and some net WARNING). > Let's see if .23-mm1 still has those first. > > I'm adding Cc: linux-scsi > > PS: I'll hardly be able to bisect in the next days... :P That looks like a Jens and Dave production to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.23-git] toplevel Makefile/depmod bugfix
On Fri, Oct 19, 2007 at 09:42:24PM -0700, David Brownell wrote: > This removes a BASH syntax error (seen building on Ubuntu Feisty). > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > > --- g26.orig/Makefile 2007-10-19 21:29:43.0 -0700 > +++ g26/Makefile 2007-10-19 18:35:32.0 -0700 > @@ -1507,7 +1507,7 @@ quiet_cmd_rmfiles = $(if $(wildcard $(rm > # and we build for the host arch > quiet_cmd_depmod = DEPMOD $(KERNELRELEASE) >cmd_depmod = \ > - if [ -r System.map -a -x $(DEPMOD) -a "$(SUBARCH)" == "$(ARCH)" ]; then > \ > + if [ -r System.map -a -x $(DEPMOD) -a "$(SUBARCH)" = "$(ARCH)" ]; then \ > $(DEPMOD) -ae -F System.map > \ > $(if $(strip $(INSTALL_MOD_PATH)), -b $(INSTALL_MOD_PATH) -r) > \ > $(KERNELRELEASE); > \ > - Took a look at 'man bash' here. bash --version GNU bash, version 3.2.9(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. Accoding to man bash "==" is used to test for equality and "=" is used for assignmnet. I assume the above is a dash syntax error (dash is default on ubuntu IIRC). Is it truly protable with "=" or do we need to be more clever? Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-mm1 - autofs broken
On Thu, 11 Oct 2007 21:31:26 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > - I've been largely avoiding applying anything since rc8-mm2 in an > attempt to stabilise things for the 2.6.23 merge. Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the -mm kernel. Instead of mounting my home directory, I get these messages in /var/log/messages: Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache rwlock lock failed Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error: 11 at 65 in cache.c I am not sure if this is due to autofs changes or changes in some other code that was merged. If you can think of any suspicious change that I should test, please let me know. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Bug fix for the s390 dcssblk driver
Hello,
The following patch fixes and issue in the s390 dcssblk driver. The
issue is caused when an unsuccessful attempt is made in order to change
a segment's type through the device attribute file "shared". This causes
the driver to remove the device in question, removing with it the device
attribute which is currently handling the call. The result is a hang on
the driver as it removes memory from under its feet.
Not exactly sure if this explanation makes sense or its entirely
accurate. This is what I believe at this point from encountering and
fixing the error. Anyway here is the patch, hope it helps.
# This patch fixes a memory corruption bug in the s390 dcssblk driver.
# The bug occurs when an attempt to change the type of a segment
# returns an error. At this point the driver tries to remove the segment in
# question while some of the device's attributes are in use. This causes the
# driver to hang.
#
# questions/comments @ [EMAIL PROTECTED]
diff -urN linux-2.6.23.1/drivers/s390/block/dcssblk.c
linuxx/drivers/s390/block/dcssblk.c
--- linux-2.6.23.1/drivers/s390/block/dcssblk.c 2007-10-12 12:43:44.0
-0400
+++ linuxx/drivers/s390/block/dcssblk.c 2007-10-20 00:51:19.0 -0400
@@ -253,8 +253,12 @@
SEGMENT_EXCLUSIVE);
if (rc < 0) {
BUG_ON(rc == -EINVAL);
- if (rc != -EAGAIN)
- goto removeseg;
+ if (rc != -EAGAIN){
+ PRINT_DEBUG("Could not reload segment %s in the
specified format, reloading\n",
+ dev_info->segment_name);
+ rc =
segment_modify_shared(dev_info->segment_name, SEGMENT_SHARED);
+ goto out;
+ }
} else {
dev_info->is_shared = 0;
set_disk_ro(dev_info->gd, 0);
Re: [PATCH] synchronize_irq needs a barrier
> 1) some drivers use pci_disable_device(), and pci_enable_device(). > should I use it too? I generally don't do the former, and I would expect the late to be done by pci_restore_state() for you. pci_disable_device(), last I looked, only cleared the bus master bit though, which might be a good idea to do. People in ACPI/x86 land, are there more good reasons to do one or the other ? That reminds me that I volunteered to write a documentation on how drivers should do all that stuff at KS and didn't get to actually doing it yet. shame ... I'll try to start something asap. > 2) I accidentally did this: > pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state)); > pci_save_state(pci_dev); > > I somehow thought that this is correct, that I should save the pci config > state > after the power-down, but now I know that it isn't correct. Right, you need to do the save_state before the power down. You need to avoid pretty much any access to the device after the save state other than the pending set_power_state on resume. > I now need to send a patch for dmfe.c network driver that has the same > commands written by me. > (but it works perfectly anyway) On x86 desktop... might have surprises on others. > Is it possible to access pci configuration space in D3? It's only really safe to access the PM register itself, though I suppose you should be able to walk the capability chain to do that. But I wouldnt recommend doing anything else. > And lastly speaking of network drivers, one issue came to my mind: > most network drivars has a packet queue and in case of dmfe it is located in > main memory, > and card does dma from it. Note that the network stack nowadays does a fair bit of cleaning up for you before your suspend routine is called > > in .suspend I ignore that some packets may be in that queue, and I want > to ask, whenever there are better ways to do that. > > > this is my dmfe .suspend routine. > > /* Disable upper layer interface */ > netif_device_detach(dev); The above -might- not be needed any more, I have to check. I used to do it too on my drivers. > /* Disable Tx/Rx */ > db->cr6_data &= ~(CR6_RXSC | CR6_TXSC); > update_cr6(db->cr6_data, dev->base_addr); > > /* Disable Interrupt */ > outl(0, dev->base_addr + DCR7); > outl(inl (dev->base_addr + DCR5), dev->base_addr + DCR5); > > /* Fre RX buffers */ > dmfe_free_rxbuffer(db); > > /* Enable WOL */ > pci_read_config_dword(pci_dev, 0x40, &tmp); > tmp &= ~(DMFE_WOL_LINKCHANGE|DMFE_WOL_MAGICPACKET); > > if (db->wol_mode & WAKE_PHY) > tmp |= DMFE_WOL_LINKCHANGE; > if (db->wol_mode & WAKE_MAGIC) > tmp |= DMFE_WOL_MAGICPACKET; > > pci_write_config_dword(pci_dev, 0x40, tmp); > > pci_enable_wake(pci_dev, PCI_D3hot, 1); > pci_enable_wake(pci_dev, PCI_D3cold, 1); > > /* Power down device*/ > pci_set_power_state(pci_dev, pci_choose_state (pci_dev,state)); > pci_save_state(pci_dev); > Looks allright on a quick glance appart from the bits we already discussed. > I guess, everybody makes mistakes... :-) > > Other network drivers has a bit more complicated .suspend/.resume routines, > but I didn't see a driver waiting for output queue to finish I think the network stack does that nowadays but we'll have to double check, that's based on what DaveM told me at KS. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] iptables: mangle table obsoletes filter table
On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said: > Sure, the idea was to mark the filter table obsolete as to make people start > using the mangle table to do their filtering for new setups. The filter > table would then still be available for legacy/special setups. But this > would only be possible if we at least ported the REJECT target to mangle. That's *half* the battle. The other half is explaining why I should move from a perfectly functional setup that uses the filter table. What gains do I get from doing so? What isn't working that I don't know about? etc? In other words - why do I want to move from filter to mangle? pgpr5qkpwXrsl.pgp Description: PGP signature
[patch 2.6.23-git] toplevel Makefile/depmod bugfix
This removes a BASH syntax error (seen building on Ubuntu Feisty). Signed-off-by: David Brownell <[EMAIL PROTECTED]> --- g26.orig/Makefile 2007-10-19 21:29:43.0 -0700 +++ g26/Makefile2007-10-19 18:35:32.0 -0700 @@ -1507,7 +1507,7 @@ quiet_cmd_rmfiles = $(if $(wildcard $(rm # and we build for the host arch quiet_cmd_depmod = DEPMOD $(KERNELRELEASE) cmd_depmod = \ - if [ -r System.map -a -x $(DEPMOD) -a "$(SUBARCH)" == "$(ARCH)" ]; then \ + if [ -r System.map -a -x $(DEPMOD) -a "$(SUBARCH)" = "$(ARCH)" ]; then \ $(DEPMOD) -ae -F System.map \ $(if $(strip $(INSTALL_MOD_PATH)), -b $(INSTALL_MOD_PATH) -r) \ $(KERNELRELEASE); \ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synchronize_irq needs a barrier
On Saturday 20 October 2007 05:56:01 Benjamin Herrenschmidt wrote: > > > I have read this thread and I concluded few things: > > > > 1) It is impossible to know that the card won't send more interrupts: > > Even if I do a read from the device, the IRQ can be pending in the bus/APIC > > It is even possible (and likely) that the IRQ line will be shared, thus the > > handler can be called by non-relevant device. > > > > 2) the synchronize_irq(); in .suspend is useless: > > an IRQ can happen immediately after this synchronize_irq(); > > and interrupt even the .suspend() > > (At least theoretically) > > It's not totally useless not. It guarantees that by the time your > are out of your suspend(), a simultaneous instance of the IRQ handler > is either finished, or it (or any subsequent occurence) have seen > your insuspend flag set to 1. > > > Thus I now understand that .suspend() should do: > > > > saa_writel(SAA7134_IRQ1, 0); > > saa_writel(SAA7134_IRQ2, 0); > > saa_writel(SAA7134_MAIN_CTRL, 0); > > > > dev->insuspend = 1; > > smp_wmb(); > > > > /* at that point the _request to disable card's IRQs was issued, we > > don't know > >that there will be no irqs anymore. > >the smp_mb(); guaranties that the IRQ handler will bail out in that > > case. */ > > > > /* ...*/ > > > > pci_save_state(pci_dev); > > pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state)); > > return 0; > > The above doesn't handle the case where the IRQ handle just passed the > if (insuspend) test. You may end up calling pci_set_power_state() while > in the middle of some further HW accesses in the handler. > > You still need synchronize_irq() for that reason. Or use a spinlock. > > > and the interrupt handler: > > > > smp_rmb(); > > if (dev->insuspend) > > goto out; > > > > Am I right? > > Not quite :-) > > Also not that the work we are doing with synchronize_irq, if it gets > merged, renders it unnecessary for you to add those two memory barriers, > synchronize_irq will pretty much do the ordering for you. > > Cheers, > Ben. > > Fine, I Agree, and this is why I used it in first place, I just forgot. To wait for already running IRQ handler, that tested the dev->insuspend. (And I assumed that interrupts are disabled on the cpu that runs .suspend, but I know now that this isn't true.) Besides that can I ask few more .suspend/resume questions: 1) some drivers use pci_disable_device(), and pci_enable_device(). should I use it too? 2) I accidentally did this: pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state)); pci_save_state(pci_dev); I somehow thought that this is correct, that I should save the pci config state after the power-down, but now I know that it isn't correct. I now need to send a patch for dmfe.c network driver that has the same commands written by me. (but it works perfectly anyway) Is it possible to access pci configuration space in D3? And lastly speaking of network drivers, one issue came to my mind: most network drivars has a packet queue and in case of dmfe it is located in main memory, and card does dma from it. in .suspend I ignore that some packets may be in that queue, and I want to ask, whenever there are better ways to do that. this is my dmfe .suspend routine. /* Disable upper layer interface */ netif_device_detach(dev); /* Disable Tx/Rx */ db->cr6_data &= ~(CR6_RXSC | CR6_TXSC); update_cr6(db->cr6_data, dev->base_addr); /* Disable Interrupt */ outl(0, dev->base_addr + DCR7); outl(inl (dev->base_addr + DCR5), dev->base_addr + DCR5); /* Fre RX buffers */ dmfe_free_rxbuffer(db); /* Enable WOL */ pci_read_config_dword(pci_dev, 0x40, &tmp); tmp &= ~(DMFE_WOL_LINKCHANGE|DMFE_WOL_MAGICPACKET); if (db->wol_mode & WAKE_PHY) tmp |= DMFE_WOL_LINKCHANGE; if (db->wol_mode & WAKE_MAGIC) tmp |= DMFE_WOL_MAGICPACKET; pci_write_config_dword(pci_dev, 0x40, tmp); pci_enable_wake(pci_dev, PCI_D3hot, 1); pci_enable_wake(pci_dev, PCI_D3cold, 1); /* Power down device*/ pci_set_power_state(pci_dev, pci_choose_state (pci_dev,state)); pci_save_state(pci_dev); I guess, everybody makes mistakes... :-) Other network drivers has a bit more complicated .suspend/.resume routines, but I didn't see a driver waiting for output queue to finish Best regards, Maxim Levitsky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
On Fri, 19 Oct 2007, David Brownell wrote: > > My (quick, meaning that I may have missed something) testing > > indicates that the problem is in the patches attached. > > Yes, reverting this seems to resolve the problem: > > > a5bf3d891a6a0fb5aa122792d965e3774108b923 > > > > Change kconfig behavior so that mixing bool and tristate config settings in > > a choice is possible and has the desired effect of offering just the > > tristate options individually if the choice gets set to M, and a normal > > boolean selection if the choice gets set to Y. > > Reverting this patch also fixes a second problem that I didn't > mention: various dependent options couldn't be enabled. > > Again in drivers/usb/gadget/Kconfig, examples include the > ability to configure the Ethernet gadget to act as an RNDIS > peripheral; or enabling Mass Storage gadget debug options. > > > Good sleuthing, and thanks! > > Now we just need to see that patch reverted before RC1... I don't > know how Linus deals with all his LKML mail, so I cc'd him in > the hope that direct messages get through a bit faster. Ok, I'll revert it, but wanted to make sure that the parties that pushed the change are aware of this. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
> My (quick, meaning that I may have missed something) testing > indicates that the problem is in the patches attached. Yes, reverting this seems to resolve the problem: > a5bf3d891a6a0fb5aa122792d965e3774108b923 > > Change kconfig behavior so that mixing bool and tristate config settings in > a choice is possible and has the desired effect of offering just the > tristate options individually if the choice gets set to M, and a normal > boolean selection if the choice gets set to Y. Reverting this patch also fixes a second problem that I didn't mention: various dependent options couldn't be enabled. Again in drivers/usb/gadget/Kconfig, examples include the ability to configure the Ethernet gadget to act as an RNDIS peripheral; or enabling Mass Storage gadget debug options. Good sleuthing, and thanks! Now we just need to see that patch reverted before RC1... I don't know how Linus deals with all his LKML mail, so I cc'd him in the hope that direct messages get through a bit faster. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synchronize_irq needs a barrier
> > - even when you ignore the interrupt (because the driver doesn't care,
> >it's suspending), you need to make sure the hardware gets shut up by
> >reading (or writing) the proper interrupt status register.
> >
> >Otherwise, with a level interrupt, the interrupt will continue to be
> >held active ("screaming") and the CPU will get interrupted over and
> >over again, until the irq subsystem will just turn the irq off
> >entirely.
>
> His suspend routine wrote to the IRQ mask (or equivalent) register in
> his code example, thus the HW should shut up eventually, thus that isn't
> strictly necessary, the IRQ in that case is just a "short
> interrupt" (noticed by the PIC and delivered but possibly not asserted
> anymore at this stage or about to go down).
In fact, he -must not- ack it. Because is the HW is really down (in D3),
got knows what accessing the ACK register will do. I can give you
ideas... from nothing on most x86 desktops to machine checks on most
powerpc machines, though I could imagine some cards bad enough to lock
your bus up if you try to access a register while they are in D3 (I've
seen some of those critters and it seems not all bridges timeout on
cards that just keep sending retries).
Cheers,
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synchronize_irq needs a barrier
> > - even when you ignore the interrupt (because the driver doesn't care, > >it's suspending), you need to make sure the hardware gets shut up by > >reading (or writing) the proper interrupt status register. > I agree, but while device is powered off, its registers can't be accessed > Thus, if I ack the IRQ every time the handler is called, I will access the > powered off device (this is probably won't hurt a lot, but a bit incorrectly) It will actually crash your machine on some platforms. So no, best is to -not- ack. The masking is enough, the IRQ will go down eventually. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synchronize_irq needs a barrier
On Fri, 2007-10-19 at 19:25 -0700, Linus Torvalds wrote:
>
> On Sat, 20 Oct 2007, Maxim Levitsky wrote:
> >
> > and the interrupt handler:
> >
> > smp_rmb();
> > if (dev->insuspend)
> > goto out;
>
> Something like that can work, yes. However, you need to make sure that:
>
> - even when you ignore the interrupt (because the driver doesn't care,
>it's suspending), you need to make sure the hardware gets shut up by
>reading (or writing) the proper interrupt status register.
>
>Otherwise, with a level interrupt, the interrupt will continue to be
>held active ("screaming") and the CPU will get interrupted over and
>over again, until the irq subsystem will just turn the irq off
>entirely.
His suspend routine wrote to the IRQ mask (or equivalent) register in
his code example, thus the HW should shut up eventually, thus that isn't
strictly necessary, the IRQ in that case is just a "short
interrupt" (noticed by the PIC and delivered but possibly not asserted
anymore at this stage or about to go down).
We have many scenario generating such short interrupts (pretty much any
time we use interrupt disable/enable on the chip, for example it's
common with NAPI).
This is one of the reasons why we used to have a "timebomb" causing an
IRQ to erroneously get disabled by the IRQ core assuming the IRQ was
stuck, just because we accumulated too many short interrupts on that
line. A recent patch by Alan fixed that to use some more sensible
algorithm checking the time since the last spurrious interrupt, though I
suspect he's being too optimistic on his timeout value and some
scenario, such as NAPI with just the wrong packet rate, can still
trigger the bug. I need to find a piece of HW slow enough in
de-asserting the IRQ to try to make a repro-case one of these days.
> - when you resume, make sure that you get the engine going again, with
>the understanding that some interrupts may have gotten ignored.
And you forgot that he still needs synchronize_irq(), or his IRQ handler
might well be in the middle of doing something on another CPU, past the
point where it tested "insuspend", which will do no good when a
simultaneous pci_set_power_state() puts the chip into D3. On some
machines, this will machine check. Either that or he needs a spinlock in
his IRQ handler that he also takes around the code that sets insuspend.
> Also, in general, these kinds of things shouldn't always even be
> neicessary. If you use the suspend_late()/resume_early() hooks, those will
> be called with interrupts off, and while they can be harder to debug (and
> may be worth avoiding for non-critical drivers), they do allow for simpler
> models partly exactly because they don't need to worry about interrupts
> etc.
Yes, this is a easier way to deal with devices that are on a directly
mapped bus (path to them isn't gone by the time you hit suspend_late)
and don't need to do fancy things involing waiting for a queue to drain
using interrupts etc... (at one stage of HW complexity, having to
re-implement polled versions of everything is just not worth the
benefit). In general, suspend_late should cover the need of most PCI
devices I suppose.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] NFS client fixes for 2.6.23++
In message <[EMAIL PROTECTED]>, Linus Torvalds writes: > > > On Fri, 19 Oct 2007, Erez Zadok wrote: > > > > i386 > > Hmm. Doesn't happen here, not on x86-64 nor i386. > > Probably some subtle config issue as usual, where some configuration > doesn't include indirectly. > > But I'll add the direct includes of and . > > Linus FWIW, here's my .config. Erez. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23 # Fri Oct 19 16:51:35 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_DMIID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set
Re: [PATCH] synchronize_irq needs a barrier
> I have read this thread and I concluded few things: > > 1) It is impossible to know that the card won't send more interrupts: > Even if I do a read from the device, the IRQ can be pending in the bus/APIC > It is even possible (and likely) that the IRQ line will be shared, thus the > handler can be called by non-relevant device. > > 2) the synchronize_irq(); in .suspend is useless: > an IRQ can happen immediately after this synchronize_irq(); > and interrupt even the .suspend() > (At least theoretically) It's not totally useless not. It guarantees that by the time your are out of your suspend(), a simultaneous instance of the IRQ handler is either finished, or it (or any subsequent occurence) have seen your insuspend flag set to 1. > Thus I now understand that .suspend() should do: > > saa_writel(SAA7134_IRQ1, 0); > saa_writel(SAA7134_IRQ2, 0); > saa_writel(SAA7134_MAIN_CTRL, 0); > > dev->insuspend = 1; > smp_wmb(); > > /* at that point the _request to disable card's IRQs was issued, we > don't know > that there will be no irqs anymore. > the smp_mb(); guaranties that the IRQ handler will bail out in that > case. */ > > /* ...*/ > > pci_save_state(pci_dev); > pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state)); > return 0; The above doesn't handle the case where the IRQ handle just passed the if (insuspend) test. You may end up calling pci_set_power_state() while in the middle of some further HW accesses in the handler. You still need synchronize_irq() for that reason. Or use a spinlock. > and the interrupt handler: > > smp_rmb(); > if (dev->insuspend) > goto out; > > Am I right? Not quite :-) Also not that the work we are doing with synchronize_irq, if it gets merged, renders it unnecessary for you to add those two memory barriers, synchronize_irq will pretty much do the ordering for you. Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] iptables: mangle table obsoletes filter table
Bill Davidsen wrote: > Bill Davidsen wrote: > If not, then shouldn't the filter table be obsoleted to avoid > confusion? > >>> > >>> That would probably confuse people. Just don't use it if you don't > >>> need to. > > > > That is a most practical suggestion. > > > >> The problem is that people think they are safe with the filter table, > >> when in fact they need the prerouting chain to seal things. Right now > >> this is only possible in the mangle table. > > > > I'm not sure what you think is unsafe about using the filter table, and > > the order of evaluation issues certainly seem to suggest that some > > actions would take a major rethink at least. Perhaps you could avoid > > breaking all of the setups which currently work, rather than force > > everyone to do things differently because you feel that your way is > > better. > > It was my intention to suggest that unintentional breakage of existing > setups should be avoided, not that removing the filter table was some > evil plot. ;-) > On rereading my original post I failed to make that clear, please take > it as intended. Sure, the idea was to mark the filter table obsolete as to make people start using the mangle table to do their filtering for new setups. The filter table would then still be available for legacy/special setups. But this would only be possible if we at least ported the REJECT target to mangle. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synchronize_irq needs a barrier
On Sat, Oct 20, 2007 at 02:02:42AM +, Maxim Levitsky wrote:
>
> Thus I now understand that .suspend() should do:
>
> saa_writel(SAA7134_IRQ1, 0);
> saa_writel(SAA7134_IRQ2, 0);
> saa_writel(SAA7134_MAIN_CTRL, 0);
>
> dev->insuspend = 1;
> smp_wmb();
If we patch synchronize_irq() as discussed here then you can
use it in place of smp_wmb() and remove the smp_rmb from the
interrupt handler (the latter is the path that matters).
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote:
> On Fri, 19 Oct 2007 19:01:09 -0700 Randy Dunlap wrote:
>
> > >>> I noticed a regression, visible in the drivers/usb/gadget Kconfig;
> > >>> it seems to be quite recent.
> > >>>
> > >>> ...
> > >> Hm, it does look very odd. It looks like it has something to
> > >> do with working differently for some reason.
> > >>
> > >> In xconfig, I set all of the View Options and when I click on one
> > >> of the periph. controllers, it says
> > >>
> > >> depends on =y && PCI
> > >
> > > That's what I saw too. Looked dubious ...
> > >
> > >
> > >> but if I back up to -git7, it says
> > >>
> > >> depends on && PCI
> > >
> > > And that git7 thing doesn't look _quite_ so odd. Did git7 actually
> > > let you configure a modular GOKU (for example), i.e. work correctly?
> >
> > Yes, -git9 does.
> >
> > Looks to me like it broke on -git10. -git9 is OK.
> >
> > >> I'll keep looking.
> > >
> > > Thanks. Kconfig is one of the areas I prefer to let others
> > > be the experts. :)
>
> [hm, odd email problems, changing SMTP]
>
> David,
>
> Just a small update.
>
> If I set USB gadget support to Y instead of M and peripheral
> controller menu item to Y instead of M, then I can select any of the
> 4 periph. controllers that are available to me. (on -git14)
> I don't know why it's like this though.
David,
My (quick, meaning that I may have missed something) testing
indicates that the problem is in the patches attached.
Can you revert them and test that?
>From git:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a5bf3d891a6a0fb5aa122792d965e3774108b923
Change kconfig behavior so that mixing bool and tristate config settings in
a choice is possible and has the desired effect of offering just the
tristate options individually if the choice gets set to M, and a normal
boolean selection if the choice gets set to Y.
Odd, I don't recall seeing this patch...
---
~Randy
diff -u b/Makefile b/Makefile
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -235,16 +235,23 @@ void menu_finalize(struct menu *parent)
sym = parent->sym;
if (parent->list) {
if (sym && sym_is_choice(sym)) {
- /* find the first choice value and find out choice type */
+ /* find out choice type */
+ enum symbol_type type = S_UNKNOWN;
+
for (menu = parent->list; menu; menu = menu->next) {
-if (menu->sym) {
- current_entry = parent;
- menu_set_type(menu->sym->type);
- current_entry = menu;
- menu_set_type(sym->type);
- break;
+if (menu->sym && menu->sym->type != S_UNKNOWN) {
+ if (type == S_UNKNOWN)
+ type = menu->sym->type;
+ if (type != S_BOOLEAN)
+ break;
+ if (menu->sym->type == S_TRISTATE) {
+ type = S_TRISTATE;
+ break;
+ }
}
}
+ current_entry = parent;
+ menu_set_type(type);
parentdep = expr_alloc_symbol(sym);
} else if (parent->prompt)
parentdep = parent->prompt->visible.expr;
@@ -253,7 +260,16 @@ void menu_finalize(struct menu *parent)
for (menu = parent->list; menu; menu = menu->next) {
basedep = expr_transform(menu->dep);
- basedep = expr_alloc_and(expr_copy(parentdep), basedep);
+ dep = parentdep;
+ if (sym && sym_is_choice(sym) && menu->sym) {
+enum symbol_type type = menu->sym->type;
+
+if (type == S_UNKNOWN)
+ type = sym->type;
+ if (type != S_TRISTATE)
+ dep = expr_alloc_comp(E_EQUAL, sym, &symbol_yes);
+ }
+ basedep = expr_alloc_and(expr_copy(dep), basedep);
basedep = expr_eliminate_dups(basedep);
menu->dep = basedep;
if (menu->sym)
@@ -326,7 +342,8 @@ void menu_finalize(struct menu *parent)
"values not supported");
}
current_entry = menu;
- menu_set_type(sym->type);
+ if (menu->sym->type == S_UNKNOWN)
+menu_set_type(sym->type);
menu_add_symbol(P_CHOICE, sym, NULL);
prop = sym_get_choice_prop(sym);
for (ep = &prop->expr; *ep; ep = &(*ep)->left.expr)
--- a/scripts/kconfig/util.c
+++ b/scripts/kconfig/util.c
@@ -84,12 +84,15 @@ void str_free(struct gstr *gs)
/* Append to growable string */
void str_append(struct gstr *gs, const char *s)
{
- size_t l = strlen(gs->s) + strlen(s) + 1;
- if (l > gs->len) {
- gs->s = realloc(gs->s, l);
- gs->len = l;
+ size_t l;
+ if (s) {
+ l = strlen(gs->s) + strlen(s) + 1;
+ if (l > gs->len) {
+ gs->s = realloc(gs->s, l);
+ gs->len = l;
+ }
+ strcat(gs->s, s);
}
- strcat(gs->s, s);
}
/* Append printf formatted string to growable string */
Re: [PATCH] synchronize_irq needs a barrier
On Saturday 20 October 2007 04:25:34 Linus Torvalds wrote:
>
> On Sat, 20 Oct 2007, Maxim Levitsky wrote:
> >
> > and the interrupt handler:
> >
> > smp_rmb();
> > if (dev->insuspend)
> > goto out;
>
> Something like that can work, yes. However, you need to make sure that:
>
> - even when you ignore the interrupt (because the driver doesn't care,
>it's suspending), you need to make sure the hardware gets shut up by
>reading (or writing) the proper interrupt status register.
I agree, but while device is powered off, its registers can't be accessed
Thus, if I ack the IRQ every time the handler is called, I will access the
powered off device (this is probably won't hurt a lot, but a bit incorrectly)
>
>Otherwise, with a level interrupt, the interrupt will continue to be
>held active ("screaming") and the CPU will get interrupted over and
>over again, until the irq subsystem will just turn the irq off
>entirely.
>
> - when you resume, make sure that you get the engine going again, with
>the understanding that some interrupts may have gotten ignored.
Here it isn't a problem, this is a video capture card, and I suspend it by just
stopping dma
on all active buffers even if in the middle of capture, and I send those
buffers to card again
to fill them from the beginning during the resume.
>
> Also, in general, these kinds of things shouldn't always even be
> neicessary. If you use the suspend_late()/resume_early() hooks, those will
> be called with interrupts off, and while they can be harder to debug (and
> may be worth avoiding for non-critical drivers), they do allow for simpler
> models partly exactly because they don't need to worry about interrupts
> etc.
Exactly, I am aware of suspend_late , but I don't want to abuse it.
>
> Linus
>
Best regards,
Maxim Levitsky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus to receive the following updates: drivers/net/Kconfig | 41 - drivers/net/dm9000.c|6 ++-- drivers/net/phy/mdio-bitbang.c |2 + drivers/net/tsi108_eth.c|2 +- drivers/net/tulip/Kconfig | 14 +++ drivers/net/wireless/b43/main.c |5 +-- drivers/net/wireless/b43legacy/main.c |2 +- drivers/net/wireless/ipw2100.c | 39 drivers/net/wireless/ipw2100.h |4 ++ drivers/net/wireless/iwlwifi/iwl-3945-rs.c |3 -- drivers/net/wireless/iwlwifi/iwl-3945.c |1 - drivers/net/wireless/iwlwifi/iwl-4965-rs.c | 13 --- drivers/net/wireless/iwlwifi/iwl-4965.c |2 - drivers/net/wireless/iwlwifi/iwl3945-base.c | 44 +- drivers/net/wireless/iwlwifi/iwl4965-base.c | 52 +++--- drivers/net/wireless/iwlwifi/iwlwifi.h |7 +--- drivers/net/wireless/p54common.c|2 +- drivers/net/wireless/rt2x00/rt2x00dev.c |2 +- drivers/net/wireless/rt2x00/rt73usb.c |1 + drivers/net/wireless/rtl8187_dev.c | 35 -- drivers/net/wireless/zd1201.c |4 +- drivers/net/wireless/zd1211rw/zd_usb.c |7 +++- drivers/s390/net/qeth_main.c|3 +- 23 files changed, 158 insertions(+), 133 deletions(-) Adrian Bunk (1): iwl4965-base.c: fix off-by-one errors Dan Williams (1): ipw2100: send WEXT scan events Holger Schurig (1): janitorial: fix all double includes in drivers/net/wireless Ivo van Doorn (1): rt2x00: Add new rt73usb USB ID John W. Linville (1): zd1201: avoid null ptr access of skb->dev Larry Finger (1): b43legacy: Fix potential return of uninitialized variable Marc Pignat (1): zd1211rw, fix oops when ejecting install media Mattias Nissler (1): rt2x00: Fix residual check in PLCP calculations. Michael Buesch (1): b43: Make b43_stop() static Michael Wu (3): rtl8187: Fix more frag bit checking, rts duration calc rtl8187: remove NICMAC setting in configure_filters callback p54: Make filter configuration atomic Mike Rapoport (1): DM9000 initialization fix Olof Johansson (1): Fix build break in tsi108.c Randy Dunlap (3): phy/bitbang: missing MODULE_LICENSE NAPI: kconfig prompt and deleted doc file ir-functions.c:(.text+0xbce18): undefined reference to `input_event' Ron Rindjunsky (1): iwlwifi: set correct base rate for A band in rs_dbgfs_set_mcs Tomas Winkler (1): iwlwifi: Fix rate setting in probe request for HW sacn Ursula Braun (1): qeth: remove header_ops bug WANG Cong (1): drivers/net/wireless/b43/main.c: fix an uninitialized variable diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 83d52c8..2cafa5c 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1293,9 +1293,6 @@ config PCNET32_NAPI deployed on potentially unfriendly networks (e.g. in a firewall), then say Y here. - See for more - information. - If in doubt, say N. config AMD8111_ETH @@ -1313,7 +1310,7 @@ config AMD8111_ETH will be called amd8111e. config AMD8111E_NAPI - bool "Enable NAPI support" + bool "Use RX polling (NAPI)" depends on AMD8111_ETH help NAPI is a new driver API designed to reduce CPU and interrupt load @@ -1324,9 +1321,6 @@ config AMD8111E_NAPI deployed on potentially unfriendly networks (e.g. in a firewall), then say Y here. - See for more - information. - If in doubt, say N. config ADAPTEC_STARFIRE @@ -1355,9 +1349,6 @@ config ADAPTEC_STARFIRE_NAPI deployed on potentially unfriendly networks (e.g. in a firewall), then say Y here. - See for more - information. - If in doubt, say N. config AC3200 @@ -1431,7 +1422,7 @@ config FORCEDETH called forcedeth. config FORCEDETH_NAPI - bool "Use Rx and Tx Polling (NAPI) (EXPERIMENTAL)" + bool "Use Rx Polling (NAPI) (EXPERIMENTAL)" depends on FORCEDETH && EXPERIMENTAL help NAPI is a new driver API designed to reduce CPU and interrupt load @@ -1442,9 +1433,6 @@ config FORCEDETH_NAPI deployed on potentially unfriendly networks (e.g. in a firewall), then say Y here. - See for more - information. - If in doubt, say N. config CS89x0 @@ -1756,9 +1744,6 @@ config VIA_RHINE_NAPI deployed on potentially unfriendly networks (e.g. in a firewall), then say Y here. - See for more - information. - config LAN_SAA9730 bool
[git patches] libata fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/libata-core.c |2 +-
drivers/ata/pata_cs5536.c |4 ++--
drivers/ata/sata_sis.c| 15 +--
3 files changed, 12 insertions(+), 9 deletions(-)
Bartlomiej Zolnierkiewicz (1):
pata_cs5536: MWDMA fix
Jeff Garzik (1):
[libata] sata_sis: use correct S/G table size
Randy Dunlap (1):
libata: fix kernel-doc param name
Tejun Heo (1):
sata_sis: fix SCR read breakage
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index bbaa545..629eadb 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1392,7 +1392,7 @@ static void ata_qc_complete_internal(struct
ata_queued_cmd *qc)
* @tf: Taskfile registers for the command and the result
* @cdb: CDB for packet command
* @dma_dir: Data tranfer direction of the command
- * @sg: sg list for the data buffer of the command
+ * @sgl: sg list for the data buffer of the command
* @n_elem: Number of sg entries
* @timeout: Timeout in msecs (0 for default)
*
diff --git a/drivers/ata/pata_cs5536.c b/drivers/ata/pata_cs5536.c
index 53070f6..d753e56 100644
--- a/drivers/ata/pata_cs5536.c
+++ b/drivers/ata/pata_cs5536.c
@@ -40,7 +40,7 @@
#include
#define DRV_NAME "pata_cs5536"
-#define DRV_VERSION"0.0.5"
+#define DRV_VERSION"0.0.6"
enum {
CFG = 0,
@@ -214,7 +214,7 @@ static void cs5536_set_dmamode(struct ata_port *ap, struct
ata_device *adev)
cs5536_read(pdev, DTC, &dtc);
dtc &= ~(IDE_DRV_MASK << dshift);
- dtc |= mwdma_timings[mode] << dshift;
+ dtc |= mwdma_timings[mode - XFER_MW_DMA_0] << dshift;
cs5536_write(pdev, DTC, dtc);
}
diff --git a/drivers/ata/sata_sis.c b/drivers/ata/sata_sis.c
index 8d98a9f..f147dc7 100644
--- a/drivers/ata/sata_sis.c
+++ b/drivers/ata/sata_sis.c
@@ -92,7 +92,7 @@ static struct scsi_host_template sis_sht = {
.queuecommand = ata_scsi_queuecmd,
.can_queue = ATA_DEF_QUEUE,
.this_id= ATA_SHT_THIS_ID,
- .sg_tablesize = ATA_MAX_PRD,
+ .sg_tablesize = LIBATA_MAX_PRD,
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
.use_clustering = ATA_SHT_USE_CLUSTERING,
@@ -166,11 +166,11 @@ static unsigned int get_scr_cfg_addr(struct ata_port *ap,
unsigned int sc_reg)
return addr;
}
-static u32 sis_scr_cfg_read (struct ata_port *ap, unsigned int sc_reg)
+static u32 sis_scr_cfg_read (struct ata_port *ap, unsigned int sc_reg, u32
*val)
{
struct pci_dev *pdev = to_pci_dev(ap->host->dev);
unsigned int cfg_addr = get_scr_cfg_addr(ap, sc_reg);
- u32 val, val2 = 0;
+ u32 val2 = 0;
u8 pmr;
if (sc_reg == SCR_ERROR) /* doesn't exist in PCI cfg space */
@@ -178,13 +178,16 @@ static u32 sis_scr_cfg_read (struct ata_port *ap,
unsigned int sc_reg)
pci_read_config_byte(pdev, SIS_PMR, &pmr);
- pci_read_config_dword(pdev, cfg_addr, &val);
+ pci_read_config_dword(pdev, cfg_addr, val);
if ((pdev->device == 0x0182) || (pdev->device == 0x0183) ||
(pdev->device == 0x1182) || (pmr & SIS_PMR_COMBINED))
pci_read_config_dword(pdev, cfg_addr+0x10, &val2);
- return (val|val2) & 0xfffb; /* avoid problems with powerdowned
ports */
+ *val |= val2;
+ *val &= 0xfffb; /* avoid problems with powerdowned ports */
+
+ return 0;
}
static void sis_scr_cfg_write (struct ata_port *ap, unsigned int sc_reg, u32
val)
@@ -214,7 +217,7 @@ static int sis_scr_read(struct ata_port *ap, unsigned int
sc_reg, u32 *val)
return -EINVAL;
if (ap->flags & SIS_FLAG_CFGSCR)
- return sis_scr_cfg_read(ap, sc_reg);
+ return sis_scr_cfg_read(ap, sc_reg, val);
pci_read_config_byte(pdev, SIS_PMR, &pmr);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] qeth: remove header_ops bug
applied - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] NFS client fixes for 2.6.23++
On Fri, 19 Oct 2007, Erez Zadok wrote: > > i386 Hmm. Doesn't happen here, not on x86-64 nor i386. Probably some subtle config issue as usual, where some configuration doesn't include indirectly. But I'll add the direct includes of and . Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patch] libata build fix
Bartlomiej Zolnierkiewicz wrote: On Tuesday 16 October 2007, Jeff Garzik wrote: Jeff Garzik (1): [libata] pata_cs5536: new API build fix We probably need also this one for pata_cs5536: [PATCH] pata_cs5536: MWDMA fix * Fix out-of-bound array access for MWDMA modes. * Bump driver version. Cc: "Martin K. Petersen" <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- drivers/ata/pata_cs5536.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
On Fri, 19 Oct 2007 19:01:09 -0700 Randy Dunlap wrote: > >>> I noticed a regression, visible in the drivers/usb/gadget Kconfig; > >>> it seems to be quite recent. > >>> > >>> ... > >> Hm, it does look very odd. It looks like it has something to > >> do with working differently for some reason. > >> > >> In xconfig, I set all of the View Options and when I click on one > >> of the periph. controllers, it says > >> > >>depends on =y && PCI > > > > That's what I saw too. Looked dubious ... > > > > > >> but if I back up to -git7, it says > >> > >>depends on && PCI > > > > And that git7 thing doesn't look _quite_ so odd. Did git7 actually > > let you configure a modular GOKU (for example), i.e. work correctly? > > Yes, -git9 does. > > Looks to me like it broke on -git10. -git9 is OK. > > >> I'll keep looking. > > > > Thanks. Kconfig is one of the areas I prefer to let others > > be the experts. :) [hm, odd email problems, changing SMTP] David, Just a small update. If I set USB gadget support to Y instead of M and peripheral controller menu item to Y instead of M, then I can select any of the 4 periph. controllers that are available to me. (on -git14) I don't know why it's like this though. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] full suspend/resume support for i915 DRM driver
On Thursday, October 18, 2007 2:01 pm Jesse Barnes wrote:
> We seem to see a lot of bug reports along the lines of, "my machine
> resumes but I can't see X" or, "I can see X but only with a bright
> flashlight", etc. These sorts of problems are due to the fact that
> the X server isn't designed to do full state save/restore, and none
> of the available kernel drivers do it on its behalf.
>
> Since intelfb and the rest of the Intel drivers are fairly
> incompatible, this patch makes the DRM bind to the PCI device so it
> can register real suspend/resume handlers. Those handlers take care
> of saving and restoring enough state for X to come back reliably on
> at least one of my problematic test machines, but text mode still has
> trouble (still debugging VGA state save/restore, including trying to
> save/restore actual VRAM contents for possible hibernate support).
>
> How does this approach look? Is a new DRM driver flag a good thing
> for similar situations with other drivers? Thoughts?
Here's an updated one that actually works fully on my 965 based test
platform. It should also work on other 9xx platforms, but note that it
lacks TV out and SDVO state save/restore, so I don't expect those to
work. I also haven't tested on 8xx platforms, but a similar approach
should work, so I'd welcome additions to support those chipsets.
Dave can you take a look at the new flag and also see what you think
about supporting suspend/resume in the event X hasn't started yet?
There's some #if 0'd code to support that case, but I haven't tested
it.
Thanks,
Jesse
diff --git a/linux-core/Kconfig b/linux-core/Kconfig
index 2d02c76..5e73fc7 100644
--- a/linux-core/Kconfig
+++ b/linux-core/Kconfig
@@ -50,7 +50,7 @@ config DRM_I810
choice
prompt "Intel 830M, 845G, 852GM, 855GM, 865G"
- depends on DRM && AGP && AGP_INTEL
+ depends on DRM && AGP && AGP_INTEL && !FB_INTEL
optional
config DRM_I915
@@ -60,6 +60,9 @@ config DRM_I915
852GM, 855GM, 865G, 915G, 915GM, 945G, 945GM and 965G integrated
graphics. If M is selected, the module will be called i915.
AGP support is required for this driver to work.
+
+ Note that this driver is incompatible with the Intel framebuffer
+ driver.
endchoice
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
index f8ca3f4..36ce266 100644
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -106,6 +106,7 @@ struct drm_file;
#define DRIVER_DMA_QUEUE 0x200
#define DRIVER_FB_DMA 0x400
#define DRIVER_IRQ_VBL20x800
+#define DRIVER_BIND_PCI0x1000
/[EMAIL PROTECTED]/
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
index a09fa96..4d11707 100644
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -340,9 +340,10 @@ int drm_init(struct drm_driver *driver,
}
}
- if (!drm_fb_loaded)
+ if (!drm_fb_loaded || (driver->driver_features & DRIVER_BIND_PCI)) {
+ printk(KERN_ERR "DRM binding to PCI device\n");
return pci_register_driver(&driver->pci_driver);
- else {
+ } else {
for (i = 0; pciidlist[i].vendor != 0; i++) {
pid = &pciidlist[i];
diff --git a/linux-core/i915_drv.c b/linux-core/i915_drv.c
index e337e1d..809ef0d 100644
--- a/linux-core/i915_drv.c
+++ b/linux-core/i915_drv.c
@@ -69,6 +69,501 @@ static struct drm_bo_driver i915_bo_driver = {
};
#endif
+enum pipe {
+PIPE_A = 0,
+PIPE_B,
+};
+
+static bool i915_pipe_enabled(struct drm_device *dev, enum pipe pipe)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (pipe == PIPE_A)
+ return (I915_READ(DPLL_A) & DPLL_VCO_ENABLE);
+ else
+ return (I915_READ(DPLL_B) & DPLL_VCO_ENABLE);
+}
+
+static void i915_save_palette(struct drm_device *dev, enum pipe pipe)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ unsigned long reg = pipe == PIPE_A ? PALETTE_A : PALETTE_B;
+ u32 *array;
+ int i;
+
+ if (!i915_pipe_enabled(dev, pipe))
+ return;
+
+ if (pipe == PIPE_A)
+ array = dev_priv->savePaletteA;
+ else
+ array = dev_priv->savePaletteB;
+
+ for(i = 0; i < 256; i++)
+ array[i] = I915_READ(reg + (i << 2));
+}
+
+static void i915_restore_palette(struct drm_device *dev, enum pipe pipe)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ unsigned long reg = pipe == PIPE_A ? PALETTE_A : PALETTE_B;
+ u32 *array;
+ int i;
+
+ if (!i915_pipe_enabled(dev, pipe))
+ return;
+
+ if (pipe == PIPE_A)
+ array = dev_priv->savePaletteA;
+ else
+ array = dev_priv->savePaletteB;
+
+ for(i = 0; i < 256; i++)
+ I915_WRITE(reg + (i << 2), array[i]);
+}
+
+static u8 i915_read_indexed(u16 index_port, u16 data_port, u8 reg)
+{
+ outb(reg, index
Re: [PATCH 9/9] RT: Only dirty a cacheline if the priority is actually changing
Gregory Haskins wrote: > We can avoid dirtying a rq related cacheline with a simple check, so why not. > > Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]> > --- > > 0 files changed, 0 insertions(+), 0 deletions(-) I think you wanted a patch here? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] NFS client fixes for 2.6.23++
In message <[EMAIL PROTECTED]>, Linus Torvalds writes: > > > On Fri, 19 Oct 2007, Erez Zadok wrote: > > > > Trond, with Linus's latest tree, you need to #include in > > fs/nfs/unlink.c, else I get: > > > > CC [M] fs/nfs/unlink.o > > fs/nfs/unlink.c: In function 'nfs_dec_sillycount': > > fs/nfs/unlink.c:67: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in > > this function) > ... > > Hmm? Which architecture? i386 Erez. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] NFS client fixes for 2.6.23++
On Fri, 19 Oct 2007, Erez Zadok wrote: > > Trond, with Linus's latest tree, you need to #include in > fs/nfs/unlink.c, else I get: > > CC [M] fs/nfs/unlink.o > fs/nfs/unlink.c: In function 'nfs_dec_sillycount': > fs/nfs/unlink.c:67: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in > this function) ... Hmm? Which architecture? That said, I do think that there is a distinct lack of proper includes in that file. It seems to depend on getting much of the includes indirectly from and friends. And with different architectures having different header files.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nfsv2 ref leak in 2.6.24?
Trond, good news. I was able to narrow down the problem to purely the client-side, probably dcache/readdir related, and I have a shell script that deterministically triggers the problem each time for me (this is a FC6 image under Vmware 6.0.1). Here's a short shell script which reliably triggers the "lost files" problem -- I create a file via nfs2 on the client side, and sometimes it doesn't show up in readdir, but it is there if you stat it directly. BTW, since this is a client-side bug, I also tried your last set of posted client patches for Linus, but it didn't help. Happy hunting. :-) Erez. ## #!/bin/sh dd if=/dev/zero of=/tmp/fs.$$.0 bs=1024k count=1 seek=100 losetup /dev/loop0 /tmp/fs.$$.0 mkfs -t ext2 -q /dev/loop0 mkdir -p /n/export/b0 mount -t ext2 /dev/loop0 /n/export/b0 exportfs -o no_root_squash,rw localhost:/n/export/b0 mkdir -p /n/client/b0 mount -t nfs -o nfsvers=2 localhost:/n/export/b0 /n/client/b0 count=0 while true; do cfile="/n/client/b0/F.$count" if touch $cfile ; then echo $cfile created else echo "touch $cfile failed" exit 1 fi if `ls -1 /n/client/b0 | egrep -q F.$count'$'` ; then : else echo "$cfile doesn't exist (but it should)" ls -l /n/client/b0 ls -l /n/export/b0 stat $cfile exit 1 fi let count=count+1 done ## - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synchronize_irq needs a barrier
On Sat, 20 Oct 2007, Maxim Levitsky wrote:
>
> and the interrupt handler:
>
> smp_rmb();
> if (dev->insuspend)
> goto out;
Something like that can work, yes. However, you need to make sure that:
- even when you ignore the interrupt (because the driver doesn't care,
it's suspending), you need to make sure the hardware gets shut up by
reading (or writing) the proper interrupt status register.
Otherwise, with a level interrupt, the interrupt will continue to be
held active ("screaming") and the CPU will get interrupted over and
over again, until the irq subsystem will just turn the irq off
entirely.
- when you resume, make sure that you get the engine going again, with
the understanding that some interrupts may have gotten ignored.
Also, in general, these kinds of things shouldn't always even be
neicessary. If you use the suspend_late()/resume_early() hooks, those will
be called with interrupts off, and while they can be harder to debug (and
may be worth avoiding for non-critical drivers), they do allow for simpler
models partly exactly because they don't need to worry about interrupts
etc.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] NFS client fixes for 2.6.23++
In message <[EMAIL PROTECTED]>, Trond Myklebust writes: > 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 Trond, with Linus's latest tree, you need to #include in fs/nfs/unlink.c, else I get: CC [M] fs/nfs/unlink.o fs/nfs/unlink.c: In function 'nfs_dec_sillycount': fs/nfs/unlink.c:67: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in this function) fs/nfs/unlink.c:67: error: (Each undeclared identifier is reported only once fs/nfs/unlink.c:67: error: for each function it appears in.) fs/nfs/unlink.c:67: error: 'TASK_INTERRUPTIBLE' undeclared (first use in this function) fs/nfs/unlink.c: In function 'nfs_block_sillyrename': fs/nfs/unlink.c:196: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in this function) fs/nfs/unlink.c:196: error: implicit declaration of function 'schedule' make[2]: *** [fs/nfs/unlink.o] Error 1 make[1]: *** [fs/nfs] Error 2 make: *** [fs] Error 2 Cheers, Erez. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synchronize_irq needs a barrier
On Thursday 18 October 2007 03:25:42 Benjamin Herrenschmidt wrote: > synchronize_irq needs at the very least a compiler barrier and a > read barrier on SMP, but there are enough cases around where a > write barrier is also needed and it's not a hot path so I prefer > using a full smp_mb() here. > > It will degrade to a compiler barrier on !SMP. > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > > Index: linux-work/kernel/irq/manage.c > === > --- linux-work.orig/kernel/irq/manage.c 2007-10-18 11:22:16.0 > +1000 > +++ linux-work/kernel/irq/manage.c2007-10-18 11:22:20.0 +1000 > @@ -33,6 +33,7 @@ void synchronize_irq(unsigned int irq) > if (irq >= NR_IRQS) > return; > > + smp_mb(); > while (desc->status & IRQ_INPROGRESS) > cpu_relax(); > } > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > Hi, I have read this thread and I concluded few things: 1) It is impossible to know that the card won't send more interrupts: Even if I do a read from the device, the IRQ can be pending in the bus/APIC It is even possible (and likely) that the IRQ line will be shared, thus the handler can be called by non-relevant device. 2) the synchronize_irq(); in .suspend is useless: an IRQ can happen immediately after this synchronize_irq(); and interrupt even the .suspend() (At least theoretically) Thus I now understand that .suspend() should do: saa_writel(SAA7134_IRQ1, 0); saa_writel(SAA7134_IRQ2, 0); saa_writel(SAA7134_MAIN_CTRL, 0); dev->insuspend = 1; smp_wmb(); /* at that point the _request to disable card's IRQs was issued, we don't know that there will be no irqs anymore. the smp_mb(); guaranties that the IRQ handler will bail out in that case. */ /* ...*/ pci_save_state(pci_dev); pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state)); return 0; and the interrupt handler: smp_rmb(); if (dev->insuspend) goto out; Am I right? Best regards, Maxim Levitsky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
David Brownell wrote: (Originally posted to kbuild-devel per MAINTAINERS, but that post was rejected since that is -- undocumented, sigh -- a members-only list.) That mailing list is no longer used. Today's git pull for kbuild included this change: KCONFIG P: Roman Zippel M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] S: Maintained I hadn't pulled that one yet... ;) I noticed a regression, visible in the drivers/usb/gadget Kconfig; it seems to be quite recent. ... Hm, it does look very odd. It looks like it has something to do with working differently for some reason. In xconfig, I set all of the View Options and when I click on one of the periph. controllers, it says depends on =y && PCI That's what I saw too. Looked dubious ... but if I back up to -git7, it says depends on && PCI And that git7 thing doesn't look _quite_ so odd. Did git7 actually let you configure a modular GOKU (for example), i.e. work correctly? Yes, -git9 does. Looks to me like it broke on -git10. -git9 is OK. I'll keep looking. Thanks. Kconfig is one of the areas I prefer to let others be the experts. :) -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
> > (Originally posted to kbuild-devel per MAINTAINERS, but > > that post was rejected since that is -- undocumented, > > sigh -- a members-only list.) > > That mailing list is no longer used. Today's git pull for kbuild > included this change: > > KCONFIG > P: Roman Zippel > M: [EMAIL PROTECTED] > -L: [EMAIL PROTECTED] > +L: [EMAIL PROTECTED] > S: Maintained I hadn't pulled that one yet... ;) > > I noticed a regression, visible in the drivers/usb/gadget Kconfig; > > it seems to be quite recent. > > > > ... > > Hm, it does look very odd. It looks like it has something to > do with working differently for some reason. > > In xconfig, I set all of the View Options and when I click on one > of the periph. controllers, it says > > depends on =y && PCI That's what I saw too. Looked dubious ... > but if I back up to -git7, it says > > depends on && PCI And that git7 thing doesn't look _quite_ so odd. Did git7 actually let you configure a modular GOKU (for example), i.e. work correctly? > I'll keep looking. Thanks. Kconfig is one of the areas I prefer to let others be the experts. :) - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2 -mm] kexec based hibernation -v5
On Fri, 19 Oct 2007, Phillip Susi wrote: Huang, Ying wrote: The restore process with the patch set is as follow: 1. Boot a kernel C (crash dump enabled), the memory area used by kernel C must be a subset of memory area used by kernel B. 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? you could use one kernel for all three, or you could use three different kernels, and three different sets of userspace if it's appropriate. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
On Fri, 19 Oct 2007 18:22:45 -0700 David Brownell wrote: > (Originally posted to kbuild-devel per MAINTAINERS, but > that post was rejected since that is -- undocumented, > sigh -- a members-only list.) That mailing list is no longer used. Today's git pull for kbuild included this change: KCONFIG P: Roman Zippel M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] S: Maintained > Hi, > > I noticed a regression, visible in the drivers/usb/gadget Kconfig; > it seems to be quite recent. > > That Kconfig hasn't changed (other than adding new drivers), and > it's worked that way for several years now ... so the issue seems > to be changes in menuconfig/kconfig/etc semantics. > > The issue is that when USB_GADGET=m, it's no longer possible to > configure peripheral controller drivers as modules ... the controller > drivers can now only be configured for static linkage. > > It should be making a choice of one of the controller drivers which > could work on the target system, and allow that driver to be linked > either as a module (ok iff USB_GADGET=m) or statically. > > What's the deal here? Hm, it does look very odd. It looks like it has something to do with working differently for some reason. In xconfig, I set all of the View Options and when I click on one of the periph. controllers, it says depends on =y && PCI but if I back up to -git7, it says depends on && PCI I'll keep looking. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] NFS client fixes for 2.6.23++
nfs: Fix build break with CONFIG_NFS_V4=n
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
On Fri, Oct 19, 2007 at 05:23:13PM -0400, Trond Myklebust wrote:
> 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.
>
[...]
> @@ -522,8 +522,12 @@ void put_nfs_open_context(struct nfs_open_context *ctx)
> return;
> list_del(&ctx->list);
> spin_unlock(&inode->i_lock);
> - if (ctx->state != NULL)
> - nfs4_close_state(&ctx->path, ctx->state, ctx->mode);
> + if (ctx->state != NULL) {
> + if (wait)
> + nfs4_close_sync(&ctx->path, ctx->state, ctx->mode);
> + else
> + nfs4_close_state(&ctx->path, ctx->state, ctx->mode);
> + }
> if (ctx->cred != NULL)
> put_rpccred(ctx->cred);
> dput(ctx->path.dentry);
This gives me build errors on most PPC defconfigs, which don't enable NFSv4.
This seems sufficient to fix it.
diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h
index a4e3b96..b35069a 100644
--- a/fs/nfs/nfs4_fs.h
+++ b/fs/nfs/nfs4_fs.h
@@ -236,6 +236,7 @@ extern struct svc_version nfs4_callback_version1;
#else
#define nfs4_close_state(a, b, c) do { } while (0)
+#define nfs4_close_sync(a, b, c) do { } while (0)
#endif /* CONFIG_NFS_V4 */
#endif /* __LINUX_FS_NFS_NFS4_FS.H */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: 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 Those files are part of the machine subdirectories. I will look at this tomorrow and try to figure out what doesn't get picked up. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] x86: unify crash_32/64.c
From: Hiroshi Shimamoto <[EMAIL PROTECTED]>
Most of contents in crash are same.
Signed-off-by: Hiroshi Shimamoto <[EMAIL PROTECTED]>
---
arch/x86/kernel/Makefile_32 |2 +-
arch/x86/kernel/Makefile_64 |2 +-
arch/x86/kernel/crash.c | 144 +++
arch/x86/kernel/crash_32.c | 137
arch/x86/kernel/crash_64.c | 135
5 files changed, 146 insertions(+), 274 deletions(-)
create mode 100644 arch/x86/kernel/crash.c
delete mode 100644 arch/x86/kernel/crash_32.c
delete mode 100644 arch/x86/kernel/crash_64.c
diff --git a/arch/x86/kernel/Makefile_32 b/arch/x86/kernel/Makefile_32
index ccea590..b9d6798 100644
--- a/arch/x86/kernel/Makefile_32
+++ b/arch/x86/kernel/Makefile_32
@@ -26,7 +26,7 @@ obj-$(CONFIG_X86_MPPARSE) += mpparse_32.o
obj-$(CONFIG_X86_LOCAL_APIC) += apic_32.o nmi_32.o
obj-$(CONFIG_X86_IO_APIC) += io_apic_32.o
obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
-obj-$(CONFIG_KEXEC)+= machine_kexec_32.o relocate_kernel_32.o
crash_32.o
+obj-$(CONFIG_KEXEC)+= machine_kexec_32.o relocate_kernel_32.o
crash.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump_32.o
obj-$(CONFIG_X86_NUMAQ)+= numaq_32.o
obj-$(CONFIG_X86_SUMMIT_NUMA) += summit_32.o
diff --git a/arch/x86/kernel/Makefile_64 b/arch/x86/kernel/Makefile_64
index dec06e7..7b917d4 100644
--- a/arch/x86/kernel/Makefile_64
+++ b/arch/x86/kernel/Makefile_64
@@ -23,7 +23,7 @@ obj-$(CONFIG_X86_CPUID) += cpuid.o
obj-$(CONFIG_SMP) += smp_64.o smpboot_64.o trampoline_64.o
tsc_sync.o
obj-y += apic_64.o nmi_64.o
obj-y += io_apic_64.o mpparse_64.o genapic_64.o
genapic_flat_64.o
-obj-$(CONFIG_KEXEC)+= machine_kexec_64.o relocate_kernel_64.o
crash_64.o
+obj-$(CONFIG_KEXEC)+= machine_kexec_64.o relocate_kernel_64.o
crash.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump_64.o
obj-$(CONFIG_PM) += suspend_64.o
obj-$(CONFIG_HIBERNATION) += suspend_asm_64.o
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
new file mode 100644
index 000..af0253f
--- /dev/null
+++ b/arch/x86/kernel/crash.c
@@ -0,0 +1,144 @@
+/*
+ * Architecture specific (i386/x86_64) functions for kexec based crash dumps.
+ *
+ * Created by: Hariprasad Nellitheertha ([EMAIL PROTECTED])
+ *
+ * Copyright (C) IBM Corporation, 2004. All rights reserved.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef X86_32
+#include
+#else
+#include
+#endif
+
+/* This keeps a track of which one is crashing cpu. */
+static int crashing_cpu;
+
+#if defined(CONFIG_SMP) && defined(CONFIG_X86_LOCAL_APIC)
+static atomic_t waiting_for_crash_ipi;
+
+static int crash_nmi_callback(struct notifier_block *self,
+ unsigned long val, void *data)
+{
+ struct pt_regs *regs;
+#ifdef X86_32
+ struct pt_regs fixed_regs;
+#endif
+ int cpu;
+
+ if (val != DIE_NMI_IPI)
+ return NOTIFY_OK;
+
+ regs = ((struct die_args *)data)->regs;
+ cpu = raw_smp_processor_id();
+
+ /* Don't do anything if this handler is invoked on crashing cpu.
+* Otherwise, system will completely hang. Crashing cpu can get
+* an NMI if system was initially booted with nmi_watchdog parameter.
+*/
+ if (cpu == crashing_cpu)
+ return NOTIFY_STOP;
+ local_irq_disable();
+
+#ifdef X86_32
+ if (!user_mode_vm(regs)) {
+ crash_fixup_ss_esp(&fixed_regs, regs);
+ regs = &fixed_regs;
+ }
+#endif
+ crash_save_cpu(regs, cpu);
+ disable_local_APIC();
+ atomic_dec(&waiting_for_crash_ipi);
+ /* Assume hlt works */
+ halt();
+ for (;;)
+ cpu_relax();
+
+ return 1;
+}
+
+static void smp_send_nmi_allbutself(void)
+{
+ cpumask_t mask = cpu_online_map;
+ cpu_clear(safe_smp_processor_id(), mask);
+ if (!cpus_empty(mask))
+ send_IPI_mask(mask, NMI_VECTOR);
+}
+
+static struct notifier_block crash_nmi_nb = {
+ .notifier_call = crash_nmi_callback,
+};
+
+static void nmi_shootdown_cpus(void)
+{
+ unsigned long msecs;
+
+ atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
+ /* Would it be better to replace the trap vector here? */
+ if (register_die_notifier(&crash_nmi_nb))
+ return; /* return what? */
+ /* Ensure the new callback function is set before sending
+* out the NMI
+*/
+ wmb();
+
+ smp_send_nmi_allbutself();
+
+ msecs = 1000; /* Wait at most a second for the other cpus to stop */
+ while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
+
[PATCH 2/3] x86: add safe_smp_processor_id for x86_64
From: Hiroshi Shimamoto <[EMAIL PROTECTED]>
Signed-off-by: Hiroshi Shimamoto <[EMAIL PROTECTED]>
---
include/asm-x86/smp_64.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-x86/smp_64.h b/include/asm-x86/smp_64.h
index 6f0e027..ab612b0 100644
--- a/include/asm-x86/smp_64.h
+++ b/include/asm-x86/smp_64.h
@@ -76,6 +76,8 @@ extern unsigned __cpuinitdata disabled_cpus;
#endif /* CONFIG_SMP */
+#define safe_smp_processor_id()smp_processor_id()
+
static inline int hard_smp_processor_id(void)
{
/* we don't want to mark this access volatile - bad code generation */
--
1.5.2.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.23-git Kconfig regression
(Originally posted to kbuild-devel per MAINTAINERS, but that post was rejected since that is -- undocumented, sigh -- a members-only list.) Hi, I noticed a regression, visible in the drivers/usb/gadget Kconfig; it seems to be quite recent. That Kconfig hasn't changed (other than adding new drivers), and it's worked that way for several years now ... so the issue seems to be changes in menuconfig/kconfig/etc semantics. The issue is that when USB_GADGET=m, it's no longer possible to configure peripheral controller drivers as modules ... the controller drivers can now only be configured for static linkage. It should be making a choice of one of the controller drivers which could work on the target system, and allow that driver to be linked either as a module (ok iff USB_GADGET=m) or statically. What's the deal here? - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] x86: add lapic_shutdown for x86_64
From: Hiroshi Shimamoto <[EMAIL PROTECTED]>
Signed-off-by: Hiroshi Shimamoto <[EMAIL PROTECTED]>
---
arch/x86/kernel/apic_64.c | 14 ++
include/asm-x86/apic_64.h |1 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
index f47bc49..f28ccb5 100644
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -287,6 +287,20 @@ void disable_local_APIC(void)
apic_write(APIC_SPIV, value);
}
+void lapic_shutdown(void)
+{
+ unsigned long flags;
+
+ if (!cpu_has_apic)
+ return;
+
+ local_irq_save(flags);
+
+ disable_local_APIC();
+
+ local_irq_restore(flags);
+}
+
/*
* This is to verify that we're looking at a real local APIC.
* Check these against your board if the CPUs aren't getting
diff --git a/include/asm-x86/apic_64.h b/include/asm-x86/apic_64.h
index 3c8f21e..2747a11 100644
--- a/include/asm-x86/apic_64.h
+++ b/include/asm-x86/apic_64.h
@@ -69,6 +69,7 @@ extern void clear_local_APIC (void);
extern void connect_bsp_APIC (void);
extern void disconnect_bsp_APIC (int virt_wire_setup);
extern void disable_local_APIC (void);
+extern void lapic_shutdown (void);
extern int verify_local_APIC (void);
extern void cache_APIC_registers (void);
extern void sync_Arb_IDs (void);
--
1.5.2.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.
On venerdì 12 ottobre 2007, Rob Landley wrote: > [Second try, without clicking "compress" on the file attachment because > then sourceforge's spam filter bounces it.] > > --- > > The User Mode Linux build still breaks for me: > > In file included from include/asm/arch/tlb.h:18, > > from include/asm/tlb.h:4, > > from arch/um/kernel/smp.c:8: > > include/asm-generic/tlb.h: In function ‘tlb_flush_mmu’: > > include/asm-generic/tlb.h:76: error: implicit declaration of function > > ‘release_pages’ include/asm-generic/tlb.h: In function ‘tlb_remove_page’: > > include/asm-generic/tlb.h:105: error: implicit declaration of function > > ‘page_cache_release’ make[1]: *** [arch/um/kernel/smp.o] Error 1 > > make: *** [arch/um/kernel] Error 2 > > I submitted the following patch to fix it to the UML list after 2.6.23-rc3: > http://sourceforge.net/mailarchive/forum.php?thread_name=200708212148.05392 >.rob%40landley.net&forum_name=user-mode-linux-devel > > On september 4, I confirmed that I still needed it to build -rc5: > http://sourceforge.net/mailarchive/message.php?msg_name=200709040737.54516. >rob%40landley.net > > Guess what? I still need this patch to build the final 2.6.23, months > later. > > I know it may not be the right fix, but the build breaks for me without > this patch. The .config that breaks is attached. ARCH=um. Guess most people are not using SMP right now, and that the error disappears without that setting - I'm being away for a long while, has SKAS+SMP support been merged? However, a quick look at my sources tells otherwise, and git-describe says that's a v2.6.23-rc6-239-gc2f8289 tree. So I've no idea... > -- Forwarded Message -- > > Subject: [uml-devel] UML doesn't build in 2.6.23-rc3. > Date: Tuesday 21 August 2007 > From: Rob Landley <[EMAIL PROTECTED]> > To: uml-devel <[EMAIL PROTECTED]> > > I fixed it for me with the following patch, just in case anybody else had > this problem: > > --- linux-2.6.23-rc3/arch/um/kernel/smp.c 2007-08-12 23:25:24.0 > -0500 +++ linux-2.6.23-new/arch/um/kernel/smp.c 2007-08-21 > 21:39:00.0 -0500 @@ -5,6 +5,7 @@ > > #include "linux/percpu.h" > #include "asm/pgalloc.h" > +#include "linux/pagemap.h" > #include "asm/tlb.h" > > /* For some reason, mmu_gathers are referenced when CONFIG_SMP is off. */ -- "Doh!" (cit.), I've made another mistake! Paolo Giarrusso, aka Blaisorblade signature.asc Description: This is a digitally signed message part.
[PATCH 0/3] x86: unify crash_32/64.c
Hi, I made patches to unify crash_32/64.c. There are three patches; 1. add lapic_shutdown for x86_64 2. add safe_smp_processor_id for x86_64 3. unify crash_32/64.c I'm not sure that it's good to split to these patches. I've compiled on both of 32bit and 64bit, and tested kdump on 64bit. Thanks Hiroshi Shimamoto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23] tasks stuck in running state?
On 10/19/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: > 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 > -sj5 on this box), and it will "hang" in the following way: > > > 31003 ?S 0:04 sshd: [EMAIL PROTECTED]/0 > > 31004 pts/0Ss 0:02 \_ -bash > > 8280 pts/0S+ 0:00 \_ make ARCH=i386 -sj4 > > 8690 pts/0Z+ 0:00 \_ [rm] > > 8691 pts/0S+ 0:00 \_ /bin/sh -c cat > > include/config/kernel.release 2> /dev/null > > 8692 pts/0R+ 6:12 \_ cat include/config/kernel.release > > 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 *think* I'm seeing this with firefox under 2.6.23-rc6. I tried a `killall -SIGSTOP firefox; killall -SIGCONT firefox` and when I looked back it was back to life again, but that may have been a fluke. Regardless, try that the next time it happens? Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scripts: enhancements to the RPM spec file generator
From: Florin Andrei <[EMAIL PROTECTED]> "make rpm" creates a plain package that does not update grub.conf and does not create an initrd. This patch modifies scripts/package/mkspec to create an RPM spec file that updates grub.conf after install/uninstall and also that creates an initrd file after install. These new functions are activated via an environment variable (export RPM_RH5_STYLE=true) when running "make rpm". Signed-off-by: Florin Andrei <[EMAIL PROTECTED]> --- --- linux-2.6.23.1.orig/scripts/package/mkspec 2007-10-19 02:07:58.0 -0700 +++ linux-2.6.23.1/scripts/package/mkspec 2007-10-19 05:42:47.0 -0700 @@ -81,6 +81,11 @@ echo 'cp $KBUILD_IMAGE $RPM_BUILD_ROOT'" echo "%endif" echo "%endif" +if $RPM_RH5_STYLE; then +echo 'touch $RPM_BUILD_ROOT'"/boot/initrd-$KERNELRELEASE.img" +echo 'gzip -c9 < Module.symvers > $RPM_BUILD_ROOT'"/boot/symvers-$KERNELRELEASE.gz" +fi + echo 'cp System.map $RPM_BUILD_ROOT'"/boot/System.map-$KERNELRELEASE" echo 'cp .config $RPM_BUILD_ROOT'"/boot/config-$KERNELRELEASE" @@ -88,9 +93,44 @@ echo "" echo "%clean" echo '#echo -rf $RPM_BUILD_ROOT' echo "" + +if $RPM_RH5_STYLE; then +cat
Re: atm: panic when loading clip 2nd time
On Tue, 16 Oct 2007 14:33:38 -0700 Nish Aravamudan wrote: > On 10/16/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: > > 2.6.23-git7, using SLAB (not SLUB) [config attached]: > > > > # modprobe clip > > # rmmod clip > > # modprobe clip > > > > results in panic: > > > > kmem_cache_create: duplicate cache clip_arp_cache > > > > Call Trace: > > [] kmem_cache_create+0x3bf/0x3fd > > [] neigh_table_init_no_netlink+0x6c/0x242 > > [] :clip:atm_clip_init+0x10/0x8a > > [] sys_init_module+0x146c/0x15cd > > [] neigh_lookup+0x0/0xd5 > > [] syscall_trace_enter+0x95/0x99 > > [] tracesys+0xdc/0xe1 > > > > Kernel panic - not syncing: kmem_cache_create(): failed to create slab > > `clip_arp_cache' > > >From a quick read through the code, looks like > net/core/neighbour.c:neigh_table_clear() needs a kmem_cache_destroy()? > > I only see three callers of neight_table_clear() and they all seem to > be in exit routines, so that should be safe? Hi Nish, Maybe. I can't tell without knowing the code better. [make that patch, test it; test patch is below] Well, it survives light testing (boot/init and a tarball download), but I don't know how safe it is. --- From: Randy Dunlap <[EMAIL PROTECTED]> net/atm/clip.c crashes the kernel if it (module) is loaded, removed, and then loaded again. Its exit call to neigh_table_clear() should destroy the cache after freeing it. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- net/core/neighbour.c |3 +++ 1 file changed, 3 insertions(+) --- linux-2.6.23-git7.orig/net/core/neighbour.c +++ linux-2.6.23-git7/net/core/neighbour.c @@ -1436,6 +1436,9 @@ int neigh_table_clear(struct neigh_table free_percpu(tbl->stats); tbl->stats = NULL; + kmem_cache_destroy(tbl->kmem_cachep); + tbl->kmem_cachep = NULL; + return 0; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sysctl: Don't compile sysctl_check when !CONFIG_SYSCTL
On Fri, 19 Oct 2007 18:23:25 -0600 Eric W. Biederman wrote: > Randy Dunlap <[EMAIL PROTECTED]> writes: > > > On Thu, 18 Oct 2007 21:27:16 -0700 Avuton Olrich wrote: > > > >> 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: http://avuton.googlepages.com/sysctl-head-next.config > >> > >> git master: 4fa4d23fa20de67df919030c1216295664866ad7 > > > > Eric, > > > > Please have a look at this one. > > > > .config file link is above. > > > > # CONFIG_SYSCTL_SYSCALL is not set > > # CONFIG_PROC_SYSCTL is not set > > > > Weird I thought I had written the makefile so this would be handled. > Oh well this should fix it. > > Sorry about that. > > Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> > --- > kernel/Makefile |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/kernel/Makefile b/kernel/Makefile > index 05c3e6d..79f017e 100644 > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -9,8 +9,9 @@ obj-y = sched.o fork.o exec_domain.o panic.o printk.o > profile.o \ > rcupdate.o extable.o params.o posix-timers.o \ > kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \ > hrtimer.o rwsem.o latency.o nsproxy.o srcu.o \ > - utsname.o sysctl_check.o notifier.o > + utsname.o notifier.o > > +obj-$(CONFIG_SYSCTL) += sysctl_check.o > obj-$(CONFIG_STACKTRACE) += stacktrace.o > obj-y += time/ > obj-$(CONFIG_DEBUG_MUTEXES) += mutex-debug.o > -- Acked-by: Randy Dunlap <[EMAIL PROTECTED]> # and tested-by: --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to use TLB to prevent Linux accessing a particular memory region
> Out of 32MB of DDR 8MB is reserved for use by DSP > processor. But the MIPS processor downloads firmware > into this reserved memory for the DSP. > > Now, is it possible to use the TLB to prevent Linux > from accessing the reserved memory after the firmware > has been downloaded? Well, even if you did remap PTEs (TLBs are N/A), or claimed that special memory, that may be too late. The kernel might've already allocated and stomped over it. A reliable way is to redefine the kernel's "memory map" which takes effect during boot. Look for the memory map as a .h in arch/ (IIRC). -- Jim Brooks __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sysctl: Don't compile sysctl_check when !CONFIG_SYSCTL
Randy Dunlap <[EMAIL PROTECTED]> writes: > On Thu, 18 Oct 2007 21:27:16 -0700 Avuton Olrich wrote: > >> 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: http://avuton.googlepages.com/sysctl-head-next.config >> >> git master: 4fa4d23fa20de67df919030c1216295664866ad7 > > Eric, > > Please have a look at this one. > > .config file link is above. > > # CONFIG_SYSCTL_SYSCALL is not set > # CONFIG_PROC_SYSCTL is not set > Weird I thought I had written the makefile so this would be handled. Oh well this should fix it. Sorry about that. Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> --- kernel/Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/kernel/Makefile b/kernel/Makefile index 05c3e6d..79f017e 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -9,8 +9,9 @@ obj-y = sched.o fork.o exec_domain.o panic.o printk.o profile.o \ rcupdate.o extable.o params.o posix-timers.o \ kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \ hrtimer.o rwsem.o latency.o nsproxy.o srcu.o \ - utsname.o sysctl_check.o notifier.o + utsname.o notifier.o +obj-$(CONFIG_SYSCTL) += sysctl_check.o obj-$(CONFIG_STACKTRACE) += stacktrace.o obj-y += time/ obj-$(CONFIG_DEBUG_MUTEXES) += mutex-debug.o -- 1.5.3.rc6.17.g1911 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] drivers-edac-i3000 replace macros with functions
On Fri, Oct 19, 2007 at 14:11:18 -0700, Andrew Morton wrote:
> On Fri, 19 Oct 2007 13:18:23 -0600
> [EMAIL PROTECTED] wrote:
>
> > +static inline unsigned long deap_pfn(u8 edeap, u32 deap)
> > +{
> > + deap >>= PAGE_SHIFT;
> > + deap |= (edeap & 1) << (32 - PAGE_SHIFT);
> > + return deap;
> > +}
> > +
> > +static inline unsigned long deap_offset(u32 deap)
> > +{
> > + return deap & ~(I3000_DEAP_GRAIN - 1) & ~PAGE_MASK;
> > +}
> > +
>
> The types here look a bit confused. Implicit conversions of
> u32s into unsigned longs.
That's deliberate, though perhaps not as clear as it could have been:
We're calculating a pfn and an offset which are logically unsigned
longs (and treated as such by the higher level edac code where they
ultimately get passed) from some bits in config space registers which
are u8/u32.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23.1 host freezes when running kvm
* Bart Trojanowski <[EMAIL PROTECTED]> [071019 17:00]: > > Once the system is booted, I attached using vnc, then I ssh in and ran > 'svn update'... and the host machine froze. > > The last messages I on my serial console are: > > kvm: unhandled rdmsr: 0x417 > kvm: unhandled rdmsr: 0xc400 > I noticed that linus merged a bunch of KVM changes last week. I will > try those out next. It looks like Linus' tree has the fix already. -Bart -- WebSig: http://www.jukie.net/~bart/sig/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: In function sysctl_check_lookup: undef ref to sysctl_head_next
On Thu, 18 Oct 2007 21:27:16 -0700 Avuton Olrich wrote: > 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: http://avuton.googlepages.com/sysctl-head-next.config > > git master: 4fa4d23fa20de67df919030c1216295664866ad7 Eric, Please have a look at this one. .config file link is above. # CONFIG_SYSCTL_SYSCALL is not set # CONFIG_PROC_SYSCTL is not set Thanks, --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23] tasks stuck in running state?
From: Chuck Ebbert <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 18:18:08 -0400 > On 10/19/2007 06:03 PM, Jeff Garzik wrote: > >> [EMAIL PROTECTED] misc-2.6]$ strace -p8484 > >> Process 8484 attached - interrupt to quit > > [sits there, chewing up CPU grepping a 47-line header file] > > > > And sysrq-p is pretty useless unless you can force the keyboard > interrupt and the spinning process onto the same CPU. Yes, I find this a painful limitation too. Sparc64 used to dump the registers on all active cpus for show_regs() via a cross-call, and this was incredibly useful. But I disabled that as soon as I started playing with Niagara because at 32 cpus and larger the output is just too voluminous to be useful. What might be appropriate is just to get a one-line program counter dump on every cpu via some new sysrq keystroke. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] drivers-edac-i3000 replace macros with functions
Jason,
Can you provide some information on this?
doug t
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 19 Oct 2007 13:18:23 -0600
> [EMAIL PROTECTED] wrote:
>
> > +static inline unsigned long deap_pfn(u8 edeap, u32 deap)
> > +{
> > + deap >>= PAGE_SHIFT;
> > + deap |= (edeap & 1) << (32 - PAGE_SHIFT);
> > + return deap;
> > +}
> > +
> > +static inline unsigned long deap_offset(u32 deap)
> > +{
> > + return deap & ~(I3000_DEAP_GRAIN - 1) & ~PAGE_MASK;
> > +}
> > +
>
> The types here look a bit confused. Implicit conversions of
> u32s into unsigned longs.
>
W1DUG
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Thomas Gleixner wrote: > On Sat, 20 Oct 2007, Gabriel C wrote: >> Gabriel C wrote: >>> Jiri Kosina wrote: Trying 'make mrproper' first has high chances of fixing this I'd guess. >>> Is what I did before latest pull. >>> >>> Maybe this whole tree got broken. I'll try a fresh one and report back. >>> >> >> I get the same on fresh cloned git tree >> >> #-- git rev-parse --verify HEAD >> c4ec20717313daafba59225f812db89595952b83 > > Hmm. The kernel itself compiles fine ? Yes kernel is fine. > > What external thing breaks ? 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 HEAD 60812a4a99b796d894d2522dc63cb0fafc3be25e Full error log can found there : -> http://194.231.229.228/current-git/errors.txt > > tglx > Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] irq-remove: core
Eric W. Biederman wrote:
Jeff Garzik <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
Jeff Garzik <[EMAIL PROTECTED]> writes:
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?
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.
After diving in, in the past couple of hours, I'm pretty confident we simply do
not need {get,set}_irqfunc_irq()
Sounds good. That was my impression when I was looking at this kind of stuff.
'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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] irq-remove: core
Eric W. Biederman wrote:
Jeff Garzik <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
Jeff Garzik <[EMAIL PROTECTED]> writes:
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?
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.
After diving in, in the past couple of hours, I'm pretty confident we simply do
not need {get,set}_irqfunc_irq()
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.
Hey I'm the one who has kept the ball rolling since the day pt_regs were
removed... :)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[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 <[EMAIL PROTECTED]>
---
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 ibmpex_bmc_data
*data)
return 0;
out1:
- printk(KERN_ERR "%s: request_settime=%x\n", __FUNCTION__, err);
+ dev_err(data->bmc_device, "request_settime=%x\n", err);
return err;
out:
- printk(KERN_ERR "%s: validate_addr=%x\n", __FUNCTION__, err);
+ dev_err(data->bmc_device, "validate_addr=%x\n", err);
return err;
}
@@ -161,14 +161,14 @@ static int ibmpex_ver_check(struct ibmpex_bmc_data *data)
data->sensor_major = data->rx_msg_data[0];
data->sensor_minor = data->rx_msg_data[1];
- printk(KERN_INFO DRVNAME ": Found BMC with sensor interface "
- "v%d.%d %d-%02d-%02d on interface %d\n",
- data->sensor_major,
- data->sensor_minor,
- extract_value(data->rx_msg_data, 2),
- data->rx_msg_data[4],
- data->rx_msg_data[5],
- data->interface);
+ dev_info(data->bmc_device, "Found BMC with sensor interface "
+"v%d.%d %d-%02d-%02d on interface %d\n",
+data->sensor_major,
+data->sensor_minor,
+extract_value(data->rx_msg_data, 2),
+data->rx_msg_data[4],
+data->rx_msg_data[5],
+data->interface);
return 0;
}
@@ -212,8 +212,8 @@ static int ibmpex_query_sensor_data(struct ibmpex_bmc_data
*data, int sensor)
wait_for_completion(&data->read_complete);
if (data->rx_result || data->rx_msg_len < 26) {
- printk(KERN_ERR "Error reading sensor %d, please check.\n",
- sensor);
+ dev_err(data->bmc_device, "Error reading sensor %d.\n",
+ sensor);
return -ENOENT;
}
@@ -456,8 +456,7 @@ static void ibmpex_register_bmc(int iface, struct device
*dev)
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data) {
- printk(KERN_ERR DRVNAME ": Insufficient memory for BMC "
- "interface %d.\n", data->interface);
+ dev_err(dev, "Insufficient memory for BMC interface.\n");
return;
}
@@ -471,9 +470,8 @@ static void ibmpex_register_bmc(int iface, struct device
*dev)
err = ipmi_create_user(data->interface, &driver_data.ipmi_hndlrs,
data, &data->user);
if (err < 0) {
- printk(KERN_ERR DRVNAME ": Error, unable to register user with "
- "ipmi interface %d\n",
- data->interface);
+ dev_err(dev, "Unable to register user with IPMI "
+ "interface %d\n", data->interface);
goto out;
}
@@ -495,9 +493,9 @@ static void ibmpex_register_bmc(int iface, struct device
*dev)
data->hwmon_dev = hwmon_device_register(data->bmc_device);
if (IS_ERR(data->hwmon_dev)) {
- printk(KERN_ERR DRVNAME ": Error, unable to register hwmon "
- "class device for interface %d\n",
- data->interface);
+ dev_err(data->bmc_device, "Unable to register hwmon "
+ "device for IPMI interface %d\n",
+ data->interface);
goto out_user;
}
@@ -508,7 +506,7 @@ static void ibmpex_register_bmc(int iface, struct device
*dev)
/* Now go find all the sensors */
err = ibmpex_find_sensors(data);
if (err) {
- printk(KERN_ERR "Error %d allocating memory\n", err);
+ dev_err(data->bmc_device, "Error %d finding sensors\n", err);
goto out_register;
}
@@ -561,10 +559,10 @@ static void ibmpex_msg_handler(struct ipmi_recv_msg *msg,
void *user_msg_data)
struct ibmpex_bmc_data *data = (struct ibmpex_bmc_data *)user_msg_data;
if (msg->msgid != data->tx_msgid) {
- printk(KERN_ERR "Received msgid (%02x) and transmitted "
- "msgid (%02x) mismatch!\n",
- (int)msg->msgid,
- (int)data->tx_msgid);
+ dev_err(data->bmc_device, "Mismatch between received msgid "
+ "(%02x) and transmitted msgid (%02x)!\n",
+ (int)msg->msgid,
+ (int)data->tx_msgid);
ipmi_free_recv_msg(msg);
return;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
Re: Kernel configuration of a two dual core processor - Xeon 5130
jmsanchezdiaz wrote: On 17 oct, 16:26, jmsanchezdiaz <[EMAIL PROTECTED]> wrote: Hello, I have a two 2.00 GHz Dual-Core processor Intel Xeon 5130 machine, Bus Speed 1333 MHz, L2 Cache 4 MB, System Memory Size 40 GB, System Memory Speed: 667 MHz. /proc/cpuinfo: --- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU5130 @ 2.00GHz stepping: 6 cpu MHz : 1995.032 cache size : 4096 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm bogomips: 3993.93 [...]And so on for the 3 other cores /proc/pci: -- PCI devices found: Bus 0, device 0, function 0: Class 0600: PCI device 8086:25c0 (rev 18). Bus 0, device 2, function 0: Class 0604: PCI device 8086:25e2 (rev 18). IRQ 16. Master Capable. No bursts. Min Gnt=3. Bus 0, device 3, function 0: Class 0604: PCI device 8086:25e3 (rev 18). IRQ 16. Master Capable. No bursts. Min Gnt=3. Bus 0, device 4, function 0: Class 0604: PCI device 8086:25f8 (rev 18). IRQ 16. Master Capable. No bursts. Min Gnt=3. Bus 0, device 5, function 0: Class 0604: PCI device 8086:25e5 (rev 18). Bus 0, device 6, function 0: Class 0604: PCI device 8086:25f9 (rev 18). IRQ 16. Master Capable. No bursts. Min Gnt=3. Bus 0, device 7, function 0: Class 0604: PCI device 8086:25e7 (rev 18). Bus 0, device 16, function 0: Class 0600: PCI device 8086:25f0 (rev 18). Bus 0, device 16, function 1: Class 0600: PCI device 8086:25f0 (rev 18). Bus 0, device 16, function 2: Class 0600: PCI device 8086:25f0 (rev 18). Bus 0, device 17, function 0: Class 0600: PCI device 8086:25f1 (rev 18). Bus 0, device 19, function 0: Class 0600: PCI device 8086:25f3 (rev 18). Bus 0, device 21, function 0: Class 0600: PCI device 8086:25f5 (rev 18). Bus 0, device 22, function 0: Class 0600: PCI device 8086:25f6 (rev 18). Bus 0, device 28, function 0: Class 0604: PCI device 8086:2690 (rev 9). IRQ 16. Master Capable. No bursts. Min Gnt=3. Bus 0, device 29, function 0: Class 0c03: PCI device 8086:2688 (rev 9). IRQ 18. I/O at 0xbce0 [0xbcff]. Bus 0, device 29, function 1: Class 0c03: PCI device 8086:2689 (rev 9). IRQ 19. I/O at 0xbcc0 [0xbcdf]. Bus 0, device 29, function 2: Class 0c03: PCI device 8086:268a (rev 9). IRQ 18. I/O at 0xbca0 [0xbcbf]. Bus 0, device 29, function 7: Class 0c03: PCI device 8086:268c (rev 9). IRQ 18. Non-prefetchable 32 bit memory at 0xfc90 [0xfc9003ff]. Bus 0, device 30, function 0: Class 0604: PCI device 8086:244e (rev 217). Master Capable. No bursts. Min Gnt=11. Bus 0, device 31, function 0: Class 0601: PCI device 8086:2670 (rev 9). Bus 0, device 31, function 1: Class 0101: PCI device 8086:269e (rev 9). IRQ 16. I/O at 0xfc00 [0xfc0f]. Bus 5, device 0, function 0: Class 0604: PCI device 8086:3500 (rev 1). IRQ 16. Master Capable. No bursts. Min Gnt=7. Bus 5, device 0, function 3: Class 0604: PCI device 8086:350c (rev 1). Master Capable. No bursts. Min Gnt=7. Bus 6, device 0, function 0: Class 0604: PCI device 8086:3510 (rev 1). IRQ 16. Master Capable. No bursts. Min Gnt=3. Bus 6, device 1, function 0: Class 0604: PCI device 8086:3514 (rev 1). IRQ 16. Master Capable. No bursts. Min Gnt=3. Bus 3, device 0, function 0: Class 0604: PCI device 1166:0103 (rev 195). Master Capable. No bursts. Min Gnt=6. Bus 7, device 0, function 0: Class 0604: PCI device 1166:0103 (rev 195). Master Capable. No bursts. Min Gnt=6. Bus 4, device 0, function 0: Class 0200: PCI device 14e4:164c (rev 18). IRQ 16. Master Capable. Latency=32. Min Gnt=64. Non-prefetchable 64 bit memory at 0xf800 [0xf9ff]. Bus 8, device 0, function 0: Class 0200: PCI device 14e4:164c (rev 18). IRQ 16. Master Capable. Latency=64. Min Gnt=64. Non-prefetchable 64 bit memory at 0xf400 [0xf5ff]. Bus 1, device 0, function 0: Class 0604: PCI device 8086:032c (rev 9). Master Capable. No bursts. Min Gnt=6. Bus 2, device 8, function 0: Class 0100: PCI device 1000:0054 (rev 1). IRQ 17. Master Capable. Latency=72. Min Gnt=64.Max Lat=10. I/O at 0xec
Re: [Git pull] arch/x86 updates
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Fri, 19 Oct 2007, Thomas Gleixner wrote:
> >
> > Pavel Emelyanov (1):
> > i386: consolidate show_regs and show_registers for i386
>
> 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.
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 character is almost
always a certainty. I remember only a single case in the past ~10 years
where an oops would print a "never ending" p->comm because the
corruption was a runaway memset to a non-0 value.
so printing it as %s should be perfectly fine too, for all practical
purposes. (and printing it _without_ the TASK_COMM_LEN complication
might help get out information faster in some other crash situations -
so the argument can be made in the opposite direction too.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] irq-remove: core
Jeff Garzik <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Jeff Garzik <[EMAIL PROTECTED]> writes:
>>> 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?
>>
>> 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.
>
> After diving in, in the past couple of hours, I'm pretty confident we simply
> do
> not need {get,set}_irqfunc_irq()
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in: Driver core: convert block from raw kobjects to core devices
On Fri, 2007-10-19 at 13:11 -0400, Alan Stern wrote: > On Fri, 19 Oct 2007, Kay Sievers wrote: > > > Don't you have a USB storage device? It should be easy for you to > test > > > this on your own system. > > > > 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. > > 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: > ... > As you can see, this definitely proves that the final put is done at > the right time. > > See what the patch shows on your system. One extra thing to check for: > When you plug in a USB drive, the SCSI core starts up an error-handler > process for it. When you unplug the drive, the error-handler task > should exit. If it doesn't then there's an extra reference somewhere > that never got released. 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: unset subsytem caused the event to drop! kobject sdb: registering. parent: block, set: devices kobject filter function caused the event to drop! after device_add: 3 after sysfs_create_link: 3 kobject holders: registering. parent: sdb, set: kobject filter function caused the event to drop! kobject slaves: registering. parent: sdb, set: kobject filter function caused the event to drop! after disk_sysfs_add_subdirs: 5 after get_capacity: 5 after bdget_disk: 5 sd 9:0:0:0: [sdb] 127840 512-byte hardware sectors (65 MB) sd 9:0:0:0: [sdb] Write Protect is off sd 9:0:0:0: [sdb] Mode Sense: 45 00 00 08 sd 9:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 kobject sdb1: registering. parent: sdb, set: devices kobject filter function caused the event to drop! kobject holders: registering. parent: sdb1, set: kobject filter function caused the event to drop! after blkdev_get: 8 after blkdev_put: 7 fill_kobj_path: path = '/devices/pci:00/:00:1d.0/usb1/1-2/1-2:1.0/host9/target9:0:0/9:0:0:0/block/sdb' fill_kobj_path: path = '/devices/pci:00/:00:1d.0/usb1/1-2/1-2:1.0/host9/target9:0:0/9:0:0:0/block/sdb/sdb1' end of register_disk: 7 kobject queue: registering. parent: sdb, set: kobject filter function caused the event to drop! kobject iosched: registering. parent: queue, set: kobject filter function caused the event to drop! after blk_register_queue: 9 sd 9:0:0:0: [sdb] Attached SCSI removable disk kobject 9:0:0:0: registering. parent: scsi_device, set: class_obj fill_kobj_path: path = '/class/scsi_device/9:0:0:0' fill_kobj_path: path = '/devices/pci:00/:00:1d.0/usb1/1-2/1-2:1.0/host9/target9:0:0/9:0:0:0' kobject sg2: registering. parent: scsi_generic, set: class_obj fill_kobj_path: path = '/class/scsi_generic/sg2' fill_kobj_path: path = '/devices/pci:00/:00:1d.0/usb1/1-2/1-2:1.0/host9/target9:0:0/9:0:0:0' sd 9:0:0:0: Attached scsi generic sg2 type 0 kobject 9:0:0:0: registering. parent: bsg, set: class_obj fill_kobj_path: path = '/class/bsg/9:0:0:0' fill_kobj_path: path = '/devices/pci:00/:00:1d.0/usb1/1-2/1-2:1.0/host9/target9:0:0/9:0:0:0' kobject : cleaning up kobject iosched: cleaning up kobject queue: cleaning up kobject target9:0:1: registering. parent: host9, set: devices kobject filter function caused the event to drop! kobject : cleaning up kobject iosched: cleaning up kobject queue: cleaning up kobject filter function caused the event to drop! kobject target9:0:1: cleaning up kobject target9:0:2: registering. parent: host9, set: devices kobject filter function caused the event to drop! kobject : cleaning up kobject iosched: cleaning up kobject queue: cleaning up kobject filter function caused the event to drop! kobject target9:0:2: cleaning up kobject target9:0:3: registering. parent: host9, set: devices kobject filter function caused the event to drop! kobject : cleaning up kobject iosched: cleaning up kobject queue: cleaning up kobject filter function caused the event to drop! kobject target9:0:3: cleaning up kobject target9:0:4: registering. parent: host9, set: devices kobject filter function caused the event to drop! kobject : cleaning up kobject iosched: cleaning up kobject queue: cleaning up kobject filter function caused the event to drop! kobject target9:0:4: cleaning up kobject target9:0:5: registering. parent: host9, set: devices kobject filter funct
Re: nfsv2 ref leak in 2.6.24?
In message <[EMAIL PROTECTED]>, Trond Myklebust writes: > > On Fri, 2007-10-19 at 17:40 -0400, Erez Zadok wrote: [...] > > Trond, I was able to narrow down the problem w/o using unionfs at all (yay! > > :-). All I do is setup a loop device, mkfs it as ext2, mount it, then > > 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. > > 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? Yup. > That would indicate some dcache issues with the server code. What export > options are you using? 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4 resend] [x86] Add generic GPIO support to x86
On Fri, 19 Oct 2007 14:01:56 +0200, Florian Fainelli wrote: > Hi Andres, > > Le jeudi 18 octobre 2007, Andres Salomon a écrit : >> While I certainly would like to see a generic GPIO API, this one isn't >> really useful for geode GPIOs. It would be nice to have one that did >> work for us as well. Unfortunately, I haven't had the chance to give >> much thought to this problem yet. > > 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. 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 right now in the kernel on real hardware. Just because other architectures haven't found a need to expand the API doesn't mean that we shouldn't expand it now. And bear in mind, the Geode isn't unique - I'll bet beers that there are MIPS and ARM architectures that have these features too, and they would use the API if it existed. Jordan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] xconfig: set title bar
From: Randy Dunlap <[EMAIL PROTECTED]>
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 " command line option instead.
This can be useful when someone has multiple qconf instances running,
to help differentiate which one is which.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
scripts/kconfig/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.23-git13.orig/scripts/kconfig/Makefile
+++ linux-2.6.23-git13/scripts/kconfig/Makefile
@@ -5,7 +5,7 @@
PHONY += oldconfig xconfig gconfig menuconfig config silentoldconfig
update-po-config
xconfig: $(obj)/qconf
- $< arch/$(ARCH)/Kconfig
+ $< arch/$(ARCH)/Kconfig -title "Linux v${KERNELVERSION} qconf"
gconfig: $(obj)/gconf
$< arch/$(ARCH)/Kconfig
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 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 copying
when reading or writing directly to the block device, and changing the
software block size does not loose the contents of the ramdisk. Most
of all this ensures we don't loose data during normal use of the
ramdisk.
I deliberately avoid the cleanup that is now possible because this
patch is intended to be a bug fix.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
drivers/block/rd.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/block/rd.c b/drivers/block/rd.c
index 08176d2..a52f153 100644
--- a/drivers/block/rd.c
+++ b/drivers/block/rd.c
@@ -62,6 +62,7 @@
/* Various static variables go here. Most are used only in the RAM disk code.
*/
+static struct inode *rd_inode[CONFIG_BLK_DEV_RAM_COUNT];
static struct gendisk *rd_disks[CONFIG_BLK_DEV_RAM_COUNT];
static struct block_device *rd_bdev[CONFIG_BLK_DEV_RAM_COUNT];/* Protected
device data */
static struct request_queue *rd_queue[CONFIG_BLK_DEV_RAM_COUNT];
@@ -267,7 +268,7 @@ static int rd_blkdev_pagecache_IO(int rw, struct bio_vec
*vec, sector_t sector,
static int rd_make_request(struct request_queue *q, struct bio *bio)
{
struct block_device *bdev = bio->bi_bdev;
- struct address_space * mapping = bdev->bd_inode->i_mapping;
+ struct address_space * mapping =
rd_inode[MINOR(bdev->bd_dev)]->i_mapping;
sector_t sector = bio->bi_sector;
unsigned long len = bio->bi_size >> 9;
int rw = bio_data_dir(bio);
@@ -312,6 +313,7 @@ static int rd_ioctl(struct inode *inode, struct file *file,
mutex_lock(&bdev->bd_mutex);
if (bdev->bd_openers <= 2) {
truncate_inode_pages(bdev->bd_inode->i_mapping, 0);
+ truncate_inode_pages(rd_inode[iminor(inode)]->i_mapping, 0);
error = 0;
}
mutex_unlock(&bdev->bd_mutex);
@@ -344,20 +346,30 @@ static int rd_open(struct inode *inode, struct file *filp)
unsigned unit = iminor(inode);
if (rd_bdev[unit] == NULL) {
+ struct inode *ramdisk_inode;
struct block_device *bdev = inode->i_bdev;
struct address_space *mapping;
unsigned bsize;
gfp_t gfp_mask;
+ ramdisk_inode = new_inode(bdev->bd_inode->i_sb);
+ if (!ramdisk_inode)
+ return -ENOMEM;
+
inode = igrab(bdev->bd_inode);
rd_bdev[unit] = bdev;
+ rd_inode[unit] = ramdisk_inode;
bdev->bd_openers++;
bsize = bdev_hardsect_size(bdev);
bdev->bd_block_size = bsize;
inode->i_blkbits = blksize_bits(bsize);
inode->i_size = get_capacity(bdev->bd_disk)<<9;
- mapping = inode->i_mapping;
+ ramdisk_inode->i_mode = S_IFBLK;
+ ramdisk_inode->i_bdev = bdev;
+ ramdisk_inode->i_rdev = bdev->bd_dev;
+
+ mapping = ramdisk_inode->i_mapping;
mapping->a_ops = &ramdisk_aops;
mapping->backing_dev_info = &rd_backing_dev_info;
bdev->bd_inode_backing_dev_info = &rd_file_backing_dev_info;
@@ -377,7 +389,7 @@ static int rd_open(struct inode *inode, struct file *filp)
* for the page allocator emergency pools to keep the ramdisk
* driver happy.
*/
- gfp_mask = mapping_gfp_mask(mapping);
+ gfp_mask = GFP_USER;
gfp_mask &= ~(__GFP_FS|__GFP_IO);
gfp_mask |= __GFP_HIGH;
mapping_set_gfp_mask(mapping, gfp_mask);
@@ -409,6 +421,7 @@ static void __exit rd_cleanup(void)
del_gendisk(rd_disks[i]);
put_disk(rd_disks[i]);
blk_cleanup_queue(rd_queue[i]);
+ iput(rd_inode[i]);
}
unregister_blkdev(RAMDISK_MAJOR, "ramdisk");
--
1.5.3.rc6.17.g1911
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
On Sat, 20 Oct 2007, Gabriel C wrote: > Gabriel C wrote: > > Jiri Kosina wrote: > >> Trying 'make mrproper' first has high chances of fixing this I'd guess. > > > > Is what I did before latest pull. > > > > Maybe this whole tree got broken. I'll try a fresh one and report back. > > > > > I get the same on fresh cloned git tree > > #-- git rev-parse --verify HEAD > c4ec20717313daafba59225f812db89595952b83 Hmm. The kernel itself compiles fine ? What external thing breaks ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rd: Mark ramdisk buffers heads dirty
Christian Borntraeger <[EMAIL PROTECTED]> writes: > Am Donnerstag, 18. Oktober 2007 schrieb Eric W. Biederman: >> Grr. Inconsistent rules on a core piece of infrastructure. >> It looks like that if there is any trivial/minimal fix it >> is based on your patch suppressing try_to_free_buffers. Ugh. >> >> Eric > > Ok. What do you think about having my patch for 2.6.23 stable, for 2.6.24 > and doing a nicer fix (rd rewrite for example for post 2.6.24)? 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
> OTOH, it's no magic - they claim OHCI 1.1 and they do it. We don't > only know how to enable it with (only) software. I suspect all those > VT6306 could be "upgraded" as well. 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 DATA-OUT outputs port 0x20 bits 3, 2 and 1 are, respectively, CS, CLK and DATA-OUT pins in 93c46 mode and unused, SCL and SDA pins in I^2C mode port 0x20 R/O bit 0 is DATA-IN input in 93c46 mode port 0x0 bit 8 must be set to enable access port 0x20 must be written 0x20 (bit 5 only) to disable access (clears port 0x0 bit 8). They are all 32-bit I/O ports. The above allows for complete control in 93c46 mode (I'll make the program available later) and unfortunately I don't yet know how to read SDA (and SCL) state in I^2C mode (I can blindly write to the EEPROM and I can read the EEPROM data using GUID PROM register so there is a workaround). -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA driver resource allocation
On Fri, Oct 19, 2007 at 10:51:51AM -0600, Bjorn Helgaas wrote:
> Question 1: Does the linux-pcmcia list still exist? It's in MAINTAINERS:
>
> PCMCIA SUBSYSTEM
> P: Linux PCMCIA Team
> L: [EMAIL PROTECTED]
> 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.
The list is still around, but Dominik seems to have vanished.
> Question 2: Documentation/pcmcia/driver-changes.txt says drivers should
> now claim their own resources:
>
> * Resource management. (as of 2.6.8)
> Although the PCMCIA subsystem will allocate resources for cards,
> it no longer marks these resources busy. This means that driver
> authors are now responsible for claiming your resources as per
> other drivers in Linux.
>
> But I don't see any drivers that do that. It looks like there should
> be a bunch of changes like the one below. Is there a reason these
> changes didn't happen, other than just lack of interest?
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
interest in helping out with PCMCIA.
> Index: work3/drivers/net/wireless/orinoco_cs.c
> ===
> --- work3.orig/drivers/net/wireless/orinoco_cs.c 2007-10-18
> 10:56:34.0 -0600
> +++ work3/drivers/net/wireless/orinoco_cs.c 2007-10-18 13:22:44.0
> -0600
> @@ -296,6 +296,10 @@
> /* We initialize the hermes structure before completing PCMCIA
>* configuration just in case the interrupt handler gets
>* called. */
> + priv->io_resource = request_region(link->io.BasePort1,
> +link->io.NumPorts1, DRIVER_NAME);
> + if (!priv->io_resource)
> + goto cs_failed;
> mem = ioport_map(link->io.BasePort1, link->io.NumPorts1);
> if (!mem)
> goto cs_failed;
> @@ -366,6 +370,10 @@
> pcmcia_disable_device(link);
> if (priv->hw.iobase)
> ioport_unmap(priv->hw.iobase);
> + if (priv->io_resource) {
> + release_resource(priv->io_resource);
> + priv->io_resource = NULL;
Wrong function. release_resource() doesn't pair with request_region().
request_region() allocates memory for the struct resource.
release_resource() merely removes the struct resource from the tree.
release_region() on the other hand removes the struct resource and
frees it.
---
Convert pcnet_cs and serial_cs to request their IO regions, thereby
marking them busy. These are only two of many drivers which need this
update.
diff -u -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej'
ref/drivers/net/pcmcia/pcnet_cs.c linux/drivers/net/pcmcia/pcnet_cs.c
--- ref/drivers/net/pcmcia/pcnet_cs.c Sun Nov 16 19:12:33 2003
+++ linux/drivers/net/pcmcia/pcnet_cs.c Tue Dec 23 09:43:22 2003
@@ -687,8 +687,15 @@
dev->poll_controller = ei_poll;
#endif
+if (!request_region(dev->base_addr, link->io.NumPorts1, "pcnet_cs")) {
+ printk(KERN_NOTICE "pcnet_cs: request_region() failed\n");
+ link->dev = NULL;
+ goto failed;
+}
+
if (register_netdev(dev) != 0) {
printk(KERN_NOTICE "pcnet_cs: register_netdev() failed\n");
+ release_region(dev->base_addr, link->io.NumPorts1);
link->dev = NULL;
goto failed;
}
@@ -736,6 +743,9 @@
DEBUG(0, "pcnet_release(0x%p)\n", link);
+if (link->dev)
+ release_region(link->io.BasePort1, link->io.NumPorts1);
+
if (info->flags & USE_SHMEM) {
iounmap(info->base);
pcmcia_release_window(link->win);
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RESEND] i386 and x86_64: randomize brk()
On Thu, 11 Oct 2007, Andrew Morton wrote: > > Anyway, it breaks on ia64: > And on s390 > In file included from arch/s390/kernel/binfmt_elf32.c:202: > arch/s390/kernel/../../../fs/binfmt_elf.c: In function 'load_elf_binary': > arch/s390/kernel/../../../fs/binfmt_elf.c:1088: error: implicit declaration > of function 'arch_randomize_brk' > I'll drop the patch. > Really we should fix the elf mess before we try and change it any more. ... 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 some archs: http://lkml.org/lkml/2007/8/22/492 Does going back to the original ARCH_HAS_RANDOMIZE_BRK sound acceptable now, before the ELF stuff gets completely rewritten one day? Thanks, -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: > Jiri Kosina wrote: >> Trying 'make mrproper' first has high chances of fixing this I'd guess. > > Is what I did before latest pull. > > Maybe this whole tree got broken. I'll try a fresh one and report back. > I get the same on fresh cloned git tree #-- git rev-parse --verify HEAD c4ec20717313daafba59225f812db89595952b83 Regards, Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
On Saturday 20 October 2007, Nick Warne wrote: > On Friday 19 October 2007 22:44:27 Bartlomiej Zolnierkiewicz wrote: > hdparm -I 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Git pull] arch/x86 updates
On Fri, 19 Oct 2007, Linus Torvalds wrote:
>>
> > Pavel Emelyanov (1):
> > i386: consolidate show_regs and show_registers for i386
>
> 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.
Fair enough. Did not notice.
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Locking problem in usbserial with 2.6.23-git 5a34417f
Jiri Kosina wrote: > On Fri, 19 Oct 2007, Larry Finger wrote: > >> As I said earlier, the lock problem went away; however, I get the >> following two kernel warnings: > > That's because I messed up the patch, sorry. The one below should work > better. > > > > From: Jiri Kosina <[EMAIL PROTECTED]> > > 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 <[EMAIL PROTECTED]> It does work better. With it, I was able to make a dial-up connection and send pings over it. Larry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23] tasks stuck in running state?
On 10/19/2007 06:03 PM, Jeff Garzik wrote: >> [EMAIL PROTECTED] misc-2.6]$ strace -p8484 >> Process 8484 attached - interrupt to quit > [sits there, chewing up CPU grepping a 47-line header file] > And sysrq-p is pretty useless unless you can force the keyboard interrupt and the spinning process onto the same CPU. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
On Fri, Oct 19, 2007 at 11:04:23PM +0100, Nick Warne wrote: > 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 CD OK, but not DVD sometimes on the old drive? 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 reading using a 40wire cable. > hdparm -I > > /dev/hdd: > > ATAPI CD-ROM, with removable media > Model Number: TSSTcorp CDDVDW SH-S202J > Serial Number: > Firmware Revision: SB00 > Standards: > Supported: CD-ROM ATAPI-3 -4 -5 -6 -7 > Configuration: > DRQ response: 50us. > Packet size: 12 bytes > Capabilities: > LBA, IORDY(cannot be disabled) > DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 > Cycle time: min=120ns recommended=120ns > PIO: pio0 pio1 pio2 pio3 pio4 > Cycle time: no flow control=383ns IORDY flow control=120ns > > BTW, thanks for help all. -- Len Sorensen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-mm1 - list_add corruption in cgroup
On 10/17/07, Cedric Le Goater <[EMAIL PROTECTED]> wrote: > Hello ! > > While polling the contents of a cgroup task file, I caught the > following corruption. Is there a known race (and a fix) or should > I start digging ? > > list_add corruption. next->prev should be prev (80a3f338), but was > 00200200. (next=810103dcbe90). > [ cut here ] > kernel BUG at /home/legoater/linux/2.6.23-mm1/lib/list_debug.c:27! > invalid opcode: [1] SMP > last sysfs file: /devices/pci:00/:00:1e.0/:01:01.0/local_cpus > CPU 3 > Modules linked in: ipt_REJECT iptable_filter autofs4 nfs lockd sunrpc tg3 sg > joydev ext3 jbd ehci_hcd ohci_hcd uhci_hcd > Pid: 2441, comm: bash Not tainted 2.6.23-mm1 #4 > RIP: 0010:[] [] __list_add+0x27/0x5b > RSP: 0018:810103d87dd8 EFLAGS: 00010296 > RAX: 0079 RBX: 810105033040 RCX: 0079 > RDX: 810103d960c0 RSI: 0001 RDI: 0096 > RBP: 810103d87dd8 R08: 0002 R09: 810008123780 > R10: R11: 810103d87a98 R12: > R13: 810105033040 R14: 810104c11ac0 R15: > FS: 7f4e273556f0() GS:81010011a840() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: 006ca2f8 CR3: 000103d82000 CR4: 06e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process bash (pid: 2441, threadinfo 810103d86000, task 810103d960c0) > last branch before last exception/interrupt > from [] printk+0x68/0x69 > to [] __list_add+0x27/0x5b > Stack: 810103d87de8 80308d1a 810103d87e08 802606bf > 810103d87e08 810103d87ea8 80233dca > 810103ddf340 7f4e27355780 810103d87f58 > Call Trace: > [] list_add+0xc/0xe > [] cgroup_post_fork+0x41/0x52 > [] copy_process+0x12d0/0x143a > [] tracesys+0xdc/0xe1 > [] do_fork+0x76/0x203 > [] audit_syscall_entry+0x148/0x17e > [] tracesys+0xdc/0xe1 > [] sys_clone+0x23/0x25 > [] ptregscall_common+0x67/0xb0 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Locking problem in usbserial with 2.6.23-git 5a34417f
On Fri, 19 Oct 2007, Larry Finger wrote:
> As I said earlier, the lock problem went away; however, I get the
> following two kernel warnings:
That's because I messed up the patch, sorry. The one below should work
better.
From: Jiri Kosina <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 88a2c7d..9eb4a65 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -208,14 +208,15 @@ int usb_serial_generic_write(struct usb_serial_port
*port, const unsigned char *
/* only do something if we have a bulk out endpoint */
if (serial->num_bulk_out) {
- spin_lock_bh(&port->lock);
+ unsigned long flags;
+ spin_lock_irqsave(&port->lock, flags);
if (port->write_urb_busy) {
- spin_unlock_bh(&port->lock);
+ spin_unlock_irqrestore(&port->lock, flags);
dbg("%s - already writing", __FUNCTION__);
return 0;
}
port->write_urb_busy = 1;
- spin_unlock_bh(&port->lock);
+ spin_unlock_irqrestore(&port->lock, flags);
count = (count > port->bulk_out_size) ? port->bulk_out_size :
count;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Git pull] arch/x86 updates
On Fri, 19 Oct 2007, Thomas Gleixner wrote:
>
> Pavel Emelyanov (1):
> i386: consolidate show_regs and show_registers for i386
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
On Friday 19 October 2007 22:44:27 Bartlomiej Zolnierkiewicz wrote: > > 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 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 CD OK, but not DVD sometimes on the old drive? hdparm -I /dev/hdd: ATAPI CD-ROM, with removable media Model Number: TSSTcorp CDDVDW SH-S202J Serial Number: Firmware Revision: SB00 Standards: Supported: CD-ROM ATAPI-3 -4 -5 -6 -7 Configuration: DRQ response: 50us. Packet size: 12 bytes Capabilities: LBA, IORDY(cannot be disabled) DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=383ns IORDY flow control=120ns BTW, thanks for help all. Nick -- Free Software Foundation Associate Member 5508 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23] tasks stuck in running state?
Chuck Ebbert wrote: On 10/19/2007 05:39 PM, Jeff Garzik wrote: 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 -sj5 on this box), and it will "hang" in the following way: Can you try to strace the hanging task? Well, to the system it's running, so that doesn't do much of anything... 8482 pts/0S+ 0:00 \_ /bin/sh /garz/repo/misc-2.6/scripts/hdrcheck.sh /garz/repo/misc-2.6/usr/include /garz/repo/misc-2.6/usr/include/linux/kernelcapi.h /garz/repo/misc-2.6/usr/include/linux/.check.kernelcapi.h 8484 pts/0R+ 3:10 \_ grep ^[ \t]*#[ \t]*include[ \t]*< /garz/repo/misc-2.6/usr/include/linux/kernelcapi.h 8486 pts/0S+ 0:00 \_ cut -f2 -d< 8487 pts/0S+ 0:00 \_ cut -f1 -d> 8488 pts/0S+ 0:00 \_ egrep ^linux|^asm [EMAIL PROTECTED] misc-2.6]$ strace -p8484 Process 8484 attached - interrupt to quit [sits there, chewing up CPU grepping a 47-line header file] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
