[PATCH] Net: Remove FASTCALL macro

[Harvey Harrison]

X86_32 was the last user of the FASTCALL macro, now that it
uses regparm(3) by default, this macro expands to nothing.

Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
Should this be coordinated with the FASTCALL() removal in the
x86 git tree?

 drivers/net/ns83820.c  |5 +
 include/net/bluetooth/rfcomm.h |4 ++--
 include/net/sock.h |4 ++--
 3 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ns83820.c b/drivers/net/ns83820.c
index ea71f6d..972acc3 100644
--- a/drivers/net/ns83820.c
+++ b/drivers/net/ns83820.c
@@ -611,7 +611,7 @@ static inline int rx_refill(struct net_device *ndev, gfp_t 
gfp)
return i ? 0 : -ENOMEM;
 }
 
-static void FASTCALL(rx_refill_atomic(struct net_device *ndev));
+static void rx_refill_atomic(struct net_device *ndev));
 static void fastcall rx_refill_atomic(struct net_device *ndev)
 {
rx_refill(ndev, GFP_ATOMIC);
@@ -633,7 +633,6 @@ static inline void clear_rx_desc(struct ns83820 *dev, 
unsigned i)
build_rx_desc(dev, dev-rx_info.descs + (DESC_SIZE * i), 0, 0, 
CMDSTS_OWN, 0);
 }
 
-static void FASTCALL(phy_intr(struct net_device *ndev));
 static void fastcall phy_intr(struct net_device *ndev)
 {
struct ns83820 *dev = PRIV(ndev);
@@ -832,7 +831,6 @@ static void ns83820_cleanup_rx(struct ns83820 *dev)
}
 }
 
-static void FASTCALL(ns83820_rx_kick(struct net_device *ndev));
 static void fastcall ns83820_rx_kick(struct net_device *ndev)
 {
struct ns83820 *dev = PRIV(ndev);
@@ -854,7 +852,6 @@ static void fastcall ns83820_rx_kick(struct net_device 
*ndev)
 /* rx_irq
  *
  */
-static void FASTCALL(rx_irq(struct net_device *ndev));
 static void fastcall rx_irq(struct net_device *ndev)
 {
struct ns83820 *dev = PRIV(ndev);
diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h
index 25aa575..98ec7a3 100644
--- a/include/net/bluetooth/rfcomm.h
+++ b/include/net/bluetooth/rfcomm.h
@@ -252,8 +252,8 @@ static inline void rfcomm_dlc_put(struct rfcomm_dlc *d)
rfcomm_dlc_free(d);
 }
 
-extern void FASTCALL(__rfcomm_dlc_throttle(struct rfcomm_dlc *d));
-extern void FASTCALL(__rfcomm_dlc_unthrottle(struct rfcomm_dlc *d));
+extern void __rfcomm_dlc_throttle(struct rfcomm_dlc *d);
+extern void __rfcomm_dlc_unthrottle(struct rfcomm_dlc *d);
 
 static inline void rfcomm_dlc_throttle(struct rfcomm_dlc *d)
 {
diff --git a/include/net/sock.h b/include/net/sock.h
index 67e35c7..bdad9ba 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -812,14 +812,14 @@ do {  
\
lockdep_init_map((sk)-sk_lock.dep_map, (name), (key), 0); \
 } while (0)
 
-extern void FASTCALL(lock_sock_nested(struct sock *sk, int subclass));
+extern void lock_sock_nested(struct sock *sk, int subclass);
 
 static inline void lock_sock(struct sock *sk)
 {
lock_sock_nested(sk, 0);
 }
 
-extern void FASTCALL(release_sock(struct sock *sk));
+extern void release_sock(struct sock *sk);
 
 /* BH context may only use the following locking interface. */
 #define bh_lock_sock(__sk) spin_lock(((__sk)-sk_lock.slock))
-- 
1.5.3.7.2212.gd092



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] sata_nv,adma: fix error when rmmod sata_nv

[Tejun Heo]

Kuan Luo wrote:
 hi,
 The below error happens when i rmmod sata_nv in adma mode on ck804
 chipset with 2.6.24 kernel.
 I traced the code and found that the driver attempts to write device mem
 that has been unmapped.
 
 Only simply removing the code writew(0, mmio + NV_ADMA_CTL); in the
 nv_adma_port_stop function or remove .port_stop field in nv_adma_ops,
 rmmod is ok.
 
 static void nv_adma_port_stop(struct ata_port *ap)
 {
   struct nv_adma_port_priv *pp = ap-private_data;
   void __iomem *mmio = pp-ctl_block;
 
   VPRINTK(ENTER\n);
 - writew(0, mmio + NV_ADMA_CTL);
 }
 
 Or
  Place pcim_iomap_regions before ata_pci_prepare_native_host in
 nv_init_one function.
 This can guarantee that the code writew(0, mmio + NV_ADMA_CTL)  write
 device mem before the device mem is unmapped.

Which kernel version are you using?  The following commit should have
fixed the problem.  Please give a shot at 2.6.24-rc5.  Thanks.

commit 32ebbc0c0d5d18c0135b55d1eb0029f48c54aff0
Author: Tejun Heo [EMAIL PROTECTED]
Date:   Thu Nov 8 13:09:00 2007 +0900

libata: port and host should be stopped before hardware resources are
released

-- 
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] Add support for the S-35390A RTC chip.

[Andrew Morton]

On Thu,  6 Dec 2007 22:10:27 + Byron Bradley [EMAIL PROTECTED] wrote:

 This adds basic get/set time support for the Seiko Instruments
 S-35390A. This chip communicates using I2C and is used on the
 QNAP TS-109/TS-209 NAS devices.
 

A nice looking little driver.

 +static inline char reverse(char x)
 +{
 + x = ((x  1)  0x55) | ((x  1)  0xaa);
 + x = ((x  2)  0x33) | ((x  2)  0xcc);
 + return (x  4) | (x  4);
 +}

Please take a peek in include/linux/bitrev.h ;)

(I worry about the handling of right-shift-of-negative-values
in your version, too).

Could you review and runtime test this please?

--- a/drivers/rtc/rtc-s35390a.c~rtc-add-support-for-the-s-35390a-rtc-chip-fix
+++ a/drivers/rtc/rtc-s35390a.c
@@ -12,6 +12,7 @@
 #include linux/module.h
 #include linux/rtc.h
 #include linux/i2c.h
+#include linux/bitrev.h
 #include linux/bcd.h
 
 #define S35390A_CMD_STATUS10
@@ -121,13 +122,6 @@ static int s35390a_reg2hr(struct s35390a
return hour;
 }
 
-static inline char reverse(char x)
-{
-   x = ((x  1)  0x55) | ((x  1)  0xaa);
-   x = ((x  2)  0x33) | ((x  2)  0xcc);
-   return (x  4) | (x  4);
-}
-
 static int s35390a_set_datetime(struct i2c_client *client, struct rtc_time *tm)
 {
struct s35390a  *s35390a = i2c_get_clientdata(client);
@@ -149,7 +143,7 @@ static int s35390a_set_datetime(struct i
 
/* This chip expects the bits of each byte to be in reverse order */
for (i = 0; i  7; ++i)
-   buf[i] = reverse(buf[i]);
+   buf[i] = bitrev8(buf[i]);
 
err = s35390a_set_reg(s35390a, S35390A_CMD_TIME1, buf, sizeof(buf));
 
@@ -168,7 +162,7 @@ static int s35390a_get_datetime(struct i
 
/* This chip returns the bits of each byte in reverse order */
for (i = 0; i  7; ++i)
-   buf[i] = reverse(buf[i]);
+   buf[i] = bitrev8(buf[i]);
 
tm-tm_sec = BCD2BIN(buf[S35390A_BYTE_SECS]);
tm-tm_min = BCD2BIN(buf[S35390A_BYTE_MINS]);
_

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: PNP: do not stop/start devices in suspend/resume path

[Andrew Morton]

On Thu, 6 Dec 2007 16:25:57 -0700 Bjorn Helgaas [EMAIL PROTECTED] wrote:

 Andrew, can you add this before
 pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch?
 
 ...

 PNP: do not stop/start devices in suspend/resume path

I did, but I also temporarily dropped
pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch.

Is it expected that this patch will fix
pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch? 
Should I bring it back?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT] Port 0x80 I/O speed

[Paolo Ornati]

On Wed, 12 Dec 2007 00:31:18 +0100
Rene Herman [EMAIL PROTECTED] wrote:
 
 and on a PII 400 (Intel 440BX chipset) a constant:
 
 [EMAIL PROTECTED]:~/src/port80$ su -c ./port80
 cycles: out 553, in 251
 
 Results are (mostly) independent of compiler optimisation, but testing with 
 an -O2 compile should be most useful. Thanks!


### Core2 Duo 1.8 GHz ###

X86_64 -m32 -O2:

$ for i in `seq 5`; do sudo ./port80; sleep 1; done
cycles: out 1498, in 964
cycles: out 1498, in 964
cycles: out 1499, in 964
cycles: out 1498, in 964
cycles: out 1498, in 965

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 CPU  6300  @ 1.86GHz
stepping: 6
cpu MHz : 1864.805
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 
ssse3 cx16 xtpr lahf_lm
bogomips: 3731.82
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

[...]


-- 
Paolo Ornati
Linux 2.6.24-rc4-g94545bad on x86_64
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] pcie AER: don't check _OSC when acpi is disabled

[Subrata Modak]

Would you like to submit the Driver Test Cases to LTP ? Or, if you have
your Driver test cases written in C, we can port to LTP and have it
inside the LTP package.
You can also check out the following links for more info, and can always
ping me for anything:
http://ltp.cvs.sourceforge.net/ltp/ltp/testcases/kernel/device-drivers/,
http://ltp.sourceforge.net/documentation/how-to/ltp.php?

Regards--
Subrata
(LTP Maintainer)

On Tue, 2007-12-11 at 20:13 -0800, Yinghai Lu wrote:
 [PATCH] pcie AER: don't check _OSC when acpi is disabled
 
 when acpi=off and pci=nomsi, don't check _OSC in aer_osc_setup
 
 Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
 
 diff --git a/drivers/pci/pcie/aer/aerdrv_acpi.c 
 b/drivers/pci/pcie/aer/aerdrv_acpi.c
 index 1a1eb45..dd38777 100644
 --- a/drivers/pci/pcie/aer/aerdrv_acpi.c
 +++ b/drivers/pci/pcie/aer/aerdrv_acpi.c
 @@ -34,6 +34,9 @@ int aer_osc_setup(struct pcie_device *pciedev)
   acpi_handle handle = DEVICE_ACPI_HANDLE(pdev-dev);
   struct pci_bus *parent;
 
 + if (acpi_pci_disabled)
 + return -1;
 +
   while (!handle) {
   if (!pdev || !pdev-bus-parent)
   break;
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

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

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Chris Rankin]

--- Andrew Morton [EMAIL PROTECTED] wrote:
 It might be interesting to see what value of `i' is causing it to fall over.

I tried unrolling the loop, but a single byte read for i = 0 is enough to lock 
things up.

 Did any earlier version of the 2.6 kernel work OK?

Unfortunately, I don't know. I swapped this card out of the old 2.4.x machine 
into a machine
already running Fedora 7. The card works when I put it back into the 2.4 
machine too, so it's not
a hardware problem with the card.

So I suppose the next step would be trying a linux 2.6.0 kernel? Or was hostap 
included in the
kernel later than that?

Cheers,
Chris




  ___
Support the World Aids Awareness campaign this month with Yahoo! For Good 
http://uk.promotions.yahoo.com/forgood/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 -v2] x86 boot : export boot_params via sysfs

[Huang, Ying]

This patch export the boot parameters via sysfs. This can be used for
debugging and kexec.

The files added are as follow:

/sys/kernel/boot_params/data: binary file for struct boot_params
/sys/kernel/boot_params/version : boot protocol version

This patch is based on 2.6.24-rc4-mm1 and has been tested on i386 and
x86_64 platoform.

This patch is based on the Peter Anvin's proposal.


v2:

- Add document in Document/ABI.


Signed-off-by: Huang Ying [EMAIL PROTECTED]

---
 Documentation/ABI/testing/sysfs-kernel-boot_params |   14 +++
 arch/x86/kernel/Makefile_32|1 
 arch/x86/kernel/Makefile_64|1 
 arch/x86/kernel/ksysfs.c   |   89 +
 arch/x86/kernel/setup64.c  |2 
 arch/x86/kernel/setup_32.c |2 
 6 files changed, 107 insertions(+), 2 deletions(-)

--- a/arch/x86/kernel/Makefile_64
+++ b/arch/x86/kernel/Makefile_64
@@ -39,6 +39,7 @@ obj-$(CONFIG_X86_VSMP)+= vsmp_64.o
 obj-$(CONFIG_K8_NB)+= k8.o
 obj-$(CONFIG_AUDIT)+= audit_64.o
 obj-$(CONFIG_EFI)  += efi.o efi_64.o efi_stub_64.o
+obj-$(CONFIG_SYSFS)+= ksysfs.o
 
 obj-$(CONFIG_MODULES)  += module_64.o
 obj-$(CONFIG_PCI)  += early-quirks.o
--- a/arch/x86/kernel/setup64.c
+++ b/arch/x86/kernel/setup64.c
@@ -24,7 +24,7 @@
 #include asm/sections.h
 #include asm/setup.h
 
-struct boot_params __initdata boot_params;
+struct boot_params boot_params;
 
 cpumask_t cpu_initialized __cpuinitdata = CPU_MASK_NONE;
 
--- /dev/null
+++ b/arch/x86/kernel/ksysfs.c
@@ -0,0 +1,89 @@
+/*
+ * Architecture specific sysfs attributes in /sys/kernel
+ *
+ * Copyright (C) 2007, Intel Corp.
+ *  Huang Ying [EMAIL PROTECTED]
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/kobject.h
+#include linux/string.h
+#include linux/sysfs.h
+#include linux/init.h
+#include linux/stat.h
+#include linux/mm.h
+
+#include asm/setup.h
+
+static ssize_t boot_params_version_show(struct kobject *kobj,
+   struct kobj_attribute *attr, char *buf)
+{
+   return sprintf(buf, 0x%04x\n, boot_params.hdr.version);
+}
+
+static struct kobj_attribute boot_params_version_attr =
+   __ATTR(version, S_IRUGO, boot_params_version_show, NULL);
+
+static struct attribute *boot_params_attrs[] = {
+   boot_params_version_attr.attr,
+   NULL
+};
+
+static struct attribute_group boot_params_attr_group = {
+   .attrs = boot_params_attrs,
+};
+
+static ssize_t boot_params_data_read(struct kobject *kobj,
+struct bin_attribute *bin_attr,
+char *buf, loff_t off, size_t count)
+{
+   memcpy(buf, (void *)boot_params + off, count);
+   return count;
+}
+
+static struct bin_attribute boot_params_data_attr = {
+   .attr = {
+   .name = data,
+   .mode = S_IRUGO,
+   },
+   .read = boot_params_data_read,
+   .size = sizeof(boot_params),
+};
+
+static int __init boot_params_ksysfs_init(void)
+{
+   int error;
+   struct kobject *boot_params_kobj;
+
+   boot_params_kobj = kobject_create_and_register(boot_params,
+  kernel_kobj);
+   if (!boot_params_kobj) {
+   error = -ENOMEM;
+   goto err_return;
+   }
+   error = sysfs_create_group(boot_params_kobj,
+  boot_params_attr_group);
+   if (error)
+   goto err_boot_params_subsys_unregister;
+   error = sysfs_create_bin_file(boot_params_kobj,
+ boot_params_data_attr);
+   if (error)
+   goto err_boot_params_subsys_unregister;
+   return 0;
+err_boot_params_subsys_unregister:
+   kobject_unregister(boot_params_kobj);
+err_return:
+   return error;
+}
+
+static int __init arch_ksysfs_init(void)
+{
+   int error;
+
+   error = boot_params_ksysfs_init();
+
+   return error;
+}
+
+arch_initcall(arch_ksysfs_init);
--- a/arch/x86/kernel/Makefile_32
+++ b/arch/x86/kernel/Makefile_32
@@ -44,6 +44,7 @@ obj-$(CONFIG_EARLY_PRINTK)+= early_prin
 obj-$(CONFIG_HPET_TIMER)   += hpet.o
 obj-$(CONFIG_K8_NB)+= k8.o
 obj-$(CONFIG_MGEODE_LX)+= geode_32.o mfgpt_32.o
+obj-$(CONFIG_SYSFS)+= ksysfs.o
 
 obj-$(CONFIG_VMI)  += vmi_32.o vmiclock_32.o
 obj-$(CONFIG_PARAVIRT) += paravirt_32.o
--- a/arch/x86/kernel/setup_32.c
+++ b/arch/x86/kernel/setup_32.c
@@ -194,7 +194,7 @@ unsigned long saved_videomode;
 
 static char __initdata command_line[COMMAND_LINE_SIZE];
 
-struct boot_params __initdata boot_params;
+struct boot_params boot_params;
 
 #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
 struct edd edd;
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-boot_params
@@ -0,0 

Re: [PATCH] Intel Management Engine Interface

[Alexander E. Patrakov]

Anas Nashif wrote:

The Intel Management Engine Interface (aka HECI: Host Embedded 
Controller Interface ) enables communication between the host OS and 
the Management Engine firmware. MEI is bi-directional, and either the 
host or Intel AMT firmware can initiate transactions.


There is a little problem: the driver doesn't work at all with the 64-bit 
kernel and 32-bit userspace combination.


ioctl32(lms:7759): Unknown cmd fd(0) cmd(c0084800){t:'H';sz:8} arg(ffdfea44) on 
/dev/heci


Could you please fix it?

--
Alexander E. Patrakov
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] k8: Enable legacy irqs with extended cpu ids

[Eric W. Biederman]

Neil Horman [EMAIL PROTECTED] writes:

 Recently a kdump bug was discovered in which a system would hang inside
 calibrate_delay during the booting of the kdump kernel.  This was caused by 
 the
 fact that the jiffies counter was not being incremented during timer
 calibration.  The root cause of this problem was found to be a bios
 misconfiguration of the hypertransport bus.  On system affected by this hang,
 the bios had assigned APIC ids which used extended apic bits (more than the
 nominal 4 bit ids's), but failed to configure bit 17 of the hypertransport
 transaction config register, which indicated that the mask for the destination
 field of interrupt packets accross the ht bus (see section 3.3.9 of
 http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF).
 If a crash occurs on a cpu with an APIC id that extends beyond 4 bits, it will
 not recieve interrupts during the kdump kernel boot, and this hang will be the
 result.  The fix is to add this patch, whcih add an early pci quirk check, to
 forcibly enable this bit in the httcfg register.  This enables all cpus on a
 system to receive interrupts, and allows kdump kernel bootup to procede
 normally.

 Regards
 Neil


 Signed-off-by: Neil Horman [EMAIL PROTECTED]

Acked-by: Eric W. Biederman [EMAIL PROTECTED]

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

Re: [RFT] Port 0x80 I/O speed

[Edwin de Caluwé]

Exactly constant timing in every iteration:

cycles: out 667, in 305

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Celeron (Coppermine)
stepping: 3
cpu MHz : 497.582
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse up
bogomips: 996.21
clflush size: 32


On 12/12/07, Paolo Ornati [EMAIL PROTECTED] wrote:
 On Wed, 12 Dec 2007 00:31:18 +0100
 Rene Herman [EMAIL PROTECTED] wrote:
 
  and on a PII 400 (Intel 440BX chipset) a constant:
 
  [EMAIL PROTECTED]:~/src/port80$ su -c ./port80
  cycles: out 553, in 251
 
  Results are (mostly) independent of compiler optimisation, but testing
 with
  an -O2 compile should be most useful. Thanks!
 

 ### Core2 Duo 1.8 GHz ###

 X86_64 -m32 -O2:

 $ for i in `seq 5`; do sudo ./port80; sleep 1; done
 cycles: out 1498, in 964
 cycles: out 1498, in 964
 cycles: out 1499, in 964
 cycles: out 1498, in 964
 cycles: out 1498, in 965

 processor : 0
 vendor_id : GenuineIntel
 cpu family: 6
 model : 15
 model name: Intel(R) Core(TM)2 CPU  6300  @ 1.86GHz
 stepping  : 6
 cpu MHz   : 1864.805
 cache size: 2048 KB
 physical id   : 0
 siblings  : 2
 core id   : 0
 cpu cores : 2
 fpu   : yes
 fpu_exception : yes
 cpuid level   : 10
 wp: yes
 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
 pat
 pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
 constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2
 ssse3 cx16 xtpr lahf_lm
 bogomips  : 3731.82
 clflush size  : 64
 cache_alignment   : 64
 address sizes : 36 bits physical, 48 bits virtual
 power management:

 [...]


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

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

Re: [PATCH 7/7] [NETDEV]: myri10ge Fix possible causing oops of net_rx_action

[Subrata Modak]

Would you like to submit the Driver Test Cases to LTP ? Or, if you have
your Driver test cases written in C, we can port to LTP and have it
inside the LTP package.
You can also check out the following links for more info, and can always
ping me for anything:
http://ltp.cvs.sourceforge.net/ltp/ltp/testcases/kernel/device-drivers/,
http://ltp.sourceforge.net/documentation/how-to/ltp.php?

Regards--
Subrata
(LTP Maintainer)

On Wed, 2007-12-12 at 13:01 +0900, Joonwoo Park wrote:
 [NETDEV]: myri10ge Fix possible causing oops of net_rx_action
 
 Signed-off-by: Joonwoo Park [EMAIL PROTECTED]
 ---
  drivers/net/myri10ge/myri10ge.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
 index 8def865..57311ed 100644
 --- a/drivers/net/myri10ge/myri10ge.c
 +++ b/drivers/net/myri10ge/myri10ge.c
 @@ -1242,6 +1242,8 @@ static int myri10ge_poll(struct napi_struct *napi, int 
 budget)
   if (work_done  budget || !netif_running(netdev)) {
   netif_rx_complete(netdev, napi);
   put_be32(htonl(3), mgp-irq_claim);
 + if (unlikely(work_done == napi-weight))
 + return work_done - 1;
   }
   return work_done;
  }
 ---
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

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

Re: [RFT] Port 0x80 I/O speed

[Dave Young]

On Dec 12, 2007 7:31 AM, Rene Herman [EMAIL PROTECTED] wrote:
 Good day.

 Would some people on x86 (both 32 and 64) be kind enough to compile and run
 the attached program? This is about testing how long I/O port access to port
 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting.

 Posted a previous incarnation of this before, buried in the outb 0x80 thread
 which had a serialising problem. This one should as far as I can see measure
 the right thing though. Please yell if you disagree...

 For me, on a Duron 1300 (AMD756 chipset) I have a constant:

 [EMAIL PROTECTED]:~/src/port80$ su -c ./port80
 cycles: out 2400, in 2400

 and on a PII 400 (Intel 440BX chipset) a constant:

 [EMAIL PROTECTED]:~/src/port80$ su -c ./port80
 cycles: out 553, in 251

 Results are (mostly) independent of compiler optimisation, but testing with
 an -O2 compile should be most useful. Thanks!

 Rene.

 /* gcc -W -Wall -O2 -o port80 port80.c */

 #include stdlib.h
 #include stdio.h

 #include sys/io.h

 #define LOOPS 1

 inline unsigned long long rdtsc(void)
 {
 unsigned long long tsc;

 asm volatile (rdtsc: =A (tsc));

 return tsc;
 }

 inline void serialize(void)
 {
 asm volatile (cpuid: : : eax, ebx, ecx, edx);
 }

 int main(void)
 {
 unsigned long long start;
 unsigned long long overhead;
 unsigned long long output;
 unsigned long long input;
 int i;

 if (iopl(3)  0) {
 perror(iopl);
 return EXIT_FAILURE;
 }

 asm volatile (cli);
 start = rdtsc();
 for (i = 0; i  LOOPS; i++) {
 serialize();
 serialize();
 }
 overhead = rdtsc() - start;

 start = rdtsc() + overhead;
 for (i = 0; i  LOOPS; i++) {
 serialize();
 asm volatile (outb %al, $0x80);
 serialize();
 }
 output = rdtsc() - start;

 start = rdtsc() + overhead;
 for (i = 0; i  LOOPS; i++) {
 serialize();
 asm volatile (inb $0x80, %%al: : : al);
 serialize();
 }
 input = rdtsc() - start;
 asm volatile (sti);

 output /= LOOPS;
 input  /= LOOPS;
 printf(cycles: out %llu, in %llu\n, output, input);

 return EXIT_SUCCESS;
 }



[EMAIL PROTECTED]:~/work/tmp$ sudo ./port80
cycles: out 2522, in 1788
[EMAIL PROTECTED]:~/work/tmp$ sudo ./port80
cycles: out 2522, in 1795
[EMAIL PROTECTED]:~/work/tmp$ sudo ./port80
cycles: out 2523, in 1788
[EMAIL PROTECTED]:~/work/tmp$ sudo ./port80
cycles: out 2516, in 1788
[EMAIL PROTECTED]:~/work/tmp$ sudo ./port80
cycles: out 2516, in 1798
[EMAIL PROTECTED]:~/work/tmp$ sudo ./port80
cycles: out 2523, in 1788
[EMAIL PROTECTED]:~/work/tmp$ sudo ./port80
cycles: out 2518, in 1788
[EMAIL PROTECTED]:~/work/tmp$ sudo ./port80
cycles: out 2517, in 1788
[EMAIL PROTECTED]:~/work/tmp$ sudo ./port80
cycles: out 2523, in 1788
[EMAIL PROTECTED]:~/work/tmp$ sudo ./port80
cycles: out 2517, in 1788

[EMAIL PROTECTED]:~$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 4
model name  : Intel(R) Pentium(R) D CPU 2.80GHz
stepping: 7
cpu MHz : 2793.194
cache size  : 1024 KB
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] Improve inode list scanning in add_dquot_ref()

[Jan Kara]

On Tue 11-12-07 15:43:10, Andrew Morton wrote:
 On Tue, 11 Dec 2007 14:43:19 +0100
 Jan Kara [EMAIL PROTECTED] wrote:
 
Hi,
  
attached patch makes add_dquot_ref() quite faster if used on a life
  filesystem. It has survived some testing on my machine but there could be
  some subtle races I've missed so please leave it in -mm for a while (not
  that I'd think that people use quotas with -mm kernels but at least it
  should go into vanilla in -rc1...). Thanks.
  
  Honza
  
  ---
  We restarted scan of sb-s_inodes list whenever we had to drop inode_lock in
  add_dquot_ref(). This leads to overall quadratic running time and thus
  add_dquot_ref() can take several minutes when called on a life filesystem.  
  We
  fix the problem by using the fact that inode cannot be removed from s_inodes
  list while we hold a reference to it and thus we can safely restart the 
  scan if
  we don't drop the reference. Here we use the fact that inodes freshly added 
  to
  s_inodes list are already guaranteed to have quotas properly initialized and
  the ordering of inodes on s_inodes list does not change so we cannot skip 
  any
  inode.  Thanks goes to Nick [EMAIL PROTECTED] for analyzing the problem 
  and
  testing the fix.
  
  Signed-off-by: Jan Kara [EMAIL PROTECTED]
  CC: Nick [EMAIL PROTECTED]
  
  diff --git a/fs/dquot.c b/fs/dquot.c
  index 2809768..ecea4be 100644
  --- a/fs/dquot.c
  +++ b/fs/dquot.c
  @@ -696,9 +696,8 @@ static int dqinit_needed(struct inode *inode, int type)
   /* This routine is guarded by dqonoff_mutex mutex */
   static void add_dquot_ref(struct super_block *sb, int type)
   {
  -   struct inode *inode;
  +   struct inode *inode, *old_inode = NULL;
   
  -restart:
  spin_lock(inode_lock);
  list_for_each_entry(inode, sb-s_inodes, i_sb_list) {
  if (!atomic_read(inode-i_writecount))
  @@ -711,12 +710,20 @@ restart:
  __iget(inode);
  spin_unlock(inode_lock);
   
  +   if (old_inode)
  +   iput(old_inode);
  sb-dq_op-initialize(inode, type);
  -   iput(inode);
  -   /* As we may have blocked we had better restart... */
  -   goto restart;
  +   /* We hold a reference to 'inode' so it couldn't have been
  +* removed from s_inodes list while we dropped the inode_lock.
  +* We cannot iput the inode now as we can be holding the last
  +* reference and we cannot iput it under inode_lock. So we
  +* keep the reference and iput it later. */
  +   old_inode = inode;
  +   spin_lock(inode_lock);
  }
  spin_unlock(inode_lock);
  +   if (old_inode)
  +   iput(old_inode);
   }
   
 
 iput(NULL) is legal.  In the great majority of cases old_inode!=NULL so I
 think we should use that feature here?
  OK. Thanks for the improvement.

 --- a/fs/dquot.c~quota-improve-inode-list-scanning-in-add_dquot_ref-fix
 +++ a/fs/dquot.c
 @@ -710,8 +710,7 @@ static void add_dquot_ref(struct super_b
   __iget(inode);
   spin_unlock(inode_lock);
  
 - if (old_inode)
 - iput(old_inode);
 + iput(old_inode);
   sb-dq_op-initialize(inode, type);
   /* We hold a reference to 'inode' so it couldn't have been
* removed from s_inodes list while we dropped the inode_lock.
 @@ -722,8 +721,7 @@ static void add_dquot_ref(struct super_b
   spin_lock(inode_lock);
   }
   spin_unlock(inode_lock);
 - if (old_inode)
 - iput(old_inode);
 + iput(old_inode);
  }
  
  /* Return 0 if dqput() won't block (note that 1 doesn't necessarily mean 
 blocking) */
 _
 
Honza
-- 
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT] Port 0x80 I/O speed

[Jiri Slaby]

On 12/12/2007 12:31 AM, Rene Herman wrote:
 Good day.
 
 Would some people on x86 (both 32 and 64) be kind enough to compile and
 run the attached program? This is about testing how long I/O port access

model name  : Intel(R) Core(TM)2 Duo CPU E6850  @ 3.00GHz

cycles: out 6490, in 3135
cycles: out 6484, in 3126
cycles: out 6511, in 3128
cycles: out 6500, in 3135
cycles: out 6492, in 3154
cycles: out 6506, in 3136
cycles: out 6516, in 3144
cycles: out 6489, in 3140
cycles: out 6492, in 3129
cycles: out 6507, in 3130

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

Re: 2.6.24-rc5 videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!

[Adrian Bunk]

Patch looks good, it seems a merge conflict of
commit 19bc5133dae9562e8824ef101464061f9854c1d8
was resolved the wrong way.

@Mauro:
Any objections against a later path that changes the exports to the 
general immediately after the function convention?
It would have avoided at least two such bugs in this file alone since 
2.6.23...

cu
Adrian


On Wed, Dec 12, 2007 at 12:20:31AM -0500, Shane wrote:
 In 2.6.24-rc5+, I hit this problem with videobuf_read_start
 not being exported. Patch attached, only compile tested.
 
   CHK include/linux/version.h
   CHK include/linux/utsrelease.h
   CALLscripts/checksyscalls.sh
   CHK include/linux/compile.h
   CC [M]  drivers/media/video/videobuf-core.o
   Building modules, stage 2.
 Kernel: arch/x86/boot/bzImage is ready  (#1)
   MODPOST 202 modules
 ERROR: videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!
 make[1]: *** [__modpost] Error 1
 make: *** [modules] Error 2
 
 Shane

 diff --git a/drivers/media/video/videobuf-core.c 
 b/drivers/media/video/videobuf-core.c
 index de2f56b..44fa76b 100644
 --- a/drivers/media/video/videobuf-core.c
 +++ b/drivers/media/video/videobuf-core.c
 @@ -1058,6 +1058,7 @@ EXPORT_SYMBOL_GPL(videobuf_dqbuf);
  EXPORT_SYMBOL_GPL(videobuf_streamon);
  EXPORT_SYMBOL_GPL(videobuf_streamoff);
  
 +EXPORT_SYMBOL_GPL(videobuf_read_start);
  EXPORT_SYMBOL_GPL(videobuf_read_stop);
  EXPORT_SYMBOL_GPL(videobuf_stop);
  EXPORT_SYMBOL_GPL(videobuf_read_stream);


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] netmos 9855 fix

[Andrew Morton]

On Wed,  5 Dec 2007 11:27:27 +0100 [EMAIL PROTECTED] wrote:

 Fixes wrong netmos 9855 serial port configuration.
 
 Generated on  20071205  against v2.6.21
 
 Signed-off-by: Christian Pellegrin [EMAIL PROTECTED]
 ---
  drivers/parport/parport_serial.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/parport/parport_serial.c 
 b/drivers/parport/parport_serial.c
 index 78c0a26..5b04e78 100644
 --- a/drivers/parport/parport_serial.c
 +++ b/drivers/parport/parport_serial.c
 @@ -77,7 +77,7 @@ static struct parport_pc_pci cards[] __devinitdata = {
   /* titan_110l */{ 1, { { 3, -1 }, } },
   /* titan_210l */{ 1, { { 3, -1 }, } },
   /* netmos_9xx5_combo */ { 1, { { 2, -1 }, }, 
 netmos_parallel_init },
 - /* netmos_9855 */   { 1, { { 0, -1 }, }, 
 netmos_parallel_init },
 + /* netmos_9855 */   { 1, { { 2, -1 }, }, 
 netmos_parallel_init },
   /* avlab_1s1p */{ 1, { { 1, 2}, } },
   /* avlab_1s2p */{ 2, { { 1, 2}, { 3, 4 },} },
   /* avlab_2s1p */{ 1, { { 2, 3}, } },
 @@ -185,7 +185,7 @@ static struct pciserial_board pci_parport_serial_boards[] 
 __devinitdata = {
   .uart_offset= 8,
   },
   [netmos_9855] = {
 - .flags  = FL_BASE2 | FL_BASE_BARS,
 + .flags  = FL_BASE4 | FL_BASE_BARS,
   .num_ports  = 1,
   .base_baud  = 115200,
   .uart_offset= 8,

What was wrong with it?

Martin, does this change affect the hardware upon which you tested
44e58a6a0bd604f46be9d808408a1cd880cc9b19, parport: NetMos nm9855 fix?

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: x86, ptrace: support for branch trace store(BTS)

[Metzger, Markus T]

-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED] 
Sent: Dienstag, 11. Dezember 2007 15:53


In the second use-case (tracing, profiling, call coverage metrics), we 
could live without zero-copy, as long as the buffer could be 
made large 
enough. The current 4000 records limit seems rather low (and 
arbitrary) 
and probably makes the mechanism unsuitable for say call coverage 
profiling purposes. 

The limit is indeed arbitrary. It was requested by one of my internal
reviewers. The rationale was that we do not want to allow ptrace users
to request that an unlimited amount of memory be allocated in the
kernel.

Andi suggested to make this a sysctl.

Would it be safe to drop the artificial limit and let the limit be the
available memory?


There's also no real mechanism that i can see to 
create a guaranteed flow of this information between the debugger and 
debuggee (unless i missed something), the code appears to overflow the 
array, and destroy earlier entries, right? That's by design for 
debugging, but quite a limitation for instrumentation which might want 
to have a reliable stream of the data (and would like the originating 
task to block until the debugger had an opportunity to siphoon out the 
data).

That's correct as well. My focus is on debugging. And that's actually
the most useful behavior in that case. I'm not sure what you mean with
'instrumentation'.


Regarding streaming data (the only real use case I can think of would be
path profiling), I think I would rather allocate a bigger buffer and
send a signal when the buffer gets full instead of having the kernel
provide an interrupt service routine and copy the data from a smaller
buffer into a bigger one.

This would leave it to the tracing task which likely wants to write the
data into a file if it really got too big to hold it in physical memory.
We would need another command to reset the DS index, and probably one to
provide the entire buffer at once, and add some configuration bits to
say whether we want the signal or a cyclic buffer.


For debugging, I think this extension is not relevant. Since it could be
implemented as an extension of the current interface, I would leave it,
for now.


 I need to look more into mlock. So far, I found a system call in 
 /usr/include/sys/mman.h and two functions sys_mlock() and 
 user_shm_lock() in the kernel. Is there a memory expert around who 
 could point me to some interesting places to look at?

sys_mlock() is what i meant - you could just call it internally from 
ptrace and fail the call if sys_mlock() returns -EPERM. This keeps all 
the there's too much memory pinned down details out of the ptrace 
code.

 Can we distinguish kernel-locked memory from user-locked memory? I 
 could imagine a malicious user to munlock() the buffer he 
provided to 
 ptrace.

yeah. Once mlock()-ed, you need to pin it via get_user_pages(). That 
gives a permanent reference count to those pages.

sys_mlock() eventually results in a call to get_user_pages().
I have not found the corresponding put_page() call for munlock(),
though.

So you're suggesting to do an additional get_user_pages to prevent the
user from munlock()ing the memory?
So, if the pages are unlocked, they will still be pinned down and cannot
further be unlocked?

Something like:
ptrace_allocate(struct task_struct *child, void *base, size_t size) {
if (sys_mlock(base, size)  0)
return -EPERM;
get_user_pages(child, , base, size, );
}


 Is there a real difference between mlock()ing user memory and 
 allocating kernel memory? There would be if we could page out 
 mlock()ed memory when the user thread is not running. We 
would need to 
 disable DS before paging out, and page in before enabling it. If we 
 cannot, then kernel allocated memory would require less space in 
 physical memory.

mlock() would in essence just give you an easy does this user have 
enough privilege to lock this many pages API. The real 
pinning would be 
done by get_user_pages(). Once you have those pages, they wont be 
swapped out.

The actual physical memory consumption will be worse (or at best equal)
compared to kalloc()ed memory, since we need to pin down entire pages,
whereas kalloc() would allocate just the memory that is actually needed.

Unless we would put_page() and get_user_pages() the pinned down pages on
a context switch. But then, get_user_pages() calls cond_resched(), which
might not be a good think to do during a context switch.


Overall, I think that kalloc() is actually more memory efficient than
mlock(). The only benefit of mlock() would be that we save some
copy_to_user() in the debugger task. This should not be a big deal for
debuggers, but it might become interesting for profilers.

On the other hand, profilers would typically expect a stream of data and
they would either want a terribly big buffer or store the data into a
file. In both cases, they need to do a lot of copying, already.

I would stay 

Re: [PATCH 20/30] blk_end_request: changing xsysace (take 4)

[Boaz Harrosh]

Kiyoshi Ueda wrote:
 This patch converts xsysace to use blk_end_request interfaces.
 Related 'uptodate' arguments are converted to 'error'.
 
 xsysace is a little bit different from normal drivers.
 xsysace driver has a state machine in it.
 It calls end_that_request_first() and end_that_request_last()
 from different states. (ACE_FSM_STATE_REQ_TRANSFER and
 ACE_FSM_STATE_REQ_COMPLETE, respectively.)
 
 However, those states are consecutive and without any interruption
 inbetween.
 So we can just follow the standard conversion rule (b) mentioned in
 the patch subject [PATCH 01/30] blk_end_request: add new request
 completion interface.
 
 Cc: Grant Likely [EMAIL PROTECTED]
 Signed-off-by: Kiyoshi Ueda [EMAIL PROTECTED]
 Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
 ---
  drivers/block/xsysace.c |5 +
  1 files changed, 1 insertion(+), 4 deletions(-)
 
 Index: 2.6.24-rc4/drivers/block/xsysace.c
 ===
 --- 2.6.24-rc4.orig/drivers/block/xsysace.c
 +++ 2.6.24-rc4/drivers/block/xsysace.c
 @@ -703,7 +703,7 @@ static void ace_fsm_dostate(struct ace_d
  
   /* bio finished; is there another one? */
   i = ace-req-current_nr_sectors;
 - if (end_that_request_first(ace-req, 1, i)) {
 + if (__blk_end_request(ace-req, 0, i)) {
end_that_request_first() took sectors __blk_end_request() now takes
bytes

   /* dev_dbg(ace-dev, next block; h=%li c=%i\n,
*  ace-req-hard_nr_sectors,
*  ace-req-current_nr_sectors);
 @@ -718,9 +718,6 @@ static void ace_fsm_dostate(struct ace_d
   break;
  
   case ACE_FSM_STATE_REQ_COMPLETE:
 - /* Complete the block request */
 - blkdev_dequeue_request(ace-req);
 - end_that_request_last(ace-req, 1);
   ace-req = NULL;
  
   /* Finished request; go to idle state */
 -
 To unsubscribe from this list: send the line unsubscribe linux-scsi in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

kernel panic - help!?

[Oliver Falk]

Can someone explain me that?

Dec 12 00:24:15 santorini kernel: Unable to handle kernel NULL pointer
dereference at virtual address 
Dec 12 00:24:15 santorini kernel:  printing eip:
Dec 12 00:24:15 santorini kernel: c0190182
Dec 12 00:24:15 santorini kernel: *pde = 1b62b001
Dec 12 00:24:15 santorini kernel: Oops:  [#1]
Dec 12 00:24:15 santorini kernel: SMP
Dec 12 00:24:15 santorini kernel: Modules linked in: mptctl mptbase sg
md5 ipv6 i2c_dev i2c_core button battery ac uhci_hcd ehci_hcd hw_rand
om tg3 bonding(U) floppy ata_piix libata dm_snapshot dm_zero dm_mirror
ext3 jbd dm_mod cciss sd_mod scsi_mod
Dec 12 00:24:15 santorini kernel: CPU:2
Dec 12 00:24:15 santorini kernel: EIP:0060:[c0190182]Not
tainted VLI
Dec 12 00:24:15 santorini kernel: EFLAGS: 00010246   (2.6.9-55.0.9.ELsmp)
Dec 12 00:24:15 santorini kernel: EIP is at sysfs_readdir+0x123/0x187
Dec 12 00:24:15 santorini kernel: eax:    ebx: e1f04880   ecx:
   edx: 
Dec 12 00:24:15 santorini kernel: esi: e1f04884   edi:    ebp:
f6bf2144   esp: ec134f60
Dec 12 00:24:15 santorini kernel: ds: 007b   es: 007b   ss: 0068
Dec 12 00:24:15 santorini kernel: Process save (pid: 13931,
threadinfo=ec134000 task=f59c12b0)
Dec 12 00:24:15 santorini kernel: Stack:  f7e14e40 c016baf5
ec134fa0 f2eb8180 c0332640 f2eb8180 f7c45438
Dec 12 00:24:15 santorini kernel:c016baf5 c016b771 ec134fa0
ffda 08304764 f2eb8180  c016bdab
Dec 12 00:24:15 santorini kernel:083047cc 083047b4 0f98
ffea 0009 08304764 b7fccff4 ec134000
Dec 12 00:24:15 santorini kernel: Call Trace:
Dec 12 00:24:15 santorini kernel:  [c016baf5] filldir64+0x0/0x11a
Dec 12 00:24:15 santorini kernel:  [c016baf5] filldir64+0x0/0x11a
Dec 12 00:24:15 santorini kernel:  [c016b771] vfs_readdir+0x7d/0xa5
Dec 12 00:24:15 santorini kernel:  [c016bdab] sys_getdents64+0x80/0xba
Dec 12 00:24:15 santorini kernel:  [c02d64db] syscall_call+0x7/0xb
Dec 12 00:24:15 santorini kernel:  [c02d007b]
unix_dgram_sendmsg+0x23c/0x45d
Dec 12 00:24:16 santorini kernel: Code: 04 89 69 0c 8b 75 00 8b 44 24 04
83 c0 0c 39 c6 74 73 8d 5e fc 83 7b 14 00 74 66 89 d8 e8 07 ec ff f
f 89 c2 83 c9 ff 31 c0 89 d7 f2 ae f7 d1 49 0f b7 43 1c c1 e8 0c 50 ff
73 20 8b 44 24 18 ff
Dec 12 00:24:16 santorini kernel:  0Fatal exception: panic in 5 seconds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT] Port 0x80 I/O speed

[Juergen Beisert]

$ for i in `seq 5`; do ./port80; sleep 1; done
cycles: out 5260, in 2372
cycles: out 5260, in 2384
cycles: out 5260, in 2323
cycles: out 5270, in 2382
cycles: out 5259, in 2323

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 7
model name  : Pentium III (Katmai)
stepping: 3
cpu MHz : 501.208
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 mmx fxsr sse
bogomips: 993.28

#

$ for i in `seq 5`; do ./port80; sleep 1; done
cycles: out 1214, in 1095
cycles: out 1215, in 1094
cycles: out 1214, in 1095
cycles: out 1216, in 1095
cycles: out 1213, in 1093

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 11
model name  : Intel(R) Celeron(TM) CPU1000MHz
stepping: 1
cpu MHz : 1002.285
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat 
pse36 mmx fxsr sse
bogomips: 1998.84
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] Get rid of FASTCALL() in include/linux/*.h

[Ingo Molnar]

* Harvey Harrison [EMAIL PROTECTED] wrote:

 Now that x86 uses regparm(3) by default, we can get rid of the 
 FASTCALL() macro.  This gets rid of it in all linux/include header 
 files.

i suspect this patch is for Andrew and -mm.

i've picked your other, x86 unification patches up into x86.git - they 
look fine.

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

Re: [PATCH] Add Documentation for FAIR_USER_SCHED sysfs files

[Ingo Molnar]

* Dhaval Giani [EMAIL PROTECTED] wrote:

  Hm, how about describing the units here?  Can you put 10 in each 
  file and everyone will get the same share?  100?  1?  1024 seems 
  like an odd share number.  Unless there is some other document you 
  wish to refer people to do help describe these values?
 
 It is proportional. That is, if two users have same value for shares, 
 they will get equal bandwidth on the CPU. If they are in the ratio 
 1:2, then they will share it in that ratio. I've updated the patch for 
 this. Hope it is clearer.

thanks, applied.

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

Re: [PATCH] max3100 driver

[Andrew Morton]

On Wed,  5 Dec 2007 11:26:45 +0100 [EMAIL PROTECTED] wrote:

 This patch adds support for the MAX3100 SPI UART.
 

Doesn't compile on x86_64:

drivers/serial/max3100.c: In function 'startup':
drivers/serial/max3100.c:706: error: 'IRQT_FALLING' undeclared (first use in 
this function)
drivers/serial/max3100.c:706: error: (Each undeclared identifier is reported 
only once
drivers/serial/max3100.c:706: error: for each function it appears in.)
drivers/serial/max3100.c:708: error: 'IRQT_LOW' undeclared (first use in this 
function)

  include/linux/serial_max3100.h |   25 +
  4 files changed, 993 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
 index 81b52b7..4e7111b 100644
 --- a/drivers/serial/Kconfig
 +++ b/drivers/serial/Kconfig
 @@ -461,6 +461,13 @@ config SERIAL_S3C2410_CONSOLE
 your boot loader about how to pass options to the kernel at
 boot time.)
  
 +config SERIAL_MAX3100
 +tristate MAX3100 support
 +depends on SPI
 +help
 +  MAX3100 chip support
 +

Putting a depends on ARM in here might be sufficient.

 +++ b/drivers/serial/max3100.c
 @@ -0,0 +1,960 @@
 +
 +/* 
 + *
 + *  Copyright (C) 2007 Christian Pellegrin [EMAIL PROTECTED]
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * version 0.1  31/5/2006   first public release
 + * version 0.2  11/11/2007  ported to kernel 2.6.23

Normally we skip info like this - it's all in the git tree, in better form.

 +static struct tty_driver *serial_driver = NULL;

This initialisation is unneeded and is undesirable because it increases the
kernel image's .data.

Please run the diff through scripts/checkpatch.pl.  It would have mentioned
this, and a whole lot of other things, too.

 +/* global since we do register the driver only once */

I assume this comment refers to the preceding line?

Please put comments like this above the code which they're talking about. 
Doing it this way is quite confusing to kernel developers.

 +#define MAX_MAX3100 4/* 4 MAX3100s should be enough for 
 everyone */
 +static struct max3100_port_s * max3100s[MAX_MAX3100]; /* the chips */

No space after the *, please (checkpatch should detect this).

 +
 +#define MAX3100_TX_BUF_N 16
 +/* our buffer for sendind chars */

Typo.  Misplaced comment.

 +#define MAX3100_FLIP_EVERY 8
 +/* how many chars we wait befor flipping tty buffer */

Misplaced comment.

 +static void irq_state(struct max3100_port_s *s, int on) {

That brace should go in column 1.

 + unsigned long flags;
 +
 + spin_lock_irqsave(s-irq_lock, flags);
 + if (s-irq_status != on) {
 + if (on) {
 + enable_irq(s-irq);
 + }
 + else {
 + disable_irq(s-irq);
 + }

The `else' should be like this:

} else {

and as the brqaces are unneeded we'd prefer

if (on)
enable_irq(s-irq);
else
disable_irq(s-irq);

but checkpatch knows about this too.

 + s-irq_status = on;
 + }
 + spin_unlock_irqrestore(s-irq_lock, flags);
 +}
 +
 +
 +static int max3100_do_parity(struct max3100_port_s *s, u16 c)
 +{
 + int parity;
 + int i,n;
 +
 + if (s-parity  MAX3100_PARITY_ODD)
 + parity = 0;
 + else
 + parity = 1;
 + 
 + if (s-parity  MAX3100_7BIT)
 + n = 7;
 + else
 + n = 8;
 +
 + for(i=0;in;i++) {
 + parity = parity ^ ( (ci)  1);
 + }

Those three lines will cause a checkpatch frenzy.

 + return parity;
 +}
 +
 +static inline int max3100_check_parity(struct max3100_port_s *s, u16 c)
 +{
 + return max3100_do_parity(s, c) == ( (c9)  1);
 +}
 +
 +static inline void max3100_calc_parity(struct max3100_port_s *s, u16 *c)
 +{
 + *c =  ~MAX3100_PT;
 + *c |= max3100_do_parity(s, *c)8;
 +}
 +
 +
 +static void max3100_work(struct work_struct *w);
 +
 +static inline void max3100_dowork(struct max3100_port_s *s)
 +{
 + if (!s-force_end_work) {
 + PREPARE_WORK(s-work, max3100_work);
 + queue_work(s-workqueue, s-work);
 + }
 +}

You'd be surprised how small an inlined function can be and yet still be
too large to be inlined (if that sentence makes sense).

I'd suggest that you try removing inlines then recmpiling and doing `size
drivers/serial/max3100.o'.  You'll probably find that most of them are
either unneeded or plain wrong.

 +static int max3100_sr(struct max3100_port_s *s, u16 tx, u16 *rx, int push)
 +{
 + /* note: we suppose that the T bit fron conf_status is in sync
 +  * with the hw one, so all the communication must go through
 +  * this function */
 + 

Re: kernel panic - help!?

[Dave Young]

On Dec 12, 2007 5:17 PM, Oliver Falk [EMAIL PROTECTED] wrote:
 Can someone explain me that?

 Dec 12 00:24:15 santorini kernel: Unable to handle kernel NULL pointer
 dereference at virtual address 
 Dec 12 00:24:15 santorini kernel:  printing eip:
 Dec 12 00:24:15 santorini kernel: c0190182
 Dec 12 00:24:15 santorini kernel: *pde = 1b62b001
 Dec 12 00:24:15 santorini kernel: Oops:  [#1]
 Dec 12 00:24:15 santorini kernel: SMP
 Dec 12 00:24:15 santorini kernel: Modules linked in: mptctl mptbase sg
 md5 ipv6 i2c_dev i2c_core button battery ac uhci_hcd ehci_hcd hw_rand
 om tg3 bonding(U) floppy ata_piix libata dm_snapshot dm_zero dm_mirror
 ext3 jbd dm_mod cciss sd_mod scsi_mod
 Dec 12 00:24:15 santorini kernel: CPU:2
 Dec 12 00:24:15 santorini kernel: EIP:0060:[c0190182]Not
 tainted VLI
 Dec 12 00:24:15 santorini kernel: EFLAGS: 00010246   (2.6.9-55.0.9.ELsmp)
 Dec 12 00:24:15 santorini kernel: EIP is at sysfs_readdir+0x123/0x187
 Dec 12 00:24:15 santorini kernel: eax:    ebx: e1f04880   ecx:
    edx: 
 Dec 12 00:24:15 santorini kernel: esi: e1f04884   edi:    ebp:
 f6bf2144   esp: ec134f60
 Dec 12 00:24:15 santorini kernel: ds: 007b   es: 007b   ss: 0068
 Dec 12 00:24:15 santorini kernel: Process save (pid: 13931,
 threadinfo=ec134000 task=f59c12b0)
 Dec 12 00:24:15 santorini kernel: Stack:  f7e14e40 c016baf5
 ec134fa0 f2eb8180 c0332640 f2eb8180 f7c45438
 Dec 12 00:24:15 santorini kernel:c016baf5 c016b771 ec134fa0
 ffda 08304764 f2eb8180  c016bdab
 Dec 12 00:24:15 santorini kernel:083047cc 083047b4 0f98
 ffea 0009 08304764 b7fccff4 ec134000
 Dec 12 00:24:15 santorini kernel: Call Trace:
 Dec 12 00:24:15 santorini kernel:  [c016baf5] filldir64+0x0/0x11a
 Dec 12 00:24:15 santorini kernel:  [c016baf5] filldir64+0x0/0x11a
 Dec 12 00:24:15 santorini kernel:  [c016b771] vfs_readdir+0x7d/0xa5
 Dec 12 00:24:15 santorini kernel:  [c016bdab] sys_getdents64+0x80/0xba
 Dec 12 00:24:15 santorini kernel:  [c02d64db] syscall_call+0x7/0xb
 Dec 12 00:24:15 santorini kernel:  [c02d007b]
 unix_dgram_sendmsg+0x23c/0x45d
 Dec 12 00:24:16 santorini kernel: Code: 04 89 69 0c 8b 75 00 8b 44 24 04
 83 c0 0c 39 c6 74 73 8d 5e fc 83 7b 14 00 74 66 89 d8 e8 07 ec ff f
 f 89 c2 83 c9 ff 31 c0 89 d7 f2 ae f7 d1 49 0f b7 43 1c c1 e8 0c 50 ff
 73 20 8b 44 24 18 ff
 Dec 12 00:24:16 santorini kernel:  0Fatal exception: panic in 5 seconds
 --

Please tell the kernel version before post.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [crash] kernel BUG at drivers/cpufreq/cpufreq.c:1060!

[Ingo Molnar]

* Ingo Molnar [EMAIL PROTECTED] wrote:

 2.6.24-rc4-git5, got this cpufreq crash on x86 64-bit, during 'make 
 randconfig' random bootup testing:

hm, does not seem to be easily reproducible. I tried 10 bootups and 2 of 
them failed.

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: [RFT] Port 0x80 I/O speed

[Luciano Rocha]

On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
  Good day.
 
  Would some people on x86 (both 32 and 64) be kind enough to compile and run 
  the attached program? This is about testing how long I/O port access to port 
  0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting.
 

$ sudo ./port80
cycles: out 2729, in 1872
$ sudo ./port80
cycles: out 2729, in 1872
$ sudo ./port80
cycles: out 2711, in 1856
$ sudo ./port80
cycles: out 2711, in 1856

model name  : Intel(R) Pentium(R) 4 CPU 1.90GHz
stepping: 2
cpu MHz : 1917.229
cache size  : 256 KB

-- 
Luciano Rocha [EMAIL PROTECTED]
Eurotux Informática, S.A. http://www.eurotux.com/


pgpNPo6XbBfoE.pgp
Description: PGP signature

Re: 2.6.24-rc3-mm1

[Boaz Harrosh]

On Tue, Dec 11 2007 at 18:33 +0200, James Bottomley [EMAIL PROTECTED] wrote:
 On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
 OK, thanks.  I'll assume that James and Hannes have this in hand (or will
 have, by mid-week) and I won't do anything here.
 
 Just to confirm what I think I'm going to be doing:  rebasing the
 scsi-misc tree to remove this commit:
 
 commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
 Author: Hannes Reinecke [EMAIL PROTECTED]
 Date:   Tue Nov 6 09:23:40 2007 +0100
 
 [SCSI] Do not requeue requests if REQ_FAILFAST is set
 
 And its allied fix ups:
 
 commit 983289045faa96fba8841d3c51b98bb8623d9504
 Author: James Bottomley [EMAIL PROTECTED]
 Date:   Sat Nov 24 19:47:25 2007 +0200
 
 [SCSI] fix up REQ_FASTFAIL not to fail when state is QUIESCE
 
 commit 9dd15a13b332e9f5c8ee752b1ccd9b84cb5bdf17
 Author: James Bottomley [EMAIL PROTECTED]
 Date:   Sat Nov 24 19:55:53 2007 +0200
 
 [SCSI] fix domain validation to work again
 
 James
 

The problems caused by this patch where nagging me at the back of my head
from the begging. Why should we fail on a check of FAIL_FAST in all kind
of weird places like boots, when the only place that should ever set the 
flag should be one of the multi-path drivers. finally it struck me:

It might be a bug in ll_rw_blk at blk_rq_bio_prep() there is this:

static void blk_rq_bio_prep(struct request_queue *q, struct request *rq,
struct bio *bio)
{
/* first two bits are identical in rq-cmd_flags and bio-bi_rw */
rq-cmd_flags |= (bio-bi_rw  3);
...

Now this is no longer true and is a bug.
Second bit of bio-bi_rw defined in bio.h is:
#define BIO_RW_AHEAD1
but
Second bit of rq-cmd_flags is __REQ_FAILFAST

so maybe we are getting FAILFAST in the wrong places?

(I will look for an old patch I sent a year ago that fixes
this bug)

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

Re: [PATCH 1/1] : hwmon - new chip driver for TI ADS7828 A-D

[Andrew Morton]

On Mon, 03 Dec 2007 17:59:59 + Steve Hardy [EMAIL PROTECTED] wrote:

 Hi,
 
 Here is a patch against 2.6.23.9 which adds support for the 
 Burr-Brown/Texas-Instruments
 ADS7828 12-bit 8-channel A-D converter.
 
 The chip is used for voltage monitoring on the COTS processor card I am
 currently working with.
 
 The driver simply outputs the current input voltages (in mv as specified
 in the lm-sensors sysfs interface documentation).  Any scaling required for
 a specific board is handled by user-space.  Hopefully this makes the driver
 generic enough to be generally useful.
 
 The driver is basically a simple rehash of existing code - I used lm75 as
 the starting point, with some inspiration from other existing drivers.
 
 ...

 diff -uprN -X linux-2.6.23.9/Documentation/dontdiff 
 linux-2.6.23.9/drivers/hwmon/Kconfig 
 linux-2.6.23.9-ads7828/drivers/hwmon/Kconfig
 --- linux-2.6.23.9/drivers/hwmon/Kconfig2007-11-26 
 17:51:43.0 +
 +++ linux-2.6.23.9-ads7828/drivers/hwmon/Kconfig2007-11-28 

Your email client is wordwrapping the text and it replaces tabs with
spaces.  It will need a resend, please.

 @@ -530,6 +530,16 @@ config SENSORS_THMC50
This driver can also be built as a module.  If so, the module
will be called thmc50.
  
 +config SENSORS_ADS7828
 +tristate Texas Instruments ADS7828
 +depends on I2C  EXPERIMENTAL

I wouldn't bother with EXPERIMENTAL personally.  It seems a farily
pointless thing.

 linux-2.6.23.9-ads7828/drivers/hwmon/ads7828.c

Please prepare and test patches against the latest Linus tree, from git or
from ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots

Usually it's OK to develop a new driver against the latest stable release,
but we regularly change interfaces and if we did, this driver won't even
compile.

 +static int ads7828_attach_adapter(struct i2c_adapter *adapter);
 +static int ads7828_detect(struct i2c_adapter *adapter, int address, int 
 kind);
 +static void ads7828_init_client(struct i2c_client *client);
 +static int ads7828_detach_client(struct i2c_client *client);
 +static struct ads7828_data *ads7828_update_device(struct device *dev);
 +static u16 ads7828_read_value(struct i2c_client *client, u8 reg);

I do dislike all these forward declarations, but they're all needed here
give the order of the functions.  Maybe from my Pascal-on-pdp11 days..

 +/* This is the driver that will be inserted */
 +static struct i2c_driver ads7828_driver = {
 +.driver = {
 +.name = ads7828,
 +},
 +.id = I2C_DRIVERID_ADS7828,
 +.attach_adapter = ads7828_attach_adapter,
 +.detach_client = ads7828_detach_client,
 +};
 +
 +static ssize_t show_in(struct device *dev, struct device_attribute *da,
 +char *buf)
 +{
 +struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
 +struct ads7828_data *data = ads7828_update_device(dev);
 +/* Print value (in mv as specified in sysctl-interface 
 documentation) */
 +return sprintf(buf, %d\n, (data-adc_input[attr-index] *
 +ads7828_lsb_resol)/1000);
 +}
 +
 +#define in_reg(offset)\
 +static SENSOR_DEVICE_ATTR(in##offset##_input, S_IRUGO, show_in,\
 +NULL, offset);
 +
 +in_reg(0);
 +in_reg(1);
 +in_reg(2);
 +in_reg(3);
 +in_reg(4);
 +in_reg(5);
 +in_reg(6);
 +in_reg(7);
 +
 +static int ads7828_attach_adapter(struct i2c_adapter *adapter)
 +{
 +if (!(adapter-class  I2C_CLASS_HWMON))
 +return 0;

Can this happen?

 +return i2c_probe(adapter, addr_data, ads7828_detect);
 +}
 +
 +static struct attribute *ads7828_attributes[] = {
 +sensor_dev_attr_in0_input.dev_attr.attr,
 +sensor_dev_attr_in1_input.dev_attr.attr,
 +sensor_dev_attr_in2_input.dev_attr.attr,
 +sensor_dev_attr_in3_input.dev_attr.attr,
 +sensor_dev_attr_in4_input.dev_attr.attr,
 +sensor_dev_attr_in5_input.dev_attr.attr,
 +sensor_dev_attr_in6_input.dev_attr.attr,
 +sensor_dev_attr_in7_input.dev_attr.attr,
 +NULL
 +};
 +
 +static const struct attribute_group ads7828_group = {
 +.attrs = ads7828_attributes,
 +};
 +
 +/* This function is called by i2c_detect */
 +static int ads7828_detect(struct i2c_adapter *adapter, int address, int 
 kind)
 +{
 +struct i2c_client *new_client;
 +struct ads7828_data *data;
 +int err = 0, ch = 0;
 +const char *name = ;
 +u8 cmd;
 +u16 in_data;
 +
 +/* Check we have a valid client */
 +if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA |
 + I2C_FUNC_SMBUS_WORD_DATA))
 +goto exit;
 +
 +/* OK. For now, we presume we have a valid client. We now create the
 + client structure, even though we cannot fill it completely yet.
 + But it allows us to access ads7828_read_value. */
 +data = kmalloc(sizeof(struct ads7828_data), GFP_KERNEL);
 +if (!data)
 +err = -ENOMEM;
 +goto exit;
 +}
 +memset(data, 0, sizeof(struct ads7828_data));

Use kzalloc() above, remove the memset.

 +

Re: [RFT] Port 0x80 I/O speed

[Peter Zijlstra]

On Wed, 2007-12-12 at 00:31 +0100, Rene Herman wrote:
 Good day.
 
 Would some people on x86 (both 32 and 64) be kind enough to compile and run 
 the attached program? This is about testing how long I/O port access to port 
 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting.
 
 Posted a previous incarnation of this before, buried in the outb 0x80 thread 
 which had a serialising problem. This one should as far as I can see measure 
 the right thing though. Please yell if you disagree...
 
 For me, on a Duron 1300 (AMD756 chipset) I have a constant:
 
 [EMAIL PROTECTED]:~/src/port80$ su -c ./port80
 cycles: out 2400, in 2400
 
 and on a PII 400 (Intel 440BX chipset) a constant:
 
 [EMAIL PROTECTED]:~/src/port80$ su -c ./port80
 cycles: out 553, in 251
 
 Results are (mostly) independent of compiler optimisation, but testing with 
 an -O2 compile should be most useful. Thanks!

Since a lot of people reported timings for all the fancy new x86_64
hardware, I've not included those. Timings for my ancient machines still
in service:

$ gcc -o port80 -O2 port80.c
$ sudo ./port80
cycles: out 1736, in 1735
$ sudo ./port80
cycles: out 1831, in 1827
$ sudo ./port80
cycles: out 1735, in 1735
$ sudo ./port80
cycles: out 1743, in 1737
$ sudo ./port80
cycles: out 1737, in 1734

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 6
model name  : AMD Athlon(tm) MP 1800+
stepping: 2
cpu MHz : 1533.420
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow ts
bogomips: 3069.09
clflush size: 32

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 6
model name  : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 1533.420
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov   pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow ts
bogomips: 3067.07
clflush size: 32


---

# ./port80
cycles: out 812, in 354
# ./port80
cycles: out 811, in 354
# ./port80
cycles: out 811, in 354
# ./port80
cycles: out 811, in 354

# cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 1
cpu MHz : 672.071
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse
bogomips: 1331.20


---


# ./port80
cycles: out 116, in 47
# ./port80
cycles: out 116, in 47
# ./port80
cycles: out 116, in 47
# ./port80
cycles: out 116, in 47

# cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 5
model   : 2
model name  : Pentium 75 - 200
stepping: 12
cpu MHz : 99.476
fdiv_bug: no
hlt_bug : no
f00f_bug: yes
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr mce cx8
bogomips: 198.24


P133 clocked at 100MHz

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] Generic IRQ: Add unlocked version of set_irq_handler()

[Ingo Molnar]

* Kevin Hilman [EMAIL PROTECTED] wrote:

 Add unlocked version for use by irq_chip.set_type handlers which may 
 wish to change handler to level or edge handler when IRQ type is 
 changed.
 
 The normal set_irq_handler() call cannot be used because it tries to 
 take irq_desc.lock which is already held when the irq_chip.set_type 
 hook is called.

looks fine to me. Thomas?

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] sysctl : proc_dointvec_minmax() expects int values for min/max guard values

[Eric Dumazet]

min_sched_granularity_ns, max_sched_granularity_ns, min_wakeup_granularity_ns 
and max_wakeup_granularity_ns are declared unsigned long.

This is incorrect since proc_dointvec_minmax() expects plain int guard values.

This bug only triggers on big endian 64 bit arches.

Signed-off-by: Eric Dumazet [EMAIL PROTECTED]

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 8ac5171..707a26b 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -225,10 +225,10 @@ static struct ctl_table root_table[] = {
 };
 
 #ifdef CONFIG_SCHED_DEBUG
-static unsigned long min_sched_granularity_ns = 10;/* 100 
usecs */
-static unsigned long max_sched_granularity_ns = NSEC_PER_SEC;  /* 1 second */
-static unsigned long min_wakeup_granularity_ns;/* 0 
usecs */
-static unsigned long max_wakeup_granularity_ns = NSEC_PER_SEC; /* 1 second */
+static int min_sched_granularity_ns = 10;  /* 100 usecs */
+static int max_sched_granularity_ns = NSEC_PER_SEC;/* 1 second */
+static int min_wakeup_granularity_ns;  /* 0 usecs */
+static int max_wakeup_granularity_ns = NSEC_PER_SEC;   /* 1 second */
 #endif
 
 static struct ctl_table kern_table[] = {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Chris Rankin]

--- Andrew Morton [EMAIL PROTECTED] wrote:
 hm.  Could be some platform thing.  Strange.  It might be worth checking
 around that ioremap, make sure that the value which it returned is the one
 which is being used in the function-which-hangs, etc.

OK, not difficult to try. (This is x86, BTW.) But I'm still baffled as to 
precisely why it is
hanging. Is it waiting for a value from the PCI bus that never appears, or 
something? Are there
any other PCI-related tests that I can do to check that the device has been 
initialised correctly
on the bus, please?

 hostap_plx.c first appeared in 2.6.14.

OK, I can build one of those kernels. Before then, I think that hostap was 
provided as an external
source package.

Cheers,
Chris


  __
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

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

acpi -video_device_list corruption

[William Lee Irwin III]

The -cap fields of struct acpi_video_device and struct acpi_video_bus
are 1B each, not 4B. The oversized memset()'s corrupted the subsequent
list_head fields. This resulted in silent corruption without
CONFIG_DEBUG_LIST and BUG's with it. This patch uses sizeof() to pass
the proper bounds to the memset() calls and thereby correct the bugs.

Included as a MIME attachment is a compressed dmesg from an affected
system. The patch was seen to resolve the issue on the affected system.

vs. 2.6.24-rc5

Signed-off-by: William Irwin [EMAIL PROTECTED]


-- wli

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 44a0d9b..7895d57 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -577,7 +577,7 @@ static void acpi_video_device_find_cap(struct 
acpi_video_device *device)
struct acpi_video_device_brightness *br = NULL;
 
 
-   memset(device-cap, 0, 4);
+   memset(device-cap, 0, sizeof(struct acpi_video_device_cap));
 
if (ACPI_SUCCESS(acpi_get_handle(device-dev-handle, _ADR, 
h_dummy1))) {
device-cap._ADR = 1;
@@ -697,7 +697,7 @@ static void acpi_video_bus_find_cap(struct acpi_video_bus 
*video)
 {
acpi_handle h_dummy1;
 
-   memset(video-cap, 0, 4);
+   memset(video-cap, 0, sizeof(struct acpi_video_bus_cap));
if (ACPI_SUCCESS(acpi_get_handle(video-device-handle, _DOS, 
h_dummy1))) {
video-cap._DOS = 1;
}


dmesg.acpibug.gz
Description: dmesg.acpibug.gz

Re: 2.6.24-rc4-mm1: acpi reboots machine... solved

[Borislav Petkov]

On Tue, Dec 11, 2007 at 05:08:59PM -0700, Bjorn Helgaas wrote:
 On Tuesday 11 December 2007 01:52:55 pm Borislav Petkov wrote:
  From what i can roughly tell so far it seems like an resource conflict 
  between acpi and
  the pnp requested regions in your patch which result in the acpi_thermal 
  code
  to read the wrong (0xff) temperature value and halt the machine, but i 
  might be
  wrong on the details since acpi is such a big code chunk to swallow.
 
 I don't see any obvious conflict from the log you posted.  For the sake
 of comparison, can you post the corresponding dmesg log after you removed
 the patch?

The only difference i see is that ACPI finds EC in DSDT in the working kernel
and in the broken case something silently fails. Please find attached the 2 
bootlogs
and a disassembled DSDT.

-- 
Regards/Gruß,
Boris.
BZh91AYSYµÜ¬t$Øÿ¬ý´€ÿÿÿïÿþÿÿÿô

`/?
* P¨ P
 IMˆÓS4CÔjz‰€Òz©ˆi“F! Ð
hۈ
 4

4È4i
£@4 
¦™24dÁ
ˆ€€Ð44Ó [EMAIL PROTECTED] 
1pЀšd4Èѓ ¤ˆ
 Ñ ši 
ÄLš˜Èɪaè„ÚM©ý_åÿ/;ý÷b°[$‰íĖTGµýD{žÞ¥ó¢DÍJe‚—Kñ.¢…(¼«%Id¥”)E…D¢Soúí|ÏõW©?ӝmŸ
ªY.ë]ò±âÓNÃb667ÿÏ՞æÁnTÿ£¿­†ªÍÁ¬ÕÛu¯]¼ßsFXÓý3Õ}2F
h–b­l˜¾¦—nZÓoSz·cËG×ÿwØÖº²u²¦»®¬äъŸãEFtõ
9m’òS®ÙÃv6“4¾s¬™+0Ee£jçIJB[EMAIL PROTECTED]|Ywv]ÑòZÏ%r£[’øîV;1`¤÷`
Ôő£†¡Z’AµL¼tÖ/‹TàJÒómo~ÿsVܹ62¾5ÉJR”¥9ª×\Þk`RcPñEë0ç“8ÙĹ«DÅ0_$[õ¯’†[qrÔú5kõ?ي©Íµ8¯»©¬Á€)†}úhíoùuŠt8pÍuï}ø·7¶,ÔÁþ»2dÉ©’Ì,Á‚Ì,Áêu²›.¦Öo¯Z„f¤ƒò½ÎÉë})îm~F[6QO­çl8µ¿âõop
ÌVOü¾Å½()RO枕…çËÝêf÷#½Ôï{éÁírdþ˜Îú¬}
ËWÈñtN‚ŒƒÜ§½F;ýM‰³µ±ä»HžãcÌÛ2nS”ÍíYþ+5?Åõº^嚟Þâ›Wt³:mmCñfYw½wZë6Tجn¨Œb*#oŠ¢nÉÿ?ðÎÎՆOå€üôcæO2ëÝ.º÷K­u]]ÖÂêR”¥6Óå–ZÓ.45e³d¥)(¥(¥)4ù™¹°k{\
}¸²pGþ”Ñü”ý·©%Ɂ{UÔpkÂÌ͋Ê5¬Å‚Ÿ8Ÿ£d©ÂNÓlm´ø…,5r5K¦‘HÖc¢}ö͋Ջä^}2«¶,iänqb]’—“%œ[¿*Ê}oÁ±¹îuîöñàv©ý…QââÍϽ\_©ÔÔû®§µòÙ݊ØÊît¬žå:‹©÷t*ñ²¡ëgccðYéM®3Ž§ñ}~—3btV¯CQµì-çûٛ®
]9üºŸcrŒòM^I~·
Œð{ÎÆÆÆ-+ÝïþmŒ_‹çÅçäâüTÍyãö1qw=ß{’q}/™i½ñwö¬ìbíì{u©O”p~–
Ôö2?\ÙGÖòx®z(åäˆ(Hi#
ÎAäÃê4,8´©‡Tœc4Ñ\΃éY¡Jlfø5Fì[öeècã’xsüמ
ܧkÇ):ÔjZÉù^ÏÎ×kÉå„ÉS±ú.ó6¬ØÉâÜɓaN.—7ëÁÙ«}Uí-
¢Ö´ªµ­UlÚښ”îyùúð™©ÉO%Æ¥Êt=ë›ÛÊ*QE)¥žµ
j=)îqw;
ýژ¦-é_²èâ§4×çvGSþ}š’.ÖÐðt1]Óû)wÔÍظ’›™»ZΆGçhÞ÷µÌNwhþK[#cïXkÎÈ䍋)¿¥iœæ‡ƒ¡ç{[žw˖çs{¥ä‹hÔ±=§[ßfº5½nµ§^cµÖ¾Å*›Š'LŠGûnX{Ý.k¦òž‡¿“åtíkvøõéÚÚónøIÓ¥,Ÿô§¡OG›wƒõ6º•SÎîdš¬·’×ã0ö˜0Qñp`èt:Td啽޾ž^‘¢ÌÜÔÝ/³›6ÔS‹âõ§½­sDâé-‚CÔwàɌ™z]šØºÞš[SÁ©Þë[ÈÚôxIɓçí֝¤fbè~Vsà²ÍN—ÊûW{\»¹ûŸ¸ñàÚêx¼ýªvbo^IÈt5¬ìôÉNk,êw:Û3yÑèõ¬Os[ɛ¥=«6¾³'ï{ŸÕ—­ƒÐÀÖ¨z©ÚÙ±ßÝÂêIâÅ»D”ó,ؕ’cÂYŠíىJl2RhŒq´#NS¶13â½Hö‘ŒëíÒûKI:›5éD÷)™ò1æìß2ß{µ)ÐìæäÅOpܺ3ˆÚúލ®—Gêkb¿{{]؟à©òDZÒäÖéfðu2™

ô”º–7½ªŸ‘Ç¿’ӯ̻àÅì­¿~Œ¬\šÔä°ít*IðQÇG5–Y‹ÑµÜ׸ð~GkTاsŒíъ(´¸NL%½H·adHâpè—`—GÄ0ȧ%OcgçðÁɚYDïiCv»mÎ՟nƒM±L
ª•„aE70jV8–À¨º2G™IÛ±8(ÉÜý\ýz›[^–/ý¹CÐ~té
G Ñ•¥¥x˜nO‹ý—÷+¼ËAR46ž·µò?S[EMAIL 
PROTECTED]iƒGˆ|¿—skcoÔõŽOÜçewü-ñ«|Ú¾Öo·|³­§qÅÔë5¹¦¦îÕUl56¬Áۚë÷5}Á-—Û¤öïÔíÑK:L}X­K´[àÔècí|ÌýmO°WÖ¥)e)c{,Ö}s[Û«Ãé¯:Î3÷¾§ÒR¥?ÓrÓС²†µŸ÷X}jû”sp–z”šéOž‡Ê¯Êö,§ØÒêiñ;6|_r–S±g“/¼¸5¿
šÕ0~:\ô©¹îqg6?k¿¹ïd³¥ÒWÛ«S¡²´³ìŽ·™JQÀÚÔÍÖæÖ]øþŽ§˜=.Ísö”s}Kèx½ÈÞü†NõÖdðzØ:[Íàâýj\ÉNá­Í Ã/³ÆæáϚΣ.¡°šó.
‹½ñlö,·¥FçBh§üz]Ò
¬æè±Õ¯­Í›au×džõ!Ò±g½eÙýX¶kԚ«Z~¤§Êá{O¹í{‚äù,žg8Ø}8¹:ΗÐKÿɝHÕ®ºÈðG“sÉI©§öÝÀô¹O¿Þ³öÙ§êaeL66bÃ6ÕûW~§ß?ìðØÎ
JG£äèÙl˜27½f
ËoV
Šµì|Œ¬.¡IK1²ï‰k).ÁUKK,]0`³Æ¦/M2fC,èÑZ|,£VÍWfj¢S½k?õ0Òý^…ÞHêsØ¿ÁéS¿T  
`Œ´‰¦ƒÑ’F9âÂҌ„MX4PG%¿Îlõ¤Æ'ƒó`ì%.ŒIlÝ0Ne;jH‰Ü¯e»TôTòWoô{c%ÕONëþΦ,•ÎÖ´ÉûYCú¿äᣃo‚íìSÎÓf«òv5è©ÉÎϕ¯E9ª¦f첩³[ÿ¯ØÔÅ¥?£ýRÍn$Ô¹8¼_BíÇëy.Ü»7­ÔÄó»,{Öè]ïœØ¹)
  ΉnqRÃÅe”¨Éš®õ)““k+55/vµ)cKR´i„ fîôÝ·ó°{»®kZµö:juœZ˜¬Y‰w‹‡6NŸ
R”¥)_'þ50) 
âðN#­ªÍk)ÖàÅg6¦n,Y¿¦n¦²`ÐE:‚Íjc·fL)uš[ŠÓS{«%Ôa|ð;—ARAlŒî.,•šJÁNuYuc’ªksp^r1’fÿõv‹jkt,³›;³íZs¦æöÄÁ,;—éfšóg7ó]fݘ´˜[üU$Å1RÝ*lpMZaÕ¯RjtNÈmi=Jß*éŠ;YJVæ(7Bv­'k)=/èì¥õ6¹µ:–uЛ]92v[×ûº…(£S%ßÄ£R”¥)JR”’Ä©éRꔊR”¥)E(¥:¾•›“ÉXªê-T¥J”«Œ·¾,ŸÝ”MªLGð.}Müxãè}O;zQŽî3àæô´}N–“‹[•̲¬‹¦­QN:¤Àä‹5ý–

*Ëõ#éRüíeI²ž2Ý_'ú¦Ç©ñfõ´llãF¶-`o+væÕô£­LkO‹­–Ù–YR²`»Ö°Ò†Ë-®òÏ¥“65–(Ã]ZôÍf­ê˜Yu™¼¬o¥`³5³`ÁžMºŽŽO.µ›m.ÓÎàžÆ_þURiçW½ßJQT६V¬—T‹±OàùŸ:Ë3ån.8‚ǼSDø,Üìo]îPÂ^¶#՝öðΗpV·šìuͳäRmÖ,ɹF

WuÒ¦Ó¼O¿ƒ
G]ÝJNõ#ÂÇ­äKçЮL\ï3ëW5~‚±p’ÚjpF£qټٯtüìYáO3®íž5Œ^š›ØßL691Ã6O'U)J£Z–±\d˜©¬õ®¦öLV`äØôåÑÄË_“wx±àù©›ì×éfÍ:läø·¶åèmfà¦ç lYƑ†ãкö}íí•¯½©5*œ§²ìYj»Øó6á8¼—^—Tóêéfï3¿ß½æy5®Jq'IÉv…²]¬Í£kËc–T©K÷¯èd³¦¥f‚ãü‹ù.Ŗz×X™c…F¦Œ›^fŒš”Wr:Q߄sÆnÏ%ܔÁNo‚~vKƒæYü¼†½ÖqoÏr°_÷ð귅G™²ÍêkÖ¹©FJëx’™ô»Ç5”˜MZ[W‡±f³ÂÊ`ñX蝘cž6TèÃ'‹UئØÅ°§ñY­“{co'yÞ`mgMÖÔÚúò~õ[Z­gr÷hS{](lK»p5úUyŸS‹µÚ»^Y¶1Ý]–µÛ˜°mYCŽZ_^“k3›¥“םìäkiÀŸ6[”œØ·¯Ãš3ÔÉ]

¿K‘8²uÔÕ¾¦î=ÖjΘ襜µÖÎJiÔÃÿßÁw,iשvi±´Õùse–EÊd|ÞíYž¹›Z™iý-Ö3t)Ö6â±£'Ê×ÔÅNÕÚúY“Gæ¶Æ
µëpÕ¤Êe»RÇL—ilO‹™¶6¿ƒFÙ¤¹;¼)‰)ýŠhLVrmÎLÕà¶m¬ÌÛÖm7mÏ
Wm_kF9V¤ÓsvK¶³¥xí|‰ŸÔùwÖÑÝ{—áÉG%ÜüOÚýêÔüYÑOÀR`Ÿ™J(џáÀž34z¯R¨ü_­±2obÂ4TYY”Ý]YY£Fx©Ñ±ÁöӉØý­Z¥¯d¬™­üÆ2{¬ŒYtø¿Éø»ÍEJk]ҋjáëöê½ï{_š9,»+^ªRë»Û”‰7ºX`¥4iTÑ£s4ûḳ6lÚ4F©Ðê]±ýlãmm­Y#š^¹¸¬jWƒ½±±ÁÁkængfŽMâÀØñÜÞW

Re: [4/4] DST: Algorithms used in distributed storage.

[Dmitry Monakhov]

On 14:47 Mon 10 Dec , Evgeniy Polyakov wrote:
 
 Algorithms used in distributed storage.
 Mirror and linear mapping code.
Hi, i've finally take a look on your DST solution.
It seems what your current implementation will not work on nonstandard
devices for example software raid0.
other comments are follows:
 
 Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
 
 
 diff --git a/drivers/block/dst/alg_linear.c b/drivers/block/dst/alg_linear.c
 new file mode 100644
 index 000..9dc0976
 --- /dev/null
 +++ b/drivers/block/dst/alg_linear.c
 @@ -0,0 +1,105 @@
 +/*
 + * 2007+ Copyright (c) Evgeniy Polyakov [EMAIL PROTECTED]
 + * All rights reserved.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include linux/module.h
 +#include linux/kernel.h
 +#include linux/init.h
 +#include linux/dst.h
 +
 +static struct dst_alg *alg_linear;
 +
 +/*
 + * This callback is invoked when node is removed from storage.
 + */
 +static void dst_linear_del_node(struct dst_node *n)
 +{
 +}
 +
 +/*
 + * This callback is invoked when node is added to storage.
 + */
 +static int dst_linear_add_node(struct dst_node *n)
 +{
 + struct dst_storage *st = n-st;
 +
 + dprintk(%s: disk_size: %llu, node_size: %llu.\n,
 + __func__, st-disk_size, n-size);
 +
 + mutex_lock(st-tree_lock);
 + n-start = st-disk_size;
 + st-disk_size += n-size;
 + set_capacity(st-disk, st-disk_size);
 + mutex_unlock(st-tree_lock);
 +
 + return 0;
 +}
 +
 +static int dst_linear_remap(struct dst_request *req)
 +{
 + int err;
 +
 + if (req-node-bdev) {
 + generic_make_request(req-bio);
 + return 0;
 + }
 +
 + err = kst_check_permissions(req-state, req-bio);
 + if (err)
 + return err;
 +
 + return req-state-ops-push(req);
 +}
 +
 +/*
 + * Failover callback - it is invoked each time error happens during
 + * request processing.
 + */
 +static int dst_linear_error(struct kst_state *st, int err)
 +{
 + if (err)
 + set_bit(DST_NODE_FROZEN, st-node-flags);
 + else
 + clear_bit(DST_NODE_FROZEN, st-node-flags);
 + return 0;
 +}
 +
 +static struct dst_alg_ops alg_linear_ops = {
 + .remap  = dst_linear_remap,
 + .add_node   = dst_linear_add_node,
 + .del_node   = dst_linear_del_node,
 + .error  = dst_linear_error,
 + .owner  = THIS_MODULE,
 +};
 +
 +static int __devinit alg_linear_init(void)
 +{
 + alg_linear = dst_alloc_alg(alg_linear, alg_linear_ops);
 + if (!alg_linear)
 + return -ENOMEM;
 +
 + return 0;
 +}
 +
 +static void __devexit alg_linear_exit(void)
 +{
 + dst_remove_alg(alg_linear);
 +}
 +
 +module_init(alg_linear_init);
 +module_exit(alg_linear_exit);
 +
 +MODULE_LICENSE(GPL);
 +MODULE_AUTHOR(Evgeniy Polyakov [EMAIL PROTECTED]);
 +MODULE_DESCRIPTION(Linear distributed algorithm.);
 diff --git a/drivers/block/dst/alg_mirror.c b/drivers/block/dst/alg_mirror.c
 new file mode 100644
 index 000..3c457ff
 --- /dev/null
 +++ b/drivers/block/dst/alg_mirror.c
 @@ -0,0 +1,1128 @@
 +/*
 + * 2007+ Copyright (c) Evgeniy Polyakov [EMAIL PROTECTED]
 + * All rights reserved.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include linux/module.h
 +#include linux/kernel.h
 +#include linux/init.h
 +#include linux/poll.h
 +#include linux/dst.h
 +
 +struct dst_mirror_node_data
 +{
 + u64 age;
 +};
 +
 +struct dst_mirror_priv
 +{
 + unsigned intchunk_num;
 +
 + u64 last_start;
 +
 + spinlock_t  backlog_lock;
 + struct list_headbacklog_list;
 +
 + struct dst_mirror_node_data old_data, new_data;
 +
 + unsigned long   *chunk;
 +};
 +
 +static struct dst_alg *alg_mirror;
 +static struct bio_set *dst_mirror_bio_set;
 +
 +static int dst_mirror_resync(struct dst_node *n, int ndp);
 +
 +static void dst_mirror_mark_sync(struct dst_node *n)
 +{
 + if (test_bit(DST_NODE_NOTSYNC, n-flags)) {
 + 

Re: [2.6.23.9] hostap_plx locks up PC when reading PCI I/O memory

[Andrew Morton]

On Wed, 12 Dec 2007 08:56:44 + (GMT) Chris Rankin [EMAIL PROTECTED] wrote:

 --- Andrew Morton [EMAIL PROTECTED] wrote:
  It might be interesting to see what value of `i' is causing it to fall over.
 
 I tried unrolling the loop, but a single byte read for i = 0 is enough to 
 lock things up.

hm.  Could be some platform thing.  Strange.  It might be worth checking
around that ioremap, make sure that the value which it returned is the one
which is being used in the function-which-hangs, etc.


  Did any earlier version of the 2.6 kernel work OK?
 
 Unfortunately, I don't know. I swapped this card out of the old 2.4.x machine 
 into a machine
 already running Fedora 7. The card works when I put it back into the 2.4 
 machine too, so it's not
 a hardware problem with the card.
 
 So I suppose the next step would be trying a linux 2.6.0 kernel? Or was 
 hostap included in the
 kernel later than that?

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

Re: [2.6 patch] kernel/timer.c section fixes

[Ingo Molnar]

* Adrian Bunk [EMAIL PROTECTED] wrote:

 This patch fixes the following section mismatches with 
 CONFIG_HOTPLUG=n, CONFIG_HOTPLUG_CPU=y:

thanks, applied.

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

Re: [PATCH] Add Documentation for FAIR_USER_SCHED sysfs files

[Ingo Molnar]

* Ingo Molnar [EMAIL PROTECTED] wrote:

 
 * Dhaval Giani [EMAIL PROTECTED] wrote:
 
   Hm, how about describing the units here?  Can you put 10 in each 
   file and everyone will get the same share?  100?  1?  1024 seems 
   like an odd share number.  Unless there is some other document you 
   wish to refer people to do help describe these values?
  
  It is proportional. That is, if two users have same value for shares, 
  they will get equal bandwidth on the CPU. If they are in the ratio 
  1:2, then they will share it in that ratio. I've updated the patch for 
  this. Hope it is clearer.
 
 thanks, applied.

unless Greg wants to push this via the sysfs git tree?

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: [4/4] DST: Algorithms used in distributed storage.

[Evgeniy Polyakov]

On Wed, Dec 12, 2007 at 12:12:47PM +0300, Dmitry Monakhov ([EMAIL PROTECTED]) 
wrote:
 On 14:47 Mon 10 Dec , Evgeniy Polyakov wrote:
  
  Algorithms used in distributed storage.
  Mirror and linear mapping code.
 Hi, i've finally take a look on your DST solution.
 It seems what your current implementation will not work on nonstandard
 devices for example software raid0.
 other comments are follows:

  +static int dst_mirror_process_node_data(struct dst_node *n,
  +   struct dst_mirror_node_data *ndata, int op)

  +
  +   kunmap(cmp-page);
  MINOR_BUG:
You has forgot to unmap page on error path, so IMHO it is better to move
kunmap to err_out_free_cmp label.

Yep, I will fix this.

  +   priv = kzalloc(sizeof(struct dst_mirror_priv), GFP_KERNEL);
  +   if (!priv)
  +   return -ENOMEM;
  +
  +   priv-chunk_num = st-disk_size;
  +
  +   priv-chunk = vmalloc(DIV_ROUND_UP(priv-chunk_num, BITS_PER_LONG) * 
  sizeof(long));
  Ohhh. My. I want to add my 500G hdd. Do you really wanna
say what i have to store 128Mb in memory object for this.

Right now yes. There was a code which used single bit for bigger
data units, but I dropped it because of resync troubles (i.e. when
one single sector has been updated, it requires to resync the whole
block). I can not say which case is better though.

  +   dprintk(%s: start: %llu, size: %llu/%u, bio: %p, req: %p, 
  +   node: %p.\n,
  +   __func__, req-start, req-size, nr_pages, bio,
  +   req, req-node);
  +
  +   err = n-st-queue-make_request_fn(n-st-queue, bio);
  Why direct make_request_fn instead of generic_make_request?

generic_make_request() will queue the bio in this case,
so I call request_fn directly.

  +   for (i = 0; i  DIV_ROUND_UP(priv-chunk_num, BITS_PER_LONG); ++i) {
  +   int bit, num, start;
  +   unsigned long word = priv-chunk[i];
  +
  +   if (!word)
  +   continue;
  +
  +   num = 0;
  +   start = -1;
  +   while (word  num  BITS_PER_LONG) {
  +   bit = __ffs(word);
  +   if (start == -1)
  +   start = bit;
  +   num++;
  MINOR_BUG: Seems you have misstyped here. AFAIU @num represent position
of last non zero bit (start + num == last_non_zero_bit_pos)
   if (start == -1) {
   start = bit;
   num = 1;
   } else
 num += bit;

Yes, you are right of course.
Since I shift word to more than a single bit, @num has to be update
accordingly.

  +   word = (bit+1);

Dmitry, thanks a lot for comments, I will fix issues you pointed in the
next release, although will stay bitmap case opened for a while.

-- 
Evgeniy Polyakov
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [crash] kernel BUG at drivers/cpufreq/cpufreq.c:1060!

[Alexey Dobriyan]

On 12/12/07, Ingo Molnar [EMAIL PROTECTED] wrote:

 2.6.24-rc4-git5, got this cpufreq crash on x86 64-bit, during 'make
 randconfig' random bootup testing:

Ingo, since you already scripted this, maybe you can add
modprobe everything/rmmod everything test after successful bootup.
It will catch amazing amount of stuff, I promise.

Ditto for modprobe/rmmod/modprobe and modprobe/rmmod/cat /proc,
cat /sys smoke tests.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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.24-rc4: bluetooth device gone after suspend to ram

[Soeren Sonnenburg]

Dear all,

I noticed that on my macbook pro1,1 the bluetooth device is gone after
suspend to ram, i.e.

/usr/sbin/hciconfig -a

normally lists hci0:Type: USB ...

but after suspend does nothing.

Here it does not help to remove the modules and to reload them. Also the
driver reloads without giving any error msg, but still nothing. As
others on mactel-users had the same problem (on mac mini/mbp2,2) it may
be worth investigating:

relevant dmesg:

Bluetooth: Core ver 2.11
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.9
Bluetooth: L2CAP socket layer initialized
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.8
Bluetooth: HCI USB driver ver 2.9

Any ideas?
Soeren
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] apm_event{,info}_t are userspace types.

[Andrew Morton]

On Fri, 30 Nov 2007 15:02:43 -0500 Adam Jackson [EMAIL PROTECTED] wrote:

 These types define the size of data read from /dev/apm_bios.  They
 should not be hidden behind #ifdef __KERNEL__.

Missing info: what are the consequences of this fix?  What id broken when
it it not applied?


 ---
  include/linux/apm_bios.h |6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)

Please include Signed-off-by:, as per Documentation/SubmittingPatches,
thanks.

 diff --git a/include/linux/apm_bios.h b/include/linux/apm_bios.h
 index 9754baa..01a6244 100644
 --- a/include/linux/apm_bios.h
 +++ b/include/linux/apm_bios.h
 @@ -18,6 +18,9 @@
  
  #include linux/types.h
  
 +typedef unsigned short   apm_event_t;
 +typedef unsigned short   apm_eventinfo_t;
 +
  struct apm_bios_info {
   __u16   version;
   __u16   cseg;
 @@ -32,9 +35,6 @@ struct apm_bios_info {
  
  #ifdef __KERNEL__
  
 -typedef unsigned short   apm_event_t;
 -typedef unsigned short   apm_eventinfo_t;
 -
  #define APM_CS   (GDT_ENTRY_APMBIOS_BASE * 8)
  #define APM_CS_16(APM_CS + 8)
  #define APM_DS   (APM_CS_16 + 8)

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

Re: [PATCH 00/47] CRIS patches for CRISv32 EtraxFS and ARTPEC-3

[Andrew Morton]

On Thu, 29 Nov 2007 17:02:22 +0100 Jesper Nilsson [EMAIL PROTECTED] wrote:

 Hi,
 
 This patchset contains the differences to add support for the EtraxFS and
 ARTPEC-3 CPUs, both of the CRISv32 family.  Both chips can now be compiled
 with minimal configs.
 
 To compile you'll need the Axis gcc cross port for CRISv32, it is mentioned
 in http://marc.info/?l=linux-kernelm=119337976126184w=2 how to get this.
 
 Still missing to allow full compile is include/linux/mtd/mtdram.h,
 see http://marc.info/?l=linux-kernelm=119373777301863w=2
 
 This is step two in syncing the Axis internal changes with mainline Linux,
 with the final goal being getting the CRIS port to the same level as
 the rest of the kernel.
 
 I've tried to remove as much checkpatch warnings and errors as possible,
 but some remain, mostly (I think you'll agree) spurious warnings,
 although there's also a bunch of generated files which don't conform,
 but I hope to fix this at the source later on.
 
 I realise this is a hefty chunk of code to review, but any suggestions
 on improvements are thankfully received.
 
 The changes are also available in the export2 branch at
 
 git://www.jni.nu/axis.git
 

I don't think there's much point in me merging these.  Please ask Linus to
pull that tree once the 2.6.25 merge window opens.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: broken dpt_i2o in 2.6.23 (was: ext2 check page: bad entry in directory) (fwd)

[Anders Henke]

Hi,

I'd like to let you now that my boxes are running a 32-bit kernel, so
the 64-bit-uncleanliness shouldn't apply to my boxes; however,

http://www.miquels.cistron.nl/linux/dpt_i2o-64bit-2.6.23.patch

fixed the issue on my testbox.

I took a clean 2.6.23, applied patch, recompiled the kernel, reboot: works.



Regards,

Anders

PS: Sorry for breaking the threading, I'm not a regular subscriber to
linux-kernel and haven't received Miguel's message by mail.
-- 
11 Internet AG  System Design
Brauerstrasse 48 v://49.721.91374.50
D-76135 Karlsruhef://49.721.91374.225

Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger,
Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Norbert Lang, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT] Port 0x80 I/O speed

[Dave Haywood]

Rene Herman wrote:
 Good day.

 Would some people on x86 (both 32 and 64) be kind enough to compile
 and run the attached program? This is about testing how long I/O port
 access to port 0x80 takes. It measures in CPU cycles so CPU speed is
 crucial in reporting.

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 6
cpu MHz : 930.347
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 mmx fxsr sse
bogomips: 1861.99
clflush size: 32

cycles: out 1183, in 706

cycles: out 1183, in 707

cycles: out 1182, in 706

cycles: out 1182, in 706

cycles: out 1183, in 706

cycles: out 1182, in 706

cycles: out 1182, in 706

cycles: out 1183, in 706

cycles: out 1183, in 707

cycles: out 1183, in 707

cycles: out 1183, in 706

cycles: out 1183, in 706

cycles: out 1183, in 706

cycles: out 1182, in 706

cycles: out 1183, in 707

cycles: out 1183, in 707

cycles: out 1183, in 706

cycles: out 1183, in 706

cycles: out 1182, in 706

cycles: out 1183, in 706

cycles: out 1183, in 706

cycles: out 1183, in 706

Dave.


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

Re: [PATCH] sysctl : proc_dointvec_minmax() expects int values for min/max guard values

[Ingo Molnar]

* Eric Dumazet [EMAIL PROTECTED] wrote:

 min_sched_granularity_ns, max_sched_granularity_ns, 
 min_wakeup_granularity_ns and max_wakeup_granularity_ns are declared 
 unsigned long.
 
 This is incorrect since proc_dointvec_minmax() expects plain int 
 guard values.
 
 This bug only triggers on big endian 64 bit arches.

thanks, applied it to the 2.6.24 fixes queue.

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: [crash] kernel BUG at drivers/cpufreq/cpufreq.c:1060!

[Ingo Molnar]

* Alexey Dobriyan [EMAIL PROTECTED] wrote:

 On 12/12/07, Ingo Molnar [EMAIL PROTECTED] wrote:
 
  2.6.24-rc4-git5, got this cpufreq crash on x86 64-bit, during 'make
  randconfig' random bootup testing:
 
 Ingo, since you already scripted this, maybe you can add modprobe 
 everything/rmmod everything test after successful bootup. It will 
 catch amazing amount of stuff, I promise.

something close to that is one of my standard tests: booting up an 
allyesconfig kernel.

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: 2.6.24-rc5 videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!

[Soeren Sonnenburg]

On Wed, 2007-12-12 at 00:20 -0500, Shane wrote:
 In 2.6.24-rc5+, I hit this problem with videobuf_read_start
 not being exported. Patch attached, only compile tested.
 
   CHK include/linux/version.h
   CHK include/linux/utsrelease.h
   CALLscripts/checksyscalls.sh
   CHK include/linux/compile.h
   CC [M]  drivers/media/video/videobuf-core.o
   Building modules, stage 2.
 Kernel: arch/x86/boot/bzImage is ready  (#1)
   MODPOST 202 modules
 ERROR: videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!
 make[1]: *** [__modpost] Error 1
 make: *** [modules] Error 2

FWIW, I've seen the same thing and Shane's patch fixes things for me.

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

Re: 2.6.24-rc4-mm1: acpi reboots machine... solved

[Alexey Starikovskiy]

Borislav Petkov wrote:

On Tue, Dec 11, 2007 at 05:08:59PM -0700, Bjorn Helgaas wrote:
  

On Tuesday 11 December 2007 01:52:55 pm Borislav Petkov wrote:


From what i can roughly tell so far it seems like an resource conflict between 
acpi and
the pnp requested regions in your patch which result in the acpi_thermal code
to read the wrong (0xff) temperature value and halt the machine, but i might be
wrong on the details since acpi is such a big code chunk to swallow.
  

I don't see any obvious conflict from the log you posted.  For the sake
of comparison, can you post the corresponding dmesg log after you removed
the patch?



The only difference i see is that ACPI finds EC in DSDT in the working kernel
and in the broken case something silently fails. Please find attached the 2 
bootlogs
and a disassembled DSDT.

  

This seems to be the start of trouble...
   PCI: Cannot allocate resource region 4 of device :00:1f.3

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

Re: [PATCH] scheduler: fix x86 regression in native_sched_clock

[Ingo Molnar]

* Nick Piggin [EMAIL PROTECTED] wrote:

  the scariest bit is the adding of cpu_clock() to kernel/printk.c so 
  late in the game, and the anti-recursion code i did there. Maybe 
  because this only affects CONFIG_PRINTK_TIME we could try it even 
  for v2.6.24.
 
 Printk recursion I guess shouldn't happen, but if there is a bug 
 somewhere in eg. the scheduler locking, then it may trigger, right?

or we just crash somewhere. It's all about risk management - printk is 
crutial, and with more complex codepaths being touched in printk it 
might make sense to just add built-in recursion protection into printk 
via my patch.

 Probably pretty rare case, however it would be nice to be able to find 
 out where the recursion comes from? Can you put an instruction pointer 
 in the recursion message perhaps?

yeah, as i mentioned if this would be occuring in practice we can always 
save the stacktrace of the incident and output that. I opted for the 
simplest approach first. Thanks for your Reviewed-by, i've queued it up 
for 2.6.25.

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/

[GIT PATCHES] V4L/DVB fix

[Mauro Carvalho Chehab]

Linus,

Please pull from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git 
master

For the following:

   - Re-adds lock safe videobuf_read_start

Cheers,
Mauro.

---

 drivers/media/video/videobuf-core.c |   14 +-
 1 files changed, 13 insertions(+), 1 deletions(-)

Mauro Carvalho Chehab (1):
  V4L/DVB (6609): Re-adds lock safe videobuf_read_start

---
V4L/DVB development is hosted at http://linuxtv.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.24-rc5 videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!

[Mauro Carvalho Chehab]

Em Qua, 2007-12-12 às 00:20 -0500, Shane escreveu:
 In 2.6.24-rc5+, I hit this problem with videobuf_read_start
 not being exported. Patch attached, only compile tested.
 
   CHK include/linux/version.h
   CHK include/linux/utsrelease.h
   CALLscripts/checksyscalls.sh
   CHK include/linux/compile.h
   CC [M]  drivers/media/video/videobuf-core.o
   Building modules, stage 2.
 Kernel: arch/x86/boot/bzImage is ready  (#1)
   MODPOST 202 modules
 ERROR: videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!
 make[1]: *** [__modpost] Error 1
 make: *** [modules] Error 2
Thanks for reporting.

The patch is incomplete. I've just sent Linus the complete fix for this.

The issue here is that videobuf_read_start were replaced by
__videobuf_read_start, but mutex is missing at the last.

The patch I've just sent adds a mutex-safe version of
videobuf_read_start, adding the proper EXPORT_SYMBOL_GPL().
 
Cheers,
Mauro

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

Re: 2.6.24-rc5 videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!

[Mauro Carvalho Chehab]

 Any objections against a later path that changes the exports to the 
 general immediately after the function convention?

No objections. Please generate against devel branch on my -git, since
I did a patch fixing most CodingStyle issues reported by checkpatch.pl.

Several files under /media still uses the old convention of having such
things at the end of the file.

 It would have avoided at least two such bugs in this file alone since 
 2.6.23...

I'm afraid that this wouldn't avoid this bug, however. 

The removal of the EXPORT_SYMBOL_GPL seemed to be the intention of
Brandon, since he renamed the function, removing the locks. I think he
didn't noticed that videobuf_dvb were using videobuf_read_start. The
patch I've just send fixes it properly.

Btw, Shane patch reveals a small trouble with EXPORT_SYMBOL_GPL: adding
the tag for a non-existing function didn't rise any error. IMO, it
should generate some compilation error, if you try to export a symbol
that doesn't exist at the file that is being compiled.
 
Cheers,
Mauro

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] REQ-flags to/from BIO-flags bugfix

[Boaz Harrosh]

 - BIO flags bio-bi_rw and REQ flags req-cmd_flags no longer match.
   Remove comments and do a proper translation between the 2 systems.

 (Please look in ll_rw_blk.c/blk_rq_bio_prep() below if we need more flags)

Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
 block/ll_rw_blk.c|   23 +--
 include/linux/blktrace_api.h |8 +++-
 2 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index 8b91994..c6a84bb 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -1990,10 +1990,6 @@ blk_alloc_request(struct request_queue *q, int rw, int 
priv, gfp_t gfp_mask)
if (!rq)
return NULL;
 
-   /*
-* first three bits are identical in rq-cmd_flags and bio-bi_rw,
-* see bio.h and blkdev.h
-*/
rq-cmd_flags = rw | REQ_ALLOCED;
 
if (priv) {
@@ -3772,8 +3768,23 @@ EXPORT_SYMBOL(end_request);
 static void blk_rq_bio_prep(struct request_queue *q, struct request *rq,
struct bio *bio)
 {
-   /* first two bits are identical in rq-cmd_flags and bio-bi_rw */
-   rq-cmd_flags |= (bio-bi_rw  3);
+   if (bio_data_dir(bio))
+   rq-cmd_flags |= REQ_RW;
+   else
+   rq-cmd_flags = ~REQ_RW;
+
+   if (bio-bi_rw  (1BIO_RW_SYNC))
+   rq-cmd_flags |= REQ_RW_SYNC;
+   else
+   rq-cmd_flags = ~REQ_RW_SYNC;
+   /* FIXME: what about other flags, should we sync these too? */
+   /*
+   BIO_RW_AHEAD== ??
+   BIO_RW_BARRIER  == REQ_SOFTBARRIER/REQ_HARDBARRIER
+   BIO_RW_FAILFAST == REQ_FAILFAST
+   BIO_RW_SYNC == REQ_RW_SYNC
+   BIO_RW_META == REQ_RW_META
+   */
 
rq-nr_phys_segments = bio_phys_segments(q, bio);
rq-nr_hw_segments = bio_hw_segments(q, bio);
diff --git a/include/linux/blktrace_api.h b/include/linux/blktrace_api.h
index 7e11d23..9e7ce65 100644
--- a/include/linux/blktrace_api.h
+++ b/include/linux/blktrace_api.h
@@ -165,7 +165,13 @@ static inline void blk_add_trace_rq(struct request_queue 
*q, struct request *rq,
u32 what)
 {
struct blk_trace *bt = q-blk_trace;
-   int rw = rq-cmd_flags  0x03;
+   /* blktrace.c prints them according to bio flags */
+   int rw = (((rq_rw_dir(rq) == WRITE)  BIO_RW) |
+ (((rq-cmd_flags  (REQ_SOFTBARRIER|REQ_HARDBARRIER)) != 0) 
+  BIO_RW_BARRIER) |
+ (((rq-cmd_flags  REQ_FAILFAST) != 0)  BIO_RW_FAILFAST) |
+ (((rq-cmd_flags  REQ_RW_SYNC) != 0)  BIO_RW_SYNC) |
+ (((rq-cmd_flags  REQ_RW_META) != 0)  BIO_RW_META));
 
if (likely(!bt))
return;
-- 
1.5.3.3


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

Re: x86, ptrace: support for branch trace store(BTS)

[Ingo Molnar]

* Metzger, Markus T [EMAIL PROTECTED] wrote:

 Andi suggested to make this a sysctl.

that's just as arbitrary ...

 Would it be safe to drop the artificial limit and let the limit be the 
 available memory?

no, that would be a DoS :-/

mlock() is rlimit controlled and is available to unprivileged users - up 
to a small amount of memory can be locked down. But i agree that mlock() 
can be problematic - see below.

  There's also no real mechanism that i can see to create a guaranteed 
  flow of this information between the debugger and debuggee (unless i 
  missed something), the code appears to overflow the array, and 
  destroy earlier entries, right? That's by design for debugging, 
  but quite a limitation for instrumentation which might want to have 
  a reliable stream of the data (and would like the originating task 
  to block until the debugger had an opportunity to siphoon out the 
  data).
 
 That's correct as well. My focus is on debugging. And that's actually 
 the most useful behavior in that case. I'm not sure what you mean with 
 'instrumentation'.

the branch trace can be used to generate a very finegrained 
profile/histogram of code execution - even of rarely executed codepaths 
which cannot be captured via timer/perf-counter based profiling.

another potential use would be for call graph coverage testing. (which 
currently requires compiler-inserted calls - would be much nicer if we 
could do this via the hardware.)

etc. Branch tracing isnt just for debugging i think - as long as the 
framework is flexible enough.

 The actual physical memory consumption will be worse (or at best 
 equal) compared to kalloc()ed memory, since we need to pin down entire 
 pages, whereas kalloc() would allocate just the memory that is 
 actually needed.

i agree that mlock() has problems. A different model would be: no mlock 
and no get_user_pages() - something quite close to what you have 
already. Data is streamed out of the internal (hardware-filled, 
kmalloc()-ed, user-inaccessible) buffer, we stop task execution until it 
is copied to the larger, user-provided buffer. The debugging feature you 
are interested in could be enabled as a special-case of this mechanism: 
if the user-space buffer is not larger than the hardware buffer then no 
streaming is needed, you can just capture into the kernel buffer. 
User-space would have to do a PTRACE_BTS_DRAIN_BUFFER call (or something 
like that) to get the final portion of the branch trace out into the 
user-space buffer. [which, in your debugging special-case, would the 
full internal buffer.]

that way the kmalloc()-ed buffer becomes an internal detail of buffering 
that you rarely have to be aware of. (it could still be queried - like 
your patch does it now.)

or something else that is intelligent. Basically, what we'd like to have 
is a future-proof, extensible approach that does not necessarily stop at 
debugging and integrates this hardware capability into Linux 
intelligently.

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

Re: [PATCH 15/47] Minor fixes to mm/fault.c for CRIS.

[Andrew Morton]

On Fri, 30 Nov 2007 13:59:57 +0100 Jesper Nilsson [EMAIL PROTECTED] wrote:

 @@ -360,7 +247,7 @@ do_page_fault(unsigned long address, struct pt_regs *regs,
   up_read(mm-mmap_sem);
   printk(VM: killing process %s\n, tsk-comm);
   if (user_mode(regs))
 - do_group_exit(SIGKILL);
 + do_exit(SIGKILL);

Is this change correct?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 21/47] New version of CRISv32 I2C driver.

[Andrew Morton]

On Fri, 30 Nov 2007 15:54:01 +0100 Jesper Nilsson [EMAIL PROTECTED] wrote:

 +int
 +i2c_write(unsigned char theSlave, void *data, size_t nbytes)
 +{
 + int error, cntr = 3;
 + unsigned char bytes_wrote = 0;
 + unsigned char value;
 + unsigned long flags;
 +
 + spin_lock(i2c_lock);
 +
 + do {
 + error = 0;
 + /*
 +  * we don't like to be interrupted
 +  */
 + local_irq_save(flags);
 +
 + i2c_start();
 + /*

Well if you _are_ interrupted prior to the local_irq_save() you'll deadlock
on i2c_lock?

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

Re: [RFT] Port 0x80 I/O speed

[Jiri Slaby]

On Dec 12, 2007 9:48 AM, Jiri Slaby [EMAIL PROTECTED] wrote:
 On 12/12/2007 12:31 AM, Rene Herman wrote:
  Good day.
 
  Would some people on x86 (both 32 and 64) be kind enough to compile and
  run the attached program? This is about testing how long I/O port access

model name  : Intel(R) Xeon(R) CPU   E5335  @ 2.00GHz

cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898

model name  : Dual Core AMD Opteron(tm) Processor 275
cycles: out 5508, in 5524
cycles: out 5509, in 5525
cycles: out 5510, in 5522
cycles: out 5512, in 5522
cycles: out 5512, in 5522
cycles: out 5510, in 5524
cycles: out 5510, in 5522
cycles: out 5511, in 5525
cycles: out 5513, in 5521
cycles: out 5509, in 5522
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 42/47] Minor updates to CRISv32 kernel/process.c

[Andrew Morton]

On Mon, 3 Dec 2007 10:54:15 +0100 Jesper Nilsson [EMAIL PROTECTED] wrote:

 - /* Parameter to ret_from_sys_call. 0 is don't restart the syscall. */
 + /* Paramater to ret_from_sys_call. 0 is don't restart the syscall. */

Parameter.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 02/47] Add new driver files for Artpec-3.

[Andrew Morton]

On Thu, 29 Nov 2007 17:03:41 +0100 Jesper Nilsson [EMAIL PROTECTED] wrote:

 Adds gpio and nandflash handling for Artpec-3.
 
 ...

 +static volatile unsigned long *data_out[NUM_PORTS] = {

all these volatiles really shouldn't be here.

 +static void
 +gpio_set_alarm(struct gpio_private *priv)
 +{
 + int bit;
 + int intr_cfg;
 + int mask;
 + int pins;
 + unsigned long flags;
 +
 + local_irq_save(flags);

Will never run on SMP?

 +
 +inline unsigned long setget_input(struct gpio_private *priv, unsigned long 
 arg)
 +{
 + /* Set direction 0=unchanged 1=input,
 +  * return mask with 1=input
 +  */
 + unsigned long flags;
 + unsigned long dir_shadow;
 +
 + local_irq_save(flags);
 + dir_shadow = *dir_oe[priv-minor];
 + dir_shadow = ~(arg  changeable_dir[priv-minor]);
 + *dir_oe[priv-minor] = dir_shadow;
 + local_irq_restore(flags);
 +
 + if (priv-minor == GPIO_MINOR_C)
 + dir_shadow ^= 0x;   /* Only 16 bits */
 +#ifdef CONFIG_ETRAX_VIRTUAL_GPIO
 + else if (priv-minor == GPIO_MINOR_V)
 + dir_shadow ^= 0x;   /* Only 16 bits */
 +#endif
 + else
 + dir_shadow ^= 0x;   /* PA, PB and PD 32 bits */
 +
 + return dir_shadow;
 +
 +} /* setget_input */
 +
 +inline unsigned long setget_output(struct gpio_private *priv, unsigned long 
 arg)
 +{
 + unsigned long flags;
 + unsigned long dir_shadow;
 +
 + local_irq_save(flags);
 + dir_shadow = *dir_oe[priv-minor];
 + dir_shadow |=  (arg  changeable_dir[priv-minor]);
 + *dir_oe[priv-minor] = dir_shadow;
 + local_irq_restore(flags);
 + return dir_shadow;
 +} /* setget_output */

The `inline's here are surely deoptimising the code.

 +static int
 +gpio_leds_ioctl(unsigned int cmd, unsigned long arg);
 +
 +static int
 +gpio_pwm_ioctl(struct gpio_private *priv, unsigned int cmd, unsigned long 
 arg);
 +
 +static int
 +gpio_ioctl(struct inode *inode, struct file *file,
 +unsigned int cmd, unsigned long arg)
 +{
 + unsigned long flags;
 + unsigned long val;
 + unsigned long shadow;
 + struct gpio_private *priv = (struct gpio_private *)file-private_data;

Unneeded and undesirable cast of void*.

 +
 + if (_IOC_TYPE(cmd) != ETRAXGPIO_IOCTYPE)
 + return -EINVAL;

Not ENOTTY?

 + /* Check for special ioctl handlers first */
 +
 +#ifdef CONFIG_ETRAX_VIRTUAL_GPIO
 + if (priv-minor == GPIO_MINOR_V)
 + return virtual_gpio_ioctl(file, cmd, arg);
 +#endif
 +
 + if (priv-minor == GPIO_MINOR_LEDS)
 + return gpio_leds_ioctl(cmd, arg);
 +
 + if (priv-minor = GPIO_MINOR_PWM0 
 + priv-minor = GPIO_MINOR_LAST_PWM)
 + return gpio_pwm_ioctl(priv, cmd, arg);
 +
 + switch (_IOC_NR(cmd)) {
 + case IO_READBITS: /* Use IO_READ_INBITS and IO_READ_OUTBITS instead */
 + /* Read the port. */
 + return *data_in[priv-minor];

Really.  Nuke the volatiles, use readl().

 + break;
 + case IO_SETBITS:
 + local_irq_save(flags);
 + /* Set changeable bits with a 1 in arg. */
 + shadow = *data_out[priv-minor];

readl()

 + shadow |=  (arg  changeable_bits[priv-minor]);
 + *data_out[priv-minor] = shadow;

writel()

 + local_irq_restore(flags);
 + break;
 + case IO_CLRBITS:
 + local_irq_save(flags);
 + /* Clear changeable bits with a 1 in arg. */
 + shadow = *data_out[priv-minor];
 + shadow =  ~(arg  changeable_bits[priv-minor]);
 + *data_out[priv-minor] = shadow;
 + local_irq_restore(flags);
 + break;
 + case IO_HIGHALARM:
 + /* Set alarm when bits with 1 in arg go high. */
 + priv-highalarm |= arg;
 + gpio_set_alarm(priv);
 + break;
 + case IO_LOWALARM:
 + /* Set alarm when bits with 1 in arg go low. */
 + priv-lowalarm |= arg;
 + gpio_set_alarm(priv);
 + break;
 + case IO_CLRALARM:
 + /* Clear alarm for bits with 1 in arg. */
 + priv-highalarm = ~arg;
 + priv-lowalarm  = ~arg;
 + gpio_set_alarm(priv);
 + break;
 + case IO_READDIR: /* Use IO_SETGET_INPUT/OUTPUT instead! */
 + /* Read direction 0=input 1=output */
 + return *dir_oe[priv-minor];
 + case IO_SETINPUT: /* Use IO_SETGET_INPUT instead! */
 + /* Set direction 0=unchanged 1=input,
 +  * return mask with 1=input
 +  */
 + return setget_input(priv, arg);
 + break;

That break is a bit pointless.

 + case IO_SETOUTPUT: /* Use IO_SETGET_OUTPUT instead! */
 + /* Set direction 0=unchanged 1=output,
 +  * return mask with 1=output
 +  */
 + return setget_output(priv, 

Re: [PATCH] netmos 9855 fix

[chri]

On Dec 12, 2007 10:16 AM, Andrew Morton [EMAIL PROTECTED] wrote:

 What was wrong with it?


Hi,

on loading only one serial port was present and it wasn't working.
After looking in the data sheet I realized that the base address was
wrong. For further reference here is lspci and relevant dmesg output:

02:00.0 Communication controller: NetMos Technology PCI 9855 Multi-I/O
Controller (rev 01) (prog-if 02)
Subsystem: LSI Logic / Symbios Logic Unknown device 0022
Flags: medium devsel, IRQ 19
I/O ports at df00 [size=8]
I/O ports at de00 [size=8]
I/O ports at dd00 [size=8]
I/O ports at dc00 [size=8]
I/O ports at db00 [size=8]
I/O ports at da00 [size=16]

parport1: PC-style at 0xdd00 [PCSPP,TRISTATE]
parport2: PC-style at 0xdf00 [PCSPP,TRISTATE,EPP]
:02:00.0: ttyS0 at I/O 0xdb00 (irq = 19) is a 16550A
:02:00.0: ttyS1 at I/O 0xda00 (irq = 19) is a 16550A



-- 
Christian Pellegrin, see http://www.evolware.org/chri/
Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 06/47] Add serial driver for CRISv32.

[Andrew Morton]

On Thu, 29 Nov 2007 17:23:14 +0100 Jesper Nilsson [EMAIL PROTECTED] wrote:

 +static void serial_cris_set_mctrl(struct uart_port *port, unsigned int mctrl)
 +{
 + struct uart_cris_port *up = (struct uart_cris_port *)port;

use container_of() here

 +static irqreturn_t dma_tr_interrupt(int irq, void *dev_id)
 +{
 + struct uart_cris_port *up = (struct uart_cris_port *)dev_id;

This driver is a somewhat depressing read too.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 29/47] Update CRISv32 traps.c

[Andrew Morton]

On Fri, 30 Nov 2007 16:22:50 +0100 Jesper Nilsson [EMAIL PROTECTED] wrote:

 +#ifdef CONFIG_DEBUG_BUGVERBOSE
 +void
 +handle_BUG(struct pt_regs *regs)
  {
 -  asm volatile(setf m);
 + struct bug_frame f;
 + unsigned char c;
 + unsigned long irp = regs-irp;
 +
 + if (__copy_from_user(f, (const void __user *)(irp - 8), sizeof f))
 + return;
 + if (f.prefix != BUG_PREFIX || f.magic != BUG_MAGIC)
 + return;
 + if (__get_user(c, f.filename))
 + f.filename = bad filename;
 +
 + printk(kernel BUG at %s:%d!\n, f.filename, f.line);
  }
 +#endif

Why is it accessing user memory in the BUG handler?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 39/47] Update and improve CRISv32 fasttimer.c

[Andrew Morton]

On Fri, 30 Nov 2007 17:46:11 +0100 Jesper Nilsson [EMAIL PROTECTED] wrote:

  arch/cris/arch-v32/kernel/fasttimer.c |  519 

I'm suspecting that most of the inlines which this patch retains are
deoptimising the code.

This file still seems to use two-spaces for indentation in many places.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: broken dpt_i2o in 2.6.23 (was: ext2 check page: bad entry in directory) (fwd)

[Andrew Morton]

On Wed, 12 Dec 2007 11:58:41 +0100 Anders Henke [EMAIL PROTECTED] wrote:

 Hi,
 
 I'd like to let you now that my boxes are running a 32-bit kernel, so
 the 64-bit-uncleanliness shouldn't apply to my boxes; however,
 
 http://www.miquels.cistron.nl/linux/dpt_i2o-64bit-2.6.23.patch
 
 fixed the issue on my testbox.
 
 I took a clean 2.6.23, applied patch, recompiled the kernel, reboot: works.

What a huge patch :(

We already reverted the offening patch so I assume that 2.6.24-rc5 is
working for you?

I guess we need to look at restoring dpt_i2o: convert to SCSI hotplug
model and then absorbing what Miquel has done there.

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

Re: 2.6.24-rc3-mm1

[Jens Axboe]

On Wed, Dec 12 2007, Boaz Harrosh wrote:
 On Tue, Dec 11 2007 at 18:33 +0200, James Bottomley [EMAIL PROTECTED] wrote:
  On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
  OK, thanks.  I'll assume that James and Hannes have this in hand (or will
  have, by mid-week) and I won't do anything here.
  
  Just to confirm what I think I'm going to be doing:  rebasing the
  scsi-misc tree to remove this commit:
  
  commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
  Author: Hannes Reinecke [EMAIL PROTECTED]
  Date:   Tue Nov 6 09:23:40 2007 +0100
  
  [SCSI] Do not requeue requests if REQ_FAILFAST is set
  
  And its allied fix ups:
  
  commit 983289045faa96fba8841d3c51b98bb8623d9504
  Author: James Bottomley [EMAIL PROTECTED]
  Date:   Sat Nov 24 19:47:25 2007 +0200
  
  [SCSI] fix up REQ_FASTFAIL not to fail when state is QUIESCE
  
  commit 9dd15a13b332e9f5c8ee752b1ccd9b84cb5bdf17
  Author: James Bottomley [EMAIL PROTECTED]
  Date:   Sat Nov 24 19:55:53 2007 +0200
  
  [SCSI] fix domain validation to work again
  
  James
  
 
 The problems caused by this patch where nagging me at the back of my head
 from the begging. Why should we fail on a check of FAIL_FAST in all kind
 of weird places like boots, when the only place that should ever set the 
 flag should be one of the multi-path drivers. finally it struck me:
 
 It might be a bug in ll_rw_blk at blk_rq_bio_prep() there is this:
 
 static void blk_rq_bio_prep(struct request_queue *q, struct request *rq,
   struct bio *bio)
 {
   /* first two bits are identical in rq-cmd_flags and bio-bi_rw */
   rq-cmd_flags |= (bio-bi_rw  3);
   ...
 
 Now this is no longer true and is a bug.
 Second bit of bio-bi_rw defined in bio.h is:
 #define BIO_RW_AHEAD  1
 but
 Second bit of rq-cmd_flags is __REQ_FAILFAST
 
 so maybe we are getting FAILFAST in the wrong places?

But that's actually on purpose, though the comment is pretty much crap.
We don't want to be retrying readahead requests, those should always
just be tossable.

-- 
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: acpi -video_device_list corruption

[Mikael Pettersson]

William Lee Irwin III writes:
  The -cap fields of struct acpi_video_device and struct acpi_video_bus
  are 1B each, not 4B. The oversized memset()'s corrupted the subsequent
  list_head fields. This resulted in silent corruption without
  CONFIG_DEBUG_LIST and BUG's with it. This patch uses sizeof() to pass
  the proper bounds to the memset() calls and thereby correct the bugs.
  
  Included as a MIME attachment is a compressed dmesg from an affected
  system. The patch was seen to resolve the issue on the affected system.
  
  vs. 2.6.24-rc5
  
  Signed-off-by: William Irwin [EMAIL PROTECTED]
  
  
  -- wli
  
  diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
  index 44a0d9b..7895d57 100644
  --- a/drivers/acpi/video.c
  +++ b/drivers/acpi/video.c
  @@ -577,7 +577,7 @@ static void acpi_video_device_find_cap(struct 
  acpi_video_device *device)
   struct acpi_video_device_brightness *br = NULL;
   
   
  -memset(device-cap, 0, 4);
  +memset(device-cap, 0, sizeof(struct acpi_video_device_cap));

IMO the memset(ptr, 0, sizeof(*ptr)) idiom is both safer
and avoids having to write an uninteresting type name.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.24-rc4: bluetooth device gone after suspend to ram

[Oliver Neukum]

Am Mittwoch, 12. Dezember 2007 11:31:57 schrieb Soeren Sonnenburg:
 Dear all,
 
 I noticed that on my macbook pro1,1 the bluetooth device is gone after
 suspend to ram, i.e.

Is this a regression?
Does it work if you unload hci_usb before you suspend?
If so, please recompile with CONFIG_USB_DEBUG and provide
dmesg.

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: [PATCH] max3100 driver

[chri]

Hi,

thank you for your extensive review, I will fix and resubmitt. Anyway
I learned an important lesson: checkpatch.pl will be my best friend.
Sorry I haven't read about it earlier.

Just a question:


  +/*
  + *
  + *  Copyright (C) 2007 Christian Pellegrin
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License as published by
  + * the Free Software Foundation; either version 2 of the License, or
  + * (at your option) any later version.
  + */
  +
  +
  +#ifndef _LINUX_SERIAL_MAX3100_H
  +#define _LINUX_SERIAL_MAX3100_H 1
  +
  +struct plat_max3100 {
  + int loopback;
  +/* force MAX3100 in loopback */
  + int crystal;
  +/* 0 for 3.6864 Mhz, 1 for 1.8432  */
  + int only_edge_irq;
  +/* for archs like PXA with only edge irqs */
  +};

 Does this header file need to exist?  afaict plat_max3100 is only used by
 drivers/serial/max3100.c and hence could be defined there?


It's used in the machine definition file for platform devices that
cannot be autoprobed. Anyway where is the best place to put such
struct definition / include files? And what is the best way to
document them (if not inline)? For example I put in my machine
definition file (let's say arch/arm/mach-s3c2410/mach-smdk2410.c):

static struct plat_max3100 max3100_plat_data = {
.loopback = 0,
.crystal = 0,
.only_edge_irq = 0,
};

static struct spi_board_info spi_board_info[] = {
{
.modalias   = max3100,
.platform_data  = max3100_plat_data,
.irq= IRQ_EINT12,
.max_speed_hz   = 5*1000*1000,
.chip_select= 0,
},
};

...

   spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info));



-- 
Christian Pellegrin, see http://www.evolware.org/chri/
Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT] Port 0x80 I/O speed

[Alejandro Riveira Fernández]

El Wed, 12 Dec 2007 01:16:06 +0100
Rene Herman [EMAIL PROTECTED] escribió:

 On 12-12-07 01:09, Alejandro Riveira Fernández wrote:

[...]

 
 Great, thanks much for reporting. Sort of interesting in itself that without 
 -O2 you do still get correct results on 64-bit but for some other time.
 
 You're the first one to go significantly below 1 us it seems.

 :( I have seen the other msg and i have to say that the tests where done at
1GHz not at full speed. At full speed i see
 
 cycles: out 3025, in 1653
 cycles: out 3040, in 1708
 cycles: out 3044, in 1650
 cycles: out 3034, in 1652
 cycles: out 3035, in 1652
 cycles: out 3037, in 1652
 cycles: out 3043, in 1709
 cycles: out 3032, in 1648
 cycles: out 3039, in 1652
 cycles: out 3041, in 1652
 cycles: out 3048, in 1704
 cycles: out 3040, in 1650
 cycles: out 3023, in 1631
 cycles: out 3036, in 1652
 cycles: out 3042, in 1706
 cycles: out 3047, in 1708
 cycles: out 3047, in 1711
 cycles: out 3036, in 1652


 

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

Re: [RFT] Port 0x80 I/O speed

[linux]

Here are a variety of machines:

600 MHz PIII (Katmai), 440BX chipset, 82371AB/EB/MB PIIX4 ISA bridge:
cycles: out 794, in 348
cycles: out 791, in 348
cycles: out 791, in 349
cycles: out 791, in 348
cycles: out 791, in 348

433 MHz Celeron (Mendocino), 440 BX chipset, same ISA bridge:
cycles: out 624, in 297
cycles: out 623, in 296
cycles: out 624, in 297
cycles: out 623, in 297
cycles: out 623, in 296

1100 MHz Athlon, nForce2 chipset, nForce2 ISA bridge:
cycles: out 1295, in 1162
cycles: out 1295, in 1162
cycles: out 1295, in 1162
cycles: out 1295, in 1162
cycles: out 1295, in 1162

800 MHz Transmeta Crusoe TM5800, Transmeta/ALi M7101 chipset.
cycles: out 1212, in 388
cycles: out 1195, in 375
cycles: out 1197, in 377
cycles: out 1196, in 376
cycles: out 1196, in 377

2200 MHz Athlon 64, K8T890 chipset, VT8237 ISA bridge:
cycles: out 1844674407370814, in 1844674407365758
cycles: out 1844674407370813, in 1844674407365756
cycles: out 1844674407370805, in 1844674407365750
cycles: out 1844674407370813, in 1844674407365755
cycles: out 1844674407370814, in 1844674407365756

Um, huh?  That's gcc 4.2.3 (Debian version 4.2.2-4), -O2.  Very odd.

I can run it with -O0:
cycles: out 4894, in 4894
cycles: out 4905, in 4917
cycles: out 4910, in 4896
cycles: out 4909, in 4896
cycles: out 4894, in 4898
cycles: out 4911, in 4898

or with -O2 -m32:
cycles: out 4914, in 4927
cycles: out 4913, in 4927
cycles: out 4913, in 4913
cycles: out 4914, in 4913
cycles: out 4913, in 4929
cycles: out 4912, in 4912
cycles: out 4913, in 4915

With -O2, the cycle counts come out (before division) as
out: 0xFFEA6F4F
in:  0xFCE68BB6
I think the A constraint doesn't work quite the same in
64-bit code.  The compiler seems to be using %rdx rather than
%edx:%eax.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 44/47] Minor fixes for CRISv32 io.h

[Andrew Morton]

On Mon, 3 Dec 2007 11:16:25 +0100 Jesper Nilsson [EMAIL PROTECTED] wrote:

 - Shorten include paths for machine dependent header files.
 - Add volatile to hardeware register pointers.
 - Add spinlocks around critical region.
 - Expand macros for handling of leds.
 
 ...

  struct crisv32_ioport
  {
 -  unsigned long* oe;
 -  unsigned long* data;
 -  unsigned long* data_in;
 +  volatile unsigned long *oe;
 +  volatile unsigned long *data;
 +  volatile unsigned long *data_in;
unsigned int pin_count;
 +  spinlock_t lock;
  };

tabs.

  struct crisv32_iopin
 @@ -34,22 +36,37 @@ extern struct crisv32_iopin crisv32_led2_red;
  extern struct crisv32_iopin crisv32_led3_green;
  extern struct crisv32_iopin crisv32_led3_red;
  
 +extern struct crisv32_iopin crisv32_led_net0_green;
 +extern struct crisv32_iopin crisv32_led_net0_red;
 +extern struct crisv32_iopin crisv32_led_net1_green;
 +extern struct crisv32_iopin crisv32_led_net1_red;
 +
  static inline void crisv32_io_set(struct crisv32_iopin* iopin,
  int val)
  {
 + long flags;
 + spin_lock_irqsave(iopin-port-lock, flags);
 +
   if (val)
   *iopin-port-data |= iopin-bit;
   else
   *iopin-port-data = ~iopin-bit;
 +
 + spin_unlock_irqrestore(iopin-port-lock, flags);
  }
  
  static inline void crisv32_io_set_dir(struct crisv32_iopin* iopin,
  enum crisv32_io_dir dir)
  {
 + long flags;
 + spin_lock_irqsave(iopin-port-lock, flags);
 +
   if (dir == crisv32_io_dir_in)
   *iopin-port-oe = ~iopin-bit;
   else
   *iopin-port-oe |= iopin-bit;
 +
 + spin_unlock_irqrestore(iopin-port-lock, flags);
  }

These surely are far too large to be inlined.

 +#define LED_NETWORK_GRP0_SET(x)  \
 + do { \
 + LED_NETWORK_GRP0_SET_G((x)  LED_GREEN); \
 + LED_NETWORK_GRP0_SET_R((x)  LED_RED);   \
   } while (0)
 +#else
 +#define LED_NETWORK_GRP0_SET(x) while (0) {}
 +#endif
 +
 +#define LED_NETWORK_GRP0_SET_G(x) \
 + crisv32_io_set(crisv32_led_net0_green, !(x));
 +
 +#define LED_NETWORK_GRP0_SET_R(x) \
 + crisv32_io_set(crisv32_led_net0_red, !(x));
 +
 +#if defined(CONFIG_ETRAX_NBR_LED_GRP_TWO)
 +#define LED_NETWORK_GRP1_SET(x)  \
 + do { \
 + LED_NETWORK_GRP1_SET_G((x)  LED_GREEN); \
 + LED_NETWORK_GRP1_SET_R((x)  LED_RED);   \
 + } while (0)
 +#else
 +#define LED_NETWORK_GRP1_SET(x) while (0) {}
 +#endif
 +
 +#define LED_NETWORK_GRP1_SET_G(x) \
 + crisv32_io_set(crisv32_led_net1_green, !(x));
 +
 +#define LED_NETWORK_GRP1_SET_R(x) \
 + crisv32_io_set(crisv32_led_net1_red, !(x));
 +
  #define LED_ACTIVE_SET(x)   \
   do {\
   LED_ACTIVE_SET_G((x)  LED_GREEN);  \
   LED_ACTIVE_SET_R((x)  LED_RED);\
   } while (0)
  

PLease generally prefer (lower-case) inlined functions over macros.  They
are cleaner, clearer, safer and have better typechecking.

Several of the above macros reference their argument more than once and
hence cannot be used as, for example,

LED_ACTIVE_SET(foo++);


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

Celeron cpu vs. i810 chipset

[Pavel Machek]

Hi!

We have strange problem with Celeron on i810 mainboards here: machine
reproducibly hangs in test 8 from memtest, and randomly hangs running
linux. (Problem is not bad RAM, not bad powersupply, and not related
to powersaving).

It seems that heavy memory traffic just makes it hang, as soon as main
memory (not L2 cache) is hit.

CPU runs at 8.5x bus clock, ISTR something was wrong with half
multipliers somewhere.

Unfortunately, Intel's web is less than helpful:

 Note: The 810 chipset may contain design defects or errors known as errata
 which may cause the product to deviate from published specifications. Current
 characterized errata are available on request.
 http://developer.intel.com/design/chipsets/810/

...so perhaps someone else can help?
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 46/47] Update and improve CRISv32 kernel/time.c

[Andrew Morton]

On Tue, 4 Dec 2007 17:25:45 +0100 Jesper Nilsson [EMAIL PROTECTED] wrote:

 +#ifdef CONFIG_CPU_FREQ
 + cpufreq_register_notifier(cris_time_freq_notifier_block,
 + CPUFREQ_TRANSITION_NOTIFIER);
  #endif

include/linux/cpufreq.h has

#ifdef CONFIG_CPU_FREQ
...
#else   /* CONFIG_CPU_FREQ */
static inline int cpufreq_register_notifier(struct notifier_block *nb,
unsigned int list)
{
return 0;
}


the idea is that you remove the above ifdefs and also the ifdefs around
cris_time_freq_notifier_block and then gcc magically removes
cris_time_freq_notifier_block from your generated code.

Advantages: no ifdefs, and full typechecking even when CONFIG_CPU_FREQ=n.


cpufreq_register_notifier() can fail but this code pretends otherwise...
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] [net/wireless/iwlwifi] : iwlwifi 3945 Fix raceconditional panic.

[Andrew Morton]

On Thu, 29 Nov 2007 10:42:49 +0900 Joonwoo Park [EMAIL PROTECTED] wrote:

 2007/11/29, Zhu Yi [EMAIL PROTECTED]:
  
  Good catch. But it will be better if you add it into
  iwl_cancel_deferred_work().
  
 
 Thanks.
 I agree with you. 
 Actually, I considered it, but I was afraid of side effect.
 Anyway, I'm attaching a new one.
 
 Thanks.
 Joonwoo
 
 [net/wireless/iwlwifi] : iwlwifi 3945 Fix race conditional panic.
 
 Signed-off-by: Joonwoo Park [EMAIL PROTECTED]
 ---
 diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c 
 b/drivers/net/wireless/iwlwifi/iwl3945-base.c
 index 465da4f..e51e872 100644
 --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
 +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
 @@ -8270,6 +8270,7 @@ static void iwl_cancel_deferred_work(struct iwl_priv 
 *priv)
  {
   iwl_hw_cancel_deferred_work(priv);
  
 + cancel_delayed_work_sync(priv-init_alive_start);
   cancel_delayed_work(priv-scan_check);
   cancel_delayed_work(priv-alive_start);
   cancel_delayed_work(priv-post_associate);

Did drivers/net/wireless/iwlwifi/iwl4965-base.c get fixed in a simlar
fashion?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: acpi -video_device_list corruption

[William Lee Irwin III]

On Wed, Dec 12, 2007 at 12:48:09PM +0100, Mikael Pettersson wrote:
 IMO the memset(ptr, 0, sizeof(*ptr)) idiom is both safer
 and avoids having to write an uninteresting type name.

How about this, then?

The -cap fields of struct acpi_video_device and struct acpi_video_bus
are 1B each, not 4B. The oversized memset()'s corrupted the subsequent
list_head fields. This resulted in silent corruption without
CONFIG_DEBUG_LIST and BUG's with it. This patch uses sizeof() to pass
the proper bounds to the memset() calls and thereby correct the bugs.

The patch was seen to resolve the issue on the affected system.

vs. 2.6.24-rc5

Signed-off-by: William Irwin [EMAIL PROTECTED]

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 44a0d9b..bd77e81 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -577,7 +577,7 @@ static void acpi_video_device_find_cap(struct 
acpi_video_device *device)
struct acpi_video_device_brightness *br = NULL;
 
 
-   memset(device-cap, 0, 4);
+   memset(device-cap, 0, sizeof(device-cap));
 
if (ACPI_SUCCESS(acpi_get_handle(device-dev-handle, _ADR, 
h_dummy1))) {
device-cap._ADR = 1;
@@ -697,7 +697,7 @@ static void acpi_video_bus_find_cap(struct acpi_video_bus 
*video)
 {
acpi_handle h_dummy1;
 
-   memset(video-cap, 0, 4);
+   memset(video-cap, 0, sizeof(video-cap));
if (ACPI_SUCCESS(acpi_get_handle(video-device-handle, _DOS, 
h_dummy1))) {
video-cap._DOS = 1;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.24-rc5 videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!

[Adrian Bunk]

On Wed, Dec 12, 2007 at 09:03:14AM -0200, Mauro Carvalho Chehab wrote:
...
 I'm afraid that this wouldn't avoid this bug, however. 
 
 The removal of the EXPORT_SYMBOL_GPL seemed to be the intention of
 Brandon, since he renamed the function, removing the locks. I think he
 didn't noticed that videobuf_dvb were using videobuf_read_start. The
 patch I've just send fixes it properly.

At least in the commit in Linus' tree, videobuf_read_start() stayed 
nearly unchanged.

 Btw, Shane patch reveals a small trouble with EXPORT_SYMBOL_GPL: adding
 the tag for a non-existing function didn't rise any error.

See above.

 IMO, it
 should generate some compilation error, if you try to export a symbol
 that doesn't exist at the file that is being compiled.

It does give you a compile error when there's not at least a prototype 
for the stuff to be exported, and a link error if there's no
variable/function.

 Cheers,
 Mauro

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/

Re: [PATCH 00/30] blk_end_request: full I/O completion handler (take 4)

[Jens Axboe]

On Tue, Dec 11 2007, Kiyoshi Ueda wrote:
 Hi Jens, Boaz,
 
 The following is the updated patch-set for blk_end_request().
 I have done some interface/implementation changes based on
 feedbacks/discussions since the previous version.
 (Although this patch-set was made on top of 2.6.24-rc4, I confirmed
  it can be applied to 2.6.24-rc5, too.  Also, I confirmed it has
  no build error on my IA64 box.)

Trying to apply this, but it fails from patch #24 and on:

patching file block/ll_rw_blk.c
Hunk #1 succeeded at 3852 (offset 49 lines).
Hunk #2 succeeded at 3867 with fuzz 2 (offset 49 lines).
Hunk #3 succeeded at 3904 with fuzz 1 (offset 66 lines).
Hunk #4 FAILED at 3916.
Hunk #5 succeeded at 3967 with fuzz 2 (offset 60 lines).
1 out of 5 hunks FAILED -- saving rejects to file block/ll_rw_blk.c.rej
patching file include/linux/blkdev.h
Reversed (or previously applied) patch detected!  Assume -R? [n] 

This is 2.6.24-rc5 (pretty close to at least, no changes to ll_rw_blk.c
from that version). Are you using quilt and forgot to refresh, or
something like that?

-- 
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: acpi -video_device_list corruption

[Mikael Pettersson]

William Lee Irwin III writes:
  On Wed, Dec 12, 2007 at 12:48:09PM +0100, Mikael Pettersson wrote:
   IMO the memset(ptr, 0, sizeof(*ptr)) idiom is both safer
   and avoids having to write an uninteresting type name.
  
  How about this, then?

Looks good.

Acked-by: Mikael Pettersson [EMAIL PROTECTED]

  
  The -cap fields of struct acpi_video_device and struct acpi_video_bus
  are 1B each, not 4B. The oversized memset()'s corrupted the subsequent
  list_head fields. This resulted in silent corruption without
  CONFIG_DEBUG_LIST and BUG's with it. This patch uses sizeof() to pass
  the proper bounds to the memset() calls and thereby correct the bugs.
  
  The patch was seen to resolve the issue on the affected system.
  
  vs. 2.6.24-rc5
  
  Signed-off-by: William Irwin [EMAIL PROTECTED]
  
  diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
  index 44a0d9b..bd77e81 100644
  --- a/drivers/acpi/video.c
  +++ b/drivers/acpi/video.c
  @@ -577,7 +577,7 @@ static void acpi_video_device_find_cap(struct 
  acpi_video_device *device)
   struct acpi_video_device_brightness *br = NULL;
   
   
  -memset(device-cap, 0, 4);
  +memset(device-cap, 0, sizeof(device-cap));
   
   if (ACPI_SUCCESS(acpi_get_handle(device-dev-handle, _ADR, 
  h_dummy1))) {
   device-cap._ADR = 1;
  @@ -697,7 +697,7 @@ static void acpi_video_bus_find_cap(struct 
  acpi_video_bus *video)
   {
   acpi_handle h_dummy1;
   
  -memset(video-cap, 0, 4);
  +memset(video-cap, 0, sizeof(video-cap));
   if (ACPI_SUCCESS(acpi_get_handle(video-device-handle, _DOS, 
  h_dummy1))) {
   video-cap._DOS = 1;
   }
  --
  To unsubscribe from this list: send the line unsubscribe linux-kernel in
  the body of a message to [EMAIL PROTECTED]
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  Please read the FAQ at  http://www.tux.org/lkml/
  
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT] Port 0x80 I/O speed

[Ville Syrjälä]

On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
 Good day.

 Would some people on x86 (both 32 and 64) be kind enough to compile and run 
 the attached program? This is about testing how long I/O port access to 
 port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in 
 reporting.

vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 CPU  6600  @ 2.40GHz
stepping: 6

cpu MHz : 2394.000
cycles: out 1830, in 1166

cpu MHz : 1596.000
cycles: out 1925, in 1266

##

vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 10

cpu MHz : 850.000
cycles: out 1142, in 475

cpu MHz : 700.000
cycles: out 914, in 406

##

vendor_id   : AuthenticAMD
cpu family  : 6
model   : 7
model name  : AMD Duron(tm) processor
stepping: 1

cpu MHz : 1300.108
cycles: out 2562, in 2562

##

vendor_id   : GenuineIntel
cpu family  : 6
model   : 5
model name  : Pentium II (Deschutes)
stepping: 2

cpu MHz : 449.242
cycles: out 607, in 272

-- 
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [ewg] Re: [PATCH] IB/ehca: Serialize HCA-related hCalls on POWER5

[Or Gerlitz]

Joachim Fenkes wrote:

Roland Dreier [EMAIL PROTECTED] wrote on 10.12.2007 22:47:37:



It's an optional device feature, so this should be OK
(although the iSER driver currently seems to depend on a device
supporting FMRs, which is probably going to be a problem with iWARP
support in the future anyway).


I don't feel very well with removing code from the driver that iSER seems 
to depend on. Are there plans to fix this in iSER?


What is the fix you suggest, to add a device query that tells you for 
which verbs the documentation does not apply? or enhance the code of the 
 map_phys_fmr verb within the ehca driver to return error if called 
from non-sleepable context?


Or.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: x86, ptrace: support for branch trace store(BTS)

[Metzger, Markus T]

-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED] 
Sent: Mittwoch, 12. Dezember 2007 12:04

 Would it be safe to drop the artificial limit and let the 
limit be the 
 available memory?

no, that would be a DoS :-/

How about:

for (;;) {
int pid = fork();
if (pid) 
ptrace_allocate(pid, small_buffer_size);
}


I guess what we really want is a per-task kalloc() limit. That limit can
be quite big.

Should this rather be within kalloc() itself (with the data stored in
task_struct) or should this be local to ptrace_bts_alloc?

Is there already a per-task memory limit? We could deduct the kalloc()ed
memory from that.


 the most useful behavior in that case. I'm not sure what you 
mean with 
 'instrumentation'.

the branch trace can be used to generate a very finegrained 
profile/histogram of code execution - even of rarely executed 
codepaths 
which cannot be captured via timer/perf-counter based profiling.

another potential use would be for call graph coverage testing. (which 
currently requires compiler-inserted calls - would be much nicer if we 
could do this via the hardware.)

etc. Branch tracing isnt just for debugging i think - as long as the 
framework is flexible enough.

Agreed.


 The actual physical memory consumption will be worse (or at best 
 equal) compared to kalloc()ed memory, since we need to pin 
down entire 
 pages, whereas kalloc() would allocate just the memory that is 
 actually needed.

i agree that mlock() has problems. A different model would be: 

I have my doubts regarding any form of two-buffer approach. 

Let's assume we find a way to get a reasonably big limit. 

Users who want to process that huge amount of data would be better off
using a file-based approach (well, if it cannot be held in physical
memory, they will spend most of their time swapping, anyway). Those
users would typically wait for the 'buffer full' event and drain the
buffer into a file - whether this is the real buffer or a bigger virtual
buffer.

The two-buffer approach would only benefit users who want to hold the
full profile in memory - or who want to stall the debuggee until they
processed or somehow compressed the data collected so far.
Those approaches would not scale for very big profiles.
The small profile cases would already be covered with a reasonably big
real buffer.

The two-buffer approach is moving out the limit of what can be profiled
in (virtual) memory.


Independent of how many buffers we have, we need to offer overflow
handling. This could be:
1. cyclic buffer
2. buffer full event

Robust users would either:
a. select 2 and ignore the overflow signal to collect an initial profile
b. select 1 to collect a profile tail
c. select 2 and drain the real or virtual buffer into a file to collect
the full profile
d. select 2 and bail out on overflow (robust but limited usefulness)

Debuggers would typically choose b. Path profilers would typically
choose c. Student projects would typically choose d.


I see benefit in providing a second overflow handling method. 
I only see benefit in a bigger second buffer if we cannot get the limit
to a reasonable size.

Am I missing something?


thanks and regards,
markus.
-
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT] Port 0x80 I/O speed

[Paolo Ornati]

On 12 Dec 2007 06:20:49 -0500
[EMAIL PROTECTED] wrote:

 With -O2, the cycle counts come out (before division) as
 out: 0xFFEA6F4F
 in:  0xFCE68BB6
 I think the A constraint doesn't work quite the same in
 64-bit code.  The compiler seems to be using %rdx rather than
 %edx:%eax.

In another message he says to compile it with -m32  :)

-- 
Paolo Ornati
Linux 2.6.24-rc5-g4af75653 on x86_64
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 01/30] blk_end_request: add new request completion interface (take 4)

[James Bottomley]

On Tue, 2007-12-11 at 17:40 -0500, Kiyoshi Ueda wrote:
 This patch adds 2 new interfaces for request completion:
   o blk_end_request()   : called without queue lock
   o __blk_end_request() : called with queue lock held
 
 blk_end_request takes 'error' as an argument instead of 'uptodate',
 which current end_that_request_* take.
 The meanings of values are below and the value is used when bio is
 completed.
 0 : success
0 : error
 
 Some device drivers call some generic functions below between
 end_that_request_{first/chunk} and end_that_request_last().
   o add_disk_randomness()
   o blk_queue_end_tag()
   o blkdev_dequeue_request()

If we can roll the whole thing together, that would be nice.  However,
the way you're doing it with this patch, we now have an asymmetrical
interface:  The request routine must explicitly start the tag, but now
doesn't have to end it.

We really need symmetry.  Either go back to start tag/end tag, or absorb
the whole lot into the block infrastructure.

The original reason for the explicit start/end is that there are some
requests on a tagged device that aren't able to be tagged by the block
layer (some devices reserve tag numbers for specific meanings).
However, I don't think there's any driver that actually implemented this
feature.

James


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

Re: Lnux 2.6.24-rc5

[Johannes Weiner]

Hi,

Oleksandr Natalenko [EMAIL PROTECTED] writes:

 And... Linus, why do yo make mistakes in headers of announces :)? Not first 
 time.

This is the effect of a plugin for the Linus-bot written in Lisp.  It's
an output-scrambler that makes him act more human.

Hannes
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4

[Peter Zijlstra]

On Tue, 2007-12-11 at 17:11 -0500, Jie Chen wrote:
 Ingo Molnar wrote:
  * Jie Chen [EMAIL PROTECTED] wrote:
  
  The following is pthread_sync output for 2.6.21.7-cfs-v24 #1 SMP 
  kernel.
  
  2 threads:
  
  PARALLEL time =   11.106580 microseconds +/- 0.002460
  PARALLEL overhead =0.617590 microseconds +/- 0.003409
  
  Output for Kernel 2.6.24-rc4 #1 SMP
  
  PARALLEL time =  19.668450 microseconds +/- 0.015782
  PARALLEL overhead =   9.157945 microseconds +/- 0.018217
  
  ok, so the problem is that this PARALLEL time has an additional +9 usecs 
  overhead, right? I dont see this myself on a Core2 CPU:
  
  PARALLEL time =   10.446933 microseconds +/- 
  0.078849
  PARALLEL overhead =   0.751732 microseconds +/- 0.177446
  

On my dual socket AMD Athlon MP

2.6.20-13-generic

PARALLEL time =   22.751875 microseconds +/- 21.370942
PARALLEL overhead =   7.046595 microseconds +/- 24.370040

2.6.24-rc5

PARALLEL time =   17.365543 microseconds +/- 3.295133
PARALLEL overhead =   2.213722 microseconds +/- 4.797886




signature.asc
Description: This is a digitally signed message part

Re: [PATCH 27/30] blk_end_request: changing scsi (take 4)

[James Bottomley]

On Tue, 2007-12-11 at 17:52 -0500, Kiyoshi Ueda wrote:
 This patch converts scsi mid-layer to use blk_end_request interfaces.
 Related 'uptodate' arguments are converted to 'error'.
 
 As a result, the interface of internal function, scsi_end_request(),
 is changed.

This looks fine, as far as it goes.

One of the things that might actually be useful in future is as well as
communicating the error, the ability to say more information about what
happened.  For instance dm-mp needs to know whether the error is
transport or device related (the former being retryable on a different
path).

James


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

RE: 2.6.22.14 oops msg with commvault galaxy ?

[Fortier,Vincent [Montreal]]

 -Message d'origine-
 De : Dhaval Giani [mailto:[EMAIL PROTECTED] 
 
 On Tue, Dec 11, 2007 at 10:06:53PM +0100, Ingo Molnar wrote:
  
  * Fortier,Vincent [Montreal] [EMAIL PROTECTED] wrote:
  
That has changed from /sys/kernel/uids/uid/cpu_share
   
   Here is my config.
   
   Maybie I should give it a shot without CFS at all and see what 
   happends ?

It got triggerred also using a 2.6.22.14:
[57560.396000] BUG: unable to handle kernel paging request at virtual
address 8000
[57560.396000]  printing eip:
[57560.396000] c01d6c56
[57560.396000] *pdpt = 08d02001
[57560.396000] *pde = 
[57560.396000] Oops:  [#34]
[57560.396000] SMP
[57560.396000] last sysfs file: /devices/platform/floppy.0/uevent
[57560.396000] Modules linked in: xfs drbd cn nfs nfsd exportfs lockd
nfs_acl sunrpc ppdev parport_pc lp parport button ac battery ipv6 fuse
ide_cd ide_generic usbkbd usbmouse tsdev iTCO_wdt iTCO_vendor_support
psmouse e752x_edac edac_mc serio_raw evdev pcspkr sg floppy shpchp
pci_hotplug sr_mod cdrom ext3 jbd mbcache dm_mirror dm_snapshot dm_mod
generic piix ide_core tg3 ata_piix ehci_hcd uhci_hcd usbcore thermal
processor fan mptscsih mptbase megaraid_sas megaraid_mbox megaraid_mm
cciss aacraid
[57560.396000] CPU:2
[57560.396000] EIP:0060:[c01d6c56]Not tainted VLI
[57560.396000] EFLAGS: 00010297   (2.6.22.14-etch-686-envcan #1)
[57560.396000] EIP is at vsnprintf+0x2af/0x48c
[57560.396000] eax: 8000   ebx:    ecx: 8000   edx:
fffe
[57560.396000] esi: edf37017   edi: edf09eac   ebp:    esp:
edf09e4c
[57560.396000] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[57560.396000] Process clBackup (pid: 31421, ti=edf08000 task=f7d36530
task.ti=edf08000)
[57560.396000] Stack: c852b000 1000 c0338c78 f895b56c c0233bf5
c852b000 120c8fe8 edf37017
[57560.396000]00c3bd08    
c03354eb 0003 0017
[57560.396000]c0376dc0 c852b000 c01d6eb4 edf09eac edf09eac
c0233170 edf37017 c03354ea
[57560.396000] Call Trace:
[57560.396000]  [c0233bf5] dev_uevent+0x189/0x1e0
[57560.396000]  [c01d6eb4] sprintf+0x20/0x23
[57560.396000]  [c0233170] show_uevent+0xad/0xd5
[57560.396000]  [c0154f48] get_page_from_freelist+0x296/0x32d
[57560.396000]  [c012e6f0] group_send_sig_info+0x12/0x56
[57560.396000]  [c0155031] __alloc_pages+0x52/0x294
[57560.396000]  [c02330c3] show_uevent+0x0/0xd5
[57560.396000]  [c0232c82] dev_attr_show+0x15/0x18
[57560.396000]  [c01a6979] sysfs_read_file+0x87/0xd8
[57560.396000]  [c0185f04] sys_getxattr+0x46/0x4e
[57560.396000]  [c01a68f2] sysfs_read_file+0x0/0xd8
[57560.396000]  [c016fe03] vfs_read+0xa6/0x128
[57560.396000]  [c01701ff] sys_read+0x41/0x67
[57560.396000]  [c0103d8a] syscall_call+0x7/0xb
[57560.396000]  ===
[57560.396000] Code: 74 24 28 73 03 c6 06 20 4d 46 85 ed 7f f1 e9 b9 00
00 00 8b 0f b8 79 e0 32 c0 8b 54 24 2c 81 f9 ff 0f 00 00 0f 46 c8 89 c8
eb 06 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 f6 44 24 30 10 89 c3
[57560.396000] EIP: [c01d6c56] vsnprintf+0x2af/0x48c SS:ESP
0068:edf09e4c

  
  and also with CFS but without CONFIG_FAIR_GROUP_SCHED.
  

Is it still required since it now does not seems to be CFS related?

 
 Hi Ingo,
 
 I am able to reproduce the oops here on my system with 
 2.6.22.14 + CFS backport. I am not able to reproduce it with 
 2.6.22.13 + CFS backport. I believe the CFS backport is just 
 exposing the bug. Can't find an obvious culprit and am 
 looking into this issue.
 
 Vincent, could you please confirm if you are able to 
 reproduce this with
 2.6.22.13 + CFS?

Using 2.6.13 + CFS v24 I was also able to reproduce the bug (I already
had one built in my depot without the
display_most-recently-opened_sysfs_file_name_when_oopsing.patch).  So it
looks like it is at least related to = 2.6.22.13 and probably not
directly CFS related.  Note that to get a oops on a 2.6.13 it seems to
need a full backup since it usually works with incremental.  The backup
does start properly then, in this case, at around 70% it oopsed.  Using
2.6.22.14 it seems to oops right at startup.  Here is the 2.6.22.13 CFS
v24 oops:

[  170.152908] SGI XFS Quota Management subsystem
[  170.168443] Filesystem drbd0: Disabling barriers, not supported by
the underlying device
[  170.174964] XFS mounting filesystem drbd0
[  170.232455] Ending clean XFS mount for filesystem: drbd0
[  170.318614] Filesystem drbd1: Disabling barriers, not supported by
the underlying device
[  170.327708] XFS mounting filesystem drbd1
[  170.380481] Ending clean XFS mount for filesystem: drbd1
[  947.493764] BUG: unable to handle kernel NULL pointer dereference at
virtual address 00c8
[  947.493797]  printing eip:
[  947.493810] c01a922c
[  947.493823] *pdpt = 2a97a001
[  947.493837] *pde = 
[  947.493852] Oops:  [#1]
[  947.493865] SMP
[  947.493881] Modules linked in: xfs drbd cn nfs nfsd exportfs lockd
nfs_acl sunrpc ppdev parport_pc lp parport 

ext3 SMP bug ? PANIC in __d_find_alias

[Mitch]

Can anyone help with this ? This seems to be a true SMP bug - the same 
kernel on another UP machine is working fine (although different h/w). 
Seems like stress (find for example) can easily trigger this. Does it 
look like i have a bad filesystem ? Can anyone help me figure out which 
one ? The fact that this is tainted (due to nvidia) is a red herring i 
think because both my machines (the SMP and UP one) are using the same 
nvidia module and the panic is in ext3 code.


Help
Mitch

Dec 10 03:02:43 home kernel: BUG: unable to handle kernel NULL pointer 
dereference at virtual address 

Dec 10 03:02:43 home kernel:  printing eip:
Dec 10 03:02:43 home kernel: c01761fc
Dec 10 03:02:43 home kernel: *pdpt = 198a6001
Dec 10 03:02:43 home kernel: *pde = 
Dec 10 03:02:43 home kernel: Oops:  [#1]
Dec 10 03:02:43 home kernel: PREEMPT SMP
Dec 10 03:02:43 home kernel: Modules linked in: loop nls_iso8859_1 
nls_cp437 vfat fat tun iptable_nat nvidia(P) appletalk psnap llc nfsd expo
rtfs lockd sunrpc xt_limit xt_tcpudp iptable_mangle ipt_LOG 
ipt_MASQUERADE nf_nat ipt_TOS ipt_REJECT nf_conntrack_irc 
nf_conntrack_ftp nf_con
ntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables 
ftdi_sio usbserial forcedeth snd_hda_intel snd_seq_oss snd_seq_midi_event
 snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc 
snd_mixer_oss snd usb_storage ehci_hcd ohci_hcd it87 hwmon_vid i2c_dev i

2c_core
Dec 10 03:02:43 home kernel: CPU:1
Dec 10 03:02:43 home kernel: EIP:0060:[__d_find_alias+44/192] 
Tainted: PVLI

Dec 10 03:02:43 home kernel: EFLAGS: 00010282   (2.6.23 #5)
Dec 10 03:02:43 home kernel: EIP is at __d_find_alias+0x2c/0xc0
Dec 10 03:02:43 home kernel: eax:    ebx: c03579bc   ecx: 
   edx: 4000
Dec 10 03:02:44 home kernel: esi: f55d58bc   edi:    ebp: 
0001   esp: d479dda4
Dec 10 03:02:44 home kernel: ds: 007b   es: 007b   fs: 00d8  gs: 0033 
ss: 0068
Dec 10 03:02:44 home kernel: Process find (pid: 8233, ti=d479c000 
task=f6d35ab0 task.ti=d479c000)
Dec 10 03:02:44 home kernel: Stack: f55d58a4 ebf42f00 f6735800 ebf42f00 
c017832f f55d58a4 ebf42f00 f6735800
Dec 10 03:02:44 home kernel:c01ad386 c0177755 ebf42f60 d479de38 
ebf42f00 e85bf2fc c0357e80 ebf42f00
Dec 10 03:02:44 home kernel:d479df04 c016d242 d479de44 f7c04740 
f1352a98 f1352b0c d479de38 00034c98

Dec 10 03:02:44 home kernel: Call Trace:
Dec 10 03:02:44 home kernel:  [d_splice_alias+95/208] 
d_splice_alias+0x5f/0xd0

Dec 10 03:02:44 home kernel:  [ext3_lookup+230/288] ext3_lookup+0xe6/0x120
Dec 10 03:02:44 home kernel:  [d_alloc+309/416] d_alloc+0x135/0x1a0
Dec 10 03:02:44 home kernel:  [do_lookup+290/416] do_lookup+0x122/0x1a0
Dec 10 03:02:44 home kernel:  [__link_path_walk+1873/3408] 
__link_path_walk+0x751/0xd50
Dec 10 03:02:44 home kernel:  [link_path_walk+101/192] 
link_path_walk+0x65/0xc0
Dec 10 03:02:44 home kernel:  [link_path_walk+69/192] 
link_path_walk+0x45/0xc0
Dec 10 03:02:44 home kernel:  [nameidata_to_filp+53/64] 
nameidata_to_filp+0x35/0x40

Dec 10 03:02:44 home kernel:  [do_filp_open+75/96] do_filp_open+0x4b/0x60
Dec 10 03:02:44 home kernel:  [do_path_lookup+120/448] 
do_path_lookup+0x78/0x1c0

Dec 10 03:02:44 home kernel:  [getname+160/192] getname+0xa0/0xc0
Dec 10 03:02:44 home kernel:  [__user_walk_fd+59/96] 
__user_walk_fd+0x3b/0x60

Dec 10 03:02:44 home kernel:  [vfs_lstat_fd+31/80] vfs_lstat_fd+0x1f/0x50
Dec 10 03:02:44 home kernel:  [nameidata_to_filp+53/64] 
nameidata_to_filp+0x35/0x40

Dec 10 03:02:44 home kernel:  [do_filp_open+75/96] do_filp_open+0x4b/0x60
Dec 10 03:02:44 home kernel:  [sys_lstat64+15/48] sys_lstat64+0xf/0x30
Dec 10 03:02:44 home kernel:  [__fput+257/352] __fput+0x101/0x160
Dec 10 03:02:44 home kernel:  [mntput_no_expire+19/96] 
mntput_no_expire+0x13/0x60

Dec 10 03:02:44 home kernel:  [filp_close+71/128] filp_close+0x47/0x80
Dec 10 03:02:44 home kernel:  [sys_close+102/208] sys_close+0x66/0xd0
Dec 10 03:02:44 home kernel:  [sysenter_past_esp+95/133] 
sysenter_past_esp+0x5f/0x85

Dec 10 03:02:44 home kernel:  ===
Dec 10 03:02:44 home kernel: Code: 89 c1 89 d5 57 56 8d 70 18 53 8b 40 
18 31 db 39 c6 74 6c 0f b7 51 6a 31 ff 81 e2 00 f0 00 00 eb 0a 85 ed 7
4 6a 39 ce 74 2e 89 c8 8b 08 0f 18 01 90 81 fa 00 40 00 00 8d 58 bc 74 
06 f6 43 04 10
Dec 10 03:02:44 home kernel: EIP: [__d_find_alias+44/192] 
__d_find_alias+0x2c/0xc0 SS:ESP 0068:d479dda4

Dec 10 03:02:44 home kernel: note: find[8233] exited with preempt_count 1
Dec 10 03:02:44 home kernel: BUG: scheduling while atomic: 
find/0x1002/8233
Dec 10 03:02:44 home kernel:  [schedule+1474/1728] 
__sched_text_start+0x5c2/0x6c0
Dec 10 03:02:44 home kernel:  [__cond_resched+24/48] 
__cond_resched+0x18/0x30

Dec 10 03:02:44 home kernel:  [cond_resched+42/64] cond_resched+0x2a/0x40
Dec 10 03:02:44 home kernel:  [unmap_vmas+1502/1536] unmap_vmas+0x5de/0x600
Dec 10 03:02:44 home kernel:  [exit_mmap+123/288] exit_mmap+0x7b/0x120
Dec 

Re: broken dpt_i2o in 2.6.23 (was: ext2 check page: bad entry in directory) (fwd)

[Miquel van Smoorenburg]

On Wed, 2007-12-12 at 03:38 -0800, Andrew Morton wrote:
 On Wed, 12 Dec 2007 11:58:41 +0100 Anders Henke [EMAIL PROTECTED] wrote:
 
  Hi,
  
  I'd like to let you now that my boxes are running a 32-bit kernel, so
  the 64-bit-uncleanliness shouldn't apply to my boxes; however,
  
  http://www.miquels.cistron.nl/linux/dpt_i2o-64bit-2.6.23.patch
  
  fixed the issue on my testbox.
  
  I took a clean 2.6.23, applied patch, recompiled the kernel, reboot: works.
 
 What a huge patch :(
 
 We already reverted the offening patch so I assume that 2.6.24-rc5 is
 working for you?
 
 I guess we need to look at restoring dpt_i2o: convert to SCSI hotplug
 model and then absorbing what Miquel has done there.

This was just a patch I had lying around, if it worked it would confirm
my suspicion, which it has.

The minimal patch which is suitable for 2.6.23-stable and 2.6.24 would
be the attached one-liner. The dpt_i2o: convert to SCSI hotplug model
patch could be restored then.

(if the list eats the attachment, it's also available here:
http://www.miquels.cistron.nl/linux/linux-2.6.23+24-dpt_i2o-dma64.patch 
)

Anders, does this one-liner patch work for you ?

Mike.
diff -ruN linux-2.6.23.9.orig/drivers/scsi/dpt_i2o.c linux-2.6.23.9/drivers/scsi/dpt_i2o.c
--- linux-2.6.23.9.orig/drivers/scsi/dpt_i2o.c	2007-11-26 18:51:43.0 +0100
+++ linux-2.6.23.9/drivers/scsi/dpt_i2o.c	2007-12-12 13:21:05.0 +0100
@@ -905,8 +905,7 @@
 	}
 
 	pci_set_master(pDev);
-	if (pci_set_dma_mask(pDev, DMA_64BIT_MASK) 
-	pci_set_dma_mask(pDev, DMA_32BIT_MASK))
+	if (pci_set_dma_mask(pDev, DMA_32BIT_MASK))
 		return -EINVAL;
 
 	base_addr0_phys = pci_resource_start(pDev,0);

Re: [RFT] Port 0x80 I/O speed

[Rene Herman]

On 12-12-07 13:59, linux-os (Dick Johnson) wrote:


On Tue, 11 Dec 2007, [utf-8] Alejandro Riveira Fern?ndez wrote:



On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:

cycles: out 1844674407370808, in 1844674407369087

It is not constant but variations are not significant afaics



It looks as though this hardware does not have a port 0x80
and its access is trapped by the hardware with a long time-out!
This may be the reason when the _p was called harmful on this
platform!

I'm not sure the rules for port access allow for this kind of
behavior. This design may be defective, needing to be brought
to the attention of the vendor. A decent vendor would update
a FPGA and provide code to burn a new BIOS.


I'm afraid it's just the test that is defective as 64-bit code. For some 
reason =A doesn't mean edx:eax on amd64 even though it's a useful register 
pair to be able to name there as well. Didn't catch that being without amd64 
machines myself.


Oh well. gcc -m32 fixes it...

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

Re: [RFT] Port 0x80 I/O speed

[linux-os (Dick Johnson)]

On Wed, 12 Dec 2007, Rene Herman wrote:

 On 12-12-07 13:59, linux-os (Dick Johnson) wrote:

 On Tue, 11 Dec 2007, [utf-8] Alejandro Riveira Fern?ndez wrote:

 On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:

 cycles: out 1844674407370808, in 1844674407369087

 It is not constant but variations are not significant afaics


 It looks as though this hardware does not have a port 0x80
 and its access is trapped by the hardware with a long time-out!
 This may be the reason when the _p was called harmful on this
 platform!

 I'm not sure the rules for port access allow for this kind of
 behavior. This design may be defective, needing to be brought
 to the attention of the vendor. A decent vendor would update
 a FPGA and provide code to burn a new BIOS.

 I'm afraid it's just the test that is defective as 64-bit code. For some
 reason =A doesn't mean edx:eax on amd64 even though it's a useful register
 pair to be able to name there as well. Didn't catch that being without amd64
 machines myself.

 Oh well. gcc -m32 fixes it...

 Rene.


Yep. By bad. I actually believed the returned value!


Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips).
My book : http://www.AbominableFirebug.com/
_



The information transmitted in this message is confidential and may be 
privileged.  Any review, retransmission, dissemination, or other use of this 
information by persons or entities other than the intended recipient is 
prohibited.  If you are not the intended recipient, please notify Analogic 
Corporation immediately - by replying to this message or by sending an email to 
[EMAIL PROTECTED] - and destroy all copies of this information, including any 
attachments, without reading or disclosing them.

Thank you.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

[linux-os (Dick Johnson)]

On Tue, 11 Dec 2007, David P. Reed wrote:

 1) I found in a book, the Undocumented PC, that I have lying around that
 the pause recommended for some old adapter chips on the ISA bus was 1
 usec.  The book carefully points out on various models of PCs how many
 short jumps are required to implement 1 usec, and suggests that for
 faster machines, 1 usec loops be calibrated.  That seems like a good
 heuristic.

 2) Also, Dick, you got me interested in doing more historical research
 into electrical specs and circuit diagrams (which did come with the IBM
 5150).  The bus in the original IBM PC had no problem with bus capacity
 being charged as you put it.   Perhaps you don't remember that the I/O
 bus had the same electrical characteristics as the memory bus.  Thus
 there is no issue with the bus being charged.  The issue of delays
 between i/o instructions was entirely a problem of whether the adapter
 card could clock data into its buffers and handle the clocked in data in
 time for another bus cycle.  This had nothing to do with charging -
 buses in those days happily handled edges that were much faster than 1 usec.

Wrong: the bus is not a clocked bus. Read a book. There is
a clock trace provided, but it has nothing to do with the
bus or its timing. The bus is not impedance-controlled, nor
is it clocked. It relies upon certain established states.
Look in the back of the IBM/PC book or read about the bus
in http://www.techfest.com/hardware/nis/isa.htm and observe
the bus-timing with no clock involved at all.


 We at Software Arts did what we did based on direct measurements and
 testing.  We found that the early BIOS listings were usually fine, but
 in fact were misleading. After all, the guys who built the machine and
 wrote the BIOS were in a hurry.  There were errata.


Yep. We are all wrong. You come out of nowhere and claim to
be right. Goodbye.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips).
My book : http://www.AbominableFirebug.com/
_



The information transmitted in this message is confidential and may be 
privileged.  Any review, retransmission, dissemination, or other use of this 
information by persons or entities other than the intended recipient is 
prohibited.  If you are not the intended recipient, please notify Analogic 
Corporation immediately - by replying to this message or by sending an email to 
[EMAIL PROTECTED] - and destroy all copies of this information, including any 
attachments, without reading or disclosing them.

Thank you.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] more i2c fixes for 2.6.24

[Jean Delvare]

Hi Linus,

Please pull the i2c subsystem fixes for Linux 2.6.24 from:

git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus


 Documentation/i2c/summary|   45 +++--
 drivers/i2c/busses/i2c-davinci.c |4 +-
 drivers/i2c/busses/i2c-gpio.c|1 +
 drivers/i2c/busses/i2c-omap.c|6 ++--
 drivers/i2c/chips/isp1301_omap.c |2 +-
 5 files changed, 11 insertions(+), 47 deletions(-)

---

Atsushi Nemoto (1):
  i2c-gpio: Initialize adapter class

David Brownell (1):
  i2c/isp1301_omap: Build fix

Jean Delvare (1):
  i2c: Delete an outdated piece of documentation

Joe Perches (1):
  i2c: Add missing spaces in split log messages


Thanks,
-- 
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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.22.14 oops msg with commvault galaxy ?

[Fortier,Vincent [Montreal]]

 -Message d'origine-
 De : [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] De la part de 
 Fortier,Vincent [Montreal]
 
  -Message d'origine-
  De : Dhaval Giani [mailto:[EMAIL PROTECTED]
  
  On Tue, Dec 11, 2007 at 10:06:53PM +0100, Ingo Molnar wrote:
   
   * Fortier,Vincent [Montreal] [EMAIL PROTECTED] wrote:
   
 That has changed from /sys/kernel/uids/uid/cpu_share

Here is my config.

Maybie I should give it a shot without CFS at all and see what 
happends ?
 
 It got triggerred also using a 2.6.22.14:

Just to clarify... this is a non CFS kernel oops...

 [57560.396000] BUG: unable to handle kernel paging request at 
 virtual address 8000 [57560.396000]  printing eip:
 [57560.396000] c01d6c56
 [57560.396000] *pdpt = 08d02001
 [57560.396000] *pde = 
 [57560.396000] Oops:  [#34]
 [57560.396000] SMP
 [57560.396000] last sysfs file: 
 /devices/platform/floppy.0/uevent [57560.396000] Modules 
 linked in: xfs drbd cn nfs nfsd exportfs lockd nfs_acl sunrpc 
 ppdev parport_pc lp parport button ac battery ipv6 fuse 
 ide_cd ide_generic usbkbd usbmouse tsdev iTCO_wdt 
 iTCO_vendor_support psmouse e752x_edac edac_mc serio_raw 
 evdev pcspkr sg floppy shpchp pci_hotplug sr_mod cdrom ext3 
 jbd mbcache dm_mirror dm_snapshot dm_mod generic piix 
 ide_core tg3 ata_piix ehci_hcd uhci_hcd usbcore thermal 
 processor fan mptscsih mptbase megaraid_sas megaraid_mbox 
 megaraid_mm cciss aacraid
 [57560.396000] CPU:2
 [57560.396000] EIP:0060:[c01d6c56]Not tainted VLI
 [57560.396000] EFLAGS: 00010297   (2.6.22.14-etch-686-envcan #1)
 [57560.396000] EIP is at vsnprintf+0x2af/0x48c
 [57560.396000] eax: 8000   ebx:    ecx: 8000   edx:
 fffe
 [57560.396000] esi: edf37017   edi: edf09eac   ebp:    esp:
 edf09e4c
 [57560.396000] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
 [57560.396000] Process clBackup (pid: 31421, ti=edf08000 task=f7d36530
 task.ti=edf08000)
 [57560.396000] Stack: c852b000 1000 c0338c78 f895b56c 
 c0233bf5 c852b000 120c8fe8 edf37017
 [57560.396000]00c3bd08    
 c03354eb 0003 0017
 [57560.396000]c0376dc0 c852b000 c01d6eb4 edf09eac edf09eac
 c0233170 edf37017 c03354ea
 [57560.396000] Call Trace:
 [57560.396000]  [c0233bf5] dev_uevent+0x189/0x1e0 
 [57560.396000]  [c01d6eb4] sprintf+0x20/0x23 [57560.396000] 
  [c0233170] show_uevent+0xad/0xd5 [57560.396000]  
 [c0154f48] get_page_from_freelist+0x296/0x32d
 [57560.396000]  [c012e6f0] group_send_sig_info+0x12/0x56 
 [57560.396000]  [c0155031] __alloc_pages+0x52/0x294 
 [57560.396000]  [c02330c3] show_uevent+0x0/0xd5 
 [57560.396000]  [c0232c82] dev_attr_show+0x15/0x18 
 [57560.396000]  [c01a6979] sysfs_read_file+0x87/0xd8 
 [57560.396000]  [c0185f04] sys_getxattr+0x46/0x4e 
 [57560.396000]  [c01a68f2] sysfs_read_file+0x0/0xd8 
 [57560.396000]  [c016fe03] vfs_read+0xa6/0x128 
 [57560.396000]  [c01701ff] sys_read+0x41/0x67 
 [57560.396000]  [c0103d8a] syscall_call+0x7/0xb 
 [57560.396000]  === [57560.396000] Code: 
 74 24 28 73 03 c6 06 20 4d 46 85 ed 7f f1 e9 b9 00 00 00 8b 
 0f b8 79 e0 32 c0 8b 54 24 2c 81 f9 ff 0f 00 00 0f 46 c8 89 
 c8 eb 06 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 f6 44 24 
 30 10 89 c3 [57560.396000] EIP: [c01d6c56] 
 vsnprintf+0x2af/0x48c SS:ESP 0068:edf09e4c
 
   
   and also with CFS but without CONFIG_FAIR_GROUP_SCHED.
   
 
 Is it still required since it now does not seems to be CFS related?
 
  
  Hi Ingo,
  
  I am able to reproduce the oops here on my system with
  2.6.22.14 + CFS backport. I am not able to reproduce it with
  2.6.22.13 + CFS backport. I believe the CFS backport is 
 just exposing 
  the bug. Can't find an obvious culprit and am looking into 
 this issue.
  
  Vincent, could you please confirm if you are able to reproduce this 
  with
  2.6.22.13 + CFS?
 
 Using 2.6.13 + CFS v24 I was also able to reproduce the bug 
 (I already had one built in my depot without the 
 display_most-recently-opened_sysfs_file_name_when_oopsing.patc
 h).  So it looks like it is at least related to = 2.6.22.13 
 and probably not directly CFS related.  Note that to get a 
 oops on a 2.6.13 it seems to need a full backup since it 
 usually works with incremental.  The backup does start 
 properly then, in this case, at around 70% it oopsed.  Using
 2.6.22.14 it seems to oops right at startup.  Here is the 
 2.6.22.13 CFS v24 oops:

Again, just to clarify, I'm not even sure the backup worked at all using
a 2.6.22.13 CFS v24 since I already had a previous pending full backup
at 70% ... so it may simply had tried to finalize that one and crash
right at startup?

 [  170.152908] SGI XFS Quota Management subsystem [  
 170.168443] Filesystem drbd0: Disabling barriers, not 
 supported by the underlying device [  170.174964] XFS 
 mounting filesystem drbd0 [  170.232455] Ending clean XFS 
 mount for filesystem: drbd0 [  170.318614] Filesystem 
 drbd1: 

ip_rt_bug weirdness

[Thomas Egerer]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Hello *,

maybe it's my bad. Most probably! Even in that case I'd need someone to
point out the mistake to me!
I'm currently (trying) to write a transparent proxy application, using
libipq to capture packets + iptables' redirect mechanism.
The basic idea works as follows:
+---+  +---+  +---+
| S || P || D |
+---+ (1)  +---+  (2) +---+

(1) uses iptables' REDIRECT target; the received data is then forwarded,
using another socket connection (2)
(2) uses libipq to do some kind of SNAT and change the local source
address to S's address and vice versa for the incoming packets
from D

So far the theory. The application works fine, as long, as I do not
remap the source port (destination port, respectively) from P to D. Once
I enable the port remapping I get syslog messages like the following:
[ 7742.939471] ip_rt_bug: [S' IP] - [P's IP at (2)], ?
and a reset from P towards D, using exactly all the correct TCP
settings, except for the destination port, that is 1, sometimes 2, or 3.
I couldn't figure out, why.
By the way, the three-way-handshake works fine, the RSTs are generated
for the first packet to contain a TCP-payload. Also netstat tells me,
there is an established connection between P and D, but somehow (I
assume that this might be the trouble) looking for the corresponding
socket connection on P fails.
I'm totally puzzled why that happens. libipq reinjects the packets with
properly changed checksums and whatnot, yet the RSTs are generated.
I've also tried NF_REPEAT, instead of the NF_ACCEPT verdict. The
behavior remains identically.

Any ideas, anyone?

Thanks in advance

Thomas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHX9jgUGqFG0l5Kr0RAyKTAJ9qempDK//O0TrCwXgXzpdjBhW+QwCeJnUQ
udz08rqnHoFvkFF6q7a2C2s=
=DZhp
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry indirectory) (fwd)

[Salyzyn, Mark]

ACK, patch looks good. Thanks for composing this patch. Glad to hear of
successful test results.

Sincerely -- Mark Salyzyn

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Miquel 
 van Smoorenburg
. . .
 
 I just recompiled 2.6.23.9 with the 64 bit patch for dpt_i2o 
 and now it
 boots just fine.
 
 The patch is here:
 http://www.miquels.cistron.nl/linux/dpt_i2o-64bit-2.6.23.patch
 
 It's not the final version - it needs a few cleanups before it can be
 submitted, but perhaps you can test if it also works for you.
 
 Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 15/47] Minor fixes to mm/fault.c for CRIS.

[Jesper Nilsson]

On Wed, Dec 12, 2007 at 03:17:13AM -0800, Andrew Morton wrote:
 On Fri, 30 Nov 2007 13:59:57 +0100 Jesper Nilsson [EMAIL PROTECTED] wrote:
 
  @@ -360,7 +247,7 @@ do_page_fault(unsigned long address, struct pt_regs 
  *regs,
  up_read(mm-mmap_sem);
  printk(VM: killing process %s\n, tsk-comm);
  if (user_mode(regs))
  -   do_group_exit(SIGKILL);
  +   do_exit(SIGKILL);
 
 Is this change correct?

No, good catch, that's a change since we last imported to the internal tree.

/^JN - Jesper Nilsson
--
   Jesper Nilsson -- [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: [v4l-dvb-maintainer] build #340 failed for 2.6.24-rc5-g75b8c13 in linux/drivers/media/video/tuner.ko

[Michael Krufky]

Toralf Förster wrote:
 Hello,

 the build with the attached .config failed, make ends with:
 ...
   GZIParch/x86/boot/compressed/vmlinux.bin.gz
   LD  arch/x86/boot/compressed/piggy.o
   LD  arch/x86/boot/compressed/vmlinux
   OBJCOPY arch/x86/boot/vmlinux.bin
   HOSTCC  arch/x86/boot/tools/build
   BUILD   arch/x86/boot/bzImage
 Root device is (3, 8)
 Setup is 11320 bytes (padded to 11776 bytes).
 System is 1848 kB
 Kernel: arch/x86/boot/bzImage is ready  (#1)
   Building modules, stage 2.
   MODPOST 352 modules
 ERROR: tea5761_attach [drivers/media/video/tuner.ko] undefined!
 ERROR: tea5761_autodetection [drivers/media/video/tuner.ko] undefined!
 ERROR: tea5767_autodetection [drivers/media/video/tuner.ko] undefined!
 ERROR: tea5767_attach [drivers/media/video/tuner.ko] undefined!
 make[1]: *** [__modpost] Error 1
 make: *** [modules] Error 2

 The build was made with an old .config from kernel 2.6.24-rc2
 (where the build also failed) :
 $ make mrproper  cp oldconfig .config  make oldconfig  make

 Here's the config:

 [snip]

 CONFIG_VIDEO_TUNER=m
 CONFIG_VIDEO_TUNER_CUSTOMIZE=y
 # CONFIG_TUNER_MT20XX is not set
 CONFIG_TUNER_TDA8290=m
 CONFIG_TUNER_TEA5761=y
 CONFIG_TUNER_TEA5767=y
 CONFIG_TUNER_SIMPLE=m
   
Toralf,

It looks like the problem has something to do with VIDEO_TUNER=m while
both TUNER_TEA5761  TUNER_TEA5767 are set to 'y'.

I thought that we had already seen this issue and fixed it, but I guess
not :-/

One would think that this could be fixed by making TUNER_TEA5761 
TUNER_TEA5767 both depend on VIDEO_TUNER , but that would be wrong,
since each of those modules can be attached directly to a bridge driver
without tuner.ko being present at all (although this is not done in
practice right now, but it *is* the case with some other tuner drivers)

I'm going to have to think about this for a bit and do some
experimentation.  Thanks for reporting.

Regards,

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