Re: [PATCH -mm 7/8] user_ns: handle file sigio

[Serge E. Hallyn]

Quoting Andrew Morton ([EMAIL PROTECTED]):
> On Thu, 4 Jan 2007 12:12:57 -0600
> "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> 
> > A process in one user namespace could set a fowner and sigio on a file in a
> > shared vfsmount, ending up killing a task in another user namespace.
> >
> > Prevent this by adding a user namespace pointer to the fown_struct, and
> > enforcing that a process causing a signal to be sent be in the same
> > user namespace as the file owner.
> 
> This patch breaks the X server (stock FC5 install) with CONFIG_USER_NS=n.
> Neither the USB mouse nor the trackpad work.  They work OK under GPM.
> 
> Setting CONFIG_USER_NS=y "fixes" this.  This bug was not observed in
> 2.6.20-rc3-mm1 because that kernel had user-ns-always-on.patch for other
> reasons.  (I'll restore that patch).
> 
> There's nothing very interesting here:
> 
> 
> sony:/home/akpm> diff -u Xorg.0.log.good Xorg.0.log.bad
> --- Xorg.0.log.good 2007-01-11 21:11:11.0 -0800
> +++ Xorg.0.log.bad  2007-01-11 21:17:31.0 -0800
> @@ -6,7 +6,7 @@
>  Release Date: 21 December 2005
>  X Protocol Version 11, Revision 0, Release 7.0
>  Build Operating System:Linux 2.6.9-22.18.bz155725.ELsmp i686Red Hat, Inc.
> -Current Operating System: Linux sony 2.6.20-rc4-mm1 #15 Thu Jan 11 21:07:58 
> PST 2007 i686
> +Current Operating System: Linux sony 2.6.20-rc4-mm1 #16 Thu Jan 11 21:14:03 
> PST 2007 i686
>  Build Date: 22 March 2006
> Before reporting problems, check http://wiki.x.org
> to make sure that you have the latest version.
> @@ -14,7 +14,7 @@
>  Markers: (--) probed, (**) from config file, (==) default setting,
> (++) from command line, (!!) notice, (II) informational,
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> -(==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan 11 21:10:16 2007
> +(==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan 11 21:16:39 2007
>  (==) Using config file: "/etc/X11/xorg.conf"
>  (==) ServerLayout "single head configuration"
>  (**) |-->Screen "Screen0" (0)
> @@ -2117,9 +2117,9 @@
>  (II) I810(0): Allocated 128 kB for the ring buffer at 0x0
>  (II) I810(0): Allocating at least 256 scanlines for pixmap cache
>  (II) I810(0): Initial framebuffer allocation size: 12288 kByte
> -(II) I810(0): Allocated 4 kB for HW cursor at 0x000 (0x35dd3000)
> -(II) I810(0): Allocated 16 kB for HW (ARGB) cursor at 0xfffb000 (0x35e78000)
> -(II) I810(0): Allocated 4 kB for Overlay registers at 0xfffa000 (0x35e39000).
> +(II) I810(0): Allocated 4 kB for HW cursor at 0x000 (0x358d5000)
> +(II) I810(0): Allocated 16 kB for HW (ARGB) cursor at 0xfffb000 (0x35888000)
> +(II) I810(0): Allocated 4 kB for Overlay registers at 0xfffa000 (0x358d7000).
>  (II) I810(0): Allocated 64 kB for the scratch buffer at 0xffea000
>  drmOpenDevice: node name is /dev/dri/card0
>  drmOpenDevice: open result is -1, (No such device or address)
> @@ -2137,8 +2137,8 @@
>  (II) I810(0): [drm] loaded kernel module for "i915" driver
>  (II) I810(0): [drm] DRM interface version 1.3
>  (II) I810(0): [drm] created "i915" driver at busid "pci::00:02.0"
> -(II) I810(0): [drm] added 8192 byte SAREA at 0xf8e46000
> -(II) I810(0): [drm] mapped SAREA 0xf8e46000 to 0xb7eec000
> +(II) I810(0): [drm] added 8192 byte SAREA at 0xf8d4a000
> +(II) I810(0): [drm] mapped SAREA 0xf8d4a000 to 0xb7f23000
>  (II) I810(0): [drm] framebuffer handle = 0xc002
>  (II) I810(0): [drm] added 1 reserved context for kernel
>  (II) I810(0): Allocated 32 kB for the logical context at 0xffe2000.

I can't see any reason for this in the code or comparative ltp runs.
Cedric is testing on a fc6 laptop, hopefully he can reproduce it.

thanks,
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [stable] 2.6.19.2 regression introduced by "IPV4/IPV6: Fix inet{, 6} device initialization order."

[Greg KH]

On Sun, Jan 14, 2007 at 09:30:08PM -0800, David Miller wrote:
> From: David Stevens <[EMAIL PROTECTED]>
> Date: Sun, 14 Jan 2007 19:47:49 -0800
> 
> > I think it's better to add the fix than withdraw this patch, since
> > the original bug is a crash.
> 
> I completely agree.

Great, can someone forward the patch to us?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc4-mm1 md problem

[Ingo Molnar]

* Michal Piotrowski <[EMAIL PROTECTED]> wrote:

> My system hangs on this
> http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc4-mm1/bug2.jpg
> http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc4-mm1/mm-config
> 
> Debug plan:
> - revert md-* patches
> - binary search
> 
> Does someone have a better idea?

Thomas saw something similar yesterday and he the partial results that 
git.block (between rc2-mm1 and rc4-mm1) breaks certain disk drivers or 
filesystems drivers. For me it worked fine, so it must be only on some 
combinations. The changes to ll_rw_block.c look quite extensive.

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: SATA exceptions with 2.6.20-rc5

[Mikael Pettersson]

Björn Steinbrink writes:
 > Hi,
 > 
 > with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite
 > often, with 2.6.19 there are no such exceptions. dmesg and lspci -v
 > output follows. In the meantime, I'll start bisecting.
 > 
 > Thanks
 > Björn
 > 
 > 
 > Linux version 2.6.20-rc2 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 
 > (prerelease) (Debian 4.1.1-21)) #4 SMP Sun Dec 31 12:54:22 CET 2006

[uneventful kernel log omitted]

 > sata_nv :00:07.0: Using ADMA mode
 > PCI: Setting latency timer of device :00:07.0 to 64
 > ata1: SATA max UDMA/133 cmd 0xC2004480 ctl 0xC20044A0 bmdma 
 > 0xD400 irq 23
 > ata2: SATA max UDMA/133 cmd 0xC2004580 ctl 0xC20045A0 bmdma 
 > 0xD408 irq 23
 > scsi0 : sata_nv
 > ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
 > ata1.00: ATA-7, max UDMA/133, 160086528 sectors: LBA 
 > ata1.00: ata1: dev 0 multi count 16
 > ata1.00: configured for UDMA/133
 > scsi1 : sata_nv
 > ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
 > ata2.00: ATA-7, max UDMA/133, 160086528 sectors: LBA 
 > ata2.00: ata2: dev 0 multi count 16
 > ata2.00: configured for UDMA/133
 > scsi 0:0:0:0: Direct-Access ATA  Maxtor 6Y080M0   YAR5 PQ: 0 ANSI: 5
 > ata1: bounce limit 0x, segment boundary 0x, hw segs 
 > 61
 > SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
 > sda: Write Protect is off
 > sda: Mode Sense: 00 3a 00 00
 > SCSI device sda: write cache: enabled, read cache: enabled, doesn't support 
 > DPO or FUA
 > SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
 > sda: Write Protect is off
 > sda: Mode Sense: 00 3a 00 00
 > SCSI device sda: write cache: enabled, read cache: enabled, doesn't support 
 > DPO or FUA
 >  sda: sda1 sda2 sda3
 > sd 0:0:0:0: Attached scsi disk sda
 > scsi 1:0:0:0: Direct-Access ATA  Maxtor 6Y080M0   YAR5 PQ: 0 ANSI: 5
 > ata2: bounce limit 0x, segment boundary 0x, hw segs 
 > 61
 > SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB)
 > sdb: Write Protect is off
 > sdb: Mode Sense: 00 3a 00 00
 > SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
 > DPO or FUA
 > SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB)
 > sdb: Write Protect is off
 > sdb: Mode Sense: 00 3a 00 00
 > SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
 > DPO or FUA
 >  sdb: sdb1 sdb2 sdb3
 > sd 1:0:0:0: Attached scsi disk sdb

Things are fine so far.

[more uneventful kernel log omitted]

 > NVRM: loading NVIDIA Linux x86_64 Kernel Module  1.0-9631  Thu Nov  9 
 > 17:35:27 PST 2006
 > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
 > ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in
 >  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
 > ata1: soft resetting port
 > ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
 > ata1.00: configured for UDMA/133
 > ata1: EH complete
 > SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
 > sda: Write Protect is off
 > sda: Mode Sense: 00 3a 00 00
 > SCSI device sda: write cache: enabled, read cache: enabled, doesn't support 
 > DPO or FUA
 > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
 > ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 out
 >  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

and then things start to break.

Notice how the problems started exactly at the point the
"NVRM" NVIDIA module (whatever it is) was loaded ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc5] intel_rng: substitue magic PCI IDs with macros

[Ahmed S. Darwish]

On Sun, Jan 14, 2007 at 09:37:21AM -0800, Arjan van de Ven wrote:
> On Sun, 2007-01-14 at 19:24 +0200, Ahmed S. Darwish wrote:
> > Substitue intel_rng magic PCI IDs values used in the IDs table
> > with the macros defined in pci_ids.h
> > 
> Hi,
> 
> 
> hmm this is actually the opposite direction than most of the kernel is
> heading in, mostly because the pci_ids.h file is a major maintenance
> pain.
> 
> Afaik the current "rule" is: if a PCI ID is only used in one driver, use
> the numeric value and not (add) a symbolic constant.

I think you understood me wrong .. I haven't added new macros in pci_ids.h,
I've just used the macros already defined there like the PCI_VENDOR_ID_INTEL
and others.

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.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] i386: modpost apic related warning fixes

[Vivek Goyal]

o Modpost generates warnings for i386 if compiled with CONFIG_RELOCATABLE=y

WARNING: vmlinux - Section mismatch: reference to 
.init.text:find_unisys_acpi_oem_table from .text between 'acpi_madt_oem_check' 
(at offset 0xc0101eda) and 'enable_apic_mode'
WARNING: vmlinux - Section mismatch: reference to 
.init.text:acpi_get_table_header_early from .text between 'acpi_madt_oem_check' 
(at offset 0xc0101ef0) and 'enable_apic_mode'
WARNING: vmlinux - Section mismatch: reference to .init.text:parse_unisys_oem 
from .text between 'acpi_madt_oem_check' (at offset 0xc0101f2e) and 
'enable_apic_mode'
WARNING: vmlinux - Section mismatch: reference to .init.text:setup_unisys from 
.text between 'acpi_madt_oem_check' (at offset 0xc0101f37) and 
'enable_apic_mode'WARNING: vmlinux - Section mismatch: reference to 
.init.text:parse_unisys_oem from .text between 'mps_oem_check' (at offset 
0xc0101ec7) and 'acpi_madt_oem_check'
WARNING: vmlinux - Section mismatch: reference to .init.text:es7000_sw_apic 
from .text between 'enable_apic_mode' (at offset 0xc0101f48) and 
'check_apicid_present'

o Some functions which are inline (acpi_madt_oem_check) are not inlined by
  compiler as these functions are accessed using function pointer. These
  functions are put in .text section and they in-turn access __init type
  functions hence modpost generates warnings.

o Do not iniline acpi_madt_oem_check, instead make it __init. 

Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
---

 arch/i386/mach-generic/es7000.c |   41 
 include/asm-i386/mach-es7000/mach_apic.h|7 
 include/asm-i386/mach-es7000/mach_mpparse.h |   32 -
 scripts/mod/modpost.c   |1 
 4 files changed, 42 insertions(+), 39 deletions(-)

diff -puN 
include/asm-i386/mach-es7000/mach_mpparse.h~modpost-apic-related-warning-fixes 
include/asm-i386/mach-es7000/mach_mpparse.h
--- 
linux-2.6.20-rc4-mm1-reloc/include/asm-i386/mach-es7000/mach_mpparse.h~modpost-apic-related-warning-fixes
   2007-01-15 11:30:12.0 +0530
+++ linux-2.6.20-rc4-mm1-reloc-root/include/asm-i386/mach-es7000/mach_mpparse.h 
2007-01-15 11:50:15.0 +0530
@@ -18,18 +18,6 @@ extern int parse_unisys_oem (char *oempt
 extern int find_unisys_acpi_oem_table(unsigned long *oem_addr);
 extern void setup_unisys(void);
 
-static inline int mps_oem_check(struct mp_config_table *mpc, char *oem,
-   char *productid)
-{
-   if (mpc->mpc_oemptr) {
-   struct mp_config_oemtable *oem_table = 
-   (struct mp_config_oemtable *)mpc->mpc_oemptr;
-   if (!strncmp(oem, "UNISYS", 6))
-   return parse_unisys_oem((char *)oem_table);
-   }
-   return 0;
-}
-
 #ifdef CONFIG_ACPI
 static inline int es7000_check_dsdt(void)
 {
@@ -40,26 +28,6 @@ static inline int es7000_check_dsdt(void
return 1;
return 0;
 }
-
-/* Hook from generic ACPI tables.c */
-static inline int acpi_madt_oem_check(char *oem_id, char *oem_table_id)
-{
-   unsigned long oem_addr; 
-   if (!find_unisys_acpi_oem_table(_addr)) {
-   if (es7000_check_dsdt())
-   return parse_unisys_oem((char *)oem_addr);
-   else {
-   setup_unisys();
-   return 1;
-   }
-   }
-   return 0;
-}
-#else
-static inline int acpi_madt_oem_check(char *oem_id, char *oem_table_id)
-{
-   return 0;
-}
 #endif
 
 #endif /* __ASM_MACH_MPPARSE_H */
diff -puN arch/i386/mach-generic/es7000.c~modpost-apic-related-warning-fixes 
arch/i386/mach-generic/es7000.c
--- 
linux-2.6.20-rc4-mm1-reloc/arch/i386/mach-generic/es7000.c~modpost-apic-related-warning-fixes
   2007-01-15 11:30:12.0 +0530
+++ linux-2.6.20-rc4-mm1-reloc-root/arch/i386/mach-generic/es7000.c 
2007-01-15 11:56:18.0 +0530
@@ -25,4 +25,45 @@ static int probe_es7000(void)
return 0;
 }
 
+extern void es7000_sw_apic(void);
+static void __init enable_apic_mode(void)
+{
+   es7000_sw_apic();
+   return;
+}
+
+static __init int mps_oem_check(struct mp_config_table *mpc, char *oem,
+   char *productid)
+{
+   if (mpc->mpc_oemptr) {
+   struct mp_config_oemtable *oem_table =
+   (struct mp_config_oemtable *)mpc->mpc_oemptr;
+   if (!strncmp(oem, "UNISYS", 6))
+   return parse_unisys_oem((char *)oem_table);
+   }
+   return 0;
+}
+
+#ifdef CONFIG_ACPI
+/* Hook from generic ACPI tables.c */
+static int __init acpi_madt_oem_check(char *oem_id, char *oem_table_id)
+{
+   unsigned long oem_addr;
+   if (!find_unisys_acpi_oem_table(_addr)) {
+   if (es7000_check_dsdt())
+   return parse_unisys_oem((char *)oem_addr);
+   else {
+   setup_unisys();
+   return 1;
+   }
+   }
+   return 0;
+}

Re: allocation failed: out of vmalloc space error treating and VIDEO1394 IOC LISTEN CHANNEL ioctl failed problem

[Peter Antoniac]

On Monday 15 January 2007 13:14, Peter Antoniac wrote:
> This is more the answer that I expect. But is there a way, function or
> constant from **libdc** that can give you the answer, or you have to get it
...
What was I thinking... not from libdc but from LIBC :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-fbdev-devel] How to mmap a shadow framebuffer in virtual memory

[Bernardo Innocenti]

Geert Uytterhoeven wrote:

> It's known to work for the PS3 frame buffer device driver, which copies the
> virtual frame buffer to the GPU on every vsync. Check out ps3fb_mmap() in
> http://www.kernel.org/git/?p=linux/kernel/git/geoff/ps3-linux.git;a=blob_plain;f=drivers/video/ps3fb.c;hb=HEAD

I still couldn't solve my problem, but thanks for helping.

The way you map memory in ps3fb_mmap() is basically the same.
In my case, memory is allocated with __get_free_pages() instead
of being at an absolute physical address, but I can't see how
it could make any difference.

-- 
   // Bernardo Innocenti - Develer S.r.l., R dept.
 \X/  http://www.develer.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/

[GIT PULL] MMC updates

[Pierre Ossman]

Linus, please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git
for-linus

to receive the following updates:

 drivers/mmc/imxmmc.c|3 ---
 drivers/mmc/omap.c  |   15 +--
 drivers/mmc/pxamci.c|2 +-
 drivers/mmc/tifm_sd.c   |3 ---
 include/linux/mmc/mmc.h |2 +-
 5 files changed, 11 insertions(+), 14 deletions(-)

Carlos Eduardo Aguiar (1):
  omap: Update MMC response types

Philip Langdale (1):
  mmc: Correct definition of R6

diff --git a/drivers/mmc/imxmmc.c b/drivers/mmc/imxmmc.c
index 06e7fcd..bfb9ff6 100644
--- a/drivers/mmc/imxmmc.c
+++ b/drivers/mmc/imxmmc.c
@@ -351,9 +351,6 @@ static void imxmci_start_cmd(struct imxmci_host
*host, struct mmc_command *cmd,
case MMC_RSP_R3: /* short */
cmdat |= CMD_DAT_CONT_RESPONSE_FORMAT_R3;
break;
-   case MMC_RSP_R6: /* short CRC */
-   cmdat |= CMD_DAT_CONT_RESPONSE_FORMAT_R6;
-   break;
default:
break;
}
diff --git a/drivers/mmc/omap.c b/drivers/mmc/omap.c
index 9488408..d30540b 100644
--- a/drivers/mmc/omap.c
+++ b/drivers/mmc/omap.c
@@ -91,7 +91,6 @@


 #define DRIVER_NAME "mmci-omap"
-#define RSP_TYPE(x)((x) & ~(MMC_RSP_BUSY|MMC_RSP_OPCODE))

 /* Specifies how often in millisecs to poll for card status changes
  * when the cover switch is open */
@@ -204,18 +203,22 @@ mmc_omap_start_command(struct mmc_omap_host *host,
struct mmc_command *cmd)
cmdtype = 0;

/* Our hardware needs to know exact type */
-   switch (RSP_TYPE(mmc_resp_type(cmd))) {
-   case RSP_TYPE(MMC_RSP_R1):
-   /* resp 1, resp 1b */
+   switch (mmc_resp_type(cmd)) {
+   case MMC_RSP_NONE:
+   break;
+   case MMC_RSP_R1:
+   case MMC_RSP_R1B:
+   /* resp 1, 1b, 6, 7 */
resptype = 1;
break;
-   case RSP_TYPE(MMC_RSP_R2):
+   case MMC_RSP_R2:
resptype = 2;
break;
-   case RSP_TYPE(MMC_RSP_R3):
+   case MMC_RSP_R3:
resptype = 3;
break;
default:
+   dev_err(mmc_dev(host->mmc), "Invalid response type:
%04x\n", mmc_resp_type(cmd));
break;
}

diff --git a/drivers/mmc/pxamci.c b/drivers/mmc/pxamci.c
index 45a9283..6073d99 100644
--- a/drivers/mmc/pxamci.c
+++ b/drivers/mmc/pxamci.c
@@ -171,7 +171,7 @@ static void pxamci_start_cmd(struct pxamci_host
*host, struct mmc_command *cmd,

 #define RSP_TYPE(x)((x) & ~(MMC_RSP_BUSY|MMC_RSP_OPCODE))
switch (RSP_TYPE(mmc_resp_type(cmd))) {
-   case RSP_TYPE(MMC_RSP_R1): /* r1, r1b, r6 */
+   case RSP_TYPE(MMC_RSP_R1): /* r1, r1b, r6, r7 */
cmdat |= CMDAT_RESP_SHORT;
break;
case RSP_TYPE(MMC_RSP_R3):
diff --git a/drivers/mmc/tifm_sd.c b/drivers/mmc/tifm_sd.c
index f18ad99..fa4a528 100644
--- a/drivers/mmc/tifm_sd.c
+++ b/drivers/mmc/tifm_sd.c
@@ -173,9 +173,6 @@ static unsigned int tifm_sd_op_flags(struct
mmc_command *cmd)
case MMC_RSP_R3:
rc |= TIFM_MMCSD_RSP_R3;
break;
-   case MMC_RSP_R6:
-   rc |= TIFM_MMCSD_RSP_R6;
-   break;
default:
BUG();
}
diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
index a3594df..bcf2490 100644
--- a/include/linux/mmc/mmc.h
+++ b/include/linux/mmc/mmc.h
@@ -42,7 +42,7 @@ struct mmc_command {
 #define MMC_RSP_R1B
(MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE|MMC_RSP_BUSY)
 #define MMC_RSP_R2 (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC)
 #define MMC_RSP_R3 (MMC_RSP_PRESENT)
-#define MMC_RSP_R6 (MMC_RSP_PRESENT|MMC_RSP_CRC)
+#define MMC_RSP_R6 (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE)

 #define mmc_resp_type(cmd) ((cmd)->flags &
(MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY|MMC_RSP_OPCODE))


-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.19.2 regression introduced by "IPV4/IPV6: Fix inet{,6} device initialization order."

[David Miller]

From: David Stevens <[EMAIL PROTECTED]>
Date: Sun, 14 Jan 2007 19:47:49 -0800

> I think it's better to add the fix than withdraw this patch, since
> the original bug is a crash.

I completely agree.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: allocation failed: out of vmalloc space error treating and VIDEO1394 IOC LISTEN CHANNEL ioctl failed problem

[Peter Antoniac]

On Monday 15 January 2007 05:31, Stefan Richter wrote:
> On 14 Jan, Arjan van de Ven wrote:
> > vmalloc space is limited; you really can't assume you can get any more
> > than 64Mb or so (and even then it's thight on some systems already);
>
> I suppose "grep VmallocChunk /proc/meminfo" shows what is available?

This is more the answer that I expect. But is there a way, function or 
constant from libdc that can give you the answer, or you have to get it from 
the /proc/meminfo? Now, if you can only get it from the /proc/meminfo, is 
this info always there? As far as I remember, you can compile kernels without 
the /proc/meminfo...

And yes, probably we would have to get rid of this issue and look for an 
alternative way. Still, from a technical point of view, I am really curious 
if this information on the size of VmallocChunk is available to the developer 
in other forms...

Thank you all!

Cheers,
Peter

> > it really sounds like vmalloc space isn't the right solution for your
> > problem whatever it is (context is lost in the quoted mail)...
> > can you restate the problem to see if there's a better solution
> > possible?
>
> Thanks. Below is Peter's message to linux1394-devel. The previous
> discussion went over libdc1394-devel which I don't receive. Obviously he
> wants a really large buffer for reception of an isochronous stream. I
> guess his reason is highly application specific...
>
> | Hi all,
> |
> | I've been trying to get a resolution to the problem with vmalloc error
> | (the < to
> | increase size.>> kernel error message thing). The plan how to resolve the
> | issue is simple; get the buffer size that we try to allocate
> | (vmmap.nb_buffers * vmmap.buf_size) and compare it to the
> | VMALLOC_RESERVED. If too big, error with explanation how to fix it. If
> | small, other error (usual out of mem). Problem is: how to get the
> | VMALLOC_RESERVED value for the kernel that is running? I couldn't find
> | any standard way to do that (something to apply to GNU Linux and the
> | like). All the things I could get were the default value being 128MiB :)
> | and that is it. Now, I could just put 128, but what if somebody changes
> | that, or in some new distro suddenly decides to make it different? Even
> | worse, what if it is an old kernel with 64 setting?
> |
> | Currently, in the SVN version, Damien was kind to change so that a
> | message gets printed with a full explanation of how to treat it. Still,
> | this is a compromise solution and not the elegant one that I was looking
> | for. I believe and hope that maybe somebody had this issue before and
> | could help with some suggestions...
> |
> | So, my question is: anybody knows the way to get to the kernel value like
> | VMALLOC_RESERVED or something around this area (a function like
> | getpagesize or sysconf)? It will do a great deal to solve the problematic
> | error treatment in the library...
> |
> | Thank you.
> |
> | For your reference, this is in response to this line of thinking or the
> | libdc1394-devel thread:
> | [...]
> |
> | > > When I set NUM_BUFFERS (number of DMA buffers) to a value greater
> | > > than 5 the program dies like this:
> | > >
> | > > (dc1394_capture.c) VIDEO1394_IOC_LISTEN_CHANNEL ioctl failed!
> | > > Libdc1394 error (dc1394_capture.c:dc1394_capture_setup_dma:382):
> | > > Capture is not set : Could not setup DMA capture
> |
> | [...]
> |
> | > > [17723533.496000] video1394_0: Iso receive DMA: 8 buffers of size
> | > > 6627328 allocated for a frame size 6624000, each with 1619 prgs
> | > > [17723533.516000] video1394_0: iso context 0 listen on channel 1
> | > > [17723533.712000] ieee1394: Node [1-01:1023] wants to release
> | > > broadcast channel 31.  Ignoring.
> | > > [17723534.448000] video1394_1: mask: 0004 usage:
> | > > 
> | > > [17723534.448000]
> | > > [17723534.508000] video1394_1: Iso receive DMA: 8 buffers of size
> | > > 6627328 allocated for a frame size 6624000, each with 1619 prgs
> | > > [17723534.532000] video1394_1: iso context 0 listen on channel 2
> | > > [17723534.728000] ieee1394: Node [2-01:1023] wants to release
> | > > broadcast channel 31.  Ignoring.
> | > > [17723535.464000] video1394_2: mask: 0008 usage:
> | > > 
> | > > [17723535.464000]
> | > > [17723535.464000] printk: 11 messages suppressed.
> | > > [17723535.464000] allocation failed: out of vmalloc space - use
> | > > vmalloc= to increase size.
> | > > [17723535.464000] dma_region_alloc: vmalloc_32() failed
> | > > [17723535.464000] video1394_2: Failed to allocate dma buffer
> | > > [17723535.464000] video1394_2: Couldn't allocate ir context
> | > > [17723535.668000] video1394_0: On release: Iso receive context 0 stop
> | > > listening on channel 1
> | > > [17723535.676000] video1394_1: On release: Iso receive context 0 stop
> | > > listening on channel 2
> |
> | [...]
> |
> | > --
> | >
> | > Message: 2
> | > Date: Fri, 05 Jan 2007 17:30:39 

Re: [PATCH] flush_cpu_workqueue: don't flush an empty ->worklist

[Srivatsa Vaddagiri]

On Mon, Jan 15, 2007 at 02:54:10AM +0300, Oleg Nesterov wrote:
> How about the pseudo-code below?

Some quick comments:

- singlethread_cpu needs to be hotplug safe (broken currently)

- Any reason why cpu_populated_map is not modified on CPU_DEAD?

- I feel more comfortable if workqueue_cpu_callback were to take
  workqueue_mutex in LOCK_ACQ and release it in LOCK_RELEASE 
  notifications. This will provide stable access to cpu_populated_map
  to functions like __create_workqueue.

Finally, I wonder if these changes will be unnecessary if we move to
process freezer based hotplug locking ...

-- 
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: ahci_softreset prevents acpi_power_off

[Tejun Heo]

Arjan van de Ven wrote:
> I'd be interested in finding out how to best test this; if the bios is
> really broken I'd love to add a test to the Linux-ready Firmware
> Developer Kit for this, so that BIOS developers can make sure future
> bioses do not suffer from this bug...

As reported, this is almost a butterfly effect.  ->softreset method is
only used during initialization and error recovery of ATA devices which
has almost nothing to do with the rest of the system.  This is almost
like 'changing my mixer input to line-in makes power off fail'.  (it's
more related due to ATA ACPI stuff and maybe that's why this happens but
I'm trying to make a point here.)

I'm not sure the test can be generalized and included in the firmware
devel kit.  This is a really really special obscure corner case bug
which, I believe, none will be able to recreate in the future unless the
same code is reused.  So, I think the right course of action is to bug
the manufacturer.  Eh Does that work with sony these days?

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -mm] AVR32: fix build breakage

[Ben Nizette]

Remove an unwanted remnant of the recent revert of AVR32/AT91 SPI 
patches in -mm.  Without this patch, the AVR32 build of 
2.6.20-rc[34]-mm1 breaks.


Signed-off-by: Ben Nizette <[EMAIL PROTECTED]>
---
Index: linux-2.6.20-rc3/arch/avr32/mach-at32ap/at32ap7000.c
===
--- linux-2.6.20-rc3.orig/arch/avr32/mach-at32ap/at32ap7000.c	2007-01-11 
17:29:01.0 +1100
+++ linux-2.6.20-rc3/arch/avr32/mach-at32ap/at32ap7000.c	2007-01-11 
17:29:18.0 +1100

@@ -895,7 +895,7 @@
_pclk,
_hclk,
_pclk,
-   _spi0_mck,
+   _spi0_pclk,
_spi1_pclk,
_hclk,
_pixclk,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.19.2 regression introduced by "IPV4/IPV6: Fix inet{,6} device initialization order."

[David Stevens]

I expect this is the failure to join the all-nodes multicast group,
in which case the fix has already been posted to netdev. I
believe the router advertisements are sent to that, and if the
join failed, it wouldn't receive any of them.

I think it's better to add the fix than withdraw this patch, since
the original bug is a crash.

Details:
The IPv6 code passes the "dev" entry to the multicast group
incrementer and uses it to dereference to get the in6_dev.
IPv4, by contrast, passes the in_dev directly to its equivalent
functions.

IPv6 joins the required "all-nodes" multicast group in the
multicast device initialization function, which due to the fix
won't have a dev entry at that time. The patch posted by
Yoshifuji Hideaki moves the all-nodes join until after the
ip6_ptr is added to the dev.

+-DLS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.19.2 regression introduced by "IPV4/IPV6: Fix inet{,6} device initialization order."

[Daniel Drake]

Hi,

The patch titled "IPV4/IPV6: Fix inet{,6} device initialization order" 
shipped in 2.6.19.2 appears to be the cause of this regression:


https://bugs.gentoo.org/show_bug.cgi?id=161907

Is this a known issue? Should this patch be dropped from -stable?

Thanks,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Proposed changes for libata speed handling

[Tejun Heo]

Alan wrote:
> O> Wouldn't it be better to have ->determine_xfer_mask() and
>> ->set_specific_mode() than having two somewhat overlapping callbacks?
>> Or is there some problem that can't be handled that way?
> 
> I'm not sure I follow what you are suggesting - can you explain further.
> 
> Right now ->set_mode does all the policy management with regards to
> picking the right modes which is sometimes done by the usual ATA rules
> and sometimes by card specific code.
> 
> ->set_specific_mode does no policy work but merely sets up a mode.
> 
> The default behaviour of ->set_mode() is the ATA mode selection by best
> mode available, and this function is normally not provided by a driver.
> 
> The default behaviour of ->set_specific_mode() is to verify the mode is
> valid then issue ->set_pio|dma_mode() (for both devices in case a timing
> change on both is triggered). This function is overridable because of
> things like IT821x where the IDE mode is imaginary.

What I was thinking about was something like the following.

* ops

unsigned int (*determine_xfer_mask)(struct ata_device *dev);
int (*set_specific_mode)(struct ata_device *dev,
unsigned int xfer_mode);

* during init and EH

if (init) {
ap->xfer_mask &= ops->determine_xfer_mask(dev);
DETERMINE best_mode;
}

if (ap->ehi.target_mode && valid)
mode = ap->ehi.target_mode;
else
mode = best_mode;

rc = ops->set_specific_mode(dev, mode);

* when the user issues SET_XFERMODE, in the issue path

if (command is SET_XFERMODE) {
if (mode is invalid)
fail;
ap->ehi.target_mode = user_specified_mode;
ata_port_schedule_eh(ap);
done;
}

To sum up,

1. separate supported mode detection and mode programming such that we
can use the same programming path for both init and handling user-issued
SET_XFERMODE.

2. group all mode programming callbacks (->set_piomode, ->set_dmamode
and ->post_set_mode into ->set_specific_mode) into ->set_specific_mode
to allow more flexibility and replace ->set_mode.

3. make sure all xfer mode programming is done in EH.  this will ease
support for weird controllers (e.g. cross-port synchronization).

Thanks.

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] bonding: Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls

[joe jin]

> Hi Joe,
> 
> On 1/12/07, joe jin <[EMAIL PROTECTED]> wrote:
> > @@ -788,7 +786,7 @@ static int rlb_initialize(struct bonding
> >
> > spin_lock_init(&(bond_info->rx_hashtbl_lock));
> >
> > -   new_hashtbl = kmalloc(size, GFP_KERNEL);
> > +   new_hashtbl = kzalloc(size, GFP_KERNEL);
> > if (!new_hashtbl) {
> > printk(KERN_ERR DRV_NAME
> >": %s: Error: Failed to allocate RLB hash table\n",
> 
> You forgot to remove the memset here.

Here is not a memset :)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA exceptions with 2.6.20-rc5

[Jens Axboe]

On Sun, Jan 14 2007, Robert Hancock wrote:
> Jeff Garzik wrote:
> >>Looks like all of these errors are from a FLUSH CACHE command and the 
> >>drive is indicating that it is no longer busy, so presumably done. 
> >>That's not a DMA-mapped command, so it wouldn't go through the ADMA 
> >>machinery and I wouldn't have expected this to be handled any 
> >>differently from before. Curious..
> >
> >It's possible the flush-cache command takes longer than 30 seconds, if 
> >the cache is large, contents are discontiguous, etc.  It's a 
> >pathological case, but possible.
> >
> >Or maybe flush-cache doesn't get a 30 second timeout, and it should...? 
> > (thinking out loud)
> >
> >Jeff
> 
> If the flush was still in progress I would expect Busy to still be set, 
> however..

I'd be surprised if the device would not obey the 7 second timeout rule
that seems to be set in stone and not allow more dirty in-drive cache
than it could flush out in approximately that time.

And BUSY should also be set for that case, as Robert indicates.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA exceptions with 2.6.20-rc5

[Björn Steinbrink]

On 2007.01.15 01:34:48 +0100, Björn Steinbrink wrote:
> On 2007.01.14 19:22:51 -0500, Jeff Garzik wrote:
> > Robert Hancock wrote:
> > >Björn Steinbrink wrote:
> > >>Hi,
> > >>
> > >>with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite
> > >>often, with 2.6.19 there are no such exceptions. dmesg and lspci -v
> > >>output follows. In the meantime, I'll start bisecting.
> > >
> > >...
> > >
> > >>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> > >>ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in
> > >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> > >>ata1: soft resetting port
> > >>ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > >>ata1.00: configured for UDMA/133
> > >>ata1: EH complete
> > >>SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
> > >>sda: Write Protect is off
> > >>sda: Mode Sense: 00 3a 00 00
> > >>SCSI device sda: write cache: enabled, read cache: enabled, doesn't 
> > >>support DPO or FUA
> > >
> > >Looks like all of these errors are from a FLUSH CACHE command and the 
> > >drive is indicating that it is no longer busy, so presumably done. 
> > >That's not a DMA-mapped command, so it wouldn't go through the ADMA 
> > >machinery and I wouldn't have expected this to be handled any 
> > >differently from before. Curious..
> > 
> > It's possible the flush-cache command takes longer than 30 seconds, if 
> > the cache is large, contents are discontiguous, etc.  It's a 
> > pathological case, but possible.
> > 
> > Or maybe flush-cache doesn't get a 30 second timeout, and it should...? 
> >  (thinking out loud)
> 
> Bi-section led to commit 249e83fe839 which makes absolutely no sense to
> me, just in case that anyone sees any problem with that commit.
> I'll go and re-check a few of those commits that I marked as good.

Next round of bisecting led to another useless result, a) it was an
unrelated driver, b) the kernel I just marked as good after 20 minutes
of testing decided to fail when I hit reply... Guess that it was pure
luck that the kernel I marked as bad failed within 1-2 minutes.
I send the git bisect log with this mail, maybe at least the early good
kernel are really good and someone can make some sense out of it. At
least I ended up somewhere in a series of libata changes.

Thanks,
Björn

git-bisect start
# bad: [8a2d17a56a71c5c796b0a5378ee76a105f21fdd9] Linux 2.6.20-rc2
git-bisect bad 8a2d17a56a71c5c796b0a5378ee76a105f21fdd9
# good: [c3fe6924620fd733ffe8bc8a9da1e9cde08402b3] Linux 2.6.19
git-bisect good c3fe6924620fd733ffe8bc8a9da1e9cde08402b3
# bad: [2685b267bce34c9b66626cb11664509c32a761a5] Merge 
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
git-bisect bad 2685b267bce34c9b66626cb11664509c32a761a5
# good: [a985239bdf017e00e985c3a31149d6ae128fdc5f] [POWERPC] cell: spu 
management xmon routines
git-bisect good a985239bdf017e00e985c3a31149d6ae128fdc5f
# bad: [33f2ef89f8e181486b63fdbdc97c6afa6ca9f34b] mm: make compound page 
destructor handling explicit
git-bisect bad 33f2ef89f8e181486b63fdbdc97c6afa6ca9f34b
# bad: [651857a1ecaf97a8ad9d324dd2a61675c53e541e] Merge branch 'upstream-linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2
git-bisect bad 651857a1ecaf97a8ad9d324dd2a61675c53e541e
# bad: [ff51a98799931256b555446b2f5675db08de6229] Merge branch 'upstream-linus' 
of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev
git-bisect bad ff51a98799931256b555446b2f5675db08de6229
# bad: [3ac551a6a63dcbc707348772a27bd7090b081524] [libata] pata_cs5535: fix 
build
git-bisect bad 3ac551a6a63dcbc707348772a27bd7090b081524
# good: [750426aa1ad1ddd1fa8bb4ed531a7956f3b9a27c] libata: cosmetic changes to 
sense generation functions
git-bisect good 750426aa1ad1ddd1fa8bb4ed531a7956f3b9a27c
# good: [62d64ae0ec76360736c9dc4ca2067ae8de0ba9f2] pata : more drivers that 
need only standard suspend and resume
git-bisect good 62d64ae0ec76360736c9dc4ca2067ae8de0ba9f2
# good: [6a36261e63770ab61422550b774fe949ccca5fa9] libata: fix READ CAPACITY 
simulation
git-bisect good 6a36261e63770ab61422550b774fe949ccca5fa9
# good: [2432697ba0ce312d60be5009ffe1fa054a761bb9] libata: implement 
ata_exec_internal_sg()
git-bisect good 2432697ba0ce312d60be5009ffe1fa054a761bb9
# good: [70e6ad0c6d1e6cb9ee3c036a85ca2561eb1fd766] libata: prepare 
ata_sg_clean() for invocation from EH
git-bisect good 70e6ad0c6d1e6cb9ee3c036a85ca2561eb1fd766
# good: [8e16f941226f15622fbbc416a1f3d8705001a191] ahci: do not powerdown 
during initialization
git-bisect good 8e16f941226f15622fbbc416a1f3d8705001a191
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 -mm] sata_nv: cleanup ADMA error handling

[Robert Hancock]

Should apply to -mm tree or current libata-dev git tree. Sorry for 
attaching, but I seem to have misplaced the magic incantations to make 
Thunderbird not destroy inline patches..


---

This cleans up a few issues with the error handling in sata_nv in ADMA 
mode to make it more consistent with other NCQ-capable drivers like ahci 
and sata_sil24:


-When a command failed, we would effectively set AC_ERR_DEV on the 
queued command always. In the case of NCQ commands this prevents libata 
from doing a log page query to determine the details of the failed 
command, since it thinks we've already analyzed. Just set flags in the 
port ehi->err_mask, then freeze or abort and let libata figure out what 
went wrong.


-The code handled NV_ADMA_STAT_CPBERR as a "really bad error" which 
caused it to set error flags on every queued command. I don't know 
exactly what this flag means (no docs, grr!) but from what I can guess 
from the standard ADMA spec, it just means that one or more of the CPBs 
had an error, so we just need to go through and do our normal checks in 
this case.


-In the error_handler function the code would always go through and do 
an ADMA channel reset and also dump out the state of all the CPBs. This 
reset seems heinous in this situation since we haven't even decided to 
reset anything yet. The output seems redundant at this point since 
libata already dumps the state of all active commands on errors (and it 
also triggers at times when it shouldn't, like when suspending). Do the 
ADMA reset only on hardreset and remove the output.


Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

--- linux-2.6.20-rc5/drivers/ata/sata_nv.c  2007-01-12 23:18:08.0 
-0600
+++ linux-2.6.20-rc5edit/drivers/ata/sata_nv.c  2007-01-14 20:08:35.0 
-0600
@@ -646,53 +646,64 @@ static unsigned int nv_adma_tf_to_cpb(st
return idx;
 }
 
-static void nv_adma_check_cpb(struct ata_port *ap, int cpb_num, int force_err)
+static int nv_adma_check_cpb(struct ata_port *ap, int cpb_num, int force_err)
 {
struct nv_adma_port_priv *pp = ap->private_data;
-   int complete = 0, have_err = 0;
u8 flags = pp->cpb[cpb_num].resp_flags;
 
VPRINTK("CPB %d, flags=0x%x\n", cpb_num, flags);
 
-   if (flags & NV_CPB_RESP_DONE) {
-   VPRINTK("CPB flags done, flags=0x%x\n", flags);
-   complete = 1;
-   }
-   if (flags & NV_CPB_RESP_ATA_ERR) {
-   ata_port_printk(ap, KERN_ERR, "CPB flags ATA err, 
flags=0x%x\n", flags);
-   have_err = 1;
-   complete = 1;
-   }
-   if (flags & NV_CPB_RESP_CMD_ERR) {
-   ata_port_printk(ap, KERN_ERR, "CPB flags CMD err, 
flags=0x%x\n", flags);
-   have_err = 1;
-   complete = 1;
-   }
-   if (flags & NV_CPB_RESP_CPB_ERR) {
-   ata_port_printk(ap, KERN_ERR, "CPB flags CPB err, 
flags=0x%x\n", flags);
-   have_err = 1;
-   complete = 1;
+   if(unlikely((force_err ||
+flags & (NV_CPB_RESP_ATA_ERR |
+ NV_CPB_RESP_CMD_ERR |
+ NV_CPB_RESP_CPB_ERR {
+   struct ata_eh_info *ehi = >eh_info;
+   int freeze = 0;
+   ata_ehi_clear_desc(ehi);
+   ata_ehi_push_desc(ehi, "CPB resp_flags 0x%x", flags );
+   if(flags & NV_CPB_RESP_ATA_ERR) {
+   ata_ehi_push_desc(ehi, ": ATA error");
+   ehi->err_mask |= AC_ERR_DEV;
+   }
+   else if(flags & NV_CPB_RESP_CMD_ERR) {
+   ata_ehi_push_desc(ehi, ": CMD error");
+   ehi->err_mask |= AC_ERR_DEV;
+   }
+   else if(flags & NV_CPB_RESP_CPB_ERR) {
+   ata_ehi_push_desc(ehi, ": CPB error");
+   ehi->err_mask |= AC_ERR_SYSTEM;
+   freeze = 1;
+   }
+   else {
+   /* notifier error, but no error in CPB flags? */
+   ehi->err_mask |= AC_ERR_OTHER;
+   freeze = 1;
+   }
+   /* Kill all commands. EH will determine what actually failed. */
+   if(freeze)
+   ata_port_freeze(ap);
+   else
+   ata_port_abort(ap);
+   return 1;
}
-   if(complete || force_err)
-   {
+   
+   if (flags & NV_CPB_RESP_DONE) {
struct ata_queued_cmd *qc = ata_qc_from_tag(ap, cpb_num);
+   VPRINTK("CPB flags done, flags=0x%x\n", flags);
if(likely(qc)) {
-   u8 ata_status = 0;
-   /* Only use the ATA port status for non-NCQ commands.
+   /* Grab the ATA port status for non-NCQ commands.
   For NCQ commands the current status may have nothing 
to do 

Re: SATA exceptions with 2.6.20-rc5

[Robert Hancock]

Jeff Garzik wrote:
Looks like all of these errors are from a FLUSH CACHE command and the 
drive is indicating that it is no longer busy, so presumably done. 
That's not a DMA-mapped command, so it wouldn't go through the ADMA 
machinery and I wouldn't have expected this to be handled any 
differently from before. Curious..


It's possible the flush-cache command takes longer than 30 seconds, if 
the cache is large, contents are discontiguous, etc.  It's a 
pathological case, but possible.


Or maybe flush-cache doesn't get a 30 second timeout, and it should...? 
 (thinking out loud)


Jeff


If the flush was still in progress I would expect Busy to still be set, 
however..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA hotplug from the user side ?

[Tejun Heo]

Soeren Sonnenburg wrote:
> Jeff & Tejun thanks *a lot* for clarifying this. I am quite happy to see
> that this is working very reliably!

You're welcome.  :-)

>>> These messages sound eval - so now the question is should I care ?
>>> ( On the other hand it did not crash the machine )
>> So, no, you don't really have to care.  Just make sure the device is
>> unmounted prior to unplugging.
> 
> OK, but then this really should be in the SATA hotplug FAQ (or can one
> fix this somehow?)... No user will ignore messages like this. What is

Yeah, probably.  Care to submit patch to FAQ to Jeff?

> especially annoying is that udev on the first remove/insert cycle
> created a new device node so the disk became /dev/sde (was /dev/sdd):
> dmesg output of reinserting the disk 2 times follows:

That's because something is still holding onto /dev/sdd.  The device
remains dangled until all references to it are gone.  /dev/sdd is still
lingering when the drive is hotplugged; thus, it gets assigned the next
device.

I think this is best solved by udev.  Think of /dev/sdX as kernel
internal name which may change from time to time.  Mount devices with
LABEL's and use udev-provided persistent names to access removable
devices.  Also, libata can be improved to tell udev that certain ports
are external, I think.

Thanks.

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Cell SPU task notification

[Michael Ellerman]

> Subject: Enable SPU switch notification to detect currently active SPU tasks.
> 
> From: Maynard Johnson <[EMAIL PROTECTED]>
> 
> This patch adds to the capability of spu_switch_event_register so that the
> caller is also notified of currently active SPU tasks.  It also exports
> spu_switch_event_register and spu_switch_event_unregister.

Hi Maynard,

It'd be really good if you could convince your mailer to send patches inline :)

> Index: 
> linux-2.6.19-rc6-arnd1+patches/arch/powerpc/platforms/cell/spufs/sched.c
> ===
> --- 
> linux-2.6.19-rc6-arnd1+patches.orig/arch/powerpc/platforms/cell/spufs/sched.c 
> 2006-12-04 10:56:04.730698720 -0600
> +++ linux-2.6.19-rc6-arnd1+patches/arch/powerpc/platforms/cell/spufs/sched.c  
> 2007-01-11 09:45:37.918333128 -0600
> @@ -46,6 +46,8 @@
>  
>  #define SPU_MIN_TIMESLICE(100 * HZ / 1000)
>  
> +int notify_active[MAX_NUMNODES];

You're basing the size of the array on MAX_NUMNODES
(1 << CONFIG_NODES_SHIFT), but then indexing it by spu->number.

It's quite possible we'll have a system with MAX_NUMNODES == 1, but > 1
spus, in which case this code is going to break. The PS3 is one such
system.

Instead I think you should have a flag in the spu struct.

>  #define SPU_BITMAP_SIZE (((MAX_PRIO+BITS_PER_LONG)/BITS_PER_LONG)+1)
>  struct spu_prio_array {
>   unsigned long bitmap[SPU_BITMAP_SIZE];
> @@ -81,18 +83,45 @@
>  static void spu_switch_notify(struct spu *spu, struct spu_context *ctx)
>  {
>   blocking_notifier_call_chain(_switch_notifier,
> - ctx ? ctx->object_id : 0, spu);
> +  ctx ? ctx->object_id : 0, spu);
> +}

Try not to make whitespace only changes in the same patch as actual code 
changes.

> +
> +static void notify_spus_active(void)
> +{
> + int node;
> + /* Wake up the active spu_contexts. When the awakened processes 
> +  * sees their notify_active flag is set, they will call
> +  * spu_notify_already_active().
> +  */
> + for (node = 0; node < MAX_NUMNODES; node++) {
> + struct spu *spu;
> + mutex_lock(_prio->active_mutex[node]);
> +list_for_each_entry(spu, _prio->active_list[node], list) 
> {
> + struct spu_context *ctx = spu->ctx;
> + wake_up_all(>stop_wq);
> + notify_active[ctx->spu->number] = 1;
> + smp_mb();
> + }

I don't understand why you're setting the notify flag after you do the
wake_up_all() ?

You only need a smp_wmb() here.

Does the scheduler guarantee that ctxs won't swap nodes? Otherwise
between releasing the lock on one node and getting the lock on the next,
a ctx could migrate between them - which would cause either spurious
wake ups, or missing a ctx altogether. Although I'm not sure if it's
that important.

> +mutex_unlock(_prio->active_mutex[node]);
> + }
> + yield();
>  }
>  
>  int spu_switch_event_register(struct notifier_block * n)
>  {
> - return blocking_notifier_chain_register(_switch_notifier, n);
> + int ret;
> + ret = blocking_notifier_chain_register(_switch_notifier, n);
> + if (!ret)
> + notify_spus_active();
> + return ret;
>  }
> +EXPORT_SYMBOL_GPL(spu_switch_event_register);
>  
>  int spu_switch_event_unregister(struct notifier_block * n)
>  {
>   return blocking_notifier_chain_unregister(_switch_notifier, n);
>  }
> +EXPORT_SYMBOL_GPL(spu_switch_event_unregister);
>  
>  
>  static inline void bind_context(struct spu *spu, struct spu_context *ctx)
> @@ -250,6 +279,14 @@
>   return spu_get_idle(ctx, flags);
>  }
>  
> +void spu_notify_already_active(struct spu_context *ctx)
> +{
> + struct spu *spu = ctx->spu;
> + if (!spu)
> + return;
> + spu_switch_notify(spu, ctx);
> +}
> +
>  /* The three externally callable interfaces
>   * for the scheduler begin here.
>   *
> Index: 
> linux-2.6.19-rc6-arnd1+patches/arch/powerpc/platforms/cell/spufs/spufs.h
> ===
> --- 
> linux-2.6.19-rc6-arnd1+patches.orig/arch/powerpc/platforms/cell/spufs/spufs.h 
> 2007-01-08 18:18:40.093354608 -0600
> +++ linux-2.6.19-rc6-arnd1+patches/arch/powerpc/platforms/cell/spufs/spufs.h  
> 2007-01-08 18:31:03.610345792 -0600
> @@ -183,6 +183,7 @@
>  void spu_yield(struct spu_context *ctx);
>  int __init spu_sched_init(void);
>  void __exit spu_sched_exit(void);
> +void spu_notify_already_active(struct spu_context *ctx);
>  
>  extern char *isolated_loader;
>  
> Index: linux-2.6.19-rc6-arnd1+patches/arch/powerpc/platforms/cell/spufs/run.c
> ===
> --- 
> linux-2.6.19-rc6-arnd1+patches.orig/arch/powerpc/platforms/cell/spufs/run.c   
> 2007-01-08 18:33:51.979311680 -0600
> +++ 

Re: heavy nfs[4]] causes fs badness Was: 2.6.20-rc4: known unfixed regressions (v2)

[Florin Iucha]

Jiri and Trond,

On Mon, Jan 15, 2007 at 01:14:09AM +0100, Jiri Kosina wrote:
> On Sun, 14 Jan 2007, Florin Iucha wrote:
> 
> > All the testing was done via a ssh into the workstation.  The console 
> > was left as booted into, with the gdm running.  The remote nfs4 
> > directory was mounted on "/mnt". After copying the 60+ GB and testing 
> > that the keyboard was still functioning, I did not reboot but stayed in 
> > the same kernel and pulled the latest git then started bisecting.  
> 
> Hi Florin,
> 
> thanks a lot for the testing. Just to verify - what kernel is 'the same 
> kernel' mentioned above? (just to isolate whether the problem is really 
> somewhere between 2.6.19 and 2.6.20-rc2, as you stated in previous posts, 
> or the situation has changed).

This happened with 2.6.19.  It worked last time, but I wanted to test
again, to make sure.  This time, it bombed, but half an hour after the 
transfer finished.

> > After recompiling, I moved over to the workstation to reboot it, but the 
> > keyboard was not functioning ;(
> 
> So this time the hang occured when the system was idle, not during the 
> transfers, right?

Yes it was idle.  Immediately after the transfer finished, the keyboard was
still functioning.  It "hang" minutes later, after the first bisected kernel
was compiled and installed.

> > I ran "lsusb" and it displayed all the devices. "dmesg" did not show
> > any oops, anything for that matter.  I have unplugged the keyboard and
> > run "lsusb" again, but it hang.  I ran "ls /mnt" and it hang as well.
> > Stracing "lsusb" showed it hang (entered the kernel) at opening the device
> > that used to be the keyboard.  Stracing "ls /mnt" showed that it
> > hang at "stat(/mnt)".  Both processes were in "D" state.  "ls /root"
> > worked without problem, so it appears that crossing mountpoints causes
> > some hang in the kernel.
> 
> Could you please do alt-sysrq-t (or "echo t > /proc/sysrq-trigger" via 
> ssh, when your keyboard is dead) to see the calltraces of the processes 
> which are stuck inside kernel?
> 
> You will probably get a lot of output after the sysrq, so please either 
> put it somewhere on the web if possible, or just extract the interesting 
> processes out of it (mainly the ones which are stuck).

Will do.

florin

-- 
Bruce Schneier expects the Spanish Inquisition.
  http://geekz.co.uk/schneierfacts/fact/163


signature.asc
Description: Digital signature

[ANNOUNCE] Guilt v0.18

[Josef Sipek]

Guilt v0.18 is available for download.

Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
queues-like functionality and interface to git.

Tarballs:
http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/

Git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git


The majority of changes is in greater sanity checking - before a patch is
pushed/popped/refreshed, we check the HEAD hash with that in the status file.
guilt-pop now does only one git-reset instead of n (n == number of patches
to pop). This should greatly increase the speed of popping patches.

Josef "Jeff" Sipek.

--

Josef 'Jeff' Sipek (10):
  push_patch should be more careful when applying patches
  pop_patch should be quieter
  Removed debug line out of push_patch
  guilt-pop is now less brain damaged
  Add -m & -s args to guilt-new
  push_patch: look at diff stats instead of number of lines in patch
  Check HEAD hash against what we expect before push/pop/refresh
  Small cleanup in push_patch
  TODO moved to a separate branch
  Guilt v0.18

-- 
All science is either physics or stamp collecting.
- Ernest Rutherford
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] How to (automatically) find the correct maintainer(s)

[Stefan Richter]

On 15 Jan, Matthias Schniedermeyer wrote:
> Stefan Richter wrote:
>> On 14 Jan, Richard Knutsson wrote:
>>>(Really liked the idea to have a "Maintainer"-button 
>>>next to "Help" in *config)
>> 
>> Rhetorical question: What will this button be used for?
> 
> Having "all(tm)" information of something in one place?

Or, "click here to say 'it does not work'"?

My rhetorical question wasn't about what it is intended for, but what
people would think it was intended for if it was there.

> Help-Text and Dependencies/Selects are already there.

Yes. For the purpose of configuring the kernel.

> I think adding the Maintainers-data is more or less a logical next step.
> 
> It's not always clear from the MAINTAINERS-file who is the right person
> for what. Especially as it is a rather large text-file with only
> mediocre search-friendlieness. It's a 3.5 K-lines file!
> 
> So when you know that you have a problem with drivers X, wouldn't it be
> great if you could just "go to" the driver in *config and see not only
> the Help-Text but the Maintainers-Data also.

Seems more like what you actually want to have there is links to users'
mailinglists or forums.

When this thread started, it was about assisting authors in submitting
patches.

> And you can place "Fallback"-Maintainers-Data on Tree-Parents, for the
> cases where you only can pinpoint a area, like when you have a problem
> with a USB-device.
> 
> 
> I can ask a rhetorical question too:
> Why not go back to Config.help. Having a huge X K-Lines file with
> everything in one file can't be that bad. It worked before!

I am in no way against Richard's plan to improve development and
maintenance processes by easier access to contact data.
-- 
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: [RFC][PATCH] MMC: Major restructuring and cleanup

[Philip Langdale]

Pierre Ossman wrote:
 >
> Eeeeww... This is a problem as the SD spec. clearly states the order of
> init commands. So I wouldn't be surprised if we find SD cards that choke
> on the MMC init sequence.
> 
> I guess what we lose by not supporting these is 8 bit data bus, but as
> we do not currently have a controller for that I think the point is moot.

Hrm. Even the MMC 4.1 App Note describes a unified init sequence where SD is
checked first.

So, these cards are essentially useless then. The number of hosts that support
MMC 4 but not SD can probably be counted on no hands. :-)

--phil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] netfilter: implement TCPMSS target for IPv6

[David Madore]

On Sun, Jan 14, 2007 at 09:10:45PM +0100, Jan Engelhardt wrote:
> On Jan 14 2007 20:20, David Madore wrote:
> >Implement TCPMSS target for IPv6 by shamelessly copying from
> >Marc Boucher's IPv4 implementation.
> 
> Would not it be worthwhile to merge ipt_TCPMSS and
> ip6t_TCPMSS to xt_TCPMSS instead?

It may be, but I'm afraid that's outside my competence.  I happened to
need ip6t_TCPMSS badly and soon, so I went for the quickest solution.
Of course, I'd appreciate it if someone were to do it in a better way.

Happy hacking,

-- 
 David A. Madore
([EMAIL PROTECTED],
 http://www.madore.org/~david/ )
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA exceptions with 2.6.20-rc5

[Björn Steinbrink]

On 2007.01.14 19:22:51 -0500, Jeff Garzik wrote:
> Robert Hancock wrote:
> >Björn Steinbrink wrote:
> >>Hi,
> >>
> >>with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite
> >>often, with 2.6.19 there are no such exceptions. dmesg and lspci -v
> >>output follows. In the meantime, I'll start bisecting.
> >
> >...
> >
> >>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> >>ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in
> >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> >>ata1: soft resetting port
> >>ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> >>ata1.00: configured for UDMA/133
> >>ata1: EH complete
> >>SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
> >>sda: Write Protect is off
> >>sda: Mode Sense: 00 3a 00 00
> >>SCSI device sda: write cache: enabled, read cache: enabled, doesn't 
> >>support DPO or FUA
> >
> >Looks like all of these errors are from a FLUSH CACHE command and the 
> >drive is indicating that it is no longer busy, so presumably done. 
> >That's not a DMA-mapped command, so it wouldn't go through the ADMA 
> >machinery and I wouldn't have expected this to be handled any 
> >differently from before. Curious..
> 
> It's possible the flush-cache command takes longer than 30 seconds, if 
> the cache is large, contents are discontiguous, etc.  It's a 
> pathological case, but possible.
> 
> Or maybe flush-cache doesn't get a 30 second timeout, and it should...? 
>  (thinking out loud)

Bi-section led to commit 249e83fe839 which makes absolutely no sense to
me, just in case that anyone sees any problem with that commit.
I'll go and re-check a few of those commits that I marked as good.

Björn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc5] intel_rng: substitue magic PCI IDs with macros

[Greg KH]

On Mon, Jan 15, 2007 at 01:07:18AM +0200, Ahmed S. Darwish wrote:
> On Mon, Jan 15, 2007 at 06:31:01AM +1100, Dave Airlie wrote:
> > On 1/15/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > >On Sun, 2007-01-14 at 19:24 +0200, Ahmed S. Darwish wrote:
> > >> Substitue intel_rng magic PCI IDs values used in the IDs table
> > >> with the macros defined in pci_ids.h
> > >>
> > >Hi,
> > >
> > >hmm this is actually the opposite direction than most of the kernel is
> > >heading in, mostly because the pci_ids.h file is a major maintenance
> > >pain.
> > >
> > >Afaik the current "rule" is: if a PCI ID is only used in one driver, use
> > >the numeric value and not (add) a symbolic constant.
> > >
> > 
> > My guess is that the RNG is on the LPC so the values are used in a few 
> > places..
> > 
> 
> Will pci_ids.h be removed from the tree some time in the future then ?

No, it should contain ids that are used in multiple places (vendor ids
are one such example.)

And in this case, the majority of the patch is just using the vendor id,
which in my opinion, is a good idea.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.20-rc5] intel_rng: substitue magic PCI IDs with macros

[Greg KH]

On Sun, Jan 14, 2007 at 07:24:21PM +0200, Ahmed S. Darwish wrote:
> Substitue intel_rng magic PCI IDs values used in the IDs table
> with the macros defined in pci_ids.h

Why not use the PCI_DEVICE() macro too?  It should make the lines even
smaller.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i810fb fails to load (was: 2.6.20-rc4-mm1)

[Andrew Morton]

> On Mon, 15 Jan 2007 00:52:36 +0100 Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> With kernel 2.6.20-rc4-mm1 and all hotfixes, i810fb fails to load on my
> Dell Optiplex GX110. Here's an excerpt of the diff between the boot logs
> of 2.6.20-rc5 (working) and 2.6.20-rc4-mm1 (non-working):
> 
> @@ -4,7 +4,7 @@
>  No module symbols loaded - kernel modules not enabled.
> 
>  klogd 1.4.1, log source = ksyslog started.
> -<5>Linux version 2.6.20-rc5-noinitrd ([EMAIL PROTECTED]) (gcc version 4.0.2 
> 20050901 (prerelease) (SUSE Linux)) #2 PREEMPT Sun Jan 14 23:37:12 CET 2007
> +<5>Linux version 2.6.20-rc4-mm1-noinitrd ([EMAIL PROTECTED]) (gcc version 
> 4.0.2 20050901 (prerelease) (SUSE Linux)) #3 PREEMPT Sun Jan 14 21:08:56 CET 
> 2007
>  <6>BIOS-provided physical RAM map:
>  <4>sanitize start
>  <4>sanitize end
> @@ -188,7 +192,6 @@
>  <6>ACPI: Interpreter enabled
>  <6>ACPI: Using PIC for interrupt routing
>  <6>ACPI: PCI Root Bridge [PCI0] (:00)
> -<7>PCI: Probing PCI hardware (bus 00)
>  <6>ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
>  <7>Boot video device is :00:01.0
>  <4>PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO
> @@ -238,20 +241,15 @@
>  <6>isapnp: No Plug & Play device found
>  <6>Real Time Clock Driver v1.12ac
>  <6>Intel 82802 RNG detected
> -<6>Linux agpgart interface v0.101 (c) Dave Jones
> +<6>Linux agpgart interface v0.102 (c) Dave Jones
>  <6>agpgart: Detected an Intel i810 E Chipset.
>  <6>agpgart: detected 4MB dedicated video ram.
>  <6>agpgart: AGP aperture is 64M @ 0xf800
>  <4>ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 9
>  <7>PCI: setting IRQ 9 as level-triggered
>  <6>ACPI: PCI Interrupt :00:01.0[A] -> Link [LNKA] -> GSI 9 (level, low) 
> -> IRQ 9
> -<4>i810-i2c: Probe DDC1 Bus
> -<4>i810fb_init_pci: DDC probe successful
> -<4>Console: switching to colour frame buffer device 160x64
> -<4>I810FB: fb0 : Intel(R) 810E Framebuffer Device v0.9.0
> -<4>I810FB: Video RAM   : 4096K
> -<4>I810FB: Monitor : H: 30-83 KHz V: 55-75 Hz
> -<4>I810FB: Mode: [EMAIL PROTECTED]
> +<4>i810fb_alloc_fbmem: can't bind framebuffer memory
> +<4>i810fb: probe of :00:01.0 failed with error -16
>  <6>Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
>  <6>serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>  <6>serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> 
> Please let me know if you need more information.
> 

Don't know.  But I bet someone on the Cc does...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA exceptions with 2.6.20-rc5

[Jeff Garzik]

Robert Hancock wrote:

Björn Steinbrink wrote:

Hi,

with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite
often, with 2.6.19 there are no such exceptions. dmesg and lspci -v
output follows. In the meantime, I'll start bisecting.


...


ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/133
ata1: EH complete
SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


Looks like all of these errors are from a FLUSH CACHE command and the 
drive is indicating that it is no longer busy, so presumably done. 
That's not a DMA-mapped command, so it wouldn't go through the ADMA 
machinery and I wouldn't have expected this to be handled any 
differently from before. Curious..


It's possible the flush-cache command takes longer than 30 seconds, if 
the cache is large, contents are discontiguous, etc.  It's a 
pathological case, but possible.


Or maybe flush-cache doesn't get a 30 second timeout, and it should...? 
 (thinking out loud)


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 00/12] Fix ppc64's writing to struct file_operations

[Arjan van de Ven]

On Mon, 2007-01-15 at 10:55 +1100, Stephen Rothwell wrote:
> On Sun, 14 Jan 2007 14:54:11 + Alan <[EMAIL PROTECTED]> wrote:
> >
> > This doesn't appea to do the same thing at all. You need to select
> > between two sets of const inode ops instead, otherwise you turn write on
> > arbitarily.
> 
> Or something like below ... (compile tested on pseries, iseries and combined).

ok I was about to do this instead... but you beat me to it.. thanks!

Acked-by: Arjan van de Ven <[EMAIL PROTECTED]>



-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: heavy nfs[4]] causes fs badness Was: 2.6.20-rc4: known unfixed regressions (v2)

[Jiri Kosina]

On Sun, 14 Jan 2007, Florin Iucha wrote:

> All the testing was done via a ssh into the workstation.  The console 
> was left as booted into, with the gdm running.  The remote nfs4 
> directory was mounted on "/mnt". After copying the 60+ GB and testing 
> that the keyboard was still functioning, I did not reboot but stayed in 
> the same kernel and pulled the latest git then started bisecting.  

Hi Florin,

thanks a lot for the testing. Just to verify - what kernel is 'the same 
kernel' mentioned above? (just to isolate whether the problem is really 
somewhere between 2.6.19 and 2.6.20-rc2, as you stated in previous posts, 
or the situation has changed).

> After recompiling, I moved over to the workstation to reboot it, but the 
> keyboard was not functioning ;(

So this time the hang occured when the system was idle, not during the 
transfers, right?

> I ran "lsusb" and it displayed all the devices. "dmesg" did not show
> any oops, anything for that matter.  I have unplugged the keyboard and
> run "lsusb" again, but it hang.  I ran "ls /mnt" and it hang as well.
> Stracing "lsusb" showed it hang (entered the kernel) at opening the device
> that used to be the keyboard.  Stracing "ls /mnt" showed that it
> hang at "stat(/mnt)".  Both processes were in "D" state.  "ls /root"
> worked without problem, so it appears that crossing mountpoints causes
> some hang in the kernel.

Could you please do alt-sysrq-t (or "echo t > /proc/sysrq-trigger" via 
ssh, when your keyboard is dead) to see the calltraces of the processes 
which are stuck inside kernel?

You will probably get a lot of output after the sysrq, so please either 
put it somewhere on the web if possible, or just extract the interesting 
processes out of it (mainly the ones which are stuck).

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: heavy nfs[4]] causes fs badness Was: 2.6.20-rc4: known unfixed regressions (v2)

[Trond Myklebust]

On Sun, 2007-01-14 at 17:58 -0600, Florin Iucha wrote:
> All the testing was done via a ssh into the workstation.  The console
> was left as booted into, with the gdm running.  The remote nfs4
> directory was mounted on "/mnt".
> 
> After copying the 60+ GB and testing that the keyboard was still
> functioning, I did not reboot but stayed in the same kernel and pulled
> the latest git then started bisecting.  After recompiling, I moved
> over to the workstation to reboot it, but the keyboard was not
> functioning ;(
> 
> I ran "lsusb" and it displayed all the devices. "dmesg" did not show
> any oops, anything for that matter.  I have unplugged the keyboard and
> run "lsusb" again, but it hang.  I ran "ls /mnt" and it hang as well.
> Stracing "lsusb" showed it hang (entered the kernel) at opening the device
> that used to be the keyboard.  Stracing "ls /mnt" showed that it
> hang at "stat(/mnt)".  Both processes were in "D" state.  "ls /root"
> worked without problem, so it appears that crossing mountpoints causes
> some hang in the kernel.
> 
> Based on this info, I think we can rule out any USB.  I will try
> testing with NFS3 to see if the problem persists.  Unfortunately there
> is no oops or anything in "dmesg".

Did you try an 'echo t > /proc/sysrq-trigger' in order to find out where
the stat process is hanging?

  Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc4-mm1

[Jens Axboe]

On Sun, Jan 14 2007, Thomas Gleixner wrote:
> On Sun, 2007-01-14 at 11:46 +0100, Thomas Gleixner wrote:
> > > Boot proceeds, but gets stuck hard at:
> > > "Remounting root filesystem in read-write mode:"
> > > 
> > > No SysRq-T, nothing.
> > > 
> > > The above BUG seems unrelated to that. Investigating further.
> > 
> > Bisect identified: git-block.patch
> 
> Does only happen on 2 systems. Both have sata + raid1 setup. I managed 
> to get a stacktrace from the SMP box. Sits there and sleeps forever.
> 
>   tglx
> 
> [] io_schedule+0x7a/0x9a
> [] sleep_on_page+0x8/0xc
> [] __wait_on_bit+0x36/0x5d
> [] wait_on_page_bit+0x5b/0x61
> [] wait_on_page_writeback_range+0x4f/0xef
> [] filemap_fdatawait+0x44/0x49
> [] filemap_write_and_wait+0x22/0x2d
> [] sync_blockdev+0x17/0x1d
> [] quota_sync_sb+0x33/0xd6
> [] sync_dquots+0x22/0xfa
> [] __fsync_super+0x17/0x66
> [] fsync_super+0xb/0x19
> [] do_remount_sb+0x49/0x101
> [] do_mount+0x1ad/0x678
> [] sys_mount+0x6f/0xa4
> [] sysenter_past_esp+0x5f/0x99

raid seems to have severe problems with the plugging change. I'll try
and find Neil and have a chat with him, hopefully we can work it out.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] How to (automatically) find the correct maintainer(s)

[Matthias Schniedermeyer]

Stefan Richter wrote:
> On 14 Jan, Richard Knutsson wrote:
> 
>>(Really liked the idea to have a "Maintainer"-button 
>>next to "Help" in *config)
> 
> 
> Rhetorical question: What will this button be used for?

Having "all(tm)" information of something in one place?
Help-Text and Dependencies/Selects are already there.
I think adding the Maintainers-data is more or less a logical next step.

It's not always clear from the MAINTAINERS-file who is the right person
for what. Especially as it is a rather large text-file with only
mediocre search-friendlieness. It's a 3.5 K-lines file!

So when you know that you have a problem with drivers X, wouldn't it be
great if you could just "go to" the driver in *config and see not only
the Help-Text but the Maintainers-Data also.
And you can place "Fallback"-Maintainers-Data on Tree-Parents, for the
cases where you only can pinpoint a area, like when you have a problem
with a USB-device.


I can ask a rhetorical question too:
Why not go back to Config.help. Having a huge X K-Lines file with
everything in one file can't be that bad. It worked before!




Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

heavy nfs[4]] causes fs badness Was: 2.6.20-rc4: known unfixed regressions (v2)

[Florin Iucha]

On Sun, Jan 14, 2007 at 04:57:01PM -0600,  wrote:
> On Wed, Jan 10, 2007 at 10:54:34AM -0500, Alan Stern wrote:
> > It's still possible that this is hardware related; perhaps some component
> > just began to wear out.  If you return to an earlier kernel, does the 
> > problem go away?
> 
> As reported in my original e-mail and verified just minutes ago, the
> copy succeeds with 2.6.19 (kernel.org vanilla, compiled with the same
> config as 2.6.20-rcX).  I will begin bisecting between .19 and .20-rc1
> after re-reading Jiri's messages.

All the testing was done via a ssh into the workstation.  The console
was left as booted into, with the gdm running.  The remote nfs4
directory was mounted on "/mnt".

After copying the 60+ GB and testing that the keyboard was still
functioning, I did not reboot but stayed in the same kernel and pulled
the latest git then started bisecting.  After recompiling, I moved
over to the workstation to reboot it, but the keyboard was not
functioning ;(

I ran "lsusb" and it displayed all the devices. "dmesg" did not show
any oops, anything for that matter.  I have unplugged the keyboard and
run "lsusb" again, but it hang.  I ran "ls /mnt" and it hang as well.
Stracing "lsusb" showed it hang (entered the kernel) at opening the device
that used to be the keyboard.  Stracing "ls /mnt" showed that it
hang at "stat(/mnt)".  Both processes were in "D" state.  "ls /root"
worked without problem, so it appears that crossing mountpoints causes
some hang in the kernel.

Based on this info, I think we can rule out any USB.  I will try
testing with NFS3 to see if the problem persists.  Unfortunately there
is no oops or anything in "dmesg".

florin

-- 
Bruce Schneier expects the Spanish Inquisition.
  http://geekz.co.uk/schneierfacts/fact/163


signature.asc
Description: Digital signature

user pointer bugs

[Suhabe Bugrara]

Hello,

In linux-2.6.19.2, do the following lines have bugs in them? It looks
like they dereference a user pointer without first being checked by
the "access_ok" macro to ensure that they point into userspace.

Suhabe


File: sound/isa/sscape.c
Lines: 550, 665
Description: The pointer "bb" is dereferenced in the expression
"bb->code" without being checked first.
Fix: Replace "bb->code" with ">code"


File: block/scsi_ioctl.c
Lines: 406, 427, 430, 482, 486
Description: The pointer "sic" is dereferenced in the expression
"sic->data" without being checked first.
Fix: Replace "sic->code" with ">code"


File: sound/pci/rme9652/hdsp.c
Line: 4589
Description: The pointer "mixer" is dereferenced in the expression
"mixer->data" without being checked first.
Fix: Replace "mixer->matrix" with ">matrix"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] flush_cpu_workqueue: don't flush an empty ->worklist

[Oleg Nesterov]

How about the pseudo-code below?

workqueue_mutex is only used to protect "struct list_head workqueues",
all workqueue operations can run in parallel with cpuhotplug callback path.
take_over_work(), migrate_sequence, CPU_LOCK_ACQUIRE/RELEASE go away.

I'd like to make a couple of cleanups (and fix schedule_on_each_cpu) before
sending the patch, but if somebody doesn't like this intrusive change, he
can nack it right now.

Oleg.

struct cpu_workqueue_srtuct {
...
int should_stop;
...
};

// also used by flush_work/flush_workqueue
static cpumask_t cpu_populated_map __read_mostly;

/*
 * NOTE: the caller must not touch *cwq if this func returns true
 */
static inline int cwq_should_stop(struct cpu_workqueue_struct *cwq)
{
int should_stop = cwq->should_stop;

if (unlikely(should_stop)) {
spin_lock_irq(>lock);
should_stop = cwq->should_stop && list_empty(>worklist);
if (should_stop)
cwq->thread = NULL;
spin_unlock_irq(>lock);
}

return should_stop;
}

static int worker_thread(void *cwq)
{
while (!cwq_should_stop(cwq)) {
...
run_workqueue();
...
}
}

static int create_workqueue_thread(struct cpu_workqueue_struct *cwq, int cpu)
{
struct task_struct *p;

spin_lock_irq(>lock);
cwq->should_stop = 0;
p = cwq->thread;
spin_unlock_irq(>lock);

if (!p) {
struct workqueue_struct *wq = cwq->wq;
const char *fmt = is_single_threaded(wq) ? "%s" : "%s/%d";

p = kthread_create(worker_thread, cwq, fmt, wq->name, cpu);
/*
 * Nobody can add the work_struct to this cwq,
 *  if (caller is __create_workqueue)
 *  nobody should see this wq
 *  else // caller is CPU_UP_PREPARE
 *  cpu is not on cpu_online_map
 * so we can abort safely.
 */
if (IS_ERR(p))
return PTR_ERR(p);

if (!is_single_threaded(wq))
kthread_bind(p, cpu);
/*
 * Cancels affinity if the caller is CPU_UP_PREPARE.
 * Needs a cleanup, but OK.
 */
wake_up_process(p);
cwq->thread = p;
}

return 0;
}

struct workqueue_struct *__create_workqueue(const char *name,
int singlethread, int freezeable)
{
struct workqueue_struct *wq;
struct cpu_workqueue_struct *cwq;
int err = 0, cpu;

wq = kzalloc(sizeof(*wq), GFP_KERNEL);
if (!wq)
return NULL;

wq->cpu_wq = alloc_percpu(struct cpu_workqueue_struct);
if (!wq->cpu_wq) {
kfree(wq);
return NULL;
}

wq->name = name;
wq->freezeable = freezeable;

if (singlethread) {
INIT_LIST_HEAD(>list);
cwq = init_cpu_workqueue(wq, singlethread_cpu);
err = create_workqueue_thread(cwq, singlethread_cpu);
} else {
mutex_lock(_mutex);
list_add(>list, );

for_each_possible_cpu(cpu) {
cwq = init_cpu_workqueue(wq, cpu);
if (err || !cpu_isset(cpu, cpu_populated_map))
continue;
err = create_workqueue_thread(cwq, cpu);
}
mutex_unlock(_mutex);
}

if (err) {
destroy_workqueue(wq);
wq = NULL;
}
return wq;
}

static void cleanup_workqueue_thread(struct workqueue_struct *wq, int cpu)
{
struct cpu_workqueue_struct *cwq = per_cpu_ptr(wq->cpu_wq, cpu);
struct wq_barrier barr;
int alive = 0;

spin_lock_irq(>lock);
if (cwq->thread != NULL) {
insert_wq_barrier(cwq, , 1);
cwq->should_stop = 1;
alive = 1;
}
spin_unlock_irq(>lock);

if (alive) {
wait_for_completion();

while (unlikely(cwq->thread != NULL))
cpu_relax();
/*
 * Wait until cwq->thread unlocks cwq->lock,
 * it won't touch *cwq after that.
 */
smp_rmb();
spin_unlock_wait(>lock);
}
}

void destroy_workqueue(struct workqueue_struct *wq)
{
if (is_single_threaded(wq))
cleanup_workqueue_thread(wq, singlethread_cpu);
else {
int cpu;

mutex_lock(_mutex);
list_del(>list);
mutex_unlock(_mutex);

for_each_cpu_mask(cpu, 

Re: [patch 00/12] Fix ppc64's writing to struct file_operations

[Stephen Rothwell]

On Sun, 14 Jan 2007 14:54:11 + Alan <[EMAIL PROTECTED]> wrote:
>
> This doesn't appea to do the same thing at all. You need to select
> between two sets of const inode ops instead, otherwise you turn write on
> arbitarily.

Or something like below ... (compile tested on pseries, iseries and combined).

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/

diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index 41c05dc..0de5a08 100644
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
@@ -439,6 +439,10 @@ static ssize_t lparcfg_write(struct file *file, const char 
__user * buf,
 
ssize_t retval = -ENOMEM;
 
+   if (!firmware_has_feature(FW_FEATURE_SPLPAR) ||
+   firmware_has_feature(FW_FEATURE_ISERIES))
+   return -EINVAL;
+
kbuf = kmalloc(count, GFP_KERNEL);
if (!kbuf)
goto out;
@@ -517,7 +521,7 @@ static int pseries_lparcfg_data(struct seq_file *m, void *v)
 static ssize_t lparcfg_write(struct file *file, const char __user * buf,
 size_t count, loff_t * off)
 {
-   return count;
+   return -EINVAL;
 }
 
 #endif /* CONFIG_PPC_PSERIES */
@@ -570,6 +574,7 @@ static int lparcfg_open(struct inode *inode, struct file 
*file)
 struct file_operations lparcfg_fops = {
.owner  = THIS_MODULE,
.read   = seq_read,
+   .write  = lparcfg_write,
.open   = lparcfg_open,
.release= single_release,
 };
@@ -581,10 +586,8 @@ int __init lparcfg_init(void)
 
/* Allow writing if we have FW_FEATURE_SPLPAR */
if (firmware_has_feature(FW_FEATURE_SPLPAR) &&
-   !firmware_has_feature(FW_FEATURE_ISERIES)) {
-   lparcfg_fops.write = lparcfg_write;
+   !firmware_has_feature(FW_FEATURE_ISERIES))
mode |= S_IWUSR;
-   }
 
ent = create_proc_entry("ppc64/lparcfg", mode, NULL);
if (ent) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

i810fb fails to load (was: 2.6.20-rc4-mm1)

[Tilman Schmidt]

With kernel 2.6.20-rc4-mm1 and all hotfixes, i810fb fails to load on my
Dell Optiplex GX110. Here's an excerpt of the diff between the boot logs
of 2.6.20-rc5 (working) and 2.6.20-rc4-mm1 (non-working):

@@ -4,7 +4,7 @@
 No module symbols loaded - kernel modules not enabled.

 klogd 1.4.1, log source = ksyslog started.
-<5>Linux version 2.6.20-rc5-noinitrd ([EMAIL PROTECTED]) (gcc version 4.0.2 
20050901 (prerelease) (SUSE Linux)) #2 PREEMPT Sun Jan 14 23:37:12 CET 2007
+<5>Linux version 2.6.20-rc4-mm1-noinitrd ([EMAIL PROTECTED]) (gcc version 
4.0.2 20050901 (prerelease) (SUSE Linux)) #3 PREEMPT Sun Jan 14 21:08:56 CET 
2007
 <6>BIOS-provided physical RAM map:
 <4>sanitize start
 <4>sanitize end
@@ -188,7 +192,6 @@
 <6>ACPI: Interpreter enabled
 <6>ACPI: Using PIC for interrupt routing
 <6>ACPI: PCI Root Bridge [PCI0] (:00)
-<7>PCI: Probing PCI hardware (bus 00)
 <6>ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
 <7>Boot video device is :00:01.0
 <4>PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO
@@ -238,20 +241,15 @@
 <6>isapnp: No Plug & Play device found
 <6>Real Time Clock Driver v1.12ac
 <6>Intel 82802 RNG detected
-<6>Linux agpgart interface v0.101 (c) Dave Jones
+<6>Linux agpgart interface v0.102 (c) Dave Jones
 <6>agpgart: Detected an Intel i810 E Chipset.
 <6>agpgart: detected 4MB dedicated video ram.
 <6>agpgart: AGP aperture is 64M @ 0xf800
 <4>ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 9
 <7>PCI: setting IRQ 9 as level-triggered
 <6>ACPI: PCI Interrupt :00:01.0[A] -> Link [LNKA] -> GSI 9 (level, low) -> 
IRQ 9
-<4>i810-i2c: Probe DDC1 Bus
-<4>i810fb_init_pci: DDC probe successful
-<4>Console: switching to colour frame buffer device 160x64
-<4>I810FB: fb0 : Intel(R) 810E Framebuffer Device v0.9.0
-<4>I810FB: Video RAM   : 4096K
-<4>I810FB: Monitor : H: 30-83 KHz V: 55-75 Hz
-<4>I810FB: Mode: [EMAIL PROTECTED]
+<4>i810fb_alloc_fbmem: can't bind framebuffer memory
+<4>i810fb: probe of :00:01.0 failed with error -16
 <6>Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
 <6>serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
 <6>serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

Please let me know if you need more information.

Thanks
Tilman

-- 
Tilman Schmidt  E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

Re: SATA exceptions with 2.6.20-rc5

[Robert Hancock]

Björn Steinbrink wrote:

Hi,

with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite
often, with 2.6.19 there are no such exceptions. dmesg and lspci -v
output follows. In the meantime, I'll start bisecting.


...


ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/133
ata1: EH complete
SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA


Looks like all of these errors are from a FLUSH CACHE command and the 
drive is indicating that it is no longer busy, so presumably done. 
That's not a DMA-mapped command, so it wouldn't go through the ADMA 
machinery and I wouldn't have expected this to be handled any 
differently from before. Curious..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] How to (automatically) find the correct maintainer(s)

[Matthias Schniedermeyer]

Richard Knutsson wrote:
> Matthias Schniedermeyer wrote:
> 
>> Richard Knutsson wrote:
>>  
>>
>>> Matthias Schniedermeyer wrote:
>>>
>>>
>>>
 Richard Knutsson wrote:

  

  

> Any thoughts on this is very much appreciated (is there any flaws with
> this?).
> 

 The thought that crossed my mind was:

 Why not do the same thing that was done to the "Help"-file. (Before it
 was superseded by Kconfig).

 Originaly there was a central Help-file, with all the texts. Then it
 was
 split and placed in each sub-dir. And later it was superseded by
 Kconfig.

 On the other hand you could skip the intermediate step and just fold
 the
 Maintainer-data directly into Kconfig, that way everything is "in one
 place" and you could place a "Maintainers"-Button next to the
 "Help"-Button in *config, or just display it alongside the help.

 And MAYBE that would also lessen the "update-to-date"-problem, as you
 can just write the MAINTAINERs-data when you create/update the
 Kconfig-file. Which is a thing that creates much bigger pain when you
 forget it accidently. ;-)

 Oh, and it neadly solves the mapping-problem, for at least all
 kernel-parts that have a Kconfig-option/Sub-Tree.
 
>>>
>>> I'm all for splitting up the MAINTAINERS! :)
>>>
>>> Just, do you have any ideas how to solve the possible multiple of the
>>> same entries, when handling multiple sub-directories and when many
>>> different drivers with different maintainers are in the same directory
>>> and a maintainer have more then one driver?
>>> 
>>
>>
>> Handles.
>> If a Maintainer maintains several subsystems/drivers a "handle" could be
>> used to references to a handle-list (hello MAINTAINERS) or to the place
>> where the full-maintainers-entry is placed.
>>   
> 
> Mm, and maybe store the entry on the shortest-pathway common directory.
> Then there should be just a few left entries in the current MAINTAINERS.
> But how to create the handles?
> * Name (problem with persons with the same name)
> * E-mail (much to change when they change it)
> This also make a problem when there is a change of the maintainer, what
> happens with the entry if there is no maintainer?
> * Just numbers and increase every new one with one? (quite ugly!)
> ... and here is the end of my ideas.
> 
> Any good ideas? (Really liked the idea to have a "Maintainer"-button
> next to "Help" in *config)

I'd say something like:

e.g.
MS0001
MaSchn001
or something along that line.

Some people have several entries in the MAINTAINERs and a new way would
have to make that possible too.





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.19] USB HID: proper LED-mapping (support for SpaceNavigator)

[Simon Budig]

From: Simon Budig <[EMAIL PROTECTED]>

This change introduces a mapping for LED indicators between the USB HID
specification and the Linux input subsystem. The previous code properly
mapped the LEDs relevant for Keyboards, but garbeled the remaining ones.
With this change all LED enums from the input system get mapped to more
or less equivalent LED numbers from the HID specification.

This patch also extends the debug output and ensures that the unused
bits in a HID report to the device are zeroed out. This makes the
3Dconnexion SpaceNavigator fully usable with the linux input system.

Signed-off-by: Simon Budig <[EMAIL PROTECTED]>

diff -uprN -X linux/Documentation/dontdiff 
linux/drivers/usb/input.orig/hid-core.c linux/drivers/usb/input/hid-core.c
--- linux/drivers/usb/input.orig/hid-core.c 2006-11-29 22:57:37.0 
+0100
+++ linux/drivers/usb/input/hid-core.c  2007-01-15 00:01:25.0 +0100
@@ -1089,6 +1089,10 @@ static void hid_output_field(struct hid_
unsigned size = field->report_size;
unsigned n;
 
+   /* make sure the unused bits in the last byte are zeros */
+   if (count > 0 && size > 0)
+   data[(count*size-1)/8] = 0;
+
for (n = 0; n < count; n++) {
if (field->logical_minimum < 0) /* signed values */
implement(data, offset + n * size, size, 
s32ton(field->value[n], size));
diff -uprN -X linux/Documentation/dontdiff 
linux/drivers/usb/input.orig/hid-debug.h linux/drivers/usb/input/hid-debug.h
--- linux/drivers/usb/input.orig/hid-debug.h2006-11-29 22:57:37.0 
+0100
+++ linux/drivers/usb/input/hid-debug.h 2007-01-08 15:36:51.0 +0100
@@ -700,9 +700,10 @@ static char *keys[KEY_MAX + 1] = {
 
 static char *relatives[REL_MAX + 1] = {
[REL_X] = "X",  [REL_Y] = "Y",
-   [REL_Z] = "Z",  [REL_HWHEEL] = "HWheel",
-   [REL_DIAL] = "Dial",[REL_WHEEL] = "Wheel",
-   [REL_MISC] = "Misc",
+   [REL_Z] = "Z",  [REL_RX] = "Rx",
+   [REL_RY] = "Ry",[REL_RZ] = "Rz",
+   [REL_HWHEEL] = "HWheel",[REL_DIAL] = "Dial",
+   [REL_WHEEL] = "Wheel",  [REL_MISC] = "Misc",
 };
 
 static char *absolutes[ABS_MAX + 1] = {
diff -uprN -X linux/Documentation/dontdiff 
linux/drivers/usb/input.orig/hid-input.c linux/drivers/usb/input/hid-input.c
--- linux/drivers/usb/input.orig/hid-input.c2006-11-29 22:57:37.0 
+0100
+++ linux/drivers/usb/input/hid-input.c 2007-01-08 17:20:16.0 +0100
@@ -366,9 +366,22 @@ static void hidinput_configure_usage(str
break;
 
case HID_UP_LED:
-   if (((usage->hid - 1) & 0x) >= LED_MAX)
-   goto ignore;
-   map_led((usage->hid - 1) & 0x);
+
+   switch (usage->hid & 0x) {
/* HID-Value: */
+   case 0x01:  map_led (LED_NUML); break;
/* Num Lock */
+   case 0x02:  map_led (LED_CAPSL);break;
/* Caps Lock */
+   case 0x03:  map_led (LED_SCROLLL);  break;
/* Scroll Lock */
+   case 0x04:  map_led (LED_COMPOSE);  break;
/* Compose */
+   case 0x05:  map_led (LED_KANA); break;
/* Kana */
+   case 0x27:  map_led (LED_SLEEP);break;
/* Stand-By */
+   case 0x4c:  map_led (LED_SUSPEND);  break;
/* System Suspend */
+   case 0x09:  map_led (LED_MUTE); break;
/* Mute */
+   case 0x4b:  map_led (LED_MISC); break;
/* Generic Indicator */
+   case 0x19:  map_led (LED_MAIL); break;
/* Message Waiting */
+   case 0x4d:  map_led (LED_CHARGING); break;
/* External Power Connected */
+
+   default: goto ignore;
+   }
break;
 
case HID_UP_DIGITIZER:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: it821x trouble since 2.6.18

[Alan]

> 2. Trying to understand what has happened I found the main difference
> is not in the driver but in ide-dma.c:
> 
> --- linux-2.6.17.14/drivers/ide/ide-dma.c   2006-06-18 01:49:35.0 
> +
> +++ linux-2.6.18.6/drivers/ide/ide-dma.c2006-09-20 03:42:06.0 
> +
> @@ -752,7 +750,7 @@
> goto bug_dma_off;
> printk(", DMA");
> } else if (id->field_valid & 1) {
> -   printk(", BUG");
> +   goto bug_dma_off;
> }
> return;
>  bug_dma_off:
> 
> 
> and reverting that change returns the old transfer rates. But that is
> probably not a good idea.

It should be just fine. 

> So I tried this again:

This is complete bogus. You simply poked random incorrect registers and
happened not to crash the chip, or confuse it, and since you have the
IT821x bios enabled it happened to have roughly valid configuration.

> and disabled CONFIG_BLK_DEV_IT821X - and now the disk is even faster
> than before:

For all the wrong reasons I would add.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc5] intel_rng: substitue magic PCI IDs with macros

[Ahmed S. Darwish]

On Mon, Jan 15, 2007 at 06:31:01AM +1100, Dave Airlie wrote:
> On 1/15/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> >On Sun, 2007-01-14 at 19:24 +0200, Ahmed S. Darwish wrote:
> >> Substitue intel_rng magic PCI IDs values used in the IDs table
> >> with the macros defined in pci_ids.h
> >>
> >Hi,
> >
> >hmm this is actually the opposite direction than most of the kernel is
> >heading in, mostly because the pci_ids.h file is a major maintenance
> >pain.
> >
> >Afaik the current "rule" is: if a PCI ID is only used in one driver, use
> >the numeric value and not (add) a symbolic constant.
> >
> 
> My guess is that the RNG is on the LPC so the values are used in a few 
> places..
> 

Will pci_ids.h be removed from the tree some time in the future then ?

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] How to (automatically) find the correct maintainer(s)

[Stefan Richter]

On 14 Jan, Richard Knutsson wrote:
> (Really liked the idea to have a "Maintainer"-button 
> next to "Help" in *config)

Rhetorical question: What will this button be used for?
-- 
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: [linux-usb-devel] 2.6.20-rc4: known unfixed regressions (v2)

[Florin Iucha]

On Wed, Jan 10, 2007 at 10:54:34AM -0500, Alan Stern wrote:
> It's still possible that this is hardware related; perhaps some component
> just began to wear out.  If you return to an earlier kernel, does the 
> problem go away?

As reported in my original e-mail and verified just minutes ago, the
copy succeeds with 2.6.19 (kernel.org vanilla, compiled with the same
config as 2.6.20-rcX).  I will begin bisecting between .19 and .20-rc1
after re-reading Jiri's messages.

florin

-- 
Bruce Schneier expects the Spanish Inquisition.
  http://geekz.co.uk/schneierfacts/fact/163


signature.asc
Description: Digital signature

it821x trouble since 2.6.18

[Christoph Biedl]

Hi,

There are ITE 8212-based controllers installed in some of my
computers. I had always skipped the build-in RAID things and used them
as plain controllers.

1. Beginning with 2.6.18 there was some trouble, basically slowed data
transfer, sometimes even a totally stalled system (I cannot reproduce
the latter though).

Diffing dmesg of 2.6.17.x and 2.6.18.x (same for 2.6.19):

 Probing IDE interface ide2...
 hde: SAMSUNG VA34324A, ATA DISK drive
 hde: Performing identify fixups.
 ide2 at 0xd000-0xd007,0xd402 on irq 10
 hde: max request size: 128KiB
-hde: 8446032 sectors (4324 MB) w/478KiB Cache, CHS=14896/9/63, BUG
+hde: 8446032 sectors (4324 MB) w/478KiB Cache, CHS=14896/9/63, BUG DMA OFF
  hde:hde: recal_intr: status=0x51 { DriveReady SeekComplete Error }
 hde: recal_intr: error=0x04 { DriveStatusError }
 ide: failed opcode was: unknown
+hde: irq timeout: status=0xd0 { Busy }
+ide: failed opcode was: unknown
+ide2: reset: master: ECC circuitry error
+hde: recal_intr: status=0x51 { DriveReady SeekComplete Error }
+hde: recal_intr: error=0x04 { DriveStatusError }
+ide: failed opcode was: unknown
  hde1 hde2 < hde5 hde6 >

OK, there was "BUG" up to and including 2.6.17 but the disk(s) worked
without any problem. 

Not surprisingly the disk throughput was affected by that. Comparing
"hdparm -tT /dev/hde":

2.6.17
/dev/hde:
 Timing cached reads:88 MB in  2.01 seconds =  43.72 MB/sec
 Timing buffered disk reads:   26 MB in  3.21 seconds =   8.10 MB/sec

2.6.18
/dev/hde:
 Timing cached reads:90 MB in  2.04 seconds =  44.01 MB/sec
 Timing buffered disk reads:   16 MB in  3.14 seconds =   5.10 MB/sec


2. Trying to understand what has happened I found the main difference
is not in the driver but in ide-dma.c:

--- linux-2.6.17.14/drivers/ide/ide-dma.c   2006-06-18 01:49:35.0 +
+++ linux-2.6.18.6/drivers/ide/ide-dma.c2006-09-20 03:42:06.0 +
@@ -752,7 +750,7 @@
goto bug_dma_off;
printk(", DMA");
} else if (id->field_valid & 1) {
-   printk(", BUG");
+   goto bug_dma_off;
}
return;
 bug_dma_off:


and reverting that change returns the old transfer rates. But that is
probably not a good idea.


3. To increase confusion: I had learned the ite8212 chip is close to
the cmd/sil680, and patching siimage.c had been a solution to get
support for 8212 before it showed up in the kernel.

So I tried this again:

--- ORG/linux-2.6.19.2/drivers/ide/pci/siimage.c2006-11-29 
21:57:37.0 +
+++ NEW/linux-2.6.19.2/drivers/ide/pci/siimage.c2007-01-14 
17:59:03.0 +
@@ -52,6 +52,7 @@
case PCI_DEVICE_ID_SII_1210SA:
return 1;
case PCI_DEVICE_ID_SII_680:
+   case PCI_DEVICE_ID_ITE_8212:
return 0;
}
BUG();
@@ -1082,6 +1083,7 @@

 static struct pci_device_id siimage_pci_tbl[] = {
{ PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_680,  PCI_ANY_ID, PCI_ANY_ID, 0, 
0, 0},
+   { PCI_VENDOR_ID_ITE, PCI_DEVICE_ID_ITE_8212,  PCI_ANY_ID, PCI_ANY_ID, 
0, 0, 0},
 #ifdef CONFIG_BLK_DEV_IDE_SATA
{ PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_3112, PCI_ANY_ID, PCI_ANY_ID, 0, 
0, 1},
{ PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_1210SA, PCI_ANY_ID, PCI_ANY_ID, 
0, 0, 2},


and disabled CONFIG_BLK_DEV_IT821X - and now the disk is even faster
than before:

/dev/hde:
 Timing cached reads:88 MB in  2.01 seconds =  43.71 MB/sec
 Timing buffered disk reads:   34 MB in  3.02 seconds =  11.25 MB/sec


So it seems the problem is it82xx.c at least for my controllers.


4. Now there is 2.6.19 and the new ata driver model. So I tried that
one, too:

Booting with 
| CONFIG_PATA_IT821X=m
stalls the system upon module load. The last kernel messages were

ata1.00: tag 0 cmd 0xc4 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: port failed to respond (30 secs, Status 0xd0)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: tag 0 cmd 0xc4 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: port failed to respond (30 secs, Status 0xd0)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: tag 0 cmd 0xc4 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: port failed to respond (30 secs, Status 0xd0)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: tag 0 cmd 0xc4 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: port failed to respond (30 secs, Status 0xd0)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: tag 0 cmd 0xc4 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: port failed to respond (30 secs, Status 0xd0)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: tag 0 cmd 0xc4 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: port failed to respond (30 secs, Status 0xd0)
Buffer I/O error on device sda, logical block 0


Patching the sil driver again:

--- ORG/linux-2.6.19.2/drivers/ata/pata_sil680.c2006-11-29 

Re: [RFC] How to (automatically) find the correct maintainer(s)

[Stefan Richter]

On 14 Jan, Richard Knutsson wrote:
> Stefan Richter wrote:
>> gcc -o test3.o test.c test.c
>>   
> That produces just an executable file with a misleading name :)

#-)

[...]
>> 3. When people notice that patches are misdirected too often, they will
>>update MAINTAINERS.
>>   
> You mean they update other maintainers entries? That would be good...

Strictly spoken, only Linus updates MAINTAINERS. Everybody else merely
sends change requests which are forwarded or rejected. If newbie John
Doe finds there is something missing in MAINTAINERS, he could send a
proper patch *to the proper contacts*, et voilà. In short, people
including John Doe updated MAINTAINERS.

[...]
>> May I remind that whoever uses scripts to figure out contacts should
>> better double-check what the script found out for him.
[...]
> During development, that's a given. But I would hope that when its more 
> stable it will always find the right answer or no answer at all (if 
> there is errors in ex MAINTAINERS, even the human will bother the receiver)

Note, if people build scripts which look up contacts, I hope they don't
become careless and forget to search elsewhere for proper contacts if
_no_ contact was found automatically.

[...]
>> It is already somewhat
>> costly to backtrack .c files from .o files from config options, but
>> considerably more so with .h files.
>> 
> I think it is to early to be thinking about what is easier, first a 
> "algorithm" that does what we want is needed, then I'm more then happy 
> to write a script/program for it :)
> Costly?? It is even simple in bash:
> C_FILE=${O_FILE/'.o'/'.c'}

When I wrote "somewhat costly" I didn't refer to a 1:1 mapping between
.c and .o. That's not what it takes. I mostly referred to having to
implement a parser for parts of the Linux Makefile language. On the
bright side, the more indirection you introduce, the less people will
write their own scripts and the less scripts with bugs will be out
there. :-)

[...]
> (I: for "include". Btw, what is F: standing for? Is it instead of P:?)
[...]

Doesn't need to be F. "Files" happens to start with F.
-- 
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/

SATA exceptions with 2.6.20-rc5

[Björn Steinbrink]

Hi,

with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite
often, with 2.6.19 there are no such exceptions. dmesg and lspci -v
output follows. In the meantime, I'll start bisecting.

Thanks
Björn


Linux version 2.6.20-rc2 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 
(prerelease) (Debian 4.1.1-21)) #4 SMP Sun Dec 31 12:54:22 CET 2006
Command line: root=/dev/md0 ro quiet 
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f000 (usable)
 BIOS-e820: 0009f000 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 7fee (usable)
 BIOS-e820: 7fee - 7fee3000 (ACPI NVS)
 BIOS-e820: 7fee3000 - 7fef (ACPI data)
 BIOS-e820: 7fef - 7ff0 (reserved)
 BIOS-e820: e000 - f000 (reserved)
 BIOS-e820: fec0 - 0001 (reserved)
Entering add_active_range(0, 0, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 524000) 1 entries of 256 used
end_pfn_map = 1048576
DMI 2.2 present.
ACPI: RSDP (v000 Nvidia) @ 0x000f7a70
ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x7fee3040
ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x7fee30c0
ACPI: SSDT (v001 PTLTD  POWERNOW 0x0001  LTP 0x0001) @ 
0x7fee9540
ACPI: SRAT (v001 AMDHAMMER   0x0001 AMD  0x0001) @ 
0x7fee9780
ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x7fee9480
ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 
0x
Entering add_active_range(0, 0, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 524000) 1 entries of 256 used
Zone PFN ranges:
  DMA 0 -> 4096
  DMA324096 ->  1048576
  Normal1048576 ->  1048576
early_node_map[2] active PFN ranges
0:0 ->  159
0:  256 ->   524000
On node 0 totalpages: 523903
  DMA zone: 56 pages used for memmap
  DMA zone: 1122 pages reserved
  DMA zone: 2821 pages, LIFO batch:0
  DMA32 zone: 7108 pages used for memmap
  DMA32 zone: 512796 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
ACPI: IRQ9 used by override.
ACPI: IRQ14 used by override.
ACPI: IRQ15 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Nosave address range: 0009f000 - 000a
Nosave address range: 000a - 000f
Nosave address range: 000f - 0010
Allocating PCI resources starting at 8000 (gap: 7ff0:6010)
PERCPU: Allocating 32000 bytes of per cpu data
Built 1 zonelists.  Total pages: 515617
Kernel command line: root=/dev/md0 ro quiet 
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Checking aperture...
CPU 0: aperture @ 5a7400 size 32 MB
Aperture too small (32 MB)
No AGP bridge found
Memory: 2059000k/2096000k available (2795k kernel code, 36392k reserved, 1089k 
data, 224k init)
Calibrating delay using timer specific routine.. 4422.42 BogoMIPS (lpj=22112114)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
Freeing SMP alternatives: 28k freed
ACPI: Core revision 20060707
Using local APIC timer interrupts.
result 12558084
Detected 12.558 MHz APIC timer.
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 4420.44 BogoMIPS (lpj=22102213)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping 02
CPU 1: Syncing TSC to CPU 0.
CPU 1: synchronized TSC with CPU 0 (last diff 89 cycles, maxerr 393 cycles)
Brought up 2 CPUs
testing NMI watchdog ... OK.
Disabling vsyscall due to use of PM timer
time.c: Using 3.579545 MHz WALL PM GTOD PM timer.
time.c: 

Re: "svc: unknown version (3)" when CONFIG_NFSD_V4=y

[Neil Brown]

On Saturday January 13, [EMAIL PROTECTED] wrote:
> On Sat, Jan 13, 2007 at 06:43:07AM +1100, Neil Brown wrote:
> > 
> > Ok, thanks.  I must have missed something else wrong in the code..
> > 
> > Probably this 'break' in the wrong place...
> > 
> > Could you try this patch instead please - or just move the 'break' to
> > where it should be.
> 
> Now it worked :)

Thanks.  I'll try to get those fixes into 2.6.20...

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc4-mm1

[Jens Axboe]

On Sun, Jan 14 2007, Thomas Gleixner wrote:
> On Mon, 2007-01-15 at 09:05 +1100, Jens Axboe wrote:
> > raid seems to have severe problems with the plugging change. I'll try
> > and find Neil and have a chat with him, hopefully we can work it out.
> 
> Some hints:
> 
> mount(1899): WRITE block 16424 on md3
> call md_write_start
> md3_raid1(438): WRITE block 40965504 on sdb6
> md3_raid1(438): WRITE block 40965504 on sda6
> First Write sector 16424 disks 2
> 
> Stuck.
> 
> Note, that neither end_buffer_async_write() nor
> raid1_end_write_request() are invoked, 
> 
> In a previous write invoked by:
> fsck.ext3(1896): WRITE block 8552 on sdb1
> end_buffer_async_write() is invoked.
> 
> sdb1 is not a part of a raid device.

When I briefly tested this before I left (and found it broken), doing a
cat /proc/mdstat got things going again. Hard if that's your rootfs,
it's just a hint :-)

> Hope that helps,

I can reproduce, so that's not a problem. I can't do much about it until
I'm back next week, but Neil might be able to help. We shall see. Thanks
for testing.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc4-mm1

[Thomas Gleixner]

On Mon, 2007-01-15 at 09:05 +1100, Jens Axboe wrote:
> raid seems to have severe problems with the plugging change. I'll try
> and find Neil and have a chat with him, hopefully we can work it out.

Some hints:

mount(1899): WRITE block 16424 on md3
call md_write_start
md3_raid1(438): WRITE block 40965504 on sdb6
md3_raid1(438): WRITE block 40965504 on sda6
First Write sector 16424 disks 2

Stuck.

Note, that neither end_buffer_async_write() nor
raid1_end_write_request() are invoked, 

In a previous write invoked by:
fsck.ext3(1896): WRITE block 8552 on sdb1
end_buffer_async_write() is invoked.

sdb1 is not a part of a raid device.

Hope that helps,

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: 2.6.20-rc4-mm1 md problem

[Jens Axboe]

On Fri, Jan 12 2007, Michal Piotrowski wrote:
> On 12/01/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> >On 12/01/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> >> On Friday, 12 January 2007 14:33, Michal Piotrowski wrote:
> >> > My system hangs on this
> >> > 
> >http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc4-mm1/bug2.jpg
> >> > 
> >http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc4-mm1/mm-config
> >> >
> >> > Debug plan:
> >> > - revert md-* patches
> >> > - binary search
> >> >
> >> > Does someone have a better idea?
> >>
> >> Revert git-block.patch and related stuff?
> >
> >Indeed.
> >
> >GOOD
> >#
> >##git-sym2.patch
> >#git-scsi-target.patch
> >#git-scsi-target-fixup.patch
> >#
> >git-block.patch
> >git-block-fixup.patch
> >BAD
> >
> >git-block.patch it's huge patch.
> >
> >diffstat git-block.patch
> >[..]
> >drivers/md/bitmap.c |1
> > drivers/md/dm-emc.c |2
> > drivers/md/dm-table.c   |   14 -
> > drivers/md/dm.c |   18 -
> > drivers/md/dm.h |1
> > drivers/md/linear.c |   14 -
> > drivers/md/md.c |3
> > drivers/md/multipath.c  |   32 --
> > drivers/md/raid0.c  |   17 -
> > drivers/md/raid1.c  |   70 -
> > drivers/md/raid10.c |   73 --
> > drivers/md/raid5.c  |   60 
> >[..]
> >
> >I'll do a binary search through those files.
> >
> 
> That wasn't a good idea.
> 
> /mnt/md0/devel/linux-mm/drivers/md/raid1.c: In function 'unplug_slaves':
> /mnt/md0/devel/linux-mm/drivers/md/raid1.c:556: error:
> 'request_queue_t' has no member named 'unplug_fn'

You can't go throught he individual files and expect that to compile,
yet alone work. Fortunately I think I already fixed this last week,
unfortunately I think I forgot to push the #plug branch for #for-akpm so
that Andrew automatically picks it up...

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc4-mm1

[Jens Axboe]

On Sun, Jan 14 2007, Thomas Gleixner wrote:
> On Sun, 2007-01-14 at 11:46 +0100, Thomas Gleixner wrote:
> > > Boot proceeds, but gets stuck hard at:
> > > "Remounting root filesystem in read-write mode:"
> > > 
> > > No SysRq-T, nothing.
> > > 
> > > The above BUG seems unrelated to that. Investigating further.
> > 
> > Bisect identified: git-block.patch
> 
> Does only happen on 2 systems. Both have sata + raid1 setup. I managed 
> to get a stacktrace from the SMP box. Sits there and sleeps forever.
> 
>   tglx
> 
> [] io_schedule+0x7a/0x9a
> [] sleep_on_page+0x8/0xc
> [] __wait_on_bit+0x36/0x5d
> [] wait_on_page_bit+0x5b/0x61
> [] wait_on_page_writeback_range+0x4f/0xef
> [] filemap_fdatawait+0x44/0x49
> [] filemap_write_and_wait+0x22/0x2d
> [] sync_blockdev+0x17/0x1d
> [] quota_sync_sb+0x33/0xd6
> [] sync_dquots+0x22/0xfa
> [] __fsync_super+0x17/0x66
> [] fsync_super+0xb/0x19
> [] do_remount_sb+0x49/0x101
> [] do_mount+0x1ad/0x678
> [] sys_mount+0x6f/0xa4
> [] sysenter_past_esp+0x5f/0x99

raid seems to have severe problems with the plugging change. I'll try
and find Neil and have a chat with him, hopefully we can work it out.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] How to (automatically) find the correct maintainer(s)

[Richard Knutsson]

Matthias Schniedermeyer wrote:

Richard Knutsson wrote:
  

Matthias Schniedermeyer wrote:



Richard Knutsson wrote:

 

  

Any thoughts on this is very much appreciated (is there any flaws with
this?).



The thought that crossed my mind was:

Why not do the same thing that was done to the "Help"-file. (Before it
was superseded by Kconfig).

Originaly there was a central Help-file, with all the texts. Then it was
split and placed in each sub-dir. And later it was superseded by Kconfig.

On the other hand you could skip the intermediate step and just fold the
Maintainer-data directly into Kconfig, that way everything is "in one
place" and you could place a "Maintainers"-Button next to the
"Help"-Button in *config, or just display it alongside the help.

And MAYBE that would also lessen the "update-to-date"-problem, as you
can just write the MAINTAINERs-data when you create/update the
Kconfig-file. Which is a thing that creates much bigger pain when you
forget it accidently. ;-)

Oh, and it neadly solves the mapping-problem, for at least all
kernel-parts that have a Kconfig-option/Sub-Tree.
  
  

I'm all for splitting up the MAINTAINERS! :)

Just, do you have any ideas how to solve the possible multiple of the
same entries, when handling multiple sub-directories and when many
different drivers with different maintainers are in the same directory
and a maintainer have more then one driver?



Handles.
If a Maintainer maintains several subsystems/drivers a "handle" could be
used to references to a handle-list (hello MAINTAINERS) or to the place
where the full-maintainers-entry is placed.
  
Mm, and maybe store the entry on the shortest-pathway common directory. 
Then there should be just a few left entries in the current MAINTAINERS. 
But how to create the handles?

* Name (problem with persons with the same name)
* E-mail (much to change when they change it)
This also make a problem when there is a change of the maintainer, what 
happens with the entry if there is no maintainer?

* Just numbers and increase every new one with one? (quite ugly!)
... and here is the end of my ideas.

Any good ideas? (Really liked the idea to have a "Maintainer"-button 
next to "Help" in *config)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] How to (automatically) find the correct maintainer(s)

[Richard Knutsson]

Stefan Richter wrote:

On 14 Jan, Richard Knutsson wrote:
  

Stefan Richter wrote:


[getting a wrong contact from looking at the MAINTAINERS file]
  
Hopefully, but I think it is asking much of the maintainer and then 
there will certanly be confused/frustrated submitter who don't know why 
they don't get any answer nor patched included. We have already seen a 
few asking about what happened with their patches.



Sure. But such glitches occur due to lack of research by the submitter
or due to missing information about maintainers. Neither one would be
made worse nor cured by adding script-readable references to sources or
config options to the MAINTAINERS file.
  

I suspect I have misunderstood your idea. Correct me if this is wrong:
if you add:

F:  drivers/pci

Then also the directories hotplug and pcie (and its content) will fall 
to that entry, unless there is someone adding:


F:  drivers/pci/hotplug

in their entry.

With the approach I suggested that is not possible (unless introducing 
wildcards).


Also, a maintainer for the "hotplug" have to add:

F:  drivers/pci/hotplug
F:  drivers/pci/setup-bus
or
C:  HOTPLUG

and what will hinder it from including drivers/pci/hotplug/ other then 
adding the F: on PCI Hotplugs maintainer? (yes, this is no real problem 
since they probably are the same maintainer or just add the F: )

Can you make a object-file out of 2 c-files? Using Makefile?


Yes, you can, although I don't know if it is directly done in the
kernel build system.
  

[...]
  

How?:
gcc -c test.c test2.c -o test3.o
gcc: cannot specify -o with -c or -S with multiple files
(with only -c i got test.o and test2.o)



gcc -o test3.o test.c test.c
  
That produces just an executable file with a misleading name :) (test 
with two files were neither has a 'main()')

You need the '-c'-flag to tell the gcc just make them to object-files.
  
In the kernel building system, an object-file is made from a c- or 
s-file with the same name. Then, of course, they can be put together to 
a larger object-file.


[...]
[multiple references in one maintainer record]
  

What about possibility to replace it with:

C:  IEEE1394*

and use the same system as with the path-approach, "longest wins". (I 
don't think just IEEE1394 is appropriate, since then there is 
possibility with false-positives again)



I doubt that wildcards (or maybe regular expressions) are really needed.
But this can only be found out by going through some non-trivial cases.
  

Mm, that is just a feature. Best to get the basics straighten out first :)

On the other hand, we could write

IEEE 1394 SUBSYSTEM
F:  drivers/ieee1394
L:  [EMAIL PROTECTED]
P:  Ben and me
[...]
IEEE 1394 IPV4 DRIVER (eth1394)
F:  drivers/ieee1394/eth1394
[...]

If it was done the latter way, i.e. using F: not C:, it could be
made a rule that the more specific entries come after more generic
entries. Thus the last match of multiple matches is the proper one.
In any case, the longest match is the proper one.
  
  
As I wrote in the initial mail, my first idea was like that. But how to 
solve when different drivers (with of course different maintainers) lies 
in the same directory?



To continue my above example:

IEEE 1394 PCILYNX DRIVER
F:  drivers/ieee1394/pcilynx

Should work. Note, the substrings "eth1394" and "pcilynx" do not denote
subdirectories. They are substrings of the paths to these drivers'
sources nonetheless.
  

Absolutely, also it can easily refer to the "include header-files" by:

F:  include/linux/pci.h

which is not as easily done in "my" way. The local headers are ok I 
think as the c-files that includes it should have the same maintainer, 
but ex pci.h are used by _quite_ many drivers. But is the headers in the 
include/-directory just a matter for the maintainer since they are 
globally reachable. But I think this is _the_ downside of that approach.
I thought something like include/linux/config.h,autoconf.h could be used 
when referring to a few specific files in a directory. But there is also 
the problem that all mails were the maintainer has no F: will fall in 
the lap of the "good" maintainer with the shorter pathway, and I'm 
afraid this might make people hesitant to add the F:.



1. The same can be said about the C: method, or about the status quo.
  

No, since it is either a hit or it is not. Without wildcards, an entry like:

C:  CONFIG_IEEE1394

would not pick up ex CONFIG_IEEE1394_RAWIO.

2. The patches will typically be Cced to the respective mailinglist
   where the driver maintainer can harvest the patch or can send an ACK
   or NAK as a signal to the subsystem maintainer whether to pick it up.
3. When people notice that patches are misdirected too often, they will
   update MAINTAINERS.
  

You mean they update other maintainers entries? That would be good...

[...]
  

It is just the problems with false-positives and picking out 

Re: umask ignored in mkdir(2)?

[Tigran Aivazian]

I figured it out! I thought you might be interested --- the reason is the 
mismatch between the default mount options stored in the superblock on 
disk and the filesystem features compiled into the kernel.


Namely, dumpe2fs on the offending filesystems showed the following default 
mount options:


user_xattr acl

but on good filesystems it showed "(none)". So, I used "tune2fs -o ^acl"
(and ^user_xattr) to clear these in the superblock and mounted the 
filesystem --- and now mkdir system call works as expected, i.e. 
honours the umask.


Maybe the ext3 filesystem should automatically detect this (the mismatch) 
and printk a warning so the user is told that his filesystem is mounted in 
extremely insecure way, i.e. making directories as root will result in 
lots of 0777 places (e.g. try "make modules_install" --- this will create 
lots of security holes in /lib/modules).


I cc'd linux-kernel as someone may wish to fix this. (see below for the 
actual report).


Kind regards
Tigran

On Sun, 14 Jan 2007, Tigran Aivazian wrote:

I forgot to mention that on another machine running the same kernel version 
with the same (as close as a UP machine can be to SMP) kernel configuration 
the umask is honoured properly on ext3 filesystem.


On Sun, 14 Jan 2007, Tigran Aivazian wrote:


Hi Hugh,

I think I may have found a bug --- on one of my machines the umask value is 
ignored by ext3 (but honoured on tmpfs) for mkdir system call:


$ cd /tmp
$ df -T .
FilesystemType   1K-blocks  Used Available Use% Mounted on
/dev/hdf1 ext3   189238556 155721568  23749068  87% /
$ rmdir ok ; mkdir ok ; ls -ld ok
rmdir: ok: No such file or directory
drwxrwxrwx 2 tigran tigran 4096 Jan 14 20:36 ok/
$ umask
0022
$ cd /dev/shm
$ df -T .
FilesystemType   1K-blocks  Used Available Use% Mounted on
tmpfstmpfs  517988 0517988   0% /dev/shm
$ rmdir ok ; mkdir ok ; ls -ld ok
rmdir: ok: No such file or directory
drwxr-xr-x 2 tigran tigran 40 Jan 14 20:36 ok/
$ uname -a
Linux ws 2.6.19.1 #6 SMP Sun Jan 14 20:03:30 GMT 2007 i686 i686 i386 
GNU/Linux

$ grep -i acl /usr/src/linux/.config
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFSD_V3_ACL is not set

As you see, ACL is not configured in, and neither are extended attributes:

$ grep -i xattr /usr/src/linux/.config
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT3_FS_XATTR is not set

So, this is something fs-specific. What do you think?

Kind regards
Tigran




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] 2.6.20-rc4: usb somehow broken

[Oliver Neukum]

Am Sonntag, 14. Januar 2007 20:47 schrieb [EMAIL PROTECTED]:
> > When the scanner is not in use, the system automatically suspends it after
> > two seconds.  When you use sane the scanner is resumed, but it then
> > disconnects itself and reconnects.  Sane is left trying to control the
> > disconnected device instance, so of course it fails.
> >
> > I'm beginning to think that we need some way to deal with devices that
> > cannot recover from a suspend.  Several examples have cropped up.
> > Unfortunately, I can't think of anything better than a blacklist, which is
> > not very satisfactory.
> >
> > Can anyone suggest another approach?
> >
> > Alan Stern
> 
> Just a thought, you could use both a blacklist approach, and a module 
> paramater, or something in sysfs, to allow specifying devices that won't 
> be suspend and resume compatible.

Yes,
but in any case the sysfs attributes would have to populated somehow.
You'd just shift the burden. As this behavior is hopefully rare, it's
probably not worth the effort.

I can't think of anything better than a blacklist.

Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: allocation failed: out of vmalloc space error treating and VIDEO1394 IOC LISTEN CHANNEL ioctl failed problem

[Arjan van de Ven]

On Sun, 2007-01-14 at 21:31 +0100, Stefan Richter wrote:
> On 14 Jan, Arjan van de Ven wrote:
> > vmalloc space is limited; you really can't assume you can get any more
> > than 64Mb or so (and even then it's thight on some systems already);
> 
> I suppose "grep VmallocChunk /proc/meminfo" shows what is available?
> 
> > it really sounds like vmalloc space isn't the right solution for your
> > problem whatever it is (context is lost in the quoted mail)...
> > can you restate the problem to see if there's a better solution
> > possible?
> 
> Thanks. Below is Peter's message to linux1394-devel. The previous
> discussion went over libdc1394-devel which I don't receive. Obviously he
> wants a really large buffer for reception of an isochronous stream. I
> guess his reason is highly application specific...


but why does that even use vmalloc? You can just do a scatter gather
thing instead... and keep a list of pages that you're mapping into
userspace. vmalloc isn't really a requirement for that

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: allocation failed: out of vmalloc space error treating and VIDEO1394 IOC LISTEN CHANNEL ioctl failed problem

[Stefan Richter]

On 14 Jan, Arjan van de Ven wrote:
> vmalloc space is limited; you really can't assume you can get any more
> than 64Mb or so (and even then it's thight on some systems already);

I suppose "grep VmallocChunk /proc/meminfo" shows what is available?

> it really sounds like vmalloc space isn't the right solution for your
> problem whatever it is (context is lost in the quoted mail)...
> can you restate the problem to see if there's a better solution
> possible?

Thanks. Below is Peter's message to linux1394-devel. The previous
discussion went over libdc1394-devel which I don't receive. Obviously he
wants a really large buffer for reception of an isochronous stream. I
guess his reason is highly application specific...

| Hi all,
| 
| I've been trying to get a resolution to the problem with vmalloc error (the 
| < to increase 
| size.>> kernel error message thing). The plan how to resolve the issue is 
| simple; get the buffer size that we try to allocate (vmmap.nb_buffers * 
| vmmap.buf_size) and compare it to the VMALLOC_RESERVED. If too big, error 
| with explanation how to fix it. If small, other error (usual out of mem). 
| Problem is: how to get the VMALLOC_RESERVED value for the kernel that is 
| running? I couldn't find any standard way to do that (something to apply to 
| GNU Linux and the like). All the things I could get were the default value 
| being 128MiB :) and that is it. Now, I could just put 128, but what if 
| somebody changes that, or in some new distro suddenly decides to make it 
| different? Even worse, what if it is an old kernel with 64 setting?
| 
| Currently, in the SVN version, Damien was kind to change so that a message 
| gets printed with a full explanation of how to treat it. Still, this is a 
| compromise solution and not the elegant one that I was looking for. I believe 
| and hope that maybe somebody had this issue before and could help with some 
| suggestions...
| 
| So, my question is: anybody knows the way to get to the kernel value like 
| VMALLOC_RESERVED or something around this area (a function like getpagesize 
| or sysconf)? It will do a great deal to solve the problematic error treatment 
| in the library...
| 
| Thank you.
| 
| For your reference, this is in response to this line of thinking or the 
| libdc1394-devel thread:
| [...]
| > > When I set NUM_BUFFERS (number of DMA buffers) to a value greater than 5
| > > the program dies like this:
| > >
| > > (dc1394_capture.c) VIDEO1394_IOC_LISTEN_CHANNEL ioctl failed!
| > > Libdc1394 error (dc1394_capture.c:dc1394_capture_setup_dma:382): Capture
| > > is not set : Could not setup DMA capture
| [...]
| > > [17723533.496000] video1394_0: Iso receive DMA: 8 buffers of size
| > > 6627328 allocated for a frame size 6624000, each with 1619 prgs
| > > [17723533.516000] video1394_0: iso context 0 listen on channel 1
| > > [17723533.712000] ieee1394: Node [1-01:1023] wants to release broadcast
| > > channel 31.  Ignoring.
| > > [17723534.448000] video1394_1: mask: 0004 usage:
| > > 
| > > [17723534.448000]
| > > [17723534.508000] video1394_1: Iso receive DMA: 8 buffers of size
| > > 6627328 allocated for a frame size 6624000, each with 1619 prgs
| > > [17723534.532000] video1394_1: iso context 0 listen on channel 2
| > > [17723534.728000] ieee1394: Node [2-01:1023] wants to release broadcast
| > > channel 31.  Ignoring.
| > > [17723535.464000] video1394_2: mask: 0008 usage:
| > > 
| > > [17723535.464000]
| > > [17723535.464000] printk: 11 messages suppressed.
| > > [17723535.464000] allocation failed: out of vmalloc space - use
| > > vmalloc= to increase size.
| > > [17723535.464000] dma_region_alloc: vmalloc_32() failed
| > > [17723535.464000] video1394_2: Failed to allocate dma buffer
| > > [17723535.464000] video1394_2: Couldn't allocate ir context
| > > [17723535.668000] video1394_0: On release: Iso receive context 0 stop
| > > listening on channel 1
| > > [17723535.676000] video1394_1: On release: Iso receive context 0 stop
| > > listening on channel 2
| [...]
| > --
| >
| > Message: 2
| > Date: Fri, 05 Jan 2007 17:30:39 +0100
| > From: Martin Peris 
| > Subject: Re: [libdc1394-devel] [SPAM RBL] Re:
| > VIDEO1394_IOC_LISTEN_CHANNELioctl failed! and Bad images
| > To: Damien Douxchamps 
| > Cc: libdc1394-devel 
| [...]
| > I think I have some answers...
| >
| > I've been investigating a bit, and the  problem with the limit in the
| > size of the allocated DMA buffer  is not so obscure.
| >
| > vmalloc_32() allocate virtually contiguous memory (32bit addressable),
| > the default maximum amount of memory reserved for this depends on each
| > kernel compilation, and in my case it was set to 128Mbytes that's why I
| > had an error if tried to allocate too many buffers.
| >
| >  but at boot time you can specify how much virtually contiguous memory
| > you want with the parameter vmalloc, so if you want about 512Mbytes of
| > 

Re: Linux 2.6.20-rc5

[William Heimbigner]

On Sun, 14 Jan 2007, Robert P. J. Day wrote:


On Sun, 14 Jan 2007, [EMAIL PROTECTED] wrote:


In compiling:
  CC [M]  net/ipv4/netfilter/ipt_TTL.o
  LD [M]  drivers/usb/storage/usb-storage.o
  CC [M]  drivers/usb/gadget/net2280.o
  CC [M]  net/ipv4/netfilter/arp_tables.o
drivers/usb/gadget/net2280.c: In function 'net2280_probe':
drivers/usb/gadget/net2280.c:2969: warning: ignoring return value of
'pci_set_mwi', declared with attribute warn_unused_result
--
  CC [M]  net/netfilter/xt_tcpmss.o
  CC [M]  net/netfilter/xt_hashlimit.o
  LD [M]  net/netfilter/nf_conntrack.o
  Building modules, stage 2.
  MODPOST 239 modules
WARNING: "__ucmpdi2" [drivers/media/video/v4l2-common.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

If a .config is needed or any other information, I'd be happy to provide it.


is this for a powerpc?  there's a thread you might want to read:

http://uwsg.iu.edu/hypermail/linux/kernel/0612.1/2162.html

rday

That ended up causing another undefined issue in a different place, but I 
did find http://uwsg.iu.edu/hypermail/linux/kernel/0612.2/0223.html


Seems like we may want to have this patched, until the compiler gets fixed 
to properly handle it.


William Heimbigner
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

incorrect TCP checksum on sent TCP-MD5 packets (2.6.20-rc5)

[Torsten Luettgert]

Hi,

I'm using the new TCP-MD5 option in 2.6.20-rc4 and rc5
to talk BGP to cisco routers.
My box connects to the cisco, and the handshake looks fine:
SYN, SYN/ACK, ACK all have md5 option and correct TCP checksums.

All packets after that, i.e. the ones with payload data,
have wrong TCP checksums, quoth wireshark.
The same happens if the cisco connects: the first, "empty" packet
is ok, packets with payload aren't.

Am I doing something wrong? Or is this a bug?

I'll gladly send tcpdumps if it helps.

Thanks for your help,
Torsten

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] netfilter: implement TCPMSS target for IPv6

[Jan Engelhardt]

On Jan 14 2007 20:20, David Madore wrote:
>
>Implement TCPMSS target for IPv6 by shamelessly copying from
>Marc Boucher's IPv4 implementation.
>
>Signed-off-by: David A. Madore <[EMAIL PROTECTED]>

Would not it be worthwhile to merge ipt_TCPMSS and
ip6t_TCPMSS to xt_TCPMSS instead?


-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] binfmt_elf: core dump masking support

[Pavel Machek]

Hi!

> > Well, you can have it as set of 0-1 "limits"...
> 
> I have come up with a similar idea of regarding the ulimit
> value as a bitmask, and I think it may work.
> But it will be confusable for users to add the new concept of
> 0-1 limitation into the traditional resouce limitation feature.
> Additionaly, this approach needs a modification of each shell
> command.
> What do you think about these demerits?

> The /proc// approach doesn't have these demerits, and it
> has an advantage that users can change the bitmask of any process
> at anytime.

Well... not sure if it is advantage. Semantics of ulimit inheritance
are well given, for example. How is this going to be inherited?

Anyway, yes, I see 0/1 "limits" have bad sides, too, so...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] lockdep: shrink held_lock structure

[Ingo Molnar]

* Ingo Molnar <[EMAIL PROTECTED]> wrote:

> Subject: [patch] lockdep: shrink held_lock structure
> From: Dave Jones <[EMAIL PROTECTED]>
> 
> shrink the held_lock structure from 40 to 20 bytes. This shrinks struct 
> task_struct from 3056 to 2464 bytes.
> 
> [ From: Ingo Molnar <[EMAIL PROTECTED]>, shrunk hlock->class too. ]

doh - some buglet sneaked into the hlock->class_idx change ... 
investigating it. Ignore this patch for now.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] lockdep: shrink held_lock structure

[Ingo Molnar]

Subject: [patch] lockdep: shrink held_lock structure
From: Dave Jones <[EMAIL PROTECTED]>

shrink the held_lock structure from 40 to 20 bytes. This shrinks struct 
task_struct from 3056 to 2464 bytes.

[ From: Ingo Molnar <[EMAIL PROTECTED]>, shrunk hlock->class too. ]

Shrunk MAX_KEYS_BITS from 11 to 10, and thus kernel size
goes down significantly too:

textdata bss dec hex filename
 5297365  642664 3203072 9143101  8b833d vmlinux.before
 5298257  642024 2953216 8893497  87b439 vmlinux.after

Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 include/linux/lockdep.h|   16 ---
 kernel/lockdep.c   |   91 -
 kernel/lockdep_internals.h |3 -
 3 files changed, 58 insertions(+), 52 deletions(-)

Index: linux/include/linux/lockdep.h
===
--- linux.orig/include/linux/lockdep.h
+++ linux/include/linux/lockdep.h
@@ -143,6 +143,9 @@ struct lock_chain {
u64 chain_key;
 };
 
+#define MAX_LOCKDEP_KEYS_BITS  10
+#define MAX_LOCKDEP_KEYS   (1UL << MAX_LOCKDEP_KEYS_BITS)
+
 struct held_lock {
/*
 * One-way hash of the dependency chain up to this point. We
@@ -159,10 +162,9 @@ struct held_lock {
 * with zero), here we store the previous hash value:
 */
u64 prev_chain_key;
-   struct lock_class   *class;
unsigned long   acquire_ip;
struct lockdep_map  *instance;
-
+   int class_idx:MAX_LOCKDEP_KEYS_BITS;
/*
 * The lock-stack is unified in that the lock chains of interrupt
 * contexts nest ontop of process context chains, but we 'separate'
@@ -176,11 +178,11 @@ struct held_lock {
 * The following field is used to detect when we cross into an
 * interrupt context:
 */
-   int irq_context;
-   int trylock;
-   int read;
-   int check;
-   int hardirqs_off;
+   unsigned char irq_context:1;
+   unsigned char trylock:1;
+   unsigned char read:2;
+   unsigned char check:1;
+   unsigned char hardirqs_off:1;
 };
 
 /*
Index: linux/kernel/lockdep.c
===
--- linux.orig/kernel/lockdep.c
+++ linux/kernel/lockdep.c
@@ -128,6 +128,11 @@ static struct lock_class lock_classes[MA
  */
 LIST_HEAD(all_lock_classes);
 
+static inline struct lock_class *hlock_class(struct held_lock *hlock)
+{
+   return lock_classes + hlock->class_idx;
+}
+
 /*
  * The lockdep classes are in a hash-table as well, for fast lookup:
  */
@@ -416,7 +421,7 @@ static void print_lockdep_cache(struct l
 
 static void print_lock(struct held_lock *hlock)
 {
-   print_lock_name(hlock->class);
+   print_lock_name(hlock_class(hlock));
printk(", at: ");
print_ip_sym(hlock->acquire_ip);
 }
@@ -594,7 +599,7 @@ static noinline int print_circular_bug_t
if (debug_locks_silent)
return 0;
 
-   this.class = check_source->class;
+   this.class = hlock_class(check_source);
if (!save_trace())
return 0;
 
@@ -639,7 +644,7 @@ check_noncircular(struct lock_class *sou
 * Check this lock's dependency list:
 */
list_for_each_entry(entry, >locks_after, entry) {
-   if (entry->class == check_target->class)
+   if (entry->class == hlock_class(check_target))
return print_circular_bug_header(entry, depth+1);
debug_atomic_inc(_cyclic_checks);
if (!check_noncircular(entry->class, depth+1))
@@ -773,9 +778,9 @@ print_bad_irq_dependency(struct task_str
printk("\nand this task is already holding:\n");
print_lock(prev);
printk("which would create a new lock dependency:\n");
-   print_lock_name(prev->class);
+   print_lock_name(hlock_class(prev));
printk(" ->");
-   print_lock_name(next->class);
+   print_lock_name(hlock_class(next));
printk("\n");
 
printk("\nbut this new dependency connects a %s-irq-safe lock:\n",
@@ -816,12 +821,12 @@ check_usage(struct task_struct *curr, st
 
find_usage_bit = bit_backwards;
/* fills in  */
-   ret = find_usage_backwards(prev->class, 0);
+   ret = find_usage_backwards(hlock_class(prev), 0);
if (!ret || ret == 1)
return ret;
 
find_usage_bit = bit_forwards;
-   ret = find_usage_forwards(next->class, 0);
+   ret = find_usage_forwards(hlock_class(next), 0);
if (!ret || ret == 1)
return ret;
/* ret == 2 */
@@ -874,7 +879,7 @@ 

Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken

[icxcnika]

On Sun, 14 Jan 2007, Alan Stern wrote:


On Sun, 14 Jan 2007, Prakash Punnoor wrote:


Am Sonntag 14 Januar 2007 10:28 schrieb Oliver Neukum:

Am Sonntag, 14. Januar 2007 10:08 schrieb Prakash Punnoor:

Am Donnerstag 11 Januar 2007 18:28 schrieb Oliver Neukum:

Am Donnerstag, 11. Januar 2007 18:20 schrieb Prakash Punnoor:

Hi,

I can't scan anymore. :-( I don't know which rc kernel introduced it,
but this are the messages I get (w/o touching the device/usb cable
except pluggin it in for the first time):

usb 1-1.2: new full speed USB device using ehci_hcd and address 4
ehci_hcd :00:0b.1: qh 81007bc6c280 (#00) state 4
usb 1-1.2: configuration #1 chosen from 1 choice
usb 1-1.2: USB disconnect, address 4
usb 1-1.2: new full speed USB device using ehci_hcd and address 5
usb 1-1.2: configuration #1 chosen from 1 choice
usb 1-1.2: USB disconnect, address 5
usb 1-1.2: new full speed USB device using ehci_hcd and address 6
usb 1-1.2: configuration #1 chosen from 1 choice
usb 1-1.2: USB disconnect, address 6
usb 1-1.2: new full speed USB device using ehci_hcd and address 7
usb 1-1.2: configuration #1 chosen from 1 choice
usb 1-1.2: USB disconnect, address 7
usb 1-1.2: new full speed USB device using ehci_hcd and address 8
usb 1-1.2: configuration #1 chosen from 1 choice


[..]


Hi, I did more tests and I was wrong about "broken". It seems more a
time-out problem, ie if I try to use sane again in short intervalls, I
will get my device working. The cause seems CONFIG_USB_SUSPEND=y. With
2.6.20-rc5 the


Have you confirmed that by using a kernel without  CONFIG_USB_SUSPEND ?


Yes. I compiled the modules with various settings, reloaded the modules and
above option made the difference. I also don't get the disconnect mesages, as
well, w/o USB_SUSPEND.


Judging from the log, it looks like the scanner cannot handle being
suspended.  (BTW this is in violation of the USB specification -- all
devices must be able to suspend and resume.)

When the scanner is not in use, the system automatically suspends it after
two seconds.  When you use sane the scanner is resumed, but it then
disconnects itself and reconnects.  Sane is left trying to control the
disconnected device instance, so of course it fails.

I'm beginning to think that we need some way to deal with devices that
cannot recover from a suspend.  Several examples have cropped up.
Unfortunately, I can't think of anything better than a blacklist, which is
not very satisfactory.

Can anyone suggest another approach?

Alan Stern


Just a thought, you could use both a blacklist approach, and a module 
paramater, or something in sysfs, to allow specifying devices that won't 
be suspend and resume compatible.


William Heimbigner
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: O_DIRECT question

[Bodo Eggert]

Bill Davidsen <[EMAIL PROTECTED]> wrote:

> My point is, that there is code to handle sparse data now, without
> O_DIRECT involved, and if O_DIRECT bypasses that, it's not a problem
> with the idea of O_DIRECT, the kernel has a security problem.

The idea of O_DIRECT is to bypass the pagecache, and the pagecache is what
provides the security against reading someone else's data using sparse
files or partial-block-IO.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc5] intel_rng: substitue magic PCI IDs with macros

[Dave Airlie]

On 1/15/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:

On Sun, 2007-01-14 at 19:24 +0200, Ahmed S. Darwish wrote:
> Substitue intel_rng magic PCI IDs values used in the IDs table
> with the macros defined in pci_ids.h
>
Hi,


hmm this is actually the opposite direction than most of the kernel is
heading in, mostly because the pci_ids.h file is a major maintenance
pain.

Afaik the current "rule" is: if a PCI ID is only used in one driver, use
the numeric value and not (add) a symbolic constant.



My guess is that the RNG is on the LPC so the values are used in a few places..

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/

[patch] netfilter: implement TCPMSS target for IPv6

[David Madore]

Implement TCPMSS target for IPv6 by shamelessly copying from
Marc Boucher's IPv4 implementation.

Signed-off-by: David A. Madore <[EMAIL PROTECTED]>

---

 Note: The patch for ip6tables to make use of this module can be
 obtained from ftp://quatramaran.ens.fr/pub/madore/misc/ip6t-TCPMSS/
 > (also contains a version of this same patch for 2.6.19.2).

 include/linux/netfilter_ipv6/ip6t_TCPMSS.h |   10 ++
 net/ipv6/netfilter/Kconfig |   26 
 net/ipv6/netfilter/Makefile|1 +
 net/ipv6/netfilter/ip6t_TCPMSS.c   |  225 
 4 files changed, 262 insertions(+), 0 deletions(-)

diff --git a/include/linux/netfilter_ipv6/ip6t_TCPMSS.h 
b/include/linux/netfilter_ipv6/ip6t_TCPMSS.h
new file mode 100644
index 000..412d1cb
--- /dev/null
+++ b/include/linux/netfilter_ipv6/ip6t_TCPMSS.h
@@ -0,0 +1,10 @@
+#ifndef _IP6T_TCPMSS_H
+#define _IP6T_TCPMSS_H
+
+struct ip6t_tcpmss_info {
+   u_int16_t mss;
+};
+
+#define IP6T_TCPMSS_CLAMP_PMTU 0x
+
+#endif /*_IP6T_TCPMSS_H*/
diff --git a/net/ipv6/netfilter/Kconfig b/net/ipv6/netfilter/Kconfig
index adcd613..3890a59 100644
--- a/net/ipv6/netfilter/Kconfig
+++ b/net/ipv6/netfilter/Kconfig
@@ -154,6 +154,32 @@ config IP6_NF_TARGET_REJECT
 
  To compile it as a module, choose M here.  If unsure, say N.
 
+config IP6_NF_TARGET_TCPMSS
+   tristate "TCPMSS target support"
+   depends on IP6_NF_IPTABLES
+   ---help---
+ This option adds a `TCPMSS' target, which allows you to alter the
+ MSS value of TCP SYN packets, to control the maximum size for that
+ connection (usually limiting it to your outgoing interface's MTU
+ minus 60).
+
+ This is used to overcome criminally braindead ISPs or servers which
+ block ICMPv6 Packet Too Big packets.  The symptoms of this
+ problem are that everything works fine from your Linux
+ firewall/router, but machines behind it can never exchange large
+ packets:
+   1) Web browsers connect, then hang with no data received.
+   2) Small mail works fine, but large emails hang.
+   3) ssh works fine, but scp hangs after initial handshaking.
+
+ Workaround: activate this option and add a rule to your firewall
+ configuration like:
+
+ ip6tables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
+-j TCPMSS --clamp-mss-to-pmtu
+
+ To compile it as a module, choose M here.  If unsure, say N.
+
 config IP6_NF_MANGLE
tristate "Packet mangling"
depends on IP6_NF_IPTABLES
diff --git a/net/ipv6/netfilter/Makefile b/net/ipv6/netfilter/Makefile
index ac1dfeb..616a006 100644
--- a/net/ipv6/netfilter/Makefile
+++ b/net/ipv6/netfilter/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_IP6_NF_TARGET_LOG) += ip6t_LOG.o
 obj-$(CONFIG_IP6_NF_RAW) += ip6table_raw.o
 obj-$(CONFIG_IP6_NF_MATCH_HL) += ip6t_hl.o
 obj-$(CONFIG_IP6_NF_TARGET_REJECT) += ip6t_REJECT.o
+obj-$(CONFIG_IP6_NF_TARGET_TCPMSS) += ip6t_TCPMSS.o
 
 # objects for l3 independent conntrack
 nf_conntrack_ipv6-objs  :=  nf_conntrack_l3proto_ipv6.o 
nf_conntrack_proto_icmpv6.o nf_conntrack_reasm.o
diff --git a/net/ipv6/netfilter/ip6t_TCPMSS.c b/net/ipv6/netfilter/ip6t_TCPMSS.c
new file mode 100644
index 000..ab492c3
--- /dev/null
+++ b/net/ipv6/netfilter/ip6t_TCPMSS.c
@@ -0,0 +1,225 @@
+/*
+ * This is a module which is used for setting the MSS option in TCP packets.
+ *
+ * Copyright (C) 2007 David Madore <[EMAIL PROTECTED]>
+ *
+ * Shamelessly based on net/ipv4/netfilter/ipt_TCPMSS.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("David Madore <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("ip6tables TCP MSS modification module");
+
+static inline unsigned int
+optlen(const u_int8_t *opt, unsigned int offset)
+{
+   /* Beware zero-length options: make finite progress */
+   if (opt[offset] <= TCPOPT_NOP || opt[offset+1] == 0)
+   return 1;
+   else
+   return opt[offset+1];
+}
+
+static unsigned int
+ip6t_tcpmss_target(struct sk_buff **pskb,
+  const struct net_device *in,
+  const struct net_device *out,
+  unsigned int hooknum,
+  const struct xt_target *target,
+  const void *targinfo)
+{
+   const struct ip6t_tcpmss_info *tcpmssinfo = targinfo;
+   struct tcphdr *tcph;
+   struct ipv6hdr *ipv6h;
+   u_int8_t nexthdr;
+   int tcphoff;
+   u_int16_t tcplen, newmss;
+   __be16 newiplen, oldval;
+   unsigned int i;
+   u_int8_t *opt;
+
+   if (!skb_make_writable(pskb, (*pskb)->len))
+   return NF_DROP;
+
+   ipv6h = 

Re: allocation failed: out of vmalloc space error treating and VIDEO1394 IOC LISTEN CHANNEL ioctl failed problem

[Arjan van de Ven]

On Sun, 2007-01-14 at 20:19 +0100, Stefan Richter wrote:
> On 10 Jan, Peter Antoniac wrote:
> [...]
> > Problem is: how to get the VMALLOC_RESERVED value for the kernel that is 
> > running? I couldn't find any standard way to do that (something to apply to 
> > GNU Linux and the like). All the things I could get were the default value 
> > being 128MiB :) and that is it. Now, I could just put 128, but what if 
> > somebody changes that, or in some new distro suddenly decides to make it 
> > different? Even worse, what if it is an old kernel with 64 setting?
> [...]
> 
> Maybe somebody at LKML has answers?

vmalloc space is limited; you really can't assume you can get any more
than 64Mb or so (and even then it's thight on some systems already); it
really sounds like vmalloc space isn't the right solution for your
problem whatever it is (context is lost in the quoted mail)...
can you restate the problem to see if there's a better solution
possible?

Greetings,
   Arjan van de Ven
-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] 2.6.20-rc4: usb somehow broken

[Alan Stern]

On Sun, 14 Jan 2007, Prakash Punnoor wrote:

> Am Sonntag 14 Januar 2007 10:28 schrieb Oliver Neukum:
> > Am Sonntag, 14. Januar 2007 10:08 schrieb Prakash Punnoor:
> > > Am Donnerstag 11 Januar 2007 18:28 schrieb Oliver Neukum:
> > > > Am Donnerstag, 11. Januar 2007 18:20 schrieb Prakash Punnoor:
> > > > > Hi,
> > > > >
> > > > > I can't scan anymore. :-( I don't know which rc kernel introduced it,
> > > > > but this are the messages I get (w/o touching the device/usb cable
> > > > > except pluggin it in for the first time):
> > > > >
> > > > > usb 1-1.2: new full speed USB device using ehci_hcd and address 4
> > > > > ehci_hcd :00:0b.1: qh 81007bc6c280 (#00) state 4
> > > > > usb 1-1.2: configuration #1 chosen from 1 choice
> > > > > usb 1-1.2: USB disconnect, address 4
> > > > > usb 1-1.2: new full speed USB device using ehci_hcd and address 5
> > > > > usb 1-1.2: configuration #1 chosen from 1 choice
> > > > > usb 1-1.2: USB disconnect, address 5
> > > > > usb 1-1.2: new full speed USB device using ehci_hcd and address 6
> > > > > usb 1-1.2: configuration #1 chosen from 1 choice
> > > > > usb 1-1.2: USB disconnect, address 6
> > > > > usb 1-1.2: new full speed USB device using ehci_hcd and address 7
> > > > > usb 1-1.2: configuration #1 chosen from 1 choice
> > > > > usb 1-1.2: USB disconnect, address 7
> > > > > usb 1-1.2: new full speed USB device using ehci_hcd and address 8
> > > > > usb 1-1.2: configuration #1 chosen from 1 choice
> >
> > [..]
> >
> > > Hi, I did more tests and I was wrong about "broken". It seems more a
> > > time-out problem, ie if I try to use sane again in short intervalls, I
> > > will get my device working. The cause seems CONFIG_USB_SUSPEND=y. With
> > > 2.6.20-rc5 the
> >
> > Have you confirmed that by using a kernel without  CONFIG_USB_SUSPEND ?
> 
> Yes. I compiled the modules with various settings, reloaded the modules and 
> above option made the difference. I also don't get the disconnect mesages, as 
> well, w/o USB_SUSPEND.

Judging from the log, it looks like the scanner cannot handle being
suspended.  (BTW this is in violation of the USB specification -- all
devices must be able to suspend and resume.)

When the scanner is not in use, the system automatically suspends it after 
two seconds.  When you use sane the scanner is resumed, but it then 
disconnects itself and reconnects.  Sane is left trying to control the
disconnected device instance, so of course it fails.

I'm beginning to think that we need some way to deal with devices that 
cannot recover from a suspend.  Several examples have cropped up.  
Unfortunately, I can't think of anything better than a blacklist, which is 
not very satisfactory.

Can anyone suggest another approach?

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: allocation failed: out of vmalloc space error treating and VIDEO1394 IOC LISTEN CHANNEL ioctl failed problem

[Stefan Richter]

On 10 Jan, Peter Antoniac wrote:
[...]
> Problem is: how to get the VMALLOC_RESERVED value for the kernel that is 
> running? I couldn't find any standard way to do that (something to apply to 
> GNU Linux and the like). All the things I could get were the default value 
> being 128MiB :) and that is it. Now, I could just put 128, but what if 
> somebody changes that, or in some new distro suddenly decides to make it 
> different? Even worse, what if it is an old kernel with 64 setting?
[...]

Maybe somebody at LKML has answers?
-- 
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/

[2.6.20-rc5]KVM - Win98SE won't install

[Bill Davidsen]

Hardware list attached, and config. When scanning disk at the start of 
the install, exits with "signal 13 (0)" and no log entry. Just as the 
kvm dies there's a switch from the blue install screen to a white on 
black screen, and a message displays for a fraction of a sec, unreadably 
fast.


I dount it's hardware, memtest was recently run 12hr, and installs of 
DragonFlyBSD and FreeBSD work.


I have two patches applied, diff also attached.

Running qemu user mode works, running xen-install does exactly the sdame 
thing. Obviously I would rather run kvm.


Any other info needed, or things to try, let me know. I did run with -d, 
nothing written in qemu.log.


--
Bill Davidsen
  He was a full-time professional cat, not some moonlighting
ferret or weasel. He knew about these things.
Linux version 2.6.20-rc5 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red 
Hat 4.1.1-51)) #3 SMP Sun Jan 14 11:33:19 EST 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start:  size: 0009fc00 end: 
0009fc00 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 0009fc00 size: 0400 end: 
000a type: 2
copy_e820_map() start: 000e4000 size: 0001c000 end: 
0010 type: 2
copy_e820_map() start: 0010 size: 7f6a end: 
7f7a type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 7f7a size: e000 end: 
7f7ae000 type: 3
copy_e820_map() start: 7f7ae000 size: 00032000 end: 
7f7e type: 4
copy_e820_map() start: 7f7e size: 0002 end: 
7f80 type: 2
copy_e820_map() start: ffb8 size: 0048 end: 
0001 type: 2
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e4000 - 0010 (reserved)
 BIOS-e820: 0010 - 7f7a (usable)
 BIOS-e820: 7f7a - 7f7ae000 (ACPI data)
 BIOS-e820: 7f7ae000 - 7f7e (ACPI NVS)
 BIOS-e820: 7f7e - 7f80 (reserved)
 BIOS-e820: ffb8 - 0001 (reserved)
1143MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000ff780
Entering add_active_range(0, 0, 522144) 0 entries of 256 used
Zone PFN ranges:
  DMA 0 -> 4096
  Normal   4096 ->   229376
  HighMem229376 ->   522144
early_node_map[1] active PFN ranges
0:0 ->   522144
On node 0 totalpages: 522144
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 1760 pages used for memmap
  Normal zone: 223520 pages, LIFO batch:31
  HighMem zone: 2287 pages used for memmap
  HighMem zone: 290481 pages, LIFO batch:31
DMI 2.4 present.
ACPI: RSDP (v002 ACPIAM) @ 0x000fa5d0
ACPI: XSDT (v001 A M I  OEMXSDT  0x1627 MSFT 0x0097) @ 0x7f7a0100
ACPI: FADT (v003 A M I  OEMFACP  0x1627 MSFT 0x0097) @ 0x7f7a0290
ACPI: MADT (v001 A M I  OEMAPIC  0x1627 MSFT 0x0097) @ 0x7f7a0390
ACPI: OEMB (v001 A M I  AMI_OEM  0x1627 MSFT 0x0097) @ 0x7f7ae040
ACPI: MCFG (v001 A M I  OEMMCFG  0x1627 MSFT 0x0097) @ 0x7f7a4f00
ACPI: DSDT (v001  A0281 A0281074 0x0074 INTL 0x02002026) @ 0x
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:15 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 6:15 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 8000 (gap: 7f80:8038)
Detected 2394.060 MHz processor.
Built 1 zonelists.  Total pages: 518065
Kernel command line: ro root=/dev/VG01/Root32 rhgb quiet
mapped APIC to d000 (fee0)
mapped IOAPIC to c000 (fec0)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2061272k/2088576k available (4101k kernel code, 26112k reserved, 1851k 
data, 324k 

Re: ahci_softreset prevents acpi_power_off

[Faik Uygur]

14 Oca 2007 Paz 20:06 tarihinde, Arjan van de Ven şunları yazmıştı: 
> Hi,

Hi,

> I'd be interested in finding out how to best test this; if the bios is
> really broken I'd love to add a test to the Linux-ready Firmware
> Developer Kit for this, so that BIOS developers can make sure future
> bioses do not suffer from this bug...

I would be glad to help finding out for this.

> Greetings,
>Arjan van de Ven

Regards,
- Faik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: O_DIRECT question

[Bodo Eggert]

On Sat, 13 Jan 2007, Bill Davidsen wrote:

> Bodo Eggert wrote:
> 
> > (*) This would allow fadvise_size(), too, which could reduce fragmentation
> > (and give an early warning on full disks) without forcing e.g. fat to
> > zero all blocks. OTOH, fadvise_size() would allow users to reserve the
> > complete disk space without his filesizes reflecting this.
> 
> Please clarify how this would interact with quota, and why it wouldn't 
> allow someone to run me out of disk.

I fell into the "write-will-never-fail"-pit. Therefore I have to talk 
about the original purpose, write with O_DIRECT, too.

- Reserved blocks should be taken out of the quota, since they are about
  to be written right now. If you emptied your quota doing this, it's
  your fault. It it was the group's quota, just run fast enough.-)

- If one write failed that extended the reserved range, the reserved area 
  should be shrunk again. Obviously you'll need something clever here.
  * You can't shrink carelessly while there are O_DIRECT writes.
  * You can't just try to grab the semaphore[0] for writing, this will 
deadlock with other write()s.
  * If you drop the read lock, it will work out, because you aren't
writing anymore, and if you get the write lock, there won't be anybody 
else writing. Therefore you can clear the reservation for the not-
written blocks. You may unreserve blocks that should stay reserved,
but that won't harm much. At worst, you'll get fragmentation, loss
of speed and an aborted (because of no free space) write command.
Document this, it's a feature.-)

- If you fadvise_size on a non-quota-disk, you can possibly reserve it 
  completely, without being the easy-to-spot offender. You can do the
  same by actually writing these files, keeping them open and unlinking 
  them. The new quality is: You can't just look at the file sizes in
  /proc in order to spot the offender. However, if you reflect the 
  reserved blocks in the used-blocks-field of struct stat, du will
  work as expected and the BOFH will know whom to LART.

  BTW: If the fs supports holes, using du would be the right thing
  to do anyway.


BTW2: I don't know if reserving without actually assigning blocks is 
supported or easy to support at all. These reservations are the result of 
"These blocks are not yet written, therefore they contain possibly secret 
data that would leak on failed writes, therefore they may not be actually 
assigned to the file before write finishes. They may not be on the free 
list either. And hey, if we support pre-reserving blocks to the file, we 
may additionally use it for fadvise_size. I'll mention that briefly."




[0] r/w semaphore, read={r,w}_odirect, write=ftruncate

-- 
Fun things to slip into your budget
Paradigm pro-activator (a whole pack)
(you mean beer?)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Shrink the held_lock struct by using bitfields.

[Ingo Molnar]

On Tue, 2007-01-02 at 18:38 -0500, Dave Jones wrote:
> +   unsigned char irq_context:1;
> +   unsigned char trylock:1;
> +   unsigned char read:2;
> +   unsigned char check:1;
> +   unsigned char hardirqs_off:1; 

cool! I totally missed those. I'd even do this for 2.6.20, but it's
probably too late for that.

Acked-by: Ingo Molnar <[EMAIL PROTECTED]>

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ahci_softreset prevents acpi_power_off

[Arjan van de Ven]

On Sun, 2007-01-14 at 19:59 +0200, Faik Uygur wrote:
> 14 Oca 2007 Paz 03:23 tarihinde, Robert Hancock şunları yazmıştı: 
> >> [...]
> >> > Since you're getting to this point I think this has to be some kind of 
> > BIOS interaction causing this. The only thing that happens after the
> > "Entering sleep state" is that the kernel writes to some ACPI registers
> > to tell the hardware to power down. I think some laptop BIOSes do things
> > on ACPI power down like try to park the drive heads, etc. and maybe this
> > change that you found from git bisecting is somehow interfering with it
> > doing this?
> >
> > Might want to check for a BIOS update first of all..
> 
> Checked from the Sony support page for the laptop model and seems the BIOS 
> version is the latest.
> 
> So it is nothing interesting but a broken BIOS.

Hi,

I'd be interested in finding out how to best test this; if the bios is
really broken I'd love to add a test to the Linux-ready Firmware
Developer Kit for this, so that BIOS developers can make sure future
bioses do not suffer from this bug...

Greetings,
   Arjan van de Ven

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: ahci_softreset prevents acpi_power_off

[Faik Uygur]

14 Oca 2007 Paz 03:23 tarihinde, Robert Hancock şunları yazmıştı: 
>> [...]
>> > Since you're getting to this point I think this has to be some kind of 
> BIOS interaction causing this. The only thing that happens after the
> "Entering sleep state" is that the kernel writes to some ACPI registers
> to tell the hardware to power down. I think some laptop BIOSes do things
> on ACPI power down like try to park the drive heads, etc. and maybe this
> change that you found from git bisecting is somehow interfering with it
> doing this?
>
> Might want to check for a BIOS update first of all..

Checked from the Sony support page for the laptop model and seems the BIOS 
version is the latest.

So it is nothing interesting but a broken BIOS.

Regards,
- Faik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: ahci_softreset prevents acpi_power_off

[Faik Uygur]

14 Oca 2007 Paz 05:18 tarihinde şunları yazmıştınız:
>> [...]
> > Since you're getting to this point I think this has to be some kind of
> > BIOS interaction causing this. The only thing that happens after the
> > "Entering sleep state" is that the kernel writes to some ACPI registers
> > to tell the hardware to power down. I think some laptop BIOSes do things
> > on ACPI power down like try to park the drive heads, etc. and maybe this
> > change that you found from git bisecting is somehow interfering with it
> > doing this?
> >
> > Might want to check for a BIOS update first of all..
>
> It would be interesting to try -mm, which includes ACPI support for ATA...

With the same .config used and with CONFIG_SATA_ACPI defined as default
in 2.6.20-rc4-mm1 the machine did not poweroff again.

>   Jeff

Regards,
- Faik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc5] intel_rng: substitue magic PCI IDs with macros

[Arjan van de Ven]

On Sun, 2007-01-14 at 19:24 +0200, Ahmed S. Darwish wrote:
> Substitue intel_rng magic PCI IDs values used in the IDs table
> with the macros defined in pci_ids.h
> 
Hi,


hmm this is actually the opposite direction than most of the kernel is
heading in, mostly because the pci_ids.h file is a major maintenance
pain.

Afaik the current "rule" is: if a PCI ID is only used in one driver, use
the numeric value and not (add) a symbolic constant.


Greetings,
   Arjan van de Ven

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.20-rc5] intel_rng: substitue magic PCI IDs with macros

[Ahmed S. Darwish]

Substitue intel_rng magic PCI IDs values used in the IDs table
with the macros defined in pci_ids.h


Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---

I've used a small script to generate this patch then manually tried to 
make sure it's (hopefully) correct. 

#!/bin/bash

INTEL_RNG_FILE=drivers/char/hw_random/intel-rng.c
TMP_FILE=$(mktemp)
MAGIC_NUMS_FILE=$(mktemp)

# grep the contents of "pci_device_id pci_tbl[]"
grep "{ 0x8086"  drivers/char/hw_random/intel-rng.c > $TMP_FILE
# Extract the magic numbers to be replaced
cat $TMP_FILE | awk ' { print $3 } ' | cut -d, -f1 | grep "0x" > 
$MAGIC_NUMS_FILE

sed -i "s/0x8086/PCI_VENDOR_ID_INTEL/g" $INTEL_RNG_FILE

# For each magic number in MAGIC_NUMS_FILE, find its defined macro 
# in pci_ids.h then replace them.

for i in $(cat $MAGIC_NUMS_FILE); do 
var=$(grep "PCI_DEVICE_ID" include/linux/pci_ids.h | grep "$i" | awk ' { 
print $2 } ')
if [[ -n "$var" ]] ; then
# sed: Side effect of replacing the magic number in the whole file
# Collisions with other magics belonging to another family ?
# Manual checking reveals no bad collisions happen.
sed -i "s/${i}/${var}/g" $INTEL_RNG_FILE
fi
done

rm -f $TMP_FILE
rm -f $MAGIC_NUMS_FILE

diff --git a/drivers/char/hw_random/intel-rng.c 
b/drivers/char/hw_random/intel-rng.c
index f22e78e..85b0374 100644
--- a/drivers/char/hw_random/intel-rng.c
+++ b/drivers/char/hw_random/intel-rng.c
@@ -95,50 +95,96 @@
  * want to register another driver on the same PCI id.
  */
 static const struct pci_device_id pci_tbl[] = {
-/* AA
-   { 0x8086, 0x2418, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, */
-   { 0x8086, 0x2410, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* AA */
-/* AB
-   { 0x8086, 0x2428, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, */
-   { 0x8086, 0x2420, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* AB */
-/* ??
-   { 0x8086, 0x2430, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, */
-/* BAM, CAM, DBM, FBM, GxM
-   { 0x8086, 0x2448, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, */
-   { 0x8086, 0x244c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* BAM */
-   { 0x8086, 0x248c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* CAM */
-   { 0x8086, 0x24cc, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* DBM */
-   { 0x8086, 0x2641, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* FBM */
-   { 0x8086, 0x27b9, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* GxM */
-   { 0x8086, 0x27bd, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* GxM DH */
-/* BA, CA, DB, Ex, 6300, Fx, 631x/632x, Gx
-   { 0x8086, 0x244e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, */
-   { 0x8086, 0x2440, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* BA */
-   { 0x8086, 0x2480, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* CA */
-   { 0x8086, 0x24c0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* DB */
-   { 0x8086, 0x24d0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* Ex */
-   { 0x8086, 0x25a1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 6300 */
-   { 0x8086, 0x2640, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* Fx */
-   { 0x8086, 0x2670, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x2671, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x2672, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x2673, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x2674, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x2675, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x2676, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x2677, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x2678, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x2679, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x267a, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x267b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x267c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x267d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x267e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x267f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */
-   { 0x8086, 0x27b8, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* Gx */
-/* E
-   { 0x8086, 0x245e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, */
-   { 0x8086, 0x2450, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* E  */
+/* 
+ * AA
+ * { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AA_8, PCI_ANY_ID, 
+ * PCI_ANY_ID, 0, 0, 0, }, 
+ */
+   { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AA_0, PCI_ANY_ID,
+ PCI_ANY_ID, 0, 0, 0, },
+/* 
+ * AB
+ * { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AB_8, PCI_ANY_ID, 
+ * PCI_ANY_ID, 0, 0, 0, }, 
+ */
+   { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AB_0, PCI_ANY_ID, 
+ PCI_ANY_ID, 0, 0, 0, },
+/* 
+ * ??
+ * { PCI_VENDOR_ID_INTEL, 0x2430, PCI_ANY_ID, PCI_ANY_ID, 

Re: [patch] disable NMI watchdog by default

[Arjan van de Ven]

> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>

Fully agree!
NMI watchdog is high risk in terms of interacting with firmware and
other things (and the code is sort of broken anyway)

Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: licence for LGPLed files

[Arjan van de Ven]

On Sun, 2007-01-14 at 14:32 +0100, Jan Engelhardt wrote:
> >There are various files (in my copy of the Ubuntu 2.6.15 source) which
> >have an LGPL licence, but there isn't a copy of the licence in the
> >distribution as there should be.  Changing them to GPL seems the best
> >thing to do.
> 
> Changing them to GPL seems the hardest and most instrusive thing to do.

well technically they don't need to be changed at all because they ARE
gpl as long as they're part of the kernel effectively (LGPL has that
"conversion to GPL" clause) ; only when used outside they are actually
lgpl

also most of the files in question are header files where LGPL actually
makes sense when those same headers are used in userspace...

so how about not changing anything since there is no  need to change..



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][REVISED] Remove all traces of "raw device" support.

[Robert P. J. Day]

  Remove all traces of raw devices support, which were officially
obsolete since 2.6.3.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

  crap.  the "allyesconfig" build worked, except when it came to
installing the sanitized headers, whose include/linux/Kbuild file
still had a reference to the "raw.h" header file.

  sorry.  my bad.

 Documentation/feature-removal-schedule.txt |8
 Documentation/ioctl-number.txt |1
 drivers/char/Kconfig   |   21 -
 drivers/char/Makefile  |1
 drivers/char/mem.c |1
 drivers/char/raw.c |  306 ---
 fs/compat_ioctl.c  |   71 
 include/linux/Kbuild   |1
 include/linux/compat_ioctl.h   |3
 include/linux/raw.h|   18 -
 10 files changed, 431 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index fc53239..020b760 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -21,14 +21,6 @@ Who: Pavel Machek <[EMAIL PROTECTED]>

 ---

-What:  RAW driver (CONFIG_RAW_DRIVER)
-When:  December 2005
-Why:   declared obsolete since kernel 2.6.3
-   O_DIRECT can be used instead
-Who:   Adrian Bunk <[EMAIL PROTECTED]>
-

-
 What:  raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
 When:  June 2007
 Why:   Deprecated in favour of the more efficient and robust rawiso interface.
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
index 5a8bd5b..4ffd365 100644
--- a/Documentation/ioctl-number.txt
+++ b/Documentation/ioctl-number.txt
@@ -179,7 +179,6 @@ CodeSeq#Include FileComments

 0xA3   90-9F   linux/dtlk.h
 0xAB   00-1F   linux/nbd.h
-0xAC   00-1F   linux/raw.h
 0xAD   00  Netfilter devicein development:

 0xB0   all RATIO devices   in development:
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 9e43e39..eaf021e 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -948,27 +948,6 @@ config GPIO_VR41XX
tristate "NEC VR4100 series General-purpose I/O Unit support"
depends on CPU_VR41XX

-config RAW_DRIVER
-   tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)"
-   depends on BLOCK
-   help
- The raw driver permits block devices to be bound to /dev/raw/rawN.
- Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
- See the raw(8) manpage for more details.
-
-  The raw driver is deprecated and will be removed soon.
-  Applications should simply open the device (eg /dev/hda1)
-  with the O_DIRECT flag.
-
-config MAX_RAW_DEVS
-   int "Maximum number of RAW devices to support (1-8192)"
-   depends on RAW_DRIVER
-   default "256"
-   help
- The maximum number of RAW devices that are supported.
- Default is 256. Increase this number in case you need lots of
- raw devices.
-
 config HPET
bool "HPET - High Precision Event Timer" if (X86 || IA64)
default n
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index fc11063..21d0873 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -46,7 +46,6 @@ obj-$(CONFIG_HVC_CONSOLE) += hvc_vio.o hvsi.o
 obj-$(CONFIG_HVC_ISERIES)  += hvc_iseries.o
 obj-$(CONFIG_HVC_RTAS) += hvc_rtas.o
 obj-$(CONFIG_HVC_DRIVER)   += hvc_console.o
-obj-$(CONFIG_RAW_DRIVER)   += raw.o
 obj-$(CONFIG_SGI_SNSC) += snsc.o snsc_event.o
 obj-$(CONFIG_MSPEC)+= mspec.o
 obj-$(CONFIG_MMTIMER)  += mmtimer.o
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 4f1813e..32a826b 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/char/raw.c b/drivers/char/raw.c
deleted file mode 100644
index 645e20a..000
--- a/drivers/char/raw.c
+++ /dev/null
@@ -1,306 +0,0 @@
-/*
- * linux/drivers/char/raw.c
- *
- * Front-end raw character devices.  These can be bound to any block
- * devices to provide genuine Unix raw character device semantics.
- *
- * We reserve minor number 0 for a control interface.  ioctl()s on this
- * device are used to bind the other minor numbers to block devices.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-struct raw_device_data {
-   struct block_device *binding;
-   int inuse;
-};
-
-static struct class *raw_class;
-static struct raw_device_data raw_devices[MAX_RAW_MINORS];
-static 

Re: Choosing a HyperThreading/SMP/MultiCore kernel ?

[Bill Davidsen]

[EMAIL PROTECTED] wrote:

On Sat, 13 Jan 2007 15:18:31 EST, Bill Davidsen said:

[EMAIL PROTECTED] wrote:

On Fri, 12 Jan 2007 10:03:49 EST, Lennart Sorensen said:

I would expect any distribution should work on these (as long as the
kernel they use isn't too old.).  Of course if it is a Mac, you need a
distribution that supports their firmware (which is of course not a PC
bios).  As long as you can boot it, any i386 or amd64 kernel with smp
enabled should use all the processors present (well amd64 on the
core2duo and on the p4 if it is em64t enabled).

amd64 will only work on a core2duo if it's a T7200 or higher - the
lower numbers are 32-bit-only chipsets.  I admit not knowing what
exact variant the Mac has.
I don't believe that's correct, the Intel features page indicates all 
core2 have both 64bit and virtualization. Perhaps some of the core (no 
2) models didn't? Even the old 930 had those features by my notes.


My screwup - the chart I looked at managed to get the Core and Core2 series
mixed up. Here's a hopefully more canonical one:

http://www.intel.com/products/processor_number/proc_info_table.pdf

Does however list some Core2 that don't do virtualization (page 3, the
T5600 and T5500), which is what I think confused the author of the table
that I misread. ;)


I missed those in terms of virtualization, but it seems that all core2 
support "intel 64" which I assume means emt64t, and what I thought 
Valdis meant by "the lower numbers are 32-bit-only chipsets." They all 
do seem to have 64bit, and should run 64bit Linux just fine.

--
bill davidsen <[EMAIL PROTECTED]>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [RFC] remove ext3 inode from orphan list when link and unlink race

[Eric Sandeen]

Dmitriy Monakhov wrote:

Eric Sandeen <[EMAIL PROTECTED]> writes:


I've been looking at a case where many threads are opening, unlinking, and
hardlinking files on ext3 .
How many concurent threads do you use and how long does it takes to trigger 
this race? I've tried to reproduce this with two threads, but not succeed.
  
fd = create("src")

close(fd)
unlink("src")

link("src", "dst")
unlink("dst")

Original testcase will be the best answer :).


Sure :)  Though I didn't write it... see this collection of bash scripts:

http://people.redhat.com/esandeen/testcases/orphan-repro.tar.bz2

I didn't write it, but it exposed the bug for me.  The VAR file contains 
variables to specify mountpoint and a device, which the script starts by 
mkfs'ing, so be warned.


It spawns -many- threads, and on my 4 CPU opteron I can hit it in a 
reasonable amount of time.  It would probably be nice to have a more 
targeted testcase but it did the trick for me.


Thanks,
-Eric


Thanks.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: O_DIRECT question

[Bill Davidsen]

Michael Tokarev wrote:

Bill Davidsen wrote:



If I got it right (and please someone tell me if I *really* got it right!),
the problem is elsewhere.

Suppose you have a filesystem, not at all related to databases and stuff.
Your usual root filesystem, with your /etc/ /var and so on directories.

Some time ago you edited /etc/shadow, updating it by writing new file and
renaming it to proper place.  So you have that old content of your shadow
file (now deleted) somewhere on the disk, but not accessible from the
filesystem.

Now, a bad guy deliberately tries to open some file on this filesystem, using
O_DIRECT flag, ftruncates() it to some huge size (or does seek+write), and
at the same time tries to use O_DIRECT read of the data.


Which should be identified and zeros returned. Consider: I open a file 
for database use, and legitimately seek to a location out at, say, 
250MB, and then write at the location my hash says I should. That's all 
legitimate. Now when some backup program accesses the file sequentially, 
it gets a boatload of zeros, because Linux "knows" that is sparse data. 
Yes, the backup program should detect this as well, so what?


My point is, that there is code to handle sparse data now, without 
O_DIRECT involved, and if O_DIRECT bypasses that, it's not a problem 
with the idea of O_DIRECT, the kernel has a security problem.


Due to all the races etc, it is possible for him to read that old content of
/etc/shadow file you've deleted before.


I do have one thought, WRT reading uninitialized disk data. I would hope
that sparse files are handled right, and that when doing a write with
O_DIRECT the metadata is not updated until the write is done.


"hope that sparse files are handled right" is a high hope.  Exactly because
this very place IS racy.


Other than assuring that a program can't read where no program has 
written, I don't see a problem. Anyone accessing the same file with 
multiple processes had better be doing user space coordination, and gets 
no sympathy from me if they don't. In this case, "works right" does not 
mean "works as expected," because the program has no right to assume the 
kernel will sort out poor implementations.


Without O_DIRECT the problem of doing ordered i/o in user space becomes 
very difficult, if not impossible, so "get rid of O_DIRECT" is the wrong 
direction. When the program can be sure the i/o is done, then cleverness 
in user space can see that it's done RIGHT.


--
bill davidsen <[EMAIL PROTECTED]>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [-mm patch] remove quirk_sis_96x_compatible()

[Mark M. Hoffman]

Hi Adrian:

> On Sun, Jan 07, 2007 at 10:40:49AM -0500, Mark M. Hoffman wrote:
> > It's just cruft from the original quirk.  The "compatible" printk could have
> > had value as a diagnostic in case the new quirk didn't work for some reason,
> > but I never saw any complaints about it (apart from the link order problem,
> > which is something different.)  It's safe to remove by now.

* Adrian Bunk <[EMAIL PROTECTED]> [2007-01-14 14:46:32 +0100]:
> Below is a patch to remove it.
> 
> Since 2.6.0-test10, all quirk_sis_96x_compatible() had any effect on
> was a printk().
> 
> This patch therefore removes it.
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

Acked-by: Mark M. Hoffman <[EMAIL PROTECTED]>

> ---
> 
>  drivers/pci/quirks.c |   15 ---
>  1 file changed, 15 deletions(-)
> 
> --- linux-2.6.20-rc4-mm1/drivers/pci/quirks.c.old 2007-01-14 
> 09:58:01.0 +0100
> +++ linux-2.6.20-rc4-mm1/drivers/pci/quirks.c 2007-01-14 09:58:37.0 
> +0100
> @@ -1141,8 +1141,6 @@
>   *
>   * We can also enable the sis96x bit in the discovery register..
>   */
> -static int __devinitdata sis_96x_compatible = 0;
> -
>  #define SIS_DETECT_REGISTER 0x40
>  
>  static void quirk_sis_503(struct pci_dev *dev)
> @@ -1158,9 +1156,6 @@
>   return;
>   }
>  
> - /* Make people aware that we changed the config.. */
> - printk(KERN_WARNING "Uncovering SIS%x that hid as a SIS503 
> (compatible=%d)\n", devid, sis_96x_compatible);
> -
>   /*
>* Ok, it now shows up as a 96x.. run the 96x quirk by
>* hand in case it has already been processed.
> @@ -1172,16 +1167,6 @@
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI,   PCI_DEVICE_ID_SI_503,   
> quirk_sis_503 );
>  DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_SI,   PCI_DEVICE_ID_SI_503,   
> quirk_sis_503 );
>  
> -static void __init quirk_sis_96x_compatible(struct pci_dev *dev)
> -{
> - sis_96x_compatible = 1;
> -}
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI,   PCI_DEVICE_ID_SI_645,   
> quirk_sis_96x_compatible );
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI,   PCI_DEVICE_ID_SI_646,   
> quirk_sis_96x_compatible );
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI,   PCI_DEVICE_ID_SI_648,   
> quirk_sis_96x_compatible );
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI,   PCI_DEVICE_ID_SI_650,   
> quirk_sis_96x_compatible );
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI,   PCI_DEVICE_ID_SI_651,   
> quirk_sis_96x_compatible );
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI,   PCI_DEVICE_ID_SI_735,   
> quirk_sis_96x_compatible );
>  
>  /*
>   * On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller

-- 
Mark M. Hoffman
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Remove "raw devices" support.

[Robert P. J. Day]

  Remove all traces of "raw devices" support.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

  since this feature is listed as being obsolete since 2.6.3 and was
scheduled for removal back in Dec of 2005, I figure there wasn't much
harm in getting rid of it.

  i'm trying a "make allyesconfig" build as we speak -- so far, it's
moving along nicely.


 Documentation/feature-removal-schedule.txt |8
 Documentation/ioctl-number.txt |1
 drivers/char/Kconfig   |   21 -
 drivers/char/Makefile  |1
 drivers/char/mem.c |1
 drivers/char/raw.c |  306 ---
 fs/compat_ioctl.c  |   71 
 include/linux/compat_ioctl.h   |3
 include/linux/raw.h|   18 -
 9 files changed, 430 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index fc53239..020b760 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -21,14 +21,6 @@ Who: Pavel Machek <[EMAIL PROTECTED]>

 ---

-What:  RAW driver (CONFIG_RAW_DRIVER)
-When:  December 2005
-Why:   declared obsolete since kernel 2.6.3
-   O_DIRECT can be used instead
-Who:   Adrian Bunk <[EMAIL PROTECTED]>
-

-
 What:  raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
 When:  June 2007
 Why:   Deprecated in favour of the more efficient and robust rawiso interface.
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
index 5a8bd5b..4ffd365 100644
--- a/Documentation/ioctl-number.txt
+++ b/Documentation/ioctl-number.txt
@@ -179,7 +179,6 @@ CodeSeq#Include FileComments

 0xA3   90-9F   linux/dtlk.h
 0xAB   00-1F   linux/nbd.h
-0xAC   00-1F   linux/raw.h
 0xAD   00  Netfilter devicein development:

 0xB0   all RATIO devices   in development:
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 9e43e39..eaf021e 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -948,27 +948,6 @@ config GPIO_VR41XX
tristate "NEC VR4100 series General-purpose I/O Unit support"
depends on CPU_VR41XX

-config RAW_DRIVER
-   tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)"
-   depends on BLOCK
-   help
- The raw driver permits block devices to be bound to /dev/raw/rawN.
- Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
- See the raw(8) manpage for more details.
-
-  The raw driver is deprecated and will be removed soon.
-  Applications should simply open the device (eg /dev/hda1)
-  with the O_DIRECT flag.
-
-config MAX_RAW_DEVS
-   int "Maximum number of RAW devices to support (1-8192)"
-   depends on RAW_DRIVER
-   default "256"
-   help
- The maximum number of RAW devices that are supported.
- Default is 256. Increase this number in case you need lots of
- raw devices.
-
 config HPET
bool "HPET - High Precision Event Timer" if (X86 || IA64)
default n
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index fc11063..21d0873 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -46,7 +46,6 @@ obj-$(CONFIG_HVC_CONSOLE) += hvc_vio.o hvsi.o
 obj-$(CONFIG_HVC_ISERIES)  += hvc_iseries.o
 obj-$(CONFIG_HVC_RTAS) += hvc_rtas.o
 obj-$(CONFIG_HVC_DRIVER)   += hvc_console.o
-obj-$(CONFIG_RAW_DRIVER)   += raw.o
 obj-$(CONFIG_SGI_SNSC) += snsc.o snsc_event.o
 obj-$(CONFIG_MSPEC)+= mspec.o
 obj-$(CONFIG_MMTIMER)  += mmtimer.o
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 4f1813e..32a826b 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/char/raw.c b/drivers/char/raw.c
deleted file mode 100644
index 645e20a..000
--- a/drivers/char/raw.c
+++ /dev/null
@@ -1,306 +0,0 @@
-/*
- * linux/drivers/char/raw.c
- *
- * Front-end raw character devices.  These can be bound to any block
- * devices to provide genuine Unix raw character device semantics.
- *
- * We reserve minor number 0 for a control interface.  ioctl()s on this
- * device are used to bind the other minor numbers to block devices.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-struct raw_device_data {
-   struct block_device *binding;
-   int inuse;
-};
-
-static struct class *raw_class;
-static struct raw_device_data raw_devices[MAX_RAW_MINORS];
-static DEFINE_MUTEX(raw_mutex);
-static const struct 

Re: Linux 2.6.20-rc5

[Robert P. J. Day]

On Sun, 14 Jan 2007, [EMAIL PROTECTED] wrote:

> In compiling:
>   CC [M]  net/ipv4/netfilter/ipt_TTL.o
>   LD [M]  drivers/usb/storage/usb-storage.o
>   CC [M]  drivers/usb/gadget/net2280.o
>   CC [M]  net/ipv4/netfilter/arp_tables.o
> drivers/usb/gadget/net2280.c: In function 'net2280_probe':
> drivers/usb/gadget/net2280.c:2969: warning: ignoring return value of
> 'pci_set_mwi', declared with attribute warn_unused_result
> --
>   CC [M]  net/netfilter/xt_tcpmss.o
>   CC [M]  net/netfilter/xt_hashlimit.o
>   LD [M]  net/netfilter/nf_conntrack.o
>   Building modules, stage 2.
>   MODPOST 239 modules
> WARNING: "__ucmpdi2" [drivers/media/video/v4l2-common.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> If a .config is needed or any other information, I'd be happy to provide it.

is this for a powerpc?  there's a thread you might want to read:

http://uwsg.iu.edu/hypermail/linux/kernel/0612.1/2162.html

rday
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 2.6.20-rc5

[icxcnika]

In compiling:
  CC [M]  net/ipv4/netfilter/ipt_TTL.o
  LD [M]  drivers/usb/storage/usb-storage.o
  CC [M]  drivers/usb/gadget/net2280.o
  CC [M]  net/ipv4/netfilter/arp_tables.o
drivers/usb/gadget/net2280.c: In function 'net2280_probe':
drivers/usb/gadget/net2280.c:2969: warning: ignoring return value of 
'pci_set_mwi', declared with attribute warn_unused_result

--
  CC [M]  net/netfilter/xt_tcpmss.o
  CC [M]  net/netfilter/xt_hashlimit.o
  LD [M]  net/netfilter/nf_conntrack.o
  Building modules, stage 2.
  MODPOST 239 modules
WARNING: "__ucmpdi2" [drivers/media/video/v4l2-common.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

If a .config is needed or any other information, I'd be happy to provide 
it.


Please CC a reply to my email.
William Heimbigner
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] disable NMI watchdog by default

[Henrique de Moraes Holschuh]

On Sun, 14 Jan 2007, Ingo Molnar wrote:
> And with this my laptop (Lenovo T60) also stops its sporadic hard 
> hanging (sometimes in acpi_init(), sometimes later during bootup, 
> sometimes much later during actual use) as well. It hung with both 
> nmi_watchdog=1 and nmi_watchdog=2, so it's generally the fact of NMI 
> injection that is causing problems, not the NMI watchdog variant, nor 
> any particular bootup code.

I seem to recall a patch sent to lkml that removed nmi_watchdog
functionality from ThinkPads exactly because of this.  Something to do with
SMBIOS code calling int 10h under SMM, and that it would hang hard if NMIs
happened at that time.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 00/12] Fix ppc64's writing to struct file_operations

[Alan]

>   .read   = seq_read,
> + .write  = lparcfg_write,
>   .open   = lparcfg_open,
>   .release= single_release,
>  };
> @@ -581,10 +582,8 @@ int __init lparcfg_init(void)
>  
>   /* Allow writing if we have FW_FEATURE_SPLPAR */
>   if (firmware_has_feature(FW_FEATURE_SPLPAR) &&
> - !firmware_has_feature(FW_FEATURE_ISERIES)) {
> - lparcfg_fops.write = lparcfg_write;
> + !firmware_has_feature(FW_FEATURE_ISERIES))
>   mode |= S_IWUSR;
> - }


This doesn't appea to do the same thing at all. You need to select
between two sets of const inode ops instead, otherwise you turn write on
arbitarily.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc4-mm1: different values for OHCI_QUIRK_ZFMICRO

[David Brownell]

On Sunday 14 January 2007 1:10 am, Adrian Bunk wrote:
> <--  snip  -->

Waiting for Tony to submit bugfixes to his driver...


> ...
>   CC  drivers/usb/misc/ftdi-elan.o
> /home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/usb/misc/ftdi-elan.c:2307:1:
>  warning: "OHCI_QUIRK_ZFMICRO" redefined
> In file included from 
> /home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/usb/misc/ftdi-elan.c:76:
> /home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/usb/misc/../host/ohci.h:399:1:
>  warning: this is the location of the previous definition
> ...
> $ grep -r ^#define * | grep OHCI_QUIRK_ZFMICRO  
> drivers/usb/host/ohci.h:#define OHCI_QUIRK_ZFMICRO  0x20  
>  /* Compaq ZFMicro chipset*/
> drivers/usb/host/u132-hcd.c:#define OHCI_QUIRK_ZFMICRO 0x10
> drivers/usb/misc/ftdi-elan.c:#define OHCI_QUIRK_ZFMICRO 0x10
> $ 
> 
> <--  snip  -->
> 
> cu
> Adrian
> 
> -- 
> 
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/