Re: [PATCH] remove input_call_hotplug (Take#2)

[Hannes Reinecke]

Greg KH wrote:
On Wed, Jan 19, 2005 at 02:48:14PM +0100, Hannes Reinecke wrote:
Hi Dmitry,
attached is the reworked patch for removing the call to 
call_usermodehelper from input.c
I've used the 'phys' attribute to generate the device names, this way we 
don't need to touch all drivers and the patch itself is nice and small.

The main problem of this is the input_dev structures are created
statically, right?  Because of this, the release function really doesn't
work out correctly I think
That depends on the driver. input_dev is in general a static entry in 
the driver-dependend structure, which in turn may be statically or 
dynamically allocated (depending on whether the driver allows for more 
than one instance of the device to be connected).
Would dynamic allocation be of any help here?

I must admit that reference counting in sysfs is still a somewhat 
darkish grey box to me.

Other than that this looks a lot better.
kewl.
Hm, you're still generating hotplug events with this patch of the
"input_device" type, right?
Of course. I didn't see another way, as already stated the originial 
input events were something of a misnomer.
So either I had to change the existing sysfs layout by renaming the 
current 'input' class and retain compability with the events
or change the event types and retain compability with the sysfs layout.
I opted for the latter, as AFAIK more userland tools might be reading 
from sysfs than processing hotplug events.

Cheers,
Hannes
--
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux AG   S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg  http://www.suse.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] dynamic tick patch

[Tony Lindgren]

* Pavel Machek <[EMAIL PROTECTED]> [050119 16:56]:
> Hi!
> 
> > > > > > Thanks for trying it out. I have quite accurate time here on my
> > > > > > systems, and sleep works as it should. I wonder what's happening on
> > > > > > your system? If you have a chance, could you please post the results
> > > > > > from following simple tests?
> > > > > 
> > > > > On patched 2.6.11-rc1:
> > > > > 
> > > > > [Heh, clock is two times too fast, perhaps that makes ntpdate fail? 
> > > > > -- yes.
> > > > > 
> > > > > [EMAIL PROTECTED]:~# dmesg | grep -i time; for i in 1 2 3 4 5; do 
> > > > > ntpdate -b tak.cesnet.cz && sleep 10; done ; date && sleep 10 && 
> > > > > date; while [ 1 ]; do date; done | uniq
> > > > > PCI: Setting latency timer of device :00:11.5 to 64
> > > > > dyn-tick: Enabling dynamic tick timer
> > > > > dyn-tick: Timer using dynamic tick
> > > > 
> > > > Thanks. Looks like you're running on PIT only, I guess my patch
> > > > currently breaks PIT (and possibly HPET) No dmesg message for "
> > > > "Using XXX for high-res timesource".
> > > 
> > > This machine definitely has TSC... What do I have to do in .config to
> > > make it do something interesting? My .config is:
> > 
> > I suspect it's the HPET_TIMER, see below. CONFIG_X86_PM_TIMER is
> > optional, otherwise TSC is used.
> 
> Okay, so I tried to measure power consumption. Patched kernel seems to
> be about 200mW better. That's on 22W... I'll see if I can tweak ACPI
> somehow to decrease it a bit more.

Good to hear you finally got it to work, and can enjoy the extra few 
milliseconds of battery life :) Now the real problem is what to do
with the idle to take advantage of the extra idle time... I'm not
convinced that hlt or ACPI C2/C3 actually sleep through it. Maybe
there's something more that can be done?

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: [Lists-linux-kernel-news] Re: [PATCH] raid6: altivec support

[Jon Masters]

[excuse formatting, adhoc connectivity]


Ben writes:


> And ppc64 adds a flattened device-tree format, even better imho :)


This is exactly what I was looking at - pulling that in to ppc32, helps
with stuff like kexec too. Like everything else, it helps to have people
moaning at me to make me get on with it :-) I'll see if I can't spend a
few hours on the plane and ressurrect this instead of window gazing.

Jon.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Alps touchpad probing failure

[Juergen Quade]

On Thu, Jan 20, 2005 at 12:23:58AM +0100, Daniel Caujolle-Bert wrote:
> Hi,
> 
>  With 2.6.11-rc1 bk6 and bk7 (didn't tried with < bk6), my alps touchpad is 
> no 
> more correctly probed, it's recognised as a standard PS/2 mouse.
>  So, with this trivial two line patch, everything is working again.
> 
> Cheers.

I have had the same problems...
Now solved ...

Thanks for the patch,

 Juergen.
> -- 
> 73's de Daniel "Der Schreckliche", F1RMB.
> 
>  -=- Daniel Caujolle-Bert -=- [EMAIL PROTECTED] -=-
> -=- http://naboo.homelinux.org -=-

> --- linux-2.6.11-rc1/drivers/input/mouse/alps.c   2005-01-19 
> 19:43:36.0 +0100
> +++ linux/drivers/input/mouse/alps.c  2005-01-19 19:34:32.0 +0100
> @@ -194,6 +194,12 @@
>   int i;
>  
>   /*
> +  * Let's clean the stuff.
> +  */
> + if(psmouse_reset(psmouse) < 0)
> +   printk(KERN_ERR "alps reset failed\n");
> +
> + /*
>* First try "E6 report".
>* ALPS should return 0x00,0x00,0x0a or 0x00,0x00,0x64
>*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.11-rc1

[Peter Osterlund]

On Wed, 19 Jan 2005, Daniel Gryniewicz wrote:

> On Wed, 2005-01-19 at 23:16 -0500, Dmitry Torokhov wrote:
> > On Wednesday 19 January 2005 16:07, Daniel Gryniewicz wrote:
> > > On Tue, 2005-01-11 at 21:09 -0800, Linus Torvalds wrote:
> > > > Ok, the big merges after 2.6.10 are hopefully over, and 2.6.11-rc1 is 
> > > > out
> > > > there.
> > > >
> > > > Peter Osterlund:
> > > >   o input: Add ALPS touchpad driver, driver by Neil Brown, Peter
> > > > Osterlund and Dmitry Torokhov, some fixes by Vojtech Pavlik.
> > >
> > > 2.6.11-rc1 broke my ALPS touchpad.  I have a Dell Inspiron 8600, and
> > > previously, I was patching my kernels with the patch from
> > >
> > > Message-Id: <[EMAIL PROTECTED]>
> > > Subject: [RFT/PATCH 2.6] ALPS touchpad driver
> > >
> > > and this worked fine.
> > >
> > Could you please try this patch by Peter Osterlund:
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel=110513688110246=raw
> >
> > It looks like Kensington and ALPS hate each other.
>
> That fixed it, thanks.  I hope this can make it in before 2.6.11 final,
> but if it doesn't, I'll just patch it in.

OK, I've got another report in private mail where this patch fixed the
ALPS detection, so the score for this patch is now 3 success reports and 0
problem reports. I also think the patch should be included before 2.6.11
final.

The patch is already in -mm btw, it's called alps-touchpad-detection-fix.

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

serial8250_init and platform_device

[Kumar Gala]

I dont get how it is you dont have more platform_devices register than 
you should based on how serial8250_init works if you have additional 
code registering a serial8250 device.  For example, 
arch/arm/mach-s3c2410/mach-vr1000.c will register one serial8250 
device, and it appears to me that serial8250_init will register a 2nd.  
Is this the expected behavior or am I missing something?

- 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] Alps touchpad probing failure

[Daniel Caujolle-Bert]

Hi Dmitry,

Le Jeudi 20 Janvier 2005 04:45, Dmitry Torokhov a ÃcritÂ:
> On Wednesday 19 January 2005 18:23, Daniel Caujolle-Bert wrote:
> > Hi,
> >
> >  With 2.6.11-rc1 bk6 and bk7 (didn't tried with < bk6), my alps touchpad
> > is no more correctly probed, it's recognised as a standard PS/2 mouse.
> > So, with this trivial two line patch, everything is working again.
> >
> > Cheers.
>
> Hi,
>
> I think Peter Osterlund has send similar patch recently - the breakage
> appears to be caused by Kensington mouse detection. It looks like these
> two don't like each other.

 Oh, i see. Okay, maybe that explain why the ps2 command _CMD_GETINFO returned 
the wrong 0x0 0x0 0x16 values.

Cheers.
-- 
73's de Daniel "Der Schreckliche", F1RMB.

 -=- Daniel Caujolle-Bert -=- [EMAIL PROTECTED] -=-
-=- http://naboo.homelinux.org -=-


pgpwZOUCRoG3O.pgp
Description: PGP signature

Re: 2.6.11-rc1-mm2: CONFIG_SMP=n compile error

[Andrew Morton]

Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> arch/i386/kernel/nmi.c:130: error: `cpu_callin_map' undeclared (first use in 
> this function)

--- 25/arch/i386/kernel/nmi.c~i386-x86-64-fix-smp-nmi-watchdog-race-fix 
2005-01-19 23:03:08.946815320 -0800
+++ 25-akpm/arch/i386/kernel/nmi.c  2005-01-19 23:05:07.968721240 -0800
@@ -117,8 +117,10 @@ int __init check_nmi_watchdog (void)
/* FIXME: Only boot CPU is online at this stage.  Check CPUs
as they come up. */
for (cpu = 0; cpu < NR_CPUS; cpu++) {
+#ifdef CONFIG_SMP
if (!cpu_isset(cpu, cpu_callin_map))
continue;
+#endif
if (nmi_count(cpu) - prev_nmi_count[cpu] <= 5) {
printk("CPU#%d: NMI appears to be stuck!\n", cpu);
nmi_active = 0;
diff -puN include/asm-i386/smp.h~i386-x86-64-fix-smp-nmi-watchdog-race-fix 
include/asm-i386/smp.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]Fix an error in copy_page_range

[Zou Nan hai]

Hi, 

There is a bug in copy_page_range in current 2.6.11-rc1 with 4 level
page table change. copy_page_range do a continue without adding pgds and
addr when pgd_none(*src_pgd) or pgd_bad(*src_pgd).

I think it's wrong in logic, copy_page_range will run into infinite loop
when when pgd_none(*src_pgd) or pgd_bad(*src_pgd).

Although maybe this bug does not break anything currently..., 


Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>

--- a/mm/memory.c   2005-01-21 01:21:18.0 +0800
+++ b/mm/memory.c   2005-01-21 04:49:13.0 +0800
@@ -442,17 +442,18 @@ int copy_page_range(struct mm_struct *ds
if (next > end || next <= addr)
next = end;
if (pgd_none(*src_pgd))
-   continue;
+   goto next_pgd;
if (pgd_bad(*src_pgd)) {
pgd_ERROR(*src_pgd);
pgd_clear(src_pgd);
-   continue;
+   goto next_pgd;
}
err = copy_pud_range(dst, src, dst_pgd, src_pgd,
vma, addr, next);
if (err)
break;
 
+next_pgd:
src_pgd++;
dst_pgd++;
addr = next;



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc1-mm2: CONFIG_SMP=n compile error

[Adrian Bunk]

On Wed, Jan 19, 2005 at 09:38:18PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.11-rc1-mm1:
>...
> +i386-x86-64-fix-smp-nmi-watchdog-race.patch
>...
>  x86_64 updates
>...

This obviously breaks compilation for CONFIG_SMP=n:

<--  snip  -->

...
  CC  arch/i386/kernel/nmi.o
arch/i386/kernel/nmi.c: In function `check_nmi_watchdog':
arch/i386/kernel/nmi.c:130: error: `cpu_callin_map' undeclared (first use in 
this function)
arch/i386/kernel/nmi.c:130: error: (Each undeclared identifier is reported only 
once
arch/i386/kernel/nmi.c:130: error: for each function it appears in.)
make[1]: *** [arch/i386/kernel/nmi.o] Error 1

<--  snip  -->

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Con Kolivas wrote:
Jack O'Quin wrote:
I was misreading the x-axis.  They're actually every 20 sec.  My
system isn't doing that.

Possibly reiserfs journal related. That has larger non-preemptible code 
sections.

You're really getting hammered with those periodic 6 msec delays,
though.  The basic audio cycle is only 1.45 msec.

As you've already pointed out, though, they occur even with SCHED_FIFO 
so I'm certain it's an artefact unrelated to cpu scheduling.
Ok to try and answer my own possibility I remounted reiserfs with the 
nolog option and tested with SCHED_ISO

*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 0
Delay Count (>spare time) . . : 1
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :  6750   usecs
Cycle Maximum . . . . . . . . :   717   usecs
Average DSP Load. . . . . . . :30.7 %
Average CPU System Load . . . : 5.7 %
Average CPU User Load . . . . :23.2 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.6 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1683.8 /sec
Average Context-Switch Rate . : 20015.8 /sec
*
You'll see on
http://ck.kolivas.org/patches/SCHED_ISO/iso2-benchmarks/jack_test3-iso2-40c-nolog.png
That the 20s periodic thing delay has all but gone. Just one towards the 
end (no idea what that was).

Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
If I look at those png's locally (with gimp or gqview) they have a
dark grey checkerboard background.  If I look at them on the web (with
galeon), the background is white.  Go figure.  Maybe the file has no
background?  I dunno.
Yes there's no background so it depends on what you look at it with. 
Gene already pointed out the checkered background in gimp :)

I was misreading the x-axis.  They're actually every 20 sec.  My
system isn't doing that.
Possibly reiserfs journal related. That has larger non-preemptible code 
sections.

You're really getting hammered with those periodic 6 msec delays,
though.  The basic audio cycle is only 1.45 msec.
As you've already pointed out, though, they occur even with SCHED_FIFO 
so I'm certain it's an artefact unrelated to cpu scheduling.

Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] dynamic tick patch

[Thomas Gleixner]

On Wed, 2005-01-19 at 15:45 -0800, john stultz wrote:
> On Thu, 2005-01-20 at 00:26 +0100, Thomas Gleixner wrote:
> > On Wed, 2005-01-19 at 14:59 -0800, George Anzinger wrote:
> > > I don't think you will ever get good time if you EVER reprogramm the PIT.
> > 
> > Why not ? If you have a continous time source, which keeps track of
> > "ticks" regardless the CPU state, why should PIT reprogramming be evil ?
> 
> That's a big if.  The problem is that while the PIT has its problems
> (such as lost ticks), it runs at a known frequency and is reasonably
> accurate. Time sources like the TSC have the problem that it doesn't run
> at a known frequency, and thus we have to calibrate it (usually using
> the PIT). Unfortunately this calibration is not extremely accurate
> (George can go on to the reasons why), which causes the TSC to be a poor
> stand alone time source.
>
> That said, the PIT is a poor time source as well, as it does loose ticks
> and is very slow to access. ACPI PM and HPET are better as they don't
> have the lost tick problem, but they are still off chip and slower to
> access then the TSC.

And they aren't available on every board - especially not on embedded
ones. 

> For an example of your ideal continuous timesource, check out the
> timebase on PPC/PPC64. Other arches also have similar well behaved time
> hardware. 

Yes, I'm aware of that. Unfortunately we live in the x86 universe. 

tglx


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

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

utz lehmann wrote:
I had experimented with throttling runaway RT tasks. I use a similar
accounting. I saw a difference between counting with or without the
calling from fork. If i remember correctly the timeout expired too fast
if the non-RT load was "while /bin/true; do :; done".
With "while true; do :; done" ("true" is bash buildin) it worked good.
But maybe it's not important in the real world.
It won't be relevant if we move to a sched_clock() based timesource 
anyway, which looks to be the next major development for this.

If i understand sched_clock correctly it only has higher resolution if
you can use tsc. In the non tsc case it's jiffies based. (On x86).
I think you can easily fool a timer tick/jiffies based accounting and do
a local DoS.
The same timer is used for accounting of SCHED_NORMAL tasks, so if you 
can work around that you can DoS the system with even the correct 
combination of SCHED_NORMAL tasks. When Ingo implemented sched_clock all 
the architectures slowly came on board. If I recall correctly the lowest 
resolution one still had microsecond accuracy which is more than enough 
given the time a context switch takes.

Making SCHED_ISO privileged if you don't have a high resolution
sched_clock is ugly.
I really like the idea of a unprivileged SCHED_ISO but it has to be safe
for a multi user system. And the kernel default should be safe for multi
user.
Agreed; this is exactly what this work is about.
Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Horrible regression with -CURRENT from "Don't busy-lock-loop in preemptable spinlocks" patch

[Grant Grundler]

On Thu, Jan 20, 2005 at 08:43:30AM +1100, Paul Mackerras wrote:
> I suggest read_poll(), write_poll(), spin_poll(),...

Erm...those names sound way too much like existing interfaces.
Perhaps check_read_lock()/check_write_lock() ?

If they don't get used too much, the longer name should be ok.

grant
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Gene Heskett]

On Wednesday 19 January 2005 23:57, Jack O'Quin wrote:
>Con Kolivas <[EMAIL PROTECTED]> writes:
>> Jack O'Quin wrote:
>>> Outstanding.  How do you get rid of that checkerboard grey
>>> background in the graphs?
>>>
>>> Con Kolivas <[EMAIL PROTECTED]> writes:
>>
>> Funny; that's the script you sent me so... beats me?
>
>It's just one of the many things I don't understand about graphics.
>
>If I look at those png's locally (with gimp or gqview) they have a
>dark grey checkerboard background.  If I look at them on the web
> (with galeon), the background is white.  Go figure.  Maybe the file
> has no background?  I dunno.
>
I think you've probably hit it there Con.  Thats exactly what the gimp 
will show you if you expand the view window bigger than the image.  
No data=checkerboard here, everytime.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.32% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: User space out of memory approach

[Bodo Eggert]

On Thu, 20 Jan 2005, Edjard Souza Mota wrote:

> > > > What about creating a linked list of (stackable) algorhithms which can 
> > > > be
> > > > extended by loading modules and resorted using {proc,sys}fs? It will 
> > > > avoid
> > > > the extra process, the extra CPU time (and task switches) to frequently
> > > > update the list and I think it will decrease the typical amount of used
> > > > memory, too.
> > >
> > > Wouldn't this bring the (set of ) ranking algorithm(s) back to the 
> > > kernel? This
> > > is exactly what we're trying to avoid.
> > 
> > You're trying to avoid it in order to let admins try other ranking
> > algorhithms (at least that's what I read). The module approach seems to be
> > flexible enough to do that, and it avoids the mentioned issues. If you
> > really want a userspace daemon, it can be controled by a module.-)
> 
> Yes, your reading is correct, but this choice should take into account
> the "patterns"
> of how memory is allocated for user's mostly used applications. Why?
> The closer the
> ranking gets to "The Best choice" the longer it will take to invoke
> oom killer again.

ACK.

> I am wondering how could a module control a user space deamon if it
> hasn't started
> yet? I mean, processes at user space are supposed to start only after
> all modules
> are loaded (those loadable at boot time). So, this user space deamon
> would break
> this standard. But if we manage to have a special module that takes
> care of loading
> this stack of  OOM Killer ranking algorithms, then the deamon would
> not need to break
> the default order of loading modules.

I don't think there neeeds to be a special order while loading the 
modules, since each module will provide a defined interface which can be 
registered in a linked list and sorted on demand. Just init all 
compiled-in modules and sort using a kernel-parameter (remembering 
modprobe might be fubar), then modprobe (if compiled-in) all missing 
decision modules from the list (appending them) and resort again.

If the admin wants to add a module later, he can also change the order
again, possibly after configuring the module. Disabeling may be either
done by moving a decision past one without fall-through or by using a
seperate list.

There will be a need for a controling instance which will build a list of
candidates and pass it to each decision module in turn untill the victim
is found. Maybe the list will need a field for a ranking offset and a
scaling factor if a module is not supposed to do the final decision but to
modify the ranking for some blessed processes.

> The init could be changed to
> start the deamon,
> and then the module would start controlling it. Am I right?

It can, but it should be run from the (possibly autogenerated)  
initr{d,amfs} if it's used.

> So that's why people is complaining every distro would have to update the init
> and load this new module. Correct?

ACK. (It's just me - for now)

Upgrading kernels used to be a drop-in replacement, except for ISDN and 
(for 2.4 -> 2.6) v4l. I like it that way.
-- 
Top 100 things you don't want the sysadmin to say:
66. What do you mean you needed that directory?

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

Re: 3ware driver (3w-xxxx) in 2.6.10: procfs entry

[Kyle Moffett]

On Jan 19, 2005, at 23:49, Jason L Tibbitts III wrote:
I'm not sure why you indicate that no in-engineering toolset exists
for the 7000 cards.  It works fine on my 7810 and 7500-8 cards, as
well as a bunch of 8506-4LP cards and of course the 9500S-4LP cards I
have.  I don't think it would work on my 6800 cards, but those are
just running JBOD with software RAID so there wouldn't be much point.
It could be that I just completely missed it, but I went to the 3ware
site and chose "7000".  There was not a "CLI" item, so I assumed there
wasn't a specific CLI just for the 7000s.  I later, however, found
that the 9000 CLIs (Normal and In-Eng) worked fine, so I never looked
for any others, such as 8000 or 8500 CLIs.  I may have made a mistake,
but I couldn't find a CLI in the "In Engineering"->"7000" section, and
I had a working solution, so I didn't try elsewhere.
Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r  
!y?(-)
--END GEEK CODE BLOCK--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 3/4] use a rwsem for cpucontrol

[Rusty Russell]

On Wed, 2005-01-19 at 22:38 +0100, Dominik Brodowski wrote:
> Currently, lock_cpu_hotplug serializes multiple calls to cpufreq->target()
> on multiple CPUs even though that's unnecessary. Even further, it
> serializes these calls with totally unrelated other parts of the kernel...
> some ppc64 event reporting, some cache management, and so on. In my opinion
> locking should be done subsystem (and normally data-)specific, and disabling
> CPU hotplug should just do that.

Sure.

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Jack O'Quin]

Con Kolivas <[EMAIL PROTECTED]> writes:

> Jack O'Quin wrote:
>> Outstanding.  How do you get rid of that checkerboard grey
>> background in the graphs?
>
>> Con Kolivas <[EMAIL PROTECTED]> writes:
> Funny; that's the script you sent me so... beats me?

It's just one of the many things I don't understand about graphics.  

If I look at those png's locally (with gimp or gqview) they have a
dark grey checkerboard background.  If I look at them on the web (with
galeon), the background is white.  Go figure.  Maybe the file has no
background?  I dunno.

>> Looking at the graphs, your system has a substantial 4 to 6 msec delay
>> on approximately 40 second intervals, regardless of which scheduling
>> class or how many clients you run.  I'm guessing this is a recurring
>> long code path in the kernel and not a scheduling artifact at all.
>
> Probably. No matter what I do the hard drive seems to keep trying to
> spin down. Might be related.

I was misreading the x-axis.  They're actually every 20 sec.  My
system isn't doing that.

> in the background:
> while true ; do make clean && make ; done
>
> SCHED_ISO with 40 clients:
> *
> Timeout Count . . . . . . . . :(0)
> XRUN Count  . . . . . . . . . : 3
> Delay Count (>spare time) . . :20
> Delay Count (>1000 usecs) . . : 0
> Delay Maximum . . . . . . . . :  5841   usecs
> Cycle Maximum . . . . . . . . :   891   usecs
> Average DSP Load. . . . . . . :34.1 %
> Average CPU System Load . . . :10.7 %
> Average CPU User Load . . . . :87.8 %
> Average CPU Nice Load . . . . : 0.0 %
> Average CPU I/O Wait Load . . : 0.7 %
> Average CPU IRQ Load  . . . . : 0.8 %
> Average CPU Soft-IRQ Load . . : 0.0 %
> Average Interrupt Rate  . . . :  1711.4 /sec
> Average Context-Switch Rate . : 20751.6 /sec
> *

The scheduler seems to be working great.  

You're really getting hammered with those periodic 6 msec delays,
though.  The basic audio cycle is only 1.45 msec.
-- 
  joq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.11-rc1

[Daniel Gryniewicz]

On Wed, 2005-01-19 at 23:16 -0500, Dmitry Torokhov wrote:
> On Wednesday 19 January 2005 16:07, Daniel Gryniewicz wrote:
> > On Tue, 2005-01-11 at 21:09 -0800, Linus Torvalds wrote:
> > > Ok, the big merges after 2.6.10 are hopefully over, and 2.6.11-rc1 is out 
> > > there.
> > > 
> > 
> > 
> > > Peter Osterlund:
> > >   o input: Add ALPS touchpad driver, driver by Neil Brown, Peter
> > > Osterlund and Dmitry Torokhov, some fixes by Vojtech Pavlik.
> > 
> > 2.6.11-rc1 broke my ALPS touchpad.  I have a Dell Inspiron 8600, and
> > previously, I was patching my kernels with the patch from 
> > 
> > Message-Id: <[EMAIL PROTECTED]>
> > Subject: [RFT/PATCH 2.6] ALPS touchpad driver
> > 
> > and this worked fine.  I had the scroll zones and tapping, and so on,
> > working fine, and dmesg included indications that the Alps was detected:
> > 
> > Jan 19 10:09:40 athena alps.c: E6 report: 00 00 64
> > Jan 19 10:09:40 athena alps.c: E7 report: 73 02 0a
> > Jan 19 10:09:40 athena alps.c: E6 report: 00 00 64
> > Jan 19 10:09:40 athena alps.c: E7 report: 73 02 0a
> > Jan 19 10:09:40 athena alps.c: Status: 15 01 0a
> > Jan 19 10:09:40 athena ALPS Touchpad (Glidepoint) detected
> > Jan 19 10:09:40 athena alps.c: Status: 15 01 0a
> > Jan 19 10:09:40 athena input: AlpsPS/2 ALPS TouchPad on isa0060/serio1
> > 
> > 
> 
> Hi,
> 
> Could you please try this patch by Peter Osterlund:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel=110513688110246=raw
> 
> It looks like Kensington and ALPS hate each other.
> 

That fixed it, thanks.  I hope this can make it in before 2.6.11 final,
but if it doesn't, I'll just patch it in.

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/

Re: 3ware driver (3w-xxxx) in 2.6.10: procfs entry

[Kyle Moffett]

On Jan 19, 2005, at 21:23, Jason L Tibbitts III wrote:
"PD" == Peter Daum <[EMAIL PROTECTED]> writes:
You should report the problems you find to them.  They do indicate (in
the knowledge base on their web site) that you're going to need the
in-engineering files to run on the latest kernels.  It's only recently
that the newer tools acquired the ability to control older
controllers.
According to a recent post from a 3ware employee on linux-ide-arrays,
a proper release is expected in February.  Obviously the best solution
is that they just give us the source to these tools so that we can fix
them ourselves.  Knowing that isn't going to happen I'm happy they're
at least giving us something while they catch up with the speed of
kernel progress.
I can verify the fact that info is busted when the controller is
verifying the array; I'll gather some more info and pass this on to
3ware.
We have some 3ware 7000 ATA-RAID controllers that I've tested with  
various
versions of the tools trying to get them to work:
+---+--- 
++
| Kernel| CLI Utility   | Functionality/Limitations  
 |
+---+--- 
++
|   | 7000 - Stable | Works great, everything OK (Of course  
:-D) |
| Debian 2.4.28 |   |
 |
|   | 7000 - In-Eng | [N/A] No such tool exists! 
 |
+---+--- 
++
|   | 7000 - Stable | Works ok, except some operations fail  
with |
|   |   | unusual errors, and the info stuff  
doesn't |
|   |   | really work properly   
 |
|   |   |
 |
|   | 7000 - In-Eng | [N/A] No such tool exists! 
 |
|   |   |
 |
|   | 9000 - Stable | Works great, everything OK, although  
some  |
|   |   | operations have status errors, though  
they |
|   |   | still function as expected.  This one  
has  |
| Debian 2.6.8  |   | an interesting new interface that I  
like.  |
|   |   |
 |
|   | 9000 - In-Eng | This one lacks the new interface that  
is   |
|   |   | present in the tested release, which  
is|
|   |   | kind of weird, given that it is a  
much |
|   |   | newer version.  It also appears to  
work|
|   |   | great on the 3ware 7000 card, but  
without  |
|   |   | the weird errors that plagued the  
stable   |
|   |   | tool.  This looks promising, but I  
kinda   |
|   |   | liked the interface of the 9000 tool.  
 |
+---+--- 
++

Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r   
!y?(-)
--END GEEK CODE BLOCK--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]sched: Isochronous class v2 for unprivileged soft rt scheduling

[utz lehmann]

On Thu, 2005-01-20 at 11:33 +1100, Con Kolivas wrote:
> utz lehmann wrote:
> > @@ -2406,6 +2489,10 @@ void scheduler_tick(void)
> > task_t *p = current;
> >  
> > rq->timestamp_last_tick = sched_clock();
> > +   if (iso_task(p) && !rq->iso_refractory)
> > +   inc_iso_ticks(rq, p);
> > +   else 
> > +   dec_iso_ticks(rq, p);
> > 
> > scheduler_tick() is not only called by the timer interrupt but also form
> > the fork code. Is this intended? I think the accounting for
> 
> The calling from fork code only occurs if there is one millisecond of 
> time_slice left so it will only very rarely be hit. I dont think this 
> accounting problem is worth worrying about.

I had experimented with throttling runaway RT tasks. I use a similar
accounting. I saw a difference between counting with or without the
calling from fork. If i remember correctly the timeout expired too fast
if the non-RT load was "while /bin/true; do :; done".
With "while true; do :; done" ("true" is bash buildin) it worked good.
But maybe it's not important in the real world.

> 
> > Futher on i see a fundamental problem with this accounting for
> > iso_refractory. What if i manage as unprivileged user to run a SCHED_ISO
> > task which consumes all cpu and only sleeps very short during the timer
> > interrupt? I think this will nearly lockup or very slow down the system.
> > The iso_cpu limit can't guaranteed.
> 
> Right you are. The cpu accounting uses primitive on-interrupt run time 
> which as we know is not infallible. To extend this I'll have to keep a 
> timer based on the sched_clock which is already implemented. That's 
> something for me to work on.

If i understand sched_clock correctly it only has higher resolution if
you can use tsc. In the non tsc case it's jiffies based. (On x86).
I think you can easily fool a timer tick/jiffies based accounting and do
a local DoS.
Making SCHED_ISO privileged if you don't have a high resolution
sched_clock is ugly.
I really like the idea of a unprivileged SCHED_ISO but it has to be safe
for a multi user system. And the kernel default should be safe for multi
user.

cheers
utz

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

Re: COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6

[Chris Bruner]

FYI, I found that the problem I was having was caused by the "BIOS Enhanced 
Disk Drives" turned on.   It was on in previous versions as well, and they 
worked ok, so I assume that something has changed. In anycase turning it off 
fixed my problem.

Chris Bruner

On Wed January 19 2005 06:13 pm, Janos Farkas wrote:
> Hi Andi!
>
> I had difficulties booting recent rc1-bkN kernels on at least two
> Athlon machines (but somehow, on an *old* Pentium laptop booted with the
> a very similar system just fine).
>
> The kernel just hung very early, just after displaying "BIOS data check
> successful" by lilo (22.6.1).  Ctrl-Alt-Del worked to reboot, but
> nothing else was shown.
>
> It is a similar experience to Chris Bruner's post here:
> > http://article.gmane.org/gmane.linux.kernel/271352
>
> I also recall someone having similar problem with Opterons too, but
> can't find just now..
>
> rc1-bk6 didn't boot, and thus I started checking revisions:
> rc1-bk3 did boot (as well as plain rc1)
> rc1-bk4 didn't boot
>
> rc1-bk7 booted *after* reverting the patch below:
> > 4 days ak 1.2329.1.38 [PATCH] x86_64/i386: increase command line size
> > Enlarge i386/x86-64 kernel command line to 2k
> > This is useful when the kernel command line is used to pass other
> > information to initrds or installers.
> > On i386 it was duplicated for unknown reasons.
> > Signed-off-by: Andi Kleen
> > Signed-off-by: Andrew Morton
> > Signed-off-by: Linus Torvalds
>
> While arguably it's not a completely scientific approach (no plain bk7,
> and no bk6 reverted was tested), I'm inclined to say this was my
> problem...
>
> Isn't this define a lilo dependence?

-- 
   I say, if your knees aren't green by the end of the day, you ought to
seriously re-examine your life.  -- Calvin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.11-rc1

[Dmitry Torokhov]

On Wednesday 19 January 2005 16:07, Daniel Gryniewicz wrote:
> On Tue, 2005-01-11 at 21:09 -0800, Linus Torvalds wrote:
> > Ok, the big merges after 2.6.10 are hopefully over, and 2.6.11-rc1 is out 
> > there.
> > 
> 
> 
> > Peter Osterlund:
> >   o input: Add ALPS touchpad driver, driver by Neil Brown, Peter
> > Osterlund and Dmitry Torokhov, some fixes by Vojtech Pavlik.
> 
> 2.6.11-rc1 broke my ALPS touchpad.  I have a Dell Inspiron 8600, and
> previously, I was patching my kernels with the patch from 
> 
> Message-Id: <[EMAIL PROTECTED]>
> Subject: [RFT/PATCH 2.6] ALPS touchpad driver
> 
> and this worked fine.  I had the scroll zones and tapping, and so on,
> working fine, and dmesg included indications that the Alps was detected:
> 
> Jan 19 10:09:40 athena alps.c: E6 report: 00 00 64
> Jan 19 10:09:40 athena alps.c: E7 report: 73 02 0a
> Jan 19 10:09:40 athena alps.c: E6 report: 00 00 64
> Jan 19 10:09:40 athena alps.c: E7 report: 73 02 0a
> Jan 19 10:09:40 athena alps.c: Status: 15 01 0a
> Jan 19 10:09:40 athena ALPS Touchpad (Glidepoint) detected
> Jan 19 10:09:40 athena alps.c: Status: 15 01 0a
> Jan 19 10:09:40 athena input: AlpsPS/2 ALPS TouchPad on isa0060/serio1
> 
> 

Hi,

Could you please try this patch by Peter Osterlund:

http://marc.theaimsgroup.com/?l=linux-kernel=110513688110246=raw

It looks like Kensington and ALPS hate each other.

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

Does it degrade significantly with a compile running in the background?
Check results below.
Full results and pretty pictures available here:
http://ck.kolivas.org/patches/SCHED_ISO/iso2-benchmarks/
More pretty pictures with compile load on SCHED_ISO put up there now.
Outstanding.  

How do you get rid of that checkerboard grey background in the graphs?
Funny; that's the script you sent me so... beats me?
Looking at the graphs, your system has a substantial 4 to 6 msec delay
on approximately 40 second intervals, regardless of which scheduling
class or how many clients you run.  I'm guessing this is a recurring
long code path in the kernel and not a scheduling artifact at all.
Probably. No matter what I do the hard drive seems to keep trying to 
spin down. Might be related.

in the background:
while true ; do make clean && make ; done
SCHED_ISO with 40 clients:
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 3
Delay Count (>spare time) . . :20
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :  5841   usecs
Cycle Maximum . . . . . . . . :   891   usecs
Average DSP Load. . . . . . . :34.1 %
Average CPU System Load . . . :10.7 %
Average CPU User Load . . . . :87.8 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.7 %
Average CPU IRQ Load  . . . . : 0.8 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1711.4 /sec
Average Context-Switch Rate . : 20751.6 /sec
*
Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] dynamic tick patch

[Zwane Mwaikambo]

On Tue, 18 Jan 2005, Tony Lindgren wrote:

> Hi all,
> 
> Attached is the dynamic tick patch for x86 to play with
> as I promised in few threads earlier on this list.[1][2]
> 
> The dynamic tick patch does following:
> 
> - Separates timer interrupts from updating system time
> 
> - Allows updating time from other interrupts in addition
>   to timer interrupt
> 
> - Makes timer tick dynamic
> 
> - Allows power management modules to take advantage of the
>   idle time inbetween skipped ticks
> 
> - Might help with the whistling caps?

This doesn't seem to cover the local APIC timer, what do you do about the 
1kHz tick which it's programmed to do?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] agp_backend: remove drm_agp_t & inter_module_ V1 [1/1]

[Dave Jones]

On Wed, Jan 19, 2005 at 06:38:32PM -0800, Chris Wedgwood wrote:
 > What extremely obvious thing am I missing which prevents up from
 > kill drm_agp_t and the inter_module_register, etc. code that goes with
 > it?

Gar, this is the 3rd copy of this patch I've got.
I wanted the dust to settle on the agp carnage in -mm before
merging anything else, but tbh, I'm so sick of the sight
of this patch coming around every few days I'm going to merge
it and let Andrew deal with any resulting breakage when he
cuts the next -mm

Dave

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

Re: [PATCH] Alps touchpad probing failure

[Dmitry Torokhov]

On Wednesday 19 January 2005 18:23, Daniel Caujolle-Bert wrote:
> Hi,
> 
>  With 2.6.11-rc1 bk6 and bk7 (didn't tried with < bk6), my alps touchpad is 
> no 
> more correctly probed, it's recognised as a standard PS/2 mouse.
>  So, with this trivial two line patch, everything is working again.
> 
> Cheers.

Hi,

I think Peter Osterlund has send similar patch recently - the breakage
appears to be caused by Kensington mouse detection. It looks like these
two don't like each other.

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

Re: [PATCH RFC] 'spinlock/rwlock fixes' V3 [1/1]

[Andrew Morton]

Chris Wedgwood <[EMAIL PROTECTED]> wrote:
>
> On Wed, Jan 19, 2005 at 07:01:04PM -0800, Andrew Morton wrote:
> 
> > ... how about we simply nuke this statement:
> >
> > Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> > >
> > >   if (!spin_is_locked(>sighand->siglock) &&
> > >  -!rwlock_is_locked(_lock))
> > >  +!rwlock_write_locked(_lock))
> >
> > and be done with the whole thing?
> 
> I'm all for killing that.  I'll happily send a patch once the dust
> settles.
> 
> It still isn't enough to rid of the rwlock_read_locked and
> rwlock_write_locked usage in kernel/spinlock.c as those are needed for
> the cpu_relax() calls so we have to decide on suitable names still...

Oh crap, you're right.  There's not much we can do about that.

I have a do-seven-things-at-once patch from Ingo here which touches all
this stuff so cannot really go backwards or forwards.

And your patch is a do-four-things-at-once patch.  Can you split it up please?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time

[David McCullough]

Jivin James Morris lays it down ...
> On Sat, 15 Jan 2005, Fruhwirth Clemens wrote:
> 
> > However, developing two different APIs isn't particular efficient. I
> > know, at the moment there isn't much choice, as J.Morris hasn't commited
> > to acrypto in anyway.
> 
> There is also the OCF port (OpenBSD crypto framework) to consider, if 
> permission to dual license from the original authors can be obtained.

For anyone looking for the OCF port for linux,  you can find the latest
release here:

http://lists.logix.cz/pipermail/cryptoapi/2004/000261.html

One of the drivers uses the existing kernel crypto API to implement
a SW crypto engine for OCF.

As for permission to use a dual license,  I will gladly approach the
authors if others feel it is important to know the possibility of it at this
point,

Cheers,
Davidm

-- 
David McCullough, [EMAIL PROTECTED]  Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security   Fx:+61 7 38913630 http://www.uCdot.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 5/5] Disallow in-inode attributes for reserved inodes

[Andreas Gruenbacher]

When creating a filesystem with inodes bigger than 128 bytes, mke2fs
fails to clear out bytes beyond EXT3_GOOD_OLD_INODE_SIZE in all inodes
it creates (the journal, the filesystem root, and lost+found). We would
require a zeroed-out i_extra_isize field but we don't get it, so
disallow in-inode attributes for those inodes.

Add an i_extra_isize sanity check.

Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>

Index: linux-2.6.11-latest/fs/ext3/inode.c
===
--- linux-2.6.11-latest.orig/fs/ext3/inode.c
+++ linux-2.6.11-latest/fs/ext3/inode.c
@@ -2493,15 +2493,30 @@ void ext3_read_inode(struct inode * inod
ei->i_data[block] = raw_inode->i_block[block];
INIT_LIST_HEAD(>i_orphan);
 
-   ei->i_extra_isize =
-   (EXT3_INODE_SIZE(inode->i_sb) > EXT3_GOOD_OLD_INODE_SIZE) ?
-   le16_to_cpu(raw_inode->i_extra_isize) : 0;
-   if (ei->i_extra_isize) {
-   __le32 *magic = (void *)raw_inode + EXT3_GOOD_OLD_INODE_SIZE +
-   ei->i_extra_isize;
-   if (le32_to_cpu(*magic))
-ei->i_state |= EXT3_STATE_XATTR;
-   }
+   if (inode->i_ino >= EXT3_FIRST_INO(inode->i_sb) + 1 &&
+   EXT3_INODE_SIZE(inode->i_sb) > EXT3_GOOD_OLD_INODE_SIZE) {
+   /*
+* When mke2fs creates big inodes it does not zero out
+* the unused bytes above EXT3_GOOD_OLD_INODE_SIZE,
+* so ignore those first few inodes.
+*/
+   ei->i_extra_isize = le16_to_cpu(raw_inode->i_extra_isize);
+   if (EXT3_GOOD_OLD_INODE_SIZE + ei->i_extra_isize >
+   EXT3_INODE_SIZE(inode->i_sb))
+   goto bad_inode;
+   if (ei->i_extra_isize == 0) {
+   /* The extra space is currently unused. Use it. */
+   ei->i_extra_isize = sizeof(struct ext3_inode) -
+   EXT3_GOOD_OLD_INODE_SIZE;
+   } else {
+   __le32 *magic = (void *)raw_inode +
+   EXT3_GOOD_OLD_INODE_SIZE +
+   ei->i_extra_isize;
+   if (*magic == cpu_to_le32(EXT3_XATTR_MAGIC))
+ei->i_state |= EXT3_STATE_XATTR;
+   }
+   } else
+   ei->i_extra_isize = 0;
 
if (S_ISREG(inode->i_mode)) {
inode->i_op = _file_inode_operations;

--
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX PRODUCTS GMBH

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/5] Set the EXT3_FEATURE_COMPAT_EXT_ATTR for in-inode xattrs

[Andreas Gruenbacher]

The xattr feature was only set when creating an xattr block. Also set it
when creating in-inode xattrs.

Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>

Index: linux-2.6.11-latest/fs/ext3/xattr.c
===
--- linux-2.6.11-latest.orig/fs/ext3/xattr.c
+++ linux-2.6.11-latest/fs/ext3/xattr.c
@@ -823,7 +823,6 @@ getblk_failed:
error = ext3_journal_dirty_metadata(handle, new_bh);
if (error)
goto cleanup;
-   ext3_xattr_update_super_block(handle, sb);
}
}
 
@@ -1001,6 +1000,7 @@ ext3_xattr_set_handle(handle_t *handle, 
}
}
if (!error) {
+   ext3_xattr_update_super_block(handle, inode->i_sb);
inode->i_ctime = CURRENT_TIME_SEC;
error = ext3_mark_iloc_dirty(handle, inode, );
/*

--
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX PRODUCTS GMBH

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

[patch 4/5] Fix i_extra_isize check

[Andreas Gruenbacher]

We are checking for (EXT3_SB(inode->i_sb)->s_inode_size <=
EXT3_GOOD_OLD_INODE_SIZE) to find out if we can set in-inode attributes;
the test fails for inodes that have been created before the ea-in-inode
patch. Those inodes have (i_extra_isize == 0), so we end up with the
attributes overlapping the i_extra_isize field. Checking for
(i_extra_isize == 0) instead fixes this case.

The EXT3_STATE_XATTR flag is only set if (i_extra_isize > 0) and the
inodes has in-inode attributes, so that is enough in the first two
tests.

Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>

Index: linux-2.6.11-latest/fs/ext3/xattr.c
===
--- linux-2.6.11-latest.orig/fs/ext3/xattr.c
+++ linux-2.6.11-latest/fs/ext3/xattr.c
@@ -272,8 +272,7 @@ ext3_xattr_ibody_get(struct inode *inode
void *end;
int error;
 
-   if (EXT3_SB(inode->i_sb)->s_inode_size <= EXT3_GOOD_OLD_INODE_SIZE ||
-   !(EXT3_I(inode)->i_state & EXT3_STATE_XATTR))
+   if (!(EXT3_I(inode)->i_state & EXT3_STATE_XATTR))
return -ENODATA;
error = ext3_get_inode_loc(inode, );
if (error)
@@ -399,8 +398,7 @@ ext3_xattr_ibody_list(struct inode *inod
void *end;
int error;
 
-   if (EXT3_SB(inode->i_sb)->s_inode_size <= EXT3_GOOD_OLD_INODE_SIZE ||
-   !(EXT3_I(inode)->i_state & EXT3_STATE_XATTR))
+   if (!(EXT3_I(inode)->i_state & EXT3_STATE_XATTR))
return 0;
error = ext3_get_inode_loc(inode, );
if (error)
@@ -865,7 +863,7 @@ ext3_xattr_ibody_find(struct inode *inod
struct ext3_inode *raw_inode;
int error;
 
-   if (EXT3_SB(inode->i_sb)->s_inode_size <= EXT3_GOOD_OLD_INODE_SIZE)
+   if (EXT3_I(inode)->i_extra_isize == 0)
return 0;
raw_inode = ext3_raw_inode(>iloc);
header = IHDR(inode, raw_inode);
@@ -896,7 +894,7 @@ ext3_xattr_ibody_set(handle_t *handle, s
struct ext3_xattr_search *s = >s;
int error;
 
-   if (EXT3_SB(inode->i_sb)->s_inode_size <= EXT3_GOOD_OLD_INODE_SIZE)
+   if (EXT3_I(inode)->i_extra_isize == 0)
return -ENOSPC;
error = ext3_xattr_set_entry(i, s);
if (error)

--
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX PRODUCTS GMBH

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

[Andreas Gruenbacher]

In-inode xattr entry descriptors are unsorted.

Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>

Index: linux-2.6.11-latest/fs/ext3/xattr.c
===
--- linux-2.6.11-latest.orig/fs/ext3/xattr.c
+++ linux-2.6.11-latest/fs/ext3/xattr.c
@@ -37,9 +37,9 @@
  *   | value 2  | |
  *   +--+
  *
- * The header is followed by multiple entry descriptors. Descriptors are
- * kept sorted. The attribute values are aligned to the end of the block
- * in no specific order.
+ * The header is followed by multiple entry descriptors. In disk blocks, the
+ * entry descriptors are kept sorted. In inodes, they are unsorted. The
+ * attribute values are aligned to the end of the block in no specific order.
  *
  * Locking strategy
  * 

--
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX PRODUCTS GMBH

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

[patch 1/5] No lock needed when freeing inode

[Andreas Gruenbacher]

ext3_xattr_delete_inode is called from ext3_free_inode which always
has exclusive access to the inode, so there is no need to take the
xattr semaphore.

Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>

Index: linux-2.6.11-latest/fs/ext3/xattr.c
===
--- linux-2.6.11-latest.orig/fs/ext3/xattr.c
+++ linux-2.6.11-latest/fs/ext3/xattr.c
@@ -1066,7 +1066,6 @@ ext3_xattr_delete_inode(handle_t *handle
 {
struct buffer_head *bh = NULL;
 
-   down_write(_I(inode)->xattr_sem);
if (!EXT3_I(inode)->i_file_acl)
goto cleanup;
bh = sb_bread(inode->i_sb, EXT3_I(inode)->i_file_acl);
@@ -1088,7 +1087,6 @@ ext3_xattr_delete_inode(handle_t *handle
 
 cleanup:
brelse(bh);
-   up_write(_I(inode)->xattr_sem);
 }
 
 /*

--
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX PRODUCTS GMBH

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

[ea-in-inode 0/5] Further fixes

[Andreas Gruenbacher]

Hello,

here is a set of fixes for ext3 in-inode attributes:

patches/ea-xattr-nolock.diff
  No lock needed when freeing inode

  The effect of the additional lock taking is very minor, but
  it's still unnecessary.

patches/ea-xattr-update-sb.diff
  Set the EXT3_FEATURE_COMPAT_EXT_ATTR for in-inode xattrs

  The EXT_ATTR filesystem feature was set for xattr blocks, but not
  for in-inode attributes.

patches/ea-xattr-doc.diff
  Documentation fix

patches/ea-xattr-no-extra_isize.diff
  Fix i_extra_isize check

  Filesystem corruption fix.

patches/ea-xattr-reserved-inodes.diff
  Disallow in-inode attributes for reserved inodes

  Filesystem corruption fix.


Regards,
--
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX PRODUCTS GMBH

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

Re: [PATCH RFC] 'spinlock/rwlock fixes' V3 [1/1]

[Chris Wedgwood]

On Wed, Jan 19, 2005 at 07:01:04PM -0800, Andrew Morton wrote:

> ... how about we simply nuke this statement:
>
> Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> >
> > if (!spin_is_locked(>sighand->siglock) &&
> >  -  !rwlock_is_locked(_lock))
> >  +  !rwlock_write_locked(_lock))
>
> and be done with the whole thing?

I'm all for killing that.  I'll happily send a patch once the dust
settles.

It still isn't enough to rid of the rwlock_read_locked and
rwlock_write_locked usage in kernel/spinlock.c as those are needed for
the cpu_relax() calls so we have to decide on suitable names still...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: User space out of memory approach

[Edjard Souza Mota]

> > > If my system needs the OOM killer, it's usurally unresponsive to most
> > > userspace applications. A normal daemon would be swapped out before the
> > > runaway dhcpd grows larger than the web cache. It would have to be a 
> > > mlocked
> > > RT task started from early userspace. It would be difficult to set up 
> > > (unless
> > > you upgrade your distro), and almost nobody will feel like tweaking it to
> > > take the benefit (OOM == -ECANNOTHAPPEN).
> >
> > Please correct me if I got it wrong: as deamon in this case is not a normal 
> > one,
> > since it never gets rate for its own safety,
> 
> That's it's own task, it must make sure not to commit suicide. I forgot
> about that.

Ok.

> > then it needs an RT lock whenever
> > system boots.
> 
> It may not be blocked by a random RT task iff the RT task is supposed to
> be OOM-killed. Therefore it *MUST* run at the highest priority and be
> locked into the RAM.
> 
> It *SHOULD* be run at boot time, too, just in case it's needed early.

Yes. That's the idea of the application we posted to test the oom
killer ranking at
user space. At least, we are working to put it at boot time and these
suggestions are very helpful.

> > > What about creating a linked list of (stackable) algorhithms which can be
> > > extended by loading modules and resorted using {proc,sys}fs? It will avoid
> > > the extra process, the extra CPU time (and task switches) to frequently
> > > update the list and I think it will decrease the typical amount of used
> > > memory, too.
> >
> > Wouldn't this bring the (set of ) ranking algorithm(s) back to the kernel? 
> > This
> > is exactly what we're trying to avoid.
> 
> You're trying to avoid it in order to let admins try other ranking
> algorhithms (at least that's what I read). The module approach seems to be
> flexible enough to do that, and it avoids the mentioned issues. If you
> really want a userspace daemon, it can be controled by a module.-)

Yes, your reading is correct, but this choice should take into account
the "patterns"
of how memory is allocated for user's mostly used applications. Why?
The closer the
ranking gets to "The Best choice" the longer it will take to invoke
oom killer again.

I am wondering how could a module control a user space deamon if it
hasn't started
yet? I mean, processes at user space are supposed to start only after
all modules
are loaded (those loadable at boot time). So, this user space deamon
would break
this standard. But if we manage to have a special module that takes
care of loading
this stack of  OOM Killer ranking algorithms, then the deamon would
not need to break
the default order of loading modules. The init could be changed to
start the deamon,
and then the module would start controlling it. Am I right?

So that's why people is complaining every distro would have to update the init
and load this new module. Correct?

> 
> I 'm thinking of something like that:
> 
> [X] support stacking of OOM killer ranking algorhythms
> [X] Task blessing OOM filter
> [X] Userspace OOM ranking daemon
> [X] Default OOM killer ranking
> 
> -vs-
> 
> [ ] support stacking of OOM killer ranking algorhythms
> ( ) Userspace OOM ranking daemon
> (o) Default OOM killer ranking
> 

Very interesting idea. Will take that into account. Thanks a lot.

-- 
"In a world without fences ... who needs Gates?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] dynamic tick patch

[Valdis . Kletnieks]

On Wed, 19 Jan 2005 14:59:20 PST, George Anzinger said:

> allows the PIT to be the "gold standard" in time that it is designed to be. 
> The 
> wake up interrupt, then needs to come from an independent timer.  My patch 
> requires a local APIC for this.  Patch is available at 
> http://sourceforge.net/projects/high-res-timers/

Foo. and me with a BIOS-borked LAPIC.  Anybody have helpful hints on how to
get Dell to fix a laptop BIOS(*), or are you all too busy dying of hysterical 
laughter?

Dell Latitude C840, running bios A13 (most recent). I *know* it was borked
around A08, and the bios release notes haven't mentioned fixing it.  I wonder
if it's worth re-checking anyhow


pgpT2zsRWL9u5.pgp
Description: PGP signature

Re: [PATCH] aoe: add documentation for udev users

[Bodo Eggert]

Ed L Cashin <[EMAIL PROTECTED]> wrote:

> +if test -z "$conf"; then
> +conf="`find /etc -type f -name udev.conf 2> /dev/null`"
> +fi
> +if test -z "$conf" || test ! -r $conf; then
> +echo "$me Error: could not find readable udev.conf in /etc" 1>&2
> +exit 1
> +fi

This will fail and print
---
bash: test: etc/udev.conf: binary operator expected
---
if there is more than one udev.conf.

Fix: Always put quotes around variables.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 Backport of pci cardbus number enumeration from 2.6 to 2.4.29

[Paul Marrons]

Martin,
I forgot to attach the actually patch file in my last mail. It's 
attached this time with a copy of my previous email below:

Hi Martin,
To overcome a problem with my laptop cardbus not being assigned the 
correct bus number in 2.4.29 (I originally did this change for 2.4.27) I 
backported a portion of the code in the 2.6 kernel drivers/pci/pci.c 
file. I did this because I noticed that only 2.6 assigned the correct 
bus number and I specifically need to run 2.4.X because of a driver I 
need that is not 2.6 compatible. Basically without this change on my 
laptop (Thinkpad 240) both the main PCI bus and cardbus bridge both get 
assigned bus#0 and as a result any cardbus devices present are not 
correctly detected and allocated any resources, in addition the 
/proc/bus/pci contains two '0' entries and tools such as lspci fail to 
work.

I am aware of people overcoming this problem (with my model of laptop) 
by setting defining pcibios_assign_all_busses() as 1. But this backport 
is a superior solution to the problem.

The few small changes are isolated to pci_add_new_bus and 
pci_scan_bridge. I hope you will be able to incorporate them into the 
next 2.4 kernel release.

If there is anything else I need to do please let me know.
Regards,
Paul Marrons.
--- pci.c.orig  2004-11-17 11:54:21.0 +
+++ pci.c   2005-01-20 02:01:26.0 +
@@ -1,3 +1,4 @@
+
 /*
  * $Id: pci.c,v 1.91 1999/01/21 13:34:01 davem Exp $
  *
@@ -1238,8 +1239,6 @@
 * Allocate a new bus, and inherit stuff from the parent..
 */
child = pci_alloc_bus();
-   if (!child)
-   return NULL;
 
list_add_tail(>node, >children);
child->self = dev;
@@ -1286,29 +1285,25 @@
 
pci_read_config_dword(dev, PCI_PRIMARY_BUS, );
DBG("Scanning behind PCI bridge %s, config %06x, pass %d\n", 
dev->slot_name, buses & 0xff, pass);
-   if ((buses & 0x00) && !pcibios_assign_all_busses()) {
+   if ((buses & 0x00) && !pcibios_assign_all_busses() && !is_cardbus) {
/*
 * Bus already configured by firmware, process it in the first
 * pass and just note the configuration.
 */
+   unsigned busnr,cmax;
+   busnr = (buses >> 8)&0xFF;
if (pass)
return max;
-
-   child = pci_add_new_bus(bus, dev, 0);
-   if (!child)
-   return max;
-
+   child = pci_add_new_bus(bus, dev, busnr);
child->primary = buses & 0xFF;
-   child->secondary = (buses >> 8) & 0xFF;
child->subordinate = (buses >> 16) & 0xFF;
child->number = child->secondary;
-   if (!is_cardbus) {
-   unsigned int cmax = pci_do_scan_bus(child);
-   if (cmax > max) max = cmax;
-   } else {
-   unsigned int cmax = child->subordinate;
-   if (cmax > max) max = cmax;
-   }
+   
+   cmax = pci_do_scan_bus(child);
+   if(cmax > max)
+max=cmax;
+   if(child->subordinate > max)
+max = child->subordinate;
} else {
/*
 * We need to assign a number to this bus which we always
@@ -1322,13 +1317,19 @@
pci_write_config_word(dev, PCI_STATUS, 0x);
 
child = pci_add_new_bus(bus, dev, ++max);
-   if (!child)
-   return max;
-
buses = (buses & 0xff00)
  | ((unsigned int)(child->primary) <<  0)
  | ((unsigned int)(child->secondary)   <<  8)
  | ((unsigned int)(child->subordinate) << 16);
+   /*
+* yenta.c forces a secondary latency timer of 176.
+* Copy that behaviour here.
+*/
+   if (is_cardbus) {
+   buses &= ~0xff00;
+   buses |= 176 << 24;
+   }
+  
/*
 * We need to blast all three values with a single write.
 */

Re: [PATCH RFC] 'spinlock/rwlock fixes' V3 [1/1]

[Andrew Morton]

Given the general confusion and the difficulty of defining and
understanding the semantics of these predicates.  And given that the
foo_is_locked() predicates have a history of being used to implement
ghastly kludges, how about we simply nuke this statement:

Chris Wedgwood <[EMAIL PROTECTED]> wrote:
>
>   if (!spin_is_locked(>sighand->siglock) &&
>  -!rwlock_is_locked(_lock))
>  +!rwlock_write_locked(_lock))

and be done with the whole thing?

I mean, do we really want these things in the kernel anyway?  We've never
needed them before.

If we raly need the debug check, just do

BUG_ON(read_trylock(...))

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

Backport of pci cardbus number enumeration from 2.6 to 2.4.29

[Paul Marrons]

Hi Martin,
To overcome a problem with my laptop cardbus not being assigned the 
correct bus number in 2.4.29 (I originally did this change for 2.4.27) I 
backported a portion of the code in the 2.6 kernel drivers/pci/pci.c 
file. I did this because I noticed that only 2.6 assigned the correct 
bus number and I specifically need to run 2.4.X because of a driver I 
need that is not 2.6 compatible. Basically without this change on my 
laptop (Thinkpad 240) both the main PCI bus and cardbus bridge both get 
assigned bus#0 and as a result any cardbus devices present are not 
correctly detected and allocated any resources, in addition the 
/proc/bus/pci contains two '0' entries and tools such as lspci fail to 
work.

I am aware of people overcoming this problem (with my model of laptop) 
by setting defining pcibios_assign_all_busses() as 1. But this backport 
is a superior solution to the problem.

The few small changes are isolated to pci_add_new_bus and 
pci_scan_bridge. I hope you will be able to incorporate them into the 
next 2.4 kernel release.

If there is anything else I need to do please let me know.
Regards,
Paul Marrons.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: [2.6 patch] let BLK_DEV_UB depend on USB_STORAGE=n

[Matthew Dharm]

On Wed, Jan 19, 2005 at 02:07:07PM -0800, Greg KH wrote:
> On Thu, Dec 23, 2004 at 03:40:31AM +0100, Adrian Bunk wrote:
> > On Sun, Dec 19, 2004 at 04:31:46PM -0800, Greg KH wrote:
> > > On Mon, Dec 20, 2004 at 01:16:44AM +0100, Adrian Bunk wrote:
> > > > I've already seen people crippling their usb-storage driver with 
> > > > enabling BLK_DEV_UB - and I doubt the warning in the help text added 
> > > > after 2.6.9 will fix all such problems.
> > > > 
> > > > Is there except for kernel size any good reason for using BLK_DEV_UB 
> > > > instead of USB_STORAGE?
> > > 
> > > You don't want to use the scsi layer?  You like the stability of it at
> > > times?  :)
> > > 
> > > > If not, I'd suggest the patch below to let BLK_DEV_UB depend
> > > > on EMBEDDED.
> > > 
> > > No, it's good for non-embedded boxes too.
> > 
> > 
> > My current understanding is:
> > - BLK_DEV_UB supports a subset of what USB_STORAGE can support
> > - for an average user, there's no reason to enable BLK_DEV_UB
> > - if you really know what you are doing, there might be several reasons
> >   why you might want to use BLK_DEV_UB
> 
> I have been running with just the code portion of this patch for a while
> now, with good results (no Kconfig changes.)
> 
> Pete and Matt, do you mind me applying the following portion of the
> patch to the kernel tree?

I have no objection.

Matt

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

E:  You run this ship with Windows?!  YOU IDIOT!
L:  Give me a break, it came bundled with the computer!
-- ESR and Lan Solaris
User Friendly, 12/8/1998


pgp7YGciMjT7c.pgp
Description: PGP signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Jack O'Quin]

Con Kolivas <[EMAIL PROTECTED]> writes:

> Jack O'Quin wrote:
>> Excellent.  Judging by the DSP Load, your machine seems to run almost
>> twice as fast as my 1.5GHz Athlon (surprising).  You might want to try
>
> Not really surprising; the 2Mb cache makes this a damn fine cpu, if
> not necessarily across the board :)

I wonder if most of the critical DSP cycle fits in the cache?

Does it degrade significantly with a compile running in the background?

> Full results and pretty pictures available here:
> http://ck.kolivas.org/patches/SCHED_ISO/iso2-benchmarks/

Outstanding.  

How do you get rid of that checkerboard grey background in the graphs?

Looking at the graphs, your system has a substantial 4 to 6 msec delay
on approximately 40 second intervals, regardless of which scheduling
class or how many clients you run.  I'm guessing this is a recurring
long code path in the kernel and not a scheduling artifact at all.
-- 
  joq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 RFC] 'spinlock/rwlock fixes' V3 [1/1]

[Chris Wedgwood]

On Thu, Jan 20, 2005 at 08:43:30AM +1100, Paul Mackerras wrote:

> I suggest read_poll(), write_poll(), spin_poll(), which are like
> {read,write,spin}_trylock but don't do the atomic op to get the
> lock, that is, they don't change the lock value but return true if
> the trylock would succeed, assuming no other cpu takes the lock in
> the meantime.

I'm not personally convinced *_poll is any clearer really, I would if
this is vague prefer longer more obvious names but that's just me.

Because spin_is_locked is used in quite a few places I would leave
that one alone for now --- I'm not saying we can't change this name,
but it should be a separate issue IMO.

Because rwlock_is_locked isn't used in many places changing that isn't
a big deal.

As a compromise I have the following patch in my quilt tree based upon
what a few people have said in this thread already.  This is again the
"-CURRENT bk" tree as of a few minutes ago and seems to be working as
expected.

  * i386: rename spinlock_t -> lock to slock to catch possible
macro abuse problems

  * i386, ia64: rename rwlock_is_locked to rwlock_write_locked as this
is IMO a better name

  * i386, ia64: add rwlock_read_locked (if people are OK with these, I
can do the other architectures)

  * generic: fix kernel/exit.c to use rwlock_write_locked

  * generic: fix kernel/spinlock.c

Comments?

---

 include/asm-i386/spinlock.h |   26 ++
 include/asm-ia64/spinlock.h |   12 +++-
 kernel/exit.c   |2 +-
 kernel/spinlock.c   |4 ++--
 4 files changed, 32 insertions(+), 12 deletions(-)



= include/asm-i386/spinlock.h 1.16 vs edited =
Index: cw-current/include/asm-i386/spinlock.h
===
--- cw-current.orig/include/asm-i386/spinlock.h 2005-01-19 17:37:27.497810394 
-0800
+++ cw-current/include/asm-i386/spinlock.h  2005-01-19 17:37:30.044914512 
-0800
@@ -15,7 +15,7 @@
  */
 
 typedef struct {
-   volatile unsigned int lock;
+   volatile unsigned int slock;
 #ifdef CONFIG_DEBUG_SPINLOCK
unsigned magic;
 #endif
@@ -43,7 +43,7 @@
  * We make no fairness assumptions. They have a cost.
  */
 
-#define spin_is_locked(x)  (*(volatile signed char *)(&(x)->lock) <= 0)
+#define spin_is_locked(x)  (*(volatile signed char *)(&(x)->slock) <= 0)
 #define spin_unlock_wait(x)do { barrier(); } while(spin_is_locked(x))
 
 #define spin_lock_string \
@@ -83,7 +83,7 @@
 
 #define spin_unlock_string \
"movb $1,%0" \
-   :"=m" (lock->lock) : : "memory"
+   :"=m" (lock->slock) : : "memory"
 
 
 static inline void _raw_spin_unlock(spinlock_t *lock)
@@ -101,7 +101,7 @@
 
 #define spin_unlock_string \
"xchgb %b0, %1" \
-   :"=q" (oldval), "=m" (lock->lock) \
+   :"=q" (oldval), "=m" (lock->slock) \
:"0" (oldval) : "memory"
 
 static inline void _raw_spin_unlock(spinlock_t *lock)
@@ -123,7 +123,7 @@
char oldval;
__asm__ __volatile__(
"xchgb %b0,%1"
-   :"=q" (oldval), "=m" (lock->lock)
+   :"=q" (oldval), "=m" (lock->slock)
:"0" (0) : "memory");
return oldval > 0;
 }
@@ -138,7 +138,7 @@
 #endif
__asm__ __volatile__(
spin_lock_string
-   :"=m" (lock->lock) : : "memory");
+   :"=m" (lock->slock) : : "memory");
 }
 
 static inline void _raw_spin_lock_flags (spinlock_t *lock, unsigned long flags)
@@ -151,7 +151,7 @@
 #endif
__asm__ __volatile__(
spin_lock_string_flags
-   :"=m" (lock->lock) : "r" (flags) : "memory");
+   :"=m" (lock->slock) : "r" (flags) : "memory");
 }
 
 /*
@@ -186,7 +186,17 @@
 
 #define rwlock_init(x) do { *(x) = RW_LOCK_UNLOCKED; } while(0)
 
-#define rwlock_is_locked(x) ((x)->lock != RW_LOCK_BIAS)
+/**
+ * rwlock_read_locked - would read_trylock() fail?
+ * @lock: the rwlock in question.
+ */
+#define rwlock_read_locked(x) (atomic_read((atomic_t *)&(x)->lock) <= 0)
+
+/**
+ * rwlock_write_locked - would write_trylock() fail?
+ * @lock: the rwlock in question.
+ */
+#define rwlock_write_locked(x) ((x)->lock != RW_LOCK_BIAS)
 
 /*
  * On x86, we implement read-write locks as a 32-bit counter
Index: cw-current/include/asm-ia64/spinlock.h
===
--- cw-current.orig/include/asm-ia64/spinlock.h 2005-01-19 17:37:27.498810435 
-0800
+++ cw-current/include/asm-ia64/spinlock.h  2005-01-19 17:37:30.044914512 
-0800
@@ -126,7 +126,17 @@
 #define RW_LOCK_UNLOCKED (rwlock_t) { 0, 0 }
 
 #define rwlock_init(x) do { *(x) = RW_LOCK_UNLOCKED; } while(0)
-#define rwlock_is_locked(x)(*(volatile int *) (x) != 0)
+
+/* rwlock_read_locked - would read_trylock() fail?
+ * @lock: the rwlock in question.
+ */
+#define rwlock_read_locked(x)   (*(volatile int *) (x) < 0)
+
+/**
+ * rwlock_write_locked - 

[PATCH RFC] agp_backend: remove drm_agp_t & inter_module_ V1 [1/1]

[Chris Wedgwood]

What extremely obvious thing am I missing which prevents up from
kill drm_agp_t and the inter_module_register, etc. code that goes with
it?

I couldn't see any in-tree users of this stuff...


---

 drivers/char/agp/backend.c  |   15 ---
 include/linux/agp_backend.h |   18 --
 2 files changed, 33 deletions(-)

Index: cw-current/drivers/char/agp/backend.c
===
--- cw-current.orig/drivers/char/agp/backend.c  2005-01-19 17:57:33.838452042 
-0800
+++ cw-current/drivers/char/agp/backend.c   2005-01-19 17:57:42.830795786 
-0800
@@ -214,17 +214,6 @@
phys_to_virt(bridge->scratch_page_real));
 }
 
-static const drm_agp_t drm_agp = {
-   _free_memory,
-   _allocate_memory,
-   _bind_memory,
-   _unbind_memory,
-   _enable,
-   _backend_acquire,
-   _backend_release,
-   _copy_info
-};
-
 /* XXX Kludge alert: agpgart isn't ready for multiple bridges yet */
 struct agp_bridge_data *agp_alloc_bridge(void)
 {
@@ -277,9 +266,6 @@
goto frontend_err;
}
 
-   /* FIXME: What to do with this? */
-   inter_module_register("drm_agp", THIS_MODULE, _agp);
-
agp_count++;
return 0;
 
@@ -298,7 +284,6 @@
bridge->type = NOT_SUPPORTED;
agp_frontend_cleanup();
agp_backend_cleanup(bridge);
-   inter_module_unregister("drm_agp");
agp_count--;
module_put(bridge->driver->owner);
 }
Index: cw-current/include/linux/agp_backend.h
===
--- cw-current.orig/include/linux/agp_backend.h 2005-01-19 17:57:33.839452080 
-0800
+++ cw-current/include/linux/agp_backend.h  2005-01-19 17:57:42.830795786 
-0800
@@ -96,23 +96,5 @@
 extern int agp_backend_acquire(void);
 extern void agp_backend_release(void);
 
-/*
- * Interface between drm and agp code.  When agp initializes, it makes
- * the below structure available via inter_module_register(), drm might
- * use it.  Keith Owens  28 Oct 2000.
- */
-typedef struct {
-   void(*free_memory)(struct agp_memory *);
-   struct agp_memory * (*allocate_memory)(size_t, u32);
-   int (*bind_memory)(struct agp_memory *, off_t);
-   int (*unbind_memory)(struct agp_memory *);
-   void(*enable)(u32);
-   int (*acquire)(void);
-   void(*release)(void);
-   int (*copy_info)(struct agp_kern_info *);
-} drm_agp_t;
-
-extern const drm_agp_t *drm_agp_p;
-
 #endif /* __KERNEL__ */
 #endif /* _AGP_BACKEND_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: 3ware driver (3w-xxxx) in 2.6.10: procfs entry

[Jason L Tibbitts III]

> "PD" == Peter Daum <[EMAIL PROTECTED]> writes:

PD> At least on my 8506-controllers there are also some minor problems
PD> (e.g. "info" doesn't work during a verify) which I thought was due
PD> to the fact that the program is intended exclusively for
PD> 9000-controllers.

You should report the problems you find to them.  They do indicate (in
the knowledge base on their web site) that you're going to need the
in-engineering files to run on the latest kernels.  It's only recently
that the newer tools acquired the ability to control older
controllers.

According to a recent post from a 3ware employee on linux-ide-arrays,
a proper release is expected in February.  Obviously the best solution
is that they just give us the source to these tools so that we can fix
them ourselves.  Knowing that isn't going to happen I'm happy they're
at least giving us something while they catch up with the speed of
kernel progress.

I can verify the fact that info is busted when the controller is
verifying the array; I'll gather some more info and pass this on to
3ware.

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

intel8x0 and 2.6.11-rc1

[Narayan Desai]

I am running 2.6.11-rc1 (patched with software suspend2) and no longer
get any sound output from my sound card. My old kernel 2.6.10 (with
slightly older software suspend 2 patches) works perfectly. the
hardware is recognized, and it appears to work, other than the lack
out of output. I have also checked the standard volume levels type
stuff.  Updating to the latest alsa bk patch (from 2.6.11-rc1-mm1)
doesn't fix it. Can anyone suggest what the problem might be? my
.config is attached. thanks..
 -nld


.config
Description: .config

RE: Make pipe data structure be a circular list of pages, rather than

[Robert White]

P.S.  Not to reply to myself... 8-)  I took some liberties with that 
description.
STREAMS doesn't, to the best of my knowledge, have the cleanup hook stuff.  
That was
me folding your issues (direct PCI device buffers etc) from this thread on top 
of the
basic skeleton of STREAMS to broaden the "impedance matching" possibilities.

(No really, back to lurking... 8-)

Rob White,
Casabyte, Inc.

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

[BUG] 2.6.* pktgen doesn't set ethnet header properly

[Junfeng Yang]

Hi,

I tried to use pktgen module from 2.6.* kernels and found out that I
couldn't receive any packets generated by pktgen.  I did not even see a
"packet dropped by kernel" message.  It turned out that function
setup_inject in net/core/pktgen.c doesn't setup the ethernet header field
correctly.  Below is a patch that fixes the problem.

--- kernel-source-2.6.8-orig/net/core/pktgen.c  2004-08-13 22:37:26.0 
-0700
+++ kernel-source-2.6.8/net/core/pktgen.c   2005-01-19 17:54:46.0 
-0800
@@ -259,6 +259,9 @@

/* Set up Dest MAC */
memcpy(&(info->hh[0]), info->dst_mac, 6);
+
+   /* Set up protocol */
+   ((struct ethhdr *)(info->hh))->h_proto = htons(ETH_P_IP);

info->saddr_min = 0;
info->saddr_max = 0;

-Junfeng

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] consolidate arch specific resource.h headers

[Chris Wright]

Most of the include/asm-*/resource.h headers are the same as one another.
This patch makes one generic version, include/asm-generic/resource.h,
and uses that when appropriate.  The only vaguely interesting things here
are that the generic version introduces a new _STK_LIM_MAX macro, which can
be populated by an arch (ia64 and parisc needed that).  Also, some arches
hid RLIM_INFINITY under __KERNEL__, while others did not.  The generic
version does not, so the following arches will see that change:
arm, arm26, mips, ppc, ppc64, sh (and hence sh64)

And, finally, some arches maintain their own order for the resource
numbers.  This is now marked by __ARCH_RLIMIT_ORDER, and is used by the
following arches:
alpha, mips, sparc, and sparc64.

This actually uncovered a mips bug (fix already sent, this patch is
relative to that fix), where the default RLIMIT_MEMLOCK was set to
RLIM_INFINITY and RLIMIT_NPROC set to MLOCK_LIMIT (the latter is no big
deal because RLIMIT_NPROC default is overwritten dynamically during
bootup in fork_init()).  Also, this change makes alpha's default for
RLIMIT_NPROC change from RLIM_INFINITY to 0, but again...no problem as
it's dynamically overwritten during bootup.

The following arches are left untouched:
m68knommu: untouched (uses m68k/resource.h)
sh64: untouched (uses asm-sh/resource.h)
um: untouched (uses arch code already)

Signed-off-by: Chris Wright <[EMAIL PROTECTED]>

 include/asm-alpha/resource.h   |   22 +--
 include/asm-arm/resource.h |   47 
 include/asm-arm26/resource.h   |   47 
 include/asm-cris/resource.h|   47 
 include/asm-frv/resource.h |   48 
 include/asm-generic/resource.h |   60 +
 include/asm-h8300/resource.h   |   47 
 include/asm-i386/resource.h|   48 
 include/asm-ia64/resource.h|   54 +---
 include/asm-m32r/resource.h|   51 --
 include/asm-m68k/resource.h|   47 
 include/asm-mips/resource.h|   25 ++---
 include/asm-parisc/resource.h  |   48 +---
 include/asm-ppc/resource.h |   44 --
 include/asm-ppc64/resource.h   |   53 
 include/asm-s390/resource.h|   47 
 include/asm-sh/resource.h  |   47 
 include/asm-sparc/resource.h   |   20 +
 include/asm-sparc64/resource.h |   26 +
 include/asm-v850/resource.h|   47 
 include/asm-x86_64/resource.h  |   47 
 21 files changed, 87 insertions(+), 835 deletions(-)

--- /dev/null   2005-01-14 06:27:56.540397616 -0800
+++ edited/include/asm-generic/resource.h   2005-01-19 15:35:51.0 
-0800
@@ -0,0 +1,60 @@
+#ifndef _ASM_GENERIC_RESOURCE_H
+#define _ASM_GENERIC_RESOURCE_H
+
+/*
+ * Resource limits
+ */
+
+/* Allow arch to control resource order */
+#ifndef __ARCH_RLIMIT_ORDER
+#define RLIMIT_CPU 0   /* CPU time in ms */
+#define RLIMIT_FSIZE   1   /* Maximum filesize */
+#define RLIMIT_DATA2   /* max data size */
+#define RLIMIT_STACK   3   /* max stack size */
+#define RLIMIT_CORE4   /* max core file size */
+#define RLIMIT_RSS 5   /* max resident set size */
+#define RLIMIT_NPROC   6   /* max number of processes */
+#define RLIMIT_NOFILE  7   /* max number of open files */
+#define RLIMIT_MEMLOCK 8   /* max locked-in-memory address space */
+#define RLIMIT_AS  9   /* address space limit */
+#define RLIMIT_LOCKS   10  /* maximum file locks held */
+#define RLIMIT_SIGPENDING  11  /* max number of pending signals */
+#define RLIMIT_MSGQUEUE12  /* maximum bytes in POSIX 
mqueues */
+
+#define RLIM_NLIMITS   13
+#endif
+
+/*
+ * SuS says limits have to be unsigned.
+ * Which makes a ton more sense anyway.
+ */
+#ifndef RLIM_INFINITY
+#define RLIM_INFINITY  (~0UL)
+#endif
+
+#ifndef _STK_LIM_MAX
+#define _STK_LIM_MAX   RLIM_INFINITY
+#endif
+
+#ifdef __KERNEL__
+
+#define INIT_RLIMITS   \
+{  \
+   [RLIMIT_CPU]= { RLIM_INFINITY, RLIM_INFINITY }, \
+   [RLIMIT_FSIZE]  = { RLIM_INFINITY, RLIM_INFINITY }, \
+   [RLIMIT_DATA]   = { RLIM_INFINITY, RLIM_INFINITY }, \
+   [RLIMIT_STACK]  = {  _STK_LIM, _STK_LIM_MAX  }, \
+   [RLIMIT_CORE]   = { 0, RLIM_INFINITY }, \
+

RE: Make pipe data structure be a circular list of pages, rather than

[Robert White]

Howdy,

The below (sorry about the Outlook style includes, work _requires_ outlook 8-() 
is
why I previously mentioned the STREAMS implementation from SVR4 (and so Solaris 
etc).

Every interface point has a pointer to its peer, a pair of queues and a put()
routine.  Every message is in two or more pieces, the message header and the 
message
buffer/buffers (read real data pages).

So the "participating interface" requirement is really that the device be able 
to
expose a data structure consisting of four pointers that their peer can point 
to.

The "message types" for the messages passing around are all contained in the 
message
header structures.  These headers have all the reference counting and
disposal/cleanup hook procedures (pointers) along with the references to the 
actual
data.  This means that you could have a stock pool (from the slab cache) of 
these
headers for moving plain data around, and "magical devices" could use specialty
message headers with the necessary disposal elements or necessary "extra data" 
in
them.

All the devices in any kind of chain/mux/pipe/whatever arrangement pass 
messages to
their peers by invoking peer->put(message) [in OOD parlance, really probably
(*peer)(peer,message) in straight C].  And modules can be induced into the
chain/mux/pipe/whtever at runtime. The target put() procedure decides to copy or
reference-increment the message and put it on it's receive queue or process it
immediately.  At no time does any member of a STREAMS structure need to know any
details about the workings of their peers.

In the abstract, most communications would have message headers referring to 
blocks
of normal memory.  Some devices could send out messages that reference their PCI
mapped memory or whatever, and all _that_ device would have to do to mesh with 
the
system is to replace the cleanup function pointer with one appropriate to its 
need.
When the message has gone as far as it is going to go, its reference count 
drops to
zero and it gets cleaned up.

Unget can be done with some queue insertion/manipulation.  There is no pull() as
every target is either hot-processed or queued.  Flow control takes place when a
put() procedure returns a no-space-for-message indication.

If you absolutely _must_ know if the data was actually consumed by the target 
(and I
could argue that this is virtually never the case as things get lost in 
error-induced
pipe tear-down all the time) it would only be necessary to add a "cursor" 
member to
the message header and, at destruction time, see if the cursor had been 
advanced to
"use up" the data.

One could even have message headers that know they are dealing with

Now the message header is Linus' "impedance matcher" interface, transport is 
really
just about knowing your peer, calling put(), and doing reference counting.

There were a lot of (IMHO) mistakes in the STREAMS design, but the programming
document (previously referenced in this thread) covers a lot of the same message
typing and management questions that are being raised here.

While I can see that the fit between Linux and SVR4 STREAMS wouldn't be 
identical, a
good bit of the pipe-fitting (to pun 8-) and operation definitions would be.

(I'll go back to lurking now... 8-)

Rob White,
Casabyte, Inc.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:

The main infrastructure hassle you need to support this *universally*
is the unget() on "character devices" like pipes and network sockets.
Ideally, it would be some generic buffer front end that could be used
by the device for normal data as well as the special case.
 
Ooh.  Need to think.  If there's a -EIO problem on one of the file
descriptors, how does the caller know which one?  That's an argument for
separate pull and push (although the splice() library routine still
has the problem).  Any suggestions?  Does userland need to fall
back on read()/write() for a byte?



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

Con Kolivas wrote:
Here are my results with SCHED_ISO v2 on a pentium-M 1.7Ghz (all
powersaving features off):
Increasing iso_cpu did not change the results.
At least in my testing on my hardware, v2 is working as advertised. I
need results from more hardware configurations to know if priority
support is worth adding or not.

Excellent.  Judging by the DSP Load, your machine seems to run almost
twice as fast as my 1.5GHz Athlon (surprising).  You might want to try
Not really surprising; the 2Mb cache makes this a damn fine cpu, if not 
necessarily across the board :)

pushing it a bit harder by running more clients (2nd parameter,
default is 20).
Ask and ye shall receive.
Are you getting fairly consistent results running SCHED_ISO
repeatedly?  That worked better for me after I fixed that bug in JACK
0.99.47, but I think there is still more variance than with
SCHED_FIFO.
Much more consistent, and I believe some bugs in the earlier 
implementation were probably biting.

40 clients:
SCHED_FIFO:
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 7
Delay Count (>spare time) . . :20
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :  6739   usecs
Cycle Maximum . . . . . . . . :   746   usecs
Average DSP Load. . . . . . . :30.4 %
Average CPU System Load . . . : 5.7 %
Average CPU User Load . . . . :23.3 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.6 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1692.0 /sec
Average Context-Switch Rate . : 20907.7 /sec
*
SCHED_ISO:
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . :11
Delay Count (>spare time) . . :19
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :  8723   usecs
Cycle Maximum . . . . . . . . :   714   usecs
Average DSP Load. . . . . . . :31.1 %
Average CPU System Load . . . : 5.7 %
Average CPU User Load . . . . :23.2 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.6 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1685.4 /sec
Average Context-Switch Rate . : 20496.9 /sec
*
Full results and pretty pictures available here:
http://ck.kolivas.org/patches/SCHED_ISO/iso2-benchmarks/
Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE][RFC] plugsched-2.0 patches ...

[Kasper Sandberg]

its nice to see that this project is not dead after all :DD

On Thu, 2005-01-20 at 12:23 +1100, Peter Williams wrote:
> ... are now available from:
> 
> 
> 
> as a single patch to linux-2.6.10 and at:
> 
> 
> 

> 
> Peter

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

[PATCH] mips default mlock limit fix

[Chris Wright]

Mips RLIMIT_MEMLOCK incorrectly defaults to unlimited, it was confused
with RLIMIT_NPROC.  Found while consolidating resource.h headers.

Signed-off-by: Chris Wright <[EMAIL PROTECTED]>

= include/asm-mips/resource.h 1.6 vs edited =
--- 1.6/include/asm-mips/resource.h 2004-08-23 01:15:26 -07:00
+++ edited/include/asm-mips/resource.h  2005-01-19 17:34:25 -08:00
@@ -53,8 +53,8 @@
{ INR_OPEN,  INR_OPEN  },   \
{ RLIM_INFINITY, RLIM_INFINITY },   \
{ RLIM_INFINITY, RLIM_INFINITY },   \
-   { MLOCK_LIMIT, MLOCK_LIMIT },   \
-   { RLIM_INFINITY, RLIM_INFINITY },   \
+   { 0, 0 },   \
+   { MLOCK_LIMIT,   MLOCK_LIMIT   },   \
{ RLIM_INFINITY, RLIM_INFINITY },   \
{ MAX_SIGPENDING, MAX_SIGPENDING }, \
{ MQ_BYTES_MAX, MQ_BYTES_MAX }, \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook

[Michael S. Tsirkin]

Quoting r. Chris Wright ([EMAIL PROTECTED])
> > > > I'm all for it, but the way the patch below works, we could end up
> > > > calling ->ioctl or ->unlocked_ioctl from the compat 
> > > > syscall, and we dont want that.
> > > 
> > > Hmm, I didn't actually change how those are called.  So if it's an issue,
> > > then I don't think this patch introduces it.
> > 
> > Sorry, you are right, we go to do_ioctl only if there are no
> > callbacks.
> 
> I suppose there is one case (not introduced by the patch).  Not sure if
> it's even a problem though:
> 
> t->cmd matches, yet NULL t->handler.  This will fall-thru to
> the do_ioctl: case.  I assume NULL handler is for case where no
> conversion is needed, so it's not a problem?  At least some callers of
> register_ioctl32_conversion() pass NULL handler.

Yes, this is an by design, you put in a NULL handler to say: I dont need
conversions, call my regular handlers. Some in-tree drivers do this.

MST
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 2/4] interruptible rwsem operations (i386, core)

[Nick Piggin]

David Howells wrote:
Dominik Brodowski <[EMAIL PROTECTED]> wrote:

Add functions down_read_interruptible, and down_write_interruptible to rw
semaphores. Implement these for i386.
...

+static inline int
+rwsem_down_interruptible_failed_common(struct rw_semaphore *sem,
+   struct rwsem_waiter *waiter, signed long adjustment)
+{
...

I wonder if you should check to see if there are any readers that can be woken
up if a sleeping writer is interrupted, but I can't think of a simple way to
do it.

I think it will, won't it?
-struct rw_semaphore fastcall __sched *
-rwsem_down_read_failed(struct rw_semaphore *sem)
+void fastcall __sched rwsem_down_read_failed(struct rw_semaphore *sem)

Please don't.

@@ -199,14 +253,33 @@ rwsem_down_read_failed(struct rw_semapho
RWSEM_WAITING_BIAS - RWSEM_ACTIVE_BIAS);
rwsemtrace(sem, "Leaving rwsem_down_read_failed");
-   return sem;

Ditto.

-struct rw_semaphore fastcall __sched *
-rwsem_down_write_failed(struct rw_semaphore *sem)
+void fastcall __sched rwsem_down_write_failed(struct rw_semaphore *sem)

Ditto.

@@ -216,10 +289,31 @@ rwsem_down_write_failed(struct rw_semaph
rwsem_down_failed_common(sem, , -RWSEM_ACTIVE_BIAS);
rwsemtrace(sem, "Leaving rwsem_down_write_failed");
-   return sem;

Ditto.

@@ -99,11 +103,12 @@ static inline void __down_read(struct rw
{
__asm__ __volatile__(
"# beginning down_read\n\t"
-LOCK_PREFIX"  incl  (%%eax)\n\t" /* adds 0x0001, returns the old 
value */
+LOCK_PREFIX"  incl  %0\n\t" /* adds 0x0001, returns the old value 
*/

Ditto.

"  js2f\n\t" /* jump if we weren't granted the lock */
"1:\n\t"
LOCK_SECTION_START("")
"2:\n\t"
+   "  movl  %2,%%eax\n\t"

Splat.

"  pushl %%ecx\n\t"
"  pushl %%edx\n\t"
"  call  rwsem_down_read_failed\n\t"

Splat.

@@ -113,11 +118,41 @@ LOCK_PREFIX   "  incl  (%%eax)\n\t" /*
LOCK_SECTION_END
"# ending down_read\n\t"
: "=m"(sem->count)
-   : "a"(sem), "m"(sem->count)
+   : "m"(sem->count), "m"(sem)
: "memory", "cc");
}

You appear to be corrupting EAX.

+static inline int __down_read_interruptible(struct rw_semaphore *sem)

Will corrupt EAX.
I'll fix these up. You're right by the looks.

"# beginning down_write\n\t"
-LOCK_PREFIX"  xadd  %%edx,(%%eax)\n\t" /* subtract 0x, returns 
the old value */
+LOCK_PREFIX"  xadd  %%edx,%0\n\t" /* subtract 0x, returns the 
old value */

Again, please don't. It's a lot more readable when it mentions EAX directly,
plus it's also independent of constraint reordering.
OK I suppose so...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Jack O'Quin]

Con Kolivas <[EMAIL PROTECTED]> writes:

> Con Kolivas wrote:
>
> Here are my results with SCHED_ISO v2 on a pentium-M 1.7Ghz (all
> powersaving features off):
>
> Increasing iso_cpu did not change the results.
>
> At least in my testing on my hardware, v2 is working as advertised. I
> need results from more hardware configurations to know if priority
> support is worth adding or not.

Excellent.  Judging by the DSP Load, your machine seems to run almost
twice as fast as my 1.5GHz Athlon (surprising).  You might want to try
pushing it a bit harder by running more clients (2nd parameter,
default is 20).

Are you getting fairly consistent results running SCHED_ISO
repeatedly?  That worked better for me after I fixed that bug in JACK
0.99.47, but I think there is still more variance than with
SCHED_FIFO.
-- 
  joq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ANNOUNCE][RFC] plugsched-2.0 patches ...

[Peter Williams]

... are now available from:

as a single patch to linux-2.6.10 and at:

as a (gzipped and tarred) patch set including "series" file which 
nominates the order of application of the patches.

This is an update of the earlier version of plugsched (previously 
released by Con Kolivas) and has a considerably modified scheduler 
interface that is intended to reduce the amount of code duplication 
required when adding a new scheduler.  It also contains a sysfs 
interface based on work submitted by Chris Han.

This version of plugsched contains 4 schedulers:
1. "ingosched" which is the standard active/expired array O(1) scheduler 
created by Ingo Molnar,
2. "staircase" which is Con Kolivas's version 10.5 O(1) staircase scheduler,
3. "spa_no_frills" which is a single priority array O(1) scheduler 
without any interactive response enhancements, etc., and
4. "zaphod" which is a single priority array O(1) scheduler with 
interactive response bonuses, throughput bonuses and a choice of 
priority based or entitlement based interpretation of "nice".

Schedulers 3 and 4 also offer unprivileged real time tasks and hard/soft 
per task CPU rate caps.

The required scheduler can be selected at boot time by supplying a 
string of the form "cpusched=" where  is one of the names 
listed above.

The default scheduler (that will be used in the absence of a "cpusched" 
boot argument) can be configured at build time and is set to "ingosched" 
by default.

The file /proc/scheduler contains a string describing the current scheduler.
The directory /sys/cpusched// contains any 
scheduler configuration control files that may apply to the current 
scheduler.

Peter
--
Peter Williams   [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Jack O'Quin]

Con Kolivas <[EMAIL PROTECTED]> writes:

> Jack O'Quin wrote:
>> Try again with JACK 0.99.48.  It's in CVS now, but you probably need
>> this tarball to get around the dreaded SourceForge anon CVS lag...
>>
>> http://www.joq.us/jack/tarballs/jack-audio-connection-kit-0.99.48.tar.gz
>
> Thanks it finally ran to completion. By the way the patch you sent
> with the test suite did not apply so I had to do it manually
> (booraroom..)

Oops!  Sorry.  I generated those by hand using some rather crude 
`diff -u  >> xxx.diff' commands.  

We should just add Rui's latest version to JACK CVS.

> Since I (finally) have it running at this end at last I'll do some
> benchmarking of my own to see how (lack of) priorities affects
> SCHED_ISO. If it is inadequate, it wont be too difficult to add them
> to the design. The problem with priorities is that once you go over
> the cpu limit everyone suffers equally; but that's a failsafe that you
> shouldn't actually hit in normal usage so it probably doesn't
> matter... 

I'd be surprised if we're hitting it in this test.  AFAICT, our
"Average DSP Load" should approximate your CPU limit.  That's running
in the 30% to 40% range.  Is there any way to verify this?  Is your
running average readable in /proc/sys/kernel somewhere?

We do need to test that the system degrades gracefully when the CPU is
overloaded.  That *will* happen (the dreaded P4 float denormal
problems quickly come to mind).  At some point, the user should be
allowed to choose how much CPU to consume, possibly shutting down
plugins as needed.

> Hmm come to think of it, it probably _is_ a good idea to implement
> priority support afterall.

Hard to say for sure without trying it.  These threads are dealing
with a realtime cycle that is smaller than normal scheduler time
slices.  Getting all the work done is important.  But, getting it done
in the right order might make a difference for important statistics
like Max Delay.
-- 
  joq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook

[Chris Wright]

* Michael S. Tsirkin ([EMAIL PROTECTED]) wrote:
> Quoting r. Chris Wright ([EMAIL PROTECTED]) "Re: [PATCH 1/5] compat_ioctl 
> call seems to miss a security hook":
> > * Michael S. Tsirkin ([EMAIL PROTECTED]) wrote:
> > > I'm all for it, but the way the patch below works, we could end up
> > > calling ->ioctl or ->unlocked_ioctl from the compat 
> > > syscall, and we dont want that.
> > 
> > Hmm, I didn't actually change how those are called.  So if it's an issue,
> > then I don't think this patch introduces it.
> 
> Sorry, you are right, we go to do_ioctl only if there are no
> callbacks.

I suppose there is one case (not introduced by the patch).  Not sure if
it's even a problem though:

t->cmd matches, yet NULL t->handler.  This will fall-thru to
the do_ioctl: case.  I assume NULL handler is for case where no
conversion is needed, so it's not a problem?  At least some callers of
register_ioctl32_conversion() pass NULL handler.

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook

[Michael S. Tsirkin]

Quoting r. Chris Wright ([EMAIL PROTECTED]) "Re: [PATCH 1/5] compat_ioctl call 
seems to miss a security hook":
> * Michael S. Tsirkin ([EMAIL PROTECTED]) wrote:
> > I'm all for it, but the way the patch below works, we could end up
> > calling ->ioctl or ->unlocked_ioctl from the compat 
> > syscall, and we dont want that.
> 
> Hmm, I didn't actually change how those are called.  So if it's an issue,
> then I don't think this patch introduces it.
> 
> thanks,
> -chris

Sorry, you are right, we go to do_ioctl only if there are no
callbacks.
Patch looks good to go to me.
mst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Job - inescapable job containers

[Andrew Morton]

Limin Gu <[EMAIL PROTECTED]> wrote:
>
>  Could you consider this for inclusion in the mm tree?
>  The Job patch has been posted a few times, and I've addressed
>  the issues others raised.

I'm totally not in a position to evaluate the completeness, desirability,
interest-level, etc of this patch, I'm afraid.  This is an opportunity for
other stakeholders to weigh in..

A similar thing happened last year with the "enhanced system accounting"
patch.  I tossed it back to lse-tech, asking the people there to come up
with some sort of agreed framework.  After several months we have one small
patch for enhanced accounting which nothing actually uses yet.

So things aren't working very well.  What's up?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] dynamic tick patch

[Pavel Machek]

Hi!

> > > > > Thanks for trying it out. I have quite accurate time here on my
> > > > > systems, and sleep works as it should. I wonder what's happening on
> > > > > your system? If you have a chance, could you please post the results
> > > > > from following simple tests?
> > > > 
> > > > On patched 2.6.11-rc1:
> > > > 
> > > > [Heh, clock is two times too fast, perhaps that makes ntpdate fail? -- 
> > > > yes.
> > > > 
> > > > [EMAIL PROTECTED]:~# dmesg | grep -i time; for i in 1 2 3 4 5; do 
> > > > ntpdate -b tak.cesnet.cz && sleep 10; done ; date && sleep 10 && date; 
> > > > while [ 1 ]; do date; done | uniq
> > > > PCI: Setting latency timer of device :00:11.5 to 64
> > > > dyn-tick: Enabling dynamic tick timer
> > > > dyn-tick: Timer using dynamic tick
> > > 
> > > Thanks. Looks like you're running on PIT only, I guess my patch
> > > currently breaks PIT (and possibly HPET) No dmesg message for "
> > > "Using XXX for high-res timesource".
> > 
> > This machine definitely has TSC... What do I have to do in .config to
> > make it do something interesting? My .config is:
> 
> I suspect it's the HPET_TIMER, see below. CONFIG_X86_PM_TIMER is
> optional, otherwise TSC is used.

Okay, so I tried to measure power consumption. Patched kernel seems to
be about 200mW better. That's on 22W... I'll see if I can tweak ACPI
somehow to decrease it a bit more.
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] dynamic tick patch

[Pavel Machek]

Hi!


> > > Thanks. Looks like you're running on PIT only, I guess my patch
> > > currently breaks PIT (and possibly HPET) No dmesg message for "
> > > "Using XXX for high-res timesource".
> > 
> > This machine definitely has TSC... What do I have to do in .config to
> > make it do something interesting? My .config is:
> 
> I suspect it's the HPET_TIMER, see below. CONFIG_X86_PM_TIMER is
> optional, otherwise TSC is used.

Now it seems to work okay, see below.

[EMAIL PROTECTED]:~# dmesg | grep -i time; for i in 1 2 3 4 5; do ntpdate -t 10 
tak.cesnet.cz && sleep 10; done ; date && sleep 10 && date; while [ 1 ]; do 
date; done |
uniq
PCI: Setting latency timer of device :00:11.5 to 64
dyn-tick: Enabling dynamic tick timer
dyn-tick: Timer using dynamic tick
20 Jan 01:39:45 ntpdate[1365]: step time server 195.113.144.238 offset 
-3.449324 sec
20 Jan 01:40:00 ntpdate[1371]: adjust time server 195.113.144.238 offset 
0.005790 sec
20 Jan 01:40:15 ntpdate[1375]: adjust time server 195.113.144.238 offset 
0.024061 sec
20 Jan 01:40:31 ntpdate[1380]: adjust time server 195.113.144.238 offset 
0.004277 sec
20 Jan 01:40:46 ntpdate[1384]: adjust time server 195.113.144.238 offset 
0.000283 sec
Thu Jan 20 01:40:56 CET 2005
Thu Jan 20 01:41:06 CET 2005
Thu Jan 20 01:41:06 CET 2005
Thu Jan 20 01:41:07 CET 2005
Thu Jan 20 01:41:08 CET 2005
Thu Jan 20 01:41:09 CET 2005
Thu Jan 20 01:41:10 CET 2005
Thu Jan 20 01:41:11 CET 2005

Timer interrupts are no longer that common, good.

[EMAIL PROTECTED]:~# cat /proc/interrupts ; sleep 10; cat /proc/interrupts
   CPU0
  0:  16390IO-APIC-edge  timer
  1:646IO-APIC-edge  i8042
 10: 49   IO-APIC-level  acpi
 12: 69IO-APIC-edge  i8042
 14:   1688IO-APIC-edge  ide0
 15: 14IO-APIC-edge  ide1
 17:  1   IO-APIC-level  yenta
 19:  2   IO-APIC-level  ohci1394
 21:   1252   IO-APIC-level  ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd
 22:  0   IO-APIC-level  VIA8233
 23:  3   IO-APIC-level  eth0
NMI:  0
LOC:  20306
ERR:  0
MIS:  0
   CPU0
  0:  16586IO-APIC-edge  timer
  1:647IO-APIC-edge  i8042
 10: 49   IO-APIC-level  acpi
 12: 69IO-APIC-edge  i8042
 14:   1744IO-APIC-edge  ide0
 15: 14IO-APIC-edge  ide1
 17:  1   IO-APIC-level  yenta
 19:  2   IO-APIC-level  ohci1394
 21:   1337   IO-APIC-level  ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd
 22:  0   IO-APIC-level  VIA8233
 23:  3   IO-APIC-level  eth0
NMI:  0
LOC:  20647
ERR:  0
MIS:  0

Pavel
> --- config.orig   2005-01-19 16:05:16.0 -0800
> +++ config2005-01-19 16:06:07.0 -0800
> @@ -103,7 +103,7 @@
>  CONFIG_X86_GOOD_APIC=y
>  CONFIG_X86_INTEL_USERCOPY=y
>  CONFIG_X86_USE_PPRO_CHECKSUM=y
> -CONFIG_HPET_TIMER=y
> +# CONFIG_HPET_TIMER is not set
>  CONFIG_NO_IDLE_HZ=y
>  # CONFIG_SMP is not set
>  CONFIG_PREEMPT=y
> @@ -169,7 +169,7 @@
>  CONFIG_ACPI_POWER=y
>  CONFIG_ACPI_PCI=y
>  CONFIG_ACPI_SYSTEM=y
> -# CONFIG_X86_PM_TIMER is not set
> +CONFIG_X86_PM_TIMER=y
>  # CONFIG_ACPI_CONTAINER is not set
>  
>  #


-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Con Kolivas wrote:
This is version 2 of the SCHED_ISO patch with the yield bug fixed and 
code cleanups.
...answering on this thread to consolidate the two branches of the email 
thread.

Here are my results with SCHED_ISO v2 on a pentium-M 1.7Ghz (all 
powersaving features off):

SCHED_NORMAL:
awk: ./jack_test3_summary.awk:67: (FILENAME=- FNR=862) fatal: division 
by zero attempted
Well we wont bother looking at those results then. there were 38 XRUNS 
that did make it on the parsed output.

SCHED_FIFO:
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 4
Delay Count (>spare time) . . :18
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :  6595   usecs
Cycle Maximum . . . . . . . . :   368   usecs
Average DSP Load. . . . . . . :17.9 %
Average CPU System Load . . . : 3.4 %
Average CPU User Load . . . . :13.7 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 1.4 %
Average CPU IRQ Load  . . . . : 0.6 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1697.0 /sec
Average Context-Switch Rate . : 13334.1 /sec
*
SCHED_ISO (iso_cpu 70):
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 5
Delay Count (>spare time) . . :18
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :  6489   usecs
Cycle Maximum . . . . . . . . :   405   usecs
Average DSP Load. . . . . . . :18.0 %
Average CPU System Load . . . : 3.3 %
Average CPU User Load . . . . :13.7 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.6 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1700.2 /sec
Average Context-Switch Rate . : 12457.2 /sec
*
Increasing iso_cpu did not change the results.
At least in my testing on my hardware, v2 is working as advertised. I 
need results from more hardware configurations to know if priority 
support is worth adding or not.

Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] cputime_t patches broke RLIMIT_CPU

[Linus Torvalds]

On Wed, 19 Jan 2005, Roland McGrath wrote:
> 
> Yes, that's how it was done before.  The patch I just posted was intended
> to fix the apparent typo without getting any deeper.  Below is an untested
> alternate patch to restore the old behavior under the new macro regime.

Thanks, this one looks good. I have this nagging feeling that the test for 
"every second" should be doable by using a multiply (ie do a
secs_to_cputime(secs) and see if it's smaller than "total - cputime") 
rather than doing the divide that is implied by "cputime_to_secs()", but I 
can't really bring myself to care, and if anything, that test for "did we 
go into the next whole second" really is pretty obscure anyway.

So I can't see anything wrong with this. Anybody else? Going, going..

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

Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook

[Chris Wright]

* Michael S. Tsirkin ([EMAIL PROTECTED]) wrote:
> I'm all for it, but the way the patch below works, we could end up
> calling ->ioctl or ->unlocked_ioctl from the compat 
> syscall, and we dont want that.

Hmm, I didn't actually change how those are called.  So if it's an issue,
then I don't think this patch introduces it.

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT] skge: new syskonnect gigabit ethernet driver

[Nish Aravamudan]

On Wed, 19 Jan 2005 19:00:31 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > This is the second public release of my new rewrite of the SysKonnect 
> > Gigabit
> > Ethernet driver.  This 0.3 version fixes bugs with link up/down and ethtool
> > phys_id support.  It adds ethtool support for interrupt coalescing and pause
> > parameters. Performance is good, I am able to get 941 Mbit/sec receiving
> > (TCP using iperf). But obviously, the driver is still experimental.
> >
> > This driver doesn't support Yukon2 (yet), and there is report of problem
> > with D-Link card (Yukon-EC).
> >
> > The patch should work on 2.6.8 or later, I am testing with 2.6.11-rc1.
> > Also available as download from http://developer.osdl.org/shemminge/skge



> > +static int skge_phys_id(struct net_device *dev, u32 data)
> > +{
> > + struct skge_port *skge = netdev_priv(dev);
> > +
> > + if(!data || data > (u32)(MAX_SCHEDULE_TIMEOUT / HZ))
> > + data = (u32)(MAX_SCHEDULE_TIMEOUT / HZ);
> > +
> > + /* start blinking */
> > + skge->blink_on = 1;
> > + mod_timer(>led_blink, jiffies);
> > +
> > + set_current_state(TASK_INTERRUPTIBLE);
> > + schedule_timeout(data * HZ);
> > + del_timer_sync(>led_blink);

Please consider using msleep_interruptible(data * 1000) here. The same
substitution has worked in other drivers that have used the exact same
code.

Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] dynamic tick patch

[George Anzinger]

Thomas Gleixner wrote:
On Wed, 2005-01-19 at 14:59 -0800, George Anzinger wrote:
I don't think you will ever get good time if you EVER reprogramm the PIT.

Why not ? If you have a continous time source, which keeps track of
"ticks" regardless the CPU state, why should PIT reprogramming be evil ?
First it takes too long.  Second, you are (usually) programming it to run at 
1/HZ but you do this somewhere between the ticks (and, likely you don't really 
know where between them you are).  This last means, on the average, that you 
lose 1/2 a tick time, i.e. the tick interrupt will happen 1/2 a tick late for 
each reprogramm done.

If you say, well, lets just use the TSC (or some other timer) you have the 
problem that in x86 boxes those don't rely on "rocks" selected for time keeping, 
so you have an inaccurate clock to this degree.  Also, in the case of the TSC, 
at boot time we "try" to figure out how many cycles of TSC it takes to do a PIT 
cycle by "looking" as the PIT in a loop while we catch the TSC.  Problem is that 
the I/O sync needed to look at the PIT is several TSC cycles long and we don't 
really know how close we got.  Even using the max PIT time of around 50 ms the 
error on my 800 MHZ PII is 10 or more TSC cycles.

At one point I tried to get the PIT to sync back up by doing a short cycle 
followed by the normal cycle.  I.e. I loaded the counter for the time remaining 
in the jiffie, started the PIT and then loaded the 1/HZ latch count on top of 
it.  The spec says the new count should be loaded by the chip when the current 
one expires.  This sort of worked, but I still got feedback on clock drift. 
Also, there are some PITs out there that don't do this correctly.  And in the 
load part, you have to wait for the first program to start prior to loading the 
second one.  This is a busy loop waiting for an I/O event, i.e. much too long.

We should also keep in mind that we really want the timer tick to happen as 
close as possible to the jiffies++ as possible.  Especially if we are doing high 
res timers, any delay here will show up as late timers.

--
George Anzinger   george@mvista.com
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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

utz lehmann wrote:
@@ -2406,6 +2489,10 @@ void scheduler_tick(void)
 	task_t *p = current;
 
 	rq->timestamp_last_tick = sched_clock();
+	if (iso_task(p) && !rq->iso_refractory)
+		inc_iso_ticks(rq, p);
+	else 
+		dec_iso_ticks(rq, p);

scheduler_tick() is not only called by the timer interrupt but also form
the fork code. Is this intended? I think the accounting for
The calling from fork code only occurs if there is one millisecond of 
time_slice left so it will only very rarely be hit. I dont think this 
accounting problem is worth worrying about.

iso_refractory is wrong. Isn't calling it from
timer.c::update_process_times() better?
And shouldn't real RT task also counted? If RT tasks use 40% cpu you can
lockup the system as unprivileged user with SCHED_ISO because it doesn't
reach the 70% cpu limit.
Ah yes. Good point. Will add that to the equation.
Futher on i see a fundamental problem with this accounting for
iso_refractory. What if i manage as unprivileged user to run a SCHED_ISO
task which consumes all cpu and only sleeps very short during the timer
interrupt? I think this will nearly lockup or very slow down the system.
The iso_cpu limit can't guaranteed.
Right you are. The cpu accounting uses primitive on-interrupt run time 
which as we know is not infallible. To extend this I'll have to keep a 
timer based on the sched_clock which is already implemented. That's 
something for me to work on.

sysrq-n causes a reboot.
And that will need looking into.
Thanks very much for your comments!
Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook

[Michael S. Tsirkin]

Hello!
Quoting r. Chris Wright ([EMAIL PROTECTED]) "Re: [PATCH 1/5] compat_ioctl call 
seems to miss a security hook":
> * Michael S. Tsirkin ([EMAIL PROTECTED]) wrote:
> > diff -rup linux-2.6.10-orig/fs/compat.c linux-2.6.10-ioctl-sym/fs/compat.c
> > --- linux-2.6.10-orig/fs/compat.c   2005-01-18 10:58:33.609880024 +0200
> > +++ linux-2.6.10-ioctl-sym/fs/compat.c  2005-01-18 10:54:26.289478440 
> > +0200
> > @@ -437,6 +437,11 @@ asmlinkage long compat_sys_ioctl(unsigne
> > if (!filp)
> > goto out;
> >  
> > +   /* RED-PEN how should LSM module know it's handling 32bit? */
> > +   error = security_file_ioctl(filp, cmd, arg);
> > +   if (error)
> > +   goto out_fput;
> > +
> 
> This is now called twice in the plain do_ioctl: case.  A generic vfs handler
> could alleviate that.

I'm all for it, but the way the patch below works, we could end up
calling ->ioctl or ->unlocked_ioctl from the compat 
syscall, and we dont want that.

MST



> = fs/ioctl.c 1.15 vs edited =
> --- 1.15/fs/ioctl.c   2005-01-15 14:31:01 -08:00
> +++ edited/fs/ioctl.c 2005-01-18 11:18:33 -08:00
> @@ -77,21 +77,10 @@ static int file_ioctl(struct file *filp,
>   return do_ioctl(filp, cmd, arg);
>  }
>  
> -
> -asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long 
> arg)
> +int vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd, unsigned 
> long arg)
>  {
> - struct file * filp;
>   unsigned int flag;
> - int on, error = -EBADF;
> - int fput_needed;
> -
> - filp = fget_light(fd, _needed);
> - if (!filp)
> - goto out;
> -
> - error = security_file_ioctl(filp, cmd, arg);
> - if (error)
> - goto out_fput;
> + int on, error = 0;
>  
>   switch (cmd) {
>   case FIOCLEX:
> @@ -157,6 +146,24 @@ asmlinkage long sys_ioctl(unsigned int f
>   error = do_ioctl(filp, cmd, arg);
>   break;
>   }
> + return error;
> +}
> +
> +asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long 
> arg)
> +{
> + struct file * filp;
> + int error = -EBADF;
> + int fput_needed;
> +
> + filp = fget_light(fd, _needed);
> + if (!filp)
> + goto out;
> +
> + error = security_file_ioctl(filp, cmd, arg);
> + if (error)
> + goto out_fput;
> +
> + error = vfs_ioctl(filp, fd, cmd, arg);
>   out_fput:
>   fput_light(filp, fput_needed);
>   out:
> = fs/compat.c 1.48 vs edited =
> --- 1.48/fs/compat.c  2005-01-15 14:31:01 -08:00
> +++ edited/fs/compat.c2005-01-18 11:07:56 -08:00
> @@ -437,6 +437,11 @@ asmlinkage long compat_sys_ioctl(unsigne
>   if (!filp)
>   goto out;
>  
> + /* RED-PEN how should LSM module know it's handling 32bit? */
> + error = security_file_ioctl(filp, cmd, arg);
> + if (error)
> + goto out_fput;
> +
>   if (filp->f_op && filp->f_op->compat_ioctl) {
>   error = filp->f_op->compat_ioctl(filp, cmd, arg);
>   if (error != -ENOIOCTLCMD)
> @@ -477,7 +482,7 @@ asmlinkage long compat_sys_ioctl(unsigne
>  
>   up_read(_sem);
>   do_ioctl:
> - error = sys_ioctl(fd, cmd, arg);
> + error = vfs_ioctl(filp, fd, cmd, arg);
>   out_fput:
>   fput_light(filp, fput_needed);
>   out:
> = include/linux/fs.h 1.373 vs edited =
> --- 1.373/include/linux/fs.h  2005-01-15 14:31:01 -08:00
> +++ edited/include/linux/fs.h 2005-01-18 11:10:54 -08:00
> @@ -1564,6 +1564,8 @@ extern int vfs_stat(char __user *, struc
>  extern int vfs_lstat(char __user *, struct kstat *);
>  extern int vfs_fstat(unsigned int, struct kstat *);
>  
> +extern int vfs_ioctl(struct file *, unsigned int, unsigned int, unsigned 
> long);
> +
>  extern struct file_system_type *get_fs_type(const char *name);
>  extern struct super_block *get_super(struct block_device *);
>  extern struct super_block *user_get_super(dev_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] cputime_t patches broke RLIMIT_CPU

[Roland McGrath]

> So would it not be nicer to just keep everything in seconds instead? 

Yes, that's how it was done before.  The patch I just posted was intended
to fix the apparent typo without getting any deeper.  Below is an untested
alternate patch to restore the old behavior under the new macro regime.

> Alternatively, seriously fix "secs_to_cputime()" to do the proper thing?
> Or did I miss a patch and you already did that?

I wasn't really on a cputime-cleanup rampage, just fixing the obvious bugs
I saw.  I hope Martin would like to do some cleanup.


Thanks,
Roland


--- linux-2.6/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -2299,17 +2325,17 @@ static void account_it_prof(struct task_
 static void check_rlimit(struct task_struct *p, cputime_t cputime)
 {
cputime_t total, tmp;
+   unsigned long secs;
 
total = cputime_add(p->utime, p->stime);
-   tmp = jiffies_to_cputime(p->signal->rlim[RLIMIT_CPU].rlim_cur);
-   if (unlikely(cputime_gt(total, tmp))) {
+   secs = cputime_to_secs(total);
+   if (unlikely(secs >= p->signal->rlim[RLIMIT_CPU].rlim_cur)) {
/* Send SIGXCPU every second. */
tmp = cputime_sub(total, cputime);
-   if (cputime_to_secs(tmp) < cputime_to_secs(total))
+   if (cputime_to_secs(tmp) < secs)
send_sig(SIGXCPU, p, 1);
/* and SIGKILL when we go over max.. */
-   tmp = jiffies_to_cputime(p->signal->rlim[RLIMIT_CPU].rlim_max);
-   if (cputime_gt(total, tmp))
+   if (secs >= p->signal->rlim[RLIMIT_CPU].rlim_max)
send_sig(SIGKILL, p, 1);
}
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] dynamic tick patch

[George Anzinger]

Tony Lindgren wrote:
* George Anzinger  [050119 15:00]:
I don't think you will ever get good time if you EVER reprogramm the PIT.  
That is why the VST patch on sourceforge does NOT touch the PIT, it only 
turns off the interrupt by interrupting the interrupt path (not changing 
the PIT).  This allows the PIT to be the "gold standard" in time that it is 
designed to be.  The wake up interrupt, then needs to come from an 
independent timer.  My patch requires a local APIC for this.  Patch is 
available at http://sourceforge.net/projects/high-res-timers/

Well on my test systems I have pretty good accurate time. But I agree,
PIT is not the best option for interrupt. It should be possible to use
other interrupt sources as well.
It should not matter where the timer interrupt comes from, as long as 
it comes when programmed. Updating time should be separate from timer
interrupts. Currently we have a problem where time is tied to the
timer interrupt.
In the HRT code time is most correctly stated as wall_time + 
get_arch_cycles_since(wall_jiffies) (plus conversion or two:)).  This is some 
what removed from the tick interrupt, but is resynced to that interrupt more or 
less each interrupt.

A second issue is trying to get the jiffies update as close to the run of the 
timer list as possible.  Without this we have no hope of high res timers.

--
George Anzinger   george@mvista.com
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: [PATCH] cputime.h seems to assume HZ==1000

[George Anzinger]

Linus Torvalds wrote:
On Mon, 17 Jan 2005, Roland McGrath wrote:
Shouldn't msecs mean msecs, not secs/HZ?

Hmm, sure, but why go through "msecs" at all?

--- linux-2.6/include/asm-generic/cputime.h
+++ linux-2.6/include/asm-generic/cputime.h
@@ -35,8 +35,8 @@ typedef u64 cputime64_t;
/*
 * Convert cputime to seconds and back.
 */
-#define cputime_to_secs(__ct)  (jiffies_to_msecs(__ct) / HZ)
-#define secs_to_cputime(__secs)(msecs_to_jiffies(__secs * HZ))
+#define cputime_to_secs(__ct)  (jiffies_to_msecs(__ct) / 1000)
+#define secs_to_cputime(__secs)(msecs_to_jiffies(__secs * 
1000))

iow, why not
#define cputime_to_secs(jif)((jif) / HZ)
#define secs_to_cputime(sec)((sec) * HZ)
which avoids double rounding issues etc.
If we care, the jiffies_to_msecs() code is in include/linux/jiffies.h just prior 
to other conversion code that does NOT make the assumtion that HZ is exact.  To 
be exact:

static inline long cputime_to_secs(unsigned long jif)
{
int t;
u64 result = (u64)jif * TICK_NSEC;
t = do_div(result ,NSEC_PER_SEC);
return (u32)result + t ? 1:0;  /* round up if not exact */
}
#define secs_to_cputime(sec) (((U64) sec * SEC_CONVERSION) >> SEC_JIFFIE_SC)
This last assumes sec worth of jiffies will actually fit in a long...
--
George Anzinger   george@mvista.com
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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[utz lehmann]

Hi Con

On Thu, 2005-01-20 at 09:39 +1100, Con Kolivas wrote:
> This is version 2 of the SCHED_ISO patch with the yield bug fixed and 
> code cleanups.

Thanks for the update.


@@ -2406,6 +2489,10 @@ void scheduler_tick(void)
task_t *p = current;
 
rq->timestamp_last_tick = sched_clock();
+   if (iso_task(p) && !rq->iso_refractory)
+   inc_iso_ticks(rq, p);
+   else 
+   dec_iso_ticks(rq, p);

scheduler_tick() is not only called by the timer interrupt but also form
the fork code. Is this intended? I think the accounting for
iso_refractory is wrong. Isn't calling it from
timer.c::update_process_times() better?

And shouldn't real RT task also counted? If RT tasks use 40% cpu you can
lockup the system as unprivileged user with SCHED_ISO because it doesn't
reach the 70% cpu limit.

Futher on i see a fundamental problem with this accounting for
iso_refractory. What if i manage as unprivileged user to run a SCHED_ISO
task which consumes all cpu and only sleeps very short during the timer
interrupt? I think this will nearly lockup or very slow down the system.
The iso_cpu limit can't guaranteed.


My simple yield DoS don't work anymore. But i found another way.
Running this as SCHED_ISO:

#include 
#include 
#include 
#include 
#include 

struct timeval tv;
int a, b, i0, i1;

int cpuusage ()
{
struct rusage ru;

getrusage(RUSAGE_SELF, );
return ru.ru_utime.tv_usec + ru.ru_stime.tv_usec;
}

int main ()
{
while(1) {
a = tv.tv_sec;
b = tv.tv_usec;
gettimeofday(, 0);
i0 = i1;
i1 = cpuusage();
if (i0 != i1) {
//  printf("%d.%06d\t%d.%06d\t%d\t%d\n",
// a, b, (int)tv.tv_sec, (int)tv.tv_usec, i0, i1);
}
}
}

It stalled the system for a few seconds and the drop it to SCHED_OTHER.
Then start a additional SCHED_OTHER cpu hog (while true; do : ; done).
The system locks up after a few seconds.
sysrq-n causes a reboot.


utz


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

Re: multiple page allocation errors in 2.6.10

[Nathan Scott]

On Wed, Jan 19, 2005 at 09:11:32AM +0100, Ake wrote:
> Hi!
> I'm getting multiple page allocation errors under high load.
> Should i worry about them?
> 
> nfsd: page allocation failure. order:4, mode:0x50
> ...[xfs stack]...

No, this one is OK and was a recoverable situation.
We need to do some (non-trivial) work in XFS to
prevent high order allocations in this situation
altogether, but your system should still be fine.

cheers.

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

Re: [NET] TUN needs CRC32 after adding multicast filtering to it

[Jeff Garzik]

Vitezslav Samel wrote:
Hi!
  Just tried to compile 2.6.11-rc1, but it fails with unresolved symbols
"bitreverse" etc. Found out that TUN driver needs CRC32 which I haven't
compiled in.
  Following patch fixes this. Please, consider applying.
Yes, already in -bk...
Jeff

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

Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Try again with JACK 0.99.48.  It's in CVS now, but you probably need
this tarball to get around the dreaded SourceForge anon CVS lag...
   http://www.joq.us/jack/tarballs/jack-audio-connection-kit-0.99.48.tar.gz
Thanks it finally ran to completion. By the way the patch you sent with 
the test suite did not apply so I had to do it manually (booraroom..)

The results I get with these versions are a lot more stable.  But,
there are still some puzzles about the scheduling.  Do you distinguish
different SCHED_ISO priorities?  
It was not clear whether that would be required or not. This is why 
testing is so critical because if you are having latency issues it 
wouldn't be a problem of getting cpu time since your cpu usage is well 
below the 70% limit.

JACK runs with three different SCHED_FIFO priorities:
  (1) The main jackd audio thread uses the -P parameter.  The JACK
  default is 10, but Rui's script sets it with -P60.  I don't think
  the absolute value matters, but the value relative to the other JACK
  realtime threads probably does.
  (2) The clients' process threads run at a priority one less (59).
  (3) The watchdog timer thread runs at a priority 10 greater (70).
  (4) LinuxThreads creates a manager thread in each process running
  one level higher than the highest user realtime thread priority.
Since I (finally) have it running at this end at last I'll do some 
benchmarking of my own to see how (lack of) priorities affects 
SCHED_ISO. If it is inadequate, it wont be too difficult to add them to 
the design. The problem with priorities is that once you go over the cpu 
limit everyone suffers equally; but that's a failsafe that you shouldn't 
actually hit in normal usage so it probably doesn't matter... Hmm come 
to think of it, it probably _is_ a good idea to implement priority 
support afterall.

Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] cputime_t patches broke RLIMIT_CPU

[Linus Torvalds]

On Wed, 19 Jan 2005, Roland McGrath wrote:
>
> The RLIMIT_CPU limit is in seconds, not in jiffies.

This patch would seem to have its own problems, though. See:

#define secs_to_cputime(__secs)   (msecs_to_jiffies(__secs * 
HZ))

which means that since there is no overflow checking (not in the current 
tree, and not in the fixed one that uses proper parenthesis and *1000, you 
can easily end up overflowing in the *1000 case, and causing nasty things.

So would it not be nicer to just keep everything in seconds instead? 
Alternatively, seriously fix "secs_to_cputime()" to do the proper thing?
Or did I miss a patch and you already did that?

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

Re: [PATCH] dynamic tick patch

[Tony Lindgren]

* Pavel Machek <[EMAIL PROTECTED]> [050119 15:58]:
> Hi!
> 
> > > > Thanks for trying it out. I have quite accurate time here on my
> > > > systems, and sleep works as it should. I wonder what's happening on
> > > > your system? If you have a chance, could you please post the results
> > > > from following simple tests?
> > > 
> > > On patched 2.6.11-rc1:
> > > 
> > > [Heh, clock is two times too fast, perhaps that makes ntpdate fail? -- 
> > > yes.
> > > 
> > > [EMAIL PROTECTED]:~# dmesg | grep -i time; for i in 1 2 3 4 5; do ntpdate 
> > > -b tak.cesnet.cz && sleep 10; done ; date && sleep 10 && date; while [ 1 
> > > ]; do date; done | uniq
> > > PCI: Setting latency timer of device :00:11.5 to 64
> > > dyn-tick: Enabling dynamic tick timer
> > > dyn-tick: Timer using dynamic tick
> > 
> > Thanks. Looks like you're running on PIT only, I guess my patch
> > currently breaks PIT (and possibly HPET) No dmesg message for "
> > "Using XXX for high-res timesource".
> 
> This machine definitely has TSC... What do I have to do in .config to
> make it do something interesting? My .config is:

I suspect it's the HPET_TIMER, see below. CONFIG_X86_PM_TIMER is
optional, otherwise TSC is used.

Tony

--- config.orig 2005-01-19 16:05:16.0 -0800
+++ config  2005-01-19 16:06:07.0 -0800
@@ -103,7 +103,7 @@
 CONFIG_X86_GOOD_APIC=y
 CONFIG_X86_INTEL_USERCOPY=y
 CONFIG_X86_USE_PPRO_CHECKSUM=y
-CONFIG_HPET_TIMER=y
+# CONFIG_HPET_TIMER is not set
 CONFIG_NO_IDLE_HZ=y
 # CONFIG_SMP is not set
 CONFIG_PREEMPT=y
@@ -169,7 +169,7 @@
 CONFIG_ACPI_POWER=y
 CONFIG_ACPI_PCI=y
 CONFIG_ACPI_SYSTEM=y
-# CONFIG_X86_PM_TIMER is not set
+CONFIG_X86_PM_TIMER=y
 # CONFIG_ACPI_CONTAINER is not set
 
 #

Re: Make pipe data structure be a circular list of pages, rather than

[Linus Torvalds]

On Wed, 19 Jan 2005, Larry McVoy wrote:
>   
> See how more generic that is?  Pipes are just one source/sink but 
> everything else needs to play as well.  How are you going to 
> implement a socket sending data to a file without the VM nonsense
> and the extra copies?

Heh. This is exactly why I originally told you it is undoable - because 
your model implies a O(M x N) complexity, where everybody has to agree on 
how to push things to everybody else. 

The thing that made me so excited about the pipes is exactly that the 
pipes is what finally made me see how to actually _implement_ kind of what 
you wanted. Instead of a "everything to everything" thing that has O(n²) 
complexity, it's a "everything to a pipe", where the pipe ends up being 
the common medium for things to talk to each other.

So you have an extra level of indirection, but it also means that now the
interface complexity is purely linear - everybody needs to know how to
accept data from (and push data to) a pipe, but they do _not_ need to know
how to do it to anything else.

I agree that it's not what you described, and one of my first emails 
describing it even said so, but I now notice that you weren't cc'd on 
that one (I tried to cc you on some others, but not the whole discussion):

   "...

And to be honest, my pipes aren't really what Larry's "splice()" was: his 
notion was more of a direct "fd->fd" thing, with nothing in between. That 
was what I still consider unworkable. 

The problem with splicing two file descriptors together is that it needs
for them to agree on the interchange format, and these things tend to be
very expensive from an interface angle (ie the format has to _exactly_
match the "impedance" at both ends, since any conversion would make the
whole exercise pointless - you'd be better off just doing a read and a
write).

..."

so what makes the pipes special is that they are the "impedance matcher". 

For example, absolutely _none_ of the regular file IO stuff wants to work 
with page fragments: it's all very much about whole-page stuff in the page 
cache, and that is how it has to be, considering the semantics of a 
coherent mmap etc. 

So your notion of having all the subsystems natively use a common format 
just never struck me as workable, because they very fundamentally do _not_ 
want work with the same kind of data structures, and forcing them to just 
didn't seem valid.  So I ignored splice as unworkable.

So think of my "splice" as giving you credit through the name, but at the
same time it definitely is something different (and in my opinion a lot
more workable). If you object to the name, I can call it "wire()" instead,
which was somebody elses suggestion, but I thought you might appreciate 
the name even if it isn't _really_ what you want ;)

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

Re: [PATCH] dynamic tick patch

[Pavel Machek]

Hi!

> > > Thanks for trying it out. I have quite accurate time here on my
> > > systems, and sleep works as it should. I wonder what's happening on
> > > your system? If you have a chance, could you please post the results
> > > from following simple tests?
> > 
> > On patched 2.6.11-rc1:
> > 
> > [Heh, clock is two times too fast, perhaps that makes ntpdate fail? -- yes.
> > 
> > [EMAIL PROTECTED]:~# dmesg | grep -i time; for i in 1 2 3 4 5; do ntpdate 
> > -b tak.cesnet.cz && sleep 10; done ; date && sleep 10 && date; while [ 1 ]; 
> > do date; done | uniq
> > PCI: Setting latency timer of device :00:11.5 to 64
> > dyn-tick: Enabling dynamic tick timer
> > dyn-tick: Timer using dynamic tick
> 
> Thanks. Looks like you're running on PIT only, I guess my patch
> currently breaks PIT (and possibly HPET) No dmesg message for "
> "Using XXX for high-res timesource".

This machine definitely has TSC... What do I have to do in .config to
make it do something interesting? My .config is:
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


config.gz
Description: Binary data

Re: 2.6.11-rc1-mm1

[Barry K. Nathan]

On Wed, Jan 19, 2005 at 11:06:10PM +, Marcos D. Marado Torres wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Fri, 14 Jan 2005, Barry K. Nathan wrote:
> 
> >This isn't new to 2.6.11-rc1-mm1, but it has the infamous (to Fedora
> >users) "ACPI shutdown bug" -- poweroff hangs instead of actually turning
> >the computer off, on some computers. Here's the RH Bugzilla report where
> >most of the discussion took place:
> >
> >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132761
> 
> This is the same bug I've talked here:
> http://lkml.org/lkml/2005/1/11/88

FWIW the RH Bugzilla bug is (unfortunately) discussing several different
similar but not identical bugs, as far as I can tell.

> This only happens with -mm and not with vanilla sources.
> 
> I'm reporting about this issue in an ASUS M3N laptop with Debian.
> 
> Best regards,
> Mind Booster Noori

FWIW my report against -mm (where I narrowed it down to one of the kexec
patches in particular) is here:
http://bugme.osdl.org/show_bug.cgi?id=4041

-Barry K. Nathan <[EMAIL PROTECTED]>

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

Re: patch to fix set_itimer() behaviour in boundary cases

[George Anzinger]

Arjan van de Ven wrote:
On Sun, 2005-01-16 at 00:58 +, Alan Cox wrote:
On Sad, 2005-01-15 at 09:30, Andrew Morton wrote:
Matthias Lang <[EMAIL PROTECTED]> wrote:
These are things we probably cannot change now.  All three are arguably
sensible behaviour and do satisfy the principle of least surprise.  So
there may be apps out there which will break if we "fix" these things.
If the kernel version was 2.7.0 then well maybe...
These are things we should fix. They are bugs. Since there is no 2.7
plan pick a date to fix it. We should certainly error the overflow case
*now* because the behaviour is undefined/broken. The other cases I'm not
clear about. setitimer() is a library interface and it can do the basic
checking and error if it wants to be strictly posixly compliant.

why error?
I'm pretty sure we can make a loop in the setitimer code that detects
we're at the end of jiffies but haven't upsurped the entire interval the
user requested yet, so that the code should just do another round of
sleeping...
That would work for sleep (but glibc uses nanosleep for that) but an itimer 
delivers a signal.  Rather hard to trap that in glibc.

For what its worth, you can tell it was truncated by reading back the remaining 
time.  That could be done in the glibc wrapper and an error passed back, but 
actually doing the proper wait using this interface is rather hard.

The timer_settime(CLOCK...  interface detects overflow and passes back an 
error...
Clock_nanosleep on the otherhand, will sleep for the whole time, provide the 
machine doesn't turn to dust :)
--
George Anzinger   george@mvista.com
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: [PATCH] dynamic tick patch

[Tony Lindgren]

* Pavel Machek <[EMAIL PROTECTED]> [050119 15:47]:
> Hi!
> 
> > > > > > As this patch is related to the VST/High-Res timers, there
> > > > > > are probably various things that can be merged. I have not
> > > > > > yet looked at what all could be merged.
> > > > > > 
> > > > > > I'd appreciate some comments and testing!
> > > > > 
> > > > > Good news is that it does seem to reduce number of interrupts. Bad
> > > > > news is that time now runs faster (like "sleep 10" finishes in ~5
> > > > > seconds) and that I could not measure any difference in power
> > > > > consumption.
> > > > 
> > > > Thanks for trying it out. I have quite accurate time here on my
> > > > systems, and sleep works as it should. I wonder what's happening on
> > > > your system? If you have a chance, could you please post the results
> > > > from following simple tests?
> > > 
> > > On patched 2.6.11-rc1:
> > > 
> > > [Heh, clock is two times too fast, perhaps that makes ntpdate fail? -- 
> > > yes.
> > > 
> > > [EMAIL PROTECTED]:~# dmesg | grep -i time; for i in 1 2 3 4 5; do ntpdate 
> > > -b tak.cesnet.cz && sleep 10; done ; date && sleep 10 && date; while [ 1 
> > > ]; do date; done | uniq
> > > PCI: Setting latency timer of device :00:11.5 to 64
> > > dyn-tick: Enabling dynamic tick timer
> > > dyn-tick: Timer using dynamic tick
> > 
> > Thanks. Looks like you're running on PIT only, I guess my patch
> > currently breaks PIT (and possibly HPET) No dmesg message for "
> > "Using XXX for high-res timesource".
> 
> Okay, so I set CONFIG_HPET. CONFIG_X86_TSC was already set, I wonder
> why the code did not use it?

Can you try with no CONFIG_HPET and CONFIG_X86_TCS or X86_PM_TIMER?
I don't have hardware with HPET, so I have not looked at it.

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] dynamic tick patch

[Pavel Machek]

Hi!

> > > > > As this patch is related to the VST/High-Res timers, there
> > > > > are probably various things that can be merged. I have not
> > > > > yet looked at what all could be merged.
> > > > > 
> > > > > I'd appreciate some comments and testing!
> > > > 
> > > > Good news is that it does seem to reduce number of interrupts. Bad
> > > > news is that time now runs faster (like "sleep 10" finishes in ~5
> > > > seconds) and that I could not measure any difference in power
> > > > consumption.
> > > 
> > > Thanks for trying it out. I have quite accurate time here on my
> > > systems, and sleep works as it should. I wonder what's happening on
> > > your system? If you have a chance, could you please post the results
> > > from following simple tests?
> > 
> > On patched 2.6.11-rc1:
> > 
> > [Heh, clock is two times too fast, perhaps that makes ntpdate fail? -- yes.
> > 
> > [EMAIL PROTECTED]:~# dmesg | grep -i time; for i in 1 2 3 4 5; do ntpdate 
> > -b tak.cesnet.cz && sleep 10; done ; date && sleep 10 && date; while [ 1 ]; 
> > do date; done | uniq
> > PCI: Setting latency timer of device :00:11.5 to 64
> > dyn-tick: Enabling dynamic tick timer
> > dyn-tick: Timer using dynamic tick
> 
> Thanks. Looks like you're running on PIT only, I guess my patch
> currently breaks PIT (and possibly HPET) No dmesg message for "
> "Using XXX for high-res timesource".

Okay, so I set CONFIG_HPET. CONFIG_X86_TSC was already set, I wonder
why the code did not use it?
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] dynamic tick patch

[john stultz]

On Thu, 2005-01-20 at 00:26 +0100, Thomas Gleixner wrote:
> On Wed, 2005-01-19 at 14:59 -0800, George Anzinger wrote:
> > I don't think you will ever get good time if you EVER reprogramm the PIT.
> 
> Why not ? If you have a continous time source, which keeps track of
> "ticks" regardless the CPU state, why should PIT reprogramming be evil ?

That's a big if.  The problem is that while the PIT has its problems
(such as lost ticks), it runs at a known frequency and is reasonably
accurate. Time sources like the TSC have the problem that it doesn't run
at a known frequency, and thus we have to calibrate it (usually using
the PIT). Unfortunately this calibration is not extremely accurate
(George can go on to the reasons why), which causes the TSC to be a poor
stand alone time source.

That said, the PIT is a poor time source as well, as it does loose ticks
and is very slow to access. ACPI PM and HPET are better as they don't
have the lost tick problem, but they are still off chip and slower to
access then the TSC.

For an example of your ideal continuous timesource, check out the
timebase on PPC/PPC64. Other arches also have similar well behaved time
hardware. 

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: [kbuild 2/5] Dont use the running kernels config file by default

[Gerd Knorr]

Andreas Gruenbacher <[EMAIL PROTECTED]> writes:

> The user does a ``make menuconfig'', and expects to see sane defaults.
> What kconfig really does is take the running kernel's configuration
> instead. This is a ad choice; it makes much more sense to take
> arch/$ARCH/defconfig.

IIRC the vanilla kernel's arch/i386/defconfig is the "this config
boots Linus' machine" configuration (or has that changed recently?).
I certainly wouldn't call that a sane default ...

For vendor kernels with a generic defconfig that makes sense though.

  Gerd

-- 
#define printk(args...) fprintf(stderr, ## args)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc1 vs. PowerMac 8500/G3 (and VAIO laptop) [usb-storage oops]

[John Mock]

First, thanks to those involved in the 2.6.10 effort, as that's the first 
kernel in quite some time that seems stable on my PowerMac 8500/G3.  It is
not quite as good on the Sony VAIO laptop, due to software suspend problems
(mostly USB related).

2.6.11-rc1 seemed to help with the VAIO laptop's problems.  However i just
discovered both have trouble with USB storage devices on the PowerMac.  In
addition, there's a minor compilation glitch:

 CC  arch/ppc/kernel/ppc_htab.o
 CC  arch/ppc/kernel/perfmon.o
   arch/ppc/kernel/perfmon.c: In function `dummy_perf':
   arch/ppc/kernel/perfmon.c:55: error: `MMCR0_PMXE' undeclared (first use in 
this function)
   arch/ppc/kernel/perfmon.c:55: error: (Each undeclared identifier is reported 
only once
   arch/ppc/kernel/perfmon.c:55: error: for each function it appears in.)
   make[1]: *** [arch/ppc/kernel/perfmon.o] Error 1
   make: *** [arch/ppc/kernel] Error 2

Conditionalizing out the offending line in dummy_perf() gets around this.

However, both a digital camera and a iomega CD/RW get the same oops on
the PPC (see below) when plugged in after booting up.  2.6.8 does not
exhibit this problem (with 2.6.9 having too many unrelated problems to
be worth testing), but both 2.6.10 and 2.6.11-rc1 do.  See below for
log extracts and .config file.

New to 2.6.11-rc1 is that 'lsusb' exhibits 'endian' problems on the PowerMac.

   Bus 004 Device 002: ID 6d04:01c0
   Bus 004 Device 001: ID :  
   Bus 003 Device 002: ID ce0a:0112
   Bus 003 Device 001: ID :  
   Bus 002 Device 001: ID :  
   Bus 001 Device 001: ID :  

Instead of

   Bus 004 Device 002: ID 046d:c001 Logitech, Inc. N48/M-BB48 [FirstMouse Plus]
   Bus 004 Device 001: ID :  
   Bus 003 Device 002: ID 0ace:1201 GigaFast WF741-UIC Wireless 11 Mbps
   Bus 003 Device 001: ID :  
   Bus 002 Device 001: ID :  
   Bus 001 Device 001: ID :  

I'm testing two USB cards (on OHCI type and the other UHCI/ECHI) and both
seem to exhibit similar symptoms.

As before, suspending the VAIO laptop breaks its firewire device (CD-RW/DVD).

 -- JM

Attachments: 'dmesg' extracts containing 'oops' [.config upon request]
---
...
hub 1-0:1.0: state 5 ports 4 chg fff0 evt 0008
ehci_hcd :00:0f.2: GetStatus port 3 status 001803 POWER sig=j  CSC CONNECT
hub 1-0:1.0: port 3, status 0501, change 0001, 480 Mb/s
hub 1-0:1.0: debounce: port 3: total 100ms stable 100ms status 0x501
ehci_hcd :00:0f.2: port 3 full speed --> companion
ehci_hcd :00:0f.2: GetStatus port 3 status 003801 POWER OWNER sig=j  CONNECT
hub 3-0:1.0: state 5 ports 2 chg fffc evt 0002
uhci_hcd :00:0f.1: port 1 portsc 0093,00
hub 3-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
usb 3-1: new full speed USB device using uhci_hcd and address 3
usb 3-1: ep0 maxpacket = 8
usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-1: default language 0x0409
usb 3-1: Product: Nikon Digital Camera E4500
usb 3-1: Manufacturer: NIKON
usb 3-1: SerialNumber: 03552010
usb 3-1: hotplug
usb 3-1: adding 3-1:1.0 (config #1, interface 0)
usb 3-1:1.0: hotplug
hub 3-0:1.0: state 5 ports 2 chg fffc evt 0002
Initializing USB Mass Storage driver...
usb-storage 3-1:1.0: usb_probe_interface
usb-storage 3-1:1.0: usb_probe_interface - got id
scsi1 : SCSI emulation for USB Mass Storage devices
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
  Vendor: NIKON Model: NIKON DSC E4500   Rev: 1.00
  Type:   Direct-Access  ANSI SCSI revision: 02
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT 
NIP: C009ABA4 LR: C009ABA4 SP: C13E7DC0 REGS: c13e7d10 TRAP: 0300Not tainted
MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 006C, DSISR: 4000
TASK = c12f43f0[3641] 'usb-stor-scan' THREAD: c13e6000
Last syscall: -1 
GPR00: C009ABA4 C13E7DC0 C12F43F0 C01AADE0 0047 0047 C13E7DF8 000A 
GPR08:  8000 C258B4DC C13E7DC0 42002448 1001E284 100013A4  
GPR16:     100013A4 100187B0  C13E7F18 
GPR24: C13E7F1C 0001  C1907708 C13E7DF8 C10E23FC C190770C 006C 
NIP [c009aba4] create_dir+0x38/0x1d0
LR [c009aba4] create_dir+0x38/0x1d0
Call trace:
 [c009ad98] sysfs_create_dir+0x48/0x94
 [c00ad688] create_dir+0x28/0x6c
 [c00ad98c] kobject_add+0x5c/0x15c
 [c00eaa40] device_add+0xb8/0x18c
 [c0111f9c] scsi_sysfs_add_sdev+0x78/0x39c
 [c01107c4] scsi_add_lun+0x2f8/0x364
 [c011091c] scsi_probe_and_add_lun+0xec/0x1d8
 [c010] scsi_scan_target+0x7c/0xec
 [c0fc] scsi_scan_channel+0x7c/0x9c
 [c01112f4] scsi_scan_host_selected+0xd8/0x138
 [cfb86cf8] usb_stor_scan_thread+0x6c/0x124 [usb_storage]
 [c0006704] 

Re: [PATCH 2.6] I2C: Kill i2c_client.id

[Greg KH]

On Sun, Jan 16, 2005 at 07:46:53PM +0100, Jean Delvare wrote:
> Hi Greg,
> 
> As discussed earlier on the LKML [1], here comes a patch set killing the
> id member of the i2c_client structure. Let me recap my main reasons for
> doing so:

I've applied all 5 patches, and then just deleted the field altogether
(mainly because sparse complained about it, and there's no reason to
have it around anymore.)

thanks for doing this work, it was really needed.

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

Re: VST patches ported to 2.6.11-rc1

[Tony Lindgren]

* George Anzinger  [050119 15:21]:
> George Anzinger wrote:
> >Pavel Machek wrote:
> >
> >>Hi!
> >>
> >>
> >>>I really hate sf download system... Here are those patches (only
> >>>common+i386) ported to 2.6.11-rc1.
> >>
> >>
> >>
> >>Good news is it booted. But I could not measure any powersavings by
> >>turning it on. (I could measure difference between HZ=100 and
> >>HZ=1000).
> >>
> >>Hmm, it does not want to do anything. threshold used to be 1000, does
> >>it mean that it would not use vst unless there was one second of quiet
> >>state? I tried to lower it to 10 ("get me HZ=100 power consumption")
> >>but it does not seem to be used, anyway:
> 
> I wonder if the problem is that we are not disabling the PIT interrupt.  I 
> have a PIII SMP system so the interrupt path may be different and the code 
> to stop interrupts may be wrong.  The normal system does not admit to 
> stopping the time base so it is possible that this is wrong.

That could make a difference as hlt and ACPI C2/C3 will wake to PIT
interrupt AFAIK.

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] I2C: Allow it87 pwm reconfiguration

[Greg KH]

On Sat, Jan 15, 2005 at 04:30:45PM +0100, Jean Delvare wrote:
> Quoting myself:
> 
> > As soon as you will have confirmed that everything worked as expected,
> > Jonas and I will provide a patch adding a pwm polarity reconfiguration
> > module parameter for you to test. This should give you access to the
> > PWM features of your it87 chip again, but in a safe way for a change
> > ;)
> 
> Here comes this patch. The new "fix_pwm_polarity" module parameter
> allows one to force the it87 chip reconfiguration. This is only
> supported in the case the original PWM configuration is suspected to be
> bogus, and only if we think that reconfiguring the chip is safe.
> 
> I wish to thank Rudolf Marek and Jonas Munsin again for their testing
> and review of my code.
> 
> Greg, please apply, thanks.

Applied, thanks.

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

Re: [PATCH] raid6: altivec support

[Benjamin Herrenschmidt]

On Wed, 2005-01-19 at 14:48 +, David Woodhouse wrote:
> On Wed, 2005-01-19 at 08:45 -0600, Kumar Gala wrote:
> > We did talk about looking at using some work Ben did in ppc64 with OF 
> > in ppc32.  John Masters was looking into this, but I havent heard much
> > from him on it lately.
> > 
> > The firmware interface on the ppc32 embedded side is some what broken 
> > in my mind.
> 
> The binary structure which changes every few weeks and which is shared
> between the bootloader and the kernel? Yeah, "somewhat broken" is one
> way of putting it :)
> 
> The ARM kernel does it a lot better with tag,value pairs.

And ppc64 adds a flattened device-tree format, even better imho :)

Ben.


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

Re: [PATCH] dynamic tick patch

[Thomas Gleixner]

On Wed, 2005-01-19 at 14:59 -0800, George Anzinger wrote:
> I don't think you will ever get good time if you EVER reprogramm the PIT.

Why not ? If you have a continous time source, which keeps track of
"ticks" regardless the CPU state, why should PIT reprogramming be evil ?

tglx


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

Re: [PATCH] raid6: altivec support

[Benjamin Herrenschmidt]

On Wed, 2005-01-19 at 07:43 +, David Woodhouse wrote:
> On Wed, 2005-01-19 at 15:11 +1100, Benjamin Herrenschmidt wrote:
> > We should probably "backport" that simplification to ppc32...
> 
> Yeah I'm increasingly tempted to merge ppc32/ppc64 into one arch
> like mips/parisc/s390. Or would that get vetoed on the basis that we
> don't have all that horrid non-OF platform support in ppc64 yet, and
> we're still kidding ourselves that all those embedded vendors will
> either not notice ppc64 or will use OF?

Oh well... i've though about it too, and decided that I was not ready to
try it. For one, the problem you mention, with the pile of embedded
junk. I made the design decision to define an OF client interface as the
standard & mandatory entry mecanism to the ppc64 kernel (except legacy
iSeries of course, but I don't want that to multiply). That or the
kexec-like entrypoint passing a flattened device-tree in.

Also, there are other significant differences in other areas. At this
point, I think the differences are  bigger than the common code.

What would be interesting would be to proceed incrementally, having a
directory somewhere to put the "common" ppc/ppc64 code, and slowly
moving things there.

Ben.


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

Re: [PATCH 2.6] I2C: Fix DS1621 detection

[Greg KH]

On Wed, Jan 19, 2005 at 09:27:49PM +0100, Aur?lien Jarno wrote:
> Hi Greg,
> 
> Dallas Semiconductors as recently changed the design of their DS1621
> chips, including the bits that were checked in the kernel driver to 
> detect it.
> 
> The patch below fixes the detection by checking an other bit of the
> configuration register instead.
> 
> Please apply.

Applied, thanks.

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

[PATCH] Alps touchpad probing failure

[Daniel Caujolle-Bert]

Hi,

 With 2.6.11-rc1 bk6 and bk7 (didn't tried with < bk6), my alps touchpad is no 
more correctly probed, it's recognised as a standard PS/2 mouse.
 So, with this trivial two line patch, everything is working again.

Cheers.
-- 
73's de Daniel "Der Schreckliche", F1RMB.

 -=- Daniel Caujolle-Bert -=- [EMAIL PROTECTED] -=-
-=- http://naboo.homelinux.org -=-
--- linux-2.6.11-rc1/drivers/input/mouse/alps.c	2005-01-19 19:43:36.0 +0100
+++ linux/drivers/input/mouse/alps.c	2005-01-19 19:34:32.0 +0100
@@ -194,6 +194,12 @@
 	int i;
 
 	/*
+	 * Let's clean the stuff.
+	 */
+	if(psmouse_reset(psmouse) < 0)
+	  printk(KERN_ERR "alps reset failed\n");
+
+	/*
 	 * First try "E6 report".
 	 * ALPS should return 0x00,0x00,0x0a or 0x00,0x00,0x64
 	 */


pgpHT1nexYL59.pgp
Description: PGP signature