Re: 2.6.24: Serial disabled in BIOS but serial modules still loaded (probably PnP related)
Michael H. Warfield wrote: On Sat, 2007-11-24 at 23:36 +0300, Andrey Borzenkov wrote: I have no COM port on notebook (without port replicator which I do not have) so COM is disabled in BIOS. No ttyS* is detected during boot (and no device created) but I just noticed that serial modules are still loaded. Well, this partially defeats the purpose of disabling COM port - the intention was to free resources by *not* loading unneeded modules ... This may have something to do with (ACPI) PnP which apparently believes COM is alive. Notebook is Toshiba Portege 4000. Nice... What's this then? 00:09 PNP0501 16550A-compatible serial port state = active io 0x3f8-0x3ff irq 5 This doesn't mean that a port (ie connector) is present. My notebook also has the electronics without the physical connector. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: I/O error, system hangs
On Sat, 2007-11-24 at 23:59 +0100, Laurent Riffard wrote: > Le 24.11.2007 14:26, James Bottomley a écrit : > > OK, could you post dmesgs again, please. I actually tested this > with an > > aic79xx card, and for me it does cause Domain Validation to succeed > > again. > > James, > > Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch "separates > the > BLOCK and QUIESCE states > correctly" (http://lkml.org/lkml/2007/11/24/8). > > How to reproduce : > - boot > - switch to a text console > - capture dmesg in a file, sync, etc. There are 3 I/O errors, but the > system does work. > - switch to X console, log in the Gnome Desktop, the system partially > hangs. > - switch back to a text console: dmesg(1) still works, it shows some > additonal I/O errors. At this point, any disk access makes the > system > completely hung. > > Additionnal data: > - the I/O errors always happen on the same blocks. > > plain text document attachment (dmesg-2.6.24-rc3-mm1-patched) [...] > [ 25.521256] scsi0 : pata_via > [ 25.521711] scsi1 : pata_via > [ 25.524089] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma > 0xb800 irq 14 > [ 25.524176] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma > 0xb808 irq 15 > [ 25.683141] ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100 > [ 25.683208] ata1.00: 78165360 sectors, multi 16: LBA > [ 25.683475] ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133 > [ 25.684116] ata1.01: 160086528 sectors, multi 16: LBA > [ 25.691127] ata1.00: configured for UDMA/100 > [ 25.699142] ata1.01: configured for UDMA/100 > [ 26.170860] ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-4165B, DL05, max > UDMA/33 > [ 26.171562] ata2.01: ATAPI: CD-950E/AKU, A4Q, max MWDMA2, CDB intr > [ 26.330839] ata2.00: configured for UDMA/33 > [ 26.490828] ata2.01: configured for MWDMA2 > [ 26.503014] scsi 0:0:0:0: Direct-Access ATA ST340016A > 3.75 PQ: 0 ANSI: 5 > [ 26.504670] scsi 0:0:1:0: Direct-Access ATA Maxtor 6Y080L0 > YAR4 PQ: 0 ANSI: 5 > [ 26.509842] scsi 1:0:0:0: CD-ROMHL-DT-ST DVDRAM > GSA-4165B DL05 PQ: 0 ANSI: 5 > [ 26.511673] scsi 1:0:1:0: CD-ROME-IDECD-950E/AKU > A4Q PQ: 0 ANSI: 5 [...] > [ 60.216113] sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > [ 60.216124] end_request: I/O error, dev sda, sector 16460 I think this one's quite easy: PATA devices in libata are queue depth 1 (since they don't do NCQ). Thus, they're peculiarly sensitive to the bug where we fail over queue depth requests. On the other hand, I don't see how a filesystem request is getting REQ_FAILFAST ... unless there's a bio or readahead issue involved. Anyway, could you try this patch: http://marc.info/?l=linux-scsi=119592627425498 Which should fix the queue depth issue, and see if the errors go away? Thanks, 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: [HIFN 00/03]: RNG support v2
On Sat, Nov 24, 2007 at 10:38:45PM -0800, Andrew Morton wrote:
> On Sun, 18 Nov 2007 22:32:52 +0100 (MET) Patrick McHardy <[EMAIL PROTECTED]>
> wrote:
>
> > These patches add support for using the HIFN rng.
>
> Dumb question: what is HIFN?
They make crypto hardware: www.hifn.com.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [HIFN 00/03]: RNG support v2
On Sun, 18 Nov 2007 22:32:52 +0100 (MET) Patrick McHardy <[EMAIL PROTECTED]> wrote: > These patches add support for using the HIFN rng. Dumb question: what is HIFN? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: forcedeth ethernet driver & Low power state
On Sun, 25 Nov 2007 03:52:33 +0100 Jeroen <[EMAIL PROTECTED]> wrote: > Hi, > > I'm migrating my server from windows 2003 server to Ubuntu, but I am > stumbling over the "Low Power State Link Speed" option for my NIC > (forcedeth) > > I need to disable this option in my windows driver otherwise the trough pout > is > horrible because the link fluctuates constantly from 100/1000. > > Anyway, my question is where and how can I turn off this feature for the > forcedeth driver? I've looked in the source and as far as I can tell there is > no > bootoption for this. There are some references noted in the code, but AFAIK > no setting. > > Any ideas? Thanks in advance! > (cc's added) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
On Sat, 17 Nov 2007 23:20:36 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote: > Completely reproducible... 2.6.23-rc3 kernel boots, and normal messages > are seen on console as far as disks found and partitions on each. However, > once /dev is populated and the boottime scripts attempt to check filesystem > status, no partitions on either of the two disks attached to the SCSI > controller are seen. Dropping into a single-user root shell confirms > the sudden "blindness": fdisk can't open /dev/sda. > > When I reboot on 2.6.24-rc2, everything works normally. > > System environment is Debian Etch. Both 2.6.24-rc2 and -rc3 were built > from the respective unaltered kernel.org source trees, using the same > kernel configuration modulo saying "no" to CONFIG_SENSORS_I5K_AMB and > CONFIG_PID_NS in -rc3. No problems with -rc3 on a x86 box. Could be something change in sysfs. Please double-check the config options, make sure that something important didn't get disabled. Failing that, it would be great if you could bisect this down to the offending commit. http://www.kernel.org/doc/local/git-quick.html has help. Richard, Ivan: have you seen anything like this? Meanwhile, I guess we should track this as another post-2.6.23 regression please. 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: ipmi_watchdog can not reset the kernel panic machine
(cc's added)
On Fri, 23 Nov 2007 20:28:41 -0800 (PST) [EMAIL PROTECTED] wrote:
> Build kernel-2.6.24-rc3. pmi_watchdog can not reset the kernel panic
> machine. The watchdog can never to record panic information to IPMI SEL.
>
> 1. I disable auto reset when kernel panic by echo "0" >
> /proc/sys/kernel/panic
>
> 2. modprobe ipmi_watchdog timeout=120 action=reset
>
> 3. Load a driver, the driver will call panic() when ioctl to call into
> the driver.
>
> 4. By ioctl call into the driver, panic the system.
>
> in wdog_panic_handler, I printk "ipmi_watchdog_state=WDOG_TIMEOUT_NONE"
> so, the watchdog can never to record panic information to IPMI SEL.
>
>
> static int wdog_panic_handler(struct notifier_block *this,
> unsigned long event,
> void *unused)
> {
> static int panic_event_handled = 0;
>
> /* On a panic, if we have a panic timeout, make sure to extend
> the watchdog timer to a reasonable value to complete the
> panic, if the watchdog timer is running. Plus the
> pretimeout is meaningless at panic time. */
> if (watchdog_user && !panic_event_handled &&
> ipmi_watchdog_state != WDOG_TIMEOUT_NONE) {
> /* Make sure we do this only once. */
> panic_event_handled = 1;
>
> timeout = 255;
> pretimeout = 0;
> panic_halt_ipmi_set_timeout();
> }
>
> return NOTIFY_OK;
> }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] USB_PERSIST
On Tue, 20 Nov 2007 17:04:32 -0700 "Raymano Garibaldi" <[EMAIL PROTECTED]> wrote: > Is there any other information that I can provide which might help in > resolving this bug? Let's cc the USB developers. > On 11/18/07, Raymano Garibaldi <[EMAIL PROTECTED]> wrote: > > The last time I tried this and it worked was 2.6.21. Below is a > > portion of the kernel log file where I had a USB storage device > > attached to the computer, then suspended the computer, while computer > > was suspended detached and reattached the USB storage device, and > > resumed the computer. > > > > > > Nov 18 23:07:42 myfaun Stopping tasks ... done. > > Nov 18 23:07:42 myfaun Suspending console(s) > > Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Synchronizing SCSI cache > > Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Stopping disk > > Nov 18 23:07:42 myfaun ACPI handle has no context! > > Nov 18 23:07:42 myfaun ACPI handle has no context! > > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1f.2 disabled > > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1f.1 disabled > > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.7 disabled > > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.3 disabled > > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.2 disabled > > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.1 disabled > > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.0 disabled > > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1b.0 disabled > > Nov 18 23:07:42 myfaun Disabling non-boot CPUs ... > > Nov 18 23:07:42 myfaun CPU 1 is now offline > > Nov 18 23:07:42 myfaun SMP alternatives: switching to UP code > > Nov 18 23:07:42 myfaun CPU1 is down > > Nov 18 23:07:42 myfaun Intel machine check architecture supported. > > Nov 18 23:07:42 myfaun Intel machine check reporting enabled on CPU#0. > > Nov 18 23:07:42 myfaun CPU0: Intel P4/Xeon Extended MCE MSRs (24) available > > Nov 18 23:07:42 myfaun CPU0: Thermal monitoring enabled > > Nov 18 23:07:42 myfaun Back to C! > > Nov 18 23:07:42 myfaun Enabling non-boot CPUs ... > > Nov 18 23:07:42 myfaun SMP alternatives: switching to SMP code > > Nov 18 23:07:42 myfaun Booting processor 1/1 eip 3000 > > Nov 18 23:07:42 myfaun Initializing CPU#1 > > Nov 18 23:07:42 myfaun Calibrating delay using timer specific > > routine.. 6004.38 BogoMIPS (lpj=10003815) > > Nov 18 23:07:42 myfaun CPU: After generic identify, caps: bfebfbff > > 2010 e49d 0001 > > Nov 18 23:07:42 myfaun monitor/mwait feature present. > > Nov 18 23:07:42 myfaun CPU: Trace cache: 12K uops, L1 D cache: 16K > > Nov 18 23:07:42 myfaun CPU: L2 cache: 2048K > > Nov 18 23:07:42 myfaun CPU: Physical Processor ID: 0 > > Nov 18 23:07:42 myfaun CPU: Processor Core ID: 1 > > Nov 18 23:07:42 myfaun CPU: After all inits, caps: bfebfbff 2010 > > b180 e49d 0001 > > Nov 18 23:07:42 myfaun Intel machine check architecture supported. > > Nov 18 23:07:42 myfaun Intel machine check reporting enabled on CPU#1. > > Nov 18 23:07:42 myfaun CPU1: Intel P4/Xeon Extended MCE MSRs (24) available > > Nov 18 23:07:42 myfaun CPU1: Thermal monitoring enabled > > Nov 18 23:07:42 myfaun CPU1: Intel(R) Pentium(R) D CPU 3.00GHz stepping 05 > > Nov 18 23:07:42 myfaun CPU1 is up > > Nov 18 23:07:42 myfaun ACPI: Unable to turn cooling device [dfe34dc8] 'off' > > Nov 18 23:07:42 myfaun Switched to high resolution mode on CPU 1 > > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:02.0[A] -> GSI 16 > > (level, low) -> IRQ 19 > > Nov 18 23:07:42 myfaun PM: Writing back config space on device > > :00:1b.0 at offset f (was 100, writing 105) > > Nov 18 23:07:42 myfaun PM: Writing back config space on device > > :00:1b.0 at offset 4 (was 4, writing fdff8004) > > Nov 18 23:07:42 myfaun PM: Writing back config space on device > > :00:1b.0 at offset 3 (was 0, writing 8) > > Nov 18 23:07:42 myfaun PM: Writing back config space on device > > :00:1b.0 at offset 1 (was 10, writing 12) > > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1b.0[A] -> GSI 16 > > (level, low) -> IRQ 19 > > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1b.0 to > > 64 > > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1d.0[A] -> GSI 23 > > (level, low) -> IRQ 18 > > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1d.0 to > > 64 > > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1d.1[B] -> GSI 19 > > (level, low) -> IRQ 17 > > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1d.1 to > > 64 > > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1d.2[C] -> GSI 18 > > (level, low) -> IRQ 16 > > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1d.2 to >
[PATCH] -mm (2.6.24-rc3-mm1) Smack using capabilities 32 and 33
From: Casey Schaufler <[EMAIL PROTECTED]>
This patch takes advantage of the increase in capability bits
to allocate capabilities for Mandatory Access Control. Whereas
Smack was overloading a previously allocated capability it is
now using a pair, one for overriding access control checks and
the other for changes to the MAC configuration.
The two capabilities allocated should be obvious in their intent.
The comments in capability.h are intended to make it clear that
there is no intention that implementations of MAC LSM modules
be any more constrained by the presence of these capabilities
than an implementation of DAC LSM modules are by the analogous
DAC capabilities.
Signed-off-by: Casey Schaufler <[EMAIL PROTECTED]>
---
The companion patch for libcap-2.02 is provided as an attachment.
The attachment is not a kernel patch, although it would be easy to
mistake it for one.
Thank you.
include/linux/capability.h | 20 +++-
security/smack/smack.h |8
security/smack/smack_lsm.c |8
security/smack/smackfs.c | 12 ++--
4 files changed, 29 insertions(+), 19 deletions(-)
diff -uprN -X linux-2.6.24-rc3-mm1-base/Documentation/dontdiff
linux-2.6.24-rc3-mm1-base/include/linux/capability.h
linux-2.6.24-rc3-mm1-smack/include/linux/capability.h
--- linux-2.6.24-rc3-mm1-base/include/linux/capability.h2007-11-22
01:51:36.0 -0800
+++ linux-2.6.24-rc3-mm1-smack/include/linux/capability.h 2007-11-24
11:26:51.0 -0800
@@ -314,6 +314,23 @@ typedef struct kernel_cap_struct {
#define CAP_SETFCAP 31
+/* Override MAC access.
+ The base kernel enforces no MAC policy.
+ An LSM may enforce a MAC policy, and if it does and it chooses
+ to implement capability based overrides of that policy, this is
+ the capability it should use to do so. */
+
+#define CAP_MAC_OVERRIDE 32
+
+/* Allow MAC configuration or state changes.
+ The base kernel requires no MAC configuration.
+ An LSM may enforce a MAC policy, and if it does and it chooses
+ to implement capability based checks on modifications to that
+ policy or the data required to maintain it, this is the
+ capability it should use to do so. */
+
+#define CAP_MAC_ADMIN33
+
/*
* Bit location of each capability (used by user-space library and kernel)
*/
@@ -334,7 +351,8 @@ typedef struct kernel_cap_struct {
| CAP_TO_MASK(CAP_DAC_OVERRIDE) \
| CAP_TO_MASK(CAP_DAC_READ_SEARCH) \
| CAP_TO_MASK(CAP_FOWNER) \
- | CAP_TO_MASK(CAP_FSETID))
+ | CAP_TO_MASK(CAP_FSETID) \
+ | CAP_TO_MASK(CAP_MAC_OVERRIDE))
#if _LINUX_CAPABILITY_U32S != 2
# error Fix up hand-coded capability macro initializers
diff -uprN -X linux-2.6.24-rc3-mm1-base/Documentation/dontdiff
linux-2.6.24-rc3-mm1-base/security/smack/smackfs.c
linux-2.6.24-rc3-mm1-smack/security/smack/smackfs.c
--- linux-2.6.24-rc3-mm1-base/security/smack/smackfs.c 2007-11-22
01:51:43.0 -0800
+++ linux-2.6.24-rc3-mm1-smack/security/smack/smackfs.c 2007-11-24
11:29:29.0 -0800
@@ -241,7 +241,7 @@ static ssize_t smk_write_load(struct fil
* No partial writes.
* Enough data must be present.
*/
- if (!capable(CAP_MAC_OVERRIDE))
+ if (!capable(CAP_MAC_ADMIN))
return -EPERM;
if (*ppos != 0)
return -EINVAL;
@@ -474,7 +474,7 @@ static ssize_t smk_write_cipso(struct fi
* No partial writes.
* Enough data must be present.
*/
- if (!capable(CAP_MAC_OVERRIDE))
+ if (!capable(CAP_MAC_ADMIN))
return -EPERM;
if (*ppos != 0)
return -EINVAL;
@@ -601,7 +601,7 @@ static ssize_t smk_write_doi(struct file
char temp[80];
int i;
- if (!capable(CAP_MAC_OVERRIDE))
+ if (!capable(CAP_MAC_ADMIN))
return -EPERM;
if (count >= sizeof(temp) || count == 0)
@@ -666,7 +666,7 @@ static ssize_t smk_write_direct(struct f
char temp[80];
int i;
- if (!capable(CAP_MAC_OVERRIDE))
+ if (!capable(CAP_MAC_ADMIN))
return -EPERM;
if (count >= sizeof(temp) || count == 0)
@@ -747,7 +747,7 @@ static ssize_t smk_write_ambient(struct
char in[SMK_LABELLEN];
char *smack;
- if (!capable(CAP_MAC_OVERRIDE))
+ if (!capable(CAP_MAC_ADMIN))
return -EPERM;
if (count >= SMK_LABELLEN)
@@ -840,7 +840,7 @@ static ssize_t smk_write_nltype(struct f
char *cp;
int i;
- if (!capable(CAP_MAC_OVERRIDE))
+ if (!capable(CAP_MAC_ADMIN))
return -EPERM;
if (count >= 40)
diff -uprN -X linux-2.6.24-rc3-mm1-base/Documentation/dontdiff
linux-2.6.24-rc3-mm1-base/security/smack/smack.h
"son of unifdef"
just for the entertainment value, i ran "make headers_install" on my x86 box using the newer "sunifdef" utility, which has the advantage that it will remove parts of compound preprocessor conditionals. here's the diff output between the old and the new generated header directories: diff -r include.orig/asm/posix_types_32.h include.sunifdef/asm/posix_types_32.h 42c42 < #if defined(__KERNEL__) || defined(__USE_ALL) --- > #if defined(__USE_ALL) 49c49 < #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) --- > #if !defined(__GLIBC__) || __GLIBC__ < 2 diff -r include.orig/linux/acct.h include.sunifdef/linux/acct.h 62d61 < #if !defined(CONFIG_M68K) || !defined(__KERNEL__) 64d62 < #endif diff -r include.orig/linux/ext2_fs.h include.sunifdef/linux/ext2_fs.h 240c240 < #if defined(__KERNEL__) || defined(__linux__) --- > #if defined(__linux__) diff -r include.orig/linux/ext3_fs.h include.sunifdef/linux/ext3_fs.h 295c295 < #if defined(__KERNEL__) || defined(__linux__) --- > #if defined(__linux__) diff -r include.orig/linux/nfs3.h include.sunifdef/linux/nfs3.h 99c99 < #if defined(__KERNEL__) || defined(NFS_NEED_KERNEL_TYPES) --- > #if defined(NFS_NEED_KERNEL_TYPES) diff -r include.orig/linux/socket.h include.sunifdef/linux/socket.h 19c19 < #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) --- > #if !defined(__GLIBC__) || __GLIBC__ < 2 diff -r include.orig/linux/soundcard.h include.sunifdef/linux/soundcard.h 1036c1036 < #if (!defined(__KERNEL__) && !defined(KERNEL) && !defined(INKERNEL) && !defined(_KERNEL)) || defined(USE_SEQ_MACROS) --- > #if !defined(KERNEL) && !defined(INKERNEL) && !defined(_KERNEL) || > defined(USE_SEQ_MACROS) diff -r include.orig/linux/stat.h include.sunifdef/linux/stat.h 5c5 < #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) --- > #if !defined(__GLIBC__) || __GLIBC__ < 2 diff -r include.orig/linux/videodev.h include.sunifdef/linux/videodev.h 17d16 < #if defined(CONFIG_VIDEO_V4L1_COMPAT) || !defined (__KERNEL__) 297d295 < #endif /* CONFIG_VIDEO_V4L1_COMPAT */ diff -r include.orig/video/edid.h include.sunifdef/video/edid.h 4d3 < #if !defined(__KERNEL__) || defined(CONFIG_X86) 11d9 < #endif in addition, sunifdef whined as follows: UNIFDEF include/linux/netlink.h sunifdef: /home/rpjday/k/git/include/linux/netlink.h: line 205: warning 0x02070: Garbage following preprocessor directive in "#if PAGE_SIZE < 8192UL" (#if line 152 depth 2) i'm guessing it's that "UL" suffix it doesn't like. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Bogus PCI vendor ID
On Mon, 19 Nov 2007 09:27:36 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > On Mon, 19 Nov 2007 12:22:20 - > "Simon Arlott" <[EMAIL PROTECTED]> wrote: > > > On Sat, November 17, 2007 18:40, Francois Romieu wrote: > > > Kai Ruhnau <[EMAIL PROTECTED]> : > > > [...] > > >> I have a problem with two of my PCI devices showing the wrong PCI vendor > > >> ID (0001) in vanilla kernels. > > Please try CONFIG_PCI_MMCONFIG=n - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Serial disabled in BIOS but serial modules still loaded (probably PnP related)
On Sat, 2007-11-24 at 23:36 +0300, Andrey Borzenkov wrote: > I have no COM port on notebook (without port replicator which I do not have) > so COM is disabled in BIOS. No ttyS* is detected during boot (and no device > created) but I just noticed that serial modules are still loaded. Well, this > partially defeats the purpose of disabling COM port - the intention was to > free resources by *not* loading unneeded modules ... > This may have something to do with (ACPI) PnP which apparently believes COM > is alive. > Notebook is Toshiba Portege 4000. Nice... What's this then? > 00:09 PNP0501 16550A-compatible serial port > state = active > io 0x3f8-0x3ff > irq 5 0x3f8-0x3ff is COM1 and a 16550A is the most common invocation of the vernerable serial port. I haven't seen a real 8250 in ages. the 16550 is an 8250 with larger FIFO's and better rates. Now, it's on IRQ5 instead of IRQ4 but that's all allocatable on PCI. Unless I'm missing something, it looks like you've got a COM port and it looks like it's active. Might be related to an IR port? > 00:0a SMCf010 SMC Fast Infrared Port > state = disabled > 00:0b PNP0401 ECP printer port > state = disabled : Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | [EMAIL PROTECTED] /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Kyle Moffett wrote: > On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote: >> Andrew Morgan wrote: >>> It feels to me as if a MAC "override capability" is, if true to its >>> name, extra to the MAC model; any MAC model that needs an 'override' >>> to function seems under-specified... SELinux clearly feels no need >>> for one, >> That's not quite right. More specifically, it already has one in the >> form of unconfined_t. AppArmor has a similar escape hatch in the "Ux" >> permission. Its not that they don't need one, it is that they already >> have one. They get to have one because they allow you to actually >> write a policy that is more nuanced than "process label must dominate >> object label". > Actually, a fully-secured strict-mode SELinux system will have no > unconfined_t processes; none of my test systems have any. Generally > "unconfined_t" is used for situations similar to what AppArmor was > designed for, where the only "interesting" security is that of the > daemon (which is properly labelled) and one or more of the users are > unconfined. Interesting. In a Targeted Policy, you do your policy administration from unconfined_t. But how do you administer a Strict Policy machine? I can think of 2 ways: * reboot to single user and hack away o hurts usability because you need physical presence to change policy, but is highly secure * there is some type that is tighter than unconfined_t but none the less has sufficient privilege to change policy o to me, this would be semantically equivalent to unconfined_t, because any rogue code or user with this type could then fabricate unconfined_t and do what they want > Even then "unconfined_t" is not an implicit part of the policy, it is > explicitly given the ability to take any action on any object by rules > in the policy, and it typically still falls under a few MLS labeling > restrictions even in the targeted policy. Which is more or less the distinction I was trying to draw between hierarchical systems (MLS) and policy systems (SELinux TE, AppArmor, etc.) that policy systems let you write yourself an escape hatch in policy, and MLS systems don't. Or at least they need to kludge something :) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] msi: set 'En' bit of MSI Mapping Capability on HT platform
According to the HyperTransport spec, 'En' indicate if the MSI Mapping is active. So it should be set when enable the MSI. The patch base on kernel 2.6.24-rc3 Signed-off-by: Andy Currid <[EMAIL PROTECTED]> Signed-off-by: Peer Chen <[EMAIL PROTECTED]> --- --- linux-2.6.24-rc3/include/linux/pci_ids.h.orig 2007-11-23 17:50:30.0 -0500 +++ linux-2.6.24-rc3/include/linux/pci_ids.h2007-11-23 17:50:42.0 -0500 @@ -1153,7 +1153,16 @@ #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_IDE 0x0265 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_SATA 0x0266 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_SATA20x0267 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC0 0x02F0 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC1 0x02F1 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC2 0x02F2 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC3 0x02F3 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC4 0x02F4 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC5 0x02F5 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC6 0x02F6 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC7 0x02F7 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SMBUS0x0368 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_MEMC 0x0369 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_IDE 0x036E #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA 0x037E #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA20x037F - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 1/2] msi: set 'En' bit of MSI Mapping Capability on HT platform
According to the HyperTransport spec, 'En' indicate if the MSI Mapping is
active. So it should be set when enable the MSI.
The patch base on kernel 2.6.24-rc3
Signed-off-by: Andy Currid <[EMAIL PROTECTED]>
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
---
--- linux-2.6.24-rc3/drivers/pci/msi.c.orig 2007-11-23 17:28:45.0
-0500
+++ linux-2.6.24-rc3/drivers/pci/msi.c 2007-11-23 17:50:59.0 -0500
@@ -20,6 +20,8 @@
#include
#include
+#include
+
#include "pci.h"
#include "msi.h"
@@ -290,6 +292,99 @@ void pci_restore_msi_state(struct pci_de
}
#endif /* CONFIG_PM */
+/*
+ * pci_enable_msi_ht_cap - Set the HT MSI mapping capability En bit of
+ * a device.
+ *
+ * @dev: pointer to the pci_dev data structure of MSI device function
+ */
+
+static int pci_enable_msi_ht_cap(struct pci_dev *dev)
+{
+ int pos;
+ u8 flags;
+
+ if ((pos = pci_find_ht_capability(dev, HT_CAPTYPE_MSI_MAPPING)) != 0)
+ {
+ pci_read_config_byte(dev, pos + HT_MSI_FLAGS, );
+ pci_write_config_byte(dev, pos + HT_MSI_FLAGS,
+ flags | HT_MSI_FLAGS_ENABLE);
+
+ printk(KERN_INFO "PCI: %s: enabled HT MSI mapping\n",
pci_name(dev));
+ }
+
+ return pos;
+}
+
+/**
+ * pci_check_msi_ht_cap - check for and enable the MSI mapping capability En
bit
+ * of devices or upstream bridge on HT-base system.
+ * @dev: pointer to the pci_dev data structure of MSI device function
+ *
+ * Search if device support ht MSI mapping capability on HT-base
+ * platform, if yes, enable the En bit. If device can't support MSI mapping,
+ * search the the upstream bridge for that capability, enable En bit find it,
+ * otherwise disable the MSI function if device and upstream bridge can't
+ * support MSI mapping capability.
+ **/
+
+static int pci_check_msi_ht_cap(struct pci_dev *dev)
+{
+ struct pci_dev *bridge_dev;
+
+ if (num_k8_northbridges != 0) { /* If the system is the HT-base */
+
+ /* Check for upstream NVIDIA host bridges */
+
+ if (((bridge_dev = pci_find_slot(0, 0)) != NULL) &&
+(bridge_dev->vendor == PCI_VENDOR_ID_NVIDIA)) {
+ switch (bridge_dev->device) {
+ case PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC0:
+ case PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC1:
+ case PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC2:
+ case PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC3:
+ case PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC4:
+ case PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC5:
+ case PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC6:
+ case PCI_DEVICE_ID_NVIDIA_NFORCE_C51_MEMC7:
+ case PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_MEMC:
+
+ pci_enable_msi_ht_cap(bridge_dev);
+
+ bridge_dev = NULL;
+ while ((bridge_dev =
pci_get_device(PCI_VENDOR_ID_NVIDIA,
+ PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_MEMC,
bridge_dev))
+ != NULL) {
+ pci_enable_msi_ht_cap(bridge_dev);
+ }
+
+ break;
+
+ default:
+ break;
+ }
+ }
+
+
+ if (pci_enable_msi_ht_cap(dev) != 0) {
+ return 0;
+ } else {
+ /* Get upstream bridge device handle */
+
+ bridge_dev = dev->bus->self;
+ while(bridge_dev != 0) {
+ if (pci_enable_msi_ht_cap(bridge_dev) != 0) {
+ return 0;
+ } else
+ bridge_dev = bridge_dev->bus->self;
+ }
+
+ return 1;
+ }
+ }
+ return 0;
+}
+
/**
* msi_capability_init - configure device's MSI capability structure
* @dev: pointer to the pci_dev data structure of MSI device function
@@ -510,6 +605,10 @@ int pci_enable_msi(struct pci_dev* dev)
status = pci_msi_check_device(dev, 1, PCI_CAP_ID_MSI);
if (status)
return status;
+
+ status = pci_check_msi_ht_cap(dev);
+ if(status)
+ return status;
WARN_ON(!!dev->msi_enabled);
@@ -606,6 +705,10 @@ int pci_enable_msix(struct pci_dev* dev,
if (status)
return status;
+ status = pci_check_msi_ht_cap(dev);
+ if(status)
+ return status;
+
pos = pci_find_capability(dev, PCI_CAP_ID_MSIX);
pci_read_config_word(dev, msi_control_reg(pos), );
nr_entries
forcedeth ethernet driver & Low power state
Hi, I'm migrating my server from windows 2003 server to Ubuntu, but I am stumbling over the "Low Power State Link Speed" option for my NIC (forcedeth) I need to disable this option in my windows driver otherwise the trough pout is horrible because the link fluctuates constantly from 100/1000. Anyway, my question is where and how can I turn off this feature for the forcedeth driver? I've looked in the source and as far as I can tell there is no bootoption for this. There are some references noted in the code, but AFAIK no setting. Any ideas? Thanks in advance! -- Jeroen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
Date: Sun, 25 Nov 2007 03:02:20 +0100
Subject: [PATCH] IP22ZILOG: fix lockup and sysrq
- fix lockup when switching from early console to real console
- make sysrq reliable
- fix panic, if sysrq is issued before console is opened
Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
---
arch/mips/sgi-ip22/ip22-setup.c | 19 ---
drivers/serial/ip22zilog.c | 247 +--
include/linux/serial_core.h |2 +-
3 files changed, 107 insertions(+), 161 deletions(-)
diff --git a/arch/mips/sgi-ip22/ip22-setup.c b/arch/mips/sgi-ip22/ip22-setup.c
index 174f09e..5f389ee 100644
--- a/arch/mips/sgi-ip22/ip22-setup.c
+++ b/arch/mips/sgi-ip22/ip22-setup.c
@@ -31,25 +31,6 @@
unsigned long sgi_gfxaddr;
EXPORT_SYMBOL_GPL(sgi_gfxaddr);
-/*
- * Stop-A is originally a Sun thing that isn't standard on IP22 so to avoid
- * accidents it's disabled by default on IP22.
- *
- * FIXME: provide a mechanism to change the value of stop_a_enabled.
- */
-int stop_a_enabled;
-
-void ip22_do_break(void)
-{
- if (!stop_a_enabled)
- return;
-
- printk("\n");
- ArcEnterInteractiveMode();
-}
-
-EXPORT_SYMBOL(ip22_do_break);
-
extern void ip22_be_init(void) __init;
void __init plat_mem_setup(void)
diff --git a/drivers/serial/ip22zilog.c b/drivers/serial/ip22zilog.c
index f3257f7..9c95bc0 100644
--- a/drivers/serial/ip22zilog.c
+++ b/drivers/serial/ip22zilog.c
@@ -45,8 +45,6 @@
#include "ip22zilog.h"
-void ip22_do_break(void);
-
/*
* On IP22 we need to delay after register accesses but we do not need to
* flush writes.
@@ -81,12 +79,9 @@ struct uart_ip22zilog_port {
#define IP22ZILOG_FLAG_REGS_HELD 0x0040
#define IP22ZILOG_FLAG_TX_STOPPED 0x0080
#define IP22ZILOG_FLAG_TX_ACTIVE 0x0100
+#define IP22ZILOG_FLAG_RESET_DONE 0x0200
- unsigned intcflag;
-
- /* L1-A keyboard break state. */
- int kbd_id;
- int l1_down;
+ unsigned inttty_break;
unsigned char parity_mask;
unsigned char prev_status;
@@ -250,13 +245,26 @@ static void ip22zilog_maybe_update_regs(struct
uart_ip22zilog_port *up,
}
}
-static void ip22zilog_receive_chars(struct uart_ip22zilog_port *up,
- struct zilog_channel *channel)
+#define Rx_BRK 0x0100 /* BREAK event software flag. */
+#define Rx_SYS 0x0200 /* SysRq event software flag. */
+
+static struct tty_struct *ip22zilog_receive_chars(struct uart_ip22zilog_port
*up,
+ struct zilog_channel *channel)
{
- struct tty_struct *tty = up->port.info->tty;/* XXX info==NULL? */
+ struct tty_struct *tty;
+ unsigned char ch, flag;
+ unsigned int r1;
+
+ tty = NULL;
+ if (up->port.info != NULL &&
+ up->port.info->tty != NULL)
+ tty = up->port.info->tty;
- while (1) {
- unsigned char ch, r1, flag;
+ for (;;) {
+ ch = readb(>control);
+ ZSDELAY();
+ if (!(ch & Rx_CH_AV))
+ break;
r1 = read_zsreg(channel, R1);
if (r1 & (PAR_ERR | Rx_OVR | CRC_ERR)) {
@@ -265,43 +273,26 @@ static void ip22zilog_receive_chars(struct
uart_ip22zilog_port *up,
ZS_WSYNC(channel);
}
- ch = readb(>control);
- ZSDELAY();
-
- /* This funny hack depends upon BRK_ABRT not interfering
-* with the other bits we care about in R1.
-*/
- if (ch & BRK_ABRT)
- r1 |= BRK_ABRT;
-
ch = readb(>data);
ZSDELAY();
ch &= up->parity_mask;
- if (ZS_IS_CONS(up) && (r1 & BRK_ABRT)) {
- /* Wait for BREAK to deassert to avoid potentially
-* confusing the PROM.
-*/
- while (1) {
- ch = readb(>control);
- ZSDELAY();
- if (!(ch & BRK_ABRT))
- break;
- }
- ip22_do_break();
- return;
- }
+ /* Handle the null char got when BREAK is removed. */
+ if (!ch)
+ r1 |= up->tty_break;
/* A real serial line, record the character and status. */
flag = TTY_NORMAL;
up->port.icount.rx++;
- if (r1 & (BRK_ABRT | PAR_ERR | Rx_OVR | CRC_ERR)) {
- if (r1 & BRK_ABRT) {
- r1 &= ~(PAR_ERR | CRC_ERR);
+ if
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote: Andrew Morgan wrote: It feels to me as if a MAC "override capability" is, if true to its name, extra to the MAC model; any MAC model that needs an 'override' to function seems under-specified... SELinux clearly feels no need for one, That's not quite right. More specifically, it already has one in the form of unconfined_t. AppArmor has a similar escape hatch in the "Ux" permission. Its not that they don't need one, it is that they already have one. They get to have one because they allow you to actually write a policy that is more nuanced than "process label must dominate object label". Actually, a fully-secured strict-mode SELinux system will have no unconfined_t processes; none of my test systems have any. Generally "unconfined_t" is used for situations similar to what AppArmor was designed for, where the only "interesting" security is that of the daemon (which is properly labelled) and one or more of the users are unconfined. Even then "unconfined_t" is not an implicit part of the policy, it is explicitly given the ability to take any action on any object by rules in the policy, and it typically still falls under a few MLS labeling restrictions even in the targeted policy. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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, 4GB RAM, swiotlb, r8169, out of space
On Sunday 25 November 2007 01:27:54 Francois Romieu wrote:
> Francois Romieu <[EMAIL PROTECTED]> :
> > Alistair John Strachan <[EMAIL PROTECTED]> :
> > [...]
> >
> > > The "choke" affects other devices on the system too, notably libata,
> > > which does not recover gracefully. In my logs, I see a stream of:
> > >
> > > DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0
> > > DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0
> >
> > You are using jumbo frames, aren't you ?
>
> See below for my late night crap. At least it should avoid the driver
> issuing Rx/Tx DMA with the single static buffer of lib/swiotlb.c
> (io_tlb_overflow_buffer). Ghee.
No improvement. It might be possible to reproduce the problem on your end if
you add iommu support and force enable the swiotlb (which should be possible
even with <4GB RAM).
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 1f647b9..72a7370 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -2262,10 +2262,16 @@ static struct sk_buff *rtl8169_alloc_rx_skb(struct
> pci_dev *pdev, mapping = pci_map_single(pdev, skb->data, rx_buf_sz,
>PCI_DMA_FROMDEVICE);
>
> + if (pci_dma_mapping_error(mapping))
> + goto err_kfree_skb;
> +
> rtl8169_map_to_asic(desc, mapping, rx_buf_sz);
> out:
> return skb;
>
> +err_kfree_skb:
> + dev_kfree_skb(skb);
> + skb = NULL;
> err_out:
> rtl8169_make_unusable_by_asic(desc);
> goto out;
> @@ -2486,6 +2492,7 @@ static int rtl8169_xmit_frags(struct rtl8169_private
> *tp, struct sk_buff *skb, dma_addr_t mapping;
> u32 status, len;
> void *addr;
> + int rc;
>
> entry = (entry + 1) % NUM_TX_DESC;
>
> @@ -2493,6 +2500,22 @@ static int rtl8169_xmit_frags(struct rtl8169_private
> *tp, struct sk_buff *skb, len = frag->size;
> addr = ((void *) page_address(frag->page)) + frag->page_offset;
> mapping = pci_map_single(tp->pci_dev, addr, len,
> PCI_DMA_TODEVICE);
> + rc = pci_dma_mapping_error(mapping);
> + if (unlikely(rc < 0)) {
> + while (cur_frag-- > 0) {
> + frag = info->frags + cur_frag;
> + entry = (entry - 1) % NUM_TX_DESC;
> + txd = tp->TxDescArray + entry;
> + len = frag->size;
> + mapping = le64_to_cpu(txd->addr);
> + pci_unmap_single(tp->pci_dev, mapping, len,
> + PCI_DMA_TODEVICE);
> + txd->opts1 = 0x00;
> + txd->opts2 = 0x00;
> + txd->addr = 0x00;
> + }
> + return rc;
> + }
>
> /* anti gcc 2.95.3 bugware (sic) */
> status = opts1 | len | (RingEnd * !((entry + 1) % NUM_TX_DESC));
> @@ -2534,13 +2557,13 @@ static inline u32 rtl8169_tso_csum(struct sk_buff
> *skb, struct net_device *dev) static int rtl8169_start_xmit(struct sk_buff
> *skb, struct net_device *dev) {
> struct rtl8169_private *tp = netdev_priv(dev);
> - unsigned int frags, entry = tp->cur_tx % NUM_TX_DESC;
> + unsigned int entry = tp->cur_tx % NUM_TX_DESC;
> struct TxDesc *txd = tp->TxDescArray + entry;
> void __iomem *ioaddr = tp->mmio_addr;
> dma_addr_t mapping;
> u32 status, len;
> u32 opts1;
> - int ret = NETDEV_TX_OK;
> + int frags, ret = NETDEV_TX_OK;
>
> if (unlikely(TX_BUFFS_AVAIL(tp) < skb_shinfo(skb)->nr_frags)) {
> if (netif_msg_drv(tp)) {
> @@ -2557,7 +2580,11 @@ static int rtl8169_start_xmit(struct sk_buff *skb,
> struct net_device *dev) opts1 = DescOwn | rtl8169_tso_csum(skb, dev);
>
> frags = rtl8169_xmit_frags(tp, skb, opts1);
> - if (frags) {
> + if (frags < 0) {
> + printk(KERN_ERR "%s: PCI mapping failure (%d).\n", dev->name,
> +frags);
> + goto err_busy;
> + } else if (frags > 0) {
> len = skb_headlen(skb);
> opts1 |= FirstFrag;
> } else {
> @@ -2605,6 +2632,7 @@ out:
>
> err_stop:
> netif_stop_queue(dev);
> +err_busy:
> ret = NETDEV_TX_BUSY;
> err_update_stats:
> dev->stats.tx_dropped++;
--
Cheers,
Alistair.
137/1 Warrender Park Road, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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, 4GB RAM, swiotlb, r8169, out of space
On Sunday 25 November 2007 00:25:10 Francois Romieu wrote: > Alistair John Strachan <[EMAIL PROTECTED]> : > [...] > > > The "choke" affects other devices on the system too, notably libata, > > which does not recover gracefully. In my logs, I see a stream of: > > > > DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0 > > DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0 > > You are using jumbo frames, aren't you ? Yes, 7200 byte frames. I'll certainly try out your patch and report back. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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, 4GB RAM, swiotlb, r8169, out of space
Francois Romieu <[EMAIL PROTECTED]> :
> Alistair John Strachan <[EMAIL PROTECTED]> :
> [...]
> > The "choke" affects other devices on the system too, notably libata, which
> > does not recover gracefully. In my logs, I see a stream of:
> >
> > DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0
> > DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0
>
> You are using jumbo frames, aren't you ?
See below for my late night crap. At least it should avoid the driver
issuing Rx/Tx DMA with the single static buffer of lib/swiotlb.c
(io_tlb_overflow_buffer). Ghee.
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 1f647b9..72a7370 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2262,10 +2262,16 @@ static struct sk_buff *rtl8169_alloc_rx_skb(struct
pci_dev *pdev,
mapping = pci_map_single(pdev, skb->data, rx_buf_sz,
PCI_DMA_FROMDEVICE);
+ if (pci_dma_mapping_error(mapping))
+ goto err_kfree_skb;
+
rtl8169_map_to_asic(desc, mapping, rx_buf_sz);
out:
return skb;
+err_kfree_skb:
+ dev_kfree_skb(skb);
+ skb = NULL;
err_out:
rtl8169_make_unusable_by_asic(desc);
goto out;
@@ -2486,6 +2492,7 @@ static int rtl8169_xmit_frags(struct rtl8169_private *tp,
struct sk_buff *skb,
dma_addr_t mapping;
u32 status, len;
void *addr;
+ int rc;
entry = (entry + 1) % NUM_TX_DESC;
@@ -2493,6 +2500,22 @@ static int rtl8169_xmit_frags(struct rtl8169_private
*tp, struct sk_buff *skb,
len = frag->size;
addr = ((void *) page_address(frag->page)) + frag->page_offset;
mapping = pci_map_single(tp->pci_dev, addr, len,
PCI_DMA_TODEVICE);
+ rc = pci_dma_mapping_error(mapping);
+ if (unlikely(rc < 0)) {
+ while (cur_frag-- > 0) {
+ frag = info->frags + cur_frag;
+ entry = (entry - 1) % NUM_TX_DESC;
+ txd = tp->TxDescArray + entry;
+ len = frag->size;
+ mapping = le64_to_cpu(txd->addr);
+ pci_unmap_single(tp->pci_dev, mapping, len,
+PCI_DMA_TODEVICE);
+ txd->opts1 = 0x00;
+ txd->opts2 = 0x00;
+ txd->addr = 0x00;
+ }
+ return rc;
+ }
/* anti gcc 2.95.3 bugware (sic) */
status = opts1 | len | (RingEnd * !((entry + 1) % NUM_TX_DESC));
@@ -2534,13 +2557,13 @@ static inline u32 rtl8169_tso_csum(struct sk_buff *skb,
struct net_device *dev)
static int rtl8169_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
- unsigned int frags, entry = tp->cur_tx % NUM_TX_DESC;
+ unsigned int entry = tp->cur_tx % NUM_TX_DESC;
struct TxDesc *txd = tp->TxDescArray + entry;
void __iomem *ioaddr = tp->mmio_addr;
dma_addr_t mapping;
u32 status, len;
u32 opts1;
- int ret = NETDEV_TX_OK;
+ int frags, ret = NETDEV_TX_OK;
if (unlikely(TX_BUFFS_AVAIL(tp) < skb_shinfo(skb)->nr_frags)) {
if (netif_msg_drv(tp)) {
@@ -2557,7 +2580,11 @@ static int rtl8169_start_xmit(struct sk_buff *skb,
struct net_device *dev)
opts1 = DescOwn | rtl8169_tso_csum(skb, dev);
frags = rtl8169_xmit_frags(tp, skb, opts1);
- if (frags) {
+ if (frags < 0) {
+ printk(KERN_ERR "%s: PCI mapping failure (%d).\n", dev->name,
+ frags);
+ goto err_busy;
+ } else if (frags > 0) {
len = skb_headlen(skb);
opts1 |= FirstFrag;
} else {
@@ -2605,6 +2632,7 @@ out:
err_stop:
netif_stop_queue(dev);
+err_busy:
ret = NETDEV_TX_BUSY;
err_update_stats:
dev->stats.tx_dropped++;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Problem with ufs nextstep in 2.6.18 (debian)
This fixes only symptom, not illness. This check represent what code think about filesystem layout. On what actually kind of UFS system did you test this patch? When I sometime ago fixed similar issue for openstep ufs, actully this was darwin's ufs which has the same layout, I just set s_dirblksize to right value, may be for UFS_MOUNT_UFSTYPE_NEXTSTEP, UFS_MOUNT_UFSTYPE_NEXTSTEP_CD you need do the same, see TODO items in fs/ufs/super.c. -- /Evgeniy Your right; I was using the NextStep ufstype on an OpenStep HD. I have now checked an old (pre NS 3.3) floppy and a NS 3.3 CDROM and they both need a s_dirblksize of 1024, just as the OpenStep filesystem does. For the floppies, one can just use the OpenStep option, but for a NextStep CDROM, the right s_dirblksize is crucial. I would suggest changing both. Thanks for the response, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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, 4GB RAM, swiotlb, r8169, out of space
Alan Cox <[EMAIL PROTECTED]> :
[...]
> You seem to have a leak, which actually isn't suprising
>
> rtl8169_xmit_frags allocates a set of maps for a fragmented packet
>
> rtl8169_start_xmit allocates a buffer
>
> When we finish the transit we free the main buffer (always using skb->len
> when sometimes its skb->headlne. We don't seem to free the fragment
> buffers at all.
> Looks like the unmap path for fragmented packets is broken with any kind
> of iommu
Are you referring to the pci_unmap part ?
There is a 1:1 correspondance between a Tx descriptor entry and
{an unfragmented skb or a fragment of a skb}. Afaiks rtl8169_unmap_tx_skb()
is issued for each Tx descriptor entry, be it after a Tx completion irq or
a general Tx ring cleanup.
I'll read it again after some sleep but the leak does not seem clear to me.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
NFSv3 bug: F_SETLEASE/F_WRLCK active on file causes it to appear modified over NVSv3 mount
<<< No Message Collected >>> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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, 4GB RAM, swiotlb, r8169, out of space
> when these messages appear, removing r8169 would appear to be key. Indeed, if > there is no significant libata activity, the problem still occurs on the NIC > within approximately the same amount of transfer. You seem to have a leak, which actually isn't suprising rtl8169_xmit_frags allocates a set of maps for a fragmented packet rtl8169_start_xmit allocates a buffer When we finish the transit we free the main buffer (always using skb->len when sometimes its skb->headlne. We don't seem to free the fragment buffers at all. Looks like the unmap path for fragmented packets is broken with any kind of iommu Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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, 4GB RAM, swiotlb, r8169, out of space
Alistair John Strachan <[EMAIL PROTECTED]> : [...] > The "choke" affects other devices on the system too, notably libata, which > does not recover gracefully. In my logs, I see a stream of: > > DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0 > DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0 You are using jumbo frames, aren't you ? -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
[ I removed Frans from cc: since it is off-topic to the original bugreport ]
On Saturday 24 November 2007, Rafael J. Wysocki wrote:
> On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> [--snip--]
> > Rafael, I see that you've filled a bug for this bugreport into kernel
> > bugzilla tracker (one day after the bugreport):
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=9442
> >
> > Since we try to address regressions with the highest priority in the
> > IDE-land (and usually they get fixed quickly) I would strongly prefer to
> > use bugzilla only for long-term bugs and avoid the needless bureaucracy.
>
> As a rule, I put all of the reported regressions into the Bugzilla early. You
> are not required to use these entries for tracking the bugs, though. If you
[ I really don't think that the recent push from both Andrew and you in
bugzilla direction is a good thing... ]
There is a mix of technical and psychological issues with using bugzilla:
* Interface for filling bugs is a joke:
- help for "Product" selection is mediocre
("IO/Storage:" -> "Bugs related to IO")
- there is no help for "Componenet" selection
- "Some basic debugging hints" are not there
- "Kernel version" given by reporter should be checked against the latest
kernel version and if not matching there should be a kind request to
retest with the latest kernel
- it should be strongly suggested to attach dmesg output and kernel config
- zillion other little improvements...
[ The average bug quality is not very high (bugs often lack critical
information) and this is really not reporters' fault! The interface
should be kept as simple as possible but if the reporter wants to
find some help and hints they should be there. ]
* Bugs that sit in NEEDINFO state for more than i.e. one month should be
automatically closed.
* After each major kernel release bugzilla should send a kind request for
retesting to all open bugs.
* You can't close/reject bugs by email.
* There is "Assigned-to:" field which is described as "This is the person in
charge of resolving the bug." in bugzilla's help so people get assumptions
that there is somebody who is supposed to handle the bug and that this
person should be actively working on it. Both assumptions may be invalid
(orhpaned drivers, there are more high priority bugs etc.). OTOH mailing
list doesn't give such assumptions and encourages more active attitudes
of bugreporters.
[ also compare this with "Maintained" definition in MAINTAINERS file ]
* From maintainer/developer POV you really want to track bugs in public
(mailing list) so other people can jump in and help.
[ It is also important that the other developers see that you are active. ]
* We want bug tracking the other way around: everything goes through mailing
list first (including bugs filled to the bug tracker) and if not fixed
quickly, somebody (maintainer of the given part of code or a higher level
maintainer) replies cc:ing bugzilla so the new bug entry is added.
Also this way we fix trivial/easy/medium bugs ASAP or reject invalid ones
without any bugzilla overhead. We also add a new patch description tags:
- "Fixes-bug:" tag with reference to the original discussion
and
- "Fixes-commit:" tag with reference to the kernel commit
which are automatically snooped by bugzilla from git so we keep info about
fixed bugs/regression for statistics, bugs history and to aid -stable team
in their efforts.
[ This is just a blurry sketch of the desired workflow but please note how
this is different from just assigning your component to the mailing list
address which should already be possible. ]
* Last but not least our bugzilla just looks ugly (it is _very_ important,
I feel disgusted each time I have to work with it, OTOH I love using
gitweb - you get the idea).
Sigh, I've just realized that comparing to source code control we are in
the "stone-age" when it comes to bug tracking. Hmm, what about switching
to some proprietary bug tracking system just to talk Linus into writing
a superior one? ;-)
> don't want to, just leave the entry as is and I'll close it when the fix is in
> the Linus' tree.
> > Therefore I kindly ask you to defer filling bugs for new bugreports for
> > a week or two, and give us some time to react (and always ping me about
> > the bugreport status before filling bugzilla entry).
>
> Well, I thought you'd get an email from the Bugzilla, but of course I can
> notify
> you directly about reported regressions related to IDE.
I do get mails from bugzilla so if you are going to assign these bugs to
yourself and track them, then no need to notify me.
[ I also regularly read your regressions list. ]
> > The alternative solution would be that you fill all new bugreports but
> > then please assign them to yourself and track their status (if after two
> > weeks the problem is not fixed feel free to reassign
2.6.24-rc3, 4GB RAM, swiotlb, r8169, out of space
Hi, I have recently assembled a Core 2 Duo system with 4GB RAM and I believe there might be a bug in the r8169 driver in >4GB RAM configurations. Initially I can use one of two active r8169 NICs on the motherboard with this quantity of RAM with other devices, without issue. But after some amount of data (generally about 50MB), no more network packets are sent/received. The "choke" affects other devices on the system too, notably libata, which does not recover gracefully. In my logs, I see a stream of: DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0 DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0 The device :04:00.0 corresponds to one of the r8169s. The reason I believe r8169 is at fault is that I was doing a rebuild of my RAID5 across 3 SATA drives via libata's ahci driver, and transferring over the network. When the "choke" occurred the RAID sync stopped, libata errors were seen, and I simply did a "ifconfig br0 down" (which contained the r8169) and the messages went away. Bringing the NIC up again would see some initial functionality then very rapidly it would go back to the same error messages. The Intel chipset I am using does not support any kind of hardware IOMMU, so I am forced to use swiotlb in a 4GB RAM configuration. In an attempt to delay the failures, I used the swiotlb option to increase the swiotlb's page allocation with "swiotlb=65536" (which seems to correspond to a 256MB bounce buffer). Assuming both libata and r8169 use the swiotlb, and both systems are impaired when these messages appear, removing r8169 would appear to be key. Indeed, if there is no significant libata activity, the problem still occurs on the NIC within approximately the same amount of transfer. This option delays the failure for some time but it will happen eventually, which makes me suspicious that maybe the driver is somehow pinning an area of the buffer and not releasing it. (I hunted bugzilla for reports similar to this one, but couldn't find anything.) Having tested the r8169 driver on an AMD system I did not experience the same problems with 4GB RAM, so this could be a bug specific to swiotlb. I would have added more people to CC but I have no idea who might be responsible. Andrew, I've added you just in case you're aware of other similar reports (maybe r8169 on big iron) and have anybody from the sw-iommu camp that could be added to CC. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[CFT][PATCH] proc_net: Remove userspace visible changes.
Ok. I have kicked around a lot implementation ideas and took a good hard
look at my /proc/net implementation. The patch below should close all
of the holes with /proc/net that I am aware of.
Bind mounts work and properly capture /proc/net/
stat of /proc/net and /proc/net/ return the same information.
cd /proc/net/ ; ls .. works
The dentry has the proper parent and no longer appears deleted.
As well as few more theoretical cases I have been able to imagine,
like open("/proc/net", O_NOFOLLOW | O_DIRECTORY) getdents...
Please take a look and kick this patch around. I don't expect anyone
to find any issues but a few more eyeballs before I send this
along to Linus would be appreciated. Thanks.
From: Eric W. Biederman <[EMAIL PROTECTED]>
Subject: [PATCH] proc_net: Remove userspace visible changes.
This patch fixes some bugs in corner cases of the /proc/net
implementation.
In proc_net_shadow_dentry.
- Set the parent dentry properly.
- Make the dentry appear hashed so .. works.
Remove the unreachable proc_net_lookup.
Implement proc_net_getattr to complete the
set of implemented inode operations.
Implement proc_net_open which changes the directory we
are openting to remove the need to implement any other
file operations.
Add a big fat comment on how /proc/net works to make it
easier for someone else to look at and understand this code.
This patch should remove the last of the accidental user visible artifacts
that arose from adding network namespace support to /proc/net.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
fs/proc/proc_net.c | 116 +--
1 files changed, 93 insertions(+), 23 deletions(-)
diff --git a/fs/proc/proc_net.c b/fs/proc/proc_net.c
index 131f9c6..b0b4b3f 100644
--- a/fs/proc/proc_net.c
+++ b/fs/proc/proc_net.c
@@ -50,24 +50,69 @@ struct net *get_proc_net(const struct inode *inode)
}
EXPORT_SYMBOL_GPL(get_proc_net);
+/*
+ * The contents of the files under /proc/net depend on which network
+ * namespace you are in.
+ *
+ * This implementation relies on the following properties.
+ *
+ * - Each network namespaces has it's own /proc/net dcache tree.
+ * - A directory with a follow_link method never calls lookup
+ * - It is possible in ->open to competely change which underlying
+ * filesystem, path, and inode the struct file refers to.
+ * - A dcache entry with DCACHE_UNHASHED clear and pprev set
+ * appares hashed (and thus valid) to the dcache.
+ *
+ * To give each network namespace it's own /proc/net directory
+ * in a manner transparent to user space (and not requiring /proc)
+ * be remounted we do the following things:
+ *
+ * Keep a different dentry tree for each network namespace under
+ * /proc/net.
+ *
+ * Have the root of the /proc/net dentry tree be a ``unhashed''
+ * dentry with it's root pointing at the /proc dentry. Making
+ * it appear in parallel with the normal /proc/net.
+ *
+ * Redirect all opens of the normal /proc/net to the one appropriate
+ * for the opening process in ->open.
+ *
+ * Redirect all directory traversals onto the appropriate /proc/net
+ * with a follow_link method.
+ *
+ * Wrap all other applicable inode operations so they appear to
+ * happen not on the normal /proc/net but on the network namespace
+ * specific one.
+ *
+ * Currently we can use a bind mount inside a network namespace
+ * to /proc/net visible to processes outside that network namespace.
+ * Long term /proc/net should migrate to /proc//net removing
+ * the need for the bind mount for monitoring processes.
+ */
+
static struct proc_dir_entry *proc_net_shadow;
-static struct dentry *proc_net_shadow_dentry(struct dentry *parent,
- struct proc_dir_entry *de)
+static struct dentry *proc_net_shadow_dentry(struct net *net,
+struct dentry *dentry)
{
+ struct proc_dir_entry *de = net->proc_net;
struct dentry *shadow = NULL;
struct inode *inode;
if (!de)
goto out;
de_get(de);
- inode = proc_get_inode(parent->d_inode->i_sb, de->low_ino, de);
+ inode = proc_get_inode(dentry->d_sb, de->low_ino, de);
if (!inode)
goto out_de_put;
- shadow = d_alloc_name(parent, de->name);
+ shadow = d_alloc(dentry->d_parent, >d_name);
if (!shadow)
goto out_iput;
- shadow->d_op = parent->d_op; /* proc_dentry_operations */
+ shadow->d_op = dentry->d_op; /* proc_dentry_operations */
d_instantiate(shadow, inode);
+
+ /* Make the dentry looked hashed */
+ shadow->d_hash.pprev = >d_hash.next;
+ shadow->d_flags &= ~DCACHE_UNHASHED;
out:
return shadow;
out_iput:
@@ -77,36 +122,36 @@ out_de_put:
goto out;
}
-static void *proc_net_follow_link(struct dentry *parent, struct nameidata *nd)
+static void *proc_net_follow_link(struct dentry *dentry, struct
[PATCH 3/3] build system: section garbage collection - main part
On Saturday 24 November 2007 15:14, Denys Vlasenko wrote:
> 3.gc
> The meat of the patchset is here.
> Introduce config option DISCARD_UNUSED_SECTIONS.
> If it is selected:
> Pass -ffunction-sections -fdata-sections to gcc and
> --gc-sections --print-gc-sections to ld.
> Use arch/$(SRCARCH)/kernel/modules.lds.S linker script for linking *.ko
> files.
> Generate linker map files for vmlinux and modules.
> Add *(.text.*), *(.data.*) wildcards to linker scripts to accomodate
> new kinds of sections generated by gcc.
> Add KEEP() directives to sections which must not be
> discarded. Fix arch/frv/Makefile to use DISCARD_UNUSED_SECTIONS instead
> of what seems to be a vestigial custom solution.
Signed-off-by: Denys Vlasenko <[EMAIL PROTECTED]>
--
vda
diff -urpN linux-2.6.gc2/Makefile linux-2.6.gc3/Makefile
--- linux-2.6.gc2/Makefile 2007-11-23 18:55:08.0 -0800
+++ linux-2.6.gc3/Makefile 2007-11-24 14:46:38.0 -0800
@@ -526,6 +526,11 @@ KBUILD_CFLAGS += $(call cc-optio
NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
CHECKFLAGS += $(NOSTDINC_FLAGS)
+ifdef CONFIG_DISCARD_UNUSED_SECTIONS
+CFLAGS += $(call cc-option, -ffunction-sections -fdata-sections)
+LDFLAGS_vmlinux += --gc-sections --print-gc-sections -Map vmlinux.map
+endif
+
# warn about C99 declaration after statement
KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
@@ -924,6 +929,7 @@ prepare: prepare0
# done in arch/$(ARCH)/kernel/Makefile
export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH)
+export CPPFLAGS_modules.lds += -P -C -U$(ARCH)
# The asm symlink changes when $(ARCH) changes.
# Detect this and ask user to run make mrproper
diff -urpN linux-2.6.gc2/arch/alpha/boot/bootloader.lds linux-2.6.gc3/arch/alpha/boot/bootloader.lds
--- linux-2.6.gc2/arch/alpha/boot/bootloader.lds 2007-11-23 18:55:08.0 -0800
+++ linux-2.6.gc3/arch/alpha/boot/bootloader.lds 2007-11-23 21:22:59.0 -0800
@@ -4,17 +4,17 @@ printk = srm_printk;
SECTIONS
{
. = 0x2000;
- .text : { *(.text) }
+ .text : { *(.text) *(.text.*) }
_etext = .;
PROVIDE (etext = .);
.rodata : { *(.rodata) *(.rodata.*) }
- .data : { *(.data) CONSTRUCTORS }
+ .data : { *(.data) *(.data.*) CONSTRUCTORS }
.got : { *(.got) }
.sdata : { *(.sdata) }
_edata = .;
PROVIDE (edata = .);
.sbss : { *(.sbss) *(.scommon) }
- .bss : { *(.bss) *(COMMON) }
+ .bss : { *(.bss) *(.bss.*) *(COMMON) }
_end = . ;
PROVIDE (end = .);
diff -urpN linux-2.6.gc2/arch/alpha/kernel/vmlinux.lds.S linux-2.6.gc3/arch/alpha/kernel/vmlinux.lds.S
--- linux-2.6.gc2/arch/alpha/kernel/vmlinux.lds.S 2007-11-23 20:55:55.0 -0800
+++ linux-2.6.gc3/arch/alpha/kernel/vmlinux.lds.S 2007-11-23 21:30:54.0 -0800
@@ -129,6 +129,7 @@ SECTIONS
}
.bss : {
*(.bss)
+ *(.bss.*)
*(COMMON)
}
__bss_stop = .;
diff -urpN linux-2.6.gc2/arch/arm/boot/bootp/bootp.lds linux-2.6.gc3/arch/arm/boot/bootp/bootp.lds
--- linux-2.6.gc2/arch/arm/boot/bootp/bootp.lds 2007-11-23 18:55:08.0 -0800
+++ linux-2.6.gc3/arch/arm/boot/bootp/bootp.lds 2007-11-23 21:23:15.0 -0800
@@ -15,7 +15,7 @@ SECTIONS
.text : {
_stext = .;
*(.start)
- *(.text)
+ *(.text .text.*)
initrd_size = initrd_end - initrd_start;
_etext = .;
}
diff -urpN linux-2.6.gc2/arch/arm/boot/compressed/vmlinux.lds.in linux-2.6.gc3/arch/arm/boot/compressed/vmlinux.lds.in
--- linux-2.6.gc2/arch/arm/boot/compressed/vmlinux.lds.in 2007-11-23 18:55:08.0 -0800
+++ linux-2.6.gc3/arch/arm/boot/compressed/vmlinux.lds.in 2007-11-23 21:24:25.0 -0800
@@ -35,12 +35,12 @@ SECTIONS
.got : { *(.got) }
_got_end = .;
.got.plt : { *(.got.plt) }
- .data : { *(.data) }
+ .data : { *(.data) *(.data.*) }
_edata = .;
. = BSS_START;
__bss_start = .;
- .bss : { *(.bss) }
+ .bss : { *(.bss) *(.bss.*) }
_end = .;
.stack (NOLOAD) : { *(.stack) }
diff -urpN linux-2.6.gc2/arch/arm/kernel/vmlinux.lds.S linux-2.6.gc3/arch/arm/kernel/vmlinux.lds.S
--- linux-2.6.gc2/arch/arm/kernel/vmlinux.lds.S 2007-11-23 20:55:54.0 -0800
+++ linux-2.6.gc3/arch/arm/kernel/vmlinux.lds.S 2007-11-23 21:31:04.0 -0800
@@ -169,6 +169,7 @@ SECTIONS
.bss : {
__bss_start = .; /* BSS*/
*(.bss)
+ *(.bss.*)
*(COMMON)
_end = .;
}
diff -urpN linux-2.6.gc2/arch/avr32/kernel/vmlinux.lds.S linux-2.6.gc3/arch/avr32/kernel/vmlinux.lds.S
--- linux-2.6.gc2/arch/avr32/kernel/vmlinux.lds.S 2007-11-23 20:55:53.0 -0800
+++ linux-2.6.gc3/arch/avr32/kernel/vmlinux.lds.S 2007-11-23 21:31:12.0 -0800
@@ -124,6 +124,7 @@ SECTIONS
.bss : AT(ADDR(.bss) - LOAD_OFFSET) {
__bss_start = .;
*(.bss)
+ *(.bss.*)
*(COMMON)
. = ALIGN(8);
__bss_stop = .;
diff -urpN linux-2.6.gc2/arch/cris/arch-v10/vmlinux.lds.S linux-2.6.gc3/arch/cris/arch-v10/vmlinux.lds.S
--- linux-2.6.gc2/arch/cris/arch-v10/vmlinux.lds.S
[PATCH 2/3] build system: section garbage collection - modpost fix
On Saturday 24 November 2007 15:14, Denys Vlasenko wrote:
> 2.modpost
> Update scripts/mod/* machinery to correctly handle the case
> when we have more than 64k sections.
Signed-off-by: Denys Vlasenko <[EMAIL PROTECTED]>
--
vda
diff -urpN linux-2.6.gc1/scripts/mod/file2alias.c linux-2.6.gc2/scripts/mod/file2alias.c
--- linux-2.6.gc1/scripts/mod/file2alias.c 2007-11-23 18:55:26.0 -0800
+++ linux-2.6.gc2/scripts/mod/file2alias.c 2007-11-23 21:10:04.0 -0800
@@ -585,7 +585,7 @@ void handle_moddevtable(struct module *m
char *zeros = NULL;
/* We're looking for a section relative symbol */
- if (!sym->st_shndx || sym->st_shndx >= info->hdr->e_shnum)
+ if (!sym->st_shndx || get_secindex(info, sym) >= info->num_sections)
return;
/* Handle all-NULL symbols allocated into .bss */
@@ -594,7 +594,7 @@ void handle_moddevtable(struct module *m
symval = zeros;
} else {
symval = (void *)info->hdr
- + info->sechdrs[sym->st_shndx].sh_offset
+ + info->sechdrs[get_secindex(info, sym)].sh_offset
+ sym->st_value;
}
diff -urpN linux-2.6.gc1/scripts/mod/modpost.c linux-2.6.gc2/scripts/mod/modpost.c
--- linux-2.6.gc1/scripts/mod/modpost.c 2007-11-23 20:55:54.0 -0800
+++ linux-2.6.gc2/scripts/mod/modpost.c 2007-11-23 21:08:41.0 -0800
@@ -235,7 +235,7 @@ static enum export export_no(const char
return export_unknown;
}
-static enum export export_from_sec(struct elf_info *elf, Elf_Section sec)
+static enum export export_from_sec(struct elf_info *elf, unsigned sec)
{
if (sec == elf->export_sec)
return export_plain;
@@ -356,6 +356,8 @@ static int parse_elf(struct elf_info *in
Elf_Ehdr *hdr;
Elf_Shdr *sechdrs;
Elf_Sym *sym;
+ const char *secstrings;
+ unsigned int symtab_idx = ~0U;
hdr = grab_file(filename, >size);
if (!hdr) {
@@ -375,6 +377,7 @@ static int parse_elf(struct elf_info *in
/* Not an ELF file - silently ignore it */
return 0;
}
+
/* Fix endianness in ELF header */
hdr->e_shoff= TO_NATIVE(hdr->e_shoff);
hdr->e_shstrndx = TO_NATIVE(hdr->e_shstrndx);
@@ -390,8 +393,18 @@ static int parse_elf(struct elf_info *in
return 0;
}
+ /* Fixups for more than 64k sections */
+ info->num_sections = hdr->e_shnum;
+ if (info->num_sections == SHN_UNDEF) { /* more than 64k sections? */
+ /* doesn't need shndx2secindex() */
+ info->num_sections = TO_NATIVE(sechdrs[0].sh_size);
+ }
+ info->secindex_strings = hdr->e_shstrndx;
+ if (info->secindex_strings == SHN_XINDEX)
+ info->secindex_strings = shndx2secindex(TO_NATIVE(sechdrs[0].sh_link));
+
/* Fix endianness in section headers */
- for (i = 0; i < hdr->e_shnum; i++) {
+ for (i = 0; i < info->num_sections; i++) {
sechdrs[i].sh_type = TO_NATIVE(sechdrs[i].sh_type);
sechdrs[i].sh_offset = TO_NATIVE(sechdrs[i].sh_offset);
sechdrs[i].sh_size = TO_NATIVE(sechdrs[i].sh_size);
@@ -401,9 +414,8 @@ static int parse_elf(struct elf_info *in
sechdrs[i].sh_addr = TO_NATIVE(sechdrs[i].sh_addr);
}
/* Find symbol table. */
- for (i = 1; i < hdr->e_shnum; i++) {
- const char *secstrings
- = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
+ secstrings = (void *)hdr + sechdrs[info->secindex_strings].sh_offset;
+ for (i = 1; i < info->num_sections; i++) {
const char *secname;
if (sechdrs[i].sh_offset > info->size) {
@@ -425,14 +437,29 @@ static int parse_elf(struct elf_info *in
else if (strcmp(secname, "__ksymtab_gpl_future") == 0)
info->export_gpl_future_sec = i;
- if (sechdrs[i].sh_type != SHT_SYMTAB)
- continue;
+ if (sechdrs[i].sh_type == SHT_SYMTAB) {
+ symtab_idx = i;
+ info->symtab_start = (void *)hdr + sechdrs[i].sh_offset;
+ info->symtab_stop = (void *)hdr + sechdrs[i].sh_offset
+ + sechdrs[i].sh_size;
+ info->strtab = (void *)hdr +
+ sechdrs[shndx2secindex(sechdrs[i].sh_link)].sh_offset;
+ }
- info->symtab_start = (void *)hdr + sechdrs[i].sh_offset;
- info->symtab_stop = (void *)hdr + sechdrs[i].sh_offset
- + sechdrs[i].sh_size;
- info->strtab = (void *)hdr +
- sechdrs[sechdrs[i].sh_link].sh_offset;
+ /* 32bit section no. table? ("more than 64k sections") */
+ if (sechdrs[i].sh_type == SHT_SYMTAB_SHNDX) {
+ uint32_t *p32;
+ info->symtab_shndx = (void *)hdr + sechdrs[i].sh_offset;
+ if (symtab_idx != shndx2secindex(sechdrs[i].sh_link))
+fatal("%s: SYMTAB_SHNDX has bad sh_link: %u!=%u\n",
+ filename,
+ shndx2secindex(sechdrs[i].sh_link),
+ symtab_idx);
+ /* Fix endianness */
+ p32 = (void*)info->symtab_shndx + sechdrs[i].sh_size;
+ while (--p32 >= info->symtab_shndx)
+*p32 = TO_NATIVE(*p32);
+ }
}
if (!info->symtab_start) {
fatal("%s has no symtab?\n", filename);
@@ -459,7 +486,7 @@ static void handle_modversions(struct mo
Elf_Sym *sym, const char *symname)
{
unsigned int crc;
- enum export export = export_from_sec(info, sym->st_shndx);
+ enum export export =
Re: nohz and strange sleep latencies
On Sunday, 25 of November 2007, Rafael J. Wysocki wrote:
> On Saturday, 24 of November 2007, Pavel Machek wrote:
> > Hi!
> >
> > > > > but perhaps somehow we miss this fact and fail to turn off the lapic
> > > > > clockevents drivers?
> > > >
> > > > Ok, I guess I'm lost. If I offline second CPU, I immediately get
> > > > 1000Hz timer tick... is that expected?
> > >
> > > Hmm. No. I have no idea why this is happening.
> > >
> > > 34196 total events, 55.083 events/sec
> > > echo 0 >/sys/devices/system/cpu/cpu1/online
> > > 36073 total events, 54.679 events/sec
> >
> > Digging into process_32|64.c...
> >
> > 64:
> > while (1) {
> > while (!need_resched()) {
> > void (*idle)(void);
> >
> > if (__get_cpu_var(cpu_idle_state))
> > __get_cpu_var(cpu_idle_state) = 0;
> >
> > tick_nohz_stop_sched_tick();
> >
> > 32:
> > while (1) {
> > tick_nohz_stop_sched_tick();
> > while (!need_resched()) {
> > void (*idle)(void);
> >
> > if (__get_cpu_var(cpu_idle_state))
> > __get_cpu_var(cpu_idle_state) = 0;
> >
> > ...eek? Which one is wrong?
>
> Hm, it looks like you should have quoted more lines ...
>
> In the second case (32), the tick_nohz_stop_sched_tick() seems to be
> redundant, so I bet it's this one.
OTOH, the ARM's process.c is more similar to process_32.c ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 0/3] build system: section garbage collection
Hi Sam, On Sunday 18 November 2007 15:00, Sam Ravnborg wrote: > On Tue, Sep 11, 2007 at 09:05:33PM +0100, Denys Vlasenko wrote: > > Build system: section garbage collection for vmlinux > > > > Newer gcc and binutils can do dead code and data removal > > at link time. It is achieved using combination of > > -ffunction-sections -fdata-sections options for gcc and > > --gc-sections for ld. > > ... > Hi Denys. > > We are now well pass the merge window and I like this patchset to show up > in -mm. But I'm lacking time myself and wondered if you can send an updated > version based on the latest -git tree from Linus? Got around to do this. 1.fixname: Rename all special sections with names like .text., .data. and .rodata. to ..text/data/rodata. This makes it possible to not mix up these sections with gcc-generated ones when gcc -ffunction-sections -fdata-sections is used. .bss. cannot be treated this way, because for section names linke ..bss gcc won't create section with correct attribute. Thus .bss.x sections are renamed .bss.k.x. 2.modpost Update scripts/mod/* machinery to correctly handle the case when we have more than 64k sections. 3.gc The meat of the patchset is here. Introduce config option DISCARD_UNUSED_SECTIONS. If it is selected: Pass -ffunction-sections -fdata-sections to gcc and --gc-sections --print-gc-sections to ld. Use arch/$(SRCARCH)/kernel/modules.lds.S linker script for linking *.ko files. Generate linker map files for vmlinux and modules. Add *(.text.*), *(.data.*) wildcards to linker scripts to accomodate new kinds of sections generated by gcc. Add KEEP() directives to sections which must not be discarded. Fix arch/frv/Makefile to use DISCARD_UNUSED_SECTIONS instead of what seems to be a vestigial custom solution. Patches are against yesterday's Linus git tree and should be applied in order. They should not have any effect at all if DISCARD_UNUSED_SECTIONS is off. DISCARD_UNUSED_SECTIONS is marked DANGEROUS for now. It is likely to not work on arches other than x86 (modules.lds needs to be added for each arch). Compile and run tested on 32-bit x86 (running this kernel now). Signed-off-by: Denys Vlasenko <[EMAIL PROTECTED]> -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: nohz and strange sleep latencies
On Saturday, 24 of November 2007, Pavel Machek wrote:
> Hi!
>
> > > > but perhaps somehow we miss this fact and fail to turn off the lapic
> > > > clockevents drivers?
> > >
> > > Ok, I guess I'm lost. If I offline second CPU, I immediately get
> > > 1000Hz timer tick... is that expected?
> >
> > Hmm. No. I have no idea why this is happening.
> >
> > 34196 total events, 55.083 events/sec
> > echo 0 >/sys/devices/system/cpu/cpu1/online
> > 36073 total events, 54.679 events/sec
>
> Digging into process_32|64.c...
>
> 64:
> while (1) {
> while (!need_resched()) {
> void (*idle)(void);
>
> if (__get_cpu_var(cpu_idle_state))
> __get_cpu_var(cpu_idle_state) = 0;
>
> tick_nohz_stop_sched_tick();
>
> 32:
> while (1) {
> tick_nohz_stop_sched_tick();
> while (!need_resched()) {
> void (*idle)(void);
>
> if (__get_cpu_var(cpu_idle_state))
> __get_cpu_var(cpu_idle_state) = 0;
>
> ...eek? Which one is wrong?
Hm, it looks like you should have quoted more lines ...
In the second case (32), the tick_nohz_stop_sched_tick() seems to be
redundant, so I bet it's this one.
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Serial disabled in BIOS but serial modules still loaded (probably PnP related)
On Nov 24, 2007 12:36 PM, Andrey Borzenkov <[EMAIL PROTECTED]> wrote:
> I have no COM port on notebook (without port replicator which I do not have)
> so COM is disabled in BIOS. No ttyS* is detected during boot (and no device
> created) but I just noticed that serial modules are still loaded. Well, this
> partially defeats the purpose of disabling COM port - the intention was to
> free resources by *not* loading unneeded modules ...
>
> This may have something to do with (ACPI) PnP which apparently believes COM
> is alive.
> Notebook is Toshiba Portege 4000.
>
> {pts/0}% lsmod | grep 82
> 8250_pnp9792 0
> 8250 24660 1 8250_pnp
> serial_core22872 1 8250
>
> {pts/0}% lspnp -v
> 00:00 PNP0c01 System board
> state = active
> mem 0x0-0x9
> mem 0xe-0xe
> mem 0xf-0xf
> mem 0x10-0x1ef5
>
> 00:01 PNP0a03 PCI bus
> state = active
> io 0xcf8-0xcff
>
> 00:02 PNP0200 AT DMA controller
> state = active
> io 0x0-0xf
> io 0x81-0x83
> io 0x87-0x87
> io 0x89-0x8b
> io 0x8f-0x8f
> io 0xc0-0xdf
> dma 4
>
> 00:03 PNP0800 AT speaker
> state = active
> io 0x61-0x61
>
> 00:04 PNP0c04 Math coprocessor
> state = active
> io 0xf0-0xff
> irq 13
>
> 00:05 PNP0303 IBM enhanced keyboard (101/102-key, PS/2 mouse support)
> state = active
> io 0x60-0x60
> io 0x64-0x64
> irq 1
>
> 00:06 PNP0f13 PS/2 port for PS/2-style mice
> state = active
> irq 12
>
> 00:07 PNP0b00 AT real-time clock
> state = active
> io 0x70-0x71
> irq 8
>
> 00:08 PNP0c02 Motherboard resources
> state = active
> io 0x2e-0x2f
> io 0x62-0x62
> io 0x66-0x66
> io 0x80-0x80
> io 0x84-0x86
> io 0x88-0x88
> io 0x8c-0x8e
> io 0x92-0x92
>
> 00:09 PNP0501 16550A-compatible serial port
> state = active
> io 0x3f8-0x3ff
> irq 5
>
> 00:0a SMCf010 SMC Fast Infrared Port
> state = disabled
>
> 00:0b PNP0401 ECP printer port
> state = disabled
>
> ..
> [ 126.035809] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
> sharing enabled
...
> [ 126.107096] serial 00:09: activated
...
Can you cat /sys/firmware/acpi/DSDT and use iasl to decode it?
it seems that your BIOS has problem about com setup.
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: I/O error, system hangs
Le 24.11.2007 14:26, James Bottomley a écrit : > On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote: >> Le 24.11.2007 07:42, James Bottomley a écrit : >>> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote: Le 23.11.2007 12:38, Hannes Reinecke a écrit : [snip] I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 does fix the problem. >> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an >> error where >> I shouldn't. Checking ... >> > Ok, found it. We are blocking even special commands (ie requests with > PREEMPT not set) > when FAILFAST is set. Which is clearly wrong. The attached patch fixes > this. Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors. >>> I think the problem is the way we treat BLOCKED and QUIESCED (the latter >>> is the state that the domain validation uses and which we cannot kill >>> fastfail on). It's definitely wrong to kill fastfail requests when the >>> state is QUIESCE. >>> >>> This patch (which is applied on top of Hannes original) separates the >>> BLOCK and QUIESCE states correctly ... does this fix the problem? >> >> No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems) > > OK, could you post dmesgs again, please. I actually tested this with an > aic79xx card, and for me it does cause Domain Validation to succeed > again. James, Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch "separates the BLOCK and QUIESCE states correctly" (http://lkml.org/lkml/2007/11/24/8). How to reproduce : - boot - switch to a text console - capture dmesg in a file, sync, etc. There are 3 I/O errors, but the system does work. - switch to X console, log in the Gnome Desktop, the system partially hangs. - switch back to a text console: dmesg(1) still works, it shows some additonal I/O errors. At this point, any disk access makes the system completely hung. Additionnal data: - the I/O errors always happen on the same blocks. -- laurent [0.00] Linux version 2.6.24-rc3-mm1 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #122 PREEMPT Fri Nov 23 18:47:58 CET 2007 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 1ffec000 (usable) [0.00] BIOS-e820: 1ffec000 - 1ffef000 (ACPI data) [0.00] BIOS-e820: 1ffef000 - 1000 (reserved) [0.00] BIOS-e820: 1000 - 2000 (ACPI NVS) [0.00] BIOS-e820: - 0001 (reserved) [0.00] 511MB LOWMEM available. [0.00] Entering add_active_range(0, 0, 131052) 0 entries of 256 used [0.00] sizeof(struct page) = 32 [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] Normal 4096 -> 131052 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 -> 131052 [0.00] On node 0 totalpages: 131052 [0.00] Node 0 memmap at 0xC100 size 4194304 first pfn 0xC100 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 4064 pages, LIFO batch:0 [0.00] Normal zone: 991 pages used for memmap [0.00] Normal zone: 125965 pages, LIFO batch:31 [0.00] Movable zone: 0 pages used for memmap [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F6A80, 0014 (r0 ASUS ) [0.00] ACPI: RSDT 1FFEC000, 002C (r1 ASUS A7V133-C 30303031 MSFT 31313031) [0.00] ACPI: FACP 1FFEC080, 0074 (r1 ASUS A7V133-C 30303031 MSFT 31313031) [0.00] ACPI: DSDT 1FFEC100, 2CE1 (r1 ASUS A7V133-C 1000 MSFT 10B) [0.00] ACPI: FACS 1000, 0040 [0.00] ACPI: BOOT 1FFEC040, 0028 (r1 ASUS A7V133-C 30303031 MSFT 31313031) [0.00] ACPI: PM-Timer IO Port: 0xe408 [0.00] Allocating PCI resources starting at 3000 (gap: 2000:dfff) [0.00] swsusp: Registered nosave memory region: 0009f000 - 000a [0.00] swsusp: Registered nosave memory region: 000a - 000f [0.00] swsusp: Registered nosave memory region: 000f - 0010 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130029 [0.00] Kernel command line: root=/dev/mapper/vglinux1-lv_ubuntu2 ro locale=fr_FR video=radeonfb:[EMAIL PROTECTED] resume=/dev/mapper/vglinux1-lvswap [0.00] Local APIC disabled by BIOS -- you can enable it with "lapic" [0.00] mapped APIC to b000
[PATCH] x86_64: not set boot cpu in cpu_present_map again
[PATCH] x86_64: not set boot cpu in cpu_present_map again in init/main.c boot_cpu_init() already does that before setup_arch Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]> diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c index 30d94d1..9905c45 100644 --- a/arch/x86/kernel/setup_64.c +++ b/arch/x86/kernel/setup_64.c @@ -409,12 +409,6 @@ void __init setup_arch(char **cmdline_p) early_quirks(); #endif - /* -* set this early, so we dont allocate cpu0 -* if MADT list doesnt list BSP first -* mpparse.c/MP_processor_info() allocates logical cpu numbers. -*/ - cpu_set(0, cpu_present_map); #ifdef CONFIG_ACPI /* * Read APIC and some other early information from ACPI tables. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] x86_64: not set boot cpu in cpu_online_map at x86_64_start_kernel
[PATCH] x86_64: not set boot cpu in cpu_online_map at x86_64_start_kernel in init/main.c boot_cpu_init() does that later Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c index 6b34693..82b9f03 100644 --- a/arch/x86/kernel/head64.c +++ b/arch/x86/kernel/head64.c @@ -67,8 +67,6 @@ void __init x86_64_start_kernel(char * real_mode_data) pda_init(0); copy_bootdata(__va(real_mode_data)); -#ifdef CONFIG_SMP - cpu_set(0, cpu_online_map); -#endif + start_kernel(); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: nohz and strange sleep latencies
Hi!
> > > but perhaps somehow we miss this fact and fail to turn off the lapic
> > > clockevents drivers?
> >
> > Ok, I guess I'm lost. If I offline second CPU, I immediately get
> > 1000Hz timer tick... is that expected?
>
> Hmm. No. I have no idea why this is happening.
>
> 34196 total events, 55.083 events/sec
> echo 0 >/sys/devices/system/cpu/cpu1/online
> 36073 total events, 54.679 events/sec
Digging into process_32|64.c...
64:
while (1) {
while (!need_resched()) {
void (*idle)(void);
if (__get_cpu_var(cpu_idle_state))
__get_cpu_var(cpu_idle_state) = 0;
tick_nohz_stop_sched_tick();
32:
while (1) {
tick_nohz_stop_sched_tick();
while (!need_resched()) {
void (*idle)(void);
if (__get_cpu_var(cpu_idle_state))
__get_cpu_var(cpu_idle_state) = 0;
...eek? Which one is wrong?
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: nohz and strange sleep latencies
On Thu 2007-11-22 21:29:51, Thomas Gleixner wrote: > On Thu, 22 Nov 2007, Pavel Machek wrote: > > > but perhaps somehow we miss this fact and fail to turn off the lapic > > > clockevents drivers? > > > > Ok, I guess I'm lost. If I offline second CPU, I immediately get > > 1000Hz timer tick... is that expected? > > Hmm. No. I have no idea why this is happening. > > 34196 total events, 55.083 events/sec > echo 0 >/sys/devices/system/cpu/cpu1/online > 36073 total events, 54.679 events/sec Strange... > Just to make sure what we are hunting: Do you have the same problem > with an non-pavel-tainted 2.6.24-rc3 ? The effect described above disappeared from both clean and tainted-pavel trees...? But I have verified again that time sleep 0.01 is perfectly willing to sleep for 0.9second on untainted 2.6.24-rc3... 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: radeonfb i2c regression post-2.6.18.
> Very strange indeed. Another possibility is that there is a hardware > monitoring chip connected to one of the Radeon adapter's I2C buses, and > that holding the I2C lines prevents reading from it, so whatever is > responsible for controlling the temperature prefers to play it safe and > shuts everything down. Somehow it seems more realistic than an actual > overheating (3 seconds is a very short period of time for that), but > we'd need the exact schematics of the hardware, and the details of the > thermal control system, to validate this theory. > > Anyway, no need to worry anymore now that the bug is fixed :) Actually, that's a possibility yes, though generally Apple put all temp. monitoring chips elsewhere, it could well be the case. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeonfb i2c regression post-2.6.18.
On Sat, 24 Nov 2007 15:18:26 +0100, Michael Buesch wrote: > On Friday 23 November 2007 23:29:28 Jean Delvare wrote: > > Out of curiosity, what kind of crash was it? I admit that I can't see > > how the code could crash. > > It's not the code that crashes. It's the hardware that turns off the machine. > It only happens if I boot the machine and only if it's hot at this > time. Some hardware will turn off the hardware two or three seconds > after the radeon driver was loaded. > It seems to be some overheating protection that's going crazy. Very strange indeed. Another possibility is that there is a hardware monitoring chip connected to one of the Radeon adapter's I2C buses, and that holding the I2C lines prevents reading from it, so whatever is responsible for controlling the temperature prefers to play it safe and shuts everything down. Somehow it seems more realistic than an actual overheating (3 seconds is a very short period of time for that), but we'd need the exact schematics of the hardware, and the details of the thermal control system, to validate this theory. Anyway, no need to worry anymore now that the bug is fixed :) -- 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: [PATCH 5/5] lguest: loading bzImage directly
Kjartan Maraas wrote: to., 04.10.2007 kl. 10.02 +1000, skrev Rusty Russell: On Wed, 2007-10-03 at 10:37 +0100, Chris Malley wrote: Hi guys Would it not be clearer to #include and use the relevant named members of struct setup_header / struct boot_params rather than the hard-coded values 0x202, 0x1F1, 0x214 ? Yes, but unfortunately bootparam.h wasn't designed to be included from userspace. [snip] This change seems to have broken build of the battstat applet in gnome-applets or rather the included apmlib in there. Intended? Any pointers on how to adapt the code in case it was? Perhaps you could actually give some detail how it broke the code?! -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel: Compliment va_copy with va_end()
Compliment va_copy() with va_end(). Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]> --- Compile-tested on i386 with allyesconfig & allmodconfig. diff --git a/kernel/audit.c b/kernel/audit.c index f93c271..836626c 100644 --- a/kernel/audit.c +++ b/kernel/audit.c @@ -1245,6 +1245,7 @@ static void audit_log_vformat(struct audit_buffer *ab, const char *fmt, goto out; len = vsnprintf(skb_tail_pointer(skb), avail, fmt, args2); } + va_end(args2); if (len > 0) skb_put(skb, len); out: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 5/5] lguest: loading bzImage directly
to., 04.10.2007 kl. 10.02 +1000, skrev Rusty Russell:
> On Wed, 2007-10-03 at 10:37 +0100, Chris Malley wrote:
> > Hi guys
> >
> > Would it not be clearer to #include and use
> > the relevant named members of struct setup_header / struct boot_params
> > rather than the hard-coded values 0x202, 0x1F1, 0x214 ?
>
> Yes, but unfortunately bootparam.h wasn't designed to be included from
> userspace.
>
[snip]
This change seems to have broken build of the battstat applet in
gnome-applets or rather the included apmlib in there. Intended?
Any pointers on how to adapt the code in case it was?
> diff -r 6bb527d113a8 include/linux/apm_bios.h
> --- a/include/linux/apm_bios.hWed Oct 03 13:49:31 2007 +1000
> +++ b/include/linux/apm_bios.hThu Oct 04 09:37:28 2007 +1000
> @@ -16,28 +16,28 @@
> * General Public License for more details.
> */
>
> +#include
> +
> +struct apm_bios_info {
> + __u16 version;
> + __u16 cseg;
> + __u32 offset;
> + __u16 cseg_16;
> + __u16 dseg;
> + __u16 flags;
> + __u16 cseg_len;
> + __u16 cseg_16_len;
> + __u16 dseg_len;
> +};
> +
> +#ifdef __KERNEL__
> +
> typedef unsigned short apm_event_t;
> typedef unsigned short apm_eventinfo_t;
> -
> -#ifdef __KERNEL__
> -
> -#include
>
> #define APM_CS (GDT_ENTRY_APMBIOS_BASE * 8)
> #define APM_CS_16(APM_CS + 8)
> #define APM_DS (APM_CS_16 + 8)
> -
> -struct apm_bios_info {
> - u16 version;
> - u16 cseg;
> - u32 offset;
> - u16 cseg_16;
> - u16 dseg;
> - u16 flags;
> - u16 cseg_len;
> - u16 cseg_16_len;
> - u16 dseg_len;
> -};
>
> /* Results of APM Installation Check */
> #define APM_16_BIT_SUPPORT 0x0001
Cheers
Kjartan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] IB/ehca: Fix static rate regression
thanks, applied. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [MIPS]: Compliment va_start() with va_end().
Compliment va_start() with va_end(). Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]> --- ieee754.c |2 ++ ieee754dp.c |2 ++ ieee754sp.c |2 ++ 3 files changed, 6 insertions(+) diff --git a/arch/mips/math-emu/ieee754.c b/arch/mips/math-emu/ieee754.c index 946aee3..cb1b682 100644 --- a/arch/mips/math-emu/ieee754.c +++ b/arch/mips/math-emu/ieee754.c @@ -108,6 +108,7 @@ int ieee754si_xcpt(int r, const char *op, ...) ax.rv.si = r; va_start(ax.ap, op); ieee754_xcpt(); + va_end(ax.ap); return ax.rv.si; } @@ -122,5 +123,6 @@ s64 ieee754di_xcpt(s64 r, const char *op, ...) ax.rv.di = r; va_start(ax.ap, op); ieee754_xcpt(); + va_end(ax.ap); return ax.rv.di; } diff --git a/arch/mips/math-emu/ieee754dp.c b/arch/mips/math-emu/ieee754dp.c index 3e214aa..6d2d89f 100644 --- a/arch/mips/math-emu/ieee754dp.c +++ b/arch/mips/math-emu/ieee754dp.c @@ -57,6 +57,7 @@ ieee754dp ieee754dp_xcpt(ieee754dp r, const char *op, ...) ax.rv.dp = r; va_start(ax.ap, op); ieee754_xcpt(); + va_end(ax.ap); return ax.rv.dp; } @@ -83,6 +84,7 @@ ieee754dp ieee754dp_nanxcpt(ieee754dp r, const char *op, ...) ax.rv.dp = r; va_start(ax.ap, op); ieee754_xcpt(); + va_end(ax.ap); return ax.rv.dp; } diff --git a/arch/mips/math-emu/ieee754sp.c b/arch/mips/math-emu/ieee754sp.c index adda851..4635340 100644 --- a/arch/mips/math-emu/ieee754sp.c +++ b/arch/mips/math-emu/ieee754sp.c @@ -58,6 +58,7 @@ ieee754sp ieee754sp_xcpt(ieee754sp r, const char *op, ...) ax.rv.sp = r; va_start(ax.ap, op); ieee754_xcpt(); + va_end(ax.ap); return ax.rv.sp; } @@ -84,6 +85,7 @@ ieee754sp ieee754sp_nanxcpt(ieee754sp r, const char *op, ...) ax.rv.sp = r; va_start(ax.ap, op); ieee754_xcpt(); + va_end(ax.ap); return ax.rv.sp; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/4] Timerfd v2 - new timerfd API
On Sat, 24 Nov 2007, Michael Kerrisk wrote:
> > +asmlinkage long sys_timerfd_create(int clockid, int flags)
> > {
> > - int error;
> > + int error, ufd;
> > struct timerfd_ctx *ctx;
> > struct file *file;
> > struct inode *inode;
> > - struct itimerspec ktmr;
> > -
> > - if (copy_from_user(, utmr, sizeof(ktmr)))
> > - return -EFAULT;
> >
> > if (clockid != CLOCK_MONOTONIC &&
> > clockid != CLOCK_REALTIME)
> > return -EINVAL;
>
> Could I suggest here, the following placeholder addition:
>
> if (flags != 0)
> return -EINVAL;
Make sense, will repost.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] net/irda/parameters.c: Trivial fixes
Make a single va_start() -> va_end() path + fixing:
CHECK /home/kernel/src/net/irda/parameters.c
/home/kernel/src/net/irda/parameters.c:466:2: warning: Using plain integer as
NULL pointer
/home/kernel/src/net/irda/parameters.c:520:2: warning: Using plain integer as
NULL pointer
/home/kernel/src/net/irda/parameters.c:573:2: warning: Using plain integer as
NULL pointer
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested on i386 with allyesconfig and allmodconfig.
diff --git a/net/irda/parameters.c b/net/irda/parameters.c
index 2627dad..bf19071 100644
--- a/net/irda/parameters.c
+++ b/net/irda/parameters.c
@@ -368,10 +368,11 @@ int irda_param_pack(__u8 *buf, char *fmt, ...)
va_list args;
char *p;
int n = 0;
+ int retval = 0;
va_start(args, fmt);
- for (p = fmt; *p != '\0'; p++) {
+ for (p = fmt; *p != '\0' && retval == 0; p++) {
switch (*p) {
case 'b': /* 8 bits unsigned byte */
buf[n++] = (__u8)va_arg(args, int);
@@ -392,13 +393,12 @@ int irda_param_pack(__u8 *buf, char *fmt, ...)
break;
#endif
default:
- va_end(args);
- return -1;
+ retval = -1;
}
}
va_end(args);
- return 0;
+ return retval;
}
EXPORT_SYMBOL(irda_param_pack);
@@ -411,10 +411,11 @@ static int irda_param_unpack(__u8 *buf, char *fmt, ...)
va_list args;
char *p;
int n = 0;
+ int retval = 0;
va_start(args, fmt);
- for (p = fmt; *p != '\0'; p++) {
+ for (p = fmt; *p != '\0' && retval == 0; p++) {
switch (*p) {
case 'b': /* 8 bits byte */
arg.ip = va_arg(args, __u32 *);
@@ -436,14 +437,13 @@ static int irda_param_unpack(__u8 *buf, char *fmt, ...)
break;
#endif
default:
- va_end(args);
- return -1;
+ retval = -1;
}
}
va_end(args);
- return 0;
+ return retval;
}
/*
@@ -463,7 +463,7 @@ int irda_param_insert(void *self, __u8 pi, __u8 *buf, int
len,
int n = 0;
IRDA_ASSERT(buf != NULL, return ret;);
- IRDA_ASSERT(info != 0, return ret;);
+ IRDA_ASSERT(info != NULL, return ret;);
pi_minor = pi & info->pi_mask;
pi_major = pi >> info->pi_major_offset;
@@ -517,7 +517,7 @@ static int irda_param_extract(void *self, __u8 *buf, int
len,
int n = 0;
IRDA_ASSERT(buf != NULL, return ret;);
- IRDA_ASSERT(info != 0, return ret;);
+ IRDA_ASSERT(info != NULL, return ret;);
pi_minor = buf[n] & info->pi_mask;
pi_major = buf[n] >> info->pi_major_offset;
@@ -570,7 +570,7 @@ int irda_param_extract_all(void *self, __u8 *buf, int len,
int n = 0;
IRDA_ASSERT(buf != NULL, return ret;);
- IRDA_ASSERT(info != 0, return ret;);
+ IRDA_ASSERT(info != NULL, return ret;);
/*
* Parse all parameters. Each parameter must be at least two bytes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [ACPI] utilities/: Compliment va_start() with va_end().
Compliment va_start() with va_end().
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested on i386 with allyesconfig & allmodconfig.
utdebug.c |2 ++
utmisc.c |4
2 files changed, 6 insertions(+)
diff --git a/drivers/acpi/utilities/utdebug.c b/drivers/acpi/utilities/utdebug.c
index c7e128e..f45e3d5 100644
--- a/drivers/acpi/utilities/utdebug.c
+++ b/drivers/acpi/utilities/utdebug.c
@@ -203,6 +203,7 @@ acpi_ut_debug_print(u32 requested_debug_level,
va_start(args, format);
acpi_os_vprintf(format, args);
+ va_end(args);
}
ACPI_EXPORT_SYMBOL(acpi_ut_debug_print)
@@ -240,6 +241,7 @@ acpi_ut_debug_print_raw(u32 requested_debug_level,
va_start(args, format);
acpi_os_vprintf(format, args);
+ va_end(args);
}
ACPI_EXPORT_SYMBOL(acpi_ut_debug_print_raw)
diff --git a/drivers/acpi/utilities/utmisc.c b/drivers/acpi/utilities/utmisc.c
index 2d19f71..ca4904c 100644
--- a/drivers/acpi/utilities/utmisc.c
+++ b/drivers/acpi/utilities/utmisc.c
@@ -1032,6 +1032,7 @@ acpi_ut_error(char *module_name, u32 line_number, char
*format, ...)
va_start(args, format);
acpi_os_vprintf(format, args);
+ va_end(args);
acpi_os_printf(" [%X]\n", ACPI_CA_VERSION);
}
@@ -1046,6 +1047,7 @@ acpi_ut_exception(char *module_name,
va_start(args, format);
acpi_os_vprintf(format, args);
+ va_end(args);
acpi_os_printf(" [%X]\n", ACPI_CA_VERSION);
}
@@ -1060,6 +1062,7 @@ acpi_ut_warning(char *module_name, u32 line_number, char
*format, ...)
va_start(args, format);
acpi_os_vprintf(format, args);
+ va_end(args);
acpi_os_printf(" [%X]\n", ACPI_CA_VERSION);
}
@@ -1076,5 +1079,6 @@ acpi_ut_info(char *module_name, u32 line_number, char
*format, ...)
va_start(args, format);
acpi_os_vprintf(format, args);
+ va_end(args);
acpi_os_printf("\n");
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: No error when inotify_add_watch(/an/NFS/file)
On Sat, Nov 24, 2007 at 08:11:45PM +, Phil Endecott wrote: > J. Bruce Fields wrote: >> On Fri, Nov 23, 2007 at 11:20:55PM +, Phil Endecott wrote: >>> Dear Experts, >>> >>> NFS doesn't work with inotify (and it looks like it can't, certainly not >>> before NFS v4.1). However, if I give an NFS filename to >>> inotify_add_watch(), I don't get an error. >>> >>> If it indicated an error in this case then I could easily fall back to >>> some sort of polling. Without an error, I need some other way to detect >>> NFS (and any other non-inotify-compatible filesystems). >>> >>> Any thoughts? >> >> The one reason I can think of that you might want that behavior is if >> you know you only access a given piece of the filesystem from one client >> at a time, and you still want inotify to work in that situation. > > That's a good point. > >> (I'm assuming inotify still notifies you of changes that are made on the same >> client.) > > A quick test suggest that it does. > >> But maybe you could handle that case by allowing inotify_add_watch() in >> the case where the nfs filesystem was mounted with the "nolock" option, >> and failing it otherwise, and telling people to turn on nolock if >> they're sure they know what they're doing. > > I'm not sure what your rationale for proposing that is, and I don't think > it helps in my scenario; a user wants their inotify-using application to > "just work", not to be told to "sudo re-mount". I agree, it doesn't help you much. But for a user that's stuck with an application that just refuses to do anything if it can't use inotify, this would allow them to tell the nfs client, "it's OK to let applications on this filesystem use inotify, because nobody else writes to this filesystem." > I suppose that I just need some way to determine whether I will get all, > some, or none of the events that I've asked for. Right. So you'd like to know that if an inotify watch is granted, that means you really are going to get notified about everything (either because the kernel really does have the required knowledge about every change, or in the "nfs mounted with nolock case" because the user has told the kernel it doesn't have to worry about the changes it can't track). --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Serial disabled in BIOS but serial modules still loaded (probably PnP related)
I have no COM port on notebook (without port replicator which I do not have)
so COM is disabled in BIOS. No ttyS* is detected during boot (and no device
created) but I just noticed that serial modules are still loaded. Well, this
partially defeats the purpose of disabling COM port - the intention was to
free resources by *not* loading unneeded modules ...
This may have something to do with (ACPI) PnP which apparently believes COM is
alive.
Notebook is Toshiba Portege 4000.
{pts/0}% lsmod | grep 82
8250_pnp9792 0
8250 24660 1 8250_pnp
serial_core22872 1 8250
{pts/0}% lspnp -v
00:00 PNP0c01 System board
state = active
mem 0x0-0x9
mem 0xe-0xe
mem 0xf-0xf
mem 0x10-0x1ef5
00:01 PNP0a03 PCI bus
state = active
io 0xcf8-0xcff
00:02 PNP0200 AT DMA controller
state = active
io 0x0-0xf
io 0x81-0x83
io 0x87-0x87
io 0x89-0x8b
io 0x8f-0x8f
io 0xc0-0xdf
dma 4
00:03 PNP0800 AT speaker
state = active
io 0x61-0x61
00:04 PNP0c04 Math coprocessor
state = active
io 0xf0-0xff
irq 13
00:05 PNP0303 IBM enhanced keyboard (101/102-key, PS/2 mouse support)
state = active
io 0x60-0x60
io 0x64-0x64
irq 1
00:06 PNP0f13 PS/2 port for PS/2-style mice
state = active
irq 12
00:07 PNP0b00 AT real-time clock
state = active
io 0x70-0x71
irq 8
00:08 PNP0c02 Motherboard resources
state = active
io 0x2e-0x2f
io 0x62-0x62
io 0x66-0x66
io 0x80-0x80
io 0x84-0x86
io 0x88-0x88
io 0x8c-0x8e
io 0x92-0x92
00:09 PNP0501 16550A-compatible serial port
state = active
io 0x3f8-0x3ff
irq 5
00:0a SMCf010 SMC Fast Infrared Port
state = disabled
00:0b PNP0401 ECP printer port
state = disabled
[0.00] Linux version 2.6.24-rc3-1avb ([EMAIL PROTECTED]) (gcc version
4.2.2 (4.2.2-1mdv2008.1)) #7 Sat Nov 17 12:09:07 MSK 2007
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: - 0009fc00 (usable)
[0.00] BIOS-e820: 0009fc00 - 000a (reserved)
[0.00] BIOS-e820: 000e - 000eee00 (reserved)
[0.00] BIOS-e820: 000eee00 - 000ef000 (ACPI NVS)
[0.00] BIOS-e820: 000ef000 - 0010 (reserved)
[0.00] BIOS-e820: 0010 - 1ef6 (usable)
[0.00] BIOS-e820: 1ef6 - 1ef7 (ACPI data)
[0.00] BIOS-e820: 1ef7 - 2000 (reserved)
[0.00] BIOS-e820: fff8 - 0001 (reserved)
[0.00] 495MB LOWMEM available.
[0.00] Entering add_active_range(0, 0, 126816) 0 entries of 256 used
[0.00] Zone PFN ranges:
[0.00] DMA 0 -> 4096
[0.00] Normal 4096 -> 126816
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[1] active PFN ranges
[0.00] 0:0 -> 126816
[0.00] On node 0 totalpages: 126816
[0.00] DMA zone: 32 pages used for memmap
[0.00] DMA zone: 0 pages reserved
[0.00] DMA zone: 4064 pages, LIFO batch:0
[0.00] Normal zone: 958 pages used for memmap
[0.00] Normal zone: 121762 pages, LIFO batch:31
[0.00] Movable zone: 0 pages used for memmap
[0.00] DMI 2.3 present.
[0.00] ACPI: RSDP 000F0090, 0014 (r0 TOSHIB)
[0.00] ACPI: RSDT 1EF6, 0028 (r1 TOSHIB 750970814 TASM
401)
[0.00] ACPI: FACP 1EF60054, 0084 (r2 TOSHIB 750970814 TASM
401)
[0.00] ACPI: DSDT 1EF600D8, 68DA (r1 TOSHIB 4000 20020417 MSFT
10A)
[0.00] ACPI: FACS 000EEE00, 0040
[0.00] ACPI: PM-Timer IO Port: 0xee08
[0.00] Allocating PCI resources starting at 3000 (gap:
2000:dff8)
[0.00] swsusp: Registered nosave memory region: 0009f000 -
000a
[0.00] swsusp: Registered nosave memory region: 000a -
000e
[0.00] swsusp: Registered nosave memory region: 000e -
000ee000
[0.00] swsusp: Registered nosave memory region: 000ee000 -
000ef000
[0.00] swsusp: Registered nosave memory region: 000ef000 -
0010
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 125826
[0.00] Kernel command line: BOOT_IMAGE=2.6.24-rc3-1avb root=LABEL=/
resume=LABEL=swap vga=791
[0.00] Enabling fast FPU save and restore... done.
[0.00] Enabling unmasked SIMD FPU exception support... done.
[0.00] Initializing CPU#0
[0.00] PID hash table entries: 2048 (order: 11, 8192 bytes)
[0.00] Detected 747.681 MHz
2.6.24-rc3-git1: Reported regressions from 2.6.23 (updated)
This message contains a list of some regressions from 2.6.23 which have been reported since 2.6.24-rc1 was released and for which there are no fixes in the mainline that I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. Subject : On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at virtual address 3d15b925 Submitter : Giacomo Catenazzi <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/24/487 http://bugzilla.kernel.org/show_bug.cgi?id=9246 Handled-By : Patch : Subject : EHCI causes system to resume instantly from S4 Submitter : Maxim Levitsky <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/27/66 http://bugzilla.kernel.org/show_bug.cgi?id=9258 Handled-By : "Rafael J. Wysocki" <[EMAIL PROTECTED]> Patch : Note: : the problem appears to heavily depend on hardware Subject : leds: ledtrig-timer calls sleeping function from invalid context Submitter : Márton Németh <[EMAIL PROTECTED]> References : http://bugzilla.kernel.org/show_bug.cgi?id=9264 Handled-By : Richard Purdie <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/attachment.cgi?id=13493=view Subject : Device mapper regression 2.6.23 vs. v2.6.23-6597-gcfa76f0 Submitter : Thomas Meyer <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/21/153 http://bugzilla.kernel.org/show_bug.cgi?id=9280 Handled-By : Patch : Subject : pdflush stuck in D state with v2.6.24-rc1-192-gef49c32 Submitter : Florin Iucha <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/28/65 http://bugzilla.kernel.org/show_bug.cgi?id=9291 Handled-By : Trond Myklebust <[EMAIL PROTECTED]> Fengguang Wu <[EMAIL PROTECTED]> Patch : Subject : Audigy 2 ZS Notebook prevents snd_emu10k1 module from loading/working Submitter : [EMAIL PROTECTED] References : http://bugzilla.kernel.org/show_bug.cgi?id=9304 Handled-By : Takashi Iwai <[EMAIL PROTECTED]> James Courtier-Dutton <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/attachment.cgi?id=13511=view Subject : PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object Submitter : Hans de Bruin <[EMAIL PROTECTED]> References : http://bugzilla.kernel.org/show_bug.cgi?id=9320 Handled-By : Robert Moore <[EMAIL PROTECTED]> Tejun Heo <[EMAIL PROTECTED]> Fu Michael <[EMAIL PROTECTED]> Patch : Subject : 2.6.24-rc1: pata_amd fails to detect 80-pin wire Submitter : "Thomas Lindroth" <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/11/7/152 http://bugzilla.kernel.org/show_bug.cgi?id=9322 Handled-By : Tejun Heo <[EMAIL PROTECTED]> Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/11/11/115 Subject : snd_hda_intel 2.6.24-rc2 bug: interrupts don't always work on Lenovo X60s Submitter : Roland Dreier <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/11/8/255 http://bugzilla.kernel.org/show_bug.cgi?id=9332 Handled-By : Patch : Subject : system hangs after a few minutes Submitter : Marcus Better <[EMAIL PROTECTED]> References : http://bugzilla.kernel.org/show_bug.cgi?id=9335 Handled-By : Andrew Morton <[EMAIL PROTECTED]> Alan Stern <[EMAIL PROTECTED]> Patch : Subject : 2.6.24 regression: hibernation hangs on "Suspending console" in low-battery condition Submitter : Andrey Borzenkov <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/11/11/28 http://bugzilla.kernel.org/show_bug.cgi?id=9344 Handled-By : "Rafael J. Wysocki" <[EMAIL PROTECTED]> Alexey Starikovskiy <[EMAIL PROTECTED]> Patch : Note: Not reproducible with -rc3 Subject : 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading Submitter : Chris Friedhoff <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/11/10/114 http://bugzilla.kernel.org/show_bug.cgi?id=9345 Handled-By : "Rafael J. Wysocki" <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/attachment.cgi?id=13651=view Subject : cd/dvd inaccessible in 2.6.24-rc2 Submitter : Will Trives <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/11/9/290 http://bugzilla.kernel.org/show_bug.cgi?id=9346 Handled-By : Len Brown <[EMAIL PROTECTED]> Patch : Subject
(solved) Re: Linux 2.6.24-rc* regression: sensors says "No sensors found"
> Stefan Richter wrote: >> I just booted 2.6.24-rc3 on two different PCs, one with i945 based MSI >> motherboard and i386 kernel and one with i945 based Apple motherboard >> and x86-64 kernel. Before that I ran linux 2.6.23. >> >> On both PCs, "sensors" exits with >>> No sensors found! > > now logged at http://bugzilla.kernel.org/show_bug.cgi?id=9451 Updating sysfsutils from version 1.3.0 to 2.1.0 cured this on both PCs. Thanks to Jean for pointing me to sysfsutils. -- Stefan Richter -=-=-=== =-== ==--- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No error when inotify_add_watch(/an/NFS/file)
J. Bruce Fields wrote: On Fri, Nov 23, 2007 at 11:20:55PM +, Phil Endecott wrote: Dear Experts, NFS doesn't work with inotify (and it looks like it can't, certainly not before NFS v4.1). However, if I give an NFS filename to inotify_add_watch(), I don't get an error. If it indicated an error in this case then I could easily fall back to some sort of polling. Without an error, I need some other way to detect NFS (and any other non-inotify-compatible filesystems). Any thoughts? The one reason I can think of that you might want that behavior is if you know you only access a given piece of the filesystem from one client at a time, and you still want inotify to work in that situation. That's a good point. (I'm assuming inotify still notifies you of changes that are made on the same client.) A quick test suggest that it does. But maybe you could handle that case by allowing inotify_add_watch() in the case where the nfs filesystem was mounted with the "nolock" option, and failing it otherwise, and telling people to turn on nolock if they're sure they know what they're doing. I'm not sure what your rationale for proposing that is, and I don't think it helps in my scenario; a user wants their inotify-using application to "just work", not to be told to "sudo re-mount". I suppose that I just need some way to determine whether I will get all, some, or none of the events that I've asked for. Phil. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No error when inotify_add_watch(/an/NFS/file)
On Fri, Nov 23, 2007 at 11:20:55PM +, Phil Endecott wrote: > Dear Experts, > > NFS doesn't work with inotify (and it looks like it can't, certainly not > before NFS v4.1). However, if I give an NFS filename to > inotify_add_watch(), I don't get an error. > > If it indicated an error in this case then I could easily fall back to some > sort of polling. Without an error, I need some other way to detect NFS > (and any other non-inotify-compatible filesystems). > > Any thoughts? The one reason I can think of that you might want that behavior is if you know you only access a given piece of the filesystem from one client at a time, and you still want inotify to work in that situation. (I'm assuming inotify still notifies you of changes that are made on the same client.) But maybe you could handle that case by allowing inotify_add_watch() in the case where the nfs filesystem was mounted with the "nolock" option, and failing it otherwise, and telling people to turn on nolock if they're sure they know what they're doing. --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: "buggy cmd640" message followed by soft lockup
On Saturday, 24 of November 2007, Frans Pop wrote: > On Saturday 24 November 2007, Bartlomiej Zolnierkiewicz wrote: > > Unfortunately I'm unable to reproduce this with: > > > > * VirtualBox 1.5.2 from http://www.virtualbox.org > > (VirtualBox-1.5.2_25433_fedora7-1.i586.rpm) > > > > * Fedora 7 with kernel-2.6.22.9-91.fc7 as a host OS > > > > * Fedora 8 with vanilla 2.6.24-rc2 as a guest OS > > (using the kernel config posted by you) > > > > so right now I suspect either a problem somehow specific to your system > > (narrowing it down using git-bisect to a specific kernel commit would > > greatly help) or a weird gcc bug (please make sure that you are using > > non-buggy/up-to-date gcc version). > > Thanks for looking at the issue Bartlomiej. > > I started a bisect yesterday and suddenly found I could not reproduce the > issue anymore. Today I tried again and _did_ manage to reproduce the issue > again, but only with a 24-rc3 kernel, not with 24-rc1 or 24-rc2 kernels. > And also only in combination with ata_piix and not with piix (one or the > other blacklisted). Also, after I changed the setup of the VM (changed > default boot medium from CD-ROM to hard disk), the kernel that failed > suddenly booted correctly. > Both of these (module used and boot order) could explain why I could not > reproduce the issue yesterday. > > After I changed the boot order back I could reproduce the BUG again, but > seemingly completely random for 24-rc1, 24-rc2 and 24-rc3: sometimes a > kernel boots fine, other times it fails. It may be related to way the > system is shut down, but I'm not sure of that. > > My conclusion is that the base cause is probably an issue somewhere in > VirtualBox, but I suspect there is also something not 100% clean in the > kernel code (if only a missing sanity check). Especially since I've never > yet been able to reproduce it with a kernel before 2.6.24-rcX. > > However, as it seems there are various variables involved and I cannot be > confident that I can reliably reproduce the issue with different kernels, I > do not really see any point in trying to bisect this. > > I suggest closing #9442 in bugzilla as it does not seem worth tracking this > as a regression. Closed. Thanks, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 4/4] Atmel MCI: Driver for Atmel on-chip MMC controllers
On Sat, 24 Nov 2007 10:48:39 -0800 David Brownell <[EMAIL PROTECTED]> wrote: > On Saturday 24 November 2007, Haavard Skinnemoen wrote: > > > > > > Why is this needed and is it perhaps something that can be moved > > > to the MMC core? > > > > We used to have lots of problems with overruns and underruns and > > those parameters were useful to limit the transfer rate. Now that > > the RDPROOF and WRPROOF bits seem to have taken care of these > > problems for good, I guess we can remove this parameter. > > Not all silicon *has* those bits though, right? Like at91rm9200. Right. The at91rm9200 doesn't have them, and I believe one of the at91sam926x chips (at91sam9261?) doesn't have them. So if we're going to merge this driver with at91_mci, I suppose it makes sense to keep this parameter. Haavard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.22.y][PATCH] atl1: disable broken 64-bit DMA
atl1: disable broken 64-bit DMA
[ Upstream commit: 5f08e46b621a769e52a9545a23ab1d5fb2aec1d4 ]
The L1 network chip can DMA to 64-bit addresses, but multiple descriptor
rings share a single register for the high 32 bits of their address, so
only a single, aligned, 4 GB physical address range can be used at a time.
As a result, we need to confine the driver to a 32-bit DMA mask, otherwise
we see occasional data corruption errors in systems containing 4 or more
gigabytes of RAM.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
Cc: Luca Tettamanti <[EMAIL PROTECTED]>
Cc: Chris Snook <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_main.c | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index 6862c11..1b7a5a8 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -2097,21 +2097,26 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
struct net_device *netdev;
struct atl1_adapter *adapter;
static int cards_found = 0;
- bool pci_using_64 = true;
int err;
err = pci_enable_device(pdev);
if (err)
return err;
- err = pci_set_dma_mask(pdev, DMA_64BIT_MASK);
+ /*
+* The atl1 chip can DMA to 64-bit addresses, but it uses a single
+* shared register for the high 32 bits, so only a single, aligned,
+* 4 GB physical address range can be used at a time.
+*
+* Supporting 64-bit DMA on this hardware is more trouble than it's
+* worth. It is far easier to limit to 32-bit DMA than update
+* various kernel subsystems to support the mechanics required by a
+* fixed-high-32-bit system.
+*/
+ err = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
if (err) {
- err = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
- if (err) {
- dev_err(>dev, "no usable DMA configuration\n");
- goto err_dma;
- }
- pci_using_64 = false;
+ dev_err(>dev, "no usable DMA configuration\n");
+ goto err_dma;
}
/* Mark all PCI regions associated with PCI device
* pdev as being reserved by owner atl1_driver_name
@@ -2176,7 +2181,6 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
netdev->ethtool_ops = _ethtool_ops;
adapter->bd_number = cards_found;
- adapter->pci_using_64 = pci_using_64;
/* setup the private structure */
err = atl1_sw_init(adapter);
@@ -2193,9 +2197,6 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
*/
/* netdev->features |= NETIF_F_TSO; */
- if (pci_using_64)
- netdev->features |= NETIF_F_HIGHDMA;
-
netdev->features |= NETIF_F_LLTX;
/*
--
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: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
--- Crispin Cowan <[EMAIL PROTECTED]> wrote: > Andrew Morgan wrote: > > Its not so much why you are wrong, as being clear that we're not using a > > generic name and inadvertently limiting ourselves to a SMACK-like model... > > > It seems we all agree that it is a bad idea to tie a POSIX Capability to > one specific LSM model. I think that's fair. > > It feels to me as if a MAC "override capability" is, if true to its > > name, extra to the MAC model; any MAC model that needs an 'override' to > > function seems under-specified... That's the reason we have a privilege model, not just for MAC, but DAC as well. The Unix/Linux model where administration and system tasks are performed by normal processes that are just a little bit special, as opposed to a completely separate set of interfaces, often makes things look a little contrived. This is one of the advantages of SELinux, with it's model of complete specification. > An interesting observation. This is a core part of why I have always > found the hierarchical models BLP and Biba to be unsatisfying. These > systems essentially have one simple fixed policy "process label must > dominate object label to get access", and then you express all the rest > of your "policy" by labeling your stuff. It is impossible to manage such > systems without a MAC_OVERRIDE escape hatch of some kind, because the > "policy" is too simple and inflexible, e.g. it does not allow you to > reclassify anything. Wll... That's sort of what the "mandatory" is all about. > > SELinux clearly feels no need for one, > > > That's not quite right. More specifically, it already has one in the > form of unconfined_t. AppArmor has a similar escape hatch in the "Ux" > permission. Its not that they don't need one, it is that they already > have one. They get to have one because they allow you to actually write > a policy that is more nuanced than "process label must dominate object > label". That SELinux doesn't require any capabilities is an artifact of design on that LSM. The whole notion of privilege is somewhat out of context when your model is to explicitly state how every possible decision ought to go. That is one important philosophical difference between SELinux and Smack, with Smack taking a higher level view on policy and hence privilege. > > and browsing through your SMACK patch, there are many instances where > > this capability is used as an convenience privileged override. However, > > in other situations, it appears as if the capability is required for > > basic SMACK operations to succeed. > > > > My sense is that there is a case to be made for: CAP_MAC_ADMIN and > > CAP_MAC_OVERRIDE here. The former being for cases where SMACK (or > > whatever MAC supports it) requires privilege to perform a privileged MAC > > operation, and the latter for saying "OK, I'm without a paddle but need > > one" (or words to that effect). > > > I don't get the difference. Both seem to permit the process to violate > the MAC policy. I could make up a meaning for MAC_ADMIN that is > different from MAC_OVERRIDE in the AppArmor sense, but I don't want to > :-) and worse, I suspect the distinction would be different for each > LSM. So let not, and just have one MAC_OVERRIDE capability. I am pretty close to agreeing with Andrew that a distinction between allowing a process to change the state of the MAC configuration (e.g. set file or process MAC labels, add rules) and violating the rules is in order. SELinux can ignore both, AppArmor can ignore one, and the upcoming DG/UX port* can ask for further granularity when they show up. I will look in this direction and see if I can patches proposed before the virus in my sinuses knocks me out completely. Thank you. * DG/UX supported over 330 capabilities and is my personal poster child for excesses of granularity with regard to capabilities. I don't really expect to see a Linux port. Casey Schaufler [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: [BUG] jiffies counter leaps in 2.6.24-rc3
On Saturday, 24 of November 2007, Stefano Brivio wrote: > On Sat, 24 Nov 2007 19:48:58 +0100 > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > NO_HZ? Highres timers? > > CONFIG_HZ_1000=y > # CONFIG_HIGH_RES_TIMERS is not set > > > I understand that the previous kernels behave correctly. All of them? > > 2.6.21 behaved correctly. Sorry but git-bisect would take a lot of time (I > can't reliably reproduce the jiffies jump), so I would avoid that if not > strictly needed. Well, it would be good to know if 2.6.23 behaves correctly, at least. Thanks, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Len Brown ha scritto: On Sunday 21 October 2007 05:43, [EMAIL PROTECTED] wrote: have emerged lm_sensors but can't get it running - it keeps saying "No sensors found!" and complaining about kernel drivers not properly setup. I have attached the output of sensors-detect, from which it seems that the kernel is OK. In this case, getting sensors installed is the opposite of what you want to do. The idea is to simplify the system until it works, then figure out what simplification made it work. ie. disable sensors entirely by building a kernel with CONFIG_HWMON=n If that makes things work, then it is a clue. If that was disabled already, then just keep it disabled. It is disabled since when I abandoned the lm_sensors approach; I remember that I did some more testing with lm_sensors and got almost all chips identified, although didn't know how to use lm_sensors to generate some useful logs. I agree with you that we have to simplify the system down. Note: when I built kernel 2.6.24-rc3 to see if it is still affected by bug #9147, CONFIG_HWMON was enabled instead (and the problem was verified anyway). I don't recall how that setting got enabled, however I did not enable it manually and I was not enabling lm_sensors support. Best regards, -- Daniele C. cheers, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Laptop keyboard unusable when ACPI is active
Len Brown ha scritto: On Thursday 22 November 2007 02:24, [EMAIL PROTECTED] wrote: It is also important to note that this bug always comes with bug 8740 http://bugzilla.kernel.org/show_bug.cgi?id=8740 (also confirmed and also an ACPI issue). No, 8740 is not an ACPI issue. http://bugzilla.kernel.org/show_bug.cgi?id=8740#c2 Sorry for the misleading statement; I no more think that it is an ACPI issue. Although I am still curious about the reason of these bugs happening together even on different hardware configurations; maybe a side effect of the same kernel bug? No idea. Best regards, -- Daniele C. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [RFC 4/4] Atmel MCI: Driver for Atmel on-chip MMC controllers
On Saturday 24 November 2007, Haavard Skinnemoen wrote: > > > > Why is this needed and is it perhaps something that can be moved to > > the MMC core? > > We used to have lots of problems with overruns and underruns and those > parameters were useful to limit the transfer rate. Now that the RDPROOF > and WRPROOF bits seem to have taken care of these problems for good, I > guess we can remove this parameter. Not all silicon *has* those bits though, right? Like at91rm9200. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: "buggy cmd640" message followed by soft lockup
On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote: [--snip--] > Rafael, I see that you've filled a bug for this bugreport into kernel > bugzilla tracker (one day after the bugreport): > > http://bugzilla.kernel.org/show_bug.cgi?id=9442 > > Since we try to address regressions with the highest priority in the > IDE-land (and usually they get fixed quickly) I would strongly prefer to > use bugzilla only for long-term bugs and avoid the needless bureaucracy. As a rule, I put all of the reported regressions into the Bugzilla early. You are not required to use these entries for tracking the bugs, though. If you don't want to, just leave the entry as is and I'll close it when the fix is in the Linus' tree. > Therefore I kindly ask you to defer filling bugs for new bugreports for > a week or two, and give us some time to react (and always ping me about > the bugreport status before filling bugzilla entry). Well, I thought you'd get an email from the Bugzilla, but of course I can notify you directly about reported regressions related to IDE. > The alternative solution would be that you fill all new bugreports but > then please assign them to yourself and track their status (if after two > weeks the problem is not fixed feel free to reassign bug to me). I can do that, but please note that the bugs filed against IDE are assigned to you automatically, so I'll have to reassign them to me (as I've just done with this particular entry). If you don't want them to be assigned to you at all, please contact the Bugzilla administrators and ask them to change that. Thanks, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] jiffies counter leaps in 2.6.24-rc3
On Sat, 24 Nov 2007 19:48:58 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > NO_HZ? Highres timers? CONFIG_HZ_1000=y # CONFIG_HIGH_RES_TIMERS is not set > I understand that the previous kernels behave correctly. All of them? 2.6.21 behaved correctly. Sorry but git-bisect would take a lot of time (I can't reliably reproduce the jiffies jump), so I would avoid that if not strictly needed. -- Ciao Stefano - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: unable to handle kernel NULL pointer dereference at virtual address 00000000
Rafael J. Wysocki wrote: > On Saturday, 24 of November 2007, Udo van den Heuvel wrote: >> Hello, >> >> What happened in the attached messages? >> It was on a VIA Epia EN12000, while compiling. >> Yes, the machine has been stable before and after that issue. >> So I suspect no hardware issues. > > Which kernel is this? Sorry for not mentioning: 2.6.23.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: [PATCH 2/9]: Reduce Log I/O latency
On Fri, Nov 23, 2007 at 01:01:15PM +0100, Andi Kleen wrote: > On Fri, Nov 23, 2007 at 03:03:29PM +1100, David Chinner wrote: > > On Fri, Nov 23, 2007 at 03:53:17AM +0100, Andi Kleen wrote: > > > On Fri, Nov 23, 2007 at 12:15:39AM +1100, David Chinner wrote: > > > > On Thu, Nov 22, 2007 at 01:06:11PM +0100, Andi Kleen wrote: > > > > > > FWIW from a "real time" database POV this seems to make sense to > > > > > > me... > > > > > > in fact, we probably rely on filesystem metadata way too much > > > > > > (historically it's just "worked" although we do seem to get > > > > > > issues > > > > > > on ext3). > > > > > > > > > > For that case you really would need priority inheritance: any metadata > > > > > IO on behalf or blocking a process needs to use the process' block IO > > > > > priority. > > > > > > > > How do you do that when the processes are blocking on semaphores, > > > > mutexes or rw-semaphores in the fileysystem three layers removed from > > > > the I/O in progress? > > > > > > [...] I didn't say it was easy (or rather explicitely said it would be > > > tricky). > > > Probably it would be possible to fold it somehow into rt mutexes PI, > > > but it's not easy and semaphores would need to be handled too. > > > > > > Just my point was to solve the metadata RT problem unconditionally > > > increasing > > > the priority is a bad idea and not really a replacement to a "full" > > > solution. Short term a user can just increase the priority of all the XFS > > > threads anyways. > > > > The point is that it's not actually a thread-based problem - the priority > > can't be inherited via the traditional mutex-like manner. There is no > > connection between a thread and an I/o it has already issued and so you > > can't transfer a priority from a blocked thread to an issued-but-blocked > > i/o > > It could be handled in theory similar to standard CPU priority inheritance -- > \ > keep track of IO priority of all threads you block and boost your IO priority > always to that level. But it would be probably not very easy to do. Well I think what Dave is saying is that we can't find the related process. The submitter process may have even exited before the flush happens.. You'd instead have to keep track of (the max of) all the submitted I/O segment priorities related to the transaction instead. But I'm sure there are complications. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: unable to handle kernel NULL pointer dereference at virtual address 00000000
On Saturday, 24 of November 2007, Udo van den Heuvel wrote: > Hello, > > What happened in the attached messages? > It was on a VIA Epia EN12000, while compiling. > Yes, the machine has been stable before and after that issue. > So I suspect no hardware issues. Which kernel is this? Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] jiffies counter leaps in 2.6.24-rc3
On Saturday, 24 of November 2007, Stefano Brivio wrote: > It looks like the jiffies counter sometimes jumps back and forth of some > hundreds seconds in 2.6.24-rc3. I observed that this happens when I use the > su(1) command, e.g.: > > Nov 24 06:17:17 morte [190769.065301] wmaster0: STA 00:14:c1:35:8d:eb Average > rate: 232 (6730/29) > Nov 24 06:17:22 morte su[16826]: Successful su for root by st3 > Nov 24 06:17:22 morte su[16826]: + pts/1 st3:root > Nov 24 06:17:22 morte su(pam_unix)[16826]: session opened for user root by > (uid=1000) > Nov 24 06:17:38 morte [715682.606983] b43-phy2 ERROR: PHY transmission error > Nov 24 06:18:17 morte [715707.765415] wmaster0: STA 00:14:c1:35:8d:eb Average > rate: 194 (970/5) > > or > > Nov 23 20:55:40 morte [627074.320296] wmaster0: STA 00:14:c1:35:8d:eb Average > rate: 10 (550/55) > Nov 23 20:56:01 morte su[5452]: Successful su for root by st3 > Nov 23 20:56:01 morte su[5452]: + pts/4 st3:root > Nov 23 20:56:01 morte su(pam_unix)[5452]: session opened for user root by > (uid=1000) > Nov 23 20:56:03 morte su(pam_unix)[5452]: session closed for user root > Nov 23 20:56:40 morte [167187.102931] wmaster0: STA 00:14:c1:35:8d:eb Average > rate: 10 (40/4) > > or > > Nov 23 06:31:00 morte [156536.124549] wmaster0: STA 00:14:c1:35:8d:eb Average > rate: 240 (6480/27) > Nov 23 06:31:58 morte su[4350]: Successful su for root by st3 > Nov 23 06:31:58 morte su[4350]: + pts/0 st3:root > Nov 23 06:31:58 morte su(pam_unix)[4350]: session opened for user root by > (uid=1000) > Nov 23 06:32:09 morte [587438.574530] wmaster0: STA 00:14:c1:35:8d:eb Average > rate: 240 (4080/17) > > (I checked with a clock the timestamp prepended by syslog-ng, and it's > correct.) > > I'm thinking this could be somehow related to the setpriority() call made > by su(1), but I don't know how to debug this further. Any clue? NO_HZ? Highres timers? I understand that the previous kernels behave correctly. All of them? Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: I/O error, system hangs
Gabriel C wrote: > James Bottomley wrote: >> On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote: >>> James Bottomley wrote: On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote: > Le 24.11.2007 07:42, James Bottomley a écrit : >> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote: >>> Le 23.11.2007 12:38, Hannes Reinecke a écrit : Hannes Reinecke wrote: > Laurent Riffard wrote: >> Le 21.11.2007 23:41, Andrew Morton a écrit : >>> On Wed, 21 Nov 2007 22:45:22 +0100 >>> Laurent Riffard <[EMAIL PROTECTED]> wrote: >>> Le 21.11.2007 05:45, Andrew Morton a écrit : > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ Hello, My system hangs shortly after I logged in Gnome desktop. SysRq-W shows that a bunch of task are blocked in "D" state, they seem to wait for some I/O completion. I can try to hand-copy some data if requested. I found these messages in dmesg: ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 EXT3-fs: mounted filesystem with ordered data mode. sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sda, sector 16460 ReiserFS: sda7: found reiserfs format "3.6" with standard journal ReiserFS: sda7: using ordered data mode -- ReiserFS: sda7: Using r5 hash to sort names sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 19632 sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 40037363 Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k lp0: using parport0 (interrupt-driven). These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible. 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. Maybe something is broken in pata_via driver ? >>> Could be - >>> libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch >>> and >>> pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch >>> touch pata_via.c. >> None of the above... >> >> I did a bisection, it spotted git-scsi-misc.patch. >> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works >> fine. >> >> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do >> not >> requeue requests if REQ_FAILFAST is set" is the real culprit. The >> other >> commits are touching documentation or drivers I don't use. I'll try >> to revert only this one this evening. >>> I can confirm : reverting commit >>> 8655a546c83fc43f0a73416bbd126d02de7ad6c0 >>> does fix the problem. >>> > Hmm. Weird. I'll have a look into it. Apparently I'll be returning an > error where > I shouldn't. Checking ... > Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set) when FAILFAST is set. Which is clearly wrong. The attached patch fixes this. >>> Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with >>> I/O errors. >> I think the problem is the way we treat BLOCKED and QUIESCED (the latter >> is the state that the domain validation uses and which we cannot kill >> fastfail on). It's definitely wrong to kill fastfail requests when the >> state is QUIESCE. >> >> This patch (which is applied on top of Hannes original) separates the >> BLOCK and QUIESCE states correctly ... does this fix the problem? > No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems) OK, could you post dmesgs again, please. I actually tested this with an aic79xx card, and for me it does cause Domain Validation to succeed again. >>> Are the patches indeed to fix that problem as well ? >>> >>> http://lkml.org/lkml/2007/11/23/5 >> That dmesg is from an unknown SCSI card exhibiting Domain Validation >> problems, so it's a reasonable probability, yes ... but you'll need the >> additional hack I just did to prevent further intermittent failures. > > My controller is: > > 03:0e.0 SCSI storage controller [0100]: Adaptec AIC-7892P U160/m [9005:008f] > (rev 02) > > I'll try the patches in a bit. With your patches my problem(s) are solved. Domain Validation works again. ... [ 32.179521] scsi
Re: [RFC] Documentation about unaligned memory access
On Sat, Nov 24, 2007 at 06:35:25PM +0100, Pierre Ossman wrote: > On Sat, 24 Nov 2007 17:22:36 + > Luciano Rocha <[EMAIL PROTECTED]> wrote: > > > On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote: > > > It most certainly does not. gcc will assume that an int* has int > > > alignment. memcpy() is a builtin, which gcc can translate to pretty much > > > anything. And C specifies that a pointer to foo, will point to a real > > > object of type foo, so gcc can't be blamed for the unsafe typecasts. I > > > have tested this the hard way, so this is not just speculation. > > > > Yes, on *int and other assumed aligned pointers, gcc uses its internal > > version. > > > > However, my point is that those pointers, unless speaking of packed > > structures, can safely be assumed aligned, while char*/void* can't. > > > > I get the sensation we're violently in agreement here, just misunderstanding > each other. :) That's it. :) Sorry for the noise,... -- lfr 0/0 pgprb39HuMXhL.pgp Description: PGP signature
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
Simon, can you test this patch? I think it's the most straightforward
2.6.24 fix.
diff -r c60016ba6237 net/core/netpoll.c
--- a/net/core/netpoll.cTue Nov 13 09:09:36 2007 -0800
+++ b/net/core/netpoll.cFri Nov 23 13:10:28 2007 -0600
@@ -203,6 +203,12 @@ static void refill_skbs(void)
spin_unlock_irqrestore(_pool.lock, flags);
}
+/* used to mark an skb as owned by netpoll */
+static void netpoll_skb_destroy(struct sk_buff *skb)
+{
+ return;
+}
+
static void zap_completion_queue(void)
{
unsigned long flags;
@@ -219,10 +225,12 @@ static void zap_completion_queue(void)
while (clist != NULL) {
struct sk_buff *skb = clist;
clist = clist->next;
- if (skb->destructor)
+ if (skb->destructor == netpoll_skb_destroy) {
+ skb->destructor = NULL;
+ __kfree_skb(skb);
+ }
+ else
dev_kfree_skb_any(skb); /* put this one back */
- else
- __kfree_skb(skb);
}
}
@@ -252,6 +260,7 @@ repeat:
atomic_set(>users, 1);
skb_reserve(skb, reserve);
+ skb->destructor = netpoll_skb_destroy;
return skb;
}
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 4/4] Atmel MCI: Driver for Atmel on-chip MMC controllers
On Sat, 24 Nov 2007 18:00:23 +0100
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> On Fri, 23 Nov 2007 13:20:13 +0100
> Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
>
> > This is a driver for the MMC controller on the AP7000 chips from
> > Atmel. It should in theory work on AT91 systems too with some
> > tweaking, but since the DMA interface is quite different, it's not
> > entirely clear if it's worth it.
> >
> > This driver has been around for a while in BSPs and kernel sources
> > provided by Atmel, but this particular version uses the generic DMA
> > Engine framework (with the slave extensions) instead of an
> > avr32-only DMA controller framework.
> >
> > Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
>
> Why didn't I get a cc? Don't you love me any more? :'(
Sorry, I didn't really mean to submit it for inclusion yet, as I
explained in the first mail in the series. I probably should have left
out the signoff to make this clearer.
Thanks for the feedback anyway.
> Could you add a note to MAINTAINERS as well?
Yes, I intend to do that in the final version.
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index 5fef678..687cf8b 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -91,6 +91,16 @@ config MMC_AT91
> >
> > If unsure, say N.
> >
> > +config MMC_ATMELMCI
> > + tristate "Atmel Multimedia Card Interface support"
> > + depends on AVR32 && DMA_ENGINE
> > + help
> > + This selects the Atmel Multimedia Card Interface. If you
> > have
> > + a AT91 (ARM) or AT32 (AVR32) platform with a Multimedia
> > Card
> > + slot, say Y or M here.
> > +
> > + If unsure, say N.
> > +
> > config MMC_IMX
> > tristate "Motorola i.MX Multimedia Card Interface support"
> > depends on ARCH_IMX
>
> Now this gets a bit confusing as we'll have two drivers for AT91. Any
> status report on merging these?
I haven't really started working on that I'm afraid. I imagine the
parts dealing with data transfer will have to be completely separate
due to the differences in the DMA interface. Probably the interrupt
handler as well, unless we're willing to live with a few #ifdefs in it.
> I can accept having two drivers (for a while at least), but the
> Kconfig help texts should explain the sordid details.
Yeah, the help text is indeed confusing. I'll update it.
> > +
> > +/* Those printks take an awful lot of time... */
> > +#ifndef DEBUG
> > +static unsigned int fmax = 1500U;
> > +#else
> > +static unsigned int fmax = 100U;
> > +#endif
> > +module_param(fmax, uint, 0444);
> > +MODULE_PARM_DESC(fmax, "Max frequency in Hz of the MMC bus clock");
> > +
>
> Why is this needed and is it perhaps something that can be moved to
> the MMC core?
We used to have lots of problems with overruns and underruns and those
parameters were useful to limit the transfer rate. Now that the RDPROOF
and WRPROOF bits seem to have taken care of these problems for good, I
guess we can remove this parameter.
> > +
> > +static int req_dbg_open(struct inode *inode, struct file *file)
> > +{
>
> This also looks like something that can be made general.
Yeah, could be. I'll look into it.
> > +
> > + if (mmc->ios.bus_mode == MMC_BUSMODE_OPENDRAIN)
> > + cmdr |= MCI_BIT(OPDCMD);
> > +
> > + dev_dbg(>class_dev,
> > + "cmd: op %02x arg %08x flags %08x, cmdflags
> > %08lx\n",
> > + cmd->opcode, cmd->arg, cmd->flags, (unsigned
> > long)cmdr); +
>
> The debug output in the core should make this redundant.
Yes, most of it is redundant, but the hardware register dump might
still make sense, but it should probably be turned into a dev_vdbg().
> > +
> > +static void atmci_request(struct mmc_host *mmc, struct mmc_request
> > *mrq) +{
>
> I seem to recall that atmci couldn't currently handle transfers that
> weren't a multiple of four. Could you please add a check for this and
> fail the request with -EINVAL when that happens?
Yeah, although I want to fix that before submitting the final version.
The hardware has a special "byte mode" which will be slow, but it
should work.
> > + /* Enable the MCI controller */
> > + mci_writel(host, CR, MCI_BIT(MCIEN));
> > + } else {
> > + /* Disable the MCI controller */
> > + mci_writel(host, CR, MCI_BIT(MCIDIS));
> > + }
> > +
>
> I hope "disable" here doesn't power down the card, as that would be
> incorrect.
No, it just stops the clock. I suppose we could use clk_disable()
instead of resetting the controller, but I don't think there's any
controller state we really care about at this point anyway.
> > + dev_dbg(>class_dev, "bytes xfered: %u\n",
> > + data->bytes_xfered);
> > +
>
> The debug output here is already provided by the MMC core.
Indeed. I'll remove it.
> > +
> > +static int __exit atmci_remove(struct platform_device *pdev)
> > +{
> > + struct atmel_mci *host =
Re: [BUG] jiffies counter leaps in 2.6.24-rc3
On Sat, 24 Nov 2007 18:56:57 +0100 Frans Pop <[EMAIL PROTECTED]> wrote: > Stefano Brivio wrote: > > It looks like the jiffies counter sometimes jumps back and forth of some > > hundreds seconds in 2.6.24-rc3. I observed that this happens when I use > > the su(1) command, e.g.: > > Can you please explain what exactly the problem is here? > > Are you perhaps referring to the number between square brackets for the su > log lines? In that case there is no problem as in that case the number is > not jiffies, but the process ID (PID) of the su process... Sorry guy but I'm not _that_ idiot. Please notice jiffies values before and after that. -- Ciao Stefano - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: I/O error, system hangs
James Bottomley wrote: > On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote: >> James Bottomley wrote: >>> On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote: Le 24.11.2007 07:42, James Bottomley a écrit : > On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote: >> Le 23.11.2007 12:38, Hannes Reinecke a écrit : >>> Hannes Reinecke wrote: Laurent Riffard wrote: > Le 21.11.2007 23:41, Andrew Morton a écrit : >> On Wed, 21 Nov 2007 22:45:22 +0100 >> Laurent Riffard <[EMAIL PROTECTED]> wrote: >> >>> Le 21.11.2007 05:45, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ >>> Hello, >>> >>> My system hangs shortly after I logged in Gnome desktop. SysRq-W >>> shows >>> that a bunch of task are blocked in "D" state, they seem to wait for >>> some I/O completion. I can try to hand-copy some data if requested. >>> >>> I found these messages in dmesg: >>> >>> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 >>> EXT3-fs: mounted filesystem with ordered data mode. >>> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT >>> driverbyte=DRIVER_OK,SUGGEST_OK >>> end_request: I/O error, dev sda, sector 16460 >>> ReiserFS: sda7: found reiserfs format "3.6" with standard journal >>> ReiserFS: sda7: using ordered data mode >>> -- >>> ReiserFS: sda7: Using r5 hash to sort names >>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT >>> driverbyte=DRIVER_OK,SUGGEST_OK >>> end_request: I/O error, dev sdb, sector 19632 >>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT >>> driverbyte=DRIVER_OK,SUGGEST_OK >>> end_request: I/O error, dev sdb, sector 40037363 >>> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 >>> extents:1 across:1048568k >>> lp0: using parport0 (interrupt-driven). >>> >>> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% >>> reproducible. >>> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. >>> >>> Maybe something is broken in pata_via driver ? >>> >> Could be - >> libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch >> and >> pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch >> touch pata_via.c. > None of the above... > > I did a bisection, it spotted git-scsi-misc.patch. > I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works > fine. > > I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do > not > requeue requests if REQ_FAILFAST is set" is the real culprit. The > other > commits are touching documentation or drivers I don't use. I'll try > to revert only this one this evening. >> I can confirm : reverting commit >> 8655a546c83fc43f0a73416bbd126d02de7ad6c0 >> does fix the problem. >> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where I shouldn't. Checking ... >>> Ok, found it. We are blocking even special commands (ie requests with >>> PREEMPT not set) >>> when FAILFAST is set. Which is clearly wrong. The attached patch fixes >>> this. >> Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O >> errors. > I think the problem is the way we treat BLOCKED and QUIESCED (the latter > is the state that the domain validation uses and which we cannot kill > fastfail on). It's definitely wrong to kill fastfail requests when the > state is QUIESCE. > > This patch (which is applied on top of Hannes original) separates the > BLOCK and QUIESCE states correctly ... does this fix the problem? No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems) >>> OK, could you post dmesgs again, please. I actually tested this with an >>> aic79xx card, and for me it does cause Domain Validation to succeed >>> again. >>> >> Are the patches indeed to fix that problem as well ? >> >> http://lkml.org/lkml/2007/11/23/5 > > That dmesg is from an unknown SCSI card exhibiting Domain Validation > problems, so it's a reasonable probability, yes ... but you'll need the > additional hack I just did to prevent further intermittent failures. My controller is: 03:0e.0 SCSI storage controller [0100]: Adaptec AIC-7892P U160/m [9005:008f] (rev 02) I'll try the patches in a bit. > > James > Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: sata NCQ blacklist entry
On Saturday, 24 of November 2007, Jan-Simon Möller wrote:
> Am Freitag 23 November 2007 08:21:09 schrieb Andrew Morton:
> > On Tue, 13 Nov 2007 21:55:15 +0100 Jan-Simon M__ller <[EMAIL PROTECTED]>
> > wrote:
> > > Hi!
> >
> > You removed from cc the guys who are most likely to fix this. Please
> > always do reply-to-all.
> Sri, will remember that.
> >
> > > Just using kernel 2.6.24-rc2 (325d22df7b19e0116aff3391d3a03f73d0634ded).
> > >
> >
> > So is this problem (which in another email you attributed to smartd)
> Even without smartd in my default runlevel it happens at some point.
>
> > also
> > present in 2.6.23?
> I compiled and tested 2.6.23.8. Smartd enabled, nothing noticed, dmesg is
> really clean:
> dmesg | grep ata
> ACPI: SSDT 7F6D3C3F, 02DD (r1 SataRe SataAhci 1000 INTL 20060912)
> PERCPU: Allocating 46888 bytes of per cpu data
> Memory: 2042960k/2087744k available (2062k kernel code, 44396k reserved, 982k
> data, 324k init)
> ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
> ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
> libata version 2.21 loaded.
> ata1: SATA max UDMA/133 cmd 0xc234e100 ctl 0x bmdma
> 0x irq 4347
> ata2: SATA max UDMA/133 cmd 0xc234e180 ctl 0x bmdma
> 0x irq 4347
> ata3: SATA max UDMA/133 cmd 0xc234e200 ctl 0x bmdma
> 0x irq 4347
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: ATA-8: WDC WD2500BEVS-22UST0, 01.01A01, max UDMA/133
> ata1.00: 488397168 sectors, multi 16: LBA48 NCQ (depth 31/32)
> ata1.00: configured for UDMA/133
> ata2: SATA link down (SStatus 0 SControl 300)
> ata3: SATA link down (SStatus 0 SControl 300)
> ata_piix :00:1f.1: version 2.12
> scsi3 : ata_piix
> scsi4 : ata_piix
> ata4: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma
> 0x00011810 irq 14
> ata5: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma
> 0x00011818 irq 15
> ata4.00: ATAPI: HL-DT-ST DVDRAM GSA-T20N, WW01, max UDMA/33
> ata4.00: configured for UDMA/33
> EXT3-fs: mounted filesystem with ordered data mode.
>
>
>
> >
> > And is is still present in 2.6.24-rc3?
> Went back to 2.6.24-rc3 ...
> Yes, but not at boot when smartd is started.
>
> dmesg | grep ata
> ACPI: SSDT 7F6D3C3F, 02DD (r1 SataRe SataAhci 1000 INTL 20060912)
> PERCPU: Allocating 46968 bytes of per cpu data
> Memory: 2048732k/2087744k available (2219k kernel code, 38624k reserved, 992k
> data, 344k init)
> ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
> libata version 3.00 loaded.
> ata1: SATA max UDMA/133 abar [EMAIL PROTECTED] port 0xfc404100 irq 4347
> ata2: SATA max UDMA/133 abar [EMAIL PROTECTED] port 0xfc404180 irq 4347
> ata3: SATA max UDMA/133 abar [EMAIL PROTECTED] port 0xfc404200 irq 4347
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: ATA-8: WDC WD2500BEVS-22UST0, 01.01A01, max UDMA/133
> ata1.00: 488397168 sectors, multi 16: LBA48 NCQ (depth 31/32)
> ata1.00: configured for UDMA/133
> ata2: SATA link down (SStatus 0 SControl 300)
> ata3: SATA link down (SStatus 0 SControl 300)
> ata_piix :00:1f.1: version 2.12
> scsi3 : ata_piix
> scsi4 : ata_piix
> ata4: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x1810 irq 14
> ata5: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15
> ata4.00: ATAPI: HL-DT-ST DVDRAM GSA-T20N, WW01, max UDMA/33
> ata4.00: configured for UDMA/33
> EXT3-fs: mounted filesystem with ordered data mode.
> ata1.00: exception Emask 0x2 SAct 0x73 SErr 0x0 action 0x2 frozen
> ata1.00: spurious completions during NCQ issue=0x0 SAct=0x73
> FIS=004040a1:0008
> ata1.00: cmd 60/10:00:d4:82:31/00:00:07:00:00/40 tag 0 cdb 0x0 data 8192 in
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/08:08:9c:e5:cc/00:00:08:00:00/40 tag 1 cdb 0x0 data 4096 in
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/10:20:24:61:25/00:00:09:00:00/40 tag 4 cdb 0x0 data 8192 in
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/58:28:c4:65:25/00:00:09:00:00/40 tag 5 cdb 0x0 data 45056 in
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/20:30:7c:f6:a3/00:00:05:00:00/40 tag 6 cdb 0x0 data 16384 in
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: configured for UDMA/133
> ata1: EH complete
> ata1.00: exception Emask 0x2 SAct 0x187 SErr 0x0 action 0x2 frozen
> ata1.00: spurious completions during NCQ issue=0x0 SAct=0x187
> FIS=004040a1:0040
> ata1.00: cmd 60/08:00:ec:af:10/00:00:04:00:00/40 tag 0 cdb 0x0 data 4096 in
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/10:08:8c:e6:d8/00:00:04:00:00/40 tag 1 cdb 0x0 data 8192 in
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/20:10:24:1a:da/00:00:04:00:00/40 tag 2 cdb 0x0 data 16384 in
> ata1.00: status: { DRDY }
> ata1.00: cmd 61/01:38:15:b3:30/00:00:07:00:00/40 tag 7 cdb 0x0 data 512 out
> ata1.00: status: { DRDY }
> ata1.00: cmd
Re: 2.6.24-rc3-mm1 (sync is slow ?)
kosaki wrote: > Hi, Andrew > >>> Hi, Andrew >>> >>> I got following result in 'sync' command. >>> It was too slow. (memory controller config is off ;) >>> I attaches my .config. >>> == > (snip) >> Well I wonder how we did that. >> >> It seems OK here from a quick test (i386, ext3-on-IDE). >> >> Maybe device driver/block breakage? Try revert http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff_plain;h=8655a546c83fc43f0a73416bbd126d02de7ad6c0;hp=5bc717b6bdaaf52edf365eb7d9d8c89fec79df5d See also : http://lkml.org/lkml/2007/11/23/5 and search for '2.6.24-rc3-mm1: I/O error, system hangs' on LKML > > I tested x86, ext3-on-SATA(/dev/sda). > It seems works well. > > Hmm... IDE/SATA is fine here as well just SCSI broke Regards, Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc3-mm1: I/O error, system hangs
On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote: > James Bottomley wrote: > > On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote: > >> Le 24.11.2007 07:42, James Bottomley a écrit : > >>> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote: > Le 23.11.2007 12:38, Hannes Reinecke a écrit : > > Hannes Reinecke wrote: > >> Laurent Riffard wrote: > >>> Le 21.11.2007 23:41, Andrew Morton a écrit : > On Wed, 21 Nov 2007 22:45:22 +0100 > Laurent Riffard <[EMAIL PROTECTED]> wrote: > > > Le 21.11.2007 05:45, Andrew Morton a écrit : > >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ > > Hello, > > > > My system hangs shortly after I logged in Gnome desktop. SysRq-W > > shows > > that a bunch of task are blocked in "D" state, they seem to wait for > > some I/O completion. I can try to hand-copy some data if requested. > > > > I found these messages in dmesg: > > > > ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 > > EXT3-fs: mounted filesystem with ordered data mode. > > sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT > > driverbyte=DRIVER_OK,SUGGEST_OK > > end_request: I/O error, dev sda, sector 16460 > > ReiserFS: sda7: found reiserfs format "3.6" with standard journal > > ReiserFS: sda7: using ordered data mode > > -- > > ReiserFS: sda7: Using r5 hash to sort names > > sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT > > driverbyte=DRIVER_OK,SUGGEST_OK > > end_request: I/O error, dev sdb, sector 19632 > > sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT > > driverbyte=DRIVER_OK,SUGGEST_OK > > end_request: I/O error, dev sdb, sector 40037363 > > Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 > > extents:1 across:1048568k > > lp0: using parport0 (interrupt-driven). > > > > These errors occur *only* with 2.6.24-rc3-mm1, they are 100% > > reproducible. > > 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. > > > > Maybe something is broken in pata_via driver ? > > > Could be - > libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch > and > pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch > touch pata_via.c. > >>> None of the above... > >>> > >>> I did a bisection, it spotted git-scsi-misc.patch. > >>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works > >>> fine. > >>> > >>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do > >>> not > >>> requeue requests if REQ_FAILFAST is set" is the real culprit. The > >>> other > >>> commits are touching documentation or drivers I don't use. I'll try > >>> to revert only this one this evening. > I can confirm : reverting commit > 8655a546c83fc43f0a73416bbd126d02de7ad6c0 > does fix the problem. > > >> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an > >> error where > >> I shouldn't. Checking ... > >> > > Ok, found it. We are blocking even special commands (ie requests with > > PREEMPT not set) > > when FAILFAST is set. Which is clearly wrong. The attached patch fixes > > this. > Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O > errors. > >>> I think the problem is the way we treat BLOCKED and QUIESCED (the latter > >>> is the state that the domain validation uses and which we cannot kill > >>> fastfail on). It's definitely wrong to kill fastfail requests when the > >>> state is QUIESCE. > >>> > >>> This patch (which is applied on top of Hannes original) separates the > >>> BLOCK and QUIESCE states correctly ... does this fix the problem? > >> > >> No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems) > > > > OK, could you post dmesgs again, please. I actually tested this with an > > aic79xx card, and for me it does cause Domain Validation to succeed > > again. > > > > Are the patches indeed to fix that problem as well ? > > http://lkml.org/lkml/2007/11/23/5 That dmesg is from an unknown SCSI card exhibiting Domain Validation problems, so it's a reasonable probability, yes ... but you'll need the additional hack I just did to prevent further intermittent failures. 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: [BUG] jiffies counter leaps in 2.6.24-rc3
Stefano Brivio wrote: > It looks like the jiffies counter sometimes jumps back and forth of some > hundreds seconds in 2.6.24-rc3. I observed that this happens when I use > the su(1) command, e.g.: Can you please explain what exactly the problem is here? Are you perhaps referring to the number between square brackets for the su log lines? In that case there is no problem as in that case the number is not jiffies, but the process ID (PID) of the su process... Cheers, FJP - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: I/O error, system hangs
James Bottomley wrote: > On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote: >> Le 24.11.2007 07:42, James Bottomley a écrit : >>> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote: Le 23.11.2007 12:38, Hannes Reinecke a écrit : > Hannes Reinecke wrote: >> Laurent Riffard wrote: >>> Le 21.11.2007 23:41, Andrew Morton a écrit : On Wed, 21 Nov 2007 22:45:22 +0100 Laurent Riffard <[EMAIL PROTECTED]> wrote: > Le 21.11.2007 05:45, Andrew Morton a écrit : >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ > Hello, > > My system hangs shortly after I logged in Gnome desktop. SysRq-W shows > that a bunch of task are blocked in "D" state, they seem to wait for > some I/O completion. I can try to hand-copy some data if requested. > > I found these messages in dmesg: > > ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 > EXT3-fs: mounted filesystem with ordered data mode. > sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > end_request: I/O error, dev sda, sector 16460 > ReiserFS: sda7: found reiserfs format "3.6" with standard journal > ReiserFS: sda7: using ordered data mode > -- > ReiserFS: sda7: Using r5 hash to sort names > sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > end_request: I/O error, dev sdb, sector 19632 > sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > end_request: I/O error, dev sdb, sector 40037363 > Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 > extents:1 across:1048568k > lp0: using parport0 (interrupt-driven). > > These errors occur *only* with 2.6.24-rc3-mm1, they are 100% > reproducible. > 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. > > Maybe something is broken in pata_via driver ? > Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch touch pata_via.c. >>> None of the above... >>> >>> I did a bisection, it spotted git-scsi-misc.patch. >>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works >>> fine. >>> >>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not >>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other >>> commits are touching documentation or drivers I don't use. I'll try >>> to revert only this one this evening. I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 does fix the problem. >> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an >> error where >> I shouldn't. Checking ... >> > Ok, found it. We are blocking even special commands (ie requests with > PREEMPT not set) > when FAILFAST is set. Which is clearly wrong. The attached patch fixes > this. Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors. >>> I think the problem is the way we treat BLOCKED and QUIESCED (the latter >>> is the state that the domain validation uses and which we cannot kill >>> fastfail on). It's definitely wrong to kill fastfail requests when the >>> state is QUIESCE. >>> >>> This patch (which is applied on top of Hannes original) separates the >>> BLOCK and QUIESCE states correctly ... does this fix the problem? >> >> No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems) > > OK, could you post dmesgs again, please. I actually tested this with an > aic79xx card, and for me it does cause Domain Validation to succeed > again. > Are the patches indeed to fix that problem as well ? http://lkml.org/lkml/2007/11/23/5 > James Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Documentation about unaligned memory access
On Sat, 24 Nov 2007 17:22:36 + Luciano Rocha <[EMAIL PROTECTED]> wrote: > Nothing does, even memcpy doesn't check alignment of the source, or > alignment at all in some assembly implementations (only word-copy, > without checking if at word-boundary). An out-of-line implementation can only do that if the architecture allows unaligned loads and stores. Since it has no clue about the types involved, it must assume that both pointers as well as the length may be misaligned. gcc, on the other hand, knows exactly what types are involved, so when it expands its own builtin-memcpy inline it can optimize it based on the required alignment of those types. So when you cast between types with different alignment requirements, you must make sure the result is properly aligned, or you need to use get_unaligned()/put_unaligned() to override gcc's assumptions. Btw, some versions of avr32-gcc (I think it was 4.0.x) assumed packed structs were properly aligned too, with disastrous results. gcc-4.1 handles packed structs correctly as far as I can tell. Håvard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: I/O error, system hangs
Probing intermittent failures in Domain Validation, even with the fixes
applied leads me to the conclusion that there are further problems with
this commit:
commit fc5eb4facedbd6d7117905e775cee1975f894e79
Author: Hannes Reinecke <[EMAIL PROTECTED]>
Date: Tue Nov 6 09:23:40 2007 +0100
[SCSI] Do not requeue requests if REQ_FAILFAST is set
The essence of the problems is that you're causing REQ_FAILFAST to
terminate commands with error on requeuing conditions, some of which are
relatively common on most SCSI devices. While this may be the correct
behaviour for multi-path, it's certainly wrong for the previously
understood meaning of REQ_FAILFAST, which was don't retry on error,
which is why domain validation and other applications use it to control
error handling, but don't expect to get failures for a simple requeue
are now spitting errors.
I honestly can't see that, even for the multi-path case, returning an
error when we're over queue depth is the correct thing to do (it may not
matter to something like a symmetrix, but an array that has a non-zero
cost associated with a path change, like a CPQ HSV or the AVT
controllers, will show fairly large slow downs if you do this). Even if
this is the desired behaviour (and I think that's a policy issue),
DID_NO_CONNECT is almost certainly the wrong error to be sending back.
This patch fixes up domain validation to work again correctly, however,
I really think it's just a bandaid. Do you want to rethink the above
commit?
James
Index: BUILD-2.6/drivers/scsi/scsi_lib.c
===
--- BUILD-2.6.orig/drivers/scsi/scsi_lib.c 2007-11-24 11:25:20.0
-0600
+++ BUILD-2.6/drivers/scsi/scsi_lib.c 2007-11-24 11:26:22.0 -0600
@@ -1552,7 +1552,8 @@ static void scsi_request_fn(struct reque
break;
if (!scsi_dev_queue_ready(q, sdev)) {
- if (req->cmd_flags & REQ_FAILFAST) {
+ if ((req->cmd_flags & REQ_FAILFAST) &&
+ !(req->cmd_flags & REQ_PREEMPT)) {
scsi_kill_request(req, q);
continue;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.24-rc* regression: sensors says "No sensors found"
Stefan Richter wrote: > I just booted 2.6.24-rc3 on two different PCs, one with i945 based MSI > motherboard and i386 kernel and one with i945 based Apple motherboard > and x86-64 kernel. Before that I ran linux 2.6.23. > > On both PCs, "sensors" exits with >> No sensors found! now logged at http://bugzilla.kernel.org/show_bug.cgi?id=9451 -- Stefan Richter -=-=-=== =-== ==--- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Documentation about unaligned memory access
On Sat, 24 Nov 2007 17:22:36 + Luciano Rocha <[EMAIL PROTECTED]> wrote: > On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote: > > It most certainly does not. gcc will assume that an int* has int alignment. > > memcpy() is a builtin, which gcc can translate to pretty much anything. And > > C specifies that a pointer to foo, will point to a real object of type foo, > > so gcc can't be blamed for the unsafe typecasts. I have tested this the > > hard way, so this is not just speculation. > > Yes, on *int and other assumed aligned pointers, gcc uses its internal > version. > > However, my point is that those pointers, unless speaking of packed > structures, can safely be assumed aligned, while char*/void* can't. > I get the sensation we're violently in agreement here, just misunderstanding each other. :) _My_ point was that the documentation should mention that normal, unpacked C objects have alignments that influence the code generated by __builtin_memcpy(). As such, one should always make sure to have either src or dst be char*/void* when alignment cannot be guaranteed. The example in the documentation has this, but it isn't explicit that this is required. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.24-rc* regression: sensors says "No sensors found"
I just booted 2.6.24-rc3 on two different PCs, one with i945 based MSI motherboard and i386 kernel and one with i945 based Apple motherboard and x86-64 kernel. Before that I ran linux 2.6.23. On both PCs, "sensors" exits with > No sensors found! > Make sure you loaded all the kernel drivers you need. > Try sensors-detect to find out which these are. Modules loaded on the i386, among others: coretemp, w83627ehf, hwmon_vid, hwmon Modules loaded on the x86-64, among others: i2c_dev, applesmc, led_class, input_polldev, coretemp, hwmon, eeprom The configuration scripts are the same as I used them under 2.6.23. sensors-detect doesn't come up with anything which I didn't know and had configured already. On both PCs: $ sensors -v sensors version 2.10.4 with libsensors version 2.10.4 -- Stefan Richter -=-=-=== =-== ==--- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] jiffies counter leaps in 2.6.24-rc3
It looks like the jiffies counter sometimes jumps back and forth of some hundreds seconds in 2.6.24-rc3. I observed that this happens when I use the su(1) command, e.g.: Nov 24 06:17:17 morte [190769.065301] wmaster0: STA 00:14:c1:35:8d:eb Average rate: 232 (6730/29) Nov 24 06:17:22 morte su[16826]: Successful su for root by st3 Nov 24 06:17:22 morte su[16826]: + pts/1 st3:root Nov 24 06:17:22 morte su(pam_unix)[16826]: session opened for user root by (uid=1000) Nov 24 06:17:38 morte [715682.606983] b43-phy2 ERROR: PHY transmission error Nov 24 06:18:17 morte [715707.765415] wmaster0: STA 00:14:c1:35:8d:eb Average rate: 194 (970/5) or Nov 23 20:55:40 morte [627074.320296] wmaster0: STA 00:14:c1:35:8d:eb Average rate: 10 (550/55) Nov 23 20:56:01 morte su[5452]: Successful su for root by st3 Nov 23 20:56:01 morte su[5452]: + pts/4 st3:root Nov 23 20:56:01 morte su(pam_unix)[5452]: session opened for user root by (uid=1000) Nov 23 20:56:03 morte su(pam_unix)[5452]: session closed for user root Nov 23 20:56:40 morte [167187.102931] wmaster0: STA 00:14:c1:35:8d:eb Average rate: 10 (40/4) or Nov 23 06:31:00 morte [156536.124549] wmaster0: STA 00:14:c1:35:8d:eb Average rate: 240 (6480/27) Nov 23 06:31:58 morte su[4350]: Successful su for root by st3 Nov 23 06:31:58 morte su[4350]: + pts/0 st3:root Nov 23 06:31:58 morte su(pam_unix)[4350]: session opened for user root by (uid=1000) Nov 23 06:32:09 morte [587438.574530] wmaster0: STA 00:14:c1:35:8d:eb Average rate: 240 (4080/17) (I checked with a clock the timestamp prepended by syslog-ng, and it's correct.) I'm thinking this could be somehow related to the setpriority() call made by su(1), but I don't know how to debug this further. Any clue? morte st3 # cat /proc/interrupts CPU0 0: 319167512XT-PIC-XTtimer 1: 459332XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 3: 1XT-PIC-XT 4: 1XT-PIC-XT 5: 1XT-PIC-XT 7: 9XT-PIC-XT 8: 2XT-PIC-XTrtc 9: 9114XT-PIC-XTacpi 10: 46272099XT-PIC-XTuhci_hcd:usb1, [EMAIL PROTECTED]::00:02.0 11: 23691749XT-PIC-XTyenta, Intel 82801DB-ICH4, uhci_hcd:usb2, uhci_hcd:usb3, ehci_hcd:usb4, Intel 82801DB-ICH4 Modem, ohci1394, b43 12:3287633XT-PIC-XTi8042 14:1076167XT-PIC-XTide0 15: 47XT-PIC-XTide1 NMI: 0 Non-maskable interrupts LOC: 0 Local timer interrupts TRM: 0 Thermal event interrupts SPU: 0 Spurious interrupts ERR: 8 MIS: 0 morte st3 # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.50GHz stepping: 6 cpu MHz : 1500.000 cache size : 2048 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 mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe bts est tm2 bogomips: 2993.47 clflush size: 64 -- Ciao Stefano - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] wait_task_zombie: remove ->exit_state/exit_signal checks for WNOWAIT
The first "p->exit_state != EXIT_ZOMBIE" check doesn't make too much sense. The
exit_state was EXIT_ZOMBIE when the function was called, and another thread can
change it to EXIT_DEAD right after the check.
The second condition is not possible, detached non-traced threads were already
filtered out by eligible_child(), we didn't drop tasklist since then.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- PT/kernel/exit.c~8_wtz_dead_code2007-11-24 19:28:11.0 +0300
+++ PT/kernel/exit.c2007-11-24 20:02:27.0 +0300
@@ -1193,10 +1193,6 @@ static int wait_task_zombie(struct task_
int exit_code = p->exit_code;
int why, status;
- if (unlikely(p->exit_state != EXIT_ZOMBIE))
- return 0;
- if (unlikely(p->exit_signal == -1 && p->ptrace == 0))
- return 0;
get_task_struct(p);
read_unlock(_lock);
if ((exit_code & 0x7f) == 0) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Documentation about unaligned memory access
On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
> On Sat, 24 Nov 2007 15:50:52 +
> Luciano Rocha <[EMAIL PROTECTED]> wrote:
>
> >
> > Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems
> > in any case. Intelligent ones, like the one provided in glibc, first copy
> > bytes till output is aligned (C file) *or* size is a multiple (i686 asm
> > file)
> > of word size, and then it copies word-by-word.
> >
> > Linux's x86_64 memcpy does the opposite, copies 64bit words, and then
> > copies the last bytes.
> >
> > So, in effect, as long as no packed structures are used, memcpy should
> > be safer on *int, etc., than *char, as the compiler ensures
> > word-alignment.
> >
>
> It most certainly does not. gcc will assume that an int* has int alignment.
> memcpy() is a builtin, which gcc can translate to pretty much anything. And C
> specifies that a pointer to foo, will point to a real object of type foo, so
> gcc can't be blamed for the unsafe typecasts. I have tested this the hard
> way, so this is not just speculation.
Yes, on *int and other assumed aligned pointers, gcc uses its internal
version.
However, my point is that those pointers, unless speaking of packed
structures, can safely be assumed aligned, while char*/void* can't.
> In other words, memcpy() does _not_ save you from alignment issues. If you
> cast from char* or void* to something else, you better be damn sure the
> alignment is correct because gcc will assume it is.
Nothing does, even memcpy doesn't check alignment of the source, or
alignment at all in some assembly implementations (only word-copy,
without checking if at word-boundary).
--
lfr
0/0
pgpSqyJvQFOo9.pgp
Description: PGP signature
fs/cifs/cifsacl.c: check-after-use
The Coverity checker spotted the following check-after-use in
fs/cifs/cifsacl.c:
<-- snip -->
...
static void parse_dacl(struct cifs_acl *pdacl, char *end_of_acl,
struct cifs_sid *pownersid, struct cifs_sid *pgrpsid,
struct inode *inode)
{
...
if (end_of_acl < (char *)pdacl + le16_to_cpu(pdacl->size)) {
... ^^^
if (!pdacl) {
...
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 4/4] Atmel MCI: Driver for Atmel on-chip MMC controllers
On Fri, 23 Nov 2007 13:20:13 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> This is a driver for the MMC controller on the AP7000 chips from
> Atmel. It should in theory work on AT91 systems too with some
> tweaking, but since the DMA interface is quite different, it's not
> entirely clear if it's worth it.
>
> This driver has been around for a while in BSPs and kernel sources
> provided by Atmel, but this particular version uses the generic DMA
> Engine framework (with the slave extensions) instead of an
> avr32-only DMA controller framework.
>
> Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
Why didn't I get a cc? Don't you love me any more? :'(
> ---
> arch/avr32/boards/atngw100/setup.c |6 +
> arch/avr32/boards/atstk1000/atstk1002.c |3 +
> arch/avr32/mach-at32ap/at32ap7000.c | 31 +-
> drivers/mmc/host/Kconfig| 10 +
> drivers/mmc/host/Makefile |1 +
> drivers/mmc/host/atmel-mci.c| 1170
> +++
> drivers/mmc/host/atmel-mci.h| 192 +
> include/asm-avr32/arch-at32ap/board.h | 10 +-
> 8 files changed, 1417 insertions(+), 6 deletions(-)
> create mode 100644 drivers/mmc/host/atmel-mci.c
> create mode 100644 drivers/mmc/host/atmel-mci.h
>
Could you add a note to MAINTAINERS as well?
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 5fef678..687cf8b 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -91,6 +91,16 @@ config MMC_AT91
>
> If unsure, say N.
>
> +config MMC_ATMELMCI
> + tristate "Atmel Multimedia Card Interface support"
> + depends on AVR32 && DMA_ENGINE
> + help
> + This selects the Atmel Multimedia Card Interface. If you have
> + a AT91 (ARM) or AT32 (AVR32) platform with a Multimedia Card
> + slot, say Y or M here.
> +
> + If unsure, say N.
> +
> config MMC_IMX
> tristate "Motorola i.MX Multimedia Card Interface support"
> depends on ARCH_IMX
Now this gets a bit confusing as we'll have two drivers for AT91. Any status
report on merging these?
I can accept having two drivers (for a while at least), but the Kconfig help
texts should explain the sordid details.
> +
> +/* Those printks take an awful lot of time... */
> +#ifndef DEBUG
> +static unsigned int fmax = 1500U;
> +#else
> +static unsigned int fmax = 100U;
> +#endif
> +module_param(fmax, uint, 0444);
> +MODULE_PARM_DESC(fmax, "Max frequency in Hz of the MMC bus clock");
> +
Why is this needed and is it perhaps something that can be moved to the MMC
core?
> +
> +static int req_dbg_open(struct inode *inode, struct file *file)
> +{
This also looks like something that can be made general.
> +
> + if (mmc->ios.bus_mode == MMC_BUSMODE_OPENDRAIN)
> + cmdr |= MCI_BIT(OPDCMD);
> +
> + dev_dbg(>class_dev,
> + "cmd: op %02x arg %08x flags %08x, cmdflags %08lx\n",
> + cmd->opcode, cmd->arg, cmd->flags, (unsigned long)cmdr);
> +
The debug output in the core should make this redundant.
> +
> +static void atmci_request(struct mmc_host *mmc, struct mmc_request *mrq)
> +{
I seem to recall that atmci couldn't currently handle transfers that weren't a
multiple of four. Could you please add a check for this and fail the request
with -EINVAL when that happens?
> +
> +static void atmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> +{
> + struct atmel_mci*host = mmc_priv(mmc);
> + u32 mr;
> +
> + if (ios->clock) {
> + u32 clkdiv;
> +
> + /* Set clock rate */
> + clkdiv = host->bus_hz / (2 * ios->clock) - 1;
> + if (clkdiv > 255) {
> + dev_warn(>class_dev,
> + "clock %u too slow; using %lu\n",
> + ios->clock, host->bus_hz / (2 * 256));
> + clkdiv = 255;
> + }
> +
> + mr = mci_readl(host, MR);
> + mr = MCI_BFINS(CLKDIV, clkdiv, mr)
> + | MCI_BIT(WRPROOF) | MCI_BIT(RDPROOF);
> + mci_writel(host, MR, mr);
> +
> + /* Enable the MCI controller */
> + mci_writel(host, CR, MCI_BIT(MCIEN));
> + } else {
> + /* Disable the MCI controller */
> + mci_writel(host, CR, MCI_BIT(MCIDIS));
> + }
> +
I hope "disable" here doesn't power down the card, as that would be incorrect.
> +
> + if (status & MCI_BIT(DCRCE)) {
> + dev_dbg(>class_dev, "data CRC error\n");
> + data->error = -EILSEQ;
> + } else if (status & MCI_BIT(DTOE)) {
> + dev_dbg(>class_dev, "data timeout error\n");
> + data->error = -ETIMEDOUT;
> + } else {
> + dev_dbg(>class_dev, "data FIFO error\n");
> + data->error = -EIO;
> +
[PATCH] wait_task_continued/zombie: don't use task_pid_nr_ns() lockless
Surprise, other 2 wait_task_() functions also abuse task_pid_nr_ns(). May cause
read-after-free or report nr == 0 in wait_task_continued(). wait_task_zombie()
doesn't have this problem, but still it is better to cache pid_t rather than
call task_pid_nr_ns() 3 times on the saved pid_namespace.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- PT/kernel/exit.c~PID2007-11-24 18:17:20.0 +0300
+++ PT/kernel/exit.c2007-11-24 19:28:11.0 +0300
@@ -1186,12 +1186,9 @@ static int wait_task_zombie(struct task_
{
unsigned long state;
int retval, status, traced;
- struct pid_namespace *ns;
-
- ns = current->nsproxy->pid_ns;
+ pid_t pid = task_pid_nr_ns(p, current->nsproxy->pid_ns);
if (unlikely(noreap)) {
- pid_t pid = task_pid_nr_ns(p, ns);
uid_t uid = p->uid;
int exit_code = p->exit_code;
int why, status;
@@ -1310,11 +1307,11 @@ static int wait_task_zombie(struct task_
retval = put_user(status, >si_status);
}
if (!retval && infop)
- retval = put_user(task_pid_nr_ns(p, ns), >si_pid);
+ retval = put_user(pid, >si_pid);
if (!retval && infop)
retval = put_user(p->uid, >si_uid);
if (!retval)
- retval = task_pid_nr_ns(p, ns);
+ retval = pid;
if (traced) {
write_lock_irq(_lock);
@@ -1433,7 +1430,6 @@ static int wait_task_continued(struct ta
int retval;
pid_t pid;
uid_t uid;
- struct pid_namespace *ns;
if (!(p->signal->flags & SIGNAL_STOP_CONTINUED))
return 0;
@@ -1448,8 +1444,7 @@ static int wait_task_continued(struct ta
p->signal->flags &= ~SIGNAL_STOP_CONTINUED;
spin_unlock_irq(>sighand->siglock);
- ns = current->nsproxy->pid_ns;
- pid = task_pid_nr_ns(p, ns);
+ pid = task_pid_nr_ns(p, current->nsproxy->pid_ns);
uid = p->uid;
get_task_struct(p);
read_unlock(_lock);
@@ -1460,7 +1455,7 @@ static int wait_task_continued(struct ta
if (!retval && stat_addr)
retval = put_user(0x, stat_addr);
if (!retval)
- retval = task_pid_nr_ns(p, ns);
+ retval = pid;
} else {
retval = wait_noreap_copyout(p, pid, uid,
CLD_CONTINUED, SIGCONT,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Documentation about unaligned memory access
On Sat, 24 Nov 2007 15:50:52 +
Luciano Rocha <[EMAIL PROTECTED]> wrote:
>
> Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems
> in any case. Intelligent ones, like the one provided in glibc, first copy
> bytes till output is aligned (C file) *or* size is a multiple (i686 asm file)
> of word size, and then it copies word-by-word.
>
> Linux's x86_64 memcpy does the opposite, copies 64bit words, and then
> copies the last bytes.
>
> So, in effect, as long as no packed structures are used, memcpy should
> be safer on *int, etc., than *char, as the compiler ensures
> word-alignment.
>
It most certainly does not. gcc will assume that an int* has int alignment.
memcpy() is a builtin, which gcc can translate to pretty much anything. And C
specifies that a pointer to foo, will point to a real object of type foo, so
gcc can't be blamed for the unsafe typecasts. I have tested this the hard way,
so this is not just speculation.
E.g., we have the following struct:
struct foo
{
u8 a[4];
u32 b;
};
This struct will have a size of 8 bytes and an alignment of 4 bytes (caused by
the member b). Now take the following code:
void copy_foo(struct foo *dst, struct foo *src)
{
*dst = *src;
}
On a platform that supports 64-bit loads and stores (e.g. AVR32, where I got
hit by this), this will generate:
LD r1, (src)
ST r1, (dst)
Now if I replace that with:
void copy_foo(struct foo *dst, struct foo *src)
{
memcpy(dst, src, sizeof(struct foo));
}
then it will generate the same code. So I cannot use copy_foo() to transfer a
struct foo either out of, or into a packet buffer.
In other words, memcpy() does _not_ save you from alignment issues. If you cast
from char* or void* to something else, you better be damn sure the alignment is
correct because gcc will assume it is.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 4/5] Allow setting O_NONBLOCK flag for new sockets
On Nov 24, 2007 12:28 AM, Eric Dumazet <[EMAIL PROTECTED]> wrote: > OK, but maybe for consistency, we might accept the two mechanisms. It's not a question of the kernel interface. The issue with all these extensions is the userlevel interface. Ideally no new userlevel interface is needed. This is the case for open() and incidentally also for this case (through the flags parameter for recvmsg). For socket(), accept(), the situation is unfortunately different and we need a new interface. With your proposed patch, we would have to introduce another recvmsg() interface to take advantage of the additional functionality. This just doesn't make any sense. This is no contest in aesthetics. You first have to think about the interface presented to the programmer at userlevel and then design the syscall interface. This is how MSG_CMSG_CLOEXEC came about. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Documentation about unaligned memory access
On Sat, Nov 24, 2007 at 02:34:41PM +0100, Pierre Ossman wrote:
> On Fri, 23 Nov 2007 00:15:53 + (GMT)
> Daniel Drake <[EMAIL PROTECTED]> wrote:
>
> > Being spoilt by the luxuries of i386/x86_64 I've never really had a good
> > grasp on unaligned memory access problems on other architectures and decided
> > it was time to figure it out. As a result I've written this documentation
> > which I plan to submit for inclusion as
> > Documentation/unaligned_memory_access.txt
> >
> > Before I do so, any comments on the following?
> >
>
> A very nice, and much needed document. I think you should include one thing
> though:
>
> memcpy() is _only_ safe when one of the pointers is char* or void*. If it is
> anything more complex than that, gcc will assume alignment and optimise based
> on that. E.g. memcpy() of two long:s generates the same assembly as doing an
> assignment.
Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems
in any case. Intelligent ones, like the one provided in glibc, first copy
bytes till output is aligned (C file) *or* size is a multiple (i686 asm file)
of word size, and then it copies word-by-word.
Linux's x86_64 memcpy does the opposite, copies 64bit words, and then
copies the last bytes.
So, in effect, as long as no packed structures are used, memcpy should
be safer on *int, etc., than *char, as the compiler ensures
word-alignment.
--
lfr
0/0
pgpQa3znDcMST.pgp
Description: PGP signature
Re: [PATCH] sdio_uart: fix sign of paramter status in sdio_uart_receive_chars()
On Sat, 24 Nov 2007, Pierre Ossman wrote: > On Wed, 21 Nov 2007 12:33:45 +0100 > Andre Haupt <[EMAIL PROTECTED]> wrote: > > > I think, the status paramter should be unsigned. Is this correct? > > This also fixes a sparse warning about different signedness. > > Only compile tested, because i do not have the hardware. > > > > From: Andre Haupt <[EMAIL PROTECTED]> > > Signed-off-by: Andre Haupt <[EMAIL PROTECTED]> > > Nicolas, does this seem correct to you? I'm not familiar with the > serial stuff. Yes, that should be fine. Acked-by: Nicolas Pitre <[EMAIL PROTECTED]> Nicolas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH -mm] do_wait: fix security checks
Imho, the current usage of security_task_wait() is not logical.
Suppose we have the single child p, and security_task_wait(p) return -EANY.
In that case waitpid(-1) returns this error. Why? Isn't it better to return
ECHLD? We don't really have the reapable childs.
Now suppose that child was stealed by gdb. In that case we find this child
on ->ptrace_children and set flag = 1, but we don't check that the child was
denied. So, do_wait(..., WNOHANG) returns 0, this doesn't match the behaviour
above. Without WNOHANG do_wait() blocks only to return the error later, when
the child will be untraced. Inho, really strange.
I think eligible_child() should return the error only if the child's pid was
requested explicitly, otherwise we should silently ignore the tasks which were
nacked by security_task_wait().
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- PT/kernel/exit.c~7_security_task_wait 2007-11-23 21:29:44.0
+0300
+++ PT/kernel/exit.c2007-11-24 18:17:20.0 +0300
@@ -1139,10 +1139,14 @@ static int eligible_child(pid_t pid, int
return 0;
err = security_task_wait(p);
- if (err)
- return err;
+ if (likely(!err))
+ return 1;
- return 1;
+ if (pid <= 0)
+ return 0;
+ /* This child was explicitly requested, abort */
+ read_unlock(_lock);
+ return err;
}
static int wait_noreap_copyout(struct task_struct *p, pid_t pid, uid_t uid,
@@ -1473,7 +1477,6 @@ static long do_wait(pid_t pid, int optio
DECLARE_WAITQUEUE(wait, current);
struct task_struct *tsk;
int flag, retval;
- int allowed, denied;
add_wait_queue(>signal->wait_chldexit,);
repeat:
@@ -1481,8 +1484,7 @@ repeat:
* We will set this flag if we see any child that might later
* match our criteria, even if we are not able to reap it yet.
*/
- flag = 0;
- allowed = denied = 0;
+ flag = retval = 0;
current->state = TASK_INTERRUPTIBLE;
read_lock(_lock);
tsk = current;
@@ -1495,13 +1497,8 @@ repeat:
continue;
if (unlikely(ret < 0)) {
- denied = ret;
- continue;
- }
- allowed = 1;
-
- retval = 0;
- if (is_task_stopped_or_traced(p)) {
+ retval = ret;
+ } else if (is_task_stopped_or_traced(p)) {
/*
* It's stopped now, so it might later
* continue, exit, or stop again.
@@ -1539,24 +1536,25 @@ repeat:
if (retval != 0) /* tasklist_lock released */
goto end;
}
- if (!flag) {
- list_for_each_entry(p, >ptrace_children,
- ptrace_list) {
- if (!eligible_child(pid, options, p))
- continue;
- flag = 1;
+ if (flag)
+ continue;
+ list_for_each_entry(p, >ptrace_children, ptrace_list) {
+ flag = eligible_child(pid, options, p);
+ if (!flag)
+ continue;
+ if (likely(flag > 0))
break;
- }
+ retval = flag;
+ goto end;
}
if (options & __WNOTHREAD)
break;
tsk = next_thread(tsk);
BUG_ON(tsk->signal != current->signal);
} while (tsk != current);
-
read_unlock(_lock);
+
if (flag) {
- retval = 0;
if (options & WNOHANG)
goto end;
retval = -ERESTARTSYS;
@@ -1566,8 +1564,6 @@ repeat:
goto repeat;
}
retval = -ECHILD;
- if (unlikely(denied) && !allowed)
- retval = denied;
end:
current->state = TASK_RUNNING;
remove_wait_queue(>signal->wait_chldexit,);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: HELP: Internal error: Oops: f5 [#1]
wuhm schrieb: Unable to handle kernel paging request at virtual address c3c0 pgd = c3a5c000 [c3c0] *pgd= Internal error: Oops: f5 [#1] Modules linked in: dm642 mv_sata ixp400_eth ixp400 dm642 is an out-of-tree module. Contact the author of that module. CPU: 0 PC is at .c2u_0cpynopld+0x8/0x24 LR is at mpeg_read+0x19c/0x35c [dm642] pc : []lr : []Tainted: P Your Kernel is tainted. The proprietary module seems to crash. You won't get help from us regarding this module. Please read: http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html Regards, -- Clemens Koller ___ R Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] sdio_uart: fix sign of paramter status in sdio_uart_receive_chars()
On Wed, 21 Nov 2007 12:33:45 +0100 Andre Haupt <[EMAIL PROTECTED]> wrote: > I think, the status paramter should be unsigned. Is this correct? > This also fixes a sparse warning about different signedness. > Only compile tested, because i do not have the hardware. > > From: Andre Haupt <[EMAIL PROTECTED]> > Signed-off-by: Andre Haupt <[EMAIL PROTECTED]> Nicolas, does this seem correct to you? I'm not familiar with the serial stuff. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc3-mm1 make headers_check fails
On Wed, Nov 21, 2007 at 10:58:21AM +0100, Sam Ravnborg wrote: > On Wed, Nov 21, 2007 at 10:44:40AM +0200, Avi Kivity wrote: > > Kamalesh Babulal wrote: > > >Andrew Morton wrote: > > > > > >>On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal > > >><[EMAIL PROTECTED]> wrote: > > >> > > >> > > >>>The make headers_check fails, > > >>> > > >>> CHECK include/linux/usb/gadgetfs.h > > >>> CHECK include/linux/usb/ch9.h > > >>> CHECK include/linux/usb/cdc.h > > >>> CHECK include/linux/usb/audio.h > > >>> CHECK include/linux/kvm.h > > >>>/root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires > > >>>asm/kvm.h, which does not exist in exported headers > > >>> > > >>hm, works for me, on i386 and x86_64. What's different over there? > > >> > > >Hi Andrew, > > > > > >It fails on the powerpc box, with allyesconfig option. > > > > > > > > > > How do we fix this? Export linux/kvm.h only on x86? Seems ugly. > > Is kvm x86 specific? Then move the .h file to asm-x86. > Otherwise no good idea... What about adding a whitelist in hdrcheck.sh? For all practical purposes in userspace the compile error due to the non-existing asm header should be fine, so there's no reason to change the code in such cases. > Sam 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/
