Re: [UPDATED] Re: [PATCH 1/5] Add pagetable allocation notifiers
* Zachary Amsden ([EMAIL PROTECTED]) wrote: Done. Looks like you want empty_zero_page write protected too. That seems like a fine idea to me unless something really wants to do atomic 64-bit reads on it. Thanks, I added this set (minus the 3/5, which I already have) to the virt-2.6 tree. The -1 is quite useless when you're going to shift 12 anyways to get a frame number to index into mem_map, which is why they are not there. Plus, it just seems scary if you got it wrong - let's say you had a not present page - not that you could, but now you are freeing a misaligned address in the _previous_ page. I really don't like that -1 at all. I will clean it up, but it does certainly deserve another patch. Heh, that's exactly what I was concerned with from the patch (being on the wrong page). Thanks for clearing up my confusion. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 for arch-specific IOREMAP_MAX_ORDER
Version 6 of the ARM architecture introduces the concept of 16MB pages
(supersections) and 36-bit (40-bit actually, but nobody uses this)
physical addresses. 36-bit addressed memory and I/O and ARMv6 can
only be mapped using supersections and the requirement on these is
that both virtual and physical addresses be 16MB aligned. In trying
to add support for ioremap() of 36-bit I/O, we run into the issue that
get_vm_area() allows for a maximum of 512K alignment via the
IOREMAP_MAX_ORDER constant. To work around this, we can:
- Allocate a larger VM area than needed (size + (1ul IOREMAP_MAX_ORDER))
and then align the pointer ourselves, but this ends up with 512K of
wasted VM per ioremap().
- Provide a new __get_vm_area_aligned() API and make __get_vm_area() sit
on top of this. I did this and it works but I don't like the idea
adding another VM API just for this one case.
- My preferred solution which is to allow the architecture to override
the IOREMAP_MAX_ORDER constant with it's own version.
Signed-off-by: Deepak Saxena [EMAIL PROTECTED]
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -10,6 +10,14 @@
#define VM_MAP 0x0004 /* vmap()ed pages */
/* bits [20..32] reserved for arch specific ioremap internals */
+/*
+ * Maximum alignment for ioremap() regions.
+ * Can be overriden by arch-specific value.
+ */
+#ifndef IOREMAP_MAX_ORDER
+#define IOREMAP_MAX_ORDER (7 + PAGE_SHIFT)/* 128 pages */
+#endif
+
struct vm_struct {
void*addr;
unsigned long size;
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -158,8 +158,6 @@ int map_vm_area(struct vm_struct *area,
return err;
}
-#define IOREMAP_MAX_ORDER (7 + PAGE_SHIFT)/* 128 pages */
-
struct vm_struct *__get_vm_area(unsigned long size, unsigned long flags,
unsigned long start, unsigned long end)
{
--
Deepak Saxena - [EMAIL PROTECTED] - http://www.plexity.net
Even a stopped clock gives the right time twice a day.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] Additions to .data.read_mostly section
Ravikiran G Thirumalai a écrit : Following patch moves a few static 'read mostly' variables to the .data.read_mostly section. Typically these are vector - irq tables, boot_cpu_data, node_maps etc., which are initialized once and read from often and rarely written to. Please include. Good candidates for read_mostly are all the 'kmem_cache_t *xxx_cache' slab was carefuly designed to eliminate cache line ping pongs on SMP, but if the initial pointer to slab sits in a heavily modified cache line, we loose. 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: Linux-2.6.13-rc7 : OK
Hello, On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: Hullo. I really wanted to release a 2.6.13, but there's been enough changes while we've been waiting for other issues to resolve that I think it's best to do a -rc7 first. Most of the -rc7 changes are pretty trivial, either one-liners or affecting some particular specific driver or unusual configuration. The shortlog (appended) should give a pretty good idea of what's up. Well, it's been running here for a few hours this evening, and I must say that I have not noticed anything strange yet (except the printk timestamps which switch to zero twice during boot and start with funny values, but that's not important). The box is a dual-k7 with aic7xxx, and NFSv3 over an e1000 NIC. Tested with SMP and preempt enabled. Linus Regards, Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
On Wed, Aug 24, 2005 at 04:52:37PM -0400, Wakko Warner wrote: Care to send me the patch? Heh. Not really as I don't really know if people should be using it in it's current state --- the shmem init is very very hacky and I have other changes I've not had a chance to do. Anyhow, here is an older version of it. It's from some old internal embedded tree but should be trivial to shoehorn into anything recent. If people really do like or want this I would like to know and maybe something more elegant can be worked out. I tried it with kernel 2.6.13-rc5 and it seems to work. It uses 50% of total memory for tmpfs, but it would be nice to have an option (tmpfs_size=90% etc.) that you could pass to the kernel. You need to add this to init/main.c for it to compile. #include asm/uaccess.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/
[PATCH] ignore all debugging info sections in scripts/reference_discarded.pl
GCC 4 emits more DWARF debugging information than before and there is now a
.debug_loc section as well. This causes make buildcheck to fail.
Rather than just add that one to the special case list, I used a regexp to
ignore any .debug_ANYTHING sections in case more show up in the future.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
scripts/reference_discarded.pl |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
a91d80398d6f8c1f335a0af34342b5747f153c13
diff --git a/scripts/reference_discarded.pl b/scripts/reference_discarded.pl
--- a/scripts/reference_discarded.pl
+++ b/scripts/reference_discarded.pl
@@ -91,11 +91,7 @@ foreach $object (keys(%object)) {
$from !~ /\.exit\.data$/
$from !~ /\.altinstructions$/
$from !~ /\.pdr$/
-$from !~ /\.debug_info$/
-$from !~ /\.debug_aranges$/
-$from !~ /\.debug_ranges$/
-$from !~ /\.debug_line$/
-$from !~ /\.debug_frame$/
+$from !~ /\.debug_.*$/
$from !~ /\.exitcall\.exit$/
$from !~ /\.eh_frame$/
$from !~ /\.stab$/)) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
overlapping MTRR regions
Hi, I tested 2.6.13-rc7 on nice server motherboard with 16GB of RAM ;) http://www.msicomputer.com/product/p_spec.asp?model=E7520_Master-S2Mclass=spd and I see the following when acpi is enabled (haven't even tried without): # cat /proc/mtrr reg00: base=0xd000 (3328MB), size= 256MB: uncachable, count=1 reg01: base=0xe000 (3584MB), size= 512MB: uncachable, count=1 reg02: base=0x ( 0MB), size=16384MB: write-back, count=1 reg03: base=0x4 (16384MB), size= 512MB: write-back, count=1 reg04: base=0x42000 (16896MB), size= 256MB: write-back, count=1 reg05: base=0xcff8 (3327MB), size= 512KB: uncachable, count=1 # Is that correct? Please cc: me in replies. phylo ~ # lspci :00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 0c) :00:00.1 Class ff00: Intel Corporation E7525/E7520 Error Reporting Registers (rev 0c) :00:01.0 System peripheral: Intel Corporation E7520 DMA Controller (rev 0c) :00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 0c) :00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B (rev 0c) :00:05.0 PCI bridge: Intel Corporation E7520 PCI Express Port B1 (rev 0c) :00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev 0c) :00:07.0 PCI bridge: Intel Corporation E7520 PCI Express Port C1 (rev 0c) :00:1c.0 PCI bridge: Intel Corporation 6300ESB 64-bit PCI-X Bridge (rev 02) :00:1d.0 USB Controller: Intel Corporation 6300ESB USB Universal Host Controller (rev 02) :00:1d.1 USB Controller: Intel Corporation 6300ESB USB Universal Host Controller (rev 02) :00:1d.4 System peripheral: Intel Corporation 6300ESB Watchdog Timer (rev 02) :00:1d.5 PIC: Intel Corporation 6300ESB I/O Advanced Programmable Interrupt Controller (rev 02) :00:1d.7 USB Controller: Intel Corporation 6300ESB USB2 Enhanced Host Controller (rev 02) :00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 0a) :00:1f.0 ISA bridge: Intel Corporation 6300ESB LPC Interface Controller (rev 02) :00:1f.1 IDE interface: Intel Corporation 6300ESB PATA Storage Controller (rev 02) :00:1f.2 IDE interface: Intel Corporation 6300ESB SATA Storage Controller (rev 02) :00:1f.3 SMBus: Intel Corporation 6300ESB SMBus Controller (rev 02) :01:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09) :01:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09) :08:01.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] :08:02.0 Ethernet controller: Intel Corporation 82541GI/PI Gigabit Ethernet Controller :08:03.0 Ethernet controller: Intel Corporation 82541GI/PI Gigabit Ethernet Controller :09:01.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) phylo ~ # lspci -v :00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 0c) Subsystem: Intel Corporation E7520 Memory Controller Hub Flags: bus master, fast devsel, latency 0 Capabilities: [40] #09 [4105] :00:00.1 Class ff00: Intel Corporation E7525/E7520 Error Reporting Registers (rev 0c) Subsystem: Micro-Star International Co., Ltd.: Unknown device 3590 Flags: fast devsel :00:01.0 System peripheral: Intel Corporation E7520 DMA Controller (rev 0c) Subsystem: Micro-Star International Co., Ltd.: Unknown device 3594 Flags: fast devsel, IRQ 10 Memory at d000 (32-bit, non-prefetchable) [size=4K] Capabilities: [b0] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- :00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 0c) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=03, sec-latency=0 Capabilities: [50] Power Management version 2 Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Capabilities: [64] #10 [0041] :00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B (rev 0c) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Capabilities: [50] Power Management version 2 Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Capabilities: [64] #10 [0041] :00:05.0 PCI bridge: Intel Corporation E7520 PCI Express Port B1 (rev 0c) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 Capabilities: [50] Power Management version 2 Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Capabilities: [64] #10 [0041] :00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev 0c) (prog-if 00 [Normal decode])
[PATCH 2.6.13-rc7] Fix IXP4xx flash resource range
[Resend...forgot to send to lkml]
We are currently reserving one byte more than actually needed
by the flash device and overlapping into the next I/O expansion
bus window. This a) causes us to allocate an extra page of VM due
to ARM ioremap() alignment code and b) could cause problems
if another driver tries to request the next expansion bus window.
Signed-off-by: Deepak Saxena [EMAIL PROTECTED]
diff --git a/arch/arm/mach-ixp4xx/coyote-setup.c
b/arch/arm/mach-ixp4xx/coyote-setup.c
--- a/arch/arm/mach-ixp4xx/coyote-setup.c
+++ b/arch/arm/mach-ixp4xx/coyote-setup.c
@@ -36,7 +36,7 @@ static struct flash_platform_data coyote
static struct resource coyote_flash_resource = {
.start = COYOTE_FLASH_BASE,
- .end= COYOTE_FLASH_BASE + COYOTE_FLASH_SIZE,
+ .end= COYOTE_FLASH_BASE + COYOTE_FLASH_SIZE - 1,
.flags = IORESOURCE_MEM,
};
diff --git a/arch/arm/mach-ixp4xx/gtwx5715-setup.c
b/arch/arm/mach-ixp4xx/gtwx5715-setup.c
--- a/arch/arm/mach-ixp4xx/gtwx5715-setup.c
+++ b/arch/arm/mach-ixp4xx/gtwx5715-setup.c
@@ -114,7 +114,7 @@ static struct flash_platform_data gtwx57
static struct resource gtwx5715_flash_resource = {
.start = GTWX5715_FLASH_BASE,
- .end= GTWX5715_FLASH_BASE + GTWX5715_FLASH_SIZE,
+ .end= GTWX5715_FLASH_BASE + GTWX5715_FLASH_SIZE - 1,
.flags = IORESOURCE_MEM,
};
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c
b/arch/arm/mach-ixp4xx/ixdp425-setup.c
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -36,7 +36,7 @@ static struct flash_platform_data ixdp42
static struct resource ixdp425_flash_resource = {
.start = IXDP425_FLASH_BASE,
- .end= IXDP425_FLASH_BASE + IXDP425_FLASH_SIZE,
+ .end= IXDP425_FLASH_BASE + IXDP425_FLASH_SIZE - 1,
.flags = IORESOURCE_MEM,
};
--
Deepak Saxena - [EMAIL PROTECTED] - http://www.plexity.net
Even a stopped clock gives the right time twice a day.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 8/8] PCI Error Recovery: PPC64 core recovery routines
Linas Vepstas writes: The meta-issue that I'd like to reach consensus on first is whether there should be any hot-plug recovery attempted at all. Removing hot-plug-recovery support will make many of the issues you raise to be moot. Yes, this probably the thorniest issue we have. My feeling is that the unplug half of it is probably fairly uncontroversial, but the replug half is a can of worms. Would you agree with that? Is it udev that handles the hotplug notifications on the userspace side in all cases (do both RHEL and SLES use udev, for instance)? How hard is it to add a new sort of notification, on the kernel side and in udev? I think what I'd like to see is that when a slot gets isolated and the driver doesn't have recovery code, the kernel calls the driver's unplug function and generates a hotplug event to udev. Ideally this would be a variant of the remove event which would say and by the way, please try replugging this slot when you've finished handling the remove event or something along those lines. Thoughts? Paul. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: process creation time increases linearly with shmem
Ray Fucillo wrote: I am seeing process creation time increase linearly with the size of the shared memory segment that the parent touches. The attached forktest.c is a very simple user program that illustrates this behavior, which I have tested on various kernel versions from 2.4 through 2.6. Is this a known issue, and is it solvable? fork() can be changed so as not to set up page tables for MAP_SHARED mappings. I think that has other tradeoffs like initially causing several unavoidable faults reading libraries and program text. What kind of application are you using? -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
root:sleipner:~# modprobe hotkey FATAL: Error inserting hotkey (/lib/modules/2.6.13-rc7/kernel/drivers/acpi/hotkey.ko): No such device Not that I care, but it at least loaded in -rc6 and created the /proc/acpi/hotkey directory with its content. When the revolution comes, the author of acpi-hotkey.txt will face the wall first. Mvh Mats Johannesson -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add pselect, ppoll system calls.
David Woodhouse wrote:
If it's mandatory that we actually call the signal handler, then we need
to play tricks like sigsuspend() does to leave the old signal mask on
the stack frame. That's a bit painful atm because do_signal is different
between architectures.
It is necessary that the handler is called. This is the purpose of
these interfaces. If this means more complexity is needed then this is
how the cookie crumbles. One use case for pselect would be something
like this:
int got_signal;
void sigint_handler(int sig) {
got_signal = 1;
}
{
...
while (1) {
if (!got_signal)
pselect()
if (got_signal) {
handle signal
got_signal = 0;
}
}
...
}
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
Re: [patch 8/8] PCI Error Recovery: PPC64 core recovery routines
I think what I'd like to see is that when a slot gets isolated and the driver doesn't have recovery code, the kernel calls the driver's unplug function and generates a hotplug event to udev. Ideally this would be a variant of the remove event which would say and by the way, please try replugging this slot when you've finished handling the remove event or something along those lines. I'm still trying to understand why we care. What prevents us from just uplugging the previous device and re-plugging right away ? After all, the driver-remove() function is supposed to guarantee that no HW access will happen after it returns and that everything was unmapped. Of course, we'll possibly end up with a different ethX or whatever, but I don't see the problem with that ... It's hopeless to think we might manage to keep that identical anyway, unless the driver implements proper error recovery. Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Where do packets sent to 255.255.255.255 go?
Hi list, If I understand correctly, packets sent to the all-ones broadcast address only go out through a single interface. My question is threefold: 1. Why doesn't Linux send 255.255.255.255 packages through all network interfaces? (I realize that this is probably not a Linux-specific question.) 2. How does it choose which interface to send through? My first guess was that it just took the first Ethernet interface and used that for broadcasting. But playing around with nameif, this seems not to be the case. 3. Can I set the default broadcast interface explicitly? For example, say I wanted broadcasts to go out over eth1 by default, instead of over eth0. What if I wanted them to get sent through tap0? Yes, I know that what I *should* be doing is just send the packages to the broadcast address specific to the network where I want them to go. (That is, I should be sending them to 10.255.255.255 instead of 255.255.255.255 if I want them to be broadcast to the 10.0.0.0 network.) Unfortunately, this is not a viable option in my case, as I'm dealing with a closed-source application that unconditionally sends broadcasts to 255.255.255.255. Ideally, the application would let me choose which interface to broadcast to, but alas it does not. I've tried searching for a solution to this problem on the web and on IRC with no luck, so now I'm turning to you guys. Thanks in advance, -- Daniel Brockman [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] RT-patch update to remove the global pi_lock
Well, after turning off hrtimers, I keep getting one bug. A possible
soft lockup with the ext3 code. But this didn't seem to be caused by the
changes I made. So just to be sure, I ran my test on the vanilla
2.6.13-rc6-rt11 and it gave the same bug too. So, it looks like my
changes are now at par with what is out there with the rt11 release.
They both give the same bug! ;-)
Attached is the test I ran. I did a
while : ; do ./test3a_rt ; done
Where test3a_rt is a C program that does adding, deleting and reading of
files, by different tasks that are each at a different priority. Here's
the soft lockup I'm getting:
NFSD: starting 90-second grace period
BUG: test3a_rt:6138, possible softlockup detected on CPU#0!
[c01043f3] dump_stack+0x23/0x30 (20)
[c014cf81] softlockup_detected+0x41/0x60 (24)
[c014d090] softlockup_tick+0xf0/0x100 (24)
[c012] update_process_times+0x5b/0x80 (28)
[c011415e] smp_apic_timer_interrupt+0xee/0x100 (36)
[c0103ec1] apic_timer_interrupt+0x21/0x28 (124)
[c01c1641] ext3_add_entry+0xd1/0x210 (60)
[c01c1e0d] ext3_add_nondir+0x2d/0x80 (32)
[c01c1f1b] ext3_create+0xbb/0x110 (40)
[c0180721] vfs_create+0xf1/0x170 (44)
[c018105b] open_namei+0x61b/0x6e0 (72)
[c016eb5f] filp_open+0x3f/0x70 (92)
[c016f033] sys_open+0x53/0x100 (44)
[c01033da] syscall_call+0x7/0xb (-8116)
---
| preempt count: 0001 ]
| 0-level deep critical section nesting:
--
| showing all locks held by: | (test3a_rt/6138 [f7ef61a0, 89]):
--
#001: [f2eaddac] {(struct semaphore *)(inode-i_sem)}
... acquired at: open_namei+0xf9/0x6e0
NMI show regs on CPU#0:
Pid: 6138, comm:test3a_rt
EIP: 0060:[c0114929] CPU: 0
EIP is at nmi_show_all_regs+0x89/0xd0
EFLAGS: 0046Not tainted (2.6.13-rc6-rt11-real)
EAX: EBX: 17fa ECX: 0060 EDX: 0080
ESI: EDI: 0006c692 EBP: f07dbd48 DS: 007b ES: 007b
CR0: 8005003b CR2: b7e37ae0 CR3: 3085 CR4: 06d0
[c01013b4] show_regs+0x164/0x16c (36)
[c0114a98] nmi_watchdog_tick+0x128/0x2b0 (56)
[c01054bf] default_do_nmi+0x7f/0x190 (52)
[c0105630] do_nmi+0x50/0x60 (24)
[c010405a] nmi_stack_correct+0x1d/0x22 (72)
[c014cf86] softlockup_detected+0x46/0x60 (24)
[c014d090] softlockup_tick+0xf0/0x100 (24)
[c012] update_process_times+0x5b/0x80 (28)
[c011415e] smp_apic_timer_interrupt+0xee/0x100 (36)
[c0103ec1] apic_timer_interrupt+0x21/0x28 (124)
[c01c1641] ext3_add_entry+0xd1/0x210 (60)
[c01c1e0d] ext3_add_nondir+0x2d/0x80 (32)
[c01c1f1b] ext3_create+0xbb/0x110 (40)
[c0180721] vfs_create+0xf1/0x170 (44)
[c018105b] open_namei+0x61b/0x6e0 (72)
[c016eb5f] filp_open+0x3f/0x70 (92)
[c016f033] sys_open+0x53/0x100 (44)
[c01033da] syscall_call+0x7/0xb (-8116)
---
| preempt count: 00010001 ]
| 1-level deep critical section nesting:
.. [c0143f5c] add_preempt_count+0x1c/0x20
.[c0114a7d] .. ( = nmi_watchdog_tick+0x10d/0x2b0)
--
| showing all locks held by: | (test3a_rt/6138 [f7ef61a0, 89]):
--
#001: [f2eaddac] {(struct semaphore *)(inode-i_sem)}
... acquired at: open_namei+0xf9/0x6e0
NMI show regs on CPU#1:
Pid: 6137, comm:test3a_rt
EIP: 0060:[c01cd9c3] CPU: 1
EIP is at do_get_write_access+0x83/0x560
EFLAGS: 0206Not tainted (2.6.13-rc6-rt11-real)
EAX: 000e201d EBX: f7ffe000 ECX: f71e49bc EDX: f71e49bc
ESI: f7f6b3bc EDI: f71e49bc EBP: f1409e94 DS: 007b ES: 007b
CR0: 8005003b CR2: b7fdb000 CR3: 326fb000 CR4: 06d0
[c01013b4] show_regs+0x164/0x16c (36)
[c0114a98] nmi_watchdog_tick+0x128/0x2b0 (56)
[c01054bf] default_do_nmi+0x7f/0x190 (52)
[c0105630] do_nmi+0x50/0x60 (24)
[c010405a] nmi_stack_correct+0x1d/0x22 (132)
[c01cded5] journal_get_write_access+0x35/0x50 (28)
[c01c2b02] ext3_orphan_del+0x1a2/0x230 (80)
[c01bae03] ext3_delete_inode+0x73/0x110 (24)
[c018cad9] generic_delete_inode+0x99/0x160 (28)
[c018cd1d] generic_drop_inode+0x1d/0x30 (12)
[c018cda0] iput+0x70/0x80 (20)
[c0181ee0] sys_unlink+0x110/0x140 (96)
[c01033da] syscall_call+0x7/0xb (-8116)
---
| preempt count: 0001 ]
| 1-level deep critical section nesting:
.. [c0143f5c] add_preempt_count+0x1c/0x20
.[c0114a7d] .. ( = nmi_watchdog_tick+0x10d/0x2b0)
--
| showing all locks held by: | (test3a_rt/6137 [f5d437f0, 90]):
--
#001: [f709cc88] {(struct semaphore *)(s-s_lock)}
... acquired at: ext3_orphan_del+0x3a/0x230
Well, looking at this further, it seems to release somehow, and
continue, since I've got multiple possible soft lockups, by different
threads. But It doesn't seem to go any further. Somethings spinning
quite a bit, and something else must be starved. I'll
[PATCH 4/5] Remove unnecessary default capability callbacks.
Now that all security hook inline stubs conditionally call to module and
do proper default action as fallback, all the old no-op default hooks can
be removed. Similarly, the verify() bits which populated empty slots with
default hooks is no longer needed. A few hooks are called from security
core directly rather than from inline stubs, so fix those up as well.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
security/commoncap.c | 825 ---
security/security.c | 50 +--
2 files changed, 17 insertions(+), 858 deletions(-)
Index: lsm-hooks-2.6/security/commoncap.c
===
--- lsm-hooks-2.6.orig/security/commoncap.c
+++ lsm-hooks-2.6/security/commoncap.c
@@ -337,828 +337,3 @@ int cap_netlink_recv(struct sk_buff *skb
return 0;
}
EXPORT_SYMBOL(cap_netlink_recv);
-
-#ifdef CONFIG_SECURITY
-
-static int cap_acct (struct file *file)
-{
- return 0;
-}
-
-static int cap_sysctl (ctl_table * table, int op)
-{
- return 0;
-}
-
-static int cap_quotactl (int cmds, int type, int id, struct super_block *sb)
-{
- return 0;
-}
-
-static int cap_quota_on (struct dentry *dentry)
-{
- return 0;
-}
-
-static int cap_bprm_alloc_security (struct linux_binprm *bprm)
-{
- return 0;
-}
-
-static void cap_bprm_free_security (struct linux_binprm *bprm)
-{
- return;
-}
-
-static void cap_bprm_post_apply_creds (struct linux_binprm *bprm)
-{
- return;
-}
-
-static int cap_bprm_check_security (struct linux_binprm *bprm)
-{
- return 0;
-}
-
-static int cap_sb_alloc_security (struct super_block *sb)
-{
- return 0;
-}
-
-static void cap_sb_free_security (struct super_block *sb)
-{
- return;
-}
-
-static int cap_sb_copy_data (struct file_system_type *type,
- void *orig, void *copy)
-{
- return 0;
-}
-
-static int cap_sb_kern_mount (struct super_block *sb, void *data)
-{
- return 0;
-}
-
-static int cap_sb_statfs (struct super_block *sb)
-{
- return 0;
-}
-
-static int cap_sb_mount (char *dev_name, struct nameidata *nd, char *type,
- unsigned long flags, void *data)
-{
- return 0;
-}
-
-static int cap_sb_check_sb (struct vfsmount *mnt, struct nameidata *nd)
-{
- return 0;
-}
-
-static int cap_sb_umount (struct vfsmount *mnt, int flags)
-{
- return 0;
-}
-
-static void cap_sb_umount_close (struct vfsmount *mnt)
-{
- return;
-}
-
-static void cap_sb_umount_busy (struct vfsmount *mnt)
-{
- return;
-}
-
-static void cap_sb_post_remount (struct vfsmount *mnt, unsigned long flags,
- void *data)
-{
- return;
-}
-
-
-static void cap_sb_post_mountroot (void)
-{
- return;
-}
-
-static void cap_sb_post_addmount (struct vfsmount *mnt, struct nameidata *nd)
-{
- return;
-}
-
-static int cap_sb_pivotroot (struct nameidata *old_nd, struct nameidata
*new_nd)
-{
- return 0;
-}
-
-static void cap_sb_post_pivotroot (struct nameidata *old_nd, struct nameidata
*new_nd)
-{
- return;
-}
-
-static int cap_inode_alloc_security (struct inode *inode)
-{
- return 0;
-}
-
-static void cap_inode_free_security (struct inode *inode)
-{
- return;
-}
-
-static int cap_inode_create (struct inode *inode, struct dentry *dentry,
- int mask)
-{
- return 0;
-}
-
-static void cap_inode_post_create (struct inode *inode, struct dentry *dentry,
-int mask)
-{
- return;
-}
-
-static int cap_inode_link (struct dentry *old_dentry, struct inode *inode,
-struct dentry *new_dentry)
-{
- return 0;
-}
-
-static void cap_inode_post_link (struct dentry *old_dentry,
- struct inode *inode,
- struct dentry *new_dentry)
-{
- return;
-}
-
-static int cap_inode_unlink (struct inode *inode, struct dentry *dentry)
-{
- return 0;
-}
-
-static int cap_inode_symlink (struct inode *inode, struct dentry *dentry,
- const char *name)
-{
- return 0;
-}
-
-static void cap_inode_post_symlink (struct inode *inode,
- struct dentry *dentry, const char *name)
-{
- return;
-}
-
-static int cap_inode_mkdir (struct inode *inode, struct dentry *dentry,
- int mask)
-{
- return 0;
-}
-
-static void cap_inode_post_mkdir (struct inode *inode, struct dentry *dentry,
- int mask)
-{
- return;
-}
-
-static int cap_inode_rmdir (struct inode *inode, struct dentry *dentry)
-{
- return 0;
-}
-
-static int cap_inode_mknod (struct inode *inode, struct dentry *dentry,
- int mode, dev_t dev)
-{
- return 0;
-}
-
-static void cap_inode_post_mknod (struct inode *inode, struct dentry *dentry,
-
[PATCH 2/5] Rework stubs in security.h
Collapse security stubs so that the def'n is done in one spot with ifdef
in function body rather than two separately defined functions.
Patch from Kurt Garloff [EMAIL PROTECTED], and slightly altered by me to
make all ifdef sites consistent and move the prototype decl's to a sane
spot.
Signed-off-by: Kurt Garloff [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
include/linux/security.h | 1410 ---
1 files changed, 609 insertions(+), 801 deletions(-)
Index: lsm-hooks-2.6/include/linux/security.h
===
--- lsm-hooks-2.6.orig/include/linux/security.h
+++ lsm-hooks-2.6/include/linux/security.h
@@ -1248,10 +1248,27 @@ struct security_operations {
/* global variables */
extern struct security_operations *security_ops;
-/* inline stuff */
+/* prototypes */
+extern int security_init (void);
+extern int register_security (struct security_operations *ops);
+extern int unregister_security (struct security_operations *ops);
+extern int mod_reg_security(const char *name, struct security_operations
*ops);
+extern int mod_unreg_security (const char *name, struct security_operations
*ops);
+#else
+static inline int security_init(void)
+{
+ return 0;
+}
+#endif /* CONFIG_SECURITY */
+
static inline int security_ptrace (struct task_struct * parent, struct
task_struct * child)
{
+#ifdef CONFIG_SECURITY
return security_ops-ptrace (parent, child);
+#else
+ return cap_ptrace (parent, child);
+#endif
+
}
static inline int security_capget (struct task_struct *target,
@@ -1259,7 +1281,11 @@ static inline int security_capget (struc
kernel_cap_t *inheritable,
kernel_cap_t *permitted)
{
+#ifdef CONFIG_SECURITY
return security_ops-capget (target, effective, inheritable, permitted);
+#else
+ return cap_capget (target, effective, inheritable, permitted);
+#endif
}
static inline int security_capset_check (struct task_struct *target,
@@ -1267,7 +1293,11 @@ static inline int security_capset_check
kernel_cap_t *inheritable,
kernel_cap_t *permitted)
{
+#ifdef CONFIG_SECURITY
return security_ops-capset_check (target, effective, inheritable,
permitted);
+#else
+ return cap_capset_check (target, effective, inheritable, permitted);
+#endif
}
static inline void security_capset_set (struct task_struct *target,
@@ -1275,278 +1305,457 @@ static inline void security_capset_set (
kernel_cap_t *inheritable,
kernel_cap_t *permitted)
{
+#ifdef CONFIG_SECURITY
security_ops-capset_set (target, effective, inheritable, permitted);
+#else
+ cap_capset_set (target, effective, inheritable, permitted);
+#endif
}
static inline int security_acct (struct file *file)
{
+#ifdef CONFIG_SECURITY
return security_ops-acct (file);
+#else
+ return 0;
+#endif
}
static inline int security_sysctl(struct ctl_table *table, int op)
{
+#ifdef CONFIG_SECURITY
return security_ops-sysctl(table, op);
+#else
+ return 0;
+#endif
}
static inline int security_quotactl (int cmds, int type, int id,
struct super_block *sb)
{
+#ifdef CONFIG_SECURITY
return security_ops-quotactl (cmds, type, id, sb);
+#else
+ return 0;
+#endif
}
static inline int security_quota_on (struct dentry * dentry)
{
+#ifdef CONFIG_SECURITY
return security_ops-quota_on (dentry);
+#else
+ return 0;
+#endif
}
static inline int security_syslog(int type)
{
+#ifdef CONFIG_SECURITY
return security_ops-syslog(type);
+#else
+ return cap_syslog(type);
+#endif
}
static inline int security_settime(struct timespec *ts, struct timezone *tz)
{
+#ifdef CONFIG_SECURITY
return security_ops-settime(ts, tz);
+#else
+ return cap_settime(ts, tz);
+#endif
}
-
static inline int security_vm_enough_memory(long pages)
{
+#ifdef CONFIG_SECURITY
return security_ops-vm_enough_memory(pages);
+#else
+ return cap_vm_enough_memory(pages);
+#endif
}
static inline int security_bprm_alloc (struct linux_binprm *bprm)
{
+#ifdef CONFIG_SECURITY
return security_ops-bprm_alloc_security (bprm);
+#else
+ return 0;
+#endif
}
+
static inline void security_bprm_free (struct linux_binprm *bprm)
{
+#ifdef CONFIG_SECURITY
security_ops-bprm_free_security (bprm);
+#else
+ return;
+#endif
}
+
static inline void security_bprm_apply_creds (struct linux_binprm *bprm, int
unsafe)
{
+#ifdef CONFIG_SECURITY
security_ops-bprm_apply_creds (bprm, unsafe);
+#else
+ cap_bprm_apply_creds (bprm, unsafe);
+#endif
}
+
static inline void security_bprm_post_apply_creds (struct linux_binprm *bprm)
{
+#ifdef
[PATCH 1/5] Use capabilities as default w/ and w/out CONFIG_SECURITY.
If a kernel is compiled with CONFIG_SECURITY to enable LSM, the
default behaviour changes unless the admin loads capability.
This is undesirable. This patch makes capability the default.
capability can still be compiled as module and be loaded as LSM.
If loaded as primary LSM, it won't change anything. But it may
also be loaded as secondary LSM and stacked on top of another
LSM (if the other LSM allows this or if stacker is used).
Based on original patch from Kurt Garloff [EMAIL PROTECTED].
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
security/dummy.c | 996 ---
security/Makefile|9
security/commoncap.c | 977 +-
security/security.c | 22 -
4 files changed, 912 insertions(+), 1092 deletions(-)
Index: lsm-hooks-2.6/security/Makefile
===
--- lsm-hooks-2.6.orig/security/Makefile
+++ lsm-hooks-2.6/security/Makefile
@@ -5,15 +5,12 @@
obj-$(CONFIG_KEYS) += keys/
subdir-$(CONFIG_SECURITY_SELINUX) += selinux
-# if we don't select a security model, use the default capabilities
-ifneq ($(CONFIG_SECURITY),y)
obj-y += commoncap.o
-endif
# Object file lists
-obj-$(CONFIG_SECURITY) += security.o dummy.o
+obj-$(CONFIG_SECURITY) += security.o
# Must precede capability.o in order to stack properly.
obj-$(CONFIG_SECURITY_SELINUX) += selinux/built-in.o
-obj-$(CONFIG_SECURITY_CAPABILITIES)+= commoncap.o capability.o
-obj-$(CONFIG_SECURITY_ROOTPLUG)+= commoncap.o root_plug.o
+obj-$(CONFIG_SECURITY_CAPABILITIES)+= capability.o
+obj-$(CONFIG_SECURITY_ROOTPLUG)+= root_plug.o
obj-$(CONFIG_SECURITY_SECLVL) += seclvl.o
Index: lsm-hooks-2.6/security/commoncap.c
===
--- lsm-hooks-2.6.orig/security/commoncap.c
+++ lsm-hooks-2.6/security/commoncap.c
@@ -8,7 +8,6 @@
*/
#include linux/config.h
-#include linux/module.h
#include linux/init.h
#include linux/kernel.h
#include linux/security.h
@@ -23,38 +22,7 @@
#include linux/ptrace.h
#include linux/xattr.h
#include linux/hugetlb.h
-
-int cap_netlink_send(struct sock *sk, struct sk_buff *skb)
-{
- NETLINK_CB(skb).eff_cap = current-cap_effective;
- return 0;
-}
-
-EXPORT_SYMBOL(cap_netlink_send);
-
-int cap_netlink_recv(struct sk_buff *skb)
-{
- if (!cap_raised(NETLINK_CB(skb).eff_cap, CAP_NET_ADMIN))
- return -EPERM;
- return 0;
-}
-
-EXPORT_SYMBOL(cap_netlink_recv);
-
-int cap_capable (struct task_struct *tsk, int cap)
-{
- /* Derived from include/linux/sched.h:capable. */
- if (cap_raised(tsk-cap_effective, cap))
- return 0;
- return -EPERM;
-}
-
-int cap_settime(struct timespec *ts, struct timezone *tz)
-{
- if (!capable(CAP_SYS_TIME))
- return -EPERM;
- return 0;
-}
+#include linux/sysctl.h
int cap_ptrace (struct task_struct *parent, struct task_struct *child)
{
@@ -64,6 +32,7 @@ int cap_ptrace (struct task_struct *pare
return -EPERM;
return 0;
}
+EXPORT_SYMBOL(cap_ptrace);
int cap_capget (struct task_struct *target, kernel_cap_t *effective,
kernel_cap_t *inheritable, kernel_cap_t *permitted)
@@ -74,6 +43,7 @@ int cap_capget (struct task_struct *targ
*permitted = cap_t (target-cap_permitted);
return 0;
}
+EXPORT_SYMBOL(cap_capget);
int cap_capset_check (struct task_struct *target, kernel_cap_t *effective,
kernel_cap_t *inheritable, kernel_cap_t *permitted)
@@ -100,6 +70,7 @@ int cap_capset_check (struct task_struct
return 0;
}
+EXPORT_SYMBOL(cap_capset_check);
void cap_capset_set (struct task_struct *target, kernel_cap_t *effective,
kernel_cap_t *inheritable, kernel_cap_t *permitted)
@@ -108,34 +79,42 @@ void cap_capset_set (struct task_struct
target-cap_inheritable = *inheritable;
target-cap_permitted = *permitted;
}
+EXPORT_SYMBOL(cap_capset_set);
-int cap_bprm_set_security (struct linux_binprm *bprm)
+int cap_capable (struct task_struct *tsk, int cap)
{
- /* Copied from fs/exec.c:prepare_binprm. */
-
- /* We don't have VFS support for capabilities yet */
- cap_clear (bprm-cap_inheritable);
- cap_clear (bprm-cap_permitted);
- cap_clear (bprm-cap_effective);
+ /* Derived from include/linux/sched.h:capable. */
+ if (cap_raised(tsk-cap_effective, cap))
+ return 0;
+ return -EPERM;
+}
+EXPORT_SYMBOL(cap_capable);
- /* To support inheritance of root-permissions and suid-root
-* executables under compatibility mode, we raise all three
-* capability sets for the file.
-*
-* If only the real uid is 0, we only raise the inheritable
-* and permitted sets of
[PATCH 0/5] LSM hook updates
This is based on Kurt's original work. The net effect is that LSM hooks are called conditionally, and in all cases capabilities provide the defaults. I've done some basic performance testing, and found nothing surprising. I'm interested to see numbers from others before I push this up. These are against Linus' current git tree (they will clash with the -mm tree). security/dummy.c | 996 include/linux/security.h | 1665 --- security/Makefile|9 security/commoncap.c | 160 ++-- security/root_plug.c | 14 security/security.c | 62 - 6 files changed, 839 insertions(+), 2067 deletions(-) thanks, -chris -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 5/5] Remove unnecesary capability hooks in rootplug.
Now that capability functions are default, rootplug no longer needs to
manually add them to its security_ops.
Cc: Greg Kroah [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
security/root_plug.c | 14 +-
1 files changed, 1 insertion(+), 13 deletions(-)
Index: lsm-hooks-2.6/security/root_plug.c
===
--- lsm-hooks-2.6.orig/security/root_plug.c
+++ lsm-hooks-2.6/security/root_plug.c
@@ -83,19 +83,7 @@ static int rootplug_bprm_check_security
}
static struct security_operations rootplug_security_ops = {
- /* Use the capability functions for some of the hooks */
- .ptrace = cap_ptrace,
- .capget = cap_capget,
- .capset_check = cap_capset_check,
- .capset_set = cap_capset_set,
- .capable = cap_capable,
-
- .bprm_apply_creds = cap_bprm_apply_creds,
- .bprm_set_security =cap_bprm_set_security,
-
- .task_post_setuid = cap_task_post_setuid,
- .task_reparent_to_init =cap_task_reparent_to_init,
-
+ /* The capability functions are the defaults */
.bprm_check_security = rootplug_bprm_check_security,
};
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] Call security hooks conditionally if the security_op is filled out.
Call security hooks conditionally if the security_op is filled out.
Branches can be more efficient than the unconditional indirect function
call. Inspired by patch from Kurt Garloff [EMAIL PROTECTED].
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
include/linux/security.h | 825 +++
1 files changed, 411 insertions(+), 414 deletions(-)
Index: linus-2.6/include/linux/security.h
===
--- linus-2.6.orig/include/linux/security.h
+++ linus-2.6/include/linux/security.h
@@ -1264,10 +1264,10 @@ static inline int security_init(void)
static inline int security_ptrace (struct task_struct * parent, struct
task_struct * child)
{
#ifdef CONFIG_SECURITY
- return security_ops-ptrace (parent, child);
-#else
- return cap_ptrace (parent, child);
+ if (security_ops-ptrace)
+ return security_ops-ptrace(parent, child);
#endif
+ return cap_ptrace (parent, child);
}
@@ -1277,10 +1277,10 @@ static inline int security_capget (struc
kernel_cap_t *permitted)
{
#ifdef CONFIG_SECURITY
- return security_ops-capget (target, effective, inheritable, permitted);
-#else
- return cap_capget (target, effective, inheritable, permitted);
+ if (security_ops-capget)
+ return security_ops-capget(target, effective, inheritable,
permitted);
#endif
+ return cap_capget (target, effective, inheritable, permitted);
}
static inline int security_capset_check (struct task_struct *target,
@@ -1289,10 +1289,10 @@ static inline int security_capset_check
kernel_cap_t *permitted)
{
#ifdef CONFIG_SECURITY
- return security_ops-capset_check (target, effective, inheritable,
permitted);
-#else
+ if (security_ops-capset_check)
+ return security_ops-capset_check(target, effective,
inheritable, permitted);
+#endif
return cap_capset_check (target, effective, inheritable, permitted);
-#endif
}
static inline void security_capset_set (struct task_struct *target,
@@ -1301,183 +1301,183 @@ static inline void security_capset_set (
kernel_cap_t *permitted)
{
#ifdef CONFIG_SECURITY
- security_ops-capset_set (target, effective, inheritable, permitted);
-#else
- cap_capset_set (target, effective, inheritable, permitted);
+ if (security_ops-capset_set)
+ return security_ops-capset_set(target, effective, inheritable,
permitted);
#endif
+ cap_capset_set (target, effective, inheritable, permitted);
}
static inline int security_acct (struct file *file)
{
#ifdef CONFIG_SECURITY
- return security_ops-acct (file);
-#else
- return 0;
+ if (security_ops-acct)
+ return security_ops-acct(file);
#endif
+ return 0;
}
static inline int security_sysctl(struct ctl_table *table, int op)
{
#ifdef CONFIG_SECURITY
- return security_ops-sysctl(table, op);
-#else
- return 0;
+ if (security_ops-sysctl)
+ return security_ops-sysctl(table, op);
#endif
+ return 0;
}
static inline int security_quotactl (int cmds, int type, int id,
struct super_block *sb)
{
#ifdef CONFIG_SECURITY
- return security_ops-quotactl (cmds, type, id, sb);
-#else
- return 0;
+ if (security_ops-quotactl)
+ return security_ops-quotactl(cmds, type, id, sb);
#endif
+ return 0;
}
static inline int security_quota_on (struct dentry * dentry)
{
#ifdef CONFIG_SECURITY
- return security_ops-quota_on (dentry);
-#else
- return 0;
+ if (security_ops-quota_on)
+ return security_ops-quota_on(dentry);
#endif
+ return 0;
}
static inline int security_syslog(int type)
{
#ifdef CONFIG_SECURITY
- return security_ops-syslog(type);
-#else
- return cap_syslog(type);
+ if (security_ops-syslog)
+ return security_ops-syslog(type);
#endif
+ return cap_syslog(type);
}
static inline int security_settime(struct timespec *ts, struct timezone *tz)
{
#ifdef CONFIG_SECURITY
- return security_ops-settime(ts, tz);
-#else
- return cap_settime(ts, tz);
+ if (security_ops-settime)
+ return security_ops-settime(ts, tz);
#endif
+ return cap_settime(ts, tz);
}
static inline int security_vm_enough_memory(long pages)
{
#ifdef CONFIG_SECURITY
- return security_ops-vm_enough_memory(pages);
-#else
- return cap_vm_enough_memory(pages);
+ if (security_ops-vm_enough_memory)
+ return security_ops-vm_enough_memory(pages);
#endif
+ return cap_vm_enough_memory(pages);
}
static inline int security_bprm_alloc (struct linux_binprm *bprm)
{
#ifdef CONFIG_SECURITY
- return security_ops-bprm_alloc_security (bprm);
-#else
-
Re: [PATCH 3/3] Add disk hotswap support to libata RESEND #2
On 8/24/05, Jim Ramsay [EMAIL PROTECTED] wrote: On 8/24/05, Lukasz Kosewski [EMAIL PROTECTED] wrote: On 8/24/05, Stefan Richter [EMAIL PROTECTED] wrote: Timers appear to operate in an atomic context, so timers should not be allowed to call scsi_remove_device, which eventually schedules. Any suggestions on the best way to fix this? Workqueue, perhaps. Perhaps. Actually, of course :) How about the existing ata_wq workqueue? This makes sense. When the timer expires, it adds a task to this queue. Note to self - No, you cannot use the exsting 'ata_wq' workqueue - The plug-in events need to put other work on the queue during the hotplug event... and of course this deadlocks since you're in the queuethread already. -- Jim Ramsay Me fail English? That's unpossible! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] RT-patch update to remove the global pi_lock
On Wed, 2005-08-24 at 21:13 -0400, Steven Rostedt wrote: Well, after turning off hrtimers, I keep getting one bug. A possible soft lockup with the ext3 code. But this didn't seem to be caused by the changes I made. So just to be sure, I ran my test on the vanilla 2.6.13-rc6-rt11 and it gave the same bug too. So, it looks like my changes are now at par with what is out there with the rt11 release. They both give the same bug! ;-) Attached is the test I ran. I did a while : ; do ./test3a_rt ; done Where test3a_rt is a C program that does adding, deleting and reading of files, by different tasks that are each at a different priority. Here's the soft lockup I'm getting: I got a report of a possible softlockup with setiathome, the trace wasn't a little garbled though . I'm not sure the checking is working correctly . But if it is maybe these spot need some performance analysis . Didn't you changes catch anything that stays in the kernel for 10 seconds or more ? Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc6] dcdbas: add Dell Systems Management Base Driver with sysfs support
This patch adds the Dell Systems Management Base Driver with sysfs support. This driver has been tested with Dell OpenManage. Signed-off-by: Doug Warzecha [EMAIL PROTECTED] --- diff -uprN linux-2.6.13-rc6.orig/Documentation/dcdbas.txt linux-2.6.13-rc6/Documentation/dcdbas.txt --- linux-2.6.13-rc6.orig/Documentation/dcdbas.txt 1969-12-31 18:00:00.0 -0600 +++ linux-2.6.13-rc6/Documentation/dcdbas.txt 2005-08-19 18:45:37.0 -0500 @@ -0,0 +1,87 @@ +Overview + +The Dell Systems Management Base Driver provides a sysfs interface for +systems management software such as Dell OpenManage to perform system +management interrupts and host control actions (system power cycle or +power off after OS shutdown) on certain Dell systems. + +Dell OpenManage requires this driver on the following Dell PowerEdge systems: +300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC, +700, and 750. Other Dell software such as the open source Libsmbios library +is expected to make use of this driver, and it may include the use of this +driver on other Dell systems. + + +System Management Interrupt + +On some Dell systems, systems management software must access certain +management information via a system management interrupt (SMI). The SMI data +buffer must reside in 32-bit address space, and the physical address of the +buffer is required for the SMI. The driver maintains the memory required for +the SMI and provides a way for the application to generate the SMI. +The driver creates the following sysfs entries for systems management +software to perform these system management interrupts: + +/sys/devices/platform/dcdbas/smi_data +/sys/devices/platform/dcdbas/smi_data_buf_phys_addr +/sys/devices/platform/dcdbas/smi_data_buf_size +/sys/devices/platform/dcdbas/smi_request + +Systems management software must perform the following steps to execute +a SMI using this driver: + +1) Lock smi_data. +2) Write system management command to smi_data. +3) Write 1 to smi_request to generate a calling interface SMI or + 2 to generate a raw SMI. +4) Read system management command response from smi_data. +5) Unlock smi_data. + + +Host Control Action + +Dell OpenManage supports a host control feature that allows the administrator +to perform a power cycle or power off of the system after the OS has finished +shutting down. On some Dell systems, this host control feature requires that +a driver perform a SMI after the OS has finished shutting down. + +The driver creates the following sysfs entries for systems management software +to schedule the driver to perform a power cycle or power off host control +action after the system has finished shutting down: + +/sys/devices/platform/dcdbas/host_control_action +/sys/devices/platform/dcdbas/host_control_smi_type +/sys/devices/platform/dcdbas/host_control_on_shutdown + +Dell OpenManage performs the following steps to execute a power cycle or +power off host control action using this driver: + +1) Write host control action to be performed to host_control_action. +2) Write type of SMI that driver needs to perform to host_control_smi_type. +3) Write 1 to host_control_on_shutdown to enable host control action. +4) Initiate OS shutdown. + (Driver will perform host control SMI when it is notified that the OS + has finished shutting down.) + + +Host Control SMI Type + +The following table shows the value to write to host_control_smi_type to +perform a power cycle or power off host control action: + +PowerEdge SystemHost Control SMI Type +- + 300 HC_SMITYPE_TYPE1 + 1300 HC_SMITYPE_TYPE1 + 1400 HC_SMITYPE_TYPE2 + 500SC HC_SMITYPE_TYPE2 + 1500SC HC_SMITYPE_TYPE2 + 1550 HC_SMITYPE_TYPE2 + 600SC HC_SMITYPE_TYPE2 + 1600SC HC_SMITYPE_TYPE2 + 650 HC_SMITYPE_TYPE2 + 1655MC HC_SMITYPE_TYPE2 + 700 HC_SMITYPE_TYPE3 + 750 HC_SMITYPE_TYPE3 + + diff -uprN linux-2.6.13-rc6.orig/drivers/firmware/dcdbas.c linux-2.6.13-rc6/drivers/firmware/dcdbas.c --- linux-2.6.13-rc6.orig/drivers/firmware/dcdbas.c 1969-12-31 18:00:00.0 -0600 +++ linux-2.6.13-rc6/drivers/firmware/dcdbas.c 2005-08-19 19:07:50.823719952 -0500 @@ -0,0 +1,593 @@ +/* + * dcdbas.c: Dell Systems Management Base Driver + * + * The Dell Systems Management Base Driver provides a sysfs interface for + * systems management software to perform System Management Interrupts (SMIs) + * and Host Control Actions (power cycle or power off after OS shutdown) on + * Dell systems. + * + * See Documentation/dcdbas.txt for more information. + * + * Copyright (C) 1995-2005 Dell Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License v2.0 as published by + * the Free Software Foundation. + * + * This
Re: [RFC] RT-patch update to remove the global pi_lock
On Wed, 24 Aug 2005, Daniel Walker wrote: I got a report of a possible softlockup with setiathome, the trace wasn't a little garbled though . I'm not sure the checking is working correctly . But if it is maybe these spot need some performance analysis . Didn't you changes catch anything that stays in the kernel for 10 seconds or more ? I haven't looked that hard yet. If Ingo is ready for my changes, to replace the pi_lock, then I can spend time tracking this down. Something is definity wrong, regardless whether or not the output is right. The tests constantly spit crap out, but when this happens, everything is silent. So something is definity amiss. Try it out and see what I mean. -- Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: question on memory barrier
Wrong. Reference: http://www.phy.duke.edu/~rgb/General/c_book/c_book/chapter8/sequen ce_points.html Cheers, Dick Johnson That discussion is wrong. The form of the argument is simply invalid. Just because an optimization could break things in some cases doesnt mean the compiler cant ever make the optimization. It just cant make the optimization in the case that breaks things. And by things I mean things that are defined in the standard that would be broken, not things outside of it. DS - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add MCE resume under ia32
On Wed, 2005-08-24 at 10:50 +0200, Pavel Machek wrote:
Hi!
diff -puN arch/i386/power/cpu.c~mcheck_resume arch/i386/power/cpu.c
--- linux-2.6.13-rc6/arch/i386/power/cpu.c~mcheck_resume
2005-08-23 09:32:13.054008584 +0800
+++ linux-2.6.13-rc6-root/arch/i386/power/cpu.c 2005-08-23
09:41:54.992540480 +0800
@@ -104,6 +104,8 @@ static void fix_processor_context(void)
}
+extern void mcheck_init(struct cpuinfo_x86 *c);
+
void __restore_processor_state(struct saved_context *ctxt)
{
/*
this should go to some header file and most importantly
If you agree my other points, I'll do this.
Ok, updated one.
Reinitialize MCE to avoid MCE non-fatal warning after resume.
Signed-off-by: Shaohua Li[EMAIL PROTECTED]
---
linux-2.6.13-rc6-root/arch/i386/kernel/cpu/common.c |5 +
linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/k7.c |2 +-
linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/mce.c |4 ++--
linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/p4.c |4 ++--
linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/p5.c |2 +-
linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/p6.c |2 +-
linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/winchip.c |2 +-
linux-2.6.13-rc6-root/arch/i386/power/cpu.c |1 +
linux-2.6.13-rc6-root/include/asm-i386/processor.h |6 ++
9 files changed, 16 insertions(+), 12 deletions(-)
diff -puN arch/i386/kernel/cpu/mcheck/k7.c~mcheck_resume
arch/i386/kernel/cpu/mcheck/k7.c
--- linux-2.6.13-rc6/arch/i386/kernel/cpu/mcheck/k7.c~mcheck_resume
2005-08-24 17:00:32.0 +0800
+++ linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/k7.c 2005-08-24
17:00:32.0 +0800
@@ -69,7 +69,7 @@ static fastcall void k7_machine_check(st
/* AMD K7 machine check is Intel like */
-void __devinit amd_mcheck_init(struct cpuinfo_x86 *c)
+void amd_mcheck_init(struct cpuinfo_x86 *c)
{
u32 l, h;
int i;
diff -puN arch/i386/kernel/cpu/mcheck/mce.c~mcheck_resume
arch/i386/kernel/cpu/mcheck/mce.c
--- linux-2.6.13-rc6/arch/i386/kernel/cpu/mcheck/mce.c~mcheck_resume
2005-08-24 17:00:32.0 +0800
+++ linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/mce.c 2005-08-24
17:00:32.0 +0800
@@ -16,7 +16,7 @@
#include mce.h
-int mce_disabled __devinitdata = 0;
+int mce_disabled = 0;
int nr_mce_banks;
EXPORT_SYMBOL_GPL(nr_mce_banks); /* non-fatal.o */
@@ -31,7 +31,7 @@ static fastcall void unexpected_machine_
void fastcall (*machine_check_vector)(struct pt_regs *, long error_code) =
unexpected_machine_check;
/* This has to be run for each processor */
-void __devinit mcheck_init(struct cpuinfo_x86 *c)
+void mcheck_init(struct cpuinfo_x86 *c)
{
if (mce_disabled==1)
return;
diff -puN arch/i386/kernel/cpu/mcheck/p4.c~mcheck_resume
arch/i386/kernel/cpu/mcheck/p4.c
--- linux-2.6.13-rc6/arch/i386/kernel/cpu/mcheck/p4.c~mcheck_resume
2005-08-24 17:00:32.0 +0800
+++ linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/p4.c 2005-08-24
17:00:32.0 +0800
@@ -78,7 +78,7 @@ fastcall void smp_thermal_interrupt(stru
}
/* P4/Xeon Thermal regulation detect and init */
-static void __devinit intel_init_thermal(struct cpuinfo_x86 *c)
+static void intel_init_thermal(struct cpuinfo_x86 *c)
{
u32 l, h;
unsigned int cpu = smp_processor_id();
@@ -232,7 +232,7 @@ static fastcall void intel_machine_check
}
-void __devinit intel_p4_mcheck_init(struct cpuinfo_x86 *c)
+void intel_p4_mcheck_init(struct cpuinfo_x86 *c)
{
u32 l, h;
int i;
diff -puN arch/i386/kernel/cpu/mcheck/p5.c~mcheck_resume
arch/i386/kernel/cpu/mcheck/p5.c
--- linux-2.6.13-rc6/arch/i386/kernel/cpu/mcheck/p5.c~mcheck_resume
2005-08-24 17:00:32.0 +0800
+++ linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/p5.c 2005-08-24
17:00:32.0 +0800
@@ -29,7 +29,7 @@ static fastcall void pentium_machine_che
}
/* Set up machine check reporting for processors with Intel style MCE */
-void __devinit intel_p5_mcheck_init(struct cpuinfo_x86 *c)
+void intel_p5_mcheck_init(struct cpuinfo_x86 *c)
{
u32 l, h;
diff -puN arch/i386/kernel/cpu/mcheck/p6.c~mcheck_resume
arch/i386/kernel/cpu/mcheck/p6.c
--- linux-2.6.13-rc6/arch/i386/kernel/cpu/mcheck/p6.c~mcheck_resume
2005-08-24 17:00:32.0 +0800
+++ linux-2.6.13-rc6-root/arch/i386/kernel/cpu/mcheck/p6.c 2005-08-24
17:00:32.0 +0800
@@ -80,7 +80,7 @@ static fastcall void intel_machine_check
}
/* Set up machine check reporting for processors with Intel style MCE */
-void __devinit intel_p6_mcheck_init(struct cpuinfo_x86 *c)
+void intel_p6_mcheck_init(struct cpuinfo_x86 *c)
{
u32 l, h;
int i;
diff -puN arch/i386/kernel/cpu/mcheck/winchip.c~mcheck_resume
arch/i386/kernel/cpu/mcheck/winchip.c
---
Hardware Perfromance Counters
Hello everyone, The system I am working on is a single processor Athlon. In the kernel I need to detect a cache miss (L1/L2) and trigger an event/function (inside the kernel). Now we have performance counters for detecting/counting cache misses. Among the various tools/patches available for accessing performance counters, which one do you guys recommend. Or do you think it would be easy to write code for this myself, as i just need this one event detection. Can you give some links where one can read about programming performance counters or some book on it. Thanks a lot. please cc reply to me too. -- Sushant Sharma http://cs.unm.edu/~sushant - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PowerOP Take 2 1/3: ARM OMAP1 platform support
PowerOP support for OMAP1 platforms. Currently handles these power
parameters:
dpllmult DPLL_CTL reg PLL MULT bits
dplldiv DPLL_CTL reg PLL DIV bits
armdiv ARM_CKCTL reg ARMDIV bits
dspdiv ARM_CKCTL reg DSPDIV bits
tcdivARM_CKCTL reg TCDIV bits
lowpwr 1 = assert ULPD LOW_PWR, voltage scale low
Other parameters such as DSPMMUDIV, LCDDIV, and ARM_PERDIV might also be
useful.
Example usage will be shown with a follow-on sysfs UI patch.
Index: linux-2.6.13-rc4/arch/arm/mach-omap1/powerop.c
===
--- /dev/null
+++ linux-2.6.13-rc4/arch/arm/mach-omap1/powerop.c
@@ -0,0 +1,157 @@
+/*
+ * PowerOP support for OMAP1
+ *
+ * Based on DPM OMAP code by Matthew Locke, Dmitry Chigirev, Vladimir
+ * Barinov, and Todd Poynor.
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed as is without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include linux/module.h
+#include linux/errno.h
+#include linux/init.h
+
+#include asm/arch/powerop.h
+#include asm/hardware.h
+#include asm/arch/pm.h
+
+/* ARM_CKCTL bit shifts */
+#define CKCTL_PERDIV_OFFSET0
+#define CKCTL_LCDDIV_OFFSET2
+#define CKCTL_ARMDIV_OFFSET4
+#define CKCTL_DSPDIV_OFFSET6
+#define CKCTL_TCDIV_OFFSET 8
+#define CKCTL_DSPMMUDIV_OFFSET 10
+
+#define DPLL_CTL_MASK 0xfe0
+
+#define ULPD_MIN_MAX_REG (1 11)
+#define ULPD_DVS_ENABLE (1 10)
+#define ULPD_LOW_PWR_REQ (1 1)
+#define LOW_POWER (ULPD_MIN_MAX_REG | ULPD_DVS_ENABLE | ULPD_LOW_PWR_REQ | \
+ ULPD_LOW_PWR_EN)
+
+int
+powerop_get_point(struct powerop_point *point)
+{
+ unsigned long flags;
+ int dpll_ctl, arm_cktl;
+
+ local_irq_save(flags);
+ dpll_ctl = omap_readw(DPLL_CTL);
+ arm_cktl = omap_readw(ARM_CKCTL);
+
+ point-dpllmult = dpll_ctl 7 0x1f;
+ point-dplldiv = dpll_ctl 5 0x3;
+ point-armdiv = arm_cktl CKCTL_ARMDIV_OFFSET 0x3;
+ point-dspdiv = arm_cktl CKCTL_DSPDIV_OFFSET 0x3;
+ point-tcdiv = arm_cktl CKCTL_TCDIV_OFFSET 0x3;
+ point-lowpwr = (omap_readw(ULPD_POWER_CTRL) (ULPD_LOW_PWR_REQ)) ?
+ 1 : 0;
+ local_irq_restore(flags);
+ return 0;
+}
+
+static void scale_dpll(int dpll_ctl)
+{
+ int i;
+
+ omap_writew((omap_readw(DPLL_CTL) ~DPLL_CTL_MASK) | dpll_ctl,
+ DPLL_CTL);
+
+ for (i = 0; i 0x1FF; i++)
+ nop();
+
+ /*
+* Wait for PLL relock.
+*/
+
+ while ((omap_readw(DPLL_CTL) 0x1) == 0);
+}
+
+static void set_low_pwr(int lowpwr)
+{
+ int cur_lowpwr;
+
+ if (lowpwr == -1)
+ return;
+
+ cur_lowpwr = (omap_readw(ULPD_POWER_CTRL) (ULPD_LOW_PWR_REQ)) ?
+ 1 : 0;
+
+ if (cur_lowpwr != lowpwr) {
+ if (lowpwr)
+ omap_writew(omap_readw(ULPD_POWER_CTRL) | LOW_POWER,
+ ULPD_POWER_CTRL);
+ else
+ omap_writew(omap_readw(ULPD_POWER_CTRL) ~LOW_POWER,
+ ULPD_POWER_CTRL);
+ }
+}
+
+int
+powerop_set_point(struct powerop_point *point)
+{
+ int dpll_ctl = 0;
+ int dpll_mod = 0;
+ int arm_ctl = 0;
+ int arm_msk = 0;
+ int cur_dpll_ctl;
+ unsigned long flags;
+
+ if ((point-dpllmult != -1) (point-dplldiv != -1)) {
+ dpll_ctl = (point-dpllmult 7) |
+ (point-dplldiv 5);
+ dpll_mod = 1;
+ }
+
+ if (point-armdiv != -1) {
+ arm_ctl |= (point-armdiv CKCTL_ARMDIV_OFFSET);
+ arm_msk |= (3 CKCTL_ARMDIV_OFFSET);
+ }
+
+ if (point-dspdiv != -1) {
+ arm_ctl |= (point-dspdiv CKCTL_DSPDIV_OFFSET);
+ arm_msk |= (3 CKCTL_DSPDIV_OFFSET);
+ }
+
+ if (point-tcdiv != -1) {
+ arm_ctl |= (point-tcdiv CKCTL_TCDIV_OFFSET);
+ arm_msk |= (3 CKCTL_TCDIV_OFFSET);
+ }
+
+ local_irq_save(flags);
+ cur_dpll_ctl = omap_readw(DPLL_CTL) DPLL_CTL_MASK;
+
+ if (dpll_mod (dpll_ctl cur_dpll_ctl))
+ scale_dpll(dpll_ctl);
+
+ if (arm_msk != 0)
+ omap_writew((omap_readw(ARM_CKCTL) ~arm_msk) | arm_ctl,
+ ARM_CKCTL);
+
+ if (dpll_mod (dpll_ctl cur_dpll_ctl))
+ scale_dpll(dpll_ctl);
+
+ set_low_pwr(point-lowpwr);
+ local_irq_restore(flags);
+ return 0;
+}
+
+EXPORT_SYMBOL_GPL(powerop_get_point);
+EXPORT_SYMBOL_GPL(powerop_set_point);
+
+static int __init powerop_init(void)
+{
+ return 0;
+}
+
+static void __exit powerop_exit(void)
+{
+}
+
+module_init(powerop_init);
+module_exit(powerop_exit);
Index: linux-2.6.13-rc4/include/asm-arm/arch-omap/powerop.h
PowerOP Take 2 0/3 Intro
PowerOP is a system power parameter management API submitted for discussion. PowerOP writes and reads power operating points, comprised of arbitrary values, called power parameters, that correspond to registers, clocks, dividers, voltage regulators, etc. that may be modified to set a basic power/performance point for the system. Higher-layer power management software passes a platform-specific struct of power parameters to a backend that makes the requested adjustments. PowerOP can be thought of as a layer below cpufreq that actually accesses the hardware to make cpu frequency, voltage, core bus, and perhaps other modifications to set a power point. The main goal is to open up interfaces to operating points comprised of arbitrary power parameters, as an alternative to the cpu frequency parameter that cpufreq is designed around. It pushes the hardware-level power parameter management down to a level that can be shared with other power management policy frameworks that deal with entire operating points as the basic unit of system power management for reasons described below, and that The new layer is intended to leave all power policy decisions, and various other power management chores such as driver notification, to higher layers in a power management software stack. This work is aimed in part at supporting embedded systems, which often have several parameters that can be set and the cpu frequency abstraction specifies only part of the operating point that may be managed from software. For example, an XScale PXA27x could be considered to have six basic power parameters (mainly cpu run mode and memory and bus dividers) that for the most part should be set in tandem to known good sets of values as validated by the silicon vendor. Embedded systems typically handle more hardware clock manipulation directly in Linux than do, for example, desktop/server systems based on ACPI interfaces. Desktop/server systems may also benefit from the ability to select custom voltages, bus speeds, etc., although deviating from values validated by the hardware vendor is risky and controversial. An optional sysfs interface to create and activate operating points is also submitted for discussion. This interface could be used in an actual power management stack, or at least can serve as a starting point for discussing how to manage operating points at the next higher layer in the power management soctware stack. cpufreq is another possible interface. PowerOP can fit below cpufreq to make cpu frequency, voltage, core bus, and perhaps other modifications to set a power point, leaving cpufreq to manage the interfaces based around the cpu frequency abstraction, the policies and governors that select the frequency, its notifiers, and so forth. An example hooking up support for one cpufreq platform to PowerOP has been previously submitted. Some discussion regarding incorporating an expanded set of power parameters into the cpufreq interfaces has also taken place. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PowerOP Take 2 3/3: OMAP1 sysfs UI
A PowerOP sysfs UI backend for OMAP1 platforms, adding sysfs attributes
and show/store functions that correspond to the platform power
parameters.
An example usage on an OMAP1510 Innovator which does not have voltage
scaling and ignoring the DSP:
# echo -n 168-168-84 /sys/powerop/new # DPLL 168MHz, ARM 168MHz, TC 84MHz
# echo -n 14 /sys/powerop/168-168-84/dpllmult
# echo -n 0 /sys/powerop/168-168-84/dplldiv
# echo -n 0 /sys/powerop/168-168-84/armdiv
# echo -n 1 /sys/powerop/168-168-84/tcdiv
# echo -n -1 /sys/powerop/168-168-84/dspdiv
# echo -n -1 /sys/powerop/168-168-84/lowpwr
# echo -n 60-60-60 /sys/powerop/new # DPLL 60MHz, ARM 60MHz, TC 60MHz
# echo -n 5 /sys/powerop/60-60-60/dpllmult
# echo -n 0 /sys/powerop/60-60-60/dplldiv
# echo -n 0 /sys/powerop/60-60-60/armdiv
# echo -n 0 /sys/powerop/60-60-60/tcdiv
# echo -n -1 /sys/powerop/60-60-60/dspdiv
# echo -n -1 /sys/powerop/60-60-60/lowpwr
# echo -n 60-60-60 /sys/powerop/active
# cat /sys/powerop/hw/dpllmult
5
The lower-powered operating point consumes about .07A less power using
my .config (it should be noted this is not a proper low-power evaluation
platform).
Index: linux-2.6.13-rc4/arch/arm/mach-omap1/Kconfig
===
--- linux-2.6.13-rc4.orig/arch/arm/mach-omap1/Kconfig
+++ linux-2.6.13-rc4/arch/arm/mach-omap1/Kconfig
@@ -155,3 +155,5 @@ source arch/arm/plat-omap/dsp/Kconfig
config POWEROP
bool PowerOP Platform Core Power Management for OMAP1
help
+
+source drivers/powerop/Kconfig
Index: linux-2.6.13-rc4/arch/arm/mach-omap1/powerop.c
===
--- linux-2.6.13-rc4.orig/arch/arm/mach-omap1/powerop.c
+++ linux-2.6.13-rc4/arch/arm/mach-omap1/powerop.c
@@ -13,6 +13,7 @@
#include linux/module.h
#include linux/errno.h
#include linux/init.h
+#include linux/powerop_sysfs.h
#include asm/arch/powerop.h
#include asm/hardware.h
@@ -144,13 +145,141 @@ powerop_set_point(struct powerop_point *
EXPORT_SYMBOL_GPL(powerop_get_point);
EXPORT_SYMBOL_GPL(powerop_set_point);
+#ifdef CONFIG_POWEROP_SYSFS
+
+ssize_t lowpwr_show(struct powerop_point *op, char * buf)
+{
+ return sprintf(buf,%d\n,op-lowpwr);
+}
+
+ssize_t lowpwr_store(struct powerop_point *op, const char * buf, size_t count)
+{
+ int error;
+
+ if ((error = sscanf(buf, %d, op-lowpwr)) == 1)
+ return count;
+ return error;
+}
+
+powerop_param_attr(lowpwr);
+
+ssize_t dpllmult_show(struct powerop_point *op, char * buf)
+{
+ return sprintf(buf,%d\n,op-dpllmult);
+}
+
+ssize_t dpllmult_store(struct powerop_point *op, const char * buf, size_t
count)
+{
+ int error;
+
+ if ((error = sscanf(buf, %d, op-dpllmult)) == 1)
+ return count;
+ return error;
+}
+
+powerop_param_attr(dpllmult);
+
+ssize_t dplldiv_show(struct powerop_point *op, char * buf)
+{
+ return sprintf(buf,%d\n,op-dplldiv);
+}
+
+ssize_t dplldiv_store(struct powerop_point *op, const char * buf, size_t count)
+{
+ int error;
+
+ if ((error = sscanf(buf, %d, op-dplldiv)) == 1)
+ return count;
+ return error;
+}
+
+powerop_param_attr(dplldiv);
+
+ssize_t armdiv_show(struct powerop_point *op, char * buf)
+{
+ return sprintf(buf,%d\n,op-armdiv);
+}
+
+ssize_t armdiv_store(struct powerop_point *op, const char * buf, size_t count)
+{
+ int error;
+
+ if ((error = sscanf(buf, %d, op-armdiv)) == 1)
+ return count;
+ return error;
+}
+
+powerop_param_attr(armdiv);
+
+ssize_t dspdiv_show(struct powerop_point *op, char * buf)
+{
+ return sprintf(buf,%d\n,op-dspdiv);
+}
+
+ssize_t dspdiv_store(struct powerop_point *op, const char * buf, size_t count)
+{
+ int error;
+
+ if ((error = sscanf(buf, %d, op-dspdiv)) == 1)
+ return count;
+ return error;
+}
+
+powerop_param_attr(dspdiv);
+
+ssize_t tcdiv_show(struct powerop_point *op, char * buf)
+{
+ return sprintf(buf,%d\n,op-tcdiv);
+}
+
+ssize_t tcdiv_store(struct powerop_point *op, const char * buf, size_t count)
+{
+ int error;
+
+ if ((error = sscanf(buf, %d, op-tcdiv)) == 1)
+ return count;
+ return error;
+}
+
+powerop_param_attr(tcdiv);
+
+static struct attribute *powerop_sysfs_param_attrs[] = {
+ lowpwr_attr.attr,
+ dpllmult_attr.attr,
+ dplldiv_attr.attr,
+ armdiv_attr.attr,
+ dspdiv_attr.attr,
+ tcdiv_attr.attr,
+ NULL,
+};
+
+static void powerop_omap1_sysfs_init()
+{
+ powerop_sysfs_register(powerop_sysfs_param_attrs);
+}
+
+static void powerop_omap1_sysfs_exit()
+{
+ powerop_sysfs_unregister(powerop_sysfs_param_attrs);
+}
+#else /* CONFIG_POWEROP_SYSFS */
+static void powerop_omap1_sysfs_init()
+{
+}
+static void powerop_omap1_sysfs_exit()
+{
+}
+#endif /* CONFIG_POWEROP_SYSFS */
+
static int __init powerop_init(void)
{
+ powerop_omap1_sysfs_init();
PowerOP Take 2 2/3: sysfs UI core
A sysfs interface for PowerOP that allows operating points to be created
and activated from userspace.
The platform-specific backend provides the code to read and write sysfs
attributes for each power parameter; the core sysfs interface has no
knowledge of the struct powerop_point contents. This interface could be
used independently of an integrated cpufreq or DPM interface. It is not
an integral part of PowerOP and is provided in part to facilitate
discussion and experimentation with PowerOP, but could serve as a basis
for a basic userspace power policy management stack.
Operating points are created by writing the name of the operating point
to /sys/powerop/new. This may be a job for configfs.
/sys/powerop/op/ will contain an attribute for each power parameter
that may be written to set the associated parameter for the new
operating point. An operating point may be activated by writing its
name to /sys/powerop/active. The hardware power parameters currently
set may be read and written via /sys/powerop/hw/, a special operating
point that reads and writes parameter attribute values immediately,
primarily for diagnostic purposes.
Buried in this interface is also the notion of a registry of named
operating points, allowing operating points created by some other
interface (such as cpufreq or loading a module with the definitions as
suggested previously by David Brownell) to be activated from userspace
via /sys/powerop/active.
Changing operating points (or other power-policy-based information that
triggers changes in operating points) from userspace is a common
scenario in some embedded systems, where power/performance needs change
based on system state changes that are coordinated by a userspace
process (for example, a mobile phone starting a multimedia application).
Index: linux-2.6.13-rc4/drivers/powerop/Kconfig
===
--- /dev/null
+++ linux-2.6.13-rc4/drivers/powerop/Kconfig
@@ -0,0 +1,4 @@
+config POWEROP_SYSFS
+ bool Enable PowerOP sysfs interface
+ depends on POWEROP SYSFS
+ help
Index: linux-2.6.13-rc4/drivers/powerop/Makefile
===
--- /dev/null
+++ linux-2.6.13-rc4/drivers/powerop/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_POWEROP_SYSFS)+= powerop_sysfs.o
Index: linux-2.6.13-rc4/drivers/powerop/powerop_sysfs.c
===
--- /dev/null
+++ linux-2.6.13-rc4/drivers/powerop/powerop_sysfs.c
@@ -0,0 +1,398 @@
+/*
+ * PowerOP sysfs UI
+ *
+ * Author: Todd Poynor [EMAIL PROTECTED]
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed as is without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include linux/config.h
+#include linux/module.h
+#include linux/powerop_sysfs.h
+#include linux/init.h
+#include linux/kobject.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/string.h
+#include linux/err.h
+#include linux/errno.h
+
+#include asm/powerop.h
+
+int powerop_register_point(const char *id, struct powerop_point *point);
+int powerop_select_point(const char *id);
+
+struct namedop {
+ struct kobject kobj;
+ struct powerop_point *point;
+ struct list_head node;
+ struct completion released;
+};
+
+#define to_namedop(_kobj) container_of(_kobj,\
+ struct namedop,kobj)
+
+static DECLARE_MUTEX(namedop_list_mutex);
+static struct list_head namedop_list;
+static struct namedop *activeop;
+
+struct sysfsop {
+ struct powerop_point point;
+ struct list_head node;
+};
+
+static DECLARE_MUTEX(sysfsop_list_mutex);
+static struct list_head sysfsop_list;
+
+static struct powerop_point *hwop;
+
+#define powerop_attr(_name) \
+static struct subsys_attribute _name##_attr = { \
+ .attr = { \
+ .name = __stringify(_name), \
+ .mode = 0644, \
+ .owner = THIS_MODULE, \
+ }, \
+ .show = _name##_show, \
+ .store = _name##_store,\
+}
+
+static struct attribute_group param_attr_group;
+
+#define to_powerop_param_attr(_attr) container_of(_attr,\
+ struct powerop_param_attribute,attr)
+
+
+decl_subsys(powerop, NULL, NULL);
+static int subsys_reg;
+static int sysfs_init;
+
+static void namedop_release(struct kobject *kobj)
+{
+ struct namedop *op = to_namedop(kobj);
+
+ complete(op-released);
+ return;
+}
+
+static struct sysfsop *sysfsop_create(const char *id)
+{
+ struct sysfsop *op;
+ int error;
+
+ if ((op = kmalloc(sizeof(struct sysfsop), GFP_KERNEL)) == NULL)
+ return ERR_PTR(-ENOMEM);
+
+ down(sysfsop_list_mutex);
+ list_add_tail(op-node, sysfsop_list);
+
Re: [PATCH 2.6.13-rc6] dcdbas: add Dell Systems Management Base Driver with sysfs support
On Wed, Aug 24, 2005 at 09:00:21PM -0500, Doug Warzecha wrote: [...] +Dell OpenManage requires this driver on the following Dell PowerEdge systems: +300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC, +700, and 750. Other Dell software such as the open source Libsmbios library +is expected to make use of this driver, and it may include the use of this +driver on other Dell systems. I'd like to see a URL/pointer somewhere about here in the docs for the location of libsmbios if nobody objects. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and TMPFS!
On Wed, Aug 24, 2005 at 06:41:26PM -0400, [EMAIL PROTECTED] wrote: I tried it with kernel 2.6.13-rc5 and it seems to work. it should yes It uses 50% of total memory for tmpfs, but it would be nice to have an option (tmpfs_size=90% etc.) that you could pass to the kernel. that's just because of the tmpfs default; you can remount to change that if it's not suitable once your up and running in your init-scripts or whatever You need to add this to init/main.c for it to compile. #include asm/uaccess.h hmm... really? i'll rediff it at some point and test it maybe. i really don't like the explicity shm init though, i'd like to think of a cleaner way to do that - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and TMPFS!
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote: Also, tar should be an option instead of cpio for the archiver, because tar is more widely used. pretty much everyone will have cpio and it's format is much simpler/cleaner to deal with if we want vastly more complex early-userspace semantics i think we need to carefully decide what is needed and how to put as much of that logic into userspace rather than hacking this much more in the kernel for fear of breaking things in subtle ways - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.13-rc6: halt instead of reboot
Meelis Roos [EMAIL PROTECTED] writes: It does not hang, it just powers off like on halt. Ok. Then at least in part the kernel behavior is either intersecting with a BIOS bug, a bad reboot script that calls halt instead, or a driver that is scribbling on the wrong register. There is nothing in that code path that should remove the power. With reboot=c, reboot=w and reboot=h it still powers off. With reboot=b it actually reboots. With 2.6.13-rc2 (the previous good kernel here) it just works and does a reboot with no special parameters. I also have lapic nmi_watchdog=1 in boot command line but removing these does not help either. So far I only know that rc6+somegit and rc7 power off and rc2 works, will try som kernels inbetween. Hmm. Odd. When skimming through the code I thought that reboot_thru_bios was the default. So the code is currently trying a reset through the keyboard controller and a triple fault and neither work. If you can't track this down we can at least dig up your board DMI ID and put it in the list of systems that need to go through the BIOS to reboot. 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: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
john stultz wrote: On Wed, 2005-08-24 at 16:46 -0700, George Anzinger wrote: john stultz wrote: On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote: Roman Zippel wrote: Hi, On Tue, 23 Aug 2005, john stultz wrote: I'm assuming gettimeofday()/clock_gettime() looks something like: xtime + (get_cycles()-last_update)*(mult+ntp_adj)shift Where did you get the ntp_adj from? It's not in my example. gettimeofday() was in the previous mail: xtime + (cycle_offset * mult + error) shift. The difference between system time and reference time is really important. gettimeofday() returns the system time, NTP controls the reference time and these two are synchronized regularly. I didn't see that anywhere in your example. If I read your example right, the problem is when the NTP adjustment changes while the two clocks are out of sync (because of a late tick). Not quite. The issue that I'm trying to describe is that if, we inconsistently calculate time intervals in gettimeofday and the timer interrupt, we have the possibility for time inconsistencies. The trivial example using the current code would be something like: Again with my 2 cyc per tick clock, HZ=1000. gettimeofday(): xtime + offset_ns timer_interrupt: xtime += tick_length + ntp_adj offset_ns = 0 0: gettimeofday: 0 + 0 = 0 ns 1: gettimeofday: 0 + 500k ns = 500k ns 2: gettimeofday: 0 + 1M ns = 1M ns 2: timer_interrupt: 2: gettimeofday: 1M ns + 0 ns = 1M ns 3: gettimeofday: 1M ns + 500k ns = 1.5M ns 4: gettimeofday: 1M ns + 1M ns = 2 ns 4: timer_interrupt (using -500ppm adjustment) 4: gettimeofday: 1,999,500 ns + 0 ns = 1,999,500 ns At point 4 you are introducing a NEW ntp adjustment. This, I submit, needs to actually have been introduced to the system prior to the interrupt at point 2 with the first xtime change at point 4. However, gettimeofday() should be aware of it from the interrupt at point 2 and be doing corrections from that time forward. Thus when the point 4 interrutp happens xtime will be the same at the gettimeofday a ns earlier. Yes, clearly a forward knowledge of the NTP adjustment is necessary for gettimeofday(), because after the NTP adjustment has been accumulated into xtime, there's nothing left for gettimeofday to adjust (its already been applied). :) Likewise, gettimeofday() needs to know when to stop apply the correction so that if a tick is late, it will apply the correction only for those times that it was needed. This, could be done by figuring the offset thusly: offset = (offset from last tick to end of ntp period * ntp_adj1) + (offset from end of ntp period to now) Well, in my example, the ntp_adjustment is a fixed nanosecond offset, so it would be added to the nanosecond offset from the last tick (which is how the current code works). If you are doing scaling (as you have in the equation above), then the problem goes away, since you can apply the adjustment consistently through any interval. Until the end of the correction time... I suppose it is possible that the latter part of the offset is also under a different ntp correction which would mean a * ntp_adj2 is needed. Ok, so your forcing gettimeofday to be interval aware, so its applying different fixed NTP adjustments to different chunks of the current interval. The issue of course is if you're using fixed adjustments, is that you have to have n ntp adjustments for n intervals, or you have to apply the same ntp adjustment to multiple intervals. Uh, are you saying that one ntpd call can set up several different adjustments? I was assuming that any given call would set up either a fixed adjustment for ever or a fixed adjustment to be applied for a fixed number of ticks (or until so much correcting was done, which, in the end is the same thing at this point in the code). If ntpd has to come back to change the adjustment, I am assuming that some kernel action can be taken at that time to sync the xtime clock and the gettimeofday reading of it. I.e. we would only have to keep track of one adjustment with a possible pre specified end time. I would argue that only two terms are needed here regardless of how late a tick is. This is because, I would expect the ntp system call to sync the two clocks. This means in your example, the ntp call would have been made at, or prior to the timer interrupt at 2 and this is the same edge that gettimeofday is to used to start applying the correction. If you argue that we only need two adjustments, why not argue for only one? You're saying have one adjustment that you apply for the first tick's worth of time, and a second adjustment that you apply for the following N ticks' worth of time in the interval. Why the odd base case? Correct me if I am wrong here, but I am assuming that ntpd can ask for an adjustment of X amount which the kernel changes into N adjustments of X/N amount spread over the next N
Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
Hi, On Wed, 24 Aug 2005, john stultz wrote: from your example: // at init: system_update = update_cycles * mult; system_time += system_update; and: error = system_time - (xtime.tv_nsec shift); This doesn't seem to make sense with the above. Could you clarify? The example here doesn't keep the complete system time, just enough to compute the difference. bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 - 0/9] Generic timekeeping subsystem (v. B5)
On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote: Roman Zippel wrote: Hi, On Tue, 23 Aug 2005, john stultz wrote: I'm assuming gettimeofday()/clock_gettime() looks something like: xtime + (get_cycles()-last_update)*(mult+ntp_adj)shift Where did you get the ntp_adj from? It's not in my example. gettimeofday() was in the previous mail: xtime + (cycle_offset * mult + error) shift. The difference between system time and reference time is really important. gettimeofday() returns the system time, NTP controls the reference time and these two are synchronized regularly. I didn't see that anywhere in your example. If I read your example right, the problem is when the NTP adjustment changes while the two clocks are out of sync (because of a late tick). Not quite. The issue that I'm trying to describe is that if, we inconsistently calculate time intervals in gettimeofday and the timer interrupt, we have the possibility for time inconsistencies. The trivial example using the current code would be something like: Again with my 2 cyc per tick clock, HZ=1000. gettimeofday(): xtime + offset_ns timer_interrupt: xtime += tick_length + ntp_adj offset_ns = 0 0: gettimeofday: 0 + 0 = 0 ns 1: gettimeofday: 0 + 500k ns = 500k ns 2: gettimeofday: 0 + 1M ns = 1M ns 2: timer_interrupt: 2: gettimeofday: 1M ns + 0 ns = 1M ns 3: gettimeofday: 1M ns + 500k ns = 1.5M ns 4: gettimeofday: 1M ns + 1M ns = 2 ns 4: timer_interrupt (using -500ppm adjustment) 4: gettimeofday: 1,999,500 ns + 0 ns = 1,999,500 ns It would appear that gettimeofday would need to know that the NTP adjustment is changing (and to what). It would also appear that this is known by the ntp code and could be made available to gettimeofday. If it is changing due to an NTP call, that system call, itself, should/must force synchronization. So the only case gettimeofday needs to worry/know about is that an adjustment is to change at time X to value Y. Also, me thinks there is only one such change that can be present at any given time. Well, in many arches gettimeofday() works around the above issue by capping the offset_ns value as such: gettimeofday: xtime + min(offset_ns, tick_len + ntp_adj) The problem with this is that when we have lost or late ticks, or if we are using dynamic ticks you have granularity problems. thanks -john - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Hdaps-devel] Re: HDAPS, Need to park the head for real
Jens Axboe wrote:
Ok, I'll give you some hints to get you started... What you really want
to do, is:
- Insert a park request at the front of the queue
- On completion callback on that request, freeze the block queue and
schedule it for unfreeze after a given time
Am attaching a first attempt at a patch - for comments only - please
don't apply to a production system. I've not delved into the IDE code
before, so I've just been following my nose... In other words - It
appears to work for me - but I may be doing something crazy ;)
Having said that, I tested with a utility that repeatedly froze/thawed
hundreds of times while really hammering the disk with file copies, and
nothing oopsed or failed to checksum afterwards...
To do:
Move the /proc interface to sysfs. At the moment it's just a simple
'echo -n 1 /proc/ide/hda/freeze' to freeze, and 0 to thaw.
Address Jens concerns about our userspace code falling over and leaving
the machine hung. I favour retaining a binary on/off interface (rather
than specifying a timeout up front), but having the IDE code auto-thaw
on a timer.. That way we can just keep writing 1's to it while we're
checking the accelerometer and wanting to keep it frozen, and if we
should die then it'll wake up by itself after a second or so...
Same again for libata (for T43 owners).
Regards,
Jon.
__
Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk)diff -urN linux-2.6.13-rc6.original/drivers/ide/ide-io.c linux-2.6.13-rc6/drivers/ide/ide-io.c
--- linux-2.6.13-rc6.original/drivers/ide/ide-io.c 2005-06-17 20:48:29.0 +0100
+++ linux-2.6.13-rc6/drivers/ide/ide-io.c 2005-08-24 20:56:31.0 +0100
@@ -1181,6 +1181,16 @@
}
/*
+ * Don't accept a request when the queue is stopped
+ * (unless we are resuming from suspend)
+ */
+ if (test_bit(QUEUE_FLAG_STOPPED, drive-queue-queue_flags) !blk_pm_resume_request(rq)) {
+ printk(KERN_ERR %s: queue is stopped!\n, drive-name);
+ hwgroup-busy = 0;
+ break;
+ }
+
+ /*
* Sanity: don't accept a request that isn't a PM request
* if we are currently power managed. This is very important as
* blk_stop_queue() doesn't prevent the elv_next_request()
@@ -1661,6 +1671,9 @@
where = ELEVATOR_INSERT_FRONT;
rq-flags |= REQ_PREEMPT;
}
+ if (action == ide_next)
+ where = ELEVATOR_INSERT_FRONT;
+
__elv_add_request(drive-queue, rq, where, 0);
ide_do_request(hwgroup, IDE_NO_IRQ);
spin_unlock_irqrestore(ide_lock, flags);
diff -urN linux-2.6.13-rc6.original/drivers/ide/ide-proc.c linux-2.6.13-rc6/drivers/ide/ide-proc.c
--- linux-2.6.13-rc6.original/drivers/ide/ide-proc.c 2005-06-17 20:48:29.0 +0100
+++ linux-2.6.13-rc6/drivers/ide/ide-proc.c 2005-08-24 21:51:14.0 +0100
@@ -264,6 +264,122 @@
return -EINVAL;
}
+static int proc_ide_read_freeze
+ (char *page, char **start, off_t off, int count, int *eof, void *data)
+{
+ ide_drive_t *drive = (ide_drive_t *) data;
+ char *out = page;
+ int len;
+
+ proc_ide_settings_warn();
+
+ if (test_bit(QUEUE_FLAG_STOPPED, drive-queue-queue_flags))
+ out += sprintf(out, %s: queue is stopped\n, drive-name);
+ else
+ out += sprintf(out, %s: queue not stopped\n, drive-name);
+
+ len = out - page;
+ PROC_IDE_READ_RETURN(page,start,off,count,eof,len);
+}
+
+void ide_end_freeze_rq(struct request *rq)
+{
+ struct completion *waiting = rq-waiting;
+ u8 *argbuf = rq-buffer;
+
+ /* Spinlock is already acquired */
+ if (argbuf[3] == 0xc4) {
+ blk_stop_queue(rq-q);
+ printk(KERN_ERR ide_end_freeze_rq(): Queue stopped...\n);
+ }
+ else
+ printk(KERN_ERR ide_end_freeze_rq(): Head not parked...\n);
+/*
+ blk_stop_queue(rq-q);
+ printk(KERN_ERR ide_end_freeze_rq(): Queue stopped...\n);
+*/
+ complete(waiting);
+}
+
+static int proc_ide_write_freeze(struct file *file, const char __user *buffer,
+ unsigned long count, void *data)
+{
+ DECLARE_COMPLETION(wait);
+ unsigned long val, flags;
+ char *buf, *s;
+ struct request rq;
+ ide_drive_t *drive = (ide_drive_t *) data;
+ u8 args[7], *argbuf = args;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
+
+ proc_ide_settings_warn();
+
+ if (count = PAGE_SIZE)
+ return -EINVAL;
+
+ s = buf = (char *)__get_free_page(GFP_USER);
+ if (!buf)
+ return -ENOMEM;
+
+ if (copy_from_user(buf, buffer, count)) {
+ free_page((unsigned long)buf);
+ return -EFAULT;
+ }
+
+ buf[count] = '\0';
+ memset(rq, 0, sizeof(rq));
+ memset(args, 0, sizeof(args));
+
+ /* Ought to check we're the right sort of device - i.e. hard disk only */
+
+ /* STANDY IMMEDIATE COMMAND (spins down drive - more obvious for testing?)
+ argbuf[0] = 0xe0;
+ */
+
+ /* UNLOAD IMMEDIATE COMMAND */
+ argbuf[0] = 0xe1;
+ argbuf[1] = 0x44;
+ argbuf[3] = 0x4c;
+ argbuf[4] = 0x4e;
+ argbuf[5] = 0x55;
+
+ /* Ought to have some sanity checking around these values */
+ val = simple_strtoul(buf, s, 10);
+ if (val) {
+ /* Check we're not already frozen */
+ if
Re: [PATCH 2.6] I2C: Drop I2C_DEVNAME and i2c_clientname
Hi Mauro, I2C_DEVNAME and i2c_clientname were introduced in 2.5.68 [1] to help media/video driver authors who wanted their code to be compatible with both Linux 2.4 and 2.6. The cause of the incompatibility has gone since [2], so I think we can get rid of them, as they tend to make the code harder to read and longer to preprocess/compile for no more benefit. I'd hope nobody seriously attempts to keep media/video driver compatible across Linux trees anymore, BTW. That's not true. We keep V4L tree compatible with older kernel releases. Each change like this does generate a lot of work at V4L side to provide #ifdefs to check for linux version and provide a compatible way to compile with older versions. I'm sorry but we will not stop updating the various Linux 2.6 subsystems to keep them compatible with 2.4 - else one would wonder why there is a 2.6 kernel tree at all. As time goes, the differences bwteen 2.4 and 2.6 will only increase. You seem to be trying to keep common driver code across incompatible trees. I'm not surprised that it is a lot of work. That's your choice, live with it. I don't see any sense on applying this patch, since it will not reduce code size or increase execution time. Code size and execution time are not the only factors to take into account. Code readability and compilation time are two other ones that I mentioned already. Anyway, it doesn't look like you actually read what I wrote in the first place. My comment about common driver code was really only by the way. The reason why I have been proposing this patch is that I2C_DEVNAME and i2c_clientname were only needed between Linux 2.5.68 and 2.6.0-test3, which are unsupported by now, as they were development releases. As far as i2c_client.name is concerned, 2.4 and 2.6.0+ trees are compatible. Thanks, -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
On Wed, 2005-08-24 at 21:49 +0200, Roman Zippel wrote: On Wed, 24 Aug 2005, john stultz wrote: from your example: // at init: system_update = update_cycles * mult; system_time += system_update; and: error = system_time - (xtime.tv_nsec shift); This doesn't seem to make sense with the above. Could you clarify? The example here doesn't keep the complete system time, just enough to compute the difference. Hey Roman, Ok, well, I'm still at a loss for understanding how this avoids my concern about time inconsistencies. However, I don't want to burn any more of your patience explaining it, so in the hopes making some productive outcome, I'm going to take a step back, pull the most trivial and uncontroversial cleanups and fixes in my patches and try to send them to Andrew one by one. Hopefully that will give me a chance to spend some time and understand your suggestions (or maybe allow someone else to express your suggestions differently) and think of alternate solutions without feeling like I'm constantly running into walls. Again, I really do appreciate the time you've spent giving me feedback. thanks -john - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
john stultz wrote: On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote: Roman Zippel wrote: Hi, On Tue, 23 Aug 2005, john stultz wrote: I'm assuming gettimeofday()/clock_gettime() looks something like: xtime + (get_cycles()-last_update)*(mult+ntp_adj)shift Where did you get the ntp_adj from? It's not in my example. gettimeofday() was in the previous mail: xtime + (cycle_offset * mult + error) shift. The difference between system time and reference time is really important. gettimeofday() returns the system time, NTP controls the reference time and these two are synchronized regularly. I didn't see that anywhere in your example. If I read your example right, the problem is when the NTP adjustment changes while the two clocks are out of sync (because of a late tick). Not quite. The issue that I'm trying to describe is that if, we inconsistently calculate time intervals in gettimeofday and the timer interrupt, we have the possibility for time inconsistencies. The trivial example using the current code would be something like: Again with my 2 cyc per tick clock, HZ=1000. gettimeofday(): xtime + offset_ns timer_interrupt: xtime += tick_length + ntp_adj offset_ns = 0 0: gettimeofday: 0 + 0 = 0 ns 1: gettimeofday: 0 + 500k ns = 500k ns 2: gettimeofday: 0 + 1M ns = 1M ns 2: timer_interrupt: 2: gettimeofday: 1M ns + 0 ns = 1M ns 3: gettimeofday: 1M ns + 500k ns = 1.5M ns 4: gettimeofday: 1M ns + 1M ns = 2 ns 4: timer_interrupt (using -500ppm adjustment) 4: gettimeofday: 1,999,500 ns + 0 ns = 1,999,500 ns At point 4 you are introducing a NEW ntp adjustment. This, I submit, needs to actually have been introduced to the system prior to the interrupt at point 2 with the first xtime change at point 4. However, gettimeofday() should be aware of it from the interrupt at point 2 and be doing corrections from that time forward. Thus when the point 4 interrutp happens xtime will be the same at the gettimeofday a ns earlier. Likewise, gettimeofday() needs to know when to stop apply the correction so that if a tick is late, it will apply the correction only for those times that it was needed. This, could be done by figuring the offset thusly: offset = (offset from last tick to end of ntp period * ntp_adj1) + (offset from end of ntp period to now) I suppose it is possible that the latter part of the offset is also under a different ntp correction which would mean a * ntp_adj2 is needed. I would argue that only two terms are needed here regardless of how late a tick is. This is because, I would expect the ntp system call to sync the two clocks. This means in your example, the ntp call would have been made at, or prior to the timer interrupt at 2 and this is the same edge that gettimeofday is to used to start applying the correction. It would appear that gettimeofday would need to know that the NTP adjustment is changing (and to what). It would also appear that this is known by the ntp code and could be made available to gettimeofday. If it is changing due to an NTP call, that system call, itself, should/must force synchronization. So the only case gettimeofday needs to worry/know about is that an adjustment is to change at time X to value Y. Also, me thinks there is only one such change that can be present at any given time. Well, in many arches gettimeofday() works around the above issue by capping the offset_ns value as such: I think this may have been done with only usec gettimeofday. Now that we have clock_gettime() returning nsec, we need to be a bit more careful. gettimeofday: xtime + min(offset_ns, tick_len + ntp_adj) The problem with this is that when we have lost or late ticks, or if we are using dynamic ticks you have granularity problems. -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kgdbwait in 2.6.13-rc4-mm1?
Wilkerson, Bryan P wrote: Is there an equivalent kernel boot option for kgdbwait in 2.6.13-rc4-mm1? I grep'd the kernel source but didn't find kgdbwait. Is there any documentation other than the source for the flavor of KGDB that is included in the akpm kernel patch? The patch has some documentation at Documentation/i386/kgdb/* as well as a couple of gdb macros... The wait option is gdb. This has been in flux so, to be absolutely sure, look at include/asm-i386/bugs.h -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] fix minor bug in sungem.h
This changes the Sun Gem Ether driver's tx ring buffer length to the proper constant. Currently TX_RING_SIZE and RX_RING_SIZE are equal, so no malfunction occurs. Signed-off-by: Geoff Levand [EMAIL PROTECTED] --- a/drivers/net/sungem.h 2005-08-19 14:35:50.0 -0700 +++ b/drivers/net/sungem.h 2005-08-24 17:14:18.0 -0700 @@ -1020,7 +1020,7 @@ struct gem_init_block *init_block; struct sk_buff *rx_skbs[RX_RING_SIZE]; - struct sk_buff *tx_skbs[RX_RING_SIZE]; + struct sk_buff *tx_skbs[TX_RING_SIZE]; dma_addr_t gblock_dvma; struct pci_dev *pdev; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Incorrect CLOCK_TICK_RATE in 2.6 kernel
CLOCK_TICK_RATE is used by the kernel to compute LATCH, TICK_NSEC and tick_nsec. This latter is used to update xtime each tick. TICK_NSEC is then used to compute (at compile time) the conversion constants needed to convert to/from jiffies from/to timespec and timeval (and others). The problem is that, if the timer being used is either Cyclone or HPET, the wrong CLOCK_TICK_RATE is used. This means that systems using these interrupt sources will be doing a) incorrect update of xtime and b) incorrect conversion of jiffies. Since these two values will track each other this will not be seen by simple gettimeofday(); sleep();gettimeofday() tests, but will be seen as a system clock drift (without NTP) or with NTP, a somewhat high drift rate (to the point of loosing sync at HZ=1000). The fact that the user/ system chooses the clock to use at boot time and can change the clock after boot means that it is not possible to pin down CLOCK_TICK_RATE at compile time. However, since the computation of TICK_NSEC and the conversion constants is rather involved it is clear that we REALLY do want to compute these at compile time. The suggested solution is to a) set up a structure with the default (clock of choice at config time) conversion constants in it at compile time. Then b) at clock init time, populate the structure with the proper constants for the given clock. These can be computed at compile time, but from the correct CLOCK_TICK_RATE for the given clock. Switching to a fall back clock would also require an update of this structure. Commits? -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Incorrect CLOCK_TICK_RATE in 2.6 kernel
On Wed, 2005-08-24 at 17:24 -0700, George Anzinger wrote: CLOCK_TICK_RATE is used by the kernel to compute LATCH, TICK_NSEC and tick_nsec. This latter is used to update xtime each tick. TICK_NSEC is then used to compute (at compile time) the conversion constants needed to convert to/from jiffies from/to timespec and timeval (and others). The problem is that, if the timer being used is either Cyclone or HPET, the wrong CLOCK_TICK_RATE is used. Err, the Cyclone does not generate interrupts. So this issue does not affect those systems. As for the HPET, it sets its own interrupt frequency based off of KERNEL_TICK_USEC (which you're right, isn't quite what is used in the jiffies conversions). Would it be easier to just adjust that value to use ACTHZ or CLOCK_TICK_RATE? thanks -john - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
On Wed, 2005-08-24 at 16:46 -0700, George Anzinger wrote: john stultz wrote: On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote: Roman Zippel wrote: Hi, On Tue, 23 Aug 2005, john stultz wrote: I'm assuming gettimeofday()/clock_gettime() looks something like: xtime + (get_cycles()-last_update)*(mult+ntp_adj)shift Where did you get the ntp_adj from? It's not in my example. gettimeofday() was in the previous mail: xtime + (cycle_offset * mult + error) shift. The difference between system time and reference time is really important. gettimeofday() returns the system time, NTP controls the reference time and these two are synchronized regularly. I didn't see that anywhere in your example. If I read your example right, the problem is when the NTP adjustment changes while the two clocks are out of sync (because of a late tick). Not quite. The issue that I'm trying to describe is that if, we inconsistently calculate time intervals in gettimeofday and the timer interrupt, we have the possibility for time inconsistencies. The trivial example using the current code would be something like: Again with my 2 cyc per tick clock, HZ=1000. gettimeofday(): xtime + offset_ns timer_interrupt: xtime += tick_length + ntp_adj offset_ns = 0 0: gettimeofday: 0 + 0 = 0 ns 1: gettimeofday: 0 + 500k ns = 500k ns 2: gettimeofday: 0 + 1M ns = 1M ns 2: timer_interrupt: 2: gettimeofday: 1M ns + 0 ns = 1M ns 3: gettimeofday: 1M ns + 500k ns = 1.5M ns 4: gettimeofday: 1M ns + 1M ns = 2 ns 4: timer_interrupt (using -500ppm adjustment) 4: gettimeofday: 1,999,500 ns + 0 ns = 1,999,500 ns At point 4 you are introducing a NEW ntp adjustment. This, I submit, needs to actually have been introduced to the system prior to the interrupt at point 2 with the first xtime change at point 4. However, gettimeofday() should be aware of it from the interrupt at point 2 and be doing corrections from that time forward. Thus when the point 4 interrutp happens xtime will be the same at the gettimeofday a ns earlier. Yes, clearly a forward knowledge of the NTP adjustment is necessary for gettimeofday(), because after the NTP adjustment has been accumulated into xtime, there's nothing left for gettimeofday to adjust (its already been applied). :) Likewise, gettimeofday() needs to know when to stop apply the correction so that if a tick is late, it will apply the correction only for those times that it was needed. This, could be done by figuring the offset thusly: offset = (offset from last tick to end of ntp period * ntp_adj1) + (offset from end of ntp period to now) Well, in my example, the ntp_adjustment is a fixed nanosecond offset, so it would be added to the nanosecond offset from the last tick (which is how the current code works). If you are doing scaling (as you have in the equation above), then the problem goes away, since you can apply the adjustment consistently through any interval. I suppose it is possible that the latter part of the offset is also under a different ntp correction which would mean a * ntp_adj2 is needed. Ok, so your forcing gettimeofday to be interval aware, so its applying different fixed NTP adjustments to different chunks of the current interval. The issue of course is if you're using fixed adjustments, is that you have to have n ntp adjustments for n intervals, or you have to apply the same ntp adjustment to multiple intervals. I would argue that only two terms are needed here regardless of how late a tick is. This is because, I would expect the ntp system call to sync the two clocks. This means in your example, the ntp call would have been made at, or prior to the timer interrupt at 2 and this is the same edge that gettimeofday is to used to start applying the correction. If you argue that we only need two adjustments, why not argue for only one? You're saying have one adjustment that you apply for the first tick's worth of time, and a second adjustment that you apply for the following N ticks' worth of time in the interval. Why the odd base case? It would appear that gettimeofday would need to know that the NTP adjustment is changing (and to what). It would also appear that this is known by the ntp code and could be made available to gettimeofday. If it is changing due to an NTP call, that system call, itself, should/must force synchronization. So the only case gettimeofday needs to worry/know about is that an adjustment is to change at time X to value Y. Also, me thinks there is only one such change that can be present at any given time. Well, in many arches gettimeofday() works around the above issue by capping the offset_ns value as such: I think this may have been done with only usec gettimeofday. Now that we have clock_gettime() returning nsec, we need to be a bit more careful. Indeed.
Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
Hi, On Wed, 24 Aug 2005, john stultz wrote: Ok, well, I'm still at a loss for understanding how this avoids my concern about time inconsistencies. Let's take a simple example to demonstrate the difference between system time and reference time. NTP tells us to update the reference time by 1000 units every tick and a single tick consists of 123 cycles, so the initial multiplier is 8. This means after 1 tick the system time is 984 and off by -16: time (ticks)reference time system time multerror 0 0 0 8 0 1 1000984 8 -16 2 200019688 -32 3 300029528 -48 4 400039369 -64 the error is now big enough, so we speed up system time: 5 500050439 43 6 600061508 150 and slow it down again: 7 700071348 134 8 800081188 118 9 900091028 102 10 1 10086 8 86 11 11000 11070 8 70 12 12000 12054 8 54 13 13000 13038 8 38 14 14000 14022 8 22 15 15000 15006 8 6 16 16000 15990 8 -10 17 17000 16974 8 -26 18 18000 17958 8 -42 19 19000 18942 8 -58 20 2 19926 8 -74 let's assume we're late with the update by 10 cycles (gettimeofday=19926+10*8=20006), so a change to the mult also requires a adjustment of the system time: 20+10 2 19916 9 -84 so gettimeofday=19916+10*9=20006 21 21000 21023 9 23 22 22000 22130 8 130 now add a single adjustment of 500 to the reference time: 23 23500 23114 11 -386 24 24500 24467 8 -33 A detail which is missing now in my example code is that we actually should look ahead to the next update, so that multiplier is immediately adjusted and the error above would never exceed 123/2 unless an update is delayed. It's really not that difficult :), it's just important to understand the difference between reference time and system time. All the NTP adjustments are done to the reference time and we manipulate the speed of the system clock to keep it close. The latter has _nothing_ to do with NTP so I don't want to see anything called like ntp_adj there. bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] VFS: update documentation (take #2)
Hi,
This is my second go at giving you my comments. The first time the email
got lost due to a connection crash. )-: Anyway, its great to see this
updated!
On Wed, 24 Aug 2005, Pekka Enberg wrote:
This patch brings the now out-of-date Documentation/filesystems/vfs.txt back
to life. Thanks to Carsten Otte for the description on get_xip_page().
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
---
vfs.txt | 382
1 file changed, 291 insertions(+), 91 deletions(-)
Index: 2.6-mm/Documentation/filesystems/vfs.txt
===
--- 2.6-mm.orig/Documentation/filesystems/vfs.txt
+++ 2.6-mm/Documentation/filesystems/vfs.txt
@@ -1,10 +1,9 @@
-/* -*- auto-fill -*-
*/
Overview of the Virtual File System
- Richard Gooch [EMAIL PROTECTED]
+ Original author: Richard Gooch [EMAIL PROTECTED]
- 5-JUL-1999
+ Last updated on August 24, 2005
Conventions used in this document
section
@@ -15,9 +14,6 @@ right-hand side of the section title. Ea
subsection at the right-hand side. These strings are meant to make
it easier to search through the document.
-NOTE that the master copy of this document is available online at:
-http://www.atnf.csiro.au/~rgooch/linux/docs/vfs.txt
-
What is it?
section
===
@@ -26,7 +22,7 @@ The Virtual File System (otherwise known
Switch) is the software layer in the kernel that provides the
filesystem interface to userspace programs. It also provides an
abstraction within the kernel which allows different filesystem
-implementations to co-exist.
+implementations to coexist.
A Quick Look At How It Works
section
@@ -77,7 +73,7 @@ back to userspace.
Opening a file requires another operation: allocation of a file
structure (this is the kernel-side implementation of file
-descriptors). The freshly allocated file structure is initialised with
+descriptors). The freshly allocated file structure is initialized with
a pointer to the dentry and a set of file operation member functions.
These are taken from the inode data. The open() file method is then
called so the specific filesystem implementation can do it's work. You
@@ -126,14 +122,18 @@ It's now time to look at things in more
struct file_system_type
section
===
-This describes the filesystem. As of kernel 2.1.99, the following
+This describes the filesystem. As of kernel 2.6.13, the following
members are defined:
struct file_system_type {
const char *name;
int fs_flags;
- struct super_block *(*read_super) (struct super_block *, void *, int);
- struct file_system_type * next;
+struct super_block *(*get_sb) (struct file_system_type *, int,
+ const char *, void *);
+void (*kill_sb) (struct super_block *);
+struct module *owner;
+struct file_system_type * next;
+struct list_head fs_supers;
};
name: the name of the filesystem type, such as ext2, iso9660,
@@ -141,51 +141,96 @@ struct file_system_type {
fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.)
- read_super: the method to call when a new instance of this
+ get_sb: the method to call when a new instance of this
filesystem should be mounted
- next: for internal VFS use: you should initialise this to NULL
+ kill_sb: the method to call when an instance of this filesystem
+ should be unmounted
+
+ owner: for internal VFS use: you should initialize this to NULL
-The read_super() method has the following arguments:
+ next: for internal VFS use: you should initialize this to NULL
+
+The get_sb() method has the following arguments:
struct super_block *sb: the superblock structure. This is partially
- initialised by the VFS and the rest must be initialised by the
- read_super() method
+ initialized by the VFS and the rest must be initialized by the
+ get_sb() method
+
+ int flags: mount flags
+
+ const char *dev_name: the device name we are mounting.
void *data: arbitrary mount options, usually comes as an ASCII
string
int silent: whether or not to be silent on error
-The read_super() method must determine if the block device specified
+The get_sb() method must determine if the block device specified
in the superblock contains a filesystem of the type the method
supports. On success the method returns the superblock pointer, on
failure it returns NULL.
The most interesting member of the superblock
[PATCH] Ext3 online resizing locking issue
This simple patch provides a fix for a locking issue found in the online
resizing code. The problem actually happened while trying to resize the
filesystem trough the resize=xxx option in a remount.
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
diff -up linux-2.6.13-rc6-orig/fs/ext3/ioctl.c linux/fs/ext3/ioctl.c
--- linux-2.6.13-rc6-orig/fs/ext3/ioctl.c 2005-08-24 17:48:22.0
-0300
+++ linux/fs/ext3/ioctl.c 2005-08-24 15:12:48.0 -0300
@@ -206,7 +206,9 @@ flags_err:
if (get_user(n_blocks_count, (__u32 __user *)arg))
return -EFAULT;
+ lock_super(sb);
err = ext3_group_extend(sb, EXT3_SB(sb)-s_es, n_blocks_count);
+ unlock_super(sb);
journal_lock_updates(EXT3_SB(sb)-s_journal);
journal_flush(EXT3_SB(sb)-s_journal);
journal_unlock_updates(EXT3_SB(sb)-s_journal);
Only in linux/fs/ext3: patch-mnt_resize
diff -up linux-2.6.13-rc6-orig/fs/ext3/resize.c linux/fs/ext3/resize.c
--- linux-2.6.13-rc6-orig/fs/ext3/resize.c 2005-08-24 17:48:22.0
-0300
+++ linux/fs/ext3/resize.c 2005-08-24 15:15:28.0 -0300
@@ -884,7 +884,9 @@ exit_put:
/* Extend the filesystem to the new number of blocks specified. This entry
* point is only used to extend the current filesystem to the end of the last
* existing group. It can be accessed via ioctl, or by remount,resize=size
- * for emergencies (because it has no dependencies on reserved blocks).
+ * for emergencies (because it has no dependencies on reserved blocks).
+ *
+ * It should be called with sb-s_lock held
*
* If we _really_ wanted, we could use default values to call ext3_group_add()
* allow the remount trick to work for arbitrary resizing, assuming enough
@@ -959,7 +961,6 @@ int ext3_group_extend(struct super_block
goto exit_put;
}
- lock_super(sb);
if (o_blocks_count != le32_to_cpu(es-s_blocks_count)) {
ext3_warning(sb, __FUNCTION__,
multiple resizers run on filesystem!\n);
@@ -978,7 +979,6 @@ int ext3_group_extend(struct super_block
es-s_blocks_count = cpu_to_le32(o_blocks_count + add);
ext3_journal_dirty_metadata(handle, EXT3_SB(sb)-s_sbh);
sb-s_dirt = 1;
- unlock_super(sb);
ext3_debug(freeing blocks %ld through %ld\n, o_blocks_count,
o_blocks_count + add);
ext3_free_blocks_sb(handle, sb, o_blocks_count, add, freed_blocks);
diff -up linux-2.6.13-rc6-orig/fs/ext3/super.c linux/fs/ext3/super.c
--- linux-2.6.13-rc6-orig/fs/ext3/super.c 2005-08-24 17:48:22.0
-0300
+++ linux/fs/ext3/super.c 2005-08-24 15:13:16.0 -0300
@@ -639,8 +639,8 @@ static match_table_t tokens = {
{Opt_quota, quota},
{Opt_quota, usrquota},
{Opt_barrier, barrier=%u},
+ {Opt_resize, resize=%u},
{Opt_err, NULL},
- {Opt_resize, resize},
};
static unsigned long get_sb_block(void **data)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Incorrect CLOCK_TICK_RATE in 2.6 kernel
john stultz wrote: On Wed, 2005-08-24 at 17:24 -0700, George Anzinger wrote: CLOCK_TICK_RATE is used by the kernel to compute LATCH, TICK_NSEC and tick_nsec. This latter is used to update xtime each tick. TICK_NSEC is then used to compute (at compile time) the conversion constants needed to convert to/from jiffies from/to timespec and timeval (and others). The problem is that, if the timer being used is either Cyclone or HPET, the wrong CLOCK_TICK_RATE is used. Err, the Cyclone does not generate interrupts. So this issue does not affect those systems. As for the HPET, it sets its own interrupt frequency based off of KERNEL_TICK_USEC (which you're right, isn't quite what is used in the jiffies conversions). Would it be easier to just adjust that value to use ACTHZ or CLOCK_TICK_RATE? If you want to take that approach you would want the HPET to interrupt every TICK_NSEC nanoseconds, that being what xtime is pushed by each tick. -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 - 0/9] Generic timekeeping subsystem (v. B5)
On Wed, 2005-08-24 at 18:44 -0700, George Anzinger wrote: Ok, so your forcing gettimeofday to be interval aware, so its applying different fixed NTP adjustments to different chunks of the current interval. The issue of course is if you're using fixed adjustments, is that you have to have n ntp adjustments for n intervals, or you have to apply the same ntp adjustment to multiple intervals. Uh, are you saying that one ntpd call can set up several different adjustments? Well, it allows for frequency adjustments, tick adjustments, and offset adjustments in a single call or just the singleshot (adjtime) adjustment. However it does not give multiple scaling factors for different intervals, so you are correct there. I was assuming that any given call would set up either a fixed adjustment for ever or a fixed adjustment to be applied for a fixed number of ticks (or until so much correcting was done, which, in the end is the same thing at this point in the code). If ntpd has to come back to change the adjustment, I am assuming that some kernel action can be taken at that time to sync the xtime clock and the gettimeofday reading of it. I.e. we would only have to keep track of one adjustment with a possible pre specified end time. Well, I guess a component of the adjustment would end at a specified time, that's true. I would argue that only two terms are needed here regardless of how late a tick is. This is because, I would expect the ntp system call to sync the two clocks. This means in your example, the ntp call would have been made at, or prior to the timer interrupt at 2 and this is the same edge that gettimeofday is to used to start applying the correction. If you argue that we only need two adjustments, why not argue for only one? You're saying have one adjustment that you apply for the first tick's worth of time, and a second adjustment that you apply for the following N ticks' worth of time in the interval. Why the odd base case? Correct me if I am wrong here, but I am assuming that ntpd can ask for an adjustment of X amount which the kernel changes into N adjustments of X/N amount spread over the next N ticks. No, sorry, you are correct there, I was confusing things. It may work, and I had considered a similar idea when developing my solution, but it seemed far too ugly and complicated. But that could have just been my fault. :) thanks -john - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] NTP ntp-helper functions
Andrew, All,
This patch cleans up a commonly repeated set of changes to the NTP
state variables by adding two helper inline functions:
ntp_clear(): Clears the ntp state variables
ntp_synced(): Returns 1 if the system is synced with a time server.
This was compile tested for alpha, arm, i386, x86-64, ppc64, s390,
sparc, sparc64.
Please consider for inclusion into your tree.
thanks
-john
Signed-off-by: John Stultz [EMAIL PROTECTED]
linux-2.6.13-rc7_ntp-helpers_A0.patch
=
diff --git a/arch/alpha/kernel/time.c b/arch/alpha/kernel/time.c
--- a/arch/alpha/kernel/time.c
+++ b/arch/alpha/kernel/time.c
@@ -149,7 +149,7 @@ irqreturn_t timer_interrupt(int irq, voi
* CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be
* called as close as possible to 500 ms before the new second starts.
*/
- if ((time_status STA_UNSYNC) == 0
+ if (ntp_synced()
xtime.tv_sec state.last_rtc_update + 660
xtime.tv_nsec = 50 - ((unsigned) TICK_SIZE) / 2
xtime.tv_nsec = 50 + ((unsigned) TICK_SIZE) / 2) {
@@ -502,10 +502,7 @@ do_settimeofday(struct timespec *tv)
set_normalized_timespec(xtime, sec, nsec);
set_normalized_timespec(wall_to_monotonic, wtm_sec, wtm_nsec);
- time_adjust = 0;/* stop active adjtime() */
- time_status |= STA_UNSYNC;
- time_maxerror = NTP_PHASE_LIMIT;
- time_esterror = NTP_PHASE_LIMIT;
+ ntp_clear();
write_sequnlock_irq(xtime_lock);
clock_was_set();
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -102,7 +102,7 @@ static unsigned long next_rtc_update;
*/
static inline void do_set_rtc(void)
{
- if (time_status STA_UNSYNC || set_rtc == NULL)
+ if (!ntp_synced() || set_rtc == NULL)
return;
if (next_rtc_update
@@ -292,10 +292,7 @@ int do_settimeofday(struct timespec *tv)
set_normalized_timespec(xtime, sec, nsec);
set_normalized_timespec(wall_to_monotonic, wtm_sec, wtm_nsec);
- time_adjust = 0;/* stop active adjtime() */
- time_status |= STA_UNSYNC;
- time_maxerror = NTP_PHASE_LIMIT;
- time_esterror = NTP_PHASE_LIMIT;
+ ntp_clear();
write_sequnlock_irq(xtime_lock);
clock_was_set();
return 0;
diff --git a/arch/arm26/kernel/time.c b/arch/arm26/kernel/time.c
--- a/arch/arm26/kernel/time.c
+++ b/arch/arm26/kernel/time.c
@@ -114,7 +114,7 @@ static unsigned long next_rtc_update;
*/
static inline void do_set_rtc(void)
{
- if (time_status STA_UNSYNC || set_rtc == NULL)
+ if (!ntp_synced() || set_rtc == NULL)
return;
//FIXME - timespec.tv_sec is a time_t not unsigned long
@@ -189,10 +189,7 @@ int do_settimeofday(struct timespec *tv)
xtime.tv_sec = tv-tv_sec;
xtime.tv_nsec = tv-tv_nsec;
- time_adjust = 0;/* stop active adjtime() */
- time_status |= STA_UNSYNC;
- time_maxerror = NTP_PHASE_LIMIT;
- time_esterror = NTP_PHASE_LIMIT;
+ ntp_clear();
write_sequnlock_irq(xtime_lock);
clock_was_set();
return 0;
diff --git a/arch/cris/arch-v10/kernel/time.c b/arch/cris/arch-v10/kernel/time.c
--- a/arch/cris/arch-v10/kernel/time.c
+++ b/arch/cris/arch-v10/kernel/time.c
@@ -240,7 +240,7 @@ timer_interrupt(int irq, void *dev_id, s
* The division here is not time critical since it will run once in
* 11 minutes
*/
- if ((time_status STA_UNSYNC) == 0
+ if (ntp_synced()
xtime.tv_sec last_rtc_update + 660
(xtime.tv_nsec / 1000) = 50 - (tick_nsec / 1000) / 2
(xtime.tv_nsec / 1000) = 50 + (tick_nsec / 1000) / 2) {
diff --git a/arch/cris/kernel/time.c b/arch/cris/kernel/time.c
--- a/arch/cris/kernel/time.c
+++ b/arch/cris/kernel/time.c
@@ -114,10 +114,7 @@ int do_settimeofday(struct timespec *tv)
set_normalized_timespec(xtime, sec, nsec);
set_normalized_timespec(wall_to_monotonic, wtm_sec, wtm_nsec);
- time_adjust = 0;/* stop active adjtime() */
- time_status |= STA_UNSYNC;
- time_maxerror = NTP_PHASE_LIMIT;
- time_esterror = NTP_PHASE_LIMIT;
+ ntp_clear();
write_sequnlock_irq(xtime_lock);
clock_was_set();
return 0;
diff --git a/arch/frv/kernel/time.c b/arch/frv/kernel/time.c
--- a/arch/frv/kernel/time.c
+++ b/arch/frv/kernel/time.c
@@ -85,7 +85,7 @@ static irqreturn_t timer_interrupt(int i
* CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be
* called as close as possible to 500 ms before the new second starts.
*/
- if ((time_status STA_UNSYNC) == 0
+ if (ntp_synced()
xtime.tv_sec last_rtc_update + 660
(xtime.tv_nsec / 1000) = 50 -
Re: [PATCH 2.6.13-rc6] cpu_exclusive sched domains build fix
Paul Jackson wrote: Dinakar wrote: Can we hold on to this patch for a while, as I reported yesterday, Sure - though I guess it's Linus or Andrew who will have to do the holding. I sent it off contingent on the approval of yourself, Hawkes and Nick. I get the feeling that the problem would be present in more than just misaligned nodes. On the POWER5 for example, Dinakar probably has SMT enabled, which may cause something similar to pop up. I get the feeling that exclusive cpusets should just be completely disabled for 2.6.13, and John Ingo's complete fix put in 2.6.14-early -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/15] ia64: remove use of asm/segment.h
On Wednesday 24 August 2005 10:53 am, Kumar Gala wrote: Removed IA64 architecture specific users of asm/segment.h and asm-ia64/segment.h itself I posted a similar patch a month ago, but I only removed the arch/ia64 includes of asm/segment.h. There are still a few drivers that include asm/segment.h, so I don't think we should remove asm/segment.h itself just yet. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 05/15] ia64: remove use of asm/segment.h
There are still a few drivers that include asm/segment.h, so I don't think we should remove asm/segment.h itself just yet. Agreed. The sequence should be to send patches to get rid of all #include asm/segment.h references. Once they have all gone, then a patch can remove the files. If you are concerned that people would start adding new references and you don't want to get into a game of whack-a-mole, then you could add #warning include of deprecated asm/segment.h, but that might be overkill. I'll apply this for ia64 w/o the deletion. -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 2.6.13-rc6] cpu_exclusive sched domains build fix
Nick wrote:
I get the feeling that exclusive cpusets should just be
completely disabled for 2.6.13
No no - not disable exclusive cpusets - disable using them to try
to define sched domains.
That is, I hope you mean that Dinakar's patch that uses cpu_exclusive
cpusets to define sched domains should be disabled for 2.6.13. For
what they were worth (not a whole lot, granted), cpu_exclusive cpusets
have been in the kernel since 2.6.12. They just didn't have any affect
in the placement of sched domains. So long as they continue to do not
a whole lot, I see more risk than gain in disabling them for 2.6.13.
So long as the cpuset code stops making any calls to partition_sched_domains()
whatsoever, then we should be back where we were in 2.6.12, so far as the
scheduler is concerned - right?
I hope that the following (untested, unbuilt) patch, that I suggested
in my Mon, 22 Aug 2005 13:38:23 -0700 message best meets you
suggestion above ... and I quote:
==
The safest, mind numbingly simple thing to do that would avoid the oops
that Hawkes reported is to simply not have the cpuset code call the
code to setup a dynamic sched domain. This is choice (2) above, and
could be done at the last hour with relative safety.
Here is an untested patch that does (2):
=
Index: linux-2.6.13-cpuset-mempolicy-migrate/kernel/cpuset.c
===
--- linux-2.6.13-cpuset-mempolicy-migrate.orig/kernel/cpuset.c
+++ linux-2.6.13-cpuset-mempolicy-migrate/kernel/cpuset.c
@@ -627,6 +627,15 @@ static int validate_change(const struct
* Call with cpuset_sem held. May nest a call to the
* lock_cpu_hotplug()/unlock_cpu_hotplug() pair.
*/
+
+/*
+ * Hack to avoid 2.6.13 partial node dynamic sched domain bug.
+ * Disable letting 'cpu_exclusive' cpusets define dynamic sched
+ * domains, until the sched domain can handle partial nodes.
+ * Remove this ifdef hackery when sched domains fixed.
+ */
+#define DISABLE_EXCLUSIVE_CPU_DOMAINS 1
+#ifdef DISABLE_EXCLUSIVE_CPU_DOMAINS
static void update_cpu_domains(struct cpuset *cur)
{
struct cpuset *c, *par = cur-parent;
@@ -667,6 +676,11 @@ static void update_cpu_domains(struct cp
partition_sched_domains(pspan, cspan);
unlock_cpu_hotplug();
}
+#else
+static void update_cpu_domains(struct cpuset *cur)
+{
+}
+#endif
static int update_cpumask(struct cpuset *cs, char *buf)
{
=
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson [EMAIL PROTECTED] 1.925.600.0401
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 05/15] ia64: remove use of asm/segment.h
On Aug 24, 2005, at 3:19 PM, Luck, Tony wrote: There are still a few drivers that include asm/segment.h, so I don't think we should remove asm/segment.h itself just yet. Agreed. The sequence should be to send patches to get rid of all #include asm/segment.h references. Once they have all gone, then a patch can remove the files. If you are concerned that people would start adding new references and you don't want to get into a game of whack-a-mole, then you could add #warning include of deprecated asm/segment.h, but that might be overkill. I'll apply this for ia64 w/o the deletion. I've posted a patch before this to remove all non-architecture users of asm/segment.h. http://www.ussg.iu.edu/hypermail/linux/kernel/0508.3/0099.html - kumar - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 05/15] ia64: remove use of asm/segment.h
I'll apply this for ia64 w/o the deletion. This is now in my test tree. I will send to Linus soon after 2.6.13 is released. I've posted a patch before this to remove all non-architecture users of asm/segment.h. http://www.ussg.iu.edu/hypermail/linux/kernel/0508.3/0099.html Good. After that gets I applied I will delete include/asm-ia64/segment.h -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 2.6.13-rc6] cpu_exclusive sched domains build fix
Paul Jackson wrote: So long as the cpuset code stops making any calls to partition_sched_domains() whatsoever, then we should be back where we were in 2.6.12, so far as the scheduler is concerned - right? That's right - sorry I just meant disabling the dynamic sched domains behaviour of the cpu_exclusive cpusets. I hope that the following (untested, unbuilt) patch, that I suggested in my Mon, 22 Aug 2005 13:38:23 -0700 message best meets you suggestion above ... and I quote: I apologise, I missed that patch you sent. I think it looks OK, and that it looks like what I was thinking about. We need to revert to a stable behaviour, however we can't risk major surgery to get there. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13-rc6] cpu_exclusive sched domains build fix
Nick wrote: and that it looks like what I was thinking about. Ok - I almost have my crosstool installation healthy again. I will actually see to it that my patch builds this time for whatever arch's I can test on, and send this simple disabling of sched domain mangling from cpuset-land as a real patch. I have a couple other commitments - it will be 6 to 12 hours before I send it in, unless someone asks for a half-baked version sooner. We need to revert to a stable behaviour, however we can't risk major surgery to get there. Yup. Agreed. Thanks for looking into this, Nick. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] for acpi S1 power cycle resume problems
Date: Fri, 19 Aug 2005 08:39:25 -0600 From: William Morrow [EMAIL PROTECTED] Subject: [PATCH] for acpi S1 power cycle resume problems Hi I was told that if I had a patch to submit for a baseline change that this was the place to do it. In this case that works fine. Normally they should go to linux-usb-devel for me (and others) to read there. Thanks, these need a bit of cleaning up, finishing, and splitting out; they should be in 2.6.14 though. Comments below. Were these patches written by you, or by Jordan? - Dave If not, please let me know... thanks, morrow Patched against 2.6.11 baseline problems fixed: 1) OHCI_INTR_RD not being cleared in ohci interrupt handler results in interrupt storm and system hang on RD status. ohci spec indicates this should be done. Yeah, I noticed that one but didn't fix it yet. It's not that it was _never_ cleared ... only certain code paths missed it. The systems I test with were clearly using those working paths! Having this fixed should help get rid of the 1/4 second timer this driver normally ties up. That'll help make the dynamic tick stuff work better, reducing power even when something like ACPI S1 doesn't exist (like say, on that one Zaurus). 2) PORT_CSC not being cleared in ehci_hub_status_data code attempts to clear bit, but bit is write to clear. there are other errant clears, since the PORTSCn regs have 3 RWC bits, and the rest are RW. All stmts of the form: writel (v, ehci-regs-port_status[i]) should clear RWC bits if they do not intend to clear status, and should set the bits which should be cleared (this case). Yeah, whoever did that RWC patch for UHCI ports certainly should have checked other HCDs for the same bug. (Kicks self.) In fact you didn't fix this issue comprehensively. There are other places that register is written; they need to change too. This is clearly wrong, but did you notice any effects more serious than lsusb -v output for EHCI root hubs looking a bit strange? 3) loop control and subsequent port resume/reset not correct. unsigned index made detecting port1 active impossible, Odd, I've done that with some regularity. Is that maybe some kind of compiler bug? (I heard even 4.1 isn't quite there yet for kernels.) The looping doesn't look incorrect to me; ports are numbered from 1..N, and C code in the body must index them from 0..(N-1). and OWNER/POWER status was being ignored on ports assigned to companion controller. Well, in that one resume case anyway! But OWNER and POWER are very different status bits ... if POWER ever goes off, that port is by definition not resumable. But if a port's owned by the companion (OHCI or UHCI) controller, then it surely ought not to be reset (even if the companion's own SUSPEND bit doesn't show through EHCI). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[KCONFIG] Can't compile 2.6.12 without Gettext
Hi,
I didn't see much informations about this.
It's not possible to make {,menu}config and even to compile a 2.6.12
kernel if there is no or partially installed Gettext on the system.
Full Gettext is *required* to launch the kbuild scripts since the
modifications to add i18n to the config scripts.
Not all system have gettext, I'm thinking about small or embedded
system with specific toolchain. For example, uClibc is widely used but
as still a partial nls support.
Anyway, this should not be required for compiling a kernel. At least
an option to pass to make which override the default behavior could
solve the issue.
Moreover, the script doesn't do any sanity check about the system
(there is no configure script of course) and just try to catch the
gettext binaries he founds first. There is a hard-coded filename too.
Seems dangerous to me and should not be allowed by default.
Am I misleading ?
--
Jerome Pinot
ftp://ngc891.blogdns.net/pub
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Initramfs and TMPFS!
It uses 50% of total memory for tmpfs, but it would be nice to have an option (tmpfs_size=90% etc.) that you could pass to the kernel. that's just because of the tmpfs default; you can remount to change that if it's not suitable once your up and running in your init-scripts or whatever Right, but it would be nice to have that option if initramfs using tmpfs becomes part of the kernel. You need to add this to init/main.c for it to compile. #include asm/uaccess.h hmm... really? i'll rediff it at some point and test it maybe. i really don't like the explicity shm init though, i'd like to think of a cleaner way to do that You get this error without it. init/main.c: In function `overmount_rootfs': init/main.c:663: warning: implicit declaration of function `get_fs' init/main.c:663: error: incompatible types in assignment init/main.c:664: warning: implicit declaration of function `set_fs' init/main.c:664: error: `KERNEL_DS' undeclared (first use in this function) init/main.c:664: error: (Each undeclared identifier is reported only once init/main.c:664: error: for each function it appears in.) make[1]: *** [init/main.o] Error 1 make: *** [init] Error 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/
Initramfs and TMPFS!
Also, tar should be an option instead of cpio for the archiver, because tar is more widely used. pretty much everyone will have cpio and it's format is much simpler/cleaner to deal with if we want vastly more complex early-userspace semantics i think we need to carefully decide what is needed and how to put as much of that logic into userspace rather than hacking this much more in the kernel for fear of breaking things in subtle ways I don't know, because tar is probably more widely used and consequently people are more familiar with how to use it. But, that is not as important as having the option of using tmpfs as the initramfs. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] LSM hook updates
On Wed, 24 Aug 2005, Chris Wright wrote: This is based on Kurt's original work. The net effect is that LSM hooks are called conditionally, and in all cases capabilities provide the defaults. I've done some basic performance testing, and found nothing surprising. Do you mean nothing noticable? I'm interested to see numbers from others before I push this up. These are against Linus' current git tree (they will clash with the -mm tree). Are there any numbers for popular architectures like i386 and x86_64? - James -- James Morris [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: kernel
Could anyone inform which will be a good guide to start learning the linux kernel programming. -- Shwetha V Software Engineer - Networks Business Unit Sasken Communication Technologies Ltd. Gold Hill Square, Hosur Road, Bangalore. Ph: +91-80-25355501 Ext: 5799 Web: www.sasken.com Srinivas K [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] hi friends, post concepts regarding linux kernel which will be useful -- Srinivasa Rao K Systems Engineer Nortel Business Unit Sasken Communication Technologies Ltd 139/25, Ring Road, Domlur Bangalore - 560 071 Ph: 2535 5501 Extn.:4804 mail : [EMAIL PROTECTED] SASKEN RATED THE BEST EMPLOYER IN THE COUNTRY by the BUSINESS TODAY Mercer Survey 2004 SASKEN BUSINESS DISCLAIMER This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email SASKEN RATED THE BEST EMPLOYER IN THE COUNTRY by the BUSINESS TODAY Mercer Survey 2004 SASKEN BUSINESS DISCLAIMER This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 3/3] exterminate strtok - usr/gen_init_cpio.c
Horst wrote:
- if ('\n' == *type) {
+ if (!*type || '\n' == *type) {
Redundant. If *type == '\n', it is certainly != 0.
No - I don't think redundant, at least not this change in isolation.
Perhaps redundant in light of subsequent code lines, as Jesper notes in
his followup.
But it is confusing to read - poor and inconsistent choice of code
phrasing.
If the patch had read as:
- if (*type == '\n') {
+ if (*type == '\n' || *type == '\0') {
then it would be clearer to the reader in my view. A check for newline
is changed to a check for newline or nul-byte.
(Yes - I recognize that one is not given the freedom to change the
-old- lines in a patch for the sake of clarity ;).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson [EMAIL PROTECTED] 1.925.600.0401
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] cache pollution aware __copy_from_user_ll()
From: Hirokazu Takahashi [EMAIL PROTECTED] The following patch does not use MMX regsiters so that we don't have to worry about save/restore the FPU/MMX states. What do you think? I think __copy_user_zeroing_intel_nocache() should be followed by sfence or mfence instruction to flush the data. Thanks. I'll implement it. Regards, Hiro - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 3/3] exterminate strtok - usr/gen_init_cpio.c
On Wed, Aug 24, 2005 at 09:08:53PM +0200, Jesper Juhl wrote: Convert strtok() use to strsep() in usr/gen_init_cpio.c I've compile tested this patch and it compiles fine. I build a 2.6.13-rc6-mm2 kernel with the patch applied without problems, and the resulting kernel boots and runs just fine (using it right now). But despite this basic testing it would still be nice if someone would double-check that I haven't made some silly mistake that would break some other setup than mine. This is userland - I see no point in uglyfying the code. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()
From: Andi Kleen [EMAIL PROTECTED] Hi, The following patch does not use MMX regsiters so that we don't have to worry about save/restore the FPU/MMX states. What do you think? Performance will probably be bad on K7 Athlons - those have a microcoded movnti which is quite slow. Also BTW I don't see any code anywhere that tests the CPUID bits, so your code will fail spectacularly on a PII that didn't do SSE (intel user copy used to be enabled on those) One way to solve this might be to use different code using alternative() -Andi Thanks for your comments. I'll consider it. Regards, Hiro - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/22) bogus function argument types (sun3_pgtable.h)
function arguments can not be inline, TYVM...
Signed-off-by: Al Viro [EMAIL PROTECTED]
diff -urN RC13-rc7-sun3ints/include/asm-m68k/sun3_pgtable.h
RC13-rc7-sun3_pgtable/include/asm-m68k/sun3_pgtable.h
--- RC13-rc7-sun3ints/include/asm-m68k/sun3_pgtable.h 2005-06-17
15:48:29.0 -0400
+++ RC13-rc7-sun3_pgtable/include/asm-m68k/sun3_pgtable.h 2005-08-25
00:54:07.0 -0400
@@ -211,7 +211,7 @@
return pte.pte SUN3_PAGE_PGNUM_MASK;
}
-static inline pte_t pgoff_to_pte(inline unsigned off)
+static inline pte_t pgoff_to_pte(unsigned off)
{
pte_t pte = { off + SUN3_PAGE_ACCESSED };
return pte;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] (5/22) static vs. extern in amigaints.h
extern declaration of static object removed from header Signed-off-by: Al Viro [EMAIL PROTECTED] diff -urN RC13-rc7-sun3_pgtable/include/asm-m68k/amigaints.h RC13-rc7-amigaints/include/asm-m68k/amigaints.h --- RC13-rc7-sun3_pgtable/include/asm-m68k/amigaints.h 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-amigaints/include/asm-m68k/amigaints.h 2005-08-25 00:54:07.0 -0400 @@ -109,8 +109,6 @@ extern void amiga_do_irq(int irq, struct pt_regs *fp); extern void amiga_do_irq_list(int irq, struct pt_regs *fp); -extern unsigned short amiga_intena_vals[]; - /* CIA interrupt control register bits */ #define CIA_ICR_TA 0x01 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/22) compile fixes for dmsound (static vs. extern)
sound/oss/dmasound/dmasound_atari.c has static expand_bal sound/oss/dmasound/dmasound_q40.c has static expand_bal sound/oss/dmasound/dmasound_awacs.c has non-static expand_bal sound/oss/dmasound/trans_16.c uses expand_bal from dmasound_awacs.c all 4 include dmasound.h; extern for expand_bal used to be there, which is a bloody bad idea, considering _atari and _q40. Moved the extern to trans_16.c. Signed-off-by: Al Viro [EMAIL PROTECTED] diff -urN RC13-rc7-dmasound-lvalues/sound/oss/dmasound/dmasound.h RC13-rc7-dmasound-extern/sound/oss/dmasound/dmasound.h --- RC13-rc7-dmasound-lvalues/sound/oss/dmasound/dmasound.h 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-dmasound-extern/sound/oss/dmasound/dmasound.h 2005-08-25 00:54:05.0 -0400 @@ -270,7 +270,6 @@ #define SW_INPUT_VOLUME_SCALE 4 #define SW_INPUT_VOLUME_DEFAULT(128 / SW_INPUT_VOLUME_SCALE) -extern int expand_bal; /* Balance factor for expanding (not volume!) */ extern int expand_read_bal;/* Balance factor for reading */ extern uint software_input_volume; /* software implemented recording volume! */ diff -urN RC13-rc7-dmasound-lvalues/sound/oss/dmasound/trans_16.c RC13-rc7-dmasound-extern/sound/oss/dmasound/trans_16.c --- RC13-rc7-dmasound-lvalues/sound/oss/dmasound/trans_16.c 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-dmasound-extern/sound/oss/dmasound/trans_16.c 2005-08-25 00:54:05.0 -0400 @@ -17,6 +17,7 @@ #include asm/uaccess.h #include dmasound.h +extern int expand_bal; /* Balance factor for expanding (not volume!) */ static short dmasound_alaw2dma16[] ; static short dmasound_ulaw2dma16[] ; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/22) lvalues abuse in dmasound
result of typecast is not an lvalue. Part of those are fixed in m68k
CVS.
Signed-off-by: Al Viro [EMAIL PROTECTED]
diff -urN RC13-rc7/sound/oss/dmasound/dmasound_atari.c
RC13-rc7-dmasound-lvalues/sound/oss/dmasound/dmasound_atari.c
--- RC13-rc7/sound/oss/dmasound/dmasound_atari.c2005-06-17
15:48:29.0 -0400
+++ RC13-rc7-dmasound-lvalues/sound/oss/dmasound/dmasound_atari.c
2005-08-25 00:54:04.0 -0400
@@ -217,8 +217,9 @@
used = count*2;
while (count 0) {
u_short data;
- if (get_user(data, ((u_short *)userPtr)++))
+ if (get_user(data, (u_short *)userPtr))
return -EFAULT;
+ userPtr += 2;
*p++ = data ^ 0x8080;
count--;
}
@@ -240,8 +241,9 @@
used = count*2;
while (count 0) {
u_short data;
- if (get_user(data, ((u_short *)userPtr)++))
+ if (get_user(data, (u_short *)userPtr))
return -EFAULT;
+ userPtr += 2;
*p++ = data;
*p++ = data;
count--;
@@ -271,8 +273,9 @@
used = count*2;
while (count 0) {
u_short data;
- if (get_user(data, ((u_short *)userPtr)++))
+ if (get_user(data, (u_short *)userPtr))
return -EFAULT;
+ userPtr += 2;
data ^= 0x8000;
*p++ = data;
*p++ = data;
@@ -285,8 +288,9 @@
used = count*4;
while (count 0) {
u_long data;
- if (get_user(data, ((u_int *)userPtr)++))
+ if (get_user(data, (u_int *)userPtr))
return -EFAULT;
+ userPtr += 4;
*p++ = data ^ 0x80008000;
count--;
}
@@ -309,8 +313,9 @@
used = count*2;
while (count 0) {
u_short data;
- if (get_user(data, ((u_short *)userPtr)++))
+ if (get_user(data, (u_short *)userPtr))
return -EFAULT;
+ userPtr += 2;
data = le2be16(data);
*p++ = data;
*p++ = data;
@@ -323,8 +328,9 @@
used = count*4;
while (count 0) {
u_long data;
- if (get_user(data, ((u_int *)userPtr)++))
+ if (get_user(data, (u_int *)userPtr))
return -EFAULT;
+ userPtr += 4;
data = le2be16dbl(data);
*p++ = data;
count--;
@@ -348,8 +354,9 @@
used = count*2;
while (count 0) {
u_short data;
- if (get_user(data, ((u_short *)userPtr)++))
+ if (get_user(data, (u_short *)userPtr))
return -EFAULT;
+ userPtr += 2;
data = le2be16(data) ^ 0x8000;
*p++ = data;
*p++ = data;
@@ -361,8 +368,9 @@
used = count;
while (count 0) {
u_long data;
- if (get_user(data, ((u_int *)userPtr)++))
+ if (get_user(data, (u_int *)userPtr))
return -EFAULT;
+ userPtr += 4;
data = le2be16dbl(data) ^ 0x80008000;
*p++ = data;
count--;
@@ -470,8 +478,9 @@
if (bal 0) {
if (userCount 2)
break;
- if (get_user(data, ((u_short *)userPtr)++))
+ if (get_user(data, (u_short *)userPtr))
return -EFAULT;
+ userPtr += 2;
userCount -= 2;
bal += hSpeed;
}
@@ -524,8 +533,9 @@
if (bal 0) {
if (userCount 2)
break;
- if (get_user(data, ((u_short *)userPtr)++))
+ if (get_user(data, (u_short *)userPtr))
return -EFAULT;
+
Re: [PATCH] (20/22) task_thread_info - part 3/4
Bah... I can't count, apparently. That one is 4/5, the next is 5/5. My apologies - cut'n'waste damage while editing patchset description.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] (18/22) task_thread_info - part 2/4
encapsulates the rest of arch-dependent operations with thread_info access.
Two new helpers - setup_thread_info() and end_of_stack(). For normal
case the former consists of copying thread_info of parent to new thread_info
and the latter returns pointer immediately past the end of thread_info.
Signed-off-by: Al Viro [EMAIL PROTECTED]
diff -urN RC13-rc7-task_thread_info/include/linux/sched.h
RC13-rc7-other-helpers/include/linux/sched.h
--- RC13-rc7-task_thread_info/include/linux/sched.h 2005-08-25
00:54:17.0 -0400
+++ RC13-rc7-other-helpers/include/linux/sched.h2005-08-25
00:54:17.0 -0400
@@ -1138,6 +1138,16 @@
#define task_thread_info(task) (task)-thread_info
+static inline void setup_thread_info(struct task_struct *p, struct thread_info
*ti)
+{
+ *ti = *p-thread_info;
+}
+
+static inline unsigned long *end_of_stack(struct task_struct *p)
+{
+ return (unsigned long *)(p-thread_info + 1);
+}
+
/* set thread flags in other task's structures
* - see asm/thread_info.h for TIF_ flags available
*/
diff -urN RC13-rc7-task_thread_info/kernel/fork.c
RC13-rc7-other-helpers/kernel/fork.c
--- RC13-rc7-task_thread_info/kernel/fork.c 2005-08-25 00:54:17.0
-0400
+++ RC13-rc7-other-helpers/kernel/fork.c2005-08-25 00:54:17.0
-0400
@@ -169,8 +169,8 @@
return NULL;
}
- *ti = *orig-thread_info;
*tsk = *orig;
+ setup_thread_info(tsk, ti);
tsk-thread_info = ti;
ti-task = tsk;
diff -urN RC13-rc7-task_thread_info/kernel/sched.c
RC13-rc7-other-helpers/kernel/sched.c
--- RC13-rc7-task_thread_info/kernel/sched.c2005-08-25 00:54:17.0
-0400
+++ RC13-rc7-other-helpers/kernel/sched.c 2005-08-25 00:54:17.0
-0400
@@ -4121,10 +4121,10 @@
#endif
#ifdef CONFIG_DEBUG_STACK_USAGE
{
- unsigned long * n = (unsigned long *) (p-thread_info+1);
+ unsigned long * n = end_of_stack(p);
while (!*n)
n++;
- free = (unsigned long) n - (unsigned long)(p-thread_info+1);
+ free = (unsigned long) n - (unsigned long) end_of_stack(p);
}
#endif
printk(%5lu %5d %6d , free, p-pid, p-parent-pid);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] (9/22) wrong ifdefs in 82596
ifdefs around variable declaration would better match those around its uses...
Signed-off-by: Al Viro [EMAIL PROTECTED]
diff -urN RC13-rc7-lance/drivers/net/82596.c
RC13-rc7-82596-apricot/drivers/net/82596.c
--- RC13-rc7-lance/drivers/net/82596.c 2005-08-10 10:37:49.0 -0400
+++ RC13-rc7-82596-apricot/drivers/net/82596.c 2005-08-25 00:54:10.0
-0400
@@ -614,7 +614,7 @@
static int init_i596_mem(struct net_device *dev)
{
struct i596_private *lp = dev-priv;
-#if !defined(ENABLE_MVME16x_NET) !defined(ENABLE_BVME6000_NET)
+#if !defined(ENABLE_MVME16x_NET) !defined(ENABLE_BVME6000_NET) ||
defined(ENABLE_APRICOT)
short ioaddr = dev-base_addr;
#endif
unsigned long flags;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpu_exclusive sched domains fix broke ppc64
A day or two ago, Paul M. wrote: Compiling -rc7 for ppc64 using pSeries_defconfig I get this compile error: Not that the following really matters ... I've already sent in a fix, based on your analysis, followed by Nick's suggestion that we don't do it this way anyway. ... however ... question for Paul M. ... what version of gcc did this fail on? I finally got my crosstools setup working for me again, and building a powerpc64 using gcc-3.4.0 on my Intel PC box does _not_ fail. That build goes through fine. This is with CONFIG_CPUSETS=y, but without my fix of early this Wednesday to put the cpumask in question into a local variable. Either I've managed to confuse myself (most likely) or else this gcc 3.4 is newer than you were using, and this newer gcc has gotten smart enough to unravel this particular case and recognize that there actually is already a memory object (the array of cpumasks, one per node, specifying which cpus are on that node) laying around that can be used here. Strange. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] (19/22) task_thread_info - part 3/4
a) in smp_lock.h #include of sched.h and spinlock.h moved under
#ifdef CONFIG_LOCK_KERNEL.
b) interrupt.h now explicitly pulls sched.h (not via smp_lock.h from
hardirq.h as it used to)
c) in two more places we need changes to compensate for (a) - one place in
arch/sparc needs string.h now and hardirq.h needs forward declaration of
task_struct and direct include of thread_info.h.
d) thread_info-related helpers in sched.h and thread_info.h put under
ifndef __HAVE_THREAD_FUNCTIONS. Obviously safe.
Signed-off-by: Al Viro [EMAIL PROTECTED]
diff -urN RC13-rc7-other-helpers/arch/sparc/lib/bitext.c
RC13-rc7-includes/arch/sparc/lib/bitext.c
--- RC13-rc7-other-helpers/arch/sparc/lib/bitext.c 2005-06-17
15:48:29.0 -0400
+++ RC13-rc7-includes/arch/sparc/lib/bitext.c 2005-08-25 00:54:18.0
-0400
@@ -10,6 +10,7 @@
*/
#include linux/smp_lock.h
+#include linux/string.h
#include linux/bitops.h
#include asm/bitext.h
diff -urN RC13-rc7-other-helpers/include/linux/hardirq.h
RC13-rc7-includes/include/linux/hardirq.h
--- RC13-rc7-other-helpers/include/linux/hardirq.h 2005-08-10
10:37:54.0 -0400
+++ RC13-rc7-includes/include/linux/hardirq.h 2005-08-25 00:54:18.0
-0400
@@ -4,6 +4,7 @@
#include linux/config.h
#include linux/preempt.h
#include linux/smp_lock.h
+#include linux/thread_info.h
#include asm/hardirq.h
#include asm/system.h
@@ -90,6 +91,8 @@
#define nmi_enter()irq_enter()
#define nmi_exit() sub_preempt_count(HARDIRQ_OFFSET)
+struct task_struct;
+
#ifndef CONFIG_VIRT_CPU_ACCOUNTING
static inline void account_user_vtime(struct task_struct *tsk)
{
diff -urN RC13-rc7-other-helpers/include/linux/interrupt.h
RC13-rc7-includes/include/linux/interrupt.h
--- RC13-rc7-other-helpers/include/linux/interrupt.h2005-06-17
15:48:29.0 -0400
+++ RC13-rc7-includes/include/linux/interrupt.h 2005-08-25 00:54:18.0
-0400
@@ -12,6 +12,7 @@
#include asm/atomic.h
#include asm/ptrace.h
#include asm/system.h
+#include linux/sched.h
/*
* For 2.4.x compatibility, 2.4.x can use
diff -urN RC13-rc7-other-helpers/include/linux/sched.h
RC13-rc7-includes/include/linux/sched.h
--- RC13-rc7-other-helpers/include/linux/sched.h2005-08-25
00:54:17.0 -0400
+++ RC13-rc7-includes/include/linux/sched.h 2005-08-25 00:54:18.0
-0400
@@ -1136,6 +1136,8 @@
spin_unlock(p-alloc_lock);
}
+#ifndef __HAVE_THREAD_FUNCTIONS
+
#define task_thread_info(task) (task)-thread_info
static inline void setup_thread_info(struct task_struct *p, struct thread_info
*ti)
@@ -1176,6 +1178,8 @@
return test_ti_thread_flag(task_thread_info(tsk), flag);
}
+#endif
+
static inline void set_tsk_need_resched(struct task_struct *tsk)
{
set_tsk_thread_flag(tsk,TIF_NEED_RESCHED);
diff -urN RC13-rc7-other-helpers/include/linux/smp_lock.h
RC13-rc7-includes/include/linux/smp_lock.h
--- RC13-rc7-other-helpers/include/linux/smp_lock.h 2005-06-17
15:48:29.0 -0400
+++ RC13-rc7-includes/include/linux/smp_lock.h 2005-08-25 00:54:18.0
-0400
@@ -2,11 +2,10 @@
#define __LINUX_SMPLOCK_H
#include linux/config.h
+#ifdef CONFIG_LOCK_KERNEL
#include linux/sched.h
#include linux/spinlock.h
-#ifdef CONFIG_LOCK_KERNEL
-
#define kernel_locked()(current-lock_depth = 0)
extern int __lockfunc __reacquire_kernel_lock(void);
diff -urN RC13-rc7-other-helpers/include/linux/thread_info.h
RC13-rc7-includes/include/linux/thread_info.h
--- RC13-rc7-other-helpers/include/linux/thread_info.h 2005-06-17
15:48:29.0 -0400
+++ RC13-rc7-includes/include/linux/thread_info.h 2005-08-25
00:54:18.0 -0400
@@ -22,6 +22,7 @@
#ifdef __KERNEL__
+#ifndef __HAVE_THREAD_FUNCTIONS
/*
* flag set/clear/test wrappers
* - pass TIF_ constants to these functions
@@ -88,5 +89,6 @@
}
#endif
+#endif
#endif /* _LINUX_THREAD_INFO_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/
[PATCH] (10/22) static vs. extern in scc
extern declaration before the static one Signed-off-by: Al Viro [EMAIL PROTECTED] diff -urN RC13-rc7-82596-apricot/drivers/char/scc.h RC13-rc7-scc/drivers/char/scc.h --- RC13-rc7-82596-apricot/drivers/char/scc.h 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-scc/drivers/char/scc.h 2005-08-25 00:54:11.0 -0400 @@ -399,7 +399,7 @@ __asm__ __volatile__ ( tstb %0 : : g (*_scc_del) : cc );\ } while (0) -extern unsigned char scc_shadow[2][16]; +static unsigned char scc_shadow[2][16]; /* The following functions should relax the somehow complicated * register access of the SCC. _SCCwrite() stores all written values - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/22) static vs. extern in sun3ints.h
extern declaration of static object removed from header Signed-off-by: Al Viro [EMAIL PROTECTED] diff -urN RC13-rc7-dmasound-extern/include/asm-m68k/sun3ints.h RC13-rc7-sun3ints/include/asm-m68k/sun3ints.h --- RC13-rc7-dmasound-extern/include/asm-m68k/sun3ints.h2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-sun3ints/include/asm-m68k/sun3ints.h 2005-08-25 00:54:06.0 -0400 @@ -31,7 +31,6 @@ ); extern void sun3_init_IRQ (void); extern irqreturn_t (*sun3_default_handler[]) (int, void *, struct pt_regs *); -extern irqreturn_t (*sun3_inthandler[]) (int, void *, struct pt_regs *); extern void sun3_free_irq (unsigned int irq, void *dev_id); extern void sun3_enable_interrupts (void); extern void sun3_disable_interrupts (void); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] (6/22) dumb typo in atyfb
atyfb_par misspelled as aty_par, fortunately in m68k-only part of driver
Signed-off-by: Al Viro [EMAIL PROTECTED]
diff -urN RC13-rc7-amigaints/drivers/video/aty/atyfb_base.c
RC13-rc7-atyfb-typo/drivers/video/aty/atyfb_base.c
--- RC13-rc7-amigaints/drivers/video/aty/atyfb_base.c 2005-06-17
15:48:29.0 -0400
+++ RC13-rc7-atyfb-typo/drivers/video/aty/atyfb_base.c 2005-08-25
00:54:08.0 -0400
@@ -3458,7 +3458,7 @@
static int __devinit atyfb_atari_probe(void)
{
- struct aty_par *par;
+ struct atyfb_par *par;
struct fb_info *info;
int m64_num;
u32 clock_r;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] (17/22) task_thread_info - part 1/4
new helper - task_thread_info(task). On platforms that have thread_info
allocated separately (i.e. in default case) it simply returns
task-thread_info m68k wants (and for good reasons) to embed its thread_info
into task_struct. So it will (in later patch) have task_thread_info() of
its own. For now we just add a macro for generic case and convert existing
instances of its body in core kernel to uses of new macro. Obviously safe -
all normal architectures get the same preprocessor output they used to get.
Signed-off-by: Al Viro [EMAIL PROTECTED]
diff -urN RC13-rc7-mac-fonts/include/linux/sched.h
RC13-rc7-task_thread_info/include/linux/sched.h
--- RC13-rc7-mac-fonts/include/linux/sched.h2005-08-10 10:37:54.0
-0400
+++ RC13-rc7-task_thread_info/include/linux/sched.h 2005-08-25
00:54:17.0 -0400
@@ -1136,32 +1136,34 @@
spin_unlock(p-alloc_lock);
}
+#define task_thread_info(task) (task)-thread_info
+
/* set thread flags in other task's structures
* - see asm/thread_info.h for TIF_ flags available
*/
static inline void set_tsk_thread_flag(struct task_struct *tsk, int flag)
{
- set_ti_thread_flag(tsk-thread_info,flag);
+ set_ti_thread_flag(task_thread_info(tsk), flag);
}
static inline void clear_tsk_thread_flag(struct task_struct *tsk, int flag)
{
- clear_ti_thread_flag(tsk-thread_info,flag);
+ clear_ti_thread_flag(task_thread_info(tsk), flag);
}
static inline int test_and_set_tsk_thread_flag(struct task_struct *tsk, int
flag)
{
- return test_and_set_ti_thread_flag(tsk-thread_info,flag);
+ return test_and_set_ti_thread_flag(task_thread_info(tsk), flag);
}
static inline int test_and_clear_tsk_thread_flag(struct task_struct *tsk, int
flag)
{
- return test_and_clear_ti_thread_flag(tsk-thread_info,flag);
+ return test_and_clear_ti_thread_flag(task_thread_info(tsk), flag);
}
static inline int test_tsk_thread_flag(struct task_struct *tsk, int flag)
{
- return test_ti_thread_flag(tsk-thread_info,flag);
+ return test_ti_thread_flag(task_thread_info(tsk), flag);
}
static inline void set_tsk_need_resched(struct task_struct *tsk)
@@ -1232,12 +1234,12 @@
static inline unsigned int task_cpu(const struct task_struct *p)
{
- return p-thread_info-cpu;
+ return task_thread_info(p)-cpu;
}
static inline void set_task_cpu(struct task_struct *p, unsigned int cpu)
{
- p-thread_info-cpu = cpu;
+ task_thread_info(p)-cpu = cpu;
}
#else
diff -urN RC13-rc7-mac-fonts/kernel/exit.c
RC13-rc7-task_thread_info/kernel/exit.c
--- RC13-rc7-mac-fonts/kernel/exit.c2005-08-10 10:37:54.0 -0400
+++ RC13-rc7-task_thread_info/kernel/exit.c 2005-08-25 00:54:17.0
-0400
@@ -846,7 +846,7 @@
if (group_dead tsk-signal-leader)
disassociate_ctty(1);
- module_put(tsk-thread_info-exec_domain-module);
+ module_put(task_thread_info(tsk)-exec_domain-module);
if (tsk-binfmt)
module_put(tsk-binfmt-module);
diff -urN RC13-rc7-mac-fonts/kernel/fork.c
RC13-rc7-task_thread_info/kernel/fork.c
--- RC13-rc7-mac-fonts/kernel/fork.c2005-08-10 10:37:54.0 -0400
+++ RC13-rc7-task_thread_info/kernel/fork.c 2005-08-25 00:54:17.0
-0400
@@ -898,7 +898,7 @@
if (nr_threads = max_threads)
goto bad_fork_cleanup_count;
- if (!try_module_get(p-thread_info-exec_domain-module))
+ if (!try_module_get(task_thread_info(p)-exec_domain-module))
goto bad_fork_cleanup_count;
if (p-binfmt !try_module_get(p-binfmt-module))
@@ -1151,7 +1151,7 @@
if (p-binfmt)
module_put(p-binfmt-module);
bad_fork_cleanup_put_domain:
- module_put(p-thread_info-exec_domain-module);
+ module_put(task_thread_info(p)-exec_domain-module);
bad_fork_cleanup_count:
put_group_info(p-group_info);
atomic_dec(p-user-processes);
diff -urN RC13-rc7-mac-fonts/kernel/sched.c
RC13-rc7-task_thread_info/kernel/sched.c
--- RC13-rc7-mac-fonts/kernel/sched.c 2005-08-21 13:12:57.0 -0400
+++ RC13-rc7-task_thread_info/kernel/sched.c2005-08-25 00:54:17.0
-0400
@@ -1317,7 +1317,7 @@
#endif
#ifdef CONFIG_PREEMPT
/* Want to start with kernel preemption disabled. */
- p-thread_info-preempt_count = 1;
+ task_thread_info(p)-preempt_count = 1;
#endif
/*
* Share the timeslice between parent and child, thus the
@@ -4204,9 +4204,9 @@
/* Set the preempt count _outside_ the spinlocks! */
#if defined(CONFIG_PREEMPT) !defined(CONFIG_PREEMPT_BKL)
- idle-thread_info-preempt_count = (idle-lock_depth = 0);
+ task_thread_info(idle)-preempt_count = (idle-lock_depth = 0);
#else
- idle-thread_info-preempt_count = 0;
+ task_thread_info(idle)-preempt_count = 0;
#endif
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
[PATCH] (7/22) lvalues abuse in mac8390
cast is not an lvalue
Signed-off-by: Al Viro [EMAIL PROTECTED]
diff -urN RC13-rc7-atyfb-typo/drivers/net/mac8390.c
RC13-rc7-mac8390/drivers/net/mac8390.c
--- RC13-rc7-atyfb-typo/drivers/net/mac8390.c 2005-06-17 15:48:29.0
-0400
+++ RC13-rc7-mac8390/drivers/net/mac8390.c 2005-08-25 00:54:09.0
-0400
@@ -560,55 +560,52 @@
/* directly from daynaport.c by Alan Cox */
static void dayna_memcpy_fromcard(struct net_device *dev, void *to, int from,
int count)
{
- volatile unsigned short *ptr;
- unsigned short *target=to;
+ volatile unsigned char *ptr;
+ unsigned char *target=to;
from=1; /* word, skip overhead */
- ptr=(unsigned short *)(dev-mem_start+from);
+ ptr=(unsigned char *)(dev-mem_start+from);
/* Leading byte? */
if (from2) {
- *((char *)target)++ = *(((char *)ptr++)-1);
+ *target++ = ptr[-1];
+ ptr += 2;
count--;
}
while(count=2)
{
- *target++=*ptr++; /* Copy and */
- ptr++; /* skip cruft */
+ *(unsigned short *)target = *(unsigned short volatile *)ptr;
+ ptr += 4; /* skip cruft */
+ target += 2;
count-=2;
}
/* Trailing byte? */
if(count)
- {
- /* Big endian */
- unsigned short v=*ptr;
- *((char *)target)=v8;
- }
+ *target = *ptr;
}
static void dayna_memcpy_tocard(struct net_device *dev, int to, const void
*from, int count)
{
volatile unsigned short *ptr;
- const unsigned short *src=from;
+ const unsigned char *src=from;
to=1; /* word, skip overhead */
ptr=(unsigned short *)(dev-mem_start+to);
/* Leading byte? */
if (to2) { /* avoid a byte write (stomps on other data) */
- ptr[-1] = (ptr[-1]0xFF00)|*((unsigned char *)src)++;
+ ptr[-1] = (ptr[-1]0xFF00)|*src++;
ptr++;
count--;
}
while(count=2)
{
- *ptr++=*src++; /* Copy and */
+ *ptr++=*(unsigned short *)src; /* Copy and */
ptr++; /* skip cruft */
+ src += 2;
count-=2;
}
/* Trailing byte? */
if(count)
{
- /* Big endian */
- unsigned short v=*src;
/* card doesn't like byte writes */
- *ptr=(*ptr0x00FF)|(v0xFF00);
+ *ptr=(*ptr0x00FF)|(*src 8);
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] (11/22) memory input should be an lvalue (mac/misc.c)
gcc4 is less forgiving and wants memory inputs to be real lvalues; variable added and value stored in it explicitly before doing __asm__. Signed-off-by: Al Viro [EMAIL PROTECTED] diff -urN RC13-rc7-scc/arch/m68k/mac/misc.c RC13-rc7-m68k-reset/arch/m68k/mac/misc.c --- RC13-rc7-scc/arch/m68k/mac/misc.c 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-m68k-reset/arch/m68k/mac/misc.c2005-08-25 00:54:12.0 -0400 @@ -466,12 +466,13 @@ /* make a 1-to-1 mapping, using the transparent tran. reg. */ unsigned long virt = (unsigned long) mac_reset; unsigned long phys = virt_to_phys(mac_reset); + unsigned long addr = (phys0xFF00)|0x8777; unsigned long offset = phys-virt; local_irq_disable(); /* lets not screw this up, ok? */ __asm__ __volatile__(.chip 68030\n\t pmove %0,%/tt0\n\t .chip 68k -: : m ((phys0xFF00)|0x8777)); +: : m (addr)); /* Now jump to physical address so we can disable MMU */ __asm__ __volatile__( .chip 68030\n\t - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] LSM hook updates
* James Morris ([EMAIL PROTECTED]) wrote: On Wed, 24 Aug 2005, Chris Wright wrote: This is based on Kurt's original work. The net effect is that LSM hooks are called conditionally, and in all cases capabilities provide the defaults. I've done some basic performance testing, and found nothing surprising. Do you mean nothing noticable? I did only microbenchmarking, which was as much as double digit percentage faster (on P4), nothing was slower. I'm interested to see numbers from others before I push this up. These are against Linus' current git tree (they will clash with the -mm tree). Are there any numbers for popular architectures like i386 and x86_64? I'll have some numbers tomorrow. If you'd like to run SELinux that'd be quite useful. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] (20/22) task_thread_info - part 3/4
a) added embedded thread_info [m68k processor.h]
b) added missing symbols in asm-offsets.c
c) task_thread_info() and freinds in asm-m68k/thread_info.h
d) made m68k thread_info.h included by m68k processor.h, not the
other way round.
Signed-off-by: Al Viro [EMAIL PROTECTED]
diff -urN RC13-rc7-includes/arch/m68k/kernel/asm-offsets.c
RC13-rc7-m68k/arch/m68k/kernel/asm-offsets.c
--- RC13-rc7-includes/arch/m68k/kernel/asm-offsets.c2005-06-17
15:48:29.0 -0400
+++ RC13-rc7-m68k/arch/m68k/kernel/asm-offsets.c2005-08-25
00:54:19.0 -0400
@@ -31,6 +31,7 @@
DEFINE(TASK_SIGPENDING, offsetof(struct task_struct,
thread.work.sigpending));
DEFINE(TASK_NOTIFY_RESUME, offsetof(struct task_struct,
thread.work.notify_resume));
DEFINE(TASK_THREAD, offsetof(struct task_struct, thread));
+ DEFINE(TASK_INFO, offsetof(struct task_struct, thread.info));
DEFINE(TASK_MM, offsetof(struct task_struct, mm));
DEFINE(TASK_ACTIVE_MM, offsetof(struct task_struct, active_mm));
@@ -45,6 +46,10 @@
DEFINE(THREAD_FPCNTL, offsetof(struct thread_struct, fpcntl));
DEFINE(THREAD_FPSTATE, offsetof(struct thread_struct, fpstate));
+ /* offsets into the thread_info struct */
+ DEFINE(TINFO_PREEMPT, offsetof(struct thread_info, preempt_count));
+ DEFINE(HARDIRQ_SHIFT, HARDIRQ_SHIFT);
+
/* offsets into the pt_regs */
DEFINE(PT_D0, offsetof(struct pt_regs, d0));
DEFINE(PT_ORIG_D0, offsetof(struct pt_regs, orig_d0));
diff -urN RC13-rc7-includes/include/asm-m68k/processor.h
RC13-rc7-m68k/include/asm-m68k/processor.h
--- RC13-rc7-includes/include/asm-m68k/processor.h 2005-06-17
15:48:29.0 -0400
+++ RC13-rc7-m68k/include/asm-m68k/processor.h 2005-08-25 00:54:19.0
-0400
@@ -14,6 +14,7 @@
#define current_text_addr() ({ __label__ _l; _l: _l;})
#include linux/config.h
+#include linux/thread_info.h
#include asm/segment.h
#include asm/fpu.h
#include asm/ptrace.h
@@ -79,6 +80,7 @@
unsigned long fpcntl[3]; /* fp control regs */
unsigned char fpstate[FPSTATESIZE]; /* floating point state */
struct task_work work;
+ struct thread_info info;
};
#define INIT_THREAD { \
diff -urN RC13-rc7-includes/include/asm-m68k/thread_info.h
RC13-rc7-m68k/include/asm-m68k/thread_info.h
--- RC13-rc7-includes/include/asm-m68k/thread_info.h2005-08-10
10:37:53.0 -0400
+++ RC13-rc7-m68k/include/asm-m68k/thread_info.h2005-08-25
00:54:19.0 -0400
@@ -2,7 +2,6 @@
#define _ASM_M68K_THREAD_INFO_H
#include asm/types.h
-#include asm/processor.h
#include asm/page.h
struct thread_info {
@@ -35,11 +34,11 @@
#define free_thread_info(ti) free_pages((unsigned long)(ti),1)
#endif /* PAGE_SHIFT == 13 */
-//#define init_thread_info (init_task.thread.info)
-#define init_stack (init_thread_union.stack)
-
-#define current_thread_info() (current-thread_info)
+#define init_thread_info (init_thread_union.thread_info)
+#define init_stack (init_thread_union.stack)
+#define task_thread_info(tsk) ((tsk)-thread.info)
+#define current_thread_info() task_thread_info(current)
#define __HAVE_THREAD_FUNCTIONS
@@ -52,6 +51,10 @@
extern int thread_flag_fixme(void);
+#define setup_thread_info(p, ti) do (ti)-task = p; while(0)
+
+#define end_of_stack(p) ((unsigned long *)(p)-thread_info + 1)
+
/*
* flag set/clear/test wrappers
* - pass TIF_ constants to these functions
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] (21/22) task_thread_info - part 4/4
partially pulled from m68k CVS; switches m68k handling of thread flags to usual bitmap, which allows to unify most of the thread flag helpers. After that only task_thread_info(), stack_end() and setup_thread_info() are conditional on __HAVE_THREAD_FUNCTIONS. Signed-off-by: Al Viro [EMAIL PROTECTED] diff -urN RC13-rc7-m68k/arch/m68k/fpsp040/skeleton.S RC13-rc7-m68k-flags/arch/m68k/fpsp040/skeleton.S --- RC13-rc7-m68k/arch/m68k/fpsp040/skeleton.S 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-m68k-flags/arch/m68k/fpsp040/skeleton.S2005-08-25 00:54:20.0 -0400 @@ -381,10 +381,8 @@ .Lnotkern: SAVE_ALL_INT GET_CURRENT(%d0) - tstb%curptr@(TASK_NEEDRESCHED) - jne ret_from_exception | deliver signals, - | reschedule etc.. - RESTORE_ALL + | deliver signals, reschedule etc.. + jra ret_from_exception | | mem_write --- write to user or supervisor address space diff -urN RC13-rc7-m68k/arch/m68k/ifpsp060/iskeleton.S RC13-rc7-m68k-flags/arch/m68k/ifpsp060/iskeleton.S --- RC13-rc7-m68k/arch/m68k/ifpsp060/iskeleton.S2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-m68k-flags/arch/m68k/ifpsp060/iskeleton.S 2005-08-25 00:54:20.0 -0400 @@ -75,10 +75,8 @@ .Lnotkern: SAVE_ALL_INT GET_CURRENT(%d0) - tstb%curptr@(TASK_NEEDRESCHED) - jne ret_from_exception | deliver signals, - | reschedule etc.. - RESTORE_ALL + | deliver signals, reschedule etc.. + jra ret_from_exception | | _060_real_chk(): diff -urN RC13-rc7-m68k/arch/m68k/kernel/asm-offsets.c RC13-rc7-m68k-flags/arch/m68k/kernel/asm-offsets.c --- RC13-rc7-m68k/arch/m68k/kernel/asm-offsets.c2005-08-25 00:54:19.0 -0400 +++ RC13-rc7-m68k-flags/arch/m68k/kernel/asm-offsets.c 2005-08-25 00:54:20.0 -0400 @@ -25,11 +25,6 @@ DEFINE(TASK_STATE, offsetof(struct task_struct, state)); DEFINE(TASK_FLAGS, offsetof(struct task_struct, flags)); DEFINE(TASK_PTRACE, offsetof(struct task_struct, ptrace)); - DEFINE(TASK_WORK, offsetof(struct task_struct, thread.work)); - DEFINE(TASK_NEEDRESCHED, offsetof(struct task_struct, thread.work.need_resched)); - DEFINE(TASK_SYSCALL_TRACE, offsetof(struct task_struct, thread.work.syscall_trace)); - DEFINE(TASK_SIGPENDING, offsetof(struct task_struct, thread.work.sigpending)); - DEFINE(TASK_NOTIFY_RESUME, offsetof(struct task_struct, thread.work.notify_resume)); DEFINE(TASK_THREAD, offsetof(struct task_struct, thread)); DEFINE(TASK_INFO, offsetof(struct task_struct, thread.info)); DEFINE(TASK_MM, offsetof(struct task_struct, mm)); @@ -48,7 +43,7 @@ /* offsets into the thread_info struct */ DEFINE(TINFO_PREEMPT, offsetof(struct thread_info, preempt_count)); - DEFINE(HARDIRQ_SHIFT, HARDIRQ_SHIFT); + DEFINE(TINFO_FLAGS, offsetof(struct thread_info, flags)); /* offsets into the pt_regs */ DEFINE(PT_D0, offsetof(struct pt_regs, d0)); diff -urN RC13-rc7-m68k/arch/m68k/kernel/entry.S RC13-rc7-m68k-flags/arch/m68k/kernel/entry.S --- RC13-rc7-m68k/arch/m68k/kernel/entry.S 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-m68k-flags/arch/m68k/kernel/entry.S2005-08-25 00:54:20.0 -0400 @@ -44,9 +44,7 @@ #include asm/offsets.h -.globl system_call, buserr, trap -.globl resume, ret_from_exception -.globl ret_from_signal +.globl system_call, buserr, trap, resume .globl inthandler, sys_call_table .globl sys_fork, sys_clone, sys_vfork .globl ret_from_interrupt, bad_interrupt @@ -58,7 +56,7 @@ movel %sp,[EMAIL PROTECTED] | stack frame pointer argument bsrlbuserr_c addql #4,%sp - jra ret_from_exception + jra .Lret_from_exception ENTRY(trap) SAVE_ALL_INT @@ -66,7 +64,7 @@ movel %sp,[EMAIL PROTECTED] | stack frame pointer argument bsrltrap_c addql #4,%sp - jra ret_from_exception + jra .Lret_from_exception | After a fork we jump here directly from resume, | so that %d1 contains the previous task @@ -75,30 +73,31 @@ movel %d1,[EMAIL PROTECTED] jsr schedule_tail addql #4,%sp - jra ret_from_exception + jra .Lret_from_exception -badsys: - movel #-ENOSYS,%sp@(PT_D0) - jra ret_from_exception - -do_trace: +do_trace_entry: movel #-ENOSYS,%sp@(PT_D0)| needed for strace subql #4,%sp SAVE_SWITCH_STACK jbsrsyscall_trace RESTORE_SWITCH_STACK addql #4,%sp - movel %sp@(PT_ORIG_D0),%d1 - movel #-ENOSYS,%d0 - cmpl#NR_syscalls,%d1 - jcc 1f - jbsr@(sys_call_table,%d1:l:4)@(0) -1: movel %d0,%sp@(PT_D0) | save the
[PATCH] (15/22) Kconfig fix (82596)
driver is non-modular Signed-off-by: Al Viro [EMAIL PROTECTED] diff -urN RC13-rc7-oktagon/drivers/net/Kconfig RC13-rc7-82596/drivers/net/Kconfig --- RC13-rc7-oktagon/drivers/net/Kconfig2005-08-24 01:58:29.0 -0400 +++ RC13-rc7-82596/drivers/net/Kconfig 2005-08-25 00:54:15.0 -0400 @@ -395,7 +395,7 @@ If you're not building a kernel for a Sun 3, say N. config SUN3_82586 - tristate Sun3 on-board Intel 82586 support + bool Sun3 on-board Intel 82586 support depends on NET_ETHERNET SUN3 help This driver enables support for the on-board Intel 82586 based - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] (12/22) broken constraints on mulu.l
too permissive constraint on mulu.l - the first argument should not be
an a-register. Fixed by replacing g with dm; with older gcc we got
lucky and it had never attempted mulu.l %a0, %d1:%d0. These days it
does, with predictable objections from as(1).
Signed-off-by: Al Viro [EMAIL PROTECTED]
diff -urN RC13-rc7-m68k-reset/arch/m68k/math-emu/multi_arith.h
RC13-rc7-m68k-mul/arch/m68k/math-emu/multi_arith.h
--- RC13-rc7-m68k-reset/arch/m68k/math-emu/multi_arith.h2005-06-17
15:48:29.0 -0400
+++ RC13-rc7-m68k-mul/arch/m68k/math-emu/multi_arith.h 2005-08-25
00:54:13.0 -0400
@@ -366,7 +366,7 @@
#define fp_mul64(desth, destl, src1, src2) ({ \
asm (mulu.l %2,%1:%0 : =d (destl), =d (desth) \
- : g (src1), 0 (src2)); \
+ : dm (src1), 0 (src2)); \
})
#define fp_div64(quot, rem, srch, srcl, div) \
asm (divu.l %2,%1:%0 : =d (quot), =d (rem)\
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] (16/22) Kconfig fix (mac vs. FONTS)
mac won't build without non-modular FONTS, which requires non-modular FB and FRAMEBUFFER_CONSOLE Signed-off-by: Al Viro [EMAIL PROTECTED] diff -urN RC13-rc7-82596/arch/m68k/Kconfig RC13-rc7-mac-fonts/arch/m68k/Kconfig --- RC13-rc7-82596/arch/m68k/Kconfig2005-08-10 10:37:46.0 -0400 +++ RC13-rc7-mac-fonts/arch/m68k/Kconfig2005-08-25 00:54:16.0 -0400 @@ -126,6 +126,8 @@ config MAC bool Macintosh support depends on !MMU_SUN3 + select FRAMEBUFFER_CONSOLE + select FB help This option enables support for the Apple Macintosh series of computers (yes, there is experimental support now, at least for part - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] (8/22) lvalues abuse in lance
result of comma operator is not an lvalue Signed-off-by: Al Viro [EMAIL PROTECTED] diff -urN RC13-rc7-mac8390/drivers/net/atarilance.c RC13-rc7-lance/drivers/net/atarilance.c --- RC13-rc7-mac8390/drivers/net/atarilance.c 2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-lance/drivers/net/atarilance.c 2005-08-25 00:54:10.0 -0400 @@ -235,7 +235,7 @@ #defineMEM lp-mem #defineDREGIO-data #defineAREGIO-addr -#defineREGA(a) ( AREG = (a), DREG ) +#defineREGA(a) (*( AREG = (a), DREG )) /* Definitions for packet buffer access: */ #define PKT_BUF_SZ 1544 diff -urN RC13-rc7-mac8390/drivers/net/sun3lance.c RC13-rc7-lance/drivers/net/sun3lance.c --- RC13-rc7-mac8390/drivers/net/sun3lance.c2005-06-17 15:48:29.0 -0400 +++ RC13-rc7-lance/drivers/net/sun3lance.c 2005-08-25 00:54:10.0 -0400 @@ -162,7 +162,7 @@ #defineMEM lp-mem #defineDREGlp-iobase[0] #defineAREGlp-iobase[1] -#defineREGA(a) ( AREG = (a), DREG ) +#defineREGA(a) (*( AREG = (a), DREG )) /* Definitions for the Lance */ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] (22/22) ADBREQ_RAW missing declaration
pulled from m68k CVS; ADBREQ_RAW is used in arch/m68k/mac/misc.c, but its
declaration had not been propagated to Linus' tree yet. Related chunk in
drivers/macintosh/adb.c also pulled in; even though the file is shared with
ppc, behaviour is changed only for m68k.
Signed-off-by: Al Viro [EMAIL PROTECTED]
diff -urN RC13-rc7-m68k-flags/drivers/macintosh/adb.c
RC13-rc7-m68k-adb.patch/drivers/macintosh/adb.c
--- RC13-rc7-m68k-flags/drivers/macintosh/adb.c 2005-08-10 10:37:49.0
-0400
+++ RC13-rc7-m68k-adb.patch/drivers/macintosh/adb.c 2005-08-25
00:54:21.0 -0400
@@ -476,13 +476,15 @@
use_sreq = 1;
} else
use_sreq = 0;
- req-nbytes = nbytes+1;
+ i = (flags ADBREQ_RAW) ? 0 : 1;
+ req-nbytes = nbytes+i;
req-done = done;
req-reply_expected = flags ADBREQ_REPLY;
req-data[0] = ADB_PACKET;
va_start(list, nbytes);
- for (i = 0; i nbytes; ++i)
- req-data[i+1] = va_arg(list, int);
+ while (i req-nbytes) {
+ req-data[i++] = va_arg(list, int);
+ }
va_end(list);
if (flags ADBREQ_NOSEND)
diff -urN RC13-rc7-m68k-flags/include/linux/adb.h
RC13-rc7-m68k-adb.patch/include/linux/adb.h
--- RC13-rc7-m68k-flags/include/linux/adb.h 2005-06-17 15:48:29.0
-0400
+++ RC13-rc7-m68k-adb.patch/include/linux/adb.h 2005-08-25 00:54:21.0
-0400
@@ -76,6 +76,7 @@
#define ADBREQ_REPLY 1 /* expect reply */
#define ADBREQ_SYNC2 /* poll until done */
#define ADBREQ_NOSEND 4 /* build the request, but don't send it */
+#define ADBREQ_RAW 8 /* send raw packet (don't prepend ADB_PACKET) */
/* Messages sent thru the client_list notifier. You should NOT stop
the operation, at least not with this version */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] (14/22) oktagon makefile fix
oktagon_esp is described as modular. However, drivers/scsi/Makefile doesn't handle it right - it's multi-object module, with one of the parts being built from .S. Current makefile tries to declare each part a module of its own; that not only wouldn't work (oktagon_io.o doesn't have the right parts for that), it actually doesn't even build since kbuild doesn't believe in single-object modules built from .S. Turned into proper multi-object module... Signed-off-by: Al Viro [EMAIL PROTECTED] diff -urN RC13-rc7-isa_type/drivers/scsi/Makefile RC13-rc7-oktagon/drivers/scsi/Makefile --- RC13-rc7-isa_type/drivers/scsi/Makefile 2005-08-10 10:37:50.0 -0400 +++ RC13-rc7-oktagon/drivers/scsi/Makefile 2005-08-25 00:54:14.0 -0400 @@ -41,7 +41,7 @@ obj-$(CONFIG_BLZ2060_SCSI) += NCR53C9x.o blz2060.o obj-$(CONFIG_BLZ1230_SCSI) += NCR53C9x.o blz1230.o obj-$(CONFIG_FASTLANE_SCSI)+= NCR53C9x.o fastlane.o -obj-$(CONFIG_OKTAGON_SCSI) += NCR53C9x.o oktagon_esp.o oktagon_io.o +obj-$(CONFIG_OKTAGON_SCSI) += NCR53C9x.o oktagon_esp_mod.o obj-$(CONFIG_ATARI_SCSI) += atari_scsi.o obj-$(CONFIG_MAC_SCSI) += mac_scsi.o obj-$(CONFIG_SCSI_MAC_ESP) += mac_esp.oNCR53C9x.o @@ -160,6 +160,7 @@ cpqfc-objs := cpqfcTSinit.o cpqfcTScontrol.o cpqfcTSi2c.o \ cpqfcTSworker.o cpqfcTStrigger.o libata-objs:= libata-core.o libata-scsi.o +oktagon_esp_mod-objs := oktagon_esp.o oktagon_io.o # Files generated that shall be removed upon make clean clean-files := 53c7xx_d.h 53c700_d.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: cpu_exclusive sched domains fix broke ppc64
Paul Jackson writes: ... however ... question for Paul M. ... what version of gcc did this fail on? The gcc-4.0.2 in Debian/ppc sid, which is biarch. I finally got my crosstools setup working for me again, and building a powerpc64 using gcc-3.4.0 on my Intel PC box does _not_ fail. That Did you have CONFIG_NUMA=y ? Paul. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12 Performance problems
Danial Thom wrote: I think the concensus is that 2.6 has made trade offs that lower raw throughput, which is what a networking device needs. So as a router or network appliance, 2.6 seems less suitable. A raw bridging test on a 2.0Ghz operton system: FreeBSD 4.9: Drops no packets at 900K pps Linux 2.4.24: Starts dropping packets at 350K pps Linux 2.6.12: Starts dropping packets at 100K pps I ran some quick tests using kernel 2.6.11, 1ms tick (HZ=1000), SMP kernel. Hardware is P-IV 3.0Ghz + HT on a new SuperMicro motherboard with 64/133Mhz PCI-X bus. NIC is dual Intel pro/1000. Kernel is close to stock 2.6.11. I used brctl to create a bridge with the two GigE adapters in it and used pktgen to stream traffic through it (250kpps in one direction, 1kpps in the other.) I see a reasonable amount of drops at 250kpps (60 byte packets): about 60,000,000 packets received, 20,700 dropped. Interestingly, the system is about 60% idle according to top, and still dropping pkts, so it would seem that the system could be better utilized! Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.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: 2.6.13-rc6-rt15 won't compile without HR-Timers
* K.R. Foley [EMAIL PROTECTED] wrote: Ingo, Without the attached patch 2.6.13-rc6-rt15 won't compile for me with CONFIG_HIGH_RES_TIMERS not configured. thanks, applied. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] drivers/char/drm/: small cleanups
This patch contains the following small cleanups:
- make two needlessly global functions static
- drm_sysfs.c: every file should #include the header with the prototypes
of the global functions it is offering
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/char/drm/drm_bufs.c|2 +-
drivers/char/drm/drm_context.c |2 +-
drivers/char/drm/drm_sysfs.c |1 +
3 files changed, 3 insertions(+), 2 deletions(-)
--- linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_bufs.c.old 2005-08-24
16:55:50.0 +0200
+++ linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_bufs.c 2005-08-24
16:56:06.0 +0200
@@ -1041,7 +1041,7 @@
return 0;
}
-int drm_addbufs_fb(drm_device_t *dev, drm_buf_desc_t *request)
+static int drm_addbufs_fb(drm_device_t *dev, drm_buf_desc_t *request)
{
drm_device_dma_t *dma = dev-dma;
drm_buf_entry_t *entry;
--- linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_context.c.old
2005-08-24 16:56:29.0 +0200
+++ linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_context.c2005-08-24
16:56:42.0 +0200
@@ -308,7 +308,7 @@
*
* Attempt to set drm_device::context_flag.
*/
-int drm_context_switch( drm_device_t *dev, int old, int new )
+static int drm_context_switch( drm_device_t *dev, int old, int new )
{
if ( test_and_set_bit( 0, dev-context_flag ) ) {
DRM_ERROR( Reentering -- FIXME\n );
--- linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_sysfs.c.old 2005-08-24
16:57:02.0 +0200
+++ linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_sysfs.c 2005-08-24
16:57:20.0 +0200
@@ -17,6 +17,7 @@
#include linux/err.h
#include drm_core.h
+#include drmP.h
struct drm_sysfs_class {
struct class_device_attribute attr;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
