Re: [PATCH] [44/48] Suspend2 2.1.9.8 for 2.6.12: 620-userui.patch

[Nigel Cunningham]

Hi

On Mon, 2005-07-11 at 04:22, Pavel Machek wrote:
> On St 06-07-05 12:20:44, Nigel Cunningham wrote:
> > diff -ruNp 621-swsusp-tidy.patch-old/kernel/power/swsusp.c 
> > 621-swsusp-tidy.patch-new/kernel/power/swsusp.c
> > --- 621-swsusp-tidy.patch-old/kernel/power/swsusp.c 2005-06-20 
> > 11:47:31.0 +1000
> > +++ 621-swsusp-tidy.patch-new/kernel/power/swsusp.c 2005-07-04 
> > 23:14:19.0 +1000
> > @@ -36,6 +36,8 @@
> >   * For TODOs,FIXMEs also look in Documentation/power/swsusp.txt
> >   */
> >  
> > +#define KERNEL_POWER_SWSUSP_C
> 
> Headers that change depending on #define's are considered evil..

Fixed. Thanks!

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

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

Re: [0/48] Suspend2 2.1.9.8 for 2.6.12

[Nigel Cunningham]

Hi.

On Tue, 2005-07-12 at 16:41, Andrew Morton wrote:
> Nigel Cunningham <[EMAIL PROTECTED]> wrote:
> >
> > First I'll act on feedback from this round. Regarding diffing against
> >  -mm, I though Andrew wanted patches against Linus' tree. I'm happy to do
> >  both. Andrew?
> 
> Is it anywhere near being ready?

Yes. Development has almost stopped. I'm just addressing the responses
from last week's email and then will send again, so yes. Here's my todo
list (some done already):

Todo list as at 12 July 2005.

FIX.
- Check for redundant variables & functions and remove.
- Ensure driver model calls are right (Bug 45).
- NFS issue (Bug 52)

COMPLETE.
- Opteron support (Bug 1).
- Documentation cleanups.

IMPLEMENT.
- 64GB support.
- IA64 support.
- Implement remembering compression ratio acheived using another method
apart
  from LZF plugin.

HCH/Pavel Replies.
- Setting NoSave pages early.
- Amount needed parameter.
- Add underscores to variable names.
- Inline functions for image preparation (storage needed etc).
- Debugging code from extents.
- extenchain -> extent_chain

- Patch descriptions/rationales.
- Against mm.
- Remove #define XXX_C

> Am still futzing with the ongoing pm_message_t saga here.  I hope there's
> no overlap with that.

We've been using pm_message_t in Suspend2 since February, so we should
already be where you're heading.

Regards,

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

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

Re: kernel guide to space

[Denis Vlasenko]

On Monday 11 July 2005 18:34, Sander wrote:
> Michael S. Tsirkin wrote (ao):
> > Use tabs, not spaces, for indentation. Tabs should be 8
> > characters wide.
> 
> A tab is a tab. The editor/viewer can be configured to show 2, 3, 4, 8,
> any amount of characters, right?

text with 8-char tabs:

struct s {
int n;  /* comment */
unsigned int u; /* comment */
};

Same text viewed with tabs set to 4-char width:

struct s {
int n;  /* comment */
unsigned int u; /* comment */
};

Comments are not aligned anymore
--
vda

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/48] Suspend2 2.1.9.8 for 2.6.12: 403-debug-pagealloc-support.patch

[Nigel Cunningham]

Hi.

On Mon, 2005-07-11 at 09:02, Christoph Hellwig wrote:
> this is missing a description.  But I don't think that one is gonna help, 
> we're
> not gonna add truckloads of crap just to print a warning when a user shoots 
> himself
> in his foot.

I would like to improve this so we actually check the mount time for the
filesystems, but this was a simpler intermediate step.

It may seem superfluous to you, but Suspend2 has over 12,000 users, and
not all of them are expert users. Not everyone gets it right first time.

Regards,

Nigel 
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

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

Re: [PATCH] [3/48] Suspend2 2.1.9.8 for 2.6.12: 301-proc-acpi-sleep-activate-hook.patch

[Nigel Cunningham]

Hi.

On Mon, 2005-07-11 at 09:03, Christoph Hellwig wrote:
> Please add an explanation why this is nessecary.  Big NACK for the patch 
> as-is, but
> to find a proper solution we need to know what you're actually doing.

When the user has an initrd or initramfs, they're supposed to include

echo > /proc/software_suspend/do_resume

at the point in their initrd where drivers needed for accessing the
image, encryption keys and so on have been set up, but the root fs has
not yet been mounted. If they don't do that, we should scream loudly,
because mounting the root fs (even read only) will replay the journal,
making the image not match what is on disk. This in turn can and
probably will result in hard disk corruption if they echo to do_resume
from say /etc/rc.d/rc.sysinit.

In addition, the try_to_freeze call is needed because, having loaded an
image, we freeze kernel threads before doing the atomic restore.

Regards,

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

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

Re: [0/48] Suspend2 2.1.9.8 for 2.6.12

[Andrew Morton]

Nigel Cunningham <[EMAIL PROTECTED]> wrote:
>
> First I'll act on feedback from this round. Regarding diffing against
>  -mm, I though Andrew wanted patches against Linus' tree. I'm happy to do
>  both. Andrew?

Is it anywhere near being ready?

Am still futzing with the ongoing pm_message_t saga here.  I hope there's
no overlap with that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [5/48] Suspend2 2.1.9.8 for 2.6.12: 350-workthreads.patch

[Nigel Cunningham]

Hi.

On Mon, 2005-07-11 at 09:04, Christoph Hellwig wrote:
> Again, why do you think you need this?

1. If something should be wrong with the freezer, it forms part of a
safety net that stops your data on disk being trashed.
2. Separating out threads doing syncing from threads submitting I/O
makes the refrigerator much more reliable, even under extreme load.

Regards,

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

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

Re: [0/48] Suspend2 2.1.9.8 for 2.6.12

[Nigel Cunningham]

Hi.

On Mon, 2005-07-11 at 09:06, Christoph Hellwig wrote:
> This submissions is completely useless.  48 patches without description
> and a subbject lines that hides the little information even more.

Yes. My mistake with the subject lines. Sorry. I'll also add better
descriptions when I repost.

> Please start again, and only with useful patches that on their own,
> against -mm and with detailed explanations of each patch.

First I'll act on feedback from this round. Regarding diffing against
-mm, I though Andrew wanted patches against Linus' tree. I'm happy to do
both. Andrew?

Regards,

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [12/48] Suspend2 2.1.9.8 for 2.6.12: 402-mtrr-remove-sysdev.patch

[Nigel Cunningham]

Hi.

On Mon, 2005-07-11 at 09:07, Christoph Hellwig wrote:
> So what's this deep magic doing?  And why do you add such crude function for
> debug pagealloc builds only?

For debug_pagealloc, the pages we want to save and restore need to be
mapped for the the atomic copy, and unmapped afterwards. This function
achieves that.

Regards,

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [48/48] Suspend2 2.1.9.8 for 2.6.12: 624-filewriter.patch

[Nigel Cunningham]

Hi.

On Mon, 2005-07-11 at 09:14, Christoph Hellwig wrote:
> Please send new crytptoapi algorithms to the cryptoapi maintainers for review.
> It's something that's completely independent of any software suspend stuff.

Thanks.

Did this about a week prior to sending the patches. Sorry - including
this in the patches posted was an oversight.

Regards,

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [43/48] Suspend2 2.1.9.8 for 2.6.12: 619-userspace-nofreeze.patch

[Nigel Cunningham]

Hi.

On Mon, 2005-07-11 at 09:15, Christoph Hellwig wrote:
> UI support is nothing that belongs here.  People won't die by having a text 
> console for
> a while.

UI support belongs here for the following reasons:

- While driver support is imperfect, there is the potential for hangs.
People need to be able to recognise when this happens. They therefore
need some feedback to know that the process is not hung, and to be able
to say where it hung when it does.
- Particularly for the desktop, we want the system to look professional,
not half baked.
- Some support is needed for the user to be able to cancel a suspend.
You might not want to. Others might not want to, but this doesn't mean
that others shouldn't have the option of changing their minds.

I have already moved much of the code out to userspace in an effort to
ease your concerns. I'm not going so far as to remove the functionality,
though.

Regards,

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Fusion MPT Base Driver initialization failure with kdump

[Bharata B Rao]

Fusion MPT base driver fails during initialization when kdump capture
kernel boots. The details of the problem are reported here:

http://bugzilla.kernel.org/show_bug.cgi?id=4870

Regards,
Bharata.

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

Re: reiser4 plugins

[Hans Reiser]

Horst von Brand wrote:

>Hans Reiser <[EMAIL PROTECTED]> wrote:
>  
>
>>Stefan Smietanowski wrote:
>>
>>
>>>I think "..." and ".meta" both serve as a logical delimiter. However
>>>some programs implement their own "..." which would make it clash with
>>>them. Naturally if some program created a directory called .meta we're
>>>equally screwed.
>>>  
>>>
>
>  
>
>>I chose '' (four dots) because it clashes with less, not three dots.
>>
>>
>
>Is this some kind of "My dots are more than yours" contest?!
>
>/None/ of them is safe. ".meta", "...", "", ".this.has.five.dots." are
>all perfectly legal file (or directory) names, POSIXly. If any one of them
>won't do, none will.
>  
>
There is a long history of encroaching namespaces by creating new
keywords in CS, and it is a survivable problem.

Clearcase (the version control filesystem) is an excellent example. 
They have special meanings for @ and some other common characters, and
you have to learn how to escape those characters if you use them in
Clearcase.

It works, it makes users happy, in practice it is far less of a problem
than one might think.  I think there were two or three times I had to
remember how to escape things in 2 years of using it.

Better to spend one's mind looking for bugs instead of this issue.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Merging relayfs?

[Greg KH]

On Tue, Jul 12, 2005 at 12:40:41AM -0400, Karim Yaghmour wrote:
> 
> Greg KH wrote:
> > The path/filename dictates how it is used, so putting relayfs type files
> > in debugfs is just fine.  debugfs allows any types of files to be there.
> ...
> > New trees in / are not LSB compliant, hence the reason for writing
> > securityfs to get rid of /selinux and other LSM filesystems that were
> > starting to sprout up.
> ...
> > But that's exactly what debugfs is for, to allow data to be dumped out
> > of the kernel for different usages.
> ...
> > Ok, have a better name for it?  It's simple and easy to understand.
> 
> It also carries with it the stigma of "kernel debugging", which I just
> don't see production system maintainers liking very much.

But they like the name "dtrace" instead?  (sorry, couldn't resist...)

Come on, they will never see the name "debugfs", right?  Your tools will
then have a common place to look for your ltt and other files, as you
_know_ where it will be mounted in the fs namespace.

And you _are_ doing kernel debugging and tracing with ltt, what's wrong
with admitting that?

> So tell you what, how about if we merged what's in debugfs into relayfs
> instead? We'll still end up with one filesystem, but we'll have a more
> inocuous name. After all, if debugfs is indeed for dumping data from the
> kernel to user-space for different usages, then relaying is what it's
> actually doing, right?

Sorry, but debugfs was there first, and people are already using it in
the kernel tree :)

Anyway, good luck trying to get the distros to accept
yet-another-fs-to-mount-somewhere, I know it was hard to get support for
sysfs as it was...

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

Re: reiser4 plugins

[Stefan Traby]

On Mon, Jul 11, 2005 at 10:33:24PM -0400, Horst von Brand wrote:
> Hans Reiser <[EMAIL PROTECTED]> wrote:
> > I chose '' (four dots) because it clashes with less, not three dots.
> 
> Is this some kind of "My dots are more than yours" contest?!
> 
> /None/ of them is safe. ".meta", "...", "", ".this.has.five.dots." are
> all perfectly legal file (or directory) names, POSIXly. If any one of them
> won't do, none will.

Correct. I suggest "lost+found".
It's also a legal name but was always somewhat special.
[not sure if I should place a smiley here]

-- 

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

Re: zImage on 2.6?

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Wakko Warner <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> Not all machines are PXE capable.  The boot will be generally CDrom or USB
> stick.  I wanted to continue to support our machines that are not capable of
> booting from either of these (which all of these are not PXE capable)
> 

You can stick a recent version of Etherboot on your CD-ROM or USB
stick and use that as your PXE stack.

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

Re: zImage on 2.6?

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Krzysztof Halasa <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Wakko Warner <[EMAIL PROTECTED]> writes:
> 
> > x86.  Does zImage work on other arches?  (I've only ever dealt with alpha
> > and sparc other than x86)
> 
> Sure, ARM for example. 2 MB is not a problem.

That's a completely different meaning of zImage then.  The x86 boot
protocol (also used on x86-64) only allows 504K for zImage.

For x86, zImage is so dead it's not even funny.  I tried to remove it
a few years ago but people complained.

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

Re: zImage on 2.6?

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:shogunx <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Tue, 3 May 2005, Wakko Warner wrote:
> 
> On an interesting side note, when running linux on IBM rs/6000, which is
> a ppc64 machine, one must use a zImage kernel dd'ed into a small PReP
> partition to boot the machine... bzImage kernels will not work.
> 

zImage/bzImage probably means something completely different on ppc.

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

Re: zImage on 2.6?

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:"Randy.Dunlap" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> | 
> | Yes, I do recall it says "System is 724k".  zImage failes.  bzImage says
> | 724k as well and succeeds.
> 
> The image size needs to be <= 0x7f000 (520192 bytes, 508 KB).
> 
> (No, I don't know why, just that this is what is being
> enforced.)
> 

Because that's the size of the hole that a zImage has to fit inside.

WTF is someone using zImage still?

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

Re: Merging relayfs?

[Karim Yaghmour]

Greg KH wrote:
> The path/filename dictates how it is used, so putting relayfs type files
> in debugfs is just fine.  debugfs allows any types of files to be there.
...
> New trees in / are not LSB compliant, hence the reason for writing
> securityfs to get rid of /selinux and other LSM filesystems that were
> starting to sprout up.
...
> But that's exactly what debugfs is for, to allow data to be dumped out
> of the kernel for different usages.
...
> Ok, have a better name for it?  It's simple and easy to understand.

It also carries with it the stigma of "kernel debugging", which I just
don't see production system maintainers liking very much.

So tell you what, how about if we merged what's in debugfs into relayfs
instead? We'll still end up with one filesystem, but we'll have a more
inocuous name. After all, if debugfs is indeed for dumping data from the
kernel to user-space for different usages, then relaying is what it's
actually doing, right?

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Merging relayfs?

[Andi Kleen]

Andrew Morton <[EMAIL PROTECTED]> writes:

> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, Jul 11, 2005 at 08:10:42PM -0500, Tom Zanussi wrote:
> > > 
> > > Hi Andrew, can you please merge relayfs?  It provides a low-overhead
> > > logging and buffering capability, which does not currently exist in
> > > the kernel.
> > 
> > While the code is pretty nicely in shape it seems rather pointless to
> > merge until an actual user goes with it.
> 
> Ordinarily I'd agree.  But this is a bit like kprobes - it's a funny thing
> which other kernel features rely upon, but those features are often ad-hoc
> and aren't intended for merging.

Yes, it's a special case because it's useful for custom debugging
hacks. I would be in favour of merging it.

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

Re: [PATCH][help?] Radeonfb acpi resume

[Micheal Marineau]

Pavel Machek wrote:
> Hi!
> 
> 
Aww crap, thunderbird screwed up the white space...

A usable version of the patch is attached, or here is a link:
http://dev.gentoo.org/~marineam/files/patch-radeonfb-2.6.12
>>>
>>>
>>>Wrong indentation in acpi_vgapost; I remember there was better patch
>>>to fix this out there.
>>
>>Ok, I'll go through and fix any coding style problems.  I've only seen
>>older versions of this same patch, but if there is a better way I'd love
>>to hear it.  I'll google around a little more just in case.
> 
> 
> It *was* version of the same patch, but it had codingstyle fixed, IIRC.

Ok, thats an easy fix then :-)
> 
> 
>>>Anyway, are you sure machine you have can't be fixed by any methods
>>>listed in Doc*/power/video.txt? I guess they are preferable to
>>>acpi_vgapost...
>>
>>Actually, this is one of the metholds listed in video.txt. Take a look
>>at #7 ;-).  I just tried acpi_sleep=s3_bios to see what that does, but
>>just caused an instant reboot on resume.  The only other solutions that
>>works is to disable the frame buffer and use X or some other app to do
>>the job as listed in #5 and #6, but something in kernel like this patch
>>is required to be able to use the framebuffer.
> 
> 
> I'd say that disabling framebuffer and going #5 or #6 is still
> prefered, but given nice patch, I'll probably accept it. Oh, and do
> note that (7) is listed near just one notebook.
> 
>   Pavel

Well, before the patch is ever concidered for the mainline I think
the issue with acquire_console_sem() causing the resume process to
stop and wait for a key press would have to be addressed.

This option could be listed for more notebooks with radeon cards,
for example mine is an Dell Inspiron 8500.


-- 
Michael Marineau
[EMAIL PROTECTED]
Oregon State University


signature.asc
Description: OpenPGP digital signature

Re: Merging relayfs?

[Greg KH]

On Mon, Jul 11, 2005 at 10:55:33PM -0500, Tom Zanussi wrote:
> Greg KH writes:
>  > On Mon, Jul 11, 2005 at 11:03:59PM -0400, Karim Yaghmour wrote:
>  > > 
>  > > Greg KH wrote:
>  > > > What ever happened to exporting the relayfs file ops, and just using
>  > > > debugfs as your controlling fs instead?  As all of the possible users
>  > > > fall under the "debug" type of kernel feature, it makes more sense to
>  > > > confine users to that fs, right?
>  > > 
>  > > Actually, like we discussed the last time this surfaced, there are far
>  > > more users for relayfs than just debugging.
>  > 
>  > Based on the proposed users of this fs, I don't see any.  What ones are
>  > you saying are not "debug" type operations?  And yes, I consider LTT a
>  > "debug" type operation :)
>  > 
>  > The best part of this, is it gives distros and users a consistant place
>  > to mount the fs, and to know where this kind of thing shows up in the fs
>  > namespace.
> 
> Makes sense, and I don't see a problem with getting rid of the fs part
> of relayfs and letting debugfs take over that role, if debugfs were
> there for all potential users.  It doesn't sound like it would satisfy
> users like LTT and systemtap though, who expect to be available at all
> times even on production systems, which wouldn't be the case unless
> the distros always shipped with debugfs enabled.

They will, the overhead of adding debugfs support is _very_ tiny, only:
 $ size fs/debugfs/built-in.o 
   textdata bss dec hex filename
   2257 788   83053 bed fs/debugfs/built-in.o

So I do not see why you should not just drop your fs part.

>  > > What we settled on was having relayfs export its file ops so that
>  > > indeed debugfs users could use it to log things in conjunction with
>  > > debugfs.
>  > 
>  > Last I looked, this was not possible.  Has this changed in the latest
>  > version?
> 
> The file operations are all exported, but I haven't actually tried to
> use relayfs files in debugfs.  Is there something more needed?

Shouldn't be.  Try it to make sure though :)

thanks,

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

Re: Merging relayfs?

[Greg KH]

On Mon, Jul 11, 2005 at 11:52:57PM -0400, Karim Yaghmour wrote:
> 
> Greg KH wrote:
> > Based on the proposed users of this fs, I don't see any.  What ones are
> > you saying are not "debug" type operations?  And yes, I consider LTT a
> > "debug" type operation :)
> > 
> > The best part of this, is it gives distros and users a consistant place
> > to mount the fs, and to know where this kind of thing shows up in the fs
> > namespace.
> 
> Except that relayfs contains files that all behave in a very specific
> way: as relayfs buffers, while debugfs may contain a variety of different
> types of files.

The path/filename dictates how it is used, so putting relayfs type files
in debugfs is just fine.  debugfs allows any types of files to be there.

> I kind'a see what you're trying to say, and I fully understand that some
> debugfs users may indeed use the relayfs fileops to add an entry in
> debugfs which serves as a buffer, and that's the very reason we exported
> them to boot.

Good.

> But there's something to be said about having a single filesystem (and
> therefore tree somewhere in /)

New trees in / are not LSB compliant, hence the reason for writing
securityfs to get rid of /selinux and other LSM filesystems that were
starting to sprout up.

> which contains entries dedicated to a single purpose: dump huge
> amounts of data out of the kernel and into userspace whether or not
> the system is being debuged.

But that's exactly what debugfs is for, to allow data to be dumped out
of the kernel for different usages.

> From a user point of view, it sounds awfully weird if they're using
> "debugfs" on a production system ...

Ok, have a better name for it?  It's simple and easy to understand.

> > Last I looked, this was not possible.  Has this changed in the latest
> > version?
> 
> Here's from 2.6.13-rc2-mm1 fs/relayfs/inode.c
> > +EXPORT_SYMBOL_GPL(relayfs_open);
> > +EXPORT_SYMBOL_GPL(relayfs_poll);
> > +EXPORT_SYMBOL_GPL(relayfs_mmap);
> > +EXPORT_SYMBOL_GPL(relayfs_release);
> > +EXPORT_SYMBOL_GPL(relayfs_file_operations);
> > +EXPORT_SYMBOL_GPL(relayfs_create_dir);
> > +EXPORT_SYMBOL_GPL(relayfs_remove_dir);
> 
> It's been there ever since you've asked for it earlier this year :)

Thanks, didn't realize that.  Wait, all that should be needed is
"relayfs_file_operations", right?  Why have those others exported?

thanks,

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

Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[Martin J. Bligh]

--Lee Revell <[EMAIL PROTECTED]> wrote (on Tuesday, July 12, 2005 00:13:21 
-0400):

> On Mon, 2005-07-11 at 21:07 -0700, Martin J. Bligh wrote:
>> 
>> --Lee Revell <[EMAIL PROTECTED]> wrote (on Monday, July 11, 2005 20:30:59 
>> -0400):
>> 
>> > On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen wrote:
>> >> Lee Revell wrote:
>> >> 
>> >> > Tickless + sub HZ timers is a win for everyone, the multimedia people
>> >> > get better latency, and the laptop people get to run longer.
>> >> 
>> >> IIRC it's not a win for many systems.  Throughput goes down due to timer 
>> >> manipulation overhead.
>> > 
>> > Makes sense.  Anyway, this whole thread has been pretty hand wavey, I
>> > propose that until we see some numbers from the HZ=250 advocates, we
>> > leave the default alone.
>> 
>> Odd. Since I showed you some numbers already ... and nobody from the latency
>> side of the argument has come up with any?
> 
> Sorry, I have not seen any.  Got a link?

Look back in the thread. It made kernel compiles about 5% faster on a
fairly large box. I think the SGI people did it originally because it
caused them even larger problems.

I'm not saying their aren't arguments on both sides ... there are. I just
agree with you there's a lot of hand-waving going on ... but probably not
agreeing as to who it's coming from ;-)

Some sort of comprimise has to be struck for now, until we get sub-HZ
timers. I'd prefer 100, personally (I had that set as default in my tree
for a long time). Some people would prefer 1000 or even more, maybe.
250/300 seems like a reasonable comprimise to me. Exactly what problems
*does* it cause (in visible effect, not "timers are less granular").
Jittery audio/video? How much worse is it?

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386: Selectable Frequency of the Timer Interrupt

[Lee Revell]

On Mon, 2005-07-11 at 21:07 -0700, Martin J. Bligh wrote:
> 
> --Lee Revell <[EMAIL PROTECTED]> wrote (on Monday, July 11, 2005 20:30:59 
> -0400):
> 
> > On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen wrote:
> >> Lee Revell wrote:
> >> 
> >> > Tickless + sub HZ timers is a win for everyone, the multimedia people
> >> > get better latency, and the laptop people get to run longer.
> >> 
> >> IIRC it's not a win for many systems.  Throughput goes down due to timer 
> >> manipulation overhead.
> > 
> > Makes sense.  Anyway, this whole thread has been pretty hand wavey, I
> > propose that until we see some numbers from the HZ=250 advocates, we
> > leave the default alone.
> 
> Odd. Since I showed you some numbers already ... and nobody from the latency
> side of the argument has come up with any?

Sorry, I have not seen any.  Got a link?

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386: Selectable Frequency of the Timer Interrupt

[Martin J. Bligh]

--Lee Revell <[EMAIL PROTECTED]> wrote (on Monday, July 11, 2005 20:30:59 
-0400):

> On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen wrote:
>> Lee Revell wrote:
>> 
>> > Tickless + sub HZ timers is a win for everyone, the multimedia people
>> > get better latency, and the laptop people get to run longer.
>> 
>> IIRC it's not a win for many systems.  Throughput goes down due to timer 
>> manipulation overhead.
> 
> Makes sense.  Anyway, this whole thread has been pretty hand wavey, I
> propose that until we see some numbers from the HZ=250 advocates, we
> leave the default alone.

Odd. Since I showed you some numbers already ... and nobody from the latency
side of the argument has come up with any?

M.

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

Re: [SOLVED] Prism 2.5 MiniPCI Wireless Unstable

[Michael B Allen]

My Thinkpad T30 "Intel" wireless now works perfectly after switching to the 
hostap_pci driver and updating the primary and station firmware (pk010101.hex 
and sf010804.hex respectively) on the MiniPCI card using the WinUpdate program 
(I dual boot Win2K) as described in the below link.

I re-ran my rsync test and it completed without error at a smooth 550Kbps from 
two floors up.

Thanks,
Mike

hostap_pci: Registered netdevice wifi0
wifi0: NIC: id=0x8013 v1.0.0
wifi0: PRI: id=0x15 v1.1.1
wifi0: STA: id=0x1f v1.8.4
wifi0: Intersil Prism2.5 PCI: mem=0xf800, irq=11

On Tue, 12 Jul 2005 01:46:52 +0300
Jar <[EMAIL PROTECTED]> wrote:

> Michael B Allen wrote:
> > hostap_pci: 0.3.9 - 2005-06-10 (Jouni Malinen <[EMAIL PROTECTED]>)
> > ACPI: PCI interrupt :02:02.0[A] -> GSI 11 (level, low) -> IRQ 11
> > hostap_pci: Registered netdevice wifi0
> > wifi0: NIC: id=0x8013 v1.0.0
> > wifi0: PRI: id=0x15 v1.1.0
> > wifi0: STA: id=0x1f v1.4.9
> > wifi0: Intersil Prism2.5 PCI: mem=0xf800, irq=11
> 
> Maybe you should try to update the firmwares, that is all you can do at 
> this point. For me the 1.1.1/1.7.4 combination has been worked like a 
> charm, also when used in heavy load. I belive the driver itself is 
> stable (the PCI prism2.5 card never timed out for me). So there has to 
> be hardware/firmware problem somewhere.
> 
> PRI: id=0x15 v1.1.0 --> v1.1.1
> STA: id=0x1f v1.4.9 --> v1.7.4
> 
> The Flashing HOWTO: http://linux.junsun.net/intersil-prism/
> The firmware collection: http://www.red-bean.com/~proski/firmware/
> 
> You can try the RAM (volatile) firmawares first and if it helps you can 
> flash the non volatile versions (Flash) if you want. Newer flash primary 
> firmware alone, but primary and station firmwares simultaneously. The 
> filenames (if I remember correctly) are:
> 
> ak010104.hex (RAM PRI:1.1.4)
> rf010704.hex (RAM STA:1.7.4)
> 
> pk010101.hex (Flash PRI:1.1.1)
> sf010704.hex (Flash STA:1.7.4)
> 
> There is also newer verisons available:
> 
> The latest firmwares in the collection are:
> 
>  RAM   Flash
> Prism 2  PCMCIA 1.7.1 1.7.1
> Prism 2.5/3  PCI/PCMCIA 1.8.4 (NEW!)  1.8.4
> Prism 3  USB1.8.3 1.8.4
> 
> -- 
> Best Regards, Jar
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Merging relayfs?

[Karim Yaghmour]

Greg KH wrote:
> Based on the proposed users of this fs, I don't see any.  What ones are
> you saying are not "debug" type operations?  And yes, I consider LTT a
> "debug" type operation :)
> 
> The best part of this, is it gives distros and users a consistant place
> to mount the fs, and to know where this kind of thing shows up in the fs
> namespace.

Except that relayfs contains files that all behave in a very specific
way: as relayfs buffers, while debugfs may contain a variety of different
types of files.

I kind'a see what you're trying to say, and I fully understand that some
debugfs users may indeed use the relayfs fileops to add an entry in
debugfs which serves as a buffer, and that's the very reason we exported
them to boot. But there's something to be said about having a single
filesystem (and therefore tree somewhere in /) which contains entries
dedicated to a single purpose: dump huge amounts of data out of the
kernel and into userspace whether or not the system is being debuged.

>From a user point of view, it sounds awfully weird if they're using
"debugfs" on a production system ...

> Last I looked, this was not possible.  Has this changed in the latest
> version?

Here's from 2.6.13-rc2-mm1 fs/relayfs/inode.c
> +EXPORT_SYMBOL_GPL(relayfs_open);
> +EXPORT_SYMBOL_GPL(relayfs_poll);
> +EXPORT_SYMBOL_GPL(relayfs_mmap);
> +EXPORT_SYMBOL_GPL(relayfs_release);
> +EXPORT_SYMBOL_GPL(relayfs_file_operations);
> +EXPORT_SYMBOL_GPL(relayfs_create_dir);
> +EXPORT_SYMBOL_GPL(relayfs_remove_dir);

It's been there ever since you've asked for it earlier this year :)

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Merging relayfs?

[Tom Zanussi]

Greg KH writes:
 > On Mon, Jul 11, 2005 at 11:03:59PM -0400, Karim Yaghmour wrote:
 > > 
 > > Greg KH wrote:
 > > > What ever happened to exporting the relayfs file ops, and just using
 > > > debugfs as your controlling fs instead?  As all of the possible users
 > > > fall under the "debug" type of kernel feature, it makes more sense to
 > > > confine users to that fs, right?
 > > 
 > > Actually, like we discussed the last time this surfaced, there are far
 > > more users for relayfs than just debugging.
 > 
 > Based on the proposed users of this fs, I don't see any.  What ones are
 > you saying are not "debug" type operations?  And yes, I consider LTT a
 > "debug" type operation :)
 > 
 > The best part of this, is it gives distros and users a consistant place
 > to mount the fs, and to know where this kind of thing shows up in the fs
 > namespace.

Makes sense, and I don't see a problem with getting rid of the fs part
of relayfs and letting debugfs take over that role, if debugfs were
there for all potential users.  It doesn't sound like it would satisfy
users like LTT and systemtap though, who expect to be available at all
times even on production systems, which wouldn't be the case unless
the distros always shipped with debugfs enabled.

 > 
 > > What we settled on was having relayfs export its file ops so that
 > > indeed debugfs users could use it to log things in conjunction with
 > > debugfs.
 > 
 > Last I looked, this was not possible.  Has this changed in the latest
 > version?

The file operations are all exported, but I haven't actually tried to
use relayfs files in debugfs.  Is there something more needed?

Tom


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

Re: reiser4 plugins

[Horst von Brand]

David Masover <[EMAIL PROTECTED]> wrote:

[...]

> Both camps seem to want to allow easy access to the metadata of a
> file, whether we're given that file as an inode or as a pathname.
> That's why I suggested /meta/vfs and /meta/inode -- sometimes I want
> to look up a file by name, and sometimes by inode, but either way, I
> should be able to get its metadata.

You should /never/ give access just by inode, as that makes it very easy to
bypass security given by directory permissions.

> > I mean, editing something is easy and you don't have to "know" how
> > to navigate /meta

> But then you have to "know" how to navigate .meta, and more
> importantly, how to find .meta

And what the heck the format of the metadata is today/for this particular
file.

[...]

> Either way, the major challenge to this method is not so much whether
> it'd work, but how to choose a suitable delimiter?  The delimiter must
> be standard if we're going to have apps develop for it, and it must
> not be used in the name of any existing file or directory.

The only characters that aren't used in filenames today are '/' and '\0'.

> I had a long essay here on how '.meta' breaks every recursive
> operation on directories (rm -rf, tar, mkisofs), but I deleted it when
> I remembered that I played around with the alpha/beta reiser4 which
> had a 'metas' dir that did the same thing, but was hidden from the
> normal directory listing.  'cd metas' worked, 'ls metas' worked, but
> 'ls' showed no directory called 'metas'.

And if I try to create a file or directory called metas?

> I don't *think* there are any apps that will break if you tell them to
> open a path that doesn't exist in a directory listing.  That is,
> typing 'vim /home/metas/acl' should always let me edit the acl on
> /home, and vim should never complain about how /home/metas doesn't
> show up in /home.  A program would have to be pretty retarded to fail
> on something like that.

Think a GUI that reads the directory to find out what is available and
present them as icons for mousing around. Then there is no way to futz
around with your metadata.

Think filename completion, bash style. No, not just bash uses this.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[Horst von Brand]

Hans Reiser <[EMAIL PROTECTED]> wrote:
> Stefan Smietanowski wrote:
> > I think "..." and ".meta" both serve as a logical delimiter. However
> > some programs implement their own "..." which would make it clash with
> > them. Naturally if some program created a directory called .meta we're
> > equally screwed.

> I chose '' (four dots) because it clashes with less, not three dots.

Is this some kind of "My dots are more than yours" contest?!

/None/ of them is safe. ".meta", "...", "", ".this.has.five.dots." are
all perfectly legal file (or directory) names, POSIXly. If any one of them
won't do, none will.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Lack of Documentation about SA_RESTART...

[Philippe Troin]

"Theodore Ts'o" <[EMAIL PROTECTED]> writes:

> On Mon, Jul 11, 2005 at 12:32:37PM +0200, Paolo Ornati wrote:
> > But what I'm looking for is a list of syscalls that are automatically
> > restarted when SA_RESTART is set, and especially in what conditions.
> > 
> > For example: read(), write(), open() are obviously restarted, but even
> > on non-blocking fd?
> > And what about connect() and select() for example?
> > 
> > There are a lot of syscalls that can fail with "EINTR"! What's the
> > advantage of using SA_RESTART if one doesn't know what syscalls are
> > restarted?
> 
> According to the Single Unix Specification V3, all functions that
> return EINTR are supposed to restart if a process receives a signal
> where signal handler has been installed with the SA_RESTART flag.  

Except for select() and poll(), which should always return EINTR even
when interrupted with a SA_RESTART signal.

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

Re: Kernel header policy

[Horst von Brand]

Marc Aurele La France <[EMAIL PROTECTED]> wrote:
> It has been more than a week now...

> -- Forwarded message --
> Date: Sun, 3 Jul 2005 11:12:03 -0600 (MDT)
> From: Marc Aurele La France <[EMAIL PROTECTED]>
> To: Linus Torvalds
> Subject: Kernel header policy

[]

> I am contacting you to express my concern over a growing trend in kernel
> development.  I am specifically referring to changes being made to kernel
> headers that break compatibility at the userland level, where __KERNEL__
> isn't #define'd.

The policy with respect to kernel headers is /very/ simple:

  T H E Y   A R E   N E V E R   U S E D   F R O M   U S E R L A N D.

This general policy makes all your points (trivially) moot.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Merging relayfs?

[Greg KH]

On Mon, Jul 11, 2005 at 11:03:59PM -0400, Karim Yaghmour wrote:
> 
> Greg KH wrote:
> > What ever happened to exporting the relayfs file ops, and just using
> > debugfs as your controlling fs instead?  As all of the possible users
> > fall under the "debug" type of kernel feature, it makes more sense to
> > confine users to that fs, right?
> 
> Actually, like we discussed the last time this surfaced, there are far
> more users for relayfs than just debugging.

Based on the proposed users of this fs, I don't see any.  What ones are
you saying are not "debug" type operations?  And yes, I consider LTT a
"debug" type operation :)

The best part of this, is it gives distros and users a consistant place
to mount the fs, and to know where this kind of thing shows up in the fs
namespace.

> What we settled on was having relayfs export its file ops so that
> indeed debugfs users could use it to log things in conjunction with
> debugfs.

Last I looked, this was not possible.  Has this changed in the latest
version?

thanks,

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

[patch 2.6.13-git] 8250 tweaks

[David Brownell]

Two small changes:  make the IRQ name less generic, and stop
whining about certain non-errors (details in the patch comments).
Please merge.

- Dave

Make the 8250 UART driver register its IRQ using a label that's more
appropriate ... it's an 8250 UART, not one of dozens of other kind of
serial link (I2C, SPI, USB, McBSP, I2S, non-8250 UART, USART, SSP,
MicroWire, PS/2 kbd/mouse/touchpad, MCSI, HDQ/1-Wire, ... etc).

Also, make it stop whining when one of the platform serial ports has
been disabled, e.g. because a given board doesn't wire it out.

Signed-off-by: David Brownell <[EMAIL PROTECTED]>

--- o26.orig/drivers/serial/8250.c	2005-07-11 18:41:03.0 -0700
+++ o26/drivers/serial/8250.c	2005-07-11 18:58:26.0 -0700
@@ -1317,7 +1317,7 @@ static int serial_link_irq_chain(struct 
 		spin_unlock_irq(&i->lock);
 
 		ret = request_irq(up->port.irq, serial8250_interrupt,
-  irq_flags, "serial", i);
+  irq_flags, "uart_8250", i);
 		if (ret < 0)
 			serial_do_unlink(i, up);
 	}
@@ -2331,6 +2331,8 @@ static int __devinit serial8250_probe(st
 	memset(&port, 0, sizeof(struct uart_port));
 
 	for (i = 0; p && p->flags != 0; p++, i++) {
+		if (!p->iobase && !p->membase)
+			continue;
 		port.iobase	= p->iobase;
 		port.membase	= p->membase;
 		port.irq	= p->irq;

Re: Merging relayfs?

[Karim Yaghmour]

Greg KH wrote:
> What ever happened to exporting the relayfs file ops, and just using
> debugfs as your controlling fs instead?  As all of the possible users
> fall under the "debug" type of kernel feature, it makes more sense to
> confine users to that fs, right?

Actually, like we discussed the last time this surfaced, there are far
more users for relayfs than just debugging. What we settled on was
having relayfs export its file ops so that indeed debugfs users could
use it to log things in conjunction with debugfs.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/29v2] InfiniBand core update

[David S. Miller]

Please acknowledge that you understand how inappropriate
and problem causing your huge patch bomb was today to this
mailing list.

It is nearly 8 hours later, and vger.kernel.org is still
trying mightily to spit out all of your patches to the
5000+ people subscribed to linux-kernel.

There is about ~6 hour posting latency as a result of all
of this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/29v2] InfiniBand core update

[Andrew Morton]

Hal Rosenstock <[EMAIL PROTECTED]> wrote:
>
> > I'll tentatively consider this material to be not-for-2.6.13?
> 
>  Presuming that "this material" refers to the patch to add the kernel CM
>  implementation, if kernel CM does not make 2.6.13, then user CM should
>  not either as it is dependent on it.

Well I was asking.  Do you guys think that this material is appropriate to
and safe enough for 2.6.13?

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

Re: usb mass storage bug

[Greg KH]

On Mon, Jul 11, 2005 at 01:30:47PM -0700, Joe Sevy wrote:
> Sorry, no logs or dmesg to report; just performance.
> Using kernel 2.6.12: USB flash drive (san-disk cruzer
> micro) Copy FROM drive is normal and quick; copy TO
> drive is amazingly slow. (30 minutes for 50K file).
> Used same configuration as for 2.6.11.11. Cured by
> going back to old kernel.

Are you using CONFIG_UB or CONFIG_USB_STORAGE?

Also, linux-usb-devel is the better place for this if you have a more
detailed report.

thanks,

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

Re: Kernel header policy

[Greg KH]

On Mon, Jul 11, 2005 at 03:37:47PM -0600, Marc Aurele La France wrote:
> I am contacting you to express my concern over a growing trend in kernel
> development.  I am specifically referring to changes being made to kernel
> headers that break compatibility at the userland level, where __KERNEL__
> isn't #define'd.

Kernel headers are not to be included by userspace programs.  See the
archives for details...

> b)  has been broken since 2.5.62's development cycle and has
>yet to be fixed.  Here, the #include of  needs
>to be bracked by __KERNEL__.  This is another occurrence of "1)".

-ENOPATCH.

thanks,

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

Re: Merging relayfs?

[Karim Yaghmour]

Andrew Morton wrote:
> Still, first let us get a handle on who wants relayfs now and in the future
> and for what.  Then we can better decide.

We used relayfs for our series of tests on PREEMPT_RT and I-Pipe.
Specifically, we used relayfs buffers to store the timestamps for our
interrupt latency measurements. This allowed us to easily have access
to very large buffering areas without having to worry about any form
of detailed resource allocation, or runtime overhead of logging. IOW,
it allowed us to concentrate on our main priority: log a very large
amount of timestamps.

On the LTT side, relayfs is bound to be at the center of whatever
architecture we settle on for the ongoing rewrite. For having used it
for past releases of LTT, we know that it can handle very heavy data
throughput with little overhead using a relatively simple API.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Merging relayfs?

[Greg KH]

On Mon, Jul 11, 2005 at 08:10:42PM -0500, Tom Zanussi wrote:
> 
> Hi Andrew, can you please merge relayfs?  It provides a low-overhead
> logging and buffering capability, which does not currently exist in
> the kernel.
> 
> relayfs key features:
> 
> - Extremely efficient high-speed logging/buffering
> - Simple mechanism for user-space data retrieval
> - Very short write path
> - Can be used in any context, including interrupt context
> - No runtime resource allocation
> - Doesn't do a kmalloc for each "packet"
> - No need for end-recipient
> - Data may remain buffered whether it is consumed or not
> - Data committed to disk in bulk, not per "packet"
> - Can be used in circular-buffer mode for flight-recording

What ever happened to exporting the relayfs file ops, and just using
debugfs as your controlling fs instead?  As all of the possible users
fall under the "debug" type of kernel feature, it makes more sense to
confine users to that fs, right?

thanks,

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

Re: Realtime Preemption, 2.6.12, Beginners Guide?

[Lee Revell]

On Mon, 2005-07-11 at 15:38 +0100, Alistair John Strachan wrote:
> I realise 4KSTACKS is a considerable rework of the IRQ handler, etc. and 
> probably even more heavily modified by rt-preempt, but is there nothing else 
> that can be tested before a serial console run?
> 

Well, netconsole is a lot quicker to set up than serial, but AIUI can
fail in some cases where serial console succeeds.

Lee 

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

How to find if BIOS has already enabled the device

[Parag Warudkar]

> On Sad, 2005-05-28 at 14:57, Parag Warudkar wrote:
> > This current problem of Hang-On-Boot if USB drive is attached does not 
happen 
> > with Windows - so it is some sort of additional (unnecessary?) thing which 
> > Linux does and the BIOS doesn't like.  (Like re-enabling the controller 
even 
> > if BIOS has already enabled it or some such.)

> > Alan Cox wrote:
> Provide dmesg output and we might be able to guess. The first obvious
> candidate would be the BIOS refusing to do a handover if it booted from
> USB disk.

Hi Alan

Sorry for digging this out so late - (Quick recap - My machine hangs for 
couple minutes on boot if USB storage disk is attached - hang occurs in 
pci_enable_device).

I have filed a bug to track this one - 
http://bugme.osdl.org/show_bug.cgi?id=4711

Further analysis points towards  wrong/differing IRQ assigments being the 
cause of this hang. I observed that when the machine hangs, the IRQ 
assignment looks like -

18:379   IO-APIC-level  eth0   
 19:  3   IO-APIC-level  ohci1394   
 20:   1439   IO-APIC-level  ohci_hcd, NVidia nForce3 Modem   
 21:  0   IO-APIC-level  ohci_hcd, NVidia nForce3   
 22:  12884   IO-APIC-level  ehci_hcd   

And when it does NOT hang it looks like -
16:  3   IO-APIC-level  ohci1394   
 18:  49277   IO-APIC-level  nvidia   
 19:   1753   IO-APIC-level  eth0   
 20:   6253   IO-APIC-level  ohci_hcd   
 21:646   IO-APIC-level  ohci_hcd, NVidia nForce3   
 22:   2225   IO-APIC-level  ehci_hcd, NVidia nForce3 Modem   

Seems to me like the OHCI controller doesn't like to be assigned IRQ 19. Is 
this difference in IRQ assignment normal or is it a bug somewhere? 

Parag
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/29v2] InfiniBand core update

[Hal Rosenstock]

On Mon, 2005-07-11 at 20:05, Andrew Morton wrote:
> Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> >
> > This is version 2 of a patch series to get the Infiniband core up to
> > date.
> 
> Well that was interesting.
> 
> - All the patches had mangled headers:
> 
> -- linux-2.6.13-rc2-mm1-16/...
> +++ linux-2.6.13-rc2-mm1-17/...
> 
>   instead of
> 
> --- linux-2.6.13-rc2-mm1-16/...
> +++ linux-2.6.13-rc2-mm1-17/...

Not sure how that happened.

>   Which I fixed up.

Thanks.

> - The second patch didn't apply.  I fixed that too.

Not sure how this was broken. Thanks for fixing this.

> - The patches add lots of trailing whitespace.  I habitually trim that
>   off, figuring that any downstream merging hassle which that causes is
>   just punishment ;)

I'll work on merging this back downstream :-(

> Please check that it all landed OK in the next -mm.

Will do.

> I've hung on to Tom Duffy's patch pending a test compilation.
> 
> I'll tentatively consider this material to be not-for-2.6.13?

Presuming that "this material" refers to the patch to add the kernel CM
implementation, if kernel CM does not make 2.6.13, then user CM should
not either as it is dependent on it.

-- Hal

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

Re: SCSI DVD-RAM partitions

[Christoph Hellwig]

On Sat, Jul 09, 2005 at 02:32:47PM +0200, Thomas Heinz wrote:
> Is it possible to make the DVD-RAM partitions available as device
> nodes (or at least directly mountable without the losetup hack)?
> One solution would be to make the device available as /dev/sdX and
> /dev/srX. Is that possible?

While adding support for partitions on sr is trivial it has a huge
drawback: it's chaning the dev_t space by using up device numbers
for partitions, so /dev/sr0 ff will have different device numbers
with that change applied.  I have an old patch that's supposed to
enable support for partitioned scsi removable devices at
http://rechner.lst.de/~hch/hacks/sr-parts.diff, I'm not sure it
actually ever worked (but you should get the basic idea from it)

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

Re: [patch 2.6.13-rc2] pci: restore BAR values from pci_set_power_state for D3hot->D0

[Adam Belay]

On Fri, Jul 08, 2005 at 02:34:56PM -0400, John W. Linville wrote:
> Some PCI devices lose all configuration (including BARs) when
> transitioning from D3hot->D0.  This leaves such a device in an
> inaccessible state.  The patch below causes the BARs to be restored
> when enabling such a device, so that its driver will be able to
> access it.
> 
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
> ---
> Some firmware leaves devices in D3hot after a (re)boot.  Most drivers
> call pci_enable_device very early, so devices left in D3hot that lose
> configuration during the D3hot->D0 transition will be inaccessible to
> their drivers.

Also, I think there is a possibility of only enabling boot devices for ACPI
S4.  However, for the reboot case, we're not restoring anything.  Instead new
resource assignments are being made.  Doesn't the PCI subsystem already
handle this?

> 
> Drivers could be modified to account for this, but it would
> be difficult to know which drivers need modification.  This is
> especially true since often many devices are covered by the same
> driver.  It likely would be necessary to replicate code across dozens
> of drivers.

Agreed.

> 
> The patch below should trigger only when transitioning from D3hot->D0
> (or at boot), and only for devices that have the "no soft reset" bit
> cleared in the PM control register.  I believe it is safe to include as
> part of the PCI infrastructure.


>   * pci_set_power_state - Set the power state of a PCI device
>   * @dev: PCI device to be suspended
>   * @state: PCI power state (D0, D1, D2, D3hot, D3cold) we're entering
> @@ -239,7 +270,7 @@ pci_find_parent_resource(const struct pc
>  int
>  pci_set_power_state(struct pci_dev *dev, pci_power_t state)
>  {

Couldn't this be in pci_restore_state() instead?  I was thinking it would
(in part) replace the ugly dword reads we have now.  They include many
registers we don't need to touch.  I wonder if we'll need pci_save_state()
at all or if we can derive all the information from the pci_dev.  I'll have
to look into it further.

Also we need a way to restore specific PCI capabilities.

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

Re: Merging relayfs?

[Andrew Morton]

Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> On Mon, Jul 11, 2005 at 08:10:42PM -0500, Tom Zanussi wrote:
> > 
> > Hi Andrew, can you please merge relayfs?  It provides a low-overhead
> > logging and buffering capability, which does not currently exist in
> > the kernel.
> 
> While the code is pretty nicely in shape it seems rather pointless to
> merge until an actual user goes with it.

Ordinarily I'd agree.  But this is a bit like kprobes - it's a funny thing
which other kernel features rely upon, but those features are often ad-hoc
and aren't intended for merging.

relayfs is more for in-kernel "applications" than for userspace ones, if
you like.

Still, first let us get a handle on who wants relayfs now and in the future
and for what.  Then we can better decide.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Merging relayfs?

[Christoph Hellwig]

On Mon, Jul 11, 2005 at 08:10:42PM -0500, Tom Zanussi wrote:
> 
> Hi Andrew, can you please merge relayfs?  It provides a low-overhead
> logging and buffering capability, which does not currently exist in
> the kernel.

While the code is pretty nicely in shape it seems rather pointless to
merge until an actual user goes with it.

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

Re: Merging relayfs?

[Tom Zanussi]

Andrew Morton writes:
 > Tom Zanussi <[EMAIL PROTECTED]> wrote:
 > >
 > > Hi Andrew, can you please merge relayfs?
 > 
 > I guess so.  Would you have time to prepare a list of existing and planned
 > applications?

Sure.  I know that systemtap (http://sourceware.org/systemtap/) is
using relayfs and that LTT (http://www.opersys.com/ltt/index.html) is
also currently being reworked to use it.

I've also added a couple of people to the cc: list that I've consulted
with in getting their applications to use relayfs, one of which is the
logdev debugging device recently posted to LKML.

I also know that there are still users of the old relayfs around; I
don't however know what their plans are regarding moving to the new
relayfs.

My own personal interest is to start playing around with creating some
visualization tools using data gathered from relayfs.  Hopefully, I'll
have more time to do that if relayfs gets merged. ;-)

Hope that helps,

Tom


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

Re: Merging relayfs?

[Dave Airlie]

> >
> > Hi Andrew, can you please merge relayfs?
> 
> I guess so.  Would you have time to prepare a list of existing and planned
> applications?

I have a plan to use it for something that no-one knows about yet..

I was going to use it for doing a DRM packet debug logger... to try
and trace hangs in the system, using printk doesn't really help as
guess what it slows the machine down so much that your races don't
happen... I wrote some basic code for this already.. and I'm hoping to
use some work time to get it finished at some stage...

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

Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[Eric St-Laurent]

On Mon, 2005-07-11 at 16:08 +0200, Arjan van de Ven wrote:

> Alan: you worked on this before, where did you end up with ?
> 

The last patch i've seen is 1 year old.

http://www.ussg.iu.edu/hypermail/linux/kernel/0407.3/0643.html

Eric St-Laurent


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

Re: [SOLVED ??] Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble

[Alan Stern]

On Mon, 11 Jul 2005, Michel Bouissou wrote:

> Le Lundi 11 Juillet 2005 23:21, Alan Stern a écrit :
> > Don't jump to hasty conclusions.  Problems like this are often caused by
> > unrelated things that you wouldn't suspect at first.
> 
> I know... Been working with computers for... Uh... 25 years ?

35 years for me...  My, how the time flies!

> I don't believe the hardware is broken, as it's been running for more than 2 
> years 100% stable with a 24/7/365 uptime. And with me plugging and unplugging 
> USB devices...
> 
> Never had a single problem of the kind with any 2.4.x kernel. Get those 
> problems only with 2.6.x kernels, and, in 2.6.12, only when UP IO-APIC is 
> enabled (which ran perfectly good in 2.4).
> 
> So the problem is circled to 2.6 kernel, uhci_hcd and UP IO-APIC.

Don't rule out the hardware too quickly.  2.4 and 2.6 manage the UHCI
controllers in different ways.  In particular, the usb-uhci driver in 2.4
does not suspend the controller when no devices are attached, whereas
uhci-hcd in 2.6 does.  (So does the "alternate" uhci driver in 2.4.)  I
recently handled a bug report -- from another Frenchman -- where it turned
out that his UHCI hardware instantly crashed the entire system whenever
it resumed from the suspended state!

To try and help pin things down, tomorrow (i.e., Tuesday) I'll send you a
test patch to completely disable the UHCI controllers, leaving them awake
and idle, not generating interrupts.  If you still get those spurious
IRQs, they will have to come from somewhere else.  (Assuming you can
devote server time to this sort of testing...)

And of course, if the spurious IRQs stop then we'll know where to probe 
further.

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: [PATCH] Add ENOSYS into sys_io_cancel

[Benjamin LaHaise]

Hello Wendy,

Two things: your patch needs to be properly signed off on.  Read 
Documentation/SubmittingPatches for a description of what that entials.  
Secondly, your patch adds whitespace on the end of the else.  Aside 
from that, the printk should be removed -- just replace it with the 
ret = -ENOSYS.

Also, please cc [EMAIL PROTECTED] on future aio patches.  Cheers,

-ben 

On Mon, Jul 11, 2005 at 03:06:52PM -0400, Wendy Cheng wrote:
> Previously sent via private mail that doesn't seem to go thru - resend 
> via office mailer.
> 
> Note that other than few exceptions, most of the current filesystem 
> and/or drivers do not have aio cancel specifically defined 
> (kiob->ki_cancel field is mostly NULL). However, sys_io_cancel system 
> call universally sets return code to -EGAIN. This gives applications a 
> wrong impression that this call is implemented but just never works. We 
> have customer inquires about this issue.
> 
> Upload a trivial patch to address this confusion.
> 
> -- Wendy
> 
> 

> --- linux-2.6.12/fs/aio.c 2005-06-17 15:48:29.0 -0400
> +++ linux/fs/aio.c2005-07-10 12:48:14.0 -0400
> @@ -1641,8 +1641,9 @@ asmlinkage long sys_io_cancel(aio_contex
>   cancel = kiocb->ki_cancel;
>   kiocb->ki_users ++;
>   kiocbSetCancelled(kiocb);
> - } else
> + } else 
>   cancel = NULL;
> +  
>   spin_unlock_irq(&ctx->ctx_lock);
>  
>   if (NULL != cancel) {
> @@ -1659,8 +1660,10 @@ asmlinkage long sys_io_cancel(aio_contex
>   if (copy_to_user(result, &tmp, sizeof(tmp)))
>   ret = -EFAULT;
>   }
> - } else
> + } else {
> + ret = -ENOSYS;
>   printk(KERN_DEBUG "iocb has no cancel operation\n");
> + } 
>  
>   put_ioctx(ctx);
>  


-- 
"Time is what keeps everything from happening all at once." -- John Wheeler
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Merging relayfs?

[Andrew Morton]

Tom Zanussi <[EMAIL PROTECTED]> wrote:
>
> Hi Andrew, can you please merge relayfs?

I guess so.  Would you have time to prepare a list of existing and planned
applications?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CDs which hang kernel

[randy_dunlap]

On Tue, 12 Jul 2005 04:11:03 +0300 Nerijus Baliunas wrote:

| On Mon, 11 Jul 2005 23:10:37 +0300 Nerijus Baliunas <[EMAIL PROTECTED]> wrote:
| 
| > I have 2 cdroms which hang PC - one when trying to mount, another when
| > inserted. Kernel 2.6.12-1.1390_FC4, Lite-On SOHW-1673S,
| > hdc: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
| > I can send them by mail if anyone wants.
| 
| Actually it hangs with first one, when trying to mount, with second I get 
oops.

Hi,
Can you post the oops for the second one?

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] DVB: LGDT3302 QAM256 initialization fix

[Michael Krufky]

- Initialize all non mutually exclusive variables
 without regard to the mode selected.
- Do a software reset each time the parameters are
 set, regardless of whether anything changes.
 This may allow an application to recover from a
 hung condition.
- Improved error reporting.
- Removed $Id:$

Signed-off-by: Mac Michaels <[EMAIL PROTECTED] >
Signed-off-by: Michael Krufky <[EMAIL PROTECTED] >



 linux/drivers/media/dvb/frontends/lgdt3302.c |   63 +--
 1 files changed, 30 insertions(+), 33 deletions(-)

diff -u linux-2.6.13/drivers/media/dvb/frontends/lgdt3302.c 
linux/drivers/media/dvb/frontends/lgdt3302.c
--- linux-2.6.13/drivers/media/dvb/frontends/lgdt3302.c 2005-07-07 
08:19:00.0 +
+++ linux/drivers/media/dvb/frontends/lgdt3302.c2005-07-11 
21:25:53.0 +
@@ -1,6 +1,4 @@
 /*
- * $Id: lgdt3302.c,v 1.5 2005/07/07 03:47:15 mkrufky Exp $
- *
  *Support for LGDT3302 (DViCO FustionHDTV 3 Gold) - VSB/QAM
  *
  *Copyright (C) 2005 Wilson Michaels <[EMAIL PROTECTED]>
@@ -83,7 +81,10 @@
 
if ((err = i2c_transfer(state->i2c, &msg, 1)) != 1) {
printk(KERN_WARNING "lgdt3302: %s error (addr %02x <- 
%02x, err == %i)\n", __FUNCTION__, addr, buf[0], err);
-   return -EREMOTEIO;
+   if (err < 0)
+   return err;
+   else
+   return -EREMOTEIO;
}
} else {
u8 tmp[] = { buf[0], buf[1] };
@@ -96,7 +97,10 @@
tmp[1] = buf[i];
if ((err = i2c_transfer(state->i2c, &msg, 1)) != 1) {
printk(KERN_WARNING "lgdt3302: %s error (addr 
%02x <- %02x, err == %i)\n", __FUNCTION__, addr, buf[0], err);
-   return -EREMOTEIO;
+   if (err < 0)
+   return err;
+   else
+   return -EREMOTEIO;
}
tmp[0]++;
}
@@ -266,36 +270,30 @@
i2c_writebytes(state, state->config->demod_address,
   demux_ctrl_cfg, sizeof(demux_ctrl_cfg));
 
-   if (param->u.vsb.modulation == VSB_8) {
-   /* Initialization for VSB modes only */
-   /* Change the value of NCOCTFV[25:0]of carrier
-  recovery center frequency register for VSB */
-   i2c_writebytes(state, state->config->demod_address,
+   /* Change the value of NCOCTFV[25:0] of carrier
+  recovery center frequency register */
+   i2c_writebytes(state, state->config->demod_address,
   vsb_freq_cfg, sizeof(vsb_freq_cfg));
-   } else {
-   /* Initialization for QAM modes only */
-   /* Set the value of 'INLVTHD' register 0x2a/0x2c
-  to value from 'IFACC' register 0x39/0x3b -1 */
-   int value;
-   i2c_selectreadbytes(state, AGC_RFIF_ACC0,
-   &agc_delay_cfg[1], 3);
-   value = ((agc_delay_cfg[1] & 0x0f) << 8) | 
agc_delay_cfg[3];
-   value = value -1;
-   dprintk("%s IFACC -1 = 0x%03x\n", __FUNCTION__, value);
-   agc_delay_cfg[1] = (value >> 8) & 0x0f;
-   agc_delay_cfg[2] = 0x00;
-   agc_delay_cfg[3] = value & 0xff;
-   i2c_writebytes(state, state->config->demod_address,
-  agc_delay_cfg, sizeof(agc_delay_cfg));
-
-   /* Change the value of IAGCBW[15:8]
-  of inner AGC loop filter bandwith */
-   i2c_writebytes(state, state->config->demod_address,
-  agc_loop_cfg, sizeof(agc_loop_cfg));
-   }
+   /* Set the value of 'INLVTHD' register 0x2a/0x2c
+  to value from 'IFACC' register 0x39/0x3b -1 */
+   int value;
+   i2c_selectreadbytes(state, AGC_RFIF_ACC0,
+   &agc_delay_cfg[1], 3);
+   value = ((agc_delay_cfg[1] & 0x0f) << 8) | agc_delay_cfg[3];
+   value = value -1;
+   dprintk("%s IFACC -1 = 0x%03x\n", __FUNCTION__, value);
+   agc_delay_cfg[1] = (value >> 8) & 0x0f;
+   agc_delay_cfg[2] = 0x00;
+   agc_delay_cfg[3] = value & 0xff;
+   i2c_writebytes(state, state->config->demod_address,
+  agc_delay_cfg, sizeof(agc_delay_cfg));
+
+   /* Change the value of IAGCBW[15:8]
+   

Re: [RFC][PATCH] i386: Per node IDT

[Zwane Mwaikambo]

Hello Oleg,

On Mon, 11 Jul 2005, Oleg Nesterov wrote:

> Zwane Mwaikambo wrote:
> >
> > --- linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S   3 Jul 2005 13:20:43 
> > -   1.1.1.1
> > +++ linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S   10 Jul 2005 22:33:37 
> > -
> > -
> > +/* Build the IRQ entry stubs */
> >  vector=0
> > -ENTRY(irq_entries_start)
> > +   .align IRQ_STUB_SIZE,0x90
> > +ENTRY(interrupt)
> >  .rept NR_IRQS
> > ALIGN
> > -1: pushl $vector-256
> > +   pushl $vector
> > jmp common_interrupt
> >
> >  [...snip...]
> >
> > --- linux-2.6.13-rc1-mm1/arch/i386/kernel/irq.c 3 Jul 2005 13:20:43 
> > -   1.1.1.1
> > +++ linux-2.6.13-rc1-mm1/arch/i386/kernel/irq.c 4 Jul 2005 21:39:56 
> > -
> > @@ -53,8 +53,7 @@ static union irq_ctx *softirq_ctx[NR_CPU
> >   */
> >  fastcall unsigned int do_IRQ(struct pt_regs *regs)
> >  {  
> > -   /* high bits used in ret_from_ code */
> > -   int irq = regs->orig_eax & 0xff;
> > +   int irq = regs->orig_eax;
> 
> Could you explain this change? I think it breaks do_signal/handle_signal,
> they check orig_eax >= 0 to handle -ERESTARTSYS:
> 
>   /* Are we from a system call? */
>   if (regs->orig_eax >= 0) {
>   /* If so, check system call restarting.. */
>   switch (regs->eax) {
>   case -ERESTART_RESTARTBLOCK:
>   case -ERESTARTNOHAND:

The change is so that we can send IRQs higher than 256 to do_IRQ. That 
looks like it tries to check if we came in via system_call since we'd save 
the system call number as orig_eax. Now that i think about it, doesn't 
that path always get taken when we interrupt userspace and have pending 
signals on return from interrupt?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: USB bugs in 2.6.11.8, 2.6.11.10 and 2.6.12.2

[Markus Törnqvist]

Hi!

Sorry about the bother, enabling K8 IOMMU fixed the issues.
At least that's the most relevant change I made to the conf
to fix it.

For some reason I must have had a brainfart and not enabled it.

Thanks to Pauli Borodulin for noticing this :)

-- 
mjt



signature.asc
Description: Digital signature

[PATCH 4/27] Combine some MAD routines

[Hal Rosenstock]

Combine response_mad() and solicited_mad() routines into a single
function and simplify/encapsulate its usage.

Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

This patch depends on patch 3/27.

-- 
 mad.c |  105 --
 1 files changed, 27 insertions(+), 78 deletions(-)
diff -uprN linux-2.6.13-rc2-mm1/drivers/infiniband3/core/mad.c 
linux-2.6.13-rc2-mm1/drivers/infiniband4/core/mad.c
-- linux-2.6.13-rc2-mm1/drivers/infiniband3/core/mad.c  2005-07-09 
14:31:49.0 -0400
+++ linux-2.6.13-rc2-mm1/drivers/infiniband4/core/mad.c 2005-07-09 
15:06:29.0 -0400
@@ -58,7 +58,7 @@ static int method_in_use(struct ib_mad_m
 static void remove_mad_reg_req(struct ib_mad_agent_private *priv);
 static struct ib_mad_agent_private *find_mad_agent(
struct ib_mad_port_private *port_priv,
-   struct ib_mad *mad, int solicited);
+   struct ib_mad *mad);
 static int ib_mad_post_receive_mads(struct ib_mad_qp_info *qp_info,
struct ib_mad_private *mad);
 static void cancel_mads(struct ib_mad_agent_private *mad_agent_priv);
@@ -67,7 +67,6 @@ static void ib_mad_complete_send_wr(stru
 static void timeout_sends(void *data);
 static void cancel_sends(void *data);
 static void local_completions(void *data);
-static int solicited_mad(struct ib_mad *mad);
 static int add_nonoui_reg_req(struct ib_mad_reg_req *mad_reg_req,
  struct ib_mad_agent_private *agent_priv,
  u8 mgmt_class);
@@ -558,6 +557,13 @@ int ib_unregister_mad_agent(struct ib_ma
 }
 EXPORT_SYMBOL(ib_unregister_mad_agent);
 
+static inline int response_mad(struct ib_mad *mad)
+{
+   /* Trap represses are responses although response bit is reset */
+   return ((mad->mad_hdr.method == IB_MGMT_METHOD_TRAP_REPRESS) ||
+   (mad->mad_hdr.method & IB_MGMT_METHOD_RESP));
+}
+
 static void dequeue_mad(struct ib_mad_list_head *mad_list)
 {
struct ib_mad_queue *mad_queue;
@@ -650,7 +656,7 @@ static int handle_outgoing_dr_smp(struct
  struct ib_smp *smp,
  struct ib_send_wr *send_wr)
 {
-   int ret, solicited;
+   int ret;
unsigned long flags;
struct ib_mad_local_private *local;
struct ib_mad_private *mad_priv;
@@ -696,11 +702,7 @@ static int handle_outgoing_dr_smp(struct
switch (ret)
{
case IB_MAD_RESULT_SUCCESS | IB_MAD_RESULT_REPLY:
-   /*
-* See if response is solicited and
-* there is a recv handler
-*/
-   if (solicited_mad(&mad_priv->mad.mad) &&
+   if (response_mad(&mad_priv->mad.mad) &&
mad_agent_priv->agent.recv_handler) {
local->mad_priv = mad_priv;
local->recv_mad_agent = mad_agent_priv;
@@ -717,15 +719,13 @@ static int handle_outgoing_dr_smp(struct
break;
case IB_MAD_RESULT_SUCCESS:
/* Treat like an incoming receive MAD */
-   solicited = solicited_mad(&mad_priv->mad.mad);
port_priv = ib_get_mad_port(mad_agent_priv->agent.device,
mad_agent_priv->agent.port_num);
if (port_priv) {
mad_priv->mad.mad.mad_hdr.tid =
((struct ib_mad *)smp)->mad_hdr.tid;
recv_mad_agent = find_mad_agent(port_priv,
-  &mad_priv->mad.mad,
-   solicited);
+   &mad_priv->mad.mad);
}
if (!port_priv || !recv_mad_agent) {
kmem_cache_free(ib_mad_cache, mad_priv);
@@ -1421,42 +1421,15 @@ out:
return;
 }
 
-static int response_mad(struct ib_mad *mad)
-{
-   /* Trap represses are responses although response bit is reset */
-   return ((mad->mad_hdr.method == IB_MGMT_METHOD_TRAP_REPRESS) ||
-   (mad->mad_hdr.method & IB_MGMT_METHOD_RESP));
-}
-
-static int solicited_mad(struct ib_mad *mad)
-{
-   /* CM MADs are never solicited */
-   if (mad->mad_hdr.mgmt_class == IB_MGMT_CLASS_CM) {
-   return 0;
-   }
-
-   /* XXX: Determine whether MAD is using RMPP */
-
-   /* Not using RMPP */
-   /* Is this MAD a response to a previous MAD ? */
-   return response_mad(mad);
-}
-
 static struct ib_mad_agent_private *
 find_mad_agent(struct ib_mad_port_private *port_priv,
-  struct ib_mad *mad,
-  int solicited)
+  struct ib_mad *mad)
 {
struct ib_mad_agent_private *mad_agent = NULL;
unsigned long flags;
 
spin_lock_irqsa

PATCH [6/27] Change ib_mad_send_wr_private struct

[Hal Rosenstock]

Have ib_mad_send_wr_private reference the private agent structure
directly, rather than the exposed agent definition.  Remove unneeded
parameters to functions and simplify code were possible from this
change.

Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

This patch depends on patch 5/27.

-- 
 mad.c  |   22 ++--
 mad_priv.h |4 ++--
 2 files changed, 12 insertions(+), 14 deletions(-)
diff -uprN linux-2.6.13-rc2-mm1/drivers/infiniband5/core/mad.c 
linux-2.6.13-rc2-mm1/drivers/infiniband6/core/mad.c
-- linux-2.6.13-rc2-mm1/drivers/infiniband5/core/mad.c  2005-07-09 
15:08:31.0 -0400
+++ linux-2.6.13-rc2-mm1/drivers/infiniband6/core/mad.c 2005-07-09 
15:12:32.0 -0400
@@ -839,8 +839,7 @@ void ib_free_send_mad(struct ib_mad_send
 }
 EXPORT_SYMBOL(ib_free_send_mad);
 
-static int ib_send_mad(struct ib_mad_agent_private *mad_agent_priv,
-  struct ib_mad_send_wr_private *mad_send_wr)
+static int ib_send_mad(struct ib_mad_send_wr_private *mad_send_wr)
 {
struct ib_mad_qp_info *qp_info;
struct ib_send_wr *bad_send_wr;
@@ -848,7 +847,7 @@ static int ib_send_mad(struct ib_mad_age
int ret;
 
/* Set WR ID to find mad_send_wr upon completion */
-   qp_info = mad_agent_priv->qp_info;
+   qp_info = mad_send_wr->mad_agent_priv->qp_info;
mad_send_wr->send_wr.wr_id = (unsigned long)&mad_send_wr->mad_list;
mad_send_wr->mad_list.mad_queue = &qp_info->send_queue;
 
@@ -857,7 +856,7 @@ static int ib_send_mad(struct ib_mad_age
list_add_tail(&mad_send_wr->mad_list.list,
  &qp_info->send_queue.list);
spin_unlock_irqrestore(&qp_info->send_queue.lock, flags);
-   ret = ib_post_send(mad_agent_priv->agent.qp,
+   ret = ib_post_send(mad_send_wr->mad_agent_priv->agent.qp,
   &mad_send_wr->send_wr, &bad_send_wr);
if (ret) {
printk(KERN_ERR PFX "ib_post_send failed: %d\n", ret);
@@ -950,7 +949,7 @@ int ib_post_send_mad(struct ib_mad_agent
mad_send_wr->wr_id = mad_send_wr->send_wr.wr_id;
mad_send_wr->send_wr.next = NULL;
mad_send_wr->tid = send_wr->wr.ud.mad_hdr->tid;
-   mad_send_wr->agent = mad_agent;
+   mad_send_wr->mad_agent_priv = mad_agent_priv;
/* Timeout will be updated after send completes */
mad_send_wr->timeout = msecs_to_jiffies(send_wr->wr.
ud.timeout_ms);
@@ -966,7 +965,7 @@ int ib_post_send_mad(struct ib_mad_agent
  &mad_agent_priv->send_list);
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
 
-   ret = ib_send_mad(mad_agent_priv, mad_send_wr);
+   ret = ib_send_mad(mad_send_wr);
if (ret) {
/* Fail send request */
spin_lock_irqsave(&mad_agent_priv->lock, flags);
@@ -1742,13 +1741,14 @@ static void adjust_timeout(struct ib_mad
}
 }
 
-static void wait_for_response(struct ib_mad_agent_private *mad_agent_priv,
- struct ib_mad_send_wr_private *mad_send_wr )
+static void wait_for_response(struct ib_mad_send_wr_private *mad_send_wr)
 {
+   struct ib_mad_agent_private *mad_agent_priv;
struct ib_mad_send_wr_private *temp_mad_send_wr;
struct list_head *list_item;
unsigned long delay;
 
+   mad_agent_priv = mad_send_wr->mad_agent_priv;
list_del(&mad_send_wr->agent_list);
 
delay = mad_send_wr->timeout;
@@ -1781,9 +1781,7 @@ static void ib_mad_complete_send_wr(stru
struct ib_mad_agent_private *mad_agent_priv;
unsigned long   flags;
 
-   mad_agent_priv = container_of(mad_send_wr->agent,
- struct ib_mad_agent_private, agent);
-
+   mad_agent_priv = mad_send_wr->mad_agent_priv;
spin_lock_irqsave(&mad_agent_priv->lock, flags);
if (mad_send_wc->status != IB_WC_SUCCESS &&
mad_send_wr->status == IB_WC_SUCCESS) {
@@ -1794,7 +1792,7 @@ static void ib_mad_complete_send_wr(stru
if (--mad_send_wr->refcount > 0) {
if (mad_send_wr->refcount == 1 && mad_send_wr->timeout &&
mad_send_wr->status == IB_WC_SUCCESS) {
-   wait_for_response(mad_agent_priv, mad_send_wr);
+   wait_for_response(mad_send_wr);
}
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
return;
diff -uprN linux-2.6.13-rc2-mm1/drivers/infiniband5/core/mad_priv.h 
linux-2.6.13-rc2-mm1/drivers/infiniband6/core/mad_priv.h
-- linux-2.6.13-rc2-mm1/drivers/infiniband5/core/mad_priv.h 2005-06-29 
19:00:53.0 -0400
+++ linux-2.6.13-rc2-mm1/drivers/infiniband6/cor

Re: CDs which hang kernel

[Nerijus Baliunas]

On Mon, 11 Jul 2005 23:10:37 +0300 Nerijus Baliunas <[EMAIL PROTECTED]> wrote:

> I have 2 cdroms which hang PC - one when trying to mount, another when
> inserted. Kernel 2.6.12-1.1390_FC4, Lite-On SOHW-1673S,
> hdc: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
> I can send them by mail if anyone wants.

Actually it hangs with first one, when trying to mount, with second I get oops.

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

Re: [RFC][PATCH] i386: Per node IDT

[Arjan van de Ven]

On Mon, 2005-07-11 at 08:09 -0600, Zwane Mwaikambo wrote:
> On Mon, 11 Jul 2005, Arjan van de Ven wrote:
> 
> > On Mon, 2005-07-11 at 03:59 +0200, Andi Kleen wrote:
> > > Why per node? Why not go the whole way and make it per CPU?
> > 
> > Agreed, for two reasons even
> > 1) Per cpu allows for even more devices and cache locality
> > 2) While few people have a NUMA system, many have an SMP system so you
> > get a lot more testing.
> 
> Agreed, the first version was a per cpu one simply so that i could test it 
> on a normal SMP system. Andi seems to be of the same opinion, what do you 
> think of the hotplug cpu case (explained in previous email)?

you need to cope with hotplug of entire nodes anyway, or hotunplug of
the last cpu of a node. In fact I bet that the administration needed
will be LESS in the per cpu case (since you know it's the only one)
compared to the per node case.


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

Re: PS/2 mouse not working

[Sune Mølgaard]

Sune Mølgaard wrote:
I have tried compiling psmouse as module and loading it, and I have 
tried compiling it into kernel. I have also chosen to have a /dev/psaux, 
that doesn't get any input either. Mouse seems to get detected, as per 
this snippet from dmesg:


Oh yeah. I also tried an usb -> PS/2 converter on my current mouse to 
rule out a faulty mause. Same result...


/Sune

--
The tolerance of liberty can be maintained until complete federal and
state control by Catholics has been accomplished.
- Bishop O'Connor, Pittsburgh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Merging relayfs?

[Tom Zanussi]

Hi Andrew, can you please merge relayfs?  It provides a low-overhead
logging and buffering capability, which does not currently exist in
the kernel.

relayfs key features:

- Extremely efficient high-speed logging/buffering
- Simple mechanism for user-space data retrieval
- Very short write path
- Can be used in any context, including interrupt context
- No runtime resource allocation
- Doesn't do a kmalloc for each "packet"
- No need for end-recipient
- Data may remain buffered whether it is consumed or not
- Data committed to disk in bulk, not per "packet"
- Can be used in circular-buffer mode for flight-recording

The relayfs code has been in -mm for more than three months following
the extensive review that took place on LKML at the beginning of the
year, at which time we addressed all of the issues people had.  Since
then only a few minor patches to the original codebase have been
needed, most of which were sent to us by users; we'd like to thank
those who took the time to send patches or point out problems.

The code in the -mm tree has also been pounded on very heavily through
normal use and testing, and we haven't seen any problems with it - it
appears to be very stable.

We've also tried to make it as easy as possible for people to create
'quick and dirty' (or more substantial) kernel logging applications.
Included is a link to an example that demonstrates how useful this can
be.  In a nutshell, it uses relayfs logging functions to track
kmalloc/kfree and detect memory leaks.  The only thing it does in the
kernel is to log a small binary record for each kmalloc and kfree.
The data is then post-processed in user space with a simple Perl
script.  You can see an example of the output and the example itself
here:

http://relayfs.sourceforge.net/examples.html#kleak


Last but not least, it's still small (40k worth of source),
self-contained and unobtrusive to the rest of the kernel.

In summary, relayfs is very stable, is useful to current users and
with inclusion, would be useful to many others.  If you can think of
anything we've overlooked or should work on to get relayfs to the
point of inclusion, please let us know.

Thanks,

Tom Zanussi
Karim Yaghmour


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386: Selectable Frequency of the Timer Interrupt

[Theodore Ts'o]

On Mon, Jul 11, 2005 at 02:23:08PM +0100, Alan Cox wrote:
> > > Because some machines exhibit appreciable latency in entering low power
> > > state via ACPI, and 1000Hz reduces their battery life.  By about half,
> > > iirc.
> > > 
> > Then the owners of such machines can use HZ=250 and leave the default
> > alone.  Why should everyone have to bear the cost?
> 
> They need 100 really it seems, 250-500 have no real effect and on the
> Dell I tried 250 didn't stop the wild clock slew from the APM bios
> either. I played with this a fair bit on a couple of laptops. I've not
> seen anything > 20% saving however so I've no idea who/why someone saw
> 50%

The real answer here is for the tickless patches to cleaned up to the
point where they can be merged, and then we won't waste battery power
entering the timer interrupt in the first place.  :-)

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

Re: arm: how to operate leds on zaurus?

[John Lenz]

On Mon, July 11, 2005 2:34 pm, Pavel Machek said:
> Hi!
>
> 2.6.12-rc5 (and newer) does not boot on sharp zaurus sl-5500. It
> blinks with green led, fast; what does it mean? I'd like to verify if
> it at least reaches .c code in setup.c. I inserted this code at
> begining of setup.c:674...
>
> #define locomo_writel(val,addr) ({ *(volatile u16 *)(addr) = (val); })
> #define LOCOMO_LPT_TOFH 0x80
> #define LOCOMO_LED  0xe8
> #define LOCOMO_LPT0 0x00
>
>   locomo_writel(LOCOMO_LPT_TOFH, LOCOMO_LPT0 + LOCOMO_LED);
>
> ...but that does not seem to do a trick -- it only breaks the boot :-(
> (do I need to add some kind of IO_BASE?).
>   Pavel

No, that won't work.

As Russell said, there are problems accessing memory before the io maps
have been set up correctly.  You can see the patch
http://www.cs.wisc.edu/~lenz/zaurus/files/2.6.12-rc5/lenz-03-leds-2.6.12-rc5.patch
need scroll near the bottom in file locomo.c to see how the led gets set. 
You won't actually be able to know where in memory that space is mapped
because we call ioremap, and won't be able to access the locomo stuff
until device_initcall.

WARNING: Horrible hack!  Ugly, ugly, ugly!  First read and understand the
warning at
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2002-January/006730.html

Having said that, either before the MMU has been activated or before the
ioremap() has been called, it is sometimes possible to access the LEDs at
the physical addresses they are located at.  This may or may not work,
might not always work, etc... but it can help as a last resort.  On the
SL5500, the physical address of the start of the locomo chip is
0x4000, and the leds are at an offset of 0xe8, so something like
volatile u16 *led = (volatile u16 *)0x40e8;
*led = 0x80;
As the above email says, this is not guarenteed to work at all, will fail
at some point in the boot process, but is something you can try.

That said, I am aware that recent kernel versions have broken the boot on
collie, but haven't looked at the problem in detail (i.e. tried doing a
binary search between known working versions and broken ones to see the
patch that introduced the problem).  I have been working on the SL5600
recently.

John

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

Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[Arjan van de Ven]

> The real answer here is for the tickless patches to cleaned up to the
> point where they can be merged, and then we won't waste battery power
> entering the timer interrupt in the first place.  :-)

one big step forward for that is to have a

mod_timer_relative() and add_timer_relative()

which 
1) take a relative delay as argument (and thus kill 99% of the jiffies
use in the kernel right there and then)
2) takes it in miliseconds, killing 99% of all the HZ conversions/uses
3) takes a "accuracy" argument

3) is tricky I guess, it's designed for cases that are like "I want a
timer 1 second from now, but it's ok to be also at 1.5 seconds if that
suits you better". Those cases are far less rare than you might think at
first, most watchdog kind things are of this type. This accuracy thing
will allow the kernel to save many wakeups by grouping them I suspect.

Alan: you worked on this before, where did you end up with ?

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

[PATCH 8/27] Minor cleanup during MAD startup and shutdown

[Hal Rosenstock]

Minor cleanup during startup and shutdown

Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

This patch depends on patch 7/27.

-- 
 mad.c |   44 +--
 1 files changed, 9 insertions(+), 35 deletions(-)
diff -uprN linux-2.6.13-rc2-mm1/drivers/infiniband7/core/mad.c 
linux-2.6.13-rc2-mm1/drivers/infiniband8/core/mad.c
-- linux-2.6.13-rc2-mm1/drivers/infiniband7/core/mad.c  2005-07-09 
16:48:45.0 -0400
+++ linux-2.6.13-rc2-mm1/drivers/infiniband8/core/mad.c 2005-07-09 
16:51:21.0 -0400
@@ -2487,14 +2487,6 @@ static int ib_mad_port_open(struct ib_de
unsigned long flags;
char name[sizeof "ib_mad123"];
 
-   /* First, check if port already open at MAD layer */
-   port_priv = ib_get_mad_port(device, port_num);
-   if (port_priv) {
-   printk(KERN_DEBUG PFX "%s port %d already open\n",
-  device->name, port_num);
-   return 0;
-   }
-
/* Create new device info */
port_priv = kmalloc(sizeof *port_priv, GFP_KERNEL);
if (!port_priv) {
@@ -2619,7 +2611,7 @@ static int ib_mad_port_close(struct ib_d
 
 static void ib_mad_init_device(struct ib_device *device)
 {
-   int ret, num_ports, cur_port, i, ret2;
+   int num_ports, cur_port, i;
 
if (device->node_type == IB_NODE_SWITCH) {
num_ports = 1;
@@ -2629,47 +2621,37 @@ static void ib_mad_init_device(struct ib
cur_port = 1;
}
for (i = 0; i < num_ports; i++, cur_port++) {
-   ret = ib_mad_port_open(device, cur_port);
-   if (ret) {
+   if (ib_mad_port_open(device, cur_port)) {
printk(KERN_ERR PFX "Couldn't open %s port %d\n",
   device->name, cur_port);
goto error_device_open;
}
-   ret = ib_agent_port_open(device, cur_port);
-   if (ret) {
+   if (ib_agent_port_open(device, cur_port)) {
printk(KERN_ERR PFX "Couldn't open %s port %d "
   "for agents\n",
   device->name, cur_port);
goto error_device_open;
}
}
-
-   goto error_device_query;
+   return;
 
 error_device_open:
while (i > 0) {
cur_port--;
-   ret2 = ib_agent_port_close(device, cur_port);
-   if (ret2) {
+   if (ib_agent_port_close(device, cur_port))
printk(KERN_ERR PFX "Couldn't close %s port %d "
   "for agents\n",
   device->name, cur_port);
-   }
-   ret2 = ib_mad_port_close(device, cur_port);
-   if (ret2) {
+   if (ib_mad_port_close(device, cur_port))
printk(KERN_ERR PFX "Couldn't close %s port %d\n",
   device->name, cur_port);
-   }
i--;
}
-
-error_device_query:
-   return;
 }
 
 static void ib_mad_remove_device(struct ib_device *device)
 {
-   int ret = 0, i, num_ports, cur_port, ret2;
+   int i, num_ports, cur_port;
 
if (device->node_type == IB_NODE_SWITCH) {
num_ports = 1;
@@ -2679,21 +2661,13 @@ static void ib_mad_remove_device(struct 
cur_port = 1;
}
for (i = 0; i < num_ports; i++, cur_port++) {
-   ret2 = ib_agent_port_close(device, cur_port);
-   if (ret2) {
+   if (ib_agent_port_close(device, cur_port))
printk(KERN_ERR PFX "Couldn't close %s port %d "
   "for agents\n",
   device->name, cur_port);
-   if (!ret)
-   ret = ret2;
-   }
-   ret2 = ib_mad_port_close(device, cur_port);
-   if (ret2) {
+   if (ib_mad_port_close(device, cur_port))
printk(KERN_ERR PFX "Couldn't close %s port %d\n",
   device->name, cur_port);
-   if (!ret)
-   ret = ret2;
-   }
}
 }
 


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

Re: Realtime Preemption, 2.6.12, Beginners Guide?

[Ingo Molnar]

* Alistair John Strachan <[EMAIL PROTECTED]> wrote:

> Here's a screenshot of the oops. Notice that "stack left" is now -52. 
> We've confirmed this is a stack overflow!
> 
> http://devzero.co.uk/~alistair/oops8.jpeg
> 
> I'm going to try the 8K stack kernel with the same stuff and see if I 
> can get a stack trace. I hope this is the beginning of the end for 
> this problem.

might be an incorrect printout of stack_left :( The esp looks more or 
less normal. Not sure why it printed -52.

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

[PATCH 10/27] Add automatic retries to MAD layer

[Hal Rosenstock]

Add automatic retries to MAD layer. 
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

This patch depends on patch 9/27.

-- 
 core/mad.c |   26 +-
 core/mad_priv.h|2 ++
 core/sa_query.c|3 ++-
 core/user_mad.c|1 +
 include/ib_verbs.h |1 +
 5 files changed, 31 insertions(+), 2 deletions(-)
diff -uprN linux-2.6.13-rc2-mm1/drivers/infiniband9/core/mad.c 
linux-2.6.13-rc2-mm1/drivers/infiniband10/core/mad.c
-- linux-2.6.13-rc2-mm1/drivers/infiniband9/core/mad.c  2005-07-09 
17:25:36.0 -0400
+++ linux-2.6.13-rc2-mm1/drivers/infiniband10/core/mad.c2005-07-09 
17:25:28.0 -0400
@@ -954,7 +954,7 @@ int ib_post_send_mad(struct ib_mad_agent
/* Timeout will be updated after send completes */
mad_send_wr->timeout = msecs_to_jiffies(send_wr->wr.
ud.timeout_ms);
-   mad_send_wr->retry = 0;
+   mad_send_wr->retries = mad_send_wr->send_wr.wr.ud.retries;
/* One reference for each work request to QP + response */
mad_send_wr->refcount = 1 + (mad_send_wr->timeout > 0);
mad_send_wr->status = IB_WC_SUCCESS;
@@ -2174,6 +2174,27 @@ local_send_completion:
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
 }
 
+static int retry_send(struct ib_mad_send_wr_private *mad_send_wr)
+{
+   int ret;
+
+   if (!mad_send_wr->retries--)
+   return -ETIMEDOUT;
+
+   mad_send_wr->timeout = msecs_to_jiffies(mad_send_wr->send_wr.
+   wr.ud.timeout_ms);
+
+   ret = ib_send_mad(mad_send_wr);
+
+   if (!ret) {
+   mad_send_wr->refcount++;
+   list_del(&mad_send_wr->agent_list);
+   list_add_tail(&mad_send_wr->agent_list,
+ &mad_send_wr->mad_agent_priv->send_list);
+   }
+   return ret;
+}
+
 static void timeout_sends(void *data)
 {
struct ib_mad_agent_private *mad_agent_priv;
@@ -2202,6 +2223,9 @@ static void timeout_sends(void *data)
break;
}
 
+   if (!retry_send(mad_send_wr))
+   continue;
+
list_del(&mad_send_wr->agent_list);
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
 
diff -uprN linux-2.6.13-rc2-mm1/drivers/infiniband9/core/mad_priv.h 
linux-2.6.13-rc2-mm1/drivers/infiniband10/core/mad_priv.h
-- linux-2.6.13-rc2-mm1/drivers/infiniband9/core/mad_priv.h 2005-07-09 
16:48:05.0 -0400
+++ linux-2.6.13-rc2-mm1/drivers/infiniband10/core/mad_priv.h   2005-07-09 
17:15:40.0 -0400
@@ -123,6 +123,7 @@ struct ib_mad_send_wr_private {
u64 wr_id;  /* client WR ID */
u64 tid;
unsigned long timeout;
+   int retries;
int retry;
int refcount;
enum ib_wc_status status;
@@ -136,6 +137,7 @@ struct ib_mad_local_private {
struct ib_sge sg_list[IB_MAD_SEND_REQ_MAX_SG];
u64 wr_id;  /* client WR ID */
u64 tid;
+   int retries;
 };
 
 struct ib_mad_mgmt_method_table {
diff -uprN linux-2.6.13-rc2-mm1/drivers/infiniband9/core/sa_query.c 
linux-2.6.13-rc2-mm1/drivers/infiniband10/core/sa_query.c
-- linux-2.6.13-rc2-mm1/drivers/infiniband9/core/sa_query.c 2005-07-10 
16:21:55.0 -0400
+++ linux-2.6.13-rc2-mm1/drivers/infiniband10/core/sa_query.c   2005-07-10 
16:22:13.0 -0400
@@ -462,7 +462,8 @@ static int send_mad(struct ib_sa_query *
 .mad_hdr = &query->mad->mad_hdr,
 .remote_qpn  = 1,
 .remote_qkey = IB_QP1_QKEY,
-.timeout_ms  = timeout_ms
+.timeout_ms  = timeout_ms,
+.retries = 0 
 }
 }
};
diff -uprN linux-2.6.13-rc2-mm1/drivers/infiniband9/core/user_mad.c 
linux-2.6.13-rc2-mm1/drivers/infiniband10/core/user_mad.c
-- linux-2.6.13-rc2-mm1/drivers/infiniband9/core/user_mad.c 2005-06-29 
19:00:53.0 -0400
+++ linux-2.6.13-rc2-mm1/drivers/infiniband10/core/user_mad.c   2005-07-09 
17:14:46.0 -0400
@@ -322,6 +322,7 @@ static ssize_t ib_umad_write(struct file
wr.wr.ud.remote_qpn  = be32_to_cpu(packet->mad.qpn);
wr.wr.ud.remote_qkey = be32_to_cpu(packet->mad.qkey);
wr.wr.ud.timeout_ms  = packet->mad.timeout_ms;
+   wr.wr.ud.retries = 0;
 
wr.wr_id= (unsigned long) packet;
 
diff -uprN linux-2.6.13-rc2-mm1/drivers/infiniband9/include/ib_verbs.h 
linux-2.6.13-rc2-mm1/drivers/infiniband10/include/ib_verbs.h
-- linux-2.6.13-rc2-mm1/drivers/infiniband9/include/ib_verbs.h  2005-07-10 
11:11:43.0 -0400
+++ linux-2.6.13-rc2-mm1/drivers/infiniban

Re: [PATCH] Use device_for_each_child() to unregister devices in scsi_remove_target().

[Patrick Mansfield]

On Mon, Jul 11, 2005 at 05:20:12PM -0700, Greg KH wrote:
> On Tue, Jul 05, 2005 at 05:38:50PM -0700, Patrick Mansfield wrote:
> > Hi Greg / Patrick -
> > 
> > I'm getting an oops with current (pulled today) 2.6 git, the
> > device_for_each_child() does not seem to be deletion safe.
> > 
> > We hold the klist in place via the n_ref, but the kobj (in the struct
> > device for the struct scsi_target) containing it is freed when the
> > kref->refcount goes to zero.
> 
> But we grab a reference to that object right before we call
> device_for_each_child(), right?  Or am I missing something here?

No, we get another reference on the passed in dev argument (in this
failing case, it is for an FC's rport), not its children (scsi_target)
that we want to iterate over.

If all children (scsi_targets) are removed, then the put in
scsi_remove_target() would (or could) set the rport refcount to zero and
it would be deleted. But the scsi_target would already be gone.

Cases that are not affected are passed a scsi_target:
scsi_is_target_device(dev) is true and we won't even call
device_for_each_child().

Adding another get/put in __remove_child() does *not* help either, as it
is the code within device_for_each_child() that needs another get/put of
the kref instead of a get/put on the klist (well its n_ref); and if you do
that, I don't see how the locking can be done correctly.

I thought we had some semaphores in scsi to protect calls to
scsi_remove_target(), but I only see those for scsi_device scan/removal
(the shost->scan_mutex).

It looks like scsi should not allow removal and additions to happen at the
same time on any scsi_target (and adding up/down on shost->scan_mutex
won't fix this problem).

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

RE: Serial PCI driver in 2.6.x kernel (i.e. 8250_pci HOWTO)

[Matt Schulte]

>From: Russell King [mailto:[EMAIL PROTECTED] Behalf Of Russell King

>Can we see this code?
Because I was working on the assumption that the driver would no longer be
serial.c and would use only my card, I may have done some things that
weren't exactly the best practice.  This is partially why I am trying to
figure out the "correct" way to use the new serial driver.  Because I went
with the entire serial.c file, I don't think that I can post it.  However,
you can get my modifications here:
http://support.commtech-fastcom.com/fcap335_07_11_2005.tar.gz.  I renamed
the serial.c file to fcap_335.c and I changed the devnodes to be
/dev/ttyFCx.  I think every modification that I made has a comment //mds
near it.

>Despite being the maintainer for the serial layer, I'm not on linux-serial.
Right, I am on linux-serial and I had seen a couple of posts from you on
linux-serial, I kind of assumed that you were there too.

Thanks,

Matt Schulte
Commtech, Inc.
http://www.commtech-fastcom.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 3/27] Add MAD helper functions

[Alexey Dobriyan]

On Monday 11 July 2005 17:48, Hal Rosenstock wrote:
> Add new helper routines for allocating MADs for sending and formatting
> a send WR.

> -- linux-2.6.13-rc2-mm1/drivers/infiniband2/core/mad.c
> +++ linux-2.6.13-rc2-mm1/drivers/infiniband3/core/mad.c
   ^^^
Ick. You'd better have linux-2.6.13-rc2-mm1-[0123...].

> +struct ib_mad_send_buf * ib_create_send_mad(struct ib_mad_agent *mad_agent,
> + u32 remote_qpn, u16 pkey_index,
> + struct ib_ah *ah,
> + int hdr_len, int data_len,
> + int gfp_mask)

unsigned int __nocast gfp_mask, please. 430 or so infiniband sparse warnings
is not a reason to add more.

> +{

> + buf = kmalloc(sizeof *send_buf + buf_size, gfp_mask);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Lack of Documentation about SA_RESTART...

[Theodore Ts'o]

On Mon, Jul 11, 2005 at 12:32:37PM +0200, Paolo Ornati wrote:
> But what I'm looking for is a list of syscalls that are automatically
> restarted when SA_RESTART is set, and especially in what conditions.
> 
> For example: read(), write(), open() are obviously restarted, but even
> on non-blocking fd?
> And what about connect() and select() for example?
> 
> There are a lot of syscalls that can fail with "EINTR"! What's the
> advantage of using SA_RESTART if one doesn't know what syscalls are
> restarted?

According to the Single Unix Specification V3, all functions that
return EINTR are supposed to restart if a process receives a signal
where signal handler has been installed with the SA_RESTART flag.  

There may be a few places in the kernel where this isn't happenning,
that's what the specification states. 

My preference is to always check for EINTR out of sheer paranoia and
for portability, since SA_RESTART is an optional part (XSI) of the
specification which is not necessarily implemented by all Unix
systems, and contrary to popular belief, there _are_ Linux-like
systems beyond just Linux that an application writer might want their
programs to be portable to.  You know, quaint legacy systems like
Solaris, HP-UX, AIX, etc.  :-)

> Example of behavior: according to source code it seems that "connect()"
> (the "net/ipv4/af_inet.c : inet_stream_connect()" implementation)
> returns -ERESTARTSYS if interrupted, but if the socket is in
> non-blocking mode it returns -EINTR.

If the socket is non-blocking mode, and there isn't a connection ready
to be received, then the socket is going to return with some kind of
errno set; either EINPROGRESS (Operation now in progress) or EALREADY
(Operation already in progress), or if a signal came in during the
system call (which would happen pretty rarely, the window for the race
condition is pretty small) it will return EINTR.  I _think_ that a
close reading of the specification would state that the system call
should be restarted, and since a connection isn't ready, then at that
point EINPROGRESS or EALREADY would be returned.  

But this is a pretty small corner case, and in practice happens quite
rarely.  There might be some existing code that expects EINTR in this
case, which might explain this, or perhaps it was thought that it was
useful for the application to know that a system call was handled in
the middle of a non-blocking system call (but what's the point, since
no notification would be given if the signal was processed right
before or right after the system call).  

Still, I'd suggest that the old internet dictum of being conservative
in what you send and liberal in what you accept applies here.  If you
want your program to be robust and portable, check for EINTR.  

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386: Selectable Frequency of the Timer Interrupt

[Lee Revell]

On Mon, 2005-07-11 at 11:38 -0700, Martin J. Bligh wrote:
> >> Lots of people have switched from 2.4 to 2.6 (100 Hz to 1000 Hz) with no 
> >> impact in
> >> stability, AFAIK. (I only remember some weird warning about HZ with debian 
> >> woody's
> >> ps).
> >> 
> > 
> > Yes, that's called "progress" so no one complained.  Going back is
> > called a "regression".  People don't like those as much.
> 
> That's a very subjective viewpoint. Realize that this is a balancing
> act between latency and overhead ... and you're firmly only looking
> at one side of the argument, instead of taking a comprimise in the
> middle ...

I won't deny this for a second, I'm 100% arguing from the POV of one of
Alan's 'multimedia weenies'.  I do think that if you propose a big
change the burden of proof is on you to justify it, ideally with some
hard numbers.

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 15/27] Fix a couple of MAD code paths

[Hal Rosenstock]

Fixed locking to handle error posting MAD send work requests. 
Fixed handling canceling a MAD with an active work request.

Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

This patch depends on patch 14/27.

-- 
 mad.c |   28 ++--
 1 files changed, 14 insertions(+), 14 deletions(-)
diff -uprN linux-2.6.13-rc2-mm1/drivers/infiniband14/core/mad.c 
linux-2.6.13-rc2-mm1/drivers/infiniband15/core/mad.c
-- linux-2.6.13-rc2-mm1/drivers/infiniband14/core/mad.c 2005-07-09 
18:19:51.0 -0400
+++ linux-2.6.13-rc2-mm1/drivers/infiniband15/core/mad.c2005-07-09 
18:24:43.0 -0400
@@ -841,6 +841,7 @@ static int ib_send_mad(struct ib_mad_sen
 {
struct ib_mad_qp_info *qp_info;
struct ib_send_wr *bad_send_wr;
+   struct list_head *list;
unsigned long flags;
int ret;
 
@@ -850,22 +851,20 @@ static int ib_send_mad(struct ib_mad_sen
mad_send_wr->mad_list.mad_queue = &qp_info->send_queue;
 
spin_lock_irqsave(&qp_info->send_queue.lock, flags);
-   if (qp_info->send_queue.count++ < qp_info->send_queue.max_active) {
-   list_add_tail(&mad_send_wr->mad_list.list,
- &qp_info->send_queue.list);
-   spin_unlock_irqrestore(&qp_info->send_queue.lock, flags);
+   if (qp_info->send_queue.count < qp_info->send_queue.max_active) {
ret = ib_post_send(mad_send_wr->mad_agent_priv->agent.qp,
   &mad_send_wr->send_wr, &bad_send_wr);
-   if (ret) {
-   printk(KERN_ERR PFX "ib_post_send failed: %d\n", ret);
-   dequeue_mad(&mad_send_wr->mad_list);
-   }
+   list = &qp_info->send_queue.list;
} else {
-   list_add_tail(&mad_send_wr->mad_list.list,
- &qp_info->overflow_list);
-   spin_unlock_irqrestore(&qp_info->send_queue.lock, flags);
ret = 0;
+   list = &qp_info->overflow_list;
}
+
+   if (!ret) {
+   qp_info->send_queue.count++;
+   list_add_tail(&mad_send_wr->mad_list.list, list);
+   }
+   spin_unlock_irqrestore(&qp_info->send_queue.lock, flags);
return ret;
 }
 
@@ -2023,8 +2022,7 @@ static void cancel_mads(struct ib_mad_ag
 }
 
 static struct ib_mad_send_wr_private*
-find_send_by_wr_id(struct ib_mad_agent_private *mad_agent_priv,
-  u64 wr_id)
+find_send_by_wr_id(struct ib_mad_agent_private *mad_agent_priv, u64 wr_id)
 {
struct ib_mad_send_wr_private *mad_send_wr;
 
@@ -2047,6 +2045,7 @@ int ib_modify_mad(struct ib_mad_agent *m
struct ib_mad_agent_private *mad_agent_priv;
struct ib_mad_send_wr_private *mad_send_wr;
unsigned long flags;
+   int active;
 
mad_agent_priv = container_of(mad_agent, struct ib_mad_agent_private,
  agent);
@@ -2057,13 +2056,14 @@ int ib_modify_mad(struct ib_mad_agent *m
return -EINVAL;
}
 
+   active = (!mad_send_wr->timeout || mad_send_wr->refcount > 1);
if (!timeout_ms) {
mad_send_wr->status = IB_WC_WR_FLUSH_ERR;
mad_send_wr->refcount -= (mad_send_wr->timeout > 0);
}
 
mad_send_wr->send_wr.wr.ud.timeout_ms = timeout_ms;
-   if (!mad_send_wr->timeout || mad_send_wr->refcount > 1)
+   if (active)
mad_send_wr->timeout = msecs_to_jiffies(timeout_ms);
else
ib_reset_mad_timeout(mad_send_wr, timeout_ms);


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

Re: Realtime Preemption, 2.6.12, Beginners Guide?

[Alistair John Strachan]

On Monday 11 Jul 2005 15:16, Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > might be an incorrect printout of stack_left :( The esp looks more or
> > less normal. Not sure why it printed -52.
>
> here's the stack_left calculation:
>
> +   printk("ds: %04x   es: %04x   ss: %04x   preempt: %08x\n",
> +   regs->xds & 0x, regs->xes & 0x, ss,
> preempt_count()); +   printk("Process %s (pid: %d, threadinfo=%p
> task=%p stack_left=%ld worst_left=%ld)", +   current->comm,
> current->pid, current_thread_info(), current, +   (regs->esp &
> (THREAD_SIZE-1))-sizeof(struct thread_info), +  
> worst_stack_left);
>
> i cannot see anything wrong in it, but your esp is 0xc04cded0,
> THREAD_SIZE-1 is 0xfff, so the result should be:
>
>   0xed0-sizeof(struct thread_info).
>
> which should not be -52.

Actually, it's now pretty much confirmed that this ISN'T a stack overflow, not 
just because of what you've said (now and before), but also because I've 
tried an 8K stacks kernel and, sadly, there's no stand-out stack abusers.

It's annoying that this is so readily reproducible here, yet almost impossible 
to debug, and clearly a sideaffect of 4KSTACKS.. without it actually being a 
stack overflow.

I realise 4KSTACKS is a considerable rework of the IRQ handler, etc. and 
probably even more heavily modified by rt-preempt, but is there nothing else 
that can be tested before a serial console run?

-- 
Cheers,
Alistair.

personal:   alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:CS/CSim Undergraduate
contact:1F2 55 South Clerk Street,
Edinburgh. EH8 9PP.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 16/27] Add ib_create_ah_from_wc to IB verbs

[Hal Rosenstock]

Added new call: ib_create_ah_from_wc. Call will allocate an 
address handle given work completion information, including any
received GRH.

Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

This patch depends on patch 15/27.

-- 
 core/verbs.c   |   35 +++
 include/ib_mad.h   |9 --
 include/ib_verbs.h |   24 
 3 files changed, 59 insertions(+), 9 deletions(-)
diff -uprN linux-2.6.13-rc2-mm1/drivers/infiniband15/core/verbs.c 
linux-2.6.13-rc2-mm1/drivers/infiniband16/core/verbs.c
-- linux-2.6.13-rc2-mm1/drivers/infiniband15/core/verbs.c   2005-07-10 
11:09:37.0 -0400
+++ linux-2.6.13-rc2-mm1/drivers/infiniband16/core/verbs.c  2005-07-10 
11:43:44.0 -0400
@@ -41,6 +41,7 @@
 #include 
 
 #include 
+#include 
 
 /* Protection domains */
 
@@ -88,6 +89,40 @@ struct ib_ah *ib_create_ah(struct ib_pd 
 }
 EXPORT_SYMBOL(ib_create_ah);
 
+struct ib_ah *ib_create_ah_from_wc(struct ib_pd *pd, struct ib_wc *wc,
+  struct ib_grh *grh, u8 port_num)
+{
+   struct ib_ah_attr ah_attr;
+   u32 flow_class;
+   u16 gid_index;
+   int ret;
+
+   memset(&ah_attr, 0, sizeof ah_attr);
+   ah_attr.dlid = wc->slid;
+   ah_attr.sl = wc->sl;
+   ah_attr.src_path_bits = wc->dlid_path_bits;
+   ah_attr.port_num = port_num;
+   
+   if (wc->wc_flags & IB_WC_GRH) {
+   ah_attr.ah_flags = IB_AH_GRH;
+   ah_attr.grh.dgid = grh->dgid;
+
+   ret = ib_find_cached_gid(pd->device, &grh->sgid, &port_num,
+&gid_index);
+   if (ret)
+   return ERR_PTR(ret);
+
+   ah_attr.grh.sgid_index = (u8) gid_index;
+   flow_class = be32_to_cpu(&grh->version_tclass_flow);
+   ah_attr.grh.flow_label = flow_class & 0xF;
+   ah_attr.grh.traffic_class = (flow_class >> 20) & 0xFF;
+   ah_attr.grh.hop_limit = grh->hop_limit;
+   }
+
+   return ib_create_ah(pd, &ah_attr);
+}
+EXPORT_SYMBOL(ib_create_ah_from_wc);
+
 int ib_modify_ah(struct ib_ah *ah, struct ib_ah_attr *ah_attr)
 {
return ah->device->modify_ah ?
diff -uprN linux-2.6.13-rc2-mm1/drivers/infiniband15/include/ib_mad.h 
linux-2.6.13-rc2-mm1/drivers/infiniband16/include/ib_mad.h
-- linux-2.6.13-rc2-mm1/drivers/infiniband15/include/ib_mad.h   2005-07-09 
17:57:11.0 -0400
+++ linux-2.6.13-rc2-mm1/drivers/infiniband16/include/ib_mad.h  2005-07-10 
11:43:45.0 -0400
@@ -77,15 +77,6 @@
 #define IB_QP1_QKEY0x8001
 #define IB_QP_SET_QKEY 0x8000
 
-struct ib_grh {
-   u32 version_tclass_flow;
-   u16 paylen;
-   u8  next_hdr;
-   u8  hop_limit;
-   union ib_gidsgid;
-   union ib_giddgid;
-} __attribute__ ((packed));
-
 struct ib_mad_hdr {
u8  base_version;
u8  mgmt_class;
diff -uprN linux-2.6.13-rc2-mm1/drivers/infiniband15/include/ib_verbs.h 
linux-2.6.13-rc2-mm1/drivers/infiniband16/include/ib_verbs.h
-- linux-2.6.13-rc2-mm1/drivers/infiniband15/include/ib_verbs.h 2005-07-10 
10:55:59.0 -0400
+++ linux-2.6.13-rc2-mm1/drivers/infiniband16/include/ib_verbs.h
2005-07-10 11:43:45.0 -0400
@@ -289,6 +289,15 @@ struct ib_global_route {
u8  traffic_class;
 };
 
+struct ib_grh {
+   u32 version_tclass_flow;
+   u16 paylen;
+   u8  next_hdr;
+   u8  hop_limit;
+   union ib_gidsgid;
+   union ib_giddgid;
+};
+
 enum {
IB_MULTICAST_QPN = 0xff
 };
@@ -991,6 +1000,21 @@ int ib_dealloc_pd(struct ib_pd *pd);
 struct ib_ah *ib_create_ah(struct ib_pd *pd, struct ib_ah_attr *ah_attr);
 
 /**
+ * ib_create_ah_from_wc - Creates an address handle associated with the
+ *   sender of the specified work completion.
+ * @pd: The protection domain associated with the address handle.
+ * @wc: Work completion information associated with a received message.
+ * @grh: References the received global route header.  This parameter is
+ *   ignored unless the work completion indicates that the GRH is valid.
+ * @port_num: The outbound port number to associate with the address.
+ *
+ * The address handle is used to reference a local or global destination
+ * in all UD QP post sends.
+ */
+struct ib_ah *ib_create_ah_from_wc(struct ib_pd *pd, struct ib_wc *wc,
+  struct ib_grh *grh, u8 port_num);
+
+/**
  * ib_modify_ah - Modifies the address vector associated with an address
  *   handle.
  * @ah: The address handle to modify.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386: Selectable Frequency of the Timer Interrupt

[George Anzinger]

Martin J. Bligh wrote:

Lots of people have switched from 2.4 to 2.6 (100 Hz to 1000 Hz) with no impact 
in
stability, AFAIK. (I only remember some weird warning about HZ with debian 
woody's
ps).



Yes, that's called "progress" so no one complained.  Going back is
called a "regression".  People don't like those as much.



That's a very subjective viewpoint. Realize that this is a balancing
act between latency and overhead ... and you're firmly only looking
at one side of the argument, instead of taking a compromise in the
middle ...

If I start arguing for 100HZ on the grounds that it's much more efficient,
will that make 250/300 look much better to you? ;-)


I would like to interject an addition data point, and I will NOT be subjective. 
 The nature of the PIT is that it can _hit_ some frequencies better than 
others.  We have had complaints about repeating timers not keeping good time. 
These are not jitter issues, but drift issues.  The standard says we may not 
return early from a timer so any timer will either be on time or late.  The 
amount of lateness depends very much on the HZ value.  Here is what the values 
are for the standard CLOCK_TICK_RATE:


HZ  TICK RATE   jiffie(ns)  second(ns)   error (ppbillion)
 100 1193180100010 0
 200 1193180 598119600 19600
 250 1193180 4000250162500 62500
 500 1193180 19997031001851203   1851203
1000 1193180  9998481000847848847848

The jiffie values here are exactly what the kernel uses and are based on the 
best one can do with the PIT hardware.


I am not suggesting any given default HZ, but rather an argumentation of the 
help text that goes with it.  For those who want timers to repeat at one second 
(or multiples there of) this is useful info.


For you enjoyment I have attached the program used to print this.  It allows you 
to try additional values...



--
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/


#define NSEC_PER_SEC  10
//#define CLOCK_TICK_RATE /*1 */ 1193180
#define LATCH(CLOCK_TICK_RATE,HZ)  ((CLOCK_TICK_RATE + HZ/2) / HZ)
#define SH_DIV(NOM,DEN,LSH) (	((NOM / DEN) << LSH)			\
			 + (((NOM % DEN) << LSH) + DEN / 2) / DEN)
#define ACTHZ (SH_DIV (CLOCK_TICK_RATE, LATCH(CLOCK_TICK_RATE,HZ), 8))
#define TICK_NSEC (SH_DIV (100UL * 1000, ACTHZ, 8))


struct {
	int hz;
	int clocktickrate;
} vals[] = {{100, 1193180}, {200, 1193180}, {250, 1193180}, {500, 1193180}, {1000, 1193180},{0,0}};

void do_it(int hz,int tickrate)
{
	int HZ = hz;
	int CLOCK_TICK_RATE = tickrate;
	int tick_nsec = TICK_NSEC;
	int ticks_per_sec = NSEC_PER_SEC/tick_nsec;
	int sec_size = ticks_per_sec * tick_nsec;
	int one_sec_p;
	int err;

	if (sec_size < NSEC_PER_SEC)
		sec_size += tick_nsec;
	one_sec_p = sec_size;
	err = one_sec_p - NSEC_PER_SEC;
	printf( "%4d\t%8d\t%8d\t%10d\t%8d\n",hz, tickrate, tick_nsec, 
		one_sec_p, err);
}
	
void bail(void)
{
	printf("run as: as [hz [clock_tick_rate]]\n");
	exit(1);
}

main(int argc, char** argv)
{
	int i = 0;
	int phz = 0;
	int pcr = vals[0].clocktickrate;

	if (argc > 1) { 
		phz = atoi(argv[1]);
		if (!phz)
			bail();
	}
	if (argc > 2) {
		pcr = atoi(argv[2]);
		if (!pcr)
			bail();
	}

	printf("HZ  \tTICK RATE\tjiffie(ns)\tsecond(ns)\t error (ppbillion)\n");
	while(vals[i].hz) {
		do_it(vals[i].hz, vals[i].clocktickrate);
		i++;
	}
	if (phz)
		do_it(phz, pcr);
}

PS/2 mouse not working

[Sune Mølgaard]

Hi all.

I can't seem to get a new PS/2 mouse to give any input on 2.6.11.6. I 
have tried creating /dev/input/{mouse0,mouse1} apart from 
/dev/input/mice as per numbers in Documentation/devices.txt, and cat 
 gives no output when wiggling the mouse.


I have tried compiling psmouse as module and loading it, and I have 
tried compiling it into kernel. I have also chosen to have a /dev/psaux, 
that doesn't get any input either. Mouse seems to get detected, as per 
this snippet from dmesg:


...
mice: PS/2 mouse device common for all mice
...
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
...

Best regards,

Sune Mølgaard

--
Quitting vi is the most important command of that editor, and should be 
bound to something easy to type and available in all modes, for example 
the space bar.

- Per Abrahamsen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386: Selectable Frequency of the Timer Interrupt

[Lee Revell]

On Mon, 2005-07-11 at 14:39 -0600, Chris Friesen wrote:
> Lee Revell wrote:
> 
> > Tickless + sub HZ timers is a win for everyone, the multimedia people
> > get better latency, and the laptop people get to run longer.
> 
> IIRC it's not a win for many systems.  Throughput goes down due to timer 
> manipulation overhead.

Makes sense.  Anyway, this whole thread has been pretty hand wavey, I
propose that until we see some numbers from the HZ=250 advocates, we
leave the default alone.

Lee

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

Re: Realtime Preemption, 2.6.12, Beginners Guide?

[Ingo Molnar]

* Alistair John Strachan <[EMAIL PROTECTED]> wrote:

> It's annoying that this is so readily reproducible here, yet almost 
> impossible to debug, and clearly a sideaffect of 4KSTACKS.. without it 
> actually being a stack overflow.
> 
> I realise 4KSTACKS is a considerable rework of the IRQ handler, etc.  
> and probably even more heavily modified by rt-preempt, but is there 
> nothing else that can be tested before a serial console run?

4K stacks never really caused any trouble under PREEMPT_RT (or any other 
kernel i tried). It's not that complex either.

one useful thing could be to give me exact instructions on how to set up 
an openvpn network similar to yours, and what kind of workload to 
generate. Maybe i can reproduce it here.

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

Problems with more than 8 AMD Opteron Cores per System

[Oliver Weihe]

Hello,

I've two Iwill 8way Opteron equipped with 8 Opteron 875 CPUs each.
(In the past we build some systems with singlecore CPUs and they went
very well)

The Problem now is that the machines crash during boot when maxcpus is
greater than 8.
2.6.12-rc4 works well with maxcpus=8, with 9 or more it freezes after
"Testing NMI Watchdog... OK"

2.6.12-rc5 and above have more problems even with maxcpus=4 or less very
early during booting.

2.6.13-X crashes later during boot (from 2 to 16 cores it's the same
behavior)

The last I can so on the console (kernel 2.6.13-rc2-git4, maxcpus=2..16)
is:

NET: Registered protocol family 1
Using IPI Shortcut mode
int3:  [1] SMP
CPU4
Modules linked in:
Freeing unused kernel memory: 212k freed
Pid: 0, comm: swapper Not tainted 2.6.13-rc2-git4-default
RIP: 0010:[]

After that the machines are totally freezed.

With maxcpus=1 all (tested) versions >=2.6.12-rc3 are able to boot.

Any hints/ideas/what ever?

Regards,
   Oliver Weihe

P.S. if you answer CC me ;)

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

Re: Realtime Preemption, 2.6.12, Beginners Guide?

[Ingo Molnar]

* Ingo Molnar <[EMAIL PROTECTED]> wrote:

> > might be an incorrect printout of stack_left :( The esp looks more or 
> > less normal. Not sure why it printed -52.
> 
> here's the stack_left calculation:
> 
> +   printk("ds: %04x   es: %04x   ss: %04x   preempt: %08x\n",
> +   regs->xds & 0x, regs->xes & 0x, ss, preempt_count());
> +   printk("Process %s (pid: %d, threadinfo=%p task=%p stack_left=%ld 
> worst_left=%ld)",
> +   current->comm, current->pid, current_thread_info(), current,
> +   (regs->esp & (THREAD_SIZE-1))-sizeof(struct thread_info),
> +   worst_stack_left);
> 
> i cannot see anything wrong in it, [...]

that should be "esp", not "regs->esp". regs->esp is something different 
upon in-kernel faults. I've uploaded -27 with the fix - but it should 
only confirm that it's not a stack overflow.

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

Re: [RFC] RCU and CONFIG_PREEMPT_RT progress, part 2

[Paul E. McKenney]

Hello!

More progress on CONFIG_PREEMPT_RT-compatible RCU.

o   Continued prototyping Linux-kernel implementation, still
in the CONFIG_PREEMPT environment.

o   Reasonably reliably boots, still fragile.

o   Using workqueues to ensure that grace periods advance
even if synchronize_rcu() is never called.  This seems
like a bad choice in retrospect, will be recoding to
allow per-CPU scheduling-clock tick to advance the
grace period.  Doing this should simplify the code
and eliminate the need for workqueues.

o   Numerous boneheaded bugs fixed, a number remain.

o   A number of /proc entries provide debug info.  These
will likely be removed in the final version.

o   Shortcomings remain, will fix once I have flushed out
a few more bugs:

o   The rcu_read_lock() and rcu_read_unlock() primitives
still use heavy-weight atomic operations in the common
case (avoided only in the case of nested rcu_read_lock()
calls).  Longer term, I expect to make changes to avoid
the atomics in the (hopefully) common case where there
is no preemption of RCU read-side critical sections.
But simple things first!

o   The rcu_read_lock() and rcu_read_unlock() primitives
use memory-barrier instructions.  In theory, it is
possible to dispense with these, but doing so requires
some very strange code.  Not clear that this is practical.

o   Callbacks are queued globally.  Will be changing
to per-CPU callbacks.

Broken patch included below for your amusement.

Thanx, Paul

Not-signed-off-by: [EMAIL PROTECTED]

diff -urpN -X dontdiff linux-2.6.12-rc6/arch/i386/Kconfig 
linux-2.6.12-rc6-ctrRCU/arch/i386/Kconfig
--- linux-2.6.12-rc6/arch/i386/Kconfig  2005-06-17 16:34:16.0 -0700
+++ linux-2.6.12-rc6-ctrRCU/arch/i386/Kconfig   2005-06-25 11:45:40.0 
-0700
@@ -523,6 +523,34 @@ config PREEMPT
  Say Y here if you are building a kernel for a desktop, embedded
  or real-time system.  Say N if you are unsure.
 
+config PREEMPT_RCU
+   bool "Preemptible RCU read-side critical sections"
+   depends on PREEMPT
+   default y
+   help
+ This option reduces the latency of the kernel when reacting to
+ real-time or interactive events by allowing a low priority process to
+ be preempted even if it is in an RCU read-side critical section.
+ This allows applications to run more reliably even when the system is
+ under load.
+
+ Say Y here if you enjoy debugging random oopses.
+ Say N if, for whatever reason, you want your kernel to actually work.
+
+config RCU_STATS
+   bool "/proc stats for preemptible RCU read-side critical sections"
+   depends on PREEMPT_RCU
+   default y
+   help
+ This option provides /proc stats to provide debugging info.
+ real-time or interactive events by allowing a low priority process to
+ be preempted even if it is in an RCU read-side critical section.
+ This allows applications to run more reliably even when the system is
+ under load.
+
+ Say Y here if you want to see RCU stats in /proc
+ Say N if you are unsure.
+
 config PREEMPT_BKL
bool "Preempt The Big Kernel Lock"
depends on PREEMPT
diff -urpN -X dontdiff linux-2.6.12-rc6/fs/proc/proc_misc.c 
linux-2.6.12-rc6-ctrRCU/fs/proc/proc_misc.c
--- linux-2.6.12-rc6/fs/proc/proc_misc.c2005-06-17 16:35:03.0 
-0700
+++ linux-2.6.12-rc6-ctrRCU/fs/proc/proc_misc.c 2005-06-29 11:22:11.0 
-0700
@@ -549,6 +549,48 @@ void create_seq_entry(char *name, mode_t
entry->proc_fops = f;
 }
 
+#ifdef CONFIG_RCU_STATS
+int rcu_read_proc(char *page, char **start, off_t off,
+ int count, int *eof, void *data)
+{
+   int len;
+   extern int rcu_read_proc_data(char *page);
+
+   len = rcu_read_proc_data(page);
+   return proc_calc_metrics(page, start, off, count, eof, len);
+}
+
+int rcu_read_proc_gp(char *page, char **start, off_t off,
+int count, int *eof, void *data)
+{
+   int len;
+   extern int rcu_read_proc_gp_data(char *page);
+
+   len = rcu_read_proc_gp_data(page);
+   return proc_calc_metrics(page, start, off, count, eof, len);
+}
+
+int rcu_read_proc_wqgp(char *page, char **start, off_t off,
+  int count, int *eof, void *data)
+{
+   int len;
+   extern int rcu_read_proc_wqgp_data(char *page);
+
+   len = rcu_read_proc_wqgp_data(page);
+   return proc_calc_metrics(page, start, off, count, eof, len);
+}
+
+int rcu_read_proc_ptrs(char *page, char **start, off_t off,
+  int count, int *eof, void *data)
+{
+   int le

Re: [PATCH] Use device_for_each_child() to unregister devices in scsi_remove_target().

[Greg KH]

On Tue, Jul 05, 2005 at 05:38:50PM -0700, Patrick Mansfield wrote:
> Hi Greg / Patrick -
> 
> I'm getting an oops with current (pulled today) 2.6 git, the
> device_for_each_child() does not seem to be deletion safe.
> 
> We hold the klist in place via the n_ref, but the kobj (in the struct
> device for the struct scsi_target) containing it is freed when the
> kref->refcount goes to zero.

But we grab a reference to that object right before we call
device_for_each_child(), right?  Or am I missing something here?

thanks,

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

Re: arm: how to operate leds on zaurus?

[Russell King]

On Mon, Jul 11, 2005 at 09:34:54PM +0200, Pavel Machek wrote:
> Hi!
> 
> 2.6.12-rc5 (and newer) does not boot on sharp zaurus sl-5500. It
> blinks with green led, fast; what does it mean? I'd like to verify if
> it at least reaches .c code in setup.c. I inserted this code at
> begining of setup.c:674...
> 
> #define locomo_writel(val,addr) ({ *(volatile u16 *)(addr) = (val); })
> #define LOCOMO_LPT_TOFH 0x80
> #define LOCOMO_LED  0xe8
> #define LOCOMO_LPT0 0x00
> 
>   locomo_writel(LOCOMO_LPT_TOFH, LOCOMO_LPT0 + LOCOMO_LED);
> 
> ...but that does not seem to do a trick -- it only breaks the boot :-(

Basically because you do not have access to IO during the early boot.
The easiest debugging solution is to enable CONFIG_DEBUG_LL and
throw a printascii(printk_buf) into printk.c, after vscnprintf.
That might get you some boot messages through the serial port (if
it's implemented it correctly.)

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/29v2] Change ib_mad_send_wr_private struct

[Hal Rosenstock]

Have ib_mad_send_wr_private reference the private agent structure 
directly, rather than the exposed agent definition.  Remove unneeded
parameters to functions and simplify code were possible from this
change.

Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

This patch depends on patch 5/29.

--
 mad.c  |   22 ++--
 mad_priv.h |4 ++--
 2 files changed, 12 insertions(+), 14 deletions(-)
diff -uprN linux-2.6.13-rc2-mm1-5/drivers/infiniband/core/mad.c 
linux-2.6.13-rc2-mm1-6/drivers/infiniband/core/mad.c
-- linux-2.6.13-rc2-mm1-5/drivers/infiniband/core/mad.c 2005-07-11 
13:35:56.0 -0400
+++ linux-2.6.13-rc2-mm1-6/drivers/infiniband/core/mad.c2005-07-11 
13:36:16.0 -0400
@@ -839,8 +839,7 @@ void ib_free_send_mad(struct ib_mad_send
 }
 EXPORT_SYMBOL(ib_free_send_mad);
 
-static int ib_send_mad(struct ib_mad_agent_private *mad_agent_priv,
-  struct ib_mad_send_wr_private *mad_send_wr)
+static int ib_send_mad(struct ib_mad_send_wr_private *mad_send_wr)
 {
struct ib_mad_qp_info *qp_info;
struct ib_send_wr *bad_send_wr;
@@ -848,7 +847,7 @@ static int ib_send_mad(struct ib_mad_age
int ret;
 
/* Set WR ID to find mad_send_wr upon completion */
-   qp_info = mad_agent_priv->qp_info;
+   qp_info = mad_send_wr->mad_agent_priv->qp_info;
mad_send_wr->send_wr.wr_id = (unsigned long)&mad_send_wr->mad_list;
mad_send_wr->mad_list.mad_queue = &qp_info->send_queue;
 
@@ -857,7 +856,7 @@ static int ib_send_mad(struct ib_mad_age
list_add_tail(&mad_send_wr->mad_list.list,
  &qp_info->send_queue.list);
spin_unlock_irqrestore(&qp_info->send_queue.lock, flags);
-   ret = ib_post_send(mad_agent_priv->agent.qp,
+   ret = ib_post_send(mad_send_wr->mad_agent_priv->agent.qp,
   &mad_send_wr->send_wr, &bad_send_wr);
if (ret) {
printk(KERN_ERR PFX "ib_post_send failed: %d\n", ret);
@@ -950,7 +949,7 @@ int ib_post_send_mad(struct ib_mad_agent
mad_send_wr->wr_id = mad_send_wr->send_wr.wr_id;
mad_send_wr->send_wr.next = NULL;
mad_send_wr->tid = send_wr->wr.ud.mad_hdr->tid;
-   mad_send_wr->agent = mad_agent;
+   mad_send_wr->mad_agent_priv = mad_agent_priv;
/* Timeout will be updated after send completes */
mad_send_wr->timeout = msecs_to_jiffies(send_wr->wr.
ud.timeout_ms);
@@ -966,7 +965,7 @@ int ib_post_send_mad(struct ib_mad_agent
  &mad_agent_priv->send_list);
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
 
-   ret = ib_send_mad(mad_agent_priv, mad_send_wr);
+   ret = ib_send_mad(mad_send_wr);
if (ret) {
/* Fail send request */
spin_lock_irqsave(&mad_agent_priv->lock, flags);
@@ -1742,13 +1741,14 @@ static void adjust_timeout(struct ib_mad
}
 }
 
-static void wait_for_response(struct ib_mad_agent_private *mad_agent_priv,
- struct ib_mad_send_wr_private *mad_send_wr )
+static void wait_for_response(struct ib_mad_send_wr_private *mad_send_wr)
 {
+   struct ib_mad_agent_private *mad_agent_priv;
struct ib_mad_send_wr_private *temp_mad_send_wr;
struct list_head *list_item;
unsigned long delay;
 
+   mad_agent_priv = mad_send_wr->mad_agent_priv;
list_del(&mad_send_wr->agent_list);
 
delay = mad_send_wr->timeout;
@@ -1781,9 +1781,7 @@ static void ib_mad_complete_send_wr(stru
struct ib_mad_agent_private *mad_agent_priv;
unsigned long   flags;
 
-   mad_agent_priv = container_of(mad_send_wr->agent,
- struct ib_mad_agent_private, agent);
-
+   mad_agent_priv = mad_send_wr->mad_agent_priv;
spin_lock_irqsave(&mad_agent_priv->lock, flags);
if (mad_send_wc->status != IB_WC_SUCCESS &&
mad_send_wr->status == IB_WC_SUCCESS) {
@@ -1794,7 +1792,7 @@ static void ib_mad_complete_send_wr(stru
if (--mad_send_wr->refcount > 0) {
if (mad_send_wr->refcount == 1 && mad_send_wr->timeout &&
mad_send_wr->status == IB_WC_SUCCESS) {
-   wait_for_response(mad_agent_priv, mad_send_wr);
+   wait_for_response(mad_send_wr);
}
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
return;
diff -uprN linux-2.6.13-rc2-mm1-5/drivers/infiniband/core/mad_priv.h 
linux-2.6.13-rc2-mm1-6/drivers/infiniband/core/mad_priv.h
-- linux-2.6.13-rc2-mm1-5/drivers/infiniband/core/mad_priv.h2005-06-29 
19:00:53.0 -0400
+++ linux-2.6.13-rc2-mm1-6/drivers/i

Re: [PATCH 0/29v2] InfiniBand core update

[David S. Miller]

NO No more huge patch bombs to linux-kernel@vger.kernel.org
people!  Condense your changes into more manageable pieces
or only submit smaller groups of changes at a time.

You people doing this are absolutely killing vger.kernel.org.

Every patch you post has to go to 5000+ subscribers, so please
keep this in mind when posting multiple patches.  If you feel
the need to send, say, more than 15 patches at once, reconsider.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: arm: how to operate leds on zaurus?

[Pavel Machek]

Hi!

> > 2.6.12-rc5 (and newer) does not boot on sharp zaurus sl-5500. It
> > blinks with green led, fast; what does it mean? I'd like to verify if
> > it at least reaches .c code in setup.c. I inserted this code at
> > begining of setup.c:674...
> > 
> > #define locomo_writel(val,addr) ({ *(volatile u16 *)(addr) = (val); })
> > #define LOCOMO_LPT_TOFH 0x80
> > #define LOCOMO_LED  0xe8
> > #define LOCOMO_LPT0 0x00
> > 
> >   locomo_writel(LOCOMO_LPT_TOFH, LOCOMO_LPT0 + LOCOMO_LED);
> > 
> > ...but that does not seem to do a trick -- it only breaks the boot :-(
> 
> Basically because you do not have access to IO during the early boot.
> The easiest debugging solution is to enable CONFIG_DEBUG_LL and
> throw a printascii(printk_buf) into printk.c, after vscnprintf.
> That might get you some boot messages through the serial port (if
> it's implemented it correctly.)

I'm afraid I do not have serial cable :-(. I'll try to get one [erik,
do you have one you don't need?], but zaurus has "little" nonstandard
connector.

Would code above work if executed later?
Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiser4 plugins

[David Masover]

Stefan Smietanowski wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Ok, still haven't heard much discussion of metafs vs file-as-directory,
but it seems like it'd be easier in metafs.



Why not implement it inside the directory containg the file ?

Ie the metadata for /home/stesmi/foo is in /home/stesmi/.meta/foo

This should be suit both camps I'd think?


You still need to figure out the parent of "foo", which isn't 
necessarily easy, especially considering that even if we store a link to 
the parent, it will be inside the metadata.  Then you have a 
chicken-and-egg situation.


Both camps seem to want to allow easy access to the metadata of a file, 
whether we're given that file as an inode or as a pathname.  That's why 
I suggested /meta/vfs and /meta/inode -- sometimes I want to look up a 
file by name, and sometimes by inode, but either way, I should be able 
to get its metadata.



I mean, editing something is easy and you don't have to "know" how
to navigate /meta


But then you have to "know" how to navigate .meta, and more importantly, 
how to find .meta



and you don't have the clash of files vs metadata
(is /meta/vfs/home/stesmi/foo a file or an attribute called foo of
the dir stesmi ?).


So, how do I get metadata of a directory?  If the metadata for /home/me 
is in /home/.meta/me, and the metadata for /home is in /.meta/home, then 
where is the metadata for / ?



/home/stesmi/foo <- dir
/home/stesmi/.meta/foo <- "dir" containing all metadata
/home/stesmi/.meta/foo/attrib <- some attribute called attrib
/home/stesmi/foo/bar <- file
/home/stesmi/foo/.meta/bar <- "dir" containg all metadata
/home/stesmi/foo/.meta/bar/attrib <- some attribute called attrib


[...]


If this has already been taken up, I must've missed it.


It looks a lot like how I suggested we resolve the ambiguity within 
/meta/vfs, only I called it '...' instead of '.meta'.


Either way, the major challenge to this method is not so much whether 
it'd work, but how to choose a suitable delimiter?  The delimiter must 
be standard if we're going to have apps develop for it, and it must not 
be used in the name of any existing file or directory.


I had a long essay here on how '.meta' breaks every recursive operation 
on directories (rm -rf, tar, mkisofs), but I deleted it when I 
remembered that I played around with the alpha/beta reiser4 which had a 
'metas' dir that did the same thing, but was hidden from the normal 
directory listing.  'cd metas' worked, 'ls metas' worked, but 'ls' 
showed no directory called 'metas'.


I don't *think* there are any apps that will break if you tell them to 
open a path that doesn't exist in a directory listing.  That is, typing 
'vim /home/metas/acl' should always let me edit the acl on /home, and 
vim should never complain about how /home/metas doesn't show up in 
/home.  A program would have to be pretty retarded to fail on something 
like that.


But, we have to support some pretty retarded programs.  That is why I 
like /meta -- the default view is a completely POSIX-compliant tree that 
works with tar, and even the /meta view is POSIX-compliant, even if it'd 
be a bad idea to tar it.  Then we don't have to worry at all about 
stupid programs.


How much should we be worrying about this particular brand of stupidity? 
 And what's a good delimiter?



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.12/46 - Release Date: 7/11/2005

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/29v2] InfiniBand core update

[Andrew Morton]

Hal Rosenstock <[EMAIL PROTECTED]> wrote:
>
> This is version 2 of a patch series to get the Infiniband core up to
> date.

Well that was interesting.

- All the patches had mangled headers:

-- linux-2.6.13-rc2-mm1-16/...
+++ linux-2.6.13-rc2-mm1-17/...

  instead of

--- linux-2.6.13-rc2-mm1-16/...
+++ linux-2.6.13-rc2-mm1-17/...

  Which I fixed up.

- The second patch didn't apply.  I fixed that too.

- The patches add lots of trailing whitespace.  I habitually trim that
  off, figuring that any downstream merging hassle which that causes is
  just punishment ;)


Please check that it all landed OK in the next -mm.

I've hung on to Tom Duffy's patch pending a test compilation.

I'll tentatively consider this material to be not-for-2.6.13?

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

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[Russell King]

On Mon, Jul 11, 2005 at 02:00:57PM -0600, Alex Williamson wrote:
> On Mon, 2005-07-11 at 20:46 +0100, Russell King wrote:
> > There was a bug in this area - does it happen with latest and greatest
> > kernels?
> 
>Yes, I'm using a git pull from ~5hrs ago.  How recent was the bug
> fix?  It worked fine before I applied David's patch, the A2 UART was
> detected as a 16550A.  Thanks,

The fix for this went in on 21st May 2005, so obviously it's not
actually fixed.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 11/29v2] Simplify calling of list_del in MAD

[Hal Rosenstock]

Simplify calling of list_del.


Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

This patch depends on patch 10/29.

--
 mad.c |3 +--
 1 files changed, 1 insertion(+), 2 deletions(-)
diff -uprN linux-2.6.13-rc2-mm1-10/drivers/infiniband/core/mad.c 
linux-2.6.13-rc2-mm1-11/drivers/infiniband/core/mad.c
-- linux-2.6.13-rc2-mm1-10/drivers/infiniband/core/mad.c2005-07-11 
13:37:54.0 -0400
+++ linux-2.6.13-rc2-mm1-11/drivers/infiniband/core/mad.c   2005-07-11 
13:38:06.0 -0400
@@ -2188,7 +2188,6 @@ static int retry_send(struct ib_mad_send
 
if (!ret) {
mad_send_wr->refcount++;
-   list_del(&mad_send_wr->agent_list);
list_add_tail(&mad_send_wr->agent_list,
  &mad_send_wr->mad_agent_priv->send_list);
}
@@ -2223,10 +,10 @@ static void timeout_sends(void *data)
break;
}
 
+   list_del(&mad_send_wr->agent_list);
if (!retry_send(mad_send_wr))
continue;
 
-   list_del(&mad_send_wr->agent_list);
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
 
mad_send_wc.wr_id = mad_send_wr->wr_id;


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

[PATCH 10/29v2] Add automatic retries to MAD layer

[Hal Rosenstock]

Add automatic retries to MAD layer. 
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

This patch depends on patch 9/29.

--
 core/mad.c |   26 +-
 core/mad_priv.h|2 ++
 core/sa_query.c|3 ++-
 core/user_mad.c|1 +
 include/ib_verbs.h |1 +
 5 files changed, 31 insertions(+), 2 deletions(-)
diff -uprN linux-2.6.13-rc2-mm1-9/drivers/infiniband/core/mad.c 
linux-2.6.13-rc2-mm1-10/drivers/infiniband/core/mad.c
-- linux-2.6.13-rc2-mm1-9/drivers/infiniband/core/mad.c 2005-07-11 
13:37:10.0 -0400
+++ linux-2.6.13-rc2-mm1-10/drivers/infiniband/core/mad.c   2005-07-11 
13:37:54.0 -0400
@@ -954,7 +954,7 @@ int ib_post_send_mad(struct ib_mad_agent
/* Timeout will be updated after send completes */
mad_send_wr->timeout = msecs_to_jiffies(send_wr->wr.
ud.timeout_ms);
-   mad_send_wr->retry = 0;
+   mad_send_wr->retries = mad_send_wr->send_wr.wr.ud.retries;
/* One reference for each work request to QP + response */
mad_send_wr->refcount = 1 + (mad_send_wr->timeout > 0);
mad_send_wr->status = IB_WC_SUCCESS;
@@ -2174,6 +2174,27 @@ local_send_completion:
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
 }
 
+static int retry_send(struct ib_mad_send_wr_private *mad_send_wr)
+{
+   int ret;
+
+   if (!mad_send_wr->retries--)
+   return -ETIMEDOUT;
+
+   mad_send_wr->timeout = msecs_to_jiffies(mad_send_wr->send_wr.
+   wr.ud.timeout_ms);
+
+   ret = ib_send_mad(mad_send_wr);
+
+   if (!ret) {
+   mad_send_wr->refcount++;
+   list_del(&mad_send_wr->agent_list);
+   list_add_tail(&mad_send_wr->agent_list,
+ &mad_send_wr->mad_agent_priv->send_list);
+   }
+   return ret;
+}
+
 static void timeout_sends(void *data)
 {
struct ib_mad_agent_private *mad_agent_priv;
@@ -2202,6 +2223,9 @@ static void timeout_sends(void *data)
break;
}
 
+   if (!retry_send(mad_send_wr))
+   continue;
+
list_del(&mad_send_wr->agent_list);
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
 
diff -uprN linux-2.6.13-rc2-mm1-9/drivers/infiniband/core/mad_priv.h 
linux-2.6.13-rc2-mm1-10/drivers/infiniband/core/mad_priv.h
-- linux-2.6.13-rc2-mm1-9/drivers/infiniband/core/mad_priv.h2005-07-09 
16:48:05.0 -0400
+++ linux-2.6.13-rc2-mm1-10/drivers/infiniband/core/mad_priv.h  2005-07-09 
17:15:40.0 -0400
@@ -123,6 +123,7 @@ struct ib_mad_send_wr_private {
u64 wr_id;  /* client WR ID */
u64 tid;
unsigned long timeout;
+   int retries;
int retry;
int refcount;
enum ib_wc_status status;
@@ -136,6 +137,7 @@ struct ib_mad_local_private {
struct ib_sge sg_list[IB_MAD_SEND_REQ_MAX_SG];
u64 wr_id;  /* client WR ID */
u64 tid;
+   int retries;
 };
 
 struct ib_mad_mgmt_method_table {
diff -uprN linux-2.6.13-rc2-mm1-9/drivers/infiniband/core/sa_query.c 
linux-2.6.13-rc2-mm1-10/drivers/infiniband/core/sa_query.c
-- linux-2.6.13-rc2-mm1-9/drivers/infiniband/core/sa_query.c2005-07-10 
16:21:55.0 -0400
+++ linux-2.6.13-rc2-mm1-10/drivers/infiniband/core/sa_query.c  2005-07-10 
16:22:13.0 -0400
@@ -462,7 +462,8 @@ static int send_mad(struct ib_sa_query *
 .mad_hdr = &query->mad->mad_hdr,
 .remote_qpn  = 1,
 .remote_qkey = IB_QP1_QKEY,
-.timeout_ms  = timeout_ms
+.timeout_ms  = timeout_ms,
+.retries = 0 
 }
 }
};
diff -uprN linux-2.6.13-rc2-mm1-9/drivers/infiniband/core/user_mad.c 
linux-2.6.13-rc2-mm1-10/drivers/infiniband/core/user_mad.c
-- linux-2.6.13-rc2-mm1-9/drivers/infiniband/core/user_mad.c2005-06-29 
19:00:53.0 -0400
+++ linux-2.6.13-rc2-mm1-10/drivers/infiniband/core/user_mad.c  2005-07-09 
17:14:46.0 -0400
@@ -322,6 +322,7 @@ static ssize_t ib_umad_write(struct file
wr.wr.ud.remote_qpn  = be32_to_cpu(packet->mad.qpn);
wr.wr.ud.remote_qkey = be32_to_cpu(packet->mad.qkey);
wr.wr.ud.timeout_ms  = packet->mad.timeout_ms;
+   wr.wr.ud.retries = 0;
 
wr.wr_id= (unsigned long) packet;
 
diff -uprN linux-2.6.13-rc2-mm1-9/drivers/infiniband/include/ib_verbs.h 
linux-2.6.13-rc2-mm1-10/drivers/infiniband/include/ib_verbs.h
-- linux-2.6.13-rc2-mm1-9/drivers/infiniband/include/ib_verbs.h 2005-07-10 
11:11:43.0 -0400
+++ linux-2.6.13-rc2-mm1-10/drive

[PATCH 14/29v2] Optimize canceling a MAD

[Hal Rosenstock]

Optimize canceling a MAD. 
- Eliminate searching timeout list in cancel case.
- Remove duplicate calls to queue work item.
- Eliminate resending a MAD before MAD is completed.

Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

This patch depends on patch 13/29.

--
 mad.c |   21 +--
 1 files changed, 13 insertions(+), 8 deletions(-)
diff -uprN linux-2.6.13-rc2-mm1-13/drivers/infiniband/core/mad.c 
linux-2.6.13-rc2-mm1-14/drivers/infiniband/core/mad.c
-- linux-2.6.13-rc2-mm1-13/drivers/infiniband/core/mad.c2005-07-11 
13:38:30.0 -0400
+++ linux-2.6.13-rc2-mm1-14/drivers/infiniband/core/mad.c   2005-07-11 
13:38:42.0 -0400
@@ -1754,14 +1754,18 @@ static void wait_for_response(struct ib_
delay = mad_send_wr->timeout;
mad_send_wr->timeout += jiffies;
 
-   list_for_each_prev(list_item, &mad_agent_priv->wait_list) {
-   temp_mad_send_wr = list_entry(list_item,
- struct ib_mad_send_wr_private,
- agent_list);
-   if (time_after(mad_send_wr->timeout,
-  temp_mad_send_wr->timeout))
-   break;
+   if (delay) {
+   list_for_each_prev(list_item, &mad_agent_priv->wait_list) {
+   temp_mad_send_wr = list_entry(list_item,
+   struct ib_mad_send_wr_private,
+   agent_list);
+   if (time_after(mad_send_wr->timeout,
+  temp_mad_send_wr->timeout))
+   break;
+   }
}
+   else
+   list_item = &mad_agent_priv->wait_list;
list_add(&mad_send_wr->agent_list, list_item);
 
/* Reschedule a work item if we have a shorter timeout */
@@ -2197,7 +2201,8 @@ static void timeout_sends(void *data)
}
 
list_del(&mad_send_wr->agent_list);
-   if (!retry_send(mad_send_wr))
+   if (mad_send_wr->status == IB_WC_SUCCESS &&
+   !retry_send(mad_send_wr))
continue;
 
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);


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

Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[Chris Friesen]

Lee Revell wrote:


Tickless + sub HZ timers is a win for everyone, the multimedia people
get better latency, and the laptop people get to run longer.


IIRC it's not a win for many systems.  Throughput goes down due to timer 
manipulation overhead.


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

[GIT PATCH] I2C patches for 2.6.13-rc2

[Greg KH]

Here are some i2c patches that have been in the -mm tree for a while.
They fix a number of different bugs.  But the majority of this patchest
(in diffstat volume) is moving the i2c chip drivers into the hwmon
directory.  I used your 'dotest' script to acomplish this, but don't
know if git registered that these files were just renamed or not.  If I
should do it a different way, please let me know and I'll regenerate the
tree.

Please pull from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/
or from:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/
if it isn't synced up yet.

The full patch series will sent to the linux-kernel and sensors mailing lists,
if anyone wants to see them.

thanks,

greg k-h

 Documentation/hwmon/adm1021 |  111 ++
 Documentation/hwmon/adm1025 |   51 +
 Documentation/hwmon/adm1026 |   93 +
 Documentation/hwmon/adm1031 |   35 
 Documentation/hwmon/adm9240 |  177 +++
 Documentation/hwmon/asb100  |   72 +
 Documentation/hwmon/ds1621  |  108 ++
 Documentation/hwmon/fscher  |  169 +++
 Documentation/hwmon/gl518sm |   74 +
 Documentation/hwmon/it87|   96 ++
 Documentation/hwmon/lm63|   57 +
 Documentation/hwmon/lm75|   65 +
 Documentation/hwmon/lm77|   22 
 Documentation/hwmon/lm78|   82 +
 Documentation/hwmon/lm80|   56 +
 Documentation/hwmon/lm83|   76 +
 Documentation/hwmon/lm85|  221 
 Documentation/hwmon/lm87|   73 +
 Documentation/hwmon/lm90|  121 ++
 Documentation/hwmon/lm92|   37 
 Documentation/hwmon/max1619 |   29 
 Documentation/hwmon/pc87360 |  189 +++
 Documentation/hwmon/sis5595 |  106 ++
 Documentation/hwmon/smsc47b397  |  158 +++
 Documentation/hwmon/smsc47m1|   52 +
 Documentation/hwmon/sysfs-interface |  274 +
 Documentation/hwmon/userspace-tools |   39 
 Documentation/hwmon/via686a |   65 +
 Documentation/hwmon/w83627hf|   66 +
 Documentation/hwmon/w83781d |  402 
 Documentation/hwmon/w83l785ts   |   39 
 Documentation/i2c/chips/adm1021 |  111 --
 Documentation/i2c/chips/adm1025 |   51 -
 Documentation/i2c/chips/adm1026 |   93 -
 Documentation/i2c/chips/adm1031 |   35 
 Documentation/i2c/chips/adm9240 |  177 ---
 Documentation/i2c/chips/asb100  |   72 -
 Documentation/i2c/chips/ds1621  |  108 --
 Documentation/i2c/chips/fscher  |  169 ---
 Documentation/i2c/chips/gl518sm |   74 -
 Documentation/i2c/chips/it87|   96 --
 Documentation/i2c/chips/lm63|   57 -
 Documentation/i2c/chips/lm75|   65 -
 Documentation/i2c/chips/lm77|   22 
 Documentation/i2c/chips/lm78|   82 -
 Documentation/i2c/chips/lm80|   56 -
 Documentation/i2c/chips/lm83|   76 -
 Documentation/i2c/chips/lm85|  221 
 Documentation/i2c/chips/lm87|   73 -
 Documentation/i2c/chips/lm90|  121 --
 Documentation/i2c/chips/lm92|   37 
 Documentation/i2c/chips/max1619 |   29 
 Documentation/i2c/chips/max6875 |   22 
 Documentation/i2c/chips/pc87360 |  189 ---
 Documentation/i2c/chips/sis5595 |  106 --
 Documentation/i2c/chips/smsc47b397  |  158 ---
 Documentation/i2c/chips/smsc47m1|   52 -
 Documentation/i2c/chips/via686a |   65 -
 Documentation/i2c/chips/w83627hf|   66 -
 Documentation/i2c/chips/w83781d |  402 
 Documentation/i2c/chips/w83l785ts   |   39 
 Documentation/i2c/dev-interface |   15 
 Documentation/i2c/sysfs-interface   |  274 -
 Documentation/i2c/userspace-tools   |   39 
 Documentation/i2c/writing-clients   |7 
 arch/arm/Kconfig|2 
 arch/h8300/Kconfig  |2 
 arch/sparc64/Kconfig|2 
 drivers/Kconfig |2 
 drivers/Makefile|1 
 drivers/hwmon/Kconfig   |  420 
 drivers/hwmon/Makefile  |   44 
 drivers/hwmon/adm1021.c |  402 
 drivers/hwmon/adm1025.c |  577 
 drivers/hwmon/adm1026.c | 1714 
 drivers/hwmon/adm1031.c |  977 
 drivers/hwmon/adm9240.c |  791 
 drivers/hwmon/asb100.c  | 1065 ++
 drivers/hwmon/atxp1.c   |  361 +++
 drivers/hwmon/ds1621.c  |  341 +++
 drivers/hwmon/fscher.c  |  691 ++
 drivers/hwmon/fscpos.c  |  641 +
 drivers/hwmon/gl518sm.c |  604 
 drivers/hwmon/gl520sm.c |  769 
 drivers/hwmon/it87.c| 1184 
 drivers/hwmon/lm63.c|  597 
 drivers/hwmon/lm75.c