Re: [Linux-cluster] Re: GFS, what's remaining

[Joel Becker]

On Sun, Sep 04, 2005 at 01:52:29AM -0400, Daniel Phillips wrote:
> You do have ->release and ->make_item/group.

->release is like kobject release.  It's a free callback, not a
callback from close.

> If I may hand you a more substantive argument: you don't support user-driven
> creation of files in configfs, only directories.  Dlmfs supports user-created
> files.  But you know, there isn't actually a good reason not to support
> user-created files in configfs, as dlmfs demonstrates.

It is outside the domain of configfs.  Just because it can be
done does not mean it should be.  configfs isn't a "thing to create
files".  It's an interface to creating kernel items.  The actual
filesystem representation isn't the end, it's just the means.

Joel

-- 

"In the room the women come and go
 Talking of Michaelangelo."

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-cluster] Re: GFS, what's remaining

[Joel Becker]

On Sat, Sep 03, 2005 at 10:41:40PM -0700, Andrew Morton wrote:
> Are you saying that the posix-file lookalike interface provides access to
> part of the functionality, but there are other APIs which are used to
> access the rest of the functionality?  If so, what is that interface, and
> why cannot that interface offer access to 100% of the functionality, thus
> making the posix-file tricks unnecessary?

Currently, this is all the interface that the OCFS2 DLM
provides.  But yes, if you wanted to provide the rest of the VMS
functionality (something that GFS2's DLM does), you'd need to use a more
concrete interface.
IMHO, it's worthwhile to have a simple interface, one already
used by mkfs.ocfs2, mount.ocfs2, fsck.ocfs2, etc.  This is an interface
that can and is used by shell scripts even (we do this to test the DLM).
If you make it a C-library-only interface, you've just restricted the
subset of folks that can use it, while adding programming complexity.
I think that a simple fs-based interface can coexist with a more
complex one.  FILE* doesn't give you the flexibility of read()/write(),
but I wouldn't remove it :-)

Joel

-- 

"In the beginning, the universe was created. This has made a lot 
 of people very angry, and is generally considered to have been a 
 bad move."
- Douglas Adams

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-cluster] Re: GFS, what's remaining

[Daniel Phillips]

On Sunday 04 September 2005 01:00, Joel Becker wrote:
> On Sun, Sep 04, 2005 at 12:51:10AM -0400, Daniel Phillips wrote:
> > Clearly, I ought to have asked why dlmfs can't be done by configfs.  It
> > is the same paradigm: drive the kernel logic from user-initiated vfs
> > methods.  You already have nearly all the right methods in nearly all the
> > right places.
>
>  configfs, like sysfs, does not support ->open() or ->release()
> callbacks.

struct configfs_item_operations {
 void (*release)(struct config_item *);
 ssize_t (*show)(struct config_item *, struct attribute *,char *);
 ssize_t (*store)(struct config_item *,struct attribute *,const char *, size_t);
 int (*allow_link)(struct config_item *src, struct config_item *target);
 int (*drop_link)(struct config_item *src, struct config_item *target);
};

struct configfs_group_operations {
 struct config_item *(*make_item)(struct config_group *group, const char *name);
 struct config_group *(*make_group)(struct config_group *group, const char 
*name);
 int (*commit_item)(struct config_item *item);
 void (*drop_item)(struct config_group *group, struct config_item *item);
};

You do have ->release and ->make_item/group.

If I may hand you a more substantive argument: you don't support user-driven
creation of files in configfs, only directories.  Dlmfs supports user-created
files.  But you know, there isn't actually a good reason not to support
user-created files in configfs, as dlmfs demonstrates.

Anyway, goodnight.

Regards,

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

Re: Brand-new notebook useless with Linux...

[Zwane Mwaikambo]

On Sun, 4 Sep 2005, Willy Tarreau wrote:

> On Sat, Sep 03, 2005 at 06:58:00PM -0400, Chuck Ebbert wrote:
> > I just bought a new notebook.  Here is the output from lspci using the 
> > latest
> > pci.ids file from sourceforge:
> 
> You seem to be surprized by the contents. When I recently changed my 
> work notebook (dead screen on the previous one), it took me nearly 6
> months to find one which suits my needs (serial, floppy, ...) and to
> ensure that everything in it was supported. I've refused several ones
> because there was no clear indication that they hosted supported hardware.
> So I'm a bit amazed by your reaction, you seem to have bought the first
> cheap K8 you saw in a store.

Incidentally, Is that a Compaq R4000?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-cluster] Re: GFS, what's remaining

[Andrew Morton]

Joel Becker <[EMAIL PROTECTED]> wrote:
>
>  > What happens when we want to add some new primitive which has no posix-file
>  > analog?
> 
>   The point of dlmfs is not to express every primitive that the
>  DLM has.  dlmfs cannot express the CR, CW, and PW levels of the VMS
>  locking scheme.  Nor should it.  The point isn't to use a filesystem
>  interface for programs that need all the flexibility and power of the
>  VMS DLM.  The point is a simple system that programs needing the basic
>  operations can use.  Even shell scripts.

Are you saying that the posix-file lookalike interface provides access to
part of the functionality, but there are other APIs which are used to
access the rest of the functionality?  If so, what is that interface, and
why cannot that interface offer access to 100% of the functionality, thus
making the posix-file tricks unnecessary?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Brand-new notebook useless with Linux...

[Willy Tarreau]

On Sat, Sep 03, 2005 at 06:58:00PM -0400, Chuck Ebbert wrote:
> I just bought a new notebook.  Here is the output from lspci using the latest
> pci.ids file from sourceforge:

You seem to be surprized by the contents. When I recently changed my 
work notebook (dead screen on the previous one), it took me nearly 6
months to find one which suits my needs (serial, floppy, ...) and to
ensure that everything in it was supported. I've refused several ones
because there was no clear indication that they hosted supported hardware.
So I'm a bit amazed by your reaction, you seem to have bought the first
cheap K8 you saw in a store.

If I were you, I'd return it.

Regards,
Willy

> 00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 01)
> 00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 5a3f
> 00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller
> 00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller
> 00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller
> 00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 11)
> 00:14.1 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE 
> Controller ATI
> 00:14.3 ISA bridge: ATI Technologies Inc IXP SB400 PCI-ISA Bridge
> 00:14.4 PCI bridge: ATI Technologies Inc IXP SB400 PCI-PCI Bridge
> 00:14.5 Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97 
> Audio Controller (rev 02)
> 00:14.6 Modem: ATI Technologies Inc: Unknown device 4378 (rev 02)
> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
> HyperTransport Technology Configuration
> 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
> Address Map
> 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM 
> Controller
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
> Miscellaneous Control
> 01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 
> 200M 5955 (PCIE)
> 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
> RTL-8139/8139C/8139C+ (rev 10)
> 05:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 
> 802.11g Wireless LAN Controller (rev 02)
> 05:09.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
> 05:09.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host 
> Controller
> 05:09.3 Mass storage controller: Texas Instruments PCIxx21 Integrated 
> FlashMedia Controller
> 05:09.4 Class 0805: Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621, 
> PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD) Controller
> 
> None of these work and I can find no support anywhere for them:
> 
> SMBus
> Audio ("unknown codec")
> Modem ("no codec available")
> Wireless
> FlashMedia
> SD/MMC
> 
> Additionally, the system clock runs at 2x normal speed with PowerNow enabled.
> 
> Am I stuck with running XP on this thing?
> 
> __
> Chuck
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: [Linux-cluster] Re: GFS, what's remaining

[Joel Becker]

On Sun, Sep 04, 2005 at 12:51:10AM -0400, Daniel Phillips wrote:
> Clearly, I ought to have asked why dlmfs can't be done by configfs.  It is 
> the 
> same paradigm: drive the kernel logic from user-initiated vfs methods.  You 
> already have nearly all the right methods in nearly all the right places.

configfs, like sysfs, does not support ->open() or ->release()
callbacks.  And it shouldn't.  The point is to hide the complexity and
make it easier to plug into.  
A client object should not ever have to know or care that it is
being controlled by a filesystem.  It only knows that it has a tree of
items with attributes that can be set or shown.

Joel


-- 

"In a crisis, don't hide behind anything or anybody. They're going
 to find you anyway."
- Paul "Bear" Bryant

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-cluster] Re: GFS, what's remaining

[Joel Becker]

On Sat, Sep 03, 2005 at 09:46:53PM -0700, Andrew Morton wrote:
> It would be much better to do something which explicitly and directly
> expresses what you're trying to do rather than this strange "lets do this
> because the names sound the same" thing.

So, you'd like a new flag name?  That can be done.

> What happens when we want to add some new primitive which has no posix-file
> analog?

The point of dlmfs is not to express every primitive that the
DLM has.  dlmfs cannot express the CR, CW, and PW levels of the VMS
locking scheme.  Nor should it.  The point isn't to use a filesystem
interface for programs that need all the flexibility and power of the
VMS DLM.  The point is a simple system that programs needing the basic
operations can use.  Even shell scripts.

Joel

-- 

"You must remember this:
 A kiss is just a kiss,
 A sigh is just a sigh.
 The fundamental rules apply
 As time goes by."

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 1 of 4] Configfs is really sysfs

[Joel Becker]

On Sat, Sep 03, 2005 at 09:41:36PM -0700, Joel Becker wrote:
> On Sat, Sep 03, 2005 at 09:12:24PM -0700, Joel Becker wrote:
> > On Tue, Aug 30, 2005 at 04:28:46PM -0700, Andrew Morton wrote:
> > > Sure, but all that copying-and-pasting really sucks.  I'm sure there's 
> > > some
> > > way of providing the slightly different semantics from the same codebase?
> 

So, what conclusions can we draw from looking at this again?
First, merging the kobject/kset structures with the
config_item/config_group structures has one benefit: they have the same
name.  However, that's also the first problem.  As it currently stands,
you know from the name what you are working with.  If they have the same
name, you don't know if you are working with an object in sysfs or
configfs.  We call a pid "pid_t" rather than "unsigned int" for the same
reason, clarity of usage.
Merging them has a lot of other problems.  Far from removing
code bloat (a configfs object and a sysfs object need different
initialization, etc, so there would be two paths anyway), it adds
significant memory bloat, as configfs objects and sysfs objects are
carrying around members for the other filesystem.  Finally, there are
surprises in store if you try to use some of the API that isn't
appropriate.  With a different name and type, you just _can't_ do that.
We could perhaps share the attribute structure.  This has the
same name confusion problem above, but that's about it, assuming that
sysfs never wants to do anything smarter with them.  I'm hoping the
sysfs folks comment on this.
Sharing the attribute file code is much harder.  They operate on
different types, and those types are laid out differently.  I think we'd
have to make the API far more invasive.  Instead of black-boxing the API
and having only show/store to implement, we'd have to provide some sort
of translation from the native structure to a shared type.  Basically,
repeating what the VFS has already done for us.
Finally, assuming that the sysfs_dirent/configfs_dirent
arrangement is pretty fleshed out, I think that perhaps this backing
store could be joined.  Again, no more magic could be added, and it
would have to handle the sysfs and configfs types in concurrence, but I
think it could be done.  Again, sysfs folks, please comment.

Joel

-- 

"Hell is oneself, hell is alone, the other figures in it, merely projections."
- T. S. Eliot

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-cluster] Re: GFS, what's remaining

[Andrew Morton]

Daniel Phillips <[EMAIL PROTECTED]> wrote:
>
> The model you came up with for dlmfs is beyond cute, it's downright clever.  

Actually I think it's rather sick.  Taking O_NONBLOCK and making it a
lock-manager trylock because they're kinda-sorta-similar-sounding?  Spare
me.  O_NONBLOCK means "open this file in nonblocking mode", not "attempt to
acquire a clustered filesystem lock".  Not even close.

It would be much better to do something which explicitly and directly
expresses what you're trying to do rather than this strange "lets do this
because the names sound the same" thing.

What happens when we want to add some new primitive which has no posix-file
analog?

Wy too cute.  Oh well, whatever.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-cluster] Re: GFS, what's remaining

[Daniel Phillips]

On Sunday 04 September 2005 00:30, Joel Becker wrote:
> You asked why dlmfs can't go into sysfs, and I responded.

And you got me!  In the heat of the moment I overlooked the fact that you and 
Greg haven't agreed to the merge yet ;-)

Clearly, I ought to have asked why dlmfs can't be done by configfs.  It is the 
same paradigm: drive the kernel logic from user-initiated vfs methods.  You 
already have nearly all the right methods in nearly all the right places.

Regards,

Daniel




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

Re: [RFC][PATCH 1 of 4] Configfs is really sysfs

[Joel Becker]

On Sat, Sep 03, 2005 at 09:12:24PM -0700, Joel Becker wrote:
> On Tue, Aug 30, 2005 at 04:28:46PM -0700, Andrew Morton wrote:
> > Sure, but all that copying-and-pasting really sucks.  I'm sure there's some
> > way of providing the slightly different semantics from the same codebase?

The final piece of similar code is the buffered I/O setup for
attribute files.  Here, the major difference is how config_items and
kobjects refer to their show/store operations.  The functions have
different rules on this.
A kobject doesn't need show/store, it can provide one for the
entire kset or subsystem.  A config_item necessarily has one for its
type, and cannot chain up.  So somehow the code would need to know which
was the case.
 A kobject directly has a sysfs_ops structure.  The config_item
has show/store in a config_item_operations strucutre.  If you split them
out, you add a pointer and some needless complexity.  So the different
code paths need to refer to the functions differently.
The attribute and configfs_attribute structures are physically
identical, but the sysfs one has poor naming (IMHO).  If struct
attribute wasn't going to change, and no magic would be added to its
usage (magic like kobject_add()'s intertwining with sysfs), they could
probably be shared.

Joel

-- 

"The doctrine of human equality reposes on this: that there is no
 man really clever who has not found that he is stupid."
- Gilbert K. Chesterson

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-cluster] Re: GFS, what's remaining

[Joel Becker]

On Sun, Sep 04, 2005 at 12:22:36AM -0400, Daniel Phillips wrote:
> It is 640 lines.

It's 450 without comments and blank lines.  Please, don't tell
me that comments to help understanding are bloat.

> I said "configfs" in the email to which you are replying.

To wit:

> Daniel Phillips said:
> > Mark Fasheh said:
> > > as far as userspace dlm apis go, dlmfs already abstracts away a
> > > large
> > > part of the dlm interaction...
> >
> > Dumb question, why can't you use sysfs for this instead of rolling
> > your
> > own?

You asked why dlmfs can't go into sysfs, and I responded.

Joel

-- 

"I don't want to achieve immortality through my work; I want to
 achieve immortality through not dying."
- Woody Allen

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-cluster] Re: GFS, what's remaining

[Daniel Phillips]

On Saturday 03 September 2005 23:06, Joel Becker wrote:
>  dlmfs is *tiny*.  The VFS interface is less than his claimed 500
> lines of savings.

It is 640 lines.

> The few VFS callbacks do nothing but call DLM 
> functions.  You'd have to replace this VFS glue with sysfs glue, and
> probably save very few lines of code.
>  In addition, sysfs cannot support the dlmfs model.  In dlmfs,
> mkdir(2) creates a directory representing a DLM domain and mknod(2)
> creates the user representation of a lock.  sysfs doesn't support
> mkdir(2) or mknod(2) at all.

I said "configfs" in the email to which you are replying.

>  More than mkdir() and mknod(), however, dlmfs uses open(2) to
> acquire locks from userspace.  O_RDONLY acquires a shared read lock (PR
> in VMS parlance).  O_RDWR gets an exclusive lock (X).  O_NONBLOCK is a
> trylock.  Here, dlmfs is using the VFS for complete lifetiming.  A lock
> is released via close(2).  If a process dies, close(2) happens.  In
> other words, ->release() handles all the cleanup for normal and abnormal
> termination.
>
>  sysfs does not allow hooking into ->open() or ->release().  So
> this model, and the inherent lifetiming that comes with it, cannot be 
> used.

Configfs has a per-item release method.  Configfs has a group open method.  
What is it that configfs can't do, or can't be made to do trivially?

> If dlmfs was changed to use a less intuitive model that fits 
> sysfs, all the handling of lifetimes and cleanup would have to be added.

The model you came up with for dlmfs is beyond cute, it's downright clever.  
Why mar that achievement by then failing to capitalize on the framework you 
already have in configfs?

By the way, do you agree that dlmfs is too inefficient to be an effective way 
of exporting your dlm api to user space, except for slow-path applications 
like you have here?

Regards,

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

Re: [RFC][PATCH 1 of 4] Configfs is really sysfs

[Joel Becker]

On Tue, Aug 30, 2005 at 04:28:46PM -0700, Andrew Morton wrote:
> Sure, but all that copying-and-pasting really sucks.  I'm sure there's some
> way of providing the slightly different semantics from the same codebase?

What about the backing store?  Specifically, sysfs_dirent vs
configfs_dirent.
The structures are almost identical.  What's different?
configfs has a list of symlinks, as these are hard linkages and involve
pinning and reference counting.  So, to merge the structures, you have
to add two pointers (a list_head) to every sysfs object.
Allocating, initializing, and freeing them really does appear to
be virtually identical.  The functions that call the creation are very
different, but they could call the same thing.  There are more types of
things in configfs, so all shared calls would have to be able to handle
them.
Oh, but the get_name() functions, the one that return the string
name of a _dirent, are very different.  So you'd have to add another
pointer to the structure, a ->get_name() callback.  That's an additional
pointer for every sysfs object.
The attach_attr() functions are different.  Some of that is the
BIN_ATTR type of sysfs, which configfs doesn't and shouldn't have.  In
that case, the code still works, as BIN_ATTR test wouldn't succeed.
They configure dentry_ops, which are different in sysfs and configfs.
So the API would have to change to specify the appropriate dentry_ops.
This is certainly not insurmountable.  I don't know what you'd
call it, fs/libfs/backing_store.c?  I'm interested in what the sysfs
folks have to say on this, and how much they'd like to help.

Joel

-- 

A good programming language should have features that make the
kind of people who use the phrase "software engineering" shake
their heads disapprovingly.
- Paul Graham

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: gcc coredump with 2.6.12+ kernels

[Johnny Stenback]

Alexander Nyberg wrote:

On Sat, Sep 03, 2005 at 10:25:37AM -0700 Johnny Stenback wrote:


Hey all,

I just attempted to upgrade my kernel to 2.6.13. The kernel appears to 
boot and run just fine, but when I try to build any larger projects like 
Mozilla or the Linux kernel I constantly get segfaults from gcc. All 
other apps *seem* to work fine. I remember seeing this with 2.6.12 too 
when I tried to upgrade to it too but I didn't have the time to 
investigate at all then, but now I see the same problem with 2.6.13. The 
last version I've used that didn't show this problem is 2.6.11.3, and 
that's running with no problems here.


When gcc segfaults I get the following messages in the messages log:

cc1[16775]: segfault at  rip 0036f2b0119e rsp 
7faaf0a0 error 4
cc1[17086]: segfault at  rip 0036f2b0119e rsp 
7fc4dfc0 error 4
cc1[17788]: segfault at  rip 0036f2b0119e rsp 
7fd777e0 error 4
cc1[17823]: segfault at  rip 0036f2b0119e rsp 
7fc4d630 error 4
cc1[17895]: segfault at  rip 0036f2b0119e rsp 
7ffd2330 error 4


I'm on a dual AMD Opteron system, running x86_64 code. Using Fedora Core 
2 (yeah, old, I know...) and gcc 3.3.3 20040412.


Does it still happen if you run:

echo 0 > /proc/sys/kernel/randomize_va_space


Just tried that, and I still get the same error, and the same error in 
the log too (just a different address):


cc1plus[2961]: segfault at  rip
0036f2b0119e rsp 7fffdbb0 error 4

Anything else I can try?


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



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

Re: [x86_64] Exception when using powernowd.

[Zwane Mwaikambo]

On Sat, 3 Sep 2005, Kyuma Ohta wrote:

> Thanx David,
> 
> Written by David Ranson <[EMAIL PROTECTED]>
>at Sat, 03 Sep 2005 09:33:56 +0100 :
> Subject: Re: [x86_64] Exception when using powernowd.
> 
> spam.david.trap> Kyuma Ohta wrote:
> spam.david.trap> 
> spam.david.trap> 
> spam.david.trap> >>Hi,
> spam.david.trap> >>
> spam.david.trap> >>I'm using MSI K8T Neo2 (VIA K8T800 chipset) and Athlon64 
> 3000+
> spam.david.trap> >>with  linux x86_64 2.6.13 kernel and Debian/sid.
> spam.david.trap> >>  
> spam.david.trap> >>
> spam.david.trap> >  
> spam.david.trap> >
> spam.david.trap> I'm using a K8T Neo2 FIR with the same processor and 
> powernow-k8. Up
> spam.david.trap> with 2.6.13 since Sunday, no problems noted. Mine is a SuSE 
> 9.1 based
> spam.david.trap> system though.
> spam.david.trap> 
> spam.david.trap> Maybe BIOS related??
> 
> I thought this problem,too.
> 
> But,I was upgrade BIOS from v3.3 to v9.2,this issue has happened yet.
> 
> # And,I have to put "pnpacpi=off" to kernel boot line to 
> # use w83627ths sensor (-_-;
> 
> When upgrade X 6.8.2-4 to 6.8.2-5(or after),this issue has often happend.
> I'm using nVidia Geforce 5200 as Display adapter,but this issue
> has happend bot Debian's driver and nVidia's driver.

I saw something very related in one of Bongani's posts on kernel bugzilla;

http://bugzilla.kernel.org/show_bug.cgi?id=4851 (scroll to the bottom)

Is there a specific kernel version which started this?

Thanks,
Zwane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 1 of 4] Configfs is really sysfs

[Joel Becker]

On Tue, Aug 30, 2005 at 04:28:46PM -0700, Andrew Morton wrote:
> Sure, but all that copying-and-pasting really sucks.  I'm sure there's some
> way of providing the slightly different semantics from the same codebase?

First, let's look at sharing the primary structures.

[kobject vs config_item]

When I first started configfs, I tried to make it part of sysfs.
That was obviously a bad idea before I got very far at all (more on this
as we go along).  So I forked the codebase.  I wanted, however, to
preserve kobject and kset, because I figured we didn't need another
kernel object type.  For the longest time usysfs (user-sysfs, as it was
originally called) used kobjects and jumped through hoops to make it work.
The base structures, kobject and config_item, are indeed
identical in physical layout.  But in use, they are very different.  A
kobject, when created, is expected to appear sysfs.  You mistakenly
kobject_add(), whoops, there it is.  kobject_init() tries to link a
kobject to the kobject->kset pointer, because it's expecting the kernel
to be handling the relationship.
In configfs, the relationship is handled by the VFS.  The
linkage is purposefully controlled by the ->mkdir() codepath.  The
client driver using this relationship can follow it, but never modify it
or call anything that modifies it.
In the earlier configfs incarnations that used kobject/kset, I
found myself having to fool the kobject infrastructure to get
kobject->kset correct.  In addition, it was a complexity I had to always
think about.  In configfs with config_item, it's not an issue because it
doesn't exist.

[kobj_type vs config_item_type]

kobj_type has three pointers.  A release function for the
object, a set of sysfs_ops for attribute functions, and a set of
default_attrs.
config_item_type needs to know the module owner to pin the
client module.  It has 5 item operations (this includes the parallels
for sysfs_ops) and 4 group operations (this is for config_group, the
parallel of kset).  Because operation structures are often shared, these
are made into structures.
kobj_type would have to know all the features of
config_item_type, even though it is useless stuff for sysfs.  Waste of
memory and code.

[subsystem vs configfs_subsystem]

The sysfs folks are trying to lose the semaphore from a sysfs
subsystem, because it makes sense to have locking that is finer grained.
It should apply to the granularity of the specific device or so.
configfs_subsystem needs the semaphore, because it protects only
one thing: the config_group/config_item hierarchy.  When a client module
wants to navigate the tree of its groups and items, it merely takes the
semaphore and navigates.  Once it finds and grabs a kref to what it
needs, it can drop it.  There is no need for any more complex locking.

[kset vs config_group]

Here is where it gets really different.  A kset may or may not
represent a directory exactly.  kobjects can be part of a kset they
aren't under in the sysfs tree.  configfs_items must be part of the
parent config_group, becuase the VFS tree (the dcache) is the exact
arbiter of the relationship.
Then there is the physical structure.  A kset contains a pointer
to a kobj_type that its children will be assigned.  This field is
useless in configfs, and more importantly, it could result in an
assignemnt that isn't related to the real object type, becuase of kset's
ability to have non-children members.  This adds more complexity to the
code, as you have to handle, prevent, or kludge around this case.
kset contains a lock around its list of children.  configfs
doesn't need this because the subsystem lock is protecting the hierarchy
here.
kset contains a hotplug ops pointer.  configfs has nothing to do
with hotplug.  So here are three pointers any configfs object has to
carry around for no reason other than sharing a structure.
Conversely, a config_group contains a list of default subgroups.
They are not attributes, they are groups.  This is not the same as
config_item's default_attrs.  Here, kset would carry around an extra
pointer for every object.
Given the stress everyone places on the memory usage of these
objects, adding useless pointers to both sides just to share the
structure seems a very bad idea.


-- 

"Well-timed silence hath more eloquence than speech."  
 - Martin Fraquhar Tupper

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: i386: kill !4KSTACKS

[Lee Revell]

On Fri, 2005-09-02 at 02:39 +0200, Adrian Bunk wrote:
> 4Kb kernel stacks are the future on i386, and it seems the problems it
> initially caused are now sorted out.
> 
> Does anyone knows about any currently unsolved problems?

ndiswrapper

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

Re: looking for help tracing oops

[Zwane Mwaikambo]

On Fri, 2 Sep 2005, Christopher Friesen wrote:

> 
> I'm debugging a problem.  Unfortunately, I have a module loaded that taints
> the kernel.
> 
> Now that that's out of the way, if anyone is still willing to help, the oops
> is below, along with the disassembly of filp_close().  One thing I don't
> understand--the function makes calls to other functions including printk(),
> but I don't see those calls listed in the disassembly.

I like to use `objdump -d -r` this is mostly handy for modules since the 
external references aren't resolved yet.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Brand-new notebook useless with Linux...

[Lee Revell]

On Sat, 2005-09-03 at 18:58 -0400, Chuck Ebbert wrote:
> I just bought a new notebook.

I'd return it if I were you.

Lee

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

Re: looking for help tracing oops

[Chuck Ebbert]

In-Reply-To: <[EMAIL PROTECTED]>

On Fri, 02 Sep 2005 at 22:25:40 -0600, Christopher Friesen wrote:

> One thing I 
> don't understand--the function makes calls to other functions including 
> printk(), but I don't see those calls listed in the disassembly.

Calls to external functions whose address is not known at compile time
look like this (using 'objdump -d' on my 2.6.10 kernel:)

19fd:   e8 fc ff ff ff  call   19fe 

e8 is call relative with 32-bit displacement from start of next instruction.
The displacement points right back at itself (fffc == -4)

> EIP is at filp_close+0x64/0xa0

Here:

> 0x1ac4 :mov0x2c(%eax),%edx  <
> 0x1ac7 :test   %edx,%edx
> 0x1ac9 :je 0x1a93 

eax is f88ad500 and your illegal access was at f88ad52c

Looks like filp->fops points to unallocated memory and it dies while
trying to access filp->fops->flush here:

if (filp->f_op && filp->f_op->flush) {
 
__
Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: nfs4 client bug

[Bret Towe]

On 9/3/05, Bret Towe <[EMAIL PROTECTED]> wrote:
> i encountered the following error while using nfs4
> ive hit this error i think twice now not sure what causes it yet tho
> this time the only io related items going on was emerge sync running
> in the background (which shouldnt of touched nfs at all) and xmms
> playing some music
> 
> another problem i had was iowait was showing near 100% but nothing
> over nfs was working
> but no errors or anything was showing in dmesg if i encounter this
> again is there a way to
> find out where it locked up so i can give a report on what the problem is?
> 
> attached is my config the box is an athlon64
> if any further information is needed let me know
> 
> Unable to handle kernel paging request at 00100108 RIP:
> {generic_drop_inode+56}
> PGD 27bec067 PUD 27be9067 PMD 0
> Oops: 0002 [1]
> CPU 0
> Modules linked in: fglrx agpgart snd_seq_midi snd_emu10k1_synth
> snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss
> snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1
> snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer
> snd_page_alloc snd_util_mem snd_hwdep snd w83627hf i2c_sensor i2c_isa
> i2c_core usb_storage r8169 ehci_hcd uhci_hcd dm_mirror dm_snapshot
> dm_mod
> Pid: 149, comm: kswapd0 Tainted: P   M  2.6.13
> RIP: 0010:[] {generic_drop_inode+56}
> RSP: 0018:81002f9d9b78  EFLAGS: 00010246
> RAX: 00100100 RBX: 810022d4d950 RCX: 00200200
> RDX: 810022d4d960 RSI: 81002ea21000 RDI: 810022d4d950
> RBP: 810022d4d950 R08: fffa R09: 810022d4da68
> R10: 0001 R11: 80189500 R12: 
> R13: 810022d4d7d0 R14: 810022d4d860 R15: 81002c3cec00
> FS:  2bc64f80() GS:805bc800() knlGS:
> CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
> CR2: 00100108 CR3: 27468000 CR4: 06e0
> Process kswapd0 (pid: 149, threadinfo 81002f9d8000, task 81002f9d2760)
> Stack: 81002a65fa00 801e2925 00012f9d9bf8 81002f9d9c28
> 81002f9d9c28 81002f9d9c10 810022d4d938
>0001 
> Call Trace:{__nfs_revalidate_inode+261}
> {find_get_pages_tag+31}
>{pagevec_lookup_tag+26}
> {wait_on_page_writeback_range+206}
>{nfs_do_return_delegation+42}
> {nfs_inode_return_delegation+197}
>{nfs4_clear_inode+32}
> {clear_inode+158}
>{dispose_list+94}
> {shrink_icache_memory+434}
>{shrink_slab+219} 
> {balance_pgdat+617}
>{balance_pgdat+2} {kswapd+295}
>{autoremove_wake_function+0}
> {autoremove_wake_function+0}
>{child_rip+8} {kswapd+0}
>{child_rip+0}
> 
> Code: 48 89 48 08 48 89 01 48 8b 05 8a 4e 30 00 48 89 50 08 48 89
> RIP {generic_drop_inode+56} RSP 
> CR2: 00100108
>  --- [cut here ] - [please bite here ] -
> Kernel BUG at "fs/inode.c":1142
> invalid operand:  [2]
> CPU 0
> Modules linked in: fglrx agpgart snd_seq_midi snd_emu10k1_synth
> snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss
> snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1
> snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer
> snd_page_alloc snd_util_mem snd_hwdep snd w83627hf i2c_sensor i2c_isa
> i2c_core usb_storage r8169 ehci_hcd uhci_hcd dm_mirror dm_snapshot
> dm_mod
> Pid: 9539, comm: rpciod/0 Tainted: P   M  2.6.13
> RIP: 0010:[] {iput+30}
> RSP: 0018:81002a181e08  EFLAGS: 00010246
> RAX: 80494a00 RBX: 810023da8d40 RCX: 81002311f490
> RDX: 810022919680 RSI: 81002614da40 RDI: 810023da8d40
> RBP: 8100286af780 R08: 8100230f64e0 R09: 
> R10: 0001 R11: 801f8c90 R12: 81002311f480
> R13: 81002614da00 R14: 81002c3cec00 R15: 805c3fb0
> FS:  2ade6b00() GS:805bc800() knlGS:
> CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
> CR2: 2ade0680 CR3: 22d19000 CR4: 06e0
> Process rpciod/0 (pid: 9539, threadinfo 81002a18, task 
> 81002a4a2330)
> Stack: 81002311f480 801fb0fd fff3 81002fb0f1c0
>8100286af780 801efa51 81002fb0f1c0 81002d9be310
>81002fb0f2a8 81002d9be320
> Call Trace:{nfs4_put_open_state+109}
> {nfs4_close_done+225}
>{__rpc_execute+165}
> {worker_thread+442}
>{default_wake_function+0}
> {default_wake_function+0}
>{worker_thread+0} {kthread+205}
>{child_rip+8}
> {keventd_create_kthread+0}
>{kthread+0} {child_rip+0}
> 
> 
> Code: 0f 0b a3 e0 61 3c 80 ff ff ff ff c2 76 04 66 66 66 90 48 85
> RIP {iput+30} RSP 
> 
> 
> 

after moving some files on the server to a new location then trying to
add the files
to xmms playlist i found the following in dmesg after xmms froze
wonder how many more items i can find...

nfs_update_inode: inode 

Re: [Linux-cluster] Re: GFS, what's remaining

[Joel Becker]

On Sat, Sep 03, 2005 at 06:32:41PM -0700, Andrew Morton wrote:
> If there's duplicated code in there then we should seek to either make the
> code multi-purpose or place the common or reusable parts into a library
> somewhere.

Regarding sysfs and configfs, that's a whole 'nother
conversation.  I've not yet come up with a function involved that is
identical, but that's a response here for another email.
Understanding that Daniel is talking about dlmfs, dlmfs is far
more similar to devptsfs, tmpfs, and even sockfs and pipefs than it is
to sysfs.  I don't see him proposing that sockfs and devptsfs be folded
into sysfs.
dlmfs is *tiny*.  The VFS interface is less than his claimed 500
lines of savings.  The few VFS callbacks do nothing but call DLM
functions.  You'd have to replace this VFS glue with sysfs glue, and
probably save very few lines of code.
In addition, sysfs cannot support the dlmfs model.  In dlmfs,
mkdir(2) creates a directory representing a DLM domain and mknod(2)
creates the user representation of a lock.  sysfs doesn't support
mkdir(2) or mknod(2) at all.
More than mkdir() and mknod(), however, dlmfs uses open(2) to
acquire locks from userspace.  O_RDONLY acquires a shared read lock (PR
in VMS parlance).  O_RDWR gets an exclusive lock (X).  O_NONBLOCK is a
trylock.  Here, dlmfs is using the VFS for complete lifetiming.  A lock
is released via close(2).  If a process dies, close(2) happens.  In
other words, ->release() handles all the cleanup for normal and abnormal
termination.
sysfs does not allow hooking into ->open() or ->release().  So
this model, and the inherent lifetiming that comes with it, cannot be
used.  If dlmfs was changed to use a less intuitive model that fits
sysfs, all the handling of lifetimes and cleanup would have to be added.
This would make it more complex, not less complex.  It would give it a
larger code size, not a smaller one.  In the end, it would be harder to
maintian, less intuitive to use, and larger.

Joel


-- 

"Anything that is too stupid to be spoken is sung."  
- Voltaire

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-usb-devel] Genesys USB 2.0 enclosures

[Alan Stern]

On Sat, 3 Sep 2005, Jan De Luyck wrote:

> Hello lists,
> 
> (a mail for the archives)
> 
> I've posted in the past about problems with these enclosures - increasing the 
> delay seems to fix it, albeit temporarily. The further you go in using the 
> disk in such an enclosure, the higher the udelay() had to be - atleast that's 
> what I'm seeing here (I've got two of these now :/ )
> 
> One permanent fix is adding a powered USB-hub in between the drive enclosures 
> and the computer. Since I've done that, I've no longer seen any of the 
> problems (i've attached the 'fault' log). Weird but true, since the drives 
> come with their own powersupply.
> 
> Hope this helps anyone in the future running into the same problem.

This one certainly goes into the Bizarro file.

Just out of curiosity -- when you use the powered hub, does the drive work 
even if you remove that delay completely?

Alan Stern

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

Re: Brand-new notebook useless with Linux...

[Matthew Garrett]

Chuck Ebbert <[EMAIL PROTECTED]> wrote:

> SMBus

Is there anything on there that you actually want to talk to?

> Audio ("unknown codec")

snd-ati-atiixp ought to drive it - if it doesn't, that's probably a bug.

> Modem ("no codec available")

It's a winmodem. What were you expecting?

> Wireless

Broadcom won't release any specs.

> FlashMedia

TI won't release any specs. If you're especially nice to them, they may
give you a binary driver built against your kernel.

> SD/MMC

Ditto.

> Additionally, the system clock runs at 2x normal speed with PowerNow enabled.

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

> Am I stuck with running XP on this thing?

If you buy a machine with hardware produced by manufacturers that are
hostile to Linux, and you want to use that hardware, then yes. Don't do
that.

-- 
Matthew Garrett | [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: [Linux-cluster] Re: GFS, what's remaining

[Andrew Morton]

Joel Becker <[EMAIL PROTECTED]> wrote:
>
> On Sat, Sep 03, 2005 at 06:21:26PM -0400, Daniel Phillips wrote:
>  > that fit the configfs-nee-sysfs model?  If it does, the payoff will be 
> about 
>  > 500 lines saved.
> 
>   I'm still awaiting your merge of ext3 and reiserfs, because you
>  can save probably 500 lines having a filesystem that can create reiser
>  and ext3 files at the same time.

oy.   Daniel is asking a legitimate question.

If there's duplicated code in there then we should seek to either make the
code multi-purpose or place the common or reusable parts into a library
somewhere.

If neither approach is applicable or practical for *every single function*
then fine, please explain why.  AFAIR that has not been done.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-cluster] Re: GFS, what's remaining

[Joel Becker]

On Sat, Sep 03, 2005 at 06:21:26PM -0400, Daniel Phillips wrote:
> that fit the configfs-nee-sysfs model?  If it does, the payoff will be about 
> 500 lines saved.

I'm still awaiting your merge of ext3 and reiserfs, because you
can save probably 500 lines having a filesystem that can create reiser
and ext3 files at the same time.

Joel

-- 

Life's Little Instruction Book #267

"Lie on your back and look at the stars."

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127

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

Re: [PATCH 2.6.13] lockless pagecache 2/7

[Nick Piggin]

Alan Cox wrote:

On Sad, 2005-09-03 at 11:40 +1000, Nick Piggin wrote:


We'll see how things go. I'm fairly sure that for my usage it will
be a win even if it is costly. It is replacing an atomic_inc_return,
and a read_lock/read_unlock pair.



Make sure you bench both AMD and Intel - I'd expect it to be a big loss
on AMD because the AMD stuff will perform atomic locked operations very
efficiently if they are already exclusive on this CPU or a prefetch_w()
on them was done 200+ clocks before.



I will try to get numbers for both.

I would be surprised if it was a big loss... but I'm assuming
a locked cmpxchg isn't outlandishly expensive. Basically:

  read_lock_irqsave(cacheline1);
  atomic_inc_return(cacheline2);
  read_unlock_irqrestore(cacheline1);

Turns into

  atomic_cmpxchg();

I'll do some microbenchmarks and get back to you. I'm quite
interested now ;) What sort of AMDs did you have in mind,
Opterons?

Thanks,
Nick

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 


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

Re: advice

[YH]

Hello,

Apologize for off topic questions. While I am working on a device driver 
in kernel 2.4.21, I need advices from kernel developers.


1. When the read() or write() is called from user applications, the 
driver can either have a static buffer with limited size or dynamic 
memory allocation (kmalloc).


The static buffer is simple and reliable, but limited buffer size to 
applications.


Personally, I would like to use dynamic kernel memory allocation 
(kmalloc), the question is whether it could be any issues (reliability) 
to frequently call kmalloc / kfree in a high speed device (100mpbs)?


2. Although there is a mechanism for user applications to access the 
driver through function call read(), write(), or ioctl(). Can the 
application passes a callback pointer to the driver in kernel space so 
that the driver can call the callback function when some special event 
is received. Or if there is a mechanism to let the driver to send a 
notification to the user application?


Thank you and appreciate your helps.

Jim

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

nfs4 client bug

[Bret Towe]

i encountered the following error while using nfs4
ive hit this error i think twice now not sure what causes it yet tho
this time the only io related items going on was emerge sync running
in the background (which shouldnt of touched nfs at all) and xmms
playing some music

another problem i had was iowait was showing near 100% but nothing
over nfs was working
but no errors or anything was showing in dmesg if i encounter this
again is there a way to
find out where it locked up so i can give a report on what the problem is?

attached is my config the box is an athlon64
if any further information is needed let me know

Unable to handle kernel paging request at 00100108 RIP:
{generic_drop_inode+56}
PGD 27bec067 PUD 27be9067 PMD 0
Oops: 0002 [1]
CPU 0
Modules linked in: fglrx agpgart snd_seq_midi snd_emu10k1_synth
snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss
snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1
snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer
snd_page_alloc snd_util_mem snd_hwdep snd w83627hf i2c_sensor i2c_isa
i2c_core usb_storage r8169 ehci_hcd uhci_hcd dm_mirror dm_snapshot
dm_mod
Pid: 149, comm: kswapd0 Tainted: P   M  2.6.13
RIP: 0010:[] {generic_drop_inode+56}
RSP: 0018:81002f9d9b78  EFLAGS: 00010246
RAX: 00100100 RBX: 810022d4d950 RCX: 00200200
RDX: 810022d4d960 RSI: 81002ea21000 RDI: 810022d4d950
RBP: 810022d4d950 R08: fffa R09: 810022d4da68
R10: 0001 R11: 80189500 R12: 
R13: 810022d4d7d0 R14: 810022d4d860 R15: 81002c3cec00
FS:  2bc64f80() GS:805bc800() knlGS:
CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 00100108 CR3: 27468000 CR4: 06e0
Process kswapd0 (pid: 149, threadinfo 81002f9d8000, task 81002f9d2760)
Stack: 81002a65fa00 801e2925 00012f9d9bf8 81002f9d9c28
    81002f9d9c28 81002f9d9c10 810022d4d938
   0001 
Call Trace:{__nfs_revalidate_inode+261}
{find_get_pages_tag+31}
   {pagevec_lookup_tag+26}
{wait_on_page_writeback_range+206}
   {nfs_do_return_delegation+42}
{nfs_inode_return_delegation+197}
   {nfs4_clear_inode+32}
{clear_inode+158}
   {dispose_list+94}
{shrink_icache_memory+434}
   {shrink_slab+219} {balance_pgdat+617}
   {balance_pgdat+2} {kswapd+295}
   {autoremove_wake_function+0}
{autoremove_wake_function+0}
   {child_rip+8} {kswapd+0}
   {child_rip+0}

Code: 48 89 48 08 48 89 01 48 8b 05 8a 4e 30 00 48 89 50 08 48 89
RIP {generic_drop_inode+56} RSP 
CR2: 00100108
 --- [cut here ] - [please bite here ] -
Kernel BUG at "fs/inode.c":1142
invalid operand:  [2]
CPU 0
Modules linked in: fglrx agpgart snd_seq_midi snd_emu10k1_synth
snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss
snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1
snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer
snd_page_alloc snd_util_mem snd_hwdep snd w83627hf i2c_sensor i2c_isa
i2c_core usb_storage r8169 ehci_hcd uhci_hcd dm_mirror dm_snapshot
dm_mod
Pid: 9539, comm: rpciod/0 Tainted: P   M  2.6.13
RIP: 0010:[] {iput+30}
RSP: 0018:81002a181e08  EFLAGS: 00010246
RAX: 80494a00 RBX: 810023da8d40 RCX: 81002311f490
RDX: 810022919680 RSI: 81002614da40 RDI: 810023da8d40
RBP: 8100286af780 R08: 8100230f64e0 R09: 
R10: 0001 R11: 801f8c90 R12: 81002311f480
R13: 81002614da00 R14: 81002c3cec00 R15: 805c3fb0
FS:  2ade6b00() GS:805bc800() knlGS:
CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2ade0680 CR3: 22d19000 CR4: 06e0
Process rpciod/0 (pid: 9539, threadinfo 81002a18, task 81002a4a2330)
Stack: 81002311f480 801fb0fd fff3 81002fb0f1c0
   8100286af780 801efa51 81002fb0f1c0 81002d9be310
   81002fb0f2a8 81002d9be320
Call Trace:{nfs4_put_open_state+109}
{nfs4_close_done+225}
   {__rpc_execute+165}
{worker_thread+442}
   {default_wake_function+0}
{default_wake_function+0}
   {worker_thread+0} {kthread+205}
   {child_rip+8}
{keventd_create_kthread+0}
   {kthread+0} {child_rip+0}


Code: 0f 0b a3 e0 61 3c 80 ff ff ff ff c2 76 04 66 66 66 90 48 85
RIP {iput+30} RSP 


ghoststar-config
Description: Binary data

Re: IDE HPA

[Jeff Garzik]

Peter Jones wrote:

So where would you envision this code to check the partition table, the
HPA/host default disk size, and guess how things should be set up?


From a userland perspective, it's very difficult to let users know

they'll be screwing themselves by partitioning the entire disk, so we
really should be leaving HPA enabled if the protected area is indeed not
for consumption.

Also, the heuristic is harder than this -- if we reexamine the fakeraid
case, then it's clear we have to look for raid metadata, figure out if
the raid includes stuff inside the HPA or not, and then if it doesn't we
don't care -- but that's assuming there _is_ raid metadata.

Long term, many people hope, possibly unrealistically, that we'll be
able to write out raid metadata for people creating raids on cards which
support fakeraid, and have the BIOS grok it appropriately.  So in that
case, we may well have a blank (or garbage) disk, and we can't check the
partition table or any raid metadata.  Correct me if I'm wrong, but I
don't see a simple heuristic for this case.

(as a side note, I know one user who, at OLS, noticed we fail to
re-initialize HPA after unsuspend, so on at least t40 the disk gets
smaller when you suspend.  This may or may not be fixed, I haven't
checked.  But it's one more sort of pain we get into by disabling it,
whether justified or not.)


It seems to me that one should write an ATA-specific Device Mapper 
driver, which layers on top of an ATA disk.  The driver obtains the 
starting location of HPA, then exports two block devices:  one for the 
primary data area, and one for the HPA.


For situations where we want the start Linux philosophy -- Linux exports 
100% of the hardware capability -- no DM layer needs to be used.  For 
situations where its better to treat the HPA as a separate and distinct 
area, the DM driver would come in handy.


This follows the same philosophy as fakeraid (BIOS RAID):  we simply 
export the entire disk, and Device Mapper (google for 'dmraid') handles 
the vendor-proprietary RAID metadata.


Jeff


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

Brand-new notebook useless with Linux...

[Chuck Ebbert]

I just bought a new notebook.  Here is the output from lspci using the latest
pci.ids file from sourceforge:

00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 01)
00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 5a3f
00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller
00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller
00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller
00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 11)
00:14.1 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE 
Controller ATI
00:14.3 ISA bridge: ATI Technologies Inc IXP SB400 PCI-ISA Bridge
00:14.4 PCI bridge: ATI Technologies Inc IXP SB400 PCI-PCI Bridge
00:14.5 Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97 Audio 
Controller (rev 02)
00:14.6 Modem: ATI Technologies Inc: Unknown device 4378 (rev 02)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address 
Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM 
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 
5955 (PCIE)
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
05:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 
802.11g Wireless LAN Controller (rev 02)
05:09.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
05:09.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host 
Controller
05:09.3 Mass storage controller: Texas Instruments PCIxx21 Integrated 
FlashMedia Controller
05:09.4 Class 0805: Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621, 
PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD) Controller

None of these work and I can find no support anywhere for them:

SMBus
Audio ("unknown codec")
Modem ("no codec available")
Wireless
FlashMedia
SD/MMC

Additionally, the system clock runs at 2x normal speed with PowerNow enabled.

Am I stuck with running XP on this thing?

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

Re: 2.6.13-mm1: hangs during boot ...

[Peter Williams]

Brown, Len wrote:

Please then try the latest ACPI patch here:


> 


http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches
/release/2.6.13/acpi-20050902-2.6.13.diff.gz


> It should apply to vanilla 2.6.13 with a reject in ia64/Kconfig
> that you can ignore.
> 
> If this works, then we munged git-acpi.patch in 


2.6.13-mm1 somehow.

There were no problems with this patch applied.  So it 


looks like the 


munge theory is correct.


That diff is significantly different from the diff I plucked from
master.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
.git#test
for 2.6.13-mm1.

Doing (patch -R | grep FAILED) on 2.6.13-mm1 says:



Right.
2.6.13/acpi-20050902-2.6.13.diff.gz
is newers than 2.6.13-rc1's git-acpi.patch

2.6.13/acpi-20050815-2.6.13.diff.gz
is a closer match -- though not exact.

Peter, it might be illustrative if you have a moment
if you can also test 2.6.13/acpi-20050815-2.6.13.diff.gz
all by itself.

If it fails,


It does.


then I broke -mm1
with acpi-20050815-2.6.13.diff.gz, but fixed
it by acpi-20050902-2.6.13.diff.gz.


So you did.



If it succeeds, then the issue lies in the relatively small delta
between acpi-20050815-2.6.13.diff.gz 2.6.13-mm1's git-acpi.patch.

thanks,
-Len



My pleasure
Peter
--
Peter Williams   [EMAIL PROTECTED]

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

Re: [WATCHDOG] v2.6.13 watchdog-patches

[Chuck Ebbert]

In-Reply-To: <[EMAIL PROTECTED]>

On Sat, 03 Sep 2005 at 22:11:41 +0200, Arjan van de Ven wrote:

> this looks ENTIRELY like the wrong solution!
> Isn't it a LOT easier to just del_timer_sync() the timer from the module
> exit code?

 But we want to prevent module unload so the timer can fire properly.

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

Re: forbid to strace a program

[Chase Venters]

> Is there another way to do this? If the password is crypted, I need a
> passphrase or something other to decrypt it again. Not really a solution
> of the problem.
>
> Therefore, it would be best, to hide it by preventing stracing of the
> application to all users and root.
>
> Ok, root could search for the password directly in the memory, but this
> would be not as easy as a strace.

Obfuscation isn't really valid security. Making something 'harder' to break 
isn't a solution unless you're making it hard enough that current technology 
can't break it (eg... you always have the brute force option, but good crypto 
intends to make such an option impossible without expending zillions of clock 
cycles). 

Can I ask why you want to hide the database password from root?

Regards,
Chase Venters
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] New: Omnikey CardMan 4040 PCMCIA Driver

[Jesper Juhl]

On 9/4/05, Harald Welte <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
> > Hi!
> >
> > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> > Smartcard Reader.
> 
> Sorry, the patch was missing a "cg-add" of the header file.  Please use
> the patch below.

It would be so much nicer if the patch actually was "below" - that is
"inline in the email as opposed to as an attachment". Having to first
save an attachment and then cut'n'paste from it is a pain.

Anyway, a few comments below :

+#define DEBUG(n, x, args...) do { if (pc_debug >= (n)) 
\


line longer than 80 chars. Please adhere to CodingStyle and keep lines
<80 chars.
There's more than one occourance of this.

+static inline int cmx_waitForBulkOutReady(reader_dev_t *dev)


Why TheStudlyCaps ?  Please keep function names lowercase. There are
more instances of this, only pointing out one.

+register int i;

+   register int iobase = dev->link.io.BasePort1;


Please use only tabs for indentation (line 1 of the above is indented
with spaces).

+   for (i=0; i < POLL_LOOP_COUNT; i++) {


for (i = 0; i < POLL_LOOP_COUNT; i++) {

+if (rc != 1)


Again spaces used for indentation, please fix all that up to use tabs.

+   unsigned long ulBytesToRead;


lowercase prefered also for variables.

+   for (i=0; i<5; i++) {


for (i = 0; i < 5; i++) {

+   DEBUG(5,"cmx_waitForBulkInReady rc=%.2x\n",rc);


Space after ","s please : DEBUG(5, "cmx_waitForBulkInReady rc=%.2x\n", rc);

+   ulMin = (count < (ulBytesToRead+5))?count:(ulBytesToRead+5);


needs spaces : 
ulMin = (count < (ulBytesToRead + 5)) ? count : (ulBytesToRead + 5);

+   reader_dev_t *dev=(reader_dev_t *)filp->private_data;


reader_dev_t *dev = (reader_dev_t *)filp->private_data;


+static int cmx_open (struct inode *inode, struct file *filp)


get rid of the space before the opening paren : 
static int cmx_open(struct inode *inode, struct file *filp)


+   for (rc = pcmcia_get_first_tuple(handle, );

+rc == CS_SUCCESS;

+rc = pcmcia_get_next_tuple(handle, )) {

...
+   if (parse.cftable_entry.io.nwin) {

+   link->io.BasePort1 = parse.cftable_entry.io.win[0].base;

+   link->io.NumPorts1 = parse.cftable_entry.io.win[0].len;

+   link->io.Attributes1 = IO_DATA_PATH_WIDTH_AUTO;

+   if(!(parse.cftable_entry.io.flags & CISTPL_IO_8BIT))

+   link->io.Attributes1 = IO_DATA_PATH_WIDTH_16;

...
+   }
+   }

How about not having to indent so deep by rewriting that as

for (rc = pcmcia_get_first_tuple(handle, );
 rc == CS_SUCCESS;
 rc = pcmcia_get_next_tuple(handle, )) {
...
if (!parse.cftable_entry.io.nwin)
continue;

link->io.BasePort1 = parse.cftable_entry.io.win[0].base;
link->io.NumPorts1 = parse.cftable_entry.io.win[0].len;
link->io.Attributes1 = IO_DATA_PATH_WIDTH_AUTO;
if(!(parse.cftable_entry.io.flags & CISTPL_IO_8BIT))
link->io.Attributes1 = IO_DATA_PATH_WIDTH_16;
...
}


+link->conf.IntType = 0002;


more spaces used for indentation. Not going to point out any more of these.

+   cmx_poll_timer.function = _do_poll;


shouldn't this be 
 cmx_poll_timer.function = cmx_do_poll;
???

+   int i;

+   DEBUG(3, "-> reader_detach(link=%p\n", link);


please have a blank line between variable declarations and other statements.



-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: forbid to strace a program

[Andreas Hartmann]

Alex Riesen wrote:
> On 9/3/05, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
>> Hello!
>> 
>> Is it possible to prevent a program to be straced on x86?
>> What do I have to do, eg., to prevent a perl-program to be straced?
>> 
> 
> So that none can see what are you doing? Or because your program is
> breaking because of this? Probably nothing, but someone would like
> to know what it is you are doing and exactly how it breaks (and, if
> you don't mind -
> why it breaks).

That's not really the problem. I want to hide a clear text password in
that program (something like ssh-agent or gpg-agent; the last can be
straced, too :-() which I need for a database when the program runs.

Is there another way to do this? If the password is crypted, I need a
passphrase or something other to decrypt it again. Not really a solution
of the problem.

Therefore, it would be best, to hide it by preventing stracing of the
application to all users and root.

Ok, root could search for the password directly in the memory, but this
would be not as easy as a strace.



Kind regards,
Andreas Hartmann
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] New: Omnikey CardMan 4040 PCMCIA Driver

[Chase Venters]

> Um, 100/100 = 1, not 0?

Oh my... it's been a long day. 

Regards,
Chase Venters
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-cluster] Re: GFS, what's remaining

[Daniel Phillips]

On Saturday 03 September 2005 02:46, Wim Coekaerts wrote:
> On Sat, Sep 03, 2005 at 02:42:36AM -0400, Daniel Phillips wrote:
> > On Friday 02 September 2005 20:16, Mark Fasheh wrote:
> > > As far as userspace dlm apis go, dlmfs already abstracts away a large
> > > part of the dlm interaction...
> >
> > Dumb question, why can't you use sysfs for this instead of rolling your
> > own?
>
> because it's totally different. have a look at what it does.

You create a dlm domain when a directory is created.  You create a lock 
resource when a file of that name is opened.  You lock the resource when the 
file is opened.  You access the lvb by read/writing the file.  Why doesn't 
that fit the configfs-nee-sysfs model?  If it does, the payoff will be about 
500 lines saved.

This little dlm fs is very slick, but grossly inefficient.  Maybe efficiency 
doesn't matter here since it is just your slow-path userspace tools taking 
these locks.  Please do not even think of proposing this as a way to export a 
kernel-based dlm for general purpose use!

Your userdlm.c file has some hidden gold in it.  You have factored the dlm 
calls far more attractively than the bad old bazillion-parameter Vaxcluster 
legacy.  You are almost in system call zone there.  (But note my earlier 
comment on dlms in general: until there are dlm-based applications, merging a 
general-purpose dlm API is pointless and has nothing to do with getting your 
filesystem merged.)

Regards,

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

Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver

[Nish Aravamudan]

On 9/3/05, Chase Venters <[EMAIL PROTECTED]> wrote:
> > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> > Smartcard Reader.
> 
> Someone correct me if I'm wrong, but wouldn't these #defines be a problem 
> with the new HZ flexibility:
> 
> #define CCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ)
> #define CCID_DRIVER_ASYNC_POWERUP_TIMEOUT   (35*HZ)
> #define CCID_DRIVER_MINIMUM_TIMEOUT (3*HZ)
> #define READ_WRITE_BUFFER_SIZE 512
> #define POLL_LOOP_COUNT 1000

These are all fine. Although I am a bit suspicious of 150 second
timeouts; but if that is the hardware...

> /* how often to poll for fifo status change */
> #define POLL_PERIOD (HZ/100)

This needs to be msecs_to_jiffies(10), please.

> In particular, 2.6.13 allows a HZ of 100, which would define POLL_PERIOD to 0.

Um, 100/100 = 1, not 0?

> Your later calls to mod_timer would be setting cmx_poll_timer to the current
> value of jiffies.

Which is technically ok, because HZ=100, a
 jiffies + 0
or
 jiffies + 1
timeout request will both result in the soft-timer being expired at
the *next* timer interrupt. Regardless, you're right, and
msecs_to_jiffies() will cover it.

> Also, you've got a typo in the comments:
> 
> *   - adhere to linux kenrel coding style and policies
> 
> Forgive me if I'm way off - I'm just now getting my feet wet in kernel
> development. Just making comments based on what I (think) I know at this
> point.

Of bigger concern to me is the use of the sleep_on() family of
functions, all of which are deprecated.

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

Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver

[Alexey Dobriyan]

On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
> Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> Smartcard Reader.  

> --- /dev/null
> +++ b/drivers/char/pcmcia/cm4040_cs.c

> +#include 

Not needed.

> +static volatile char *version =

Can we lose all volatile and register keywords?

> +typedef struct reader_dev_t {
> + dev_link_t  link;   
> + dev_node_t  node;   
> + wait_queue_head_t   devq;   
> +
> + wait_queue_head_t   poll_wait;
> + wait_queue_head_t   read_wait;
> + wait_queue_head_t   write_wait;
> +
> + unsigned intbuffer_status;
> +
> + unsigned intfTimerExpired;
> + struct timer_list   timer;
> + unsigned long   timeout;
> + unsigned char   sBuf[READ_WRITE_BUFFER_SIZE];
> + unsigned char   rBuf[READ_WRITE_BUFFER_SIZE];
> + struct task_struct  *owner; 
> +} reader_dev_t;

And typedefs too.

struct reader_dev {

};

> +static ssize_t cmx_read(struct file *filp,char *buf,size_t count,loff_t 
> *ppos)

char __user *buf

> + ulBytesToRead = 5 + 
> + (0x00FF&((char)dev->rBuf[1])) + 
> + (0xFF00&((char)dev->rBuf[2] << 8)) + 
> + (0x00FF&((char)dev->rBuf[3] << 16)) + 
> + (0xFF00&((char)dev->rBuf[4] << 24));

ulBytesToRead = 5 + le32_to_cpu(*(__le32 *)>rBuf[1]);

> + ulMin = (count < (ulBytesToRead+5))?count:(ulBytesToRead+5);

ulMin = min(count, ulBytesToRead + 5);

> + copy_to_user(buf, dev->rBuf, ulMin);

Can fail.

> +static ssize_t cmx_write(struct file *filp,const char *buf,size_t count,

const char __user *buf

> +  loff_t *ppos)

> + copy_from_user(dev->sBuf, buf, uiBytesToWrite);

Can fail.

> +static int cmx_ioctl(struct inode *inode,struct file *filp,unsigned int cmd,
> + unsigned long arg)
> +{
> + dev_link_t *link;
> + int rc, size;
> +
> + link=dev_table[MINOR(inode->i_rdev)];
> + if (!(DEV_OK(link))) {
> + DEBUG(4, "DEV_OK false\n");
> + return -ENODEV;
> + }
> + if (_IOC_TYPE(cmd)!=CM_IOC_MAGIC) {
> + DEBUG(4,"ioctype mismatch\n");
> + return -EINVAL;
> + }
> + if (_IOC_NR(cmd)>CM_IOC_MAXNR) {
> + DEBUG(4,"iocnr mismatch\n");
> + return -EINVAL;
> + } 
> + size = _IOC_SIZE(cmd);
> + rc = 0;
> + DEBUG(4,"iocdir=%.4x iocr=%.4x iocw=%.4x iocsize=%d cmd=%.4x\n",
> + _IOC_DIR(cmd),_IOC_READ,_IOC_WRITE,size,cmd);
> +
> + if (_IOC_DIR(cmd)&_IOC_READ) {
> + if (!access_ok(VERIFY_WRITE, (void *)arg, size))
> + return -EFAULT;
> + }
> + if (_IOC_DIR(cmd)&_IOC_WRITE) {
> + if (!access_ok(VERIFY_READ, (void *)arg, size))
> + return -EFAULT;
> + }
> +
> + return rc;
> +}

Whoo, empty ioctl handler.

> +static void reader_release(u_long arg)

> + link = (dev_link_t *)arg;

You do

reader_release((unsigned long)link);

somewhere above and below.

> +static void reader_detach_by_devno(int devno,dev_link_t *link)

> + reader_release((u_long)link);

Like this.

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

Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver

[Harald Welte]

On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
> Hi!
> 
> Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> Smartcard Reader.  

Sorry, the patch was missing a "cg-add" of the header file.  Please use
the patch below.
-- 
- Harald Welte <[EMAIL PROTECTED]>  http://gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)
Add Omnikey CardMan 4040 Driver

Signed-off-by: Harald Welte <[EMAIL PROTECTED]>

---
commit 0e760a5785ebb83b932d104679cc2b2b4070b1c1
tree 46d71d0c6b41b441a1a8d725b741450f1334296e
parent c4ab879b6ef599bf88d19b9b145878ef73400ce7
author Harald Welte <[EMAIL PROTECTED]> So, 04 Sep 2005 13:05:44 +0200
committer Harald Welte <[EMAIL PROTECTED]> So, 04 Sep 2005 13:05:44 +0200

 MAINTAINERS |5 
 drivers/char/pcmcia/Kconfig |   13 +
 drivers/char/pcmcia/Makefile|1 
 drivers/char/pcmcia/cm4040_cs.c |  900 +++
 drivers/char/pcmcia/cm4040_cs.h |   52 ++
 5 files changed, 971 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1737,6 +1737,11 @@ L:   [EMAIL PROTECTED]
 W: http://www.linuxtr.net
 S: Maintained
 
+OMNIKEY CARDMAN 4040 DRIVER
+P: Harald Welte
+M: [EMAIL PROTECTED]
+S: Maintained
+
 ONSTREAM SCSI TAPE DRIVER
 P: Willem Riede
 M: [EMAIL PROTECTED]
diff --git a/drivers/char/pcmcia/Kconfig b/drivers/char/pcmcia/Kconfig
--- a/drivers/char/pcmcia/Kconfig
+++ b/drivers/char/pcmcia/Kconfig
@@ -18,5 +18,18 @@ config SYNCLINK_CS
  The module will be called synclinkmp.  If you want to do that, say M
  here.
 
+config CARDMAN_4040
+   tristate "Omnikey CardMan 4040 support"
+   depends on PCMCIA
+   help
+ Enable support for the Omnikey CardMan 4040 PCMCIA Smartcard
+ reader.
+ 
+ This card is basically a USB CCID device connected to a FIFO
+ in I/O space.  To use the kernel driver, you will need either the
+ PC/SC ifdhandler provided from the Omnikey homepage
+ (http://www.omnikey.com/), or a current development version of OpenCT
+ (http://www.opensc.org/).
+
 endmenu
 
diff --git a/drivers/char/pcmcia/Makefile b/drivers/char/pcmcia/Makefile
--- a/drivers/char/pcmcia/Makefile
+++ b/drivers/char/pcmcia/Makefile
@@ -5,3 +5,4 @@
 #
 
 obj-$(CONFIG_SYNCLINK_CS) += synclink_cs.o
+obj-$(CONFIG_CARDMAN_4040) += cm4040_cs.o
diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c
new file mode 100644
--- /dev/null
+++ b/drivers/char/pcmcia/cm4040_cs.c
@@ -0,0 +1,900 @@
+ /*
+ * A driver for the Omnikey PCMCIA smartcard reader CardMan 4040
+ *
+ * (c) 2000-2004 Omnikey AG (http://www.omnikey.com/)
+ *
+ * (C) 2005 Harald Welte <[EMAIL PROTECTED]>
+ * - add support for poll()
+ * - driver cleanup
+ * - add waitqueues
+ * - adhere to linux kenrel coding style and policies
+ * - support 2.6.13 "new style" pcmcia interface
+ *
+ * All rights reserved, Dual BSD/GPL Licensed.
+ */
+
+/* #define PCMCIA_DEBUG 6 */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cm4040_cs.h"
+
+static atomic_t cmx_num_devices_open;
+
+#ifdef PCMCIA_DEBUG
+static int pc_debug = PCMCIA_DEBUG;
+module_param(pc_debug, int, 0600);
+#define DEBUG(n, x, args...) do { if (pc_debug >= (n)) 
\
+ printk(KERN_DEBUG "%s:%s:" x, MODULE_NAME, \
+__FUNCTION__, ##args); } while (0)
+#else
+#define DEBUG(n, args...)
+#endif
+
+static volatile char *version =
+"OMNIKEY CardMan 4040 v1.1.0gm3 - All bugs added by Harald Welte";
+
+#defineCCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ)
+#defineCCID_DRIVER_ASYNC_POWERUP_TIMEOUT   (35*HZ)
+#defineCCID_DRIVER_MINIMUM_TIMEOUT (3*HZ)
+#define READ_WRITE_BUFFER_SIZE 512
+#define POLL_LOOP_COUNT1000
+
+/* how often to poll for fifo status change */
+#define POLL_PERIOD(HZ/100)
+
+static void reader_release(u_long arg);
+static void reader_detach(dev_link_t *link);
+
+static int major;  
+
+#defineBS_READABLE 0x01
+#defineBS_WRITABLE 0x02
+
+typedef struct reader_dev_t {
+   dev_link_t  link;   
+   dev_node_t  node;   
+   wait_queue_head_t   devq;   
+
+   wait_queue_head_t   poll_wait;
+   wait_queue_head_t   read_wait;
+   wait_queue_head_t   write_wait;
+
+   unsigned intbuffer_status;
+  

Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver

[Chase Venters]

> Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> Smartcard Reader.

Someone correct me if I'm wrong, but wouldn't these #defines be a problem with 
the new HZ flexibility:

#define CCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ)
#define CCID_DRIVER_ASYNC_POWERUP_TIMEOUT   (35*HZ)
#define CCID_DRIVER_MINIMUM_TIMEOUT (3*HZ)
#define READ_WRITE_BUFFER_SIZE 512
#define POLL_LOOP_COUNT 1000

/* how often to poll for fifo status change */
#define POLL_PERIOD (HZ/100)

In particular, 2.6.13 allows a HZ of 100, which would define POLL_PERIOD to 0. 
Your later calls to mod_timer would be setting cmx_poll_timer to the current 
value of jiffies. 

Also, you've got a typo in the comments:

*   - adhere to linux kenrel coding style and policies

Forgive me if I'm way off - I'm just now getting my feet wet in kernel 
development. Just making comments based on what I (think) I know at this 
point.

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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>> The Linux kernel allows binary drivers, you just have to live with a limited
>> number of exported symbols and that the kernel is tainted. Which basically
>> means nobody sane can help you with corrupted kernel data structures.
> 
> You appear to be confused. The exported symbols are part of a GPL
> product. The only question of relevance is whether the item is a derived
> work in law or not. 

I dont understand that? Can you point out where I am confused?

Loading a non-GPL (tagged) module leads in tainting the kernel (which basically
is a flag for developers to be alerted while debugging), is that right?

Non GPL Modules are also restrited in the number of symbols they can use,
this is to make it harder to derive work from the Linux Kernel with a ABI
interface.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] New: Omnikey CardMan 4040 PCMCIA Driver

[Harald Welte]

Hi!

Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
Smartcard Reader.  

It's based on some source code originally made available by the vendor
(as BSD/GPL dual licensed code), but has undergone significant changes
to make it more compliant with the general kernel community coding
practise.

As this is the first PCMCIA driver that I'm involved in, please let me
know if I missed something.

If there are no objections, I'd like to see it included in mainline.
Thanks!

-- 
- Harald Welte <[EMAIL PROTECTED]>  http://gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)
Omnikey CardMan 4040 PCMCIA Smartcard reader driver

Signed-off-by: Harald Welte <[EMAIL PROTECTED]>

---
commit 04ec3ca3e3c6fd6d88c508b6ebe32726ef109367
tree e27a5ccafbcebda6ebfe90036016f0e76dd93137
parent c4ab879b6ef599bf88d19b9b145878ef73400ce7
author Harald Welte <[EMAIL PROTECTED]> So, 04 Sep 2005 11:59:37 +0200
committer Harald Welte <[EMAIL PROTECTED]> So, 04 Sep 2005 11:59:37 +0200

 MAINTAINERS |5 
 drivers/char/pcmcia/Kconfig |   13 +
 drivers/char/pcmcia/Makefile|1 
 drivers/char/pcmcia/cm4040_cs.c |  900 +++
 4 files changed, 919 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1737,6 +1737,11 @@ L:   [EMAIL PROTECTED]
 W: http://www.linuxtr.net
 S: Maintained
 
+OMNIKEY CARDMAN 4040 DRIVER
+P: Harald Welte
+M: [EMAIL PROTECTED]
+S: Maintained
+
 ONSTREAM SCSI TAPE DRIVER
 P: Willem Riede
 M: [EMAIL PROTECTED]
diff --git a/drivers/char/pcmcia/Kconfig b/drivers/char/pcmcia/Kconfig
--- a/drivers/char/pcmcia/Kconfig
+++ b/drivers/char/pcmcia/Kconfig
@@ -18,5 +18,18 @@ config SYNCLINK_CS
  The module will be called synclinkmp.  If you want to do that, say M
  here.
 
+config CARDMAN_4040
+   tristate "Omnikey CardMan 4040 support"
+   depends on PCMCIA
+   help
+ Enable support for the Omnikey CardMan 4040 PCMCIA Smartcard
+ reader.
+ 
+ This card is basically a USB CCID device connected to a FIFO
+ in I/O space.  To use the kernel driver, you will need either the
+ PC/SC ifdhandler provided from the Omnikey homepage
+ (http://www.omnikey.com/), or a current development version of OpenCT
+ (http://www.opensc.org/).
+
 endmenu
 
diff --git a/drivers/char/pcmcia/Makefile b/drivers/char/pcmcia/Makefile
--- a/drivers/char/pcmcia/Makefile
+++ b/drivers/char/pcmcia/Makefile
@@ -5,3 +5,4 @@
 #
 
 obj-$(CONFIG_SYNCLINK_CS) += synclink_cs.o
+obj-$(CONFIG_CARDMAN_4040) += cm4040_cs.o
diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c
new file mode 100644
--- /dev/null
+++ b/drivers/char/pcmcia/cm4040_cs.c
@@ -0,0 +1,900 @@
+ /*
+ * A driver for the Omnikey PCMCIA smartcard reader CardMan 4040
+ *
+ * (c) 2000-2004 Omnikey AG (http://www.omnikey.com/)
+ *
+ * (C) 2005 Harald Welte <[EMAIL PROTECTED]>
+ * - add support for poll()
+ * - driver cleanup
+ * - add waitqueues
+ * - adhere to linux kenrel coding style and policies
+ * - support 2.6.13 "new style" pcmcia interface
+ *
+ * All rights reserved, Dual BSD/GPL Licensed.
+ */
+
+/* #define PCMCIA_DEBUG 6 */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cm4040_cs.h"
+
+static atomic_t cmx_num_devices_open;
+
+#ifdef PCMCIA_DEBUG
+static int pc_debug = PCMCIA_DEBUG;
+module_param(pc_debug, int, 0600);
+#define DEBUG(n, x, args...) do { if (pc_debug >= (n)) 
\
+ printk(KERN_DEBUG "%s:%s:" x, MODULE_NAME, \
+__FUNCTION__, ##args); } while (0)
+#else
+#define DEBUG(n, args...)
+#endif
+
+static volatile char *version =
+"OMNIKEY CardMan 4040 v1.1.0gm3 - All bugs added by Harald Welte";
+
+#defineCCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ)
+#defineCCID_DRIVER_ASYNC_POWERUP_TIMEOUT   (35*HZ)
+#defineCCID_DRIVER_MINIMUM_TIMEOUT (3*HZ)
+#define READ_WRITE_BUFFER_SIZE 512
+#define POLL_LOOP_COUNT1000
+
+/* how often to poll for fifo status change */
+#define POLL_PERIOD(HZ/100)
+
+static void reader_release(u_long arg);
+static void reader_detach(dev_link_t *link);
+
+static int major;  
+
+#defineBS_READABLE 0x01
+#defineBS_WRITABLE 0x02
+
+typedef struct reader_dev_t {
+   dev_link_t  link;   
+   dev_node_t  node;   
+   

Potential IPSec DoS/Kernel Panic with 2.6.13

[Matt LaPlante]

I've found what I believe is a potential DoS condition in IPSec using Debian
but I need help isolating the culprit.  First my system:
Debian 3.1 stable with all updates as of 9/2. 
Custom Linux kernel 2.6.13 (no patches)
IPTables 1.3.3 (no patches)
Shorewall 2.4.3

I use my system as a multipurpose firewall/DHCP/DNS gateway on my broadband
home connection.  I have another system with the same specs on a remote
network. 
Just recently I installed the racoon debian package on both machines and
established an IPSec VPN tunnel between the two routers.  All has worked
generally as expected and I have connectivity between my local and remote
LAN while having regular internet service running alongside.  Here is my
racoon-tool
config:
#
# Configuration file for racoon-tool
#
# See racoon-tool.conf(5) for details
#

global:
log: notify

connection(test):
src_range: 192.168.4.0/24
dst_range: 192.168.1.0/24
src_ip: A.B.C.D
dst_ip: W.X.Y.Z
authentication_algorithm: hmac_sha1
admin_status: yes

peer(A.B.C.D):
passive: off
verify_identifier: on
lifetime: time 30 min
hash_algorithm[0]: sha1
encryption_algorithm[0]: aes
my_identifier: address A.B.C.D
peers_identifier: address W.X.Y.Z 

Now with this config, I can ping the remote LAN from my Win XP machine
successfully using "ping -t -l 1024 192.168.1.2".

I was just randomly messing around with some settings when I ran the
following:
"ping -t -l 2048 192.168.1.2"

Now I'm well aware that this command won't likely succeed due to the
excessive size of the packet (2048 bytes).  What I wasn't expecting was that
I would be totally and completely unable to access my router via SSH or have
any internet connectivity.  Yes, the oversize ping packet took down all the
network connectivity on my router.  Upon further inspection I noticed the
packet had actually caused a kernel panic (visible only on the monitor, now
also unresponsive).

I shut down with a hard power down, rebooted, and tried again...with the
dead same result.  This oversize ping packet seems to repeatedly crash the
system. 

I tried while booting the current Debian stock kernel (2.6.8-2-686), and
this problem was NOT present.  I think due to this, it is unlikely related
to any supporting software on my system.

I'm not sure where to proceed from here.  I'd be glad to send in the kernel
traces, but I don't know how to capture them...they aren't being logged
anywhere that I can find, so I need to know how to capture them and submit
them if they're necessary.

I want to emphasize that this is somehow related to IPSec, as I tested the
exact same command but substituted www.google.com for my remote LAN IP
address and there were NO crashes/problems whatsoever.

This bug seems to be a high threat because:
-It occurs reproducibly.
-It occurs in the latest kernel with *no* patches.
-It did not occur with a previous kernel.
-It causes a complete system failure.
-It is extremely simple to exploit.

I will gladly provide more details upon request.  I'm not experienced enough
at the low level system aspects to provide detailed debugging info from
scratch, but I do have extensive experience with administering these systems
so I can give any information necessary with a little guidance.

Note: I'm trying posting this under a 2nd email address.  I tried posting
with my subscribed email address, but the post has not appeared on the list
in 24 hours, even though I'm receiving posts normally.  If it results in
double posts I apologize.

-
Matt LaPlante

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

Re: GFS, what's remaining

[Daniel Phillips]

On Saturday 03 September 2005 06:35, David Teigland wrote:
> Just a new version, not a big difference.  The ondisk format changed a
> little making it incompatible with the previous versions.  We'd been
> holding out on the format change for a long time and thought now would be
> a sensible time to finally do it.

What exactly was the format change, and for what purpose?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: forbid to strace a program

[Alex Riesen]

On 9/3/05, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> Hello!
> 
> Is it possible to prevent a program to be straced on x86?
> What do I have to do, eg., to prevent a perl-program to be straced?
> 

So that none can see what are you doing? Or because your program is
breaking because of this? Probably nothing, but someone would like
to know what it is you are doing and exactly how it breaks (and, if
you don't mind -
why it breaks).

Actuall, you can prevent a program of being straced (or debugged, for
that matter):
run it as another user. Root still can strace anything, though.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Mail System Error - Returned Mail

[The Post Office]

ALERT!

This e-mail, in its original form, contained one or more attached files that 
were infected with a virus, worm, or other type of security threat. This e-mail 
was sent from a Road Runner IP address. As part of our continuing initiative to 
stop the spread of malicious viruses, Road Runner scans all outbound e-mail 
attachments. If a virus, worm, or other security threat is found, Road Runner 
cleans or deletes the infected attachments as necessary, but continues to send 
the original message content to the recipient. Further information on this 
initiative can be found at http://help.rr.com/faqs/e_mgsp.html.
Please be advised that Road Runner does not contact the original sender of the 
e-mail as part of the scanning process. Road Runner recommends that if the 
sender is known to you, you contact them directly and advise them of their 
issue. If you do not know the sender, we advise you to forward this message in 
its entirety (including full headers) to the Road Runner Abuse Department, at 
[EMAIL PROTECTED]

The message was undeliverable due to the following reason:

Your message could not be delivered because the destination computer was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message could not be delivered within 4 days:
Mail server 26.93.33.40 is not responding.

The following recipients could not receive this message:


Please reply to [EMAIL PROTECTED]
if you feel this message to be in error.

file attachment: instruction.zip

This e-mail in its original form contained one or more attached files that were 
infected with the [EMAIL PROTECTED] virus or worm. They have been removed.
For more information on Road Runner's virus filtering initiative, visit our 
Help & Member Services pages at http://help.rr.com, or the virus filtering 
information page directly at http://help.rr.com/faqs/e_mgsp.html. 

Re: 2.6.13-mm1

[Andrew Morton]

Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote:
> > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Andrew,
> > > 
> > > it seems you dropped 
> > > schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's 
> > > zero mentioning of this dropping in the changelog of 2.6.13-mm1.
> > > 
> > > Can you explain why you did silently drop it?
> > 
> > It spat rejects and when I looked at the putative removal date I just
> > didn't believe it anyway.  Send a rediffed one if you like, but
> > October 2005 is unrealistic.
> 
> That the date is no longer realistic is clear. What disappoints me is 
> that you didn't mention in the changelog of 2.6.13-mm1 where I'd have 
> noticed it.

Sometimes I can't be bothered getting into email threads over relatively
unimportant stuff.  Usually it's related to the number of bugs we have.

> It semms I need my own bookkeeping of patches I sent that are in -mm to 
> notice when they get lost.

This is called "quilt".

> The only positive side effect of this is that 
> I can use this to push you harder to forward some patches of me to Linus 
> that stay unforwarded in -mm for several months...

A single release cycle is 2-3 months.

I'll probably be dropping some of the patches which unexport symbols, btw. 
ANy ones which aren't really, really obvious.  We have a process for 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: [WATCHDOG] v2.6.13 watchdog-patches

[Arjan van de Ven]

On Sat, 2005-09-03 at 22:04 +0200, Wim Van Sebroeck wrote:
> Author: Chuck Ebbert <[EMAIL PROTECTED]>
> Date:   Fri Aug 19 14:14:07 2005 +0200
> 
> [WATCHDOG] softdog-timer-running-oops.patch
> 
> The softdog watchdog timer has a bug that can create an oops:
> 
> 1.  Load the module without the nowayout option.
> 2.  Open the driver and close it without writing 'V' before close.
> 3.  Unload the module.  The timer will continue to run...
> 4.  Oops happens when timer fires.
> 
> Reported Sun, 10 Oct 2004, by Michael Schierl <[EMAIL PROTECTED]>
> 
> Fix is easy: always take a reference on the module on open.
> Release it only when the device is closed and no timer is running.
> Tested on 2.6.13-rc6 using the soft_noboot option.  While the
> timer is running and the device is closed, the module use count
> stays at 1.  After the timer fires, it drops to 0.  Repeatedly
> opening and closing the driver caused no problems.  Please apply.


this looks ENTIRELY like the wrong solution!
Isn't it a LOT easier to just del_timer_sync() the timer from the module
exit code? Mucking with module refcounts in a driver is almost always a
sign of a bug or at least really bad design, and I think that is the
case here.


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

[WATCHDOG] v2.6.13 watchdog-patches

[Wim Van Sebroeck]

Hi Linus,

please do a

git pull 
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git

This will update the following files:

 drivers/char/watchdog/Kconfig|   43 -
 drivers/char/watchdog/Makefile   |   71 +++-
 drivers/char/watchdog/ixp2000_wdt.c  |2 
 drivers/char/watchdog/ixp4xx_wdt.c   |2 
 drivers/char/watchdog/s3c2410_wdt.c  |   87 ++-
 drivers/char/watchdog/scx200_wdt.c   |2 
 drivers/char/watchdog/softdog.c  |   13 +++--
 drivers/char/watchdog/w83627hf_wdt.c |6 ++
 8 files changed, 143 insertions(+), 83 deletions(-)

with these Changes:

Author: Chuck Ebbert <[EMAIL PROTECTED]>
Date:   Fri Aug 19 14:14:07 2005 +0200

[WATCHDOG] softdog-timer-running-oops.patch

The softdog watchdog timer has a bug that can create an oops:

1.  Load the module without the nowayout option.
2.  Open the driver and close it without writing 'V' before close.
3.  Unload the module.  The timer will continue to run...
4.  Oops happens when timer fires.

Reported Sun, 10 Oct 2004, by Michael Schierl <[EMAIL PROTECTED]>

Fix is easy: always take a reference on the module on open.
Release it only when the device is closed and no timer is running.
Tested on 2.6.13-rc6 using the soft_noboot option.  While the
timer is running and the device is closed, the module use count
stays at 1.  After the timer fires, it drops to 0.  Repeatedly
opening and closing the driver caused no problems.  Please apply.

Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Wim Van Sebroeck <[EMAIL PROTECTED]>

Author: [EMAIL PROTECTED] Brady <[EMAIL PROTECTED]>
Date:   Wed Aug 17 09:06:07 2005 +0200

[WATCHDOG] w83627hf_wdt.c-initialized_bios_bug

Attached is a small update to the w83627hf watchdog driver
to initialise appropriately if it was already initialised
in the BIOS. On tyan motherboards for e.g. you can init
the watchdog to 4 mins, then when the driver is loaded it
sets the watchdog to "seconds" mode, and then machine will
reboot within 4 seconds. So this patch resets the timeout
to the configured value if the watchdog is already running.

Signed-off-by: [EMAIL PROTECTED] Brady <[EMAIL PROTECTED]>
Signed-off-by: Wim Van Sebroeck <[EMAIL PROTECTED]>

Author: Ben Dooks <[EMAIL PROTECTED]>
Date:   Wed Aug 17 09:04:52 2005 +0200

[WATCHDOG] s3c2410 watchdog - replace reboot notifier

Patch from Dimitry Andric <[EMAIL PROTECTED]>

Change to using platfrom driver's .shutdown method instead
of an reboot notifier

Signed-off-by: Dimitry Andric <[EMAIL PROTECTED]>
Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>
Signed-off-by: Wim Van Sebroeck <[EMAIL PROTECTED]>

Author: Ben Dooks <[EMAIL PROTECTED]>
Date:   Wed Aug 17 09:03:23 2005 +0200

[WATCHDOG] s3c2410 watchdog power management

Patch from Dimitry Andric <[EMAIL PROTECTED]>, updated
by Ben Dooks <[EMAIL PROTECTED]>. Patch is against 2.6.11-mm2

Add power management support to the s3c2410 watchdog, so that
it is shut-down over suspend, and re-initialised on resume.

Also add Dimitry to the list of authors.

Signed-off-by: Dimitry Andric <[EMAIL PROTECTED]>
Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>
Signed-off-by: Wim Van Sebroeck <[EMAIL PROTECTED]>

Author: Olaf Hering <[EMAIL PROTECTED]>
Date:   Wed Aug 17 08:58:34 2005 +0200

[WATCHDOG] correct sysfs name for watchdog devices

While looking for possible candidates for our udev.rules package,
I found a few odd ->name properties. /dev/watchdog has minor 130
according to devices.txt. Since all watchdog drivers use the
misc_register() call, they will end up in /sys/class/misc/$foo.
udev may create the /dev/watchdog node if the driver is loaded.
I dont have such a device, so I cant test it.
The drivers below provide names with spaces and even with / in it.
Not a big deal, but apps may expect /dev/watchdog.

Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
Signed-off-by: Wim Van Sebroeck <[EMAIL PROTECTED]>

Author: Wim Van Sebroeck <[EMAIL PROTECTED]>
Date:   Sat Sep 3 13:46:56 2005 +0200

[WATCHDOG] Kconfig+Makefile-clean

Clean the Kconfig+Makefile according to a sorted list
of the drivers of each architecture (and sub-architecture).

Signed-off-by: Wim Van Sebroeck <[EMAIL PROTECTED]>

Author: Wim Van Sebroeck <[EMAIL PROTECTED]>
Date:   Wed Aug 17 01:49:24 2005 +0200

[WATCHDOG] Makefile-probe_order-patch

Re-arrange Makefile according to what we want to probe first.

Signed-off-by: Wim Van Sebroeck <[EMAIL PROTECTED]>


The Changes can also be looked at on:

http://www.kernel.org/git/?p=linux/kernel/git/wim/linux-2.6-watchdog.git;a=summary

For completeness, I added the overal diff 

Re: 2.6.13-mm1

[Adrian Bunk]

On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote:
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > Hi Andrew,
> > 
> > it seems you dropped 
> > schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's 
> > zero mentioning of this dropping in the changelog of 2.6.13-mm1.
> > 
> > Can you explain why you did silently drop it?
> 
> It spat rejects and when I looked at the putative removal date I just
> didn't believe it anyway.  Send a rediffed one if you like, but
> October 2005 is unrealistic.

That the date is no longer realistic is clear. What disappoints me is 
that you didn't mention in the changelog of 2.6.13-mm1 where I'd have 
noticed it.

It semms I need my own bookkeeping of patches I sent that are in -mm to 
notice when they get lost. The only positive side effect of this is that 
I can use this to push you harder to forward some patches of me to Linus 
that stay unforwarded in -mm for several months...

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.13-mm1

[Andrew Morton]

Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> Hi Andrew,
> 
> it seems you dropped 
> schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's 
> zero mentioning of this dropping in the changelog of 2.6.13-mm1.
> 
> Can you explain why you did silently drop it?
> 

It spat rejects and when I looked at the putative removal date I just
didn't believe it anyway.  Send a rediffed one if you like, but
October 2005 is unrealistic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] pci: Block config access during BIST (resend)

[Grant Grundler]

On Sat, Sep 03, 2005 at 06:37:52PM -0500, Brian King wrote:
...
> Without the locking, we introduce a race condition.
> 
> CPU 0   CPU 1
> 
>   pci_block_user_cfg_access
>   pci_save_state
> pci_read_user_config_space
>   check block_ucfg_access
>   set block_ucfg_access
>   other code that puts the device
>   in a state such that it cannot
>   handle read config i/o, such as
>   running BIST.
> 
>   pci read config

Ok this is good example - I see what the problem is.
You could use the following sequence too then:
pci_block_user_cfg_access
pci_save_state
block_ucfg_access = 1
mb()
while (spin_is_locked(_lock))
relax_cpu();

Think this is sufficient?

> Granted, for the specific usage scenario in ipr, where I am using this 
> to block config space over BIST, I use a pci config write to start BIST, 
> which would end up being a point of synchronization, but that seems a 
> bit non-obvious and limits how the patch can be used by others...

Yes, agreed.

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

Re: [PATCH] 2.6.13: Filesystem capabilities 0.16

[Olaf Dietsche]

[EMAIL PROTECTED] writes:

> Or, has there been any communication between yourself and
> Nicholas Hans Simmonds, who posted his xattr-based fscaps
> patch in july (first posting july 2)?

Short answer: no. I'm just keeping this patch up to date for myself
and those interested (if any ;-).

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

Re: [PATCH] 2.6.13: Filesystem capabilities 0.16

[Olaf Dietsche]

Nix <[EMAIL PROTECTED]> writes:

> On 1 Sep 2005, Olaf Dietsche murmured woefully:
>> This patch implements filesystem capabilities. It allows to run
>> privileged executables without the need for suid root.
>
> Is there some reason why this doesn't keep its capability data in
> xattrs?

When I started fscaps, xattr were new to me and I didn't understand
how to use them. So, I went and made a small and independent patch.

If you're interested in an xattr based approach, you may look at
, which is
very old or at , which is
a more recent implementation.

As serge pointed out, there's a third from Nicholas Hans Simmonds.

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

Re: Request for review

[Patrizio Bassi]

Giampaolo Tomassoni ha scritto:

Dears,

I wrote a first release of a SAR helper module for Linux 2.6.x.

It is conceptually similar to the Duncan Sands' usb_atm module, but it is not 
constrained to usb devices and is a bit different from it in its implementation 
details.

It seems to me that scores some points in this:

- supplies a coherent interface which allows the device driver to bypass
almost any interaction with the atm layer;

- supports ATM header check, correction and generation, which is
most useful for dumb atm devices (ie: most ADSL modems);

- supports automatic and fast routing of received cells to destinating
vcc;

- actually supports AALraw, AAL0 and AAL5;

- aal decoding/encoding routines are designed as atmsar plug-ins, so
that further types may easily be supported;

- implements speed- and memory-concerned techniques for per-vcc
decoding;

- allows using dma-streaming techniques in sending cells to device;

- supports tx buffer adjusting against device needs;

- avoids vcc open/close paradigm handling in device driver;

- yields a uniform view to SAR status in /proc.


I'm contacting you firstly because I would like to hear your point of view 
about the whole idea (am I reinventing the wheel?), then because I would like 
to have my code reviewed, and lastly because I have some question about the 
matter.

I prepared the SAR module as a patch against the Linux 2.6.12.3 kernel tree. It 
is attached to this message as a unified diff.

Also, in order to allow you to evaluate it, I prepared a driver adopting the 
SAR module's API for the Globespan Pulsar ADSL PCI card. This driver is made 
after the one from Guy Ellis (see http://adsl4linux.no-ip.org/pulsar.html for 
further reference). My version is a two-part driver: a GPL one ( 
http://www.tomassoni.biz/download/pulsar/pulsaradsl-1.0.1-source.tar.bz2 ) and 
a proprietary library ( 
http://www.tomassoni.biz/download/pulsar/libpulsar_fw.a.bz2 ) which shall be 
decompressed and put in the pulsaradsl-1.0.1 directory in order to build the 
driver. The libpulsar_fw.a is the one for GCC 3. If you need a version of this 
library for another GCC flavor, please see the above reported Ellis' pulsar 
site.

Note also that I'm allowing you to download a copy of the libpulsar_fw.a 
library only for the purpose of evaluating the SAR module: it is not meant to 
be used otherway.

My intention, if the maintainer of the ATM stack under Linux (Chas Williams) 
and the author of the usb_atm module (Duncan Sands) agree, is to merge the 
atmsar module into the linux tree, thereby replacing the atm+sar code in the 
Verrept-Sands' atm_usb module, which will then contain only the usb handling 
code and eventually will relay on the atmsar module for its atm+sar ops. I'm 
also looking for help by Sands to do this. Also, it could be interesting to 
have the Ellis' driver use this module, as the Pulsar PCI ADSL card is actually 
the only ADSL PCI modem of which I'm aware.

Questions are spread in comments in the atmsar sources. I can of course ask them by 
e-mail, but let the Q phase follow your feedbacks about the need for this 
brand-new wheel...

Regards,

---
Giampaolo Tomassoni - IT Consultant
Piazza VIII Aprile 1948, 4
I-53044 Chiusi (SI) - Italy
Ph: +39-0578-21100



i see a sort of non-sense in your (argh!!) binary (but just for 
evaluation) library.



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

Re: It's Urgent !!

[Willy Tarreau]

With such a subject, you'll certainly feed most people's spam traps. And
with such a fuzzy question, I don't think you'll ever get a useful response.
It's like asking what is the difference between sunny days and rainy days...

You'd better look for some litterature if your question is related to kernel
development, eg. Linux Device Drivers from Alessandro Rubini.

Willy

On Sat, Sep 03, 2005 at 06:50:24PM +0100, shashank kharche wrote:
> Note: forwarded message attached.
> 
> 
> 
>   
> 
>   
>   
> __ 
> Yahoo! India Matrimony: Find your partner online. Go to 
> http://yahoo.shaadi.com
> Date: Sat, 3 Sep 2005 18:48:24 +0100 (BST)
> From: shashank kharche <[EMAIL PROTECTED]>
> Subject: It's Urgent !!
> To: [EMAIL PROTECTED]
> 
> Sir,
> Can u tell me wat is difference between block
> device driver for linux kernel 2.4. & 2.6 .
>Shashank K.
>  PhD computer
> science
>  IIT PAWAI ( INDIA
> )
>  
> 
> 
> 
>   
> 
>   
>   
> __ 
> Yahoo! India Matrimony: Find your partner online. Go to 
> http://yahoo.shaadi.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/

It's Urgent !!

[shashank kharche]

Note: forwarded message attached.







__ 
Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.com--- Begin Message ---
Sir,
Can u tell me wat is difference between block
device driver for linux kernel 2.4. & 2.6 .
   Shashank K.
 PhD computer
science
 IIT PAWAI ( INDIA
)
 







__ 
Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.com
--- End Message ---

Re: 2.6.13: Crash in Yenta initialization

[Ivan Kokshaysky]

On Sat, Sep 03, 2005 at 02:45:08AM +0200, Andreas Koch wrote:
> crucial part seem to be the different bridge initialization sections:

Indeed.

> 2.6.12-rc6 + Ivan's patches:
...
>   PCI: Bus 7, cardbus bridge: :06:09.0
> IO window: 6000-6fff
> IO window: 7000-7fff
> PREFETCH window: 8200-83ff
> MEM window: 8c00-8dff
>   PCI: Bus 11, cardbus bridge: :06:09.1
> IO window: 8000-8fff
> IO window: 9000-9fff
> PREFETCH window: 8400-85ff
> MEM window: 8e00-8fff
>   PCI: Bus 15, cardbus bridge: :06:09.3
...
> ... Versus the much shorter output from 2.6.13
...
>   PCI: Bus 7, cardbus bridge: :06:09.0
> IO window: 4000-40ff
> IO window: 4400-44ff
> PREFETCH window: 8200-83ff
> MEM window: 8800-89ff
>   PCI: Bridge: :00:1e.0

It's mysterious.
So 2.6.13 doesn't see cardbus bridge functions 06:09.1 and 06:09.3,
which means that these devices are not on the per-bus device list.
OTOH, they are still visible on the global device list, since yenta
driver found them. No surprise that it crashes with some uninitialized
pointer.

I'd suspect some change in PCI probing code between 2.6.12-rc6 and
2.6.13, but so far I'm unable to find what it was...

Maybe you could try 2.6.12 release and 2.6.13-rc kernels to see where
it breaks?
(Note that the PCI setup patches that you're using went into 2.6.13-rc2.)

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

Re: [PATCH 2/2] [NETFILTER] remove bogus hand-coded htonll()

[Harald Welte]

On Sat, Sep 03, 2005 at 09:54:25AM -0700, Jouni Malinen wrote:
> On Sat, Sep 03, 2005 at 10:43:15AM +0200, Harald Welte wrote:
> 
> > htonll() is nothing else than cpu_to_be64(), so we'd rather call the
> > latter.
> 
> Actually, the htonll() implementation does not seem to be doing what
> cpu_to_be64() is doing.. However, I would assume this is a bug in
> htonll() and this change to use cpu_to_be64() is fixing that. 

ACK.

> Can this bug cause any major problems in the current implementation?

the "current implementation" was only merged after 2.6.13 is released,
so I doubt anyone but the netfilter developers is using it yet.

> I would assume that the first index should have had '-i' added to it, if
> the purpose is to swap byte order.. The code here is leaving some
> arbitrary data in 7 bytes of the 64-bit variable and setting
> (u8*)[7] = (u8*)[7] in somewhat inefficient way ;-). In addition,
> this looks more like swap-8-bytes-unconditionally than doing this based
> on host byte order..

yes, yes, yes.  Somehow this ancient buggy implementation slipped into
mainline.  I know I had fixed this before.

So please let's all forget about this embarrassing htonll() and move on. 

-- 
- Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/

  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."-- Paul Vixie


pgpZliKCIUmq8.pgp
Description: PGP signature

Re: Request for review

[Jiri Slaby]

Giampaolo Tomassoni napsal(a):


Dears,

I wrote a first release of a SAR helper module for Linux 2.6.x.

It is conceptually similar to the Duncan Sands' usb_atm module, but it is not 
constrained to usb devices and is a bit different from it in its implementation 
details.

It seems to me that scores some points in this:

- supplies a coherent interface which allows the device driver to bypass
almost any interaction with the atm layer;

- supports ATM header check, correction and generation, which is
most useful for dumb atm devices (ie: most ADSL modems);

- supports automatic and fast routing of received cells to destinating
vcc;

- actually supports AALraw, AAL0 and AAL5;

- aal decoding/encoding routines are designed as atmsar plug-ins, so
that further types may easily be supported;

- implements speed- and memory-concerned techniques for per-vcc
decoding;

- allows using dma-streaming techniques in sending cells to device;

- supports tx buffer adjusting against device needs;

- avoids vcc open/close paradigm handling in device driver;

- yields a uniform view to SAR status in /proc.


I'm contacting you firstly because I would like to hear your point of view 
about the whole idea (am I reinventing the wheel?), then because I would like 
to have my code reviewed, and lastly because I have some question about the 
matter.

I prepared the SAR module as a patch against the Linux 2.6.12.3 kernel tree. It 
is attached to this message as a unified diff.

Also, in order to allow you to evaluate it, I prepared a driver adopting the 
SAR module's API for the Globespan Pulsar ADSL PCI card. This driver is made 
after the one from Guy Ellis (see http://adsl4linux.no-ip.org/pulsar.html for 
further reference). My version is a two-part driver: a GPL one ( 
http://www.tomassoni.biz/download/pulsar/pulsaradsl-1.0.1-source.tar.bz2 ) and 
a proprietary library ( 
http://www.tomassoni.biz/download/pulsar/libpulsar_fw.a.bz2 ) which shall be 
decompressed and put in the pulsaradsl-1.0.1 directory in order to build the 
driver. The libpulsar_fw.a is the one for GCC 3. If you need a version of this 
library for another GCC flavor, please see the above reported Ellis' pulsar 
site.

Note also that I'm allowing you to download a copy of the libpulsar_fw.a 
library only for the purpose of evaluating the SAR module: it is not meant to 
be used otherway.

My intention, if the maintainer of the ATM stack under Linux (Chas Williams) 
and the author of the usb_atm module (Duncan Sands) agree, is to merge the 
atmsar module into the linux tree, thereby replacing the atm+sar code in the 
Verrept-Sands' atm_usb module, which will then contain only the usb handling 
code and eventually will relay on the atmsar module for its atm+sar ops. I'm 
also looking for help by Sands to do this. Also, it could be interesting to 
have the Ellis' driver use this module, as the Pulsar PCI ADSL card is actually 
the only ADSL PCI modem of which I'm aware.
 

+void   atmsar_rx_decode_52bytes(atmsar_dev_t* dev, const void* 
cell)
why the spaces between void and function name? The readability of the 
code is bad :(.

+{ sarDecode(dev, ntohl(*(unsigned*)cell), &((char*)cell)[4]); }
and
+static inline void dumpCell(char* dst, const ATM_CELL* cell) {
What's this? See CodingStyle, chapter 3.

CodingStyle, chapter 2:
-The limit on the length of lines is 80 columns and this is a hard limit.-
Please keep to it.

Fix this:
/l/latest/xxx/drivers/atm/sar.c:254:5: warning: "DBG" is not defined
/l/latest/xxx/drivers/atm/sar.c:307:5: warning: "DBG" is not defined

Remove trailing spaces from the end of lines, please.

   return(sar);
no parens around return value.

   if(len < ATM_CELL_PAYLOAD)
space between if and (

   atmsar_vcc_t *sar = (atmsar_vcc_t*)kmalloc(sizeof(sar), GFP_KERNEL);
this should be sizeof(*sar)
   if(sar != NULL)
   memset(sar, 0, sizeof(*sar));
use kzalloc instead of this piece (you may need to upgrade your kernel 
to some latest version)


   struct sk_buff* skbIn
* after space, not before

   int i;
   atm_dev_deregister(dev->atmdev);
   for(i = 0; i < ATMSAR_N_HASHVCCS; ++i)
space between for and (
   while(dev->vccs_hash[i] != NULL)
   atmClose(dev->vccs_hash[i]->vcc);
unsigned int is better if you don't need to count in negative, this is 
only hint.


thanks,

--
Jiri Slaby www.fi.muni.cz/~xslaby
~\-/~  [EMAIL PROTECTED]  ~\-/~
241B347EC88228DE51EE A49C4A73A25004CB2A10

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

Re: 2.6.13-mm1 login fails

[David S. Miller]

From: "Brown, Len" <[EMAIL PROTECTED]>
Date: Sat, 3 Sep 2005 12:58:15 -0400

> CONFIG_AUDIT=y indeed did the trick.
> 
> When will I be able to delete CONFIG_AUDIT from my kernel again?

It's a regression we accidently added to the netlink socket
family, we will fix it.  But please use the workaround of
enabling CONFIG_AUDIT until we fix it, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: gcc coredump with 2.6.12+ kernels

[Alexander Nyberg]

On Sat, Sep 03, 2005 at 10:25:37AM -0700 Johnny Stenback wrote:

> Hey all,
> 
> I just attempted to upgrade my kernel to 2.6.13. The kernel appears to 
> boot and run just fine, but when I try to build any larger projects like 
> Mozilla or the Linux kernel I constantly get segfaults from gcc. All 
> other apps *seem* to work fine. I remember seeing this with 2.6.12 too 
> when I tried to upgrade to it too but I didn't have the time to 
> investigate at all then, but now I see the same problem with 2.6.13. The 
> last version I've used that didn't show this problem is 2.6.11.3, and 
> that's running with no problems here.
> 
> When gcc segfaults I get the following messages in the messages log:
> 
> cc1[16775]: segfault at  rip 0036f2b0119e rsp 
> 7faaf0a0 error 4
> cc1[17086]: segfault at  rip 0036f2b0119e rsp 
> 7fc4dfc0 error 4
> cc1[17788]: segfault at  rip 0036f2b0119e rsp 
> 7fd777e0 error 4
> cc1[17823]: segfault at  rip 0036f2b0119e rsp 
> 7fc4d630 error 4
> cc1[17895]: segfault at  rip 0036f2b0119e rsp 
> 7ffd2330 error 4
> 
> I'm on a dual AMD Opteron system, running x86_64 code. Using Fedora Core 
> 2 (yeah, old, I know...) and gcc 3.3.3 20040412.

Does it still happen if you run:

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

Re: [PATCH 1/2] pci: Block config access during BIST (resend)

[Brian King]

Grant Grundler wrote:

On Sat, Sep 03, 2005 at 09:11:30AM +1000, Paul Mackerras wrote:


Think about it.  Taking the lock ensures that we don't do the
assignment (dev->block_ucfg_access = 1) while any other cpu has the
pci_lock.  In other words, the reason for taking the lock is so that
we wait until nobody else is doing an access, not to make others wait.



The block_ucfg_access field is only used when making the choice to
use saved state or call the PCI bus cfg accessor.
I don't what problem waiting solves here since any CPU already
accessing real cfg space will finish what they are doing anyway.
ie they already made the choice to access real cfg space.
We just need to make sure successive accesses to cfg space
for this device only access the saved state. For that, a memory barrier
around all uses of block_ucfg_access should be sufficient.
Or do you think I'm still drinking the wrong color cool-aid?


Without the locking, we introduce a race condition.

CPU 0   CPU 1

pci_block_user_cfg_access
pci_save_state
pci_read_user_config_space
check block_ucfg_access
set block_ucfg_access
other code that puts the device
in a state such that it cannot
handle read config i/o, such as
running BIST.

pci read config

In this scenario, If the real read on the left happens after the flag is 
set to block user config accesses, then the thread that set the flag 
could go off and start BIST or do something else to put the pci device 
in a state where it cannot accept real config I/O and we end up with a 
target abort, which is exactly what this patch is attempting to fix.


Granted, for the specific usage scenario in ipr, where I am using this 
to block config space over BIST, I use a pci config write to start BIST, 
which would end up being a point of synchronization, but that seems a 
bit non-obvious and limits how the patch can be used by others...



If you had:
spin_lock_irqsave(_lock, flags);
pci_save_state(dev);
dev->block_ucfg_access = 1;
spin_unlock_irqrestore(_lock, flags);

Then I could buy your arguement since the flag now implies
we need to atomically save state and set the flag.


That's probably a good thing to do to.



One needs to verify pci_lock isn't acquired in pci_save_state()
(or some other obvious dead lock).


Unfortunately, it is... Every pci config access grabs the lock, so we 
would need to use some special code that did not acquire the lock in 
pci_save_state if we wanted to do such a thing.


Brian


--
Brian King
eServer Storage I/O
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hotswap support for libata

[Alan Cox]

On Sad, 2005-09-03 at 02:38 -0400, Jeff Garzik wrote:
> controllers myself.  Many controllers don't have an explicit hotplug 
> interrupt, but rather we must examine the PhyRdy bit in the standard 
> SError register for details.  If the bit's state changes in any way 
> (including two or more state changes), we (a) check for device presence, 
> and (b) if device is present, initialize it (SET FEATURES - XFER MODE, 
> etc.).

For PATA we may need to reprogram both drives so please be sure that is
allowed for. Also much PATA is "warm swap" not "hot swap" as we have to
perform actions in software prior to the swap.

Alan

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

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

Tyler wrote:

Brett Russ wrote:


Some (non-functional) cleanup modifications since the version 0.10
driver I sent out 2005-08-30.  Also adding signed-off-by for Jeff's
upstream push.  This is my libata compatible low level driver for
the Marvell SATA family.  Currently it successfully runs in PIO mode
on a 6081 chip.  EDMA support is in the works and should be done
shortly.  Review, testing (especially on other flavors of Marvell),
comments welcome.

Thank you,
BR

Signed-off-by: Brett Russ <[EMAIL PROTECTED]>

 


[snip..]

Please find attached patches that add the Adaptec 1420SA controller to 
the PCI ID list in the driver, and a small note in the kernel config 
option to state so.  This is untested as of currently, if anyone has a 
1420SA to try, that would be great..  The one I had access to is now 
gone to a remote location out of reach for testing.  I read in one post 
I found with google, that the 1420SA uses a 6541 chip instead of a 6041, 
but I am not able to verify this, and also don't know if it may still 
work as a 6041.  The card is still a Sata2, PCI-X card, with 4 ports, 
the same as the 6041 based cards.  This patch may or may not be 
useful..  The card comes with a manufacturer ID of 9005 according to a 
linux PCI-ID list, which is a secondary id of Adaptec's known as 
ADAPTEC2, and an actual PCI Id of 0241.


I would prefer to have it tested, before accepting this patch...

Jeff



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

Re: [-mm patch] FB_GEODE should depend on PCI

[Alan Cox]

On Sad, 2005-09-03 at 14:01 +0200, Adrian Bunk wrote:
> Due to fbdev-geode-updates.patch, building with CONFIG_PCI=n results in 
> the following error:

All the Geodes have PCI or internal PCI emulation so that change makes
sense.

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

gcc coredump with 2.6.12+ kernels

[Johnny Stenback]

Hey all,

I just attempted to upgrade my kernel to 2.6.13. The kernel appears to 
boot and run just fine, but when I try to build any larger projects like 
Mozilla or the Linux kernel I constantly get segfaults from gcc. All 
other apps *seem* to work fine. I remember seeing this with 2.6.12 too 
when I tried to upgrade to it too but I didn't have the time to 
investigate at all then, but now I see the same problem with 2.6.13. The 
last version I've used that didn't show this problem is 2.6.11.3, and 
that's running with no problems here.


When gcc segfaults I get the following messages in the messages log:

cc1[16775]: segfault at  rip 0036f2b0119e rsp 
7faaf0a0 error 4
cc1[17086]: segfault at  rip 0036f2b0119e rsp 
7fc4dfc0 error 4
cc1[17788]: segfault at  rip 0036f2b0119e rsp 
7fd777e0 error 4
cc1[17823]: segfault at  rip 0036f2b0119e rsp 
7fc4d630 error 4
cc1[17895]: segfault at  rip 0036f2b0119e rsp 
7ffd2330 error 4


I'm on a dual AMD Opteron system, running x86_64 code. Using Fedora Core 
2 (yeah, old, I know...) and gcc 3.3.3 20040412.


I've ran memtest etc on this system, and with 2.6.11.3 and older kernels 
I've ran this system under moderate load for months w/o rebooting and 
I've never had any problems like this, so I'm fairly certain that I 
don't have bad hardware.


Anyone have any clues as to what could be causing this problem?

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

Re: 2.6.13-mm1: hangs during boot ...

[James Bottomley]

On Sat, 2005-09-03 at 23:51 +1000, Peter Williams wrote:
> > Are you seeing this "Device  not ready" message appear over and over, or 
> > just the once?
> 
> Just the once.

OK, I finally have a theory about this.  It's the everything goes via
bios code.  Previously there were several levels at which commands could
exit the SCSI stack; now we make everything go via bios, so they all
come out at the top.

get_capabilities() in sr.c is sending a TEST_UNIT_READY which will get
NOT_READY back.  Previously this was completing before it got to
scsi_io_completion(); now it doesn't.  There must be quite a few cases
like this.  The best fix is probably to use and respect REQ_QUIET for
internally generated commands.

James


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

Re: [PATCH 2.6.13] lockless pagecache 2/7

[Alan Cox]

On Sad, 2005-09-03 at 11:40 +1000, Nick Piggin wrote:
> We'll see how things go. I'm fairly sure that for my usage it will
> be a win even if it is costly. It is replacing an atomic_inc_return,
> and a read_lock/read_unlock pair.

Make sure you bench both AMD and Intel - I'd expect it to be a big loss
on AMD because the AMD stuff will perform atomic locked operations very
efficiently if they are already exclusive on this CPU or a prefetch_w()
on them was done 200+ clocks before.

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

Re: [PATCH 2/2] [NETFILTER] remove bogus hand-coded htonll()

[Jouni Malinen]

On Sat, Sep 03, 2005 at 10:43:15AM +0200, Harald Welte wrote:

> htonll() is nothing else than cpu_to_be64(), so we'd rather call the
> latter.

Actually, the htonll() implementation does not seem to be doing what
cpu_to_be64() is doing.. However, I would assume this is a bug in
htonll() and this change to use cpu_to_be64() is fixing that. Can this
bug cause any major problems in the current implementation?

> -u_int64_t htonll(u_int64_t in)
> -{
> - u_int64_t out;
> - int i;
> -
> - for (i = 0; i < sizeof(u_int64_t); i++)
> - ((u_int8_t *))[sizeof(u_int64_t)-1] = ((u_int8_t *))[i];

I would assume that the first index should have had '-i' added to it, if
the purpose is to swap byte order.. The code here is leaving some
arbitrary data in 7 bytes of the 64-bit variable and setting
(u8*)[7] = (u8*)[7] in somewhat inefficient way ;-). In addition,
this looks more like swap-8-bytes-unconditionally than doing this based
on host byte order..

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.13-mm1 login fails (RE: 2.6.13-mm1: hangs during boot ...)

[Brown, Len]

 
>As for the inability to log in, this bug may be relevant, 
>given I also had 
>that problem:
>
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166422
>
>There are fixes in the pipeline for util-linux audit 
>interaction in Fedora as 
>well.  I know because I reported those too ;)
>
>> after the scsi initialization which I don't normally see.  
>I've attached 
>> the scsi initialization output.  The PF_NETLINK error 
>messages after the 
>> login prompt in this output are created whenever I try to log in or 
>> connect via ssh.
>
>The workaround by enabling audit support, but obviously a 
>better fix is in the 
>pipeline..
>
>I'm surprised more people aren't discovering these 
>'interactions' due to 
>having audit not turned on.  Does everyone build audit into 
>their kernels?

This sure made my FC4 test boxes hard to use!

CONFIG_AUDIT=y indeed did the trick.

When will I be able to delete CONFIG_AUDIT from my kernel again?

thanks
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Splitting out kernel<=>userspace ABI headers

[Kyle Moffett]

On Sep 3, 2005, at 11:19:17, H. Peter Anvin wrote:
Thus, an ABIzed  or whatever it's called might  
export
"struct __kabi_stat" and "struct __kabi_stat64" with the  
expectation that
the caller would "#define __kabi_stat64 stat" if that is the  
version they
want.  A typedef isn't good enough for C, since you can't typedef  
struct

tags.


Didn't you mean "#define stat __kabi_stat64"?  Also, I can see that  
would

pose other issues as well say my app does "struct stat stat;"  Any error
messages would refer to a variable "__kabi_stat64" instead of the  
expected

"stat":

A userspace program:
struct stat stat;
stat.invalid = 1;

Preprocesses into:
struct __kabi_stat64 __kabi_stat64;
__kabi_stat64.invalid = 1;

And gives an error something like this for that line, confusing the
programmer:
Invalid member "invalid" for "__kabi_stat64"


As far as I can tell, this is not a solvable issue unless GCC can  
come up

with a way to either:
typedef struct foo struct bar;
or
struct bar { unnamed struct foo; };
the former being much nicer.  On the other hand, I think the following
should work, because the st_* names are within the C namespace and  
should

be much easier to redefine, although misuse of one of those names might
be a bit more catastrophic for the user app.

struct stat {
struct __kabi_stat64 __stat64;
};
#define st_dev __stat64.st_dev
#define st_ino __stat64.st_ino
[...]

Then the userspace program could do this:
struct stat foo;
foo.st_ino = 0;

And it would be preprocessed into:
struct stat foo;foo.__stat64.st_ino = 0;

Cheers,
Kyle Moffett

--
Somone asked me why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best  
answer:


"Why do musicians compose symphonies and poets write poems? They do  
it because
life wouldn't have any meaning for them if they didn't. That's why I  
draw

cartoons. It's my life."
  -- Charles Shultz


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

Re: [x86_64] Exception when using powernowd.

[David Ranson]

Kyuma Ohta wrote:

>When upgrade X 6.8.2-4 to 6.8.2-5(or after),this issue has often happend.
>I'm using nVidia Geforce 5200 as Display adapter,but this issue
>has happend bot Debian's driver and nVidia's driver.
>  
>
Hmmm. I use a low end Radeon 7000 in mine, so our configurations
diverge. I'm using stock SuSE X.org.

nVidia issues ?? I've no idea really :-(

David

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Splitting out kernel<=>userspace ABI headers

[Denis Vlasenko]

On Saturday 03 September 2005 19:33, Kyle Moffett wrote:
> On Sep 3, 2005, at 11:36:22, Denis Vlasenko wrote:
> > Is this an exercise in academia? Userspace app which defines
> > uint32_t to anything different than 'typedef '
> > deserves the punishment, and one which does have such typedef
> > instead of #include stdint.h will not notice.
> 
> That's not the issue.  Say I do this (which is perfectly valid on
> most platforms):
> 
> typedef unsigned int uint32_t;
> #include 
> 
> What exactly should happen?  If linux/loop.h includes stdint.h to get
> uint32_t, then I'll get duplicate definition errors.  If it omits
> stdint.h, then uint16_t won't be defined (because the userspace app
> doesn't think that it needs it) and I'll get undefined type errors.

I vote for a second choice. Do not #include stdint.h from the loop.h
(i.e. loop.h assumes that it is included (or unit32_t typedef'ed),
but doesn't do it itself).
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Splitting out kernel<=>userspace ABI headers

[Kyle Moffett]

On Sep 3, 2005, at 11:36:22, Denis Vlasenko wrote:

Is this an exercise in academia? Userspace app which defines
uint32_t to anything different than 'typedef '
deserves the punishment, and one which does have such typedef
instead of #include stdint.h will not notice.


That's not the issue.  Say I do this (which is perfectly valid on
most platforms):

typedef unsigned int uint32_t;
#include 

What exactly should happen?  If linux/loop.h includes stdint.h to get
uint32_t, then I'll get duplicate definition errors.  If it omits
stdint.h, then uint16_t won't be defined (because the userspace app
doesn't think that it needs it) and I'll get undefined type errors.
Either way, depending on the existence or nonexistence of the POSIX
types in userspace-accessible kernel headers is not viable.


All these u32, uint32_t, __u32 end up typedef-ing to same
integer type anyway...


The point is to provide a type that _isn't_ in some standard so that
_we_ can define its inclusion rules.  If the standards had gone and
defined "Userspace must include stdint.h or define _all_ types
appropriately", then we would not have had this issue, but many apps
in userspace would cease to compile on standards compliant platforms.

Cheers,
Kyle Moffett

--
Somone asked me why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best  
answer:


"Why do musicians compose symphonies and poets write poems? They do  
it because
life wouldn't have any meaning for them if they didn't. That's why I  
draw

cartoons. It's my life."
  -- Charles Shultz


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

[PATCH 2/3] 2.6.13: cpuset + build_sched_domains() fix

[hawkes]

Fix part 2:
My fix to the 2.6.13 problem:  dynamically allocate sched_group_nodes[]
and sched_group_allnodes[] for each invocation of build_sched_domains(),
rather than use global arrays for these structures, taking care to
remember kmalloc() addresses so that arch_destroy_sched_domains() can
properly kfree() them.

Signed-off-by: John Hawkes <[EMAIL PROTECTED]>

Index: linux/kernel/sched.c
===
--- linux.orig/kernel/sched.c   2005-09-02 08:44:24.0 -0700
+++ linux/kernel/sched.c2005-09-02 08:44:53.0 -0700
@@ -4970,10 +4970,10 @@
  * gets dynamically allocated.
  */
 static DEFINE_PER_CPU(struct sched_domain, node_domains);
-static struct sched_group *sched_group_nodes[MAX_NUMNODES];
+static struct sched_group **sched_group_nodes_bycpu[NR_CPUS];
 
 static DEFINE_PER_CPU(struct sched_domain, allnodes_domains);
-static struct sched_group sched_group_allnodes[MAX_NUMNODES];
+static struct sched_group *sched_group_allnodes_bycpu[NR_CPUS];
 
 static int cpu_to_allnodes_group(int cpu)
 {
@@ -4988,6 +4988,21 @@
 void build_sched_domains(const cpumask_t *cpu_map)
 {
int i;
+#ifdef CONFIG_NUMA
+   struct sched_group **sched_group_nodes = NULL;
+   struct sched_group *sched_group_allnodes = NULL;
+
+   /*
+* Allocate the per-node list of sched groups
+*/
+   sched_group_nodes = kmalloc(sizeof(struct sched_group*)*MAX_NUMNODES,
+  GFP_ATOMIC);
+   if (!sched_group_nodes) {
+   printk(KERN_WARNING "Can not alloc sched group node list\n");
+   return;
+   }
+   sched_group_nodes_bycpu[first_cpu(*cpu_map)] = sched_group_nodes;
+#endif
 
/*
 * Set up domains for cpus specified by the cpu_map.
@@ -5000,8 +5015,21 @@
cpus_and(nodemask, nodemask, *cpu_map);
 
 #ifdef CONFIG_NUMA
-   if (num_online_cpus()
+   if (cpus_weight(*cpu_map)
> SD_NODES_PER_DOMAIN*cpus_weight(nodemask)) {
+   if (!sched_group_allnodes) {
+   sched_group_allnodes
+   = kmalloc(sizeof(struct sched_group)
+   * MAX_NUMNODES,
+ GFP_KERNEL);
+   if (!sched_group_allnodes) {
+   printk(KERN_WARNING
+   "Can not alloc allnodes sched group\n");
+   break;
+   }
+   sched_group_allnodes_bycpu[i]
+   = sched_group_allnodes;
+   }
sd = _cpu(allnodes_domains, i);
*sd = SD_ALLNODES_INIT;
sd->span = *cpu_map;
@@ -5065,7 +5093,8 @@
 
 #ifdef CONFIG_NUMA
/* Set up node groups */
-   init_sched_build_groups(sched_group_allnodes, *cpu_map,
+   if (sched_group_allnodes)
+   init_sched_build_groups(sched_group_allnodes, *cpu_map,
_to_allnodes_group);
 
for (i = 0; i < MAX_NUMNODES; i++) {
@@ -5077,8 +5106,10 @@
int j;
 
cpus_and(nodemask, nodemask, *cpu_map);
-   if (cpus_empty(nodemask))
+   if (cpus_empty(nodemask)) {
+   sched_group_nodes[i] = NULL;
continue;
+   }
 
domainspan = sched_domain_node_span(i);
cpus_and(domainspan, domainspan, *cpu_map);
@@ -5223,24 +5254,42 @@
 {
 #ifdef CONFIG_NUMA
int i;
-   for (i = 0; i < MAX_NUMNODES; i++) {
-   cpumask_t nodemask = node_to_cpumask(i);
-   struct sched_group *oldsg, *sg = sched_group_nodes[i];
+   int cpu;
 
-   cpus_and(nodemask, nodemask, *cpu_map);
-   if (cpus_empty(nodemask))
-   continue;
+   for_each_cpu_mask(cpu, *cpu_map) {
+   struct sched_group *sched_group_allnodes
+   = sched_group_allnodes_bycpu[cpu];
+   struct sched_group **sched_group_nodes
+   = sched_group_nodes_bycpu[cpu];
+
+   if (sched_group_allnodes) {
+   kfree(sched_group_allnodes);
+   sched_group_allnodes_bycpu[cpu] = NULL;
+   }
 
-   if (sg == NULL)
+   if (!sched_group_nodes)
continue;
-   sg = sg->next;
+
+   for (i = 0; i < MAX_NUMNODES; i++) {
+   cpumask_t nodemask = node_to_cpumask(i);
+   struct sched_group *oldsg, *sg = sched_group_nodes[i];
+
+   cpus_and(nodemask, nodemask, 

[PATCH 3/3] 2.6.13: cpuset + build_sched_domains() fix

[hawkes]

Fix part 3:
Undo the #ifdef disabling hack that was put into 2.6.13 to disable
dynamic sched domains.

Signed-off-by: John Hawkes <[EMAIL PROTECTED]>

Index: linux/kernel/cpuset.c
===
--- linux.orig/kernel/cpuset.c  2005-08-28 16:41:01.0 -0700
+++ linux/kernel/cpuset.c   2005-09-02 08:45:24.0 -0700
@@ -628,13 +628,6 @@
  * lock_cpu_hotplug()/unlock_cpu_hotplug() pair.
  */
 
-/*
- * Hack to avoid 2.6.13 partial node dynamic sched domain bug.
- * Disable letting 'cpu_exclusive' cpusets define dynamic sched
- * domains, until the sched domain can handle partial nodes.
- * Remove this #if hackery when sched domains fixed.
- */
-#if 0
 static void update_cpu_domains(struct cpuset *cur)
 {
struct cpuset *c, *par = cur->parent;
@@ -675,11 +668,6 @@
partition_sched_domains(, );
unlock_cpu_hotplug();
 }
-#else
-static void update_cpu_domains(struct cpuset *cur)
-{
-}
-#endif
 
 static int update_cpumask(struct cpuset *cs, char *buf)
 {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 0/3] 2.6.13: cpuset + build_sched_domains() fix

[hawkes]

Dinakar Guniguntala's "dynamic sched domains" functionality was been merged
into 2.6.13-rcN, although it was disabled at the last minute in the final
2.6.13 because it triggers a fatal bug for NUMA systems with more than one
CPU per node.

Conceptually, when a user/sysadmin declares a cpu-exclusive (a.k.a.
"isolated") cpuset, the cpuset code calls build_sched_domains() to isolate
the cpu-exclusive CPU(s) such that these CPU(s) only load-balance among
themselves and the remaining CPU(s) only load-balance among themselves.
Thus, the non-isolated CPU(s) spend no load-balancing effort trying to
offload tasks cannot be migrated away from their isolated CPU(s).
Otherwise, for example, if an isolated CPU were to be the systemwide
most-heavily-loaded CPU, then this would effectively disable all dynamic
load-balancing in the Scheduler because the non-isolated CPU(s) would
keep making futile efforts to offload isolated, non-migratable tasks.

Unfortunately, the 2.6.13 bug is that build_sched_domains() expects that
a sched domain will include all the CPUs of each node in the domain; more
accurately, that no node will belong in both an isolated cpuset and a
non-isolated cpuset.  Declaring a cpuset that violates this presumption
will produce flawed data structures and will oops the kernel.  Hence,
for 2.6.13, the cpuset code that would otherwise call build_sched_domains()
is #ifdef'ed disabled.

To trigger the problem (on a NUMA system with >1 CPUs per node, if the
kernel/cpuset.c disabling #ifdef is removed):
   cd /dev/cpuset
   mkdir newcpuset
   cd newcpuset
   echo 0 >cpus
   echo 0 >mems
   echo 1 >cpu_exclusive

The fix is in three parts:
1) A contribution from Ingo Molnar to pull the arch-specific ia64
   build_sched_domains() (et al) routines into kernel/sched.c to form
   a unified set of build and destroy routines.
2) My fix to the 2.6.13 problem:  dynamically allocate sched_group_nodes[]
   and sched_group_allnodes[] for each invocation of build_sched_domains(),
   rather than use global arrays for these structures, taking care to
   remember kmalloc() addresses so that arch_destroy_sched_domains() can
   properly kfree() them.
3) Undo the #ifdef disabling hack that was put into 2.6.13 to disable
   dynamic sched domains.

This is a patch against 2.6.13.  I have posted a previous similar patch
against 2.6.13-mm1.

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

[PATCH 1/3] 2.6.13: cpuset + build_sched_domains() fix

[hawkes]

Fix part 1:
A contribution from Ingo Molnar to pull the arch-specific ia64
build_sched_domains() (et al) routines into kernel/sched.c to form
a unified set of build and destroy routines.

Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: John Hawkes <[EMAIL PROTECTED]>

Index: linux/arch/ia64/kernel/Makefile
===
--- linux.orig/arch/ia64/kernel/Makefile2005-08-28 16:41:01.0 
-0700
+++ linux/arch/ia64/kernel/Makefile 2005-09-02 08:44:24.0 -0700
@@ -16,7 +16,7 @@
 obj-$(CONFIG_IA64_PALINFO) += palinfo.o
 obj-$(CONFIG_IOSAPIC)  += iosapic.o
 obj-$(CONFIG_MODULES)  += module.o
-obj-$(CONFIG_SMP)  += smp.o smpboot.o domain.o
+obj-$(CONFIG_SMP)  += smp.o smpboot.o
 obj-$(CONFIG_NUMA) += numa.o
 obj-$(CONFIG_PERFMON)  += perfmon_default_smpl.o
 obj-$(CONFIG_IA64_CYCLONE) += cyclone.o
Index: linux/arch/ia64/kernel/domain.c
===
--- linux.orig/arch/ia64/kernel/domain.c2005-08-28 16:41:01.0 
-0700
+++ /dev/null   1970-01-01 00:00:00.0 +
@@ -1,396 +0,0 @@
-/*
- * arch/ia64/kernel/domain.c
- * Architecture specific sched-domains builder.
- *
- * Copyright (C) 2004 Jesse Barnes
- * Copyright (C) 2004 Silicon Graphics, Inc.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define SD_NODES_PER_DOMAIN 16
-
-#ifdef CONFIG_NUMA
-/**
- * find_next_best_node - find the next node to include in a sched_domain
- * @node: node whose sched_domain we're building
- * @used_nodes: nodes already in the sched_domain
- *
- * Find the next node to include in a given scheduling domain.  Simply
- * finds the closest node not already in the @used_nodes map.
- *
- * Should use nodemask_t.
- */
-static int find_next_best_node(int node, unsigned long *used_nodes)
-{
-   int i, n, val, min_val, best_node = 0;
-
-   min_val = INT_MAX;
-
-   for (i = 0; i < MAX_NUMNODES; i++) {
-   /* Start at @node */
-   n = (node + i) % MAX_NUMNODES;
-
-   if (!nr_cpus_node(n))
-   continue;
-
-   /* Skip already used nodes */
-   if (test_bit(n, used_nodes))
-   continue;
-
-   /* Simple min distance search */
-   val = node_distance(node, n);
-
-   if (val < min_val) {
-   min_val = val;
-   best_node = n;
-   }
-   }
-
-   set_bit(best_node, used_nodes);
-   return best_node;
-}
-
-/**
- * sched_domain_node_span - get a cpumask for a node's sched_domain
- * @node: node whose cpumask we're constructing
- * @size: number of nodes to include in this span
- *
- * Given a node, construct a good cpumask for its sched_domain to span.  It
- * should be one that prevents unnecessary balancing, but also spreads tasks
- * out optimally.
- */
-static cpumask_t sched_domain_node_span(int node)
-{
-   int i;
-   cpumask_t span, nodemask;
-   DECLARE_BITMAP(used_nodes, MAX_NUMNODES);
-
-   cpus_clear(span);
-   bitmap_zero(used_nodes, MAX_NUMNODES);
-
-   nodemask = node_to_cpumask(node);
-   cpus_or(span, span, nodemask);
-   set_bit(node, used_nodes);
-
-   for (i = 1; i < SD_NODES_PER_DOMAIN; i++) {
-   int next_node = find_next_best_node(node, used_nodes);
-   nodemask = node_to_cpumask(next_node);
-   cpus_or(span, span, nodemask);
-   }
-
-   return span;
-}
-#endif
-
-/*
- * At the moment, CONFIG_SCHED_SMT is never defined, but leave it in so we
- * can switch it on easily if needed.
- */
-#ifdef CONFIG_SCHED_SMT
-static DEFINE_PER_CPU(struct sched_domain, cpu_domains);
-static struct sched_group sched_group_cpus[NR_CPUS];
-static int cpu_to_cpu_group(int cpu)
-{
-   return cpu;
-}
-#endif
-
-static DEFINE_PER_CPU(struct sched_domain, phys_domains);
-static struct sched_group sched_group_phys[NR_CPUS];
-static int cpu_to_phys_group(int cpu)
-{
-#ifdef CONFIG_SCHED_SMT
-   return first_cpu(cpu_sibling_map[cpu]);
-#else
-   return cpu;
-#endif
-}
-
-#ifdef CONFIG_NUMA
-/*
- * The init_sched_build_groups can't handle what we want to do with node
- * groups, so roll our own. Now each node has its own list of groups which
- * gets dynamically allocated.
- */
-static DEFINE_PER_CPU(struct sched_domain, node_domains);
-static struct sched_group *sched_group_nodes[MAX_NUMNODES];
-
-static DEFINE_PER_CPU(struct sched_domain, allnodes_domains);
-static struct sched_group sched_group_allnodes[MAX_NUMNODES];
-
-static int cpu_to_allnodes_group(int cpu)
-{
-   return cpu_to_node(cpu);
-}
-#endif
-
-/*
- * Build sched domains for a given set of cpus and attach the sched domains
- * to the individual cpus
- */
-void build_sched_domains(const cpumask_t *cpu_map)
-{
-   int i;
-
- 

Genesys USB 2.0 enclosures

[Jan De Luyck]

Hello lists,

(a mail for the archives)

I've posted in the past about problems with these enclosures - increasing the 
delay seems to fix it, albeit temporarily. The further you go in using the 
disk in such an enclosure, the higher the udelay() had to be - atleast that's 
what I'm seeing here (I've got two of these now :/ )

One permanent fix is adding a powered USB-hub in between the drive enclosures 
and the computer. Since I've done that, I've no longer seen any of the 
problems (i've attached the 'fault' log). Weird but true, since the drives 
come with their own powersupply.

Hope this helps anyone in the future running into the same problem.
-- 
"To vacillate or not to vacillate, that is the question ... or is it?"
usb 4-3: new high speed USB device using ehci_hcd and address 8
scsi5 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 8
usb-storage: waiting for device to settle before scanning
  Vendor: Maxtor 6  Model: Y080P0Rev: 0811
  Type:   Direct-Access  ANSI SCSI revision: 00
SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
sda: assuming drive cache: write through
SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
sda: assuming drive cache: write through
 sda: sda1
Attached scsi disk sda at scsi5, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi5, channel 0, id 0, lun 0,  type 0
usb-storage: device scan complete
XFS mounting filesystem sda1
Ending clean XFS mount for filesystem: sda1
XFS mounting filesystem sda1
Ending clean XFS mount for filesystem: sda1
usb 4-3: USB disconnect, address 8
scsi: Device offlined - not ready after error recovery: host 5 channel 0 id 0 
lun 0
SCSI error : <5 0 0 0> return code = 0x1
end_request: I/O error, dev sda, sector 80067680
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being 

sym53c8xx_2 scsi parity error

[Lars Ziegler]

Hi,

two weeks ago I just installed an Dawicontrol DC2976 UW SCSI controller an an 
HP C7438 DAT streamer in my pc. I'm running a SuSE 9.3 Prof distribution with 
Kernel 2.6.13. when taking backups to my dat no error occurs. but when i try to 
rebackup data from streamer to my hd i always get scsi parity errors and the 
process is stopped. I tried different patches for the sym53c8xx_2 driver but no 
patch solved my problems. has any body an idea what i can do to get my dat work.
Thanks a lot!
Lars
_
Mit der Gruppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle 
Freunde gleichzeitig schicken: http://freemail.web.de/features/?mc=021179



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

Re: Linux 2.6.13

[Alexey Dobriyan]

On Tue, Aug 30, 2005 at 01:57:27AM +0200, Ricardo Galli wrote:
> 2.6.13 does not boot in my PPC (iBook, 500 MHz), it hangs just at the very 
> begining and the machines is automatically rebooted after a couple of 
> minutes.

I've filed a bug at kernel bugzilla so your report won't be lost. See
http://bugme.osdl.org/show_bug.cgi?id=5180

Please, register at http://bugme.osdl.org/createaccount.cgi and add
yourself to CC list.

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

Re: aoe fails on sparc64

[Jim MacBaine]

On 9/1/05, Ed L Cashin <[EMAIL PROTECTED]> wrote:

> The aoe driver looks OK, but it turns out there's a byte swapping bug
> in the vblade that could be related if he's running the vblade on a
> big endian host (even though he said it was an x86 host), but I
> haven't heard back from the original poster yet.

It is in fact a x86_64 kernel, but with a mostly x86 userland. Vblade
is pure x86 code.

> The vblade bug was the omission of swapping the bytes in each short.
> The fix below shows what I mean:

Unfortunately it doesn't fix anything here. The client still reports
the same wrong size as before.  The dmesg output is identical, too.

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

Re: [TRIVAL] Runtime linkage fix for serial_cs

[Takeharu KATO]

Hi


You need to find out why your tree doesn't export
serial8250_unregister_port().  Mis-merged patch maybe?


Thank you for your response.
I'll check our kernel again.


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

RE: 2.6.13-mm1: hangs during boot ...

[Brown, Len]

>> > Please then try the latest ACPI patch here:
>>  > 
>http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches
>/release/2.6.13/acpi-20050902-2.6.13.diff.gz
>>  > It should apply to vanilla 2.6.13 with a reject in ia64/Kconfig
>>  > that you can ignore.
>>  > 
>>  > If this works, then we munged git-acpi.patch in 
>2.6.13-mm1 somehow.
>> 
>>  There were no problems with this patch applied.  So it 
>looks like the 
>>  munge theory is correct.
>
>That diff is significantly different from the diff I plucked from
>master.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
>.git#test
>for 2.6.13-mm1.
>
>Doing (patch -R | grep FAILED) on 2.6.13-mm1 says:

Right.
2.6.13/acpi-20050902-2.6.13.diff.gz
is newers than 2.6.13-rc1's git-acpi.patch

2.6.13/acpi-20050815-2.6.13.diff.gz
is a closer match -- though not exact.

Peter, it might be illustrative if you have a moment
if you can also test 2.6.13/acpi-20050815-2.6.13.diff.gz
all by itself.

If it fails, then I broke -mm1
with acpi-20050815-2.6.13.diff.gz, but fixed
it by acpi-20050902-2.6.13.diff.gz.

If it succeeds, then the issue lies in the relatively small delta
between acpi-20050815-2.6.13.diff.gz 2.6.13-mm1's git-acpi.patch.

thanks,
-Len

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

Re: [PATCH 2/2] support for mmc chip select in wbsd

[Russell King]

On Mon, Aug 29, 2005 at 01:15:04PM +0200, Pierre Ossman wrote:
> Use the chip select ios in the wbsd driver.

Applied, thanks.

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

[PATCH][3/2] also fix rwsem-spinlock.h

[Rik van Riel]

Hi Andrew,

I forgot to also update rwsem-spinlock.h.  Here is the equivalent
change for that file.

These patches simplify the code and should not have much, if any,
difference on the behaviour of the system, compared with the
patches currently in -mm.

Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>

Index: linux-2.6.13/include/linux/rwsem-spinlock.h
===
--- linux-2.6.13.orig/include/linux/rwsem-spinlock.h
+++ linux-2.6.13/include/linux/rwsem-spinlock.h
@@ -61,14 +61,9 @@ extern void FASTCALL(__up_read(struct rw
 extern void FASTCALL(__up_write(struct rw_semaphore *sem));
 extern void FASTCALL(__downgrade_write(struct rw_semaphore *sem));
 
-static inline int sem_is_read_locked(struct rw_semaphore *sem)
+static inline int rwsem_is_locked(struct rw_semaphore *sem)
 {
-   return (sem->activity > 0);
-}
-
-static inline int sem_is_write_locked(struct rw_semaphore *sem)
-{
-   return (sem->activity < 0);
+   return (sem->activity != 0);
 }
 
 #endif /* __KERNEL__ */
From: Rik Van Riel <[EMAIL PROTECTED]>

Add sem_is_read/write_locked functions to the read/write semaphores, along the
same lines of the *_is_locked spinlock functions.  The swap token tuning patch
uses sem_is_read_locked; sem_is_write_locked is added for completeness.

Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Index: linux-2.6.13/include/asm-alpha/rwsem.h
===
--- linux-2.6.13.orig/include/asm-alpha/rwsem.h
+++ linux-2.6.13/include/asm-alpha/rwsem.h
@@ -262,5 +262,10 @@ static inline long rwsem_atomic_update(l
 #endif
 }
 
+static inline int rwsem_is_locked(struct rw_semaphore *sem)
+{
+   return (sem->count != 0);
+}
+
 #endif /* __KERNEL__ */
 #endif /* _ALPHA_RWSEM_H */
Index: linux-2.6.13/include/asm-i386/rwsem.h
===
--- linux-2.6.13.orig/include/asm-i386/rwsem.h
+++ linux-2.6.13/include/asm-i386/rwsem.h
@@ -284,5 +284,10 @@ LOCK_PREFIX"xadd %0,(%2)"
return tmp+delta;
 }
 
+static inline int rwsem_is_locked(struct rw_semaphore *sem)
+{
+   return (sem->count != 0);
+}
+
 #endif /* __KERNEL__ */
 #endif /* _I386_RWSEM_H */
Index: linux-2.6.13/include/asm-ia64/rwsem.h
===
--- linux-2.6.13.orig/include/asm-ia64/rwsem.h
+++ linux-2.6.13/include/asm-ia64/rwsem.h
@@ -186,4 +186,9 @@ __downgrade_write (struct rw_semaphore *
 #define rwsem_atomic_add(delta, sem)   atomic64_add(delta, (atomic64_t 
*)(&(sem)->count))
 #define rwsem_atomic_update(delta, sem)atomic64_add_return(delta, 
(atomic64_t *)(&(sem)->count))
 
+static inline int rwsem_is_locked(struct rw_semaphore *sem)
+{
+   return (sem->count != 0);
+}
+
 #endif /* _ASM_IA64_RWSEM_H */
Index: linux-2.6.13/include/asm-ppc64/rwsem.h
===
--- linux-2.6.13.orig/include/asm-ppc64/rwsem.h
+++ linux-2.6.13/include/asm-ppc64/rwsem.h
@@ -163,5 +163,10 @@ static inline int rwsem_atomic_update(in
return atomic_add_return(delta, (atomic_t *)(>count));
 }
 
+static inline int sem_is_read_locked(struct rw_semaphore *sem)
+{
+   return (sem->count != 0);
+}
+
 #endif /* __KERNEL__ */
 #endif /* _PPC_RWSEM_XADD_H */
Index: linux-2.6.13/include/asm-ppc/rwsem.h
===
--- linux-2.6.13.orig/include/asm-ppc/rwsem.h
+++ linux-2.6.13/include/asm-ppc/rwsem.h
@@ -168,5 +168,10 @@ static inline int rwsem_atomic_update(in
return atomic_add_return(delta, (atomic_t *)(>count));
 }
 
+static inline int rwsem_is_locked(struct rw_semaphore *sem)
+{
+   return (sem->count != 0);
+}
+
 #endif /* __KERNEL__ */
 #endif /* _PPC_RWSEM_XADD_H */
Index: linux-2.6.13/include/asm-s390/rwsem.h
===
--- linux-2.6.13.orig/include/asm-s390/rwsem.h
+++ linux-2.6.13/include/asm-s390/rwsem.h
@@ -351,5 +351,10 @@ static inline long rwsem_atomic_update(l
return new;
 }
 
+static inline int rwsem_is_locked(struct rw_semaphore *sem)
+{
+   return (sem->count != 0);
+}
+
 #endif /* __KERNEL__ */
 #endif /* _S390_RWSEM_H */
Index: linux-2.6.13/include/asm-sh/rwsem.h
===
--- linux-2.6.13.orig/include/asm-sh/rwsem.h
+++ linux-2.6.13/include/asm-sh/rwsem.h
@@ -166,5 +166,10 @@ static inline int rwsem_atomic_update(in
return atomic_add_return(delta, (atomic_t *)(>count));
 }
 
+static inline int rwsem_is_locked(struct rw_semaphore *sem)
+{
+   return (sem->count != 0);
+}
+
 #endif /* __KERNEL__ */
 #endif /* _ASM_SH_RWSEM_H */
Index: linux-2.6.13/include/asm-sparc64/rwsem.h
===
--- linux-2.6.13.orig/include/asm-sparc64/rwsem.h
+++ 

Re: [PATCH 1/2] ios for mmc chip select

[Russell King]

On Mon, Aug 29, 2005 at 01:13:42PM +0200, Pierre Ossman wrote:
> Adds a new ios for setting the chip select pin on MMC cards. Needed on
> SD controllers which use this pin for other things and therefore cannot
> have it pulled high at all times.

Applied, thanks.

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

[PATCH][2/2] fix for -mm swaptoken-tuning.patch

[Rik van Riel]

Hi Andrew,

Here is the change to rmap.c that goes together with the previous
patch, as well as a new version of swaptoken-tuning.patch that you
can just copy into place.   Quilt is great.

Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>

Index: linux-2.6.13/mm/rmap.c
===
--- linux-2.6.13.orig/mm/rmap.c
+++ linux-2.6.13/mm/rmap.c
@@ -305,7 +305,7 @@ static int page_referenced_one(struct pa
   swap token and is in the middle of a page fault. */
if (mm != current->mm && !ignore_token &&
has_swap_token(mm) &&
-   sem_is_read_locked(>mmap_sem))
+   rwsem_is_locked(>mmap_sem))
referenced++;
 
(*mapcount)--;
From: Rik Van Riel <[EMAIL PROTECTED]>

It turns out that the original swap token implementation, by Song Jiang, only
enforced the swap token while the task holding the token is handling a page
fault.  This patch approximates that, without adding an additional flag to the
mm_struct, by checking whether the mm->mmap_sem is held for reading, like the
page fault code does.

This patch has the effect of automatically, and gradually, disabling the
enforcement of the swap token when there is little or no paging going on, and
"turning up" the intensity of the swap token code the more the task holding
the token is thrashing.

Thanks to Song Jiang for pointing out this aspect of the token based thrashing
control concept.

The new code shows a slight degradation over the old swap token code, but
still a big win over running without the swap token.

2.6.12+ swap token disabled

$ for i in `seq 10` ; do /usr/bin/time ./qsbench -n 3000 -p 3 ; done
101.74user 23.13system 8:26.91elapsed 24%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (38597major+430315minor)pagefaults 0swaps
101.98user 24.91system 8:03.06elapsed 26%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (33939major+430457minor)pagefaults 0swaps
101.93user 22.12system 7:34.90elapsed 27%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (33166major+421267minor)pagefaults 0swaps
101.82user 22.38system 8:31.40elapsed 24%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (39338major+433262minor)pagefaults 0swaps

2.6.12+ swap token enabled, timeout 300 seconds

$ for i in `seq 4` ; do /usr/bin/time ./qsbench -n 3000 -p 3 ; done
102.58user 16.08system 3:41.44elapsed 53%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (19707major+285786minor)pagefaults 0swaps
102.07user 19.56system 4:00.64elapsed 50%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (19012major+299259minor)pagefaults 0swaps
102.64user 18.25system 4:07.31elapsed 48%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (21990major+304831minor)pagefaults 0swaps
101.39user 19.41system 5:15.81elapsed 38%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (24850major+323321minor)pagefaults 0swaps

2.6.12+ with new swap token code, timeout 300 seconds

$ for i in `seq 4` ; do /usr/bin/time ./qsbench -n 3000 -p 3 ; done
101.87user 24.66system 5:53.20elapsed 35%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (26848major+363497minor)pagefaults 0swaps
102.83user 19.95system 4:17.25elapsed 47%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (19946major+305722minor)pagefaults 0swaps
102.09user 19.46system 5:12.57elapsed 38%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (25461major+334994minor)pagefaults 0swaps
101.67user 20.61system 4:52.97elapsed 41%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (22190major+329508minor)pagefaults 0swaps

Signed-off-by: Rik Van Riel <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Index: linux-2.6.13/mm/rmap.c
===
--- linux-2.6.13.orig/mm/rmap.c
+++ linux-2.6.13/mm/rmap.c
@@ -301,7 +301,11 @@ static int page_referenced_one(struct pa
if (ptep_clear_flush_young(vma, address, pte))
referenced++;
 
-   if (mm != current->mm && !ignore_token && has_swap_token(mm))
+   /* Pretend the page is referenced if the task has the
+  swap token and is in the middle of a page fault. */
+   if (mm != current->mm && !ignore_token &&
+   has_swap_token(mm) &&
+   rwsem_is_locked(>mmap_sem))
referenced++;
 
(*mapcount)--;
Index: linux-2.6.13/mm/thrash.c
===
--- linux-2.6.13.orig/mm/thrash.c
+++ linux-2.6.13/mm/thrash.c
@@ -19,7 +19,7 @@ static unsigned long swap_token_check;
 struct mm_struct * swap_token_mm = _mm;
 
 #define SWAP_TOKEN_CHECK_INTERVAL (HZ * 2)
-#define SWAP_TOKEN_TIMEOUT 0
+#define SWAP_TOKEN_TIMEOUT 300
 /*
  * Currently disabled; Needs further code 

Re: FUSE merging?

[Miklos Szeredi]

> > Yes, it may confuse the user.  It may even confuse the kernel for
> > sticky directories(*).  But basically it just works, and is very
> > simple.
> > 
> 
> In principal, Plan 9 file servers handle permission checking
> server-side, so we could likewise punt -- but it seemed a good idea to
> have some form of mapping for directory listings (and things like
> sticky directories) to make sense.

Yes if the user/group names are available (as in 9P), then doing the
mapping based on /etc/passwd for example makes sense.

But sshfs only transfers the numeric uid/gid, and hence there's simply
no info to base any transformation on.

It could transfer /etc/passwd from the remote server, and use that to
do mapping, but that is getting more complex than the problem actually
warrants IMO.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Splitting out kernel<=>userspace ABI headers

[Denis Vlasenko]

On Saturday 03 September 2005 08:55, Kyle Moffett wrote:
> On Sep 3, 2005, at 00:28:59, Erik Andersen wrote:
> >> Absolutely not.  This would be a POSIX namespace violation; they
> >> *must* use double-underscore types.
> >
> > I assume you are worried about the stuff under asm that ends up
> > being included by nearly every header file in the world.  Of
> > course asm must use double-underscore types.  But the thing is,
> > the vast majority of the kernel headers live under
> > linux/include/linux/ and do not use double-underscore types, they
> > use kernel specific, non-underscored types such as s8, u32, etc.
> > My copy of IEEE 1003.1 and my copy of ISO/IEC 9899:1999 both fail
> > to prohibit using the shiny new ISO C99 type for the various
> > #include  header files, which is what I was suggesting.
> 
> Anything in linux/* that is included by userspace should not
> presume that stdint.h has already been included or include it on
> its own, because the userspace program may have already made its
> own definitions of uint32_t, or it may not want them defined at
> all.

Is this an excercise in academia? Userspace app which defines
uint32_t to anything different than 'typedef '
deserves the punishment, and one which does have such typedef
instead of #include stdint.h will not notice.

All these u32, uint32_t, __u32 end up typedef'ing to same
integer type anyway...

Why should we care of such 'struct uint32_t { ... };' pervert cases?
If we will do, I suspect we will end up with __u32's.
We already have a lot of __'s:

linux/cache.h:#define cacheline_aligned 
__attribute__((__aligned__(SMP_CACHE_BYTES)))
linux/rcupdate.h: typeof(p) _p1 = p; \

*three underscores* line count over kernel's include/:

# grep -r ___ . | wc -l
10129

and "only" two underscores:

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

[PATCH][1/2] fix for -mm add-sem_is_read-write_locked.patch

[Rik van Riel]

Hi Andrew,

Here is an incremental fix to the add-sem_is_read-write_locked
patch in -mm.  Also attached is a full version of that file,
which can just be dropped into place - I've verified that none
of the patches in your stack get rejects.

The reason for this change is that a lock that's held for
reading can be negative when there is a writer waiting, as
David pointed out to me a while ago.

The corresponding change to swaptoken-tuning.patch is in the
next mail.

Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>

Index: linux-2.6.13/include/asm-alpha/rwsem.h
===
--- linux-2.6.13.orig/include/asm-alpha/rwsem.h
+++ linux-2.6.13/include/asm-alpha/rwsem.h
@@ -262,14 +262,9 @@ static inline long rwsem_atomic_update(l
 #endif
 }
 
-static inline int sem_is_read_locked(struct rw_semaphore *sem)
+static inline int rwsem_is_locked(struct rw_semaphore *sem)
 {
-   return (sem->count > 0);
-}
-
-static inline int sem_is_write_locked(struct rw_semaphore *sem)
-{
-   return (sem->count < 0);
+   return (sem->count != 0);
 }
 
 #endif /* __KERNEL__ */
Index: linux-2.6.13/include/asm-i386/rwsem.h
===
--- linux-2.6.13.orig/include/asm-i386/rwsem.h
+++ linux-2.6.13/include/asm-i386/rwsem.h
@@ -284,14 +284,9 @@ LOCK_PREFIX"xadd %0,(%2)"
return tmp+delta;
 }
 
-static inline int sem_is_read_locked(struct rw_semaphore *sem)
+static inline int rwsem_is_locked(struct rw_semaphore *sem)
 {
-   return (sem->count > 0);
-}
-
-static inline int sem_is_write_locked(struct rw_semaphore *sem)
-{
-   return (sem->count < 0);
+   return (sem->count != 0);
 }
 
 #endif /* __KERNEL__ */
Index: linux-2.6.13/include/asm-ia64/rwsem.h
===
--- linux-2.6.13.orig/include/asm-ia64/rwsem.h
+++ linux-2.6.13/include/asm-ia64/rwsem.h
@@ -186,14 +186,9 @@ __downgrade_write (struct rw_semaphore *
 #define rwsem_atomic_add(delta, sem)   atomic64_add(delta, (atomic64_t 
*)(&(sem)->count))
 #define rwsem_atomic_update(delta, sem)atomic64_add_return(delta, 
(atomic64_t *)(&(sem)->count))
 
-static inline int sem_is_read_locked(struct rw_semaphore *sem)
+static inline int rwsem_is_locked(struct rw_semaphore *sem)
 {
-   return (sem->count > 0);
-}
-
-static inline int sem_is_write_locked(struct rw_semaphore *sem)
-{
-   return (sem->count < 0);
+   return (sem->count != 0);
 }
 
 #endif /* _ASM_IA64_RWSEM_H */
Index: linux-2.6.13/include/asm-ppc64/rwsem.h
===
--- linux-2.6.13.orig/include/asm-ppc64/rwsem.h
+++ linux-2.6.13/include/asm-ppc64/rwsem.h
@@ -165,12 +165,7 @@ static inline int rwsem_atomic_update(in
 
 static inline int sem_is_read_locked(struct rw_semaphore *sem)
 {
-   return (sem->count > 0);
-}
-
-static inline int sem_is_write_locked(struct rw_semaphore *sem)
-{
-   return (sem->count < 0);
+   return (sem->count != 0);
 }
 
 #endif /* __KERNEL__ */
Index: linux-2.6.13/include/asm-ppc/rwsem.h
===
--- linux-2.6.13.orig/include/asm-ppc/rwsem.h
+++ linux-2.6.13/include/asm-ppc/rwsem.h
@@ -168,14 +168,9 @@ static inline int rwsem_atomic_update(in
return atomic_add_return(delta, (atomic_t *)(>count));
 }
 
-static inline int sem_is_read_locked(struct rw_semaphore *sem)
+static inline int rwsem_is_locked(struct rw_semaphore *sem)
 {
-   return (sem->count > 0);
-}
-
-static inline int sem_is_write_locked(struct rw_semaphore *sem)
-{
-   return (sem->count < 0);
+   return (sem->count != 0);
 }
 
 #endif /* __KERNEL__ */
Index: linux-2.6.13/include/asm-s390/rwsem.h
===
--- linux-2.6.13.orig/include/asm-s390/rwsem.h
+++ linux-2.6.13/include/asm-s390/rwsem.h
@@ -351,14 +351,9 @@ static inline long rwsem_atomic_update(l
return new;
 }
 
-static inline int sem_is_read_locked(struct rw_semaphore *sem)
+static inline int rwsem_is_locked(struct rw_semaphore *sem)
 {
-   return (sem->count > 0);
-}
-
-static inline int sem_is_write_locked(struct rw_semaphore *sem)
-{
-   return (sem->count < 0);
+   return (sem->count != 0);
 }
 
 #endif /* __KERNEL__ */
Index: linux-2.6.13/include/asm-sh/rwsem.h
===
--- linux-2.6.13.orig/include/asm-sh/rwsem.h
+++ linux-2.6.13/include/asm-sh/rwsem.h
@@ -166,14 +166,9 @@ static inline int rwsem_atomic_update(in
return atomic_add_return(delta, (atomic_t *)(>count));
 }
 
-static inline int sem_is_read_locked(struct rw_semaphore *sem)
+static inline int rwsem_is_locked(struct rw_semaphore *sem)
 {
-   return (sem->count > 0);
-}
-
-static inline int sem_is_write_locked(struct rw_semaphore *sem)
-{
-   return (sem->count < 0);
+   return (sem->count != 0);
 

Re: [RFC] Splitting out kernel<=>userspace ABI headers

[H. Peter Anvin]

Erik Andersen wrote:


That is certainly not what I was proposing.  Why are you bringing
sys/stat.h into this?  The contents of sys/stat.h are entirely up
to SUSv3 and the C library to worry about.  Nobody has proposed
mucking with that.  I dunno about your C library, but mine
doesn't include linux/* header files (not even sys/stat.h).  And
I'd really like to fix uClibc to not use any asm/* either, since
much of it is entirely unsuitable for user space.



That's the whole problem here, isn't it, so let's fix it the sane way 
instead of putting Descartes before Dehorse.


Anyway, to answer your implied question is: since I explicitly don't 
have to worry about forward ABI compatibility, I expose the kernel ABI 
raw.  Thus I want to be able to use the kernel ABI directly, including 
for things like struct stat.  It poses a particularly interesting 
problem, actually, because the real stat system call is called stat64 on 
most platforms.


Thus, an ABIzed  or whatever it's called might export 
 "struct __kabi_stat" and "struct __kabi_stat64" with the expectation 
that the caller would "#define __kabi_stat64 stat" if that is the 
version they want.  A typedef isn't good enough for C, since you can't 
typedef struct tags.


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

Re: [RFC] Splitting out kernel<=>userspace ABI headers

[H. Peter Anvin]

Erik Andersen wrote:


That is certainly not what I was proposing.  Why are you bringing
sys/stat.h into this?  The contents of sys/stat.h are entirely up
to SUSv3 and the C library to worry about.  Nobody has proposed
mucking with that.  I dunno about your C library, but mine
doesn't include linux/* header files (not even sys/stat.h).  And
I'd really like to fix uClibc to not use any asm/* either, since
much of it is entirely unsuitable for user space.



I'm in particular commenting on the stat structure involved with the 
kernel interface.



I am proposing a single consistant policy for all of linux/* such
that all linux/* headers that need integer types of a specific
size shall #include unistd.h and use ISO C99 types rather that
the ad-hoc kernel types they now use.

The policy has _long_ been that user space must never include
linux/* header files.  Since we are now proposing a project to
reverse this policy, the long standing policy making linux/*
verboten now leaves us completely free to do pretty much anything
with linux/*.  And what I want is for linux/* to use the shiny
ISO C99 types.


And I'm pointing out that that you're not only excluding a whole major 
portion of the kernel ABI from this mechanism if you do that, you're 
effectively requiring new mechanisms every time something is included 
into POSIX over time!  If that isn't insane, I don't know what is.


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

Re: FUSE merging?

[Eric Van Hensbergen]

On 9/3/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > While FUSE doesn't handle it directly, doesn't it have to punt it to
> > its network file systems, how to the sshfs and what not handle this
> > sort of mapping?
> 
> Sshfs handles it by not handling it.  In this case it is neither
> possible, nor needed to be able to correctly map the id space.
> 
> Yes, it may confuse the user.  It may even confuse the kernel for
> sticky directories(*).  But basically it just works, and is very
> simple.
> 

In principal, Plan 9 file servers handle permission checking
server-side, so we could likewise punt -- but it seemed a good idea to
have some form of mapping for directory listings (and things like
sticky directories) to make sense.

   -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 03/11] memory hotplug prep: __section_nr helper

[Denis Vlasenko]

On Friday 02 September 2005 23:56, Dave Hansen wrote:
> 
> A little helper that we use in the hotplug code.
> 
> Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
> ---
> 
>  memhotplug-dave/include/linux/mmzone.h |   25 +
>  1 files changed, 25 insertions(+)
> 
> diff -puN include/linux/mmzone.h~C3-__section_nr include/linux/mmzone.h
> --- memhotplug/include/linux/mmzone.h~C3-__section_nr 2005-08-18 
> 14:59:45.0 -0700
> +++ memhotplug-dave/include/linux/mmzone.h2005-08-18 14:59:45.0 
> -0700
> @@ -511,6 +511,31 @@ static inline struct mem_section *__nr_t
>  }
>  
>  /*
> + * Although written for the SPARSEMEM_EXTREME case, this happens
> + * to also work for the flat array case becase
> + * NR_SECTION_ROOTS==NR_MEM_SECTIONS.
> + */
> +static inline int __section_nr(struct mem_section* ms)
> +{
> + unsigned long root_nr;
> + struct mem_section* root;
> +
> + for (root_nr = 0;
> +  root_nr < NR_MEM_SECTIONS;
> +  root_nr += SECTIONS_PER_ROOT) {
> + root = __nr_to_section(root_nr);
> +
> + if (!root)
> + continue;
> +
> + if ((ms >= root) && (ms < (root + SECTIONS_PER_ROOT)))
> +  break;
> + }
> +
> + return (root_nr * SECTIONS_PER_ROOT) + (ms - root);
> +}
> +
> +/*

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