Re: [BUG 2.6.23-rc6-mm1] NMI Watchdog detected LOCKUP on CPU 0
On Sat, Sep 22, 2007 at 10:35:45PM -0700, Andrew Morton wrote: > On Sun, 23 Sep 2007 13:30:40 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote: > > > > That's interensting. serial_in(). We have had NMI watchdog expiries when > > > the kernel is printing a large amount of stuff out a slow serial port with > > > interrutps disabled. But I thought we'd pretty much plugged those > > > problems > > > by sprinkling touch_nmi_watchdog() in various places. > > > > > > Do you think this is what was happening on your system? > > > > Very likely. I'm running linux with cmdline > > "root=/dev/sda1 ro nmi_watchdog=1 console=ttyS0,115200 console=tty0", > > and doing a lot of printks at the time ;-) > > OK. We need to find a suitable place to poke yet another > touch_nmi_watchdog(). Maybe we should give up and put one in > printk(). > > And you oopsed for different reasons in the nmi-watchdog handling > code too. I think I'll pretend I didn't see that. Let's forget it for now. I can try Ingo's latency tracing patches at some convenient 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: [00/41] Large Blocksize Support V7 (adds memmap support)
[EMAIL PROTECTED] (Mel Gorman) writes: > On (16/09/07 23:31), Andrea Arcangeli didst pronounce: >> On Sun, Sep 16, 2007 at 09:54:18PM +0100, Mel Gorman wrote: >> Allocating ptes from slab is fairly simple but I think it would be >> better to allocate ptes in PAGE_SIZE (64k) chunks and preallocate the >> nearby ptes in the per-task local pagetable tree, to reduce the number >> of locks taken and not to enter the slab at all for that. > > It runs the risk of pinning up to 60K of data per task that is unusable for > any other purpose. On average, it'll be more like 32K but worth keeping > in mind. Two things to both of you respectively. Why should we try to stay out of the pte slab? Isn't the slab exactly made for this thing? To efficiently handle a large number of equal size objects for quick allocation and dealocation? If it is a locking problem then there should be a per cpu cache of ptes. Say 0-32 ptes. If you run out you allocate 16 from slab. When you overflow you free 16 (which would give you your 64k allocations but in multiple objects). As for the wastage. Every pte can map 2MB on amd64, 4MB on i386, 8MB on sparc (?). A 64k pte chunk would be 32MB, 64MB and 32MB (?) respectively. For the sbrk() and mmap() usage from glibc malloc() that would be fine as they grow linear and the mmap() call in glibc could be made to align to those chunks. But for a programm like rtorrent using mmap to bring in chunks of a 4GB file this looks desasterous. >> Infact we >> could allocate the 4 levels (or anyway more than one level) in one >> single alloc_pages(0) and track the leftovers in the mm (or similar). Personally I would really go with a per cpu cache. When mapping a page reserve 4 tables. Then you walk the tree and add entries as needed. And last you release 0-4 unused entries to the cache. MfG Goswin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc6-mm1] NMI Watchdog detected LOCKUP on CPU 0
On Sun, 23 Sep 2007 13:30:40 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote: > > That's interensting. serial_in(). We have had NMI watchdog expiries when > > the kernel is printing a large amount of stuff out a slow serial port with > > interrutps disabled. But I thought we'd pretty much plugged those problems > > by sprinkling touch_nmi_watchdog() in various places. > > > > Do you think this is what was happening on your system? > > Very likely. I'm running linux with cmdline > "root=/dev/sda1 ro nmi_watchdog=1 console=ttyS0,115200 console=tty0", > and doing a lot of printks at the time ;-) OK. We need to find a suitable place to poke yet another touch_nmi_watchdog(). Maybe we should give up and put one in printk(). And you oopsed for different reasons in the nmi-watchdog handling code too. I think I'll pretend I didn't see that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc6-mm1] NMI Watchdog detected LOCKUP on CPU 0
On Sat, Sep 22, 2007 at 09:22:36PM -0700, Andrew Morton wrote: > On Sun, 23 Sep 2007 09:42:14 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote: > > > On Tue, Sep 18, 2007 at 01:18:41AM -0700, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/ > > > > > > 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6. > > > > > > This bug appears in 2.6.23-rc3-mm1, too. > > hm, there isn't much info here. > > > The message: > > > > [ 3267.844826] NMI Watchdog detected LOCKUP on CPU 0 > > [ 3267.849515] CPU 0 > > [ 3267.851525] Modules linked in: binfmt_misc ipt_MASQUERADE iptable_mangle > > iptable_nat nf_conntrack_ipv4 iptable_filter ip_tables x_tables nf_nat_tftp > > nf_nat_ftp nf_nat nf_conntrack_tftp nf_conntrack_ftp nf_conntrack nfnetlink > > fan ac battery ipv6 eeprom lm85 hwmon_vid i2c_core tun fuse kvm > > snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd sg soundcore > > snd_page_alloc thermal sr_mod pcspkr evdev button processor cdrom > > [ 3267.889547] Pid: 13507, comm: gcc Not tainted 2.6.23-rc6-mm1 #4 > > [ 3267.895442] RIP: 0033:[<2ab84e34cd44>] [<2ab84e34cd44>] > > [ 3267.901438] RSP: 002b:7fff5c9e03f8 EFLAGS: 0287 > > [ 3267.906726] RAX: RBX: 7fff5c9e0580 RCX: > > > > [ 3267.913833] RDX: 0013 RSI: 7fff5c9e0680 RDI: > > 012a7010 > > [ 3267.920939] RBP: 7fff5c9e0550 R08: 0050 R09: > > > > [ 3267.928045] R10: R11: 012a7410 R12: > > 0002 > > [ 3267.935151] R13: 0003 R14: 0005 R15: > > 001f > > [ 3267.942258] FS: 2ab84f144170() GS:814f3000() > > knlGS: > > [ 3267.950317] CS: 0010 DS: ES: CR0: 80050033 > > [ 3267.956038] CR2: 2ab84e3a7430 CR3: 0d618000 CR4: > > 06e0 > > [ 3267.963144] DR0: DR1: DR2: > > > > [ 3267.970250] DR3: DR6: 0ff0 DR7: > > 0400 > > [ 3267.977357] Process gcc (pid: 13507, threadinfo 81000ebe6000, task > > 810008b849d0) > > [ 3267.985416] > > [ 3267.997480] Unable to handle kernel paging request at fffe > > RIP: > > [ 3268.002082] [] > > [ 3268.007827] PGD ea85067 PUD 0 > > Looks like it oopsed in the middle of handling an NMI watchdog expiry, > perhaps. > > > [ 3268.010887] Oops: 0010 [1] SMP > > [ 3268.014035] last sysfs file: > > /devices/pci:00/:00:1e.0/:05:04.0/resource > > [ 3268.021662] CPU 0 > > [ 3268.023674] Modules linked in: binfmt_misc ipt_MASQUERADE iptable_mangle > > iptable_nat nf_conntrack_ipv4 iptable_filter ip_tables x_tables nf_nat_tftp > > nf_nat_ftp nf_nat nf_conntrack_tftp nf_conntrack_ftp nf_conntrack nfnetlink > > fan ac battery ipv6 eeprom lm85 hwmon_vid i2c_core tun fuse kvm > > snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd sg soundcore > > snd_page_alloc thermal sr_mod pcspkr evdev button processor cdrom > > [ 3268.061688] Pid: 13507, comm: gcc Not tainted 2.6.23-rc6-mm1 #4 > > [ 3268.067584] RIP: 0010:[ ] [ ] > > [ 3268.073578] RSP: :8157ce38 EFLAGS: 00010296 > > [ 3268.078867] RAX: 2710 RBX: 810009787050 RCX: > > 8100036788e0 > > [ 3268.085973] RDX: 018d RSI: 810ba000 RDI: > > 810009787080 > > [ 3268.093080] RBP: R08: R09: > > > > [ 3268.100185] R10: R11: 0001 R12: > > 810008b849d0 > > [ 3268.107293] R13: 810008b850d0 R14: 0001 R15: > > 8157cf58 > > [ 3268.114399] FS: 2ab84f144170() GS:814f3000() > > knlGS: > > [ 3268.122455] CS: 0010 DS: ES: CR0: 8005003b > > [ 3268.128178] CR2: fffe CR3: 06bfd000 CR4: > > 06e0 > > [ 3268.135283] DR0: DR1: DR2: > > > > [ 3268.142388] DR3: DR6: 0ff0 DR7: > > 0400 > > [ 3268.149495] Process gcc (pid: 13507, threadinfo 81000ebe6000, task > > 810008b849d0) > > [ 3268.157552] last branch before last exception/interrupt > > [ 3268.162753] from [] serial_in+0x23/0x80 > > [ 3268.168316] to [] serial_in+0x12/0x80 > > That's interensting. serial_in(). We have had NMI watchdog expiries when > the kernel is printing a large amount of stuff out a slow serial port with > interrutps disabled. But I thought we'd pretty much plugged those problems > by sprinkling touch_nmi_watchdog() in various places. > > Do you think this is what was happening on your system? Very likely. I'm running linux with cmdline "root=/dev/sda1 ro nmi_watchdog=1 console=ttyS0,115200 console=tty0", and doing a lot of printks at the time
Re: [patch 0/2] suspend/resume regression fixes
On Sunday 23 September 2007, Linus Torvalds wrote: > From a "future behaviour" standpoint it would probably be interesting to > hear whether Mihai can make his machine with not with the old IDE layer > (which distributions are migrating away from) but with the ATA layer > (libata) instead. It too should hopefully know about using ACPI to restore > any ATA controller quirks. I switched to libata, but it behaves like the old IDE without ACPI. I did not manage to get a full dmesg (apparently all volumes are mounted r/o right after a power up from a s2ram) but I did make a picture, from which I quote (if I may say so): " ata1.00: configured for PIO0 sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08 sd 0:0:0:0: [sda] Sense key : 0xb [current] [descriptor] Descriptor sense data with sense descriptors (in hex): 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 07 65 35 25 sd 0:0:0:0: [sda] ASC=0x0 ASCQ=0x0 end_request: I/O error, dev sda, sector 124073509 ata1: EH complete sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata1.00: cmd c5/00:10:75:36:65/00:00:00:00:00/e7 tag 0 cdb 0x0 data 8192 out res 51/04:10:75:36:65/00:00:00:00:00/e7 Emask 0x1 (device error) ata1.00: configured for PIO0 ata1: EH complete " The last six lines repeat six times after which the whole things goes from the beginning: " ata1.00: configured for PIO0 ... " It all gets crazy the moment I (or a process) try to access the root (or any other drive), until then, everything is nice and quiet. Mmm... in the excerpt above it says: "Write Protect is off" but when I did $ mount -o remount,rw / I got something like: "the device is write protected". I tried to save the dmesg on a mmc, but after powering up it said: "out of disk space" These are about all symptoms that I noticed... oh, and 'scsi_eh_0/1' enters disk-sleep often. I attached the dmesg pre s2ram. Thanks, -- Mihai Donțu [0.00] Linux version 2.6.23-rc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2)) #10 PREEMPT Sun Sep 23 06:54:24 EEST 2007 [0.00] Command line: nohz=on root=/dev/sda7 [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 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 37fd (usable) [0.00] BIOS-e820: 37fd - 37fefc00 (reserved) [0.00] BIOS-e820: 37fefc00 - 37ffb000 (ACPI NVS) [0.00] BIOS-e820: 37ffb000 - 4000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - fec02000 (reserved) [0.00] BIOS-e820: ffb8 - ffc0 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000FE270, 0014 (r0 HP) [0.00] ACPI: RSDT 37FEFC84, 0034 (r1 HP 0944 22110520 HP 1) [0.00] ACPI: FACP 37FEFC00, 0084 (r2 HP 09442 HP 1) [0.00] ACPI: DSDT 37FEFD50, 7489 (r1 HPSB4001 MSFT 10E) [0.00] ACPI: FACS 37FFAE80, 0040 [0.00] ACPI: APIC 37FEFCB8, 005A (r1 HP 09441 HP 1) [0.00] ACPI: MCFG 37FEFD14, 003C (r1 HP 09441 HP 1) [0.00] ACPI: SSDT 37FF71D9, 0382 (r1 HP HPQPpc 1001 MSFT 10E) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] No mptable found. [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 229328 [0.00] On node 0 totalpages: 229231 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1911 pages reserved [0.00] DMA zone: 2032 pages, LIFO batch:0 [0.00] DMA32 zone: 3079 pages used for memmap [0.00] DMA32 zone: 222153 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Movable zone: 0 pages used for memmap [0.00] ATI board detected. Disabling timer routing over 8254. [
Re: [kvm-devel] [PATCH -rc][RESEND] KVM: Fix virtualization menu help text
On Sat, 2007-09-22 at 14:43 +0200, Avi Kivity wrote: > What guest drivers? > > Cc: Jan Engelhardt <[EMAIL PROTECTED]> > Signed-off-by: Avi Kivity <[EMAIL PROTECTED]> Yes, agreed. Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc6-mm1] NMI Watchdog detected LOCKUP on CPU 0
On Sun, 23 Sep 2007 09:42:14 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote: > On Tue, Sep 18, 2007 at 01:18:41AM -0700, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/ > > > > 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6. > > > This bug appears in 2.6.23-rc3-mm1, too. hm, there isn't much info here. > The message: > > [ 3267.844826] NMI Watchdog detected LOCKUP on CPU 0 > [ 3267.849515] CPU 0 > [ 3267.851525] Modules linked in: binfmt_misc ipt_MASQUERADE iptable_mangle > iptable_nat nf_conntrack_ipv4 iptable_filter ip_tables x_tables nf_nat_tftp > nf_nat_ftp nf_nat nf_conntrack_tftp nf_conntrack_ftp nf_conntrack nfnetlink > fan ac battery ipv6 eeprom lm85 hwmon_vid i2c_core tun fuse kvm snd_hda_intel > snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd sg soundcore snd_page_alloc > thermal sr_mod pcspkr evdev button processor cdrom > [ 3267.889547] Pid: 13507, comm: gcc Not tainted 2.6.23-rc6-mm1 #4 > [ 3267.895442] RIP: 0033:[<2ab84e34cd44>] [<2ab84e34cd44>] > [ 3267.901438] RSP: 002b:7fff5c9e03f8 EFLAGS: 0287 > [ 3267.906726] RAX: RBX: 7fff5c9e0580 RCX: > > [ 3267.913833] RDX: 0013 RSI: 7fff5c9e0680 RDI: > 012a7010 > [ 3267.920939] RBP: 7fff5c9e0550 R08: 0050 R09: > > [ 3267.928045] R10: R11: 012a7410 R12: > 0002 > [ 3267.935151] R13: 0003 R14: 0005 R15: > 001f > [ 3267.942258] FS: 2ab84f144170() GS:814f3000() > knlGS: > [ 3267.950317] CS: 0010 DS: ES: CR0: 80050033 > [ 3267.956038] CR2: 2ab84e3a7430 CR3: 0d618000 CR4: > 06e0 > [ 3267.963144] DR0: DR1: DR2: > > [ 3267.970250] DR3: DR6: 0ff0 DR7: > 0400 > [ 3267.977357] Process gcc (pid: 13507, threadinfo 81000ebe6000, task > 810008b849d0) > [ 3267.985416] > [ 3267.997480] Unable to handle kernel paging request at fffe > RIP: > [ 3268.002082] [] > [ 3268.007827] PGD ea85067 PUD 0 Looks like it oopsed in the middle of handling an NMI watchdog expiry, perhaps. > [ 3268.010887] Oops: 0010 [1] SMP > [ 3268.014035] last sysfs file: > /devices/pci:00/:00:1e.0/:05:04.0/resource > [ 3268.021662] CPU 0 > [ 3268.023674] Modules linked in: binfmt_misc ipt_MASQUERADE iptable_mangle > iptable_nat nf_conntrack_ipv4 iptable_filter ip_tables x_tables nf_nat_tftp > nf_nat_ftp nf_nat nf_conntrack_tftp nf_conntrack_ftp nf_conntrack nfnetlink > fan ac battery ipv6 eeprom lm85 hwmon_vid i2c_core tun fuse kvm snd_hda_intel > snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd sg soundcore snd_page_alloc > thermal sr_mod pcspkr evdev button processor cdrom > [ 3268.061688] Pid: 13507, comm: gcc Not tainted 2.6.23-rc6-mm1 #4 > [ 3268.067584] RIP: 0010:[ ] [ ] > [ 3268.073578] RSP: :8157ce38 EFLAGS: 00010296 > [ 3268.078867] RAX: 2710 RBX: 810009787050 RCX: > 8100036788e0 > [ 3268.085973] RDX: 018d RSI: 810ba000 RDI: > 810009787080 > [ 3268.093080] RBP: R08: R09: > > [ 3268.100185] R10: R11: 0001 R12: > 810008b849d0 > [ 3268.107293] R13: 810008b850d0 R14: 0001 R15: > 8157cf58 > [ 3268.114399] FS: 2ab84f144170() GS:814f3000() > knlGS: > [ 3268.122455] CS: 0010 DS: ES: CR0: 8005003b > [ 3268.128178] CR2: fffe CR3: 06bfd000 CR4: > 06e0 > [ 3268.135283] DR0: DR1: DR2: > > [ 3268.142388] DR3: DR6: 0ff0 DR7: > 0400 > [ 3268.149495] Process gcc (pid: 13507, threadinfo 81000ebe6000, task > 810008b849d0) > [ 3268.157552] last branch before last exception/interrupt > [ 3268.162753] from [] serial_in+0x23/0x80 > [ 3268.168316] to [] serial_in+0x12/0x80 That's interensting. serial_in(). We have had NMI watchdog expiries when the kernel is printing a large amount of stuff out a slow serial port with interrutps disabled. But I thought we'd pretty much plugged those problems by sprinkling touch_nmi_watchdog() in various places. Do you think this is what was happening on your system? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Broadcom 8603 SAS/SATA driver, rough draft
Rather than sitting on this for far too long, I wanted to go ahead and
get this out there. I heard some chips might be trickling out into
public hands.
This is a bare bones Broadcom 8603 SAS+SATA driver, attempting to use
the vaunted libsas. Notes:
* A quick glance at the FIXMEs will tell you obviously doesn't work.
* The hardware is quite simple and straightforward and easy to program
in an efficient way: each SAS port has a command queue (DMA ring) and
a response queue (DMA ring). Or if in SATA mode, just a command
queue.
* The SAS/SATA negotiation is largely out of our hands. The silicon
does its thing, and then tells us what type of device connected. We
are then expected to switch the port to either SAS mode or SATA mode,
accordingly.
* There is no firmware or anything. Just DMA and register bitbanging.
We have plenty of low-level control.
* The state of SAS/SATA integration is perpetually pathetic. Updates
in this area are likely. There's a rumor Brian King @ IBM may look
into this area too.
* This driver pretty much completely lacks exception handling.
As an aside, I am also writing a driver for Marvell chips that behave
quite similarly to this chip. It seems the future of storage might look
like these Broadcom and Marvell SAS+SATA DMA ring interfaces, in the
volume marketspace at least.
The 'broadsas' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git broadsas
contains the following updates:
drivers/scsi/Kconfig| 10 +
drivers/scsi/Makefile |1 +
drivers/scsi/broadsas.c | 997 +++
3 files changed, 1008 insertions(+), 0 deletions(-)
create mode 100644 drivers/scsi/broadsas.c
Jeff Garzik (1):
Add rough draft Broadcom 8603 SAS/SATA driver.
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 6f2c71e..44fa3a9 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -486,6 +486,16 @@ config SCSI_AIC7XXX_OLD
source "drivers/scsi/aic7xxx/Kconfig.aic79xx"
source "drivers/scsi/aic94xx/Kconfig"
+config SCSI_BROADSAS
+ tristate "Broadcom 8603 SAS/SATA support"
+ depends on PCI
+ select SCSI_SAS_LIBSAS
+ help
+ This driver supports Broadcom SAS/SATA PCI devices.
+
+ To compile this driver as a module, choose M here: the
+ module will be called broadsas.
+
# All the I2O code and drivers do not seem to be 64bit safe.
config SCSI_DPT_I2O
tristate "Adaptec I2O RAID support "
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 86a7ba7..8f052c9 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_SCSI_AIC79XX)+= aic7xxx/
obj-$(CONFIG_SCSI_AACRAID) += aacraid/
obj-$(CONFIG_SCSI_AIC7XXX_OLD) += aic7xxx_old.o
obj-$(CONFIG_SCSI_AIC94XX) += aic94xx/
+obj-$(CONFIG_SCSI_BROADSAS)+= broadsas.o
obj-$(CONFIG_SCSI_IPS) += ips.o
obj-$(CONFIG_SCSI_FD_MCS) += fd_mcs.o
obj-$(CONFIG_SCSI_FUTURE_DOMAIN)+= fdomain.o
diff --git a/drivers/scsi/broadsas.c b/drivers/scsi/broadsas.c
new file mode 100644
index 000..a4276ec
--- /dev/null
+++ b/drivers/scsi/broadsas.c
@@ -0,0 +1,997 @@
+/*
+ * broadsas.c - Broadcom 8603 SAS/SATA support
+ *
+ * Copyright 2007 Red Hat, Inc.
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING. If not, write to
+ * the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "broadsas"
+#define DRV_VERSION "0.1"
+
+struct bs_info;
+struct bs_port;
+
+#define br32(reg) readl(regs + BS_##reg)
+#define bw32(reg,val) writel((val), regs + BS_##reg)
+#define bw32_f(reg,val)do {\
+ writel((val), regs + BS_##reg); \
+ readl(regs + BS_##reg); \
+ } while (0)
+
+/* driver compile-time configuration */
+enum driver_configuration {
+ BS_CMDQ_SZ = 128, /* OK: 2, 4, 8, 16, 32, 64, 128, 256 */
+ BS_RSPQ_SZ = 128, /* OK: 2, 4, 8, 16, 32, 64, 128, 256 */
+ BS_MAX_PRD = 256, /* S/G per slot; my arbitrary guess */
+ BS_RSP_BUF_SZ = 512, /* Response buffer size; OK: 0-64k */
+};
+
+/* unchangeable hardware details */
+enum hardware_details {
+ BS_PORTS= 8,/* number
Re: [RFC] New kernel-message logging API
On Sep 22, 2007, at 20:47:21, Joe Perches wrote:
On Sat, 2007-09-22 at 20:40 -0400, Kyle Moffett wrote:
Severity is *exactly* "desirability of logging".
Disagree.
What's info to someone is an alert to someone else. The problem is
the valuation of the reasoning.
It's all opinion.
For starters, I think "its all opinion" is bogus; the value of each
log level is pretty standardly defined for the kernel:
EMERG: The system is completely failing right NOW. Immediate admin
action is definitely required
ALERT: The system is about to fail or halfway-failing. Immediate
admin action may be required.
ERR: Something went badly wrong. We are able to continue without
endangering the overall system.
NOTICE: Something unusual happened but it's either not a device/code
failure or it's an expected failure.
INFO:Something useful happened, like a device probe or a major
system-wide event
DEBUG: Something happened that only a developer or somebody looking
for bugs would care about.
All of those are basically defined as: "This is how much the admin
probably wants to see this message". If you find a message which
doesn't seem to match the log level it's logged at, please submit a
patch.
Even assuming its not a bogus argument, what you actually want is
*NOT* "Show me INFO and DEBUG, but not EMERG, ALERT, ERR, or NOTICE",
you actually want multiple metrics by which to measure things. We
already have multiple ways of filtering log messages:
1) Log-level (greater than $LEVEL).
2) Userspace textual post-processing filters and classifiers (EG:
logcheck)
3) CONFIG_${SUBSYS}_DEBUG and CONFIG_${DRIVER}_DEBUG
Perhaps what you want is something like the syslog "facility" parameter?
The only real reason to add more kconfig options for logging is to
decrease the size of the kernel binary; most anything else can be
better done in userspace in something like logcheck. If you're going
to add new kconfig options then you aren't going to configure them
generically since they're inherently subsystem/driver specific. In
that case you might add a per-driver "CONFIG_${DRIVER}_NOLOG" for the
drivers you care about or a "CONFIG_MAX_LOG_LEVEL" to globally limit
by severity but any other qualifiers inherently don't fit in a single
scalar
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: linux 2.6.23-rc7 - 14 compile warnings
On Sat, Sep 22, 2007 at 10:23:59PM -0400, Gerhard Mack wrote: >On Sat, 22 Sep 2007, WANG Cong wrote: > >> >Summary: >> > CC mm/slub.o >> >mm/slub.c: In function 'kfree': >> >mm/slub.c:2491: warning: passing argument 3 of 'slab_free' discards >> >qualifiers from pointer target type > >static void __slab_free(struct kmem_cache *s, struct page *page, >void *x, void *addr) >but .. > >void kfree(const void *x) > >void is not the same as const void. > >> > CC fs/autofs4/symlink.o >> >fs/autofs4/symlink.c: In function 'autofs4_follow_link': >> >fs/autofs4/symlink.c:18: warning: passing argument 2 of 'nd_set_link' >> >discards qualifiers from pointer target type > >Once again ino->u.symlink is a const char and it's dropping the const. > slab_free(s, page, (void *)x, __builtin_return_address(0)); ^ I knew these things. But the explicit casts, such as the above one, mean that we are intended to discard to qualifiers and I think gcc shouldn't warn about this. Regards. WANG Cong - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/2] suspend/resume regression fixes
On Sun, 23 Sep 2007, Oleg Verych wrote: > > As i never had any suspend working ever, let me point this LKML post > > http://mid.gmane.org/[EMAIL PROTECTED] > > from Mihal, who just managed to do some other magic in sligtly > different context (maybe yet another anti "ACPI screwed up"). > > Mihai, you can find whole thread by above URL, requesting message-ids > from in-reply-to or references headers of this message. >From a "future behaviour" standpoint it would probably be interesting to hear whether Mihai can make his machine with not with the old IDE layer (which distributions are migrating away from) but with the ATA layer (libata) instead. It too should hopefully know about using ACPI to restore any ATA controller quirks. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm Patch] net/bluetooth/hidp/core.c: Make hidp_setup_input() return int
This patch does the following things:
- Make hidp_setup_input() return int to indicate errors.
- Check its return value to handle errors.
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
---
net/bluetooth/hidp/core.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: linux-2.6.23-rc6-mm1/net/bluetooth/hidp/core.c
===
--- linux-2.6.23-rc6-mm1.orig/net/bluetooth/hidp/core.c
+++ linux-2.6.23-rc6-mm1/net/bluetooth/hidp/core.c
@@ -625,7 +625,7 @@ static struct device *hidp_get_device(st
return conn ? >dev : NULL;
}
-static inline void hidp_setup_input(struct hidp_session *session, struct
hidp_connadd_req *req)
+static inline int hidp_setup_input(struct hidp_session *session, struct
hidp_connadd_req *req)
{
struct input_dev *input = session->input;
int i;
@@ -669,7 +669,7 @@ static inline void hidp_setup_input(stru
input->event = hidp_input_event;
- input_register_device(input);
+ return input_register_device(input);
}
static int hidp_open(struct hid_device *hid)
@@ -823,7 +823,8 @@ int hidp_add_connection(struct hidp_conn
session->idle_to = req->idle_to;
if (session->input)
- hidp_setup_input(session, req);
+ if ((err = (hidp_setup_input(session, req
+ goto failed;
if (session->hid)
hidp_setup_hid(session, req);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.23-rc7 - 14 compile warnings
On Sat, 22 Sep 2007, WANG Cong wrote: > >Summary: > > CC mm/slub.o > >mm/slub.c: In function 'kfree': > >mm/slub.c:2491: warning: passing argument 3 of 'slab_free' discards > >qualifiers from pointer target type static void __slab_free(struct kmem_cache *s, struct page *page, void *x, void *addr) but .. void kfree(const void *x) void is not the same as const void. > > CC fs/autofs4/symlink.o > >fs/autofs4/symlink.c: In function 'autofs4_follow_link': > >fs/autofs4/symlink.c:18: warning: passing argument 2 of 'nd_set_link' > >discards qualifiers from pointer target type Once again ino->u.symlink is a const char and it's dropping the const. > > These two warnings are suspicious. Explicit casts are already there, how > they come out? Or gcc bugs? > gcc is perfectly justified when warning about dropping const. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 Router
i used to add proxy arp's on the router when i had problems like this. Dunno if it's the recommended fix, but it worked. http://en.wikipedia.org/wiki/Proxy_arp Carlos Narváez wrote: This is starting to frustrate me, because it should be much simpler than it seems to be, and I feel like I'm missing something small and obvious. I have two private networks, we'll say 192.168.254.0/24 and 192.168.251.0/24. And I have a linux box in the middle with addresses 192.168.254.17 and 192.168.251.10: +---+ . ++ ¦ 192.168.251.1 +---+ 192.168.251.10 ¦ . ++ +---+ . ¦ 192.168.254.17 +---+ 192.168.254.16 ¦ . . . . . . . . . . ++ . ++ There is no NAT involved.. I just want the box in the middle to pass traffic between the two networks. Here is what I have done: - IP Forwarding has been enabled on the router via "echo 1 > /proc/sys/net/ipv4/ip_forward" - A route has been configured on 192.168.251.1 to point all traffic for 192.168.254.0/24 to 192.168.251.10. - A route has been configured on 192.168.254.16 to point all traffic for 192.168.251.0/24 to 192.168.254.17. - The command "iptables -I FORWARD -j ACCEPT" has been executed. Now.. here's what happens. 192.168.251.10 can ping both interfaces on the router. 192.168.254.16 can also ping both interfaces on the router. However, 192.168.251.1 cannot ping 192.168.254.16, and likewise, 192.168.254.16 cannot ping 192.168.251.1. What have I forgotten? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] use pgd_list_add/pgd_list_del
Cleanup by using pgd_list_add() and pgd_list_del() in the right place.
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
include/asm-x86_64/pgalloc.h | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
Index: 2.6-git/include/asm-x86_64/pgalloc.h
===
--- 2.6-git.orig/include/asm-x86_64/pgalloc.h
+++ 2.6-git/include/asm-x86_64/pgalloc.h
@@ -65,7 +65,6 @@ static inline void pgd_ctor(void *x)
{
unsigned boundary;
pgd_t *pgd = x;
- struct page *page = virt_to_page(pgd);
/*
* Copy kernel pointers in from init.
@@ -75,19 +74,14 @@ static inline void pgd_ctor(void *x)
init_level4_pgt + boundary,
(PTRS_PER_PGD - boundary) * sizeof(pgd_t));
- spin_lock(_lock);
- list_add(>lru, _list);
- spin_unlock(_lock);
+ pgd_list_add(pgd);
}
static inline void pgd_dtor(void *x)
{
pgd_t *pgd = x;
- struct page *page = virt_to_page(pgd);
-spin_lock(_lock);
- list_del(>lru);
- spin_unlock(_lock);
+ pgd_list_del(pgd);
}
static inline pgd_t *pgd_alloc(struct mm_struct *mm)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: Network sky2 Module, kernel version 2.6.23-rc7
i spoke too soon. The Gbit interface still dies. Lasted around 19hrs. or so. i can't tell if there are hardware issues: yesterday a Gbit NIC on the firewall died. Different chip (Realtek), different driver, different machine, same segment. Segment is a mix of 100Mbit and 1Gbit machines. Symptoms of the failure are it just stops functioning with no error messages. ifconfig says there are packets being TX'd and none being RX'd. Interface can't be brought up again. i use this box as the secondary DNS for our Internet domains (unblocked by firewall), as well as the database server for our developmental web CMS and the LAN ntp server (both services invisible outside the LAN). dmesg says this on bootup: ACPI: PCI Interrupt :01:00.0[A] -> GSI 18 (level, low) -> IRQ 16 PCI: Setting latency timer of device :01:00.0 to 64 sky2 :01:00.0: v1.17 addr 0xdfefc000 irq 16 Yukon-EC (0xb6) rev 2 sky2 eth0: addr 00:01:29:d6:35:f4 ACPI: PCI Interrupt :02:00.0[A] -> GSI 19 (level, low) -> IRQ 17 PCI: Setting latency timer of device :02:00.0 to 64 sky2 :02:00.0: v1.17 addr 0xdfcfc000 irq 17 Yukon-EC (0xb6) rev 2 sky2 eth1: addr 00:01:29:d6:36:26 Motherboard manufacturer identifies the chips as: Dual Gigabit LAN - Marvell 88E8052 and Marvell 88E8053 Gigabit PCI LAN board is DFI LANPARTY UT CFX3200-DR/G running an Opteron 165. i've brought up the other Gbit network interface on the motherboard and am using that. ben soo wrote: i turned off the motherboard Marvell Gbit devices and installed a Realtek 8169 card, all the while keeping to kernel version 2.6.23-rc6, and saw all the network problems go away. Must mean it was a sky2 driver bug. Am currently running 2.6.23-rc7 on the affected server and the rc7 sky2 driver is holding up fine so far. thank you! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [35/50] i386: Do cpuid_device_create() in CPU_UP_PREPARE instead of CPU_ONLINE.
2007/9/23, Thomas Gleixner <[EMAIL PROTECTED]>: > On Sat, 2007-09-22 at 00:32 +0200, Andi Kleen wrote: > > From: Akinobu Mita <[EMAIL PROTECTED]> > > > > Do cpuid_device_create() in CPU_UP_PREPARE instead of CPU_ONLINE. > > > > Cc: "H. Peter Anvin" <[EMAIL PROTECTED]> > > Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]> > > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> > > Cc: Gautham R Shenoy <[EMAIL PROTECTED]> > > Cc: Oleg Nesterov <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > --- > > > > arch/i386/kernel/cpuid.c | 32 +++- > > 1 file changed, 19 insertions(+), 13 deletions(-) > > > > Index: linux/arch/i386/kernel/cpuid.c > > === > > --- linux.orig/arch/i386/kernel/cpuid.c > > +++ linux/arch/i386/kernel/cpuid.c > > @@ -136,15 +136,18 @@ static const struct file_operations cpui > > .open = cpuid_open, > > }; > > > > -static int __cpuinit cpuid_device_create(int i) > > +static int cpuid_device_create(int cpu) > > __cpuinit please > Yes. This eliminates earlier patch in this series. ([22/50] i386: Misc cpuinit annotation) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc6-mm1] NMI Watchdog detected LOCKUP on CPU 0
On Sun, Sep 23, 2007 at 09:42:14AM +0800, Fengguang Wu wrote: > On Tue, Sep 18, 2007 at 01:18:41AM -0700, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/ > > > > 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6. > > > This bug appears in 2.6.23-rc3-mm1, too. > > The message: > > [ 3267.844826] NMI Watchdog detected LOCKUP on CPU 0 > [ 3267.849515] CPU 0 > [ 3267.851525] Modules linked in: binfmt_misc ipt_MASQUERADE iptable_mangle > iptable_nat nf_conntrack_ipv4 iptable_filter ip_tables x_tables nf_nat_tftp > nf_nat_ftp nf_nat nf_conntrack_tftp nf_conntrack_ftp nf_conntrack nfnetlink > fan ac battery ipv6 eeprom lm85 hwmon_vid i2c_core tun fuse kvm snd_hda_intel > snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd sg soundcore snd_page_alloc > thermal sr_mod pcspkr evdev button processor cdrom > [ 3267.889547] Pid: 13507, comm: gcc Not tainted 2.6.23-rc6-mm1 #4 > [ 3267.895442] RIP: 0033:[<2ab84e34cd44>] [<2ab84e34cd44>] > [ 3267.901438] RSP: 002b:7fff5c9e03f8 EFLAGS: 0287 > [ 3267.906726] RAX: RBX: 7fff5c9e0580 RCX: > > [ 3267.913833] RDX: 0013 RSI: 7fff5c9e0680 RDI: > 012a7010 > [ 3267.920939] RBP: 7fff5c9e0550 R08: 0050 R09: > > [ 3267.928045] R10: R11: 012a7410 R12: > 0002 > [ 3267.935151] R13: 0003 R14: 0005 R15: > 001f > [ 3267.942258] FS: 2ab84f144170() GS:814f3000() > knlGS: > [ 3267.950317] CS: 0010 DS: ES: CR0: 80050033 > [ 3267.956038] CR2: 2ab84e3a7430 CR3: 0d618000 CR4: > 06e0 > [ 3267.963144] DR0: DR1: DR2: > > [ 3267.970250] DR3: DR6: 0ff0 DR7: > 0400 > [ 3267.977357] Process gcc (pid: 13507, threadinfo 81000ebe6000, task > 810008b849d0) > [ 3267.985416] > [ 3267.997480] Unable to handle kernel paging request at fffe > RIP: > [ 3268.002082] [] > [ 3268.007827] PGD ea85067 PUD 0 > [ 3268.010887] Oops: 0010 [1] SMP > [ 3268.014035] last sysfs file: > /devices/pci:00/:00:1e.0/:05:04.0/resource > [ 3268.021662] CPU 0 > [ 3268.023674] Modules linked in: binfmt_misc ipt_MASQUERADE iptable_mangle > iptable_nat nf_conntrack_ipv4 iptable_filter ip_tables x_tables nf_nat_tftp > nf_nat_ftp nf_nat nf_conntrack_tftp nf_conntrack_ftp nf_conntrack nfnetlink > fan ac battery ipv6 eeprom lm85 hwmon_vid i2c_core tun fuse kvm snd_hda_intel > snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd sg soundcore snd_page_alloc > thermal sr_mod pcspkr evdev button processor cdrom > [ 3268.061688] Pid: 13507, comm: gcc Not tainted 2.6.23-rc6-mm1 #4 > [ 3268.067584] RIP: 0010:[ ] [ ] > [ 3268.073578] RSP: :8157ce38 EFLAGS: 00010296 > [ 3268.078867] RAX: 2710 RBX: 810009787050 RCX: > 8100036788e0 > [ 3268.085973] RDX: 018d RSI: 810ba000 RDI: > 810009787080 > [ 3268.093080] RBP: R08: R09: > > [ 3268.100185] R10: R11: 0001 R12: > 810008b849d0 > [ 3268.107293] R13: 810008b850d0 R14: 0001 R15: > 8157cf58 > [ 3268.114399] FS: 2ab84f144170() GS:814f3000() > knlGS: > [ 3268.122455] CS: 0010 DS: ES: CR0: 8005003b > [ 3268.128178] CR2: fffe CR3: 06bfd000 CR4: > 06e0 > [ 3268.135283] DR0: DR1: DR2: > > [ 3268.142388] DR3: DR6: 0ff0 DR7: > 0400 > [ 3268.149495] Process gcc (pid: 13507, threadinfo 81000ebe6000, task > 810008b849d0) > [ 3268.157552] last branch before last exception/interrupt > [ 3268.162753] from [] serial_in+0x23/0x80 > [ 3268.168316] to [] serial_in+0x12/0x80 > [ 3268.173701] Stack: 8157ce78 812e214f 81000ebe7fd8 > > [ 3268.181728] 0ebe7f2d 003d > 8157cf58 > [ 3268.189133] 8157ce88 812e218d 8157ce98 > 812e21a1 > [ 3268.196358] Call Trace: > [ 3268.198974] Inexact backtrace: > [ 3268.202014][] notifier_call_chain+0x3f/0x70 > [ 3268.208531] [] __atomic_notifier_call_chain+0xd/0x10 > [ 3268.215118] [] atomic_notifier_call_chain+0x11/0x20 > [ 3268.221619] [] notify_die+0x2e/0x30 > [ 3268.226736] [] nmi_watchdog_tick+0x4c/0x1e0 > [ 3268.232545] [] default_do_nmi+0x67/0x1e0 > [ 3268.238093] [] do_nmi+0x2f/0x50 > [ 3268.242863] [] nmi+0x7f/0x90 > [ 3268.247377] [] __delay+0xe/0x20 > [ 3268.252147] <> > [ 3268.254416] > [ 3268.254416] Code: Bad RIP value. > [ 3268.259216] RIP [ ]
Re: [PATCH] [9/50] i386: validate against ACPI motherboard resources
On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote: > Yinghai Lu wrote: > > On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote: > >> Thomas Gleixner wrote: > >>> On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote: > Yinghai Lu wrote: > > No! > > > > MMCONFIG will not work with acpi=off any more. > I don't think this is unreasonable. The ACPI MCFG table is how we are > supposed to learn about the area in the first place. If we can't get the > table location via an approved mechanism, and can't validate it doesn't > overlap with another memory reservation or something, I really don't > think we should be using it. > >>> We all know how correct ACPI tables are. Specifications are nice, > >>> reality tells a different story. > >> MMCONFIG can't be used without ACPI in any case unless we know where the > >> table is using chipset-specific knowledge (i.e. reading the registers > >> directly). Doing that without being told that this area is really > >> intended to be used, via the ACPI table, is dangerous, i.e. we don't > >> necessarily know if the MMCONFIG is broken on the platform in some way > >> we can't detect. > > > > the BIOS get these info from the chipset too. > > for AMD Fam 10h opteron, we can read that MSR for MMCONFIG base. > > > I don't think it's much of an issue anyway - the chances that somebody > will want to run without ACPI on a system with MCFG are pretty low given > that you'll end up losing a bunch of functionality (not least of which > is multi-cores). > >>> acpi=off is an often used debug switch and it _is_ quite useful. Taking > >>> away debug functionality is not a good idea. > >> If someone has to turn ACPI off, disabling MMCONFIG is probably the > >> least of their worries.. > > > > MMCONFIG has nothing to do ACPI..., just becase MCFG in the ACPI, we > > must use ACPI for MMCONFIG? > > config PCI_MMCONFIG > bool > depends on PCI && ACPI && (PCI_GOMMCONFIG || PCI_GOANY) > default y > > We already depend on ACPI for MMCONFIG support at compile time. This > patch does not change that. > > We could conceivably skip the validation if ACPI was disabled, though > this would only make a difference in the few cases where we can detect > the MMCONFIG area without it (looks like currently only Intel E7520 and > 945, at least in mainline). i added support for AMD Fam 10h NB, and that patch is in -mm. I like to see pci_mmcfg_check_hostbridge is called before any acpi check up. also in your pci_mmcfg_early_init, you may miss calling to pci_mmcfg_insert_resource... 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: [PATCH] [20/50] x86_64: Fix some broken white space in arch/x86_64/mm/init.c
Much, much better :)
> -static void __meminit phys_pud_init(pud_t *pud_page, unsigned long addr,
> unsigned long end)
> -{
+static void __meminit phys_pud_init(pud_t *pud_page, ulong addr, ulong end)
If somebody have *strong* objections, please say so.
[]
> @@ -737,7 +750,7 @@ int in_gate_area_no_task(unsigned long addr)
> void * __init alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size)
> {
> return __alloc_bootmem_core(pgdat->bdata, size,
> - SMP_CACHE_BYTES, (4UL*1024*1024*1024), 0);
> + SMP_CACHE_BYTES, (4UL*1024*1024*1024), 0);
> }
Maybe just?
+ return __alloc_bootmem_core(pgdat->bdata, size, SMP_CACHE_BYTES, 1UL <<
32, 0);
(87 is alright sometimes)
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc6-mm1 -- mkfs stuck in 'D'
On Sat, Sep 22, 2007 at 03:16:22PM +0200, Peter Zijlstra wrote: > On Sat, 22 Sep 2007 09:55:09 +0800 Fengguang Wu <[EMAIL PROTECTED]> > wrote: > > > --- linux-2.6.22.orig/mm/page-writeback.c > > +++ linux-2.6.22/mm/page-writeback.c > > @@ -426,6 +426,14 @@ static void balance_dirty_pages(struct a > > bdi_nr_writeback = bdi_stat(bdi, BDI_WRITEBACK); > > } > > > > + printk(KERN_DEBUG "balance_dirty_pages written %lu %lu > > congested %d limits %lu %lu %lu %lu %lu %ld\n", > > + pages_written, > > + write_chunk - wbc.nr_to_write, > > + bdi_write_congested(bdi), > > + background_thresh, dirty_thresh, > > + bdi_thresh, bdi_nr_reclaimable, > > bdi_nr_writeback, > > + bdi_thresh - bdi_nr_reclaimable - > > bdi_nr_writeback); > > + > > if (bdi_nr_reclaimable + bdi_nr_writeback <= bdi_thresh) > > break; > > if (pages_written >= write_chunk) > > > > > [ 1305.361511] balance_dirty_pages written 0 0 congested 0 limits 48869 > > 195477 5801 5760 288 -247 > > > > Could you perhaps instrument the writeback_inodes() path to see why > nothing is written out? - the attached patch would be a nice start. Curiously the lockup problem disappeared after upgrading to 2.6.23-rc6-mm1. (need to watch it in a longer time window). Anyway here's the output of your patch: sb_locked 0 sb_empty 97011 > Most peculiar. It seems writeback_inodes() doesn't even attempt to > write out stuff. Nor are outstanding writeback pages completed. Still true. Another problem is that balance_dirty_pages() is being called even when there are only 54 dirty pages. That could slow down writers unnecessarily. balance_dirty_pages() should not be entered at all with small nr_dirty. Look at these lines: [ 197.471619] balance_dirty_pages for tar written 405 405 congested 0 global 196554 54 403 196097 bdi 0 0 398 -398 [ 197.472196] balance_dirty_pages for tar written 405 0 congested 0 global 196554 54 372 196128 bdi 0 0 380 -380 [ 197.472893] balance_dirty_pages for tar written 405 0 congested 0 global 196554 54 372 196128 bdi 23 0 369 -346 [ 197.473158] balance_dirty_pages for tar written 405 0 congested 0 global 196554 54 372 196128 bdi 23 0 366 -343 [ 197.473403] balance_dirty_pages for tar written 405 0 congested 0 global 196554 54 372 196128 bdi 23 0 365 -342 [ 197.473674] balance_dirty_pages for tar written 405 0 congested 0 global 196554 54 372 196128 bdi 23 0 364 -341 [ 197.474265] balance_dirty_pages for tar written 405 0 congested 0 global 196554 54 372 196128 bdi 23 0 362 -339 [ 197.475440] balance_dirty_pages for tar written 405 0 congested 0 global 196554 54 341 196159 bdi 47 0 327 -280 [ 197.476970] balance_dirty_pages for tar written 405 0 congested 0 global 196546 54 279 196213 bdi 95 0 279 -184 [ 197.43] balance_dirty_pages for tar written 405 0 congested 0 global 196546 54 248 196244 bdi 95 0 255 -160 [ 197.479463] balance_dirty_pages for tar written 405 0 congested 0 global 196546 54 217 196275 bdi 143 0 210 -67 [ 197.479656] balance_dirty_pages for tar written 405 0 congested 0 global 196546 54 217 196275 bdi 143 0 209 -66 [ 197.481159] balance_dirty_pages for tar written 405 0 congested 0 global 196546 54 155 196337 bdi 167 0 163 4 The trace messages are generated by the following code: --- linux-2.6.23-rc6-mm1.orig/mm/page-writeback.c +++ linux-2.6.23-rc6-mm1/mm/page-writeback.c @@ -421,6 +421,18 @@ static void balance_dirty_pages(struct a bdi_nr_writeback = bdi_stat(bdi, BDI_WRITEBACK); } + printk(KERN_DEBUG "balance_dirty_pages for %s written %lu %lu congested %d " + "global %lu %lu %lu %ld bdi %lu %lu %lu %ld\n", + current->comm, + pages_written, write_chunk - wbc.nr_to_write, + bdi_write_congested(bdi), + dirty_thresh, + global_dirty_unstable_pages(), global_page_state(NR_WRITEBACK), + dirty_thresh - + global_dirty_unstable_pages() - global_page_state(NR_WRITEBACK), + bdi_thresh, bdi_nr_reclaimable, bdi_nr_writeback, + bdi_thresh - bdi_nr_reclaimable - bdi_nr_writeback); + if (bdi_nr_reclaimable + bdi_nr_writeback <= bdi_thresh) break; if (pages_written >= write_chunk) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [9/50] i386: validate against ACPI motherboard resources
On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> Yinghai Lu wrote:
> > On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> >> Thomas Gleixner wrote:
> >>> On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
> Yinghai Lu wrote:
> > No!
> >
> > MMCONFIG will not work with acpi=off any more.
> I don't think this is unreasonable. The ACPI MCFG table is how we are
> supposed to learn about the area in the first place. If we can't get the
> table location via an approved mechanism, and can't validate it doesn't
> overlap with another memory reservation or something, I really don't
> think we should be using it.
> >>> We all know how correct ACPI tables are. Specifications are nice,
> >>> reality tells a different story.
> >> MMCONFIG can't be used without ACPI in any case unless we know where the
> >> table is using chipset-specific knowledge (i.e. reading the registers
> >> directly). Doing that without being told that this area is really
> >> intended to be used, via the ACPI table, is dangerous, i.e. we don't
> >> necessarily know if the MMCONFIG is broken on the platform in some way
> >> we can't detect.
> >
> > the BIOS get these info from the chipset too.
> > for AMD Fam 10h opteron, we can read that MSR for MMCONFIG base.
> >
> I don't think it's much of an issue anyway - the chances that somebody
> will want to run without ACPI on a system with MCFG are pretty low given
> that you'll end up losing a bunch of functionality (not least of which
> is multi-cores).
> >>> acpi=off is an often used debug switch and it _is_ quite useful. Taking
> >>> away debug functionality is not a good idea.
> >> If someone has to turn ACPI off, disabling MMCONFIG is probably the
> >> least of their worries..
> >
> > MMCONFIG has nothing to do ACPI..., just becase MCFG in the ACPI, we
> > must use ACPI for MMCONFIG?
>
> config PCI_MMCONFIG
> bool
> depends on PCI && ACPI && (PCI_GOMMCONFIG || PCI_GOANY)
> default y
>
> We already depend on ACPI for MMCONFIG support at compile time. This
> patch does not change that.
>
> We could conceivably skip the validation if ACPI was disabled, though
> this would only make a difference in the few cases where we can detect
> the MMCONFIG area without it (looks like currently only Intel E7520 and
> 945, at least in mainline).
can you make pci_mmcfg_late_init take one parameter about if acpi is
there or not?
so in acpi_init will be
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 9ba778a..a4a6a6f 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -746,6 +746,7 @@ static int __init acpi_init(void)
if (acpi_disabled) {
printk(KERN_INFO PREFIX "Interpreter disabled.\n");
+ pci_mmcfg_late_init(0);
return -ENODEV;
}
@@ -757,6 +758,7 @@ static int __init acpi_init(void)
result = acpi_bus_init();
if (!result) {
+ pci_mmcfg_late_init(1);
#ifdef CONFIG_PM_LEGACY
if (!PM_IS_ACTIVE())
pm_active = 1;
@@ -767,8 +769,10 @@ static int __init acpi_init(void)
result = -ENODEV;
}
#endif
- } else
+ } else {
+ pci_mmcfg_late_init(0);
disable_acpi();
+ }
return result;
}
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: Should parent's WIFSIGNALED(siginfo->si_status) be true EVEN IF the SIGNAL was caught by the child?
On Saturday 22 September 2007 16:35:56 Andreas Schwab wrote: > "John Z. Bohach" <[EMAIL PROTECTED]> writes: > > if (WIFEXITED(siginfo->si_status)) > > That does not make any sense. si_status is _not_ a wait status. > > Andreas. Thank you for clearing that up. That explains it. --john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] New kernel-message logging API
On 9/22/07, Vegard Nossum <[EMAIL PROTECTED]> wrote:
> After recent discussions on LKML and a general dissatisfaction at the
> current printk() kernel-message logging interface, I've decided to
> write down some of the ideas for a better system.
Nice. I would suggest having some kind of standard way to show the
information on the screen/dmesg. I mean, instead of having plain lines
being written to the log, having something very short like:
SSL: Message sent.
Being:
SS - Subsystem ("EA" for early code, "MM" for memory managment, "PU"
for processor stuff, "HD" for hard disks, "PP" for parallel port, "NT"
for networking, "VI" for video stuff, "FB" for framebuffers, "SN" for
sound stuff, "KE" for keyboard, "MO" for mouse, ... I think you get
the idea, just generic things).
L - Log level (0 for emerg, ..., 7 for debug)
And maybe some other character for other information. This would be
great to read pretty easily dmesg and for grepping, like:
$ dmesg | grep ^FB
for getting just information about framebuffers, or
$ dmesg | grep ^..[0123]
to get all the problems of the whole kernel/system.
So, for example, userspace scripts will be able to separate into
different log files the kernel stuff:
#!/bin/sh
dmesg | grep ^..[0123] > klog.errors
dmesg | grep ^NT > klog.networking
dmesg | grep ^HD > klog.harddisks
dmesg | grep ^FB > klog.framebuffers
Maybe its weird at first, but I think it will speed up the reading of
plain dmesg's outputs for everyone at the cost of 3-5 more characters
at every line in dmesg.
Also, it may help to make printk()'s messages to be more uniform,
instead of having every .c file having differents ways to express
similar things.
Getting more complex, lets add another character:
SSLR: Message sent.
being R the reason of the message (D for information about a
probed-and-detected hardware [like a PCI card], R for a new
succesfully registered device [like a framebuffer], S for new settings
in a device [like taking up a ethernet link, or that messages about
IRQs], C for copyright/about/info lines, ...).
Now we have at some dmesg (for example):
eth0: Broadcom 4400 10/100BaseT Ethernet 00:1f:a2:0c:4a:72
ieee80211_crypt: registered algorithm 'TKIP'
ipw3945: Intel(R) PRO/Wireless 3945 Network Connection 1.2.2d
ipw3945: Copyright(c) 2003-2006 Intel Corporation
ACPI: PCI Interrupt :0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device :0c:00.0 to 64
ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection
ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)
usb 6-1: new low speed USB device using uhci_hcd and address 2
usb 6-1: configuration #1 chosen from 1 choice
usbcore: registered new interface driver hiddev
and we could have:
NT6R eth0: Broadcom 4400 10/100BaseT Ethernet 00:1f:a2:0c:4a:72
NT6R ieee80211_crypt: algorithm 'TKIP'
NT6C ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver 1.2.2d
NT7C ipw3945: Copyright(c) 2003-2006 Intel Corporation
XX6S ACPI: PCI Interrupt :0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
XX6S PCI: Latency timer of device :0c:00.0 to 64
NT6R ipw3945: Intel PRO/Wireless 3945ABG Network Connection
NT6D ipw3945: geography ABG (13 802.11bg channels, 23 802.11a channels)
US6R usb 6-1: low speed USB device using uhci_hcd and address 2
US6S usb 6-1: configuration #1 chosen from 1 choice
US6R usbcore: new interface driver hiddev
which I think its much more clear... Wanna know about registered
networking-related devices? Then grep using "^NT.R":
NT6R eth0: Broadcom 4400 10/100BaseT Ethernet 00:1f:a2:0c:4a:72
NT6R ieee80211_crypt: algorithm 'TKIP'
NT6R ipw3945: Intel PRO/Wireless 3945ABG Network Connection
...
Nothing more, thanks for reading :)
--
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/2] suspend/resume regression fixes
* Sat, 22 Sep 2007 15:59:25 -0700 (PDT) As i never had any suspend working ever, let me point this LKML post http://mid.gmane.org/[EMAIL PROTECTED] from Mihal, who just managed to do some other magic in sligtly different context (maybe yet another anti "ACPI screwed up"). Mihai, you can find whole thread by above URL, requesting message-ids from in-reply-to or references headers of this message. _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] New kernel-message logging API
On Sat, 2007-09-22 at 20:40 -0400, Kyle Moffett wrote: > Severity is *exactly* "desirability of logging". Disagree. What's info to someone is an alert to someone else. The problem is the valuation of the reasoning. It's all opinion. cheers, Joe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] New kernel-message logging API
On Sep 22, 2007, at 20:13:03, Joe Perches wrote: On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: Additionally, this would allow the compiler to completely optimize out calls that are below a certain log-level severity level [2][3]. Severity doesn't really equate to desire to log. I'd prefer arbitrary control of log levels. Umm, actually... Severity is *exactly* "desirability of logging". If you find any place that's otherwise then please provide patches to fix it (or at least notify the maintainer with a useful bug report and reasoning. 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: [RFC] New kernel-message logging API
On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: > #define kprint(fmt, ...) Good ideas. Perhaps a prefix of klog or kp_ instead? Given the number of 80 column zealots, character naming length matters. > Additionally, this would allow the compiler to completely optimize out > calls that are below a certain log-level severity level [2][3]. Severity doesn't really equate to desire to log. I'd prefer arbitrary control of log levels. cheers, Joe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Serial ATA does not find partitions (Hitachi HD, new? ATI controller) where old SATA works
Hello I am disturbing you with this problem because I think there is something to be learnt, I have no urgency or further-problem with my work-around. Description: trying to boot with kernel 2.6.22 the booting process stops not finding the root partition, in the previous line it gives an EMPTY list of available partitions. Disabling completely the (Serial) ATA driver and enabling the old SATA driver is my work-around (a regresion). Installing linux with debian 4.0 is possible (kernel 2.6.18.4-amd64), but ubuntu crashes silently after loading kernel and initrd.image (I guess it is the same problem). Description of the machine, dmesg output with kernel 2.6.22, lspci, modules, cpu, iomem, ioports, acpi-table as well as instalation story at http://www.df.uba.ar/~solari/acer.html Hitachi 120Gb drive scsi 0:0:0:0: Direct-Access ATA Hitachi HTS54161 SBDO PQ: 0 ANSI: 5 ATI controller 00:12.0 IDE interface: ATI Technologies Inc 4379 Serial ATA Controller (rev 80) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: Acer Incorporated [ALI] Unknown device 010f (pci.ids are up-to-day) The acpi system does not work either, but I have reported the problem to a more specific list. I can test patches in case you want. thanks for your attention Hernan -- Hernán Gustavo Solari, [EMAIL PROTECTED], http://www.df.uba.ar/~solari - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VGA text console display problem with kernel 2.6.23-rc5/6
On Thu, 2007-09-20 at 02:26 -0400, ben soo wrote: > Antonino A. Daplas wrote: > > On Tue, 2007-09-18 at 03:26 -0400, ben soo wrote: > >> i've 2 servers with old PCI VGA cards, one using X86_64 kernel > >> version 2.6.23-rc5 and one with i386 kernel version 2.6.23-rc6, > >> both wired into the same CRT via a KVM switch. > > > > Is this new? If yes, what's the version of the last working kernel? > > Hi Antonio; i'm very sorry about the delay in answering: been > pretty ill. > That's okay. > i had upgraded all four servers here to 2.6.23-rc6 and found that > only one had this console problem. It runs a very old S3 Virge > PCI vidcard. > > Tonight i upgraded it to 2.6.23-rc7 and the console is fine again, > but, just to be complete i include the requested info: > > > Can you post dmesg and output of stty -a? > > stty -a > > speed 38400 baud; rows 34; columns 80; line = 0; Yes, you have an 80x34 screen (normal VGA is 80x25). I have received several reports about this problem (if the kernel boots with an initial screen which is not 80x25 and the init scripts attempts to set an 8x16 font, the user gets a display that does not fit the screen). Your problem though is probably unrelated. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should parent's WIFSIGNALED(siginfo->si_status) be true EVEN IF the SIGNAL was caught by the child?
"John Z. Bohach" <[EMAIL PROTECTED]> writes: > if (WIFEXITED(siginfo->si_status)) That does not make any sense. si_status is _not_ a wait status. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] usb-gadget-ether: Prevent oops caused by error interrupt race -V2 (comments update)
On Sat, 2007-09-22 at 13:53 -0700, David Brownell wrote: > > Sigh. I need a real deep look inside that code to understand, why > > tx_reqs is not a requestlist but a freelist. Very intuitive naming :) > > It *is* a list of requests: free ones -- the only kind this level of > driver is allowed to remember! ;) > > Yeah, I had to go back and read the driver again before I understood > just what problem this patch was trying to fix. Which is why I wanted > to make sure the mismatch between comments and contents was resolved. Fair enough. Thanks for sanitizing the comments. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/2] suspend/resume regression fixes
Linus, On Sat, 2007-09-22 at 15:59 -0700, Linus Torvalds wrote: > > My final enlightment was, when I removed the ACPI processor module, > > which controls the lower idle C-states, right before resume; this > > worked fine all the time even without all the workaround hacks. > > > > I really hope that this two patches finally set an end to the "jinxed > > VAIO heisenbug series", which started when we removed the periodic > > tick with the clockevents/dyntick patches. > > Ok, so the patches look fine, but I somehow have this slight feeling that > you gave up a bit too soon on the "*why* does this happen?" question. Yeah, I gave up at the point where I was not longer able to dig deeper :) > I realize that the answer is easily "because ACPI screwed up", but I'm > wondering if there's something we do to trigger that screw-up. Fair enough. > In particular, I also suspect that this may not really fix the problem - > maybe it just makes the window sufficiently small that it no longer > triggers. Because we don't necessarily understand what the real background > for the problem is, I'm not sure we can say that it is solved. > > The reason I say this is that I have a suspicion on what triggers it. > > I suspect that the problem is that we do > > pm_ops->prepare(); > disable_nonboot_cpus() > suspend_enter(); > enable_nonboot_cpus() > pm_finish() > > and here the big thing to notice is that "pm_ops->prepare()" call, which > sets the wakup vector etc etc. > > So maybe the real problem here is that once we've done the "->prepare()" > call and ACPI has set up various stuff, we MUST NOT do any calls to any > ACPI routines to set low-power states, because the stupid firmware isn't > expecting it. That's what I suspect and deduced from the various experiments including a force the cpu into a lower c-state one, which triggered the problem fully reproducible. Note that in case of the "force a lower c-state" I verified, that the PIT was activated to avoid the local apic stops in c3 issue. But I never got an PIT interrupt. Either the box was completely stuck or I was able to recover by hitting a key, which is as well one of the unexplained phenomenons. > Now, if this is the cause, then I think your patch should indeed fix it, > since you get called by the early-suspend code (which happens *before* the > "->prepare()" call), but at the same time, I wonder if maybe it would be > slightly "more correct" to instead of using the suspend/resume callbacks, > simply do this in the "acpi_pm_prepare()" stage, since that is likely the > thing that triggers it? Yeah, probably that's the correct point, but I leave this to the ACPI wizards. > But hey, I think I'll apply the patches as-is. I'd just feel even better > if we actually understood *why* doing the CPU Cx states is not something > we can do around the suspend code! That needs some explanation of the folks who can actually look beyond the ACPI/BIOS internals. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Not kernel dev related story (Re: Linux Router)
* Sat, 22 Sep 2007 18:09:15 -0500 > This is starting to frustrate me, because it should be much simpler > than it seems to be, and I feel like I'm missing something small and > obvious. Please address such questions to any user forum, or to <[EMAIL PROTECTED]> otherwise. While doing that, provide exact output of route and firewall tables, but not just semi hand-waving with just one command. Thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: A revised timerfd API
On Sat, 22 Sep 2007, Thomas Gleixner wrote: > On Sat, 2007-09-22 at 14:07 -0700, Davide Libenzi wrote: > > On Sat, 22 Sep 2007, Michael Kerrisk wrote: > > > > > So I'm inclined to implement option (b), unless someone has strong > > > objections. Davide, could I persuade you to help? > > > > I guess I better do, otherwise you'll continue to stress me ;) > > > > int timerfd_create(int clockid); > > int timerfd_settime(int ufd, int flags, > > const struct itimerspec *utmr, > > struct itimerspec *otmr); > > int timerfd_gettime(int ufd, struct itimerspec *otmr); > > > > Patch below. Builds, not tested yet (you need to remove the "broken" > > status from CONFIG_TIMERFD in case you want to test - and plug the new > > syscall to arch/xxx). > > May that work for you? > > Thomas-san, hrtimer_try_to_cancel() does not touch ->expires and I assume > > it'll never do, granted? > > Davide-san, I have no intention to change that, but remember there is > this file "Documentation/stable_api_nonsense.txt" :) Heh, I guess that'll work then ;) - 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/
Linux Router
This is starting to frustrate me, because it should be much simpler than it seems to be, and I feel like I'm missing something small and obvious. I have two private networks, we'll say 192.168.254.0/24 and 192.168.251.0/24. And I have a linux box in the middle with addresses 192.168.254.17 and 192.168.251.10: +---+ . ++ ¦ 192.168.251.1 +---+ 192.168.251.10 ¦ . ++ +---+ . ¦ 192.168.254.17 +---+ 192.168.254.16 ¦ . . . . . . . . . . ++ . ++ There is no NAT involved.. I just want the box in the middle to pass traffic between the two networks. Here is what I have done: - IP Forwarding has been enabled on the router via "echo 1 > /proc/sys/net/ipv4/ip_forward" - A route has been configured on 192.168.251.1 to point all traffic for 192.168.254.0/24 to 192.168.251.10. - A route has been configured on 192.168.254.16 to point all traffic for 192.168.251.0/24 to 192.168.254.17. - The command "iptables -I FORWARD -j ACCEPT" has been executed. Now.. here's what happens. 192.168.251.10 can ping both interfaces on the router. 192.168.254.16 can also ping both interfaces on the router. However, 192.168.251.1 cannot ping 192.168.254.16, and likewise, 192.168.254.16 cannot ping 192.168.251.1. What have I forgotten? -- Carlos Narváez http://www.juegopixel.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/2] suspend/resume regression fixes
On Sat, 22 Sep 2007, Thomas Gleixner wrote: > > My final enlightment was, when I removed the ACPI processor module, > which controls the lower idle C-states, right before resume; this > worked fine all the time even without all the workaround hacks. > > I really hope that this two patches finally set an end to the "jinxed > VAIO heisenbug series", which started when we removed the periodic > tick with the clockevents/dyntick patches. Ok, so the patches look fine, but I somehow have this slight feeling that you gave up a bit too soon on the "*why* does this happen?" question. I realize that the answer is easily "because ACPI screwed up", but I'm wondering if there's something we do to trigger that screw-up. In particular, I also suspect that this may not really fix the problem - maybe it just makes the window sufficiently small that it no longer triggers. Because we don't necessarily understand what the real background for the problem is, I'm not sure we can say that it is solved. The reason I say this is that I have a suspicion on what triggers it. I suspect that the problem is that we do pm_ops->prepare(); disable_nonboot_cpus() suspend_enter(); enable_nonboot_cpus() pm_finish() and here the big thing to notice is that "pm_ops->prepare()" call, which sets the wakup vector etc etc. So maybe the real problem here is that once we've done the "->prepare()" call and ACPI has set up various stuff, we MUST NOT do any calls to any ACPI routines to set low-power states, because the stupid firmware isn't expecting it. Now, if this is the cause, then I think your patch should indeed fix it, since you get called by the early-suspend code (which happens *before* the "->prepare()" call), but at the same time, I wonder if maybe it would be slightly "more correct" to instead of using the suspend/resume callbacks, simply do this in the "acpi_pm_prepare()" stage, since that is likely the thing that triggers it? But hey, I think I'll apply the patches as-is. I'd just feel even better if we actually understood *why* doing the CPU Cx states is not something we can do around the suspend code! Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/7] Extended crashkernel command line
* Thu, 20 Sep 2007 19:18:46 +0200
[]
> extern u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
> extern unsigned int vmcoreinfo_size;
> extern unsigned int vmcoreinfo_max_size;
> +int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
> + unsigned long long *crash_size, unsigned long long *crash_base);
(BTW, why `system_ram' is `unsigned long' in parse_crashkernel_mem() but
`unsigned long long' in parse_crashkernel()?)
> +static int __init parse_crashkernel_mem(char
> *cmdline,
> + unsigned long system_ram,
> + unsigned long long *crash_size,
> + unsigned long long *crash_base)
> +{
> + char *cur = cmdline;
> +
> + /* for each entry of the comma-separated list */
> + do {
> + unsigned long long start = 0, end = ULLONG_MAX;
> + unsigned long long size = -1;
[]
What is the point of not using `ulong' and `u64'?
What about another names?
+int __init get_crashkernel_params(u64 *memsize, u64 *addrbase, char *cmdline,
u64 ram);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] clockevents: remove the suspend/resume workaround^Wthinko
In a desparate attempt to fix the suspend/resume problem on Andrews
VAIO I added a workaround which enforced the broadcast of the oneshot
timer on resume. This was actually resolving the problem on the VAIO
but was just a stupid workaround, which was not tackling the root
cause: the assignement of lower idle C-States in the ACPI processor_idle
code. The cpuidle patches, which utilize the dynamic tick feature and
go faster into deeper C-states exposed the problem again. The correct
solution is the previous patch, which prevents lower C-states across
the suspend/resume.
Remove the enforcement code, including the conditional broadcast timer
arming, which helped to pamper over the real problem for quite a time.
The oneshot broadcast flag for the cpu, which runs the resume code can
never be set at the time when this code is executed. It only gets set,
when the CPU is entering a lower idle C-State.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Tested-by: Andrew Morton <[EMAIL PROTECTED]>
Cc: Len Brown <[EMAIL PROTECTED]>
Cc: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Cc: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
kernel/time/tick-broadcast.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
Index: linux-2.6/kernel/time/tick-broadcast.c
===
--- linux-2.6.orig/kernel/time/tick-broadcast.c 2007-09-23 00:00:59.0
+0200
+++ linux-2.6/kernel/time/tick-broadcast.c 2007-09-23 00:01:00.0
+0200
@@ -382,23 +382,8 @@ static int tick_broadcast_set_event(ktim
int tick_resume_broadcast_oneshot(struct clock_event_device *bc)
{
- int cpu = smp_processor_id();
-
- /*
-* If the CPU is marked for broadcast, enforce oneshot
-* broadcast mode. The jinxed VAIO does not resume otherwise.
-* No idea why it ends up in a lower C State during resume
-* without notifying the clock events layer.
-*/
- if (cpu_isset(cpu, tick_broadcast_mask))
- cpu_set(cpu, tick_broadcast_oneshot_mask);
-
clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT);
-
- if(!cpus_empty(tick_broadcast_oneshot_mask))
- tick_broadcast_set_event(ktime_get(), 1);
-
- return cpu_isset(cpu, tick_broadcast_oneshot_mask);
+ return 0;
}
/*
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 0/2] suspend/resume regression fixes
Sorry, it took me quite a while to realize the real root cause of the VAIO - and probably many other machines - suspend/resume regressions, which were unearthed by the dyntick / clockevents patches. We disable a lot of ACPI/BIOS functionality during suspend, but we keep the lower idle C-states functionality active across suspend/resume. It seems that this causes trouble with certain BIOSes, but I assume that the problem is more wide spread and just not surfacing due to the various scenarios in which a machine goes into suspend/resume. I spent some quality time to figure out a set of debug mechanisms, which did not influence the problem. So it is quite likely that a lot of machines might be affected by this, but due to the configuration, interrupt scenarios, the problem just does not show up. My final enlightment was, when I removed the ACPI processor module, which controls the lower idle C-states, right before resume; this worked fine all the time even without all the workaround hacks. I really hope that this two patches finally set an end to the "jinxed VAIO heisenbug series", which started when we removed the periodic tick with the clockevents/dyntick patches. Venki, can you please add the analogous fix to the cpuidle patch set ? Thanks, tglx -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] ACPI: disable lower idle C-states across suspend/resume
device_suspend() calls ACPI suspend functions, which seems to have undesired
side effects on lower idle C-states. It took me some time to realize that
especially the VAIO BIOSes (both Andrews jinxed UP and my elfstruck SMP one)
show this effect. I'm quite sure that other bug reports against suspend/resume
about turning the system into a brick have the same root cause.
After fishing in the dark for quite some time, I realized that removing the ACPI
processor module before suspend (this removes the lower C-state functionality)
made the problem disappear. Interestingly enough the propability of having a
bricked box is influenced by various factors (interrupts, size of the ram image,
...). Even adding a bunch of printks in the wrong places made the problem go
away. The previous periodic tick implementation simply pampered over the
problem, which explains why the dyntick / clockevents changes made this more
prominent.
We avoid complex functionality during the boot process and we have to do the
same during suspend/resume. It is a similar scenario and equaly fragile.
Add suspend / resume functions to the ACPI processor code and disable the lower
idle C-states across suspend/resume. Fall back to the default idle
implementation (halt) instead.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Tested-by: Andrew Morton <[EMAIL PROTECTED]>
Cc: Len Brown <[EMAIL PROTECTED]>
Cc: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Cc: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
drivers/acpi/processor_core.c |2 ++
drivers/acpi/processor_idle.c | 19 ++-
include/acpi/processor.h |2 ++
3 files changed, 22 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/acpi/processor_core.c
===
--- linux-2.6.orig/drivers/acpi/processor_core.c2007-09-23
00:01:00.0 +0200
+++ linux-2.6/drivers/acpi/processor_core.c 2007-09-23 00:01:00.0
+0200
@@ -102,6 +102,8 @@ static struct acpi_driver acpi_processor
.add = acpi_processor_add,
.remove = acpi_processor_remove,
.start = acpi_processor_start,
+ .suspend = acpi_processor_suspend,
+ .resume = acpi_processor_resume,
},
};
Index: linux-2.6/drivers/acpi/processor_idle.c
===
--- linux-2.6.orig/drivers/acpi/processor_idle.c2007-09-23
00:01:00.0 +0200
+++ linux-2.6/drivers/acpi/processor_idle.c 2007-09-23 00:01:00.0
+0200
@@ -325,6 +325,23 @@ static void acpi_state_timer_broadcast(s
#endif
+/*
+ * Suspend / resume control
+ */
+static int acpi_idle_suspend;
+
+int acpi_processor_suspend(struct acpi_device * device, pm_message_t state)
+{
+ acpi_idle_suspend = 1;
+ return 0;
+}
+
+int acpi_processor_resume(struct acpi_device * device)
+{
+ acpi_idle_suspend = 0;
+ return 0;
+}
+
static void acpi_processor_idle(void)
{
struct acpi_processor *pr = NULL;
@@ -355,7 +372,7 @@ static void acpi_processor_idle(void)
}
cx = pr->power.state;
- if (!cx) {
+ if (!cx || acpi_idle_suspend) {
if (pm_idle_save)
pm_idle_save();
else
Index: linux-2.6/include/acpi/processor.h
===
--- linux-2.6.orig/include/acpi/processor.h 2007-09-23 00:01:00.0
+0200
+++ linux-2.6/include/acpi/processor.h 2007-09-23 00:01:00.0 +0200
@@ -320,6 +320,8 @@ int acpi_processor_power_init(struct acp
int acpi_processor_cst_has_changed(struct acpi_processor *pr);
int acpi_processor_power_exit(struct acpi_processor *pr,
struct acpi_device *device);
+int acpi_processor_suspend(struct acpi_device * device, pm_message_t state);
+int acpi_processor_resume(struct acpi_device * device);
/* in processor_thermal.c */
int acpi_processor_get_limit_info(struct acpi_processor *pr);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] Intel FB: force even line count in interlaced mode
Intel FB: the chip adds two halflines automatically in interlaced mode,
force even line count for the right timings.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
--- a/drivers/video/intelfb/intelfbhw.c
+++ b/drivers/video/intelfb/intelfbhw.c
@@ -317,6 +317,14 @@ int intelfbhw_validate_mode(struct intelfb_info *dinfo,
var->yres, VACTIVE_MASK + 1);
return 1;
}
+ if (var->xres < 4) {
+ WRN_MSG("X resolution too small (%d vs 4).\n", var->xres);
+ return 1;
+ }
+ if (var->yres < 4) {
+ WRN_MSG("Y resolution too small (%d vs 4).\n", var->yres);
+ return 1;
+ }
/* Check for doublescan modes. */
if (var->vmode & FB_VMODE_DOUBLE) {
@@ -324,6 +332,11 @@ int intelfbhw_validate_mode(struct intelfb_info *dinfo,
return 1;
}
+ if ((var->vmode & FB_VMODE_INTERLACED) && (var->yres & 1)) {
+ WRN_MSG("Odd number of lines in interlaced mode\n");
+ return 1;
+ }
+
/* Check if clock is OK. */
tmp = 10 / var->pixclock;
if (tmp < MIN_CLOCK) {
@@ -1127,6 +1140,8 @@ int intelfbhw_mode_to_hw(struct intelfb_info *dinfo,
hblank_end);
vactive = var->yres;
+ if (var->vmode & FB_VMODE_INTERLACED)
+ vactive--; /* the chip adds 2 halflines automatically */
vsync_start = vactive + var->lower_margin;
vsync_end = vsync_start + var->vsync_len;
vtotal = vsync_end + var->upper_margin;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 4/4] Intel FB: more interlaced mode support
Intel FB: allow odd- and even-field-first in interlaced modes, and
proper sync to vertical retrace
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
--- a/drivers/video/intelfb/intelfbhw.c
+++ b/drivers/video/intelfb/intelfbhw.c
@@ -376,7 +376,7 @@ int intelfbhw_pan_display(struct fb_var_screeninfo *var,
struct fb_info *info)
dinfo->vsync.pan_offset = offset;
if ((var->activate & FB_ACTIVATE_VBL) &&
- !intelfbhw_enable_irq(dinfo, 0))
+ !intelfbhw_enable_irq(dinfo))
dinfo->vsync.pan_display = 1;
else {
dinfo->vsync.pan_display = 0;
@@ -1240,7 +1240,7 @@ int intelfbhw_program_mode(struct intelfb_info *dinfo,
u32 tmp;
const u32 *dpll, *fp0, *fp1, *pipe_conf;
const u32 *hs, *ht, *hb, *vs, *vt, *vb, *ss;
- u32 dpll_reg, fp0_reg, fp1_reg, pipe_conf_reg;
+ u32 dpll_reg, fp0_reg, fp1_reg, pipe_conf_reg, pipe_stat_reg;
u32 hsync_reg, htotal_reg, hblank_reg;
u32 vsync_reg, vtotal_reg, vblank_reg;
u32 src_size_reg;
@@ -1281,6 +1281,7 @@ int intelfbhw_program_mode(struct intelfb_info *dinfo,
fp0_reg = FPB0;
fp1_reg = FPB1;
pipe_conf_reg = PIPEBCONF;
+ pipe_stat_reg = PIPEBSTAT;
hsync_reg = HSYNC_B;
htotal_reg = HTOTAL_B;
hblank_reg = HBLANK_B;
@@ -1304,6 +1305,7 @@ int intelfbhw_program_mode(struct intelfb_info *dinfo,
fp0_reg = FPA0;
fp1_reg = FPA1;
pipe_conf_reg = PIPEACONF;
+ pipe_stat_reg = PIPEASTAT;
hsync_reg = HSYNC_A;
htotal_reg = HTOTAL_A;
hblank_reg = HBLANK_A;
@@ -1390,6 +1392,17 @@ int intelfbhw_program_mode(struct intelfb_info *dinfo,
OUTREG(vtotal_reg, *vt);
OUTREG(src_size_reg, *ss);
+ switch (dinfo->info->var.vmode & (FB_VMODE_INTERLACED |
+ FB_VMODE_ODD_FLD_FIRST)) {
+ case FB_VMODE_INTERLACED | FB_VMODE_ODD_FLD_FIRST:
+ OUTREG(pipe_stat_reg, 0x | PIPESTAT_FLD_EVT_ODD_EN);
+ break;
+ case FB_VMODE_INTERLACED: /* even lines first */
+ OUTREG(pipe_stat_reg, 0x | PIPESTAT_FLD_EVT_EVEN_EN);
+ break;
+ default:/* non-interlaced */
+ OUTREG(pipe_stat_reg, 0x); /* clear all status bits only */
+ }
/* Enable pipe */
OUTREG(pipe_conf_reg, *pipe_conf | PIPECONF_ENABLE);
@@ -1955,71 +1968,72 @@ void intelfbhw_cursor_reset(struct intelfb_info *dinfo)
}
}
-static irqreturn_t
-intelfbhw_irq(int irq, void *dev_id) {
- int handled = 0;
+static irqreturn_t intelfbhw_irq(int irq, void *dev_id)
+{
u16 tmp;
struct intelfb_info *dinfo = (struct intelfb_info *)dev_id;
spin_lock(>int_lock);
tmp = INREG16(IIR);
- tmp &= VSYNC_PIPE_A_INTERRUPT;
+ if (dinfo->info->var.vmode & FB_VMODE_INTERLACED)
+ tmp &= PIPE_A_EVENT_INTERRUPT;
+ else
+ tmp &= VSYNC_PIPE_A_INTERRUPT; /* non-interlaced */
if (tmp == 0) {
spin_unlock(>int_lock);
- return IRQ_RETVAL(handled);
+ return IRQ_RETVAL(0); /* not us */
}
- OUTREG16(IIR, tmp);
+ /* clear status bits 0-15 ASAP and don't touch bits 16-31 */
+ OUTREG(PIPEASTAT, INREG(PIPEASTAT));
- if (tmp & VSYNC_PIPE_A_INTERRUPT) {
- dinfo->vsync.count++;
- if (dinfo->vsync.pan_display) {
- dinfo->vsync.pan_display = 0;
- OUTREG(DSPABASE, dinfo->vsync.pan_offset);
- }
- wake_up_interruptible(>vsync.wait);
- handled = 1;
+ OUTREG16(IIR, tmp);
+ if (dinfo->vsync.pan_display) {
+ dinfo->vsync.pan_display = 0;
+ OUTREG(DSPABASE, dinfo->vsync.pan_offset);
}
+ dinfo->vsync.count++;
+ wake_up_interruptible(>vsync.wait);
+
spin_unlock(>int_lock);
- return IRQ_RETVAL(handled);
+ return IRQ_RETVAL(1);
}
-int
-intelfbhw_enable_irq(struct intelfb_info *dinfo, int reenable) {
-
+int intelfbhw_enable_irq(struct intelfb_info *dinfo)
+{
+ u16 tmp;
if (!test_and_set_bit(0, >irq_flags)) {
if (request_irq(dinfo->pdev->irq, intelfbhw_irq, IRQF_SHARED,
-"intelfb", dinfo)) {
+ "intelfb", dinfo)) {
clear_bit(0, >irq_flags);
return -EINVAL;
}
spin_lock_irq(>int_lock);
- OUTREG16(HWSTAM, 0xfffe);
- OUTREG16(IMR, 0x0);
- OUTREG16(IER, VSYNC_PIPE_A_INTERRUPT);
- spin_unlock_irq(>int_lock);
- } else if (reenable) {
- u16 ier;
-
+
[PATCH 2/4] Intel FB: obvious changes and corrections
Intel FB: obvious changes and corrections
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
--- a/drivers/video/intelfb/intelfb.h
+++ b/drivers/video/intelfb/intelfb.h
@@ -355,7 +355,10 @@ struct intelfb_info {
struct intelfb_output_rec output[MAX_OUTPUTS];
};
-#define IS_I9XX(dinfo) (((dinfo)->chipset == INTEL_915G)||(dinfo->chipset ==
INTEL_915GM)||((dinfo)->chipset == INTEL_945G)||(dinfo->chipset==INTEL_945GM))
+#define IS_I9XX(dinfo) (((dinfo)->chipset == INTEL_915G) ||\
+ ((dinfo)->chipset == INTEL_915GM) ||\
+ ((dinfo)->chipset == INTEL_945G) || \
+ ((dinfo)->chipset==INTEL_945GM))
#ifndef FBIO_WAITFORVSYNC
#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)
--- a/drivers/video/intelfb/intelfbhw.c
+++ b/drivers/video/intelfb/intelfbhw.c
@@ -434,14 +434,14 @@ void intelfbhw_setcolreg(struct intelfb_info *dinfo,
unsigned regno,
unsigned red, unsigned green, unsigned blue,
unsigned transp)
{
+ u32 palette_reg = (dinfo->pipe == PIPE_A) ?
+ PALETTE_A : PALETTE_B;
+
#if VERBOSE > 0
DBG_MSG("intelfbhw_setcolreg: %d: (%d, %d, %d)\n",
regno, red, green, blue);
#endif
- u32 palette_reg = (dinfo->pipe == PIPE_A) ?
- PALETTE_A : PALETTE_B;
-
OUTREG(palette_reg + (regno << 2),
(red << PALETTE_8_RED_SHIFT) |
(green << PALETTE_8_GREEN_SHIFT) |
@@ -1305,8 +1305,8 @@ int intelfbhw_program_mode(struct intelfb_info *dinfo,
count = 0;
do {
- tmp_val[count%3] = INREG(0x7);
- if ((tmp_val[0] == tmp_val[1]) && (tmp_val[1]==tmp_val[2]))
+ tmp_val[count % 3] = INREG(PIPEA_DSL);
+ if ((tmp_val[0] == tmp_val[1]) && (tmp_val[1] == tmp_val[2]))
break;
count++;
udelay(1);
@@ -2004,7 +2004,6 @@ intelfbhw_enable_irq(struct intelfb_info *dinfo, int
reenable) {
void
intelfbhw_disable_irq(struct intelfb_info *dinfo) {
- u16 tmp;
if (test_and_clear_bit(0, >irq_flags)) {
if (dinfo->vsync.pan_display) {
@@ -2016,8 +2015,7 @@ intelfbhw_disable_irq(struct intelfb_info *dinfo) {
OUTREG16(IMR, 0x);
OUTREG16(IER, 0x0);
- tmp = INREG16(IIR);
- OUTREG16(IIR, tmp);
+ OUTREG16(IIR, INREG16(IIR)); /* clear IRQ requests */
spin_unlock_irq(>int_lock);
free_irq(dinfo->pdev->irq, dinfo);
--- a/drivers/video/intelfb/intelfbhw.h
+++ b/drivers/video/intelfb/intelfbhw.h
@@ -93,7 +93,7 @@
#define IIR0x20A4
#define IMR0x20A8
#define VSYNC_PIPE_A_INTERRUPT (1 << 7)
-#define PIPE_A_EVENT_INTERRUPT (1 << 4)
+#define PIPE_A_EVENT_INTERRUPT (1 << 6)
#define VSYNC_PIPE_B_INTERRUPT (1 << 5)
#define PIPE_B_EVENT_INTERRUPT (1 << 4)
#define HOST_PORT_EVENT_INTERRUPT (1 << 3)
@@ -276,6 +276,8 @@
#define DVOB_SRCDIM0x61144
#define DVOC_SRCDIM0x61164
+#define PIPEA_DSL 0x7
+#define PIPEB_DSL 0x71000
#define PIPEACONF 0x70008
#define PIPEBCONF 0x71008
#define PIPECONF_ENABLE(1 << 31)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/4] Intel FB: whitespace, bracket and other clean-ups
Intel FB: whitespace, bracket and other clean-ups
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
--- a/drivers/video/intelfb/intelfb.h
+++ b/drivers/video/intelfb/intelfb.h
@@ -231,8 +231,8 @@ struct intelfb_hwstate {
struct intelfb_heap_data {
u32 physical;
u8 __iomem *virtual;
- u32 offset; // in GATT pages
- u32 size;// in bytes
+ u32 offset; /* in GATT pages */
+ u32 size; /* in bytes */
};
#ifdef CONFIG_FB_INTEL_I2C
@@ -270,9 +270,9 @@ struct intelfb_info {
struct intelfb_hwstate save_state;
/* agpgart structs */
- struct agp_memory *gtt_fb_mem; // use all stolen memory or vram
- struct agp_memory *gtt_ring_mem; // ring buffer
- struct agp_memory *gtt_cursor_mem; // hw cursor
+ struct agp_memory *gtt_fb_mem; /* use all stolen memory or vram */
+ struct agp_memory *gtt_ring_mem; /* ring buffer */
+ struct agp_memory *gtt_cursor_mem; /* hw cursor */
/* use a gart reserved fb mem */
u8 fbmem_gart;
@@ -346,7 +346,7 @@ struct intelfb_info {
/* driver registered */
int registered;
-
+
/* index into plls */
int pll_index;
--- a/drivers/video/intelfb/intelfb_i2c.c
+++ b/drivers/video/intelfb/intelfb_i2c.c
@@ -58,7 +58,8 @@ static void intelfb_gpio_setscl(void *data, int state)
struct intelfb_info *dinfo = chan->dinfo;
u32 val;
- OUTREG(chan->reg, (state ? SCL_VAL_OUT : 0) | SCL_DIR | SCL_DIR_MASK |
SCL_VAL_MASK);
+ OUTREG(chan->reg, (state ? SCL_VAL_OUT : 0) |
+ SCL_DIR | SCL_DIR_MASK | SCL_VAL_MASK);
val = INREG(chan->reg);
}
@@ -68,7 +69,8 @@ static void intelfb_gpio_setsda(void *data, int state)
struct intelfb_info *dinfo = chan->dinfo;
u32 val;
- OUTREG(chan->reg, (state ? SDA_VAL_OUT : 0) | SDA_DIR | SDA_DIR_MASK |
SDA_VAL_MASK);
+ OUTREG(chan->reg, (state ? SDA_VAL_OUT : 0) |
+ SDA_DIR | SDA_DIR_MASK | SDA_VAL_MASK);
val = INREG(chan->reg);
}
@@ -97,26 +99,26 @@ static int intelfb_gpio_getsda(void *data)
}
static int intelfb_setup_i2c_bus(struct intelfb_info *dinfo,
-struct
intelfb_i2c_chan *chan,
-const u32 reg,
const char *name)
+struct intelfb_i2c_chan *chan,
+const u32 reg, const char *name)
{
int rc;
- chan->dinfo = dinfo;
- chan->reg = reg;
+ chan->dinfo = dinfo;
+ chan->reg = reg;
snprintf(chan->adapter.name, sizeof(chan->adapter.name),
"intelfb %s", name);
- chan->adapter.owner = THIS_MODULE;
- chan->adapter.id= I2C_HW_B_INTELFB;
+ chan->adapter.owner = THIS_MODULE;
+ chan->adapter.id= I2C_HW_B_INTELFB;
chan->adapter.algo_data = >algo;
chan->adapter.dev.parent= >dinfo->pdev->dev;
- chan->algo.setsda = intelfb_gpio_setsda;
- chan->algo.setscl = intelfb_gpio_setscl;
- chan->algo.getsda = intelfb_gpio_getsda;
- chan->algo.getscl = intelfb_gpio_getscl;
- chan->algo.udelay = 40;
- chan->algo.timeout = 20;
- chan->algo.data = chan;
+ chan->algo.setsda = intelfb_gpio_setsda;
+ chan->algo.setscl = intelfb_gpio_setscl;
+ chan->algo.getsda = intelfb_gpio_getsda;
+ chan->algo.getscl = intelfb_gpio_getscl;
+ chan->algo.udelay = 40;
+ chan->algo.timeout = 20;
+ chan->algo.data = chan;
i2c_set_adapdata(>adapter, chan);
@@ -142,40 +144,44 @@ void intelfb_create_i2c_busses(struct intelfb_info *dinfo)
dinfo->output[i].type = INTELFB_OUTPUT_ANALOG;
/* setup the DDC bus for analog output */
- intelfb_setup_i2c_bus(dinfo, >output[i].ddc_bus, GPIOA,
"CRTDDC_A");
+ intelfb_setup_i2c_bus(dinfo, >output[i].ddc_bus, GPIOA,
+ "CRTDDC_A");
i++;
-/* need to add the output busses for each device
- - this function is very incomplete
- - i915GM has LVDS and TVOUT for example
-*/
-switch(dinfo->chipset) {
+ /* need to add the output busses for each device
+ - this function is very incomplete
+ - i915GM has LVDS and TVOUT for example
+ */
+ switch(dinfo->chipset) {
case INTEL_830M:
case INTEL_845G:
case INTEL_855GM:
[PATCH 0/4] Intel FB: cleanup and misc interlaced mode support
Hi,
I'll attach 4 patches for Intel FB (i830+) here:
1/4 - whitespace, bracket and other clean-ups (rather long)
working with kernel-style brackets instead of:
void
function_name (int arg) {
is a bit easier. I think it would be best to apply it in the
beginning of the "patch period" to avoid potential conflicts.
2/4 - obvious changes and corrections
3/4 - the chip adds two halflines automatically in interlaced mode,
we have to force the number of lines to be even
4/4 - allow odd- and even-field-first in interlaced modes, and
proper sync to vertical retrace. It enables video players
(got it working with MPlayer currently) to play perfect
field-synced stream to RGB-connected (VGA output) TV set.
This patch adds #define FB_VMODE_ODD_FLD_FIRST 4 in
include/linux/fb.h, to be able to force odd field first (analog
broadcast PAL and some PAL DVD discs use it) instead of even
field (bottom) first, as used by NTSC, DV PAL, some PAL
DVDs etc. Interlaced-only thing.
This change need a coresponding change in fbset and probably in
media players which want to set video mode themselves, I will
do the fbset part and maybe MPlayer's if the fb.h patch is ok.
All four patches change only files in drivers/video/intelfb/, except
patch 4/4 which also adds FB_VMODE_ODD_FLD_FIRST in include/linux/fb.h.
Tested on i915G in 1440x576 50 Hz (I) with PAL TV.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Unfortunate infinite make recursion
On Sat, Sep 22, 2007 at 10:40:02PM +0200, Sam Ravnborg wrote: > On Sat, Sep 22, 2007 at 05:42:52PM +0200, Oleg Verych wrote: > > * Sat, 22 Sep 2007 13:24:32 +0200 (CEST) > > [] > > > The make O=$PWD truncates the Makefile, making it necessary to run `git > > > checkout Makefile` - should you have git; or reextract the tarball > > > (should you /still/ have it). Well, can we catch this case somehow? > > > > Read-only source-tree for kbuild user, end of question. By current kbuild > > one can garbage source by various means. Read-write for quilt, git and > > editor users. > > Please Oleg. > You know very well that most people will not have their kernel src RO. Sure, if it will be not comfortable. But if kbuild deals with this transparently, it must be OK. Brokenness due to binutils, kbuild, root user bugs won't garbage source. Only thing to ask from experienced users *and* kernel developers, is `useradd kbuild`, everything else will not bother anybody. I just express my vision, of course. But see, i can't play with kernel sources error-free now. If i type some `make` somewhere in obj or src tree, i need to know, that vanilla source stays so in any circumstances. Currently it's not. It is about making things in order on my working place (not looking to be in order, though :). Not thinking every time, if something fscked sources, saves my and time of diff/patch. Experimenting/testing/finding fixes with small amount of in-development sources in obj tree, also very helpful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On 9/21/07, Huang, Ying <[EMAIL PROTECTED]> wrote: > This is fairly simple in fact. For example, you can specify the > bdev/sectors in kernel command line when do kexec load "kexec -l <...> > --append='...'", then the image writing system can get it through > "cat /proc/cmdline". I hope you take into account encrypted swap configuration. Currently all three suspend implementations support using encrypted swap in order to suspend/resume. A configuration which forces the user to remap encryption on the kexec kernel during suspend is not valid. Best Regards, Alon Bar-Lev. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory allocation problem with 2.6.22 after suspend/resume cycle
On Saturday, 22 September 2007 17:41, Christian P. Schmidt wrote: > Hi all, > > I'm having a strange problem, of course not reproducible. Sometimes > after a suspend (to ram) and resume cycle, the kernel will try to free > all memory. This means, all running applications are flushed to swap (as > long as it is available), caches and buffers stay at around 15MB each. > > The following video (traded quality for bandwidth) shows what happens on > the way from no swap to "swapon -a" (that's the unreadable thing in the > small shell): http://digadd.de/swapping.avi > > The system: > Linux dnnote 2.6.22.5 #1 SMP PREEMPT Sat Aug 25 18:39:21 AST 2007 x86_64 > Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz GenuineIntel GNU/Linux Are you using an ATI binary graphics driver? > A 32bit Kernel is unable to suspend/resume at all. No idea why. dmesg > shows nothing, logs show nothing. Any ideas for debugging are welcome. Well, that's interesting. Can you try in the minimal configuration (ie. boot with init=/bin/bash, mount /sys, mount /proc and run "echo mem > /sys/power/disk)? 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: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Saturday, 22 September 2007 20:00, Kyle Moffett wrote: > On Sep 22, 2007, at 06:34:17, Rafael J. Wysocki wrote: > > On Saturday, 22 September 2007 01:19, Kyle Moffett wrote: > >> On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: > >>> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > The ACPI platform firmware is allowed to preserve information > accross the hibernation-resume cycle, so this need not be the same. > >>> > >>> All of my comments related to the case where S4 is not being used > >>> (instead the system is just powered off normally), and a boot > >>> kernel that does not initialize ACPI is used. In that case, the > >>> ACPI platform firmware should not be able to distinguish a normal > >>> boot from a resume from hibernation. > >> > >> I think that in order for this to work, there would need to be > >> some ABI whereby the resume-ing kernel can pass its entire ACPI > >> state and a bunch of other ACPI-related device details to the > >> resume-ed kernel, which I believe it does not do at the moment. > > > > In fact we don't need to do this. > > > > The solution is not to touch ACPI in the boot kernel (ie. the one > > that loads the image) and pass control to the image kernel. This > > is how it's supposed to work according to the spec, more or less > > (well, there are some ugly details that need handling, like the > > restoration of the NVS area). > > First of all, we will need to make the resumed kernel throw away > *ALL* of its ACPI state on S5 and completely reinitialize ACPI as > though it was booting for the first time on resume. Yes, if we entered S5 in the last step of the hibernation sequence, the right thing to do would be to make the resumed kernel reinitialize ACPI from scratch. > From what I can tell, we "throw away" all the ACPI state in the boot kernel > and reinitialize it there, but then the reinitialized state is > overwritten with the resumed kernel's state and the two don't always > happen to be the same. (Like if a battery got replaced or AC status > changed). Usually it goes like that. Still, you can pass "acpi=off" to the boot kernel, in which case it won't reinitialize ACPI. > Umm, I don't see how that can possibly work properly. For a laptop, > for example, the restore kernel will need to access the disk, the LCD > display, and possibly the AC/battery and current CPU frequency. From > what I understand of ACPI, both of the former may need ACPI code to > operate properly (Isn't there an ATA taskfile object of some kind?) > and the latter two almost definitely need ACPI. Well, this is not the case on any systems that I have access to, including two quite modern notebooks. Apparently, everything works without ACPI on these machines. Besides, in theory, it's possible to use an "intelligent" boot loader to read the hibernation image and that doesn't need ACPI for anything. > Ergo the boot kernel may need to initialize and use ACPI just to run an ATA > taskfile so it can read from the HDD efficiently. It is possible, but I haven't seen that yet. > >> I believe that what causes problems is the ACPI state data that > >> the kernel stores is *different* between identical sequential > >> boots, especially when you add/remove/replace batteries, AC, etc. > > > > Rather the ACPI state data that the platform firmware stores may be > > different, depending on whether you enter S4 or S5 during "power > > off" and that determines the interactions between the kernel and > > the firmware after the next boot. > > That's not what he was talking about. The problem discussed was: >(A) You hibernate your box, entering S5 (IE: power off) >(B) You resume the box and the boot kernel inits all the ACPI stuff. >(C) The boot kernel's ACPI state is completely replaced by the > resumed kernel's state. >(D) Hardware stops working mysteriously because of ACPI problems. > > The only possible conclusion is that the state between the boot > kernel and the resume kernel was *different* and so the device failed > because the ACPI state in the resume kernel doesn't match the actual > state of the hardware. I think it's even more complicated. The ACPI state of the resumed kernel has to match whatever is preserved by the platform. Well, my impression is that our current ACPI resume code actually expects the platform to preserve something and if that's missing the devices in question are not handled properly. If that really is the case, there is the question whether we can do something about it in a reasonable way and I can't answer it right now. Besides, I really think that we should use the ACPI S4 state, because machines generally support that. 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
[RFC] IRQ sharing for PCI parport cards
Hello,
currently, the parport_pc driver doesn't use IRQs automatically for
PCI devices. However, why is it not possible? It's no problem to find
out the corresponding IRQ, and it should also be possible to use IRQ
sharing. The following patch implements this.
Could somebody tell me what's wrong with that approach? _If_ it would
be that simple, I'm sure that sombody would have implemented this
already.
At least it works here.
Thanks,
Bernhard
---
drivers/parport/parport_cs.c |2 +-
drivers/parport/parport_pc.c | 39 +--
drivers/parport/parport_serial.c |2 +-
include/linux/parport_pc.h |6 +-
4 files changed, 32 insertions(+), 17 deletions(-)
--- a/drivers/parport/parport_cs.c
+++ b/drivers/parport/parport_cs.c
@@ -200,7 +200,7 @@ static int parport_config(struct pcmcia_
p = parport_pc_probe_port(link->io.BasePort1, link->io.BasePort2,
link->irq.AssignedIRQ, PARPORT_DMA_NONE,
- >dev);
+ >dev, 0);
if (p == NULL) {
printk(KERN_NOTICE "parport_cs: parport_pc_probe_port() at "
"0x%3x, irq %u failed\n", link->io.BasePort1,
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -274,8 +274,14 @@ static int clear_epp_timeout(struct parp
static irqreturn_t parport_pc_interrupt(int irq, void *dev_id)
{
- parport_generic_irq(irq, (struct parport *) dev_id);
- /* FIXME! Was it really ours? */
+ struct parport *pb = dev_id;
+
+ /* for shared interrupt handlers */
+ if (parport_pc_read_status(pb) & (1<<2))
+ return IRQ_NONE;
+
+ parport_generic_irq(irq, pb);
+
return IRQ_HANDLED;
}
@@ -2149,7 +2155,8 @@ static DEFINE_SPINLOCK(ports_lock);
struct parport *parport_pc_probe_port (unsigned long int base,
unsigned long int base_hi,
int irq, int dma,
- struct device *dev)
+ struct device *dev,
+ unsigned int flags)
{
struct parport_pc_private *priv;
struct parport_operations *ops;
@@ -2301,8 +2308,10 @@ struct parport *parport_pc_probe_port (u
EPP_res = NULL;
}
if (p->irq != PARPORT_IRQ_NONE) {
+ unsigned int irq_flags = flags & PARPORT_PC_SHARE_IRQ
+ ? IRQF_SHARED : 0;
if (request_irq (p->irq, parport_pc_interrupt,
-0, p->name, p)) {
+ irq_flags, p->name, p)) {
printk (KERN_WARNING "%s: irq %d in use, "
"resorting to polled operation\n",
p->name, p->irq);
@@ -2506,7 +2515,7 @@ static int __devinit sio_ite_8872_probe
*/
release_resource(base_res);
if (parport_pc_probe_port (ite8872_lpt, ite8872_lpthi,
- irq, PARPORT_DMA_NONE, >dev)) {
+ irq, PARPORT_DMA_NONE, >dev, 0)) {
printk (KERN_INFO
"parport_pc: ITE 8872 parallel port: io=0x%X",
ite8872_lpt);
@@ -2689,7 +2698,7 @@ static int __devinit sio_via_probe (stru
}
/* finally, do the probe with values obtained */
- if (parport_pc_probe_port (port1, port2, irq, dma, >dev)) {
+ if (parport_pc_probe_port (port1, port2, irq, dma, >dev, 0)) {
printk (KERN_INFO
"parport_pc: VIA parallel port: io=0x%X", port1);
if (irq != PARPORT_IRQ_NONE)
@@ -2980,14 +2989,16 @@ static int parport_pc_pci_probe (struct
io_lo += hi; /* Reinterpret the meaning of
"hi" as an offset (see SYBA
def.) */
- /* TODO: test if sharing interrupts works */
printk (KERN_DEBUG "PCI parallel port detected: %04x:%04x, "
"I/O at %#lx(%#lx)\n",
parport_pc_pci_tbl[i + last_sio].vendor,
parport_pc_pci_tbl[i + last_sio].device, io_lo, io_hi);
+ /* according to PCI spec, IRQ sharing must be supported */
data->ports[count] =
- parport_pc_probe_port (io_lo, io_hi, PARPORT_IRQ_NONE,
- PARPORT_DMA_NONE, >dev);
+ parport_pc_probe_port (io_lo, io_hi, dev->irq,
+ PARPORT_DMA_NONE,
+ >dev,
+ PARPORT_PC_SHARE_IRQ);
if (data->ports[count])
count++;
}
@@ -3095,7 +3106,7 @@ static int
Re: [PATCH] [9/50] i386: validate against ACPI motherboard resources
Yinghai Lu wrote: On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote: Thomas Gleixner wrote: On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote: Yinghai Lu wrote: No! MMCONFIG will not work with acpi=off any more. I don't think this is unreasonable. The ACPI MCFG table is how we are supposed to learn about the area in the first place. If we can't get the table location via an approved mechanism, and can't validate it doesn't overlap with another memory reservation or something, I really don't think we should be using it. We all know how correct ACPI tables are. Specifications are nice, reality tells a different story. MMCONFIG can't be used without ACPI in any case unless we know where the table is using chipset-specific knowledge (i.e. reading the registers directly). Doing that without being told that this area is really intended to be used, via the ACPI table, is dangerous, i.e. we don't necessarily know if the MMCONFIG is broken on the platform in some way we can't detect. the BIOS get these info from the chipset too. for AMD Fam 10h opteron, we can read that MSR for MMCONFIG base. I don't think it's much of an issue anyway - the chances that somebody will want to run without ACPI on a system with MCFG are pretty low given that you'll end up losing a bunch of functionality (not least of which is multi-cores). acpi=off is an often used debug switch and it _is_ quite useful. Taking away debug functionality is not a good idea. If someone has to turn ACPI off, disabling MMCONFIG is probably the least of their worries.. MMCONFIG has nothing to do ACPI..., just becase MCFG in the ACPI, we must use ACPI for MMCONFIG? config PCI_MMCONFIG bool depends on PCI && ACPI && (PCI_GOMMCONFIG || PCI_GOANY) default y We already depend on ACPI for MMCONFIG support at compile time. This patch does not change that. We could conceivably skip the validation if ACPI was disabled, though this would only make a difference in the few cases where we can detect the MMCONFIG area without it (looks like currently only Intel E7520 and 945, at least in mainline). For AMD Fam 10h opteron, because using MMCONFIG need via %eax, so BIOS will stilll stay with MCFG entry for MCP55 SB to not break other os..., then you can not access ext config space for NB... with enabling MMCONFIG in NB, and read NNCONFIG BASE from NB,( via pci_mmcfg_check_hostbridge) that we get full MMCONFIG access for NB... Anyway this patch alter the feature... BTW if you trust MCFG in ACPI so much, why do you need to bother to verify that in DSDT... One reason is that Windows pre-Vista does not use the MCFG table, it does use the ACPI reserved resources. Since the board/system manufacturers have been testing against Windows, the resource reservations should be more likely correct than the MCFG table which was not used until Vista came along. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: A revised timerfd API
On Sat, 2007-09-22 at 14:07 -0700, Davide Libenzi wrote: > On Sat, 22 Sep 2007, Michael Kerrisk wrote: > > > So I'm inclined to implement option (b), unless someone has strong > > objections. Davide, could I persuade you to help? > > I guess I better do, otherwise you'll continue to stress me ;) > > int timerfd_create(int clockid); > int timerfd_settime(int ufd, int flags, > const struct itimerspec *utmr, > struct itimerspec *otmr); > int timerfd_gettime(int ufd, struct itimerspec *otmr); > > Patch below. Builds, not tested yet (you need to remove the "broken" > status from CONFIG_TIMERFD in case you want to test - and plug the new > syscall to arch/xxx). > May that work for you? > Thomas-san, hrtimer_try_to_cancel() does not touch ->expires and I assume > it'll never do, granted? Davide-san, I have no intention to change that, but remember there is this file "Documentation/stable_api_nonsense.txt" :) tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Unfortunate infinite make recursion
Jan Engelhardt <[EMAIL PROTECTED]> wrote: > You can cause a recursion in kbuild/make with the following: > > make O=$PWD kernel/time.o > make mrproper > > Of course no one would use O=$PWD (that's just the testcase), > but this happened too often: > > /ws/linux/linux-2.6.23$ make O=/ws/linux/linux-2.6.23 kernel/time.o > (Oops - should have been O=/ws/linux/obj-2.6.23!) > > The make O=$PWD truncates the Makefile, making it necessary to run `git > checkout Makefile` - should you have git; or reextract the tarball > (should you /still/ have it). Well, can we catch this case somehow? You can test for the existence of MAINTAINERS in the build dir and abort if it's there. -- My computer isn't that nervous...it's just a bit ANSI. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [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: RFC: A revised timerfd API
On Sat, 22 Sep 2007, Michael Kerrisk wrote:
> So I'm inclined to implement option (b), unless someone has strong
> objections. Davide, could I persuade you to help?
I guess I better do, otherwise you'll continue to stress me ;)
int timerfd_create(int clockid);
int timerfd_settime(int ufd, int flags,
const struct itimerspec *utmr,
struct itimerspec *otmr);
int timerfd_gettime(int ufd, struct itimerspec *otmr);
Patch below. Builds, not tested yet (you need to remove the "broken"
status from CONFIG_TIMERFD in case you want to test - and plug the new
syscall to arch/xxx).
May that work for you?
Thomas-san, hrtimer_try_to_cancel() does not touch ->expires and I assume
it'll never do, granted?
- Davide
---
fs/compat.c | 32 --
fs/timerfd.c | 144 +--
include/linux/compat.h |7 +-
include/linux/syscalls.h |7 +-
4 files changed, 126 insertions(+), 64 deletions(-)
Index: linux-2.6.mod/fs/timerfd.c
===
--- linux-2.6.mod.orig/fs/timerfd.c 2007-09-22 12:22:19.0 -0700
+++ linux-2.6.mod/fs/timerfd.c 2007-09-22 13:21:21.0 -0700
@@ -23,6 +23,7 @@
struct timerfd_ctx {
struct hrtimer tmr;
+ int clockid;
ktime_t tintv;
wait_queue_head_t wqh;
int expired;
@@ -46,7 +47,7 @@
return HRTIMER_NORESTART;
}
-static void timerfd_setup(struct timerfd_ctx *ctx, int clockid, int flags,
+static void timerfd_setup(struct timerfd_ctx *ctx, int flags,
const struct itimerspec *ktmr)
{
enum hrtimer_mode htmode;
@@ -58,7 +59,7 @@
texp = timespec_to_ktime(ktmr->it_value);
ctx->expired = 0;
ctx->tintv = timespec_to_ktime(ktmr->it_interval);
- hrtimer_init(>tmr, clockid, htmode);
+ hrtimer_init(>tmr, ctx->clockid, htmode);
ctx->tmr.expires = texp;
ctx->tmr.function = timerfd_tmrproc;
if (texp.tv64 != 0)
@@ -150,76 +151,109 @@
.read = timerfd_read,
};
-asmlinkage long sys_timerfd(int ufd, int clockid, int flags,
- const struct itimerspec __user *utmr)
+asmlinkage long sys_timerfd_create(int clockid)
{
- 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;
+
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ init_waitqueue_head(>wqh);
+ ctx->clockid = clockid;
+
+ error = anon_inode_getfd(, , , "[timerfd]",
+_fops, ctx);
+ if (error)
+ goto err_kfree_ctx;
+
+ return ufd;
+
+err_kfree_ctx:
+ kfree(ctx);
+ return error;
+}
+
+asmlinkage long sys_timerfd_settime(int ufd, int flags,
+ const struct itimerspec __user *utmr,
+ struct itimerspec __user *otmr)
+{
+ struct file *file;
+ struct timerfd_ctx *ctx;
+ struct itimerspec ktmr, kotmr;
+
+ if (copy_from_user(, utmr, sizeof(ktmr)))
+ return -EFAULT;
+
if (!timespec_valid(_value) ||
!timespec_valid(_interval))
return -EINVAL;
- if (ufd == -1) {
- ctx = kmalloc(sizeof(*ctx), GFP_KERNEL);
- if (!ctx)
- return -ENOMEM;
-
- init_waitqueue_head(>wqh);
-
- timerfd_setup(ctx, clockid, flags, );
-
- /*
-* When we call this, the initialization must be complete, since
-* anon_inode_getfd() will install the fd.
-*/
- error = anon_inode_getfd(, , , "[timerfd]",
-_fops, ctx);
- if (error)
- goto err_tmrcancel;
- } else {
- file = fget(ufd);
- if (!file)
- return -EBADF;
- ctx = file->private_data;
- if (file->f_op != _fops) {
- fput(file);
- return -EINVAL;
- }
- /*
-* We need to stop the existing timer before reprogramming
-* it to the new values.
-*/
- for (;;) {
- spin_lock_irq(>wqh.lock);
- if (hrtimer_try_to_cancel(>tmr) >= 0)
- break;
- spin_unlock_irq(>wqh.lock);
- cpu_relax();
- }
- /*
-* Re-program the
Re: [PATCH] [9/50] i386: validate against ACPI motherboard resources
Yinghai Lu wrote: >>> We all know how correct ACPI tables are. Specifications are nice, >>> reality tells a different story. >> MMCONFIG can't be used without ACPI in any case unless we know where the >> table is using chipset-specific knowledge (i.e. reading the registers >> directly). Doing that without being told that this area is really >> intended to be used, via the ACPI table, is dangerous, i.e. we don't >> necessarily know if the MMCONFIG is broken on the platform in some way >> we can't detect. > > the BIOS get these info from the chipset too. > for AMD Fam 10h opteron, we can read that MSR for MMCONFIG base. I think he's saying we don't know a safe place to park the MMCONFIG area if we don't have this information. However, this applies to *any* allocation of address space, which we do all the time, so although a valid argument this has been decided already many times over. -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/
Re: [PATCH] usb-gadget-ether: Prevent oops caused by error interrupt race -V2 (comments update)
> Sigh. I need a real deep look inside that code to understand, why
> tx_reqs is not a requestlist but a freelist. Very intuitive naming :)
It *is* a list of requests: free ones -- the only kind this level of
driver is allowed to remember! ;)
Yeah, I had to go back and read the driver again before I understood
just what problem this patch was trying to fix. Which is why I wanted
to make sure the mismatch between comments and contents was resolved.
- Dave
== CUT HERE
From: Benedikt Spranger <[EMAIL PROTECTED]>
This patch fixes a longstanding race in the Ethernet gadget driver,
which can cause an oops on device disconnect. The fix is just to
make the TX path check whether its freelist is empty. That check
is otherwise not necessary, since the queue is always stopped when
that list empties (and restarted when request completion puts an
entry back on that freelist).
The race window starts when the network code decides to transmit a
packet, and ends when hard_start_xmit() grabs the freelist lock.
When disconnect() is called inside that window, it shuts down the
TX queue and breaks the otherwise-solid assumption that packets are
never sent through a TX queue that's stopped.
Signed-off-by: Benedikt Spranger <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -1989,8 +1989,20 @@ static int eth_start_xmit (struct sk_buff *skb, struct
net_device *net)
}
spin_lock_irqsave(>req_lock, flags);
+ /*
+* this freelist can be empty if an interrupt triggered disconnect()
+* and reconfigured the gadget (shutting down this queue) after the
+* network stack decided to xmit but before we got the spinlock.
+*/
+ if (list_empty(>tx_reqs)) {
+ spin_unlock_irqrestore(>req_lock, flags);
+ return 1;
+ }
+
req = container_of (dev->tx_reqs.next, struct usb_request, list);
list_del (>list);
+
+ /* temporarily stop TX queue when the freelist empties */
if (list_empty (>tx_reqs))
netif_stop_queue (net);
spin_unlock_irqrestore(>req_lock, flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Unfortunate infinite make recursion
On Sat, Sep 22, 2007 at 01:24:32PM +0200, Jan Engelhardt wrote: > Hi, > > > You can cause a recursion in kbuild/make with the following: > > make O=$PWD kernel/time.o > make mrproper > > Of course no one would use O=$PWD (that's just the testcase), > but this happened too often: > > /ws/linux/linux-2.6.23$ make O=/ws/linux/linux-2.6.23 kernel/time.o > (Oops - should have been O=/ws/linux/obj-2.6.23!) > > The make O=$PWD truncates the Makefile, making it necessary to run `git > checkout Makefile` - should you have git; or reextract the tarball > (should you /still/ have it). Well, can we catch this case somehow? Does the following patch fix it at your end? Seems to work for me. Sam diff --git a/Makefile b/Makefile index 6708e41..f787b05 100644 --- a/Makefile +++ b/Makefile @@ -115,7 +115,9 @@ saved-output := $(KBUILD_OUTPUT) KBUILD_OUTPUT := $(shell cd $(KBUILD_OUTPUT) && /bin/pwd) $(if $(KBUILD_OUTPUT),, \ $(error output directory "$(saved-output)" does not exist)) - +# Check the OUTPUT directory is not the same as where we have kernel src +$(if $(filter-out $(KBUILD_OUTPUT),$(shell /bin/pwd)),, \ + $(error Output directory (O=...) specify kernel src dir)) PHONY += $(MAKECMDGOALS) $(filter-out _all,$(MAKECMDGOALS)) _all: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [9/50] i386: validate against ACPI motherboard resources
On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote: > Yinghai Lu wrote: > > No! > > > > MMCONFIG will not work with acpi=off any more. > > I don't think this is unreasonable. The ACPI MCFG table is how we are > supposed to learn about the area in the first place. If we can't get the > table location via an approved mechanism, and can't validate it doesn't > overlap with another memory reservation or something, I really don't > think we should be using it. > > I don't think it's much of an issue anyway - the chances that somebody > will want to run without ACPI on a system with MCFG are pretty low given > that you'll end up losing a bunch of functionality (not least of which > is multi-cores). with acpi=off, that we do lose some features including acpi hotplug and power management feature... but we don't lose anything about numa ( multi-cores...) and bus-numa... (we get these info from NB pci conf for AMD rev C, rev E, rev F, and Fam 10 opteron)... Finally we lose bugs introduced by ACPI code ... 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: [PATCH] [9/50] i386: validate against ACPI motherboard resources
On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote: > Thomas Gleixner wrote: > > On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote: > >> Yinghai Lu wrote: > >>> No! > >>> > >>> MMCONFIG will not work with acpi=off any more. > >> I don't think this is unreasonable. The ACPI MCFG table is how we are > >> supposed to learn about the area in the first place. If we can't get the > >> table location via an approved mechanism, and can't validate it doesn't > >> overlap with another memory reservation or something, I really don't > >> think we should be using it. > > > > We all know how correct ACPI tables are. Specifications are nice, > > reality tells a different story. > > MMCONFIG can't be used without ACPI in any case unless we know where the > table is using chipset-specific knowledge (i.e. reading the registers > directly). Doing that without being told that this area is really > intended to be used, via the ACPI table, is dangerous, i.e. we don't > necessarily know if the MMCONFIG is broken on the platform in some way > we can't detect. the BIOS get these info from the chipset too. for AMD Fam 10h opteron, we can read that MSR for MMCONFIG base. > > > > >> I don't think it's much of an issue anyway - the chances that somebody > >> will want to run without ACPI on a system with MCFG are pretty low given > >> that you'll end up losing a bunch of functionality (not least of which > >> is multi-cores). > > > > acpi=off is an often used debug switch and it _is_ quite useful. Taking > > away debug functionality is not a good idea. > > If someone has to turn ACPI off, disabling MMCONFIG is probably the > least of their worries.. MMCONFIG has nothing to do ACPI..., just becase MCFG in the ACPI, we must use ACPI for MMCONFIG? For AMD Fam 10h opteron, because using MMCONFIG need via %eax, so BIOS will stilll stay with MCFG entry for MCP55 SB to not break other os..., then you can not access ext config space for NB... with enabling MMCONFIG in NB, and read NNCONFIG BASE from NB,( via pci_mmcfg_check_hostbridge) that we get full MMCONFIG access for NB... Anyway this patch alter the feature... BTW if you trust MCFG in ACPI so much, why do you need to bother to verify that in DSDT... 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: Unfortunate infinite make recursion
On Sat, Sep 22, 2007 at 05:42:52PM +0200, Oleg Verych wrote: > * Sat, 22 Sep 2007 13:24:32 +0200 (CEST) > [] > > The make O=$PWD truncates the Makefile, making it necessary to run `git > > checkout Makefile` - should you have git; or reextract the tarball > > (should you /still/ have it). Well, can we catch this case somehow? > > Read-only source-tree for kbuild user, end of question. By current kbuild > one can garbage source by various means. Read-write for quilt, git and > editor users. Please Oleg. You know very well that most people will not have their kernel src RO. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: memset as memzero
22-09-2007, Bernd Eckenfels: > In article <[EMAIL PROTECTED]> you wrote: >> it doesn't add value memset with a constant 0 is just as fast >> (since the compiler knows it's 0) than any wrapper around it, and the >> syntax around it is otherwise the same. linux/arch/x86_64/lib/memset.S isn't file for compile, but for assembler, isn't it? Removing argument processing will have size effect. > it would however allow easier changing if you need to add a page cleaning > system (for example new architecture which has support for it). [] > On the other hand, is memset used for anything else than zero filling > or redzone "filling"? There are non zero ones (not sure what redzone is, though). > Gruss > Bernd (Here are reply-to-all people, BTW) _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] usb-gadget-ether: Prevent oops caused by error interrupt race -V2 (comments update)
On Sat, 2007-09-22 at 13:14 -0700, David Brownell wrote:
> How's this? Note that the queue should already have been stopped,
> so I removed what should be an extra call (as well as fixing the
> comments).
Yeah, stop queue should be not necessary.
> - Dave
>
>
> From: Thomas Gleixner <[EMAIL PROTECTED]>
Please change to:
From: Benedikt Spranger <[EMAIL PROTECTED]>
He did all the grump work of figuring out what's going wrong. I was just
the messenger.
> This patch fixes a longstanding race in the Ethernet gadget driver,
> which can cause an oops on device disconnect. The fix is just to
> make the TX path check whether its freelist is empty. That check
> is otherwise not necessary, since the queue is always stopped when
> that list empties (and restarted when request completion puts an
> entry back on that freelist).
Sigh. I need a real deep look inside that code to understand, why
tx_reqs is not a requestlist but a freelist. Very intuitive naming :)
> The race window starts when the network code decides to transmit a
> packet, and ends when hard_start_xmit() grabs the freelist lock.
> If disconnect() is called inside that window, it shuts down the
> TX queue and breaks the otherwise-solid assumption that packets are
> never sent when the TX queue is stopped.
Please add our signed offs as well
Signed-off-by: Benedikt Spranger <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Thanks,
tglx
> --- a/drivers/usb/gadget/ether.c
> +++ b/drivers/usb/gadget/ether.c
> @@ -1989,8 +1989,20 @@ static int eth_start_xmit (struct sk_buff *skb, struct
> net_device *net)
> }
>
> spin_lock_irqsave(>req_lock, flags);
> + /*
> + * the freelist can be empty if an interrupt triggered disconnect()
> + * and reconfigured the gadget (shutting down this queue) after the
> + * network stack decided to xmit but before we got the spinlock.
> + */
> + if (list_empty(>tx_reqs)) {
> + spin_unlock_irqrestore(>req_lock, flags);
> + return 1;
> + }
> +
> req = container_of (dev->tx_reqs.next, struct usb_request, list);
> list_del (>list);
> +
> + /* temporarily stop TX queue when the freelist empties */
> if (list_empty (>tx_reqs))
> netif_stop_queue (net);
> spin_unlock_irqrestore(>req_lock, flags);
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Should parent's WIFSIGNALED(siginfo->si_status) be true EVEN IF the SIGNAL was caught by the child?
On Saturday 22 September 2007 11:49:09 Michael Kerrisk wrote:
> John,
>
...snip...
>
> If the child terminated by calling exit(), regardless of whether it
> was done from inside a signal handler, then WIFEXITED() should test
> true, but WIFSIGNALED() will not. If you are seeing otherwise, then
> show a *short* program that demonstrates the behavior. (But it seems
> unlikely that there would be a kernel bug on this point, so do check
> your program carefully!)
Attached is a (somewhat) short program that demonstates the behavior. I
simply compile it with 'make sigtest'.
My observed behavior is:
$ ./sigtest
sigtest started
child1 started
child2 started
selecting...
sigCaught: 3366 receieved signal 15
sigtest 3366 exiting
sigChld: 3365 receieved signal 17
sigChld: 3365 child 3366 WIFEXITED with childStat 15
sigChld: 3365 child 3366 WIFSIGNALED with si_status 15
select error: Interrupted system call
selecting...
sigCaught: 3367 receieved signal 15
sigtest 3367 exiting
sigChld: 3365 receieved signal 17
sigChld: 3365 child 3367 WIFEXITED with childStat 15
sigChld: 3365 child 3367 WIFSIGNALED with si_status 15
select error: Interrupted system call
selecting...
sigCaught: 3365 receieved signal 15
sigtest 3365 exiting
$
To get this output, I ran, from another shell, the following sequence:
$ ps -eaf | grep sigtest
zoltan3365 2307 0 13:04 pts/000:00:00 ./sigtest
zoltan3366 3365 98 13:04 pts/000:00:06 ./sigtest
zoltan3367 3365 98 13:04 pts/000:00:06 ./sigtest
$ kill -SIGTERM 3366
$ kill -SIGTERM 3367
$ kill -SIGTERM 3365
That's it. What I find odd is that the wait_pid() status and the
si_status are the same for both a WIFEXITED and a WIFSIGNALED, which
should be impossible, if I read the documentation right.
Thanks for your responses,
John
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define SER_PORT_ID 1234 /* The server's port */
static int child;/* child = 0, parent != 0 */
static void child1(void);
static void child2(void);
static void sigChld(int signum, siginfo_t * siginfo, void * ucontext);
static void sigCaught(int signum, siginfo_t * siginfo, void * ucontext);
static void setupEnv(void);
static void serverLoop(void);
static void processConnect(int csfd);
static void sigtestExit();
/**
* main:
* @argc: The count of command line data
* @argv: The array of command line strings
*
* The entry point of the executable.
*/
int
main(int argc, char * argv[])
{
setupEnv();
/*
* spawn two child processes so they (the children) can be sent SIGNAL's
* and the behaviour can be observed...
*/
if ((child = fork()) < 0)/* fork error */
{
perror("Child1 could not be created");
exit(1);
}
else
if (child == 0) /* In child */
{
child1();/* never returns... */
}
if ((child = fork()) < 0)/* fork error */
{
perror("Monitor child could not be created");
exit(1);
}
else
if (child == 0) /* In child */
{
child2();/* never returns... */
}
serverLoop();/* Never returns */
return 0;
}
/**
* child1:
*
* This is the first child.
*/
static void
child1(void)
{
printf("child1 started\n");
for ( ; ; );
}
/**
* child2:
*
* This is the second child.
*/
static void
child2(void)
{
printf("child2 started\n");
for ( ; ; );
}
/**
* sigChild:
* @signum: The signal that got us here.
* @siginfo: Additional data associated with the signal.
* @ucontext: Pointer to ucontext_t struct. Unused here.
*
* Signal handler for catching SIGCHLD. Is re-entrant...
*/
static void
sigChld(int signum, siginfo_t * siginfo, void * ucontext)
{
int childStat;
printf("sigChld: %d receieved signal %d\n", getpid(), signum);
if (signum != SIGCHLD) /* technically can't happen here... */
return; /* but ignore it if it does */
waitpid(siginfo->si_pid, , 0); /* orderly child shutdown... */
/*
* These next 4 if blocks are where it gets interesting...this I believe
* demonstrates the inconsistency.
*/
if (WIFEXITED(childStat))
printf("sigChld: %d child %d WIFEXITED with childStat %d\n",
getpid(), siginfo->si_pid, WEXITSTATUS(childStat));
if (WIFEXITED(siginfo->si_status))
printf("sigChld: %d child %d WIFEXITED with si_status %d\n",
getpid(), siginfo->si_pid, WEXITSTATUS(siginfo->si_status));
if (WIFSIGNALED(childStat))
{
printf("sigChld: %d child %d WIFSIGNALED with childStat %d\n",
getpid(), siginfo->si_pid, WTERMSIG(childStat));
}
if
Re: [PATCH] usb-gadget-ether: Prevent oops caused by error interrupt race -V2 (comments update)
How's this? Note that the queue should already have been stopped,
so I removed what should be an extra call (as well as fixing the
comments).
- Dave
From: Thomas Gleixner <[EMAIL PROTECTED]>
This patch fixes a longstanding race in the Ethernet gadget driver,
which can cause an oops on device disconnect. The fix is just to
make the TX path check whether its freelist is empty. That check
is otherwise not necessary, since the queue is always stopped when
that list empties (and restarted when request completion puts an
entry back on that freelist).
The race window starts when the network code decides to transmit a
packet, and ends when hard_start_xmit() grabs the freelist lock.
If disconnect() is called inside that window, it shuts down the
TX queue and breaks the otherwise-solid assumption that packets are
never sent when the TX queue is stopped.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -1989,8 +1989,20 @@ static int eth_start_xmit (struct sk_buff *skb, struct
net_device *net)
}
spin_lock_irqsave(>req_lock, flags);
+ /*
+* the freelist can be empty if an interrupt triggered disconnect()
+* and reconfigured the gadget (shutting down this queue) after the
+* network stack decided to xmit but before we got the spinlock.
+*/
+ if (list_empty(>tx_reqs)) {
+ spin_unlock_irqrestore(>req_lock, flags);
+ return 1;
+ }
+
req = container_of (dev->tx_reqs.next, struct usb_request, list);
list_del (>list);
+
+ /* temporarily stop TX queue when the freelist empties */
if (list_empty (>tx_reqs))
netif_stop_queue (net);
spin_unlock_irqrestore(>req_lock, flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB autosuspend and turning of usb pendrive leds
On Sat, 22 Sep 2007, Hans de Goede wrote: > >> Now call me naive, but I would expect a mass-storage devices with no > >> partitions mounted to autosuspend when autosuspend is enabled for that > >> device. > > > > Yes, that is naive. The driver has no way to tell whether or not any > > partitions are mounted. Furthermore, you might very well want to > > access the raw device without mounting any partitions (database > > managers frequently do such things to reduce I/O overhead), in which > > case you certainly would not the device to be autosuspended. > > > > How does this relate to your "It works fine on my systems" remark, do I need > to > do anything other the unmounting the paritions to make the device eligible > for > autosuspend, like unbind the sd driver or even the usb-storage driver? You shouldn't have to do anything. Mounted or unmounted, bound to sd or not bound, it shouldn't matter. Provided the device isn't being used, it ought to autosuspend. I repeat: To find out what is really happening, you should use usbmon. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc6 : crash with RTL8187 USB
On Sat, Sep 22, 2007 at 04:45:28PM +0200, Paul Rolland (ポール・ロラン) wrote: > Hello, > > > [PATCH] mac80211: fix initialisation when built-in > > http://article.gmane.org/gmane.linux.kernel.wireless.general/5710/match=patch+mac80211+initialisation > > > > [PATCH] cfg80211: fix initialisation if built-in > > http://article.gmane.org/gmane.linux.network/71326/match=patch+cfg80211+initialisation > > This is not present in 2.6.23-rc7 ! :((( I asked Dave M. to pull it a week ago, and I sent a reminder today. Hopefully that will take care of it. John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Uninline kcalloc()
This saves some bytes on usual config here and allows inserting integer
overflow warning without pissing off printk-haters crowd later on.
textdata bss dec hex filename
2662791 195347 159744 3017882 2e0c9a vmlinux -O2 before
2662535 195347 159744 3017626 2e0b9a vmlinux -O2 after
---
-256
2439726 195347 159744 2794817 2aa541 vmlinux -Os before
2439598 195347 159744 2794689 2aa4c1 vmlinux -Os after
---
-128
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
include/linux/slab.h | 58
mm/util.c| 59 +
2 files changed, 60 insertions(+), 57 deletions(-)
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -120,63 +120,7 @@ size_t ksize(const void *);
#include
#endif
-/**
- * kcalloc - allocate memory for an array. The memory is set to zero.
- * @n: number of elements.
- * @size: element size.
- * @flags: the type of memory to allocate.
- *
- * The @flags argument may be one of:
- *
- * %GFP_USER - Allocate memory on behalf of user. May sleep.
- *
- * %GFP_KERNEL - Allocate normal kernel ram. May sleep.
- *
- * %GFP_ATOMIC - Allocation will not sleep. May use emergency pools.
- * For example, use this inside interrupt handlers.
- *
- * %GFP_HIGHUSER - Allocate pages from high memory.
- *
- * %GFP_NOIO - Do not do any I/O at all while trying to get memory.
- *
- * %GFP_NOFS - Do not make any fs calls while trying to get memory.
- *
- * %GFP_NOWAIT - Allocation will not sleep.
- *
- * %GFP_THISNODE - Allocate node-local memory only.
- *
- * %GFP_DMA - Allocation suitable for DMA.
- * Should only be used for kmalloc() caches. Otherwise, use a
- * slab created with SLAB_DMA.
- *
- * Also it is possible to set different flags by OR'ing
- * in one or more of the following additional @flags:
- *
- * %__GFP_COLD - Request cache-cold pages instead of
- * trying to return cache-warm pages.
- *
- * %__GFP_HIGH - This allocation has high priority and may use emergency pools.
- *
- * %__GFP_NOFAIL - Indicate that this allocation is in no way allowed to fail
- * (think twice before using).
- *
- * %__GFP_NORETRY - If memory is not immediately available,
- * then give up at once.
- *
- * %__GFP_NOWARN - If allocation fails, don't issue any warnings.
- *
- * %__GFP_REPEAT - If allocation fails initially, try once more before failing.
- *
- * There are other flags available as well, but these are not intended
- * for general use, and so are not documented here. For a full list of
- * potential flags, always refer to linux/gfp.h.
- */
-static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
-{
- if (n != 0 && size > ULONG_MAX / n)
- return NULL;
- return __kmalloc(n * size, flags | __GFP_ZERO);
-}
+void *kcalloc(size_t n, size_t size, gfp_t flags);
#if !defined(CONFIG_NUMA) && !defined(CONFIG_SLOB)
/**
--- a/mm/util.c
+++ b/mm/util.c
@@ -5,6 +5,65 @@
#include
/**
+ * kcalloc - allocate memory for an array. The memory is set to zero.
+ * @n: number of elements.
+ * @size: element size.
+ * @flags: the type of memory to allocate.
+ *
+ * The @flags argument may be one of:
+ *
+ * %GFP_USER - Allocate memory on behalf of user. May sleep.
+ *
+ * %GFP_KERNEL - Allocate normal kernel ram. May sleep.
+ *
+ * %GFP_ATOMIC - Allocation will not sleep. May use emergency pools.
+ * For example, use this inside interrupt handlers.
+ *
+ * %GFP_HIGHUSER - Allocate pages from high memory.
+ *
+ * %GFP_NOIO - Do not do any I/O at all while trying to get memory.
+ *
+ * %GFP_NOFS - Do not make any fs calls while trying to get memory.
+ *
+ * %GFP_NOWAIT - Allocation will not sleep.
+ *
+ * %GFP_THISNODE - Allocate node-local memory only.
+ *
+ * %GFP_DMA - Allocation suitable for DMA.
+ * Should only be used for kmalloc() caches. Otherwise, use a
+ * slab created with SLAB_DMA.
+ *
+ * Also it is possible to set different flags by OR'ing
+ * in one or more of the following additional @flags:
+ *
+ * %__GFP_COLD - Request cache-cold pages instead of
+ * trying to return cache-warm pages.
+ *
+ * %__GFP_HIGH - This allocation has high priority and may use emergency pools.
+ *
+ * %__GFP_NOFAIL - Indicate that this allocation is in no way allowed to fail
+ * (think twice before using).
+ *
+ * %__GFP_NORETRY - If memory is not immediately available,
+ * then give up at once.
+ *
+ * %__GFP_NOWARN - If allocation fails, don't issue any warnings.
+ *
+ * %__GFP_REPEAT - If allocation fails initially, try once more before failing.
+ *
+ * There are other flags available as well, but these are not intended
+ * for general use, and so are not documented here. For a full list of
+ * potential flags, always refer to linux/gfp.h.
+ */
+void *kcalloc(size_t n, size_t size, gfp_t flags)
+{
+ if
Re: [PATCH -mm -v3 1/2] i386/x86_64 boot: setup data
Jeremy Fitzhardinge wrote: > > Do you actually need a linked list of data? This is similar to the > changes to bzImage to support booting bzImage a paravirt environment, > but I just proposed a pointer to a single info structure, along with a > field to identify the boot environment (ie, native/lguest/xen etc). It > would be easy to extend this to handle EFI as just another boot > environment, and you could hang a list of structures off the pointer. > *He* doesn't, but *we* do. We have already run into at least one case where the existing structure is insufficient (EDD overhaul), and so we need to do something extensible. -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] Update version information
This patch just makes the version number in ips.c and ips.h consistent. It
seems that this has been forgotten in a60768e2d43eb30a1adb8a119aeac35dc0d03ef6.
It also removes code duplication, each number is now only once in the code to
avoid similar errors in the future.
Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
---
drivers/scsi/ips.c |4 ++--
drivers/scsi/ips.h | 11 ++-
2 files changed, 8 insertions(+), 7 deletions(-)
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -204,8 +204,8 @@ module_param(ips, charp, 0);
/*
* DRIVER_VER
*/
-#define IPS_VERSION_HIGH"7.12"
-#define IPS_VERSION_LOW ".05 "
+#define IPS_VERSION_HIGHIPS_VER_MAJOR_STRING "." IPS_VER_MINOR_STRING
+#define IPS_VERSION_LOW "." IPS_VER_BUILD_STRING " "
#if !defined(__i386__) && !defined(__ia64__) && !defined(__x86_64__)
#warning "This driver has only been tested on the x86/ia64/x86_64 platforms"
--- a/drivers/scsi/ips.h
+++ b/drivers/scsi/ips.h
@@ -1172,12 +1172,13 @@ typedef struct {
*/
#define IPS_VER_MAJOR 7
-#define IPS_VER_MAJOR_STRING "7"
+#define IPS_VER_MAJOR_STRING __stringify(IPS_VER_MAJOR)
#define IPS_VER_MINOR 12
-#define IPS_VER_MINOR_STRING "12"
-#define IPS_VER_BUILD 02
-#define IPS_VER_BUILD_STRING "02"
-#define IPS_VER_STRING "7.12.02"
+#define IPS_VER_MINOR_STRING __stringify(IPS_VER_MINOR)
+#define IPS_VER_BUILD 05
+#define IPS_VER_BUILD_STRING __stringify(IPS_VER_BUILD)
+#define IPS_VER_STRING IPS_VER_MAJOR_STRING "." \
+ IPS_VER_MINOR_STRING "." IPS_VER_BUILD_STRING
#define IPS_RELEASE_ID 0x0002
#define IPS_BUILD_IDENT 761
#define IPS_LEGALCOPYRIGHT_STRING "(C) Copyright IBM Corp. 1994, 2002. All
Rights Reserved."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [35/50] i386: Do cpuid_device_create() in CPU_UP_PREPARE instead of CPU_ONLINE.
On Sat, 2007-09-22 at 00:32 +0200, Andi Kleen wrote: > From: Akinobu Mita <[EMAIL PROTECTED]> > > Do cpuid_device_create() in CPU_UP_PREPARE instead of CPU_ONLINE. > > Cc: "H. Peter Anvin" <[EMAIL PROTECTED]> > Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]> > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> > Cc: Gautham R Shenoy <[EMAIL PROTECTED]> > Cc: Oleg Nesterov <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > --- > > arch/i386/kernel/cpuid.c | 32 +++- > 1 file changed, 19 insertions(+), 13 deletions(-) > > Index: linux/arch/i386/kernel/cpuid.c > === > --- linux.orig/arch/i386/kernel/cpuid.c > +++ linux/arch/i386/kernel/cpuid.c > @@ -136,15 +136,18 @@ static const struct file_operations cpui > .open = cpuid_open, > }; > > -static int __cpuinit cpuid_device_create(int i) > +static int cpuid_device_create(int cpu) __cpuinit please Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: memset as memzero
[Arjan van de Ven - Sat, Sep 22, 2007 at 12:46:59PM -0700] | On Sat, 22 Sep 2007 12:33:55 +0400 | Cyrill Gorcunov <[EMAIL PROTECTED]> wrote: | | > Hi list, | > | > could anyone tell me why there is no official memzero function (or | > macros) in the kernel. | | it doesn't add value memset with a constant 0 is just as fast | (since the compiler knows it's 0) than any wrapper around it, and the | syntax around it is otherwise the same. | It seems I expressed wrong. I'm worried about code duplication. Look simple grep for memzero tells us that in particular: ... -- arch/x86_64/boot/compressed/misc.c:110:#define memzero(s, n) memset ((s), 0, (n)) -- init/do_mounts_rd.c:279:#define memzero(s, n) memset ((s), 0, (n)) -- init/initramfs.c:377:#define memzero(s, n) memset ((s), 0, (n)) -- lib/inflate.c:331: memzero(stk->c, sizeof(stk->c)); ... So instead of several 'define' that are the _same_ maybe better just use _single common_ define? That's all I wanna ask. (Btw, it seems ARM has a special case for memzero ;) | | > As I see a lot of kernel parts calls for it | > (defying own macros as alias to memset). Maybe there is a special | > reason not to do so? Actually my suggestion is to define _one_ | > general macros for this. | | my suggestion is to nuke all the macros and just use memset(). | Quite clear, thanks. So if that is OK - I'm shutting up ;) Cyrill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] usb-gadget-ether: Prevent oops caused by error interrupt race -V2 (comments update)
On Sat, 2007-09-22 at 12:18 -0700, David Brownell wrote: > I think you misread my comment. Those requests are **NOT** pending!! > So this update has a *MORE* incorrect description of the issue. > > That's just the freelist ... it's a fairly conventional model whereby > there's a pool of "free" request slots which can be issued. When the > pool empties, the TX queue shuts down until one of the requests which > is pending in the hardware completes, and makes a slot free. > > The problem you're addressing is that there's a small window where a > disconnect IRQ can shut down the TX queue (and empty that freelist) > after upper layers in the network stack started a transmission on > an active (pre-disconnect) TX queue. > > That problem is *NOT* related to any pending requests at all!! Sorry, I misunderstood your comment. Can you please add the correct comment yourself before we play some more rounds of ping pong ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] New kernel-message logging API
After recent discussions on LKML and a general dissatisfaction at the
current printk() kernel-message logging interface, I've decided to
write down some of the ideas for a better system.
Requirements
* Backwards compatibility with printk(), syslog(), etc. There is no
way the whole kernel can be converted to a new interface in one go.
printk() is used all over the kernel, in many different ways,
including calls from assembly, multi-line prints spread over several
calls, etc.
* Extensibility. Features like timestamping or file/line recording
[1] should be both selectable at compile-time and (if compiled in) at
run-time.
API
===
#define kprint(fmt, ...)
The main part of the kprint interface should be the kprint() function.
The string must be a single line of information (ie. it must not
contain any newlines). Calling kprint("Hello world") is equivalent to
calling printk("Hello world\n"). kprint() may be implemented as a
macro, and must not be called from assembly.
To support the different log-levels, there exists one kprint_*()
function for each log-level, for example kprint_info(). The string
must be a single line of information. Calling kprint_emerg("Oops.") is
equivalent to calling printk(KERN_EMERG "Oops.\n"). These functions
may also be implemented as macros, and must also not be called from
assembly. The different log-levels (and their functions) are:
enum kprint_loglevel {
KPRINT_EMERG, /* kprint_emerg() */
KPRINT_ALERT, /* kprint_alert() */
KPRINT_CRIT,/* kprint_crit() */
KPRINT_ERROR, /* kprint_error() and/or kprint_err() */
KPRINT_WARNING, /* kprint_warning() and/or kprint_warn() */
KPRINT_NOTICE, /* kprint_notice() */
KPRINT_INFO,/* kprint_info() */
KPRINT_DEBUG, /* kprint_debug() */
};
In order to print several related lines as one chunk, the emitter
should first allocate an object of the type struct kprint_buffer. This
buffer is initialized with the function kprint_buffer_init() which
takes as arguments a pointer to an object of the type struct
kprint_buffer followed by the log-level number. The emitter may then
make as many or as few calls to kprint_buffer() that is desired.
kprint_buffer() is a function that takes a literal string followed by
a variable number of arguments, similarly to the kprint() function. A
final call to kprint_buffer_flush() appends the messages to the kernel
message log in a single, atomic call. After it has been flushed, the
buffer is not usable again (unless it is re-initialized). If for any
reason the buffer should be de-initialized without writing it to the
log, a call to kprint_buffer_abort() must be made.
Example: {
struct kprint_buffer buf;
kprint_buffer_init(, KPRINT_DEBUG);
kprint_buffer(, "Stack trace:");
while(unwind_stack()) {
kprint_buffer(, "%p %s", address, symbol);
}
kprint_buffer_flush();
}
It may happen that certain parts of the kernel might wish to emit
messages to the log (and console, if any) in an early part of the boot
procedure, for example before the main memory allocation routines have
been set up properly. For this purpose, a function kprint_early()
exists. This "early" is a minimal way for the kernel to log its
functions, and may as such not include all the features of the full
kprint system. When the kernel is beyond the critical "early" point,
the messages (if any) in the "early" log may be moved into the main
logging store and kprint_early() must not be used again.
kprint_early() is a function and may be called from assembly.
To allow non-early calls from assembly, a function kprint_asm()
exists. This function takes a log-level number followed by a string
literal followed by a variable number of arguments.
The then legacy printk() function must be replaced by a
backwards-compatible but different interface. In short, printk should
parse messages, remove (and convert) initial log-level tokens, remove
any newlines (splitting the string into several lines), and call the
apropriate kprint()-system functions.
Internals
=
The kprint() and its log-level variants are implemented as macros in
order to be able to transparently pass extra information into the main
kprint() machinery. As an example, it might happen that an extra
feature is added that prepends the current file and line (the __FILE__
and __LINE__ macros) to the message, but in such a way that it can be
discarded at run-time, or recorded along with the messages.
Additionally, this would allow the compiler to completely optimize out
calls that are below a certain log-level severity level [2][3].
With such a modular interface, message attributes (for example the
current time) and arguments can be recorded separately from the actual
format string, instead of written formatted to a ring buffer as a
sequence of characters. Parameters would be formatted to their own
strings (regardless of the original
Re: memset as memzero
In article <[EMAIL PROTECTED]> you wrote: > it doesn't add value memset with a constant 0 is just as fast > (since the compiler knows it's 0) than any wrapper around it, and the > syntax around it is otherwise the same. it would however allow easier changing if you need to add a page cleaning system (for example new architecture which has support for it). On the other hand, is memset used for anything else than zero filling or redzone "filling"? Gruss Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [31/50] x86_64: honor notify_die() returning NOTIFY_STOP
On Sat, 2007-09-22 at 00:32 +0200, Andi Kleen wrote: > - notify_die(DIE_OOPS, str, regs, err, current->thread.trap_no, SIGSEGV); > + if (notify_die(DIE_OOPS, str, regs, err, current->thread.trap_no, > SIGSEGV) == NOTIFY_STOP) 80 chars please. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [20/50] x86_64: Fix some broken white space in arch/x86_64/mm/init.c
On Sat, 2007-09-22 at 00:32 +0200, Andi Kleen wrote:
> No functional changes
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Can we please fix _ALL_ white space and coding style issues in this file
while we are at it?
Updated patch below.
tglx
diff --git a/arch/x86_64/mm/init.c b/arch/x86_64/mm/init.c
index 458893b..346c962 100644
--- a/arch/x86_64/mm/init.c
+++ b/arch/x86_64/mm/init.c
@@ -70,10 +70,11 @@ void show_mem(void)
printk(KERN_INFO "Mem-info:\n");
show_free_areas();
- printk(KERN_INFO "Free swap: %6ldkB\n",
nr_swap_pages<<(PAGE_SHIFT-10));
+ printk(KERN_INFO "Free swap: %6ldkB\n",
+ nr_swap_pages<<(PAGE_SHIFT-10));
for_each_online_pgdat(pgdat) {
- for (i = 0; i < pgdat->node_spanned_pages; ++i) {
+ for (i = 0; i < pgdat->node_spanned_pages; ++i) {
/* this loop can take a while with 256 GB and 4k pages
so update the NMI watchdog */
if (unlikely(i % MAX_ORDER_NR_PAGES == 0)) {
@@ -89,7 +90,7 @@ void show_mem(void)
cached++;
else if (page_count(page))
shared += page_count(page) - 1;
- }
+ }
}
printk(KERN_INFO "%lu pages of RAM\n", total);
printk(KERN_INFO "%lu reserved pages\n",reserved);
@@ -100,21 +101,22 @@ void show_mem(void)
int after_bootmem;
static __init void *spp_getpage(void)
-{
+{
void *ptr;
if (after_bootmem)
- ptr = (void *) get_zeroed_page(GFP_ATOMIC);
+ ptr = (void *) get_zeroed_page(GFP_ATOMIC);
else
ptr = alloc_bootmem_pages(PAGE_SIZE);
if (!ptr || ((unsigned long)ptr & ~PAGE_MASK))
- panic("set_pte_phys: cannot allocate page data %s\n",
after_bootmem?"after bootmem":"");
+ panic("set_pte_phys: cannot allocate page data %s\n",
+ after_bootmem?"after bootmem":"");
Dprintk("spp_getpage %p\n", ptr);
return ptr;
-}
+}
static __init void set_pte_phys(unsigned long vaddr,
-unsigned long phys, pgprot_t prot)
+ unsigned long phys, pgprot_t prot)
{
pgd_t *pgd;
pud_t *pud;
@@ -130,10 +132,11 @@ static __init void set_pte_phys(unsigned long vaddr,
}
pud = pud_offset(pgd, vaddr);
if (pud_none(*pud)) {
- pmd = (pmd_t *) spp_getpage();
+ pmd = (pmd_t *) spp_getpage();
set_pud(pud, __pud(__pa(pmd) | _KERNPG_TABLE | _PAGE_USER));
if (pmd != pmd_offset(pud, 0)) {
- printk("PAGETABLE BUG #01! %p <-> %p\n", pmd,
pmd_offset(pud,0));
+ printk("PAGETABLE BUG #01! %p <-> %p\n", pmd,
+ pmd_offset(pud,0));
return;
}
}
@@ -162,7 +165,7 @@ static __init void set_pte_phys(unsigned long vaddr,
}
/* NOTE: this is meant to be run only at boot */
-void __init
+void __init
__set_fixmap (enum fixed_addresses idx, unsigned long phys, pgprot_t prot)
{
unsigned long address = __fix_to_virt(idx);
@@ -177,7 +180,7 @@ __set_fixmap (enum fixed_addresses idx, unsigned long phys,
pgprot_t prot)
unsigned long __meminitdata table_start, table_end;
static __meminit void *alloc_low_page(unsigned long *phys)
-{
+{
unsigned long pfn = table_end++;
void *adr;
@@ -187,8 +190,8 @@ static __meminit void *alloc_low_page(unsigned long *phys)
return adr;
}
- if (pfn >= end_pfn)
- panic("alloc_low_page: ran out of memory");
+ if (pfn >= end_pfn)
+ panic("alloc_low_page: ran out of memory");
adr = early_ioremap(pfn * PAGE_SIZE, PAGE_SIZE);
memset(adr, 0, PAGE_SIZE);
@@ -197,13 +200,13 @@ static __meminit void *alloc_low_page(unsigned long *phys)
}
static __meminit void unmap_low_page(void *adr)
-{
+{
if (after_bootmem)
return;
early_iounmap(adr, PAGE_SIZE);
-}
+}
/* Must run before zap_low_mappings */
__meminit void *early_ioremap(unsigned long addr, unsigned long size)
@@ -224,7 +227,8 @@ __meminit void *early_ioremap(unsigned long addr, unsigned
long size)
vaddr += addr & ~PMD_MASK;
addr &= PMD_MASK;
for (i = 0; i < pmds; i++, addr += PMD_SIZE)
- set_pmd(pmd + i,__pmd(addr | _KERNPG_TABLE |
_PAGE_PSE));
+ set_pmd(pmd + i,
+ __pmd(addr | _KERNPG_TABLE | _PAGE_PSE));
__flush_tlb();
return (void *)vaddr;
next:
@@ -284,8 +288,9 @@ phys_pmd_update(pud_t *pud, unsigned long address, unsigned
long end)
__flush_tlb_all();
}
-static void __meminit phys_pud_init(pud_t
Re: [PATCH] usb-gadget-ether: Prevent oops caused by error interrupt race -V2 (comments update)
I think you misread my comment. Those requests are **NOT** pending!! So this update has a *MORE* incorrect description of the issue. That's just the freelist ... it's a fairly conventional model whereby there's a pool of "free" request slots which can be issued. When the pool empties, the TX queue shuts down until one of the requests which is pending in the hardware completes, and makes a slot free. The problem you're addressing is that there's a small window where a disconnect IRQ can shut down the TX queue (and empty that freelist) after upper layers in the network stack started a transmission on an active (pre-disconnect) TX queue. That problem is *NOT* related to any pending requests at all!! NAK... > From [EMAIL PROTECTED] Sat Sep 22 10:51:00 2007 > Subject: [PATCH] usb-gadget-ether: Prevent oops caused by error interrupt > race -V2 (comments update) > From: Thomas Gleixner <[EMAIL PROTECTED]> > Date: Sat, 22 Sep 2007 19:41:01 +0200 > > From: Benedikt Spranger <[EMAIL PROTECTED]> > > eth_start_xmit() can race against a disconnect interrupt in the gadget > device driver, which nukes all pending request. Right now we access the > pending request list unconditionally and dereference the request list > head itself in such a case, which results in an Oops. > > Check whether the list is empty before actually dereferencing > dev->tx_reqs.next. Also add a comment for the second list_empty check > further down to avoid confusion. > > Long standing bug. Patch should be applied to stable as well. > > Signed-off-by: Benedikt Spranger <[EMAIL PROTECTED]> > Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> > > diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c > index 593e235..f2a7bd5 100644 > ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [19/50] Experimental: detect if SVM is disabled by BIOS
On Sat, 2007-09-22 at 00:32 +0200, Andi Kleen wrote:
> Also allow to set svm lock.
Please use two separate patches. The detection and cpuinfo display is
not related to set svm lock.
> TBD double check, documentation, i386 support
Yes, documentation would be useful. See below.
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
>
> ---
> arch/x86_64/kernel/setup.c| 25 +++--
> include/asm-i386/cpufeature.h |1 +
> include/asm-i386/msr-index.h |3 +++
> 3 files changed, 27 insertions(+), 2 deletions(-)
>
> Index: linux/arch/x86_64/kernel/setup.c
> ===
> --- linux.orig/arch/x86_64/kernel/setup.c
> +++ linux/arch/x86_64/kernel/setup.c
> @@ -565,7 +565,7 @@ static void __cpuinit early_init_amd(str
>
> static void __cpuinit init_amd(struct cpuinfo_x86 *c)
> {
> - unsigned level;
> + unsigned level, flags, dummy;
>
> #ifdef CONFIG_SMP
> unsigned long value;
> @@ -634,7 +634,28 @@ static void __cpuinit init_amd(struct cp
> /* Family 10 doesn't support C states in MWAIT so don't use it */
> if (c->x86 == 0x10 && !force_mwait)
> clear_bit(X86_FEATURE_MWAIT, >x86_capability);
> +
> + if (c->x86 >= 0xf && c->x86 <= 0x11 &&
> + !rdmsr_safe(MSR_VM_CR, , ) &&
> + (flags & 0x18))
> + set_bit(X86_FEATURE_VIRT_DISABLED, >x86_capability);
Why the check for 0x18 And please can we use understandable
constants for this.
bit 3 (SVM_LOCK) controls only the writeability of bit 4 (SVME_DISABLE),
which controls whether SVM is allowed to be enabled or not.
bit 3 bit 4
0 0 SVM can be enabled in EFER, SVME_DISABLE is writeable
1 0 SVM can be enabled in EFER, SVME_DISABLE is not writeable
0 1 SVM can not be enabled in EFER, SVME_DISABLE is writeable
1 1 SVM can not be enabled in EFER, SVME_DISABLE is not writeable
So SVM is disabled, when bit 4 is set.
> +}
> +
> +static int enable_svm_lock(char *s)
> +{
> + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
> + boot_cpu_data.x86 >= 0xf && boot_cpu_data.x86 <= 0x11) {
> + unsigned a,b;
> + if (rdmsr_safe(MSR_VM_CR, , ))
> + return 0;
> + a |= (1 << 3); /* set SVM lock */
SVM_LOCK is read only according to data sheet. You can set bit 4
(SVME_DISABLE) to prevent KVM or what else using that feature.
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: memset as memzero
On Sat, 22 Sep 2007, Arjan van de Ven wrote: > > it doesn't add value memset with a constant 0 is just as fast > (since the compiler knows it's 0) than any wrapper around it, and the > syntax around it is otherwise the same. Indeed. The reason we have "clear_page()" is not because the value we're writing is constant - that doesn't really help/change anything at all. We could have had a "fill_page()" that sets the value to any random byte, it's just that zero is the only value that we really care about. So the reason we have "clear_page()" is because the *size* and *alignment* is constant and known at compile time, and unlike the value you write, that actually matters. So "memzero()" would never really make sense as anything but a syntactic wrapper around "memset(x,0,size)". Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should parent's WIFSIGNALED(siginfo->si_status) be true EVEN IF the SIGNAL was caught by the child?
On Sat, 2007-09-22 at 11:22 -0700, John Z. Bohach wrote: > Hello, > > It is unclear from the various documentions in the kernel and glibc what > the proper behaviour should be for the case when a child process > catches a SIGNAL (say for instance, SIGTERM), and then calls exit() > from within its caught SIGNAL handler. > > Since the exit() will cause a SIGCHLD to the parent, and the parent > (let's say) has a SIGCHLD sigaction (SA_SIGINFO sa_flags set), should > the parent's WIFSIGNALED(siginfo->si_status) be true? > > To recap, the WIFSIGNALED section of the waitpid() manpage says: > > WIFSIGNALED(status) > returns true if the child process was terminated by a signal. > > So the dilemna: the child caught the signal, so it wasn't terminated by > a signal, but rather its signal handler (let's say) called exit. POSIX says WIFSIGNALED(stat_val) Evaluates to a non-zero value if status was returned for a child process that terminated due to the receipt of a signal that was not caught (see ). So there's no dilemma at all and Linux is non-conformant. -- Nicholas Miell <[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: Should parent's WIFSIGNALED(siginfo->si_status) be true EVEN IF the SIGNAL was caught by the child?
John, > It is unclear from the various documentions in the kernel and glibc what > the proper behaviour should be for the case when a child process > catches a SIGNAL (say for instance, SIGTERM), and then calls exit() > from within its caught SIGNAL handler. > > Since the exit() will cause a SIGCHLD to the parent, and the parent > (let's say) has a SIGCHLD sigaction (SA_SIGINFO sa_flags set), should > the parent's WIFSIGNALED(siginfo->si_status) be true? > > To recap, the WIFSIGNALED section of the waitpid() manpage says: > > WIFSIGNALED(status) >returns true if the child process was terminated by a signal. > > So the dilemna: the child caught the signal, so it wasn't terminated by > a signal, but rather its signal handler (let's say) called exit. > > Furthermore: > > WTERMSIG(status) >returns the number of the signal that caused the child process >to terminate. This macro should only be employed if WIFSIGNALED >returned true. > > Observered behaviour with 2.6.20.6 is that is WIFSIGNALED(status) > returns true (possibly incorrect), and furthermore, WTERMSIG(status) > returns the exit(VALUE) VALUE from the child's exit() call, and not the > SIGNAL (let's say SIGTERM that the child caught). This may be correct, > since the siginfo_t * si_status member is: > > int si_status; /* Exit value or signal */ > > but there's no clarity on which: exit value or signal. Since the child > exited, I'm likely to assume exit status, which is current observed > behaviour, but then, WIFSIGNALED(status) should be FALSE, which its not > (observed with 2.6.20.6). > > So could someone clarify the kernel's intent? > > I can provide a short C program to illustrate above behaviour, if > needed. It also could be that I'm just misinterpreting the intent, > which is why I'm not calling this a bug, despite a possible > inconsistency in behaviour. If the child terminated by calling exit(), regardless of whether it was done from inside a signal handler, then WIFEXITED() should test true, but WIFSIGNALED() will not. If you are seeing otherwise, then show a *short* program that demonstrates the behavior. (But it seems unlikely that there would be a kernel bug on this point, so do check your program carefully!) Cheers, Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: memset as memzero
On Sat, 22 Sep 2007 12:33:55 +0400 Cyrill Gorcunov <[EMAIL PROTECTED]> wrote: > Hi list, > > could anyone tell me why there is no official memzero function (or > macros) in the kernel. it doesn't add value memset with a constant 0 is just as fast (since the compiler knows it's 0) than any wrapper around it, and the syntax around it is otherwise the same. > As I see a lot of kernel parts calls for it > (defying own macros as alias to memset). Maybe there is a special > reason not to do so? Actually my suggestion is to define _one_ > general macros for this. my suggestion is to nuke all the macros and just use memset(). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [9/50] i386: validate against ACPI motherboard resources
Thomas Gleixner wrote: On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote: Yinghai Lu wrote: No! MMCONFIG will not work with acpi=off any more. I don't think this is unreasonable. The ACPI MCFG table is how we are supposed to learn about the area in the first place. If we can't get the table location via an approved mechanism, and can't validate it doesn't overlap with another memory reservation or something, I really don't think we should be using it. We all know how correct ACPI tables are. Specifications are nice, reality tells a different story. MMCONFIG can't be used without ACPI in any case unless we know where the table is using chipset-specific knowledge (i.e. reading the registers directly). Doing that without being told that this area is really intended to be used, via the ACPI table, is dangerous, i.e. we don't necessarily know if the MMCONFIG is broken on the platform in some way we can't detect. I don't think it's much of an issue anyway - the chances that somebody will want to run without ACPI on a system with MCFG are pretty low given that you'll end up losing a bunch of functionality (not least of which is multi-cores). acpi=off is an often used debug switch and it _is_ quite useful. Taking away debug functionality is not a good idea. If someone has to turn ACPI off, disabling MMCONFIG is probably the least of their worries.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add extended crashkernel syntax to kernel-parameters.txt
This adds the documentation for the extended crashkernel syntax into Documentation/kernel-parameters.txt. Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> --- Documentation/kernel-parameters.txt |7 +++ 1 file changed, 7 insertions(+) --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -498,6 +498,13 @@ and is between 256 and 4096 characters. [KNL] Reserve a chunk of physical memory to hold a kernel to switch to with kexec on panic. + crashkernel=range1:size1[,range2:size2,[EMAIL PROTECTED] + [KNL] Same as above, but depends on the memory + in the running system. The syntax of range is + start-[end] where start and end are both + a memory unit (amount[KMG]). See also + Documentation/kdump/kdump.txt for a example. + cs4232= [HW,OSS] Format: , - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Add extended crashkernel syntax to kernel-parameters.txt
This adds the documentation for the extended crashkernel syntax into Documentation/kernel-parameters.txt. Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> --- Documentation/kernel-parameters.txt |7 +++ 1 file changed, 7 insertions(+) --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -498,6 +498,13 @@ and is between 256 and 4096 characters. [KNL] Reserve a chunk of physical memory to hold a kernel to switch to with kexec on panic. + crashkernel=range1:size1[,range2:size2,[EMAIL PROTECTED] + [KNL] Same as above, but depends on the memory + in the running system. The syntax of range is + start-[end] where start and end are both + a memory unit (amount[KMG]). See also + Documentation/kdump/kdump.txt for a example. + cs4232= [HW,OSS] Format: , - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Should parent's WIFSIGNALED(siginfo->si_status) be true EVEN IF the SIGNAL was caught by the child?
Hello, It is unclear from the various documentions in the kernel and glibc what the proper behaviour should be for the case when a child process catches a SIGNAL (say for instance, SIGTERM), and then calls exit() from within its caught SIGNAL handler. Since the exit() will cause a SIGCHLD to the parent, and the parent (let's say) has a SIGCHLD sigaction (SA_SIGINFO sa_flags set), should the parent's WIFSIGNALED(siginfo->si_status) be true? To recap, the WIFSIGNALED section of the waitpid() manpage says: WIFSIGNALED(status) returns true if the child process was terminated by a signal. So the dilemna: the child caught the signal, so it wasn't terminated by a signal, but rather its signal handler (let's say) called exit. Furthermore: WTERMSIG(status) returns the number of the signal that caused the child process to terminate. This macro should only be employed if WIFSIGNALED returned true. Observered behaviour with 2.6.20.6 is that is WIFSIGNALED(status) returns true (possibly incorrect), and furthermore, WTERMSIG(status) returns the exit(VALUE) VALUE from the child's exit() call, and not the SIGNAL (let's say SIGTERM that the child caught). This may be correct, since the siginfo_t * si_status member is: int si_status; /* Exit value or signal */ but there's no clarity on which: exit value or signal. Since the child exited, I'm likely to assume exit status, which is current observed behaviour, but then, WIFSIGNALED(status) should be FALSE, which its not (observed with 2.6.20.6). So could someone clarify the kernel's intent? I can provide a short C program to illustrate above behaviour, if needed. It also could be that I'm just misinterpreting the intent, which is why I'm not calling this a bug, despite a possible inconsistency in behaviour. Thanks, John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] taskstats: separate PID/TGID stats producers to complete the TGID ones
Guillaume Chazarain wrote:
> TASKSTATS_CMD_ATTR_TGID used to return only the delay accounting stats, not
> the basic and extended accounting. With this patch,
> TASKSTATS_CMD_ATTR_TGID also aggregates the accounting info for all threads
> of a thread group.
>
> TASKSTATS_CMD_ATTR_PID output should be unchanged
> TASKSTATS_CMD_ATTR_TGID output should have all fields set, unlike before the
> patch where most of the fiels were set to 0.
>
> To this aim, two functions were introduced: fill_threadgroup() and add_tsk().
> These functions are responsible for aggregating the subsystem specific
> accounting information. Taskstats requesters (fill_pid(), fill_tgid() and
> fill_tgid_exit()) should only call add_tsk() and fill_threadgroup() to get the
> stats.
>
> Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
> Cc: Balbir Singh <[EMAIL PROTECTED]>
> Cc: Jay Lan <[EMAIL PROTECTED]>
> Cc: Jonathan Lim <[EMAIL PROTECTED]>
> Cc: Oleg Nesterov <[EMAIL PROTECTED]>
> ---
>
> Documentation/accounting/getdelays.c |2 -
> include/linux/tsacct_kern.h | 12 ++-
> kernel/taskstats.c | 131
> ++
> kernel/tsacct.c | 106
> 4 files changed, 155 insertions(+), 96 deletions(-)
>
> diff --git a/Documentation/accounting/getdelays.c
> b/Documentation/accounting/getdelays.c
> index cbee3a2..78773c0 100644
> --- a/Documentation/accounting/getdelays.c
> +++ b/Documentation/accounting/getdelays.c
> @@ -76,7 +76,7 @@ static void usage(void)
> fprintf(stderr, "getdelays [-dilv] [-w logfile] [-r bufsize] "
> "[-m cpumask] [-t tgid] [-p pid]\n");
> fprintf(stderr, " -d: print delayacct stats\n");
> - fprintf(stderr, " -i: print IO accounting (works only with -p)\n");
> + fprintf(stderr, " -i: print IO accounting\n");
> fprintf(stderr, " -l: listen forever\n");
> fprintf(stderr, " -v: debug on\n");
> }
> diff --git a/include/linux/tsacct_kern.h b/include/linux/tsacct_kern.h
> index 7e50ac7..93dffc2 100644
> --- a/include/linux/tsacct_kern.h
> +++ b/include/linux/tsacct_kern.h
> @@ -10,17 +10,23 @@
> #include
>
> #ifdef CONFIG_TASKSTATS
> -extern void bacct_add_tsk(struct taskstats *stats, struct task_struct *tsk);
> +void bacct_fill_threadgroup(struct taskstats *stats, struct task_struct
> *task);
> +void bacct_add_tsk(struct taskstats *stats, struct task_struct *task);
> #else
> -static inline void bacct_add_tsk(struct taskstats *stats, struct task_struct
> *tsk)
> +static inline void bacct_fill_threadgroup(struct taskstats *stats, struct
> task_struct *task)
> +{}
> +static inline void bacct_add_tsk(struct taskstats *stats, struct task_struct
> *task)
> {}
> #endif /* CONFIG_TASKSTATS */
>
> #ifdef CONFIG_TASK_XACCT
> -extern void xacct_add_tsk(struct taskstats *stats, struct task_struct *p);
> +void xacct_fill_threadgroup(struct taskstats *stats, struct task_struct
> *task);
> +void xacct_add_tsk(struct taskstats *stats, struct task_struct *p);
> extern void acct_update_integrals(struct task_struct *tsk);
> extern void acct_clear_integrals(struct task_struct *tsk);
> #else
> +static inline void xacct_fill_threadgroup(struct taskstats *stats, struct
> task_struct *task)
> +{}
> static inline void xacct_add_tsk(struct taskstats *stats, struct task_struct
> *p)
> {}
> static inline void acct_update_integrals(struct task_struct *tsk)
> diff --git a/kernel/taskstats.c b/kernel/taskstats.c
> index 059431e..ce43fae 100644
> --- a/kernel/taskstats.c
> +++ b/kernel/taskstats.c
> @@ -168,6 +168,68 @@ static void send_cpu_listeners(struct sk_buff *skb,
> up_write(>sem);
> }
>
> +/**
> + * fill_threadgroup - initialize some common stats for the thread group
> + * @stats: the taskstats to write into
> + * @task: the thread representing the whole group
> + *
> + * There are two types of taskstats fields when considering a thread group:
> + * - those that can be aggregated from each thread in the group (like CPU
> + * times),
> + * - those that cannot be aggregated (like UID) or are identical (like
> + * memory usage), so are taken from the group leader.
> + * XXX_threadgroup() methods deal with the first type while XXX_add_tsk()
> with
> + * the second.
> + */
> +static void fill_threadgroup(struct taskstats *stats, struct task_struct
> *task)
> +{
How about calling this one fill_threadgroup_stats()?
> + /*
> + * Each accounting subsystem adds calls to its functions to initialize
> + * relevant parts of struct taskstsats for a single tgid as follows:
> + *
> + * per-task-foo-fill_threadgroup(stats, task);
> + */
> +
> + stats->version = TASKSTATS_VERSION;
> +
> + /* fill in basic acct fields */
> + bacct_fill_threadgroup(stats, task);
> +
> + /* fill in extended acct fields */
> + xacct_fill_threadgroup(stats, task);
> +}
> +
> +/**
> + * add_tsk - combine some thread
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Sep 22, 2007, at 06:34:17, Rafael J. Wysocki wrote: On Saturday, 22 September 2007 01:19, Kyle Moffett wrote: On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: The ACPI platform firmware is allowed to preserve information accross the hibernation-resume cycle, so this need not be the same. All of my comments related to the case where S4 is not being used (instead the system is just powered off normally), and a boot kernel that does not initialize ACPI is used. In that case, the ACPI platform firmware should not be able to distinguish a normal boot from a resume from hibernation. I think that in order for this to work, there would need to be some ABI whereby the resume-ing kernel can pass its entire ACPI state and a bunch of other ACPI-related device details to the resume-ed kernel, which I believe it does not do at the moment. In fact we don't need to do this. The solution is not to touch ACPI in the boot kernel (ie. the one that loads the image) and pass control to the image kernel. This is how it's supposed to work according to the spec, more or less (well, there are some ugly details that need handling, like the restoration of the NVS area). First of all, we will need to make the resumed kernel throw away *ALL* of its ACPI state on S5 and completely reinitialize ACPI as though it was booting for the first time on resume. From what I can tell, we "throw away" all the ACPI state in the boot kernel and reinitialize it there, but then the reinitialized state is overwritten with the resumed kernel's state and the two don't always happen to be the same. (Like if a battery got replaced or AC status changed). Umm, I don't see how that can possibly work properly. For a laptop, for example, the restore kernel will need to access the disk, the LCD display, and possibly the AC/battery and current CPU frequency. From what I understand of ACPI, both of the former may need ACPI code to operate properly (Isn't there an ATA taskfile object of some kind?) and the latter two almost definitely need ACPI. Ergo the boot kernel may need to initialize and use ACPI just to run an ATA taskfile so it can read from the HDD efficiently. I believe that what causes problems is the ACPI state data that the kernel stores is *different* between identical sequential boots, especially when you add/remove/replace batteries, AC, etc. Rather the ACPI state data that the platform firmware stores may be different, depending on whether you enter S4 or S5 during "power off" and that determines the interactions between the kernel and the firmware after the next boot. That's not what he was talking about. The problem discussed was: (A) You hibernate your box, entering S5 (IE: power off) (B) You resume the box and the boot kernel inits all the ACPI stuff. (C) The boot kernel's ACPI state is completely replaced by the resumed kernel's state. (D) Hardware stops working mysteriously because of ACPI problems. The only possible conclusion is that the state between the boot kernel and the resume kernel was *different* and so the device failed because the ACPI state in the resume kernel doesn't match the actual state of the hardware. 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: [PATCH] [9/50] i386: validate against ACPI motherboard resources
On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote: > Yinghai Lu wrote: > > No! > > > > MMCONFIG will not work with acpi=off any more. > > I don't think this is unreasonable. The ACPI MCFG table is how we are > supposed to learn about the area in the first place. If we can't get the > table location via an approved mechanism, and can't validate it doesn't > overlap with another memory reservation or something, I really don't > think we should be using it. We all know how correct ACPI tables are. Specifications are nice, reality tells a different story. > I don't think it's much of an issue anyway - the chances that somebody > will want to run without ACPI on a system with MCFG are pretty low given > that you'll end up losing a bunch of functionality (not least of which > is multi-cores). acpi=off is an often used debug switch and it _is_ quite useful. Taking away debug functionality is not a good idea. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] Add CRC checksum for RCU lists
On Fri, Sep 21, 2007 at 05:32:08PM -0400, Steven Rostedt wrote:
>
> --
> On Fri, 21 Sep 2007, Paul E. McKenney wrote:
>
> > On Thu, Sep 20, 2007 at 02:34:11PM -0400, Steven Rostedt wrote:
> > > In recent development of the RT kernel, some of our experimental code
> > > corrupted the rcu header. But the side effect (crashing) didn't rear its
> > > ugly head until way after the fact. Discussing this with Paul, he
> > > suggested that RCU should have a "self checking" mechanism to detect
> > > these kind of issues. He also suggested putting in a CRC into the
> > > rcu_head structure.
> > >
> > > This patch does so.
> >
> > Very cool!!!
>
> Thanks :-)
>
> > > This patch also takes care to update the crc when rcu_head items are
> > > moved from list to list and whenever the next pointer is modified due to
> > > addition.
> >
> > We can only be thankful that it is not possible to cancel outstanding
> > RCU callbacks...
>
> true
>
> > Looks good -- a few suggestions for better fault coverage interspersed
> > below. But would be useful as is. (And it would be good to apply after
> > the preempt/boost patches, which are currently undergoing integration
> > with the CPU hotplug patches -- the good news is that this integration
> > eliminates the need for patch #4!)
> >
> > Acked-by: Paul E. McKenney <[EMAIL PROTECTED]>
>
> Thanks, but this is still going to go through changes, from your comments
> as well as your latest patches.
Good point...
> > > Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
> > >
> > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > index fe17d7d..baca7e6 100644
> > > --- a/include/linux/rcupdate.h
> > > +++ b/include/linux/rcupdate.h
> > > @@ -50,13 +50,81 @@
> > > struct rcu_head {
> > > struct rcu_head *next;
> > > void (*func)(struct rcu_head *head);
> > > +#ifdef CONFIG_RCU_CRC_HEADER_CHECK
> > > + /*
> > > + * Checks are made in C files knowing that "next" is
> > > + * the first element. So keep it the first element.
> > > + */
> > > + unsigned long crc;
> > > + void *caller;
> > > +#endif
> > > };
> >
> > Looks good, but one question -- why not include the caller in the CRC?
> > Not a big deal either way, but would catch a few more cases of corruption.
> > Also, as things stand, the caller pointer can be silently corrupted,
> > which might causes confusion if someone had to examine the RCU callback
> > lists from a crash dump.
>
> One reason was that the caller was an addition. I originally didn't have
> it, but during my tests, the output was basically useless. It didn't give
> any hint to where things went wrong, so I added it. The CRC is to check
> the rcu is working, not really the checker itself.
>
> Note, it helped us out lately with Peter's latest file_table patches in
> -rt. With this patch applied, it triggered corruption. That was due to the
> union in the fs.h between the llist and rcu_head there was a dependency
> in the llist where the rcu_head would not grow. The llist can still do a
> spin lock on the lock _after_ the item was added to the call_rcu. Because
> of that union, the locking of the lock corrupted the crc. Set it to one.
>
> You'll see patches from Peter soon to get rid of that dependency.
Look forward to seeing them!
> > Interchanging the order of "crc" and "caller" would change the strategy,
> > if I understand correctly.
>
> yep.
>
> >
> > > -#define RCU_HEAD_INIT{ .next = NULL, .func = NULL }
> > > +#ifdef CONFIG_RCU_CRC_HEADER_CHECK
> > > +
> > > +#define RCU_CRC_MAGIC 0xC4809168UL
> >
> > Very magic indeed -- Google doesn't find it, other than in your
> > patch. ;-)
>
> Paul, I'm disappointed in you. That number doesn't ring a bell at all??
>
> (hint, ignore the 'C' that was added by me).
Well, once Kyle spilled the beans, it was pretty obvious. ;-)
Might well be a first!!!
> > > +static inline unsigned long rcu_crc_calc(struct rcu_head *head)
> > > +{
> > > + unsigned int *p = (unsigned int*)head; /* 32 bit */
> > > + unsigned long crc = RCU_CRC_MAGIC;
> > > +
> > > + for (p=(void *)head; (void*)p < (void*)>crc; p++)
> > > + crc ^= *p;
> > > + return crc;
> > > +}
> >
> > Why initialize "p" twice? (Once in the declaration, and once in the
> > "for" loop, but with different casts.)
>
> Why? probably because I was half asleep when writing it ;-)
> Will fix.
>
> > > +static inline void rcu_crc_check(struct rcu_head *head)
> > > +{
> > > + static int once;
> > > + if (unlikely(head->crc != rcu_crc_calc(head)) && !once) {
> > > + once++;
> >
> > Do we want exactly one (give or take concurrent checks), or do we want
> > the first ten or so? Sometimes having a modest sample rather than
> > exactly one is helpful.
>
> I added that because during testing, it would flood the serial console. I
> can modify this to whatever deems fit. Perhaps more hits will give a
> better clue to what went wrong. I could also just add a print_ratelimit to
> it too.
Agreed -- using the
Re: [PATCH] [4/50] x86: add cpu codenames for Kconfig.cpu
On Sat, 2007-09-22 at 00:32 +0200, Andi Kleen wrote: > From: "Oliver Pinter" <[EMAIL PROTECTED]> > > add cpu core name for arch/i386/Kconfig.cpu:Pentium 4 sections help > add Pentium D for arch/i386/Kconfig.cpu > add Pentium D for arch/x86_64/Kconfig > > Signed-off-by: Oliver Pinter <[EMAIL PROTECTED]> > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> > Acked-by: Sam Ravnborg <[EMAIL PROTECTED]> > Cc: Andi Kleen <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > --- > > arch/i386/Kconfig.cpu | 34 +++--- > arch/x86_64/Kconfig |6 +++--- > 2 files changed, 34 insertions(+), 6 deletions(-) > > Index: linux/arch/i386/Kconfig.cpu > === > --- linux.orig/arch/i386/Kconfig.cpu > +++ linux/arch/i386/Kconfig.cpu > @@ -115,11 +115,39 @@ config MPENTIUM4 > bool "Pentium-4/Celeron(P4-based)/Pentium-4 M/older Xeon" > help > Select this for Intel Pentium 4 chips. This includes the > - Pentium 4, P4-based Celeron and Xeon, and Pentium-4 M > - (not Pentium M) chips. This option enables compile flags > - optimized for the chip, uses the correct cache shift, and > + Pentium 4, Pentium D, P4-based Celeron and Xeon, and > + Pentium-4 M (not Pentium M) chips. This option enables compile > + flags optimized for the chip, uses the correct cache shift, and > applies any applicable Pentium III optimizations. > > + CPUIDs: F[0-6][1-A] (in /proc/cpuinfo show = cpu family : 15 ) > + > + Select this for: > + Pentiums (Pentium 4, Pentium D, Celeron, Celeron D) corename: > + -Willamette > + -Northwood > + -Mobile Pentium 4 > + -Mobile Pentium 4 M > + -Extreme Edition (Gallatin) > + -Prescott > + -Prescott 2M > + -Cedar Mill > + -Presler > + -Smithfiled > + Xeons (Intel Xeon, Xeon MP, Xeon LV, Xeon MV) corename: > + -Foster > + -Prestonia > + -Gallatin > + -Nocona > + -Irwindale > + -Cranford > + -Potomac > + -Paxville > + -Dempsey > + > + more info: http://balusc.xs4all.nl/srv/har-cpu.html This will never be up to date. Also the URL above is redirected to an empty bye/bye page. Put this up to one of the kernel related wikis, if you think it might be useful at all. 99% of the users do not even know which CPU they have in their system. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [34/50] i386: Fix argument signedness warnings
On Sat, 22 Sep 2007 12:01:16 +0200 (CEST) Jan Engelhardt wrote: > > On Sep 22 2007 10:36, Satyam Sharma wrote: > >> from arch/i386/boot/compressed/misc.c:14: > >> include/asm/processor.h: In function $B!F(Jcpuid_count$B!G(J: > > ^^ ^^ > >> include/asm/processor.h:615: warning: pointer targets in passing > >> argument 1 of $B!F(Jnative_cpuid$B!G(J differ in signedness > > > >> include/asm/processor.h:615: warning: pointer targets in passing > >> argument 2 of $B!F(Jnative_cpuid$B!G(J differ in signedness > > > >> include/asm/processor.h:615: warning: pointer targets in passing > >> argument 3 of $B!F(Jnative_cpuid$B!G(J differ in signedness > > > >> include/asm/processor.h:615: warning: pointer targets in passing > >> argument 4 of $B!F(Jnative_cpuid$B!G(J differ in signedness > >^^^^ > > > >Yikes. My bad, I had faulty (default) alpine settings (and a sad > >combination of LANG=en_US.UTF-8) when I made and sent out that patch. > >Please ensure that this finally gets committed in a somewhat saner and > >more readable state to the tree. > > I am not too thrilled about gcc using non-ascii for interpunctuation > (for Western languages).. Ack. I usually build with "LC_ALL=C" to make those readable. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [4/50] x86: add cpu codenames for Kconfig.cpu
On Sat, 22 Sep 2007 10:23:25 -0400 Dave Jones wrote: > On Sat, Sep 22, 2007 at 08:57:24AM +0200, Sam Ravnborg wrote: > > > > This seems like yet another list that will need to be perpetually > > > kept up to date, and given 99% of users don't know the codename > > > of their core, just the marketing name, I question its value. > > > > As a bare minimum requirement the list presented here shall use same > > names as used in /proc/cpuinfo > > > > On this box I read: > > > > vendor_id : GenuineIntel > > model name : Pentium III (Coppermine) > > There are *dozens* of possible entries here, and always new ones. > The list will become so cumbersome that searching for the name > through the help text of each possible option will become a > really boring task, that I doubt anyone will seriously do. Yep. help text: see www.wikipedia.org :) --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] usb-gadget-ether: Prevent oops caused by error interrupt race -V2 (comments update)
From: Benedikt Spranger <[EMAIL PROTECTED]>
eth_start_xmit() can race against a disconnect interrupt in the gadget
device driver, which nukes all pending request. Right now we access the
pending request list unconditionally and dereference the request list
head itself in such a case, which results in an Oops.
Check whether the list is empty before actually dereferencing
dev->tx_reqs.next. Also add a comment for the second list_empty check
further down to avoid confusion.
Long standing bug. Patch should be applied to stable as well.
Signed-off-by: Benedikt Spranger <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 593e235..f2a7bd5 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -1989,8 +1989,21 @@ static int eth_start_xmit (struct sk_buff *skb, struct
net_device *net)
}
spin_lock_irqsave(>req_lock, flags);
+ /*
+* dev->tx_reqs may be empty. We raced against a disconnect
+* interrupt in the gadget device driver, which nuked all
+* pending requests.
+*/
+ if (list_empty(>tx_reqs)) {
+ netif_stop_queue(net);
+ spin_unlock_irqrestore(>req_lock, flags);
+ return 1;
+ }
+
req = container_of (dev->tx_reqs.next, struct usb_request, list);
list_del (>list);
+
+ /* last request in list: stop queue */
if (list_empty (>tx_reqs))
netif_stop_queue (net);
spin_unlock_irqrestore(>req_lock, flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] include/linux/mutex.h: unclear reference to convention
On Sat, 22 Sep 2007 01:41:17 -0700 (PDT) Matti Linnanvuori wrote: > From: Matti Linnanvuori <[EMAIL PROTECTED]> > > Reference to two different conventions is unnecessarily unclear unless you > know them already and requires seeking and reading another file for > understanding. Could you hit the Return/Enter key about every 70-72 characters or so, to break up those long lines? Thanks. > Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]> > --- > > --- linux-2.6.23-rc7/include/linux/mutex.h2007-09-22 11:09:42.223763000 > +0300 > +++ linux-2.6.23/include/linux/mutex.h2007-09-22 11:11:19.416761000 +0300 > @@ -132,9 +132,19 @@ extern int __must_check mutex_lock_inter > # define mutex_lock_interruptible_nested(lock, subclass) > mutex_lock_interruptible(lock) > #endif > > -/* > - * NOTE: mutex_trylock() follows the spin_trylock() convention, > - * not the down_trylock() convention! Someone was trying to be helpful in include/linux/mutex.h. The real doc for the function is in kernel/mutex.c (and pasted below). Another convention is that we put kernel-doc with the implementation (i.e., in .c files) when possible, not with the function prototype. Of course, for inline functions or macros in header files, that's where the kernel-doc has to live. so we don't need this patch. > +/*** > + * mutex_trylock - try acquire the mutex, without waiting > + * @lock: the mutex to be acquired > + * > + * Try to acquire the mutex atomically. Returns 1 if the mutex > + * has been acquired successfully, and 0 on contention. > + * > + * NOTE: this function follows the spin_trylock() convention, so > + * it is negated to the down_trylock() return values! Be careful > + * about this when converting semaphore users to mutexes. > + * > + * This function must not be used in interrupt context. The > + * mutex must be released by the same task that acquired it. > */ > extern int fastcall mutex_trylock(struct mutex *lock); > extern void fastcall mutex_unlock(struct mutex *lock); --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH] 2.6.22.6 fix kernel panic on corrupted reiserfs directory
* Oliver Pinter ([EMAIL PROTECTED]) wrote: > it is Lepton's patch. > Namesys boys, this patch is OK? > Greg, I neither do find this patch in Linus's tree. The point is, if it's not important enough to go into Linus' tree, than it isn't important enough to be in the -stable tree. So please get this patch upstream to Linus, then we will take it for -stable. thanks, -chris P.S. When forwarding someone else's patch, always include the proper authorship (such as "From: Lepton Wu <[EMAIL PROTECTED]>" in the first line of the email body) so that information is not lost. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] Add CRC checksum for RCU lists
On Sat, Sep 22, 2007 at 03:04:47AM -0400, Kyle Moffett wrote:
> On Sep 21, 2007, at 17:32:08, Steven Rostedt wrote:
> >On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> >>On Thu, Sep 20, 2007 at 02:34:11PM -0400, Steven Rostedt wrote:
> >>>-#define RCU_HEAD_INIT { .next = NULL, .func = NULL }
> >>>+#ifdef CONFIG_RCU_CRC_HEADER_CHECK
> >>>+
> >>>+#define RCU_CRC_MAGIC 0xC4809168UL
> >>
> >>Very magic indeed -- Google doesn't find it, other than in your
> >>patch. ;-)
> >
> >Paul, I'm disappointed in you. That number doesn't ring a bell at
> >all??
> >
> >(hint, ignore the 'C' that was added by me).
>
> LOL! The RCU patent number; very clever indeed!
Y'know, I newer did figure this one out!
I like it!!! ;-)
Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB autosuspend and turning of usb pendrive leds
Alan Stern wrote: On Sat, 22 Sep 2007, Hans de Goede wrote: I'm afraid that that doesn't work for usb mass-storage devices. Here is what I did: 1) kill hal 2) insert usb stick -> led lights 3): echo -n 1 >/sys/bus/usb/devices/.../power/autosuspend echo -n auto > /sys/bus/usb/devices/.../power/level 4) wait Nothing happens, where as sending "suspend" to power/level does turn the led off. I don't know what went wrong. It works fine on my systems. You did fill in the correct device path for the "...", right? Yes, the one that comes and goes as I plug in one of the USB-sticks I ue for testing. And you don't need the "-n" -- adding it shouldn't matter, but you should try reading back the contents of those files to make sure the values did get written correctly. I did read them back and it did get written correctly. Now call me naive, but I would expect a mass-storage devices with no partitions mounted to autosuspend when autosuspend is enabled for that device. Yes, that is naive. The driver has no way to tell whether or not any partitions are mounted. Furthermore, you might very well want to access the raw device without mounting any partitions (database managers frequently do such things to reduce I/O overhead), in which case you certainly would not the device to be autosuspended. How does this relate to your "It works fine on my systems" remark, do I need to do anything other the unmounting the paritions to make the device eligible for autosuspend, like unbind the sd driver or even the usb-storage driver? If so I must say I find that a little counter intuitive. Regards, Hans p.s. As always, please keep me CC-ed, not on the list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: A revised timerfd API
Michael, On Sat, 2007-09-22 at 15:12 +0200, Michael Kerrisk wrote: > Davide, Andrew, Linus, et al. > > At the start of this thread > (http://thread.gmane.org/gmane.linux.kernel/581115 ), I proposed 4 > alternatives to Davide's original timerfd API. Based on the feedback in > that thread (and one or two earlier comments): > > Let's dismiss option (a), since it is an unlovely multiplexing interface. > > Option (b) seems a viable. The most notable concern was from Thomas > Gleixner, that we might end up duplicating code from the POSIX timers API > within the timerfd API -- some eventual refactoring might mitigate this > problem. It should be possible to use the timerfd syscalls as wrappers for the posix timer implementation and add the discussed SIGEV_TIMERFD only internally in the kernel to signal the posix timer code new delivery mechanism. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
