Re: Boot problems with pata_via driver

[Patrick Ale]

On 1/29/07, Patrick Ale <[EMAIL PROTECTED]> wrote:

On 1/29/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 28, 2007 at 12:47:18PM +0100, Patrick Ale wrote:

>
> Hi Patrick,


 Morning!
 The 2.6.19 was self-compiled, using the gentoo-sources-rc4 AND using
 the vanilla 2.6.19 from kernel.org (I was recommended to use vanilla
 sources with my ATI drivers), both worked.

 2.6.20 is self compiled to. I will give you the kernel output when I
 am at home, I will have to connect a serial cable to my laptop and use
 the scrollbuffer since on a kernel panic or system crash my keyboard
 leds start to blink, which the kernel sees as a device addressing
 hardware directly and giving me a kernel message for every blink :D

 Oh, and pata_via is the ONLY driver I have compiled built-in,
 regarding libsata. As I mentioned in previous mails I have quite some
 controllers and disks, but pata_via (my onboard IDE) has only two
drives attaches, on IDE0 (in 2.6.19 ata0) my boot disk

 I also tried to boot with scsi_mod.scan=sync, this didnt work either

 More info follows, thanks for your time allready :)


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

Re: 2.6.20-rc6: known unfixed regressions (v2) (part 2)

[Linus Torvalds]

On Mon, 29 Jan 2007, Mike Galbraith wrote:
> 
> Unfortunately, I'm git impaired.  I am rummaging as we speak though.

Ok, I'm personally heading to bed, but it rally should be as simple as

 - get the git tree in the first place
 - do

git bisect good v2.6.19
git bisect bad v2.6.20-rc2
.. it will pick a point for you to try ..
.. compile, boot, test ..

"git bisect {good|bad}" depending on results

 - until (found)

(Of course, you should check that -rc2 really is bad to make sure. I think 
that's what Uwe reported, though. And I don't think we've done anything 
after -rc2 that could impact this, so I don't doubt it).

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

Re: 2.6.20-rc6-mm1

[Herbert Xu]

On Sun, Jan 28, 2007 at 10:43:12PM -0800, Andrew Morton wrote:
>
> > IIRC Ingo had made fixes for the networking stack in his rt tree since
> > the networking code assumes in lots of places that rcu_read_lock
> > disables preemption.
> 
> oh.  We'd better find those fixes then.  I wonder what other code made that
> (rather hacky) assumption?  I guess we have enough debug stuff in there to
> find out..

Actually, maybe I was confusing this with the fixes Ingo had for
local_bh_disable vs. preemption in the -rt tree.  Ingo, do you
have preemptible RCU support in your -rt tree and if so did you
have to fix the networking stack to behave correctly with it?

It could also be that the fixes for local_bh_disable also masked
any problems that would trigger under preemptible RCU.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc6: known unfixed regressions (v2) (part 2)

[Mike Galbraith]

On Sun, 2007-01-28 at 22:48 -0800, Andrew Morton wrote:
> On Mon, 29 Jan 2007 07:26:03 +0100
> Mike Galbraith <[EMAIL PROTECTED]> wrote:
> 
> > FWIW, I just tried it with 2.6.20-rc6, and can confirm.  Once nero is
> > run, the kernel never gives up retrying whatever command failed, so I
> > get...
> > 
> > [ 4362.972995] hdd: status error: status=0x58 { DriveReady SeekComplete
> > DataRequest }
> > [ 4362.981475] ide: failed opcode was: unknown
> > [ 4362.986183] hdd: drive not ready for command
> > 
> > endlessly.
> 
> Do you have time to bisect it?

Unfortunately, I'm git impaired.  I am rummaging as we speak though.

-Mike

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

Re: [xfs-masters] [PATCH} XFS: Remove placeholders for unimplemented functionality.

[Christoph Hellwig]

On Sun, Jan 28, 2007 at 10:58:50PM -0600, Eric Sandeen wrote:
> >-#else
> > #define xfs_cap_vset(v,p,sz)(-EOPNOTSUPP)
> > #define xfs_cap_vget(v,p,sz)(-EOPNOTSUPP)
> > #define xfs_cap_vremove(v)  (-EOPNOTSUPP)
> > #define _CAP_EXISTS (NULL)
> >-#endif
> >
> > #endif  /* __KERNEL__ */
> 
> By the time you do this, probably may as well remove the whole file; the 
> leftover 4 definitions never seem to be used.
> 
> The same may go for xfs_mac.h.

Agreed.  As Dave said if we get this functionality on Linux it will most
likely be handled at a different level, so keeping the old IRIX-style hooks
is rather pointless.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc6: known unfixed regressions (v2) (part 2)

[Andrew Morton]

On Mon, 29 Jan 2007 07:26:03 +0100
Mike Galbraith <[EMAIL PROTECTED]> wrote:

> FWIW, I just tried it with 2.6.20-rc6, and can confirm.  Once nero is
> run, the kernel never gives up retrying whatever command failed, so I
> get...
> 
> [ 4362.972995] hdd: status error: status=0x58 { DriveReady SeekComplete
> DataRequest }
> [ 4362.981475] ide: failed opcode was: unknown
> [ 4362.986183] hdd: drive not ready for command
> 
> endlessly.

Do you have time to bisect 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: 2.6.20-rc6-mm1

[Andrew Morton]

On Mon, 29 Jan 2007 16:29:29 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:

> On Mon, Jan 29, 2007 at 04:17:44PM +1100, Herbert Xu wrote:
> > Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> > 
> > > Jan 28 22:58:29 euridica kernel: BUG: using smp_processor_id() in 
> > > preemptible [0001] code: yum-updatesd/2846
> > > Jan 28 22:58:29 euridica kernel: caller is nf_conntrack_in+0x363/0x47f 
> > > [nf_conntrack]
> > > Jan 28 22:58:29 euridica kernel:  [] 
> > > show_trace_log_lvl+0x1a/0x2f
> > > Jan 28 22:58:29 euridica kernel:  [] show_trace+0x12/0x14
> > > Jan 28 22:58:29 euridica kernel:  [] dump_stack+0x16/0x18
> > > Jan 28 22:58:29 euridica kernel:  [] 
> > > debug_smp_processor_id+0xb3/0xc8
> > > Jan 28 22:58:29 euridica kernel:  [] 
> > > nf_conntrack_in+0x363/0x47f [nf_conntrack]
> > > Jan 28 22:58:29 euridica kernel:  [] 
> > > ipv4_conntrack_local+0x53/0x5b [nf_conntrack_ipv4]
> > > Jan 28 22:58:29 euridica kernel:  [] nf_iterate+0x36/0x67
> > > Jan 28 22:58:29 euridica kernel:  [] nf_hook_slow+0x52/0xbe
> > 
> > This shouldn't have happened.  nf_hook_slow calls nf_iterate and
> > therefore everything under it with preemption disabled.  So something
> > must've reenabled it before hitting nf_conntrack_in.
> 
> Does mm now have the preemptible RCU stuff? If so that would certainly
> explain this.

It does,

> IIRC Ingo had made fixes for the networking stack in his rt tree since
> the networking code assumes in lots of places that rcu_read_lock
> disables preemption.

oh.  We'd better find those fixes then.  I wonder what other code made that
(rather hacky) assumption?  I guess we have enough debug stuff in there to
find out..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 PA Semi PCI vendor id

[Andrew Morton]

On Mon, 29 Jan 2007 00:14:24 -0600
Olof Johansson <[EMAIL PROTECTED]> wrote:

> Add PA Semi's PCI vendor ID (0x1959).
> 
> 
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
> 
> ---
> 
> Submitting this separately -- several drivers that have recently been
> posted could make use of it. I didn't want to include it in each of them
> and have patch conflicts when they're combined upstream.

I'd suggest you do it all in a single patch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded

[Valdis . Kletnieks]

On Sun, 28 Jan 2007 23:08:17 MST, Eric W. Biederman said:
> [EMAIL PROTECTED] writes:

> Does it find sys?  If so perhaps I should do something even more significant.
> I guess if I get many complaints about this I will figure out how to print
> out an appropriate error message.

It found sys, and then the second iteration in in xlate_proc_name it failed
to find net because the de->subdir for sys/net wasn't set.

> > What's the intended semantics of create_proc_entry and xlate_proc_name in
> > this new regime of no subdir pointers? Or am I just (yet again) one of the
> > first to trip over a bug?
> 
> It is supposed to fail in this instance.  If you want something under 
> /proc/sys
> you are supposed to use register_sysctl like everyone else.  If it's not a
> sysctl it should not show up under /proc/sys.

Wasn't my code originally - I think the original author thought that since
all the *other* config stuff for ipv4 was down under /proc/sys/net/ipv4, this
one should be as well because that's where sysadmins would look for it, and
wasn't thinking so much about whether it was a sysctl or not.

> I'm glad to see my cleanup uncovering more bugs, I'm sorry you were the one
> who had to find it.  I will you well fixing your out of tree ipfilter module.

It's easy enough to move the entry under /proc/net or someplace instead.

What's the current advice on what kernel interface to use for this scenario:

In userspace, we do something like this:

(while read foo; do echo $foo > /proc/my_file; done) < /etc/bunch_of_lines

and we want to catch, parse, and save each line as it enters the kernel, and
we end up with several dozen entries saved.

If we do a 'cat /proc/my_file', we iterate across the list of saved lines
and dump them all out.




pgpTmoapUd1yB.pgp
Description: PGP signature

Re: The mbox format archives of linux-kernel are gone.

[Dave Jones]

On Mon, Jan 29, 2007 at 12:59:27AM -0500, Rob Landley wrote:
 > On Sunday 28 January 2007 8:52 pm, Oleg Verych wrote:
 > > On Sun, Jan 28, 2007 at 03:17:06PM -0800, Andrew Morton wrote:
 > > > On Sun, 28 Jan 2007 22:46:32 +
 > > > Oleg Verych <[EMAIL PROTECTED]> wrote:
 > > > 
 > > > > If somebody will get lkml mbox archive, can you import it into gmane,
 > > > > please.
 > > > 
 > > > http://userweb.kernel.org/~akpm/lkml-mbox-archives/
 > > 
 > > I think, whole set, possibly from most active start years, say 1993, 1994
 > > or so, must be collected, then i can contact Lars to try to import all
 > > this into Gmane with current web links being preserved.
 > > 
 > > BTW, donwloading (big) sets of archives _from_ Gmane is strongly
 > > discouraged.
 > 
 > The very early archives are available on the web:
 > http://www.kclug.org/old_archives/linux-activists/
 > 
 > And I'm under the impression that Alan Cox once collected a complete set of 
 > mbox archives, but this is a vague an unfocused recollection of something 
 > going by years ago.  (I also thought the result was downloadable under 
 > kernel.org/pub somewhere.  This would not appear to be the case.)

ftp://ftp.linux.org.uk/pub/linux/history/funet-archive/
ftp://ftp.linux.org.uk/pub/linux/alan/Kernel/Documents/Old-Funet-Lists
has some of the really early stuff.

Until recently I had a bunch of mid 90s to early 2000's in mboxes too,
but a disk accident seems to have eaten the only copies I had.

Dave

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

Re: 2.6.20-rc6: known unfixed regressions (v2) (part 2)

[Mike Galbraith]

On Sun, 2007-01-28 at 14:33 +0100, Uwe Bugla wrote:
>  Original-Nachricht 
> Datum: Sat, 27 Jan 2007 18:42:30 +0100
> Von: Adrian Bunk <[EMAIL PROTECTED]>
> An: Linus Torvalds <[EMAIL PROTECTED]>, Andrew Morton <[EMAIL PROTECTED]>
> Betreff: 2.6.20-rc6: known unfixed regressions (v2) (part 2)
> 
> > This email lists some known regressions in 2.6.20-rc6 compared to 2.6.19
> > that are not yet fixed in Linus' tree.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way possibly
> > involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject: problems with CD burning
> > References : http://www.spinics.net/lists/linux-ide/msg06545.html
> > Submitter  : Uwe Bugla <[EMAIL PROTECTED]>
> > Status : unknown
 


> Hi everybody,
> the problem I already reported for earlier release candidates of kernel 2.6.20
> (rc1 – 5) unfortunately stills persists.
> 
> The regression has become more extreme: While in earlier release candidates 
> nerolinux recognized my burning devices at least after the first start and 
> then never again after all following starts the situation in rc6 is different 
> from that:
> 
> The CD and DVD burning devices aren´t recognized even once and the drive seek 
> errors I already reported are still there.
> 
> nerolinux runs excellently with kernel 2.6.19.2, but only shows an “image 
> recorder” (i. e. no burning device at all) in kernel 2.6.20-rc6.
> 
> Still hope that this terrible bug will not be part of the final version of 
> 2.6.20!
> 
> Regards
> 
> Uwe

FWIW, I just tried it with 2.6.20-rc6, and can confirm.  Once nero is
run, the kernel never gives up retrying whatever command failed, so I
get...

[ 4362.972995] hdd: status error: status=0x58 { DriveReady SeekComplete
DataRequest }
[ 4362.981475] ide: failed opcode was: unknown
[ 4362.986183] hdd: drive not ready for command

endlessly.

-Mike

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

Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded

[Eric W. Biederman]

[EMAIL PROTECTED] writes:

> On Sat, 27 Jan 2007 13:41:16 PST, Andrew Morton said:
>> > > >> The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded 
>> > > >> to
>> > > >>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz
>> 
>> > I have everything compiling now, mostly.  The number of fixes which were
>> > needed was just extraordinary.  I'm thinking about making changes...
>
> Aliens ate my brain, part 1:
>
> I tried building an out-of-tree ipfilters (ipt_osf) that worked fine under
> 2.6.20-rc4-mm1.  After much scratching my head and adding debugging info,
> I discovered that this code was failing:
>
> p = create_proc_entry("sys/net/ipv4/osf", S_IFREG | 0644, NULL);
> if (!p) {
> ipt_unregister_match(_match);
> return -ENXIO;
> }
>
> After much *more* head-scratching, and adding of printk's, I tracked it down
> into fs/proc/generic.c, in xlate_proc_name:
>
> len = next - cp;
> for (de = de->subdir; de ; de = de->next) {
> if (proc_match(len, cp, de))
> break;
> }
> if (!de) {
> rtn = -ENOENT;
> goto out;
>
> It appears that syssctl-reimplement-the-sysctl-proc-support.patch doesn't
> bother setting the de->subdir, so xlate_proc_name isn't able to find sys/net.

Does it find sys?  If so perhaps I should do something even more significant.
I guess if I get many complaints about this I will figure out how to print
out an appropriate error message.

> What's the intended semantics of create_proc_entry and xlate_proc_name in
> this new regime of no subdir pointers? Or am I just (yet again) one of the
> first to trip over a bug?

It is supposed to fail in this instance.  If you want something under /proc/sys
you are supposed to use register_sysctl like everyone else.  If it's not a
sysctl it should not show up under /proc/sys.

I think I fixed the one in tree instance of this behavior.

I'm glad to see my cleanup uncovering more bugs, I'm sorry you were the one
who had to find it.  I will you well fixing your out of tree ipfilter module.

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

Re: [PATCH 0/6] MSI portability cleanups

[Benjamin Herrenschmidt]

On Sun, 2007-01-28 at 21:25 -0800, David Miller wrote:
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Sun, 28 Jan 2007 22:18:59 -0700
> 
> > Regardless of my opinion on the sanity of the hypervisor architects.
> > I have not seen anything that indicates it will be hard to support
> > the hypervisor doing everything or most of everything for us, so
> > I see no valid technical objection to it.  Nor have I ever.
> > 
> > So I have no problem with additional patches in that direction.
> 
> Ok, that's great to hear.
> 
> I know your bi-directional approach isn't exactly what Ben
> wants but he can support his machines with it.  Maybe after
> some time we can agree to move from that more towards the
> totally abstracted scheme.

It can support my machines without HV with trivial changes I reckon: I
need an ops struct to indirect eric's 2 remaining arch hooks
(setup/teardown) but that can be done inline within asm-powerpc. I need
to double check of course and probably actually port the MPIC backend
and possibly go write the Cell Axon one while at it to verify everything
is allright, but the base design seems sound enough.

For the ones with HV (RTAS stuff), we still need to agree on how to
approach it. We can either:

Option 1


Do a hook -above- Eric stuff, by having the toplevel APIs themselves be
arch hooks that can either go toward the RTAS implementation or toward
Eric's code. That is, eric code would define those (pick better names if
you are good at it):

pci_generic_enable_msi
pci_generic_disable_msi
pci_generic_enable_msix
pci_generic_disable_msix
pci_generic_save_msi_state
pci_generic_restore_msi_state

Then we can have asm-i386/msi.h & friends do something like

#define pci_enable_msi  pci_generic_enable_msi
#define pci_disable_msi pci_generic_disable_msi
   etc...

And we can have asm-powerpc/msi.h hook then via ppc_md:

static inline int pci_enable_msi(xxx...)
{
return ppc_md.pci_enable_msi(xxx...);
}
etc...

(ppc_md is our per-platform global hook structure filled at boot when we
discover on what machine type we are running on) so that pSeries can use
it's own RTAS callbacks, and others can just re-hook those to Eric's
code.


Option 2


That is to make Eric's code itself cope with the HV case. I'm a bit at
loss right now as how precisely to do it. I need to spend more time
staring at the code after Eric latest patches rather than the patches
themselves I suppose :-) (Eric, they don't apply out of the box on
current git, they are against -mm ?).

Some of the main issues here, more/less following the order in which
Eric code calls things:

 - The number of vectors for MSI-X is obtained from config space (at
least for sanity checking the requested argument). On RTAS, it should
come from an OF property (we are really not supposed to go read the
config space even if we can). I -suppose- we can survive for now with
just reading it, but we might well run into trouble with some "special"
devices shared accross partitions or if the IBM magic bridges themselves
ever start sending MSI-X on their own (unlikely but who knows...).
Michael's code handled that by having a callback ->check() do the sanity
checking of the nvec, and then just use the nvec passed in as an
argument once it's sane.

So for that I would propose adding an arch_check_msi(pdev, type, nvec)
or something like that. Note the biggest issue at this point anyway.

 - The real big one: For MSI-X, Eric's code tries to "hide" the fact
that those are MSI-X by allocating the msi-x entry array, then iterating
through them calling arch_setup_msi_irq() for each of them.

For that to work for us, it would need to be different, possibly
pre-allocating the array, and having -one- call taking an array and a
nvec. That's one of the reasons why I liked Michael's approach as
instead of making MSI-X look like MSI, it made MSI look like MSI-X by
passing a 1 entry array in the MSI case. Both approaches can probably be
made to handle multiple MSIs if we ever want to handle them.

The same issue is present for teardown of course.

 - We need HV hooks for suspend/resume at one point. Nothing urgent
there as our HV machines don't do suspend/resume just yet :-) But if we
ever implement something like suspend-to-disk, they'll definitely need
something as we are likely to get different vectors back from the
firmware so we need to re-map them to the same linux IRQ numbers.

I need to have a second look at Eric's code after I manage to find the
right combination of kernel for his patches to apply to check if I
missed anything important.

Cheers,
Ben.


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

[PATCH] Add PA Semi PCI vendor id

[Olof Johansson]

Add PA Semi's PCI vendor ID (0x1959).


Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>

---

Submitting this separately -- several drivers that have recently been
posted could make use of it. I didn't want to include it in each of them
and have patch conflicts when they're combined upstream.



Index: merge/include/linux/pci_ids.h
===
--- merge.orig/include/linux/pci_ids.h
+++ merge/include/linux/pci_ids.h
@@ -2078,6 +2078,8 @@
 #define PCI_VENDOR_ID_TDI   0x192E
 #define PCI_DEVICE_ID_TDI_EHCI  0x0101
 
+#define PCI_VENDOR_ID_PASEMI   0x1959
+
 #define PCI_VENDOR_ID_JMICRON  0x197B
 #define PCI_DEVICE_ID_JMICRON_JMB360   0x2360
 #define PCI_DEVICE_ID_JMICRON_JMB361   0x2361
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 -rt 2/2] RCU priority boosting additions to rcutorture

[Josh Triplett]

Paul E. McKenney wrote:
> On Thu, Jan 25, 2007 at 11:06:35AM -0800, Josh Triplett wrote:
>> Paul E. McKenney wrote:
>>> On Thu, Jan 25, 2007 at 12:47:04AM -0800, Josh Triplett wrote:
 One major item: this new test feature really needs a new module parameter 
 to
 enable or disable it.
>>> CONFIG_PREEMPT_RCU_BOOST is the parameter -- if not set, then no test.
>>> This parameter is provided by the accompanying RCU-boost patch.
>> It seems useful for rcutorture to use or not use the preempting thread
>> independently of CONFIG_PREEMPT_RCU_BOOST.  That would bring you from two
>> cases to four, and the two new cases both make sense:
>>
>> * CONFIG_PREEMPT_RCU_BOOST=n, but run rcutorture with the preempting thread.
>>   This configuration allows you to demonstrate the need for
>>   CONFIG_PREEMPT_RCU_BOOST, by showing what happens when you need it and 
>> don't
>>   have it.
>>
>> * CONFIG_PREEMPT_RCU_BOOST=y, but run rcutorture without the preempting
>>   thread.  This configuration allows you to test with rcutorture while 
>> running
>>   a *real* real-time workload rather than the simple preempting thread, or
>>   just test basic RCU functionality.
>>
>> A simple boolean module_param would work here.
> 
> OK, am finally with you.  See below for updated patch.

Looks good to me.

> Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>

Signed-off-by: Josh Triplett <[EMAIL PROTECTED]>

- Josh Triplett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/6] MSI portability cleanups

[Eric W. Biederman]

David Miller <[EMAIL PROTECTED]> writes:

> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Sun, 28 Jan 2007 22:18:59 -0700
>
>> Regardless of my opinion on the sanity of the hypervisor architects.
>> I have not seen anything that indicates it will be hard to support
>> the hypervisor doing everything or most of everything for us, so
>> I see no valid technical objection to it.  Nor have I ever.
>> 
>> So I have no problem with additional patches in that direction.
>
> Ok, that's great to hear.
>
> I know your bi-directional approach isn't exactly what Ben
> wants but he can support his machines with it.  Maybe after
> some time we can agree to move from that more towards the
> totally abstracted scheme.

Moving farther has been my intention the entire time, even
while writing those patches.  I'm just not prepared to do it in
one giant patch where bug hunting becomes impossible.

I think I have moved msi.c to the point it won't be a horror to
work with, so we can start seriously looking at what it will
take to support hypervisors that do this.

I don't believe there is anything generic we can do in the general
hypervisor case, so we need a way for the architecture code in
the case where it is inappropriate to write directly to the msi
and msi-x registers to have a completely different implementation of:
pci_enable_msi, pci_disable_msi, pci_enable_msix, psi_disable_msix,
and whatever other driver interface bits we have in there.

One small step at a time and we should get there soon.

Eric

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

Re: The mbox format archives of linux-kernel are gone.

[Rob Landley]

On Sunday 28 January 2007 8:52 pm, Oleg Verych wrote:
> On Sun, Jan 28, 2007 at 03:17:06PM -0800, Andrew Morton wrote:
> > On Sun, 28 Jan 2007 22:46:32 +
> > Oleg Verych <[EMAIL PROTECTED]> wrote:
> > 
> > > If somebody will get lkml mbox archive, can you import it into gmane,
> > > please.
> > 
> > http://userweb.kernel.org/~akpm/lkml-mbox-archives/
> 
> I think, whole set, possibly from most active start years, say 1993, 1994
> or so, must be collected, then i can contact Lars to try to import all
> this into Gmane with current web links being preserved.
> 
> BTW, donwloading (big) sets of archives _from_ Gmane is strongly
> discouraged.

The very early archives are available on the web:
http://www.kclug.org/old_archives/linux-activists/

And I'm under the impression that Alan Cox once collected a complete set of 
mbox archives, but this is a vague an unfocused recollection of something 
going by years ago.  (I also thought the result was downloadable under 
kernel.org/pub somewhere.  This would not appear to be the case.)

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded

[Valdis . Kletnieks]

On Sun, 28 Jan 2007 21:58:26 EST, [EMAIL PROTECTED] said:
> --==_Exmh_1170039506_3335P
> Content-Type: text/plain; charset=us-ascii
> 
> On 26/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz
> 
> Aliens ate my brain, part 2:
> 
> My IPv6 configuration evaporated, totally, out of my .config.  I tracked it
> down to wierdness with net/Kconfig:

Trying again with the official -rc6-mm1 tarball...

The aliens regurgitated my brain - after I did a 'make oldconfig' against my
-rc4-mm1 config, I did a 'make menuconfig' and all the IPv6 stuff showed up
as 'NEW'.  Not sure why it didn't carry over the the -rc4-mm1 values, but
at least I was able to re-set them.


pgpzIRx65r5zV.pgp
Description: PGP signature

Re: [PATCH 2.6.20-rc5 1/1] MM: enhance Linux swap subsystem

[yunfeng zhang]

You have an interesting idea of "simplifies", given
 16 files changed, 997 insertions(+), 25 deletions(-)
(omitting your Documentation), and over 7k more code.
You'll have to be much more persuasive (with good performance
results) to get us to welcome your added layer of complexity.


If the whole idea is deployed on Linux, following core objects should be erased
1) anon_vma.
2) pgdata::active/inactive list and relatted methods -- mark_page_accessed etc.
3) PrivatePage::count and mapcount. If core need to share the page, add PG_kmap
  flag. In fact, page::lru_list can safetly be erased too.
4) All cases should be from up to down, especially simplifies debug.


Please make an effort to support at least i386 3level pagetables:
you don't actually need >4GB of memory to test CONFIG_HIGHMEM64G.
HIGHMEM testing shows you're missing a couple of pte_unmap()s,
in pps_swapoff_scan_ptes() and in shrink_pvma_scan_ptes().


Yes, it's my fault.


It would be nice if you could support at least x86_64 too
(you have pte_low code peculiar to i386 in vmscan.c, which is
preventing that), but that's harder if you don't have the hardware.


Um! Data cmpxchged should include access bit. And I have only x86 PC, memory <
1G. 3level pagetable code copied from Linux other functions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc6-mm1

[Herbert Xu]

On Mon, Jan 29, 2007 at 04:17:44PM +1100, Herbert Xu wrote:
> Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> 
> > Jan 28 22:58:29 euridica kernel: BUG: using smp_processor_id() in 
> > preemptible [0001] code: yum-updatesd/2846
> > Jan 28 22:58:29 euridica kernel: caller is nf_conntrack_in+0x363/0x47f 
> > [nf_conntrack]
> > Jan 28 22:58:29 euridica kernel:  [] show_trace_log_lvl+0x1a/0x2f
> > Jan 28 22:58:29 euridica kernel:  [] show_trace+0x12/0x14
> > Jan 28 22:58:29 euridica kernel:  [] dump_stack+0x16/0x18
> > Jan 28 22:58:29 euridica kernel:  [] 
> > debug_smp_processor_id+0xb3/0xc8
> > Jan 28 22:58:29 euridica kernel:  [] nf_conntrack_in+0x363/0x47f 
> > [nf_conntrack]
> > Jan 28 22:58:29 euridica kernel:  [] 
> > ipv4_conntrack_local+0x53/0x5b [nf_conntrack_ipv4]
> > Jan 28 22:58:29 euridica kernel:  [] nf_iterate+0x36/0x67
> > Jan 28 22:58:29 euridica kernel:  [] nf_hook_slow+0x52/0xbe
> 
> This shouldn't have happened.  nf_hook_slow calls nf_iterate and
> therefore everything under it with preemption disabled.  So something
> must've reenabled it before hitting nf_conntrack_in.

Does mm now have the preemptible RCU stuff? If so that would certainly
explain this.

IIRC Ingo had made fixes for the networking stack in his rt tree since
the networking code assumes in lots of places that rcu_read_lock
disables preemption.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lockmeter

[hui]

On Sun, Jan 28, 2007 at 10:17:05PM +0100, Ingo Molnar wrote:
> btw., while my plan is to prototype your lock-stat patch in -rt 
> initially, it should be doable to extend it to be usable with the 
> upstream kernel as well.
> 
> We can gather lock contention events when there is spinlock debugging 
> enabled, from lib/spinlock_debug.c. For example __spin_lock_debug() does 
> this:
> 
> static void __spin_lock_debug(spinlock_t *lock)
> {
> ...
> for (i = 0; i < loops; i++) {
> if (__raw_spin_trylock(>raw_lock))
> return;
> __delay(1);
> }
> 
> where the __delay(1) call is done do we notice contention - and there 
> you could drive the lock-stat code. Similarly, rwlocks have such natural 
> points too where you could insert a lock-stat callback without impacting 
> performance (or the code) all that much. mutexes and rwsems have natural 
> contention points too (kernel/mutex.c:__mutex_lock_slowpath() and 
> kernel/rwsem.c:rwsem_down_failed_common()), even with mutex debugging is 
> off.
> 
> for -rt the natural point to gather contention events is in 
> kernel/rtmutex.c, as you are doing it currently.
> 
> finally, you can enable lockdep's initialization/etc. wrappers so that 
> infrastructure between lockdep and lock-stat is shared, but you dont 
> have to call into the lock-tracking code of lockdep.c if LOCK_STAT is 
> enabled and PROVE_LOCKING is disabled. That should give you the lockdep 
> infrastructure for LOCK_STAT, without the lockdep overhead.
> 
> all in one, one motivation behind my interest in your patch for -rt is 
> that i think it's useful for upstream too, and that it can merge with 
> lockdep to a fair degree.

Fantastic. I'm going to try and finish up your suggested changes tonight
and get it to work with CONFIG_LOCK_STAT off. It's been challenging to
find time to do Linux these days, so I don't mind handing it off to you
after this point so that you and tweek it to your heart's content.

Yeah, one of the major motivations behind it was to see if Solaris style
locks were useful and to either validate or invalidate their usefulness.
Because of this patch, we have an idea of what's going on with regard to
adaptive spinning and such. The sensible conclusion is that it's not
sophistication of the lock, but parallelizing the code in the first
place to prevent the contention in the first place that's the key
philosophical drive.

I forward merged it into rc6-rt2 and you can expect a drop tonight of
what I have regardless whether it's perfect or not.

bill

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

Re: [PATCH 0/6] MSI portability cleanups

[David Miller]

From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 22:18:59 -0700

> Regardless of my opinion on the sanity of the hypervisor architects.
> I have not seen anything that indicates it will be hard to support
> the hypervisor doing everything or most of everything for us, so
> I see no valid technical objection to it.  Nor have I ever.
> 
> So I have no problem with additional patches in that direction.

Ok, that's great to hear.

I know your bi-directional approach isn't exactly what Ben
wants but he can support his machines with it.  Maybe after
some time we can agree to move from that more towards the
totally abstracted scheme.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/6] MSI portability cleanups

[Eric W. Biederman]

David Miller <[EMAIL PROTECTED]> writes:

> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Sun, 28 Jan 2007 16:26:44 -0700
>
>> Yes.  In general the mainline linux kernel does not support certain
>> classes of stupidity.  TCP offload engines, firmware drivers for
>> hardware we care about, a fixed ABI to binary only modules, etc.
>> It is the responsibility of the OS to setup MSI so we do it, not
>> the firmware so we do it.
>
> I absolutely disagree with you Eric, and I think you're being
> rediculious.
>
> If the hypervisor doesn't control the MSI PCI config space
> register writes, this allows the device to spam PCI devices
> which belong to other domains.
>
> It's a freakin' reasonable design trade off decision, get over
> it! :-)

I completely agree with you in the case you have described, it does
mean that the hypervisor needs to trust all of the MSI capable
hardware in the system but it if that is the best your hardware can
support it is a reasonable trade-off.

With the MSI-X registers in a random part of some memory mapped bar
and not guaranteed to be page aligned, things are more difficult to
isolate purely in a software based hypervisor.

> Yes it can be done at the hardware level, and many hypervisor
> based systems do that, but it's not the one-and-only true
> way to implment inter-domain protection behind a single
> PCI host controller.

The reason I consider the case crazy is that every example I have
been given is where the hardware is doing the filtering above the
PCI device.  So the hypervisor has no need to filter the pci config
traffic or to write to the msi config registers for us.  Yet the
defined hypervisor interface is.  Given the reduction in flexibility
of an interface where the hypervisor writes to the config registers
for the OS as compared to an interface where the hypervisor provides
a destination for MSI messages from a particular device upon request,
I think it is silly to design an interface when you full hardware
support to act like an interface built for a hypervisor that had
to do everything in software.

Regardless of my opinion on the sanity of the hypervisor architects.
I have not seen anything that indicates it will be hard to support
the hypervisor doing everything or most of everything for us, so
I see no valid technical objection to it.  Nor have I ever.

So I have no problem with additional patches in that direction.

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

Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded

[Randy Dunlap]

On Sun, 28 Jan 2007 21:58:26 -0500 [EMAIL PROTECTED] wrote:

> On 26/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz
> 
> Aliens ate my brain, part 2:
> 
> My IPv6 configuration evaporated, totally, out of my .config.  I tracked it
> down to wierdness with net/Kconfig:
> 
> if INET   
>   
> source "net/ipv4/Kconfig"
> source "net/netlabel/Kconfig"
>   
> endif # if INET
>   
> source "net/ipv6/Kconfig"
> 
> (Yes, the ipv6 is now *outside* the if/endif - that's what I had to do to make
> it work).  If that last 'source' was *inside* that if/endif, it became
> invisible unless I set INET to *N*, at which point ipv4 and netlabel would
> disappear, and ipv6 would become visible.  If I set INET to Y, then ipv4 and
> netlabel would come back, and ipv6 would go poof again. This affected both
> 'make menuconfig' and 'make [silent]oldconfig'.
> 
> .config follows.  I have *no* idea what caused it.

Possibly my (bad) gfs2/dlm patch...

Please try applying Adrian Bunk's patch to see if that fixes the
IPV6 disappearing trick. (below)

---
On Sun, Jan 28, 2007 at 11:08:18AM +0100, Jiri Slaby wrote:
> Andrew Morton napsal(a):
> >Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-rc6-mm1/
> 
> Unable to select IPV6. Menuconfig doesn't offer it when INET is selected. 
> When it's not it appears in the menu, but after state change it gets away. 
> The same behaviour in xconfig, gconfig.
> 
> $ mkdir ../a/tst
> $ make O=../a/tst menuconfig
>   HOSTCC  scripts/basic/fixdep
> [...]
>   HOSTLD  scripts/kconfig/mconf
> scripts/kconfig/mconf arch/i386/Kconfig
> Warning! Found recursive dependency: INET GFS2_FS_LOCKING_DLM SYSFS 
> OCFS2_FS INET
> 
> Maybe this is the problem?

Yes, patch below.

> regards,

cu
Adrian


<--  snip  -->


This patch fixes a circular dependency by letting GFS2_FS_LOCKING_DLM 
and DLM depend on instead of select SYSFS.

Since SYSFS depends on EMBEDDED this change shouldn't cause any problems 
for users.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 fs/dlm/Kconfig  |3 +--
 fs/gfs2/Kconfig |3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

--- linux-2.6.20-rc6-mm1/fs/gfs2/Kconfig.old2007-01-28 16:44:17.0 
+0100
+++ linux-2.6.20-rc6-mm1/fs/gfs2/Kconfig2007-01-28 16:44:59.0 
+0100
@@ -34,11 +34,10 @@
 
 config GFS2_FS_LOCKING_DLM
tristate "GFS2 DLM locking module"
-   depends on GFS2_FS && NET && INET && (IPV6 || IPV6=n)
+   depends on GFS2_FS && SYSFS && NET && INET && (IPV6 || IPV6=n)
select IP_SCTP if DLM_SCTP
select CONFIGFS_FS
select DLM
-   select SYSFS
help
Multiple node locking module for GFS2
 
--- linux-2.6.20-rc6-mm1/fs/dlm/Kconfig.old 2007-01-28 16:56:57.0 
+0100
+++ linux-2.6.20-rc6-mm1/fs/dlm/Kconfig 2007-01-28 16:57:16.0 +0100
@@ -3,9 +3,8 @@
 
 config DLM
tristate "Distributed Lock Manager (DLM)"
-   depends on IPV6 || IPV6=n
+   depends on SYSFS && (IPV6 || IPV6=n)
select CONFIGFS_FS
-   select SYSFS
select IP_SCTP if DLM_SCTP
help
A general purpose distributed lock manager for kernel or userspace

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

Re: 2.6.20-rc6-mm1

[Herbert Xu]

Michal Piotrowski <[EMAIL PROTECTED]> wrote:

> Jan 28 22:58:29 euridica kernel: BUG: using smp_processor_id() in preemptible 
> [0001] code: yum-updatesd/2846
> Jan 28 22:58:29 euridica kernel: caller is nf_conntrack_in+0x363/0x47f 
> [nf_conntrack]
> Jan 28 22:58:29 euridica kernel:  [] show_trace_log_lvl+0x1a/0x2f
> Jan 28 22:58:29 euridica kernel:  [] show_trace+0x12/0x14
> Jan 28 22:58:29 euridica kernel:  [] dump_stack+0x16/0x18
> Jan 28 22:58:29 euridica kernel:  [] 
> debug_smp_processor_id+0xb3/0xc8
> Jan 28 22:58:29 euridica kernel:  [] nf_conntrack_in+0x363/0x47f 
> [nf_conntrack]
> Jan 28 22:58:29 euridica kernel:  [] ipv4_conntrack_local+0x53/0x5b 
> [nf_conntrack_ipv4]
> Jan 28 22:58:29 euridica kernel:  [] nf_iterate+0x36/0x67
> Jan 28 22:58:29 euridica kernel:  [] nf_hook_slow+0x52/0xbe

This shouldn't have happened.  nf_hook_slow calls nf_iterate and
therefore everything under it with preemption disabled.  So something
must've reenabled it before hitting nf_conntrack_in.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [NFS] 2.6.17.8 - do_vfs_lock: VFS is out of sync with lock manager!

[Neil Brown]

On Monday August 21, [EMAIL PROTECTED] wrote:
> 
> Could we instead replace it with a dprintk() that returns the value of
> "res"? That will keep it useful for debugging purposes.

(only 5 months later...)

Sure, how about this?

Thanks,
NeilBrown


Remove warning: VFS is out of sync with lock manager.

But keep it as a dprintk

The message can be generated in a quite normal situation:
 If a 'lock' request is interrupted, then the lock client needs to
  record that the server has the lock, incase it does.
 When we come the unlock, the server might say it doesn't, even
  though we think it does (or might) and this generates the message.

Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./fs/nfs/file.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff .prev/fs/nfs/file.c ./fs/nfs/file.c
--- .prev/fs/nfs/file.c 2007-01-29 16:04:09.0 +1100
+++ ./fs/nfs/file.c 2007-01-29 16:04:45.0 +1100
@@ -434,8 +434,9 @@ static int do_vfs_lock(struct file *file
BUG();
}
if (res < 0)
-   printk(KERN_WARNING "%s: VFS is out of sync with lock 
manager!\n",
-   __FUNCTION__);
+   dprintk(KERN_WARNING "%s: VFS is out of sync with lock manager"
+   " - error %d!\n",
+   __FUNCTION__, res);
return res;
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded

[Valdis . Kletnieks]

On 26/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz

Aliens ate my brain, part 2:

My IPv6 configuration evaporated, totally, out of my .config.  I tracked it
down to wierdness with net/Kconfig:

if INET   
  
source "net/ipv4/Kconfig"
source "net/netlabel/Kconfig"
  
endif # if INET
  
source "net/ipv6/Kconfig"

(Yes, the ipv6 is now *outside* the if/endif - that's what I had to do to make
it work).  If that last 'source' was *inside* that if/endif, it became
invisible unless I set INET to *N*, at which point ipv4 and netlabel would
disappear, and ipv6 would become visible.  If I set INET to Y, then ipv4 and
netlabel would come back, and ipv6 would go poof again. This affected both
'make menuconfig' and 'make [silent]oldconfig'.

.config follows.  I have *no* idea what caused it.

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.20-rc6-mm1
# Sun Jan 28 02:43:46 2007
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_ZONE_DMA32=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_DMI=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SWAP_PREFETCH=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_USER_NS=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
CONFIG_X86_PC=y
# CONFIG_X86_VSMP is not set
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
CONFIG_MCORE2=y
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_MICROCODE=m
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_X86_HT=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
CONFIG_SMP=y
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_CLASSIC_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_TRACE=y
# CONFIG_NUMA is not set
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_ADAPTIVE_READAHEAD=y
CONFIG_DEBUG_READAHEAD=y
CONFIG_NR_CPUS=8
# CONFIG_HOTPLUG_CPU is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_HPET_TIMER=y
CONFIG_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set

Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded

[Valdis . Kletnieks]

On Sat, 27 Jan 2007 13:41:16 PST, Andrew Morton said:
> > > >> The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to
> > > >>
> > > >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz
> 
> > I have everything compiling now, mostly.  The number of fixes which were
> > needed was just extraordinary.  I'm thinking about making changes...

Aliens ate my brain, part 1:

I tried building an out-of-tree ipfilters (ipt_osf) that worked fine under
2.6.20-rc4-mm1.  After much scratching my head and adding debugging info,
I discovered that this code was failing:

p = create_proc_entry("sys/net/ipv4/osf", S_IFREG | 0644, NULL);
if (!p) {
ipt_unregister_match(_match);
return -ENXIO;
}

After much *more* head-scratching, and adding of printk's, I tracked it down
into fs/proc/generic.c, in xlate_proc_name:

len = next - cp;
for (de = de->subdir; de ; de = de->next) {
if (proc_match(len, cp, de))
break;
}
if (!de) {
rtn = -ENOENT;
goto out;

It appears that syssctl-reimplement-the-sysctl-proc-support.patch doesn't
bother setting the de->subdir, so xlate_proc_name isn't able to find sys/net.

What's the intended semantics of create_proc_entry and xlate_proc_name in
this new regime of no subdir pointers? Or am I just (yet again) one of the
first to trip over a bug?



pgpsw6VtA11mc.pgp
Description: PGP signature

Re: [xfs-masters] [PATCH} XFS: Remove placeholders for unimplemented functionality.

[Eric Sandeen]

Robert P. J. Day wrote:

  Remove a couple kernel config variables (FS_POSIX_CAP and
FS_POSIX_MAC) that represent placeholders for unimplemented
functionality.

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

---


...


diff --git a/fs/xfs/xfs_cap.h b/fs/xfs/xfs_cap.h
index 7a0e482..cfedfd1 100644
--- a/fs/xfs/xfs_cap.h
+++ b/fs/xfs/xfs_cap.h


...


-#else
 #define xfs_cap_vset(v,p,sz)   (-EOPNOTSUPP)
 #define xfs_cap_vget(v,p,sz)   (-EOPNOTSUPP)
 #define xfs_cap_vremove(v) (-EOPNOTSUPP)
 #define _CAP_EXISTS(NULL)
-#endif

 #endif /* __KERNEL__ */


By the time you do this, probably may as well remove the whole file; the 
leftover 4 definitions never seem to be used.


The same may go for xfs_mac.h.

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

2.6.20-rc6-mm1 posixtest failures

[Randy Dunlap]

On 2.6.20-rc6 (run #1097), the openposixtest[1] suite results were:

build errors: 13 files, 31 lines
PASS: 1687
FAILED:   68
UNTESTED: 95
UNRESOLVED:   9
UNSUPPORTED:  22
INTERRUPTED:  7
SCORE:89

[1] http://posixtest.sourceforge.net/  (using v1.5.2)

On 2.6.20-rc6-mm1 (run #1104), the results were:

build errors: 13 files, 31 lines
PASS: 1662  // 25 fewer tests PASS
FAILED:   84
UNTESTED: 95
UNRESOLVED:   18
UNSUPPORTED:  22
INTERRUPTED:  7
SCORE:88

Many of the new FAILED tests are in scheduler and mlock test cases.

Here is a diff of the test output files:

3993c3993
< /bin/sh: line 1: 27934 Segmentation fault  ./t0 240 
conformance/interfaces/pthread_key_create/speculative/5-1.test >$COMPLOG 2>&1
---
> /bin/sh: line 1: 27891 Segmentation fault  ./t0 240 
> conformance/interfaces/pthread_key_create/speculative/5-1.test >$COMPLOG 2>&1
4219c4219
< conformance/interfaces/sched_setscheduler/1-1: execution: PASS
---
> conformance/interfaces/sched_setscheduler/1-1: execution: UNRESOLVED 
4227c4227
< conformance/interfaces/sched_setscheduler/17-5: execution: UNRESOLVED 
---
> conformance/interfaces/sched_setscheduler/17-5: execution: FAILED 
4266c4266
< conformance/interfaces/sched_getparam/1-1: execution: PASS
---
> conformance/interfaces/sched_getparam/1-1: execution: FAILED 
4269,4270c4269,4270
< conformance/interfaces/sched_getparam/2-1: execution: PASS
< conformance/interfaces/sched_getparam/3-1: execution: PASS
---
> conformance/interfaces/sched_getparam/2-1: execution: FAILED 
> conformance/interfaces/sched_getparam/3-1: execution: FAILED 
4406c4406
< /bin/sh: line 1: 32176 Segmentation fault  ./t0 240 
conformance/interfaces/timer_getoverrun/speculative/6-1.test >$COMPLOG 2>&1
---
> /bin/sh: line 1: 32168 Segmentation fault  ./t0 240 
> conformance/interfaces/timer_getoverrun/speculative/6-1.test >$COMPLOG 2>&1
4429c4429
< conformance/interfaces/mlockall/3-6: execution: PASS
---
> conformance/interfaces/mlockall/3-6: execution: UNRESOLVED 
4432,4433c4432,4433
< conformance/interfaces/mlockall/8-1: execution: PASS
< conformance/interfaces/mlockall/3-7: execution: PASS
---
> conformance/interfaces/mlockall/8-1: execution: UNRESOLVED 
> conformance/interfaces/mlockall/3-7: execution: UNRESOLVED 
4545,4546c4545,4546
< conformance/interfaces/sched_get_priority_min/1-1: execution: PASS
< conformance/interfaces/sched_get_priority_min/1-2: execution: PASS
---
> conformance/interfaces/sched_get_priority_min/1-1: execution: FAILED 
> conformance/interfaces/sched_get_priority_min/1-2: execution: FAILED 
4548c4548
< conformance/interfaces/sched_get_priority_min/1-4: execution: PASS
---
> conformance/interfaces/sched_get_priority_min/1-4: execution: FAILED 
4585,4587c4585,4587
< conformance/interfaces/munlock/11-1: execution: PASS
< conformance/interfaces/munlock/10-1: execution: PASS
< conformance/interfaces/munlock/7-1: execution: PASS
---
> conformance/interfaces/munlock/11-1: execution: UNRESOLVED 
> conformance/interfaces/munlock/10-1: execution: UNRESOLVED 
> conformance/interfaces/munlock/7-1: execution: UNRESOLVED 
4590c4590
< /bin/sh: line 1:  1234 Segmentation fault  ./t0 240 
conformance/interfaces/pthread_cond_timedwait/2-2.test >$COMPLOG 2>&1
---
> /bin/sh: line 1:  1226 Segmentation fault  ./t0 240 
> conformance/interfaces/pthread_cond_timedwait/2-2.test >$COMPLOG 2>&1
4598c4598
< /bin/sh: line 1:  3593 Segmentation fault  ./t0 240 
conformance/interfaces/pthread_cond_timedwait/2-3.test >$COMPLOG 2>&1
---
> /bin/sh: line 1:  3588 Segmentation fault  ./t0 240 
> conformance/interfaces/pthread_cond_timedwait/2-3.test >$COMPLOG 2>&1
4648,4649c4648,4649
< conformance/interfaces/sched_getscheduler/4-1: execution: PASS
< conformance/interfaces/sched_getscheduler/1-1: execution: PASS
---
> conformance/interfaces/sched_getscheduler/4-1: execution: FAILED 
> conformance/interfaces/sched_getscheduler/1-1: execution: FAILED 
4653c4653
< conformance/interfaces/sched_getscheduler/3-1: execution: PASS
---
> conformance/interfaces/sched_getscheduler/3-1: execution: FAILED 
4692c4692
< /bin/sh: line 1:  4293 Segmentation fault  ./t0 240 
conformance/interfaces/timer_delete/speculative/5-1.test >$COMPLOG 2>&1
---
> /bin/sh: line 1:  4288 Segmentation fault  ./t0 240 
> conformance/interfaces/timer_delete/speculative/5-1.test >$COMPLOG 2>&1
4876c4876
< conformance/interfaces/mlock/5-1: execution: PASS
---
> conformance/interfaces/mlock/5-1: execution: UNRESOLVED 
4879,4880c4879,4880
< conformance/interfaces/mlock/10-1: execution: PASS
< conformance/interfaces/mlock/8-1: execution: PASS
---
> conformance/interfaces/mlock/10-1: execution: UNRESOLVED 
> conformance/interfaces/mlock/8-1: execution: UNRESOLVED 
4922,4923c4922,4923
< conformance/interfaces/sched_get_priority_max/1-1: execution: PASS
< conformance/interfaces/sched_get_priority_max/1-2: execution: PASS
---
> conformance/interfaces/sched_get_priority_max/1-1: 

Re: [PATCH] mm: remove global locks from mm/highmem.c

[Nick Piggin]

Andrew Morton wrote:

On Sun, 28 Jan 2007 15:11:34 +0100
Peter Zijlstra <[EMAIL PROTECTED]> wrote:



+static inline int set_page_address(struct page *page, void *address)
+{
+   if (address)
+   return cmpxchg(>virtual, NULL, address) == NULL;
+   else {
+   /*
+* cmpxchg is a bit abused because it is not guaranteed
+* safe wrt direct assignment on all platforms.
+*/
+   void *virt = page->virtual;
+   return cmpxchg(>vitrual, virt, NULL) == virt;
+   }
+}



Have you verified that all architectures which can implement
WANT_PAGE_VIRTUAL also implement cmpxchg?


Simple: we should not implement cmpxchg in generic code. We should
be able to use atomic_long_cmpxchg for this -- it will work perfectly
regardless of what anybody else tells you.

cmpxchg is only required for when that memory location may get modified
by some other means than under your control (eg. userspace, in the case
of drm, or hardware MMU in the case of Christoph's old page fault
scalability patches).

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


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

[PATCH -mm] fix DocBook build

[Don Mullis]

Fix DocBook build.
Regression was introduced by
gregkh-usb-usb-linux-usb_ch9h-becomes-linux-usb-ch9h.patch

Tested by `make htmldocs`.

Signed-off-by: Don Mullis <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
---
 Documentation/DocBook/gadget.tmpl |4 ++--
 Documentation/DocBook/usb.tmpl|6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

Index: linux-2.6.19/Documentation/DocBook/gadget.tmpl
===
--- linux-2.6.19.orig/Documentation/DocBook/gadget.tmpl
+++ linux-2.6.19/Documentation/DocBook/gadget.tmpl
@@ -482,13 +482,13 @@ slightly.
 Gadget drivers
 rely on common USB structures and constants
 defined in the
-linux/usb_ch9.h
+linux/usb/ch9.h
 header file, which is standard in Linux 2.6 kernels.
 These are the same types and constants used by host
 side drivers (and usbcore).
 
 
-!Iinclude/linux/usb_ch9.h
+!Iinclude/linux/usb/ch9.h
 
 
 Core Objects and Methods
Index: linux-2.6.19/Documentation/DocBook/usb.tmpl
===
--- linux-2.6.19.orig/Documentation/DocBook/usb.tmpl
+++ linux-2.6.19/Documentation/DocBook/usb.tmpl
@@ -187,13 +187,13 @@
 
 USB-Standard Types
 
-In linux/usb_ch9.h you will find
+In linux/usb/ch9.h you will find
 the USB data types defined in chapter 9 of the USB specification.
 These data types are used throughout USB, and in APIs including
 this host side API, gadget APIs, and usbfs.
 
 
-!Iinclude/linux/usb_ch9.h
+!Iinclude/linux/usb/ch9.h
 
 
 
@@ -574,7 +574,7 @@ for (;;) {
 #include asm/byteorder.h
The standard USB device model requests, from "Chapter 9" of
the USB 2.0 specification, are automatically included from
-   the linux/usb_ch9.h header.
+   the linux/usb/ch9.h header.

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

Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

[Paul E. McKenney]

On Sun, Jan 28, 2007 at 03:30:05PM -0800, Andrew Morton wrote:
> On Sun, 28 Jan 2007 14:47:56 -0800
> "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
> 
> > > If we use the process freezer, these bugs all get automatically fixed,
> > > and we get to remove the existing locking, and we don't need to think
> > > about it any more.
> > 
> > The idea being to essentially suspend the system to RAM, remove the
> > CPU and then unsuspend it?  Seems like quite high overhead -- or am
> > I misunderstanding the proposal?
> 
> The process freezer basically wakes up all threads in the machine and makes
> them go to sleep in a specific place, so they're all in a known state. 
> kernel threads are also captured, via their open-coded polling call to
> try_to_freeze().
> 
> The machine suspend code uses the process freezer, as does kprobes.  The
> freezer isn't tied to suspend or to power management.
> 
> The freezer does have potential to be expensive if used frequently and if
> there are many threads.  But I don't think anyone has looked at optimising
> it.  For example, there are certain places in the kernel where threads
> commonly sleep (eg, select()).  We know that this is a safe place to sleep
> wrt (at least) CPU hotplug, so there's not really a need to wake those
> processes up.  Perhaps something could be done with that observation...
> 
> But first we'd need to demonstrate that we actually have a problem.

Fair enough -- though if it is a goal to remove CPUs from systems with
realtime workloads, I can assure you that we do have a problem.

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

Re: [SCRIPT] Remove "space damage" from patches

[Oleg Verych]

On Mon, Jan 29, 2007 at 03:00:35AM +0100, Richard Knutsson wrote:
> Oleg Verych wrote:
> >On Mon, Jan 29, 2007 at 02:26:04AM +0100, Richard Knutsson wrote:
> >[]
> >  
> >>I also guess you saw that the script is _not_ for cleaning up 
> >>source-files (can be intrusive and is better to be fixed when fixing 
> >>something else), but patches.
> >>
> >
> >IMHO it's dealing with consequences, not cause, and it's even worse.
> >  
> How many patches is not to fix bugs, it is worse then some strayed 
> whitespace but it is due to reality.
> The best is, of course, if neither happened but the next best thing is 

1. Patches are signed-off (not by you).
2. Maybe Andrew Morton under his sign-off add such feature.

> >> (otherwise I believe they just deleted my mail ;) ).
> >>
> >
> >I would like to discuss, would you?
> >  
> I like to discuss but I am not sure what the result would be. Force 
> people to use the editors of our choice?
> As long people uses valid e-mail-clients when sending patches (or they 
> use the script "sendpatchset"), I'm think we have to be satisfied.
> But if you have any ideas, I'm listening.

Open-source worker, hammering his fingers? Please, let me out it ;D

> Richard Knutsson
> 

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

Re: [RFC PATCH -rt 2/2] RCU priority boosting additions to rcutorture

[Paul E. McKenney]

On Thu, Jan 25, 2007 at 11:06:35AM -0800, Josh Triplett wrote:
> Paul E. McKenney wrote:
> > On Thu, Jan 25, 2007 at 12:47:04AM -0800, Josh Triplett wrote:
> >> One major item: this new test feature really needs a new module parameter 
> >> to
> >> enable or disable it.
> > 
> > CONFIG_PREEMPT_RCU_BOOST is the parameter -- if not set, then no test.
> > This parameter is provided by the accompanying RCU-boost patch.
> 
> It seems useful for rcutorture to use or not use the preempting thread
> independently of CONFIG_PREEMPT_RCU_BOOST.  That would bring you from two
> cases to four, and the two new cases both make sense:
> 
> * CONFIG_PREEMPT_RCU_BOOST=n, but run rcutorture with the preempting thread.
>   This configuration allows you to demonstrate the need for
>   CONFIG_PREEMPT_RCU_BOOST, by showing what happens when you need it and don't
>   have it.
> 
> * CONFIG_PREEMPT_RCU_BOOST=y, but run rcutorture without the preempting
>   thread.  This configuration allows you to test with rcutorture while running
>   a *real* real-time workload rather than the simple preempting thread, or
>   just test basic RCU functionality.
> 
> A simple boolean module_param would work here.

OK, am finally with you.  See below for updated patch.

> At some point, we may want to add the ability to run multiple preempting
> threads, but that doesn't need to happen for this patch.

Or to make it bounce around onto multiple CPUs, I suppose.  Leaving
these out for the moment.  ;-)

Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---

 rcutorture.c |   90 +--
 1 file changed, 76 insertions(+), 14 deletions(-)

diff -urpNa -X dontdiff linux-2.6.20-rc4-rt1/kernel/rcutorture.c 
linux-2.6.20-rc4-rt1-rcubtorture/kernel/rcutorture.c
--- linux-2.6.20-rc4-rt1/kernel/rcutorture.c2007-01-09 10:59:54.0 
-0800
+++ linux-2.6.20-rc4-rt1-rcubtorture/kernel/rcutorture.c2007-01-26 
22:16:13.0 -0800
@@ -58,6 +58,7 @@ static int stat_interval; /* Interval be
 static int verbose;/* Print more debug info. */
 static int test_no_idle_hz;/* Test RCU's support for tickless idle CPUs. */
 static int shuffle_interval = 5; /* Interval between shuffles (in sec)*/
+static int preempt_torture = 0;/* Realtime task preempts torture 
readers. */
 static char *torture_type = "rcu"; /* What RCU implementation to torture. */
 
 module_param(nreaders, int, 0);
@@ -72,6 +73,8 @@ module_param(test_no_idle_hz, bool, 0);
 MODULE_PARM_DESC(test_no_idle_hz, "Test support for tickless idle CPUs");
 module_param(shuffle_interval, int, 0);
 MODULE_PARM_DESC(shuffle_interval, "Number of seconds between shuffles");
+module_param(preempt_torture, bool, 0);
+MODULE_PARM_DESC(preempt_torture, "Enable realtime preemption torture");
 module_param(torture_type, charp, 0);
 MODULE_PARM_DESC(torture_type, "Type of RCU to torture (rcu, rcu_bh, srcu)");
 
@@ -194,6 +197,8 @@ struct rcu_torture_ops {
int (*completed)(void);
void (*deferredfree)(struct rcu_torture *p);
void (*sync)(void);
+   long (*preemptstart)(void);
+   void (*preemptend)(void);
int (*stats)(char *page);
char *name;
 };
@@ -258,16 +263,74 @@ static void rcu_torture_deferred_free(st
call_rcu(>rtort_rcu, rcu_torture_cb);
 }
 
+static struct task_struct *rcu_preeempt_task;
+static unsigned long rcu_torture_preempt_errors = 0;
+
+static int rcu_torture_preempt(void *arg)
+{
+   int completedstart;
+   int err;
+   time_t gcstart;
+   struct sched_param sp;
+
+   sp.sched_priority = MAX_RT_PRIO - 1;
+   err = sched_setscheduler(current, SCHED_RR, );
+   if (err != 0)
+   printk(KERN_ALERT "rcu_torture_preempt() priority err: %d\n",
+  err);
+   current->flags |= PF_NOFREEZE;
+
+   do {
+   completedstart = rcu_torture_completed();
+   gcstart = xtime.tv_sec;
+   while ((xtime.tv_sec - gcstart < 10) &&
+  (rcu_torture_completed() == completedstart))
+   cond_resched();
+   if (rcu_torture_completed() == completedstart)
+   rcu_torture_preempt_errors++;
+   schedule_timeout_interruptible(HZ);
+   } while (!kthread_should_stop());
+   return NULL;
+}
+
+static long rcu_preempt_start(void)
+{
+   long retval = 0;
+
+   rcu_preeempt_task = kthread_run(rcu_torture_preempt, NULL,
+   "rcu_torture_preempt");
+   if (IS_ERR(rcu_preeempt_task)) {
+   VERBOSE_PRINTK_ERRSTRING("Failed to create preempter");
+   retval = PTR_ERR(rcu_preeempt_task);
+   rcu_preeempt_task = NULL;
+   }
+   return retval;
+}
+
+static void rcu_preempt_end(void)
+{
+   if (rcu_preeempt_task != NULL) {
+   VERBOSE_PRINTK_STRING("Stopping rcu_preempt task");
+   

Re: [-mm patch] fix GFS2 circular dependency

[Randy Dunlap]

On Sun, 28 Jan 2007 17:19:50 +0100 Adrian Bunk wrote:

> <--  snip  -->
> 
> 
> This patch fixes a circular dependency by letting GFS2_FS_LOCKING_DLM 
> and DLM depend on instead of select SYSFS.
> 
> Since SYSFS depends on EMBEDDED this change shouldn't cause any problems 
> for users.
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

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

Thanks.  Sorry about that.


> ---
> 
>  fs/dlm/Kconfig  |3 +--
>  fs/gfs2/Kconfig |3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> --- linux-2.6.20-rc6-mm1/fs/gfs2/Kconfig.old  2007-01-28 16:44:17.0 
> +0100
> +++ linux-2.6.20-rc6-mm1/fs/gfs2/Kconfig  2007-01-28 16:44:59.0 
> +0100
> @@ -34,11 +34,10 @@
>  
>  config GFS2_FS_LOCKING_DLM
>   tristate "GFS2 DLM locking module"
> - depends on GFS2_FS && NET && INET && (IPV6 || IPV6=n)
> + depends on GFS2_FS && SYSFS && NET && INET && (IPV6 || IPV6=n)
>   select IP_SCTP if DLM_SCTP
>   select CONFIGFS_FS
>   select DLM
> - select SYSFS
>   help
>   Multiple node locking module for GFS2
>  
> --- linux-2.6.20-rc6-mm1/fs/dlm/Kconfig.old   2007-01-28 16:56:57.0 
> +0100
> +++ linux-2.6.20-rc6-mm1/fs/dlm/Kconfig   2007-01-28 16:57:16.0 
> +0100
> @@ -3,9 +3,8 @@
>  
>  config DLM
>   tristate "Distributed Lock Manager (DLM)"
> - depends on IPV6 || IPV6=n
> + depends on SYSFS && (IPV6 || IPV6=n)
>   select CONFIGFS_FS
> - select SYSFS
>   select IP_SCTP if DLM_SCTP
>   help
>   A general purpose distributed lock manager for kernel or userspace
> 
> -

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

Re: [SCRIPT] Remove "space damage" from patches

[Richard Knutsson]

Oleg Verych wrote:

On Mon, Jan 29, 2007 at 02:26:04AM +0100, Richard Knutsson wrote:
[]
  
I also guess you saw that the script is _not_ for cleaning up 
source-files (can be intrusive and is better to be fixed when fixing 
something else), but patches.



IMHO it's dealing with consequences, not cause, and it's even worse.
  
How many patches is not to fix bugs, it is worse then some strayed 
whitespace but it is due to reality.
The best is, of course, if neither happened but the next best thing is 
to fix it. And if it can be automated, even better (imho).

So if a maintainer does not have anything to easily fix those, they
might want a simple script to do the work (otherwise I believe they
just deleted my mail ;) ).



I would like to discuss, would you?
  
I like to discuss but I am not sure what the result would be. Force 
people to use the editors of our choice?
As long people uses valid e-mail-clients when sending patches (or they 
use the script "sendpatchset"), I'm think we have to be satisfied.

But if you have any ideas, I'm listening.

Richard Knutsson

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

Re: [Patch][NFSv4]: Kernel panic (handle kernel NULL pointer)occurred in NFSv4 by the nfs_update_inode()

[fj-shic]

Hi, all

  Is there any good idea about this issue?
  I really think this is a problem in the NFSv4, which should be resolved 
in the latest kernel.


  Thank you for any information on this issue.


Hi, all

 I have been working on trying to evaluate the robustness of the NFS.
 When I run the files creating test on NFSv4, the kernel panic (handle
kernel NULL pointer) happened during the test when
the /proc/sys/sunrpc/nfs_debug was set to 65535.

The test I run is:
  Mount:
  mount -t nfs4  192.168.0.21:/  /mnt
  Test script:
A process creates and opens 1024 files on NFSv4
The process writes some test message to each file.
The process closes all the opening files and exit.
After the process exit, the test begins to umount the NFSv4
immediately.

In normal case, I haven't found the problem in the test; but when
the /proc/sys/sunrpc/nfs_debug is set to debug mode(65535), the panic
problem will usually happens.

The kernel panic log is as follows:

NFS: nfs_update_inode(0:18/2049980 ct=1 info=0xe)
BUG: unable to handle kernel NULL pointer dereference at virtual address
000c
printing eip: deb82605
*pde = 001f3067
Oops:  [#1]
SMP
last sysfs file: /block/hda/removable
Modules linked in: nfs fscache nfsd ¡­. ¡­¡­.
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246   (2.6.18-1.2747.el5 #1)
EIP is at nfs_update_inode+0xb0/0x692 [nfs]
¡­skip¡­.
Process rpciod/0 (pid: 1865, ti=dd3ac000 task=ddd47550 task.ti=dd3ac000)
Stack: deba0609 ¡­ ¡­
Call Trace:
[] nfs_refresh_inode+0x38/0x1b0 [nfs]
[] rpc_exit_task+0x1e/0x6c [sunrpc]
[] __rpc_execute+0x82/0x1b3 [sunrpc]
[] run_workqueue+0x83/0xc5
[] worker_thread+0xd9/0x10c
[] kthread+0xc0/0xec
[] kernel_thread_helper+0x7/0x10
DWARF2 unwinder stuck at kernel_thread_helper+0x7/0x10

I have investigated the problem, and found the cause was the NULL
pointer i_sb->s_root in the "nfs_update_inode()" when the panic
happened.

 In the kernel, at the end of the file closing operation, the
nfs_file_release() will be invoked.

 I have found the operation process of the kernel is as follows:
 nfs_file_release()
  |-- NFS_PROTO(inode)->file_release ()
|
  nfs_file_clear_open_context()
|
   put_nfs_open_context()
  | -- nfs4_close_state
  |   | -- nfs4_close_ops
  | |
  |   nfs4_do_close()
  |  |
  | nfs_update_inode()
  ||-- inode == inode->i_sb-

s_root->d_inode

  |
  | -- mntput(ctx_vfsmnt)
 |
atomic_dec_and_lock(>mnt_count,
_lock)

After the asynchronous RPC call "nfs4_close_ops" is invoked in
put_nfs_open_context(), the kernel invokes the mntput(), and the mnt-

mnt_count is decreased. In my test, after the file closing operation,

the sys_umont() was executed immediately. In normal case, the
asynchronous RPC call "nfs4_close_ops" can be completed quickly, and it
rarely ever happens that the sys_umount() is invoked before the end of
nfs_update_inode() operation. But when the sunrpc/nfs_debug is set to
debug mode, a lot of printk operations will be invoked in NFS. Due to
the lots of prink operations, the RPC call "nfs4_close_ops" will easily
be delayed, then it is possible that the sys_umount() is invoked before
the end of nfs_update_inode() operation. In the do_umont() (Because mnt-

mnt_count has been decreased, umount can be executed successfully), the

sb->s_root will be set to NULL in the shrink_dcache_for_umount () which
is invoked by the nfs_kill_super().
Therefore, kernel panic occurred by the NULL pointer access when
nfs_update_date() accessed inode->i_sb->s_root.

Because there is a possibility that sb->s_root of a super_block is set
to NULL with umount when nfs4_close_ops () is not finished in the NFS.
It is really necessary to check an empty pointer for the inode->i_sb-

s_root in the nfs_update_date().


This problem still exists in the latest linux kernel.
To resolve this problem, I have made the patch below for the
linux-2.6.19.2. After the patch is applied, the problem can be resolved.
signed-off-by:ShiChao <[EMAIL PROTECTED]>

--- old/fs/nfs/inode.c 2007-01-17 17:19:48.994020288 -0500
+++ new/fs/nfs/inode.c 2007-01-17 17:20:26.570307824 -0500
@@ -914,7 +914,7 @@

 server = NFS_SERVER(inode);
 /* Update the fsid if and only if this is the root directory */
- if (inode == inode->i_sb->s_root->d_inode
+ if ( inode->i_sb->s_root && inode == inode->i_sb->s_root->d_inode
 && !nfs_fsid_equal(>fsid, >fsid))
 server->fsid = fattr->fsid;


___
NFSv4 mailing list
[EMAIL PROTECTED]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  

[PATCH RFC] sd: spin down disks on removal or power-down

[Robert Hancock]

Here's a patch for sd.c I've cooked up which issues a START STOP UNIT
command to stop the drive when the SCSI disk is removed or the machine
is powered down. The rationale behind this is that apparently on many
drives, simply cutting power to the spinning disk forces it to do an
emergency head park/unload which creates more wear on the drive then a
controlled park/unload with power still applied. This change ensures
that the drive will be spun down if the user shuts down the machine or
if they are about to hot-unplug the drive and have done "scsiadd -r" first.

The main potential concern I have about this implementation is that if
the drive is used in a multi-initiator, iSCSI, etc. environment,
stopping the drive may be undesirable as another initiator may still be
accessing it. I'm not familiar enough with these setups to know if this
problem is likely to come up or not. For this and other reasons we may
want to make this behavior controllable - I'm open to suggestions on how
to do this or whether it's needed.

I've tested that this does work on SATA disks through libata (with my
patch "libata: fix translation for START STOP UNIT" applied). I also
tested with some external USB-to-IDE drive enclosures. The support for
START STOP UNIT on those seems rather poor though, on one enclosure with
a Genesys bridge chip it returned a check condition with "Invalid field
in CDB", and on another with a JMicron chip the request succeeded but it
didn't actually spin the drive down.

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




--- linux-2.6.20-rc6nv/drivers/scsi/sd.c2007-01-28 17:00:00.0 
-0600
+++ linux-2.6.20-rc6nvedit/drivers/scsi/sd.c2007-01-28 18:08:53.0 
-0600
@@ -821,6 +821,39 @@ static int sd_sync_cache(struct scsi_dev
return res;
 }
 
+static int sd_stop_unit(struct scsi_device *sdp, struct scsi_disk* sdkp)
+{
+   int res;
+   struct scsi_sense_hdr sshdr;
+   unsigned char cmd[10] = { 0 };
+
+   if (!scsi_device_online(sdp))
+   return -ENODEV;
+
+   cmd[0] = START_STOP;
+   /*
+* Leave the rest of the command zero to indicate
+* transition to stopped power condition and return
+* on completion.
+*/
+   printk(KERN_NOTICE "Stopping SCSI disk %s\n",
+   sdkp->disk->disk_name);
+   res = scsi_execute_req(sdp, cmd, DMA_NONE, NULL, 0, ,
+  SD_TIMEOUT, SD_MAX_RETRIES);
+
+   if (res) {
+   printk(KERN_WARNING "sd stop failed: status = %x, message = 
%02x, "
+   "host = %d, driver = %02x\n",
+   status_byte(res), msg_byte(res),
+   host_byte(res), driver_byte(res));
+   if (driver_byte(res) & DRIVER_SENSE)
+   scsi_print_sense_hdr("sd", );
+   }
+   
+   return res;
+}
+
+
 static int sd_issue_flush(struct device *dev, sector_t *error_sector)
 {
int ret = 0;
@@ -1727,11 +1760,13 @@ static int sd_probe(struct device *dev)
  **/
 static int sd_remove(struct device *dev)
 {
+   struct scsi_device *sdp = to_scsi_device(dev);
struct scsi_disk *sdkp = dev_get_drvdata(dev);
 
class_device_del(>cdev);
del_gendisk(sdkp->disk);
sd_shutdown(dev);
+   sd_stop_unit(sdp,sdkp);
 
mutex_lock(_ref_mutex);
dev_set_drvdata(dev, NULL);
@@ -1784,6 +1819,9 @@ static void sd_shutdown(struct device *d
sdkp->disk->disk_name);
sd_sync_cache(sdp);
}
+   if(system_state == SYSTEM_POWER_OFF)
+   sd_stop_unit(sdp,sdkp);
+   
scsi_disk_put(sdkp);
 }
 

Re: The mbox format archives of linux-kernel are gone.

[Oleg Verych]

On Sun, Jan 28, 2007 at 03:17:06PM -0800, Andrew Morton wrote:
> On Sun, 28 Jan 2007 22:46:32 +
> Oleg Verych <[EMAIL PROTECTED]> wrote:
> 
> > If somebody will get lkml mbox archive, can you import it into gmane,
> > please.
> 
> http://userweb.kernel.org/~akpm/lkml-mbox-archives/

I think, whole set, possibly from most active start years, say 1993, 1994
or so, must be collected, then i can contact Lars to try to import all
this into Gmane with current web links being preserved.

BTW, donwloading (big) sets of archives _from_ Gmane is strongly
discouraged.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/6] MSI portability cleanups

[Benjamin Herrenschmidt]

> To be clear I see this as 2 distinct layers of code. enable/disable
> that talks directly to the hardware, and the helpers of enable/disable
> that allocate the irq.  I base this on the fact that I only need the
> alloc/free when I am exclusively working with real hardware.

We need the alloc/free in all cases, wether we are talking to real HW or
hypervisor. Alloc free is what allocates linux virtual irq numbers (or
irq_desc's if your prefer) and what sets up the irq_desc->irq_chip to
the appropriate thing for MSIs on that machines. Thus it's really the
required step for everybody.

The thing you seem to be mixing up is allocating of linux virtual irqs
(picking an irq desc) and allocating of a HW vectors on your platformn
(which happens to be the same pretty much on x86 nowdays no ? That is,
they have the same numbering domain don't they ?).

That is, while in the HV case, we don't allocate HW vectors (the HV does
it for us), we still need to allocate linux irqs, setup the irq desc,
and hook them up.

> > You seem to absolutely want to get the HV case to go throuh the same
> > code path as the "raw" case, and that will not happen.
> 
> Yes I do.  Because that is the only sane approach for a HV to use.

BUT WE DON'T HAVE A CHOICE ON WHAT APPROACH THE HV USES  pfff...
Isn't that clear enough ?

IBM will not change their HV interfaces becasue you don't like them, and
I doubt sun will neither and despite you disagreeing on that, we -do-
have to support them (hell, that's what I'm paid for among other
things :-)

It would be nice if we could dictate all HV and hardware vendors around
how we think they should work and what interfaces they should provide, I
suppose M$ can do that with Windows, but unfortunately, we aren't in a
position to do that.
 
> And yes we need an irq allocator to call the HV to setup the upstream
> reception of the msi message.

Not sure I completely parse the above.

> However I don't think it will be to hard to support your HV once we get
> the real hardware supported.  I just refuse to consider it before we have
> figured out what makes sense in the context where we have to do everything.

Hrmph

> >   .../... (irq operations)
> >
> >> These because they are per irq make sense as per bus operations unless
> >> you have a good architecture definition like x86 has.  Roughly those
> >> operations are what we currently have except the current operations
> >> are a little simpler and easier to deal with for the architecture
> >> code.
> >
> > Oh ? How so ? (easier/simpler ?)
> 
> I don't take a type parameter, and I don't take a vector.  All of
> that work is done in the generic code.

Well, so basically, the main difference is that we make MSI looks like
MSI-X by providing an alloc/free abstraction that takes an array in all
cases and you make MSI-X look like MSI by working one interrupt at a
time.

Your case avoids a for () loop in the backend, at the cost of being
fundamentally incompatible with our HV approach (and possibly others
like sparc64).

We do pass the MSI vs. MSI-X because it's handy for the HV case to pass
it along to the firmware, though it doesn't have to be used, and indeed,
in the "raw" case, we don't use it.
 
> > This is indeed a lower level hook to be used by "raw" enable/disable. An
> > other approach would be to remove it, have each backend have it's own
> > enable/disable that obtains the address/data and calls into a helper to
> > program them. This would indeed be a little bit nicer in a layering
> > perspective. But it adds a bit more code to each backend, so we kept
> > things closer to the way they used to be. I don't have a firm reason not
> > to change it however, I need talk to Michael in case he has more good
> > reasons to keep it that way around. 
> 
> The current code in the kernel already is structured that way because
> we have to reprogram the msi message on each irq migration.  Not using
> a helper to write the message would be a noticeable change and require
> a fair amount of code rewriting on the currently supported
> architectures.

We never proposed not to use a helper to write back the message. We are
missing such a helper in the current implementation, true, but that
doesn't mean we are opposed to havign it, on the contrary.

However, I don't think your implementation is much cleaner :-) The thing
is that Michael's implementation completely avoids having any knowledge
of the specifics of enabling/disabling MSI's or MSI-X's in the top level
core code.

The main difference after the alloc/free case is the enable/disable
case:

You do something like that: Toplevel calls the backend "setup" for each
MSI or MSI-X, which itself then calls back into a helper to actually
write the message, that helper doing then a switch/case on MSI vs. MSI-X
based on infos in the msi desc. Then, you go back to the toplevel which
goes whack the config space to atually do the global enabling of MSIs or
MSI-X.

Well, I don't think that from a layering 

Re: [SCRIPT] Remove "space damage" from patches

[Oleg Verych]

On Mon, Jan 29, 2007 at 02:26:04AM +0100, Richard Knutsson wrote:
[]
> I also guess you saw that the script is _not_ for cleaning up 
> source-files (can be intrusive and is better to be fixed when fixing 
> something else), but patches.

IMHO it's dealing with consequences, not cause, and it's even worse.

> So if a maintainer does not have anything to easily fix those, they
> might want a simple script to do the work (otherwise I believe they
> just deleted my mail ;) ).

I would like to discuss, would you?


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

Re: [2.6 patch] NF_CONNTRACK_H323 must depend on (IPV6 || IPV6=n)

[Randy Dunlap]

Adrian Bunk wrote:

On Sun, Jan 28, 2007 at 04:04:42PM -0800, David Miller wrote:

From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Mon, 29 Jan 2007 01:00:11 +0100


On Sun, Jan 28, 2007 at 03:53:48PM -0800, David Miller wrote:

Adrian is this the correct way to constrain the selection between
"n" and "m" in this kind of situation?  I thought doing something
like "depends on IPV6" is sufficient to achieve that?
"depends on IPV6" would fix the bug - but it would also make 
NF_CONNTRACK_H323 unavailable for all people without IPV6 support in 
their kernel.

Yes, that is an issue.

I guess with some slightly ugly ifdefs we could support the
whole matrix of possibilities.  But perhaps that's undesirable
for another reason.
...


This depends on what NF_CONNTRACK_H323=y, IPV6=m is supposed to be:
- not allowed (NF_CONNTRACK_H323 must be modular) or
- NF_CONNTRACK_H323 can only be used for IPV4

My patch implements the first case.


Sorry for the slow reponse.  This bug only came up due to my
bad gfs2/dlm patch, which Adrian has now corrected, so I think
you can just drop this patch.  It now builds for me with only
Adrian's gfs2/dlm patch applied.

--
~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] libata: fix translation for START STOP UNIT

[Robert Hancock]

Applies to 2.6.20-rc6.

---

libata's SCSI translation for the SCSI START STOP UNIT command with the 
START bit clear (i.e. stopping the drive) appears to be incorrect. It 
sends an ATA STANDBY command with the time period set to 0, which the 
code comment says means "now", but the ATA standard says this means 
disable the standby timer, which effectively does nothing. Change this 
to issue a STANDBY IMMEDIATE command which will actually spin the drive 
down. The SAT (SCSI/ATA Translation) standard revision 9 concurs with 
this choice.


Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

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


--- linux-2.6.20-rc6nv/drivers/ata/libata-scsi.c2007-01-28 
16:59:58.0 -0600
+++ linux-2.6.20-rc6nvedit/drivers/ata/libata-scsi.c2007-01-28 
17:30:12.0 -0600
@@ -983,11 +983,10 @@ static unsigned int ata_scsi_start_stop_
}
 
tf->command = ATA_CMD_VERIFY;   /* READ VERIFY */
-   } else {
-   tf->nsect = 0;  /* time period value (0 implies now) */
-   tf->command = ATA_CMD_STANDBY;
-   /* Consider: ATA STANDBY IMMEDIATE command */
-   }
+   } else
+   /* Issue ATA STANDBY IMMEDIATE command */
+   tf->command = ATA_CMD_STANDBYNOW1;
+
/*
 * Standby and Idle condition timers could be implemented but that
 * would require libata to implement the Power condition mode page

Re: [SCRIPT] Remove "space damage" from patches

[Richard Knutsson]

Oleg Verych wrote:

29-01-2007, Richard Knutsson:
  

Oleg Verych wrote:


Nack, big and fat. It's userspace problem.

If our "developers" can't use or update their every-day-tools, it's a
shame. And this is not trolling: i'm using Jed and GNU Emacs, both are
ok with whitespace "production".
  
Oh, I hope I didn't give the impression I wanted it in the kernel (that 
is why i labeled it as SCRIPT and not PATCH), as you said it is a 
userspace problem. I just thought a simple script to remove those 
whitespace could help in an imperfect world. I prefer kate since then 
you can see where the tabs begins (and other features).



Just to give you idea, how imperfect it is:


Anyway, i still think programmers *must* take care of it, if they think
they _are_ Programmers. IMHO LKML already gives obligation to be one
Then I hope you don't mind me asking, why is there (L)indent? Everyone 
can make a mistake and if your editor does not auto-format then there 
may be a whitespace straying.
I also guess you saw that the script is _not_ for cleaning up 
source-files (can be intrusive and is better to be fixed when fixing 
something else), but patches. So if a maintainer does not have anything 
to easily fix those, they might want a simple script to do the work 
(otherwise I believe they just deleted my mail ;) ).


As I said in the posting, it is just if someone is interested in it, 
otherwise you have a Del-button.


Richard Knutsson

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

Re: unfixed regression in 2.6.20-rc6 (since 2.6.19)

[Oleg Verych]

> From: Rainer Weikusat
> Newsgroups: gmane.linux.kernel
> Subject: Re: unfixed regression in 2.6.20-rc6 (since 2.6.19)
> Date: Sun, 28 Jan 2007 14:34:56 +0100

Hallo.

> Greg KH <[EMAIL PROTECTED]> writes:
[]
>> Please work to see what is wrong with the existing patch.  Is there
>> anything that I can do to help you out?
>
> This thing has consumed something like sixteen hours of my life in
> total, with a gain-to-be-expected of exactly zero (I don't need to run
> 'current' kernels on my work machine, I have just grown into the habit
> of doing so) and those sixteen hours cannot come back (and I even have
> had these type of discussions around 'should it rather look like math
> or rather like text' in sufficent quantities :->), so, except that I
> would be very much obliged to you if a fix for this issue could go
> into the 'official' tree rather sooner than later, no.

It's hot here.

I'm in similar situation (even *usb-serial* driver [TI USB] led me there;)

In short, it turned, that usb drivers aren't drivers at all, they are
just "USB interface drivers", i.e. managers of the particular USB
interface *in* the device.

Problem is: after changing ti-usb-serial's firmware, it is being reset
and apears with new device ID. It's OK so far, but even this may be
better (from USB hardware implementation point of view). Then this
device, after being caught with new ID by the same "driver" requires
seting USB configuration #2, in order to be usb-serial converter. Day was
lost to make this happen _inside_ driver (kernel 2.6.18). It turned, that
only way to do so is SYSFS, that set up by udev, and
"usb_set_configuration()" function is being used for that.

1. Why it's not called "sysfs_usb_set_configuration()"?

2. Why

   [USB device view]: vID:dID -- bNumConfigurations -- bNumInterfaces

is being only device IDs tables in usb drivers?

3. Where's configuration and/or interfaces choosing? Yes, this may be not
so wide used, but hey, it's design issue! There's a big cave in device
setup and configuration chain!

Look at 2.6.19 with "usb_driver_set_configuration()" to see it.

And don't say, USB device requires userspace to setup (external
firmware is another question). I can be young and stupid, and this is
very wired only for my understanding. Simple NULL by default or set
table of {num_usb_conf, num_interface} for "drivers" will be enough.

> Apart from that, I make a (fairly miserable) living by adapting open
> source code to be usable in specific situations (ie adding or
> modifying features, fixing bugs, writing drivers etc)

So and i. I wanted to adopt request_firmware() for TI USB serial, but
i became very confused and upset.

--
-o--=O`C
 #oo'L O
<___=E 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/

[PATCH -mm] sata_nv: use ADMA for NODATA commands

[Robert Hancock]

Patch is against 2.6.20-rc6-mm1, though will also apply to 2.6.20-rc6 if 
sata_nv-cleanup-adma-error-handling-v2.patch and 
sata_nv-cleanup-adma-error-handling-v2-cleanup.patch from -mm are 
applied first. Testing from those who experienced the previous cache 
flush timeout problem, in particular, would be appreciated.


---

Some problems showed up recently with cache flush commands timing out on 
sata_nv. Previously these commands were always handled by transitioning 
to legacy mode from ADMA mode first. The timeout problem was worked 
around already by a change to the interrupt handling code for legacy 
mode, but for non-data commands like these it appears we can handle them 
in ADMA mode, so the switch to legacy mode is not needed.


This patch changes the behavior so that we use ADMA mode to submit 
interrupt-driven commands with ATA_PROT_NODATA protocol. In addition to 
avoiding the problem mentioned above entirely, this avoids the overhead 
of switching to legacy mode and back to ADMA mode for handling cache 
flushes. When handling non-DMA-mapped commands, we leave the APRD blank 
and clear the NV_CPB_CTL_APRD_VALID field in the CPB so the controller 
does not attempt to read it.


Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

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

--- linux-2.6.20-rc6nv/drivers/ata/sata_nv.c2007-01-28 17:05:27.0 
-0600
+++ linux-2.6.20-rc6nvedit/drivers/ata/sata_nv.c2007-01-28 
17:20:11.0 -0600
@@ -1172,16 +1172,31 @@ static void nv_adma_fill_sg(struct ata_q
cpb->next_aprd = cpu_to_le64(((u64)(pp->aprd_dma + 
NV_ADMA_SGTBL_SZ * qc->tag)));
 }
 
+static int nv_adma_use_reg_mode(struct ata_queued_cmd *qc)
+{
+   struct nv_adma_port_priv *pp = qc->ap->private_data;
+   
+   /* ADMA engine can only be used for non-ATAPI DMA commands,
+  or interrupt-driven no-data commands. */
+   if((pp->flags & NV_ADMA_ATAPI_SETUP_COMPLETE) ||
+  (qc->tf.flags & ATA_TFLAG_POLLING))
+   return 1;
+
+   if((qc->flags & ATA_QCFLAG_DMAMAP) ||
+  (qc->tf.protocol == ATA_PROT_NODATA))
+   return 0;
+   
+   return 1;
+}
+
 static void nv_adma_qc_prep(struct ata_queued_cmd *qc)
 {
struct nv_adma_port_priv *pp = qc->ap->private_data;
struct nv_adma_cpb *cpb = >cpb[qc->tag];
u8 ctl_flags = NV_CPB_CTL_CPB_VALID |
-  NV_CPB_CTL_APRD_VALID |
   NV_CPB_CTL_IEN;
 
-   if (!(qc->flags & ATA_QCFLAG_DMAMAP) ||
-(pp->flags & NV_ADMA_ATAPI_SETUP_COMPLETE)) {
+   if (nv_adma_use_reg_mode(qc)) {
nv_adma_register_mode(qc->ap);
ata_qc_prep(qc);
return;
@@ -1200,8 +1215,12 @@ static void nv_adma_qc_prep(struct ata_q
VPRINTK("qc->flags = 0x%lx\n", qc->flags);
 
nv_adma_tf_to_cpb(>tf, cpb->tf);
-
-   nv_adma_fill_sg(qc, cpb);
+   
+   if(qc->flags & ATA_QCFLAG_DMAMAP) {
+   nv_adma_fill_sg(qc, cpb);
+   ctl_flags |= NV_CPB_CTL_APRD_VALID;
+   } else
+   memset(>aprd[0], 0, sizeof(struct nv_adma_prd) * 5);
 
/* Be paranoid and don't let the device see NV_CPB_CTL_CPB_VALID until 
we are
   finished filling in all of the contents */
@@ -1216,10 +1235,9 @@ static unsigned int nv_adma_qc_issue(str
 
VPRINTK("ENTER\n");
 
-   if (!(qc->flags & ATA_QCFLAG_DMAMAP) ||
-(pp->flags & NV_ADMA_ATAPI_SETUP_COMPLETE)) {
+   if (nv_adma_use_reg_mode(qc)) {
/* use ATA register mode */
-   VPRINTK("no dmamap or ATAPI, using ATA register mode: 0x%lx\n", 
qc->flags);
+   VPRINTK("using ATA register mode: 0x%lx\n", qc->flags);
nv_adma_register_mode(qc->ap);
return ata_qc_issue_prot(qc);
} else

Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit

[Arjan van de Ven]

On Tue, 2007-01-23 at 23:28 +0300, Samium Gromoff wrote:
> Author: Samium Gromoff <[EMAIL PROTECTED]>
> Date:   Tue Jan 23 22:31:13 2007 +0300
> 
> Define the ELF binary header flag EF_AS_NO_RANDOM
> 
> EF_AS_NO_RANDOM should mean that the binary requests to not apply
> randomisation to address spaces of its processes.

sounds like it's not the right approach; better to follow the
PT_GNU_STACK example and do it that way.

(assuming you even need it... I personally consider every binary that
would need this flag as broken)

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

Re: lockmeter

[Martin J. Bligh]

Arjan van de Ven wrote:

On Sun, 2007-01-28 at 17:04 +, Christoph Hellwig wrote:

On Sun, Jan 28, 2007 at 08:52:25AM -0800, Martin J. Bligh wrote:

Mmm. not wholly convinced that's true. Whilst i don't have lockmeter
stats to hand, the heavy time in __d_lookup seems to indicate we may
still have a problem to me. I guess we could move the spinlocks out
of line again to test this fairly easily (or get lockmeter upstream).

We definitly should get lockmeter in.  Does anyone volunteer for doing
the cleanup and merged?


specifically; implementing it on top of lockdep should be very lean and
simple...


cc: John Hawkes, if we're going to discuss this ;-)

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/

slab: start_cpu_timer/cache_reap CONFIG_HOTPLUG_CPU problems

[Oleg Nesterov]

For the beginning, about another (but related) minor problem,

debug_smp_processor_id:

/*
 * Kernel threads bound to a single CPU can safely use
 * smp_processor_id():
 */

This is only true without CONFIG_HOTPLUG_CPU. Otherwise CPU can go away when
the task takes a preemption or sleeps. I think we need #ifndef here.


Now,
static void __devinit start_cpu_timer(int cpu)
{
struct delayed_work *reap_work = _cpu(reap_work, cpu);

if (keventd_up() && reap_work->work.func == NULL) {
init_reap_node(cpu);
INIT_DELAYED_WORK(reap_work, cache_reap);
schedule_delayed_work_on(cpu, reap_work,
__round_jiffies_relative(HZ, 
cpu));
}
}

This is wrong. Suppose we have a CPU_UP,CPU_DOWN,CPU_UP sequence. The last
CPU_UP will not restart a per-cpu "cache_reap timer".


With or without recent changes, it is possible that work->func() will run on
another CPU (not that to which it was submitted) if CPU goes down. In fact,
this can happen while work->func() is running, so even smp_processor_id()
is not safe to use in work->func().

However, cache_reap() seems to wrongly assume that smp_processor_id() is stable,
this is the second problem.

Is my understanding correct?

Oleg.

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

Re: lockmeter

[Arjan van de Ven]

On Sun, 2007-01-28 at 17:04 +, Christoph Hellwig wrote:
> On Sun, Jan 28, 2007 at 08:52:25AM -0800, Martin J. Bligh wrote:
> > Mmm. not wholly convinced that's true. Whilst i don't have lockmeter
> > stats to hand, the heavy time in __d_lookup seems to indicate we may
> > still have a problem to me. I guess we could move the spinlocks out
> > of line again to test this fairly easily (or get lockmeter upstream).
> 
> We definitly should get lockmeter in.  Does anyone volunteer for doing
> the cleanup and merged?

specifically; implementing it on top of lockdep should be very lean and
simple...


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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][NFSv4]: Kernel panic (handle kernel NULL pointer) occurred in NFSv4 by the nfs_update_inode()

[fj-shic]

Hi, all

  Is there any good idea about this issue?
  I really think this is a problem in the NFSv4, which should be resolved 
in the latest kernel.


  Thank you for any information on this issue.


Hi, all

 I have been working on trying to evaluate the robustness of the NFS.
 When I run the files creating test on NFSv4, the kernel panic (handle
kernel NULL pointer) happened during the test when
the /proc/sys/sunrpc/nfs_debug was set to 65535. The test I run is:
  Mount: mount -t nfs4  192.168.0.21:/  /mnt
  Test script:
A process creates and opens 1024 files on NFSv4
The process writes some test message to each file.
The process closes all the opening files and exit.
After the process exit, the test begins to umount the NFSv4
immediately.

In normal case, I haven't found the problem in the test; but when
the /proc/sys/sunrpc/nfs_debug is set to debug mode(65535), the panic
problem will usually happens.

The kernel panic log is as follows:

NFS: nfs_update_inode(0:18/2049980 ct=1 info=0xe)
BUG: unable to handle kernel NULL pointer dereference at virtual address
000c
printing eip: deb82605
*pde = 001f3067
Oops:  [#1]
SMP
last sysfs file: /block/hda/removable
Modules linked in: nfs fscache nfsd ¡­. ¡­¡­.
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246   (2.6.18-1.2747.el5 #1)
EIP is at nfs_update_inode+0xb0/0x692 [nfs]
¡­skip¡­.
Process rpciod/0 (pid: 1865, ti=dd3ac000 task=ddd47550 task.ti=dd3ac000)
Stack: deba0609 ¡­ ¡­
Call Trace:
[] nfs_refresh_inode+0x38/0x1b0 [nfs]
[] rpc_exit_task+0x1e/0x6c [sunrpc]
[] __rpc_execute+0x82/0x1b3 [sunrpc]
[] run_workqueue+0x83/0xc5
[] worker_thread+0xd9/0x10c
[] kthread+0xc0/0xec
[] kernel_thread_helper+0x7/0x10
DWARF2 unwinder stuck at kernel_thread_helper+0x7/0x10

I have investigated the problem, and found the cause was the NULL
pointer i_sb->s_root in the "nfs_update_inode()" when the panic
happened.

 In the kernel, at the end of the file closing operation, the
nfs_file_release() will be invoked.

 I have found the operation process of the kernel is as follows: 
nfs_file_release()

  |-- NFS_PROTO(inode)->file_release ()   |
  nfs_file_clear_open_context()
|
   put_nfs_open_context()
  | -- nfs4_close_state
  |   | -- nfs4_close_ops
  | |
  |   nfs4_do_close()
  |  |
  | nfs_update_inode()
  ||-- inode == inode->i_sb-

s_root->d_inode

  |
  | -- mntput(ctx_vfsmnt)
 |
atomic_dec_and_lock(>mnt_count,
_lock)

After the asynchronous RPC call "nfs4_close_ops" is invoked in
put_nfs_open_context(), the kernel invokes the mntput(), and the mnt-

mnt_count is decreased. In my test, after the file closing operation,

the sys_umont() was executed immediately. In normal case, the
asynchronous RPC call "nfs4_close_ops" can be completed quickly, and it
rarely ever happens that the sys_umount() is invoked before the end of
nfs_update_inode() operation. But when the sunrpc/nfs_debug is set to
debug mode, a lot of printk operations will be invoked in NFS. Due to
the lots of prink operations, the RPC call "nfs4_close_ops" will easily
be delayed, then it is possible that the sys_umount() is invoked before
the end of nfs_update_inode() operation. In the do_umont() (Because mnt-

mnt_count has been decreased, umount can be executed successfully), the

sb->s_root will be set to NULL in the shrink_dcache_for_umount () which
is invoked by the nfs_kill_super().
Therefore, kernel panic occurred by the NULL pointer access when
nfs_update_date() accessed inode->i_sb->s_root.

Because there is a possibility that sb->s_root of a super_block is set
to NULL with umount when nfs4_close_ops () is not finished in the NFS. It 
is really necessary to check an empty pointer for the inode->i_sb-

s_root in the nfs_update_date().


This problem still exists in the latest linux kernel.
To resolve this problem, I have made the patch below for the
linux-2.6.19.2. After the patch is applied, the problem can be resolved.
signed-off-by:ShiChao <[EMAIL PROTECTED]>

--- old/fs/nfs/inode.c 2007-01-17 17:19:48.994020288 -0500
+++ new/fs/nfs/inode.c 2007-01-17 17:20:26.570307824 -0500
@@ -914,7 +914,7 @@

 server = NFS_SERVER(inode);
 /* Update the fsid if and only if this is the root directory */
- if (inode == inode->i_sb->s_root->d_inode
+ if ( inode->i_sb->s_root && inode == inode->i_sb->s_root->d_inode
 && !nfs_fsid_equal(>fsid, >fsid))
 server->fsid = fattr->fsid;




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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Dave Airlie]

> > Because most users won't even be aware of the module option: they'll just
> > know that their card doesn't work right.
>
> This isn't a card problem this is a monitor problem, the card just
> passes through the edid data from the monitor... or else the
> programming of the card registers from edid is wrong..

In which case the same problem would occur with different video cards, so
this patch should be some generic thing, available to all drivers, no?



It should be in the fb layer not card specific.. as it may happen on any card...

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: swap: which is the maximum size allowed?

[Matt Mackall]

On Sun, Jan 28, 2007 at 09:01:34PM -0200, Eriberto wrote:
> Ok. But, mkswap man is old (1999). However, from Linux Partition HOWTO:
> 
> "footnote: "official" max swap size: With kernel 2.4, the limit is 64
> swap spaces at a maximum of 64Gb each, although this is not reflected in
> the man page for mkswap. With the 64 bit opteron on the 2.6 kernel, 128
> swap areas are permitted, each a whopping 16 Tb! (thanks to Peter Chubb
> for the calculation)"
> 
> I want to know: why 64 GB???

It's how big the available pointers are.

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Andrew Morton]

On Mon, 29 Jan 2007 11:12:57 +1100
"Dave Airlie" <[EMAIL PROTECTED]> wrote:

> > > Some nVidia video cards have broken EDID information. Using nvidiafb
> > > with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console
> > > framebuffer to use wrong timing information, causing the display to be
> > > extremely 'snowy'. Since most distribution kernels are compiled with
> > > CONFIG_FB_NVIDIA_I2C enabled, this prevents usage of the nvidia
> > > framebuffer on said broken system without recompiling the kernel
> > > (or at least the nvidiafb module).
> > >
> > > Solve the issue by introducing a new boolean module parameter (useedid)
> > > which can be set to 0 to prevent the driver from using the EDID
> > > information.
> > >
> > > If this patch is accepted, we can probably get rid of CONFIG_FB_NVIDIA_I2C
> > > altogether.
> > >
> >
> > That's a pretty sad solution.  Is it possible to detect these bad cards at
> > runtime via ther behaviour?  If not, can we generate a blacklist for the
> > known-bad cards based on PCI IDs or something?
> >
> > Because most users won't even be aware of the module option: they'll just
> > know that their card doesn't work right.
> 
> This isn't a card problem this is a monitor problem, the card just
> passes through the edid data from the monitor... or else the
> programming of the card registers from edid is wrong..

In which case the same problem would occur with different video cards, so
this patch should be some generic thing, available to all drivers, no?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [SCRIPT] Remove "space damage" from patches

[Oleg Verych]

29-01-2007, Richard Knutsson:
> Oleg Verych wrote:
>> Nack, big and fat. It's userspace problem.
>>
>> If our "developers" can't use or update their every-day-tools, it's a
>> shame. And this is not trolling: i'm using Jed and GNU Emacs, both are
>> ok with whitespace "production".
> Oh, I hope I didn't give the impression I wanted it in the kernel (that 
> is why i labeled it as SCRIPT and not PATCH), as you said it is a 
> userspace problem. I just thought a simple script to remove those 
> whitespace could help in an imperfect world. I prefer kate since then 
> you can see where the tabs begins (and other features).

Just to give you idea, how imperfect it is:


Anyway, i still think programmers *must* take care of it, if they think
they _are_ Programmers. IMHO LKML already gives obligation to be one.

> Richard Knutsson
>


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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Andrew Morton]

On Mon, 29 Jan 2007 11:12:57 +1100
"Dave Airlie" <[EMAIL PROTECTED]> wrote:

> > > Some nVidia video cards have broken EDID information. Using nvidiafb
> > > with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console
> > > framebuffer to use wrong timing information, causing the display to be
> > > extremely 'snowy'. Since most distribution kernels are compiled with
> > > CONFIG_FB_NVIDIA_I2C enabled, this prevents usage of the nvidia
> > > framebuffer on said broken system without recompiling the kernel
> > > (or at least the nvidiafb module).
> > >
> > > Solve the issue by introducing a new boolean module parameter (useedid)
> > > which can be set to 0 to prevent the driver from using the EDID
> > > information.
> > >
> > > If this patch is accepted, we can probably get rid of CONFIG_FB_NVIDIA_I2C
> > > altogether.
> > >
> >
> > That's a pretty sad solution.  Is it possible to detect these bad cards at
> > runtime via ther behaviour?  If not, can we generate a blacklist for the
> > known-bad cards based on PCI IDs or something?
> >
> > Because most users won't even be aware of the module option: they'll just
> > know that their card doesn't work right.
> 
> This isn't a card problem this is a monitor problem, the card just
> passes through the edid data from the monitor... or else the
> programming of the card registers from edid is wrong..
> 

oh.  I'll take that as an ack :(

(where'd my cc go?)

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

Re: [2.6 patch] NF_CONNTRACK_H323 must depend on (IPV6 || IPV6=n)

[Adrian Bunk]

On Sun, Jan 28, 2007 at 04:04:42PM -0800, David Miller wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
> Date: Mon, 29 Jan 2007 01:00:11 +0100
> 
> > On Sun, Jan 28, 2007 at 03:53:48PM -0800, David Miller wrote:
> > > Adrian is this the correct way to constrain the selection between
> > > "n" and "m" in this kind of situation?  I thought doing something
> > > like "depends on IPV6" is sufficient to achieve that?
> > 
> > "depends on IPV6" would fix the bug - but it would also make 
> > NF_CONNTRACK_H323 unavailable for all people without IPV6 support in 
> > their kernel.
> 
> Yes, that is an issue.
> 
> I guess with some slightly ugly ifdefs we could support the
> whole matrix of possibilities.  But perhaps that's undesirable
> for another reason.
>...

This depends on what NF_CONNTRACK_H323=y, IPV6=m is supposed to be:
- not allowed (NF_CONNTRACK_H323 must be modular) or
- NF_CONNTRACK_H323 can only be used for IPV4

My patch implements the first case.

cu
Adrian

-- 

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

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

Re: Juju

[Pete Zaitcev]

On Thu, 25 Jan 2007 16:18:35 -0500, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:

> Indeed, I've just moved to an in-tree development model now.  I still think 
> the out-off-tree model is a good way to prototype, get started and reach 
> "critical mass" with your driver.  But as I'm starting to integrate and sync 
> with Stefans tree now, an in-tree model is a lot easier to work with.  The 
> tree is here
> 
>git://people.freedesktop.org/~krh/linux-2.6

This seems to have disappeared. Was it moved or dropped?

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Dave Airlie]

> Some nVidia video cards have broken EDID information. Using nvidiafb
> with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console
> framebuffer to use wrong timing information, causing the display to be
> extremely 'snowy'. Since most distribution kernels are compiled with
> CONFIG_FB_NVIDIA_I2C enabled, this prevents usage of the nvidia
> framebuffer on said broken system without recompiling the kernel
> (or at least the nvidiafb module).
>
> Solve the issue by introducing a new boolean module parameter (useedid)
> which can be set to 0 to prevent the driver from using the EDID
> information.
>
> If this patch is accepted, we can probably get rid of CONFIG_FB_NVIDIA_I2C
> altogether.
>

That's a pretty sad solution.  Is it possible to detect these bad cards at
runtime via ther behaviour?  If not, can we generate a blacklist for the
known-bad cards based on PCI IDs or something?

Because most users won't even be aware of the module option: they'll just
know that their card doesn't work right.


This isn't a card problem this is a monitor problem, the card just
passes through the edid data from the monitor... or else the
programming of the card registers from edid is wrong..

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] nvidiafb: allow ignoring EDID info

[Andrew Morton]

On Sun, 28 Jan 2007 11:48:59 +0100
Giuseppe Bilotta <[EMAIL PROTECTED]> wrote:

> From: Giuseppe Bilotta <[EMAIL PROTECTED]>
> 
> Some nVidia video cards have broken EDID information. Using nvidiafb
> with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console
> framebuffer to use wrong timing information, causing the display to be
> extremely 'snowy'. Since most distribution kernels are compiled with
> CONFIG_FB_NVIDIA_I2C enabled, this prevents usage of the nvidia
> framebuffer on said broken system without recompiling the kernel
> (or at least the nvidiafb module).
> 
> Solve the issue by introducing a new boolean module parameter (useedid)
> which can be set to 0 to prevent the driver from using the EDID
> information.
> 
> If this patch is accepted, we can probably get rid of CONFIG_FB_NVIDIA_I2C
> altogether.
> 

That's a pretty sad solution.  Is it possible to detect these bad cards at
runtime via ther behaviour?  If not, can we generate a blacklist for the
known-bad cards based on PCI IDs or something?

Because most users won't even be aware of the module option: they'll just
know that their card doesn't work right.


> diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
> index 8454adf..6387f2b 100644
> --- a/drivers/video/nvidia/nv_i2c.c
> +++ b/drivers/video/nvidia/nv_i2c.c
> @@ -25,6 +25,8 @@
>  
>  #include "../edid.h"
>  
> +extern int useedid;
> +
>  static void nvidia_gpio_setscl(void *data, int state)
>  {
> struct nvidia_i2c_chan *chan = data;
> @@ -128,6 +130,9 @@ static int nvidia_setup_i2c_bus(struct nvidia_i2c_chan 
> *chan, const char *name)
>  
>  void nvidia_create_i2c_busses(struct nvidia_par *par)
>  {
> +   if (!useedid)
> +   return;
> +
> par->bus = 3;
>  
> par->chan[0].par = par;
> @@ -146,6 +151,9 @@ void nvidia_create_i2c_busses(struct nvidia_par *par)
>  
>  void nvidia_delete_i2c_busses(struct nvidia_par *par)
>  {
> +   if (!useedid)
> +   return;
> +
> if (par->chan[0].par)
> i2c_del_adapter(>chan[0].adapter);
> par->chan[0].par = NULL;
> @@ -195,6 +203,9 @@ static u8 *nvidia_do_probe_i2c_edid(struct 
> nvidia_i2c_chan *chan)
>  
>  int nvidia_probe_i2c_connector(struct fb_info *info, int conn, u8 **out_edid)
>  {
> +   if (!useedid)
> +   return -1;
> +
> struct nvidia_par *par = info->par;
> u8 *edid = NULL;
> int i;
> diff --git a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c
> index 538e947..179fd67 100644
> --- a/drivers/video/nvidia/nvidia.c
> +++ b/drivers/video/nvidia/nvidia.c
> @@ -83,6 +83,9 @@ static int bpp __devinitdata = 8;
>  #ifdef CONFIG_MTRR
>  static int nomtrr __devinitdata = 0;
>  #endif
> +#ifdef CONFIG_FB_NVIDIA_I2C
> +int useedid __devinitdata = 1;
> +#endif
>  
>  static char *mode_option __devinitdata = NULL;
>  
> @@ -1506,6 +1509,11 @@ module_param(nomtrr, bool, 0);
>  MODULE_PARM_DESC(nomtrr, "Disables MTRR support (0 or 1=disabled) "
>  "(default=0)");
>  #endif
> +#ifdef CONFIG_FB_NVIDIA_I2C
> +module_param(useedid, bool, 0);
> +MODULE_PARM_DESC(useedid, "Use EDID to detect video modes (0 or 1) "
> +"(default=1, use EDID)");
> +#endif
>  
>  MODULE_AUTHOR("Antonino Daplas");
>  MODULE_DESCRIPTION("Framebuffer driver for nVidia graphics chipset");
> 
> 
> 
> 
> -- 
> Giuseppe "Oblomov" Bilotta
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [SCRIPT] Remove "space damage" from patches

[Richard Knutsson]

Oleg Verych wrote:

From: Richard Knutsson
Newsgroups: gmane.linux.kernel
Subject: [SCRIPT] Remove "space damage" from patches
Date: Sun, 28 Jan 2007 22:37:01 +0100



  

Hello Andrew and all



Hallo.

  

I recently tried "git-apply" on the 2.6.20-rc6-mm1 patch and found it to 
complain about white-spaces.
So as a mean to (hopefully) cut down on these nasty white-spaces (and sometimes 
tabs) I wrote this
little script. All it does is checking (lines that are going to be added) for 
spaces before tabs
and trailing spaces/tabs. I tried it on 2.6.20-rc6-mm1 and it seem to work well

If there is someone interested, _please_ take it. Any suggestion are welcomed :)

Richard Knutsson



Nack, big and fat. It's userspace problem.

If our "developers" can't use or update their every-day-tools, it's a
shame. And this is not trolling: i'm using Jed and GNU Emacs, both are
ok with whitespace "production".
Oh, I hope I didn't give the impression I wanted it in the kernel (that 
is why i labeled it as SCRIPT and not PATCH), as you said it is a 
userspace problem. I just thought a simple script to remove those 
whitespace could help in an imperfect world. I prefer kate since then 
you can see where the tabs begins (and other features).


Richard Knutsson

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

Re: [2.6 patch] NF_CONNTRACK_H323 must depend on (IPV6 || IPV6=n)

[David Miller]

From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Mon, 29 Jan 2007 01:00:11 +0100

> On Sun, Jan 28, 2007 at 03:53:48PM -0800, David Miller wrote:
> > Adrian is this the correct way to constrain the selection between
> > "n" and "m" in this kind of situation?  I thought doing something
> > like "depends on IPV6" is sufficient to achieve that?
> 
> "depends on IPV6" would fix the bug - but it would also make 
> NF_CONNTRACK_H323 unavailable for all people without IPV6 support in 
> their kernel.

Yes, that is an issue.

I guess with some slightly ugly ifdefs we could support the
whole matrix of possibilities.  But perhaps that's undesirable
for another reason.

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

[PATCH] knfsd: Ratelimit some nfsd messages that are triggered by external events.

[NeilBrown]

Another nfsd patch suitable for 2.6.20, though it could wait for .21
if we feel it is time to be more cautious.
Thanks,
NeilBrown

### Comments for Changeset

Also remove {NFSD,RPC}_PARANOIA as having the defines doesn't
really add anything.

The printks covered by RPC_PARANOIA were tirggered by badly
formatted packets and so should be ratelimited.


Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./fs/nfsd/export.c |1 -
 ./fs/nfsd/nfsfh.c  |   14 ++
 ./fs/nfsd/vfs.c|1 -
 ./net/sunrpc/svc.c |   33 -
 ./net/sunrpc/svcsock.c |   12 
 5 files changed, 30 insertions(+), 31 deletions(-)

diff .prev/fs/nfsd/export.c ./fs/nfsd/export.c
--- .prev/fs/nfsd/export.c  2007-01-22 09:08:21.0 +1100
+++ ./fs/nfsd/export.c  2007-01-29 09:54:42.0 +1100
@@ -34,7 +34,6 @@
 #include 
 
 #define NFSDDBG_FACILITY   NFSDDBG_EXPORT
-#define NFSD_PARANOIA 1
 
 typedef struct auth_domain svc_client;
 typedef struct svc_export  svc_export;

diff .prev/fs/nfsd/nfsfh.c ./fs/nfsd/nfsfh.c
--- .prev/fs/nfsd/nfsfh.c   2007-01-22 09:08:23.0 +1100
+++ ./fs/nfsd/nfsfh.c   2007-01-29 10:56:39.0 +1100
@@ -24,8 +24,6 @@
 #include 
 
 #define NFSDDBG_FACILITY   NFSDDBG_FH
-#define NFSD_PARANOIA 1
-/* #define NFSD_DEBUG_VERBOSE 1 */
 
 
 static int nfsd_nr_verified;
@@ -230,13 +228,12 @@ fh_verify(struct svc_rqst *rqstp, struct
error = nfserrno(PTR_ERR(dentry));
goto out;
}
-#ifdef NFSD_PARANOIA
+
if (S_ISDIR(dentry->d_inode->i_mode) &&
(dentry->d_flags & DCACHE_DISCONNECTED)) {
printk("nfsd: find_fh_dentry returned a DISCONNECTED 
directory: %s/%s\n",
   dentry->d_parent->d_name.name, 
dentry->d_name.name);
}
-#endif
 
fhp->fh_dentry = dentry;
fhp->fh_export = exp;
@@ -267,12 +264,13 @@ fh_verify(struct svc_rqst *rqstp, struct
/* Finally, check access permissions. */
error = nfsd_permission(exp, dentry, access);
 
-#ifdef NFSD_PARANOIA_EXTREME
if (error) {
-   printk("fh_verify: %s/%s permission failure, acc=%x, 
error=%d\n",
-  dentry->d_parent->d_name.name, dentry->d_name.name, 
access, (error >> 24));
+   dprintk("fh_verify: %s/%s permission failure, "
+   "acc=%x, error=%d\n",
+   dentry->d_parent->d_name.name,
+   dentry->d_name.name,
+   access, (error >> 24));
}
-#endif
 out:
if (exp && !IS_ERR(exp))
exp_put(exp);

diff .prev/fs/nfsd/vfs.c ./fs/nfsd/vfs.c
--- .prev/fs/nfsd/vfs.c 2007-01-24 18:32:10.0 +1100
+++ ./fs/nfsd/vfs.c 2007-01-29 09:56:13.0 +1100
@@ -59,7 +59,6 @@
 #include 
 
 #define NFSDDBG_FACILITY   NFSDDBG_FILEOP
-#define NFSD_PARANOIA
 
 
 /* We must ignore files (but only files) which might have mandatory

diff .prev/net/sunrpc/svc.c ./net/sunrpc/svc.c
--- .prev/net/sunrpc/svc.c  2007-01-23 11:14:49.0 +1100
+++ ./net/sunrpc/svc.c  2007-01-29 10:06:49.0 +1100
@@ -26,7 +26,6 @@
 #include 
 
 #define RPCDBG_FACILITYRPCDBG_SVCDSP
-#define RPC_PARANOIA 1
 
 /*
  * Mode for mapping cpus to pools.
@@ -872,15 +871,15 @@ svc_process(struct svc_rqst *rqstp)
return 0;
 
 err_short_len:
-#ifdef RPC_PARANOIA
-   printk("svc: short len %Zd, dropping request\n", argv->iov_len);
-#endif
+   if (net_ratelimit())
+   printk("svc: short len %Zd, dropping request\n", argv->iov_len);
+
goto dropit;/* drop request */
 
 err_bad_dir:
-#ifdef RPC_PARANOIA
-   printk("svc: bad direction %d, dropping request\n", dir);
-#endif
+   if (net_ratelimit())
+   printk("svc: bad direction %d, dropping request\n", dir);
+
serv->sv_stats->rpcbadfmt++;
goto dropit;/* drop request */
 
@@ -909,10 +908,10 @@ err_bad_prog:
goto sendit;
 
 err_bad_vers:
-#ifdef RPC_PARANOIA
-   printk("svc: unknown version (%d for prog %d, %s)\n",
-  vers, prog, progp->pg_name);
-#endif
+   if (net_ratelimit())
+   printk("svc: unknown version (%d for prog %d, %s)\n",
+  vers, prog, progp->pg_name);
+
serv->sv_stats->rpcbadfmt++;
svc_putnl(resv, RPC_PROG_MISMATCH);
svc_putnl(resv, progp->pg_lovers);
@@ -920,17 +919,17 @@ err_bad_vers:
goto sendit;
 
 err_bad_proc:
-#ifdef RPC_PARANOIA
-   printk("svc: unknown procedure (%d)\n", proc);
-#endif
+   if (net_ratelimit())
+   printk("svc: unknown procedure (%d)\n", proc);
+
serv->sv_stats->rpcbadfmt++;
svc_putnl(resv, RPC_PROC_UNAVAIL);
goto sendit;
 
 err_garbage:
-#ifdef RPC_PARANOIA
-  

Re: [2.6 patch] NF_CONNTRACK_H323 must depend on (IPV6 || IPV6=n)

[Adrian Bunk]

On Sun, Jan 28, 2007 at 03:53:48PM -0800, David Miller wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
> Date: Sun, 28 Jan 2007 23:21:37 +0100
> 
> > On Sun, Jan 28, 2007 at 11:41:48AM -0800, Randy Dunlap wrote:
> > >...
> > > net/built-in.o: In function `q931_help':
> > > nf_conntrack_h323_main.c:(.text.q931_help+0x6ad): undefined reference to 
> > > `ip6_route_output'
> > > nf_conntrack_h323_main.c:(.text.q931_help+0x6c3): undefined reference to 
> > > `ip6_route_output'
> > >...
> > 
> > You didn't send your .config, but it seems you had CONFIG_IPV6=m and
> > CONFIG_NF_CONNTRACK_H323=y.
> > 
> > In this case, the untested patch below should fix it.
> > 
> > > ~Randy
> > 
> > cu
> > Adrian
> > 
> > 
> > <--  snip  -->
> > 
> > 
> > CONFIG_IPV6=m, CONFIG_NF_CONNTRACK_H323=y results in a compile error.
> > 
> > Fix this by letting NF_CONNTRACK_H323 depend on (IPV6 || IPV6=n).
> > 
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> Adrian is this the correct way to constrain the selection between
> "n" and "m" in this kind of situation?  I thought doing something
> like "depends on IPV6" is sufficient to achieve that?

"depends on IPV6" would fix the bug - but it would also make 
NF_CONNTRACK_H323 unavailable for all people without IPV6 support in 
their kernel.

cu
Adrian

-- 

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

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

Re: [2.6 patch] NF_CONNTRACK_H323 must depend on (IPV6 || IPV6=n)

[David Miller]

From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sun, 28 Jan 2007 23:21:37 +0100

> On Sun, Jan 28, 2007 at 11:41:48AM -0800, Randy Dunlap wrote:
> >...
> > net/built-in.o: In function `q931_help':
> > nf_conntrack_h323_main.c:(.text.q931_help+0x6ad): undefined reference to 
> > `ip6_route_output'
> > nf_conntrack_h323_main.c:(.text.q931_help+0x6c3): undefined reference to 
> > `ip6_route_output'
> >...
> 
> You didn't send your .config, but it seems you had CONFIG_IPV6=m and
> CONFIG_NF_CONNTRACK_H323=y.
> 
> In this case, the untested patch below should fix it.
> 
> > ~Randy
> 
> cu
> Adrian
> 
> 
> <--  snip  -->
> 
> 
> CONFIG_IPV6=m, CONFIG_NF_CONNTRACK_H323=y results in a compile error.
> 
> Fix this by letting NF_CONNTRACK_H323 depend on (IPV6 || IPV6=n).
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

Adrian is this the correct way to constrain the selection between
"n" and "m" in this kind of situation?  I thought doing something
like "depends on IPV6" is sufficient to achieve 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/

[patch] use __u64 rather than u64 in parisc statfs structs

[Mike Frysinger]

the statfs header exports some structs to userspace ... the parisc statfs64 
struct currently uses u64 so the trivial attached patch fixes it to use __u64
-mike


pgpooYiKlYGyj.pgp
Description: PGP signature
Use __u64 rather than u64 in the struct statfs64 exported to userspace.

Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>

--- a/include/asm-parisc/statfs.h
+++ b/include/asm-parisc/statfs.h
@@ -30,11 +30,11 @@ struct statfs {
 struct statfs64 {
 	long f_type;
 	long f_bsize;
-	u64 f_blocks;
-	u64 f_bfree;
-	u64 f_bavail;
-	u64 f_files;
-	u64 f_ffree;
+	__u64 f_blocks;
+	__u64 f_bfree;
+	__u64 f_bavail;
+	__u64 f_files;
+	__u64 f_ffree;
 	__kernel_fsid_t f_fsid;
 	long f_namelen;
 	long f_frsize;

Re: [PATCH 0/6] MSI portability cleanups

[David Miller]

From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 14:20:12 -0700

> I see people pushing ridiculous interfaces like the RTAS hypervisor
> interface at me, and saying we must support running firmware drivers
> in the msi code.

This is not what's going on.

The hypervisor does the PCI config space programming on the
device to setup the MSI so that it can be done in a controlled
manner and such that the device cannot ever be configured by
one domain to shoot MSI packets over at devices which belong
to another domain.

It's that simple.

That's absolutely reasonable, and is I believe what you'll see the
sparc64 hypervisor(s) all needing as well.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/6] MSI portability cleanups

[David Miller]

From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun, 28 Jan 2007 15:47:24 -0500

> I think the high-level ops approach makes more sense.  It's more future 
> proof, in addition to covering all existing implementations.

I totally agree with 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: 2.6.20-rc6-mm1

[Andrew Morton]

On Sun, 28 Jan 2007 15:23:43 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:

> Andrew Morton wrote:
> > On Sun, 28 Jan 2007 08:56:08 -0800
> > "Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
> > 
> >>> - It seems that people have been busy creating the need for this.  I had 
> >>> to
> >>>   apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 
> >>> compilation
> >>>   errors.  And a number of patches were dropped due to no-compile or to
> >>>   runtime errors.  Heaven knows how many runtime bugs were added.
> >> dbench seems to panic on xfs / cfq ?
> > 
> > OK, I'll dump git-block.patch.  That means that the fsaio patches get
> > temporarily dropped as well as they depend on git-block changes somewhat.
> 
> 
> OK ... if you can dump something in hotfixes, it should hopefully
> auto-trigger another run. But OTOH, xfs on dbench seemed to do it
> reliably on a bunch of machines, so maybe it's easy to reproduce.
> 

I think I'll go for a quick rc6-mm2.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/6] MSI portability cleanups

[David Miller]

From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 28 Jan 2007 16:26:44 -0700

> Yes.  In general the mainline linux kernel does not support certain
> classes of stupidity.  TCP offload engines, firmware drivers for
> hardware we care about, a fixed ABI to binary only modules, etc.
> It is the responsibility of the OS to setup MSI so we do it, not
> the firmware so we do it.

I absolutely disagree with you Eric, and I think you're being
rediculious.

If the hypervisor doesn't control the MSI PCI config space
register writes, this allows the device to spam PCI devices
which belong to other domains.

It's a freakin' reasonable design trade off decision, get over
it! :-)

Yes it can be done at the hardware level, and many hypervisor
based systems do that, but it's not the one-and-only true
way to implment inter-domain protection behind a single
PCI host controller.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

[Andrew Morton]

On Sun, 28 Jan 2007 14:47:56 -0800
"Paul E. McKenney" <[EMAIL PROTECTED]> wrote:

> > If we use the process freezer, these bugs all get automatically fixed,
> > and we get to remove the existing locking, and we don't need to think
> > about it any more.
> 
> The idea being to essentially suspend the system to RAM, remove the
> CPU and then unsuspend it?  Seems like quite high overhead -- or am
> I misunderstanding the proposal?

The process freezer basically wakes up all threads in the machine and makes
them go to sleep in a specific place, so they're all in a known state. 
kernel threads are also captured, via their open-coded polling call to
try_to_freeze().

The machine suspend code uses the process freezer, as does kprobes.  The
freezer isn't tied to suspend or to power management.

The freezer does have potential to be expensive if used frequently and if
there are many threads.  But I don't think anyone has looked at optimising
it.  For example, there are certain places in the kernel where threads
commonly sleep (eg, select()).  We know that this is a safe place to sleep
wrt (at least) CPU hotplug, so there's not really a need to wake those
processes up.  Perhaps something could be done with that observation...

But first we'd need to demonstrate that we actually have a problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/6] MSI portability cleanups

[Eric W. Biederman]

Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:

>  .../... (enable/disable bits)
>
>> Which are either talking directly to the hardware, or are talking
>> to the hypervisor, which is using hardware isolation so it is safe to
>> talk directly to the hardware but isn't leting us?  If we could use
>> things to work around errata in card implementation details it would
>> make some sense to me (although we don't seem to have any cards with
>> that got the MSI registers wrong at this point).  Regardless these
>> operations clearly have a different granularity than the other
>> operations, and should have a different lookup method.
>
> I'm not sure I undersdand the point of your rant here. The hypervisor
> case hooks at alloc/free and does everything from there. It doens't use
> an enable or a diable hook.
>
> The enable/disable ops are optional for that reason. When not present,
> it's assumed that alloc/free do it all.

Well my feeling is that in your weird HV case enable/disable should do
all of the work.  And alloc/free won't have to do anything because the
bus doesn't matter any more.

> When using a "direct" approach (what we call "raw"), we expect backends
> to just plug the provided helper functions in enable/disable. It's still
> a hook so that one can do additional platform specific bits if
> necessary, but in that specific case, I do agree we could just remove it
> and move the "raw" code back into the toplevel functions, with a way
> (via a special return code from alloc maybe ?) for the HV case to tell
> us not to go through there. That was one of our initial approaches when
> working with Michael on the design.
>
> However, that sort of hurts my sense of aestetics :-) I quite like the
> toplevel to be just a toplevel, and clearly separate the raw "helpers"
> and the backend. Provides more flexibility to handle all possible crazy
> cases in the future.

To be clear I see this as 2 distinct layers of code. enable/disable
that talks directly to the hardware, and the helpers of enable/disable
that allocate the irq.  I base this on the fact that I only need the
alloc/free when I am exclusively working with real hardware.

> You seem to absolutely want to get the HV case to go throuh the same
> code path as the "raw" case, and that will not happen.

Yes I do.  Because that is the only sane approach for a HV to use.
And yes we need an irq allocator to call the HV to setup the upstream
reception of the msi message.

However I don't think it will be to hard to support your HV once we get
the real hardware supported.  I just refuse to consider it before we have
figured out what makes sense in the context where we have to do everything.


>   .../... (irq operations)
>
>> These because they are per irq make sense as per bus operations unless
>> you have a good architecture definition like x86 has.  Roughly those
>> operations are what we currently have except the current operations
>> are a little simpler and easier to deal with for the architecture
>> code.
>
> Oh ? How so ? (easier/simpler ?)

I don't take a type parameter, and I don't take a vector.  All of
that work is done in the generic code.

>> And then there are the operations that are going in the wrong
>> direction.
>> +/* setup_msi_msg - Setup an MSI message for the given device.
>> + *
>> + * @pdev:   PCI device structure.
>> + * @entry:  The MSI entry to create a msi_msg for.
>> + * @msg:Written with the magic address and data.
>> + * @type:   The type, MSI or MSI-X.
>> + *
>> + * Returns the "magic address and data" used to trigger the msi.
>> + * If the setup is succesful this routine must return 0.
>> + *
>> + * This callback is optional.
>> + */
>> +int (*setup_msi_msg) (struct pci_dev *pdev, struct msix_entry *entry,
>> +struct msi_msg *msg, int type);
>> 
>> Much to much of the operations base approach as proposed looks like
>> when you have a hammer every problem looks like a nail, given how much
>> confusion about what was put into the operations structure.
>
> This is indeed a lower level hook to be used by "raw" enable/disable. An
> other approach would be to remove it, have each backend have it's own
> enable/disable that obtains the address/data and calls into a helper to
> program them. This would indeed be a little bit nicer in a layering
> perspective. But it adds a bit more code to each backend, so we kept
> things closer to the way they used to be. I don't have a firm reason not
> to change it however, I need talk to Michael in case he has more good
> reasons to keep it that way around. 

The current code in the kernel already is structured that way because
we have to reprogram the msi message on each irq migration.  Not using
a helper to write the message would be a noticeable change and require
a fair amount of code rewriting on the currently supported
architectures.

>> I don't mind taking a small step and making the 

Re: 2.6.20-rc6-mm1

[Martin J. Bligh]

Andrew Morton wrote:

On Sun, 28 Jan 2007 08:56:08 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:


- It seems that people have been busy creating the need for this.  I had to
  apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation
  errors.  And a number of patches were dropped due to no-compile or to
  runtime errors.  Heaven knows how many runtime bugs were added.

dbench seems to panic on xfs / cfq ?


OK, I'll dump git-block.patch.  That means that the fsaio patches get
temporarily dropped as well as they depend on git-block changes somewhat.



OK ... if you can dump something in hotfixes, it should hopefully
auto-trigger another run. But OTOH, xfs on dbench seemed to do it
reliably on a bunch of machines, so maybe it's easy to reproduce.

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: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

[Paul E. McKenney]

On Fri, Jan 26, 2007 at 01:29:49PM -0800, Andrew Morton wrote:
> On Sat, 27 Jan 2007 02:14:06 +0530
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> 
> > On Fri, Jan 26, 2007 at 12:17:39PM -0800, Andrew Morton wrote:
> > > On Sat, 27 Jan 2007 01:16:22 +0530
> > > Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> > > > > The plan is, I hope, to rip it all out and do freeze_processes() on 
> > > > > the
> > > > > hotplug side, so nobody else needs to worry about cpu hotplug any 
> > > > > more. 
> > > > > But at present everyone seems to be in hiding.
> > > > 
> > > > This would be ideal. However, we don't seem to have any momentum
> > > > on this.
> > > 
> > > There's no point in expending effort on a fancy new lock until this option
> > > has been eliminated, so yeah, things are stuck.
> > 
> > The new lock (scalable refcount) is almost already there. 
> > This http://lkml.org/lkml/2006/10/26/65 can be used to implement
> > get_cpu_hotplug()/put_cpu_hotplug(). The unfairness issue
> > can be fixed. I am going to play with these patches and
> > see if I can come up with something useful quickly.
> 
> You're forgetting the large, unknown number of places in the kernel which
> are presently buggy in the presence of CPU hotplug.  With your proposal, we
> still need to hunt them all down and put magic locks around them, and we need 
> to
> continue to do that as the kernel evolves.

Certainly the current practice of notifying CPU_UP_PREPARE and CPU_ONLINE
in the same order as CPU_DOWN_PREPARE and CPU_DEAD is just asking for lots
of bugs.  The "up" notifications should proceed in the same order as the
services were initialized at boot time, and the "down" notifications need
to proceed in the opposite order.

As things stand, if service B relies on service A, either service B must
go without during the CPU-removal process or services A and B must know
way too much about one another.  Either approach is an excellent way
to breed endless quantities of bugs.  If "down" notifications instead
proceeded in the opposite order from boot-time initialization, such
dependencies would be resolved automatically, and life is -much- simpler.

So why are we doing hard things the hard way here???  ;-)

> If we use the process freezer, these bugs all get automatically fixed,
> and we get to remove the existing locking, and we don't need to think
> about it any more.

The idea being to essentially suspend the system to RAM, remove the
CPU and then unsuspend it?  Seems like quite high overhead -- or am
I misunderstanding the proposal?

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

Re: Boot problems with pata_via driver

[Adrian Bunk]

On Sun, Jan 28, 2007 at 12:47:18PM +0100, Patrick Ale wrote:

> Hi,

Hi Patrick,

> With kernel 2.6.19 I was able to boot using the pata_via driver
> I tried to compile 2.6.20-rc6 and now I get a "unknown device: sda3"
> error when I try to boot.
> 
> I compiled 2.6.20-rc6 by copying over the .config from the 2.6.19 tree
> and running a make oldconfig && make
> 
> Am I doing something wrong?

Both kernels are self-compiled or is 2.6.19 a distribution kernel?

It could be that 2.6.20-rc6 has a bug and therefore no longer is able to 
use your controller.
It's also possible that the enumeration changed (e.g. sda is now an 
external hard disk).

During boot, there should be some messages prefixed with ata: and sda: 
describing what your kernel found and how it enumerated them.
What do they print with 2.6.20-rc6?

> Patrick

cu
Adrian

-- 

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

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

Re: 2.6.20-rc6-mm1

[Andrew Morton]

On Sun, 28 Jan 2007 23:31:00 +0100
Michal Piotrowski <[EMAIL PROTECTED]> wrote:

> Jan 28 22:58:29 euridica kernel: BUG: using smp_processor_id() in preemptible 
> [0001] code: yum-updatesd/2846
> Jan 28 22:58:29 euridica kernel: caller is nf_conntrack_in+0x363/0x47f 
> [nf_conntrack]

I'll plug that with this:


diff -puN include/net/netfilter/nf_conntrack.h~netfilter-warning-fix 
include/net/netfilter/nf_conntrack.h
--- a/include/net/netfilter/nf_conntrack.h~netfilter-warning-fix
+++ a/include/net/netfilter/nf_conntrack.h
@@ -254,7 +254,12 @@ extern atomic_t nf_conntrack_count;
 extern int nf_conntrack_max;
 
 DECLARE_PER_CPU(struct ip_conntrack_stat, nf_conntrack_stat);
-#define NF_CT_STAT_INC(count) (__get_cpu_var(nf_conntrack_stat).count++)
+#define NF_CT_STAT_INC(count)  \
+   do {\
+   preempt_disable();  \
+   __get_cpu_var(nf_conntrack_stat).count++;   \
+   preempt_enable();   \
+   } while (0);
 
 /* no helper, no nat */
 #defineNF_CT_F_BASIC   0
_

and will let others worry about what the real fix (for 2.6.20, please) is.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PROBLEM: Crash on device_shutdown

[Julien RF]

One line summary of the problem:
Crash on device_shutdown


Full description of the problem/report:
When I shut down the system, I get a crash on the device_shutdown function 
(called by kernel_shutdown_prepare).
Since the bug happens when the system is almost shutted down, I can't get the 
log...
I partially copied it by hand, ask me if you need further details :
Will now halt.
BUG: unable to handle kernel NULL pointer dereference at virtual adress 
0128
...
EIP is at device_shutdown + 0x49/0x6c
...
Process halt
...
/etc/rc0.d/S90halt: line 21: 11198 Segmentation fault halt -d -f $shutdown 
$poweroff $hddown

Julien Richard-Foy


Keywords (i.e., modules, networking, kernel):
base, power


Kernel version (from /proc/version):
Linux version 2.6.19.2 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 
(prerelease) 
(Debian 4.1.1-21)) #1 SMP Sun Jan 28 18:49:29 CET 2007


Software :
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux sasume 2.6.19.2 #1 SMP Sun Jan 28 18:49:29 CET 2007 i686 GNU/Linux
 
Gnu C  4.1.2
Gnu make   3.81
binutils   2.17
util-linux 2.12r
mount  2.12r
module-init-tools  3.3-pre2
e2fsprogs  1.40-WIP
reiserfsprogs  3.6.19
Linux C Library2.3.6
Dynamic linker (ldd)   2.3.6
Procps 3.2.7
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.97
udev   103
Modules Loaded n_hdlc ppdev lp ipv6 ntfs nls_iso8859_1 nls_cp437 vfat 
fat dm_snapshot dm_mirror dm_mod apm ide_generic tsdev mousedev snd_ens1370 
gameport floppy snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss rtc 
8250_pnp pcilynx psmouse serio_raw i2c_viapro snd_pcm snd_timer 
snd_ak4531_codec pcspkr snd soundcore snd_page_alloc via686a shpchp 
pci_hotplug ieee1394 i2c_algo_bit i2c_isa i2c_core parport_pc parport via_agp 
agpgart evdev reiserfs ide_cd cdrom ide_disk generic 3c59x mii via82cxxx 
ide_core uhci_hcd usbcore processor


Processor information (from /proc/cpuinfo):
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 6
model name  : AMD Athlon(tm) XP 1800+
stepping: 2
cpu MHz : 1461.000
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow up ts
bogomips: 2924.64


Module information (from /proc/modules):
n_hdlc 9476 0 - Live 0xd0f3b000
ppdev 9092 0 - Live 0xd0f02000
lp 11364 0 - Live 0xd0efe000
ipv6 227872 19 - Live 0xd0f7f000
ntfs 203220 1 - Live 0xd0f08000
nls_iso8859_1 4544 3 - Live 0xd0dfa000
nls_cp437 6208 2 - Live 0xd0d94000
vfat 12608 2 - Live 0xd0eaf000
fat 49052 1 vfat, Live 0xd0ebf000
dm_snapshot 16996 0 - Live 0xd0df4000
dm_mirror 20624 0 - Live 0xd0ded000
dm_mod 52568 2 dm_snapshot,dm_mirror, Live 0xd0dfe000
apm 20640 1 - Live 0xd0de6000
ide_generic 1728 0 [permanent], Live 0xd0d17000
tsdev 7872 0 - Live 0xd0d8a000
mousedev 11236 1 - Live 0xd0d34000
snd_ens1370 19296 0 - Live 0xd0d67000
gameport 15048 1 snd_ens1370, Live 0xd0d6d000
floppy 54564 0 - Live 0xd0d99000
snd_rawmidi 23136 1 snd_ens1370, Live 0xd0d7f000
snd_seq_device 8076 1 snd_rawmidi, Live 0xd0d38000
snd_pcm_oss 39520 0 - Live 0xd0d74000
snd_mixer_oss 15872 1 snd_pcm_oss, Live 0xd0d62000
rtc 12788 0 - Live 0xd0d5d000
8250_pnp 9600 0 - Live 0xd0d59000
pcilynx 18824 0 - Live 0xd0cda000
psmouse 35144 0 - Live 0xd0d3c000
serio_raw 7044 0 - Live 0xd0d14000
i2c_viapro 8724 0 - Live 0xd0d1
snd_pcm 71940 2 snd_ens1370,snd_pcm_oss, Live 0xd0d46000
snd_timer 21124 1 snd_pcm, Live 0xd0d29000
snd_ak4531_codec 9088 1 snd_ens1370, Live 0xd0d0c000
pcspkr 3456 0 - Live 0xd0837000
snd 48932 8 
snd_ens1370,snd_rawmidi,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_ak4531_codec,
 
Live 0xd0d1c000
soundcore 8032 1 snd, Live 0xd0d09000
snd_page_alloc 10056 2 snd_ens1370,snd_pcm, Live 0xd0d05000
via686a 15432 0 - Live 0xd0d0
shpchp 35040 0 - Live 0xd0ccd000
pci_hotplug 30080 1 shpchp, Live 0xd0cf7000
ieee1394 88568 1 pcilynx, Live 0xd0ce
i2c_algo_bit 8072 1 pcilynx, Live 0xd0bcc000
i2c_isa 5696 1 via686a, Live 0xd0bc9000
i2c_core 21056 5 pcilynx,i2c_viapro,via686a,i2c_algo_bit,i2c_isa, Live 
0xd0bb5000
parport_pc 33124 1 - Live 0xd0cbb000
parport 34056 3 ppdev,lp,parport_pc, Live 0xd0cb1000
via_agp 10048 1 - Live 0xd0bb1000
agpgart 30600 1 via_agp, Live 0xd0bbc000
evdev 9728 0 - Live 0xd0bad000
reiserfs 219904 2 - Live 0xd0bd4000
ide_cd 37088 0 - Live 0xd0b81000
cdrom 33760 1 ide_cd, Live 0xd0b8c000
ide_disk 15872 8 - Live 0xd083
generic 5828 0 [permanent], Live 0xd0814000
3c59x 41576 0 - Live 0xd0839000
mii 5760 1 3c59x, Live 0xd0827000

Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[Benjamin Herrenschmidt]

> We could have done it for interrupts too. A "struct irqnum" that has a bit 
> that specifies "valid". That would work. But it tends to be painful, so it 
> really has to give you something more than "zero is disabled".
> 
> It's just not worth it.
> 
> And it's why I decreed, that the ONLY SANE THING is to just let people do 
> the obvious thing:
> 
>   if (!dev->irq)
>   return -ENODEV;
> 
> you don't have to know ANYTHING, and that code just works, and just looks 
> obvious. And you know what? If it causes a bit of pain for some platform 
> maintainer, I don't care one whit. Because it's obviously much better than 
> the alternatives.

I'd rather have dev->irq be a struct interrupt * :-) The NULL check
would then make more sense and we completely remove "numbers" from
drivers, they have to obtain their struct interrupt via some interrupt
mapping code

Ben.

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

Re: swap: which is the maximum size allowed?

[Eriberto]

Ok. But, mkswap man is old (1999). However, from Linux Partition HOWTO:

"footnote: "official" max swap size: With kernel 2.4, the limit is 64
swap spaces at a maximum of 64Gb each, although this is not reflected in
the man page for mkswap. With the 64 bit opteron on the 2.6 kernel, 128
swap areas are permitted, each a whopping 16 Tb! (thanks to Peter Chubb
for the calculation)"

I want to know: why 64 GB???

Thanks,

Eriberto - www.eriberto.pro.br

Bodo Eggert escreveu:
> Look into the manpage of mkswap. It's 2 G x 32 swap partitions,
> minus a tiny overhead.

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

Re: 2.6.20-rc6-mm1

[Andrew Morton]

On Sun, 28 Jan 2007 08:56:08 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:

> > - It seems that people have been busy creating the need for this.  I had to
> >   apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 
> > compilation
> >   errors.  And a number of patches were dropped due to no-compile or to
> >   runtime errors.  Heaven knows how many runtime bugs were added.
> 
> dbench seems to panic on xfs / cfq ?

OK, I'll dump git-block.patch.  That means that the fsaio patches get
temporarily dropped as well as they depend on git-block changes somewhat.

btw, I didn't actually include the list-aio patches in rc6-mm1 due to
various discouraging-looking review comments - I'll be awaiting version 2
there.

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

Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[Benjamin Herrenschmidt]

> However, in all honesty, we have triggered bugs in that area too, simply 
> because some driver code "knew" that PIO addresses could fit in 16 bits, 
> and used u16 or "unsigned short" to remember the PIO address. Both ARM and 
> Sparc was bitten by this, although usually the issue is trivial to fix 
> once found.
> 
> Also, many ISA-only drivers actually have hardcoded PIO numbers (eg 
> "0x1f0").
> 
> But yes, I would generally suggest that architectures where the PIO range 
> is really just another magic MMIO range (which is most of the non-x86 
> world, as you point out) might as well at least aim for doing the 
> remapping early (ie with "pci_resource_start()")
> 
> Making that easy was one of my goals for the "new" IO accessor functions, 
> in fact.
> 
> Not that many people actually use them.

Well, as I said, I prefer keeping PIO numbers 0 based so that legacy
crap works. If 0 is to be illegal, then remap any devive that's sitting
there, but don't do weirder remapping tricks than necessary ;-) 

Note that on PowerPC, we do actually remap PIO on non-primary busses
(well, we have to since we have to present a flat space to inx/outx).

What we do there is basically we "pick" a bus as beeing primary
(typically the one that has an ISA bridge and/or SuperIO on it) and
that's the one that gets PIO 0. Resources for device on that domain
aren't fixed up.

All other ones are fixed up in such a way that pointer arithmeric gives
you an inx/outx landing in the right spot for PCI devices.

> So *if* you use the new "iomap" interfaces, and the new "pci_iomap()" 
> things, that should actually not just allow drivers (like the ATA layer) 
> to share much more code between the PIO and MMIO cases, but it hopefully 
> actually makes it easier for strange architectures to do it all.

Yes. Though adoption of iomap is a bit slow on the driver side of
things.

> So traditionally, we've had PIO be "limited integer addresses, and some 
> drivers know magic numbers", but hopefully new drivers could at least try 
> to use some of the infrastructure where we try to help people not have to 
> deal with it so much as a special case any more.

Well, hopefully new drivers don't need PIO as it's about time people
stop releasing devices that do PIO, bloody hell ! That should have been
"deprecated use for compatibility only" from day #1 :-) In fact, if I'm
not mistaken, the PCI spec mandates that device should have an MMIO way
of doing everything that can be done via PIO nowadays no ?

Ben.


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

Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[Benjamin Herrenschmidt]

> On sparc64, for example, after I pointed this out to DaveM, he was able 
> to implement the new iomap interface without the 'if (pio-mem-area)' 
> branch present on x86.

Yup, we did that from day 1 on powerpc :-) However, I don't totally
agree with adding some other remapping layer here, I think if we want
PIO 0 to be illegal, then make it illegal at the HW level too.

The reason is in fact the same as Linus invoked for remapping it in the
first place -> make things look like an x86 :-)

That is, quite a few non-x86 machines do have some kind of superIO chip
or other set of legacy devices around. They also commonly have VGA cards
hard decoding VGA PIO addresses.

So here's a very simplified version on how most non-x86 platforms do
PIO :

at boot:

 pci_io_base = ioremap(MAGIC_PIO_REGION);

and then

 #define inb(port)  (readb(pci_io_base + (port)))

The nice thing with that approach is that all those legacy x86 drivers
for bits in your SuperIO chip or for VGA do actually still work when they
do

 inb(STUPID_HARD_CODED_IO_PORT);

While if we now add some magic remapping to make 0 illegal, that will break
and all those legacy drivers would have to be fixed, which nobody wants
to do.

So I do stand firm there. I don't necessarily mind deciding that 0 is an
illegal PIO address, but if we're going to do that, we should make it
illegal as a HW PIO address, not by adding a remapping trick to something
that really doesn't want more than it already has :-)

Ben.


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

Re: [SCRIPT] Remove "space damage" from patches

[Oleg Verych]

> From: Richard Knutsson
> Newsgroups: gmane.linux.kernel
> Subject: [SCRIPT] Remove "space damage" from patches
> Date: Sun, 28 Jan 2007 22:37:01 +0100

> Hello Andrew and all

Hallo.

> I recently tried "git-apply" on the 2.6.20-rc6-mm1 patch and found it to 
> complain about white-spaces.
> So as a mean to (hopefully) cut down on these nasty white-spaces (and 
> sometimes tabs) I wrote this
> little script. All it does is checking (lines that are going to be added) for 
> spaces before tabs
> and trailing spaces/tabs. I tried it on 2.6.20-rc6-mm1 and it seem to work 
> well
>
> If there is someone interested, _please_ take it. Any suggestion are welcomed 
> :)
>
> Richard Knutsson

Nack, big and fat. It's userspace problem.

If our "developers" can't use or update their every-day-tools, it's a
shame. And this is not trolling: i'm using Jed and GNU Emacs, both are
ok with whitespace "production". 



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

Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[Benjamin Herrenschmidt]

> Indeed. Zero means "not in use". It really is that simple. 

I tried to avoid stepping into that specific flamewar as I don't have
strong opinions either way, but I've been asked to so ... and there are
a few things in your statement that I do like to argue about a bit :-)

> And I'm sorry, David, but 99% of the world _is_ a PC, and that is where 
> PCI and ATA came from, so anybody who thinks that zero is a valid PCI 
> address is just sadly mistaken and has a bug. In fact, even on a hardware 
> level, a lot of devices will literally have "zero means disabled".
> 
> Broken architectures that put PCI things at some "PCI physical address 
> zero" need to map their PCI addresses to something else. It's part of why 
> we have the whole infrastructure for doing things like

As I said, I don't have a firm pro/con position in that matter, but I
notice that we had some firmwares putting things at IO port 0 for a
while now and it generally worked for what we did with it.

I do still think that there is some value to the argument that, for IO
ports (and I'm really talking about IO ports here, the HW one, not
what's in the struct resource which may or may not be the actual HW IO
port number depending on how the arch implements them) :

 - 0 is valid and works fine on some platforms with some devices
 - 0 seems to be in some rare cases the only valid/useable spot
   according to David and even pretty common in pcmcia land
 - some existing firmwares -are- allocating things at 0 and having
   to relocate things is a pain.

Thus, based on that, while I -do- agree that it's a bad idea to
purposefully put things at 0 if you can avoid it (looking for trouble...
I always tell FW folks to start assigning IO ports at 0x1000), I don't
think it's nice to say that it's ok for drivers to use it as a special
case and thus intentionally break some of the cases that would have
worked just fine.

>   pcibios_bus_to_resource()
>   pcibios_resource_to_bus()
> 
> etc - not just because a resource having zero in "start" means that it is 
> disabled, but because normally such broken setups have *other* problems 
> too (ie they don't have a 1:1 mapping between PCI addresses and physical 
> addresses _anyway_, so they need to address translations).

Yes well... remapping... there are several issues with that, see below.

> This has come up before. For example: for an IRQ, 0 means "does not 
> exist", it does _not_ mean "physical irq 0", and we test for whether a 
> device has a valid irq by doing "if (dev->irq)" rather than having some 
> insane archiecture-specific "IRQ_NONE". And if you validly really have an 
> irq at the hardware level that is zero, then that just means that the irq 
> numbers you should tell the kernel should be translated some way.
> 
> (On a PC, hardware irq 0 is a real irq too, but it's a _special_ irq, and 
> it is set up by architecture-specific code. So as far as the generic 
> kernel and all devices are concerned, "!dev->irq" means that the irq 
> doesn't exist or hasn't been mapped for that device yet).

While I didn't much like your decree forcing everybody to consider IRQ 0
as invalid (I think nor everybody adapted yet even, isn't ARM still
using -1 as NO_IRQ ? BTW... I do like having a constant even if it's
defined to 0 :-) ... I do admit that writing a remapping layer on
powerpc (in part because of that, in part to solve other issues) ended
up cleaning up a lot of cruft, especially in the area of multiple
cascaded controllers.

Once the remapping layer was there, HW numbers became totally irrelevant
to anything but the controller instance they sit on, and linux irqs
became dynamically allocated virtual numbers, thus allowing to do some
tricks like 0 is always invalid or 1...15 are never assigned to anybody
except legacy 8259 if any. A nice way to fool-proof against stupid
drivers. In the end, remapping of IRQs did improve more stuffs than it
added bloat so I think it was a winning situation. Now, the next step is
to completely get rid of linux irq numbers alltogether and use irq_desc
* :-)

However, for IOs, things are a bit more annoying in several areas.
First, if you remap, do you remap at the HW level or the linux resource
content ? (And I'm talking about both PIO and MMIO here).

Because if we just do a linux remapping layer, we basically:

 - Don't solve any problem where HW actually doesn't like 0

 - Add a possibly complicated remapping layer on top of something that
doesn't necessarily need one.

Besides, there's already enough convoluted issues in the way archs remap
or don't remap PCI resources to not want to start playing more games in
that area (and possibly break X while at it, heh, I know it needs to be
fixed and Ian is working on it, but still).

Thus, if for some reason, IO resource 0 or memory resource 0 are
unacceptable, then they should probably be remapped by the arch code in
HW (moving the devices elsewhere), _NOT_ as a virtual remapping thing in
linux.

> So there are 

Re: swap: which is the maximum size allowed?

[Bodo Eggert]

Eriberto <[EMAIL PROTECTED]> wrote:

> I am trying understand the swap. I would like to know which is the
> maximum swap size on i386. Is 64 MB? If yes, how to know the origin of
> this "magic" number? I don't found it (Internet).

Look into the manpage of mkswap. It's 2 G x 32 swap partitions,
minus a tiny overhead.
-- 
"Whoever said the pen is mightier than the sword obviously never
encountered automatic weapons."
-Gen. Douglas MacArthur
Friß, Spammer: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: git.kernel.org move (finally)... estimated week of Feb 5

[Oleg Verych]

> From: "Parag Warudkar"
> Newsgroups: gmane.linux.kernel
> Subject: Re: git.kernel.org move (finally)... estimated week of Feb 5
> Date: Sun, 28 Jan 2007 11:51:34 -0500
[]
> Actually that's a good idea - why don't we put up a
> donation-for-hardware appeal on kernel.org and may be someplace more
> visible to raise around 8K USD for a 2x2 AMD64 machine with say 8Gig
> of RAM? May be the disks etc. stuff can be shared/re-used off the
> DL380 G2?
>
> The KDE guys did something like that a little while ago. I pledge my
> USD 100 upfront and I don't think we should have trouble getting 80
> people donating USD 100 each.

And Mozilla Org. (Corp.) did bad joke with this.
I mean in terms of open source, Debian in particular (there's no fox
there any more).

> 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: 2.6.20-rc6-mm1: linker error with arch_setup_additional_pages

[Parag Warudkar]

On 1/28/07, Parag Warudkar <[EMAIL PROTECTED]> wrote:

>CONFIG_BINFMT_ELF=y
># CONFIG_BINFMT_MISC is not set
># CONFIG_IA32_EMULATION is not set

Hm Ok. That's explainable. You don't have CONFIG_IA32_EMULATION set
and arch_setup_additional pages is only defined/exported in
syscall32.c which won't be built in your case. (It should go away if
you set CONFIG_IA32_EMULATION).



I think the easy and correct fix for this situation is defining
CONFIG_ARCH_HAS_SETUP_ADDITIONAL_PAGES on x86_64 only if
IA32_EMULATION is defined. (Because x86_64 proper doesn't seem to
require arch_setup_additional_pages() only IA32 emulation requires
it.)

The patch below should fix it. (Please use attachment - less chance of
whitespace issues. Sorry no control over mail client atm)

Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]>

--- linux-2.6.20-rc6-mm1/arch/x86_64/Kconfig.orig   2007-01-28
17:32:09.0 -0500
+++ linux-2.6.20-rc6-mm1/arch/x86_64/Kconfig2007-01-28 17:32:48.0 
-0500
@@ -405,7 +405,7 @@
config ARCH_HAS_SETUP_ADDITIONAL_PAGES
bool
default y
-   depends on X86_64
+   depends on X86_64 && IA32_EMULATION

config OUT_OF_LINE_PFN_TO_PAGE
def_bool y
--- linux-2.6.20-rc6-mm1/arch/x86_64/Kconfig.orig	2007-01-28 17:32:09.0 -0500
+++ linux-2.6.20-rc6-mm1/arch/x86_64/Kconfig	2007-01-28 17:32:48.0 -0500
@@ -405,7 +405,7 @@
 config ARCH_HAS_SETUP_ADDITIONAL_PAGES
 	bool
 	default y
-	depends on X86_64
+	depends on X86_64 && IA32_EMULATION
 
 config OUT_OF_LINE_PFN_TO_PAGE
 	def_bool y

Re: The mbox format archives of linux-kernel are gone.

[Oleg Verych]

> Path: news.gmane.org!not-for-mail
> From: Andrey Borzenkov <[EMAIL PROTECTED]>
> Newsgroups: gmane.linux.kernel
> Date: Sun, 28 Jan 2007 20:24:43 +0300

Hallo.

> Benny Amorsen wrote:
>
>>> "DK" == Dave Kleikamp <[EMAIL PROTECTED]> writes:
>> 
>> DK> On Sun, 2007-01-28 at 10:17 +0100, Benny Amorsen wrote:
  Perhaps nntp://news.gmane.org/gmane.linux.kernel can help, even if
 it isn't exactly what you asked for.
>> 
>> DK> I like to read the mailing list this way, but it's not a good
>> DK> method if you want to reply to an email. You're email was only
>> DK> sent to the list and not to the Dirk, who you were replying to.
>> 
>> True. There has been a few flame wars over whether it is good
>> netiquette to send both to the list and to the person though -- and
>> some newsreaders can be told to send courtesy copies by email.
>> 
>
> It is not newgroup, it is lkml where keeping Cc list is standard. Answering
> via gmane unfortunately completely trims Cc list, keeping at most sender
> and list but not recipients of message. May be other newsreaders behave
> better (using Knode)

Yes. LKML is a list, list with heavy load. For better tracking of
threads, MUA maybe better, sometimes.

Problem with Cc list isn't problem, actually:


("Reply-To" is forbidden by vger)

If this will be adopted by all Mail/News UAs, it will be OK.

As for my slrn, it lets me to edit whole message, i.e. incuding
headers, so until i will implement something in the sources, i can
copy "MAil-Followup-To" by hands ;D

If somebody will get lkml mbox archive, can you import it into gmane,
please.

> -andrey
>


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

PROBLEM: Crash on sysfs_follow_link

[Julien RF]

One line summary of the problem:
Crash on sysfs_follow_link


Full description of the problem/report:
When the hald deamon is started, it crashes on the sysfs_follow_link function.
Here's the log (from /var/log/kern.log) :
Jan 28 22:51:58 localhost kernel: BUG: unable to handle kernel NULL pointer 
dereference at virtual address 0148
Jan 28 22:51:58 localhost kernel:  printing eip:
Jan 28 22:51:58 localhost kernel: c0195866
Jan 28 22:51:58 localhost kernel: *pde = 
Jan 28 22:51:58 localhost kernel: Oops:  [#1]
Jan 28 22:51:58 localhost kernel: SMP 
Jan 28 22:51:58 localhost kernel: Modules linked in: ppdev lp ipv6 ntfs 
nls_iso8859_1 nls_cp437 vfat fat dm_snapshot dm_mirror dm_mod apm ide_generic 
tsdev mousedev snd_ens1370 gameport floppy snd_rawmidi snd_seq_device 
snd_pcm_oss snd_mixer_oss rtc 8250_pnp pcilynx psmouse serio_raw i2c_viapro 
snd_pcm snd_timer snd_ak4531_codec pcspkr snd soundcore snd_page_alloc 
via686a shpchp pci_hotplug ieee1394 i2c_algo_bit i2c_isa i2c_core parport_pc 
parport via_agp agpgart evdev reiserfs ide_cd cdrom ide_disk generic 3c59x 
mii via82cxxx ide_core uhci_hcd usbcore processor
Jan 28 22:51:58 localhost kernel: CPU:0
Jan 28 22:51:58 localhost kernel: EIP:0060:[]Not tainted VLI
Jan 28 22:51:58 localhost kernel: EFLAGS: 00010206   (2.6.19.2 #1)
Jan 28 22:51:58 localhost kernel: EIP is at sysfs_follow_link+0xc0/0x1a9
Jan 28 22:51:58 localhost kernel: eax: 0124   ebx: 0001   ecx: 
000c   edx: c02e38c0
Jan 28 22:51:58 localhost kernel: esi: cf22dcac   edi: c79a9324   ebp: 
cf5c4cbc   esp: ccdbfeb8
Jan 28 22:51:58 localhost kernel: ds: 007b   es: 007b   ss: 0068
Jan 28 22:51:58 localhost kernel: Process hald (pid: 4350, ti=ccdbe000 
task=cff57a70 task.ti=ccdbe000)
Jan 28 22:51:58 localhost kernel: Stack: ccdbfee0 c76be000 cf5c4da8 0001 
c02e6fe0 0100 c79a9324 080a04a0 
Jan 28 22:51:58 localhost kernel:c01643bd c0168947 ccdbff98 c016874c 
fff7 0809effc  cf2ac340 
Jan 28 22:51:58 localhost kernel:c01689f2  ff9c cb184618 
3766c227 45bd1afd c0123948 0001 
Jan 28 22:51:58 localhost kernel: Call Trace:
Jan 28 22:51:58 localhost kernel:  [] generic_readlink+0x27/0x6e
Jan 28 22:51:58 localhost kernel:  [] vfs_readdir+0x7d/0x8d
Jan 28 22:51:58 localhost kernel:  [] filldir64+0x0/0xc5
Jan 28 22:51:58 localhost kernel:  [] sys_getdents64+0x9b/0xa5
Jan 28 22:51:58 localhost kernel:  [] current_fs_time+0x4f/0x5b
Jan 28 22:51:58 localhost kernel:  [] touch_atime+0x60/0x8f
Jan 28 22:51:58 localhost kernel:  [] sys_readlinkat+0x83/0x9e
Jan 28 22:51:58 localhost kernel:  [] vfs_readdir+0x7d/0x8d
Jan 28 22:51:58 localhost kernel:  [] filldir64+0x0/0xc5
Jan 28 22:51:58 localhost kernel:  [] sys_getdents64+0x9b/0xa5
Jan 28 22:51:58 localhost kernel:  [] sys_readlink+0x27/0x2b
Jan 28 22:51:58 localhost kernel:  [] syscall_call+0x7/0xb
Jan 28 22:51:58 localhost kernel:  ===
Jan 28 22:51:58 localhost kernel: Code: 89 c5 c6 05 80 6b 32 c0 01 85 ed 75 0e 
8b 44 24 08 e8 48 b6 02 00 e9 c0 00 00 00 b8 40 6f 2e c0 31 db e8 42 d6 f9 ff 
8b 44 24 08 <8b> 40 24 43 85 c0 75 f8 89 ea be 01 00 00 00 8b 3a 31 c0 83 c9 
Jan 28 22:51:58 localhost kernel: EIP: [] 
sysfs_follow_link+0xc0/0x1a9 SS:ESP 0068:ccdbfeb8

I already sent a report here : http://bugs.debian.org/406478
Julien Richard-Foy


Keywords (i.e., modules, networking, kernel):
sysfs


Kernel version (from /proc/version):
Linux version 2.6.19.2 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 
(prerelease) 
(Debian 4.1.1-21)) #1 SMP Sun Jan 28 18:49:29 CET 2007


Software :
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux sasume 2.6.19.2 #1 SMP Sun Jan 28 18:49:29 CET 2007 i686 GNU/Linux
 
Gnu C  4.1.2
Gnu make   3.81
binutils   2.17
util-linux 2.12r
mount  2.12r
module-init-tools  3.3-pre2
e2fsprogs  1.40-WIP
reiserfsprogs  3.6.19
Linux C Library2.3.6
Dynamic linker (ldd)   2.3.6
Procps 3.2.7
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.97
udev   103
Modules Loaded n_hdlc ppdev lp ipv6 ntfs nls_iso8859_1 nls_cp437 vfat 
fat dm_snapshot dm_mirror dm_mod apm ide_generic tsdev mousedev snd_ens1370 
gameport floppy snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss rtc 
8250_pnp pcilynx psmouse serio_raw i2c_viapro snd_pcm snd_timer 
snd_ak4531_codec pcspkr snd soundcore snd_page_alloc via686a shpchp 
pci_hotplug ieee1394 i2c_algo_bit i2c_isa i2c_core parport_pc parport via_agp 
agpgart evdev reiserfs ide_cd cdrom ide_disk generic 3c59x mii via82cxxx 
ide_core uhci_hcd usbcore processor


Processor information (from /proc/cpuinfo):
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 6
model name  : AMD Athlon(tm) XP 1800+
stepping   

Re: AIC7xxx on 2.6.18

[Robert Hancock]

Wakko Warner wrote:

I have 2 machine that oops with these cards.

1) The bios has the option to enable/disable option roms on individual PCI
slots.  I have an AHA-39160 and an AHA-2940U/UW (dual channel).  If I
disable option roms, the driver oopses when accessing the 2nd card.

I can get the oops if really needed as I don't like rebooting this machine.

2) I have an AHA-39160 with Apple/Mac firmware.  When attempting to use it
on a PC, the driver oopses presumably because the card wasn't initialized or
something.  I realize this is probably not a supported configuration, but I
don't believe that it should be oopsing.

I can get the oops for this one if it'll help.



I'm guessing these are similar bugs - likely something in the driver 
goes bad if the option ROM didn't initialize the card, but I don't think 
it should be relying on this..


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

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

Re: 2.6.20-rc6-mm1

[Michal Piotrowski]

Andrew Morton napisał(a):
> Temporarily at
> 
>   http://userweb.kernel.org/~akpm/2.6.20-rc6-mm1/
> 
> will appear one day at
> 
>   
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm1/
> 
> 

Jan 28 22:58:29 euridica kernel: BUG: using smp_processor_id() in preemptible 
[0001] code: yum-updatesd/2846
Jan 28 22:58:29 euridica kernel: caller is nf_conntrack_in+0x363/0x47f 
[nf_conntrack]
Jan 28 22:58:29 euridica kernel:  [] show_trace_log_lvl+0x1a/0x2f
Jan 28 22:58:29 euridica kernel:  [] show_trace+0x12/0x14
Jan 28 22:58:29 euridica kernel:  [] dump_stack+0x16/0x18
Jan 28 22:58:29 euridica kernel:  [] debug_smp_processor_id+0xb3/0xc8
Jan 28 22:58:29 euridica kernel:  [] nf_conntrack_in+0x363/0x47f 
[nf_conntrack]
Jan 28 22:58:29 euridica kernel:  [] ipv4_conntrack_local+0x53/0x5b 
[nf_conntrack_ipv4]
Jan 28 22:58:29 euridica kernel:  [] nf_iterate+0x36/0x67
Jan 28 22:58:29 euridica kernel:  [] nf_hook_slow+0x52/0xbe
Jan 28 22:58:29 euridica kernel:  [] ip_queue_xmit+0x3d1/0x420
Jan 28 22:58:29 euridica kernel:  [] tcp_transmit_skb+0x78b/0x7ca
Jan 28 22:58:29 euridica kernel:  [] 
__tcp_push_pending_frames+0x732/0x811
Jan 28 22:58:29 euridica kernel:  [] tcp_send_fin+0x146/0x150
Jan 28 22:58:29 euridica kernel:  [] tcp_close+0x22b/0x556
Jan 28 22:58:29 euridica kernel:  [] inet_release+0x43/0x49
Jan 28 22:58:29 euridica kernel:  [] sock_release+0x17/0x9d
Jan 28 22:58:29 euridica kernel:  [] sock_close+0x2d/0x33
Jan 28 22:58:29 euridica kernel:  [] __fput+0xca/0x198
Jan 28 22:58:29 euridica kernel:  [] fput+0x32/0x36
Jan 28 22:58:29 euridica kernel:  [] filp_close+0x54/0x5c
Jan 28 22:58:29 euridica kernel:  [] put_files_struct+0x7d/0xba
Jan 28 22:58:29 euridica kernel:  [] do_exit+0x30d/0x8e6
Jan 28 22:58:29 euridica kernel:  [] sys_exit_group+0x0/0x11
Jan 28 22:58:29 euridica kernel:  [] get_signal_to_deliver+0x734/0x760
Jan 28 22:58:29 euridica kernel:  [] do_notify_resume+0x94/0x749
Jan 28 22:58:29 euridica kernel:  [] work_notifysig+0x13/0x1a
Jan 28 22:58:29 euridica kernel:  ===

http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc6-mm1/mm-config

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] mm: remove global locks from mm/highmem.c

[Andrew Morton]

On Sun, 28 Jan 2007 15:11:34 +0100
Peter Zijlstra <[EMAIL PROTECTED]> wrote:

> Eradicate global locks.
> 
>  - kmap_lock is removed by extensive use of atomic_t, a new flush
>scheme and modifying set_page_address to only allow NULL<->virt
>transitions.
> 
> A count of 0 is an exclusive state acting as an entry lock. This is done
> using inc_not_zero and cmpxchg. The restriction on changing the virtual
> address closes the gap with concurrent additions of the same entry.
> 
>  - pool_lock is removed by using the pkmap index for the
>page_address_maps.
> 
> By using the pkmap index for the hash entries it is no longer needed to
> keep a free list.
> 
> This patch has been in -rt for a while but should also help regular
> highmem machines with multiple cores/cpus.

I really don't recall any performance problems being reported out of that
code in recent years.

As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic().  Partly because kmap() is deadlockable in situations where a
large number of threads are trying to take two kmaps at the same time and
we run out.  This happened in the past, but incidences have gone away,
probably because of kmap->kmap_atomic conversions.

>From which callsite have you measured problems?

> Index: linux/include/linux/mm.h
> ===
> --- linux.orig/include/linux/mm.h
> +++ linux/include/linux/mm.h
> @@ -543,23 +543,39 @@ static __always_inline void *lowmem_page
>  #endif
>  
>  #if defined(WANT_PAGE_VIRTUAL)
> -#define page_address(page) ((page)->virtual)
> -#define set_page_address(page, address)  \
> - do {\
> - (page)->virtual = (address);\
> - } while(0)
> -#define page_address_init()  do { } while(0)
> +/*
> + * wrap page->virtual so it is safe to set/read locklessly
> + */
> +#define page_address(page) \
> + ({ typeof((page)->virtual) v = (page)->virtual; \
> +  smp_read_barrier_depends(); \
> +  v; })
> +
> +static inline int set_page_address(struct page *page, void *address)
> +{
> + if (address)
> + return cmpxchg(>virtual, NULL, address) == NULL;
> + else {
> + /*
> +  * cmpxchg is a bit abused because it is not guaranteed
> +  * safe wrt direct assignment on all platforms.
> +  */
> + void *virt = page->virtual;
> + return cmpxchg(>vitrual, virt, NULL) == virt;
> + }
> +}

Have you verified that all architectures which can implement
WANT_PAGE_VIRTUAL also implement cmpxchg?

Have you verified that sufficient headers are included for this to compile
correctly on all WANT_PAGE_VIRTUAL-enabling architectures on all configs? 
I don't see asm/system.h being included in mm.h and if I get yet another
damned it-wont-compile patch I might do something irreversible.

> +static int pkmap_get_free(void)
>  {
> - unsigned long vaddr;
> - int count;
> + int i, pos, flush;
> + DECLARE_WAITQUEUE(wait, current);
>  
> -start:
> - count = LAST_PKMAP;
> - /* Find an empty entry */
> - for (;;) {
> - last_pkmap_nr = (last_pkmap_nr + 1) & LAST_PKMAP_MASK;

The old code used masking.

> - if (!last_pkmap_nr) {
> - flush_all_zero_pkmaps();
> - count = LAST_PKMAP;
> - }
> - if (!pkmap_count[last_pkmap_nr])
> - break;  /* Found a usable entry */
> - if (--count)
> - continue;
> +restart:
> + for (i = 0; i < LAST_PKMAP; i++) {
> + pos = atomic_inc_return(_hand) % LAST_PKMAP;

The new code does more-expensive modulus.  Necessary?

> + flush = pkmap_try_free(pos);
> + if (flush >= 0)
> + goto got_one;
> + }
> +
> + /*
> +  * wait for somebody else to unmap their entries
> +  */
> + __set_current_state(TASK_UNINTERRUPTIBLE);
> + add_wait_queue(_map_wait, );
> + schedule();
> + remove_wait_queue(_map_wait, );

This looks wrong.  What happens if everyone else does their unmap between
the __set_current_state() and the add_wait_queue()?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] use __u32 rather than u32 in userspace ioctls in usbdevice_fs.h

[Mike Frysinger]

On Sunday 28 January 2007 12:42, Randy Dunlap wrote:
> Have you now audited all ioctls (and sent patches) for this misbehavior?

my audit involved grepping the headers for '\<[us](8|16|32|64)\>' and sending 
patches for the headers that came up

ive sent patches for all except for asm-parisc/statfs.h ... but i'll do that 
shortly once i finish pulling the parisc git tree
-mike


pgp6fPcMfr3AG.pgp
Description: PGP signature

[2.6 patch] NF_CONNTRACK_H323 must depend on (IPV6 || IPV6=n)

[Adrian Bunk]

On Sun, Jan 28, 2007 at 11:41:48AM -0800, Randy Dunlap wrote:
>...
> net/built-in.o: In function `q931_help':
> nf_conntrack_h323_main.c:(.text.q931_help+0x6ad): undefined reference to 
> `ip6_route_output'
> nf_conntrack_h323_main.c:(.text.q931_help+0x6c3): undefined reference to 
> `ip6_route_output'
>...

You didn't send your .config, but it seems you had CONFIG_IPV6=m and
CONFIG_NF_CONNTRACK_H323=y.

In this case, the untested patch below should fix it.

> ~Randy

cu
Adrian


<--  snip  -->


CONFIG_IPV6=m, CONFIG_NF_CONNTRACK_H323=y results in a compile error.

Fix this by letting NF_CONNTRACK_H323 depend on (IPV6 || IPV6=n).

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.20-rc6-mm1/net/netfilter/Kconfig.old  2007-01-28 
23:06:37.0 +0100
+++ linux-2.6.20-rc6-mm1/net/netfilter/Kconfig  2007-01-28 23:06:49.0 
+0100
@@ -165,7 +165,7 @@
 
 config NF_CONNTRACK_H323
tristate "H.323 protocol support (EXPERIMENTAL)"
-   depends on EXPERIMENTAL && NF_CONNTRACK
+   depends on EXPERIMENTAL && NF_CONNTRACK && (IPV6 || IPV6=n)
help
  H.323 is a VoIP signalling protocol from ITU-T. As one of the most
  important VoIP protocols, it is widely used by voice hardware and

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

Re: [PATCH 1/6] msi: Kill msi_lookup_irq

[Eric W. Biederman]

Paul Mackerras <[EMAIL PROTECTED]> writes:

> Eric W. Biederman writes:
>
>> @@ -693,15 +664,14 @@ int pci_enable_msi(struct pci_dev* dev)
>>  if (!pos)
>>  return -EINVAL;
>>  
>> -WARN_ON(!msi_lookup_irq(dev, PCI_CAP_ID_MSI));
>> +WARN_ON(!!dev->msi_enabled);
>
> Minor nit: what's wrong with just WARN_ON(dev->msi_enabled) ?

It's a bitfield so gcc complains when something in WARN_ON calls
typeof on it.  So it is easier to just say !! than to dig into
WARN_ON and see if it made any sense to fix WARN_ON, or to see if gcc
needed the bug fix.

> Also here:
>
>> @@ -836,16 +811,14 @@ int pci_enable_msix(struct pci_dev* dev, struct
> msix_entry *entries, int nvec)
>>  return -EINVAL; /* duplicate entry */
>>  }
>>  }
>> -temp = dev->irq;
>> -WARN_ON(!msi_lookup_irq(dev, PCI_CAP_ID_MSIX));
>> +WARN_ON(!!dev->msix_enabled);
>
> Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hidden SSID's

[Larry Finger]

Dan Williams wrote:
> On Fri, 2007-01-26 at 21:48 -0600, Larry Finger wrote:
>> Is there a convention regarding the information that a wireless MAC layer 
>> should provide when
>> reporting scan data from an AP with a hidden SSID?
>>
>> In ieee80211, the software inserts the string "" for such an AP, 
>> which seems to give
>> wpa_supplicant fits because it rejects the SSID before even looking at the 
>> encryption data. Is this
>> the normal convention?
> 
> No.  It's wrong.  It is not normal convention.  The one and only
> _correct_ way of reporting a hidden SSID is to not report the SSID at
> all.  The only item that needs to be reported with WEXT is the BSSID,
> and the client app assumes that if the SSID is not received for a given
> scan result, that the driver doesn't have an SSID for that BSSID.
> 
> I really, really don't know why ieee80211 uses , but it's a pain
> in the ass and should NOT be done for d80211.  I don't know if we can
> ever remove it from ieee80211 though for backwards compat reasons.

Is there something funny about Cisco APs with hidden SSID? I made a patch for 
ieee80211 and softmac
that works on my AP when its SSID is hidden. It also works for Paul Marks on 
his personal AP, but
fails for the Cisco units at Purdue. His interface is a 4311 and there may be a 
signal strength
issue, but we are not sure.

My patch fixes ieee80211 without breaking the previous behavior.

Larry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/6] MSI portability cleanups

[Eric W. Biederman]

Jeff Garzik <[EMAIL PROTECTED]> writes:

> I think the high-level ops approach makes more sense.  It's more future proof,
> in addition to covering all existing implementations.

To be precise in Michaels implementation one of the parameters passed is
a type parameter so that the architecture has to know about each different
type of msi implementation.   In my implementation that field does not exist,
because it is unnecessary.  So as long as the message on the bus is a msi
message my implementation can be adapted to support it without any architecture
changes.

Being future proof is about getting the abstraction correct, and exposing
those details that matter, and removing those detail that don't.

It is a minor nit, not a fundamental flaw in the operations concept.  But
one of the reasons I am opposed to throwing out the current working code.
Evolutionary change ensures that things only the code remembers don't get
left behind.

I guess that is the other part of the discussion that shows up here
is, as long as the change is an evolutionary change from what is
working today.  I don't have any fundamental problems with it, but I
am completely against a revolutionary change.

Meanwhile because Michael has proposed operations my position has been
perceived as against operations.  While I have a lot of technical nits
to pick with the Michaels operations approach, I'm not fundamentally
against it.  I just don't want to loose the information that only
the code remembers.

Most of my technical objections have been formed by looking at what
the code does today, looking at what Michaels code is doing and seeing
details he missed.  If we just start with the current code base and
fix it the whole approach is much easier.

Anyway last I heard Michael was working on starting with the current
msi.c and making his patch set work, and I am hoping that my work
will make that patchset cleaner, and easier to do.  Even if we do
conflict at the moment :)

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

Re: [PATCH 1/6] msi: Kill msi_lookup_irq

[Paul Mackerras]

Eric W. Biederman writes:

> @@ -693,15 +664,14 @@ int pci_enable_msi(struct pci_dev* dev)
>   if (!pos)
>   return -EINVAL;
>  
> - WARN_ON(!msi_lookup_irq(dev, PCI_CAP_ID_MSI));
> + WARN_ON(!!dev->msi_enabled);

Minor nit: what's wrong with just WARN_ON(dev->msi_enabled) ?
Also here:

> @@ -836,16 +811,14 @@ int pci_enable_msix(struct pci_dev* dev, struct 
> msix_entry *entries, int nvec)
>   return -EINVAL; /* duplicate entry */
>   }
>   }
> - temp = dev->irq;
> - WARN_ON(!msi_lookup_irq(dev, PCI_CAP_ID_MSIX));
> + WARN_ON(!!dev->msix_enabled);

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

Re: Linux 2.6.20-rc6 - suspend / resume ata_piix

[Thomas Gleixner]

On Sat, 2007-01-27 at 23:44 +0100, Thomas Gleixner wrote:
> > If its a regression, what changeset caused the problem?
> 
> Hey. I just discovered that crap. I'm going to bisect tomorrow. Bed time
> here in good old Europe. :)

It seems to be there in 2.6.18 already, although it takes more
suspend/resume cycles to show up. So it's just the surfacing of some
longer standing problem. Just went unnoticed.

tglx


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