Re: Loading both the pata_atiixp and the ahci driver causes problems

[Jon Masters]

Tejun Heo wrote:


Please take a look at the JMB quirk in drivers/pci/quirks.c in the
latest libata-dev#upstream tree for details.


For interest, I will, thanks for the info.

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: [ck] Re: is RSDL an "unfair" scheduler too?

[Radoslaw Szkodzinski]

On 3/18/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:

On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote:

> Maybe we're all discussing the problem because we have reached the point
> where we need two types of schedulers : one for the desktop and one for
> the servers. After all, this is already what is proposed with preempt,
> it would make sense provided they share the same core and avoid ifdefs
> or unused structure members. Maybe adding OPTIONAL unfairness to RSDL
> would help some scenarios, but in any case it is important to retain
> the default fairness it provides.

Bingo.



Sounds like Staircase's interactive mode switch, except this actually
requires writing additional code.

The per-user system would also be nice for servers, provided there are
CPU/disc IO/swapper/... quotas or priorities at least.

All in all, I'd hate to see mldonkey eating 1/3 of CPU time, just
because it runs as another user.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + remove-the-likelypid-check-in-copy_process.patch added to -mm tree

[sukadev]

Eric W. Biederman [EMAIL PROTECTED] wrote:
| Oleg Nesterov <[EMAIL PROTECTED]> writes:
| 
| > Yes! I meant we should change INIT_SIGNALS(), currently it does
| >
| > #define INIT_SIGNALS(sig) {
| > ...
| > .pgrp   = 1,
| > { .__session  = 1},
| >
| > and this confuses (I think) set_special_pids(1,1) above. Because
| > __set_special_pids() still deals with pid_t, not "struct pid".
| >
| > Unless I missed something, we should kill these 2 initializations
| > above.
| 
| Got it.  I agree we should initialize those fields to 0.
| 
| Sukadev you want to get that?

Sure. Will do that.

Thanks Oleg for your detailed review/comments.

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

Re: RSDL v0.31

[Kasper Sandberg]

On Sun, 2007-03-18 at 07:17 +0100, Mike Galbraith wrote:
> On Sat, 2007-03-17 at 23:55 +0300, Al Boldi wrote:
> 
> > Mike, I'm not saying RSDL is perfect, but v0.31 is by far better than 
> > mainline.  Try this easy test:
> > 
> > startx with the vesa driver
> > run reflect from the mesa5.0-demos
> > load 5 cpu-hogs
> > start moving the mouse
> > 
> > On my desktop, mainline completely breaks down, and no nicing may rescue.
> 
> (hmm.. i would think that _renicing_ X would help that)
> 
> > On RSDL, even without nicing, the desktop is at least useable.
> 
> So neither does a good job with this load.
that sorely depends on what you mean by good job.

It seems like what you call a good job is preserving the speed of the
gui(X + apps which uses it) at _ALL_ costs to other stuff.

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

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

Re: Loading both the pata_atiixp and the ahci driver causes problems

[Tejun Heo]

Hello, Jon.

Jon Masters wrote:
>> Dunno much about sb600 but ahci and pata_atiixp are probably using
>> separate IO regions && separate PCI functions.
> 
> Yeah. I actually thought about this whole issue a bit more recently -
> things like SATA/PATA interference when you've got a part that emulates
> legacy functionality so can appear as two different kinds of device -
> since I don't think my brain was really bothering to listen before.
> Words were going in, but it chose to ignore what was being said.

Dunno about the history.  Oh well, as long as the problem gets fixed.

> Only thing that comes to mind is in-driver logic/driver loading ordering
> hack combinations. At least if you've got loadable modules, you've got a
> fighting chance of fixing this kind of situation - built-in and you need
> to fight with whatever ordering exists in the array of init functions.

Not sure whether it applies to sb600 directly but libata policy for this
type of situation is..

* always prefer the native / more capable (read ahci) interface over
emulated SFF interface.

* program the device and update PCI header using a PCI quirk such that
module loading order or BIOS setting doesn't affect which driver gets
attached.  Note that if the controller needs to programmed in specific
way, the quirk also needs to be called during resume.  In this case, the
function for SFF interface can simply be disabled.

Please take a look at the JMB quirk in drivers/pci/quirks.c in the
latest libata-dev#upstream tree for details.

Thanks.

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

Re: is RSDL an "unfair" scheduler too?

[Mike Galbraith]

On Sat, 2007-03-17 at 23:09 -0700, Bill Huey wrote:

> Like I've said in a previous email, SGI schedulers have an interactive
> term in addition to the normal "nice" values. If RSDL ends up being too
> rigid for desktop use, then this might be a good idea to explore in
> addition to priority manipulation.

I've done that already (ain't perfect yet, maybe never be).  The hard
part is making it automatic, and not ruining the good side of RSDL in
the process.

-Mike

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

Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #2]

[Kyle Moffett]

On Mar 16, 2007, at 10:11:41, Alan Cox wrote:
I know what they are; and I don't think that what's available  
covers it.



and use a proper standard socket type.


Assuming that that list is exhaustive...


SOCK_RDM seems to match perfectly well here. The point isn't to  
enumerate everything in the universe the point is to find "works  
like" parallels good enough to avoid more special casing.


IMHO the problem with classifying RxRPC as a "reliable datagram"  
socket is that even an atomic unidirectional communication isn't a  
single datagram, it's at least 3; there is shared connection state  
and security context on both sides which pertains to a collection of  
independent and possibly simultaneous RxRPC calls.  From the digging  
around that I did in the kernel socket code a while ago I don't see a  
cleaner way of implementing it than a new SOCK_RXRPC.


Cheers,
Kyle Moffett

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

Re: Loading both the pata_atiixp and the ahci driver causes problems

[Jon Masters]

Tejun Heo wrote:

Jon Masters wrote:

Chuck Ebbert wrote:


If you try to load both the pata_atiixp and the ahci driver
(for the same ATI SB600 adapter), very strange things happen.
The AHCI driver churns for three minutes or so, spewing
messages like this, then nothing works:

<6>ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
<4>ata3.00: qc timeout (cmd 0xec)
<4>ata3.00: failed to IDENTIFY (I/O error, err_mask=0x104)
Shouldn't it be able to tell the device has already been
claimed by some other driver?

One would assume it'd fail to grab the PCI IO ranges twice? I haven't
looked at the code but I have seen this bug mentioned elsewhere so I
might well end up having to do that yet :-)


Dunno much about sb600 but ahci and pata_atiixp are probably using
separate IO regions && separate PCI functions.


Yeah. I actually thought about this whole issue a bit more recently - 
things like SATA/PATA interference when you've got a part that emulates 
legacy functionality so can appear as two different kinds of device - 
since I don't think my brain was really bothering to listen before. 
Words were going in, but it chose to ignore what was being said.


Only thing that comes to mind is in-driver logic/driver loading ordering 
hack combinations. At least if you've got loadable modules, you've got a 
fighting chance of fixing this kind of situation - built-in and you need 
to fight with whatever ordering exists in the array of init functions.


Jon.

P.S. Guess this means I need to admit I was wrong and apologize to 
Zaitcev sometime too in relation to another discussion...bah :P


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

Re: is RSDL an "unfair" scheduler too?

[Mike Galbraith]

On Sun, 2007-03-18 at 06:24 +0100, Willy Tarreau wrote:

> Maybe we're all discussing the problem because we have reached the point
> where we need two types of schedulers : one for the desktop and one for
> the servers. After all, this is already what is proposed with preempt,
> it would make sense provided they share the same core and avoid ifdefs
> or unused structure members. Maybe adding OPTIONAL unfairness to RSDL
> would help some scenarios, but in any case it is important to retain
> the default fairness it provides.

Bingo.

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

Re: RSDL v0.31

[Mike Galbraith]

On Sat, 2007-03-17 at 23:55 +0300, Al Boldi wrote:

> Mike, I'm not saying RSDL is perfect, but v0.31 is by far better than 
> mainline.  Try this easy test:
> 
> startx with the vesa driver
> run reflect from the mesa5.0-demos
> load 5 cpu-hogs
> start moving the mouse
> 
> On my desktop, mainline completely breaks down, and no nicing may rescue.

(hmm.. i would think that _renicing_ X would help that)

> On RSDL, even without nicing, the desktop is at least useable.

So neither does a good job with this load.

-Mike

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

Re: is RSDL an "unfair" scheduler too?

[hui]

On Sun, Mar 18, 2007 at 06:24:40AM +0100, Willy Tarreau wrote:
> > Dunno. I guess a lot of people would like to then manage the classes, 
> > which would be painful as hell. 
> 
> Sure ! I wouldn't like people to point the finger on Linux saying "hey
> look, they can't write a good scheduler so you have to adjust the knobs
> yourself!". I keep in mind that Solaris' scheduler is very good, both
> fair and interactive. FreeBSD was good (I haven't tested for a long time).
> We should manage to get something good for most usages, and optimize
> later for specific uses.

Like I've said in a previous email, SGI schedulers have an interactive
term in addition to the normal "nice" values. If RSDL ends up being too
rigid for desktop use, then this might be a good idea to explore in
addition to priority manipulation.

However, it hasn't been completely proven that RSDL can't handle desktop
loads and that needs to be completely explored first. It certain seems
like, from the .jpgs that were posted earlier in the thread regarding mysql
performance, that RSDL seems to have improved performance for those set
ups so it's not universally the case that it sucks for server loads. The
cause of this performance difference has yet to be pinpointed.

Also, bandwidth scheduler like this are a new critical development for
things like the -rt patch. It would benefit greatly if the RSDL basic
mechanisms (RR and deadlines) were to somehow slip into that patch and
be used for a more strict -rt based scheduling class. It would be the basis
for first-class control over process resource usage and would be a first
in Linux or any mainstream kernel.

This would be a powerful addition to Linux as a whole and RSDL should
not be dismissed without these considerations. If it can somehow be
integrated into the kernel with interactivity concerns addressed, then
it would be an all out win for the kernel in both these areas.

bill

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

Re: is RSDL an "unfair" scheduler too?

[Avi Kivity]

Willy Tarreau wrote:

On Sat, Mar 17, 2007 at 06:32:29PM -0700, Linus Torvalds wrote:
  

On Sat, 17 Mar 2007, William Lee Irwin III wrote:


One issue this raises is prioritizing users on a system, threads within
processes, jobs within users, etc.
  
Doing some "classing" even by just euid might be a good idea. It would 
actually catch X automatically most of the time, because the euid of the X 
server is likely to be root, so even for the "trivial" desktop example, it 
would kind of automatically mean that X would get about 50% of CPU time 
even if you have a hundred user clients, just because that's "fair" by 
euid.



Warning: all these ideas seem interesting for desktop, but are definitely
not for servers. I found RSDL to be excellent on servers, compared to
mainline in which some services are starving under load. I can understand
that on the desktop people want some unfairness, and I like the pgrp idea
for instance. But this one will certainly fail on servers, or make the
admins get grey hair very soon.
  


I didn't suggest adding any unfairness!  I suggested being fair by 
user/job/process instead of being fair by thread (which is actually 
unfair as it favors multi threaded processes over single threaded 
processes).



Maybe we're all discussing the problem because we have reached the point
where we need two types of schedulers : one for the desktop and one for
the servers. After all, this is already what is proposed with preempt,
it would make sense provided they share the same core and avoid ifdefs
or unused structure members. Maybe adding OPTIONAL unfairness to RSDL
would help some scenarios, but in any case it is important to retain
the default fairness it provides.
  


I hope not.  I think that reducing the timeslice base, combined with 
renicing X all the way to hell should suffice.



--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

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

Re: libata reports bogus addresses for everything (was PATA_PCMCIA cmd port)

[Tejun Heo]

Alan Cox wrote:
> On Sat, 17 Mar 2007 22:00:50 +0900
> Komuro <[EMAIL PROTECTED]> wrote:
> 
>> Hi,
>>  
>> The pata_pcmcia driver reports the cmd port is 0x00010100,
>> but actually the cmd port is 0x0100.
>>
>> Is this corect?
> 
> When the pci_iomap patches were applied the ports reported for every
> device went strange.  It appears to display the wrong information
> nowdays. I see the same but I've got many more important things to work
> on before I even bother to look at it.
> 
> My guess is someone is now printing the iomap virtual addresses not the
> bus ones.

Yes, we're printing the ioaddr.* directly and those are all iomapped
addressed now.  I wonder whether we should fix this or push the port
printing to LLDs (with sff helpers in libata-sff).  ahci and
pata_generic sharing one format doesn't sound like a too good idea.
I'll fix it after new init model.

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

Re: [BUG 2.6.21-rc3-git9] SATA NCQ failure with Samsum HD401LJ

[Tejun Heo]

Christian wrote:
>> This does indeed look like a drive side issue to me (the controller is
>> reporting CPBs with response flags 2 which as far as I can tell
>> indicates it's still waiting for the drive to complete the request).
> 
> I have been using this hw-config (SATA II, NCQ) since the nvidia ADMA support 
> made it in the -mm kernel (maybe around 2.6.19-mm? or even earlyer). I'm 
> seeing this problem excessively since I upgraded to 2.6.21-rc3-mm1. I think 
> something got broken recently...

Can you post the result of "hdparm -I /dev/sdX"?

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

Re: Loading both the pata_atiixp and the ahci driver causes problems

[Tejun Heo]

Jon Masters wrote:
> Chuck Ebbert wrote:
> 
>> If you try to load both the pata_atiixp and the ahci driver
>> (for the same ATI SB600 adapter), very strange things happen.
>> The AHCI driver churns for three minutes or so, spewing
>> messages like this, then nothing works:
>>
>> <6>ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>> <4>ata3.00: qc timeout (cmd 0xec)
>> <4>ata3.00: failed to IDENTIFY (I/O error, err_mask=0x104)
> 
>> Shouldn't it be able to tell the device has already been
>> claimed by some other driver?
> 
> One would assume it'd fail to grab the PCI IO ranges twice? I haven't
> looked at the code but I have seen this bug mentioned elsewhere so I
> might well end up having to do that yet :-)

Dunno much about sb600 but ahci and pata_atiixp are probably using
separate IO regions && separate PCI functions.

Conke, care to educate us a bit here?

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

Re: is RSDL an "unfair" scheduler too?

[Mike Galbraith]

On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote:

> Now for something constructive... by any chance is Mike running KDE 
> instead of GNOME?

Yes.

-Mike

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

Re: is RSDL an "unfair" scheduler too?

[Willy Tarreau]

On Sat, Mar 17, 2007 at 06:32:29PM -0700, Linus Torvalds wrote:
> 
> 
> On Sat, 17 Mar 2007, William Lee Irwin III wrote:
> > 
> > One issue this raises is prioritizing users on a system, threads within
> > processes, jobs within users, etc.
> 
> Doing some "classing" even by just euid might be a good idea. It would 
> actually catch X automatically most of the time, because the euid of the X 
> server is likely to be root, so even for the "trivial" desktop example, it 
> would kind of automatically mean that X would get about 50% of CPU time 
> even if you have a hundred user clients, just because that's "fair" by 
> euid.

Warning: all these ideas seem interesting for desktop, but are definitely
not for servers. I found RSDL to be excellent on servers, compared to
mainline in which some services are starving under load. I can understand
that on the desktop people want some unfairness, and I like the pgrp idea
for instance. But this one will certainly fail on servers, or make the
admins get grey hair very soon.

Maybe we're all discussing the problem because we have reached the point
where we need two types of schedulers : one for the desktop and one for
the servers. After all, this is already what is proposed with preempt,
it would make sense provided they share the same core and avoid ifdefs
or unused structure members. Maybe adding OPTIONAL unfairness to RSDL
would help some scenarios, but in any case it is important to retain
the default fairness it provides.

> Dunno. I guess a lot of people would like to then manage the classes, 
> which would be painful as hell. 

Sure ! I wouldn't like people to point the finger on Linux saying "hey
look, they can't write a good scheduler so you have to adjust the knobs
yourself!". I keep in mind that Solaris' scheduler is very good, both
fair and interactive. FreeBSD was good (I haven't tested for a long time).
We should manage to get something good for most usages, and optimize
later for specific uses.

Regards,
Willy

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

Re: [kvm-devel] [PATCH 0/15] KVM userspace interface updates

[Avi Kivity]

Heiko Carstens wrote:

On Sun, Mar 11, 2007 at 03:53:12PM +0200, Avi Kivity wrote:
  

This patchset updates the kvm userspace interface to what I hope will
be the long-term stable interface.  Provisions are included for extending
the interface later.  The patches address performance and cleanliness
concerns.



Searching the mailing list I figured that as soons as the interface seems
to be stable, kvm should/would switch to a system call based interface.
I assume the userspace interface might still change a lot, especially if
kvm is ported to new architectures.
But the general question is: do you still plan to switch to a syscall
interface?
  


I don't have any present plans for that.  Maybe when the interface 
starts to evolve at a slower pace, or if it is shown to be significantly 
faster.


Not that interface stabilization here doesn't mean a freeze; it means 
that backwards compatibility starts when this gets merged.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 21-rc4] misc doc and kconfig typos

[Randy Dunlap]

On Sat, 17 Mar 2007 14:44:51 -0400 Matt LaPlante wrote:

> Fix various typos in kernel docs and Kconfigs, 2.6.21-rc4.
> 
> Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]>

Acked-by: Randy Dunlap <[EMAIL PROTECTED]>

Thanks, Matt.

BTW, I would prefer to see doc and kconfig patches in separate
files.  Anyone else pro or con on that?

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: is RSDL an "unfair" scheduler too?

[Avi Kivity]

William Lee Irwin III wrote:

On Sat, Mar 17, 2007 at 10:41:01PM +0200, Avi Kivity wrote:
  
Well, the heuristic here is that process == job.  I'm not sure heuristic 
is the right name for it, but it does point out a deficieny.
A cpu-bound process with many threads will overwhelm a cpu-bound single 
threaded threaded process.

A job with many processes will overwhelm a job with a single process.
A user with many jobs can starve a user with a single job.
I don't think the problem here is heuristics, rather that the 
scheduler's manages cpu quotas at the task level rather than at the user 
visible level.  If scheduling were managed at all three hierarchies I 
mentioned ('job' is a bit artificial, but process and user are not) then:
- if N users are contending for the cpu on a multiuser machine, each 
should get just 1/N of available cpu power.  As it is, a user can run a 
few of your #1 workloads (or a make -j 20) and slow every other user down
- your example would work perfectly (if we can communicate to the kernel 
what a job is)

- multi-threaded processes would not get an unfair advantage



I like this notion very much. I should probably mention pgrp's' typical
association with the notion of "job," at least as far as shells go.

  


One day I might understand what pgrp, sessions, and all that stuff is.


One issue this raises is prioritizing users on a system, threads within
processes, jobs within users, etc. Maybe sessions would make sense, too,
and classes of users, and maybe whatever they call the affairs that pid
namespaces are a part of (someone will doubtless choke on the hierarchy
depth implied here but it doesn't bother me in the least). It's not a
deep or difficult issue. There just needs to be some user API to set the
relative scheduling priorities of all these affairs within the next higher
level of hierarchy, regardless of how many levels of hierarchy (aleph_0?).
  


I think it follows naturally.

Note that more than the scheduler needs to be taught about this.  The 
page cache and swapper should prevent a user from swapping out too many 
of another user's pages when there is contention for memory; there 
should be per-user quotas for network and disk bandwidth, etc.  Until 
then people who want true multiuser with untrusted users will be forced 
to use ugly hacks like virtualization.  Fortunately it seems the 
container people are addressing at least a part of this.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

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

Re: more precise CPU time accounting for x86

[Stephen Rothwell]

Hi Tomasz,

On Sat, 17 Mar 2007 16:47:22 +0100 Tomasz Noiński <[EMAIL PROTECTED]> wrote:
>
> I've written a small patch for more precise process CPU time accounting
> for processors with TSC.

You should have a look at the CONFIG_VIRT_CPU_ACCOUNTING on s390 and
powerpc.

--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpOPe0lDCKq1.pgp
Description: PGP signature

Re: [patch 2/13] signal/timer/event fds v6 - signalfd core ...

[Stephen Rothwell]

On Sat, 17 Mar 2007 22:35:08 +0100 Arnd Bergmann <[EMAIL PROTECTED]> wrote:
>
> sizeof(sigset_t) may be different for native and 32-bit compat code.
> It would be good if you could handle sizemask==4 && sizeof(sigset_t)==8
> in this code, so that there is no need for an extra compat_sys_signalfd
> function.

We still need a compat function to get the bit layout and the wordlayout
correct in the sigset.

--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpG55iZjZ636.pgp
Description: PGP signature

Re: [git patches] libata fixes

[Tejun Heo]

Paul Rolland wrote:
> Hello,
> 
>> The kernel says that NCQ is turned off due to excessive 
>> errors.  If your
>> HSM violation is intermittent, it might not trigger tho.
> 
> I've just grep'ed thru all my messages, and I can't find anything 
> stating that NCQ is being turned off...

Can you put the harddisk under high load and see what happens?  How
often do those errors occur?  Care to post full dmesg?

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

Re: CONFIG_REORDER Kconfig help strange sentence.

[Randy Dunlap]

On Sat, 17 Mar 2007 19:54:30 +1100 Rusty Russell wrote:

> On Thu, 2007-03-15 at 18:34 -0700, Randy Dunlap wrote:
> > On Tue, 13 Mar 2007 17:37:35 +1100 Rusty Russell wrote:
> > > diff -r de5618b5e562 arch/x86_64/Kconfig
> > > --- a/arch/x86_64/Kconfig Tue Mar 13 11:41:55 2007 +1100
> > > +++ b/arch/x86_64/Kconfig Tue Mar 13 17:27:05 2007 +1100
> > > @@ -632,8 +632,8 @@ config REORDER
> > >   default n
> > >   help
> > >   This option enables the toolchain to reorder functions for a 
> > > more 
> > > - optimal TLB usage. If you have pretty much any version of 
> > > binutils, 
> > > -  this can increase your kernel build time by roughly one minute.
> > > + optimal TLB usage.  This will slow your kernel build by
> > > +  roughly one minute.
> > 
> > Please consistently use  for help text.
> > Yes, it was already mucked up.
> 
> Erm, OK, this applies after previous patch if it's wanted.
> 
> After Randy spotted an errant TAB, this is a cleanup of
> arch/x86_64/Kconfig.
> 
> 1) clean up all the trailing whitespace,
> 2) make sure we use tabs instead of spaces,
> 3) ensure all help messages use tab & two spaces,
> 4) make sure all help messages are < 80 cols.
> 
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>

Acked-by: Randy Dunlap <[EMAIL PROTECTED]>

Thanks for doing this, Rusty.

> diff -r af971625bda6 arch/x86_64/Kconfig
> --- a/arch/x86_64/Kconfig Sat Mar 17 19:50:28 2007 +1100
> +++ b/arch/x86_64/Kconfig Sat Mar 17 19:51:01 2007 +1100
> @@ -138,10 +138,10 @@ config X86_VSMP
>  config X86_VSMP
>   bool "Support for ScaleMP vSMP"
>   depends on PCI
> -  help
> + help
> Support for ScaleMP vSMP systems.  Say 'Y' here if this kernel is
> -   supposed to run on these EM64T-based machines.  Only choose this 
> option
> -   if you have one of these machines.
> +   supposed to run on these EM64T-based machines.  Only choose this
> +   option if you have one of these machines.
>  
>  endchoice
>  
> @@ -155,13 +155,13 @@ config MK8
> Optimize for AMD Opteron/Athlon64/Hammer/K8 CPUs.
>  
>  config MPSC
> -   bool "Intel P4 / older Netburst based Xeon"
> -   help
> + bool "Intel P4 / older Netburst based Xeon"
> + help
> Optimize for Intel Pentium 4 and older Nocona/Dempsey Xeon CPUs
> with Intel Extended Memory 64 Technology(EM64T). For details see
> .
> Note that the latest Xeons (Xeon 51xx and 53xx) are not based on the
> -  Netburst core and shouldn't use this option. You can distinguish 
> them
> +   Netburst core and shouldn't use this option. You can distinguish them
> using the cpu family field
> in /proc/cpuinfo. Family 15 is an older Xeon, Family 6 a newer one
> (this rule only applies to systems that support EM64T)
> @@ -333,26 +333,26 @@ source "kernel/Kconfig.preempt"
>  source "kernel/Kconfig.preempt"
>  
>  config NUMA
> -   bool "Non Uniform Memory Access (NUMA) Support"
> -   depends on SMP
> -   help
> -  Enable NUMA (Non Uniform Memory Access) support. The kernel 
> -  will try to allocate memory used by a CPU on the local memory 
> -  controller of the CPU and add some more NUMA awareness to the kernel.
> -  This code is recommended on all multiprocessor Opteron systems.
> -  If the system is EM64T, you should say N unless your system is EM64T 
> -  NUMA. 
> + bool "Non Uniform Memory Access (NUMA) Support"
> + depends on SMP
> + help
> +   Enable NUMA (Non Uniform Memory Access) support. The kernel
> +   will try to allocate memory used by a CPU on the local memory
> +   controller of the CPU and add some more NUMA awareness to the kernel.
> +   This code is recommended on all multiprocessor Opteron systems.
> +   If the system is EM64T, you should say N unless your system is EM64T
> +   NUMA.
>  
>  config K8_NUMA
> -   bool "Old style AMD Opteron NUMA detection"
> -   depends on NUMA && PCI
> -   default y
> -   help
> -  Enable K8 NUMA node topology detection.  You should say Y here if
> -  you have a multi processor AMD K8 system. This uses an old
> -  method to read the NUMA configuration directly from the builtin
> -  Northbridge of Opteron. It is recommended to use X86_64_ACPI_NUMA
> -  instead, which also takes priority if both are compiled in.   
> + bool "Old style AMD Opteron NUMA detection"
> + depends on NUMA && PCI
> + default y
> + help
> +   Enable K8 NUMA node topology detection.  You should say Y here if
> +   you have a multi processor AMD K8 system. This uses an old
> +   method to read the NUMA configuration directly from the builtin
> +   Northbridge of Opteron. It is recommended to use X86_64_ACPI_NUMA
> +   instead, which also takes priority if both are compiled in.
>  
>  config NODES_SHIFT
>   int
> @@ 

Re: Pluggable Schedulers (was: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler)

[Bill Davidsen]

David Lang wrote:

On Fri, 9 Mar 2007, Al Boldi wrote:




My preferred sphere of operation is the Manichean domain of faster vs.
slower, functionality vs. non-functionality, and the like. For me, such
design concerns are like the need for a kernel to format pagetables so
the x86 MMU decodes what was intended, or for a compiler to emit valid
assembly instructions, or for a programmer to write C the compiler
won't reject with parse errors.


Sure, but I think, even from a technical point of view, competition is 
a good
thing to have.  Pluggable schedulers give us this kind of competition, 
that

forces each scheduler to refine or become obsolete.  Think evolution.


The point Linus is makeing is that with pluggable schedulers there isn't 
competition between them, the various developer teams would go off in 
their own direction and any drawbacks to their scheduler could be 
answered with "that's not what we are good at, use a different 
scheduler", with the very real possibility that a person could get this 
answer from ALL schedulers, leaving them with nothing good to use.


Have you noticed that currently that is exactly what happens? If the 
default scheduler doesn't handle your load well you have the option of 
rewriting it and maintaining it, or doing without, or tying to fix your 
case without breaking others, or patching in some other, non-mainline, 
scheduler.


The default scheduler has been around long enough that I don't see it 
being tuned for any A without making some B perform worse. Thus multiple 
schedulers are a possible solution.


They don't need to be available as runtime choices, boot time selection 
would still allow reasonable testing. I can see myself using a compile 
time option and building multiple kernels, but not the average user.


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: is RSDL an "unfair" scheduler too?

[Kasper Sandberg]

On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote:
> Con Kolivas wrote:

> 
> Now for something constructive... by any chance is Mike running KDE 
> instead of GNOME? I only had a short time to play because I had to look 
> at another problem in 2.6.21-rc3 (nbd not working), so the test machine 
> is in use. But it looked as if behavior was not as smooth with KDE. May 
> that thought be useful.

Now i must say here, i use KDE, and have been testing 0.31, and i have
been observing all the effects, in contrast with vanilla and staircase.
this is on 2.6.20

I do not notice kde being slower, in fact i notice various interactivity
"speedups" compared to mainline.

first one i noticed(because i deliberately tested) was kicker. Kickers
hide function was very very smooth during boot, and still is under load.
It is not entirely as smooth under vanilla during boot(i suspect IO
issue), under staircase it is, however under huge loads, it even is not
smooth under staircase.

then i started my konsole, and the one thing i immediately noticed was
that zsh started instantly, usually i can see/(feel) zsh starting, as in
it takes like 0.2 before my prompt comes. This is simply gone now with
rsdl, behavior used to be the same in vanilla/rsdl.

But the most interresting, and dare i say, completely unexpected things
are much more important.

I have for a long time had issues with tvtime, if i did stuff like move
windows, tvtime would drop frames, or simply hovering javascript stuff
on sites in konqueror, (this seemed to be introduced in 2.6.~5+), cause
in EARLY 2.6 i did not have this problem, but it was the same in
staircase and vanilla. But this is gone completely, tvtime no longer
drops any frames when doing this.

Another thing i noticed, which almost blew my mind as badly as with
tvtime, was with wine, and world of warcraft(and nvidia blob driver, but
this IS what many "desktop" users runs). While loading a level, the
sound no longer skipped. This problem afaik, EVERYBODY which runs wine
+wow has(unless they change the buffer size to ridicoulesly high which
annoys gameplay).

And more playing wow has shown me that rsdl seems to be doing an
extremely good job of not letting other tasks interfere. For example i
have spamasassin going quite very often (every minute, for lots of
accounts), and this usually kills all sorts of high performance opengl
stuff, causing severe stuttering, but with RSDL i only noticed my
framerate dropping, but no strange stuttering as i usually experience,
only lowered fps, which to me is quite natural, as spamasassin now has
to use cpu.

the last of my immediate observations are ktorrent. my ktorrent has LOTS
of open fd's (in fact like ~5-6k), and the application tends to be very
sluggish, but that is not so anymore.


And now for the side effects i have observed.

The only down right "regression" (which i wouldnt even call it, cause
its a NATURAL thing when other stuff uses cpu) is that when i play a
movie in kaffeine, and move the kaffeine window insanely fast all over
the desktop, the audio skipped once, the strange thing is, even if i
keep moving it, it does not skip any more, only the one time when you
start to move it. But 720p h264 does take SOME cpu to decode, so i dont
feel that this is unfair.

i have however with X observed that under high load(720p h264 video
playback, while doing video encoding, ktorrent running, and make
running) that windows take longer time to redraw in X, if i move windows
over each other, but not really a problem.

another effect i have observed is that stuff does not stutter as much
when under load, it simply gets slower.(but i suppose thats what i said
when describing the good effects i have noticed)

it should be noted that i have not reniced a single thing, and this is a
singlecore amd64 2ghz with 1.5gb ram.



> 

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

Re: is RSDL an "unfair" scheduler too?

[Bill Davidsen]

Ingo Molnar wrote:


* Con Kolivas <[EMAIL PROTECTED]> wrote:


Ok but please look at how it appears from my end (illness aside).


( i really think we should continue this debate after you get better. 
  Everything looks much darker when you are ill! )



You initially said you were pleased with this design.


I said that 2 years ago about the staircase scheduler and i am still 
saying this about RSDL today. That doesnt make my position automatically 
correct though :-) For example i wrote and maintained the 4g:4g patchset 
for over 2 years and still that was no guarantee of it making sense 
upstream ;) And it was a hell of a lot of work (much uglier and nastier 
work than any scheduler hacking and tuning, believe me), and it was 
thrown away as a cute but unnecessary complication we dont need. So 
what? To me what matters is the path you walk, not the destination you 
reach.


in terms of RSDL design, i like it, still i'm kind of asking myself 
'couldnt something in this direction be done in a much simpler and less 
revolutionary way'? For example couldnt we introduce per-priority level 
timeslice quotas in the current scheme as well, instead of the very 
simplistic and crude STARVATION_LIMIT approach? Furthermore, couldnt we 
make the timeslices become smaller as the runqueue length increases, to 
make starvation less of a problem? It seems like the problem cases with 
the current scheduler arent so much centered around the interactivity 
estimator, it is more that timeslices get distributed too coarsely, 
while RSDL distributes timeslices in a more finegrained way and is thus 
less suspect to starvation under certain workloads.


Yes. The "doorknob scheduler" was a scheduler which worked as follows: 
the runnable processes in the system were put in a priority sorted list 
and counted. Then the length of one cycle (turn) was divided by the 
number of processes and that was the timeslice. In the next version 
upper and lower limits were put on the length of a timeslice, so the 
system didn't get eaten by context switches under load or be jerky under 
light load. That worked fairly well.


Then people got into creating unfairness to address what they thought 
were corner cases, the code turned into a plumber's nightmare, and 
occasional jackpot cases created occasional (non-reproducible) hangs.


Finally management noted that the peripherals cost three times as much 
as the CPU, so jobs doing i/o should run first. That made batch run like 
the clappers of hell, and actually didn't do all the bad things you 
might expect. User input was waitio, disk was waitio, response was about 
as good as it could be for that hardware.


===> it might be useful to give high priority to a process going from 
waitio to runable state, once only.


The "doorknob" term came from "everybody gets a turn" and the year was 1970.

Avi Kivity wrote:

Well, the heuristic here is that process == job. I'm not sure
heuristic is the right name for it, but it does point out a
deficieny.

>

A cpu-bound process with many threads will overwhelm a cpu-bound
single threaded threaded process.

>
> A job with many processes will overwhelm a job with a single process.
>
> A user with many jobs can starve a user with a single job.
>
I don't think the problem here is heuristics, rather that the 
scheduler's manages cpu quotas at the task level rather than at the

user visible level. If scheduling were managed at all three
hierarchies I mentioned ('job' is a bit artificial, but process and
user are not) then:

>
- if N users are contending for the cpu on a multiuser machine, each 
should get just 1/N of available cpu power. As it is, a user can run

a few of your #1 workloads (or a make -j 20) and slow every other
user down - your example would work perfectly (if we can communicate
to the kernel what a job is)

>
> - multi-threaded processes would not get an unfair advantage

If we wanted to do this, a job would be defined as all children or 
threads of the oldest parent process with a PPID of one. So if I logged 
on  and did

  make -j4
on a kernel, and someone else did:
  find /var -type f | xargs grep -l zumblegarfe
and someone else was doing:
  foo & mumble & barfe

We would all be equal. That's good! And there would be some recursive 
scheduler which would pick a "job" and then a process, and run it. That 
too is good!


But we have a mail server, and there are 671 threads with a socket and 
POP3 user on each one, and they only get 1/N of a job worth of CPU 
between them, and that sucks rocks off the bottom of the ocean. So 
pretty soon the code gets some "fixes" to make POP3 work, and X work, 
and the code once again becomes plumber's nightmare... Then you start 
playing with process groups to address some of this, and address exec() 
corner cases, and complexity goes way up again. This is NOT an easy problem!


I think Con has done a good job, I think in most cases (heresy) the 
current mainline scheduler does a pretty good job. I'm in 

Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)

[Nick Piggin]

On Sat, Mar 17, 2007 at 01:17:00PM +0100, Blaisorblade wrote:
> On Tuesday 13 March 2007 02:19, Nick Piggin wrote:
> > On Tue, Mar 13, 2007 at 12:01:13AM +0100, Blaisorblade wrote:
> > > On Wednesday 07 March 2007 11:02, Nick Piggin wrote:
> > > > > Yeah, tmpfs/shm segs are what I was thinking about. If UML can live
> > > > > with that as well, then I think it might be a good option.
> > > >
> > > > Oh, hmm if you can truncate these things then you still need to
> > > > force unmap so you still need i_mmap_nonlinear.
> > >
> > > Well, we don't need truncate(), but MADV_REMOVE for memory hotunplug,
> > > which is way similar I guess.
> > >
> > > About the restriction to tmpfs, I have just discovered
> > > '[PATCH] mm: tracking shared dirty pages' (commit
> > > d08b3851da41d0ee60851f2c75b118e1f7a5fc89), which already partially
> > > conflicts with remap_file_pages for file-based mmaps (and that's fully
> > > fine, for now).
> > >
> > > Even if UML does not need it, till now if there is a VMA protection and a
> > > page hasn't been remapped with remap_file_pages, the VMA protection is
> > > used (just because it makes sense).
> > >
> > > However, it is only used when the PTE is first created - we can never
> > > change protections on a VMA  - so it vma_wants_writenotify() is true (on
> > > all file-based and on no shmfs based mapping, right?), and we
> > > write-protect the VMA, it will always be write-protected.
> >
> > Yes, I believe that is the case, however I wonder if that is going to be
> > a problem for you to distinguish between write faults for clean writable
> > ptes, and write faults for readonly ptes?
> I wouldn't be able to distinguish them, but am I going to get write faults 
> for 
> clean ptes when vma_wants_writenotify() is false (as seems to be for tmpfs)? 
> I guess not.
> 
> For tmpfs pages, clean writable PTEs are mapped as writable so they won't 
> give 
> any problem, since vma_wants_writenotify() is false for tmpfs. Correct?

Yes, that should be the case. So would this mean that nonlinear protections
don't work on regular files? I guess that's OK if Oracle and UML both use
tmpfs/shm?

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

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

[Alan Stern]

On Sat, 17 Mar 2007, Jiri Slaby wrote:

> Alan Stern napsal(a):
> > On Tue, 13 Mar 2007, Jiri Slaby wrote:
> > 
> >> So, do you mean rmmod uhci_hcd, unplug the keyboard, modprobe
> >> uhci_hcd, start usbmon, plug the keyboard, press numlock, stop usbmon,
> >> post it?
> 
> Here you are:

...

> (Remind: there is a hub inside the keyboard)

Yes.  It shows up very clearly in the log.

> >  static void uhci_free_td(struct uhci_hcd *uhci, struct uhci_td *td)
> >  {
> > -   if (!list_empty(>list))
> > +   if (!list_empty(>list)) {
> > dev_warn(uhci_dev(uhci), "td %p still in list!\n", td);
> > +   WARN_ON(1);
> 
> Nothing new in dmesg.

Oh well, I didn't really expect there to be.

Nothing in the log stands out.  Can you collect an equivalent log using a
version of uhci-hcd with the "eliminate skeleton QHs" patch reverted?  
Perhaps there will be a significant difference.  Although I doubt it...

I'm running out of ideas.  I tried doing exactly the same thing with a USB
keyboard+hub on my system, and it worked perfectly.  This suggests that
you might be seeing some weird hardware flaw that is somehow exposed by
the patch.

Can you borrow a different USB keyboard and see if it behaves the same 
way?  Or can you try using your keyboard on a different computer (one with 
UHCI)?

Alan Stern

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

Re: is RSDL an "unfair" scheduler too?

[Bill Davidsen]

Con Kolivas wrote:

On Saturday 17 March 2007 23:28, Ingo Molnar wrote:

* Con Kolivas <[EMAIL PROTECTED]> wrote:

We're obviously disagreeing on what heuristics are [...]

that could very well be so - it would be helpful if you could provide
your own rough definition for the term, so that we can agree on how to
call things?

[ in any case, there's no rush here, please reply at your own pace, as
  your condition allows. I wish you a speedy recovery! ]


You're simply cashing in on the deep pipes that do kernel work for
other tasks. You know very well that I dropped the TASK_NONINTERACTIVE
flag from rsdl which checks that tasks are waiting on pipes and you're
exploiting it.

Con, i am not 'cashing in' on anything and i'm not 'exploiting'
anything. The TASK_NONINTERACTIVE flag is totally irrelevant to my
argument because i was not testing the vanilla scheduler, i was testing
RSDL. I could have written this test using plain sockets, because i was
testing RSDL's claim of not having heuristics, i was not testing the
vanilla scheduler.

I have simply replied to this claim of yours:

Despite the claims to the contrary, RSDL does not have _less_
heuristics, it does not have _any_. [...]

and i showed you a workload under _RSDL_ that clearly shows that RSDL is
an unfair scheduler too.

my whole point was to counter the myth of 'RSDL has no heuristics'. Of
course it has heuristics, which results in unfairness. (If it didnt have
any heuristics that tilt the balance of scheduling towards sleep-intense
tasks then a default Linux desktop would not be usable at all.)

so the decision is _not_ a puristic "do we want to have heuristics or
not", the question is a more practical "which heuristics are simpler,
which heuristics are more flexible, which heuristics result in better
behavior".

Ingo


Ok but please look at how it appears from my end (illness aside).

I spend 3 years just diddling with scheduler code trying my hardest to find a 
design that fixes a whole swag of problems we still have, and a swag of 
problems we might get with other fixes.


You initially said you were pleased with this design.

..lots of code, testing, bugfixes and good feedback.

Then Mike has one testcase that most other users disagree is worthy of being 
considered a regresssion. You latched onto that and basically called it a 
showstopper in spite of who knows how many other positive things.


Then you quickly produce a counter patch designed to kill off RSDL with a 
config option for mainline.


Then you boldly announce on LKML "is RSDL an "unfair" scheduler too?" with 
some test case you whipped up to try and find fault with the design.


No damn it! He's pointing out that you do have heuristics, they are just 
built into the design. And of course he's whipping up test cases, how 
else can anyone help you find corner cases where it behaves in an 
unexpected or undesirable manner?


I think he's trying to help, please stop taking it personally.


What am I supposed to think? Considering just how many problems I have 
addressed and tried to correct with RSDL succesfully I'm surprised that 
despite your enthusiasm for it initially you have spent the rest of the time 
trying to block it.


Please, either help me (and I'm in no shape to code at the moment despite what 
I have done so far), or say you have no intention of including it. I'm 
risking paralysis just by sitting at the computer right now so I'm dropping 
the code as is at the moment and will leave it up to your better judgement as 
to what to do with it.


Actually I think Ingo has tried to help get it in, that's his patch 
offered for CONFIG_SCHED_FAIR, lets people try it and all.


Now for something constructive... by any chance is Mike running KDE 
instead of GNOME? I only had a short time to play because I had to look 
at another problem in 2.6.21-rc3 (nbd not working), so the test machine 
is in use. But it looked as if behavior was not as smooth with KDE. May 
that thought be useful.


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] drivers/char/agp: Convert to generic boolean

[Richard Knutsson]

Please use "Reply All"

Joe Perches wrote:

On Sun, 2007-03-18 at 00:45 +0100, Richard Knutsson wrote:
  

diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp/amd-k7-agp.c
index e6c534e..3d57e9f 100644
--- a/drivers/char/agp/amd-k7-agp.c
+++ b/drivers/char/agp/amd-k7-agp.c
@@ -308,9 +308,9 @@ static int amd_insert_memory(struct agp_memory *mem, off_t 
pg_start, int type)
j++;
}
 
-	if (mem->is_flushed == FALSE) {

+   if (!mem->is_flushed) {
global_cache_flush();
-   mem->is_flushed = TRUE;
+   mem->is_flushed = true;
}



perhaps a generic.c / agp.h function?
  

Sound like a good idea (not in a boolean cleanup-patch thou)
Would you mind making that patch?

Richard Knutsson

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

Re: is RSDL an "unfair" scheduler too?

[Linus Torvalds]

On Sat, 17 Mar 2007, William Lee Irwin III wrote:
> 
> One issue this raises is prioritizing users on a system, threads within
> processes, jobs within users, etc.

Doing some "classing" even by just euid might be a good idea. It would 
actually catch X automatically most of the time, because the euid of the X 
server is likely to be root, so even for the "trivial" desktop example, it 
would kind of automatically mean that X would get about 50% of CPU time 
even if you have a hundred user clients, just because that's "fair" by 
euid.

Dunno. I guess a lot of people would like to then manage the classes, 
which would be painful as hell. 

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: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler

[Bill Davidsen]

Con Kolivas wrote:

On Monday 12 March 2007 22:26, Al Boldi wrote:

Con Kolivas wrote:

On Monday 12 March 2007 15:42, Al Boldi wrote:

Con Kolivas wrote:

On Monday 12 March 2007 08:52, Con Kolivas wrote:

And thank you! I think I know what's going on now. I think each
rotation is followed by another rotation before the higher priority
task is getting a look in in schedule() to even get quota and add
it to the runqueue quota. I'll try a simple change to see if that
helps. Patch coming up shortly.

Can you try the following patch and see if it helps. There's also one
minor preemption logic fix in there that I'm planning on including.
Thanks!

Applied on top of v0.28 mainline, and there is no difference.

What's it look like on your machine?

The higher priority one always get 6-7ms whereas the lower priority one
runs 6-7ms and then one larger perfectly bound expiration amount.
Basically exactly as I'd expect. The higher priority task gets precisely
RR_INTERVAL maximum latency whereas the lower priority task gets
RR_INTERVAL min and full expiration (according to the virtual deadline)
as a maximum. That's exactly how I intend it to work. Yes I realise that
the max latency ends up being longer intermittently on the niced task but
that's -in my opinion- perfectly fine as a compromise to ensure the nice
0 one always gets low latency.

I think, it should be possible to spread this max expiration latency across
the rotation, should it not?


There is a way that I toyed with of creating maps of slots to use for each 
different priority, but it broke the O(1) nature of the virtual deadline 
management. Minimising algorithmic complexity seemed more important to 
maintain than getting slightly better latency spreads for niced tasks. It 
also appeared to be less cache friendly in design. I could certainly try and 
implement it but how much importance are we to place on latency of niced 
tasks? Are you aware of any usage scenario where latency sensitive tasks are 
ever significantly niced in the real world?


It depends on how you reconcile "completely fair" and "order of 
magnitude blips in latency." It looks (from the results, not the code) 
as if nice is implemented by round-robin scheduling followed by once in 
a while just not giving the CPU to the nice task for a while. Given the 
smooth nature of the performance otherwise, it's more obvious than if 
you weren't doing such a good job most of the time.


Ugly stands out more on something beautiful!

--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: is RSDL an "unfair" scheduler too?

[William Lee Irwin III]

On Sat, Mar 17, 2007 at 10:41:01PM +0200, Avi Kivity wrote:
> Well, the heuristic here is that process == job.  I'm not sure heuristic 
> is the right name for it, but it does point out a deficieny.
> A cpu-bound process with many threads will overwhelm a cpu-bound single 
> threaded threaded process.
> A job with many processes will overwhelm a job with a single process.
> A user with many jobs can starve a user with a single job.
> I don't think the problem here is heuristics, rather that the 
> scheduler's manages cpu quotas at the task level rather than at the user 
> visible level.  If scheduling were managed at all three hierarchies I 
> mentioned ('job' is a bit artificial, but process and user are not) then:
> - if N users are contending for the cpu on a multiuser machine, each 
> should get just 1/N of available cpu power.  As it is, a user can run a 
> few of your #1 workloads (or a make -j 20) and slow every other user down
> - your example would work perfectly (if we can communicate to the kernel 
> what a job is)
> - multi-threaded processes would not get an unfair advantage

I like this notion very much. I should probably mention pgrp's' typical
association with the notion of "job," at least as far as shells go.

One issue this raises is prioritizing users on a system, threads within
processes, jobs within users, etc. Maybe sessions would make sense, too,
and classes of users, and maybe whatever they call the affairs that pid
namespaces are a part of (someone will doubtless choke on the hierarchy
depth implied here but it doesn't bother me in the least). It's not a
deep or difficult issue. There just needs to be some user API to set the
relative scheduling priorities of all these affairs within the next higher
level of hierarchy, regardless of how many levels of hierarchy (aleph_0?).


-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] no boot with 2.6.21-rc3 and later

[Bob Tracy]

Platform is a Dell CPxJ 650GT notebook.  Attempts to boot 2.6.21-rc3
and -rc4 produce the following console output:

(apparently normal boot)
...
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller at PCI slot :00:07.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x0860-0x0867, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x0868-0x086f, BIOS settings: hdc:DMA, hdd:pio
(hangs here)

The next two lines of output for 2.6.21-rc2 and earlier are:
Probing IDE interface ide0...
hda: TOSHIBA MK3017GAP, ATA DISK drive

Any idea what's going on here?

-- 
---
Bob Tracy   WTO + WIPO = DMCA? http://www.anti-dmca.org
[EMAIL PROTECTED]
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND 2/2] Fix some kallsyms_lookup() vs rmmod races

[Rusty Russell]

On Fri, 2007-03-16 at 12:51 +0100, Ingo Molnar wrote:
> * Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> 
> > [cc'ing folks whose proc files are affected]
> > 
> > kallsyms_lookup() can call module_address_lookup() which iterates over 
> > modules list without module_mutex taken. Comment at the top of 
> > module_address_lookup() says it's for oops resolution so races are 
> > irrelevant, but in some cases it's reachable from regular code:
> 
> looking at the problem from another angle: wouldnt this be something 
> that would benefit from freeze_processes()/unfreeze_processes(), and 
> hence no locking would be required?

Actually, the list manipulation is done with stop_machine for this
reason. Alexey, is preempt enabled in your kernel?

Rusty.


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

Re: [patch 05/26] Xen-paravirt_ops: paravirt_ops: hooks to set up initial pagetable

[Rusty Russell]

On Fri, 2007-03-16 at 11:39 -0700, Jeremy Fitzhardinge wrote:
> Ingo Molnar wrote:
> >> +  /* Make sure kernel address space is empty so that a pagetable
> >> + will be allocated for it. */
> >> 
> >
> > comment style.
> >   
> 
> As you've noticed its a comment style I use quite often.

Me too, and Ingo and I have had this argument before.  These days I try
hard to fit simple comments in a single line 8)

Rusty.


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

Re: [PATCH RESEND 2/2] Fix some kallsyms_lookup() vs rmmod races

[Rusty Russell]

On Fri, 2007-03-16 at 12:49 -0800, Andrew Morton wrote:
> > Ok, I've just done a few tests with the attached patch. It basically 
> > creates a freeze_machine_run function that is equivalent in interface to 
> > stop_machine_run, but uses freeze_processes / thaw_processes to stop the 
> > machine.

I've never been convinced that the freezer was a good idea.
stop_machine is a damn big hammer, but it works.

Rusty.


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

Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

[Rusty Russell]

On Fri, 2007-03-16 at 13:38 -0700, Jeremy Fitzhardinge wrote:
> David Miller wrote:
> > Perhaps the problem can be dealt with using ELF relocations.
> >
> > There is another case, discussed yesterday on netdev, where run-time
> > resolution of ELF relocations would be useful (for
> > very-very-very-read-only variables) so if it can solve this problem
> > too it would be nice to have a generic infrastructure for it.
> 
> That's an interesting idea.  Have you or anyone else looked at what it
> would take to code up?
> 
> For this case, I guess you'd walk the relocs looking for references into
> the paravirt_ops structure.  You'd need to check that was a reference
> from an indirect jump or call instruction, which would identify a
> patchable callsite.  The offset into the pv_ops structure would identify
> which operation is involved.

I wrote a whole email on ways to do this, BUT...

Perhaps our patching code can already be vastly simplified to something
like:

#define pv_patch(call, args...) \
asm volatile(":"); 
call(args);
asm volatile("8889:"
 [ stuff to put 8889,  and call in fixup section ]

The patching code doesn't even need to decode between those two: it
simply looks for an indirect call insn (0xff 0xd?).  If it finds more
than one, it doesn't patch.  If it only finds one, it patches.  We'll
probably hit them all just doing that.

> What are the netdev requirements?

Reading Ben LaHaise's (very cool!) patch, it's not clear that using
reloc postprocessing is going to be clearer than open-coding it as he
has done.

Rusty.


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

Re: [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

[Rusty Russell]

On Fri, 2007-03-16 at 10:24 +0100, Ingo Molnar wrote:
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> 
> > Wrap a set of interesting paravirt_ops calls in a wrapper which makes 
> > the callsites available for patching.  Unfortunately this is pretty 
> > ugly because there's no way to get gcc to generate a function call, 
> > but also wrap just the callsite itself with the necessary labels.
> > 
> > This patch supports functions with 0-4 arguments, and either void or 
> > returning a value.  64-bit arguments must be split into a pair of 
> > 32-bit arguments (lower word first).  Small structures are returned in 
> > registers.
> 
> ugh. This is beyond ugly! Why dont we just compile two images, one for 
> Xen and one for native, do two passes to get those two images and 
> 'merge' them into a single vmlinuz (so that we still have a 'single' 
> kernel unit to deal with on the distro side). This way we avoid all this 
> crazy, limited, fragile patchery business...

But with lguest, VMI and kvm I don't think that's a good idea.

For background: the current patching code is ugly too, but it only deals
with the 6 most common functions, so it's contained.  This gets us
pretty close to !CONFIG_PARAVIRT performance.  (But slowdown is still
measurable).

We get worse with Xen wanting to alter mkpte et al.  By the time we
patch another 6 functions (each one slightly different), we get pretty
close to general coverage anyway, so it's clearer to do them all.

I think the question is, can we do it better than this?  My previous
attempts (which lead to the current code) ranged from ugly to very ugly
8(

Rusty.

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

Re: [PATCH RESEND 2/2] Fix some kallsyms_lookup() vs rmmod races

[Rusty Russell]

On Fri, 2007-03-16 at 14:44 +0300, Alexey Dobriyan wrote:
> [cc'ing folks whose proc files are affected]
> 
> kallsyms_lookup() can call module_address_lookup() which iterates over
> modules list without module_mutex taken. Comment at the top of
> module_address_lookup() says it's for oops resolution so races are
> irrelevant, but in some cases it's reachable from regular code:

Yes, this changed somewhere along the way. 

I prefer keeping the lock internal as much as possible, and have the
crash code use an __ variant of the function.

Note also that it might be an idea to have less-powerful accessors than
kallsyms_lookup...

Thanks!
Rusty.


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

Re: [Xen-devel] Re: [patch 20/26] Xen-paravirt_ops: Core Xen implementation

[Rusty Russell]

On Fri, 2007-03-16 at 10:14 +0100, Ingo Molnar wrote:
> > +unsigned long xen_pmd_val(pmd_t pmd)
> > +{
> > +   BUG();
> > +   return 0;
> > +}
> 
> make it noret.

OK, I missed this one.  How?

Wondering if I've missed a trick here...
Rusty.


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

Re: [patch 14/26] Xen-paravirt_ops: add common patching machinery

[Rusty Russell]

On Fri, 2007-03-16 at 10:20 +0100, Ingo Molnar wrote:
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> 
> > Implement the actual patching machinery.  paravirt_patch_default() 
> > contains the logic to automatically patch a callsite based on a few 
> > simple rules:
> > 
> >  - if the paravirt_op function is paravirt_nop, then patch nops
> >  - if the paravirt_op function is a jmp target, then jmp to it
> >  - if the paravirt_op function is callable and doesn't clobber too much
> > for the callsite, call it directly
> > 
> > paravirt_patch_default is suitable as a default implementation of 
> > paravirt_ops.patch, will remove most of the expensive indirect calls 
> > in favour of either a direct call or a pile of nops.
> 
> Acked-by: Ingo Molnar <[EMAIL PROTECTED]>

I like this one too, but note that it needs a twist when we change to
use direct calls to wrappers for the Great paravirt_ops Unexporting.

Rusty.


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

appletouch quirk doesn't run at resume

[Adrian Bunk]

On Sat, Mar 17, 2007 at 11:07:38AM +0100, Thomas Meyer wrote:
> Thomas Gleixner schrieb:
> > I finally found a dual core box, which survives suspend/resume without
> > crashing in the middle of nowhere. Sigh, I never figured out from the
> > code and the bug reports what's going on.
> >
> > The observed hangs are caused by a stale state transition of the clock
> > event devices, which keeps the RCU synchronization away from completion,
> > when the non boot CPU is brought back up.
> >
> > The suspend/resume in oneshot mode needs the similar care as the
> > periodic mode during suspend to RAM. My assumption that the state
> > transitions during the different shutdown/bringups of s2disk would go
> > through the periodic boot phase and then switch over to highres resp.
> > nohz mode were simply wrong.
> >
> > Add the appropriate suspend / resume handling for the non periodic
> > modes.
> >
> > Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
> >   
> 
> Excellent work. Now suspend to disk is working again. But:
> 
> 1.) The quirk added in commit a417a21e10831bca695b4ba9c74f4ddf5a95ac06
> for the appletouch driver doesn't seem to work after resume.
>...

Not a regression, but still a bug.
Appropriate people added to the Cc.

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: [git patches] IDE fixes

[Bartlomiej Zolnierkiewicz]

On Sunday 18 March 2007, Linus Torvalds wrote:
> 
> On Sat, 17 Mar 2007, Bartlomiej Zolnierkiewicz wrote:
> > 
> > to receive the following updates:
> > 
> >  b/drivers/ide/Kconfig   |   48 -
> >  b/drivers/ide/Makefile  |1 
> >  b/drivers/ide/arm/icside.c  |   13 
> >  b/drivers/ide/ide-dma.c |2 
> >  b/drivers/ide/ide.c |4 
> >  b/drivers/ide/mips/au1xxx-ide.c |3 
> >  b/drivers/ide/pci/Makefile  |1 
> >  b/drivers/ide/pci/cmd64x.c  |   45 -
> >  b/drivers/ide/pci/jmicron.c |   29 
> >  b/drivers/ide/pci/scc_pata.c|  858 
> > 
> >  b/drivers/ide/setup-pci.c   |5 
> >  b/include/asm-mips/mach-au1x00/au1xxx_ide.h |   34 -
> >  drivers/ide/ppc/scc_pata.c  |  858 
> > 
> >  13 files changed, 915 insertions(+), 986 deletions(-)
> 
> Please use
> 
>   git diff -M --stat --summary 
> 
> to generate the diffstat (where the "-M" is the important part). Your 
> "scc_pata.c" change was a pure rename, but because you didn't ask for 
> rename detection, it got shown as a file create/delete pair. It *should* 
> have looked like this:
> 
>  drivers/ide/Kconfig   |   48 
> +
>  drivers/ide/Makefile  |1 -
>  drivers/ide/arm/icside.c  |   13 +---
>  drivers/ide/ide-dma.c |2 +-
>  drivers/ide/ide.c |4 --
>  drivers/ide/mips/au1xxx-ide.c |3 +-
>  drivers/ide/pci/Makefile  |1 +
>  drivers/ide/pci/cmd64x.c  |   45 ---
>  drivers/ide/pci/jmicron.c |   29 ++---
>  drivers/ide/{ppc => pci}/scc_pata.c   |0
>  drivers/ide/setup-pci.c   |5 ---
>  include/asm-mips/mach-au1x00/au1xxx_ide.h |   34 
>  12 files changed, 57 insertions(+), 128 deletions(-)
>  rename drivers/ide/{ppc => pci}/scc_pata.c (100%)
> 
> which is a lot more accurate than what you get by feeding a diff through 
> "diffstat" that has no clue about renames (look at the summary for number 
> of lines changed ;)

Thanks, I updated my scripts and also a git version installed while at it.

[ I was feeling that I was missing something but these options were
  undocumented in git-1.4.4.2, no longer a case in git-1.5.0.3. :-) ]

Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 UPDATED][2] cosmetic adaption of drivers/ide/Kconfig concerning SATA

[Patrick Ringl]

Bartlomiej Zolnierkiewicz wrote:

Hello,

On Sunday 18 March 2007, Patrick Ringl wrote:

Hello,


Hi,

since especially Serial ATA has it's own menu point now, I guess we can 
change the description of the deprecated SATA driver as well, since the 
new libATA subsystem is not configured through a SCSI low-level driver 
anymore, but has it's own menu point.


The following patch is against 2.6.21-rc4:

--- linux-2.6.20.old/drivers/ide/Kconfig2007-03-18 00:05:11.0 
+0100
+++ linux-2.6.20/drivers/ide/Kconfig2007-03-18 00:09:47.0 +0100
@@ -103,7 +103,7 @@
---help---
  There are two drivers for Serial ATA controllers.

- The main driver, "libata", exists inside the SCSI subsystem
+ The main driver, "libata", exists inside the ATA subsystem


Strictly speaking libata is not a separate subsystem (it still uses SCSI
subsystem) and "ATA subsystem" may be misleading, since we now have:

* "ATA/ATAPI/MFM/RLL support" menu for drivers/ide

* "Serial ATA (prod) and Parallel ATA (experimental) drivers" menu for libata

What about replacing "exists inside" into "uses" and adding info about
the new menu instead?
Well, that's even a better idea :-) I wasn't that sure about what to do 
.. it's just that it could be misleading since the new (s/p)ata drivers 
are not living in the scsi low-level subsystem anymore, but got their 
own menu point.


Here's a different patch >:)

--- linux-2.6.20.old/drivers/ide/Kconfig 2007-03-18 00:05:11.0 +0100

+++ linux-2.6.20/drivers/ide/Kconfig 2007-03-18 01:23:51.0 +0100

@@ -103,8 +103,10 @@

---help---

  There are two drivers for Serial ATA controllers.



-   The main driver, "libata", exists inside the SCSI subsystem

-   and supports most modern SATA controllers.

+   The main driver, "libata", uses the SCSI subsystem

+   and supports most modern SATA controllers. In order to use it

+   you may take a look at "Serial ATA (prod) and Parallel ATA

+   (experimental) drivers".



  The IDE driver (which you are currently configuring) supports

  a few first-generation SATA controllers.

---

Thanks,
Bart

  


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

Re: [git patches] IDE fixes

[Linus Torvalds]

On Sat, 17 Mar 2007, Bartlomiej Zolnierkiewicz wrote:
> 
> to receive the following updates:
> 
>  b/drivers/ide/Kconfig   |   48 -
>  b/drivers/ide/Makefile  |1 
>  b/drivers/ide/arm/icside.c  |   13 
>  b/drivers/ide/ide-dma.c |2 
>  b/drivers/ide/ide.c |4 
>  b/drivers/ide/mips/au1xxx-ide.c |3 
>  b/drivers/ide/pci/Makefile  |1 
>  b/drivers/ide/pci/cmd64x.c  |   45 -
>  b/drivers/ide/pci/jmicron.c |   29 
>  b/drivers/ide/pci/scc_pata.c|  858 
> 
>  b/drivers/ide/setup-pci.c   |5 
>  b/include/asm-mips/mach-au1x00/au1xxx_ide.h |   34 -
>  drivers/ide/ppc/scc_pata.c  |  858 
> 
>  13 files changed, 915 insertions(+), 986 deletions(-)

Please use

git diff -M --stat --summary 

to generate the diffstat (where the "-M" is the important part). Your 
"scc_pata.c" change was a pure rename, but because you didn't ask for 
rename detection, it got shown as a file create/delete pair. It *should* 
have looked like this:

 drivers/ide/Kconfig   |   48 +
 drivers/ide/Makefile  |1 -
 drivers/ide/arm/icside.c  |   13 +---
 drivers/ide/ide-dma.c |2 +-
 drivers/ide/ide.c |4 --
 drivers/ide/mips/au1xxx-ide.c |3 +-
 drivers/ide/pci/Makefile  |1 +
 drivers/ide/pci/cmd64x.c  |   45 ---
 drivers/ide/pci/jmicron.c |   29 ++---
 drivers/ide/{ppc => pci}/scc_pata.c   |0
 drivers/ide/setup-pci.c   |5 ---
 include/asm-mips/mach-au1x00/au1xxx_ide.h |   34 
 12 files changed, 57 insertions(+), 128 deletions(-)
 rename drivers/ide/{ppc => pci}/scc_pata.c (100%)

which is a lot more accurate than what you get by feeding a diff through 
"diffstat" that has no clue about renames (look at the summary for number 
of lines changed ;)

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 UPDATED] cosmetic adaption of drivers/ide/Kconfig concerning SATA

[Bartlomiej Zolnierkiewicz]

On Sunday 18 March 2007, Patrick Ringl wrote:
> Hello,

Hi,

> since especially Serial ATA has it's own menu point now, I guess we can 
> change the description of the deprecated SATA driver as well, since the 
> new libATA subsystem is not configured through a SCSI low-level driver 
> anymore, but has it's own menu point.
> 
> The following patch is against 2.6.21-rc4:
> 
> --- linux-2.6.20.old/drivers/ide/Kconfig  2007-03-18 00:05:11.0 
> +0100
> +++ linux-2.6.20/drivers/ide/Kconfig  2007-03-18 00:09:47.0 +0100
> @@ -103,7 +103,7 @@
>   ---help---
> There are two drivers for Serial ATA controllers.
> 
> -   The main driver, "libata", exists inside the SCSI subsystem
> +   The main driver, "libata", exists inside the ATA subsystem

Strictly speaking libata is not a separate subsystem (it still uses SCSI
subsystem) and "ATA subsystem" may be misleading, since we now have:

* "ATA/ATAPI/MFM/RLL support" menu for drivers/ide

* "Serial ATA (prod) and Parallel ATA (experimental) drivers" menu for libata

What about replacing "exists inside" into "uses" and adding info about
the new menu instead?

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

[PATCH] drivers/scsi/eata_generic.h: Remove FALSE/TRUE defines

[Richard Knutsson]

Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Only included by drivers/scsi/eata_pio.c and it only uses FALSE/TRUE
in comments.


diff --git a/drivers/scsi/eata_generic.h b/drivers/scsi/eata_generic.h
index 635c148..5016af5 100644
--- a/drivers/scsi/eata_generic.h
+++ b/drivers/scsi/eata_generic.h
@@ -18,13 +18,6 @@
  * Misc. definitions*
  */
 
-#ifndef TRUE
-#define TRUE 1
-#endif
-#ifndef FALSE
-#define FALSE 0
-#endif
-
 #define R_LIMIT 0x2
 
 #define MAXISA4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ieee1394: unroll a weird macro

[Stefan Richter]

This is a coding style touch-up for ieee1394's handle_incoming_packet().

A preprocessor macro contained hardwired variable names and, even worse,
the 'break' keyword.  This macro is now unrolled and removed.

Also, all 'break's which had the effect of a return are replaced by
return.  And a FIXME comment is brought up to date.

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---

 drivers/ieee1394/ieee1394_core.c |   91 +--
 1 file changed, 41 insertions(+), 50 deletions(-)


Index: linux/drivers/ieee1394/ieee1394_core.c
===
--- linux.orig/drivers/ieee1394/ieee1394_core.c
+++ linux/drivers/ieee1394/ieee1394_core.c
@@ -856,12 +856,9 @@ static void fill_async_lock_resp(struct 
packet->data_size = length;
 }
 
-#define PREP_REPLY_PACKET(length) \
-   packet = create_reply_packet(host, data, length); \
-   if (packet == NULL) break
-
 static void handle_incoming_packet(struct hpsb_host *host, int tcode,
-  quadlet_t *data, size_t size, int 
write_acked)
+  quadlet_t *data, size_t size,
+  int write_acked)
 {
struct hpsb_packet *packet;
int length, rcode, extcode;
@@ -871,74 +868,72 @@ static void handle_incoming_packet(struc
u16 flags = (u16) data[0];
u64 addr;
 
-   /* big FIXME - no error checking is done for an out of bounds length */
+   /* FIXME?
+* Out-of-bounds lengths are left for highlevel_read|write to cap. */
 
switch (tcode) {
case TCODE_WRITEQ:
addr = (((u64)(data[1] & 0x)) << 32) | data[2];
-   rcode = highlevel_write(host, source, dest, data+3,
+   rcode = highlevel_write(host, source, dest, data + 3,
addr, 4, flags);
-
-   if (!write_acked
-   && (NODEID_TO_NODE(data[0] >> 16) != NODE_MASK)
-   && (rcode >= 0)) {
-   /* not a broadcast write, reply */
-   PREP_REPLY_PACKET(0);
-   fill_async_write_resp(packet, rcode);
-   send_packet_nocare(packet);
-   }
-   break;
+   goto handle_write_request;
 
case TCODE_WRITEB:
addr = (((u64)(data[1] & 0x)) << 32) | data[2];
-   rcode = highlevel_write(host, source, dest, data+4,
-   addr, data[3]>>16, flags);
-
-   if (!write_acked
-   && (NODEID_TO_NODE(data[0] >> 16) != NODE_MASK)
-   && (rcode >= 0)) {
-   /* not a broadcast write, reply */
-   PREP_REPLY_PACKET(0);
+   rcode = highlevel_write(host, source, dest, data + 4,
+   addr, data[3] >> 16, flags);
+handle_write_request:
+   if (rcode < 0 || write_acked ||
+   NODEID_TO_NODE(data[0] >> 16) == NODE_MASK)
+   return;
+   /* not a broadcast write, reply */
+   packet = create_reply_packet(host, data, 0);
+   if (packet) {
fill_async_write_resp(packet, rcode);
send_packet_nocare(packet);
}
-   break;
+   return;
 
case TCODE_READQ:
addr = (((u64)(data[1] & 0x)) << 32) | data[2];
rcode = highlevel_read(host, source, , addr, 4, flags);
+   if (rcode < 0)
+   return;
 
-   if (rcode >= 0) {
-   PREP_REPLY_PACKET(0);
+   packet = create_reply_packet(host, data, 0);
+   if (packet) {
fill_async_readquad_resp(packet, rcode, buffer);
send_packet_nocare(packet);
}
-   break;
+   return;
 
case TCODE_READB:
length = data[3] >> 16;
-   PREP_REPLY_PACKET(length);
+   packet = create_reply_packet(host, data, length);
+   if (!packet)
+   return;
 
addr = (((u64)(data[1] & 0x)) << 32) | data[2];
rcode = highlevel_read(host, source, packet->data, addr,
   length, flags);
-
-   if (rcode >= 0) {
-   fill_async_readblock_resp(packet, rcode, length);
-   send_packet_nocare(packet);
-   } else {
+   if (rcode < 0) {
hpsb_free_packet(packet);
+   return;
}
-   break;
+   fill_async_readblock_resp(packet, rcode, length);
+   send_packet_nocare(packet);
+   return;
 
case 

[PATCH] ieee1394: remove usage of skb_queue as packet queue

[Stefan Richter]

This considerably reduces the memory requirements for a packet and
eliminates ieee1394's dependency on CONFIG_NET.

TODO:
  - Double-check if there are any drivers whose packet complete routine
really needs process context. If there are none, get rid of khpsbpkt
and execute the complete routine in the low-level driver's bottom
half's context.
  - Check whether the complete packet really has to be zeroed when
allocated.
  - Allocate small frequently used packets (e.g. quadlet read requests
and 4...8 bytes write requests) from a kmem_cache. Append separately
allocated data sections only if necessary.

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---

 drivers/ieee1394/Kconfig |1
 drivers/ieee1394/hosts.c |   12 -
 drivers/ieee1394/hosts.h |4
 drivers/ieee1394/ieee1394_core.c |  296 ---
 drivers/ieee1394/ieee1394_core.h |   27 --
 5 files changed, 165 insertions(+), 175 deletions(-)


Index: linux/drivers/ieee1394/Kconfig
===
--- linux.orig/drivers/ieee1394/Kconfig
+++ linux/drivers/ieee1394/Kconfig
@@ -7,7 +7,6 @@ source "drivers/firewire/Kconfig"
 config IEEE1394
tristate "IEEE 1394 (FireWire) support"
depends on PCI || BROKEN
-   select NET
help
  IEEE 1394 describes a high performance serial bus, which is also
  known as FireWire(tm) or i.Link(tm) and is used for connecting all
Index: linux/drivers/ieee1394/hosts.c
===
--- linux.orig/drivers/ieee1394/hosts.c
+++ linux/drivers/ieee1394/hosts.c
@@ -94,14 +94,6 @@ static int alloc_hostnum_cb(struct hpsb_
return 0;
 }
 
-/*
- * The pending_packet_queue is special in that it's processed
- * from hardirq context too (such as hpsb_bus_reset()). Hence
- * split the lock class from the usual networking skb-head
- * lock class by using a separate key for it:
- */
-static struct lock_class_key pending_packet_queue_key;
-
 static DEFINE_MUTEX(host_num_alloc);
 
 /**
@@ -137,9 +129,7 @@ struct hpsb_host *hpsb_alloc_host(struct
h->hostdata = h + 1;
h->driver = drv;
 
-   skb_queue_head_init(>pending_packet_queue);
-   lockdep_set_class(>pending_packet_queue.lock,
-  _packet_queue_key);
+   INIT_LIST_HEAD(>pending_packets);
INIT_LIST_HEAD(>addr_space);
 
for (i = 2; i < 16; i++)
Index: linux/drivers/ieee1394/hosts.h
===
--- linux.orig/drivers/ieee1394/hosts.h
+++ linux/drivers/ieee1394/hosts.h
@@ -3,7 +3,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -25,8 +24,7 @@ struct hpsb_host {
 
atomic_t generation;
 
-   struct sk_buff_head pending_packet_queue;
-
+   struct list_head pending_packets;
struct timer_list timeout;
unsigned long timeout_interval;
 
Index: linux/drivers/ieee1394/ieee1394_core.c
===
--- linux.orig/drivers/ieee1394/ieee1394_core.c
+++ linux/drivers/ieee1394/ieee1394_core.c
@@ -30,7 +30,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -103,6 +102,8 @@ static void queue_packet_complete(struct
  *
  * Set the task that runs when a packet completes. You cannot call this more
  * than once on a single packet before it is sent.
+ *
+ * Typically, the complete @routine is responsible to call hpsb_free_packet().
  */
 void hpsb_set_packet_complete_task(struct hpsb_packet *packet,
   void (*routine)(void *), void *data)
@@ -115,12 +116,12 @@ void hpsb_set_packet_complete_task(struc
 
 /**
  * hpsb_alloc_packet - allocate new packet structure
- * @data_size: size of the data block to be allocated
+ * @data_size: size of the data block to be allocated, in bytes
  *
  * This function allocates, initializes and returns a new  hpsb_packet.
- * It can be used in interrupt context.  A header block is always included, its
- * size is big enough to contain all possible 1394 headers.  The data block is
- * only allocated when @data_size is not zero.
+ * It can be used in interrupt context.  A header block is always included and
+ * initialized with zeros.  Its size is big enough to contain all possible 1394
+ * headers.  The data block is only allocated if @data_size is not zero.
  *
  * For packets for which responses will be received the @data_size has to be 
big
  * enough to contain the response's data block since no further allocation
@@ -135,50 +136,42 @@ void hpsb_set_packet_complete_task(struc
  */
 struct hpsb_packet *hpsb_alloc_packet(size_t data_size)
 {
-   struct hpsb_packet *packet = NULL;
-   struct sk_buff *skb;
+   struct hpsb_packet *packet;
 
data_size = ((data_size + 3) & ~3);
 
-   skb = alloc_skb(data_size + sizeof(*packet), GFP_ATOMIC);
-

[PATCH] drivers/char/agp: Convert to generic boolean

[Richard Knutsson]

drivers/char/agp/
  Convert to generic booleans

include/linux/agpgart.h
  Removed defines of FALSE/TRUE
was only used under drivers/char/agp/
  struct agp_front_data {
Removed used_by_controller
  only assigned 'false' once and never used
Convert backend_acquired from 'u8' to 'bool'
  only used in drivers/char/agp/ and only as a boolean value

Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno"

 drivers/char/agp/amd-k7-agp.c   |4 ++--
 drivers/char/agp/amd64-agp.c|4 ++--
 drivers/char/agp/ati-agp.c  |4 ++--
 drivers/char/agp/compat_ioctl.c |2 +-
 drivers/char/agp/efficeon-agp.c |4 ++--
 drivers/char/agp/frontend.c |   11 +--
 drivers/char/agp/generic.c  |   22 +++---
 drivers/char/agp/hp-agp.c   |4 ++--
 drivers/char/agp/intel-agp.c|8 
 drivers/char/agp/nvidia-agp.c   |4 ++--
 drivers/char/agp/parisc-agp.c   |4 ++--
 drivers/char/agp/sgi-agp.c  |4 ++--
 drivers/char/agp/sworks-agp.c   |4 ++--
 include/linux/agpgart.h |   11 +--
 14 files changed, 40 insertions(+), 50 deletions(-)


diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp/amd-k7-agp.c
index e6c534e..3d57e9f 100644
--- a/drivers/char/agp/amd-k7-agp.c
+++ b/drivers/char/agp/amd-k7-agp.c
@@ -308,9 +308,9 @@ static int amd_insert_memory(struct agp_memory *mem, off_t 
pg_start, int type)
j++;
}
 
-   if (mem->is_flushed == FALSE) {
+   if (!mem->is_flushed) {
global_cache_flush();
-   mem->is_flushed = TRUE;
+   mem->is_flushed = true;
}
 
for (i = 0, j = pg_start; i < mem->page_count; i++, j++) {
diff --git a/drivers/char/agp/amd64-agp.c b/drivers/char/agp/amd64-agp.c
index 4857204..54aba18 100644
--- a/drivers/char/agp/amd64-agp.c
+++ b/drivers/char/agp/amd64-agp.c
@@ -89,9 +89,9 @@ static int amd64_insert_memory(struct agp_memory *mem, off_t 
pg_start, int type)
j++;
}
 
-   if (mem->is_flushed == FALSE) {
+   if (!mem->is_flushed) {
global_cache_flush();
-   mem->is_flushed = TRUE;
+   mem->is_flushed = true;
}
 
for (i = 0, j = pg_start; i < mem->page_count; i++, j++) {
diff --git a/drivers/char/agp/ati-agp.c b/drivers/char/agp/ati-agp.c
index 780e59e..aacd866 100644
--- a/drivers/char/agp/ati-agp.c
+++ b/drivers/char/agp/ati-agp.c
@@ -299,10 +299,10 @@ static int ati_insert_memory(struct agp_memory * mem,
j++;
}
 
-   if (mem->is_flushed == FALSE) {
+   if (!mem->is_flushed) {
/*CACHE_FLUSH(); */
global_cache_flush();
-   mem->is_flushed = TRUE;
+   mem->is_flushed = true;
}
 
for (i = 0, j = pg_start; i < mem->page_count; i++, j++) {
diff --git a/drivers/char/agp/compat_ioctl.c b/drivers/char/agp/compat_ioctl.c
index fcb4b1b..851bfa9 100644
--- a/drivers/char/agp/compat_ioctl.c
+++ b/drivers/char/agp/compat_ioctl.c
@@ -213,7 +213,7 @@ long compat_agp_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
ret_val = -EINVAL;
goto ioctl_out;
}
-   if ((agp_fe.backend_acquired != TRUE) &&
+   if (!agp_fe.backend_acquired &&
(cmd != AGPIOC_ACQUIRE32)) {
ret_val = -EBUSY;
goto ioctl_out;
diff --git a/drivers/char/agp/efficeon-agp.c b/drivers/char/agp/efficeon-agp.c
index df8da72..1941248 100644
--- a/drivers/char/agp/efficeon-agp.c
+++ b/drivers/char/agp/efficeon-agp.c
@@ -249,9 +249,9 @@ static int efficeon_insert_memory(struct agp_memory * mem, 
off_t pg_start, int t
if (type != 0 || mem->type != 0)
return -EINVAL;
 
-   if (mem->is_flushed == FALSE) {
+   if (!mem->is_flushed) {
global_cache_flush();
-   mem->is_flushed = TRUE;
+   mem->is_flushed = true;
}
 
last_page = NULL;
diff --git a/drivers/char/agp/frontend.c b/drivers/char/agp/frontend.c
index 679d7f9..a326942 100644
--- a/drivers/char/agp/frontend.c
+++ b/drivers/char/agp/frontend.c
@@ -393,7 +393,7 @@ static int agp_remove_controller(struct agp_controller 
*controller)
 
if (agp_fe.current_controller == controller) {
agp_fe.current_controller = NULL;
-   agp_fe.backend_acquired = FALSE;
+   agp_fe.backend_acquired = false;
agp_backend_release(agp_bridge);
}
kfree(controller);
@@ -441,7 +441,6 @@ static void agp_controller_release_current(struct 
agp_controller *controller,
}
 
agp_fe.current_controller = NULL;
-   agp_fe.used_by_controller = FALSE;
agp_backend_release(agp_bridge);
 }
 
@@ -571,7 +570,7 @@ static int agp_mmap(struct file *file, struct 
vm_area_struct *vma)
 
mutex_lock(&(agp_fe.agp_mutex));
 
-  

Re: Linux 2.6.21-rc4

[Adrian Bunk]

On Fri, Mar 16, 2007 at 08:03:29PM +0100, Michal Piotrowski wrote:
> On 16/03/07, Takashi Iwai <[EMAIL PROTECTED]> wrote:
> >At Fri, 16 Mar 2007 18:44:26 +0100,
> >Michal Piotrowski wrote:
> >>
> >> Takashi, unfortunately this bug isn't fixed
> >> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#1684
> >
> >The patch wasn't merged to rc4.
> 
> I know. I use patched 2.6.21-rc3-git4 for crashdump.
> 
> >Or, do you mean the bug is still present even with the patch?
> 
> This patch doesn't fix the problem.
> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/3080.html
> 
> Tomorrow, I'll try to provide more info about this problem.

You said at [1] that the patch from [2] (not yet merged into Linus' tree) 
fixed this problem for you.

Or do I confuse anything?

> Regards,
> Michal

cu
Adrian

[1] http://lkml.org/lkml/2007/3/13/276
[2] http://lkml.org/lkml/2007/3/7/540

-- 

   "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: fake config option w/kbuild?

[Adrian Bunk]

On Thu, Mar 15, 2007 at 03:08:47PM -0500, Kumar Gala wrote:
> 
> On Mar 15, 2007, at 2:12 PM, Adrian Bunk wrote:
> 
> >On Thu, Mar 15, 2007 at 10:19:03AM -0500, Kumar Gala wrote:
> >>...
> >>My initial question is that I don't want anyone using CONFIG_QE_83xx
> >>or CONFIG_QE_85xx in code, the second part is if there is a way to
> >>remove duplicating the QE_83xx/QE_85xx options down in platform/8 
> >>{3,5}
> >>xx/Kconfig.
> >
> >
> >What about the following solution:
> >
> >
> >arch/powerpc/Kconfig.qe:
> >
> ><--  snip  -->
> >
> >config MACH_SUPPORTS_QE
> > bool
> >
> >config QE
> > bool "QUICC Engine Support"
> > depends on MACH_SUPPORTS_QE
> > help
> >   ...
> >
> ><--  snip  -->
> >
> >
> >arch/powerpc/platforms/83xx/Kconfig:
> >
> ><--  snip  -->
> >
> >...
> >source arch/powerpc/Kconfig.qe
> >
> >config PPC_MPC836x
> >bool
> > select MACH_SUPPORTS_QE
> > ...
> >
> >
> ><--  snip  -->
> 
> Not sure this helps since I end up having to source arch/powerpc/ 
> Kconfig.qe from both arch/powerpc/platforms/83xx/Kconfig & arch/ 
> powerpc/platforms/85xx/Kconfig and then mconf grips about having  
> already scanned Kconfig.qe.


Sorry, my fault that I didn't test it myself before suggesting it.

It seems there is no solution for both not duplicating the options and 
getting them in the desired menu.


> - k

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: [BUG] 2.6.21-rc1,2,3 regressions on my system that I found so far

[Thomas Gleixner]

Maxim,

On Sun, 2007-03-18 at 01:00 +0200, Maxim wrote:
> >Mar 14 00:22:23 MAIN kernel: [2.072931] checking TSC synchronization 
> >[CPU#0 -> CPU#1]:
> >Mar 14 00:22:23 MAIN kernel: [2.092922] Measured 72051818872 cycles TSC 
> >warp between CPUs, turning off
> 
> ^ This one I don't think is related to NO_HZ, maybe it is hardware
> problem, but it exist without NO_HZ

The TSC is checked for synchronization between the CPUs. It's nothing to
worry about. We switch off the TSC and use a different clocksource.

Is this after resume ? If yes, then something (probably BIOS) is
fiddling with the TSC of one CPU when the resume happens.

> >[   36.217405] ENABLING IO-APIC IRQs
> >[   36.217587] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
> >[   36.433917] APIC timer disabled due to verification failure.
> 
> This one is now discussed, I will look at it and it is not related to NO_HZ

I sent a patch for this yesterday:

http://marc.info/?l=linux-kernel=117408952322631=2

> And I forgot to tell about another problem with (now I know ,hi-resolution 
> timers)
> That before suspend to ram APIC timer is used and HPET is not used :
> 
> [EMAIL PROTECTED]:/home/maxim# cat 
> /sys/devices/system/clockevents/clockevents0/registered
> lapicF:0007 M:3(periodic) C: 1
> hpet F:0003 M:1(shutdown) C: 0
> lapicF:0007 M:3(periodic) C: 0
> [EMAIL PROTECTED]:/home/maxim#   
> 
> But after suspend to ram HPET is 'woken'
> 
> [EMAIL PROTECTED]:/home/maxim# cat 
> /sys/devices/system/clockevents/clockevents0/registered
> lapicF:0007 M:3(one shoot) C: 1
> hpet F:0003 M:3(one shoot) C: 0
> lapicF:0007 M:3(one shoot) C: 0

This is unrelated to suspend / resume. The local apic timers stop
(hardware madness), when the CPU enters C3 power state. In this case we
switch to HPET (or PIT when HPET is not available) and broadcast the
events via Inter Processor Interrupts. This is nothing to worry about. 

I'm a bit surprised though, that your system was in periodic mode before
suspend and switched to one shot mode on resume.

Is this reproducible ? If yes, can you please provide the dmesg output
from boot to resume ?

> Note that I added those (one shoot), (periodic) descriptions, would be
> nice to have them in kernel, can I send a patch ?  ;-)

Sure, just s/shoot/shot/ :)

> and I see average of 18 IRQs/sec on IRQ 0

So dynticks are working as expected.

tglx


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

[PATCH UPDATED] cosmetic adaption of drivers/ide/Kconfig concerning SATA

[Patrick Ringl]

Hello,
since especially Serial ATA has it's own menu point now, I guess we can 
change the description of the deprecated SATA driver as well, since the 
new libATA subsystem is not configured through a SCSI low-level driver 
anymore, but has it's own menu point.


The following patch is against 2.6.21-rc4:

--- linux-2.6.20.old/drivers/ide/Kconfig2007-03-18 00:05:11.0 
+0100
+++ linux-2.6.20/drivers/ide/Kconfig2007-03-18 00:09:47.0 +0100
@@ -103,7 +103,7 @@
---help---
  There are two drivers for Serial ATA controllers.

- The main driver, "libata", exists inside the SCSI subsystem
+ The main driver, "libata", exists inside the ATA subsystem
  and supports most modern SATA controllers.

  The IDE driver (which you are currently configuring) supports

---

Since I am not subscribed to the list, I'd find it great if I were
personally CC'ed. :-)


Best regards
Patrick





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

I can't compile with success because ueagle-atm.ko undefined

[Thibaud Hulin]

Hi,
I can't compile with success my kernel, i've got this error message :

  Building modules, stage 2.
  MODPOST 1750 modules
WARNING: Can't handle masks in drivers/ide/pci/atiixp:05
WARNING: "try_to_freeze" [drivers/usb/atm/ueagle-atm.ko] undefined!
make[2]: *** [__modpost] Erreur 1
make[1]: *** [modules] Erreur 2

When I uncheck this module, the compiled kernel works, but there are 
many problems and the kernel fails after minutes.


I use a Nvdia Geforce graphic card.


Thanks for help,
Thibaud.

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

Re: [BUG] 2.6.21-rc1,2,3 regressions on my system that I found so far

[Maxim]

On Saturday 17 March 2007 01:39:01 Thomas Gleixner wrote:
> On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
> > Mar 14 00:22:23 MAIN kernel: [2.072875] caller is 
> > check_tsc_sync_source+0x1d/0x100
> > Mar 14 00:22:23 MAIN kernel: [2.072878]  [show_trace_log_lvl+26/48] 
> > show_trace_log_lvl+0x1a/0x30
> > Mar 14 00:22:23 MAIN kernel: [2.072931] checking TSC synchronization 
> > [CPU#0 -> CPU#1]:
> > Mar 14 00:22:23 MAIN kernel: [2.092922] Measured 72051818872 cycles TSC 
> > warp between CPUs, turning off
> > 
> > It looks clear that preempt is enabled all the way in second cpu 
> > initialization, ( I think that at least in check_tsc_sync_source, it should 
> > be disabled,
> > shouldn't it ? )
> 
> This should be fixed by commit d04f41e35343f1d788551fd3f753f51794f4afcf
> 
>   tglx
> 
> 
> 
> 

Hi,

Yes, it is fixed, thanks

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

Re: [BUG] 2.6.21-rc1,2,3 regressions on my system that I found so far

[Maxim]

On Saturday 17 March 2007 01:19:44 Len Brown wrote:
> On Friday 16 March 2007 06:30, Maxim Levitsky wrote:
> > 
> > Good day, 
> > 
> > I want to report regressions I have with 2.6.21-rc3 kernel.
> > I use CONFIG_NO_HZ.
> 
> Do any of these issues go away with CONFIG_NO_HZ=n (or boot with nohz=n)
> or are they all independent of it?
> 
> thanks,
> -Len
> 
> > 1) Both suspend to disk and suspend to RAM are completely broken:
> > On vanilla 2.6.20 suspend to disk works perfectly and suspend to ram works 
> > _almost_ perfectly (I will tell about that later).
> > On 2.6.21-rc1 and later system hangs even before suspend begins (suspend to 
> > disk hangs before image write , and after suspend to ram , 
> > some devices are powered down (disk,power leds) , and some and not(fans, 
> > power) , and system hangs).
> > 
> > I did a git-bisect and I found which commit caused that:
> > e3c7db621bed4afb8e231cb005057f2feb5db557 - [PATCH] [PATCH] PM: Change 
> > code ordering in main.c (breaks  S3)
> > ed746e3b18f4df18afa3763155972c5835f284c5 - [PATCH] [PATCH] swsusp: 
> > Change code ordering in disk.c (breaks swsusp, I don't use it, but I tested 
> > it)
> > 259130526c267550bc365d3015917d90667732f1 - [PATCH] [PATCH] swsusp: 
> > Change code ordering in user.c (breaks uswsusp, that I use)
> > 
> > I reverted those commits and now system suspends correctly to disk, but 
> > suspend to ram showed some more regressions.
> > 
> > 
> > 2) ) After suspend to ram I get this 
> > 
> > Mar 14 00:22:23 MAIN kernel: [2.072875] caller is 
> > check_tsc_sync_source+0x1d/0x100
> > Mar 14 00:22:23 MAIN kernel: [2.072878]  [show_trace_log_lvl+26/48] 
> > show_trace_log_lvl+0x1a/0x30
> > Mar 14 00:22:23 MAIN kernel: [2.072881]  [show_trace+18/32] 
> > show_trace+0x12/0x20
> > Mar 14 00:22:23 MAIN kernel: [2.072884]  [dump_stack+22/32] 
> > dump_stack+0x16/0x20
> > Mar 14 00:22:23 MAIN kernel: [2.072887]  
> > [debug_smp_processor_id+173/176] debug_smp_processor_id+0xad/0xb0
> > Mar 14 00:22:23 MAIN kernel: [2.072891]  [check_tsc_sync_source+29/256] 
> > check_tsc_sync_source+0x1d/0x100
> > Mar 14 00:22:23 MAIN kernel: [2.072894]  [__cpu_up+80/384] 
> > __cpu_up+0x50/0x180
> > Mar 14 00:22:23 MAIN kernel: [2.072897]  [_cpu_up+98/208] 
> > _cpu_up+0x62/0xd0
> > Mar 14 00:22:23 MAIN kernel: [2.072901]  [cpu_up+46/80] cpu_up+0x2e/0x50
> > Mar 14 00:22:23 MAIN kernel: [2.072903]  [enable_nonboot_cpus+110/160] 
> > enable_nonboot_cpus+0x6e/0xa0
> > Mar 14 00:22:23 MAIN kernel: [2.072906]  [enter_state+326/496] 
> > enter_state+0x146/0x1f0
> > Mar 14 00:22:23 MAIN kernel: [2.072909]  [state_store+174/192] 
> > state_store+0xae/0xc0
> > Mar 14 00:22:23 MAIN kernel: [2.072912]  [subsys_attr_store+43/64] 
> > subsys_attr_store+0x2b/0x40
> > Mar 14 00:22:23 MAIN kernel: [2.072917]  [sysfs_write_file+186/272] 
> > sysfs_write_file+0xba/0x110
> > Mar 14 00:22:23 MAIN kernel: [2.072920]  [vfs_write+150/352] 
> > vfs_write+0x96/0x160
> > Mar 14 00:22:23 MAIN kernel: [2.072923]  [sys_write+61/112] 
> > sys_write+0x3d/0x70
> > Mar 14 00:22:23 MAIN kernel: [2.072926]  [sysenter_past_esp+93/153] 
> > sysenter_past_esp+0x5d/0x99
> > Mar 14 00:22:23 MAIN kernel: [2.072929]  ===
> > Mar 14 00:22:23 MAIN kernel: [2.072931] checking TSC synchronization 
> > [CPU#0 -> CPU#1]:
> > Mar 14 00:22:23 MAIN kernel: [2.092922] Measured 72051818872 cycles TSC 
> > warp between CPUs, turning off
> > 
> > It looks clear that preempt is enabled all the way in second cpu 
> > initialization, ( I think that at least in check_tsc_sync_source, it should 
> > be disabled,
> > shouldn't it ? )
> > 
> > Then I did add preempt_disable() / preempt_enable()  to this function , and 
> >  I still got this:
> > 
> > Mar 14 00:22:23 MAIN kernel: [2.072931] checking TSC synchronization 
> > [CPU#0 -> CPU#1]:
> > Mar 14 00:22:23 MAIN kernel: [2.092922] Measured 72051818872 cycles TSC 
> > warp between CPUs, turning off
> > 
> > It happens after second CPU is brought back on-line.
> > 
> > Now I understand that this is TSC sync problem and I tried to do some tests:
> > 
> >  I tried to disable/enable second CPU by hand, eg I did number of times,
> > 
> > echo "0" > /sys/devices/system/cpu/cpu1/online
> > echo "1" > /sys/devices/system/cpu/cpu1/online
> > 
> > and TSC sync was ok.
> > 
> > Then I disabled 2nd CPU, have suspended system to RAM , resumed it  , and 
> > then enabled 2nd CPU and got same error message.
> > Then I disabled cpufreq , and did above tests, and got same results.
> > I think that maybe this error is false, that there is some difference in 
> > TSC clock, but this difference is constant, and can be fixed
> > 
> > 3) Sometimes I get this (once in three boots or so)
> > 
> > [   36.217405] ENABLING IO-APIC IRQs
> > [   36.217587] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
> > [   36.433917] APIC timer disabled due to verification 

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

[Jiri Slaby]

Alan Stern napsal(a):

On Tue, 13 Mar 2007, Jiri Slaby wrote:


So, do you mean rmmod uhci_hcd, unplug the keyboard, modprobe
uhci_hcd, start usbmon, plug the keyboard, press numlock, stop usbmon,
post it?


Here you are:
f78666c0 1992239699 C Ii:001:01 -2 0
f74d7b40 1996231756 S Ci:001:00 s 80 00   0002 2 <
f74d7b40 1996231762 C Ci:001:00 0 2 = 0300
f78666c0 1996271682 S Ii:001:01 -115 2 <
f74d7b40 1996271689 S Ci:001:00 s a3 00  0001 0004 4 <
f74d7b40 1996271694 C Ci:001:00 0 4 = 0001
f74d7b40 1996271698 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996271708 C Ci:001:00 0 4 = 01010100
f74d7b40 1996271710 S Co:001:00 s 23 01 0010 0002  0
f74d7b40 1996271713 C Co:001:00 0 0
f74d7b40 1996271719 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996271722 C Ci:001:00 0 4 = 0101
f74d7b40 1996303687 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996303693 C Ci:001:00 0 4 = 0101
f74d7b40 1996335682 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996335689 C Ci:001:00 0 4 = 0101
f74d7b40 1996367681 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996367686 C Ci:001:00 0 4 = 0101
f74d7b40 1996399686 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996399692 C Ci:001:00 0 4 = 0101
f74d7b40 1996399709 S Co:001:00 s 23 03 0004 0002  0
f74d7b40 1996399712 C Co:001:00 0 0
f74d7b40 1996455682 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996455703 C Ci:001:00 0 4 = 0301
f74d7b40 1996514453 S Co:001:00 s 23 01 0014 0002  0
f74d7b40 1996514456 C Co:001:00 0 0
f74d7b40 1996514468 S Ci:000:00 s 80 06 0100  0040 64 <
f74d7b40 1996518652 C Ci:000:00 0 8 = 12011001 0908
f74d7b40 1996518660 S Co:001:00 s 23 03 0004 0002  0
f74d7b40 1996518663 C Co:001:00 0 0
f78666c0 1996527684 C Ii:001:01 0 1 = 04
f78666c0 1996527687 S Ii:001:01 -115 2 <
f74d7b40 1996571683 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996571702 C Ci:001:00 0 4 = 0301
f74d7b40 1996627687 S Co:001:00 s 23 01 0014 0002  0
f74d7b40 1996627691 C Co:001:00 0 0
f74d7b40 1996627694 S Co:000:00 s 00 05 0002   0
f74d7b40 1996630633 C Co:000:00 0 0
f74d7b40 1996647688 S Ci:002:00 s 80 06 0100  0012 18 <
f74d7b40 1996653630 C Ci:002:00 0 18 = 12011001 0908 b4045020 01000102 0001
f74d7b40 1996653639 S Ci:002:00 s 80 06 0200  0009 9 <
f74d7b40 1996658627 C Ci:002:00 0 9 = 09021900 010100e0 32
f74d7b40 1996658634 S Ci:002:00 s 80 06 0200  0019 25 <
f74d7b40 1996665626 C Ci:002:00 0 25 = 09021900 010100e0 32090400 00010900 
0705 81030100 ff

f74d7b40 1996665640 S Ci:002:00 s 80 06 0300  00ff 255 <
f74d7b40 1996670625 C Ci:002:00 0 4 = 04030904
f74d7b40 1996670635 S Ci:002:00 s 80 06 0302 0409 00ff 255 <
f74d7b40 1996682623 C Ci:002:00 0 62 = 3e034700 42006500 6c006c00 61002000 
43006f00 72007000 6f007200 61007400

f74d7b40 1996682631 S Ci:002:00 s 80 06 0301 0409 00ff 255 <
f74d7b40 1996691621 C Ci:002:00 0 36 = 24034200 65006c00 6c006100 20004300 
6f007200 70006f00 72006100 74006900

f74d7b40 1996691781 S Co:002:00 s 00 09 0001   0
f74d7b40 1996694627 C Co:002:00 0 0
f74d7b40 1996694717 S Ci:002:00 s a0 06 2900  000f 15 <
f74d7b40 1996697629 C Ci:002:00 0 9 = 0929030d 00321902 ff
f74d7b40 1996697664 S Ci:002:00 s 80 00   0002 2 <
f74d7b40 1996698633 C Ci:002:00 0 2 = 
f74d7b40 1996698663 S Ci:002:00 s a0 00   0004 4 <
f74d7b40 1996699629 C Ci:002:00 0 4 = 
f7ab7d40 1996699658 S Co:002:00 s 23 03 0008 0001  0
f7ab7d40 1996700627 C Co:002:00 0 0
f7ab7d40 1996700645 S Co:002:00 s 23 03 0008 0002  0
f7ab7d40 1996701629 C Co:002:00 0 0
f7ab7d40 1996701644 S Co:002:00 s 23 03 0008 0003  0
f7ab7d40 1996702624 C Co:002:00 0 0
f74d7b40 1996806484 S Ii:002:01 -115 1 <
f75d02c0 1996806621 S Ci:001:00 s a3 00  0002 0004 4 <
f75d02c0 1996806626 C Ci:001:00 0 4 = 0301
f75d02c0 1996806634 S Ci:002:00 s a3 00  0001 0004 4 <
f75d02c0 1996808610 C Ci:002:00 0 4 = 01010100
f75d02c0 1996808628 S Co:002:00 s 23 01 0010 0001  0
f75d02c0 1996809607 C Co:002:00 0 0
f75d02c0 1996809628 S Ci:002:00 s a3 00  0001 0004 4 <
f75d02c0 1996810605 C Ci:002:00 0 4 = 0101
f75d02c0 1996842478 S Ci:002:00 s a3 00  0001 0004 4 <
f75d02c0 1996843599 C Ci:002:00 0 4 = 0101
f75d02c0 1996871682 S Ci:002:00 s a3 00  0001 0004 4 <
f75d02c0 1996873590 C Ci:002:00 0 4 = 0101
f75d02c0 1996903686 S Ci:002:00 s a3 00  0001 0004 4 <
f75d02c0 1996905586 C Ci:002:00 0 4 = 0101
f75d02c0 1996938484 S Ci:002:00 s a3 00  0001 0004 4 <
f75d02c0 1996939582 C Ci:002:00 0 4 = 0101
f75d02c0 1996939601 S Co:002:00 s 23 03 0004 0001  0
f75d02c0 1996940581 C Co:002:00 0 0
f75d02c0 1996955681 S Ci:002:00 s a3 00  0001 0004 4 <
f75d02c0 1996957576 C Ci:002:00 0 4 = 03011000
f74d7b40 1997003567 C Ii:002:01 0 1 = 02
f74d7b40 1997003570 S Ii:002:01 -115 1 <
f75d02c0 1997011687 S Co:002:00 s 23 01 0014 0001  0
f75d02c0 1997013566 C Co:002:00 0 0
f75d02c0 1997013579 S Ci:000:00 s 80 06 0100  0040 64 <

Re: [BUG] 2.6.21-rc1,2,3 regressions on my system that I found so far

[Maxim]

On Saturday 17 March 2007 03:32:53 Len Brown wrote:
> On Friday 16 March 2007 19:44, Thomas Gleixner wrote:
> > Maxim,
> > 
> > On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
> > > 3) Sometimes I get this (once in three boots or so)
> > > 
> > > [   36.217405] ENABLING IO-APIC IRQs
> > > [   36.217587] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
> > > [   36.433917] APIC timer disabled due to verification failure.
> > > 
> > > And NO_HZ is disabled due to that (I get 1000/s timer's interrupts)
> > > I haven't investigated that yet.
> > > It looks like another new test that my hardware fails to perform... 
> > 
> > Yes, this is probably caused by SMM code trying to emulate a PS/2
> > keyboard from a (maybe connected or not) USB keyboard. Unfortunately we
> > have no way to disable this BIOS misfeature in the early boot process. 
> > Arjan, Len ?
> 
> Nope.  By definition, SMM is invisible to the OS -- we don't even
> get a bit that said it occurred (though we'd like one -- it would
> be really helpful to diagnose issues like this one)
> 
> So go into BIOS SETUP and see if there is a USB Legacy Emulation
> feature that you can disable.  Sometimes there is not, but disabling
> onboard USB altogether may help at least prove the issue is in that area.
> 
> > I built in this test to rule out bogus LAPIC timer calibration values
> > which are sometimes off by factor 2-10.
> > 
> > But I also built in a calibration against the PM-Timer, which turned out
> > to be quite reliable and I think the additional verification step is
> > only necessary for sytems without PM-Timer.
> > 
> > That was a bit over cautious from my side. I send a patch to avoid this
> > when PM-Timer is available in a separate mail.
> 
> PM-Timer was invented to work-around the issue that the TSC became unreliable
> in the face of power management on laptops.  In particular, to be able
> to time duration of OS idle where TSC stopped.
> 
> While it is not fine grain, and it is not low-latency, is should
> be very reliable.  My understanding is that it is implemented as
> a simple divider right off the system 14MHz clock -- the signal
> which most motherboard clocks are PLL multiplied up from --
> including the 100MHz front-side bus which drives the LAPIC timer.
> 
> But that said, I don't understand why calibrating the LAPIC timer
> using the PM-timer is going to be more reliable -- exactly how
> and why did the previous calibration scheme fail?
> Maybe I could follow the new logic in apic.c if I saw the "apic=debug"
> output for this box.
> 
> cheers,
> -Len
> 
> 
> 

Hi,

Yes, usb emulation is enabled, but I need it. I will test without usb 
emulation, but since it shows only sometimes, 
I don't know yet whenever usb legacy affects it.

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

[PATCH -mm 2/2] swsusp: Use GFP_KERNEL for creating basic data structures

[Rafael J. Wysocki]

From: Rafael J. Wysocki <[EMAIL PROTECTED]>

Make swsusp call create_basic_memory_bitmaps() before processes are frozen, so
that GFP_KERNEL allocations can be made in it.  Additionally, ensure that the
swsusp's userland interface won't be used while either pm_suspend_disk()
or software_resume() is being executed.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 kernel/power/disk.c |   37 ++---
 kernel/power/power.h|3 +++
 kernel/power/snapshot.c |8 
 kernel/power/user.c |   10 +-
 4 files changed, 38 insertions(+), 20 deletions(-)

Index: linux-2.6.21-rc4/kernel/power/disk.c
===
--- linux-2.6.21-rc4.orig/kernel/power/disk.c
+++ linux-2.6.21-rc4/kernel/power/disk.c
@@ -119,28 +119,33 @@ int pm_suspend_disk(void)
 {
int error;
 
+   /* The snapshot device should not be opened while we're running */
+   if (!atomic_add_unless(_device_available, -1, 0))
+   return -EBUSY;
+
+   /* Allocate memory management structures */
+   error = create_basic_memory_bitmaps();
+   if (error)
+   goto Exit;
+
error = prepare_processes();
if (error)
-   return error;
+   goto Finish;
 
if (pm_disk_mode == PM_DISK_TESTPROC) {
printk("swsusp debug: Waiting for 5 seconds.\n");
mdelay(5000);
goto Thaw;
}
-   /* Allocate memory management structures */
-   error = create_basic_memory_bitmaps();
-   if (error)
-   goto Thaw;
 
/* Free memory before shutting down devices. */
error = swsusp_shrink_memory();
if (error)
-   goto Finish;
+   goto Thaw;
 
error = platform_prepare();
if (error)
-   goto Finish;
+   goto Thaw;
 
suspend_console();
error = device_suspend(PMSG_FREEZE);
@@ -175,7 +180,7 @@ int pm_suspend_disk(void)
power_down(pm_disk_mode);
else {
swsusp_free();
-   goto Finish;
+   goto Thaw;
}
} else {
pr_debug("PM: Image restored successfully.\n");
@@ -188,10 +193,12 @@ int pm_suspend_disk(void)
platform_finish();
device_resume();
resume_console();
- Finish:
-   free_basic_memory_bitmaps();
  Thaw:
unprepare_processes();
+ Finish:
+   free_basic_memory_bitmaps();
+ Exit:
+   atomic_inc(_device_available);
return error;
 }
 
@@ -239,9 +246,15 @@ static int software_resume(void)
if (error)
goto Unlock;
 
+   /* The snapshot device should not be opened while we're running */
+   if (!atomic_add_unless(_device_available, -1, 0)) {
+   error = -EBUSY;
+   goto Unlock;
+   }
+
error = create_basic_memory_bitmaps();
if (error)
-   goto Unlock;
+   goto Finish;
 
pr_debug("PM: Preparing processes for restore.\n");
error = prepare_processes();
@@ -287,6 +300,8 @@ static int software_resume(void)
unprepare_processes();
  Done:
free_basic_memory_bitmaps();
+ Finish:
+   atomic_inc(_device_available);
/* For success case, the suspend path will release the lock */
  Unlock:
mutex_unlock(_mutex);
Index: linux-2.6.21-rc4/kernel/power/power.h
===
--- linux-2.6.21-rc4.orig/kernel/power/power.h
+++ linux-2.6.21-rc4/kernel/power/power.h
@@ -141,6 +141,9 @@ struct resume_swap_area {
 #define PMOPS_ENTER2
 #define PMOPS_FINISH   3
 
+/* If unset, the snapshot device cannot be open. */
+extern atomic_t snapshot_device_available;
+
 /**
  * The bitmap is used for tracing allocated swap pages
  *
Index: linux-2.6.21-rc4/kernel/power/snapshot.c
===
--- linux-2.6.21-rc4.orig/kernel/power/snapshot.c
+++ linux-2.6.21-rc4/kernel/power/snapshot.c
@@ -733,19 +733,19 @@ int create_basic_memory_bitmaps(void)
 
BUG_ON(forbidden_pages_map || free_pages_map);
 
-   bm1 = kzalloc(sizeof(struct memory_bitmap), GFP_ATOMIC);
+   bm1 = kzalloc(sizeof(struct memory_bitmap), GFP_KERNEL);
if (!bm1)
return -ENOMEM;
 
-   error = memory_bm_create(bm1, GFP_ATOMIC | __GFP_COLD, PG_ANY);
+   error = memory_bm_create(bm1, GFP_KERNEL, PG_ANY);
if (error)
goto Free_first_object;
 
-   bm2 = kzalloc(sizeof(struct memory_bitmap), GFP_ATOMIC);
+   bm2 = kzalloc(sizeof(struct memory_bitmap), GFP_KERNEL);
if (!bm2)
goto Free_first_bitmap;
 
-   error = memory_bm_create(bm2, GFP_ATOMIC | __GFP_COLD, PG_ANY);
+   error = memory_bm_create(bm2, GFP_KERNEL, PG_ANY);
if 

Re: [2/6] 2.6.21-rc2: known regressions

[Thomas Gleixner]

On Sat, 2007-03-17 at 23:41 +0200, Michael S. Tsirkin wrote:
> > > a quick ping: on your box that doesnt resume - if you can log in over 
> > > the network after resume (or somehow run shell commands), does 'date' 
> > > advance properly or not? (or do you not get that far to be able to 
> > > tell?)
> > > 
> > >   Ingo
> > 
> > I just retested - 'date' does not advance after resume for me.
> > This is with NO_HZ *not* set.
> > Sorry it took so long.
> 
> Update: just re-tested with 2.6.21-rc4, same behaviour: date
> does not advance after resume from ram.

Can you get a full dmesg from boot to resume out of the box ?

tglx


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

[PATCH -mm 0/2] swsusp: Use GFP_KERNEL for creating basic data structures

[Rafael J. Wysocki]

Hi,

The first of the following two patches fixes a bug in the swsusp's userland
interface and the second one makes swsusp use GFP_KERNEL allocations for
creating its basic memory bitmaps.

Greetings,
Rafael

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

[PATCH -mm 1/2] swsusp: Fix error paths in snapshot_open

[Rafael J. Wysocki]

From: Rafael J. Wysocki <[EMAIL PROTECTED]>

We forget to increase device_available if there's an error in snapshot_open(),
so the snapshot device cannot be open at all after snapshot_open() has returned
an error.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 kernel/power/user.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

Index: linux-2.6.21-rc4/kernel/power/user.c
===
--- linux-2.6.21-rc4.orig/kernel/power/user.c
+++ linux-2.6.21-rc4/kernel/power/user.c
@@ -49,12 +49,14 @@ static int snapshot_open(struct inode *i
if (!atomic_add_unless(_available, -1, 0))
return -EBUSY;
 
-   if ((filp->f_flags & O_ACCMODE) == O_RDWR)
+   if ((filp->f_flags & O_ACCMODE) == O_RDWR) {
+   atomic_inc(_available);
return -ENOSYS;
-
-   if(create_basic_memory_bitmaps())
+   }
+   if(create_basic_memory_bitmaps()) {
+   atomic_inc(_available);
return -ENOMEM;
-
+   }
nonseekable_open(inode, filp);
data = _state;
filp->private_data = data;

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

[PATCH] PCMCIA: Delete obsolete PCMCIA_IOCTL feature.

[Robert P. J. Day]

  Delete all code and configuration info related to the obsolete
PCMCIA_IOCTL config setting.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

  according to the feature removal Doc file, this feature was
scheduled for removal back in 2005.  compile-tested with "make
allyesconfig" on x86.


 Documentation/feature-removal-schedule.txt |   17
 drivers/pcmcia/Kconfig |   14
 drivers/pcmcia/Makefile|1
 drivers/pcmcia/ds.c|   12
 drivers/pcmcia/ds_internal.h   |7
 drivers/pcmcia/pcmcia_ioctl.c  |  806 ---
 drivers/pcmcia/rsrc_mgr.c  |   80 -
 include/pcmcia/ds.h|5
 include/pcmcia/ss.h|5
 9 files changed, 947 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index 0bc8b0b..04359b7 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -65,23 +65,6 @@ Who: Mauro Carvalho Chehab <[EMAIL PROTECTED]>

 ---

-What:  PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
-When:  November 2005
-Files: drivers/pcmcia/: pcmcia_ioctl.c
-Why:   With the 16-bit PCMCIA subsystem now behaving (almost) like a
-   normal hotpluggable bus, and with it using the default kernel
-   infrastructure (hotplug, driver core, sysfs) keeping the PCMCIA
-   control ioctl needed by cardmgr and cardctl from pcmcia-cs is
-   unnecessary, and makes further cleanups and integration of the
-   PCMCIA subsystem into the Linux kernel device driver model more
-   difficult. The features provided by cardmgr and cardctl are either
-   handled by the kernel itself now or are available in the new
-   pcmciautils package available at
-   http://kernel.org/pub/linux/utils/kernel/pcmcia/
-Who:   Dominik Brodowski <[EMAIL PROTECTED]>
-

-
 What:  remove EXPORT_SYMBOL(kernel_thread)
 When:  August 2006
 Files: arch/*/kernel/*_ksyms.c
diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index 35f8864..897f42a 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -69,20 +69,6 @@ config PCMCIA_LOAD_CIS

  If unsure, say Y.

-config PCMCIA_IOCTL
-   bool "PCMCIA control ioctl (obsolete)"
-   depends on PCMCIA
-   default y
-   help
- If you say Y here, the deprecated ioctl interface to the PCMCIA
- subsystem will be built. It is needed by cardmgr and cardctl
- (pcmcia-cs) to function properly.
-
- You should use the new pcmciautils package instead (see
-  for location and details).
-
- If unsure, say Y.
-
 config CARDBUS
bool "32-bit CardBus support"
depends on PCI
diff --git a/drivers/pcmcia/Makefile b/drivers/pcmcia/Makefile
index 4276965..74f7669 100644
--- a/drivers/pcmcia/Makefile
+++ b/drivers/pcmcia/Makefile
@@ -11,7 +11,6 @@ pcmcia_core-$(CONFIG_CARDBUS) += cardbus.o
 obj-$(CONFIG_PCCARD)   += pcmcia_core.o

 pcmcia-y   += ds.o pcmcia_resource.o
-pcmcia-$(CONFIG_PCMCIA_IOCTL)  += pcmcia_ioctl.o
 obj-$(CONFIG_PCMCIA)   += pcmcia.o

 obj-$(CONFIG_PCCARD_NONSTATIC) += rsrc_nonstatic.o
diff --git a/drivers/pcmcia/ds.c b/drivers/pcmcia/ds.c
index 18e111e..0b11d9b 100644
--- a/drivers/pcmcia/ds.c
+++ b/drivers/pcmcia/ds.c
@@ -928,15 +928,6 @@ static int pcmcia_bus_match(struct device * dev, struct 
device_driver * drv) {
struct pcmcia_driver * p_drv = to_pcmcia_drv(drv);
struct pcmcia_device_id *did = p_drv->id_table;

-#ifdef CONFIG_PCMCIA_IOCTL
-   /* matching by cardmgr */
-   if (p_dev->cardmgr == p_drv) {
-   ds_dbg(0, "cardmgr matched %s to %s\n", dev->bus_id,
-  drv->name);
-   return 1;
-   }
-#endif
-
while (did && did->match_flags) {
ds_dbg(3, "trying to match %s to %s\n", dev->bus_id,
   drv->name);
@@ -1346,9 +1337,6 @@ static int __devinit pcmcia_bus_add_socket(struct device 
*dev,
 */
msleep(250);

-#ifdef CONFIG_PCMCIA_IOCTL
-   init_waitqueue_head(>queue);
-#endif
INIT_LIST_HEAD(>devices_list);
INIT_WORK(>device_add, pcmcia_delayed_add_device);
memset(>pcmcia_state, 0, sizeof(u8));
diff --git a/drivers/pcmcia/ds_internal.h b/drivers/pcmcia/ds_internal.h
index 3a2b25e..af2b392 100644
--- a/drivers/pcmcia/ds_internal.h
+++ b/drivers/pcmcia/ds_internal.h
@@ -10,14 +10,7 @@ struct pcmcia_device * pcmcia_device_add(struct 
pcmcia_socket *s, unsigned int f

 extern int pcmcia_release_configuration(struct pcmcia_device *p_dev);

-#ifdef CONFIG_PCMCIA_IOCTL
-extern void __init pcmcia_setup_ioctl(void);
-extern void __exit pcmcia_cleanup_ioctl(void);

Re: [2/6] 2.6.21-rc2: known regressions

[Michael S. Tsirkin]

> Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: Re: [2/6] 2.6.21-rc2: known regressions
> 
> > Quoting Ingo Molnar <[EMAIL PROTECTED]>:
> > Subject: Re: [2/6] 2.6.21-rc2: known regressions
> > 
> > 
> > Michael,
> > 
> > * Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> > 
> > > > > 2. First disk access after resume takes a couple of minutes
> > > > >(seemed instant with 2.6.20) during this time no new messages show 
> > > > > on console
> > > > 
> > > > Yeah, there is some problem with SATA resume. It would be beautiful if 
> > > > the 
> > > > people who actually see this could narrow it down with bisection. "It 
> > > > works for me" is clearly the case for many people, but not all.
> > > 
> > > Problem is, there seem to be multiple problems some of which got fixed 
> > > between rc2 and rc3. With rc2 I didn't get as far as getting to 
> > > console.
> > 
> > a quick ping: on your box that doesnt resume - if you can log in over 
> > the network after resume (or somehow run shell commands), does 'date' 
> > advance properly or not? (or do you not get that far to be able to 
> > tell?)
> > 
> > Ingo
> 
> I just retested - 'date' does not advance after resume for me.
> This is with NO_HZ *not* set.
> Sorry it took so long.

Update: just re-tested with 2.6.21-rc4, same behaviour: date
does not advance after resume from ram.

-- 
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 2/13] signal/timer/event fds v6 - signalfd core ...

[Arnd Bergmann]

On Saturday 17 March 2007 22:35:08 Arnd Bergmann wrote:
> Also, what's the reasoning behind defining a new structure
> instead of just returning siginfo_t? Sure siginfo_t is ugly
> but it is a well-defined structure and users already deal
> with the problems it causes.

Ok, found the answer myself, fops->read() must not do the
conversion to compat_siginfo_t on a 64 bit kernel, that would
just be too ugly for words.

Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] clockevents: Fix suspend/resume to disk hangs

[Rafael J. Wysocki]

On Saturday, 17 March 2007 11:07, Thomas Meyer wrote:
> Thomas Gleixner schrieb:
> > I finally found a dual core box, which survives suspend/resume without
> > crashing in the middle of nowhere. Sigh, I never figured out from the
> > code and the bug reports what's going on.
> >
> > The observed hangs are caused by a stale state transition of the clock
> > event devices, which keeps the RCU synchronization away from completion,
> > when the non boot CPU is brought back up.
> >
> > The suspend/resume in oneshot mode needs the similar care as the
> > periodic mode during suspend to RAM. My assumption that the state
> > transitions during the different shutdown/bringups of s2disk would go
> > through the periodic boot phase and then switch over to highres resp.
> > nohz mode were simply wrong.
> >
> > Add the appropriate suspend / resume handling for the non periodic
> > modes.
> >
> > Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
> >   
> 
> Excellent work. Now suspend to disk is working again. But:
> 
> 1.) The quirk added in commit a417a21e10831bca695b4ba9c74f4ddf5a95ac06
> for the appletouch driver doesn't seem to work after resume.
> 
> 2.) The first suspend to disk works with no problems, but the second
> suspend to disk in a row results in an oops:
>  ->resume_device ->
> pci_device_resume->ata_host_resume->ahci_pci_device_resume->ata_pci_device_do_resume->pci_restore_state

Can you please see if this problem is already in the Adrian's list of known
regressions?

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

Re: SATA problems in 2.6.20.3

[Robert Hancock]

Christian wrote:
I'm seeing the same here since a few days. Before it worked great (even with 
NCQ). I've been getting those messages since 2.6.21-rc3-mm1 and with the 
latest Ubuntu feisty kernel (2.6.20-11-generic #2 SMP Thu Mar 15 03:43:56 UTC 
2007 x86_64 GNU/Linux)


System is Athlon64 X2, Nforce4, 3x Samsung SATA II NCQ discs.


Can you try 2.6.21-rc4? There was a change that went in between rc3 and 
rc4 to revert a previous change which seemed to be problematic.


As far as 2.6.20, I'm somewhat tempted to submit this patch to -stable:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5e5c74a5e11d1e2a99d03132cc6c4455016db6c2

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

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

Re: [patch 6/13] signal/timer/event fds v6 - timerfd core ...

[Arnd Bergmann]

On Friday 16 March 2007 01:22:15 Davide Libenzi wrote:
> This patch introduces a new system call for timers events delivered
> though file descriptors. This allows timer event to be used with
> standard POSIX poll(2), select(2) and read(2). As a consequence of
> supporting the Linux f_op->poll subsystem, they can be used with
> epoll(2) too.

Half of my comments about signalfd also apply to the code in here.

Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/13] signal/timer/event fds v6 - signalfd core ...

[Arnd Bergmann]

On Friday 16 March 2007 01:22:15 Davide Libenzi wrote:

> +
> +static struct sighand_struct *signalfd_get_sighand(struct signalfd_ctx
> *ctx, +  unsigned long 
> *flags);
> +static void signalfd_put_sighand(struct signalfd_ctx *ctx,
> +  struct sighand_struct *sighand,
> +  unsigned long *flags);
> +static void signalfd_cleanup(struct signalfd_ctx *ctx);
> +static int signalfd_close(struct inode *inode, struct file *file);
> +static unsigned int signalfd_poll(struct file *file, poll_table *wait);
> +static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,
> +  siginfo_t const *kinfo);
> +static ssize_t signalfd_read(struct file *file, char __user *buf, size_t
> count, +   loff_t *ppos);
> +

see my comment about forward declarations in the previous mail

> +asmlinkage long sys_signalfd(int ufd, sigset_t __user *user_mask, size_t
> sizemask) +{
> + int error;
> + unsigned long flags;
> + sigset_t sigmask;
> + struct signalfd_ctx *ctx;
> + struct sighand_struct *sighand;
> + struct file *file;
> + struct inode *inode;
> +
> + error = -EINVAL;
> + if (sizemask != sizeof(sigset_t) ||
> + copy_from_user(, user_mask, sizeof(sigmask)))
> + goto err_exit;

sizeof(sigset_t) may be different for native and 32-bit compat code.
It would be good if you could handle sizemask==4 && sizeof(sigset_t)==8
in this code, so that there is no need for an extra compat_sys_signalfd
function.

> + if ((sighand = signalfd_get_sighand(ctx, )) != NULL) {
> + if (next_signal(>tsk->pending, >sigmask) > 0 ||
> + next_signal(>tsk->signal->shared_pending,
> + >sigmask) > 0)
> + events |= POLLIN;
> + signalfd_put_sighand(ctx, sighand, );
> + } else
> + events |= POLLIN;
> +
> + return events;
> +}

I never really understood the events mask, but other subsystems often
use (POLLIN | POLLRDNORM) instead of just POLLIN. Is there a reason
for not returning POLLRDNORM here?

> +static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,
> +  siginfo_t const *kinfo)
> +{
> + long err;
> +
> + err = __clear_user(uinfo, sizeof(*uinfo));
> +
> + /*
> +  * If you change siginfo_t structure, please be sure
> +  * this code is fixed accordingly.
> +  */
> + err |= __put_user(kinfo->si_signo, >signo);
> + err |= __put_user(kinfo->si_errno, >err);
> + err |= __put_user((short)kinfo->si_code, >code);
> + switch (kinfo->si_code & __SI_MASK) {
> + case __SI_KILL:
> + err |= __put_user(kinfo->si_pid, >pid);
> + err |= __put_user(kinfo->si_uid, >uid);
> + break;
> + case __SI_TIMER:
> +  err |= __put_user(kinfo->si_tid, >tid);
> +  err |= __put_user(kinfo->si_overrun, >overrun);
> +  err |= __put_user(kinfo->si_ptr, >svptr);
> + break;
> + case __SI_POLL:
> + err |= __put_user(kinfo->si_band, >band);
> + err |= __put_user(kinfo->si_fd, >fd);
> + break;
> + case __SI_FAULT:
> + err |= __put_user(kinfo->si_addr, >addr);
> +#ifdef __ARCH_SI_TRAPNO
> + err |= __put_user(kinfo->si_trapno, >trapno);
> +#endif
> + break;
> + case __SI_CHLD:
> + err |= __put_user(kinfo->si_pid, >pid);
> + err |= __put_user(kinfo->si_uid, >uid);
> + err |= __put_user(kinfo->si_status, >status);
> + err |= __put_user(kinfo->si_utime, >utime);
> + err |= __put_user(kinfo->si_stime, >stime);
> + break;
> + case __SI_RT: /* This is not generated by the kernel as of now. */
> + case __SI_MESGQ: /* But this is */
> + err |= __put_user(kinfo->si_pid, >pid);
> + err |= __put_user(kinfo->si_uid, >uid);
> + err |= __put_user(kinfo->si_ptr, >svptr);
> + break;
> + default: /* this is just in case for now ... */
> + err |= __put_user(kinfo->si_pid, >pid);
> + err |= __put_user(kinfo->si_uid, >uid);
> + break;
> + }
> +
> + return err ? -EFAULT: sizeof(*uinfo);
> +}

Doing it this way looks rather inefficient to me. I think it's
better to just prepare the signalfd_siginfo on the stack and
do a single copy_to_user.

Also, what's the reasoning behind defining a new structure
instead of just returning siginfo_t? Sure siginfo_t is ugly
but it is a well-defined structure and users already deal
with the problems it causes.

> +static void __exit signalfd_exit(void)
> +{
> + kmem_cache_destroy(signalfd_ctx_cachep);
> +}
> +
> +module_init(signalfd_init);
> +module_exit(signalfd_exit);
> +
> +MODULE_LICENSE("GPL");

Since this file defines a syscall, it can't 

Re: [PATCH 1/2] scc_pata: dependency fix

[Bartlomiej Zolnierkiewicz]

On Friday 16 March 2007, Akira Iguchi wrote:
> This patch fixes:
> * the dependency of scc_pata on BLK_DEV_IDEDMA_PCI
> * incorrect link to ide-core
> * move scc_pata from ide/ppc to ide/pci
> 
> Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
> Signed-off-by: Akira Iguchi <[EMAIL PROTECTED]>

I applied both patches after:

* manually fixing the reject in drivers/ide/Kconfig
  (because Al's "IDE=y" fix has already been applied)

* merging patch #1 and #2 into a single one
  (otherwise patch #1 alone breaks kernel build)

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

Re: is RSDL an "unfair" scheduler too?

[Avi Kivity]

Ingo Molnar wrote:

* Con Kolivas <[EMAIL PROTECTED]> wrote:

  
Despite the claims to the contrary, RSDL does not have _less_ 
heuristics, it does not have _any_. It's purely entitlement based.



RSDL still has heuristics very much, but this time it's hardcoded into 
the design! Let me demonstrate this via a simple experiment.



  

[...]

But it's easy to demonstrate this under RSDL: consider the following two 
scenarios, which implement precisely the same fundamental computing 
workload (everything running on the same, default nice 0 level):


1) a single task runs almost all the time and sleeps about 1 msec every
   100 msecs.

   [ run "while N=1; do N=1; done &" under bash to create such a 
 workload. ]


2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1
   msec and passes the 'token' around to the next task in the ring. (in
   essence every task will sleep 9900 msecs before getting another run)


Workload #1 uses 100% of CPU time. Workload #2 uses 99% of CPU time. 
They both do in essence the same thing.


if RSDL had no heuristics at all then if i mixed #1 with #2, both 
workloads would get roughly 50%/50% of the CPU, right? (as happens if i 
mix #1 with #1 - both CPU-intense workloads get half of the CPU)
  


Well, the heuristic here is that process == job.  I'm not sure heuristic 
is the right name for it, but it does point out a deficieny.


A cpu-bound process with many threads will overwhelm a cpu-bound single 
threaded threaded process.


A job with many processes will overwhelm a job with a single process.

A user with many jobs can starve a user with a single job.

I don't think the problem here is heuristics, rather that the 
scheduler's manages cpu quotas at the task level rather than at the user 
visible level.  If scheduling were managed at all three hierarchies I 
mentioned ('job' is a bit artificial, but process and user are not) then:


- if N users are contending for the cpu on a multiuser machine, each 
should get just 1/N of available cpu power.  As it is, a user can run a 
few of your #1 workloads (or a make -j 20) and slow every other user down
- your example would work perfectly (if we can communicate to the kernel 
what a job is)

- multi-threaded processes would not get an unfair advantage

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/13] signal/timer/event fds v6 - anonymous inode source ...

[Arnd Bergmann]

On Friday 16 March 2007 01:22:15 Davide Libenzi wrote:

> +
> +static int ainofs_delete_dentry(struct dentry *dentry);
> +static struct inode *aino_getinode(void);
> +static struct inode *aino_mkinode(void);
> +static int ainofs_get_sb(struct file_system_type *fs_type, int flags,
> +  const char *dev_name, void *data, struct vfsmount 
> *mnt);
> +

In general, it would be good if you could just reorder your functions
so that you don't need any forward declarations like these. It makes
reviewing from bottom to top a little easier and it becomes obvious
that there are no recursions in the code.

> +static struct vfsmount *aino_mnt __read_mostly;
> +static struct inode *aino_inode;
> +static struct file_operations aino_fops = { };

Iirc, file_operations should be const.

> +int aino_getfd(int *pfd, struct inode **pinode, struct file **pfile,
> +char const *name, const struct file_operations *fops, void *priv)
> +{

Since this is meant to be a generic interface that can be used
from other subsystems, a kerneldoc style comment would be nice

> +static int __init aino_init(void)
> +{
> +
> + if (register_filesystem(_fs_type))
> + goto epanic;
> +
> + aino_mnt = kern_mount(_fs_type);
> + if (IS_ERR(aino_mnt))
> + goto epanic;
> +
> + aino_inode = aino_mkinode();
> + if (IS_ERR(aino_inode))
> + goto epanic;
> +
> + return 0;
> +
> +epanic:
> + panic("aino_init() failed\n");
> +}

panic() is a little harsh from a loadable module. If you mean
the aino support to be used as a module, this should probably
just return an error.

> +static void __exit aino_exit(void)
> +{
> + iput(aino_inode);
> + unregister_filesystem(_fs_type);
> + mntput(aino_mnt);
> +}

but since the Makefile always has it as built-in, maybe you should
instead just kill the exit function and use fs_initcall instead
of init_module().

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

Re: RSDL v0.31

[Al Boldi]

Mike Galbraith wrote:
> On Sat, 2007-03-17 at 20:48 +1100, Con Kolivas wrote:
> > The most frustrating part of a discussion of this nature on lkml is that
> > earlier information in a thread seems to be long forgotten after a few
> > days and all that is left is the one reporter having a problem.
>
> One?  I'm not the only person who reported regression.

Mike, I'm not saying RSDL is perfect, but v0.31 is by far better than 
mainline.  Try this easy test:

startx with the vesa driver
run reflect from the mesa5.0-demos
load 5 cpu-hogs
start moving the mouse

On my desktop, mainline completely breaks down, and no nicing may rescue.

On RSDL, even without nicing, the desktop is at least useable.

What we need is constructive criticism to improve the situation, either with 
mainline or with RSDL.  And for now RSDL is better.


Thanks!

--
Al

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

MPT Fusion LSI22320 , Domain validation loops .

[Mr. James W. Laferriere]

	Hello All ,  I am have been having this problem since I purchased the 
controller and after changing out the disks I thought were the problem .

I am still getting the continous :

mptscsih: ioc1: attempting task abort! (sc=f7a64500)
scsi 3:0:4:0:
command: Inquiry: 12 00 00 00 60 00
mptbase: Initiating ioc1 recovery
mptscsih: ioc1: task abort: SUCCESS (sc=f7a64500)
 target3:0:4: Domain Validation detected failure, dropping back
 target3:0:4: Domain Validation skipping write tests
 target3:0:4: Ending Domain Validation
 target3:0:4: asynchronous
 target3:0:5: Beginning Domain Validation
mptscsih: ioc0: attempting target reset! (sc=f7a64380)

	The acutual device id's change and the driver continously resets the 
busses & starts all over .


	The disks are in a HP DS-SL13R-BA 4354R 14drive ultra3 racKmount cabinet 
w/ dualbus & dualps ,  Which seems to present a ID6 ,  That does not show up in 
any of the bus scans .


	Now I have previously had the same cabinet with 18gb disks which had the 
same problem with this controller .  BUT I also have a LSI Logic / Symbios 
Logic 53c1010 66MHz Ultra3 dual SCSI bus Adapter which works flawlessly with the 
18gb disks in this very same cabinet .
	The cables for connecting the adapter(s) to tha cabinet are less than 24 
inches in length .


	Would anyone please shed some light on what it is I am doing wrong or 
need to do or ?  Too have this controller recognise these disk drives in 
this cabinet .


Here is the WHOLE enchalada .  Too big to put on the list so I posted them to 
my webpage .

http://www.baby-dragons.com/linux-2.6.20.2a.config
http://www.baby-dragons.com/filesrv1b-MPTFusion-problem.log

Tia ,  JimL
--
+-+
| James   W.   Laferriere | System   Techniques | Give me VMS |
| NetworkEngineer | 663  Beaumont  Blvd |  Give me Linux  |
| [EMAIL PROTECTED] | Pacifica, CA. 94044 |   only  on  AXP |
+-+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

whatever happened with "CONFIG_FORCED_INLINING"?

[Robert P. J. Day]

  a while back, i submitted a patch to remove the config option of
FORCED_INLINING, since it was allegedly scheduled for removal in june
of last year.  (it's still listed in
Documentation/feature-removal-schedule.txt as being ready for removal
in june, 2006.)

  but, IIRC, that inspired some discussion as to whether it was ready
for removal.  was there any resolution on that?  just curious.

rday

-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] CRIS: check for memory allocation

[Cyrill Gorcunov]

This patch adds checking for allocated memory. Indents
and spaces are added to be familiar with the kernel
coding style.

Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>

---

 arch/cris/kernel/profile.c |   81 ++--
 1 files changed, 48 insertions(+), 33 deletions(-)

diff --git a/arch/cris/kernel/profile.c b/arch/cris/kernel/profile.c
index 4cfcae6..aad0a9e 100644
--- a/arch/cris/kernel/profile.c
+++ b/arch/cris/kernel/profile.c
@@ -15,39 +15,47 @@ static int prof_running = 0;
 void
 cris_profile_sample(struct pt_regs* regs)
 {
-  if (!prof_running)
-return;
-  if (user_mode(regs))
-*(unsigned int*)sample_buffer_pos = current->pid;
-  else
-*(unsigned int*)sample_buffer_pos = 0;
-  *(unsigned int*)(sample_buffer_pos + 4) = instruction_pointer(regs);
-  sample_buffer_pos += 8;
-  if (sample_buffer_pos == sample_buffer + SAMPLE_BUFFER_SIZE)
-sample_buffer_pos = sample_buffer;
+   if (!prof_running)
+   return;
+
+   if (user_mode(regs))
+   *(unsigned int*)sample_buffer_pos = current->pid;
+   else
+   *(unsigned int*)sample_buffer_pos = 0;
+
+   *(unsigned int*)(sample_buffer_pos + 4) = instruction_pointer(regs);
+   sample_buffer_pos += 8;
+
+   if (sample_buffer_pos == sample_buffer + SAMPLE_BUFFER_SIZE)
+   sample_buffer_pos = sample_buffer;
 }
 
 static ssize_t
-read_cris_profile(struct file *file, char __user *buf, size_t count, loff_t 
*ppos)
+read_cris_profile(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
 {
-  unsigned long p = *ppos;
-  if (p > SAMPLE_BUFFER_SIZE)
-return 0;
-  if (p + count > SAMPLE_BUFFER_SIZE)
-count = SAMPLE_BUFFER_SIZE - p;
-  if (copy_to_user(buf, sample_buffer + p,count))
+   unsigned long p = *ppos;
+
+   if (p > SAMPLE_BUFFER_SIZE)
+   return 0;
+
+   if (p + count > SAMPLE_BUFFER_SIZE)
+   count = SAMPLE_BUFFER_SIZE - p;
+   if (copy_to_user(buf, sample_buffer + p,count))
return -EFAULT;
-  memset(sample_buffer + p, 0, count);
-  *ppos += count;
-  return count;
+
+   memset(sample_buffer + p, 0, count);
+   *ppos += count;
+
+   return count;
 }
 
 static ssize_t
 write_cris_profile(struct file *file, const char __user *buf,
-  size_t count, loff_t *ppos)
+  size_t count, loff_t *ppos)
 {
-  sample_buffer_pos = sample_buffer;
-  memset(sample_buffer, 0, SAMPLE_BUFFER_SIZE);
+   sample_buffer_pos = sample_buffer;
+   memset(sample_buffer, 0, SAMPLE_BUFFER_SIZE);
 }
 
 static const struct file_operations cris_proc_profile_operations = {
@@ -58,16 +66,23 @@ static const struct file_operations 
cris_proc_profile_operations = {
 static int
 __init init_cris_profile(void)
 {
-  struct proc_dir_entry *entry;
-  sample_buffer = kmalloc(SAMPLE_BUFFER_SIZE, GFP_KERNEL);
-  sample_buffer_pos = sample_buffer;
-  entry = create_proc_entry("system_profile", S_IWUSR | S_IRUGO, NULL);
-  if (entry) {
-entry->proc_fops = _proc_profile_operations;
-entry->size = SAMPLE_BUFFER_SIZE;
-  }
-  prof_running = 1;
-  return 0;
+   struct proc_dir_entry *entry;
+
+   sample_buffer = kmalloc(SAMPLE_BUFFER_SIZE, GFP_KERNEL);
+   if (!sample_buffer) {
+   return -ENOMEM;
+   }
+
+   sample_buffer_pos = sample_buffer;
+
+   entry = create_proc_entry("system_profile", S_IWUSR | S_IRUGO, NULL);
+   if (entry) {
+   entry->proc_fops = _proc_profile_operations;
+   entry->size = SAMPLE_BUFFER_SIZE;
+   }
+   prof_running = 1;
+
+   return 0;
 }
 
 __initcall(init_cris_profile);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [git patches] libata fixes

[Paul Rolland]

Hello,

> The kernel says that NCQ is turned off due to excessive 
> errors.  If your
> HSM violation is intermittent, it might not trigger tho.

I've just grep'ed thru all my messages, and I can't find anything 
stating that NCQ is being turned off...

Paul 

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

Re: Porting V4L2 drivers to 2.6.20

[Mauro Carvalho Chehab]

Em Ter, 2007-03-13 às 11:08 +0100, Laurent Pinchart escreveu:
> > Hey,
> >  am porting V4L2 drivers from 2.6.13 to 2.6.20.
> >
> >  The driver is using a  structure 'video_device' which exists in
> > include/linux/videodev.h.
> >
> >  However, The linux kernel in 2.6.20 doesnot have that structure?.
> >
> >   Has the architecture changed between 2.6.13 to 2.6.20 for V4L2?.
> 
> The structure has been moved to include/media/v4l2-dev.h

Yes.

You should notice that, if you want to send those drivers to kernel
mainstream, they should also be ported to V4L2 API (since V4L1 API is
obsolete). So, you shouldn't include linux/videodev.h, but, instead,
linux/videodev2.h for v4l2 API (and v4l2-dev.h for the internal V4L2
structures). Also, please c/c me on v4l kernel patches submission, since
I'm the V4L maintainer.

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

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

Re: [git patches] libata fixes

[Tejun Heo]

Paul Rolland wrote:
>> If you leave it alone, does libata turn off NCQ and boot continues?
> 
> boot continues, but I can't tell anything about libata turning of NCQ...
> I've had a bunch of them at some while while compiling some kernel, so it
> was quite some time after booting.
> 
> Is there a message I can check for that would indicate NCQ being turned
> off ?

The kernel says that NCQ is turned off due to excessive errors.  If your
HSM violation is intermittent, it might not trigger tho.

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

Re: [git patches] libata fixes

[Alan Cox]

> > >  
> > > 
> > > Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>
> > 
> > NAK - but add the firmware to the match and you can have an Ack 8)
> 
> Second try, compiled _and_ boot tested, of course.
> 
> dmesg says :
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133
> ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)
> ata1.00: configured for UDMA/133
> 
> --- linux-2.6.21-rc4/drivers/ata/libata-core.c  2007-03-17 19:47:49.0
> +0100
> +++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c   2007-03-17
> 20:24:01.0 +0100
> @@ -3359,6 +3359,8 @@
>  { "WDC WD740ADFD-00",   NULL,  ATA_HORKAGE_NONCQ },
> /* http://thread.gmane.org/gmane.linux.ide/14907 */
> { "FUJITSU MHT2060BH",  NULL,   ATA_HORKAGE_NONCQ },
> +   /* NCQ is broken */
> +   { "Maxtor 6L250S0", "BANC1G10", ATA_HORKAGE_NONCQ }, 
>  
> /* Devices with NCQ limits */
> 
> Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>

Acked-by: Alan Cox <[EMAIL PROTECTED]>

--
  'YKYHBRTFDriverSTLW: you catch yourself saying "enough horrors for today"
and picking Lovecraft to relax...' -- Al Viro
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [git patches] libata fixes

[Paul Rolland]

> If you leave it alone, does libata turn off NCQ and boot continues?

boot continues, but I can't tell anything about libata turning of NCQ...
I've had a bunch of them at some while while compiling some kernel, so it
was quite some time after booting.

Is there a message I can check for that would indicate NCQ being turned
off ?

Regards,
Paul

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

Re: [git patches] libata fixes

[Tejun Heo]

Paul Rolland wrote:
> Hello,
> 
> I'm preparing to attach a disk. 
> In the meantime, I've rebuild a 2.6.21-rc4, and got that while booting :
> ...
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133
> ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (depth 31/32)
> ata1.00: configured for UDMA/133
> ...
> Adding 2096436k swap on /dev/sde5.  Priority:-1 extents:1 across:2096436k
> Adding 4192956k swap on /dev/sda3.  Priority:-2 extents:1 across:4192956k
> ata1.00: exception Emask 0x2 SAct 0x7fc3 SErr 0x0 action 0x2 frozen
> ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x7fc3
> FIS=004040a1:0020)
> ata1.00: cmd 60/01:00:52:eb:ff/00:00:09:00:00/40 tag 0 cdb 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)

If you leave it alone, does libata turn off NCQ and boot continues?

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

RE: [git patches] libata fixes

[Paul Rolland]

Hello,

> Please match the firmware version as well for the Maxtor drives
Ok.
 
> > --- linux-2.6.21-rc4/drivers/ata/libata-core.c  2007-03-17 
> 19:29:45.0
> > +0100
> > +++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c   2007-03-17
> > 19:37:28.0 +0100
> > @@ -3359,6 +3359,8 @@
> >  { "WDC WD740ADFD-00",   NULL,  ATA_HORKAGE_NONCQ },
> > /* http://thread.gmane.org/gmane.linux.ide/14907 */
> > { "FUJITSU MHT2060BH",  NULL,   ATA_HORKAGE_NONCQ },
> > +   /* NCQ is broken */
> > +   { "Maxtor 6L250S0", NULL,   
> ATA_HORKAGE_NONCQ }, 
> >  
> > /* Devices with NCQ limits */
> >  
> > 
> > Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>
> 
> NAK - but add the firmware to the match and you can have an Ack 8)

Second try, compiled _and_ boot tested, of course.

dmesg says :
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133
ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)
ata1.00: configured for UDMA/133

--- linux-2.6.21-rc4/drivers/ata/libata-core.c  2007-03-17 19:47:49.0
+0100
+++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c   2007-03-17
20:24:01.0 +0100
@@ -3359,6 +3359,8 @@
 { "WDC WD740ADFD-00",   NULL,  ATA_HORKAGE_NONCQ },
/* http://thread.gmane.org/gmane.linux.ide/14907 */
{ "FUJITSU MHT2060BH",  NULL,   ATA_HORKAGE_NONCQ },
+   /* NCQ is broken */
+   { "Maxtor 6L250S0", "BANC1G10", ATA_HORKAGE_NONCQ }, 
 
/* Devices with NCQ limits */

Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>

Regards,
Paul

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

Re: [PATCH] kthread_should_stop_check_freeze (was: Re: [PATCH -mm 3/7] Freezer: Remove PF_NOFREEZE from rcutorture thread)

[Paul E. McKenney]

On Mon, Mar 12, 2007 at 11:39:06PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > Looks good to me!  The other kthread_should_stop() calls in
> > > > rcutorture.c should also become
> > > > kthread_should_top_check_freeze().
> 
> > > Why is it useful?
> > 
> > Because we want to avoid repeating
> > 
> > while (!kthread_should_stop()) {
> > try_to_freeze();
> > ...
> > }
> > 
> > in many places?
> 
> Do not do it, then. Confusion it causes is not worth saving one line
> of code. 
> 
> You do less typing, but the resulting code is _less_ readable, not
> more.
> 
> NAK.

Another problem is people doing "kthread_should_stop()" and forgetting
about freezing.  Then we continue ending up with situations where we are
intermittently unable to freeze.  In the spirit of "Rusty Scale" interface
design, how do we make it difficult for people to misuse this interface?

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

Re: [git patches] libata fixes

[Alan Cox]

On Sat, Mar 17, 2007 at 07:47:01PM +0100, Paul Rolland wrote:
> Hello,
> 
> Here is a patch to avoid these pesky messages for the Maxtor disk :
> 

Please match the firmware version as well for the Maxtor drives

> --- linux-2.6.21-rc4/drivers/ata/libata-core.c  2007-03-17 19:29:45.0
> +0100
> +++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c   2007-03-17
> 19:37:28.0 +0100
> @@ -3359,6 +3359,8 @@
>  { "WDC WD740ADFD-00",   NULL,  ATA_HORKAGE_NONCQ },
> /* http://thread.gmane.org/gmane.linux.ide/14907 */
> { "FUJITSU MHT2060BH",  NULL,   ATA_HORKAGE_NONCQ },
> +   /* NCQ is broken */
> +   { "Maxtor 6L250S0", NULL,   ATA_HORKAGE_NONCQ }, 
>  
> /* Devices with NCQ limits */
>  
> 
> Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>

NAK - but add the firmware to the match and you can have an Ack 8)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 21-rc4] misc doc and kconfig typos

[Matt LaPlante]

Fix various typos in kernel docs and Kconfigs, 2.6.21-rc4.

Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]>
--

diff -ru a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
--- a/arch/arm/mach-at91/Kconfig2007-03-17 13:20:34.0 -0400
+++ b/arch/arm/mach-at91/Kconfig2007-03-17 13:37:28.0 -0400
@@ -100,7 +100,7 @@
depends on ARCH_AT91SAM9260
help
  Select this if you are using Atmel's AT91SAM9XE System-on-Chip.
- They are basicaly AT91SAM9260s with various sizes of embedded Flash.
+ They are basically AT91SAM9260s with various sizes of embedded Flash.
 
 comment "AT91SAM9260 / AT91SAM9XE Board Type"
 
diff -ru a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
--- a/arch/arm/mach-omap1/Kconfig   2007-02-04 13:44:54.0 -0500
+++ b/arch/arm/mach-omap1/Kconfig   2007-03-17 13:45:35.0 -0400
@@ -84,7 +84,7 @@
   Support for the Palm Tungsten E PDA. Currently only the LCD panel
   is supported. To boot the kernel, you'll need a PalmOS compatible
   bootloader; check out http://palmtelinux.sourceforge.net for more
-  informations.
+  information.
   Say Y here if you have such a PDA, say NO otherwise.
 
 config MACH_NOKIA770
Only in b/arch/cris/arch-v10/drivers: eeprom.c.rej
diff -ru a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
--- a/arch/powerpc/Kconfig  2007-03-17 13:20:35.0 -0400
+++ b/arch/powerpc/Kconfig  2007-03-17 13:47:58.0 -0400
@@ -625,7 +625,7 @@
depends PPC_IBM_CELL_BLADE
help
  PMI (Platform Management Interrupt) is a way to
- communicate with the BMC (Baseboard Mangement Controller).
+ communicate with the BMC (Baseboard Management Controller).
  It is used in some IBM Cell blades.
default m
 
diff -ru a/Documentation/block/ioprio.txt b/Documentation/block/ioprio.txt
--- a/Documentation/block/ioprio.txt2007-02-04 13:44:54.0 -0500
+++ b/Documentation/block/ioprio.txt2007-03-17 14:21:29.0 -0400
@@ -6,10 +6,10 @@
 -
 
 With the introduction of cfq v3 (aka cfq-ts or time sliced cfq), basic io
-priorities is supported for reads on files. This enables users to io nice
-processes or process groups, similar to what has been possible to cpu
-scheduling for ages. This document mainly details the current possibilites
-with cfq, other io schedulers do not support io priorities so far.
+priorities are supported for reads on files.  This enables users to io nice
+processes or process groups, similar to what has been possible with cpu
+scheduling for ages.  This document mainly details the current possibilities
+with cfq; other io schedulers do not support io priorities thus far.
 
 Scheduling classes
 --
diff -ru a/Documentation/cpu-freq/cpufreq-stats.txt 
b/Documentation/cpu-freq/cpufreq-stats.txt
--- a/Documentation/cpu-freq/cpufreq-stats.txt  2007-02-04 13:44:54.0 
-0500
+++ b/Documentation/cpu-freq/cpufreq-stats.txt  2007-03-17 13:33:57.0 
-0400
@@ -17,7 +17,7 @@
 
 1. Introduction
 
-cpufreq-stats is a driver that provices CPU frequency statistics for each CPU.
+cpufreq-stats is a driver that provides CPU frequency statistics for each CPU.
 These statistics are provided in /sysfs as a bunch of read_only interfaces. 
This
 interface (when configured) will appear in a separate directory under cpufreq
 in /sysfs (/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU.
diff -ru a/Documentation/driver-model/platform.txt 
b/Documentation/driver-model/platform.txt
--- a/Documentation/driver-model/platform.txt   2007-03-17 13:20:34.0 
-0400
+++ b/Documentation/driver-model/platform.txt   2007-03-17 13:33:57.0 
-0400
@@ -16,7 +16,7 @@
 into system-on-chip platforms.  What they usually have in common
 is direct addressing from a CPU bus.  Rarely, a platform_device will
 be connected through a segment of some other kind of bus; but its
-registers will still be directly addressible.
+registers will still be directly addressable.
 
 Platform devices are given a name, used in driver binding, and a
 list of resources such as addresses and IRQs.
diff -ru a/Documentation/fb/imacfb.txt b/Documentation/fb/imacfb.txt
--- a/Documentation/fb/imacfb.txt   2007-02-04 13:44:54.0 -0500
+++ b/Documentation/fb/imacfb.txt   2007-03-17 13:33:57.0 -0400
@@ -17,7 +17,7 @@
 ==
 
 Imacfb does not have any kind of autodetection of your machine.
-You have to add the fillowing kernel parameters in your elilo.conf:
+You have to add the following kernel parameters in your elilo.conf:
Macbook :
video=imacfb:macbook
MacMini :
diff -ru a/Documentation/filesystems/hpfs.txt 
b/Documentation/filesystems/hpfs.txt
--- a/Documentation/filesystems/hpfs.txt2007-02-04 13:44:54.0 
-0500
+++ b/Documentation/filesystems/hpfs.txt2007-03-17 13:33:57.0 
-0400

Re: + remove-the-likelypid-check-in-copy_process.patch added to -mm tree

[Eric W. Biederman]

Oleg Nesterov <[EMAIL PROTECTED]> writes:

> Yes! I meant we should change INIT_SIGNALS(), currently it does
>
>   #define INIT_SIGNALS(sig) {
>   ...
>   .pgrp   = 1,
>   { .__session  = 1},
>
> and this confuses (I think) set_special_pids(1,1) above. Because
> __set_special_pids() still deals with pid_t, not "struct pid".
>
> Unless I missed something, we should kill these 2 initializations
> above.

Got it.  I agree we should initialize those fields to 0.

Sukadev you want to get that?

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

RE: [git patches] libata fixes

[Paul Rolland]

Hello,

Here is a patch to avoid these pesky messages for the Maxtor disk :

--- linux-2.6.21-rc4/drivers/ata/libata-core.c  2007-03-17 19:29:45.0
+0100
+++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c   2007-03-17
19:37:28.0 +0100
@@ -3359,6 +3359,8 @@
 { "WDC WD740ADFD-00",   NULL,  ATA_HORKAGE_NONCQ },
/* http://thread.gmane.org/gmane.linux.ide/14907 */
{ "FUJITSU MHT2060BH",  NULL,   ATA_HORKAGE_NONCQ },
+   /* NCQ is broken */
+   { "Maxtor 6L250S0", NULL,   ATA_HORKAGE_NONCQ }, 
 
/* Devices with NCQ limits */
 

Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>

With this applied, my machine has stopped all those painful messages.
dmesg now says :
[EMAIL PROTECTED]:/Kernels# dmesg | grep LBA
ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)
ata2.00: 640 sectors, multi 1: LBA 
ata3.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)

instead of NCQ (depth 31/32), but there doesn't seem to be any adverse
effects.

Regards,
Paul

Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator

--

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur 
"Some people dream of success... while others wake up and work hard at it" 

"I worry about my child and the Internet all the time, even though she's too 
young to have logged on yet. Here's what I worry about. I worry that 10 or 15 
years from now, she will come to me and say 'Daddy, where were you when they 
took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 
  

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Rolland
> Sent: Saturday, March 17, 2007 6:59 PM
> To: 'Tejun Heo'
> Cc: 'Linus Torvalds'; 'Jeff Garzik'; 'Alan Cox'; 'Andrew 
> Morton'; linux-ide@vger.kernel.org; 'LKML'; 'Eric D. Mudama'
> Subject: RE: [git patches] libata fixes
> 
> Hello,
> 
> I'm preparing to attach a disk. 
> In the meantime, I've rebuild a 2.6.21-rc4, and got that 
> while booting :
> ...
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133
> ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (depth 31/32)
> ata1.00: configured for UDMA/133
> ...
> Adding 2096436k swap on /dev/sde5.  Priority:-1 extents:1 
> across:2096436k
> Adding 4192956k swap on /dev/sda3.  Priority:-2 extents:1 
> across:4192956k
> ata1.00: exception Emask 0x2 SAct 0x7fc3 SErr 0x0 action 
> 0x2 frozen
> ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x7fc3
> FIS=004040a1:0020)
> ata1.00: cmd 60/01:00:52:eb:ff/00:00:09:00:00/40 tag 0 cdb 
> 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/40:08:53:eb:ff/00:00:09:00:00/40 tag 1 cdb 
> 0x0 data 32768 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/01:30:39:eb:ff/00:00:09:00:00/40 tag 6 cdb 
> 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/01:38:3a:eb:ff/00:00:09:00:00/40 tag 7 cdb 
> 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/01:40:3b:eb:ff/00:00:09:00:00/40 tag 8 cdb 
> 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/01:48:3c:eb:ff/00:00:09:00:00/40 tag 9 cdb 
> 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/01:50:3d:eb:ff/00:00:09:00:00/40 tag 10 cdb 
> 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/01:58:3e:eb:ff/00:00:09:00:00/40 tag 11 cdb 
> 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/01:60:3f:eb:ff/00:00:09:00:00/40 tag 12 cdb 
> 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/01:68:40:eb:ff/00:00:09:00:00/40 tag 13 cdb 
> 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/01:70:41:eb:ff/00:00:09:00:00/40 tag 14 cdb 
> 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/01:78:42:eb:ff/00:00:09:00:00/40 tag 15 cdb 
> 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/01:80:43:eb:ff/00:00:09:00:00/40 tag 16 cdb 
> 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/01:88:44:eb:ff/00:00:09:00:00/40 tag 17 cdb 
> 0x0 data 512 in
>  res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 
> (HSM violation)
> ata1.00: cmd 60/01:90:45:eb:ff/00:00:09:00:00/40 tag 18 cdb 
> 0x0 data 512 in
>  res 

Re: [ck] Re: RSDL v0.31

[Mike Galbraith]

On Sat, 2007-03-17 at 19:23 +0100, Kacper Wysocki wrote:

> And for Mark and others who are as confused as I was, this is the
> thread that Mike meant to reference:
> http://thread.gmane.org/gmane.linux.kernel/503455/focus=6614

Nope, with all the back and forth (and noise), I lost track of which
thread was which.  Thanks. 

-Mike

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

Re: [git patches] libata fixes

[Alan Cox]

On Sat, Mar 17, 2007 at 06:59:12PM +0100, Paul Rolland wrote:
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133

That drive isn't in our current block list for NCQ but some close
relatives are in the one I've compiled so far (7B250S0). If you add it to 
the blacklist it behave ?

Also what controller ?

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

Re: Bug in pci_restore_msi_state

[Thomas Meyer]

Pekka Enberg schrieb:
> On 3/17/07, Thomas Meyer <[EMAIL PROTECTED]> wrote:
>> Hello everybody.
>>
>> I get this bug after suspending to disk twice:
>>
>> http://m3y3r.de/bilder/Bug-pci_restore_msi_state.png
>>
>> This happens with current git head
>> cd05a1f818073a623455a58e756c5b419fc98db9.
>
> If you know a kernel that works, please consider doing git bisect:
>
> http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt
>
>
I don't think so, because suspend to disk began to work again with the
latest commit.

But it seems to have to do with dev->msi_enabled, that is enabled, but
the msi_attrib for this device is empty (pos is zero) in the function
__pci_restore_msi_state. irq=19 and msi_attrib=0 before the bug happens
(trying to accessing msi_attrib.pos).
But 19 is not an msi interrupt, isn't it?

   CPU0   CPU1
  0: 168998  0   IO-APIC-edge  timer
  9:   9056  0   IO-APIC-fasteoi   acpi
 16: 43  0   IO-APIC-fasteoi   uhci_hcd:usb5
 17:   8278  19996   IO-APIC-fasteoi   wifi0
 18:  11388  0   IO-APIC-fasteoi   libata, uhci_hcd:usb4
 19:  3  0   IO-APIC-fasteoi   uhci_hcd:usb3, ohci1394
 20: 115285  0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
 21:225  0   IO-APIC-fasteoi   HDA Intel
218:  14365  0   PCI-MSI-edge  libata
219:  1  0   PCI-MSI-edge  eth0
NMI:  0  0
LOC:  49119  88723
ERR:  0
MIS:  0

Shouldn't  the flag msi_enabled be set to zero in function
msi_remove_pci_irq_vectors?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Bias the location of pages freed for min_free_kbytes in the same MAX_ORDER_NR_PAGES blocks

[Mel Gorman]

Begorrah - patches from Irish people on Paddy's day, who would have though it.
Clearly, this patch is full of lucky charms.

On a more serious note, this patch appears to address the page allocation
problem reported by Mariusz Kozlowski.

Changelog since v1
o Select the number of blocks to mark MIGRATE_RESERVE intelligently
o Take bootmem into account when placing MIGRATE_RESERVE blocks

The standard buddy allocator always favours the smallest block of pages. The
effect of this is that the pages free to satisfy min_free_kbytes tends to be
preserved since boot time at the same location of memory ffor a very long time
and as a contiguous block. When an administrator sets the reserve at 16384 at
boot time, it tends to be the same MAX_ORDER blocks that remain free. This
allows the occasional high atomic allocation to succeed up until the point
the blocks are split. In practice, it is difficult to split these blocks
but when they do split, the benefit of having min_free_kbytes for contiguous
blocks disappears. Additionally, increasing min_free_kbytes once the system
has been running for some time has no guarantee of creating contiguous blocks.

On the other hand, CONFIG_PAGE_GROUP_BY_MOBILITY favours splitting large blocks
when there are no free pages of the appropriate type available. A side-effect
of this is that all blocks in memory tends to be used up and the contiguous
free blocks from boot time are not preserved like in the vanilla allocator.
This can cause a problem if a new caller is unwilling to reclaim or does
not reclaim for long enough.

A failure scenario was found for a wireless network device allocating order-1
atomic allocations but the allocations were not intense or frequent enough
for a whole block of pages to be preserved for MIGRATE_HIGHALLOC. This was
reproduced on a desktop by booting with mem=256mb, forcing the driver to
allocate at order-1, running a bittorrent client (downloading a debian ISO)
and building a kernel with -j2.

This patch addresses the problem on the desktop machine booted with mem=256mb.
It works by setting aside a reserve of MAX_ORDER_NR_PAGES blocks, the number
of which depends on the value of min_free_kbytes.  These blocks are only
fallen back to when there is no other free pages. Then the smallest possible
page is used just like the normal buddy allocator instead of the largest
possible page to preserve contiguous pages The pages in free lists in the
reserve blocks are never taken for another migrate type.  The results is
that even if min_free_kbytes is set to a low value, contiguous blocks will
be preserved in the MIGRATE_RESERVE blocks.

This works better than the vanilla allocator because if min_free_kbytes
is increased, a new reserve block will be chosen based on the location of
reclaimable pages and the block will free up as contiguous pages. In the
vanilla allocator, no effort is made to target a block of pages to free as
contiguous pages and min_free_kbytes pages are scattered randomly.

This effect has been observed on the test machine. min_free_kbytes
was set initially low but it was kept as a contiguous free block within
MIGRATE_RESERVE. min_free_kbytes was then set to a higher value and over a
period of time, the free blocks were within the reserve and coalescing. How
long it takes to free up depends on how quickly LRU is rotating. Amusingly,
this means that more activity will free the blocks faster.

This mechanism potentially replaces MIGRATE_HIGHALLOC as it may be more
effective than grouping contiguous free pages together. It all depends on
whether the number of active atomic high allocations exceeds min_free_kbytes or
not. If the number of active allocations exceeds min_free_kbytes, it's worth
it but maybe in that situation, min_free_kbytes should be set higher. Once
there are no more reports of allocation failures, a patch will be submitted
that backs out MIGRATE_HIGHALLOC and see if the reports stay missing.

Credit to Mariusz Kozlowski for discovering the problem, describing the
failure scenario and testing patches and scenarios.

Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
Acked-by: Andy Whitcroft <[EMAIL PROTECTED]>

 include/linux/mmzone.h  |4 -
 include/linux/pageblock-flags.h |2 
 mm/page_alloc.c |  139 +++-
 3 files changed, 115 insertions(+), 30 deletions(-)

---

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff 
linux-2.6.21-rc3-mm2-clean/include/linux/mmzone.h 
linux-2.6.21-rc3-mm2-blockreserve/include/linux/mmzone.h
--- linux-2.6.21-rc3-mm2-clean/include/linux/mmzone.h   2007-03-14 
15:47:09.0 +
+++ linux-2.6.21-rc3-mm2-blockreserve/include/linux/mmzone.h2007-03-15 
16:07:31.0 +
@@ -30,12 +30,14 @@
 #define MIGRATE_RECLAIMABLE   1
 #define MIGRATE_MOVABLE   2
 #define MIGRATE_HIGHATOMIC3
-#define MIGRATE_TYPES 4
+#define MIGRATE_RESERVE   4
+#define MIGRATE_TYPES 5
 #else
 #define MIGRATE_UNMOVABLE 0
 #define 

Re: [ck] Re: RSDL v0.31

[Kacper Wysocki]

On 3/17/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:

On Sat, 2007-03-17 at 13:03 -0400, Gene Heskett wrote:
> On Saturday 17 March 2007, Mike Galbraith wrote:
> [...]
> >Xorg is using 50% cpu because I'm asking it to.
>
> What advantage is that giving you?

It's a test scenario.  Read the thread please, I really don't want to
repeat myself endlessly.


I've been following "this thread" since Con's .31 announcement - and
the only reference to your test scenario that you've given is that
you're still "having trouble with x/gforce vs two niced encoders",
that you've added "some targeted unfairness", that Con's new scheduler
is "an utter failure" and something about beating it to a bloody pulp.

You haven't detailed what your test actually is or what it's trying to
acheive, nor provided anyone else with the means to reproduce it or
understand any of the behaviour you're seeing. Now if you've done that
in any other thread, consider referencing it instead of worrying about
"repeating yourself endlessly". Otherwise, you're making it pretty
clear that you're just trying to be difficult, rather than being
heard.

Remember, this thread is not only cross-posted, but also exists in a
high-volume mailing list where things aren't as easy to track as in
one's own head.

And for Mark and others who are as confused as I was, this is the
thread that Mike meant to reference:
http://thread.gmane.org/gmane.linux.kernel/503455/focus=6614

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

RE: [git patches] libata fixes

[Paul Rolland]

Hello,

I'm preparing to attach a disk. 
In the meantime, I've rebuild a 2.6.21-rc4, and got that while booting :
...
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133
ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
...
Adding 2096436k swap on /dev/sde5.  Priority:-1 extents:1 across:2096436k
Adding 4192956k swap on /dev/sda3.  Priority:-2 extents:1 across:4192956k
ata1.00: exception Emask 0x2 SAct 0x7fc3 SErr 0x0 action 0x2 frozen
ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x7fc3
FIS=004040a1:0020)
ata1.00: cmd 60/01:00:52:eb:ff/00:00:09:00:00/40 tag 0 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/40:08:53:eb:ff/00:00:09:00:00/40 tag 1 cdb 0x0 data 32768 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:30:39:eb:ff/00:00:09:00:00/40 tag 6 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:38:3a:eb:ff/00:00:09:00:00/40 tag 7 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:40:3b:eb:ff/00:00:09:00:00/40 tag 8 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:48:3c:eb:ff/00:00:09:00:00/40 tag 9 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:50:3d:eb:ff/00:00:09:00:00/40 tag 10 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:58:3e:eb:ff/00:00:09:00:00/40 tag 11 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:60:3f:eb:ff/00:00:09:00:00/40 tag 12 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:68:40:eb:ff/00:00:09:00:00/40 tag 13 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:70:41:eb:ff/00:00:09:00:00/40 tag 14 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:78:42:eb:ff/00:00:09:00:00/40 tag 15 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:80:43:eb:ff/00:00:09:00:00/40 tag 16 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:88:44:eb:ff/00:00:09:00:00/40 tag 17 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:90:45:eb:ff/00:00:09:00:00/40 tag 18 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:98:46:eb:ff/00:00:09:00:00/40 tag 19 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:a0:47:eb:ff/00:00:09:00:00/40 tag 20 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:a8:48:eb:ff/00:00:09:00:00/40 tag 21 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:b0:49:eb:ff/00:00:09:00:00/40 tag 22 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:b8:4a:eb:ff/00:00:09:00:00/40 tag 23 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:c0:4b:eb:ff/00:00:09:00:00/40 tag 24 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:c8:4c:eb:ff/00:00:09:00:00/40 tag 25 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:d0:4d:eb:ff/00:00:09:00:00/40 tag 26 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:d8:4e:eb:ff/00:00:09:00:00/40 tag 27 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:e0:4f:eb:ff/00:00:09:00:00/40 tag 28 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:e8:50:eb:ff/00:00:09:00:00/40 tag 29 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/01:f0:51:eb:ff/00:00:09:00:00/40 tag 30 cdb 0x0 data 512 in
 res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation)
ata1: soft resetting port

Kernel is a stock 2.6.21-rc4 I've just downloaded... I seem to remember
this could be NCQ-related, and my disk should have been blacklisted, 
but is this already in 2.6.21-rc4 ?

Regards,
Paul

Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and 

RE: [git patches] libata fixes

[Paul Rolland]

> > PS : I'd like to try 2.6.21-rc3, but it seems that this is 
> breaking my
> > config : disk naming is no more the same, and I end up with a panic
> > Warning: unable to open an initial console
> > though i've been compiling with the same .config I was 
> using for 2.6.21-rc2
> 
> Gaah. Can you get a log through serial console or netconsole 
> to see what changed?
> 

Sorry, I've had no time this week for that.
I've just switch to 2.6.21-rc4, and carefully restored config from 2.6.21-rc2,
and boot is Ok...

So, I must have done something bad when building 2.6.21-rc3, sorry for the
noise.

Regards,
Paul

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

Re: RSDL v0.31

[Mike Galbraith]

On Sat, 2007-03-17 at 13:03 -0400, Gene Heskett wrote:
> On Saturday 17 March 2007, Mike Galbraith wrote:
> [...]
> >Xorg is using 50% cpu because I'm asking it to.
> 
> What advantage is that giving you?

It's a test scenario.  Read the thread please, I really don't want to
repeat myself endlessly.

-Mike

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

RE: [ck] Re: is RSDL an "unfair" scheduler too?

[David Schwartz]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of jos poortvliet
> Sent: Saturday, March 17, 2007 5:24 AM
> To: [EMAIL PROTECTED]
> Cc: Con Kolivas; Ingo Molnar; Al Boldi; Mike Galbraith;
> linux-kernel@vger.kernel.org; Nicholas Miell; Linus Torvalds; Andrew
> Morton
> Subject: Re: [ck] Re: is RSDL an "unfair" scheduler too?
>
>
> Op Saturday 17 March 2007, schreef Con Kolivas:
> > On Saturday 17 March 2007 22:49, Ingo Molnar wrote:
> > > * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > > > Despite the claims to the contrary, RSDL does not have _less_
> > > > heuristics, it does not have _any_. It's purely entitlement based.
> > >
> > > RSDL still has heuristics very much, but this time it's hardcoded into
> > > the design! Let me demonstrate this via a simple experiment.
> > >
> > > in the vanilla scheduler, the heuristics are ontop of a fairly basic
> > > (and fast) scheduler, they are plain visible and thus 'optional'. In
> > > RSDL, the heuristics are still present but more hidden and more
> > > engrained into the design.
> > >
> > > But it's easy to demonstrate this under RSDL: consider the
> following two
> > > scenarios, which implement precisely the same fundamental computing
> > > workload (everything running on the same, default nice 0 level):
> > >
> > > 1) a single task runs almost all the time and sleeps about 1
> msec every
> > >100 msecs.
> > >
> > >[ run "while N=1; do N=1; done &" under bash to create such a
> > >  workload. ]
> > >
> > > 2) tasks are in a 'ring' where each runs for 100 msec, sleeps for 1
> > >msec and passes the 'token' around to the next task in the
> ring. (in
> > >essence every task will sleep 9900 msecs before getting
> another run)
> > >
> > >[ run http://redhat.com/~mingo/scheduler-patches/ring-test.c to
> > >  create this workload. If the 100 tasks default is too
> much for you
> > >  then you can run "./ring-test 10" - that will show
> similar effects.
> > >]

> Well, re-reading his post, he has a point - one WOULD expect each
> of these 2
> tasks to have an equal share of CPU, and if RSDL doesn't
> currently take this
> pipe-thing into account, it might need some fixing. call it
> heuristics or not
> (after all, how could one NOT say a scheduler uses heuristics of
> some kind?).

I can't get myself to expect that no matter how hard I try. The scheduler
is, by design, fair to *tasks*. So why would one expect two different
approaches that do the same thing, but with different numbers of tasks, to
each get the same amount of CPU if they compete with each other? One would
expect the approach that uses the most tasks to get more CPU.

DS


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