Re: [PATCH] USB Elan FTDI: check for workqueue creation
On Thu, Feb 22, 2007 at 03:55:23PM -0800, Pete Zaitcev wrote: | On Mon, 19 Feb 2007 21:15:49 +0300, Cyrill Gorcunov <[EMAIL PROTECTED]> wrote: | | > +++ b/drivers/usb/misc/ftdi-elan.c | > @@ -57,9 +57,9 @@ module_param(distrust_firmware, bool, 0); | > MODULE_PARM_DESC(distrust_firmware, "true to distrust firmware power/overcurren" | > "t setup"); | > extern struct platform_driver u132_platform_driver; | > -static struct workqueue_struct *status_queue; | > +static struct workqueue_struct *status_queue = NULL; | | You better drop this part. Someone is bound to object. | | -- Pete | Hi, actually I don't understand why... Event on ftdi_elan_exit() status_queue is setting up to NULL. And what is bound to object? Could you write more detailed? 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/
off topic: Dolphin massacre in Japan
http://www.glumbert.com/media/dolphin http://www.petitiononline.com/golfinho PS: Before any smart-ass jumps in, effectively making this post a thread about what spam is, let me say that if I posted it to a dolphin or other related list, there would be no gain, as they should already be aware of it. My intent is_NOT_ to discuss the subject here (in this list). Only want to make people aware, and so, if they want they can sign the petition. So don't reply to say this is spam, because it may be, but unlike spam, it will serve its purpose anyway. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?
On Fri, 23 Feb 2007 08:13:30 +0100, Hans de Goede wrote: > I'm thinking that it might be an idea to also use this idea of udev > autoloading > through DMI info for the abituguru and abituguru3 driver (review please). The > both only support about 12 motherboards. For the abituguru driver, dmi info > could also be used to automatically set the module options needed on the 2 > oldest uguru featuring abit motherboards. What do you think about this? Given that the uguru chips are hard (impossible) to detect and only a small number of boards need it, yes, I think it's a good idea. -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?
Jean Delvare wrote:
On Wed, 21 Feb 2007 15:19:44 -0500, Dave Jones wrote:
Ah, Fedora has this horror in its initscripts (which explains why I missed
it in my grep)..
# Initialize ACPI bits
if [ -d /proc/acpi ]; then
for module in /lib/modules/$unamer/kernel/drivers/acpi/* ; do
module=${module##*/}
module=${module%.ko}
modprobe $module >/dev/null 2>&1
done
fi
Ah, this also explains why the i2c_ec and sbs drivers were loaded on
Chuck's system, although they were not needed.
This is there because there's no clean way for userspace to know whether
to load the system specific stuff right now. Bill Nottingham pointed
out that we could add a /sys/class/dmi/modalias and appropriate MODULE_DMI
tags to the various modules like asus_acpi to make udev autoload them.
Something similiar should be doable for i2c_ec, as it's only useful if a
given ACPI object is present. sbs, in turn, is only useful if i2c_ec is
loaded.
I'm thinking that it might be an idea to also use this idea of udev autoloading
through DMI info for the abituguru and abituguru3 driver (review please). The
both only support about 12 motherboards. For the abituguru driver, dmi info
could also be used to automatically set the module options needed on the 2
oldest uguru featuring abit motherboards. What do you think about this?
Regards,
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] module: use krealloc
From: Pekka Enberg <[EMAIL PROTECTED]>
This converts an open-coded krealloc() to use the shiny new API.
Cc: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
kernel/module.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: uml-2.6/kernel/module.c
===
--- uml-2.6.orig/kernel/module.c2007-02-23 09:24:14.0 +0200
+++ uml-2.6/kernel/module.c 2007-02-23 09:34:43.0 +0200
@@ -308,14 +308,14 @@
{
/* Reallocation required? */
if (pcpu_num_used + 1 > pcpu_num_allocated) {
- int *new = kmalloc(sizeof(new[0]) * pcpu_num_allocated*2,
- GFP_KERNEL);
+ int *new;
+
+ new = krealloc(pcpu_size, sizeof(new[0])*pcpu_num_allocated*2,
+ GFP_KERNEL);
if (!new)
return 0;
- memcpy(new, pcpu_size, sizeof(new[0])*pcpu_num_allocated);
pcpu_num_allocated *= 2;
- kfree(pcpu_size);
pcpu_size = new;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
raid 1 check and component device mismatches
Hello, Let me first start by saying that if a better place to ask these quesions is to be found, please let me know. I have a 2.6.20 kernel running a raid 1 set with two SATA disks. Recently (on an older (gentoo-specific) kernel) I started getting entries like this after my weekly 'echo check > /sys/block/md0/md/sync_action' mdadm: RebuildFinished event detected on md device /dev/md0, component device mismatches found : 375936 I have tried 'repair' a number of times but to no avail. The disks seem OK from their smart values and I have yet to discover an actual data problem. Still, I am a bit unsettled and would like to hear opinions. I have attached dmesg and smartctl -a output from both disks, if more is needed I am happy to provide. Thanks in advance, Rasmus 000 end: 1ffef000 type: 3 copy_e820_map() start: 1ffef000 size: 0001 end: 1000 type: 2 copy_e820_map() start: 1000 size: 1000 end: 2000 type: 4 copy_e820_map() start: size: 0001 end: 0001 type: 2 BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1ffec000 (usable) BIOS-e820: 1ffec000 - 1ffef000 (ACPI data) BIOS-e820: 1ffef000 - 1000 (reserved) BIOS-e820: 1000 - 2000 (ACPI NVS) BIOS-e820: - 0001 (reserved) 511MB LOWMEM available. Entering add_active_range(0, 0, 131052) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 131052 early_node_map[1] active PFN ranges 0:0 -> 131052 On node 0 totalpages: 131052 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 991 pages used for memmap Normal zone: 125965 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 ASUS ) @ 0x000f7930 ACPI: RSDT (v001 ASUS A7A266 0x42302e31 MSFT 0x31313031) @ 0x1ffec000 ACPI: FADT (v001 ASUS A7A266 0x42302e31 MSFT 0x31313031) @ 0x1ffec080 ACPI: BOOT (v001 ASUS A7A266 0x42302e31 MSFT 0x31313031) @ 0x1ffec040 ACPI: DSDT (v001 ASUS A7A266 0x1000 MSFT 0x010b) @ 0x ACPI: PM-Timer IO Port: 0xe408 Allocating PCI resources starting at 3000 (gap: 2000:dfff) Detected 1410.349 MHz processor. Built 1 zonelists. Total pages: 130029 Kernel command line: BOOT_IMAGE=2.6.20 ro root=902 root=/dev/ram0 lvm2root=/dev/data1/root elevator=cfq hda=none ide_setup: hda=none Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to d000 (01402000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 513016k/524208k available (2387k kernel code, 10660k reserved, 938k data, 188k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb7000 - 0xf000 ( 288 kB) vmalloc : 0xe080 - 0xfffb5000 ( 503 MB) lowmem : 0xc000 - 0xdffec000 ( 511 MB) .init : 0xc0442000 - 0xc0471000 ( 188 kB) .data : 0xc0354fda - 0xc043f8a4 ( 938 kB) .text : 0xc010 - 0xc0354fda (2387 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 2822.33 BogoMIPS (lpj=5644677) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383f9ff c1cbf9ff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383f9ff c1cbf9ff 0420 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Compat vDSO mapped to e000. CPU: AMD Athlon(TM) XP1600+ stepping 02 Checking 'hlt' instruction... OK. ACPI: Core revision 20060707 ACPI: setting ELCR to 0200 (from 1e60) NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf1170, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 *12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 *6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI
Re: 2.6.20-git15 BUG: soft lockup detected on CPU#0! - timers?
On Fri, 2007-02-23 at 07:08 +0100, Ingo Molnar wrote:
> Index: linux/kernel/sched.c
> ===
> --- linux.orig/kernel/sched.c
> +++ linux/kernel/sched.c
> @@ -4689,6 +4689,7 @@ int __sched cond_resched_softirq(void)
> BUG_ON(!in_softirq());
>
> if (need_resched() && system_state == SYSTEM_RUNNING) {
> + WARN_ON(current->state != TASK_RUNNING);
> raw_local_irq_disable();
> _local_bh_enable();
> raw_local_irq_enable();
I'm getting NOHZ: local_softirq_pending 02 or 10 every few seconds if
the box is doing anything, and the WARN_ON() has yet to trigger.
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]
Arjan van de Ven wrote: > if it's something built in the last year or two you have the hw. > > I have an ICH4-M, and from Intel's datasheets it looks like I got the short straw.. -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] fix the irq migration
"Siddha, Suresh B" <[EMAIL PROTECTED]> writes: > While debugging some other irq migration issue, observed this issue with > -git kernels. Ingo, please ACK it. > --- > > With the commit 76d2160147f43f982dfe881404cfde9fd0a9da21, irq_chip > default_disable() became an empty function. And with this change, irq > migration in the case of Edge triggered IO-APIC and MSI interrupts happens > with out masking the irq. > > Appended patch fixes by using the mask/unmask handlers of irq_chip directly > while doing the irq migration. Close. If the irq is disabled we need to bail out instead of skipping the masking. The masking is required for the function to run correctly and when IRQ_DISABLED is set we don't know enough to do anything. Once this is fixed we just need to fix the msi case where the hardware doesn't provide a mask bit. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] unionfs: fix slab abuses with krealloc
On Thu, Feb 22, 2007 at 02:41:16PM +0200, Pekka J Enberg wrote: > From: Pekka Enberg <[EMAIL PROTECTED]> > > This changes unionfs to use krealloc() for reallocating memory so that > we don't need to play tricks with slab internals. > > Cc: Josef Sipek <[EMAIL PROTECTED]> > Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]> I guess I should have Acked both patches... Acked-by: Josef 'Jeff' Sipek <[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/
circular locking: /proc/sys/vm/drop_caches
Andrew,
i just got the lockdep warning below when doing:
echo 3 > /proc/sys/vm/drop_caches
is this a known quirk in the drop_caches code?
Ingo
===
[ INFO: possible circular locking dependency detected ]
2.6.20-syslet #434
---
bash/12166 is trying to acquire lock:
(>j_list_lock){--..}, at: []
journal_try_to_free_buffers+0xd5/0x18f
but task is already holding lock:
(inode_lock){--..}, at: [] drop_pagecache+0x45/0xc8
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (inode_lock){--..}:
[] __lock_acquire+0x984/0xa94
[] lock_acquire+0x67/0x8c
[] _spin_lock+0x35/0x42
[] __mark_inode_dirty+0xe3/0x15e
[] __set_page_dirty_nobuffers+0xb4/0xbf
[] mark_buffer_dirty+0x1e/0x20
[] __journal_temp_unlink_buffer+0x176/0x17d
[] __journal_unfile_buffer+0xb/0x15
[] __journal_refile_buffer+0x6a/0xe3
[] journal_commit_transaction+0xf46/0x11da
[] kjournald+0xab/0x1e8
[] kthread+0xb2/0xd7
[] kernel_thread_helper+0x7/0x10
[] 0x
-> #0 (>j_list_lock){--..}:
[] __lock_acquire+0x87f/0xa94
[] lock_acquire+0x67/0x8c
[] _spin_lock+0x35/0x42
[] journal_try_to_free_buffers+0xd5/0x18f
[] ext3_releasepage+0x68/0x74
[] try_to_release_page+0x33/0x44
[] invalidate_mapping_pages+0x69/0xca
[] invalidate_inode_pages+0xd/0x11
[] drop_pagecache+0x61/0xc8
[] drop_caches_sysctl_handler+0x36/0x4e
[] do_rw_proc+0xaf/0xf1
[] proc_writesys+0x20/0x25
[] vfs_write+0xb1/0x165
[] sys_write+0x3d/0x61
[] syscall_call+0x7/0xb
[] 0x
other info that might help us debug this:
2 locks held by bash/12166:
#0: (>s_umount_key#17){}, at: [] drop_pagecache+0x35/0xc8
#1: (inode_lock){--..}, at: [] drop_pagecache+0x45/0xc8
stack backtrace:
[] show_trace_log_lvl+0x19/0x2e
[] show_trace+0x12/0x14
[] dump_stack+0x14/0x16
[] print_circular_bug_tail+0x5f/0x68
[] __lock_acquire+0x87f/0xa94
[] lock_acquire+0x67/0x8c
[] _spin_lock+0x35/0x42
[] journal_try_to_free_buffers+0xd5/0x18f
[] ext3_releasepage+0x68/0x74
[] try_to_release_page+0x33/0x44
[] invalidate_mapping_pages+0x69/0xca
[] invalidate_inode_pages+0xd/0x11
[] drop_pagecache+0x61/0xc8
[] drop_caches_sysctl_handler+0x36/0x4e
[] do_rw_proc+0xaf/0xf1
[] proc_writesys+0x20/0x25
[] vfs_write+0xb1/0x165
[] sys_write+0x3d/0x61
[] syscall_call+0x7/0xb
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 2.6.20 1/1] fbdev,mm: Deferred IO and hecubafb driver
Hi Tony, Paul, Peter, fbdev, lkml, and mm,
This is a first pass at abstracting deferred IO out from hecubafb and
into fbdev as was discussed before:
http://marc.theaimsgroup.com/?l=linux-fbdev-devel=117187443327466=2
Please let me know your feedback and if it looks okay so far.
Thanks,
jaya
Signed-off-by: Jaya Kumar <[EMAIL PROTECTED]>
---
Documentation/fb/deferred_io.txt | 114
drivers/video/Kconfig| 20 +
drivers/video/Makefile |2
drivers/video/fb_defio.c | 104 +++
drivers/video/fbmem.c|2
drivers/video/hecubafb.c | 513 +++
include/linux/fb.h | 25 +
mm/rmap.c|1
8 files changed, 781 insertions(+)
diff --git a/Documentation/fb/deferred_io.txt b/Documentation/fb/deferred_io.txt
new file mode 100644
index 000..be74dcc
--- /dev/null
+++ b/Documentation/fb/deferred_io.txt
@@ -0,0 +1,114 @@
+Deferred IO
+---
+
+Deferred IO is a way to delay and repurpose IO. It uses host memory as a
+buffer and the MMU pagefault as a pretrigger for when to perform the device
+IO. The following example may be a useful explaination of how one such setup
+works:
+
+- userspace app like Xfbdev mmaps framebuffer
+- deferred IO and driver sets up nopage and page_mkwrite handlers
+- userspace app tries to write to mmaped vaddress
+- we get pagefault and reach nopage handler
+- nopage handler finds and returns physical page
+- we get page_mkwrite where we add this page to a list
+- schedule a workqueue task to be run after a delay
+- app continues writing to that page with no additional cost. this is
+ the key benefit.
+- the workqueue task comes in and mkcleans the pages on the list, then
+ completes the work associated with updating the framebuffer. this is
+ the real work talking to the device.
+- app tries to write to the address (that has now been mkcleaned)
+- get pagefault and the above sequence occurs again
+
+As can be seen from above, one benefit is roughly to allow bursty framebuffer
+writes to occur at minimum cost. Then after some time when hopefully things
+have gone quiet, we go and really update the framebuffer which would be
+a relatively more expensive operation.
+
+For some types of nonvolatile high latency displays, the desired image is
+the final image rather than the intermediate stages which is why it's okay
+to not update for each write that is occuring.
+
+It may be the case that this is useful in other scenarios as well. Paul Mundt
+has mentioned a case where it is beneficial to use the page count to decide
+whether to coalesce and issue SG DMA or to do memory bursts.
+
+Another one may be if one has a device framebuffer that is in an usual format,
+say diagonally shifting RGB, this may then be a mechanism for you to allow
+apps to pretend to have a normal framebuffer but reswizzle for the device
+framebuffer at vsync time based on the touched pagelist.
+
+How to use it: (for applications)
+-
+No changes needed. mmap the framebuffer like normal and just use it.
+
+How to use it: (for fbdev drivers)
+--
+The following example may be helpful.
+
+1. Setup your mmap and vm_ops structures. Eg:
+
+static struct fb_deferred_io hecubafb_defio = {
+ .delay = HZ,
+ .deferred_io= hecubafb_dpy_deferred_io,
+};
+
+The delay is the minimum delay between when the page_mkwrite trigger occurs
+and when the deferred_io callback is called. The deferred_io callback is
+explained below.
+
+static struct vm_operations_struct hecubafb_vm_ops = {
+ .nopage = hecubafb_vm_nopage,
+ .page_mkwrite = fb_deferred_io_mkwrite,
+};
+
+You will need a nopage routine to find and retrive the struct page for your
+framebuffer pages. You must set page_mkwrite to fb_deferred_io_mkwrite.
+Here's the example nopage for hecubafb where it is a vmalloced framebuffer.
+
+static int hecubafb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ vma->vm_ops = _vm_ops;
+ vma->vm_flags |= ( VM_IO | VM_RESERVED | VM_DONTEXPAND );
+ vma->vm_private_data = info;
+ return 0;
+}
+
+static struct page* hecubafb_vm_nopage(struct vm_area_struct *vma,
+ unsigned long vaddr, int *type)
+{
+ unsigned long offset;
+ struct page *page;
+ struct fb_info *info = vma->vm_private_data;
+
+ offset = (vaddr - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT);
+ if (offset >= (DPY_W*DPY_H)/8)
+ return NOPAGE_SIGBUS;
+
+ page = vmalloc_to_page(info->screen_base + offset);
+ if (!page)
+ return NOPAGE_OOM;
+
+ get_page(page);
+ if (type)
+ *type = VM_FAULT_MINOR;
+ return page;
+}
+
+2. Setup your deferred IO callback. Eg:
+static void hecubafb_dpy_deferred_io(struct fb_info *info,
+ struct
Transparent bridges, assign_busses and poweroff/tsc problems
Hi all I have previously posted regarding a message about a transparent bridge message I get when booting my laptop. PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO PCI quirk: region 1180-11bf claimed by ICH6 GPIO PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 PCI: Transparent bridge - :00:1e.0 PCI: Bus #07 (-#0a) is hidden behind transparent bridge #06 (-#07) (try 'pci=assign-busses') Please report the result to linux-kernel to fix this permanently There doesn't appear to be any ill-effects from this, but a permanent fix is probably a good thing and so I'm reporting it. I have however tried "pci=assign-busses" as suggested. While this does make the above complaint go away, it introduces two other things, one a lot more serious. The first thing I've noticed is that when "pci=assign-busses" has been specified, I get the following in the dmesg: Clocksource tsc unstable (delta = -434140355 ns) I don't seem to get this if assignbusses hasn't been given. The second effect of "pci=assign-busses" is that it prevents Linux powering the laptop off; pressing the power button triggers an ACPI event as it should and Linux proceeds to close everything down. However, when it comes time to actually kill the power the screen goes blank and the backlight gets turned off, but power remains on until I force it off by holding the power button down for 4 seconds. I have verified this with 2.6.18, 2.6.19 and 2.6.20. Furthermore, the RT patchset does not change the behaviour. Something mighty odd seems to be going on here. Does anyone have any ideas or suggestions of things to try? Regards jonathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] s390: do not use _local_bh_enable()
Heiko, what do you think about the patch below - is there perhaps some deeper reason to s390's _local_bh_enable() use that i missed? Ingo --> Subject: [patch] s390: do not use _local_bh_enable() From: Ingo Molnar <[EMAIL PROTECTED]> _local_bh_enable() enables bhs without invoke_softirqs(), and can thus cause missed softirq processing. The s390 code seems to have two such uses of _local_bh_enable(). in cio.c the bh disable/enable pair is superfluous, because irq_enter()/exit() disables softirqs anyway. Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- drivers/s390/char/sclp.c |2 +- drivers/s390/cio/cio.c |3 +-- 2 files changed, 2 insertions(+), 3 deletions(-) Index: linux/drivers/s390/char/sclp.c === --- linux.orig/drivers/s390/char/sclp.c +++ linux/drivers/s390/char/sclp.c @@ -407,8 +407,8 @@ sclp_sync_wait(void) } local_irq_disable(); __ctl_load(cr0, 0, 0); - _local_bh_enable(); local_irq_restore(flags); + local_bh_enable(); } EXPORT_SYMBOL(sclp_sync_wait); Index: linux/drivers/s390/cio/cio.c === --- linux.orig/drivers/s390/cio/cio.c +++ linux/drivers/s390/cio/cio.c @@ -140,7 +140,6 @@ cio_tpi(void) sch = (struct subchannel *)(unsigned long)tpi_info->intparm; if (!sch) return 1; - local_bh_disable(); irq_enter (); spin_lock(sch->lock); memcpy (>schib.scsw, >scsw, sizeof (struct scsw)); @@ -148,7 +147,7 @@ cio_tpi(void) sch->driver->irq(>dev); spin_unlock(sch->lock); irq_exit (); - _local_bh_enable(); + return 1; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AE_NOT_FOUND, (Re: [ACPI] Several remarks for 9654640d0af8f2de40ff3807d3695109d3463f54)
On Thursday 22 February 2007 14:08, Thomas Meyer wrote: > 1.) My kde klaptopdaemon icon is gone. This icon displayed the remaining > battery time. This is maybe a kde problem? > > 2.) I get these new messages in the kernel log buffer: > [...] > ACPI: bus type pci registered > PCI: Using MMCONFIG > Setting up standard PCI resources > ACPI Exception (evregion-0420): AE_NOT_FOUND, Returned by Handler for > [EmbeddedControl] [20070126] > ACPI Exception (dswexec-0462): AE_NOT_FOUND, While resolving operands > for [OpcodeName unavailable] [20070126] > ACPI Error (psparse-0537): Method parse/execution failed > [\_SB_.PCI0.LPCB.EC__._REG] (Node c190db1c), AE_NOT_FOUND > ACPI Exception (ec-0956): AE_NOT_FOUND, Could not use ECDT [20070126] > ACPI: Interpreter enabled > ACPI: (supports S0 S3 S4 S5) > ACPI: Using IOAPIC for interrupt routing > [...] > ACPI Exception (evregion-0420): AE_NOT_FOUND, Returned by Handler for > [EmbeddedControl] [20070126] > ACPI Exception (dswexec-0462): AE_NOT_FOUND, While resolving operands > for [OpcodeName unavailable] [20070126] > ACPI Error (psparse-0537): Method parse/execution failed > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node c190dbbc), AE_NOT_FOUND > ACPI Error (psparse-0537): Method parse/execution failed > [\_SB_.BAT0.UBSS] (Node c190da2c), AE_NOT_FOUND > ACPI Error (psparse-0537): Method parse/execution failed > [\_SB_.BAT0._STA] (Node c190da7c), AE_NOT_FOUND > ACPI Exception (evregion-0420): AE_NOT_FOUND, Returned by Handler for > [EmbeddedControl] [20070126] > ACPI Error (psparse-0537): Method parse/execution failed > [\_SB_.PCI0.LPCB.EC__._REG] (Node c190db1c), AE_NOT_FOUND > ACPI Exception (evregion-0513): AE_NOT_FOUND, from region _REG, > [EmbeddedControl] [20070126] > ACPI: PCI Root Bridge [PCI0] (:00) > > But i guess this is ok and seems to be an acpi problem on my computer, > aren't they? Please open a bug report here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI and please attach (don't paste) the complete output from dmesg -s64000 plus the output from acpidump > acpidump.out. If you don't have acpidump, you can get it from the latest pmtools here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ please also attach the config file you're using. thanks, -Len ps. linux-acpi list added to cc: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] dma-mapping-broken.h: flesh-out DMA API stubs
How about this for telling that an architecture doesn't support DMA? At least we could get rid of dma-mapping-broken.h and don't need to compile some afterwards dead code. Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> --- arch/s390/Kconfig |3 +++ drivers/base/Makefile |4 ++-- include/asm-s390/dma-mapping.h |2 -- lib/Kconfig|5 + 4 files changed, 10 insertions(+), 4 deletions(-) Index: linux-2.6/arch/s390/Kconfig === --- linux-2.6.orig/arch/s390/Kconfig +++ linux-2.6/arch/s390/Kconfig @@ -44,6 +44,9 @@ config GENERIC_TIME config NO_IOMEM def_bool y +config NO_DMA + def_bool y + mainmenu "Linux Kernel Configuration" config S390 Index: linux-2.6/drivers/base/Makefile === --- linux-2.6.orig/drivers/base/Makefile +++ linux-2.6/drivers/base/Makefile @@ -2,10 +2,10 @@ obj-y := core.o sys.o bus.o dd.o \ driver.o class.o platform.o \ - cpu.o firmware.o init.o map.o dmapool.o \ - dma-mapping.o devres.o \ + cpu.o firmware.o init.o map.o devres.o \ attribute_container.o transport_class.o obj-y += power/ +obj-$(CONFIG_DMA) += dma-mapping.o dmapool.o obj-$(CONFIG_ISA) += isa.o obj-$(CONFIG_FW_LOADER)+= firmware_class.o obj-$(CONFIG_NUMA) += node.o Index: linux-2.6/include/asm-s390/dma-mapping.h === --- linux-2.6.orig/include/asm-s390/dma-mapping.h +++ linux-2.6/include/asm-s390/dma-mapping.h @@ -9,6 +9,4 @@ #ifndef _ASM_DMA_MAPPING_H #define _ASM_DMA_MAPPING_H -#include - #endif /* _ASM_DMA_MAPPING_H */ Index: linux-2.6/lib/Kconfig === --- linux-2.6.orig/lib/Kconfig +++ linux-2.6/lib/Kconfig @@ -111,4 +111,9 @@ config HAS_IOPORT depends on HAS_IOMEM && !NO_IOPORT default y +config HAS_DMA + boolean + depends on !NO_DMA + default y + endmenu -- Heiko Carstens Linux on System z Development IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Johann Weihen Geschaeftsfuehrung : Herbert Kircher Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-git15 BUG: soft lockup detected on CPU#0! - timers?
Michal,
* Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Here is more
>
> hardirqs last enabled at (30787): [] syscall_exit_work+0x11/0x26
> hardirqs last disabled at (30788): [] ret_from_exception+0x9/0xc
> softirqs last enabled at (30202): [] __do_softirq+0xe4/0xea
> softirqs last disabled at (30193): [] do_softirq+0x64/0xd1
could you please try the patch below? This is pretty much the only
condition under which we can silently 'leak' pending softirqs, and
trigger the new warning: if something does cond_resched_softirq() in
non-runnable state. (which is a no-no, but nothing enforced this, so it
could in theory happen.) So the question is, with this patch applied, do
you get these new warnings from sched.c?
Ingo
-->
Subject: [patch] add warning to cond_resched_softirq()
From: Ingo Molnar <[EMAIL PROTECTED]>
make sure that cond_resched_softirq() is always called with a runnable
task - so that we do not leave softirq work pending indefinitely.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
kernel/sched.c |1 +
1 file changed, 1 insertion(+)
Index: linux/kernel/sched.c
===
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -4689,6 +4689,7 @@ int __sched cond_resched_softirq(void)
BUG_ON(!in_softirq());
if (need_resched() && system_state == SYSTEM_RUNNING) {
+ WARN_ON(current->state != TASK_RUNNING);
raw_local_irq_disable();
_local_bh_enable();
raw_local_irq_enable();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc1: Ethernet card not detected correctly
My Ethernet card worked fine up through 2.6.20, but starting with 2.6.21-rc1, I get the following: Feb 22 23:27:39 gherkin kernel: natsemi dp8381x driver, version 2.1, Sept 11, 2006 Feb 22 23:27:39 gherkin kernel: originally by Donald Becker <[EMAIL PROTECTED]> Feb 22 23:27:39 gherkin kernel: http://www.scyld.com/network/natsemi.html Feb 22 23:27:39 gherkin kernel: 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder Feb 22 23:27:39 gherkin kernel: PCI: setting IRQ 12 as level-triggered Feb 22 23:27:39 gherkin kernel: PCI: Found IRQ 12 for device :00:0a.0 Feb 22 23:27:39 gherkin kernel: PCI: Sharing IRQ 12 with :00:08.1 Feb 22 23:27:39 gherkin kernel: natsemi eth0: Aculab E1/T1 PMXc cPCI carrier card at 0xdf005000 (:00:0a.0), 00:02:e3:15:25:90, IRQ 12, port MII, ignoring PHY Feb 22 23:27:42 gherkin kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 22 23:27:42 gherkin kernel: eth0: Transmit timed out, status 0x000200, resetting... (above two lines repeated until reboot) Here's the 2.6.20 output for comparison: Feb 22 23:31:23 gherkin kernel: natsemi dp8381x driver, version 2.1, Sept 11, 2006 Feb 22 23:31:23 gherkin kernel: originally by Donald Becker <[EMAIL PROTECTED]> Feb 22 23:31:23 gherkin kernel: http://www.scyld.com/network/natsemi.html Feb 22 23:31:23 gherkin kernel: 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder Feb 22 23:31:23 gherkin kernel: PCI: setting IRQ 12 as level-triggered Feb 22 23:31:23 gherkin kernel: PCI: Found IRQ 12 for device :00:0a.0 Feb 22 23:31:23 gherkin kernel: PCI: Sharing IRQ 12 with :00:08.1 Feb 22 23:31:23 gherkin kernel: natsemi eth0: NatSemi DP8381[56] at 0xdf005000 (:00:0a.0), 00:02:e3:15:25:90, IRQ 12, port TP. -- --- Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org [EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/18] bcm43xx: Fix for oops on resume
Hi! > -stable review patch. If anyone has any objections, please let us know. > > -- > From: Larry Finger <[EMAIL PROTECTED]> > > There is a kernel oops on bcm43xx when resuming due to an overly tight > timeout loop. > > Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > --- > drivers/net/wireless/bcm43xx/bcm43xx.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx.h > +++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx.h > @@ -21,7 +21,7 @@ > #define PFX KBUILD_MODNAME ": " > > #define BCM43xx_SWITCH_CORE_MAX_RETRIES 50 > -#define BCM43xx_IRQWAIT_MAX_RETRIES 50 > +#define BCM43xx_IRQWAIT_MAX_RETRIES 100 > > #define BCM43xx_IO_SIZE 8192 I'm sorry, but this does not look like fixing an oops. It may make it go away for you, or make it less probable, but it certainly can't fix it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21-rc1 -- suspend
Hi! > Ok, the merge window for 2.6.21 has closed, and -rc1 is out there. > > There's a lot of changes, as is usual for an -rc1 thing, but at least so > far it would seem that 2.6.20 has been a good base, and I don't think we > have anything *really* scary here. And lot of acpi/suspend changes, which seem to break my machine in weird and not really reproducible way. I'm looking onto that. (Yep, that should teach me to test -mm a bit more). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc1: Ethernet card not detected correctly (followup)
I forgot to include some possibly useful "lspci -v" output. This is while running 2.6.20: 00:0a.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller Subsystem: Netgear FA311 / FA312 (FA311 with WoL HW) Flags: bus master, medium devsel, latency 32, IRQ 12 I/O ports at dc00 [size=256] Memory at df005000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at 2002 [disabled] [size=64K] Capabilities: [40] Power Management version 2 -- --- Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org [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/
input.c: start on release
Here's a curious code I found in drivers/input/input.c (2.6.21-rc1):
void input_release_device(struct input_handle *handle)
{
if (handle->handler->start)
handle->handler->start(handle);
}
Is the above supposed to be this way, or you meant ->stop here?
The commit comment says:
Input: fix list iteration in input_release_device()
It says me precisely nothing about the way it's supposed ot be, sorry...
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] file caps: accomodate future 64-bit caps
Here is another attempt. This format is compatible with
KaiGai's current tools.
Tested on s390 with 32 and 64-bit caps stored in the xattrs.
-serge
From: "Serge E. Hallyn" <[EMAIL PROTECTED]>
Subject: [PATCH 2/2] file caps: accomodate future 64-bit caps
As the capability set changes and distributions start tagging
binaries with capabilities, we would like for running an older
kernel to not necessarily make those binaries unusable.
(1. Rename CONFIG_SECURITY_FS_CAPABILITIES to
CONFIG_SECURITY_FILE_CAPABILITIES)
2. Introduce CONFIG_SECURITY_FILE_CAPABILITIES_STRICTXATTR
which, when set, prevents loading binaries with capabilities
set which the kernel doesn't know about. When not set,
such capabilities run, ignoring the unknown caps.
3. To accomodate 64-bit caps, specify that capabilities are
stored as
u32 version; u32 eff0; u32 perm0; u32 inh0;
u32 eff1; u32 perm1; u32 inh1; (etc)
Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
---
include/linux/capability.h | 23 ++
security/Kconfig | 12 +++
security/commoncap.c | 157
3 files changed, 131 insertions(+), 61 deletions(-)
987fe7fcd60aaea6aaa86e6eb24a35f8bf2bdc68
diff --git a/include/linux/capability.h b/include/linux/capability.h
index 2776886..4dbfef3 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -44,11 +44,28 @@ typedef struct __user_cap_data_struct {
#define XATTR_CAPS_SUFFIX "capability"
#define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
+
+/* size of caps that we work with */
+#define XATTR_CAPS_SZ (4*sizeof(__le32))
+
+/*
+ * data[] is organized as:
+ * effective[0]
+ * permitted[0]
+ * inheritable[0]
+ * effective[1]
+ * ...
+ * this way we can just read as much of the on-disk capability as
+ * we know should exist and know we'll get the data we'll need.
+ */
struct vfs_cap_data_disk {
__le32 version;
- __le32 effective;
- __le32 permitted;
- __le32 inheritable;
+ __le32 data[]; /* eff[0], perm[0], inh[0], eff[1], ... */
+};
+
+struct vfs_cap_data_disk_v1 {
+ __le32 version;
+ __le32 data[3]; /* eff[0], perm[0], inh[0] */
};
#ifdef __KERNEL__
diff --git a/security/Kconfig b/security/Kconfig
index bc5b1be..3d5de26 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -88,7 +88,7 @@ config SECURITY_CAPABILITIES
This enables the "default" Linux capabilities functionality.
If you are unsure how to answer this question, answer Y.
-config SECURITY_FS_CAPABILITIES
+config SECURITY_FILE_CAPABILITIES
bool "File POSIX Capabilities"
depends on SECURITY=n || SECURITY_CAPABILITIES!=n
default n
@@ -98,6 +98,16 @@ config SECURITY_FS_CAPABILITIES
If in doubt, answer N.
+config SECURITY_FILE_CAPABILITIES_STRICTXATTR
+ bool "Refuse to run files with unknown caps"
+ depends on SECURITY_FILE_CAPABILITIES
+ default y
+ help
+ Refuse to run files which have unknown capabilities set
+ in the security.capability xattr. This could prevent
+ running important binaries from an updated distribution
+ on an older kernel.
+
config SECURITY_ROOTPLUG
tristate "Root Plug Support"
depends on USB && SECURITY
diff --git a/security/commoncap.c b/security/commoncap.c
index be86acb..86894be 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -110,36 +110,73 @@ void cap_capset_set (struct task_struct
target->cap_permitted = *permitted;
}
-#ifdef CONFIG_SECURITY_FS_CAPABILITIES
-static inline void cap_from_disk(struct vfs_cap_data_disk *dcap,
- struct vfs_cap_data *cap)
+#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
+
+#ifdef CONFIG_SECURITY_FILE_CAPABILITIES_STRICTXATTR
+static int check_cap_sanity(struct vfs_cap_data_disk *dcap, int size)
{
- cap->version = le32_to_cpu(dcap->version);
- cap->effective = le32_to_cpu(dcap->effective);
- cap->permitted = le32_to_cpu(dcap->permitted);
- cap->inheritable = le32_to_cpu(dcap->inheritable);
+ int word, bit;
+ u32 eff, inh, perm;
+ int sz = (size-1)/3;
+
+ word = CAP_NUMCAPS / 32;
+ bit = CAP_NUMCAPS % 32;
+
+ eff = le32_to_cpu(dcap->data[3*word]);
+ perm = le32_to_cpu(dcap->data[3*word+1]);
+ inh = le32_to_cpu(dcap->data[3*word+2]);
+
+ while (word < sz) {
+ if (bit == 32) {
+ bit = 0;
+ word++;
+ if (word >= sz)
+ break;
+ eff = le32_to_cpu(dcap->data[3*word]);
+ perm = le32_to_cpu(dcap->data[3*word+1]);
+ inh = le32_to_cpu(dcap->data[3*word+2]);
+ continue;
+ }
+
Re: BUG in 2.6.20-git15, Suspend to disk
Rafael J. Wysocki wrote: > Hi, > > On Friday, 23 February 2007 00:04, Lukas Hejtmanek wrote: >> Hello, >> >> after some time I've tried to suspend to disk. It basically works but it >> complains into log with the following message: > > Tejun says it is known and he's going to fix it. Patch went into libata-dev. Will soon propagate to Linus's tree. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SLUB: The unqueued Slab allocator
On Fri, 23 Feb 2007, Andi Kleen wrote: > If you don't cache constructed but free objects then there is no cache > advantage of constructors/destructors and they would be useless. SLUB caches those objects as long as they are part of a partially allocated slab. If all objects in the slab are freed then the whole slab will be freed. SLUB does not keep queues of freed slabs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Areca driver 2.6.19 on x86_64
These solutions are laughable Areca Support wrote: > > Dear Sir, > > This is Kevin Wang from Areca Technology, Tech-Support Team. > regarding your problem, please trying to disable ACPI in kernel loader. > if the problem happen as soon as driver loaded, it should be the IRQ > releated issue. > the motherboard bios didn't assigned a correct IRQ to controller, it makes > the driver can't initialize controller. > and in our experience, disable ACPI in kernel loader can solved this ussue > in some distro. > > > Best Regards, > > > Kevin Wang > > Areca Technology Tech-support Division > Tel : 886-2-87974060 Ext. 223 > Fax : 886-2-87975970 > Http://www.areca.com.tw > Ftp://ftp.areca.com.tw > > - Original Message - > From: "Bron Gondwana" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; ; > <[EMAIL PROTECTED]> > Sent: Thursday, December 07, 2006 7:09 AM > Subject: Re: Areca driver 2.6.19 on x86_64 > > >> On Wed, Dec 06, 2006 at 05:51:32PM +0100, [EMAIL PROTECTED] wrote: >> > OS distro used: >> > CentOS 4.4 x86_64 >> > Kernel 2.6.19 with hand-crafted config, that we are >> > able to use successfully with kernel 2.6.16.20. >> >> What patches were you applying to 2.6.16.20, since that didn't >> have an Areca driver in it I presume you're at least using that. >> >> > Have you any suggestions to resolve this issue ? >> >> 32 bit kernel? I'm somewhat serious here, depending what applications >> you're running on the machine. >> >> Otherwise, no clue sorry - we're running 32 bit kernels everywhere >> even on the couple of new Core machines we have. >> >> Bron. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > -- View this message in context: http://www.nabble.com/Areca-driver-2.6.19-on-x86_64-tf2769326.html#a9113207 Sent from the linux-kernel mailing list archive at Nabble.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] dma-mapping-broken.h: flesh-out DMA API stubs
On Thu, Feb 22, 2007 at 07:59:45PM -0500, John W. Linville wrote: > This allows some drivers compile on arches that don't support DMA > (e.g. s390). Which drivers are we talking about? Last time I checked an allmodconfig just compiled. I'd rather like to the opposite: rip out everything that depends on DMA (via e.g. CONFIG_HAS_DMA), so we don't have to compile in all the unused code. If that is is possible... -- Heiko Carstens Linux on System z Development IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Johann Weihen Geschaeftsfuehrung : Herbert Kircher Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Modprobe as script breaks initramfs kernel?
On Feb 22 2007, at 19:44, Jan Engelhardt was caught saying: > > On Feb 22 2007 14:30, Michael Tokarev wrote: > >Deepak Saxena wrote: > >> We attempted an experiment in cleaning up some modprobe messages during > >> initramfs bootup when the modules directory is missing by moving modprobe > >> to modprobe-bin and replacing modprobe with the following simple shell > >> script: > >> > >> #!/bin/sh > >> # Clean up bootup when modules are not present > >> > >> if [ -e "/lib/modules/'uname -r'/modules.dep" ] ; then > >>/sbin/modprobe-bin $* > > The nitpick guide says: `uname -r` and "$@" instead of $* ;-) Yeah. The quotes were a typo in my email. :) > >This is the same issue I reported much earlier with /sbin/hotplug being a > >script > >in initrfamfs. The problem is because pipefs isn't initialized yet at the > >time > >the script gets called, and causes a NULL-pointer deref. Obviously you're > >using > >pipe above. > > Btw, has this pipefs issue been adressed (by moving pipefs before initramfs > stage), or something? If it hasn't, it's now on my todo list. -- Deepak Saxena - [EMAIL PROTECTED] - http://www.plexity.net In the end, they will not say, "those were dark times," they will ask "why were their poets silent?" - Bertolt Brecht - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Allow kernel to build on Cygwin
This patch contains a set of small fixes to allow the kernel to build under
the Cygwin environment, which is unfortunately used by more people than
one would think in the embedded world. :(
Signed-off-by: Deepak Saxena <[EMAIL PROTECTED]>
---
lib/gen_crc32table.c |2 ++
scripts/kconfig/Makefile |6 ++
scripts/kconfig/lxdialog/check-lxdialog.sh |4
scripts/mod/file2alias.c |4
scripts/mod/mk_elfconfig.c |4
scripts/mod/modpost.h |4
scripts/mod/sumversion.c |6 +-
7 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/lib/gen_crc32table.c b/lib/gen_crc32table.c
index bea5d97..ce447ff 100644
--- a/lib/gen_crc32table.c
+++ b/lib/gen_crc32table.c
@@ -1,6 +1,8 @@
#include
#include "crc32defs.h"
+#ifndef __CYGWIN__
#include
+#endif
#define ENTRIES_PER_LINE 4
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 7e7e147..ca57efe 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -161,6 +161,12 @@ HOSTLOADLIBES_gconf= `pkg-config --libs
HOSTCFLAGS_gconf.o = `pkg-config --cflags gtk+-2.0 gmodule-2.0
libglade-2.0` \
-D LKC_DIRECT_LINK
+HOST_OS := $(shell uname -o)
+ifeq ($(HOST_OS),Cygwin)
+HOSTLOADLIBES_mconf= -lintl
+HOSTLOADLIBES_conf = -lintl
+endif
+
$(obj)/qconf.o: $(obj)/.tmp_qtcheck
ifeq ($(qconf-target),1)
diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh
b/scripts/kconfig/lxdialog/check-lxdialog.sh
index 120d624..c44b559 100644
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -4,6 +4,10 @@ # Check ncurses compatibility
# What library to link
ldflags()
{
+ if [ "`uname -o`" == "Cygwin" ]; then
+ echo '-lintl -lncurses'
+ exit
+ fi
$cc -print-file-name=libncursesw.so | grep -q /
if [ $? -eq 0 ]; then
echo '-lncursesw'
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index f61c9cc..479293f 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -29,7 +29,11 @@ #endif
#include
+#if defined(__CYGWIN__)
+typedef __uint32_t __u32;
+#else
typedef uint32_t __u32;
+#endif
typedef uint16_t __u16;
typedef unsigned char __u8;
diff --git a/scripts/mod/mk_elfconfig.c b/scripts/mod/mk_elfconfig.c
index 725d61c..4908f7a 100644
--- a/scripts/mod/mk_elfconfig.c
+++ b/scripts/mod/mk_elfconfig.c
@@ -1,7 +1,11 @@
#include
#include
#include
+#ifdef __CYGWIN__
+#include
+#else
#include
+#endif
int
main(int argc, char **argv)
diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h
index d398c61..7cdf2c6 100644
--- a/scripts/mod/modpost.h
+++ b/scripts/mod/modpost.h
@@ -7,7 +7,11 @@ #include
#include
#include
#include
+#ifdef __CYGWIN__
+#include
+#else
#include
+#endif
#include "elfconfig.h"
diff --git a/scripts/mod/sumversion.c b/scripts/mod/sumversion.c
index 8a28756..4404f87 100644
--- a/scripts/mod/sumversion.c
+++ b/scripts/mod/sumversion.c
@@ -1,7 +1,11 @@
+#if defined(__sun__)
#include
-#ifdef __sun__
#include
+#elif defined(__CYGWIN__)
+#include /* For ntohl/htonl */
+#include
#else
+#include
#include
#endif
#include
--
Deepak Saxena - [EMAIL PROTECTED] - http://www.plexity.net
In the end, they will not say, "those were dark times," they will ask
"why were their poets silent?" - Bertolt Brecht
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] sched: dynticks idle load balancing - v2
On Thu, Feb 22, 2007 at 02:33:00PM -0800, Suresh B wrote: > On Thu, Feb 22, 2007 at 04:26:54AM +0100, Nick Piggin wrote: > > This is really ugly, sorry :( > > hm. myself and others too thought it was a simple and nice idea. The idea is not bad. I won't guarantee mine will be as good or better, but I think it is sensible to try implementing the simplest approach first, so we can get a baseline to justify more complexity against... Your code just needs work, but if it really produces good results then it should be able to be made into a mergeable patch. > > My suggestion for handling this was to increase the maximum balance > > interval for an idle CPU, and just implement a global shutdown when > > the entire system goes idle. > > > > The former should take care of the power savings issues for bare metal > > hardware, and the latter should solve performance problems for many idle > > SMP guests. It should take very little code to implement. > > coming to max balance interval will be challenging. It needs to save > power and at the same time respond to load changes fast enough. Yep. > > If that approach doesn't cut it, then at least we can have some numbers > > to see how much better yours is so we can justify including it. > > > > If you are against my approach, then I can have a try at coding it up > > if you like? > > Sure. If you can provide a patch, I will be glad to provide power and > performance comparision numbers with both the approaches. OK that would be good. I'll see if I can code something up by next week. Thanks, Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] free swap space when (re)activating page
Bodo Eggert wrote:
Rik van Riel <[EMAIL PROTECTED]> wrote:
+++ linux-2.6.20.noarch/mm/swap.c2007-02-20 06:44:17.0 -0500
@@ -420,6 +420,26 @@ void pagevec_strip(struct pagevec *pvec)
+if (printk_ratelimit())
+printk("kswapd freed a swap space\n");
NOO!!!
1) This message is a debug message! You forgot to set the printk level.
Doh, I forgot to cut it out of the patch when I fixed it
according to Christoph's hint.
This chunk should be removed from the patch...
Andrew, I'll send you a new one tomorrow morning.
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc5 1/1] MM: enhance Linux swap subsystem
yunfeng zhang wrote: Performance improvement should occur when private pages of multiple processes are messed up, Ummm, yes. Linux used to do this, but doing virtual scans just does not scale when a system has a really large amount of memory, a large number of processes and multiple zones. We've seen it fall apart with as little as 8GB of RAM. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] UML utrace support, step 1
> OK, I'll do it this way. Your replacement patch still has utrace_regset stuff in it, so it doesn't compile without the later patches in the series. Try applying only utrace-tracehook.patch from the series, then get it to build and make your utrace-tracehook-um.patch. Then apply only utrace-regset.patch on top of that, and get that building to make utrace-regset-um.patch. Then apply utrace-core.patch and utrace-ptrace-compat.patch to get ptrace finally working again and make utrace-ptrace-compat-um.patch. > Yup, I'll leave this here, with .name initialized as SUBARCH, with the > regsets defined in sys-$(ARCH) somewhere. You'll still find this insufficient when you get to biarch support (x86_64). At least you'll have to add another one elsewhere too, and make utrace_native_view refer to both. > Fixed. block-step is hardware-trap-on-branch or something similar? Correct. > No, this is with preempt off. Ok. We do seem to have a problem when the host has CONFIG_PREEMPT=y, which makes me suspect it might be a race problem that could also hit with enough hardware parallelism. If you get a chance to try that and can characterize the way it misbehaves at the level of specific ptrace/wait calls, that would be a great help. Otherwise I'll try to look into it when I get some time, but it's falling down the queue a bit since people don't seem too put out about it right now. Thanks very much, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Make hvc_console.c compile on non-powerpc: Remove NO_IRQ
Linus, please apply. Andrew, please drop the other hvc_console patch
you have.
Paulus preferred this over #defining NO_IRQ in the file, since that's
0 for powerpc anyway.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Acked-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/dontdiff
--minimal linux-2.6.21-rc1/drivers/char/hvc_console.c
working-2.6.21-rc1-NO_IRQ/drivers/char/hvc_console.c
--- linux-2.6.21-rc1/drivers/char/hvc_console.c 2007-02-05 17:30:59.0
+1100
+++ working-2.6.21-rc1-NO_IRQ/drivers/char/hvc_console.c2007-02-23
14:03:26.0 +1100
@@ -316,7 +316,7 @@ static int hvc_open(struct tty_struct *t
{
struct hvc_struct *hp;
unsigned long flags;
- int irq = NO_IRQ;
+ int irq = 0;
int rc = 0;
struct kobject *kobjp;
@@ -338,14 +338,14 @@ static int hvc_open(struct tty_struct *t
hp->tty = tty;
/* Save for request_irq outside of spin_lock. */
irq = hp->irq;
- if (irq != NO_IRQ)
+ if (irq)
hp->irq_requested = 1;
kobjp = >kobj;
spin_unlock_irqrestore(>lock, flags);
/* check error, fallback to non-irq */
- if (irq != NO_IRQ)
+ if (irq)
rc = request_irq(irq, hvc_handle_interrupt, IRQF_DISABLED,
"hvc_console", hp);
/*
@@ -373,7 +373,7 @@ static void hvc_close(struct tty_struct
{
struct hvc_struct *hp;
struct kobject *kobjp;
- int irq = NO_IRQ;
+ int irq = 0;
unsigned long flags;
if (tty_hung_up_p(filp))
@@ -407,7 +407,7 @@ static void hvc_close(struct tty_struct
*/
tty_wait_until_sent(tty, HVC_CLOSE_WAIT);
- if (irq != NO_IRQ)
+ if (irq)
free_irq(irq, hp);
} else {
@@ -424,7 +424,7 @@ static void hvc_hangup(struct tty_struct
{
struct hvc_struct *hp = tty->driver_data;
unsigned long flags;
- int irq = NO_IRQ;
+ int irq = 0;
int temp_open_count;
struct kobject *kobjp;
@@ -453,7 +453,7 @@ static void hvc_hangup(struct tty_struct
irq = hp->irq;
hp->irq_requested = 0;
spin_unlock_irqrestore(>lock, flags);
- if (irq != NO_IRQ)
+ if (irq)
free_irq(irq, hp);
while(temp_open_count) {
--temp_open_count;
@@ -583,7 +583,7 @@ static int hvc_poll(struct hvc_struct *h
/* If we aren't interrupt driven and aren't throttled, we always
* request a reschedule
*/
- if (hp->irq == NO_IRQ)
+ if (hp->irq == 0)
poll_mask |= HVC_POLL_READ;
/* Read data if any */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Why __syscallN macros are removed?
Thank you very much. 2007/2/23, Davide Libenzi : On Fri, 23 Feb 2007, Dong Feng wrote: > The __syscallN series macros have disappeared in > include/asm-i386/unistd.h. Why? I occasionally what to add and use > some new system calls, mainly for debug use. Now I can not access the > system call I added from user space. You can use glibc's syscall(2) instead of macros. - 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/
Re: Why __syscallN macros are removed?
On Fri, 23 Feb 2007, Dong Feng wrote: > The __syscallN series macros have disappeared in > include/asm-i386/unistd.h. Why? I occasionally what to add and use > some new system calls, mainly for debug use. Now I can not access the > system call I added from user space. You can use glibc's syscall(2) instead of macros. - 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/
Re: [stable][PATCH < 2.6.19] Fix data corruption with dm-crypt over RAID5
Christophe Saout wrote:
> Fix corruption issue with dm-crypt on top of software raid5. Cancelled
> readahead bio's that report no error, just have BIO_UPTODATE cleared
> were reported as successful reads to the higher layers (and leaving
> random content in the buffer cache). Already fixed in 2.6.19.
>
> Signed-off-by: Christophe Saout <[EMAIL PROTECTED]>
>
>
> --- linux-2.6.18.orig/drivers/md/dm-crypt.c 2006-09-20 05:42:06.0
> +0200
> +++ linux-2.6.18/drivers/md/dm-crypt.c2006-12-02 03:03:36.0
> +0100
> @@ -717,13 +717,15 @@
> if (bio->bi_size)
> return 1;
>
> + if (!bio_flagged(bio, BIO_UPTODATE) && !error)
> + error = -EIO;
> +
> bio_put(bio);
>
> /*
> * successful reads are decrypted by the worker thread
> */
> - if ((bio_data_dir(bio) == READ)
> - && bio_flagged(bio, BIO_UPTODATE)) {
> + if (bio_data_dir(io->bio) == READ && !error) {
> kcryptd_queue_io(io);
Why doesn't kcryptd_queue_io() check the return value from queue_work()?
476 static void kcryptd_queue_io(struct crypt_io *io)
477 {
478 INIT_WORK(>work, kcryptd_do_work, io);
479 queue_work(_kcryptd_workqueue, >work);
480 }
-piet
> 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/
Why __syscallN macros are removed?
The __syscallN series macros have disappeared in include/asm-i386/unistd.h. Why? I occasionally what to add and use some new system calls, mainly for debug use. Now I can not access the system call I added from user space. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
On 2/22/07, Alan <[EMAIL PROTECTED]> wrote: > to do anything but chase pointers through cache. Done right, it > hardly even branches (although the branch misprediction penalty is a > lot less of a worry on current x86_64 than it was in the > mega-superscalar-out-of-order-speculative-execution days). It's damn Actually it costs a lot more on at least one vendors processor because you stall very long pipelines. You're right; I overreached there. I haven't measured branch misprediction penalties in dog's years (I focus more on system latency issues these days), so I'm just going on rumor. If your CPU vendor is still playing the tune-for-SpecINT-at-the-expense-of-real-code game (*cough* Itanic *cough*), get another CPU vendor -- while you still can. > threadlets promise that they will not touch anything thread-local, and > that when the FPU is handed to them in a specific, known state, they > leave it in that same state. (Some of the flags can be We don't use the FPU in the kernel except in very weird cases where it makes an enormous performance difference. The threadlets also have the same page tables so they have the same %cr3 so its very cheap to switch, basically a predicted jump and some register loads Do you not understand that real user code touches FPU state at unpredictable (to the kernel) junctures? Maybe not in a database or a web server, but in the GUIs and web-based monitoring applications that are 99% of the potential customers for kernel AIO? I have no idea what a %cr3 is, but if you don't fence off thread-local stuff from the threadlets you are just begging for end-user Heisenbugs and a place in the dustheap of history next to Symbolics LISP. > Do me a favor. Do some floating point math and a memcpy() in between > syscalls in the threadlet. Actually fiddle with errno and the FPU We don't have an errno in the kernel because its a stupid idea. Errno is a user space hack for compatibility with 1970's bad design. So its not relevant either. Dude, it's thread-local, and the glibc wrapper around most synchronous syscalls touches it. If you don't instantiate a new TLS context (or whatever the right lingo for that is) for every threadlet, you are TOAST -- if you let the user call stuff out of (let alone ) from within the threadlet. 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: [PATCH 2.6.20-rc5 1/1] MM: enhance Linux swap subsystem
Performance improvement should occur when private pages of multiple processes are messed up, such as SMP. To UP, my previous mail is done by timer, which only shows a fact, if pages are messed up fully, current readahead will degrade remarkably, and unused readaheading pages make a burden to memory subsystem. You should re-test your testcases following the advises on Linux without my patch, do normal testcases and select a testcase randomly and record '/proc/vmstat/pswpin', redo the testcase solely, if the results are close, that is, your testcases doesn't messed up private pages at all as you expected due to Linux schedule. Thank you! 2007/2/22, Rik van Riel <[EMAIL PROTECTED]>: yunfeng zhang wrote: > Any comments or suggestions are always welcomed. Same question as always: what problem are you trying to solve? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Kwatch: kernel watchpoints using CPU debug registers
> Yes, you are wrong -- although perhaps you shouldn't be. > > The current version of do_debug() clears dr7 when a debug interrupt is > fielded. As a result, if a system call touches two watchpoint addresses > in userspace only the first access will be noticed. Ah, I see. I think it would indeed be nice to fix this. > This is probably a bug in do_debug(). It would be better to disable each > individual userspace watchpoint as it is triggered (or even not to disable > it at all). dr7 would be restored when the SIGTRAP is delivered. (But > what if the user is blocking or ignoring SIGTRAP?) The user blocking or ignoring it doesn't come up, because it's a force_sig_info call. However, a debugger will indeed swallow the signal through ptrace/utrace means. In ptrace, the dr7 is always going to get reset because there will always be a context switch out and back in that does it. But with utrace it's now possible to swallow the signal and keep going without a context switch (e.g. a breakpoint that is just doing logging but not stopping). So perhaps we should have a TIF_RESTORE_DR7 that goes into _TIF_WORK_MASK and gets handled in do_notify_resume (or maybe it's TIF_HWBKPT). You should not actually need to disable user watchpoints, because in data watchpoints the exception comes after the instruction completes. Only for instruction watchpoints does the exception come before the instruction executes, and no user watchpoints can be in the address range containing kernel code. SIGTRAP both doesn't queue, and doesn't give %dr6 values in its siginfo_t. All user watchpoints will be handled via the signal; this is the only way ptrace can report them, and is also the utrace way of doing things. do_debug can happen inside kernel code, and tracing of user-level tasks can only safely do anything at the point just before returning to user mode, where signals are handled. So, getting to send_sigtrap in do_debug is enough to say "one or more user debug exceptions happened". The %dr6 value that collects in the thread state to be seen by ptrace, or by utrace-based things using your new facility, needs to collect all the %dr6 bits that were set by the hardware and weren't consumed by kernel-level tracing. An eventual utrace-based thing might in fact have some other way to tie in so that the event details could just be in some call made by do_debug and not recorded in the thread's virtual %dr6 value. But at least for ptrace, they should collect there if it becomes possible for more than one exception to happen while in kernel mode or in a single user instruction. (A single instruction can cause multiple exceptions at the hardware level.) > I've worked out a plan for implementing combined user/kernel mode > breakpoints and watchpoints (call them "debugpoints" as a catch-all > term). It should work transparently with ptrace and should accomodate > whatever scheme utrace decides to adopt. There won't need to be a > separate kwatch facility on top of it; the new combined facility will > handle debugpoints in both userspace and kernelspace. That sounds great. I'm not thrilled with the name "debugpoint", I have to tell you. The hardware documentation calls all these things "breakpoints", and I think "data breakpoint" and "instruction breakpoint" are pretty good terms. How about "hwbkpt" for the facility API? > To work with ptrace, the new scheme will completely virtualize the debug > registers. So for example, a ptrace call might request a debugpoint in > dr0, but it could end up that the physical register used is really dr2 > instead. The various bits in dr6 and dr7 will be mapped in such a way > that the entire procedure is transparent to the user. Debugpoints > registered in kernelspace or by utrace won't care, of course. I think that's a fine idea. The one caveat I have here is that I don't want ptrace (via utrace) to have to supply the usual structure. I probably only think this because it would be a pain for the ptrace/utrace implementation to find a place to stick it. But I have a rationalization. The old ptrace interface, and the utrace_regset for debugregs, is not really a "debugpoint user" in the sense you're defining it. It's an access to the "raw" debugregs as part of the thread's virtual CPU context. You can use ptrace to set a watchpoint, then detach ptrace, and the thread will get a SIGTRAP later though there is no remnant at that point of the debugger interface that made it come about. For the degenerate case of medium-high priority with no handler callbacks (that should instead be an error at registration time if no slot is free), you shouldn't really need any per-caller storage (there can only be one such caller per slot). > There are two things I am uncertain about: vm86 mode and kprobes. I don't > know anything about how either of them works. I know about kprobes. I don't know about vm86, but I can read the code. Thanks, Roland - To unsubscribe from this list:
[patch] fix the irq migration
While debugging some other irq migration issue, observed this issue with -git kernels. Ingo, please ACK it. --- With the commit 76d2160147f43f982dfe881404cfde9fd0a9da21, irq_chip default_disable() became an empty function. And with this change, irq migration in the case of Edge triggered IO-APIC and MSI interrupts happens with out masking the irq. Appended patch fixes by using the mask/unmask handlers of irq_chip directly while doing the irq migration. Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]> --- diff --git a/kernel/irq/migration.c b/kernel/irq/migration.c index 4baa3bb..14ff345 100644 --- a/kernel/irq/migration.c +++ b/kernel/irq/migration.c @@ -66,11 +66,11 @@ void move_native_irq(int irq) return; if (likely(!(desc->status & IRQ_DISABLED))) - desc->chip->disable(irq); + desc->chip->mask(irq); move_masked_irq(irq); if (likely(!(desc->status & IRQ_DISABLED))) - desc->chip->enable(irq); + desc->chip->unmask(irq); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: several messages
On Thursday 22 February 2007 2:58 pm, Guennadi Liakhovetski wrote: > > I think, we only want 1, right? And the latter seems to be more generic / > platform independent? And as a side-effect, powermac would have to migrate > to generic rtc:-) I'd certainly think that restoring the system clock should be, as much as possible, in platform-agnostic code. Like the generic RTC framework. And hmm, that powermac/time.c file replicates other RTC code... Minor obstacle: removing the EXPERIMENTAL label from that code. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RFC/patch: down_timeout_interruptible()
Hi All
I was in a situation where I could really simplify many things by
using down_interruptible() with a timeout. I went around looking for
how could one be implemented and ran away from the asm code in arch/.
At the end I realized I could make a simple one by setting up a timer
that would 'fake' a sigpending situation (setting the task's TIF_SIGPENDING
bit) so that the __down_interruptible_failed() path would quit when
the timer went off.
I gave it a quick try (must admit, not too tested) and it seems that
the setting of TIF_SIGPENDING without really having a signal queued
is not having easily visible ugly consequences.
Does anybody have suggestions on how to alternatively implement this?
Thanks,
-- Inaky
include/asm-i386/semaphore.h |3 ++
lib/semaphore-sleepers.c | 51 +++
2 files changed, 54 insertions(+)
diff -r 9ed3c4dc013f include/asm-i386/semaphore.h
--- a/include/asm-i386/semaphore.h Wed Feb 21 13:02:17 2007 -0800
+++ b/include/asm-i386/semaphore.h Thu Feb 22 17:09:13 2007 -0800
@@ -88,6 +88,9 @@ fastcall int __down_failed_interruptibl
fastcall int __down_failed_interruptible(void /* params in registers */);
fastcall int __down_failed_trylock(void /* params in registers */);
fastcall void __up_wakeup(void /* special register calling convention */);
+/* FIXME: need to add to other header files */
+extern void down_timeout_interruptible(struct semaphore *);
+
/*
* This is ugly, but we want the default case to fall through.
diff -r 9ed3c4dc013f lib/semaphore-sleepers.c
--- a/lib/semaphore-sleepers.c Wed Feb 21 13:02:17 2007 -0800
+++ b/lib/semaphore-sleepers.c Thu Feb 22 16:52:54 2007 -0800
@@ -174,3 +174,54 @@ fastcall int __down_trylock(struct semap
spin_unlock_irqrestore(>wait.lock, flags);
return 1;
}
+
+
+struct dit_data
+{
+ struct task_struct *task;
+ int result;
+};
+
+/**
+ * dit_kick_process - set a fake 'signal pending' and kick
+ *
+ * Helper for down_interruptible_timeout(). Sets the signal pending
+ * flag on the task that is waiting for a semaphore and kicks it. That
+ * tells the down_interruptible() code to quit waiting.
+ */
+static
+void dit_kick_process(unsigned long _data)
+{
+ struct dit_data *data = (void *) _data;
+ set_tsk_thread_flag(data->task, TIF_SIGPENDING);
+ data->result = -ETIMEDOUT;
+ kick_process(data->task);
+}
+
+
+/*
+ * Interruptible try to acquire a semaphore. If we obtained
+ * it, return zero. If we were interrupted, returns -EINTR. If we
+ * timedout, we return -ETIMEDOUT;
+ *
+ * Note the ugly hack, using a helper timer and function to wake up
+ * the waiter. We need to distinguish, if we get an error, if it was
+ * because we were woken up (-ETIMEDOUT) or for other reason (-EINTR),
+ * hence the last if block.
+ */
+int down_interruptible_timeout(struct semaphore *sem, unsigned long to)
+{
+ int result;
+ struct dit_data data = {
+ .task = get_current(), .result = 0
+ };
+ DEFINE_TIMER(dit_timer, dit_kick_process, to, (unsigned long) );
+ add_timer(_timer);
+ result = down_interruptible(sem);
+ del_timer(_timer);
+ if (result < 0 && data.result < 0)
+ result = data.result;
+ return result;
+}
+
+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/5] RT kernel: HPET emulate RTC and other cleanups
Cleanup HPET RTC emulation based on earlier patch which uses HPET interrupts
in normal mode instead of legacy replacement mode. RTC can now coexist with
HPET.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc-mm/arch/x86_64/Kconfig
===
--- linux-2.6.21-rc-mm.orig/arch/x86_64/Kconfig
+++ linux-2.6.21-rc-mm/arch/x86_64/Kconfig
@@ -448,6 +448,7 @@ config ARCH_ENABLE_MEMORY_HOTPLUG
config HPET_TIMER
bool
default y
+ depends ACPI
help
Use the IA-PC HPET (High Precision Event Timer) to manage
time in preference to the PIT and RTC, if a HPET is
@@ -458,7 +459,7 @@ config HPET_TIMER
config HPET_EMULATE_RTC
bool "Provide RTC interrupt"
- depends on HPET_TIMER && RTC=y
+ depends on HPET_TIMER && RTC=y && !GENERIC_TIME
# Mark as embedded because too many people got it wrong.
# The code disables itself when not needed.
Index: linux-2.6.21-rc-mm/arch/x86_64/kernel/hpet.c
===
--- linux-2.6.21-rc-mm.orig/arch/x86_64/kernel/hpet.c
+++ linux-2.6.21-rc-mm/arch/x86_64/kernel/hpet.c
@@ -2,7 +2,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -10,6 +9,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -44,36 +45,35 @@ static __init int late_hpet_init(void)
/*
* Register with driver.
-* Timer0 and Timer1 is used by platform.
+* num_timers_used timers are used by platform.
*/
hd.hd_phys_address = hpet_address;
hd.hd_address = (void __iomem *)fix_to_virt(FIX_HPET_BASE);
hd.hd_nirqs = ntimer;
hd.hd_flags = HPET_DATA_PLATFORM;
- hpet_reserve_timer(, 0);
-#ifdef CONFIG_HPET_EMULATE_RTC
- hpet_reserve_timer(, 1);
-#endif
- hd.hd_irq[0] = HPET_LEGACY_8254;
- hd.hd_irq[1] = HPET_LEGACY_RTC;
- if (ntimer > 2) {
+
+ for (i = 0; i < num_timers_used; i++) {
+ hpet_reserve_timer(, i);
+ }
+
+ if (ntimer > num_timers_used) {
struct hpet *hpet;
struct hpet_timer *timer;
int i;
hpet = (struct hpet *) fix_to_virt(FIX_HPET_BASE);
- timer = >hpet_timers[2];
- for (i = 2; i < ntimer; timer++, i++)
+ for (i = num_timers_used; i < ntimer; timer++, i++) {
+ timer = >hpet_timers[i];
hd.hd_irq[i] = (timer->hpet_config &
Tn_INT_ROUTE_CNF_MASK) >>
Tn_INT_ROUTE_CNF_SHIFT;
-
+ }
}
hpet_alloc();
return 0;
}
-fs_initcall(late_hpet_init);
+late_initcall(late_hpet_init);
#endif
static int hpet_timer_stop_set_go(unsigned long tick)
@@ -209,257 +209,6 @@ unsigned int __init hpet_calibrate_tsc(v
/ ((hpet_now - hpet_start) * hpet_period / 1000);
}
-#ifdef CONFIG_HPET_EMULATE_RTC
-/* HPET in LegacyReplacement Mode eats up RTC interrupt line. When, HPET
- * is enabled, we support RTC interrupt functionality in software.
- * RTC has 3 kinds of interrupts:
- * 1) Update Interrupt - generate an interrupt, every sec, when RTC clock
- *is updated
- * 2) Alarm Interrupt - generate an interrupt at a specific time of day
- * 3) Periodic Interrupt - generate periodic interrupt, with frequencies
- *2Hz-8192Hz (2Hz-64Hz for non-root user) (all freqs in powers of 2)
- * (1) and (2) above are implemented using polling at a frequency of
- * 64 Hz. The exact frequency is a tradeoff between accuracy and interrupt
- * overhead. (DEFAULT_RTC_INT_FREQ)
- * For (3), we use interrupts at 64Hz or user specified periodic
- * frequency, whichever is higher.
- */
-#include
-
-#define DEFAULT_RTC_INT_FREQ 64
-#define RTC_NUM_INTS 1
-
-static unsigned long UIE_on;
-static unsigned long prev_update_sec;
-
-static unsigned long AIE_on;
-static struct rtc_time alarm_time;
-
-static unsigned long PIE_on;
-static unsigned long PIE_freq = DEFAULT_RTC_INT_FREQ;
-static unsigned long PIE_count;
-
-static unsigned long hpet_rtc_int_freq; /* RTC interrupt frequency */
-static unsigned int hpet_t1_cmp; /* cached comparator register */
-
-int is_hpet_enabled(void)
-{
- return hpet_address != 0;
-}
-
-/*
- * Timer 1 for RTC, we do not use periodic interrupt feature,
- * even if HPET supports periodic interrupts on Timer 1.
- * The reason being, to set up a periodic interrupt in HPET, we need to
- * stop the main counter. And if we do that everytime someone diables/enables
- * RTC, we will have adverse effect on main kernel timer running on Timer 0.
- * So, for the time being, simulate the periodic interrupt in software.
- *
- * hpet_rtc_timer_init() is called for the first time and during subsequent
- * interuppts
[PATCH 5/5] RT kernel: HPET relates boot option changes in x86-64
Cleanup HPET related boot options in x86-64 and deprecate 'nohpet'.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc-mm/arch/x86_64/kernel/hpet.c
===
--- linux-2.6.21-rc-mm.orig/arch/x86_64/kernel/hpet.c
+++ linux-2.6.21-rc-mm/arch/x86_64/kernel/hpet.c
@@ -19,6 +19,7 @@
#include
int nohpet __initdata;
+static int nohpetforce __initdata;
unsigned long hpet_address;
unsigned long hpet_period; /* fsecs / HPET clock */
@@ -217,6 +218,19 @@ static int __init nohpet_setup(char *s)
__setup("nohpet", nohpet_setup);
+static int __init hpet_setup(char *str)
+{
+ if (str) {
+ if (!strncmp("disable", str, 7))
+ nohpet = 1;
+ if (!strncmp("noforce", str, 7))
+ nohpetforce = 1;
+ }
+ return 1;
+}
+
+__setup("hpet=", hpet_setup);
+
/* Clocksource */
#define HPET_MASK 0x
#define HPET_SHIFT 22
@@ -722,7 +736,7 @@ static int __init init_hpet_generic_time
if (nohpet)
return -ENODEV;
- if (!hpet_address) {
+ if (!hpet_address && !nohpetforce) {
hpet_address = force_hpet_address;
} else {
hpet_timer_stop();
Index: linux-2.6.21-rc-mm/Documentation/kernel-parameters.txt
===
--- linux-2.6.21-rc-mm.orig/Documentation/kernel-parameters.txt
+++ linux-2.6.21-rc-mm/Documentation/kernel-parameters.txt
@@ -371,8 +371,12 @@ and is between 256 and 4096 characters.
over the 8254 in addition to over the IO-APIC. The
kernel tries to set a sensible default.
- hpet= [IA-32,HPET] option to disable HPET and use PIT.
- Format: disable
+ hpet= [IA-32/X86_64,HPET] option to disable HPET and use PIT.
+ Format: disable|noforce
+ disable - disables HPET timer detection and usage
+ noforce - disables HPET timer detection and usage when
+ it is not explicitly enabled in BIOS. i.e,
+ HPET is not enabled based on quirks.
cm206= [HW,CD]
Format: { auto | [,][] }
Index: linux-2.6.21-rc-mm/Documentation/feature-removal-schedule.txt
===
--- linux-2.6.21-rc-mm.orig/Documentation/feature-removal-schedule.txt
+++ linux-2.6.21-rc-mm/Documentation/feature-removal-schedule.txt
@@ -316,3 +316,12 @@ Why: Unmaintained for years, superceded
Who: Jeff Garzik <[EMAIL PROTECTED]>
---
+
+What: X86-64 "nohpet" boot option
+When: May 2007
+Why: nohpet is not documented boot option in x86-64. There is a documented
+ boot option in i386 for similar purpose (hpet=), which is now in
+ x86-64 as well.
+Who: Venkatesh Pallipadi <[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 3/5] RT kernel: HPET as per CPU eventsource
Register HPET as eventsource.
If number of logical CPUs is less than number of HPET channels, HPET provides
a per CPU eventsource (using as many timers as needed). Otherwise, it is a
global eventsource (using only one timer).
HPET timers are programmed in their standard interrupt mapping mode (not
in legacy replacement mode).
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc-mm/arch/x86_64/kernel/apic.c
===
--- linux-2.6.21-rc-mm.orig/arch/x86_64/kernel/apic.c
+++ linux-2.6.21-rc-mm/arch/x86_64/kernel/apic.c
@@ -794,17 +794,24 @@ static void lapic_timer_setup(enum clock
unsigned long flags;
local_irq_save(flags);
- /* Turn off PIT interrupt if we use APIC timer as main timer.
- Only works with the PM timer right now
- TBD fix it for HPET too. */
- if ((pmtmr_ioport != 0) &&
- smp_processor_id() == boot_cpu_id &&
- apic_runs_main_timer == 1 &&
- !cpu_isset(boot_cpu_id, timer_interrupt_broadcast_ipi_mask)) {
- stop_timer_interrupt();
- apic_runs_main_timer++;
+ if (mode == CLOCK_EVT_MODE_SHUTDOWN) {
+ unsigned long v;
+ v = apic_read(APIC_LVTT);
+ v |= (APIC_LVT_MASKED | LOCAL_TIMER_VECTOR);
+ apic_write(APIC_LVTT, v);
+ } else {
+ /* Turn off IRQ 0 timer if we use APIC timer as main timer. */
+ if ( smp_processor_id() == boot_cpu_id &&
+ apic_runs_main_timer == 1 &&
+ !cpu_isset(boot_cpu_id,
+ timer_interrupt_broadcast_ipi_mask)) {
+ stop_timer_interrupt();
+ apic_runs_main_timer++;
+ }
+ __setup_APIC_LVTT(calibration_result,
+ mode != CLOCK_EVT_MODE_PERIODIC);
}
- __setup_APIC_LVTT(calibration_result, mode != CLOCK_EVT_MODE_PERIODIC);
+
local_irq_restore(flags);
}
Index: linux-2.6.21-rc-mm/arch/x86_64/kernel/hpet.c
===
--- linux-2.6.21-rc-mm.orig/arch/x86_64/kernel/hpet.c
+++ linux-2.6.21-rc-mm/arch/x86_64/kernel/hpet.c
@@ -1,3 +1,4 @@
+
#include
#include
#include
@@ -7,10 +8,14 @@
#include
#include
#include
+#include
+#include
+
#include
#include
#include
#include
+#include
int nohpet __initdata;
@@ -71,7 +76,7 @@ static __init int late_hpet_init(void)
fs_initcall(late_hpet_init);
#endif
-int hpet_timer_stop_set_go(unsigned long tick)
+static int hpet_timer_stop_set_go(unsigned long tick)
{
unsigned int cfg;
@@ -158,11 +163,6 @@ int __init hpet_arch_init(void)
return hpet_timer_stop_set_go(hpet_tick);
}
-int hpet_reenable(void)
-{
- return hpet_timer_stop_set_go(hpet_tick);
-}
-
/*
* calibrate_tsc() calibrates the processor TSC in a very simple way, comparing
* it to the HPET timer of known frequency.
@@ -468,6 +468,7 @@ static int __init nohpet_setup(char *s)
__setup("nohpet", nohpet_setup);
+/* Clocksource */
#define HPET_MASK 0x
#define HPET_SHIFT 22
@@ -517,6 +518,454 @@ static int __init init_hpet_clocksource(
return clocksource_register(_hpet);
}
+/* Eventsource */
+static unsigned int num_timers_used;
+
+#define HPET_DEV_FLAG_ONESHOT 0x1
+#define HPET_DEV_FLAG_PERIODIC 0x2
+#define HPET_DEV_FLAG_TEST 0x10
+
+/* HPET as clockevent */
+struct hpet_dev {
+ unsigned int num;
+ int cpu;
+ cpumask_t cpu_mask;
+ unsigned int irq;
+ unsigned int tick;
+ unsigned int count;
+ unsigned int flags;
+ char name[10];
+};
+
+static struct hpet_dev *cpu_hpet_dev; /* per CPU ptr */
+
+#define HPET_INTERRUPT_TEST_COUNT 5
+
+static irqreturn_t hpet_normal_interrupt(int irq, void *data);
+
+static irqreturn_t hpet_normal_interrupt_test(int irq, void *data)
+{
+ unsigned int readin;
+ struct hpet_dev *dev = (struct hpet_dev *)data;
+
+ dev->count++;
+ if (dev->count < HPET_INTERRUPT_TEST_COUNT) {
+ unsigned long flags;
+
+ local_irq_save(flags);
+ readin = hpet_readl(HPET_COUNTER);
+ hpet_writel(readin + dev->tick, HPET_Tn_CMP(dev->num));
+ local_irq_restore(flags);
+ }
+ return IRQ_HANDLED;
+}
+
+static unsigned int cpu_hpet_irq[NR_CPUS] = {[0 ... NR_CPUS-1] = -1};
+static unsigned int assigned_irqs_map = 0;
+
+/* Called sequentially and hence no synchronization */
+static int hpet_assign_irq(struct hpet_dev *dev)
+{
+ unsigned int irq = -1;
+ unsigned int cpu = dev->cpu;
+ int ret = 0;
+
+ dev->irq = -1;
+ /*
+* Simple IRQ allocation policy : One IRQ per CPU and use
+* first available for this timer.
+*/
+ if (cpu >
[PATCH 2/5] RT kernel: HPET as clocksource
Use HPET address detected by quirk, when it is not listed by BIOS and
register HPET as a clocksource.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc-mm/arch/x86_64/kernel/hpet.c
===
--- linux-2.6.21-rc-mm.orig/arch/x86_64/kernel/hpet.c
+++ linux-2.6.21-rc-mm/arch/x86_64/kernel/hpet.c
@@ -12,7 +12,7 @@
#include
#include
-int nohpet __initdata = 1;
+int nohpet __initdata;
unsigned long hpet_address;
unsigned long hpet_period; /* fsecs / HPET clock */
@@ -106,18 +106,21 @@ int hpet_timer_stop_set_go(unsigned long
return 0;
}
-int hpet_arch_init(void)
+static int init_basic_hpet_done __initdata;
+
+static int __init init_basic_hpet(void)
{
unsigned int id;
- if (!hpet_address)
- return -1;
+ if (init_basic_hpet_done)
+ return 0;
+
set_fixmap_nocache(FIX_HPET_BASE, hpet_address);
__set_fixmap(VSYSCALL_HPET, hpet_address, PAGE_KERNEL_VSYSCALL_NOCACHE);
-/*
- * Read the period, compute tick and quotient.
- */
+ /*
+* Read the period, compute tick and quotient.
+*/
id = hpet_readl(HPET_ID);
@@ -130,6 +133,26 @@ int hpet_arch_init(void)
hpet_tick = (FSEC_PER_TICK + hpet_period / 2) / hpet_period;
+ printk(KERN_DEBUG "HPET: hpet_period %lu, hpet_tick %lu\n", hpet_period,
+ hpet_tick);
+
+ init_basic_hpet_done = 1;
+ return 0;
+}
+
+int __init hpet_arch_init(void)
+{
+ unsigned int id;
+ int ret;
+
+ if (!hpet_address)
+ return -1;
+
+ ret = init_basic_hpet();
+ if (ret)
+ return ret;
+
+ id = hpet_readl(HPET_ID);
hpet_use_timer = (id & HPET_ID_LEGSUP);
return hpet_timer_stop_set_go(hpet_tick);
@@ -451,16 +474,14 @@ __setup("nohpet", nohpet_setup);
/* FSEC = 10^-15 NSEC = 10^-9 */
#define FSEC_PER_NSEC 100
-static void *hpet_ptr;
-
static cycle_t notrace read_hpet(void)
{
- return (cycle_t)readl(hpet_ptr);
+ return (cycle_t)hpet_readl(HPET_COUNTER);
}
static cycle_t __vsyscall_fn vread_hpet(void)
{
- return readl((void __iomem *)fix_to_virt(VSYSCALL_HPET) + 0xf0);
+ return readl((void __iomem *)fix_to_virt(VSYSCALL_HPET) + HPET_COUNTER);
}
struct clocksource clocksource_hpet = {
@@ -476,20 +497,8 @@ struct clocksource clocksource_hpet = {
static int __init init_hpet_clocksource(void)
{
- unsigned long hpet_period;
- void __iomem *hpet_base;
u64 tmp;
- if (!hpet_address)
- return -ENODEV;
-
- /* calculate the hpet address: */
- hpet_base = ioremap_nocache(hpet_address, HPET_MMAP_SIZE);
- hpet_ptr = hpet_base + HPET_COUNTER;
-
- /* calculate the frequency: */
- hpet_period = readl(hpet_base + HPET_PERIOD);
-
/*
* hpet period is in femto seconds per cycle
* so we need to convert this to ns/cyc units
@@ -508,4 +517,38 @@ static int __init init_hpet_clocksource(
return clocksource_register(_hpet);
}
-module_init(init_hpet_clocksource);
+static int __init init_hpet_generic_timer(void)
+{
+ int ret;
+
+ if (nohpet)
+ return -ENODEV;
+
+ if (!hpet_address)
+ hpet_address = force_hpet_address;
+
+ if (!hpet_address)
+ return -ENODEV;
+
+ ret = init_basic_hpet();
+ if (ret)
+ return ret;
+
+ ret = init_hpet_clocksource();
+ if (!ret) {
+ printk(KERN_DEBUG "Successfully registered HPET clocksource\n");
+ } else {
+ printk(KERN_DEBUG "HPET clocksource init failed\n");
+ }
+
+ if (ret) {
+ unsigned int cfg;
+ cfg = hpet_readl(HPET_CFG);
+ cfg &= (~HPET_CFG_ENABLE);
+ hpet_writel(cfg, HPET_CFG);
+ }
+
+ return ret;
+}
+
+module_init(init_hpet_generic_timer);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] free swap space when (re)activating page
Rik van Riel <[EMAIL PROTECTED]> wrote:
+++ linux-2.6.20.noarch/mm/swap.c2007-02-20 06:44:17.0 -0500
@@ -420,6 +420,26 @@ void pagevec_strip(struct pagevec *pvec)
> +if (printk_ratelimit())
> +printk("kswapd freed a swap space\n");
>
NOO!!!
1) This message is a debug message! You forgot to set the printk level.
2) The message text is bad, the average log reader only knows swap files
and pages in swapfiles. The first reaction will be like "WTF happened
to my swap???". Thousands of admins will cry out in anguish trying to
get the meaning of this message, and again cry out in wrath after they
found out.
3) What should I do if I see this message? It's neither good, nor bad for
me, nor is it in any way informative even if it were changed to be
meaningfull. It's utterly useless! Let it be!
--
We are all born ignorant, but one must work hard to remain stupid.
-- Benjamin Franklin
Friß, Spammer: [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 1/5] RT kernel: force detect HPET from PCI space
Patchset enables force detection of HPET, when it is not listed by BIOS.
and enables use of HPET as a event source. HPET timers
configures in stamdard interrupt mode can be used as dependable per CPU timer
on laptops that are known to have LAPIC stoppage with ACPI C3 state.
Patch is against rt kernel (2.6.20-rt8) and patch enables only x86-64
right now.
This patch:
Detect HPET by looking at PCI space, even when BIOS does not list HPET
device. This is useful to use HPET as dependable per CPU timer with tickless
kernels.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc-mm/arch/i386/kernel/quirks.c
===
--- linux-2.6.21-rc-mm.orig/arch/i386/kernel/quirks.c
+++ linux-2.6.21-rc-mm/arch/i386/kernel/quirks.c
@@ -48,3 +48,58 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7525_MCH,
quirk_intel_irqbalance);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7520_MCH,
quirk_intel_irqbalance);
#endif
+
+#if defined(CONFIG_HPET_TIMER)
+unsigned long force_hpet_address;
+
+static void __init force_enable_hpet(struct pci_dev *dev)
+{
+ u32 val, rcba;
+ void __iomem *base;
+
+ if (hpet_address)
+ return;
+
+ pci_read_config_dword(dev, 0xF0, );
+ rcba &= 0xC000;
+ if (rcba == 0) {
+ printk(KERN_DEBUG "RCBA disabled. Cannot force enable HPET\n");
+ return;
+ }
+
+ /* use bits 31:14, 16 kB aligned */
+ base = ioremap_nocache(rcba, 0x4000);
+ if (base == NULL) {
+ printk(KERN_DEBUG "ioremap failed. Cannot force enable HPET\n");
+ return;
+ }
+
+ /* read the Function Disable register, dword mode only */
+ val = readl(base + 0x3404);
+
+ if (!(val & 0x80)) {
+ /* HPET disabled in HPTC. Trying to enable */
+ writel(val | 0x80, base + 0x3404);
+ }
+
+ val = readl(base + 0x3404);
+
+ if (!(val & 0x80)) {
+ printk(KERN_DEBUG "Failed to force enable HPET\n");
+ } else {
+ val = val & 0x3;
+ force_hpet_address = 0xFED0 | (val << 12);
+ printk(KERN_DEBUG "Force enabled HPET. Base address 0x%x\n",
+ force_hpet_address);
+ }
+
+ iounmap(base);
+}
+
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB2_0,
force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1,
force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_1,
force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_31,
force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_1,
force_enable_hpet);
+#endif
+
Index: linux-2.6.21-rc-mm/include/asm-i386/hpet.h
===
--- linux-2.6.21-rc-mm.orig/include/asm-i386/hpet.h
+++ linux-2.6.21-rc-mm/include/asm-i386/hpet.h
@@ -91,6 +91,7 @@
#define HPET_TICK_RATE (HZ * 10UL)
extern unsigned long hpet_address; /* hpet memory map physical address */
+extern unsigned long force_hpet_address;/* hpet memory detected by quirk */
extern int is_hpet_enabled(void);
#ifdef CONFIG_X86_64
Index: linux-2.6.21-rc-mm/include/asm-x86_64/hpet.h
===
--- linux-2.6.21-rc-mm.orig/include/asm-x86_64/hpet.h
+++ linux-2.6.21-rc-mm/include/asm-x86_64/hpet.h
@@ -63,6 +63,7 @@ extern unsigned int hpet_calibrate_tsc(v
extern int hpet_use_timer;
extern unsigned long hpet_address;
+extern unsigned long force_hpet_address;
extern unsigned long hpet_period;
extern unsigned long hpet_tick;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm] Log reason why TSC was marked unstable
This patch changes mark_tsc_unstable() so it takes a string argument,
which holds the reason the TSC was marked unstable.
This is then displayed the first time mark_tsc_unstable is called.
This should help us better debug why the TSC was marked unstable on
certain systems and allow us to make sure we're not being overly
paranoid when throwing out this troublesome clocksource.
thanks
-john
arch/i386/kernel/tsc.c |5 +++--
arch/x86_64/kernel/time.c |2 +-
arch/x86_64/kernel/tsc.c|5 +++--
arch/x86_64/kernel/tsc_sync.c |2 +-
drivers/acpi/processor_idle.c |4 ++--
include/asm-i386/mach-summit/mach_mpparse.h |4 ++--
include/asm-x86_64/timex.h |2 +-
include/asm-x86_64/tsc.h|2 +-
8 files changed, 14 insertions(+), 12 deletions(-)
linux-2.6.21-rc1_mark-unstable-reason_C7.patch
diff --git a/arch/i386/kernel/tsc.c b/arch/i386/kernel/tsc.c
index 3082a41..c276575 100644
--- a/arch/i386/kernel/tsc.c
+++ b/arch/i386/kernel/tsc.c
@@ -262,7 +262,7 @@ time_cpufreq_notifier(struct notifier_bl
* TSC based sched_clock turns
* to junk w/ cpufreq
*/
- mark_tsc_unstable();
+ mark_tsc_unstable("cpufreq changes");
}
}
}
@@ -310,10 +310,11 @@ static struct clocksource clocksource_ts
CLOCK_SOURCE_MUST_VERIFY,
};
-void mark_tsc_unstable(void)
+void mark_tsc_unstable(char *reason)
{
if (!tsc_unstable) {
tsc_unstable = 1;
+ printk("Marking TSC unstable due to: %s.\n", reason);
/* Can be called before registration */
if (clocksource_tsc.mult)
clocksource_change_rating(_tsc, 0);
diff --git a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
index c9addcf..b05bb3c 100644
--- a/arch/x86_64/kernel/time.c
+++ b/arch/x86_64/kernel/time.c
@@ -348,7 +348,7 @@ void __init time_init(void)
}
if (unsynchronized_tsc())
- mark_tsc_unstable();
+ mark_tsc_unstable("TSCs unsynchronized");
if (cpu_has(_cpu_data, X86_FEATURE_RDTSCP))
vgetcpu_mode = VGETCPU_RDTSCP;
diff --git a/arch/x86_64/kernel/tsc.c b/arch/x86_64/kernel/tsc.c
index 8958318..d8e5f06 100644
--- a/arch/x86_64/kernel/tsc.c
+++ b/arch/x86_64/kernel/tsc.c
@@ -109,7 +109,7 @@ #endif
cpu_khz = cpufreq_scale(cpu_khz_ref, ref_freq, freq->new);
if (!(freq->flags & CPUFREQ_CONST_LOOPS))
- mark_tsc_unstable();
+ mark_tsc_unstable("cpufreq changes");
}
set_cyc2ns_scale(cpu_khz_ref);
@@ -197,10 +197,11 @@ static struct clocksource clocksource_ts
.vread = vread_tsc,
};
-void mark_tsc_unstable(void)
+void mark_tsc_unstable(char *reason)
{
if (!tsc_unstable) {
tsc_unstable = 1;
+ printk("Marking TSC unstable due to %s\n", reason);
/* Change only the rating, when not registered */
if (clocksource_tsc.mult)
clocksource_change_rating(_tsc, 0);
diff --git a/arch/x86_64/kernel/tsc_sync.c b/arch/x86_64/kernel/tsc_sync.c
index 014f0db..fe571fb 100644
--- a/arch/x86_64/kernel/tsc_sync.c
+++ b/arch/x86_64/kernel/tsc_sync.c
@@ -138,7 +138,7 @@ void __cpuinit check_tsc_sync_source(int
printk("\n");
printk(KERN_WARNING "Measured %Ld cycles TSC warp between CPUs,"
" turning off TSC clock.\n", max_warp);
- mark_tsc_unstable();
+ mark_tsc_unstable("check_tsc_sync_source failed");
nr_warps = 0;
max_warp = 0;
last_tsc = 0;
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 6077300..44b7836 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -482,7 +482,7 @@ #endif
#ifdef CONFIG_GENERIC_TIME
/* TSC halts in C2, so notify users */
- mark_tsc_unstable();
+ mark_tsc_unstable("possible TSC halt in C2");
#endif
/* Re-enable interrupts */
local_irq_enable();
@@ -524,7 +524,7 @@ #endif
#ifdef CONFIG_GENERIC_TIME
/* TSC halts in C3, so notify users */
- mark_tsc_unstable();
+ mark_tsc_unstable("TSC halts in C3");
#endif
/* Re-enable interrupts */
local_irq_enable();
diff --git a/include/asm-i386/mach-summit/mach_mpparse.h
b/include/asm-i386/mach-summit/mach_mpparse.h
index 9426839..c252053 100644
---
[PATCH] dma-mapping-broken.h: flesh-out DMA API stubs
This allows some drivers compile on arches that don't support DMA
(e.g. s390).
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
Is there any reason why this header should not cover the whole DMA API?
Compile-tested only...
include/asm-generic/dma-mapping-broken.h | 134 ++
1 files changed, 134 insertions(+), 0 deletions(-)
diff --git a/include/asm-generic/dma-mapping-broken.h
b/include/asm-generic/dma-mapping-broken.h
index 29413d3..84812dd 100644
--- a/include/asm-generic/dma-mapping-broken.h
+++ b/include/asm-generic/dma-mapping-broken.h
@@ -21,4 +21,116 @@ dma_free_coherent(struct device *dev, size_t size, void
*cpu_addr,
#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
#define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
+static inline dma_addr_t
+dma_map_single(struct device *dev, void *ptr, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG();
+ return (dma_addr_t)0;
+}
+
+static inline void
+dma_unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size,
+enum dma_data_direction direction)
+{
+ BUG();
+}
+
+static inline int
+dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
+ enum dma_data_direction direction)
+{
+ BUG();
+ return 0;
+}
+
+static inline void
+dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nhwentries,
+enum dma_data_direction direction)
+{
+ BUG();
+}
+
+static inline dma_addr_t
+dma_map_page(struct device *dev, struct page *page, unsigned long offset,
+size_t size, enum dma_data_direction direction)
+{
+ BUG();
+ return (dma_addr_t)0;
+}
+
+static inline void
+dma_unmap_page(struct device *dev, dma_addr_t dma_address, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG();
+}
+
+static inline void
+dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG();
+}
+
+static inline void
+dma_sync_single_range_for_cpu(struct device *dev, dma_addr_t dma_handle,
+ unsigned long offset, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG();
+}
+
+static inline void
+dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nelems,
+ enum dma_data_direction direction)
+{
+ BUG();
+}
+
+#define dma_sync_single_for_device dma_sync_single_for_cpu
+#define dma_sync_single_range_for_device dma_sync_single_range_for_cpu
+#define dma_sync_sg_for_device dma_sync_sg_for_cpu
+
+static inline int
+dma_mapping_error(dma_addr_t dma_addr)
+{
+ BUG();
+ return 1;
+}
+
+static inline int
+dma_supported(struct device *dev, u64 mask)
+{
+ return 0;
+}
+
+static inline int
+dma_set_mask(struct device *dev, u64 mask)
+{
+ BUG();
+ return -EIO;
+}
+
+static inline int
+dma_get_cache_alignment(void)
+{
+ BUG();
+ return 0;
+}
+
+int
+dma_is_consistent(struct device *dev, dma_addr_t dma_handle)
+{
+ BUG();
+ return 0;
+}
+
+static inline void
+dma_cache_sync(struct device *dev, void *vaddr, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG();
+}
+
#endif /* _ASM_GENERIC_DMA_MAPPING_H */
--
1.4.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/22/07, Alan <[EMAIL PROTECTED]> wrote: > Oh yeah? For IRIX in 1991? Or for that matter, for Linux/ARM EABI > today? Tell me, how many of what sort of users do you support Solaris (NTL - very large ISP/Telco), Dec server 5000 (for fun), Irix (and linux cross for Irix removal), MIPS embedded (including the port to Linux of Algorithmics toolchain) for Sonix then 3COM routers. My list of GNUs maintained is about the same: SunOS 4.x, Solaris 2.x, IRIX, ConvexOS, embedded MIPS and ARM and x86. I've used, but didn't maintain, GCC for embedded PowerPC and m68k, and until I found a distro I could more or less trust to be point fixable, I did my own desktop/server Linux toolchains for x86, PowerPC, and x86_64. The only one for which I resorted to coughing up the university's money to the FSF was IRIX, and that's because it had to reach functional parity with the Sun and Convex boxes pronto. It's not a hard problem. gcc 2.x wasn't too hot on MIPS but it worked although the Irix compiler generated vastly better code (and AFAIK still does). It worked until you tried a 64-bit target or stressed the floating point. I had one of the first R4400s that ever left SGI, in an Indigo with the IndigoVideo board when it was still in alpha. Part of the horse-trade between the university and the start-up I worked for was that they got to run batch jobs on the thing when I wasn't physically at the keyboard. I had built several experimental toolchains for the thing but concluded rapidly that I didn't want to tech-support that shit. Best $5K of someone else's money I ever spent. There are folks who maintain cross devel chains for just about every Linux platform specifically for testing and while it isn't a small job they do seem to be coping quite happily. Er, I'm one of them. :-) When the ARM-based device I'm currently working on first ships as an out-of-form-factor prototype to OEM customers, it will be accompanied by a complete toolchain, kernel, and userland, built from scratch using crosstool and ptxdist and extensive patches I wrote, all of them to be contributed upstream because I convinced my client that it's the right thing to do. This includes the latest upstream editions of each userland component, a gdbserver that has been tested on multi-threaded soft-float NPTL binaries, the first (public) ltrace to work correctly on Linux/ARM in at least three years, the first (public) strace to understand ALSA ioctls, and infrastructure for unit testing and system latency analysis. It will be delivered as a set of git repositories with the complete development history and tracking branches for outside projects, and the only bits that aren't open source will be those encumbered by inescapable trade secret agreements with chip vendors. With the exception of those closed binaries, everything from soup to nuts is exactly reproducible from source on any Linux distro with a moderately current native toolchain and autotools. Before the first unit ships retail, these git repositories will be carefully scrubbed of encumbered material and opened to the public. Pull one git repository and run one script, and a few hours later you have your own JFFS2 image that you can burn to flash using facilities we will leave in U-Boot for end-users' benefit. Absolutely everything in the system can be point-fixed and recompiled by the end user, with results as predictable and reproducible as I know how to make them for myself. Updates from third-party upstreams can be merged using the tools that I believe to be best-in-class for the purpose and use myself, daily. No binary ever ships without passing through an autobuild and unit test framework that I provide as part of the end user source code release. That's my personal standard of release quality. Now tell me, how does that compare to your employer's? > CodeSourcery and MontaVista and Red Hat stay in business? Not with > the quality of their code or their customer service, I'll tell you > that -- although Mark Mitchell is probably the best release manager Lots of people would disagree with you about that (and independant surveys would back the disagreement), like they would disagree with you about most things. I have never particularly feared being in the minority, as long as I'm right. :-) But seriously, if you haven't heard the complaints about unreproducibility of Red Hat toolchains going back to the "GCC 2.96" debacle, you haven't been listening -- and MontaVista became notorious in the industry for deliberately mucking with kernel APIs as a vendor lock-in tactic. (They appear to have reformed substantially since the 2.4.x days.) I don't know Mark personally but he appears to be as open about CodeSourcery's processes and priorities as any toolchain vendor has ever been, and GCC 4.1.2 looks like it's going to be as stable as any upstream GCC release has ever been and perform decently as well, so I don't have much to complain about in that department.
Re: GPL vs non-GPL device drivers
On Fri, 23 Feb 2007 00:18:26 + Alan wrote: > > me off, and in the meantime, you know where to find your keyboard's > > "stick my fingers in my ears and shout la-la-la-I-can't-hear-you" key. > > :-) > > I was hoping you'd take the pseudo-legal noise elsewhere. Yes. I find it interesting, but it should be on [EMAIL PROTECTED] instead of here. --- ~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 1/2] ibmebus: dynamic addiiton/removal of adapters, uevent, root device based on struct device
From: Joachim Fenkes <[EMAIL PROTECTED]>
This adds two sysfs attributes to /sys/bus/ibmebus which can
be used to notify the ebus driver of added / removed ebus
devices in the OF device tree.
Echoing the device's location code (as found in the OFDT
"ibm,loc-code" property) into the "probe" attribute will
notify ebus of addition of the device and cause the appropriate
device driver's probe function to be called on the device.
Likewise, echoing the location code into the "remove" attribute
will cause the device to be removed from the system.
The writes will block until the respective operation has
finished and return an error code if the operation failed.
Additionally, uevent is now supported by ibmebus through the
generic of_device_uevent function.
The fake root device used to provide a common parent for all
ebus devices is now based on device instead of of_device - it
had no associated devtree node. This saves several checks
throughout the ebus driver.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
I repost this patch because a kind fellow (wave to Paul =)
reminded me of the finer points of patch descriptions - Thanks!
As said before, I deem this ready for inclusion.
arch/powerpc/kernel/ibmebus.c | 129 ++
include/asm-powerpc/ibmebus.h |2
diff -wurp a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
--- a/arch/powerpc/kernel/ibmebus.c 2007-02-22 05:26:24.971939672 +0100
+++ b/arch/powerpc/kernel/ibmebus.c 2007-02-20 23:31:39.0 +0100
@@ -2,6 +2,7 @@
* IBM PowerPC IBM eBus Infrastructure Support.
*
* Copyright (c) 2005 IBM Corporation
+ * Joachim Fenkes <[EMAIL PROTECTED]>
* Heiko J Schick <[EMAIL PROTECTED]>
*
* All rights reserved.
@@ -43,10 +44,8 @@
#include
#include
-static struct ibmebus_dev ibmebus_bus_device = { /* fake "parent" device */
- .name = ibmebus_bus_device.ofdev.dev.bus_id,
- .ofdev.dev.bus_id = "ibmebus",
- .ofdev.dev.bus= _bus_type,
+static struct device ibmebus_bus_device = { /* fake "parent" device */
+ .bus_id = "ibmebus",
};
static void *ibmebus_alloc_coherent(struct device *dev,
@@ -161,18 +160,19 @@ static void __devinit ibmebus_dev_releas
static ssize_t ibmebusdev_show_name(struct device *dev,
struct device_attribute *attr, char *buf)
{
- return sprintf(buf, "%s\n", to_ibmebus_dev(dev)->name);
+ struct ibmebus_dev *ebus_dev = to_ibmebus_dev(dev);
+ char *name = (char*)get_property(ebus_dev->ofdev.node, "name", NULL);
+ return sprintf(buf, "%s\n", name);
}
static DEVICE_ATTR(name, S_IRUSR | S_IRGRP | S_IROTH, ibmebusdev_show_name,
NULL);
-static struct ibmebus_dev* __devinit ibmebus_register_device_common(
+static int __devinit ibmebus_register_device_common(
struct ibmebus_dev *dev, const char *name)
{
int err = 0;
- dev->name = name;
- dev->ofdev.dev.parent = _bus_device.ofdev.dev;
+ dev->ofdev.dev.parent = _bus_device;
dev->ofdev.dev.bus = _bus_type;
dev->ofdev.dev.release = ibmebus_dev_release;
@@ -186,12 +186,12 @@ static struct ibmebus_dev* __devinit ibm
if ((err = of_device_register(>ofdev)) != 0) {
printk(KERN_ERR "%s: failed to register device (%d).\n",
__FUNCTION__, err);
- return NULL;
+ return -ENODEV;
}
device_create_file(>ofdev.dev, _attr_name);
- return dev;
+ return 0;
}
static struct ibmebus_dev* __devinit ibmebus_register_device_node(
@@ -205,18 +205,18 @@ static struct ibmebus_dev* __devinit ibm
if (!loc_code) {
printk(KERN_WARNING "%s: node %s missing 'ibm,loc-code'\n",
__FUNCTION__, dn->name ? dn->name : "");
- return NULL;
+ return ERR_PTR(-EINVAL);
}
if (strlen(loc_code) == 0) {
printk(KERN_WARNING "%s: 'ibm,loc-code' is invalid\n",
__FUNCTION__);
- return NULL;
+ return ERR_PTR(-EINVAL);
}
dev = kzalloc(sizeof(struct ibmebus_dev), GFP_KERNEL);
if (!dev) {
- return NULL;
+ return ERR_PTR(-ENOMEM);
}
dev->ofdev.node = of_node_get(dn);
@@ -227,9 +227,9 @@ static struct ibmebus_dev* __devinit ibm
min(length, BUS_ID_SIZE - 1));
/* Register with generic device framework. */
- if (ibmebus_register_device_common(dev, dn->name) == NULL) {
+ if (ibmebus_register_device_common(dev, dn->name) != 0) {
kfree(dev);
- return NULL;
+ return ERR_PTR(-ENODEV);
}
return dev;
@@ -240,9 +240,8 @@ static void ibmebus_probe_of_nodes(char*
struct device_node *dn = NULL;
while ((dn = of_find_node_by_name(dn,
[PATCH 3/3] eCryptfs: no path_release() after path_lookup() error
Dmitriy Monakhov wrote:
> if path_lookup() return non zero code we don't have to worry about
> 'nd' parameter, but ecryptfs_read_super does path_release() after
> path_lookup has failed, and dentry counter becomes negative
Do not do a path_release after a path_lookup error.
Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
---
fs/ecryptfs/main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ecryptfs/main.c b/fs/ecryptfs/main.c
index 80044d1..812427e 100644
--- a/fs/ecryptfs/main.c
+++ b/fs/ecryptfs/main.c
@@ -487,7 +487,7 @@ static int ecryptfs_read_super(struct super_block *sb,
const char *dev_name)
rc = path_lookup(dev_name, LOOKUP_FOLLOW, );
if (rc) {
ecryptfs_printk(KERN_WARNING, "path_lookup() failed\n");
- goto out_free;
+ goto out;
}
lower_root = nd.dentry;
if (!lower_root->d_inode) {
--
1.4.4.4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] eCryptfs: remove unnecessary flush_dcache_page()
Remove unnecessary flush_dcache_page() call. Thanks to Dmitriy Monakhov for pointing this out. Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]> --- fs/ecryptfs/mmap.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c index 842497d..2a65914 100644 --- a/fs/ecryptfs/mmap.c +++ b/fs/ecryptfs/mmap.c @@ -238,7 +238,6 @@ int ecryptfs_do_readpage(struct file *file, struct page *page, lower_page_data = kmap_atomic(lower_page, KM_USER1); memcpy(page_data, lower_page_data, PAGE_CACHE_SIZE); kunmap_atomic(lower_page_data, KM_USER1); - flush_dcache_page(lower_page); kunmap_atomic(page_data, KM_USER0); flush_dcache_page(page); rc = 0; -- 1.4.4.4 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/3] eCryptfs: set O_LARGEFILE when opening lower file
Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
> Lets explicitly add O_LARGEFILE to opened lower file flags as it
> done in unionfs and nfsd. Also remove unnecessery #define from
> ecryptfs_initialize_file().
O_LARGEFILE should be set here when opening the lower file.
Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
---
fs/ecryptfs/file.c |1 +
fs/ecryptfs/inode.c |3 ---
2 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/fs/ecryptfs/file.c b/fs/ecryptfs/file.c
index bd969ad..7a7d25d 100644
--- a/fs/ecryptfs/file.c
+++ b/fs/ecryptfs/file.c
@@ -205,6 +205,7 @@ int ecryptfs_open_lower_file(struct file **lower_file,
{
int rc = 0;
+ flags |= O_LARGEFILE;
dget(lower_dentry);
mntget(lower_mnt);
*lower_file = dentry_open(lower_dentry, lower_mnt, flags);
diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
index cf02a66..1b12e49 100644
--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
@@ -200,9 +200,6 @@ static int ecryptfs_initialize_file(struct dentry
*ecryptfs_dentry)
inode = ecryptfs_dentry->d_inode;
crypt_stat = _inode_to_private(inode)->crypt_stat;
lower_flags = ((O_CREAT | O_TRUNC) & O_ACCMODE) | O_RDWR;
-#if BITS_PER_LONG != 32
- lower_flags |= O_LARGEFILE;
-#endif
lower_mnt = ecryptfs_dentry_to_lower_mnt(ecryptfs_dentry);
/* Corresponding fput() at end of this function */
if ((rc = ecryptfs_open_lower_file(_file, lower_dentry, lower_mnt,
--
1.4.4.4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ibmebus: whitespace fixes
From: Joachim Fenkes <[EMAIL PROTECTED]>
This fixes whitespacing in ibmebus.[ch] - no functionality changed.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ibmebus.c | 126 +-
include/asm-powerpc/ibmebus.h | 42 +++---
diff -urp b/arch/powerpc/kernel/ibmebus.c c/arch/powerpc/kernel/ibmebus.c
--- b/arch/powerpc/kernel/ibmebus.c 2007-02-22 05:43:32.133934656 +0100
+++ c/arch/powerpc/kernel/ibmebus.c 2007-02-20 23:31:39.0 +0100
@@ -4,35 +4,35 @@
* Copyright (c) 2005 IBM Corporation
* Joachim Fenkes <[EMAIL PROTECTED]>
* Heiko J Schick <[EMAIL PROTECTED]>
- *
+ *
* All rights reserved.
*
- * This source code is distributed under a dual license of GPL v2.0 and OpenIB
- * BSD.
+ * This source code is distributed under a dual license of GPL v2.0 and OpenIB
+ * BSD.
*
* OpenIB BSD License
*
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
*
- * Redistributions of source code must retain the above copyright notice, this
- * list of conditions and the following disclaimer.
+ * Redistributions of source code must retain the above copyright notice, this
+ * list of conditions and the following disclaimer.
*
- * Redistributions in binary form must reproduce the above copyright notice,
- * this list of conditions and the following disclaimer in the documentation
+ * Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
* and/or other materials
- * provided with the distribution.
+ * provided with the distribution.
*
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
- * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
* BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER
- * IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
@@ -54,7 +54,7 @@ static void *ibmebus_alloc_coherent(stru
gfp_t flag)
{
void *mem;
-
+
mem = kmalloc(size, flag);
*dma_handle = (dma_addr_t)mem;
@@ -62,7 +62,7 @@ static void *ibmebus_alloc_coherent(stru
}
static void ibmebus_free_coherent(struct device *dev,
- size_t size, void *vaddr,
+ size_t size, void *vaddr,
dma_addr_t dma_handle)
{
kfree(vaddr);
@@ -78,7 +78,7 @@ static dma_addr_t ibmebus_map_single(str
static void ibmebus_unmap_single(struct device *dev,
dma_addr_t dma_addr,
-size_t size,
+size_t size,
enum dma_data_direction direction)
{
return;
@@ -89,13 +89,13 @@ static int ibmebus_map_sg(struct device
int nents, enum dma_data_direction direction)
{
int i;
-
+
for (i = 0; i < nents; i++) {
- sg[i].dma_address = (dma_addr_t)page_address(sg[i].page)
+ sg[i].dma_address = (dma_addr_t)page_address(sg[i].page)
+ sg[i].offset;
sg[i].dma_length = sg[i].length;
}
-
+
return nents;
}
@@ -127,15 +127,15 @@ static int ibmebus_bus_probe(struct devi
struct ibmebus_driver *ibmebusdrv = to_ibmebus_driver(dev->driver);
const struct of_device_id *id;
int error = -ENODEV;
-
+
if (!ibmebusdrv->probe)
return
Re: Weird hard disk noise on shutdown (bug #7674)
Rolf Offermanns wrote: I hear the same strange noise on poweroff (2.6.20 vanilla). This is what I get on my system with ATA_DEBUG and ATA_VERBOSE_DEBUG both defined. The system will *not* poweroff with "halt -f" so there was no noise! md: stopping all md devices. Synchronizing SCSI cache for disk sda: ata_scsi_dump_cdb: CDB (1:0,0,0) 35 00 00 00 00 00 00 00 00 ata_scsi_translate: ENTER ata1: ata_dev_select: ENTER, ata1: device 0, wait 1 ata_tf_load_pio: device 0xA0 ata_exec_command_pio: ata1: cmd 0xE7 ata_scsi_translate: EXIT ata_host_intr: ata1: protocol 1 task_state 2 ata_hsm_move: ata1: protocol 1 task_state 2 (dev_stat 0x50) ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50 System halted. If I do a sysrq-o right after this, the above message repeate once more and the system turns off w/o the disturbing noise. For the next messages, I booted the system completely (no init=/bin/sh) and did a "poweroff" at the console prompt after the boot was completed. This time the noise was there. From these traces you can clearly see that no STANDBY IMMEDIATE (command code 0xE0) was issued before the power-off, which is what would prevent this problem. If you wait long enough after halting before you power down, you may not get the noise, since many laptop drives unload the heads after a fairly short period of inactivity, and so the heads are already unloaded when the power is shut off. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver
On Feb 22, 2007, at 4:18 PM, Robert Hancock wrote: model and (partial) firmware revision of the drives: Maxtor 7V300F0 VA11 Maxtor 7B300S0 BANC Until I disabled NCQ I got gazillions of messages like the ones below and absymal performance. - ask ata5: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0xf) Sounds like those are some that we should be blacklisting as well, unless Eric has a good reason why not (CCing). Can you provide the full firmware revision strings from those drives, i.e. from "hdparm -I"? ATA device, with non-removable media Model Number: Maxtor 7B300S0 Firmware Revision: BANC1B70 ATA device, with non-removable media Model Number: Maxtor 7V300F0 Firmware Revision: VA111630 - ask -- http://develooper.com/ - http://askask.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: -freg-struct-return?
> To some degree linux-arch would be a good list for it, but it's closed, > even to monitor. linux-arch is only for architecture code, but yes it serves a similar purpose. But it's very specialized. What is discussed there is unlikely to be of much interest to most people. I was thinking of a relatively low volume list where quick notes for any general interfaces changes that likely needs adaptions in a wide range of code could be sent. Then even people who cannot follow l-k or git due to volume could subscribe to that and adapt their code as needed. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] libata: add NCQ blacklist entries from Silicon Image Windows driver
Ask Bjørn Hansen wrote:
On Feb 21, 2007, at 10:57 PM, Jeff Garzik wrote:
+/* The following blacklist entries are taken from the Windows
+ driver .inf files for the Silicon Image 3124 and 3132. */
+{ "Maxtor 7B250S0","BANC1B70",ATA_HORKAGE_NONCQ, },
[...]
Do we have information that these drives fail on non-SiI controllers?
At least tangentially related:
On one of my boxes (running 2.6.18-1.2869 from Fedora) I have a couple
of other Maxtor drives that didn't like NCQ. They are on a JMicron
20360/20363 (ahci driver). (There's also a Promise 300 TX4 card in the
box and an Intel ICH8 that shows up with ata_piix).
model and (partial) firmware revision of the drives:
Maxtor 7V300F0 VA11
Maxtor 7B300S0 BANC
Until I disabled NCQ I got gazillions of messages like the ones below
and absymal performance.
- ask
ata5: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0xf)
Sounds like those are some that we should be blacklisting as well,
unless Eric has a good reason why not (CCing). Can you provide the full
firmware revision strings from those drives, i.e. from "hdparm -I"?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SLUB: The unqueued Slab allocator
On Thu, Feb 22, 2007 at 10:42:23AM -0800, Christoph Lameter wrote: > On Thu, 22 Feb 2007, Andi Kleen wrote: > > > >SLUB does not need a cache reaper for UP systems. > > > > This means constructors/destructors are becomming worthless? > > Can you describe your rationale why you think they don't make > > sense on UP? > > Cache reaping has nothing to do with constructors and destructors. SLUB > fully supports constructors and destructors. If you don't cache constructed but free objects then there is no cache advantage of constructors/destructors and they would be useless. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ACPI driver support for pata
Alan wrote: On Thu, 22 Feb 2007 12:11:32 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: Alan wrote: ACPI is the only way to do cable handling on the Nvidia PATA chipset. The You failed to quote the salient part of the message. Disliking a separate pata_acpi driver in no way invalidates your statement (quoted above). If you drive a device by the ACPI interface you don't get to fiddle with it directly or you end up in a murky world of undefined and ungood behaviour. Testing and vendor information both say pata_acpi is the right way to drive Nvidia PATA ports. Couldn't be do this generically inside libata core somehow, i.e. try to use ACPI to set the proper mode and fall back to the driver-specific mode setting code if that didn't work? I think if we could do that it would solve a number of problems (i.e. we could prevent it from doing this on SATA controllers which appear to be IDE based on the PCI ID, like the NVIDIA SATA controllers, since the _GTM and _STM methods seem to have undefined behavior on SATA). This would also eliminate the need for mkinitrd, people, etc. to know that they're supposed to be loading this other pata_acpi driver instead, since any PATA driver could take advantage of this feature. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
> It's brilliant for disk I/O, not for networking for which > blocking is the norm not the exception. > > So people will have to likely do something like divide their > applications into handling for I/O to files and I/O to networking. > So beautiful. :-) > > Nobody has proposed anything yet which scales well and handles both > cases. The truly brilliant thing about the whole "create a thread on blocking" is that you immediately make *every* system call asynchronous-capable, including the thousands of obscure ioctls, without having to boil the ocean rewriting 5/6 of the kernel from implicit (stack-based) to explicit state machines. You're right that it doesn't solve everything, but it's a big step forward while keeping a reasonably clean interface. Now, we have some portions of the kernel (to be precise, those that currently support poll() and select()) that are written as explicit state machines and can block on a much smaller context structure. In truth, the division you assume above isn't so terrible. My applications are *already* written like that. It's just "poll() until I accumulate a whole request, then fork a thread to handle it." The only way to avoid allocating a kernel stack is to have the entire handling code path, including the return to user space, written in explicit state machine style. (Once you get to user space, you can have a threading library there if you like.) All the flaming about different ways to implement completion notification is precisely because not much is known about the best way to do it; there aren't a lot of applications that work that way. (Certainly that's because it wasn't possible before, but it's clearly an area that requires research, so not committing to an implementation is A Good Thing.) But once that is solved, and "system call complete" can be reported without returning to a user-space thread (which is basically an alternate system call submission interface, *independent* of the fibril/threadlet non-blocking implementation), then you can find the hot paths in the kernel and special-case them to avoid creating a whole thread. To use a networking analogy, this is a cleanly layered protocol design, with an optimized fast path *implementation* that blurs the boundaries. As for the overhead of threading, there are basically three parts: 1) System call (user/kernel boundary crossing) costs. These depend only on the total number of system calls and not on the number of threads making them. They can be mitigated *if necessary* with a syslet-like "macro syscall" mechanism to increase the work per boundary crossing. The only place threading might increase these numbers is thread synchronization, and futexes already solve that pretty well. 2) Register and stack swapping. These (and associated cache issues) are basically unavoidable, and are the bare minimum that longjmp() does. Nothing thread-based is going to reduce this. (Actually, the kernel can do better than user space because it can do lazy FPU state swapping.) 3) MMU context switch costs. These are the big ones, particular on x86 without TLB context IDs. However, these fall into a few categories: - Mandatory switches because the entire application is blocked. I don't see how this can be avoided; these are the cases where even a user-space longjmp-based thread library would context switch. - Context switches between threads in an application. The Linux kernel already optimizes out the MMU context switch in this case, and the scheduler already knows that such context switches are cheaper and preferred. The one further optimization that's possible is if you have a system call that (in a common case) blocks multiple times *without accessing user memory*. This is not a read() or write(), but could be something like fsync() or ftruncate(). In this case, you could temporarily mark the thread as a "kernel thread" that can run in any MMU context, and then fix it explicitly when you unmark it on the return path. I can see the space overhead of 1:1 threading, but I really don't think there's much time overhead. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm] clocksource init adjustments (fix bug #7426)
This patch resolves the issue found here:
http://bugme.osdl.org/show_bug.cgi?id=7426
The basic summary is:
Currently we register most of i386/x86_64 clocksources at module_init
time. Then we enable clocksource selection at late_initcall time. This
causes some problems for drivers that use gettimeofday for init
calibration routines (specifically the es1968 driver in this case),
where durring module_init, the only clocksource available is the low-res
jiffies clocksource. This may cause slight calibration errors, due to
the small sampling time used.
It should be noted that drivers that require fine grained time may not
function on architectures that do not have better then jiffies
resolution timekeeping (there are a few). However, this does not
discount the reasonable need for such fine-grained timekeeping at init
time.
Thus the solution here is to register clocksources earlier (ideally when
the hardware is being initialized), and then we enable clocksource
selection at fs_initcall (before device_initcall).
This patch should probably get some testing time in -mm, since
clocksource selection is one of the most important issues for correct
timekeeping, and I've only been able to test this on a few of my own
boxes.
thanks
-john
Signed-off-by: John Stultz <[EMAIL PROTECTED]>
arch/i386/kernel/hpet.c | 80 ---
arch/i386/kernel/i8253.c |2
arch/i386/kernel/setup.c |1
arch/i386/kernel/time.c |1
arch/i386/kernel/tsc.c| 83
arch/x86_64/kernel/hpet.c | 122 +++---
arch/x86_64/kernel/tsc.c |7 --
drivers/clocksource/acpi_pm.c |5 +
drivers/clocksource/cyclone.c |2
kernel/time/clocksource.c |8 +-
10 files changed, 145 insertions(+), 166 deletions(-)
linux-2.6.21-rc1_adjust-clocksource-selection_C7.patch
diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index e1006b7..f3ab61e 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -201,12 +201,30 @@ static int hpet_next_event(unsigned long
}
/*
+ * Clock source related code
+ */
+static cycle_t read_hpet(void)
+{
+ return (cycle_t)hpet_readl(HPET_COUNTER);
+}
+
+static struct clocksource clocksource_hpet = {
+ .name = "hpet",
+ .rating = 250,
+ .read = read_hpet,
+ .mask = HPET_MASK,
+ .shift = HPET_SHIFT,
+ .flags = CLOCK_SOURCE_IS_CONTINUOUS,
+};
+
+/*
* Try to setup the HPET timer
*/
int __init hpet_enable(void)
{
unsigned long id;
uint64_t hpet_freq;
+ u64 tmp;
if (!is_hpet_capable())
return 0;
@@ -253,6 +271,25 @@ #endif
/* Start the counter */
hpet_start_counter();
+ /* Initialize and register HPET clocksource
+*
+* hpet period is in femto seconds per cycle
+* so we need to convert this to ns/cyc units
+* aproximated by mult/2^shift
+*
+* fsec/cyc * 1nsec/100fsec = nsec/cyc = mult/2^shift
+* fsec/cyc * 1ns/100fsec * 2^shift = mult
+* fsec/cyc * 2^shift * 1nsec/100fsec = mult
+* (fsec/cyc << shift)/100 = mult
+* (hpet_period << shift)/FSEC_PER_NSEC = mult
+*/
+ tmp = (u64)hpet_period << HPET_SHIFT;
+ do_div(tmp, FSEC_PER_NSEC);
+ clocksource_hpet.mult = (u32)tmp;
+
+ clocksource_register(_hpet);
+
+
if (id & HPET_ID_LEGSUP) {
hpet_enable_int();
hpet_reserve_platform_timers(id);
@@ -273,49 +310,6 @@ out_nohpet:
return 0;
}
-/*
- * Clock source related code
- */
-static cycle_t read_hpet(void)
-{
- return (cycle_t)hpet_readl(HPET_COUNTER);
-}
-
-static struct clocksource clocksource_hpet = {
- .name = "hpet",
- .rating = 250,
- .read = read_hpet,
- .mask = HPET_MASK,
- .shift = HPET_SHIFT,
- .flags = CLOCK_SOURCE_IS_CONTINUOUS,
-};
-
-static int __init init_hpet_clocksource(void)
-{
- u64 tmp;
-
- if (!hpet_virt_address)
- return -ENODEV;
-
- /*
-* hpet period is in femto seconds per cycle
-* so we need to convert this to ns/cyc units
-* aproximated by mult/2^shift
-*
-* fsec/cyc * 1nsec/100fsec = nsec/cyc = mult/2^shift
-* fsec/cyc * 1ns/100fsec * 2^shift = mult
-* fsec/cyc * 2^shift * 1nsec/100fsec = mult
-* (fsec/cyc << shift)/100 = mult
-* (hpet_period << shift)/FSEC_PER_NSEC = mult
-*/
- tmp = (u64)hpet_period << HPET_SHIFT;
- do_div(tmp, FSEC_PER_NSEC);
- clocksource_hpet.mult = (u32)tmp;
-
- return clocksource_register(_hpet);
-}
-
-module_init(init_hpet_clocksource);
#ifdef CONFIG_HPET_EMULATE_RTC
Re: libata FUA revisited
Ric Wheeler wrote: I think that FUA was designed for a different use case than what Linux is using barriers for currently. The advantage with FUA is when you have "before barrier", "after barrier" and "don't care" sets, where only the specific things you care about ordering are in the before/after barrier sets. Then you can do this: Issue all before barrier requests with FUA bit set Wait for all those to complete Issue all after barrier requests with FUA bit set Wait for all those to complete A couple of issues with this would be in how to support our current semantics of fsync(). Today, the flush behavior of the barrier/fsync combination means that applications can have a hard promise of data on platter for any file after a successful fsync command. If I understand correctly, to get a similar semantic from a pure FUA implementation would require us to tag all file IO as FUA. I suspect that this would actually be less efficient since it would not allow the drives to reorder IO's up to the point that we actually care (fsync time). I think for the fsync case a cache flush would likely still be needed, unless the app was only writing small amounts of data in between the syncs (it may be complicated to figure out when to do that, though). The other big user of barriers is the internal transaction of journaled file systems. It would seem that we would need to tag each write from the journal with a FUA IO as well. Again, we might actually go more slowly in some cases as you mention below. The limited queue depth of NCQ would seem to make it much harder to have a win in this case... I think the journal write case is less problematic as there are likely to be much fewer/smaller requests involved which would be more likely to fit inside the queue.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] Re: Data corruption with raid5/dm-crypt/lvm/reiserfs on 2.6.19.2
On Mon, 2007-01-22 at 22:42 +0100, Christophe Saout wrote: > Am Montag, den 22.01.2007, 11:56 -0800 schrieb Andrew Morton: > > > There has been a long history of similar problems when raid and dm-crypt > > are used together. I thought a couple of months ago that we were hot on > > the trail of a fix, but I don't think we ever got there. Perhaps > > Christophe can comment? > > No, I think it's exactly this bug. Three month ago someone came up with > a very reliable test case and I managed to nail down the bug. > > Readaheads that were aborted by the raid5 code (or some layer below) > were signalled using a cleared BIO_UPTODATE bit, but no error code, and > were missed as aborted by dm-crypt (all other layers apparently set the > error code in this case, so this only happened with raid5) which could > mess up the buffer cache. > > Anyway, it then turned out this bug was already "accidentally" fixed in > 2.6.19 by RedHat in order to play nicely with make_request changes (the > stuff to reduce stack usage with stacked block device layers), that's > why you probably missed that it got fixed. The fix for pre-2.6.19 > kernels went into some 2.6.16.x and 2.6.18.6. Hi Chris: I've been trying Andrew's suggestion of doing fault injections, currently just kmalloc() and mempool_alloc(), and just got a hang on 2.6.12 that I'm poking around on with kgdb. I'm using dm-crypt on a SCSI raid-1 (mirrored) root partition. I'm using your patch that fixes the raid5 problem just to play it safe. So far it looks like processes are waiting to be woken up by the buffer cache once reads have completed. -piet > > > -- > dm-devel mailing list > [EMAIL PROTECTED] > https://www.redhat.com/mailman/listinfo/dm-devel -- Piet DelaneyPhone: (408) 200-5256 Blue Lane Technologies Fax: (408) 200-5299 10450 Bubb Rd. Cupertino, Ca. 95014Email: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [PATCH] USB Elan FTDI: check for workqueue creation
On Mon, 19 Feb 2007 21:15:49 +0300, Cyrill Gorcunov <[EMAIL PROTECTED]> wrote: > +++ b/drivers/usb/misc/ftdi-elan.c > @@ -57,9 +57,9 @@ module_param(distrust_firmware, bool, 0); > MODULE_PARM_DESC(distrust_firmware, "true to distrust firmware > power/overcurren" > "t setup"); > extern struct platform_driver u132_platform_driver; > -static struct workqueue_struct *status_queue; > +static struct workqueue_struct *status_queue = NULL; You better drop this part. Someone is bound to object. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] usbatm: Detect usb device shutdown and ignore failed urbs.
On Thu, 22 Feb 2007 11:43:38 +0100, Duncan Sands <[EMAIL PROTECTED]> wrote: > > + /* the module/device has probably been removed */ > > + if (urb->status == -ESHUTDOWN) > > + return; > > + > > if (printk_ratelimit()) > > atm_warn(channel->usbatm, "%s: urb 0x%p failed (%d)!\n", > > __func__, urb, urb->status); > > I would rather just suppress the warning in this case, and still do the > delayed > schedule of the tasklet, in case this error was spurious and we're not really > about to be disconnected. I disagree. If ESHUTDOWN is received, the endpoint is definitely gone. I can see why you might want to retry EPROTO, ELISEQ, etc. but this case is different. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
.mailmap in top directory
On Wed, Feb 07, 2007 at 10:42:27PM -0800, Andrew Morton wrote: [] > > > add-mailmap-for-proper-git-shortlog-output.patch > > > > i can't tell anything about this one. For what? > > Beats me. git stuff. I'll let Linus decide. So it's in 2.6.21-rc1. Is it really so necessary in the linux-source? Who suppose to track and update this? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] slab: free pages in a batch in drain_freelist
On Thu, 22 Feb 2007, Pekka J Enberg wrote: > As suggested by William, free the actual pages in a batch so that we > don't keep pounding on l3->list_lock. This means holding the l3->list_lock for a prolonged time period. The existing code was done this way in order to make sure that the interrupt holdoffs are minimal. There is no pounding. The cacheline with the list_lock is typically held until the draining is complete. While we drain the freelist we need to be able to respond to interrupts. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote: > On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote: > > > > > > However, I'm still getting the same snowy effects, which doesn't come > > > as a surprise since the actual mode timings used are just the same ... > > > > Yes, because the EDID has only 1 mode entry. But now you can use 'fbset > > 1024x768-60' (or any mode smaller than 1600x1200-60) for example and it > > should work. > > No, it doesn't. I've tried all the methods from 640x480 to 1600x1200, > and they /all/ come up snowy. This is starting to look queerer and > queerer. I've also tried changing vf min and max as you suggested: Before we proceed, do you agree that the patch will allow you to change video modes without disabling DDC support? So this is still a valid fix? > > > You might want to change vfmin and vfmax to 59 and 61 > > and even the M and MR methods which you suggested in the other email. > Since nvidiafb is being loaded from the command line because it's a > blacklisted module otherwise, I've been using the mode_option option. > However, neither the mode_option nor fbset seem to give me anything > not snowy. When does your display become snowy? Is the snow constant or does it only snow when doing heavy text operations, such as scrolling? I presume that X's nv driver or vesafb does not exhibit this problem? 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: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
On Thu, 2007-02-22 at 21:39 +0100, Luca Tettamanti wrote: > Il Thu, Feb 22, 2007 at 09:01:52AM +0100, Giuseppe Bilotta ha scritto: > > On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > >On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote: > > Still scratching my head :| > > Tony, > this is the patch (modulo cosmetic stuff) that I sent to Giuseppe. I > believe it's correct (I cross checked with X.org driver): > Yes, the patch does look correct. I also don't understand why Giuseppe's hardware failed to do i2c with this... 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: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
> to do anything but chase pointers through cache. Done right, it > hardly even branches (although the branch misprediction penalty is a > lot less of a worry on current x86_64 than it was in the > mega-superscalar-out-of-order-speculative-execution days). It's damn Actually it costs a lot more on at least one vendors processor because you stall very long pipelines. > threadlets promise that they will not touch anything thread-local, and > that when the FPU is handed to them in a specific, known state, they > leave it in that same state. (Some of the flags can be We don't use the FPU in the kernel except in very weird cases where it makes an enormous performance difference. The threadlets also have the same page tables so they have the same %cr3 so its very cheap to switch, basically a predicted jump and some register loads > Do me a favor. Do some floating point math and a memcpy() in between > syscalls in the threadlet. Actually fiddle with errno and the FPU We don't have an errno in the kernel because its a stupid idea. Errno is a user space hack for compatibility with 1970's bad design. So its not relevant either. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
> Oh yeah? For IRIX in 1991? Or for that matter, for Linux/ARM EABI > today? Tell me, how many of what sort of users do you support Solaris (NTL - very large ISP/Telco), Dec server 5000 (for fun), Irix (and linux cross for Irix removal), MIPS embedded (including the port to Linux of Algorithmics toolchain) for Sonix then 3COM routers. It's not a hard problem. gcc 2.x wasn't too hot on MIPS but it worked although the Irix compiler generated vastly better code (and AFAIK still does). There are folks who maintain cross devel chains for just about every Linux platform specifically for testing and while it isn't a small job they do seem to be coping quite happily. > CodeSourcery and MontaVista and Red Hat stay in business? Not with > the quality of their code or their customer service, I'll tell you > that -- although Mark Mitchell is probably the best release manager Lots of people would disagree with you about that (and independant surveys would back the disagreement), like they would disagree with you about most things. > that any GNU project has ever had. > me off, and in the meantime, you know where to find your keyboard's > "stick my fingers in my ears and shout la-la-la-I-can't-hear-you" key. > :-) I was hoping you'd take the pseudo-legal noise elsewhere. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.20-git15, Suspend to disk
Hi, On Friday, 23 February 2007 00:04, Lukas Hejtmanek wrote: > Hello, > > after some time I've tried to suspend to disk. It basically works but it > complains into log with the following message: Tejun says it is known and he's going to fix it. > BUG: at drivers/pci/pci.c:823 pcim_enable_device() > [] pcim_enable_device+0xbc/0xd0 > [] ata_pci_device_do_resume+0x22/0x80 > [] ata_pci_device_resume+0x15/0x30 > [] pci_device_resume+0x1f/0x60 > [] resume_device+0x5a/0xf0 > [] dpm_resume+0x9e/0xc0 > [] device_resume+0x18/0x30 > [] pm_suspend_disk+0x155/0x230 > [] enter_state+0x146/0x170 > [] state_store+0xbd/0xd0 > [] state_store+0x0/0xd0 > [] subsys_attr_store+0x29/0x40 > [] sysfs_write_file+0xb1/0x110 > [] vfs_write+0xa6/0x140 > [] sysfs_write_file+0x0/0x110 > [] sys_write+0x41/0x70 > [] syscall_call+0x7/0xb > [] sleep_on_timeout+0x30/0xb0 > === > Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 2/2] cciss: add shutdown support (replaces reboot notifier)
On Thu, Feb 22, 2007 at 03:56:11PM -0600, Mike Miller (OS Dev) wrote: > On Thu, Feb 22, 2007 at 09:45:02PM +, Christoph Hellwig wrote: > > On Thu, Feb 22, 2007 at 03:38:45PM -0600, Mike Miller (OS Dev) wrote: > > > Patch 2/2 > > > > > > This adds support for struct pci_driver shutdown and negates the previous > > > NAK'ed > > > reboot_notifier patch. It's much easier, wish I had know about this > > > before. Thanks to > > > Christoph for pointing this out. > > > > Just sondering, where should we have put information about this so driver > > writers/maintainers like you would have found it easily? > > > Excellent question. I wish I had a good answer. It's pretty difficult to > monitor > everything going on, especially when I also have to consider HP's schedule > and those > of our partners. It is properly documented in Documentation/pci.txt as to how to do this... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] sched: dynticks idle load balancing - v2
On Thu, Feb 22, 2007 at 04:26:54AM +0100, Nick Piggin wrote: > This is really ugly, sorry :( hm. myself and others too thought it was a simple and nice idea. > My suggestion for handling this was to increase the maximum balance > interval for an idle CPU, and just implement a global shutdown when > the entire system goes idle. > > The former should take care of the power savings issues for bare metal > hardware, and the latter should solve performance problems for many idle > SMP guests. It should take very little code to implement. coming to max balance interval will be challenging. It needs to save power and at the same time respond to load changes fast enough. > If that approach doesn't cut it, then at least we can have some numbers > to see how much better yours is so we can justify including it. > > If you are against my approach, then I can have a try at coding it up > if you like? Sure. If you can provide a patch, I will be glad to provide power and performance comparision numbers with both the approaches. thanks, suresh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG in 2.6.20-git15, Suspend to disk
Hello, after some time I've tried to suspend to disk. It basically works but it complains into log with the following message: BUG: at drivers/pci/pci.c:823 pcim_enable_device() [] pcim_enable_device+0xbc/0xd0 [] ata_pci_device_do_resume+0x22/0x80 [] ata_pci_device_resume+0x15/0x30 [] pci_device_resume+0x1f/0x60 [] resume_device+0x5a/0xf0 [] dpm_resume+0x9e/0xc0 [] device_resume+0x18/0x30 [] pm_suspend_disk+0x155/0x230 [] enter_state+0x146/0x170 [] state_store+0xbd/0xd0 [] state_store+0x0/0xd0 [] subsys_attr_store+0x29/0x40 [] sysfs_write_file+0xb1/0x110 [] vfs_write+0xa6/0x140 [] sysfs_write_file+0x0/0x110 [] sys_write+0x41/0x70 [] syscall_call+0x7/0xb [] sleep_on_timeout+0x30/0xb0 === -- Lukáš Hejtmánek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: several messages
of the following 2 patches: On Mon, 5 Feb 2007, Johannes Berg wrote: > This patch removes the time suspend/restore code that was done through > a PMU notifier in arch/platforms/powermac/time.c. > > Instead, we introduce arch/powerpc/sysdev/timer.c which creates a sys > device and handles time of day suspend/resume through that. > > Signed-off-by: Johannes Berg <[EMAIL PROTECTED]> > Cc: Andrew Morton <[EMAIL PROTECTED]> > Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]> [patch trimmed] On Wed, 21 Feb 2007, David Brownell wrote: > RTC class suspend/resume support, re-initializing the system clock on resume > >from the clock used to initialize it at boot time. > > - Inlining the same code used by ARM, which saves and restores the >delta between a selected RTC and the current system wall-clock time. > > - Removes calls to that ARM code from AT91, OMAP, and S3C RTCs. > > This goes on top of the patch series removing "struct class_device" usage > >from the RTC framework. That makes class suspend()/resume() work. > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > > --- > drivers/rtc/Kconfig | 24 + > drivers/rtc/class.c | 74 > +++ > drivers/rtc/rtc-at91rm9200.c | 30 - > drivers/rtc/rtc-omap.c | 17 - > drivers/rtc/rtc-s3c.c| 22 > 5 files changed, 91 insertions(+), 76 deletions(-) [patch trimmed] I think, we only want 1, right? And the latter seems to be more generic / platform independent? And as a side-effect, powermac would have to migrate to generic rtc:-) Thanks Guennadi --- Guennadi Liakhovetski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] UML - Fix host LDT lookup initialization locking, try 2
Add some locking to host_ldt_entries to prevent racing when reading
LDT information from the host.
The locking is somewhat more careful than my previous attempt. Now,
only the check of host_ldt_entries is locked. The lock is dropped
immediately afterwards, and if the LDT needs initializing, that (and
the memory allocations needed) proceed outside the lock.
Also fixed some style violations.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/sys-i386/ldt.c | 36
1 file changed, 24 insertions(+), 12 deletions(-)
Index: linux-2.6.17/arch/um/sys-i386/ldt.c
===
--- linux-2.6.17.orig/arch/um/sys-i386/ldt.c2007-02-05 17:12:14.0
-0500
+++ linux-2.6.17/arch/um/sys-i386/ldt.c 2007-02-22 17:30:24.0 -0500
@@ -7,6 +7,7 @@
#include "linux/slab.h"
#include "linux/types.h"
#include "linux/errno.h"
+#include "linux/spinlock.h"
#include "asm/uaccess.h"
#include "asm/smp.h"
#include "asm/ldt.h"
@@ -386,23 +387,33 @@ static long do_modify_ldt_skas(int func,
return ret;
}
-short dummy_list[9] = {0, -1};
-short * host_ldt_entries = NULL;
+static DEFINE_SPINLOCK(host_ldt_lock);
+static short dummy_list[9] = {0, -1};
+static short * host_ldt_entries = NULL;
-void ldt_get_host_info(void)
+static void ldt_get_host_info(void)
{
long ret;
- struct ldt_entry * ldt;
+ struct ldt_entry * ldt, *tmp;
int i, size, k, order;
+ spin_lock(_ldt_lock);
+
+ if(host_ldt_entries != NULL){
+ spin_unlock(_ldt_lock);
+ return;
+ }
host_ldt_entries = dummy_list+1;
+ spin_unlock(_ldt_lock);
+
for(i = LDT_PAGES_MAX-1, order=0; i; i>>=1, order++);
ldt = (struct ldt_entry *)
__get_free_pages(GFP_KERNEL|__GFP_ZERO, order);
if(ldt == NULL) {
- printk("ldt_get_host_info: couldn't allocate buffer for host
ldt\n");
+ printk("ldt_get_host_info: couldn't allocate buffer for host "
+ "ldt\n");
return;
}
@@ -426,11 +437,13 @@ void ldt_get_host_info(void)
host_ldt_entries = dummy_list;
else {
size = (size + 1) * sizeof(dummy_list[0]);
- host_ldt_entries = kmalloc(size, GFP_KERNEL);
- if(host_ldt_entries == NULL) {
- printk("ldt_get_host_info: couldn't allocate host ldt
list\n");
+ tmp = kmalloc(size, GFP_KERNEL);
+ if(tmp == NULL) {
+ printk("ldt_get_host_info: couldn't allocate host ldt "
+ "list\n");
goto out_free;
}
+ host_ldt_entries = tmp;
}
for(i=0, k=0; iid, 1, ,
@@ -560,6 +572,6 @@ void free_ldt(struct mmu_context_skas *
int sys_modify_ldt(int func, void __user *ptr, unsigned long bytecount)
{
- return(CHOOSE_MODE_PROC(do_modify_ldt_tt, do_modify_ldt_skas, func,
- ptr, bytecount));
+ return CHOOSE_MODE_PROC(do_modify_ldt_tt, do_modify_ldt_skas, func,
+ ptr, bytecount);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] UML - add back accidentally removed error
In the 2.6.20 hang patch, I accidentally threw out an error message.
This puts it back.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/os-Linux/sigio.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6.18-mm/arch/um/os-Linux/sigio.c
===
--- linux-2.6.18-mm.orig/arch/um/os-Linux/sigio.c 2007-02-20
16:12:28.0 -0500
+++ linux-2.6.18-mm/arch/um/os-Linux/sigio.c2007-02-22 13:05:04.0
-0500
@@ -334,8 +334,11 @@ void maybe_sigio_broken(int fd, int read
sigio_lock();
err = need_poll(_sigio_fds, all_sigio_fds.used + 1);
- if(err)
+ if(err){
+ printk("maybe_sigio_broken - failed to add pollfd for "
+ "descriptor %d\n", fd);
goto out;
+ }
all_sigio_fds.poll[all_sigio_fds.used++] =
((struct pollfd) { .fd = fd,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] drivers/isdn/gigaset: build asyncdata.o into the gigaset module (fix)
a) Remove #define acrobatics that have become unnecessary by the move of asyncdata.o into the common part. b) Correct the rule for building the common part into the kernel when some or all hardware specific parts are built as modules. Signed-off-by: Tilman Schmidt <[EMAIL PROTECTED]> --- This patch applies to 2.6.20-rc1. It is the delta between Adrian Bunk's [PATCH] drivers/isdn/gigaset/: build asyncdata.o into the gigaset module which has already been merged, and my [PATCH] drivers/isdn/gigaset: build asyncdata.o into the gigaset module (v2) which came too late to replace it. Please merge. Makefile|9 + asyncdata.c |5 - 2 files changed, 5 insertions(+), 9 deletions(-) diff -purX linux-2.6.20-work/Documentation/dontdiff linux-2.6.21-rc1-orig/drivers/isdn/gigaset/asyncdata.c linux-2.6.21-rc1-work/drivers/isdn/gigaset/asyncdata.c --- linux-2.6.21-rc1-orig/drivers/isdn/gigaset/asyncdata.c 2007-02-22 23:15:53.0 +0100 +++ linux-2.6.21-rc1-work/drivers/isdn/gigaset/asyncdata.c 2007-02-21 13:27:40.0 +0100 @@ -13,11 +13,6 @@ * = */ -/* not set by Kbuild when building both ser_gigaset and usb_gigaset */ -#ifndef KBUILD_MODNAME -#define KBUILD_MODNAME "asy_gigaset" -#endif - #include "gigaset.h" #include #include diff -purX linux-2.6.20-work/Documentation/dontdiff linux-2.6.21-rc1-orig/drivers/isdn/gigaset/Makefile linux-2.6.21-rc1-work/drivers/isdn/gigaset/Makefile --- linux-2.6.21-rc1-orig/drivers/isdn/gigaset/Makefile 2007-02-22 23:15:53.0 +0100 +++ linux-2.6.21-rc1-work/drivers/isdn/gigaset/Makefile 2007-02-21 13:25:47.0 +0100 @@ -1,8 +1,9 @@ gigaset-y := common.o interface.o proc.o ev-layer.o i4l.o asyncdata.o usb_gigaset-y := usb-gigaset.o -bas_gigaset-y := bas-gigaset.o isocdata.o ser_gigaset-y := ser-gigaset.o +bas_gigaset-y := bas-gigaset.o isocdata.o -obj-$(CONFIG_GIGASET_M105) += usb_gigaset.o gigaset.o -obj-$(CONFIG_GIGASET_BASE) += bas_gigaset.o gigaset.o -obj-$(CONFIG_GIGASET_M101) += ser_gigaset.o gigaset.o +obj-$(CONFIG_ISDN_DRV_GIGASET) += gigaset.o +obj-$(CONFIG_GIGASET_M105) += usb_gigaset.o +obj-$(CONFIG_GIGASET_BASE) += bas_gigaset.o +obj-$(CONFIG_GIGASET_M101) += ser_gigaset.o - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird hard disk noise on shutdown (bug #7674)
2007/2/22, Alan <[EMAIL PROTECTED]>: The following will generate a vast amount of debug of which only the end matters. For some reason, related to my current distro, i didn't used init=/bin/sh . The full, bloated, log is here http://www.webalice.it/ceztko/log1 (taken from launch of "poweroff"). I can confirm, as Rolf Offermanns noted, that "halt -f" doesn't cut the power. An extract is here. However i'm worried that the log is trunkated. Is netconsole good enough to use in this case? [17179886.052000] ata_scsi_dump_cdb: CDB (1:0,0,0) 2a 00 07 5b dd 90 00 00 08 [17179886.052000] ata_scsi_translate: ENTER [17179886.052000] scsi_10_lba_len: ten-byte command [17179886.052000] ata_sg_setup: ENTER, ata1 [17179886.052000] ata_sg_setup: 1 sg elements mapped [17179886.052000] ata_fill_sg: PRD[0] = (0x2317000, 0x1000) [17179886.052000] ata_dev_select: ENTER, ata1: device 0, wait 1 [17179886.052000] ata_tf_load_pio: feat 0x0 nsect 0x8 lba 0x90 0xDD 0x5B [17179886.052000] ata_tf_load_pio: device 0xE7 [17179886.052000] ata_exec_command_pio: ata1: cmd 0xCA [17179886.052000] ata_scsi_translate: EXIT [17179886.052000] ata_host_intr: ata1: host_stat 0x24 [17179886.052000] ata_host_intr: ata1: protocol 3 (dev_stat 0x50) [17179886.052000] ata_sg_clean: unmapping 1 sg elements [17179886.056000] rc(4351): READ block 309568 on sda6 [17179886.056000] ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 07 5f 96 40 00 00 08 [17179886.056000] ata_scsi_translate: ENTER [17179886.056000] scsi_10_lba_len: ten-byte command [17179886.056000] ata_sg_setup: ENTER, ata1 [17179886.056000] ata_sg_setup: 1 sg elements mapped [17179886.056000] ata_fill_sg: PRD[0] = (0x7E992000, 0x1000) [17179886.056000] ata_dev_select: ENTER, ata1: device 0, wait 1 [17179886.056000] ata_tf_load_pio: feat 0x0 nsect 0x8 lba 0x40 0x96 0x5F [17179886.056000] ata_tf_load_pio: device 0xE7 [17179886.056000] ata_exec_command_pio: ata1: cmd 0xC8 [17179886.056000] ata_scsi_translate: EXIT [17179886.064000] ata_host_intr: ata1: host_stat 0x24 [17179886.064000] ata_host_intr: ata1: protocol 3 (dev_stat 0x50) [17179886.064000] ata_sg_clean: unmapping 1 sg elements [17179886.064000] S90halt(4351): READ block 307632 on sda6 [17179886.064000] ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 07 5f 8e b0 00 00 08 [17179886.064000] ata_scsi_translate: ENTER [17179886.064000] scsi_10_lba_len: ten-byte command [17179886.064000] ata_sg_setup: ENTER, ata1 [17179886.064000] ata_sg_setup: 1 sg elements mapped [17179886.064000] ata_fill_sg: PRD[0] = (0x7CC47000, 0x1000) [17179886.064000] ata_dev_select: ENTER, ata1: device 0, wait 1 [17179886.064000] ata_tf_load_pio: feat 0x0 nsect 0x8 lba 0xB0 0x8E 0x5F [17179886.064000] ata_tf_load_pio: device 0xE7 [17179886.064000] ata_exec_command_pio: ata1: cmd 0xC8 [17179886.064000] ata_scsi_translate: EXIT [17179886.076000] ata_host_intr: ata1: host_stat 0x24 [17179886.076000] ata_host_intr: ata1: protocol 3 (dev_stat 0x50) [17179886.076000] ata_sg_clean: unmapping 1 sg elements - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata FUA revisited
Tejun Heo wrote: Jens Axboe wrote: On Wed, Feb 21 2007, Tejun Heo wrote: [cc'ing Ric, Hannes and Dongjun, Hello. Feel free to drag other people in.] Robert Hancock wrote: Jens Axboe wrote: But we can't really change that, since you need the cache flushed before issuing the FUA write. I've been advocating for an ordered bit for years, so that we could just do: 3. w/FUA+ORDERED normal operation -> barrier issued -> write barrier FUA+ORDERED -> normal operation resumes So we don't have to serialize everything both at the block and device level. I would have made FUA imply this already, but apparently it's not what MS wanted FUA for, so... The current implementations take the FUA bit (or WRITE FUA) as a hint to boost it to head of queue, so you are almost certainly going to jump ahead of already queued writes. Which we of course really do not. Yeah, I think if we have tagged write command and flush tagged (or barrier tagged) things can be pretty efficient. Again, I'm much more comfortable with separate opcodes for those rather than bits changing the behavior. ORDERED+FUA NCQ would still be preferable to an NCQ enabled flush command, though. I think we're talking about two different things here. 1. The barrier write (FUA write) combined with flush. I think it would help improving the performance but I think issuing two commands shouldn't be too slower than issuing one combined command unless it causes extra physical activity (moving head, etc...). 2. FLUSH currently flushes all writes. If we can mark certain commands requiring ordering, we can selectively flush or order necessary writes. (No need to flush 16M buffer all over the disk when only journal needs barriering) We can certainly (given time to play in the lab!) try to measure this in with a micro-benchmark (with an analyzer or with block trace?). A normal flush command in my old tests seemed to be in the 20 ms range (mixed in with and occasional "freebie" cache flush which returns in 50 usecs or so - cache must be empty). Another idea Dongjun talked about while drinking in LSF was ranged flush. Not as flexible/efficient as the previous option but much less intrusive and should help quite a bit, I think. But that requires extensive tracking, I'm not so sure the implementation of that for barriers would be very clean. It'd probably be good for fsync, though. I was mostly thinking about journal area. Using it for other purposes would incur a lot of complexity. :-( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata FUA revisited
Tejun Heo wrote: [cc'ing Ric, Hannes and Dongjun, Hello. Feel free to drag other people in.] Robert Hancock wrote: Jens Axboe wrote: But we can't really change that, since you need the cache flushed before issuing the FUA write. I've been advocating for an ordered bit for years, so that we could just do: 3. w/FUA+ORDERED normal operation -> barrier issued -> write barrier FUA+ORDERED -> normal operation resumes So we don't have to serialize everything both at the block and device level. I would have made FUA imply this already, but apparently it's not what MS wanted FUA for, so... The current implementations take the FUA bit (or WRITE FUA) as a hint to boost it to head of queue, so you are almost certainly going to jump ahead of already queued writes. Which we of course really do not. Yeah, I think if we have tagged write command and flush tagged (or barrier tagged) things can be pretty efficient. Again, I'm much more comfortable with separate opcodes for those rather than bits changing the behavior. Another idea Dongjun talked about while drinking in LSF was ranged flush. Not as flexible/efficient as the previous option but much less intrusive and should help quite a bit, I think. I think that FUA was designed for a different use case than what Linux is using barriers for currently. The advantage with FUA is when you have "before barrier", "after barrier" and "don't care" sets, where only the specific things you care about ordering are in the before/after barrier sets. Then you can do this: Issue all before barrier requests with FUA bit set Wait for all those to complete Issue all after barrier requests with FUA bit set Wait for all those to complete A couple of issues with this would be in how to support our current semantics of fsync(). Today, the flush behavior of the barrier/fsync combination means that applications can have a hard promise of data on platter for any file after a successful fsync command. If I understand correctly, to get a similar semantic from a pure FUA implementation would require us to tag all file IO as FUA. I suspect that this would actually be less efficient since it would not allow the drives to reorder IO's up to the point that we actually care (fsync time). The other big user of barriers is the internal transaction of journaled file systems. It would seem that we would need to tag each write from the journal with a FUA IO as well. Again, we might actually go more slowly in some cases as you mention below. The limited queue depth of NCQ would seem to make it much harder to have a win in this case... Meanwhile a bunch of "don't care" requests could be going through on the device in the background. If we could do this, then I think there would be an advantage. Right now, it just saves a command to the drive when we're flushing on the post-barrier writes. This would only be efficient with NCQ FUA, because regular FUA forces the requests to complete serially, whereas in this case we don't really care what order the individual requests finish, we just care about the ordering of the pre vs. post barrier requests. Yeap, that makes sense too but that possibly requires intrusive changes in fs layer and limited NCQ queue depth might become a bottleneck too. I'm not too nervous about the FUA write commands, I hope we can safely assume that if you set the FUA supported bit in the id AND the write fua command doesn't get aborted, that FUA must work. Anything else would just be an immensely stupid implementation. NCQ+FUA is more tricky, I agree that it being just a command bit does make it more likely that it could be ignored. And that is indeed a danger. Given state of NCQ in early firmware drives, I would not at all be surprised if the drive vendors screwed that up too. Yeap, I bet someone did. :-) But, since we don't have the ordered bit for NCQ/FUA anyway, we do need to drain the drive queue before issuing the WRITE/FUA. And at that point we may as well not use the NCQ command, just go for the regular non-NCQ FUA write. I think that should be safe. Yeap. Aside from the issue above, as I mentioned elsewhere, lots of NCQ drives don't support non-NCQ FUA writes.. To me, using the NCQ FUA bit on such drives doesn't seem to be a good idea. Maybe I'm just too chicken but it's not like we can gain a lot from doing FUA at this point. Are there a lot of drives which support NCQ but not FUA opcodes? Thanks. Anything new (firmware included) is likely to be shaky on initial deployment. Caution is certainly the way to go on this ;-) ric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/22/07, Alan <[EMAIL PROTECTED]> wrote: > compiler people caught on to the economic opportunity. Ever pay $5K > for a CD full of GNU binaries for a commercial UNIX? I did, after No because I just downloaded them. Much easier and since they are GPL I was allowed to do so, then rebuilt them all which took about 30 minutes of brain time and a day of CPU time. Oh yeah? For IRIX in 1991? Or for that matter, for Linux/ARM EABI today? Tell me, how many of what sort of users do you support singlehandedly in an environment where you are a minority architecture and everyone else takes the GNU tools for granted? God knows I've got better things to do with my time than roll the compiler-flag dice again and again trying to get a sketchy GCC port not to ICE or, worse, generate subtly broken code. If it's so bloody easy, how do CodeSourcery and MontaVista and Red Hat stay in business? Not with the quality of their code or their customer service, I'll tell you that -- although Mark Mitchell is probably the best release manager that any GNU project has ever had. Oh, please. Steve Ballmer doesn't waste his time trying to explain to overpaid GNU/Linux Morlocks (among which I number myself) how the legal and economic underpinnings of their industry work and why they shouldn't RAPE THEMSELVES playing stupid EXPORT_SYMBOL_GPL games and cryptographically signing kernel modules. But don't worry -- neither do I beyond a couple of weeks after something really dunderheaded sets me off, and in the meantime, you know where to find your keyboard's "stick my fingers in my ears and shout la-la-la-I-can't-hear-you" key. :-) 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: libata FUA revisited
Jens Axboe wrote: On Wed, Feb 21 2007, Tejun Heo wrote: [cc'ing Ric, Hannes and Dongjun, Hello. Feel free to drag other people in.] Robert Hancock wrote: Jens Axboe wrote: But we can't really change that, since you need the cache flushed before issuing the FUA write. I've been advocating for an ordered bit for years, so that we could just do: 3. w/FUA+ORDERED normal operation -> barrier issued -> write barrier FUA+ORDERED -> normal operation resumes So we don't have to serialize everything both at the block and device level. I would have made FUA imply this already, but apparently it's not what MS wanted FUA for, so... The current implementations take the FUA bit (or WRITE FUA) as a hint to boost it to head of queue, so you are almost certainly going to jump ahead of already queued writes. Which we of course really do not. Yeah, I think if we have tagged write command and flush tagged (or barrier tagged) things can be pretty efficient. Again, I'm much more comfortable with separate opcodes for those rather than bits changing the behavior. ORDERED+FUA NCQ would still be preferable to an NCQ enabled flush command, though. Another idea Dongjun talked about while drinking in LSF was ranged flush. Not as flexible/efficient as the previous option but much less intrusive and should help quite a bit, I think. But that requires extensive tracking, I'm not so sure the implementation of that for barriers would be very clean. It'd probably be good for fsync, though. If we could invent any mechanism, it would seem that it would be nicest if we could have independent sequences of IO requests (say with a distinct tag per sequence) and an ability to issue a per sequence flush request. That might tie into the QOS support, but would still have issues when you try to map it back up the stack through the journal and into application level promises of data integrity. For example, in data journal mode, we would probably need to flush not only the transaction level data, but also all data sequences that had IO's in that transaction first. Pretty rapidly, we start to get into the database notions of nested transactions and so on ;-) ric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 2/2] cciss: add shutdown support (replaces reboot notifier)
On Thu, Feb 22, 2007 at 09:55:01PM +, Christoph Hellwig wrote: > On Thu, Feb 22, 2007 at 03:49:38PM -0600, James Bottomley wrote: > > On Thu, 2007-02-22 at 15:38 -0600, Mike Miller (OS Dev) wrote: > > > .remove = __devexit_p(cciss_remove_one), > > > .id_table = cciss_pci_device_id,/* id_table */ > > > + .shutdown = cciss_remove_one, > > > > You need a __devexit_p() wrapper for this one too. > > No. We want to call this even in the non-modular, non-hotplug > case. So we should remove __devexit from cciss_remove_one. Or > alternatively implement a separate cciss_shutdown that just does > the nessecary cache flushing, like most other drivers do. So if I remove __devexit from cciss_init_one do I also remove the __devexit_p wrapper from the remove method? -- mikem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] x86: add -freg-struct-return to CFLAGS
Adrian Bunk wrote: On Thu, Feb 22, 2007 at 09:38:22AM +0100, Ingo Molnar wrote: ... --- linux.orig/arch/i386/Makefile +++ linux/arch/i386/Makefile @@ -31,7 +31,7 @@ LDFLAGS_vmlinux := --emit-relocs endif CHECKFLAGS += -D__i386__ -CFLAGS += -pipe -msoft-float -mregparm=3 +CFLAGS += -pipe -msoft-float -mregparm=3 -freg-struct-return # prevent gcc from keeping the stack 16 byte aligned CFLAGS += $(call cc-option,-mpreferred-stack-boundary=2) Why is this i386 specific? Because virtually all other architectures have it as their ABI default, anyway, and ABI selection should be per architecture. -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: [r8169] Any success with RTL8110SC?
Tom Burns <[EMAIL PROTECTED]> : [...] > 2.6.15-1 - it was trivial changes aside from 2.6.20.1 which required > changes to the task scheduling code, but I'm pretty certain I didn't > break anything. I do not have the answar that you expect but some information could help: - which motherboard is it ? - can you send a dmesg for 2.6.20.1 as well as a lspci -vvx from your computer ? [...] > The r1000 driver seems to be able to send data on the wire for about a > minute, receive packets back about 5% of the time, and after a minute > stop working altogether, complaining that the "send buffer is full." If I read you correctly, this version of the driver is less broken than the others, right ? If you are brave, you can try the patch below against 2.6.20-rc1: http://www.fr.zoreil.com/people/francois/misc/20070221-2.6.21-rc1-r8169-test.patch -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3]cpuidle take2: Basic documentation for cpuidle
Documentation for cpuidle infrastructure Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]> Signed-off-by: Adam Belay <[EMAIL PROTECTED]> Signed-off-by: Shaohua Li <[EMAIL PROTECTED]> Index: linux-2.6.21-rc-mm/Documentation/cpuidle/core.txt === --- /dev/null +++ linux-2.6.21-rc-mm/Documentation/cpuidle/core.txt @@ -0,0 +1,17 @@ + + Supporting multiple CPU idle levels in kernel + + cpuidle + +General Information: + +Various CPUs today support multiple idle levels that are differentiated +by varying exit latencies and power consumption during idle. +cpuidle is a generic in-kernel infrastructure that separates +idle policy (governor) from idle mechanism (driver) and provides a +standardized infrastructure to support independent development of +governors and drivers. + +cpuidle resides under /drivers/cpuidle. + + Index: linux-2.6.21-rc-mm/Documentation/cpuidle/driver.txt === --- /dev/null +++ linux-2.6.21-rc-mm/Documentation/cpuidle/driver.txt @@ -0,0 +1,24 @@ + + + Supporting multiple CPU idle levels in kernel + + cpuidle drivers + + + + +cpuidle driver supports capability detection for a particular system. The +init and exit routines will be called for each online CPU, with a percpu +cpuidle_driver object and driver should fill in cpuidle_states inside +cpuidle_driver depending on the CPU capability. + +Driver can handle dynamic state changes (like battery<->AC), by calling +force_redetect interface. + +It is possible to have more than one driver registered at the same time and +user can switch between drivers using /sysfs interface. + +Interfaces: +int cpuidle_register_driver(struct cpuidle_driver *drv); +void cpuidle_unregister_driver(struct cpuidle_driver *drv); +int cpuidle_force_redetect(struct cpuidle_device *dev); Index: linux-2.6.21-rc-mm/Documentation/cpuidle/sysfs.txt === --- /dev/null +++ linux-2.6.21-rc-mm/Documentation/cpuidle/sysfs.txt @@ -0,0 +1,27 @@ + + + Supporting multiple CPU idle levels in kernel + + cpuidle sysfs + +System global cpuidle information are under +/sys/devices/system/cpu/cpuidle + +The current interfaces in this directory has self-explanatory names: +* available_drivers +* available_governors +* current_driver +* current_governor + +Per logical CPU specific cpuidle information are under +/sys/devices/system/cpu/cpuX/cpuidle +for each online cpu X + +Under this percpu directory, there is a directory for each idle state supported +by the driver, which in turn has +* latency +* power +* time +* usage + + Index: linux-2.6.21-rc-mm/Documentation/cpuidle/governor.txt === --- /dev/null +++ linux-2.6.21-rc-mm/Documentation/cpuidle/governor.txt @@ -0,0 +1,24 @@ + + + + Supporting multiple CPU idle levels in kernel + + cpuidle governors + + + + +cpuidle governor is policy routine that decides what idle state to enter at +any given time. cpuidle core uses different callbacks to governor while +handling idle entry. +* select_state callback where governor can determine next idle state to enter +* prepare_idle callback is called before entering an idle state +* scan callback is called after a driver forces redetection of the states + +More than one governor can be registered at the same time and +user can switch between drivers using /sysfs interface. + +Interfaces: +int cpuidle_register_governor(struct cpuidle_governor *gov); +void cpuidle_unregister_governor(struct cpuidle_governor *gov); + - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/3]cpuidle take2: Hookup ACPI C-states driver with cpuidle
Hookup ACPI C-states onto generic cpuidle infrastructure.
drivers/acpi/procesor_idle.c is now a ACPI C-states driver that registers as
a driver in cpuidle infrastructure and the policy part is removed from
drivers/acpi/processor_idle.c. We use governor in cpuidle instead.
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc-mm/drivers/acpi/processor_core.c
===
--- linux-2.6.21-rc-mm.orig/drivers/acpi/processor_core.c
+++ linux-2.6.21-rc-mm/drivers/acpi/processor_core.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1024,11 +1025,13 @@ static int __init acpi_processor_init(vo
acpi_processor_ppc_init();
+ cpuidle_register_driver(_idle_driver);
return 0;
}
static void __exit acpi_processor_exit(void)
{
+ cpuidle_unregister_driver(_idle_driver);
acpi_processor_ppc_exit();
Index: linux-2.6.21-rc-mm/drivers/acpi/processor_idle.c
===
--- linux-2.6.21-rc-mm.orig/drivers/acpi/processor_idle.c
+++ linux-2.6.21-rc-mm/drivers/acpi/processor_idle.c
@@ -40,6 +40,7 @@
#include/* need_resched() */
#include
#include
+#include
/*
* Include the apic definitions for x86 to have the APIC timer related defines
@@ -70,25 +71,15 @@
#define _COMPONENT ACPI_PROCESSOR_COMPONENT
ACPI_MODULE_NAME("processor_idle");
#define ACPI_PROCESSOR_FILE_POWER "power"
-#define US_TO_PM_TIMER_TICKS(t)((t *
(PM_TIMER_FREQUENCY/1000)) / 1000)
-#define C2_OVERHEAD4 /* 1us (3.579 ticks per us) */
-#define C3_OVERHEAD4 /* 1us (3.579 ticks per us) */
-static void (*pm_idle_save) (void) __read_mostly;
+#define PM_TIMER_TICKS_TO_US(p)(((p) *
1000)/(PM_TIMER_FREQUENCY/1000))
+#define C2_OVERHEAD1 /* 1us */
+#define C3_OVERHEAD1 /* 1us */
+
module_param(max_cstate, uint, 0644);
static unsigned int nocst __read_mostly;
module_param(nocst, uint, );
-/*
- * bm_history -- bit-mask with a bit per jiffy of bus-master activity
- * 1000 HZ: 0x: 32 jiffies = 32ms
- * 800 HZ: 0x: 32 jiffies = 40ms
- * 100 HZ: 0x000F: 4 jiffies = 40ms
- * reduce history for more aggressive entry into C3
- */
-static unsigned int bm_history __read_mostly =
-(HZ >= 800 ? 0x : ((1U << (HZ / 25)) - 1));
-module_param(bm_history, uint, 0644);
/* --
Power Management
--
*/
@@ -174,88 +165,6 @@ static struct dmi_system_id __cpuinitdat
{},
};
-static inline u32 ticks_elapsed(u32 t1, u32 t2)
-{
- if (t2 >= t1)
- return (t2 - t1);
- else if (!(acpi_gbl_FADT.flags & ACPI_FADT_32BIT_TIMER))
- return (((0x00FF - t1) + t2) & 0x00FF);
- else
- return ((0x - t1) + t2);
-}
-
-static void
-acpi_processor_power_activate(struct acpi_processor *pr,
- struct acpi_processor_cx *new)
-{
- struct acpi_processor_cx *old;
-
- if (!pr || !new)
- return;
-
- old = pr->power.state;
-
- if (old)
- old->promotion.count = 0;
- new->demotion.count = 0;
-
- /* Cleanup from old state. */
- if (old) {
- switch (old->type) {
- case ACPI_STATE_C3:
- /* Disable bus master reload */
- if (new->type != ACPI_STATE_C3 && pr->flags.bm_check)
- acpi_set_register(ACPI_BITREG_BUS_MASTER_RLD,
0);
- break;
- }
- }
-
- /* Prepare to use new state. */
- switch (new->type) {
- case ACPI_STATE_C3:
- /* Enable bus master reload */
- if (old->type != ACPI_STATE_C3 && pr->flags.bm_check)
- acpi_set_register(ACPI_BITREG_BUS_MASTER_RLD, 1);
- break;
- }
-
- pr->power.state = new;
-
- return;
-}
-
-static void acpi_safe_halt(void)
-{
- current_thread_info()->status &= ~TS_POLLING;
- /*
-* TS_POLLING-cleared state must be visible before we
-* test NEED_RESCHED:
-*/
- smp_mb();
- if (!need_resched())
- safe_halt();
- current_thread_info()->status |= TS_POLLING;
-}
-
-static atomic_t c3_cpu_count;
-
-/* Common C-state entry for C2, C3, .. */
-static void acpi_cstate_enter(struct acpi_processor_cx *cstate)
-{
- if (cstate->space_id == ACPI_CSTATE_FFH) {
- /* Call into architectural FFH based C-state */
-
[PATCH 1/3]cpuidle take2: Core cpuidle infrastructure
Announcing 'cpuidle', a new CPU power management infrastructure to manage
idle CPUs in a clean and efficient manner.
cpuidle separates out the drivers that can provide support for multiple types
of idle states and policy governors that decide on what idle state to use
at run time.
A cpuidle driver can support multiple idle states based on parameters like
varying power consumption, wakeup latency, etc (ACPI C-states for example).
A cpuidle governor can be usage model specific (laptop, server,
laptop on battery etc).
Main advantage of the infrastructure being, it allows independent development
of drivers and governors and allows for better CPU power management.
A huge thanks to Adam Belay and Shaohua Li who were part of this mini-project
since its beginning and are greatly responsible for this patchset.
This patch:
Core cpuidle infrastructure.
Introduces a new abstraction layer for cpuidle:
* which manages drivers that can support multiple idles states. Drivers
can be generic or particular to specific hardware/platform
* allows pluging in multiple policy governors that can take idle state policy
decision
* The core also has a set of sysfs interfaces with which administrato can know
about supported drivers and governors and switch them at run time.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
---
Take 2 - Rebased with 2.6.21-rc1.
Index: linux-2.6.21-rc-mm/arch/i386/Kconfig
===
--- linux-2.6.21-rc-mm.orig/arch/i386/Kconfig
+++ linux-2.6.21-rc-mm/arch/i386/Kconfig
@@ -1066,6 +1066,8 @@ endmenu
source "arch/i386/kernel/cpu/cpufreq/Kconfig"
+source "drivers/cpuidle/Kconfig"
+
endmenu
menu "Bus options (PCI, PCMCIA, EISA, MCA, ISA)"
Index: linux-2.6.21-rc-mm/arch/x86_64/Kconfig
===
--- linux-2.6.21-rc-mm.orig/arch/x86_64/Kconfig
+++ linux-2.6.21-rc-mm/arch/x86_64/Kconfig
@@ -670,6 +670,8 @@ source "drivers/acpi/Kconfig"
source "arch/x86_64/kernel/cpufreq/Kconfig"
+source "drivers/cpuidle/Kconfig"
+
endmenu
menu "Bus options (PCI etc.)"
Index: linux-2.6.21-rc-mm/drivers/Makefile
===
--- linux-2.6.21-rc-mm.orig/drivers/Makefile
+++ linux-2.6.21-rc-mm/drivers/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_EDAC)+= edac/
obj-$(CONFIG_MCA) += mca/
obj-$(CONFIG_EISA) += eisa/
obj-$(CONFIG_CPU_FREQ) += cpufreq/
+obj-$(CONFIG_CPU_IDLE) += cpuidle/
obj-$(CONFIG_MMC) += mmc/
obj-$(CONFIG_NEW_LEDS) += leds/
obj-$(CONFIG_INFINIBAND) += infiniband/
Index: linux-2.6.21-rc-mm/drivers/cpuidle/cpuidle.c
===
--- /dev/null
+++ linux-2.6.21-rc-mm/drivers/cpuidle/cpuidle.c
@@ -0,0 +1,287 @@
+/*
+ * cpuidle.c - core cpuidle infrastructure
+ *
+ * (C) 2006-2007 Venkatesh Pallipadi <[EMAIL PROTECTED]>
+ * Shaohua Li <[EMAIL PROTECTED]>
+ * Adam Belay <[EMAIL PROTECTED]>
+ *
+ * This code is licenced under the GPL.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cpuidle.h"
+
+DEFINE_PER_CPU(struct cpuidle_device, cpuidle_devices);
+EXPORT_PER_CPU_SYMBOL_GPL(cpuidle_devices);
+
+DEFINE_MUTEX(cpuidle_lock);
+LIST_HEAD(cpuidle_detected_devices);
+static void (*pm_idle_old)(void);
+
+
+/**
+ * cpuidle_idle_call - the main idle loop
+ *
+ * NOTE: no locks or semaphores should be used here
+ * FIXME: DYNTICKS handling
+ */
+static void cpuidle_idle_call(void)
+{
+ struct cpuidle_device *dev = &__get_cpu_var(cpuidle_devices);
+
+ struct cpuidle_state *target_state;
+ int next_state;
+
+ /* check if the device is ready */
+ if (dev->status != CPUIDLE_STATUS_DOIDLE) {
+ if (pm_idle_old)
+ pm_idle_old();
+ return;
+ }
+
+ if (cpuidle_curr_governor->prepare_idle)
+ cpuidle_curr_governor->prepare_idle(dev);
+
+ while(!need_resched()) {
+ next_state = cpuidle_curr_governor->select_state(dev);
+ if (need_resched())
+ break;
+
+ target_state = >states[next_state];
+
+ dev->last_residency = target_state->enter(dev, target_state);
+ dev->last_state = target_state;
+ target_state->time += dev->last_residency;
+ target_state->usage++;
+
+ if (dev->status != CPUIDLE_STATUS_DOIDLE)
+ break;
+ }
+}
+
+/**
+ * cpuidle_install_idle_handler - installs the cpuidle idle loop handler
+ */
+void cpuidle_install_idle_handler(void)
+{
+ if (pm_idle != cpuidle_idle_call) {
+ /* Make sure all changes finished before we switch to new idle
*/
+
Re: GPL vs non-GPL device drivers
On 2/22/07, D. Hazelton <[EMAIL PROTECTED]> wrote: > If you take the microsoft windows source code and compile it yourself > believe me you will get sued if you ship the resulting binaries and you > will lose in court. "misappropriation of trade secrets" as well as copyright infringement But that's because it is *WINDOWS*, which, unless specifically granted to you, does not include a transfer of the right to distribute in *ANY* form. Every PC manufacturer that wants to distribute Windows on new machines they produce *MUST* sign an agreement with M$. As I have never seen any of those agreements I cannot state what the terms are and whether they are different for each company holding such a license. contract in personam, creating causes of action for breach of contract (for which remedies of specific performance are available) and strengthening the case for misappropriation of trade secrets And unless you've signed a licensing agreement over the source code to Windows, you're more than likely to have another lawsuit on your hands for possessing it. Not for possessing it. For acquiring it unlawfully, and for doing things with it that violate M$ copyright. > I would also note that the FSF makes no claim about dynamic v static > linking, merely about derivative works - which is the boundary the law is > interested in. Indeed the GPLv2 was written in the days where dynamic > linking was quite novel which is one reason the LGPL talks about The FSF makes lots of such claims, all the time, and Eben Moglen uses them to finesse his letter-of-opinion / affidavit racket, along with the fork/exec fetish. Fluendo. Vidomi. XCode. Tornado. NeXT. Progress Software. > "For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link a program with the library, you must provide > complete object files to the recipients so that they can relink them > with the library, after making changes to the library and recompiling > it. And you must show them these terms so they know their rights." Eh? Complete *object* files so that after making changes and recompiling they can relink it? Umm... I don't know about you, but that makes me laugh. What is the purpose of providing "Complete Object Files" to everyone if they are just going to recompile and relink the library? Complete object files for the rest of the non-GPL application. This applies principally to static linking. It also makes it much easier to reverse engineer the application, because unless the person jockeying the linker is really, really good, all of the interfaces between the application components are visible with nm and objdump, and you can use tools like ltrace to watch the calling sequences between modules. Selective symbol stripping and obfuscation on partially linked binaries takes skill. > Flex is more complex because the resulting binary contains both compiled > work of yours and a support library of FSF owned code (-lfl). No, flex is simpler because libfl is obviously a separate work of authorship with a stable external interface, and the application that links against it is not a derivative work of any of the creative expression inside libfl. Copyright *doesn't* extend to compiled code. It cannot, because compiled code is a machine generated translation. A machine generated translation isn't the product of a creative process. And you can also provide all the routines normally provided by the support library. This means that the support library is *NOT* a necessary part of the system. That's rubbish. Copyright in compiled code is very nearly identical to copyright in the source code from which it was generated; see references in Lexmark, especially the seminal Altai case. Copyright in silicon is _not_ identical to copyright in the RTL from which it was synthesized -- the term of protection for a "mask work" is limited to 10 years -- 2 if it's not registered properly. This prima facie bizarre situation reflects the difference in national origin and lobbying power between software and hardware makers, as well as the greater difficulty of extracting the theory of operation of a complex chip using an electron microscope. The chip design oligopoly is bound by a web of contractual covenants not to do this anyway, and they like being able to snap up key people from upstart maverick companies and rip off their designs without pesky legal interference. > The non > computing analogy here is the difference between using a paint program to > create a work, and using a paint program to create a work but also > including other artwork (eg clipart). Not really. Using stock images to illustrate a manuscript requires license to copy and distribute them but rarely, if ever, creates a derivative work. Yes, but in both cases the result is *CLEARLY* the
Re: [PATCH 0/7] cxgb3 - Chelsio T3 1G/10G driver updates
Steve Wise wrote: Divy, Do these need to be pulled into OFED 1.2 as well? Hi Steve, Yes, I believe so. Cheers, Divy Steve. On Thu, 2007-02-22 at 03:58 -0800, Divy Le Ray wrote: Jeff, I'm sending a series of incremental patches updating the cxgb3 driver. These patches are built against Linus'git tree. Cheers, Divy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]
On Thu, 2007-02-22 at 22:07 +0100, Pierre Ossman wrote: > Arjan van de Ven wrote: > > no; c3 saves a TON more power. > > > > you can try enabling HPET in your BIOS... > > > > > > Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken > as is humanly possible. > > Can I determine if I have the required hardware? So I can tell if I'm > permanently screwed, or just temporarily. if it's something built in the last year or two you have the hw. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 0/6] rtc framework: remove class_device, use class suspend()/resume()
On Thursday 22 February 2007 1:37 pm, Alessandro Zummo wro > Hi David, > > thanks for your work. The interface system was originally > in place because it seemed the right-thing-to-do. if it isn't, > better to remove it ;) The Right Thing may also have changed a bit over time! - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
