Re: State of Linux graphics

[Jon Smirl]

Access has been restored. The URL is good again.

http://www.freedesktop.org/~jonsmirl/graphics.html

-- 
Jon Smirl
[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: State of Linux graphics

[Jon Smirl]

Before you shut my account off I made you this offer:

On 8/31/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> Quit being a pain and write a response to the article if you don't
> like it. Censorship is not the answer. Open debate in a public format
> is the correct response. If you want me to I'll add your reponse to
> the end of the article.

I will still include your response if you want to write one.

On 8/31/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-31 at 00:50 -0400, Jon Smirl wrote:
> > On 8/30/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> > > 'As a whole, the X.org community barely has enough resources to build a
> > > single server. Splitting these resources over many paths only results in
> > > piles of half finished projects. I know developers prefer working on
> > > whatever interests them, but given the resources available to X.org,
> > > this approach will not yield a new server or even a fully-competitive
> > > desktop based on the old server in the near term. Maybe it is time for
> > > X.org to work out a roadmap for all to follow.'
> > >
> > > You lose.
> >
> > Daniel Stone, the administrator of freedesk.org, has just taken it
> > upon himself to censor my article on the state of the X server. His
> > lame excuse is that I have stopped working the core of Xegl. It
> > doesn't seem to matter that I contributed 1,000s of lines of code to
> > fd.o that I am continuing to do maintenance on. So much for this being
> > a free desktop.
> 
> Sigh.  As I explained in the long thread we had in private mail, I have
> done several cleanups now on inactive accounts and projects.  You are
> absolutely not the first, and will not be the last.  I have not done
> such sweeps for a while, because I have not had time.  The realisation
> that your account was doing nothing other than hosting an HTML page now
> that I have some amount of time to look at fd.o again was enough to spur
> me to start a cleanup, and indeed, I am in the process of pinging many
> other dormant contributors; many of which have merely stopped working on
> X and may return, rather than having posted long statements of
> resignation to the list.
> 
> And, as I explained, a simple statement of intent from you that you
> intend to resume active development will be enough to justify your
> account being renewed.
> 
> (Alternately, if another administrator re-enables your account, I will
> not stop this.  I'm not the sole admin, not by far ...)
> 
> Possibly impolitic and bad timing, sure.  But my intent was not to
> censor.
> 
> > Can some else provide a place for me to host the article?
> 
> Is the wiki insufficient?  It is currently hosting such insignificant
> articles as the 6.9/7.0 release plan, f.e. ...
> 
> 


-- 
Jon Smirl
[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: State of Linux graphics

[Jon Smirl]

On 8/31/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-31 at 00:50 -0400, Jon Smirl wrote:
> > On 8/30/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> > > 'As a whole, the X.org community barely has enough resources to build a
> > > single server. Splitting these resources over many paths only results in
> > > piles of half finished projects. I know developers prefer working on
> > > whatever interests them, but given the resources available to X.org,
> > > this approach will not yield a new server or even a fully-competitive
> > > desktop based on the old server in the near term. Maybe it is time for
> > > X.org to work out a roadmap for all to follow.'
> > >
> > > You lose.
> >
> > Daniel Stone, the administrator of freedesk.org, has just taken it
> > upon himself to censor my article on the state of the X server. His
> > lame excuse is that I have stopped working the core of Xegl. It
> > doesn't seem to matter that I contributed 1,000s of lines of code to
> > fd.o that I am continuing to do maintenance on. So much for this being
> > a free desktop.
> 
> Sigh.  As I explained in the long thread we had in private mail, I have
> done several cleanups now on inactive accounts and projects.  You are
> absolutely not the first, and will not be the last.  I have not done
> such sweeps for a while, because I have not had time.  The realisation
> that your account was doing nothing other than hosting an HTML page now
> that I have some amount of time to look at fd.o again was enough to spur
> me to start a cleanup, and indeed, I am in the process of pinging many
> other dormant contributors; many of which have merely stopped working on
> X and may return, rather than having posted long statements of
> resignation to the list.
> 
> And, as I explained, a simple statement of intent from you that you
> intend to resume active development will be enough to justify your
> account being renewed.

I told you multiple times that I am doing bug fixes and maintenance on
1,000s of lines of contributed code. Is that not a valid reason to
have an account? So only people writing new code can have accounts? I
guess you will have to disable half of all the accounts on fd.o to
enforce that policy.

You censored the article. 

>From the fd.o account policy page:
http://www.freedesktop.org/wiki/AccountRequests

What the Project Leader does
  Review and approve the request for an account & access to your project.

I believe I am a member of five projects on fd.o and you are not the
Project Leader of any of them. I would like to see the request from
the Project Leaders for my account removal.


> 
> (Alternately, if another administrator re-enables your account, I will
> not stop this.  I'm not the sole admin, not by far ...)
> 
> Possibly impolitic and bad timing, sure.  But my intent was not to
> censor.
> 
> > Can some else provide a place for me to host the article?
> 
> Is the wiki insufficient?  It is currently hosting such insignificant
> articles as the 6.9/7.0 release plan, f.e. ...
> 
> 


-- 
Jon Smirl
[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: jack, PREEMPT_DESKTOP, delayed interrupts?

[Fernando Lopez-Lezcano]

On Tue, 2005-08-30 at 19:39, Lee Revell wrote:
> On Tue, 2005-08-30 at 19:03 -0700, Fernando Lopez-Lezcano wrote:
> > Hi, I'm starting to look at a strange problem. The configuration is:
> > hardware: AMD X2 4400+ dual core, NForce3 chipset, Midiman 66 soundcard
> > software: 2.6.13 smp + patch-2.6.13-rt1, PREEMPT_DESKTOP
> >   jack 0.100.4, current cvs
> >   alsa 1.0.10rc1
> > 
> 
> Enable all latency debug options and post the contents
> of /proc/latency_trace when this happens. 

Will try to, I'm about to go on a trip so that may have to wait. 

> Also what file system are you using? 

Ext3, Jack mounts its pipes and stuff in /dev/shm

>  And is the SMT scheduler enabled?

Is this it?: CONFIG_SCHED_SMT=y

-- Fernando


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

Re: strange CPU speedups with SMP on Athlon 64 X2

[Willy Tarreau]

Hi,

stupid question : isn't it possible that your motherboard does some sort of
overclocking when it detects high cpu usage (bus activity, etc...) ? It
should not be easy to check (rdtsc every second ?), but you might want to
explore such a possibility.

Regards,
willy

On Tue, Aug 30, 2005 at 12:16:04PM -0700, Nathan Becker wrote:
> Hi,
> 
> I'm having a strange problem when I benchmark some of my physics 
> simulation code on my new Athlon 64 X2 4800 machine.  It occurs on all 
> current kernels that I have tested including 2.6.12.5 and 2.6.13.
> 
> If I run my benchmark single threaded, so that one of the two CPU cores 
> is just idling then the calculation goes pretty fast.  But if I load both 
> CPU cores simultaneously but with INDEPENDENT calculations, then each 
> calculation runs about 12-15% faster than when running alone.  I have 
> found this to be always reproducible.  There is no disk access involved 
> in the calculation and RAM usage is fairly minimal so this is not caused 
> by caching. Also, if I compile the kernel to disable SMP then the machine 
> runs a single calculation at the same speed as when running alone when 
> SMP is enabled.
> 
> I am aware of the timing issues on these machines (especially since I 
> reported the bug http://bugzilla.kernel.org/show_bug.cgi?id=5105 ). 
> However, I double-checked my benchmark with a stop-watch, so this is 
> independent of something strange happening in the timer.
> 
> I also checked the cpufreq governor and according to the logs, my CPU is 
> holding steady at the maximum setting of 2.4GHz.  I set the governor to 
> "performance" mode which should prevent unintended downclocking.
> 
> I would be happy to post my exact C source that I use to do the 
> benchmark, but I wanted to get some feedback first in case I'm just doing 
> something stupid.  Also, since I'm not subscribed to this list, please cc 
> me directly regarding this topic.
> 
> Thanks very much,
> 
> Nathan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] blk queue io tracing support

[Tom Zanussi]

Nathan Scott writes:
 > Hi Tom,
 > 
 > On Tue, Aug 30, 2005 at 11:19:04PM -0500, Tom Zanussi wrote:
 > > You're right, it should be using simple_rmdir rather than
 > > simple_unlink for removing directories.  Thanks for sending the patch,
 > 
 > No problem.
 > 
 > > which I've modified a bit to avoid splitting the rmdir/unlink cases
 > > into separate functions, since they're almost the same except for what
 > > they end up calling.  relayfs_remove_dir now doesn't do anything but
 > > call relayfs_remove (it didn't do much more than that before anyway),
 > > but it makes sense to me to keep it, as the counterpart to
 > > relayfs_create_dir.  Let me know if you see any problems with it.
 > 
 > Looks OK, I'll give it a spin.
 > 
 > On an unrelated note, are there any known issues with using epoll
 > on relayfs file descriptors?  I'm having a few troubles, and just
 > wondering if its me doing something silly, or if its known to not
 > work...?  Symptoms of the problem are epoll continually reaching
 > its timeout with no modified fds found (when I know the inode has
 > modified trace buffers attached) ... and the epoll code is a bit
 > too hairy for me to go find a quick fix - seems like it should be
 > able to work though since relayfs has a ->poll implementation.

Well, the relayfs poll implementation is based on completed
sub-buffers, so you can be writing events into a buffer, but until a
buffer switch happens, you won't be notified that anything's changed.
The reason for the sub-buffer granularity is that relayfs was
originally meant for use only with mmap(), but now that there's a
read(), I'll probably have to make some changes to the poll
implementation as well.

Tom


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

Re: [PATCH] blk queue io tracing support

[Nathan Scott]

On Wed, Aug 31, 2005 at 02:33:10PM +1000, Nathan Scott wrote:
> ...
> On an unrelated note, are there any known issues with using epoll
> on relayfs file descriptors?  I'm having a few troubles, and just
> wondering if its me doing something silly, or if its known to not
> work...?  Symptoms of the problem are epoll continually reaching
> its timeout with no modified fds found (when I know the inode has
> modified trace buffers attached) ...

Actually, poll(2) seems to have the same behaviour with a simpler
test case (i.e. no epoll, & with just one fd being polled) - if I
read(2) from it every few thousand usec (using the blktrace tool)
it sees new data, but if I poll, it never reports the descriptor
as changed (this is a 2.6.13 kernel with the relayfs patches from
-mm patched into it and Jens' blktrace patch generating the data
that I'm attempting to poll).

cheers.

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

Re: State of Linux graphics

[Jon Smirl]

On 8/30/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> > The article has been reviewed but if it still contains technical
> > errors please let me know. Opinions on the content are also
> > appreciated.
> 
> 'As a whole, the X.org community barely has enough resources to build a
> single server. Splitting these resources over many paths only results in
> piles of half finished projects. I know developers prefer working on
> whatever interests them, but given the resources available to X.org,
> this approach will not yield a new server or even a fully-competitive
> desktop based on the old server in the near term. Maybe it is time for
> X.org to work out a roadmap for all to follow.'
> 
> You lose.

Daniel Stone, the administrator of freedesk.org, has just taken it
upon himself to censor my article on the state of the X server. His
lame excuse is that I have stopped working the core of Xegl. It
doesn't seem to matter that I contributed 1,000s of lines of code to
fd.o that I am continuing to do maintenance on. So much for this being
a free desktop.

Can some else provide a place for me to host the article?

On 8/30/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
>On Wed, 2005-08-31 at 00:37 -0400, Jon Smirl wrote:
>> Because I have written thousand of lines of code that are in the fd.o
>> repositories and I need access in order to do maintenance on them.

>Your account has been temporarily disabled in line with your assertion
>that you have stopped work on Xegl.  If you have small patches, I
>recommend submitting through Bugzilla.  If you intend to resume active
>development, please ping me and I can re-enable it.

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

Re: [PATCH] blk queue io tracing support

[Nathan Scott]

Hi Tom,

On Tue, Aug 30, 2005 at 11:19:04PM -0500, Tom Zanussi wrote:
> You're right, it should be using simple_rmdir rather than
> simple_unlink for removing directories.  Thanks for sending the patch,

No problem.

> which I've modified a bit to avoid splitting the rmdir/unlink cases
> into separate functions, since they're almost the same except for what
> they end up calling.  relayfs_remove_dir now doesn't do anything but
> call relayfs_remove (it didn't do much more than that before anyway),
> but it makes sense to me to keep it, as the counterpart to
> relayfs_create_dir.  Let me know if you see any problems with it.

Looks OK, I'll give it a spin.

On an unrelated note, are there any known issues with using epoll
on relayfs file descriptors?  I'm having a few troubles, and just
wondering if its me doing something silly, or if its known to not
work...?  Symptoms of the problem are epoll continually reaching
its timeout with no modified fds found (when I know the inode has
modified trace buffers attached) ... and the epoll code is a bit
too hairy for me to go find a quick fix - seems like it should be
able to work though since relayfs has a ->poll implementation.

cheers.

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

Re: Where is the performance bottleneck?

[Al Boldi]

Holger Kiehl wrote:
> On Mon, 29 Aug 2005, Al Boldi wrote:
> > You may be hitting a 2.6 kernel bug, which has something to do with
> > readahead, ask Jens Axboe about it! (see "[git patches] IDE update"
> > thread) Sadly, 2.6.13 did not fix it either.
>
> I did read that threat, but due to my limited understanding about kernel
> code, don't see the relation to my problem.

Basically the kernel is loosing CPU cycles while accessing bockdevices.
The problem shows most when the CPU/DISK ratio is low.
Throwing more CPU cycles at the problem may seemingly remove this bottleneck.

> But I am willing to try any patches to solve the problem.

No patches yet.

> > Did you try 2.4.31?
>
> No. Will give this a try if the problem is not found.

Keep us posted!

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

Re: State of Linux graphics

[Jon Smirl]

On 8/30/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> > The article has been reviewed but if it still contains technical
> > errors please let me know. Opinions on the content are also
> > appreciated.
> 
> 'As a whole, the X.org community barely has enough resources to build a
> single server. Splitting these resources over many paths only results in
> piles of half finished projects. I know developers prefer working on
> whatever interests them, but given the resources available to X.org,
> this approach will not yield a new server or even a fully-competitive
> desktop based on the old server in the near term. Maybe it is time for
> X.org to work out a roadmap for all to follow.'
> 
> You lose.

I am not a member of the X.org board or any of it's committees. I have
no control over what path X.org may choose to follow. All I did was
make a proposal. Everyone else is free to make proposals too. X.org
may choose to endorse one or continue business as usual.

-- 
Jon Smirl
[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: Ignore disabled ROM resources at setup

[Benjamin Herrenschmidt]

Here's a new patch based on Linus latest one with better error checking.
Please push if you are fine with it.

This patch fixes a problem with pci_map_rom() which doesn't properly
update the ROM BAR value with the address thas allocated for it by the
PCI code. This problem, among other, breaks boot on Mac laptops.

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>


Index: linux-work/drivers/pci/rom.c
===
--- linux-work.orig/drivers/pci/rom.c   2005-08-01 22:03:44.0 +1000
+++ linux-work/drivers/pci/rom.c2005-08-31 14:09:02.0 +1000
@@ -21,13 +21,21 @@
  * between the ROM and other resources, so enabling it may disable access
  * to MMIO registers or other card memory.
  */
-static void pci_enable_rom(struct pci_dev *pdev)
+static int pci_enable_rom(struct pci_dev *pdev)
 {
+   struct resource *res = pdev->resource + PCI_ROM_RESOURCE;
+   struct pci_bus_region region;
u32 rom_addr;
 
+   if (!res->flags)
+   return -1;
+
+   pcibios_resource_to_bus(pdev, , res);
pci_read_config_dword(pdev, pdev->rom_base_reg, _addr);
-   rom_addr |= PCI_ROM_ADDRESS_ENABLE;
+   rom_addr &= ~PCI_ROM_ADDRESS_MASK;
+   rom_addr |= region.start | PCI_ROM_ADDRESS_ENABLE;
pci_write_config_dword(pdev, pdev->rom_base_reg, rom_addr);
+   return 0;
 }
 
 /**
@@ -71,19 +79,21 @@
} else {
if (res->flags & IORESOURCE_ROM_COPY) {
*size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
-   return (void __iomem *)pci_resource_start(pdev, 
PCI_ROM_RESOURCE);
+   return (void __iomem *)pci_resource_start(pdev,
+PCI_ROM_RESOURCE);
} else {
/* assign the ROM an address if it doesn't have one */
-   if (res->parent == NULL)
-   pci_assign_resource(pdev, PCI_ROM_RESOURCE);
-
+   if (res->parent == NULL &&
+   pci_assign_resource(pdev,PCI_ROM_RESOURCE))
+   return NULL;
start = pci_resource_start(pdev, PCI_ROM_RESOURCE);
*size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
if (*size == 0)
return NULL;
 
/* Enable ROM space decodes */
-   pci_enable_rom(pdev);
+   if (pci_enable_rom(pdev))
+   return NULL;
}
}
 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] blk queue io tracing support

[Tom Zanussi]

Nathan Scott writes:
 > Hi there,
 > 
 > On Wed, Aug 31, 2005 at 09:48:23AM +1000, Nathan Scott wrote:
 > > ...
 > > # find /relay
 > > /relay
 > > /relay/block
 > > /relay/block/sdd
 > > /relay/block/sdd/trace3
 > > /relay/block/sdd/trace2
 > > /relay/block/sdd/trace1
 > > /relay/block/sdd/trace0
 > > /relay/block/sdb
 > > /relay/block/sdb/trace3
 > > /relay/block/sdb/trace2
 > > /relay/block/sdb/trace1
 > > /relay/block/sdb/trace0
 > > 
 > > and does the correct dynamic setup and teardown of the hierarchy
 > > as the userspace tool starts and stops tracing.  I had to modify
 > > the relayfs rmdir code a bit to make this work properly, I'll
 > > send a separate patch for that shortly.
 > 
 > Here it is.  The problem was that relayfs is allowing a directory
 > with children to be removed rather than returning -ENOTEMPTY.  It
 > looks like this can be resolved by splitting the shared relayfs
 > unlink code (which is using simple_unlink) into separate file/dir
 > variants, one using simple_unlink, the other using simple_rmdir.
 > 

Hi,

You're right, it should be using simple_rmdir rather than
simple_unlink for removing directories.  Thanks for sending the patch,
which I've modified a bit to avoid splitting the rmdir/unlink cases
into separate functions, since they're almost the same except for what
they end up calling.  relayfs_remove_dir now doesn't do anything but
call relayfs_remove (it didn't do much more than that before anyway),
but it makes sense to me to keep it, as the counterpart to
relayfs_create_dir.  Let me know if you see any problems with it.

Thanks,

Tom

--- inode.c~2005-08-31 04:08:07.0 -0500
+++ inode.c 2005-08-31 03:44:40.0 -0500
@@ -189,26 +189,39 @@ struct dentry *relayfs_create_dir(const 
 /**
  * relayfs_remove - remove a file or directory in the relay filesystem
  * @dentry: file or directory dentry
+ *
+ * Returns 0 if successful, negative otherwise.
  */
 int relayfs_remove(struct dentry *dentry)
 {
-   struct dentry *parent = dentry->d_parent;
+   struct dentry *parent;
+   int error = 0;
+
+   if (!dentry)
+   return -EINVAL;
+   parent = dentry->d_parent;
if (!parent)
return -EINVAL;
 
parent = dget(parent);
down(>d_inode->i_sem);
if (dentry->d_inode) {
-   simple_unlink(parent->d_inode, dentry);
-   d_delete(dentry);
+   if (S_ISDIR(dentry->d_inode->i_mode))
+   error = simple_rmdir(parent->d_inode, dentry);
+   else
+   error = simple_unlink(parent->d_inode, dentry);
+   if (!error)
+   d_delete(dentry);
}
-   dput(dentry);
+   if (!error)
+   dput(dentry);
up(>d_inode->i_sem);
dput(parent);
 
-   simple_release_fs(_mount, _mount_count);
+   if (!error)
+   simple_release_fs(_mount, _mount_count);
 
-   return 0;
+   return error;
 }
 
 /**
@@ -219,9 +232,6 @@ int relayfs_remove(struct dentry *dentry
  */
 int relayfs_remove_dir(struct dentry *dentry)
 {
-   if (!dentry)
-   return -EINVAL;
-
return relayfs_remove(dentry);
 }
 


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

Re: inotify and IN_UNMOUNT-events

[Kyle Moffett]

On Aug 30, 2005, at 23:33:27, Robert Love wrote:

On Tue, 2005-08-30 at 21:46 +0200, Juergen Quade wrote:


Playing around with inotify I have some problems
to generate/receive IN_UNMOUNT-events (using
a self written application and inotify_utils-0.25;
kernel 2.6.13).

Doing:
- mount /dev/hda1 /mnt
- add a watch to the path /mnt/ ("./inotify_test /mnt")
- umount /mnt

results in two events:
1. IN_DELETE_SELF (mask=0x0400)
2. IN_IGNORED (mask=0x8000)

Any ideas?


"/mnt" is not unmounted, stuff inside of it is.

Watch, say, "/mnt/foo/bar" and when /dev/hda1 is unmounted, you  
will get

an IN_UNMOUNT on the watch.


I think this might work as well:
# mount /dev/hda1 /mnt
# ./inotify_test /mnt/. &
# umount /mnt

That should get the effect you are looking for

Cheers,
Kyle Moffett

--
I have yet to see any problem, however complicated, which, when you  
looked at

it in the right way, did not become still more complicated.
  -- Poul Anderson



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

Re: inotify and IN_UNMOUNT-events

[Robert Love]

On Tue, 2005-08-30 at 21:46 +0200, Juergen Quade wrote:
> Playing around with inotify I have some problems
> to generate/receive IN_UNMOUNT-events (using
> a self written application and inotify_utils-0.25;
> kernel 2.6.13).
> 
> Doing:
> - mount /dev/hda1 /mnt
> - add a watch to the path /mnt/ ("./inotify_test /mnt")
> - umount /mnt
> 
> results in two events:
> 1. IN_DELETE_SELF (mask=0x0400)
> 2. IN_IGNORED (mask=0x8000)
> 
> Any ideas?

"/mnt" is not unmounted, stuff inside of it is.

Watch, say, "/mnt/foo/bar" and when /dev/hda1 is unmounted, you will get
an IN_UNMOUNT on the watch.

Robert Love


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

Re: State of Linux graphics

[Daniel Stone]

On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> The article has been reviewed but if it still contains technical
> errors please let me know. Opinions on the content are also
> appreciated.

'As a whole, the X.org community barely has enough resources to build a
single server. Splitting these resources over many paths only results in
piles of half finished projects. I know developers prefer working on
whatever interests them, but given the resources available to X.org,
this approach will not yield a new server or even a fully-competitive
desktop based on the old server in the near term. Maybe it is time for
X.org to work out a roadmap for all to follow.'

You lose.

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

Re: jack, PREEMPT_DESKTOP, delayed interrupts?

[Lee Revell]

On Tue, 2005-08-30 at 19:03 -0700, Fernando Lopez-Lezcano wrote:
> Hi, I'm starting to look at a strange problem. The configuration is:
> hardware: AMD X2 4400+ dual core, NForce3 chipset, Midiman 66 soundcard
> software: 2.6.13 smp + patch-2.6.13-rt1, PREEMPT_DESKTOP
>   jack 0.100.4, current cvs
>   alsa 1.0.10rc1
> 

Enable all latency debug options and post the contents
of /proc/latency_trace when this happens.  Also what file system are you
using?  And is the SMT scheduler enabled?

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/

jack, PREEMPT_DESKTOP, delayed interrupts?

[Fernando Lopez-Lezcano]

Hi, I'm starting to look at a strange problem. The configuration is:
hardware: AMD X2 4400+ dual core, NForce3 chipset, Midiman 66 soundcard
software: 2.6.13 smp + patch-2.6.13-rt1, PREEMPT_DESKTOP
  jack 0.100.4, current cvs
  alsa 1.0.10rc1

This is the sequence of events. Start Jack inside Qjackctl (a Jack Audio
Connection Kit GUI front end) with 2 x 128 frames, start Ardour (a
digital audio workstation) - load a very simple recording session, start
Hydrogen (a drum machine). Play around with them, everything seems to
work fine. No glitches, very solid performance. 

Do a "tar cvf usr.tar /usr" just to read/write a lot to disk (this
within the same SATA disk). Watch memory being used in a system monitor
applet up to 100%. After a while, hard to say how long (maybe 10/15
minutes?) the system eventually can get into a state where Jack starts
printing messages of the type "delay of 3856.000 usecs exceeds estimated
spare time of 2653.000; restart ..." (if I understand correctly this
means interrupts are being delayed on their way to Jack, or at least
Jack thinks they are arriving too late), along with some less frequent
xun notices. 

Now the strange thing is that this condition seems to be persistent.
Nothing I do after it starts to happen seems to halt those messages.
Including stopping Jack and starting it again, and even (tried it once)
stopping the alsa sound driver and loading it again. Nothing out of the
ordinary in dmesg or /var/log/messages. I would guess that something
"breaks" inside the kernel with regards to interrupt handling and/or
whatever Jack uses to measure time inside the kernel? Interrupts are
prioritized correctly (rtc, then audio and jack runs at lower realtime
priority than the audio interrupts), everything else looks fine. 

I could not get this to happen while running a uniprocessor kernel on
the same machine but I may not have tried long enough. I do see a "delay
exceeds" or "xun" message every once in a while but not a steady,
unstoppable stream of them. 

This seemed to be much worse, or easier to trigger, when running an
older realtime-preempt-2.6.12-final-V0.7.51-27 smp kernel. 

I don't know what information may be useful to even start making some
sense out of this. 

-- Fernando


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/1] Ptrace - i386: fix "syscall audit" interaction with singlestep

[Andrew Morton]

[EMAIL PROTECTED] wrote:
>
> 
> From: Bodo Stroesser <[EMAIL PROTECTED]>, Paolo 'Blaisorblade' Giarrusso 
> <[EMAIL PROTECTED]>
> CC: Roland McGrath <[EMAIL PROTECTED]>
> 
> Avoid giving two traps for singlestep instead of one, when syscall auditing is
> enabled.
> 
> In fact no singlestep trap is sent on syscall entry, only on syscall exit, as
> can be seen in entry.S:
> 
> # Note that in this mask _TIF_SINGLESTEP is not tested !!! <<
> testb 
> $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP),TI_flags(%ebp)
> jnz syscall_trace_entry
>   ...
> syscall_trace_entry:
>   ...
>   call do_syscall_trace
> 
> But auditing a SINGLESTEP'ed process causes do_syscall_trace to be called, so
> the tracer will get one more trap on the syscall entry path, which it
> shouldn't.
> 
> This does not affect (to my knowledge) UML, nor is critical, so this shouldn't
> IMHO go in 2.6.13.
> 
> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
> ---
> 
>  linux-2.6.git-paolo/arch/i386/kernel/ptrace.c |   15 +--
>  1 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff -puN arch/i386/kernel/ptrace.c~sysaudit-singlestep-non-umlhost 
> arch/i386/kernel/ptrace.c
> --- linux-2.6.git/arch/i386/kernel/ptrace.c~sysaudit-singlestep-non-umlhost   
> 2005-07-26 20:22:40.0 +0200
> +++ linux-2.6.git-paolo/arch/i386/kernel/ptrace.c 2005-07-26 
> 20:23:44.0 +0200
> @@ -683,8 +683,19 @@ void do_syscall_trace(struct pt_regs *re
>   /* do the secure computing check first */
>   secure_computing(regs->orig_eax);
>  
> - if (unlikely(current->audit_context) && entryexit)
> - audit_syscall_exit(current, AUDITSC_RESULT(regs->eax), 
> regs->eax);
> + if (unlikely(current->audit_context)) {
> + if (entryexit)
> + audit_syscall_exit(current, AUDITSC_RESULT(regs->eax), 
> regs->eax);
> +
> + /* Debug traps, when using PTRACE_SINGLESTEP, must be sent only
> +  * on the syscall exit path. Normally, when TIF_SYSCALL_AUDIT is
> +  * not used, entry.S will call us only on syscall exit, not
> +  * entry ; so when TIF_SYSCALL_AUDIT is used we must avoid
> +  * calling send_sigtrap() on syscall entry.
> +  */
> + else if (is_singlestep)
> + goto out;
> + }
>  

This appears to be a UML patch, applied to x86, which has no `is_singlestep'.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] libata: add ATAPI module option

[Jeff Garzik]

Mark Lord wrote:

Jeff Garzik wrote:



-#ifndef ATA_ENABLE_ATAPI
-if (unlikely(dev->class == ATA_DEV_ATAPI))
-return NULL;
-#endif
+if (atapi_enabled) {
+if (unlikely(dev->class == ATA_DEV_ATAPI))
+return NULL;
+}


..

Is that if-stmt the right way around?
At first glance, I'd expect it to read:

 if (!atapi_enabled) {
 ...

Cheers!


Indeed, thanks, fixed.

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: KLive: Linux Kernel Live Usage Monitor

[Andrea Arcangeli]

On Tue, Aug 30, 2005 at 06:11:26PM -0400, Bill Davidsen wrote:
> the system, like load. A week running while I was on vacation doesn't 
> test much, a week running on a loaded server tests other things.

btw, I thought about adding the load average too but it wasn't really
interesting, since sometime a server is stressed a lot for a few minutes
and then goes back to idle mode. A kernel bug will not necessairly
trigger because some app is I/O bound all the time. Certainly more load
is a factor that increases the probability of bugs and race conditions
though, it's just not obvious how to assign a 0/100% score to a certain
KLive "session".

> The use will depend on how easy it is to install, patch and build isn't 
> easy. Crontab is. And I bet developers would be interested in how long 

crontab really is easy and standard, crontab seems actually the only way I
could really write the few liner autoinstall script.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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][FAT] FAT dirent scan with hin take #2

[OGAWA Hirofumi]

OGAWA Hirofumi <[EMAIL PROTECTED]> writes:

> This patch couldn't compile. I assume you post a wrong patch...?
 ^
 version
-- 
OGAWA Hirofumi <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i386, x86_64 Initial PAT implementation

[Eric W. Biederman]

Dave Jones <[EMAIL PROTECTED]> writes:

> On Tue, Aug 30, 2005 at 03:45:36PM +0100, Alan Cox wrote:
>  > On Llu, 2005-08-29 at 18:20 -0600, Eric W. Biederman wrote:
>  > > ways.  Currently this code only allows for an additional flavor
>  > > of uncached access to physical memory addresses which should be hard
>  > > to abuse, and should raise no additional aliasing problems.  No
>  > > attempt has been made to fix theoretical aliasing problems.
>  > 
>  > Even an uncached/cached alias causes random memory corruption or an MCE
>  > on x86 systems. In fact it can occur even for an alias not in theory
>  > touched by the CPU if it happens to prefetch into or speculate the
>  > address.
>  > 
>  > Also be sure to read the PII Xeon errata - early PAT has a bug or two.
>
> There are various PAT errata all the way through to Pentium-M iirc.

Thanks, I have just read through all of them and none of them look
like a problem.

The primary issue is that you can't count on being able to use
the upper 4 PAT entries.

The most painful is that on the Pentium-III and I believe on the Pentium-M
there are occasions where PAT will fail to promote an UC entry from
the mtrrs to WC.  The page will remain UC resulting in louzy performance.

It looks like you can hard hang a Pentium-4 by mixing uncached and
writeback memory attributes.

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: Trailing comments in broken-out series file break quilt

[Paul Jackson]

Jean wrote:
> You should simply be using an up-to-date version of quilt, namely
> version 0.42, which supports Andrew-style comments in series files just
> fine.

Right you are - that works too.  Thanks for the good work on quilt
and thanks for pointing this out.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/1 2.6.13] framebuffer: bit_putcs() optimization for 8x* fonts

[Antonino A. Daplas]

Knut Petersen wrote:
> This trivial patch gives a performance boost to the framebuffer console
> 
> Constructing the bitmaps that are given to the bitblit functions of the
> framebuffer
> drivers is time consuming. Here we avoide a call to the slow
> fb_pad_aligned_buffer().
> The patch replaces that call with a simple but much more efficient
> bytewise copy.
> 
> The kernel spends a significant time at this place if you use 8x* fonts.
> Every
> pixel displayed on your screen is prepared here.
> 
> Some benchmark results:
> 
> Displaying a file of 2000 lines with 160 characters each takes 889 ms
> system
> time using  cyblafb on my system  (I´m using a 1280x1024 video mode,
> resulting in a 160x64 character console)
> 
> Displaying the same file with the enclosed patch applied to 2.6.13 only
> takes
> 760 ms system time, saving 129 ms or 14.5%.

Where did this 14.5% come from?  Is it bit_putcs alone or is more
real world, such as 'time cat text_file'? If I'm to guess, a large
percent of the improvement is caused by the inlining of the code.

I'm not against the patch, it will benefit drivers with very fast
imageblits.  However, since most drivers have imageblits done in software,
a large proportion of the processing time will go to the imageblit itself,
so I don't think you'll get that high a number (I get only a 4%
improvement, and this is in a driver with accelerated blits, and it will
probably be lower, ie, in vesafb).

Anyway, with the addition of your patch, bit_putcs has now reached an
'ugliness threshhold' for a revamp.

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

Re: [Linux-fbdev-devel] [PATCH 1/1 2.6.13] framebuffer: bit_putcs() optimization for 8x* fonts

[Antonino A. Daplas]

Knut Petersen wrote:
> fb_pad_aligned_buffer() is also slower for those cases. But does anybody
> use such fonts?

Yes, there are 16x30 fonts out there in the wild. 

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

Re: 2.6.13-rt1

[Steven Rostedt]

On Tue, 2005-08-30 at 15:34 -0700, Daniel Walker wrote:
> Have you tried turning on 
> "Non-preemptible critical section latency timing" or "Latency tracing"

I just turned on the following:

  CONFIG_CRITICAL_PREEMPT_TIMING
  CONFIG_CRITICAL_IRQSOFF_TIMING
  CONFIG_LATENCY_TRACE

recompiled and booted.  No problem here.

> 
> I don't know if it's related to the PI changes, but I'm getting a crash
> with those on em64t .
> 
> With both above options I get
> 
> <0>init[1]: segfault at 8010ef44 rip 8010ef44 rsp 
> 7error 5
> <0>init[1]: segfault at 8010ef44 rip 8010ef44 rsp 
> 7ffe8de8 error 5
> 
> printed never ending right after init starts.
> 
> If I only turn on "Non-preemptible critical section latency timing",
> then when I enter the command,
> "echo 0 > /proc/sys/kernel/preempt_max_latency"
> 
> The kernel will spit out a couple of max critical section updates , then
> it will hang silently.
> 
> This is all new in 2.6.13-rtX . It could have just come in with 2.6.13 ,
> but I thought I'd mention it.

Did you try the latest patches I just sent. Mainly this last one on
-rt2?  There is a deadlock that is fixed wrt the BKL.

-- Steve


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

Re: [Linux-fbdev-devel] [PATCH 1/1 2.6.13] framebuffer: bit_putcs() optimization for 8x* fonts

[Roman Zippel]

Hi,

On Wed, 31 Aug 2005, Knut Petersen wrote:

> How could I make it an inline function? It is used in console/bitblit.c,
> nvidia/nvidia.c,
> riva/fbdev.c and softcursor.c.

Something like below, which has the advantange that there is still only 
one implementation of the function and if it's still slower, we really 
need to check the compiler.

bye, Roman

 drivers/video/console/bitblit.c |5 -
 drivers/video/fbmem.c   |   10 +-
 include/linux/fb.h  |   13 +
 3 files changed, 18 insertions(+), 10 deletions(-)

Index: linux-2.6/drivers/video/fbmem.c
===
--- linux-2.6.orig/drivers/video/fbmem.c2005-08-30 21:17:44.0 
+0200
+++ linux-2.6/drivers/video/fbmem.c 2005-08-31 01:20:37.0 +0200
@@ -80,15 +80,7 @@ EXPORT_SYMBOL(fb_get_color_depth);
  */
 void fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 s_pitch, u32 
height)
 {
-   int i, j;
-
-   for (i = height; i--; ) {
-   /* s_pitch is a few bytes at the most, memcpy is suboptimal */
-   for (j = 0; j < s_pitch; j++)
-   dst[j] = src[j];
-   src += s_pitch;
-   dst += d_pitch;
-   }
+   __fb_pad_aligned_buffer(dst, d_pitch, src, s_pitch, height);
 }
 EXPORT_SYMBOL(fb_pad_aligned_buffer);
 
Index: linux-2.6/drivers/video/console/bitblit.c
===
--- linux-2.6.orig/drivers/video/console/bitblit.c  2005-08-30 
01:55:20.0 +0200
+++ linux-2.6/drivers/video/console/bitblit.c   2005-08-31 01:25:30.0 
+0200
@@ -175,7 +175,10 @@ static void bit_putcs(struct vc_data *vc
src = buf;
}
 
-   fb_pad_aligned_buffer(dst, pitch, src, idx, 
image.height);
+   if (likely(idx == 1))
+   __fb_pad_aligned_buffer(dst, pitch, 
src, 1, image.height);
+   else
+   fb_pad_aligned_buffer(dst, pitch, src, 
idx, image.height);
dst += width;
}
}
Index: linux-2.6/include/linux/fb.h
===
--- linux-2.6.orig/include/linux/fb.h   2005-08-30 01:56:29.0 +0200
+++ linux-2.6/include/linux/fb.h2005-08-31 01:21:04.0 +0200
@@ -824,6 +824,19 @@ extern int fb_get_color_depth(struct fb_
 extern int fb_get_options(char *name, char **option);
 extern int fb_new_modelist(struct fb_info *info);
 
+static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 
s_pitch, u32 height)
+{
+   int i, j;
+
+   d_pitch -= s_pitch;
+   for (i = height; i--; ) {
+   /* s_pitch is a few bytes at the most, memcpy is suboptimal */
+   for (j = 0; j < s_pitch; j++)
+   *dst++ = *src++;
+   dst += d_pitch;
+   }
+}
+
 extern struct fb_info *registered_fb[FB_MAX];
 extern int num_registered_fb;
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ANNOUNCE][RFC] PlugSched-6.1 for 2.6.13

[Peter Williams]

This version contains a modified spa_ws scheduler with a more persistent 
bonus mechanism. Although the "bonus only at wake up" mechanism of the 
original worked well on the first systems it was tested on (an old SMP 
system and a 3GHz SMT system) subsequent tests on a 2GHz single 
processor system were disappointing.  (Apart from a bug in the original 
implementation) the primary reason for this was that the X server was 
not always able to complete its work in the first time slice after 
waking and had to try and complete it without the benefit of the bonus 
which causes obvious delays when the system is loaded.  The new 
mechanism is a simplification of the persistent interactive bonus 
mechanism in zaphod.


A patch for 2.6.13 is available at:



Very Brief Documentation:

You can select a default scheduler at kernel build time.  If you wish to
boot with a scheduler other than the default it can be selected at boot
time by adding:

cpusched=

to the boot command line where  is one of: ingosched,
nicksched, staircase, spa_no_frills, spa_ws or zaphod.  If you don't
change the default when you build the kernel the default scheduler will
be ingosched (which is the normal scheduler).

The scheduler in force on a running system can be determined by the
contents of:

/proc/scheduler

Control parameters for the scheduler can be read/set via files in:

/sys/cpusched//

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: IDE HPA

[Bartlomiej Zolnierkiewicz]

On 8/30/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Maw, 2005-08-30 at 18:16 +0200, Bartlomiej Zolnierkiewicz wrote:
> > HPA shouldn't be disabled by default and new kernel parameter ("hdx=hpa")
> > should be added for disabling HPA (yep, people with buggy BIOS-es will
> > have to add this parameter to their kernel command line, sorry).
> 
> Thats large numbers of systems. Large numbers of disks as strapped for
> 32GB and other clipping arrangements. With a vendor hat on thats
> unworkable because
> 
> a) It will stop thousands of people installing their systems
> b) Many users will get horrible corruption when they update the kernel
> and their box explodes as the fs tries to write to areas of disk that
> have vanished mysteriously.
> 
> (and we know all about this because ancient kernels had options for
> doing this in the compile that burned people)
> 
> So its a very bad idea indeed. A boot option for not disabling the hpa
> is possibly sensible for a few users who want that, or simply getting
> them to fix their buggy user space app would be even simpler.

OK, boot option for disabling HPA for users that want it is a indeed most
sensible approach.

> The only way I can see to truely automate it for most cases would be to
> snoop the partition table if its MSDOS format and see if the table
> matches the HPA clipped disk or the non-HPA clipped disk. If it matches
> the HPA clipped disk then you know not to fiddle. Otherwise its either a
> new disk, clipped by the 32GB jumper, non-x86 disk etc in which case you
> might as well disable any HPA.
> 
> 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/

MAX_ARG_PAGES has no effect?

[Nick Matteo]

The other day I was running a grep on a big directory tree and got a 
"Argument list too long" error.  Since I'd like to have this work 
without messing with find and xargs each time, I went into 
include/linux/binfmts.h and changed


#define MAX_ARG_PAGES 32

to

#define MAX_ARG_PAGES 64

I recompiled and installed the kernel, but there's no change (getconf 
ARG_MAX still gives 131072.)  What am I missing?


I am running 2.6.13 on amd64.

Thanks,
Nick Matteo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] IBM HDAPS accelerometer driver.

[Yani Ioannou]

Please refer to my IDE freeze patch last week:

http://lkml.org/lkml/2005/8/25/140

It provides userspace with a method to freeze the queue and park the
head (through sysfs), along with a timeout to unfreeze, and works
quite well. It is in the process of being moved to the block layer
however so that implementation for libata will be simpler.

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

Re: Very strange Marvell/Yukon Gigabit NIC networking problems

[Steve Kieu]

--- Stephen Hemminger <[EMAIL PROTECTED]> wrote:

> On Wed, 31 Aug 2005 07:49:37 +1000 (EST)

> > 
> > install-8_23.tar.bz2
> 
> Just look for references to CHIP_REV_YU_LITE_A3 in
> the driver
>   sk98lin/skgeinit.c and sk98lin/skxmac2.c
> The comparison should always be:

Have a look but no clue to patch it, there are one
instance of comparing

>   pAC->GIni.GIChipRev >= CHIP_REV_YU_LITE_A3
> otherwise it will not correctly take chip out of
> powerdown (coma) mode.

please send me a patch to the install-8_23.tar.bz2
then I can test. Or intruct more details, which line
and what should change then I can do manually.

I have nerver done device driver programming in my
life!



> 


S.KIEU

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: [PATCH] Only process_die notifier in ia64_do_page_fault if KPROBES is configured.

[Andi Kleen]

On Wednesday 31 August 2005 01:54, Christoph Lameter wrote:

> Certainly not a big effect (if we make sure the compiler knows that
> this test mostly fails and insure that the variable is in
> __mostly_read) 

Currently neither, but that could be easily fixed.

> but this is a frequently executed code path and the code 
> is there without purpose if CONFIG_KPROBES is off.

Well if you really worry about it then it might be better to do some dynamic
code patching to make generic and distribution kernels too.

> It wont get too bad unless lots of other people have similar ideas about
> fixing their race conditions using similar methods. But we will be setting
> a bad precedent if we allow this.

Agreed on the general direction, but I didn't see an alternative
for kprobes for this. Well actually the hook could be maybe
right now moved into the part before kernel oops which is much less
frequently executed, but then it'll likely move up again once
kprobes support user space probes.

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

Re: [PATCH] blk queue io tracing support

[Nathan Scott]

Hi there,

On Wed, Aug 31, 2005 at 09:48:23AM +1000, Nathan Scott wrote:
> ...
> # find /relay
> /relay
> /relay/block
> /relay/block/sdd
> /relay/block/sdd/trace3
> /relay/block/sdd/trace2
> /relay/block/sdd/trace1
> /relay/block/sdd/trace0
> /relay/block/sdb
> /relay/block/sdb/trace3
> /relay/block/sdb/trace2
> /relay/block/sdb/trace1
> /relay/block/sdb/trace0
> 
> and does the correct dynamic setup and teardown of the hierarchy
> as the userspace tool starts and stops tracing.  I had to modify
> the relayfs rmdir code a bit to make this work properly, I'll
> send a separate patch for that shortly.

Here it is.  The problem was that relayfs is allowing a directory
with children to be removed rather than returning -ENOTEMPTY.  It
looks like this can be resolved by splitting the shared relayfs
unlink code (which is using simple_unlink) into separate file/dir
variants, one using simple_unlink, the other using simple_rmdir.

cheers.

-- 
Nathan


Index: 2.6.x-xfs/fs/relayfs/inode.c
===
--- 2.6.x-xfs.orig/fs/relayfs/inode.c
+++ 2.6.x-xfs/fs/relayfs/inode.c
@@ -187,8 +187,8 @@ struct dentry *relayfs_create_dir(const 
 }
 
 /**
- * relayfs_remove - remove a file or directory in the relay filesystem
- * @dentry: file or directory dentry
+ * relayfs_remove - remove a file in the relay filesystem
+ * @dentry: file dentry
  */
 int relayfs_remove(struct dentry *dentry)
 {
@@ -219,10 +219,31 @@ int relayfs_remove(struct dentry *dentry
  */
 int relayfs_remove_dir(struct dentry *dentry)
 {
+   struct dentry *parent;
+   int error = 0;
+
if (!dentry)
return -EINVAL;
+   parent = dentry->d_parent;
+   if (!parent)
+   return -EINVAL;
+
+   parent = dget(parent);
+   down(>d_inode->i_sem);
+   if (dentry->d_inode) {
+   error = simple_rmdir(parent->d_inode, dentry);
+   if (!error)
+   d_delete(dentry);
+   }
+   if (!error)
+   dput(dentry);
+   up(>d_inode->i_sem);
+   dput(parent);
+
+   if (!error)
+   simple_release_fs(_mount, _mount_count);
 
-   return relayfs_remove(dentry);
+   return error;
 }
 
 /**
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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:
> Joel Becker <[EMAIL PROTECTED]> wrote:
> > The fact that sysfs and configfs have similar backing stores
> > does not make them the same thing.
> > 
> 
> 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 way that configfs and sysfs create/destroy dentries and
their associated inodes is very different from the top, yet similar from
the bottom.  I suspect that some of it could be libraryized.  When I
first looked started configfs, I was starting from an "add on to sysfs"
perspective, after all.  The sysfs maintainers and I agreed, after much
discussion, that we should go to a separate tree.

Joel

-- 

"Here's a nickle -- get yourself a better X server."
- Keith Packard

http://www.jlbec.org/
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: [PATCH] Only process_die notifier in ia64_do_page_fault if KPROBES is configured.

[David S. Miller]

From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: [PATCH] Only process_die notifier in ia64_do_page_fault if KPROBES 
is configured.
Date: Wed, 31 Aug 2005 01:38:08 +0200

> On Wednesday 31 August 2005 01:05, Luck, Tony wrote:
> > >Please do not generate any code if the feature cannot ever be
> > >used (CONFIG_KPROBES off). With this patch we still have lots of
> > >unnecessary code being executed on each page fault.
> >
> > I can (eventually) wrap this call inside the #ifdef CONFIG_KPROBES.
> 
> At least the original die notifiers were designed as a generic debugger
> interface, not a kprobes specific thing. So I don't think it's a good idea.

Me neither, I think a way too big deal is being made about
about this by the ia64 folks.  Just put the dang hook in
there unconditionally already :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] blk queue io tracing support

[Nathan Scott]

Hi Jens,

On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> Ok, updated version.

One thing I found a bit awkward was the way its putting all inodes
in the root of the relayfs namespace, with the cpuid tacked on the
end of the bdevname - I was a bit confused at first when a trace of
sdd on my 4P box spontaneously created files for "partitions" sdd0,
sdd1, sdd2, and sdd3 ;).

I suppose if many more users of relayfs spring into existance, this
is going to get quite ugly.  Below is a patch that aligns the names
to the conventions used in sysfs; so, for example, when running two
traces simultaneously on /dev/sdd and /dev/sdb, instead of this:

# find /relay
/relay
/relay/sdd3
/relay/sdd2
/relay/sdd1
/relay/sdd0
/relay/sdb3
/relay/sdb2
/relay/sdb1
/relay/sdb0

it now uses this...

# find /relay
/relay
/relay/block
/relay/block/sdd
/relay/block/sdd/trace3
/relay/block/sdd/trace2
/relay/block/sdd/trace1
/relay/block/sdd/trace0
/relay/block/sdb
/relay/block/sdb/trace3
/relay/block/sdb/trace2
/relay/block/sdb/trace1
/relay/block/sdb/trace0

and does the correct dynamic setup and teardown of the hierarchy
as the userspace tool starts and stops tracing.  I had to modify
the relayfs rmdir code a bit to make this work properly, I'll
send a separate patch for that shortly.

> http://www.kernel.org/pub/linux/kernel/people/axboe/tools/blktrace.c
> 
> has been updated as well, the protocol version was increased to
> accomodate the trace structure changes.

I have the associated userspace change for this, as well as several
other fixes and tweaks for your tool - if you could slap a copyright
and license notice onto that source (pretty please? :) I'll send 'em
right along.

cheers.

-- 
Nathan

Index: 2.6.x-xfs/drivers/block/blktrace.c
===
--- 2.6.x-xfs.orig/drivers/block/blktrace.c
+++ 2.6.x-xfs/drivers/block/blktrace.c
@@ -40,6 +40,50 @@ void __blk_add_trace(struct blk_trace *b
local_irq_restore(flags);
 }
 
+static struct dentry * blk_tree_root;
+static DEFINE_SPINLOCK(blk_tree_lock);
+
+static inline void blk_remove_root(void)
+{
+   if (relayfs_remove_dir(blk_tree_root) != -ENOTEMPTY)
+   blk_tree_root = NULL;
+}
+
+static void blk_remove_tree(struct dentry *dir)
+{
+   spin_lock(_tree_lock);
+   relayfs_remove_dir(dir);
+   blk_remove_root();
+   spin_unlock(_tree_lock);
+}
+
+static struct dentry *blk_create_tree(const char *blk_name)
+{
+   struct dentry *dir;
+
+   spin_lock(_tree_lock);
+   if (!blk_tree_root) {
+   blk_tree_root = relayfs_create_dir("block", NULL);
+   if (!blk_tree_root) {
+   spin_unlock(_tree_lock);
+   return NULL;
+   }
+   }
+   dir = relayfs_create_dir(blk_name, blk_tree_root);
+   if (!dir)
+   blk_remove_root();
+   spin_unlock(_tree_lock);
+
+   return dir;
+}
+
+void blk_cleanup_trace(struct blk_trace *bt)
+{
+   relay_close(bt->rchan);
+   blk_remove_tree(bt->dir);
+   kfree(bt);
+}
+
 int blk_stop_trace(struct block_device *bdev)
 {
request_queue_t *q = bdev_get_queue(bdev);
@@ -61,10 +105,8 @@ int blk_stop_trace(struct block_device *
 
up(>bd_sem);
 
-   if (bt) {
-   relay_close(bt->rchan);
-   kfree(bt);
-   }
+   if (bt)
+   blk_cleanup_trace(bt);
 
return ret;
 }
@@ -74,6 +116,7 @@ int blk_start_trace(struct block_device 
request_queue_t *q = bdev_get_queue(bdev);
struct blk_user_trace_setup buts;
struct blk_trace *bt = NULL;
+   struct dentry *dir = NULL;
char b[BDEVNAME_SIZE];
int ret;
 
@@ -101,11 +144,16 @@ int blk_start_trace(struct block_device 
if (!bt)
goto err;
 
+   ret = -ENOENT;
+   dir = blk_create_tree(bdevname(bdev, b));
+   if (!dir)
+   goto err;
+
+   bt->dir = dir;
atomic_set(>sequence, 0);
 
-   bt->rchan = relay_open(bdevname(bdev, b), NULL, buts.buf_size,
-   buts.buf_nr, NULL);
ret = -EIO;
+   bt->rchan = relay_open("trace", dir, buts.buf_size, buts.buf_nr, NULL);
if (!bt->rchan)
goto err;
 
@@ -122,6 +170,8 @@ int blk_start_trace(struct block_device 
 
 err:
up(>bd_sem);
+   if (dir)
+   blk_remove_tree(dir);
if (bt)
kfree(bt);
return ret;
Index: 2.6.x-xfs/include/linux/blktrace.h
===
--- 2.6.x-xfs.orig/include/linux/blktrace.h
+++ 2.6.x-xfs/include/linux/blktrace.h
@@ -71,6 +71,7 @@ struct blk_io_trace {
 };
 
 struct blk_trace {
+   struct dentry *dir;
struct rchan *rchan;
atomic_t sequence;
u16 act_mask;
@@ -89,6 +90,7 @@ struct blk_user_trace_setup {
 #if defined(CONFIG_BLK_DEV_IO_TRACE)
 extern int blk_start_trace(struct 

Re: [PATCH] libata: add ATAPI module option

[Mark Lord]

Jeff Garzik wrote:


-#ifndef ATA_ENABLE_ATAPI
-   if (unlikely(dev->class == ATA_DEV_ATAPI))
-   return NULL;
-#endif
+   if (atapi_enabled) {
+   if (unlikely(dev->class == ATA_DEV_ATAPI))
+   return NULL;
+   }

..

Is that if-stmt the right way around?
At first glance, I'd expect it to read:

 if (!atapi_enabled) {
 ...

Cheers!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Only process_die notifier in ia64_do_page_fault if KPROBES is configured.

[Christoph Lameter]

On Wed, 31 Aug 2005, Andi Kleen wrote:

> Also with the inline the test should be essentially a single test of 
> a global variable and jump. Hardly a big performance issue, no? 

There are multiple effects of this code.

- Additional cacheline in use in the page fault handler 
  increasing the cache foot print.

- There are registers in use for checking the global variable.

- The compilers will reserve registers for the code that is never 
  executed which may affect other elements of performance. From the 
  register perspective a function call may be better on ia64.

Certainly not a big effect (if we make sure the compiler knows that 
this test mostly fails and insure that the variable is in 
__mostly_read) but this is a frequently executed code path and the code
is there without purpose if CONFIG_KPROBES is off.

It wont get too bad unless lots of other people have similar ideas about 
fixing their race conditions using similar methods. But we will be setting 
a bad precedent if we allow 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: [RFC][PATCH 1 of 4] Configfs is really sysfs

[Daniel Phillips]

On Wednesday 31 August 2005 09:34, [EMAIL PROTECTED] 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?
>
> Careful - you've almost reinvented the concept of library, which would
> violate any number of patents...

I will keep my eyes open for library candidates as I go.  For example, the 
binary blob operations really cry out for it.

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] blk queue io tracing support

[Nathan Scott]

Hi Jens,

On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
> relayfs read update from the previous mail [*] as well.

There's a small memory leak there on one of the start-tracing
error paths (relay_open failure)... this should plug it up.

cheers.

-- 
Nathan


Index: 2.6.x-xfs/drivers/block/blktrace.c
===
--- 2.6.x-xfs.orig/drivers/block/blktrace.c
+++ 2.6.x-xfs/drivers/block/blktrace.c
@@ -73,9 +73,9 @@ int blk_start_trace(struct block_device 
 {
request_queue_t *q = bdev_get_queue(bdev);
struct blk_user_trace_setup buts;
-   struct blk_trace *bt;
+   struct blk_trace *bt = NULL;
char b[BDEVNAME_SIZE];
-   int ret = 0;
+   int ret;
 
if (!q)
return -ENXIO;
@@ -116,9 +116,14 @@ int blk_start_trace(struct block_device 
spin_lock_irq(q->queue_lock);
q->blk_trace = bt;
spin_unlock_irq(q->queue_lock);
-   ret = 0;
+
+   up(>bd_sem);
+   return 0;
+
 err:
up(>bd_sem);
+   if (bt)
+   kfree(bt);
return ret;
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Only process_die notifier in ia64_do_page_fault if KPROBES is configured.

[Andi Kleen]

On Wednesday 31 August 2005 01:05, Luck, Tony wrote:
> >Please do not generate any code if the feature cannot ever be
> >used (CONFIG_KPROBES off). With this patch we still have lots of
> >unnecessary code being executed on each page fault.
>
> I can (eventually) wrap this call inside the #ifdef CONFIG_KPROBES.

At least the original die notifiers were designed as a generic debugger
interface, not a kprobes specific thing. So I don't think it's a good idea.
Given most debuggers don't need the early page fault hook and it's
mostly needed for a special case in kprobes, but it doesn't seem nice to only 
offer a subset of the hooks with specific config options.

Also with the inline the test should be essentially a single test of 
a global variable and jump. Hardly a big performance issue, no? 

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

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

[Daniel Phillips]

On Wednesday 31 August 2005 09:28, Andrew Morton wrote:
> Joel Becker <[EMAIL PROTECTED]> wrote:
> > On Wed, Aug 31, 2005 at 08:54:39AM +1000, Daniel Phillips wrote:
> > > But it would be stupid to forbid users from creating directories in
> > > sysfs or to forbid kernel modules from directly tweaking a configfs
> > > namespace.  Why should the kernel not be able to add objects to a
> > > directory a user created? It should be up to the module author to
> > > decide these things.
> >
> > This is precisely why configfs is separate from sysfs.  If both
> > user and kernel can create objects, the lifetime of the object and its
> > filesystem representation is very complex.  Sysfs already has problems
> > with people getting this wrong.  configfs does not.
> > The fact that sysfs and configfs have similar backing stores
> > does not make them the same thing.
>
> 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?

I will have that patch ready later this week.

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

[Daniel Phillips]

On Wednesday 31 August 2005 09:25, Daniel Phillips wrote:
> On Wednesday 31 August 2005 09:13, Joel Becker wrote:
> > On Wed, Aug 31, 2005 at 08:54:39AM +1000, Daniel Phillips wrote:
> > > But it would be stupid to forbid users from creating directories in
> > > sysfs or to forbid kernel modules from directly tweaking a configfs
> > > namespace. Why should the kernel not be able to add objects to a
> > > directory a user created? It should be up to the module author to
> > > decide these things.
> >
> > This is precisely why configfs is separate from sysfs.  If both
> > user and kernel can create objects, the lifetime of the object and its
> > filesystem representation is very complex.  Sysfs already has problems
> > with people getting this wrong.  configfs does not.
>
> Could you please give a specific case?

More to the point: what makes you think that this apparent ruggedness will
diminish after being re-integrated with sysfs?  If you wish, you can avoid
any dangers by not using sysfs's vfs bypass api.  It should be up to the
subsystem author.

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

[viro]

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?

Careful - you've almost reinvented the concept of library, which would
violate any number of patents...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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

[Andrew Morton]

Joel Becker <[EMAIL PROTECTED]> wrote:
>
> On Wed, Aug 31, 2005 at 08:54:39AM +1000, Daniel Phillips wrote:
> > But it would be stupid to forbid users from creating directories in sysfs 
> > or 
> > to forbid kernel modules from directly tweaking a configfs namespace.  Why 
> > should the kernel not be able to add objects to a directory a user created? 
> >  
> > It should be up to the module author to decide these things.
> 
>   This is precisely why configfs is separate from sysfs.  If both
> user and kernel can create objects, the lifetime of the object and its
> filesystem representation is very complex.  Sysfs already has problems
> with people getting this wrong.  configfs does not.
>   The fact that sysfs and configfs have similar backing stores
> does not make them the same thing.
> 

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

[Daniel Phillips]

(without kmail bugs this time)

A kernel code example that uses the modified configfs to define a simple
configuration interface.  Note the use of kobjects and ksets instead of
config_items and config_groups.

Also notice how much code is required to get a simple value from
userspace to kernel space.  This is a big problem that needs to be
addressed soon, before we end up with tens or hundreds of thousands of
lines of code code bloat just to get and set variables from user space.

Regards,

Daniel

#include 
#include 
#include 

#include 

struct ddbond_info {
 struct kobject item;
 int controlsock;
};

static inline struct ddbond_info *to_ddbond_info(struct kobject *item)
{
 return container_of(item, struct ddbond_info, item);
}

static ssize_t ddbond_info_attr_show(struct kobject *item,
 struct attribute *attr, char *page)
{
 ssize_t count;
 struct ddbond_info *ddbond_info = to_ddbond_info(item);
 count = sprintf(page, "%d\n", ddbond_info->controlsock);
 return count;
}

static ssize_t ddbond_info_attr_store(struct kobject *item,
 struct attribute *attr, const char *page, size_t count)
{
 struct ddbond_info *ddbond_info = to_ddbond_info(item);
 unsigned long tmp;
 char *p = (char *)page;

 tmp = simple_strtoul(p, , 10);
 if (!p || (*p && (*p != '\n')))
  return -EINVAL;
 if (tmp > INT_MAX)
  return -ERANGE;
 ddbond_info->controlsock = tmp;
 return count;
}

static void ddbond_info_release(struct kobject *item)
{
 kfree(to_ddbond_info(item));
}

static struct kobj_type ddbond_info_type = {
 .sysfs_ops = &(struct sysfs_ops){
  .show = ddbond_info_attr_show,
  .store = ddbond_info_attr_store,
  .release = ddbond_info_release,
 },
 .default_attrs = (struct attribute *[]){
  &(struct attribute){
   .owner = THIS_MODULE,
   .name = "sockname",
   .mode = S_IRUGO | S_IWUSR,
  },
  NULL,
 },
 .ct_owner = THIS_MODULE,
};

static struct kobject *ddbond_make_item(struct kset *group, const char *name)
{
 struct ddbond_info *ddbond_info;
 if (!(ddbond_info = kcalloc(1, sizeof(struct ddbond_info), GFP_KERNEL)))
  return NULL;
 kobject_init_type_name(_info->item, name, _info_type);
 return _info->item;
}

static ssize_t ddbond_description(struct kobject *item,
 struct attribute *attr, char *page)
{
 return sprintf(page,
  "A ddbond block server has two components: a userspace server and a kernel\n"
  "io daemon.  First start the server and give it the name of a socket it 
will\n"
  "create, then create a ddbond directory and write the same name into the\n"
  "socket attribute\n");
}

static struct kobj_type ddbond_type = {
 .sysfs_ops = &(struct sysfs_ops){
  .show = ddbond_description,
 },
 .ct_group_ops = &(struct configfs_group_operations){
  .make_item = ddbond_make_item,
 },
 .default_attrs = (struct attribute *[]){
  &(struct attribute){
   .owner = THIS_MODULE,
   .name = "description",
   .mode = S_IRUGO,
  },
  NULL,
 }
};

static struct subsystem ddbond_subsys = {
 .kset = {
  .kobj = {
   .k_name = "ddbond",
   .ktype = _type,
  },
 },
};

static int __init init_ddbond_config(void)
{
 int ret;
 config_group_init(_subsys.kset);
 init_rwsem(_subsys.rwsem);
 if ((ret = configfs_register_subsystem(_subsys)))
  printk(KERN_ERR "Error %d while registering subsystem %s\n",
 ret, ddbond_subsys.kset.kobj.k_name);
 return ret;
}

static void __exit exit_ddbond_config(void)
{
 configfs_unregister_subsystem(_subsys);
}

module_init(init_ddbond_config);
module_exit(exit_ddbond_config);
MODULE_LICENSE("GPL");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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

[Daniel Phillips]

On Wednesday 31 August 2005 09:13, Joel Becker wrote:
> On Wed, Aug 31, 2005 at 08:54:39AM +1000, Daniel Phillips wrote:
> > But it would be stupid to forbid users from creating directories in sysfs
> > or to forbid kernel modules from directly tweaking a configfs namespace. 
> > Why should the kernel not be able to add objects to a directory a user
> > created? It should be up to the module author to decide these things.
>
>   This is precisely why configfs is separate from sysfs.  If both
> user and kernel can create objects, the lifetime of the object and its
> filesystem representation is very complex.  Sysfs already has problems
> with people getting this wrong.  configfs does not.

Could you please give a specific case?

>   The fact that sysfs and configfs have similar backing stores
> does not make them the same thing.

It is not just the backing store, it is most of the code, all the structures, 
most of the functionality, a good deal of the bugs...

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 2 of 4] Configfs is really sysfs

[Daniel Phillips]

(avoiding the kmail formatting problems this time.)

Sysfs rearranged as a single file for analysis purposes.

diff -up --recursive 2.6.13-rc5-mm1.clean/fs/sysfs/Makefile 
2.6.13-rc5-mm1/fs/sysfs/Makefile
--- 2.6.13-rc5-mm1.clean/fs/sysfs/Makefile  2005-06-17 15:48:29.0 
-0400
+++ 2.6.13-rc5-mm1/fs/sysfs/Makefile2005-08-29 17:13:59.0 -0400
@@ -2,5 +2,4 @@
 # Makefile for the sysfs virtual filesystem
 #
 
-obj-y  := inode.o file.o dir.o symlink.o mount.o bin.o \
-  group.o
+obj-y := sysfs.o
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/sysfs/sysfs.c 
2.6.13-rc5-mm1/fs/sysfs/sysfs.c
--- 2.6.13-rc5-mm1.clean/fs/sysfs/sysfs.c   2005-08-30 17:52:35.0 
-0400
+++ 2.6.13-rc5-mm1/fs/sysfs/sysfs.c 2005-08-29 21:04:40.0 -0400
@@ -0,0 +1,1680 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct sysfs_symlink {
+   char *link_name;
+   struct kobject *sl_target;
+};
+
+static inline struct kobject *to_kobj(struct dentry *dentry)
+{
+   struct sysfs_dirent *sd = dentry->d_fsdata;
+   return ((struct kobject *)sd->s_element);
+}
+
+static inline struct attribute *to_attr(struct dentry *dentry)
+{
+   struct sysfs_dirent *sd = dentry->d_fsdata;
+   return ((struct attribute *)sd->s_element);
+}
+
+static inline struct kobject *sysfs_get_kobject(struct dentry *dentry)
+{
+   struct kobject *kobj = NULL;
+
+   spin_lock(_lock);
+   if (!d_unhashed(dentry)) {
+   struct sysfs_dirent *sd = dentry->d_fsdata;
+   if (sd->s_type & SYSFS_KOBJ_LINK) {
+   struct sysfs_symlink *sl = sd->s_element;
+   kobj = kobject_get(sl->sl_target);
+   } else
+   kobj = kobject_get(sd->s_element);
+   }
+   spin_unlock(_lock);
+
+   return kobj;
+}
+
+static kmem_cache_t *sysfs_dir_cachep;
+
+static void release_sysfs_dirent(struct sysfs_dirent *sd)
+{
+   if (sd->s_type & SYSFS_KOBJ_LINK) {
+   struct sysfs_symlink *sl = sd->s_element;
+   kfree(sl->link_name);
+   kobject_put(sl->sl_target);
+   kfree(sl);
+   }
+   kfree(sd->s_iattr);
+   kmem_cache_free(sysfs_dir_cachep, sd);
+}
+
+static struct sysfs_dirent *sysfs_get(struct sysfs_dirent *sd)
+{
+   if (sd) {
+   WARN_ON(!atomic_read(>s_count));
+   atomic_inc(>s_count);
+   }
+   return sd;
+}
+
+static void sysfs_put(struct sysfs_dirent *sd)
+{
+   WARN_ON(!atomic_read(>s_count));
+   if (atomic_dec_and_test(>s_count))
+   release_sysfs_dirent(sd);
+}
+
+/*
+ * inode.c - basic inode and dentry operations.
+ */
+
+int sysfs_setattr(struct dentry *dentry, struct iattr *iattr)
+{
+   struct inode *inode = dentry->d_inode;
+   struct sysfs_dirent *sd = dentry->d_fsdata;
+   struct iattr *sd_iattr;
+   unsigned int ia_valid = iattr->ia_valid;
+   int error;
+
+   if (!sd)
+   return -EINVAL;
+
+   sd_iattr = sd->s_iattr;
+
+   error = inode_change_ok(inode, iattr);
+   if (error)
+   return error;
+
+   error = inode_setattr(inode, iattr);
+   if (error)
+   return error;
+
+   if (!sd_iattr) {
+   /* setting attributes for the first time, allocate now */
+   sd_iattr = kmalloc(sizeof(struct iattr), GFP_KERNEL);
+   if (!sd_iattr)
+   return -ENOMEM;
+   /* assign default attributes */
+   memset(sd_iattr, 0, sizeof(struct iattr));
+   sd_iattr->ia_mode = sd->s_mode;
+   sd_iattr->ia_uid = 0;
+   sd_iattr->ia_gid = 0;
+   sd_iattr->ia_atime = sd_iattr->ia_mtime = sd_iattr->ia_ctime =
+   CURRENT_TIME;
+   sd->s_iattr = sd_iattr;
+   }
+
+   /* attributes were changed atleast once in past */
+
+   if (ia_valid & ATTR_UID)
+   sd_iattr->ia_uid = iattr->ia_uid;
+   if (ia_valid & ATTR_GID)
+   sd_iattr->ia_gid = iattr->ia_gid;
+   if (ia_valid & ATTR_ATIME)
+   sd_iattr->ia_atime = timespec_trunc(iattr->ia_atime,
+   inode->i_sb->s_time_gran);
+   if (ia_valid & ATTR_MTIME)
+   sd_iattr->ia_mtime = timespec_trunc(iattr->ia_mtime,
+   inode->i_sb->s_time_gran);
+   if (ia_valid & ATTR_CTIME)
+   sd_iattr->ia_ctime = timespec_trunc(iattr->ia_ctime,
+   inode->i_sb->s_time_gran);
+   if (ia_valid & ATTR_MODE) {
+   umode_t mode = iattr->ia_mode;
+
+   if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID))
+   mode &= ~S_ISGID;
+   sd_iattr->ia_mode = sd->s_mode = mode;
+   }
+
+   return error;
+}
+

Re: KLive: Linux Kernel Live Usage Monitor

[Sven Ladegast]

On Wed, 31 Aug 2005, Alan Cox wrote:


"Register a box + optional PCI id list/CPU info"
Reply with a secured serial number


Registering means to create an ID for the system? Something out of 
timestamp plus your PCI IDs and CPU info and so on?


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

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

[Daniel Phillips]

On Tuesday 30 August 2005 19:06, Stephen Hemminger wrote:
> On Wed, 31 Aug 2005 08:59:55 +1000
>
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > Configfs rewritten as a single file and updated to use kobjects instead
> > of its own clone of kobjects (config_items).
>
> Some style issues:
>  Mixed case in labels

I certainly agree.  This is strictly for comparison purposes and so I did not 
clean up the stylistic problems from the original... this time.

>  Bad identation

I did lindent it however :-)

> > +  Done:
>
> Why the mixed case label?

It shall die.

> > +void config_group_init_type_name(struct kset *group, const char *name,
> > struct kobj_type *type) +{
> > + kobject_set_name(>kobj, name);
> > + group->kobj.ktype = type;
> > + config_group_init(group);
> > +}
>
> Use tabs not one space for indent.

Urk.  Kmail did that to me, it has been broken that way for a year or so.  I 
will have to repost the whole set from a mailer that works.

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 Wed, Aug 31, 2005 at 08:54:39AM +1000, Daniel Phillips wrote:
> But it would be stupid to forbid users from creating directories in sysfs or 
> to forbid kernel modules from directly tweaking a configfs namespace.  Why 
> should the kernel not be able to add objects to a directory a user created?  
> It should be up to the module author to decide these things.

This is precisely why configfs is separate from sysfs.  If both
user and kernel can create objects, the lifetime of the object and its
filesystem representation is very complex.  Sysfs already has problems
with people getting this wrong.  configfs does not.
The fact that sysfs and configfs have similar backing stores
does not make them the same thing.

Joel

-- 

"Against stupidity the Gods themselves contend in vain."
- Freidrich von Schiller

http://www.jlbec.org/
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: GDT initialization and location question.

[Randy.Dunlap]

On Tue, 30 Aug 2005, Chris Wright wrote:

> * Pritesh Shah ([EMAIL PROTECTED]) wrote:
> > I was wondering as to where is the GDT initialized during the boot
> > sequence? I will need the filename and the name of the routine that
> > does this. Any help would be greatly appreciated.
>
> Search for cpu_gdt_table (one is literal, the other is per_cpu).  You
> should be able to work it out from there.
> -

I would have said search for /gdt/ in arch/i386/boot/setup.S .
Maybe both are helpful.

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

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

[Daniel Phillips]

On Wednesday 31 August 2005 08:59, Daniel Phillips wrote:
> -obj-$(CONFIG_CONFIGFS_FS) += configfs.o
> +obj-$(CONFIG_CONFIGFS_FS) += configfs.o ddbond.config.o

This should just be:

+obj-$(CONFIG_CONFIGFS_FS) += configfs.o

However, the wrong version does provide a convenient way of compiling the
example, I just... have... to... remember to delete it next time.

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] RT-patch update to remove the global pi_lock

[Steven Rostedt]

Ingo,

This patch contains my previous change as well as an update to fix the
race conditions that the BKL may hold.  It is against -rt2. 

The first part of the patch will stop the pi_setprio loop if the process
has a lock_depth greater than or equal to zero.  Since that would mean
that the process either is running, or is about to release the BKL.

I still kept the change from rt1 to rt2 but changed the comment.

I added the lock release logic in the __up code incase the BKL is
causing loops in the pi chain.

I'm currently runnig -rt2 with these changes as I type.

-- Steve

Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>

Index: linux_realtime_goliath/kernel/rt.c
===
--- linux_realtime_goliath/kernel/rt.c  (revision 310)
+++ linux_realtime_goliath/kernel/rt.c  (working copy)
@@ -800,7 +800,24 @@
 #endif
 
mutex_setprio(p, prio);
-   if (!w)
+
+   /*
+* The BKL can really be a pain. It can happen where the
+* BKL is being held by one task that is just about to
+* block on another task that is waiting for the BKL.
+* This isn't a deadlock, since the BKL is released
+* when the task goes to sleep.  This also means that
+* all holders of the BKL are not blocked, or are just
+* about to be blocked.
+*
+* Another side-effect of this is that there's a small
+* window where the spinlocks are not held, and the blocked
+* process hasn't released the BKL.  So if we are going
+* to boost the owner of the BKL, stop after that,
+* since that owner is either running, or about to sleep
+* but don't go any further or we are in a loop.
+*/
+   if (!w || unlikely(p->lock_depth >= 0))
break;
/*
 * If the task is blocked on a lock, and we just made
@@ -817,10 +834,9 @@
TRACE_BUG_ON_LOCKED(!lock);
 
/*
-* The BKL can really be a pain.  It can happen that the lock
-* we are blocked on is owned by a task that is waiting for
-* the BKL, and we own it.  So, if this is the BKL and we own
-* it, then end the loop here.
+* The current task that is blocking can also the one
+* holding the BKL, and blocking on a task that wants 
+* it.  So if it were to get this far, we would deadlock.
 */
if (unlikely(l == _sem.lock) && lock_owner(l) == 
current_thread_info()) {
/*
@@ -1089,11 +1105,21 @@
__raw_spin_unlock(_owner->task->pi_lock);
goto try_again;
}
+   /*
+* Once again the BKL comes to play.  Since the BKL can be grabbed and 
released
+* out of the normal P1->L1->P2 order, there's a chance that someone 
has the
+* BKL owner's lock and is waiting on the new owner lock.
+*/
+   if (unlikely(lock == _sem.lock)) {
+   if (!__raw_spin_trylock(_owner->task->pi_lock)) {
+   __raw_spin_unlock(_owner->task->pi_lock);
+   goto try_again;
+   }
+   } else
 #endif
+   __raw_spin_lock(_owner->task->pi_lock);
+
plist_del_init(>list, >wait_list);
-
-   __raw_spin_lock(_owner->task->pi_lock);
-
plist_del(>pi_list, _owner->task->pi_waiters);
plist_init(>pi_list, waiter->ti->task->prio);
 


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

RE: Where is the performance bottleneck?

[Guy]

In most of your results, your CPU usage is very high.  Once you get to about
90% usage, you really can't do much else, unless you can improve the CPU
usage.

Guy

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-raid-
> [EMAIL PROTECTED] On Behalf Of Holger Kiehl
> Sent: Tuesday, August 30, 2005 3:09 PM
> To: Mark Hahn
> Cc: linux-raid; linux-kernel
> Subject: Re: Where is the performance bottleneck?
> 
> On Mon, 29 Aug 2005, Mark Hahn wrote:
> 
> >> The U320 SCSI controller has a 64 bit PCI-X bus for itself, there is no
> other
> >> device on that bus. Unfortunatly I was unable to determine at what
> speed
> >> it is running, here the output from lspci -vv:
> > ...
> >>  Status: Bus=2 Dev=4 Func=0 64bit+ 133MHz+ SCD- USC-,
> DC=simple,
> >
> > the "133MHz+" is a good sign.  OTOH the latency (72) seems rather low -
> my
> > understanding is that that would noticably limit the size of burst
> transfers.
> >
> I have tried with 128 and 144, but the transfer rate is only a little
> bit higher barely measurable. Or what values should I try?
> 
> >
> >> Version  1.03--Sequential Output-- --Sequential Input-
> --Random-
> >>   -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
> --Seeks--
> >> Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
> /sec %CP
> >> Raid0 (8 disk)15744M 54406  96 247419 90 100752 25 60266  98 226651 29
> 830.2   1
> >> Raid0s(4 disk)15744M 54915  97 253642 89 73976  18 59445  97 198372 24
> 659.8   1
> >> Raid0s(4 disk)15744M 54866  97 268361 95 72852  17 59165  97 187183 22
> 666.3   1
> >
> > you're obviously saturating something already with 2 disks.  did you
> play
> > with "blockdev --setra" setings?
> >
> Yes, I did play a little bit with it but this only changed read
> performance,
> it made no measurable difference when writting.
> 
> Thanks,
> Holger
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.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: [RFC][PATCH 3 of 4] Configfs is really sysfs

[Stephen Hemminger]

On Wed, 31 Aug 2005 08:59:55 +1000
Daniel Phillips <[EMAIL PROTECTED]> wrote:

> Configfs rewritten as a single file and updated to use kobjects instead of its
> own clone of kobjects (config_items).
> 

Some style issues:
Mixed case in labels
Bad identation

> +static int sysfs_create(struct dentry *dentry, int mode, int (*init) (struct 
> inode *))
> +{
> + int error = 0;
> + struct inode *inode = NULL;
> + if (dentry) {
> + if (!dentry->d_inode) {
> + if ((inode = sysfs_new_inode(mode))) {
> + if (dentry->d_parent
> + && dentry->d_parent->d_inode) {
> + struct inode *p_inode =
> + dentry->d_parent->d_inode;
> + p_inode->i_mtime = p_inode->i_ctime =
> + CURRENT_TIME;
> + }
> + goto Proceed;
> + } else
> + error = -ENOMEM;
> + } else
> + error = -EEXIST;
> + } else
> + error = -ENOENT;
> + goto Done;
> +
> +  Proceed:
> + if (init)
> + error = init(inode);
> + if (!error) {
> + d_instantiate(dentry, inode);
> + if (S_ISDIR(mode) || S_ISLNK(mode)) /* pin link and directory 
> dentries */
> + dget(dentry);
> + } else
> + iput(inode);
> +  Done:

Why the mixed case label?

> + return error;
> +}


> +/* 
> + * configfs client helpers
> + */
> +
> +void config_group_init_type_name(struct kset *group, const char *name, 
> struct kobj_type *type)
> +{
> + kobject_set_name(>kobj, name);
> + group->kobj.ktype = type;
> + config_group_init(group);
> +}

Use tabs not one space for indent.

> +void config_group_init(struct kset *group)
> +{
> + kobject_init(>kobj);
> + INIT_LIST_HEAD(>cg_children);
> +}
> +
> +void kobject_init_type_name(struct kobject *kobj, const char *name, struct 
> kobj_type *type)
> +{
> + kobject_set_name(kobj, name);
> + kobj->ktype = type;
> + kobject_init(kobj);
> +}
> +
> +EXPORT_SYMBOL(configfs_register_subsystem);
> +EXPORT_SYMBOL(configfs_unregister_subsystem);
> +EXPORT_SYMBOL(config_group_init_type_name);
> +EXPORT_SYMBOL(config_group_init);
> +EXPORT_SYMBOL(kobject_init_type_name);
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 4 of 4] Configfs is really sysfs

[Daniel Phillips]

A kernel code example that uses the modified configfs to define a simple
configuration interface.  Note the use of kobjects and ksets instead of
config_items and config_groups.

Also notice how much code is required to get a simple value from
userspace to kernel space.  This is a big problem that needs to be
addressed soon, before we end up with tens or hundreds of thousands of
lines of code code bloat just to get and set variables from user space.

Regards,

Daniel

#include 
#include 
#include 

#include 

struct ddbond_info {
 struct kobject item;
 int controlsock;
};

static inline struct ddbond_info *to_ddbond_info(struct kobject *item)
{
 return container_of(item, struct ddbond_info, item);
}

static ssize_t ddbond_info_attr_show(struct kobject *item,
 struct attribute *attr, char *page)
{
 ssize_t count;
 struct ddbond_info *ddbond_info = to_ddbond_info(item);
 count = sprintf(page, "%d\n", ddbond_info->controlsock);
 return count;
}

static ssize_t ddbond_info_attr_store(struct kobject *item,
 struct attribute *attr, const char *page, size_t count)
{
 struct ddbond_info *ddbond_info = to_ddbond_info(item);
 unsigned long tmp;
 char *p = (char *)page;

 tmp = simple_strtoul(p, , 10);
 if (!p || (*p && (*p != '\n')))
  return -EINVAL;
 if (tmp > INT_MAX)
  return -ERANGE;
 ddbond_info->controlsock = tmp;
 return count;
}

static void ddbond_info_release(struct kobject *item)
{
 kfree(to_ddbond_info(item));
}

static struct kobj_type ddbond_info_type = {
 .sysfs_ops = &(struct sysfs_ops){
  .show = ddbond_info_attr_show,
  .store = ddbond_info_attr_store,
  .release = ddbond_info_release,
 },
 .default_attrs = (struct attribute *[]){
  &(struct attribute){
   .owner = THIS_MODULE,
   .name = "sockname",
   .mode = S_IRUGO | S_IWUSR,
  },
  NULL,
 },
 .ct_owner = THIS_MODULE,
};

static struct kobject *ddbond_make_item(struct kset *group, const char *name)
{
 struct ddbond_info *ddbond_info;
 if (!(ddbond_info = kcalloc(1, sizeof(struct ddbond_info), GFP_KERNEL)))
  return NULL;
 kobject_init_type_name(_info->item, name, _info_type);
 return _info->item;
}

static ssize_t ddbond_description(struct kobject *item,
 struct attribute *attr, char *page)
{
 return sprintf(page,
  "A ddbond block server has two components: a userspace server and a kernel\n"
  "io daemon.  First start the server and give it the name of a socket it 
will\n"
  "create, then create a ddbond directory and write the same name into the\n"
  "socket attribute\n");
}

static struct kobj_type ddbond_type = {
 .sysfs_ops = &(struct sysfs_ops){
  .show = ddbond_description,
 },
 .ct_group_ops = &(struct configfs_group_operations){
  .make_item = ddbond_make_item,
 },
 .default_attrs = (struct attribute *[]){
  &(struct attribute){
   .owner = THIS_MODULE,
   .name = "description",
   .mode = S_IRUGO,
  },
  NULL,
 }
};

static struct subsystem ddbond_subsys = {
 .kset = {
  .kobj = {
   .k_name = "ddbond",
   .ktype = _type,
  },
 },
};

static int __init init_ddbond_config(void)
{
 int ret;
 config_group_init(_subsys.kset);
 init_rwsem(_subsys.rwsem);
 if ((ret = configfs_register_subsystem(_subsys)))
  printk(KERN_ERR "Error %d while registering subsystem %s\n",
 ret, ddbond_subsys.kset.kobj.k_name);
 return ret;
}

static void __exit exit_ddbond_config(void)
{
 configfs_unregister_subsystem(_subsys);
}

module_init(init_ddbond_config);
module_exit(exit_ddbond_config);
MODULE_LICENSE("GPL");

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Only process_die notifier in ia64_do_page_fault if KPROBES is configured.

[Luck, Tony]

>Please do not generate any code if the feature cannot ever be 
>used (CONFIG_KPROBES off). With this patch we still have lots of 
>unnecessary code being executed on each page fault.

I can (eventually) wrap this call inside the #ifdef CONFIG_KPROBES.

But I'd like to keep following leads on making the overhead as
low as possible for those people that do have KPROBES configured
(which may be most people if OS distributors ship kernels with
this enabled).

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

Re: GDT initialization and location question.

[Chris Wright]

* Pritesh Shah ([EMAIL PROTECTED]) wrote:
> I was wondering as to where is the GDT initialized during the boot
> sequence? I will need the filename and the name of the routine that
> does this. Any help would be greatly appreciated.

Search for cpu_gdt_table (one is literal, the other is per_cpu).  You
should be able to work it out from there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 3 of 4] Configfs is really sysfs

[Daniel Phillips]

Configfs rewritten as a single file and updated to use kobjects instead of its
own clone of kobjects (config_items).

diff -up --recursive 2.6.13-rc5-mm1.clean/fs/configfs/Makefile 
2.6.13-rc5-mm1/fs/configfs/Makefile
--- 2.6.13-rc5-mm1.clean/fs/configfs/Makefile 2005-08-09 18:23:30.0 
-0400
+++ 2.6.13-rc5-mm1/fs/configfs/Makefile 2005-08-29 17:26:02.0 -0400
@@ -2,6 +2,5 @@
 # Makefile for the configfs virtual filesystem
 #
 
-obj-$(CONFIG_CONFIGFS_FS) += configfs.o
+obj-$(CONFIG_CONFIGFS_FS) += configfs.o ddbond.config.o
 
-configfs-objs := inode.o file.o dir.o symlink.o mount.o item.o
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/configfs/configfs.c 
2.6.13-rc5-mm1/fs/configfs/configfs.c
--- 2.6.13-rc5-mm1.clean/fs/configfs/configfs.c 2005-08-30 17:50:30.0 
-0400
+++ 2.6.13-rc5-mm1/fs/configfs/configfs.c 2005-08-29 21:36:47.0 -0400
@@ -0,0 +1,1897 @@
+/*
+ * Based on sysfs:
+ *  sysfs Copyright (C) 2001, 2002, 2003 Patrick Mochel
+ *
+ * configfs Copyright (C) 2005 Oracle.  All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CONFIGFS_ROOT  0x0001
+#define CONFIGFS_DIR  0x0002
+#define CONFIGFS_ITEM_ATTR 0x0004
+#define CONFIGFS_ITEM_LINK 0x0020
+#define CONFIGFS_USET_DIR  0x0040
+#define CONFIGFS_USET_DEFAULT  0x0080
+#define CONFIGFS_USET_DROPPING 0x0100
+#define CONFIGFS_NOT_PINNED(CONFIGFS_ITEM_ATTR)
+
+struct sysfs_symlink {
+   struct list_head sl_list;
+   struct kobject *sl_target;
+};
+
+static inline struct kobject *to_kobj(struct dentry *dentry)
+{
+   struct sysfs_dirent *sd = dentry->d_fsdata;
+   return ((struct kobject *)sd->s_element);
+}
+
+static inline struct attribute *to_attr(struct dentry *dentry)
+{
+   struct sysfs_dirent *sd = dentry->d_fsdata;
+   return ((struct attribute *)sd->s_element);
+}
+
+static inline struct kobject *sysfs_get_kobject(struct dentry *dentry)
+{
+   struct kobject *kobj = NULL;
+
+   spin_lock(_lock);
+   if (!d_unhashed(dentry)) {
+   struct sysfs_dirent *sd = dentry->d_fsdata;
+   if (sd->s_type & CONFIGFS_ITEM_LINK) {
+   struct sysfs_symlink *sl = sd->s_element;
+   kobj = kobject_get(sl->sl_target);
+   } else
+   kobj = kobject_get(sd->s_element);
+   }
+   spin_unlock(_lock);
+
+   return kobj;
+}
+
+static kmem_cache_t *sysfs_dir_cachep;
+
+static void release_sysfs_dirent(struct sysfs_dirent *sd)
+{
+   if ((sd->s_type & CONFIGFS_ROOT))
+   return;
+   kmem_cache_free(sysfs_dir_cachep, sd);
+}
+
+static struct sysfs_dirent *sysfs_get(struct sysfs_dirent *sd)
+{
+   if (sd) {
+   WARN_ON(!atomic_read(>s_count));
+   atomic_inc(>s_count);
+   }
+   return sd;
+}
+
+static void sysfs_put(struct sysfs_dirent *sd)
+{
+   WARN_ON(!atomic_read(>s_count));
+   if (atomic_dec_and_test(>s_count))
+   release_sysfs_dirent(sd);
+}
+
+/*
+ * inode.c - basic inode and dentry operations.
+ */
+
+static struct super_block *sysfs_sb;
+
+static struct address_space_operations sysfs_aops = {
+   .readpage = simple_readpage,
+   .prepare_write = simple_prepare_write,
+   .commit_write = simple_commit_write
+};
+
+static struct backing_dev_info sysfs_backing_dev_info = {
+   .ra_pages = 0,  /* No readahead */
+   .capabilities = BDI_CAP_NO_ACCT_DIRTY | BDI_CAP_NO_WRITEBACK,
+};
+
+static struct inode *sysfs_new_inode(mode_t mode)
+{
+   struct inode *inode = new_inode(sysfs_sb);
+   if (inode) {
+   inode->i_blksize = PAGE_CACHE_SIZE;
+   inode->i_blocks = 0;
+   inode->i_mode = mode;
+   inode->i_uid = 0;
+   inode->i_gid = 0;
+   inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
+   inode->i_mapping->a_ops = _aops;
+   inode->i_mapping->backing_dev_info = _backing_dev_info;
+   }
+   return inode;
+}
+
+static int sysfs_create(struct dentry *dentry, int mode, int (*init) (struct 
inode *))
+{
+   int error = 0;
+   struct inode *inode = NULL;
+   if (dentry) {
+   if (!dentry->d_inode) {
+   if ((inode = sysfs_new_inode(mode))) {
+   if (dentry->d_parent
+   && dentry->d_parent->d_inode) {
+   struct inode *p_inode =
+   dentry->d_parent->d_inode;
+   p_inode->i_mtime = p_inode->i_ctime =
+   CURRENT_TIME;
+   }
+   goto Proceed;
+   } else
+   error = -ENOMEM;
+   } else
+   error = -EEXIST;
+   } 

Re: Second "CPU" of 1-core HyperThreading CPU not found in 2.6.13

[Chase Venters]

> Complete 'dmesg' please.

See below.

Thanks,
Chase


Linux version 2.6.13 ([EMAIL PROTECTED]) (gcc version 3.3.5-20050130 (Gentoo 
Linux 
3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1)) #2 SMP Sun Aug 28 
23:54:34 CDT 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e4000 - 0010 (reserved)
 BIOS-e820: 0010 - 3ffb (usable)
 BIOS-e820: 3ffb - 3ffbe000 (ACPI data)
 BIOS-e820: 3ffbe000 - 3fff (ACPI NVS)
 BIOS-e820: 3fff - 4000 (reserved)
 BIOS-e820: ffb8 - 0001 (reserved)
Warning only 896MB will be used.
Use a HIGHMEM enabled kernel.
896MB LOWMEM available.
found SMP MP-table at 000ff780
On node 0 totalpages: 229376
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 225280 pages, LIFO batch:31
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 ACPIAM) @ 0x000fb250
ACPI: RSDT (v001 A M I  OEMRSDT  0x11000429 MSFT 0x0097) @ 0x3ffb
ACPI: FADT (v001 A M I  OEMFACP  0x11000429 MSFT 0x0097) @ 0x3ffb0200
ACPI: OEMB (v001 A M I  AMI_OEM  0x11000429 MSFT 0x0097) @ 0x3ffbe040
ACPI: MCFG (v001 A M I  OEMMCFG  0x11000429 MSFT 0x0097) @ 0x3ffb6c70
ACPI: DSDT (v001  A0077 A0077001 0x0001 INTL 0x02002026) @ 0x
ACPI: PM-Timer IO Port: 0x808
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: INTELProduct ID: DELUXE   APIC at: 0xFEE0
Processor #0 15:4 APIC version 20
I/O APIC #2 Version 32 at 0xFEC0.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 1
Allocating PCI resources starting at 4000 (gap: 4000:bfb8)
Built 1 zonelists
Kernel command line: root=/dev/md1 noapic
mapped APIC to d000 (fee0)
mapped IOAPIC to c000 (fec0)
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 3212.948 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 902076k/917504k available (4249k kernel code, 14984k reserved, 1657k 
data, 268k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6427.67 BogoMIPS 
(lpj=3213838)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff    
441d  
CPU: After vendor identify, caps: bfebfbff    441d 
 
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff   0080 441d 
 
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
mtrr: v2.0 (20020519)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0cb8)
CPU0: Intel(R) Pentium(R) 4 CPU 3.20GHz stepping 01
Total of 1 processors activated (6427.67 BogoMIPS).
Brought up 1 CPUs
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=4
PCI: Using MMCONFIG
ACPI: Subsystem revision 20050408
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] segment is 0
PCI: Ignoring BAR0-3 of IDE controller :00:1f.1
Boot video device is :04:00.0
PCI: Transparent bridge - :00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 *4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 14 devices
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new 

[RFC][PATCH 2 of 4] Configfs is really sysfs

[Daniel Phillips]

Sysfs rearranged as a single file for analysis purposes.

diff -up --recursive 2.6.13-rc5-mm1.clean/fs/sysfs/Makefile 
2.6.13-rc5-mm1/fs/sysfs/Makefile
--- 2.6.13-rc5-mm1.clean/fs/sysfs/Makefile 2005-06-17 15:48:29.0 -0400
+++ 2.6.13-rc5-mm1/fs/sysfs/Makefile 2005-08-29 17:13:59.0 -0400
@@ -2,5 +2,4 @@
 # Makefile for the sysfs virtual filesystem
 #
 
-obj-y  := inode.o file.o dir.o symlink.o mount.o bin.o \
- group.o
+obj-y := sysfs.o
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/sysfs/sysfs.c 
2.6.13-rc5-mm1/fs/sysfs/sysfs.c
--- 2.6.13-rc5-mm1.clean/fs/sysfs/sysfs.c 2005-08-30 17:52:35.0 -0400
+++ 2.6.13-rc5-mm1/fs/sysfs/sysfs.c 2005-08-29 21:04:40.0 -0400
@@ -0,0 +1,1680 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct sysfs_symlink {
+ char *link_name;
+ struct kobject *sl_target;
+};
+
+static inline struct kobject *to_kobj(struct dentry *dentry)
+{
+ struct sysfs_dirent *sd = dentry->d_fsdata;
+ return ((struct kobject *)sd->s_element);
+}
+
+static inline struct attribute *to_attr(struct dentry *dentry)
+{
+   struct sysfs_dirent *sd = dentry->d_fsdata;
+   return ((struct attribute *)sd->s_element);
+}
+
+static inline struct kobject *sysfs_get_kobject(struct dentry *dentry)
+{
+   struct kobject *kobj = NULL;
+
+   spin_lock(_lock);
+   if (!d_unhashed(dentry)) {
+   struct sysfs_dirent *sd = dentry->d_fsdata;
+   if (sd->s_type & SYSFS_KOBJ_LINK) {
+   struct sysfs_symlink *sl = sd->s_element;
+   kobj = kobject_get(sl->sl_target);
+   } else
+   kobj = kobject_get(sd->s_element);
+   }
+   spin_unlock(_lock);
+
+   return kobj;
+}
+
+static kmem_cache_t *sysfs_dir_cachep;
+
+static void release_sysfs_dirent(struct sysfs_dirent *sd)
+{
+   if (sd->s_type & SYSFS_KOBJ_LINK) {
+   struct sysfs_symlink *sl = sd->s_element;
+   kfree(sl->link_name);
+   kobject_put(sl->sl_target);
+   kfree(sl);
+   }
+   kfree(sd->s_iattr);
+   kmem_cache_free(sysfs_dir_cachep, sd);
+}
+
+static struct sysfs_dirent *sysfs_get(struct sysfs_dirent *sd)
+{
+ if (sd) {
+  WARN_ON(!atomic_read(>s_count));
+  atomic_inc(>s_count);
+ }
+ return sd;
+}
+
+static void sysfs_put(struct sysfs_dirent *sd)
+{
+ WARN_ON(!atomic_read(>s_count));
+ if (atomic_dec_and_test(>s_count))
+  release_sysfs_dirent(sd);
+}
+
+/*
+ * inode.c - basic inode and dentry operations.
+ */
+
+int sysfs_setattr(struct dentry *dentry, struct iattr *iattr)
+{
+ struct inode *inode = dentry->d_inode;
+ struct sysfs_dirent *sd = dentry->d_fsdata;
+ struct iattr *sd_iattr;
+ unsigned int ia_valid = iattr->ia_valid;
+ int error;
+
+ if (!sd)
+  return -EINVAL;
+
+ sd_iattr = sd->s_iattr;
+
+ error = inode_change_ok(inode, iattr);
+ if (error)
+  return error;
+
+   error = inode_setattr(inode, iattr);
+   if (error)
+   return error;
+
+   if (!sd_iattr) {
+   /* setting attributes for the first time, allocate now */
+   sd_iattr = kmalloc(sizeof(struct iattr), GFP_KERNEL);
+   if (!sd_iattr)
+   return -ENOMEM;
+   /* assign default attributes */
+   memset(sd_iattr, 0, sizeof(struct iattr));
+   sd_iattr->ia_mode = sd->s_mode;
+   sd_iattr->ia_uid = 0;
+   sd_iattr->ia_gid = 0;
+   sd_iattr->ia_atime = sd_iattr->ia_mtime = sd_iattr->ia_ctime =
+   CURRENT_TIME;
+   sd->s_iattr = sd_iattr;
+   }
+
+   /* attributes were changed atleast once in past */
+
+   if (ia_valid & ATTR_UID)
+   sd_iattr->ia_uid = iattr->ia_uid;
+   if (ia_valid & ATTR_GID)
+   sd_iattr->ia_gid = iattr->ia_gid;
+   if (ia_valid & ATTR_ATIME)
+   sd_iattr->ia_atime = timespec_trunc(iattr->ia_atime,
+   inode->i_sb->s_time_gran);
+   if (ia_valid & ATTR_MTIME)
+   sd_iattr->ia_mtime = timespec_trunc(iattr->ia_mtime,
+  inode->i_sb->s_time_gran);
+ if (ia_valid & ATTR_CTIME)
+  sd_iattr->ia_ctime = timespec_trunc(iattr->ia_ctime,
+  inode->i_sb->s_time_gran);
+ if (ia_valid & ATTR_MODE) {
+  umode_t mode = iattr->ia_mode;
+
+  if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID))
+   mode &= ~S_ISGID;
+  sd_iattr->ia_mode = sd->s_mode = mode;
+ }
+
+ return error;
+}
+
+static struct inode_operations sysfs_inode_operations = {
+ .setattr = sysfs_setattr,
+};
+
+static struct super_block *sysfs_sb;
+
+static struct address_space_operations sysfs_aops = {
+ .readpage = simple_readpage,
+ .prepare_write = simple_prepare_write,
+ .commit_write = simple_commit_write
+};
+
+static struct backing_dev_info sysfs_backing_dev_info = {
+ .ra_pages = 0,  /* No readahead */
+ .capabilities = BDI_CAP_NO_ACCT_DIRTY | 

Re: KLive: Linux Kernel Live Usage Monitor

[Alan Cox]

On Mer, 2005-08-31 at 00:43 +0200, Sven Ladegast wrote:
> collection has. What data does klive send? Is the data just a hash of
> different system variables or is it also possible to identify one single 
> computer (or person)? Data protection...laws etc. are things that must be 
> considered too maybe.

My thinking is something like this

"Register a box + optional PCI id list/CPU info"
Reply with a secured serial number 

Uptime data then can just be boot number, time up


> I think the problem is not the technical implementation. The bigger 
> problem is the data, where it comes from and the most interesting point 
> what to do with it at the end.

We don't need personally identifiable data (email, name, ip address etc)

What to do with it will be most interesting indeed.

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

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

[Daniel Phillips]

Hi Andrew,

Configfs blithely ingests kobject.h and kobject.c into itself, just changing 
the names.  Furthermore, more than half of configfs is copied verbatim from 
sysfs, the only difference being the name changes.  After undoing the name 
changes and adding a few new fields to kobject structures, configfs is able 
to use the real thing instead of its own imitation.

The changes I made to kobject.h and sysfs.h are:

  * add module owner to kobj_type.

  * add group_operations to kobj_type (because configfs does it this way
not because it is right)

  * add a children field to kset.  This is likely the same as the blandly
named "list" field but I haven't confirmed it.

  * add a default_groups field to kset, analogous to the default_attrs of
kobj_type.  Hmm, somebody seems to be mixing up types and containers
here, but let's just close our eyes for now.

  * add an s_links field to sysfs_dirent to support configfs's user
createable symlinks.

  * add two new methods to sysfs_ops for fancy symlink hooks

  * add a questionable release method to sysfs_ops.  Sysfs and configfs
have slightly different notions of when to release objects, one of
them is probably wrong.

That's it, no new fields in kobjects themselves, and just three or four fields 
in other allocateable structures.   After these changes, no structures at all 
are left in configfs.h.  Configfs is now running happily using the kobject 
machinery instead of its own mutated clones and unsurprisingly, sysfs still 
runs happily too.  These changes are all found in the first patch of this 
series.

I then looked into exactly how configfs and sysfs are different.  To reduce 
the noise, I concatentated all the files in each directory into two single 
files.  With redundant declarations removed, configfs came in at 1897 lines 
and sysfs at 1680.  Diffing those two files shows:

diff -u fs/sysfs/sysfs.c fs/configfs/configfs.c | diffstat configfs.c | 1497 
++---
 1 files changed, 857 insertions(+), 640 deletions(-)

So we see that two thirds of sysfs made it into configfs unchanged.  Of the 
remaining one third that configfs has not copied, about one third supports 
read/write/mmappable attribute files (why should configfs not have them 
too?), a little less than a third involves needlessly importing its own 
version of setattr, and the remainder, about 300 lines, exports the kernel 
interface for manipulating the user-visible sysfs tree.

Allowing for a few lines of fluff, configfs's value add is about 750 lines 
of user space glue for namespace operations.  Nothing below that glue layer 
is changed, except cosmetically.  So configfs really is sysfs.  By adding
about 300 lines to configfs we can add the vfs-bypass code, and voila, 
configfs becomess sysfs.  Another 200 lines gives us the binary blob 
attributes as well.  There is no reason whatsover for configfs and sysfs to 
live on as separate code bases.  If we really want to make a distinction, we 
can make the distinction with a flag.

But it would be stupid to forbid users from creating directories in sysfs or 
to forbid kernel modules from directly tweaking a configfs namespace.  Why 
should the kernel not be able to add objects to a directory a user created?  
It should be up to the module author to decide these things.

Please do not push configfs to stable in this form.  It is not actually a new 
filesystem, it is an extension to sysfs.  Merging it as is would add more 
than a thousand lines of pointless kernel bloat.  If indeed we wish to 
present exactly the semantics configfs now offers, we do not need a separate 
code base to do so.

The four patches in this patch set:

  1) Add new fields to kobjects; update other headers to match
  2) Sysfs all in one file
  3) Configfs all in one file
  4) A configfs kernel example using sysfs instead of configfs structures

Regards,

Daniel

diff -up --recursive 2.6.13-rc5-mm1.clean/include/linux/configfs.h 
2.6.13-rc5-mm1/include/linux/configfs.h
--- 2.6.13-rc5-mm1.clean/include/linux/configfs.h   2005-08-09 
18:23:31.0 -0400
+++ 2.6.13-rc5-mm1/include/linux/configfs.h 2005-08-29 18:30:41.0 
-0400
@@ -46,120 +46,32 @@
 
 #define CONFIGFS_ITEM_NAME_LEN 20
 
-struct module;
-
-struct configfs_item_operations;
-struct configfs_group_operations;
-struct configfs_attribute;
-struct configfs_subsystem;
-
-struct config_item {
-   char*ci_name;
-   charci_namebuf[CONFIGFS_ITEM_NAME_LEN];
-   struct kref ci_kref;
-   struct list_headci_entry;
-   struct config_item  *ci_parent;
-   struct config_group *ci_group;
-   struct config_item_type *ci_type;
-   struct dentry   *ci_dentry;
-};
-
-extern int config_item_set_name(struct config_item *, const char *, ...);
-
-static inline char *config_item_name(struct config_item * item)
-{
-   return 

Re: 2.6.13 and the IRQs

[Jesper Juhl]

On 8/31/05, Stephan Grein <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi, i updated my laptop to 2.6.13 vanilla kernel.
> When i booted up it gave me some strange irq messages (debug) which
> showed not up on 2.6.12.2 vanilla. I added irqpoll to lilo.conf, and
> it removed some output. However before i did add irqpoll to lilo my
> pcmcia cards worked also, after adding also.
> Here is the output, maybe you can help me. (I did not change .config
> from 2.6.12.2 to 2.6.13, just did a make oldconfig.)
> cheers.
> 
It seems you forgot to include the output.

full dmesg output and also a  diff -u  of  lspci -vvx  output from
2.6.12 and 2.6.13 would most likely be useful.

-- 
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/

[PATCH] PREEMPT_RT vermagic

[Daniel Walker]

Ingo,
This patch adds a vermagic hook so PREEMPT_RT modules can be
distinguished from PREEMPT_DESKTOP modules.

Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
Index: linux-2.6.10/include/linux/vermagic.h
===
--- linux-2.6.10.orig/include/linux/vermagic.h  2004-12-24 21:35:50.0 
+
+++ linux-2.6.10/include/linux/vermagic.h   2005-08-23 17:35:08.0 
+
@@ -8,7 +8,11 @@
 #define MODULE_VERMAGIC_SMP ""
 #endif
 #ifdef CONFIG_PREEMPT
-#define MODULE_VERMAGIC_PREEMPT "preempt "
+# ifdef CONFIG_PREEMPT_RT
+# define MODULE_VERMAGIC_PREEMPT "preempt_rt "
+# else
+# define MODULE_VERMAGIC_PREEMPT "preempt "
+# endif
 #else
 #define MODULE_VERMAGIC_PREEMPT ""
 #endif


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

Re: KLive: Linux Kernel Live Usage Monitor

[Sven Ladegast]

On Tue, 30 Aug 2005, Alan Cox wrote:


but it would have to be opt in. That might lower coverage but should
increase quality, especially id the id in the cookie can be put into
bugzilla reports, and the hardware reporting is done so it can be
machine processed (ie so you can ask stuff like 'reliability with Nvidia
IDE')


Maybe I used the wrong words... But you are right: It has to be opt-in! A 
change in the kernel sources which automagically sends data, regardless 
what kind of data, to somewhere in the net must not be enabled by default.


But until klive is implemented one day it is interesting thinking about 
what possibilities (and maybe even possible misuse) such a data 
collection has. What data does klive send? Is the data just a hash of
different system variables or is it also possible to identify one single 
computer (or person)? Data protection...laws etc. are things that must be 
considered too maybe.


I think the problem is not the technical implementation. The bigger 
problem is the data, where it comes from and the most interesting point 
what to do with it at the end.


Sven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/1] block: CFQ refcounting fix

[brking]

I ran across a memory leak related to the cfq scheduler. The cfq
init function increments the refcnt of the associated request_queue.
This refcount gets decremented in cfq's exit function. Since blk_cleanup_queue
only calls the elevator exit function when its refcnt goes to zero, the
request_q never gets cleaned up. It didn't look like other io schedulers were
incrementing this refcnt, so I removed the refcnt increment and it fixed the
memory leak for me.

To reproduce the problem, simply use cfq and use the scsi_host scan sysfs
attribute to scan "- - -" repeatedly on a scsi host and watch the memory
vanish.

Signed-off-by: Brian King <[EMAIL PROTECTED]>
---

 linux-2.6-bjking1/drivers/block/cfq-iosched.c |1 -
 1 files changed, 1 deletion(-)

diff -puN drivers/block/cfq-iosched.c~cfq_refcnt_fix drivers/block/cfq-iosched.c
--- linux-2.6/drivers/block/cfq-iosched.c~cfq_refcnt_fix2005-08-30 
17:26:55.0 -0500
+++ linux-2.6-bjking1/drivers/block/cfq-iosched.c   2005-08-30 
17:26:55.0 -0500
@@ -2318,7 +2318,6 @@ static int cfq_init_queue(request_queue_
e->elevator_data = cfqd;
 
cfqd->queue = q;
-   atomic_inc(>refcnt);
 
cfqd->max_queued = q->nr_requests / 4;
q->nr_batching = cfq_queued;
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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

[Henrik Persson]

Linus Torvalds wrote:
> There it is. 
> 
> The most painful part of 2.6.13 is likely to be the fact that we made x86
> use the generic PCI bus setup code for assigning unassigned resources.  
> That uncovered rather a lot of nasty small details, but should also mean
> that a lot of laptops in particular should be able to discover PCI devices
> behind bridges that the BIOS hasn't set up.
> 
> We've hopefully fixed up all the problems that the longish -rc series
> showed, and it shouldn't be that painful, but if you have device problems,
> please make a report that at a minimum contains the unified diff of the
> output of "lspci -vvx" running on 2.6.12 vs 2.6.13. That might give us
> some clues.

Well. 2.6.13 won't boot if I have my Netgear WG511 in the cardbus slot.
It boots just fine if it isn't inserted, though. If I insert it later
on, the computer will freeze and won't respond, just like it does on boot.

2.6.12.5 works just fine, and I just did make oldconfig and used the
defaults (except for the hardware monitoring).

Suggestions, anyone?

diff -u of lspci -vvx + lspci output attached.

It's an Acer Aspire 1302XV.

--
Henrik Persson
--- lspci-2.6.12.5  2005-08-31 00:31:46.274810568 +0200
+++ lspci-2.6.132005-08-31 00:26:45.718371000 +0200
@@ -6,7 +6,7 @@
Region 0: Memory at a000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 
64bit- FW- AGP3- Rate=x1,x2,x4
-   Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit- FW- 
Rate=
+   Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- 
Rate=
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
@@ -40,16 +40,16 @@
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 2f00 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
-   Memory window 0: 2f40-2f7ff000 (prefetchable)
-   Memory window 1: 2f80-2fbff000
-   I/O window 0: 4000-40ff
-   I/O window 1: 4400-44ff
-   BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt- PostWrite+
+   Memory window 0: 3000-31fff000 (prefetchable)
+   Memory window 1: 3200-33fff000
+   I/O window 0: 1000-10ff
+   I/O window 1: 1400-14ff
+   BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
 00: 17 12 72 69 87 00 10 04 00 00 07 06 00 a8 02 00
-10: 00 00 00 2f a0 00 00 02 00 02 05 b0 00 00 40 2f
-20: 00 f0 7f 2f 00 00 80 2f 00 f0 bf 2f 01 40 00 00
-30: fd 40 00 00 01 44 00 00 fd 44 00 00 0b 01 00 05
+10: 00 00 00 2f a0 00 00 02 00 02 05 b0 00 00 00 30
+20: 00 f0 ff 31 00 00 00 32 00 f0 ff 33 01 10 00 00
+30: fd 10 00 00 01 14 00 00 fd 14 00 00 0b 01 80 05
 40: 25 10 1d 00 01 00 00 00 00 00 00 00 00 00 00 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
@@ -163,13 +163,13 @@
Interrupt: pin A routed to IRQ 11
Region 0: Memory at e000 (32-bit, non-prefetchable) [size=512K]
Region 1: Memory at 9000 (32-bit, prefetchable) [size=128M]
-   Expansion ROM at 000c [disabled] [size=64K]
+   Expansion ROM at 9800 [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64- HTrans- 
64bit- FW- AGP3- Rate=x4
-   Command: RQ=32 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit- FW- 
Rate=x4
+   Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=x4
 00: 33 53 02 8d 07 00 30 02 01 00 00 03 04 40 00 00
 10: 00 00 00 e0 08 00 00 90 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 25 10 1d 00
:00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 
80)
Subsystem: Acer Incorporated [ALI]: Unknown device 001d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 06 11 05 03 06 00 10 a2 80 00 00 06 00 08 00 00
10: 08 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 25 10 1d 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00

:00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 

Re: ip_queue.c and TCP resets

[Patrick McHardy]

Michael Rash wrote:
> Attached is a patch against
> linux-2.6.11.12/net/ipv4/netfilter/ip_queue.c to put Ethernet MAC
> addresses directly into the indev_name and outdev_name portions of the
> ipq_packet_msg struct.  This is a total kludge and I doubt anyone else
> will find this useful, but for libipq IPS applications it allows TCP
> resets and other response traffic to be sent out of the appropriate
> physical ports when running as an Ethernet bridge.  I'm sure there are
> better ways to do this, but it seems to work.

ip_queue messages already include the source mac address in the hw_addr
field. The destination isn't included because except with bridge
netfilter it is always the local mac address. If you also need the
destination MAC we could consider including it in nfnetlink_queue
since its new and we don't have to worry about userspace compatibility
at this time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.13 and the IRQs

[Stephan Grein]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi, i updated my laptop to 2.6.13 vanilla kernel.
When i booted up it gave me some strange irq messages (debug) which
showed not up on 2.6.12.2 vanilla. I added irqpoll to lilo.conf, and
it removed some output. However before i did add irqpoll to lilo my
pcmcia cards worked also, after adding also.
Here is the output, maybe you can help me. (I did not change .config
from 2.6.12.2 to 2.6.13, just did a make oldconfig.)
cheers.

- --
Stephan 'hagbard' Grein, <[EMAIL PROTECTED]>
http://hagbard.ninth-art.de/
GnuPG-Key-ID: 0x08FA3507
 :wq
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDFOCqDkIR3wj6NQcRAp6EAJ488ey6G9t7udo9j/eE1sDDJBQSUwCfYzoV
4GhoE3bF8iLxHKdVuGLOit0=
=NY57
-END PGP SIGNATURE-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 8/8] PCI Error Recovery: PPC64 core recovery routines

[John Rose]

Hi Paul-

> I'm suggesting that the rpaphp code has a struct pci_driver whose
> id_table and probe function are such that it will claim the EADS
> bridges.  (It would probably be best to match on vendor=IBM and
> class=PCI-PCI bridge and let the probe function figure out which of
> the bridges it gets asked about are actually EADS bridges.)

Wouldn't this leave out hotplug-capable adapters who have direct PHB
parents, since these parent PHBs don't have pci_devs?  Thoughts?

Thanks-
John

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

Re: State of Linux graphics

[Dave Airlie]

> 
> As the author of Xgl and glitz I'd like to comment on a few things.
> 
> >From the article:
> 
> > Xgl was designed as a near term transition solution. The Xgl model
> > was to transparently replace the drawing system of the existing
> > X server with a compatible one based on using OpenGL as a device
> > driver. Xgl maintained all of the existing X APIs as primary APIs.
> > No new X APIs were offered and none were deprecated.
> ..
> > But Xgl was a near term, transition design, by delaying demand for
> > Xgl the EXA bandaid removes much of the need for it.
> 
> I've always designed Xgl to be a long term solution. I'd like if
> whatever you or anyone else see as not long term with the design of Xgl
> could be clarified.

I sent this comment to Jon before he published:
"Xgl was never near term, maybe you thought it was but no-one else did, the
sheer amount of work to get it to support all the extensions the current X
server does would make it non-near term ..."

I believe he is the only person involved who considered it near term,
without realising quite how much work was needed...

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

Re: LSM root_plug module questions

[Crispin Cowan]

Chris Wright wrote:
> * David Härdeman ([EMAIL PROTECTED]) wrote:
>   
>> 2) root_plug currently scans the usb device tree looking for the 
>> appropriate device each time it's needed. In the interest of making the 
>> result of the lookup cached, it is possible for a module to register so 
>> that it is notified when a usb device is added/removed?
>> 
> I don't think that can be done in a race free manner.  Perhaps get the
> device and check its state, but you'd have to ask usb folks.  ATM, it's
> only checked during exec of root process.
>   
Why do you want to optimize root_plug's scan for the device? Are you
planning on logging in thousands of times per second? If it was a big
RADIUS or SSO server, that would make sense, but this is the "are you
physically present at the console?" login security, so I submit that it
happens at most a couple of times per minute, and from there it does not
matter if it takes a second or two to scan the USB devices.

OTOH, it looks from the above comments that the root_plug may be checked
on *all* exec's of root processes. If that is the case, then you do have
more of an optimization issue. However, I then submit that the correct
optimization is to choke down the check so that it is only performed on
root exec's that represent logins rather than all execs, instead of
trying to make the check go faster.

Crispin
-- 
Crispin Cowan, Ph.D.  http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

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

Re: 2.6.13-rt1

[Daniel Walker]

Have you tried turning on 
"Non-preemptible critical section latency timing" or "Latency tracing"

I don't know if it's related to the PI changes, but I'm getting a crash
with those on em64t .

With both above options I get

<0>init[1]: segfault at 8010ef44 rip 8010ef44 rsp 
7error 5
<0>init[1]: segfault at 8010ef44 rip 8010ef44 rsp 
7ffe8de8 error 5

printed never ending right after init starts.

If I only turn on "Non-preemptible critical section latency timing",
then when I enter the command,
"echo 0 > /proc/sys/kernel/preempt_max_latency"

The kernel will spit out a couple of max critical section updates , then
it will hang silently.

This is all new in 2.6.13-rtX . It could have just come in with 2.6.13 ,
but I thought I'd mention it.

Daniel

On Tue, 2005-08-30 at 09:06 -0400, Steven Rostedt wrote:
> Hi Ingo,
> 
> Looks like the BKL is a little more complicated than what I first sent.
> I've been analyzing the logic and found that there's a point in time
> where the BKL->P1->L1->P2->BKL can exist without any of the spinlocks
> protecting it.  That is after P1 blocks on L1 but before it schedules
> out and releases the BKL.  In this time another process on another CPU
> could loop here.
> 
> The supplied patch fixes this.
> 
> Also, I need to look more into the logic of __up to see if the BKL can't
> cause a deadlock with the grabbing and releasing of locks there.  So I
> might be sending more patches to clean this up.
> 
> Do me a favor, and just take a quick look at the logic here, and make
> sure that the situation is OK to break there, and that there won't be
> any other side-effects, wrt. priority leaks.
> 
> Thanks,
> 
> -- Steve
> 
> Patch is against rt2
> 
> Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
> 
> Index: linux_realtime_goliath/kernel/rt.c
> ===
> --- linux_realtime_goliath/kernel/rt.c(revision 310)
> +++ linux_realtime_goliath/kernel/rt.c(working copy)
> @@ -760,11 +760,12 @@
>   */
>  static void pi_setprio(struct rt_mutex *lock, struct task_struct *task, int 
> prio)
>  {
> - struct rt_mutex *l = lock;
> - struct task_struct *p = task;
>   /*
>* We don't want to release the parameters locks.
>*/
> + struct rt_mutex *l = lock;
> + struct task_struct *p = task;
> + int bkl = 0;
>  
>   if (unlikely(!p->pid)) {
>   pi_null++;
> @@ -800,7 +801,7 @@
>  #endif
>  
>   mutex_setprio(p, prio);
> - if (!w)
> + if (!w || unlikely(bkl))
>   break;
>   /*
>* If the task is blocked on a lock, and we just made
> @@ -817,18 +818,31 @@
>   TRACE_BUG_ON_LOCKED(!lock);
>  
>   /*
> -  * The BKL can really be a pain.  It can happen that the lock
> -  * we are blocked on is owned by a task that is waiting for
> -  * the BKL, and we own it.  So, if this is the BKL and we own
> -  * it, then end the loop here.
> +  * The BKL can really be a pain. It can happen where the
> +  * BKL is being held by one task that is just about to 
> +  * block on another task that is waiting for the BKL.
> +  * This isn't a deadlock, since the BKL is released
> +  * when the task goes to sleep.  This also means that
> +  * all holders of the BKL are not blocked, or are just
> +  * about to be blocked.
> +  *
> +  * Another side-effect of this is that there's a small
> +  * window where the spinlocks are not held, and the blocked
> +  * process hasn't released the BKL.  So if we are going
> +  * to boost the owner of the BKL, stop after that,
> +  * since that owner is either running, or about to sleep
> +  * but don't go any further or we are in a loop.
>*/
> - if (unlikely(l == _sem.lock) && lock_owner(l) == 
> current_thread_info()) {
> - /*
> -  * No locks are held for locks, so fool the unlocking 
> code
> -  * by thinking the last lock was the original.
> -  */
> - l = lock;
> - break;
> + if (unlikely(l == _sem.lock)) {
> + if (lock_owner(l) == current_thread_info()) {
> + /*
> +  * No locks are held for locks, so fool the 
> unlocking code
> +  * by thinking the last lock was the original.
> +  */
> + l = lock;
> + break;
> + }
> + bkl = 1;
>   }
>  
>   if (l != lock)
> 
> 
> -
> To unsubscribe from this 

Re: Kernel 2.6.13: TCP (libnet?)

[Patrick McHardy]

John McGowan wrote:
> Kernel 2.6.13: TCP (libnet?)
> 
> Broken libnet?
> 
> KERNEL: linux-kernel@vger.kernel.org
> LIBNET 1.1 (c) 1998 - 2004 Mike D. Schiffman <[EMAIL PROTECTED]>
> 
> I don't like spam. I track spamvertized sites. Many only respond to TCP
> packets sent to port 80. I need a TCP traceroute (traceroute using TCP/SYN
> packets).
> 
> I have four such programmes.
> 
> 1: Hping in traceroute mode.
>Poor. If it hits a router which does not respond, it just sits
>and waits.
> 2: LFT
>OK.
>a: Does not work in Fedora Core2 - without patching.
>   The source code expects a header of zero bytes in the
>   pcap output of zero bytes (hard coded in the source).
>   My captures have a "linux cooked capture" header of sixteen bytes.
>   Changing an offset from zero to sixteen gets it to work.
>b: Requires traffic on the interface.
>   It seems it gets into a loop and awaits some traffic.
>   It examines it - if it is data it expects it uses it.
>   If it is other data from other programmes accessing the 'net
>   it does nothing with it.
>   In both those cases it moves on and starts over.
>   What if there is no traffic? Unless there is something for it
>   either to use or ignore, it seems to hang. To get it to work
>   I have to, say, read the NY Times online while running it.
>   (I believe the traceproto site mentions doing something to
>   get around the timeout problem)
>Output is OK - but I don't really like it.
> 3: Tcptraceroute
>I have used this since kernel 2.2 through 2.4
>(older version with older version of libnet) and
>2.6.5, 2.6.7, 2.6.9, 2.6.10, 2.6.11, 2.6.12
>It was my favourite until I got traceproto.
> 4: Traceproto
>I have used this in kernels 2.4,
>2.6.5, 2.6.7, 2.6.9, 2.6.10, 2.6.11, 2.6.12
>Good.
> 
> 
> In kernel 2.6.13: [patching 2.1.12 with the patch file]
> 
>  Standard "traceroute" works.
>  LFT works.
>  HPING works (also in traceroute mode).
>  tcptraceroute fails.
>  traceproto (tcp or udp mode) fails.
> 
> How do they fail?
> 
> A TCPDUMP shows that they do send out the packets.
> I do get back ICMP "time exceeded" error messages.
> They no longer recognize them.
> 
> Something that had never changed before has now changed
> and has broken traceproto and tcptraceroute. 

[netdev CC'ed]

Could you provide tcpdump dumps and your .config file please?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Very strange Marvell/Yukon Gigabit NIC networking problems

[Stephen Hemminger]

On Wed, 31 Aug 2005 07:49:37 +1000 (EST)
Steve Kieu <[EMAIL PROTECTED]> wrote:

> 
> --- Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> 
> > You have a version of the Marvell Yukon that was
> > affected
> > by a fix in 2.6.13.
> > skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9
> > 
> > Both the skge and sk98lin driver were fixed to check
> > for this.
> > Without the fix, the chip will be in the wrong power
> > mode.
> > 
> > The version of sk98lin driver from SysKonnect
> > already had the
> > fix, so if your distro used that one, it would have
> > the reset
> > the power mode as needed.
> 
> I am afraid not. The last time, I reproduced the
> problem using the latest sk98lin driver from
> SysKonnect  (run create patch and patch the kernel
> 2.6.13). Problem still there. The file I got from
> sysconnect is:
> 
> install-8_23.tar.bz2

Just look for references to CHIP_REV_YU_LITE_A3 in the driver
sk98lin/skgeinit.c and sk98lin/skxmac2.c
The comparison should always be:
pAC->GIni.GIChipRev >= CHIP_REV_YU_LITE_A3
otherwise it will not correctly take chip out of powerdown (coma) mode.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Telecom Clock driver for MPCBL0010 ATCA compute blade.

[Jesper Juhl]

On 8/31/05, Mark Gross <[EMAIL PROTECTED]> wrote:
> On Tuesday 30 August 2005 14:19, Jesper Juhl wrote:
> > On 8/30/05, Mark Gross <[EMAIL PROTECTED]> wrote:
> > > On Tuesday 30 August 2005 13:31, Mark Gross wrote:
> > > > On Tuesday 30 August 2005 12:16, Marcelo Tosatti wrote:
> > > > >
> > > > > Mark,
> > > > >
> > > > > Please fix identation accordingly to CodingStyle and repost, it
> > > > > looks quite ugly at the moment.
> > > > >
> > > > Sorry about that.
> > > >
> > >
> > > My email client is f-ing with me.  See attached.
> > >
> >
> > ok, a few small comments  :
> >
[snip]
> Thank you for your input.  See attached.
> 
You're welcome.
I see you fixed some of it, but I wonder why you didn't bother to fix
the spelling errors in the comments while you were at it? :-)  -
"Uppon", "interaces" ...
No big deal though.

-- 
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: [Linux-fbdev-devel] [PATCH 1/1 2.6.13] framebuffer: bit_putcs() optimization for 8x* fonts

[Knut Petersen]

Hi Roman,

Could you try the patch below, for a few extra cycles you might want to 
make it an inline function.
 

No, it does not help. If there is any difference, it is too small to be 
measured on

my system ... and my system does run at 1000 Hz.

After 2.6.12 fb_pad_aligned_buffer() was changed to use memcpy() instead 
of a
bytewise copy. That slowed things down a lot, some weeks ago that was 
reverted.
fb_pad_aligned _buffer() isn´t that slow, it´s just an external function 
to be called

and that means a lot of unnecessary code.

How could I make it an inline function? It is used in console/bitblit.c, 
nvidia/nvidia.c,

riva/fbdev.c and softcursor.c.

cu,
Knut
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 4/9] UML - Mark SMP on UML/x86_64 as broken

[Jeff Dike]

On Tue, Aug 30, 2005 at 10:42:15PM +0200, Andi Kleen wrote:
> The generic one should work too, it's just less efficient.
> So you can probably easily replace them.

Yup, just something that hasn't been done yet.

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: Telecom Clock driver for MPCBL0010 ATCA compute blade.

[Mark Gross]

On Tuesday 30 August 2005 14:19, Jesper Juhl wrote:
> On 8/30/05, Mark Gross <[EMAIL PROTECTED]> wrote:
> > On Tuesday 30 August 2005 13:31, Mark Gross wrote:
> > > On Tuesday 30 August 2005 12:16, Marcelo Tosatti wrote:
> > > >
> > > > Mark,
> > > >
> > > > Please fix identation accordingly to CodingStyle and repost, it
> > > > looks quite ugly at the moment.
> > > >
> > > Sorry about that.
> > >
> > 
> > My email client is f-ing with me.  See attached.
> > 
> 
> ok, a few small comments  : 
> 
> 
> +/* sysFS interface definition:
> 
> Isn't it just called "sysfs" without the caps?
> 
> +Uppon loading the driver will create a sysfs directory under 
> class/misc/tlclk.
> 
> s/Uppon/Upon/
> 
> +This directory exports the following interfaces.  There opperation is
> documented
> 
> Line is longer than 80 chars - there are a few more such long lines,
> not going to point them all out, just one example. Ohh, and
> "opperation" should be "operation".
> 
> +All sysfs interaces are integers in hex format, i.e echo 99 > refalign
> 
> s/interaces/interfaces/
> 
> +#if CONFIG_DEBUG_KERNEL
> 
> I believe this should be "#ifdef CONFIG_DEBUG_KERNEL" or "#if
> defined(CONFIG_DEBUG_KERNEL)" or you'll run afoul of the -Wundef
> crowd.
> 
> + int ret_val = 0;
> 
> There seems to be a preference for the name "retval" in the kernel source.
> 
> + val = (unsigned char)arg;
> 
> 
> That cast looks pointless.
> 
> +tlclk_read(struct file * filp, char __user * buf, size_t count, loff_t * 
> f_pos)
> 
> 
> tlclk_read(struct file *filp, char __user *buf, size_t count, loff_t *f_pos)
> "*" next to the variable name is generally the preffered coding style
> (several cases of this, only pointing out one).
> 
> + val = (unsigned char)tmp;
> 
> pointless cast. Do take a look at all your casts and check if they are
> really needed and remove them if not.
> 
> + * This is also the probe opperation to avoid driver use on 
> 
> s/opperation/operation/
> 
> +/* switchover_timer.function = switchover_timeout; */
> 
> +/* switchover_timer.data = 0; */
> 
> Why submit a driver with commented out code? If this is not supposed
> to be there, then just remove it. If it needs to be added later, then
> submit a patch later to add it.
> Some people may disagree with me here, but that's my oppinion.
> 
> +  out3:
> 
> 
> labels belong at column 0 (zero).
> 
> 
Thank you for your input.  See attached.


-- 
--mgross
BTW: This may or may not be the opinion of my employer, more likely not.  
diff -urN -X dontdiff_osdl vanilla/linux-2.6.13/drivers/char/Kconfig linux-2.6.13/drivers/char/Kconfig
--- vanilla/linux-2.6.13/drivers/char/Kconfig	2005-08-28 16:41:01.0 -0700
+++ linux-2.6.13/drivers/char/Kconfig	2005-08-30 10:52:25.950853752 -0700
@@ -1002,5 +1002,15 @@
 
 source "drivers/char/tpm/Kconfig"
 
+config TELCLOCK
+	tristate "Telecom clock driver for ATCA"
+	depends on EXPERIMENTAL
+	default n
+	help
+	  The telecom clock device allows direct userspace access to the
+	  configuration of the telecom clock configuration settings.
+	  This device is used for hardware synchronization across the ATCA
+	  backplane fabric.
+
 endmenu
 
diff -urN -X dontdiff_osdl vanilla/linux-2.6.13/drivers/char/Makefile linux-2.6.13/drivers/char/Makefile
--- vanilla/linux-2.6.13/drivers/char/Makefile	2005-08-28 16:41:01.0 -0700
+++ linux-2.6.13/drivers/char/Makefile	2005-08-30 10:52:25.952853448 -0700
@@ -82,6 +82,7 @@
 obj-$(CONFIG_SCx200_GPIO) += scx200_gpio.o
 obj-$(CONFIG_GPIO_VR41XX) += vr41xx_giu.o
 obj-$(CONFIG_TANBAC_TB0219) += tb0219.o
+obj-$(CONFIG_TELCLOCK) += tlclk.o
 
 obj-$(CONFIG_WATCHDOG)	+= watchdog/
 obj-$(CONFIG_MWAVE) += mwave/
diff -urN -X dontdiff_osdl vanilla/linux-2.6.13/drivers/char/tlclk.c linux-2.6.13/drivers/char/tlclk.c
--- vanilla/linux-2.6.13/drivers/char/tlclk.c	1969-12-31 16:00:00.0 -0800
+++ linux-2.6.13/drivers/char/tlclk.c	2005-08-30 15:11:42.760859152 -0700
@@ -0,0 +1,937 @@
+/*
+ * Telecom Clock driver for Intel NetStructure(tm) MPCBL0010
+ *
+ * Copyright (C) 2005 Kontron Canada
+ *
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT.  See the GNU General Public License for more
+ * details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * Send feedback to <[EMAIL PROTECTED]>
+ * 
+ * 2.6 driver version being maintained by <[EMAIL PROTECTED]>
+ *
+ * Description : This is the TELECOM CLOCK module 

[PATCH 1/1] Implement shared page tables

[Dave McCracken]

This patch implements page table sharing for all shared memory regions that
span an entire page table page.  It supports sharing at multiple page
levels, depending on the architecture.

Performance testing has shown no degradation with this patch for tests with
small processes.  Preliminary tests with large benchmarks have shown as
much as 3% improvement in overall results.

For those familiar with the shared page table patch I did a couple of years
ago, this patch does not implement copy-on-write page tables for private
mappings.  Analysis showed the cost and complexity far outweighed any
potential benefit.

This version of the patch supports i386 and x86_64.  I have additional
patches to support ppc64, but they are not quite ready for public
consumption.

The patch is against 2.6.13.

Dave McCracken
--- 2.6.13/./arch/i386/Kconfig  2005-08-28 18:41:01.0 -0500
+++ 2.6.13-shpt/./arch/i386/Kconfig 2005-08-29 10:02:47.0 -0500
@@ -748,6 +748,18 @@ config X86_PAE
depends on HIGHMEM64G
default y
 
+config PTSHARE
+   bool "Share page tables"
+   default y
+   help
+ Turn on sharing of page tables between processes for large shared
+ memory regions.
+
+config PTSHARE_PTE
+   bool
+   depends on PTSHARE
+   default y
+
 # Common NUMA Features
 config NUMA
bool "Numa Memory Allocation and Scheduler Support"
--- 2.6.13/./arch/x86_64/Kconfig2005-08-28 18:41:01.0 -0500
+++ 2.6.13-shpt/./arch/x86_64/Kconfig   2005-08-29 10:02:47.0 -0500
@@ -240,6 +240,38 @@ config NUMA_EMU
  into virtual nodes when booted with "numa=fake=N", where N is the
  number of nodes. This is only useful for debugging.
 
+config PTSHARE
+   bool "Share page tables"
+   default y
+   help
+ Turn on sharing of page tables between processes for large shared
+ memory regions.
+
+menu "Page table levels to share"
+   depends on PTSHARE
+
+config PTSHARE_PTE
+   bool "Bottom level table (PTE)"
+   depends on PTSHARE
+   default y
+
+config PTSHARE_PMD
+   bool "Middle level table (PMD)"
+   depends on PTSHARE
+   default y
+
+config PTSHARE_PUD
+   bool "Upper level table (PUD)"
+   depends on PTSHARE
+   default n
+
+endmenu
+
+config PTSHARE_HUGEPAGE
+   bool
+   depends on PTSHARE && PTSHARE_PMD
+   default y
+
 config ARCH_DISCONTIGMEM_ENABLE
bool
depends on NUMA
--- 2.6.13/./arch/x86_64/mm/fault.c 2005-08-28 18:41:01.0 -0500
+++ 2.6.13-shpt/./arch/x86_64/mm/fault.c2005-08-29 10:02:47.0 
-0500
@@ -153,7 +153,7 @@ void dump_pagetable(unsigned long addres
if (bad_address(pgd)) goto bad;
if (!pgd_present(*pgd)) goto ret; 
 
-   pud = __pud_offset_k((pud_t *)pgd_page(*pgd), address);
+   pud = __pud_offset_k((pud_t *)pgd_page_kernel(*pgd), address);
if (bad_address(pud)) goto bad;
printk("PUD %lx ", pud_val(*pud));
if (!pud_present(*pud)) goto ret;
@@ -259,7 +259,7 @@ static int vmalloc_fault(unsigned long a
pud_ref = pud_offset(pgd_ref, address);
if (pud_none(*pud_ref))
return -1;
-   if (pud_none(*pud) || pud_page(*pud) != pud_page(*pud_ref))
+   if (pud_none(*pud) || pud_page_kernel(*pud) != 
pud_page_kernel(*pud_ref))
BUG();
pmd = pmd_offset(pud, address);
pmd_ref = pmd_offset(pud_ref, address);
--- 2.6.13/./include/asm-x86_64/pgtable.h   2005-08-28 18:41:01.0 
-0500
+++ 2.6.13-shpt/./include/asm-x86_64/pgtable.h  2005-08-29 10:02:47.0 
-0500
@@ -100,9 +100,6 @@ extern inline void pgd_clear (pgd_t * pg
set_pgd(pgd, __pgd(0));
 }
 
-#define pud_page(pud) \
-((unsigned long) __va(pud_val(pud) & PHYSICAL_PAGE_MASK))
-
 #define ptep_get_and_clear(mm,addr,xp) __pte(xchg(&(xp)->pte, 0))
 #define pte_same(a, b) ((a).pte == (b).pte)
 
@@ -309,7 +306,8 @@ static inline int pmd_large(pmd_t pte) {
 /*
  * Level 4 access.
  */
-#define pgd_page(pgd) ((unsigned long) __va((unsigned long)pgd_val(pgd) & 
PTE_MASK))
+#define pgd_page_kernel(pgd) ((unsigned long) __va((unsigned long)pgd_val(pgd) 
& PTE_MASK))
+#define pgd_page(pgd)  (pfn_to_page(pgd_val(pgd) >> PAGE_SHIFT))
 #define pgd_index(address) (((address) >> PGDIR_SHIFT) & (PTRS_PER_PGD-1))
 #define pgd_offset(mm, addr) ((mm)->pgd + pgd_index(addr))
 #define pgd_offset_k(address) (init_level4_pgt + pgd_index(address))
@@ -317,9 +315,11 @@ static inline int pmd_large(pmd_t pte) {
 #define mk_kernel_pgd(address) ((pgd_t){ (address) | _KERNPG_TABLE })
 
 /* PUD - Level3 access */
+#define pud_page_kernel(pud) ((unsigned long) __va(pud_val(pud) & 
PHYSICAL_PAGE_MASK))
+#define pud_page(pud)  (pfn_to_page(pud_val(pud) >> PAGE_SHIFT))
 /* to find an entry in a page-table-directory. */
 #define pud_index(address) (((address) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
-#define pud_offset(pgd, address) ((pud_t 

Re: KLive: Linux Kernel Live Usage Monitor

[Bill Davidsen]

Rogier Wolff wrote:

On Tue, Aug 30, 2005 at 10:53:13AM +0200, Sven Ladegast wrote:


A trick to use would be to send an UDP packet at boot (after 1 minute
or so), and then randomly say "once a month" (i.e. about 1/30 chance of
sending a packet on the first day) The number of these random packets
recieved is a measure of the number of CPU-months that the kernel
runs.


This could be a sloution but like you know UDP packets may or may not 
arrive the destination address. So the packet loss with this method could 
be very high, expecially if you send only one packet. Using a 
TCP-connection for this is a lot more stable and the payload can be 
encrypted too.


The information will be public anyway, what's the gain. This is a way 
for people to voluntarily give you information, keep it simple. And to 
that end run it as a user program. It should call home at start (boot), 
stop, and from time to time to prove it's up. A single UDP packet can do 
all that, and if you see machine X boot 2.6.99-rc5 and drop back to rc4 
in ten minutes, that's valuable information. And if people stop running 
the test kernel and drop back to a vendor kernel, THAT'S valuable info 
as well. Time of use is not the only indication here, fallback is an 
indication that a kernel boot was not pleasing in some way.



The "load" that an UDP packet poses on a system is much lower than
for a TCP connection. The fact that UDP packets sometimes get lost
is not much of an issue: Those packets simply wouldn't get logged.
So what?

In 90%  (my guess, 90% of statistics is made up) of the cases 
where the first packet doesn't reach the destination, any subsequent

packets also wouldn't. So if it is so unimportant as here, why bother
with the more overhead of the TCP connection?


Your assumption is unrealistic, a fair number of routers start dropping 
packets under load, ping first, then some other icmp, then udp, tcp last 
(usually).


The "in kernel module" that might send this, could put some easily
gathered information into the packet. The goal of logging kernels-
that-get-run would then be met. Installing a userspace program is
something that most testers won't be bothered to do.


I think you have it backward, people will add a user program after the 
fact, they may not recompile just to add a feature.


A kernel option that is clearly documented what exact info is logged
would IMHO work better. (A userspace program is technically a better
solution, the social aspect of getting a bigger user-base is the main
reason for me to suggest the in-kernel approach).


The social issue is that on a stable machine I'm not going to change the 
kernel, but any one user can run the program to provide usage without 
having access to anything important, so I can install this as nobody or 
it's own UID, and feel better than putting it in my kernel.


(the people who go upgrading kernels tend to be different people from
those who go installing programs for fun.)


Part of my testing involves booting a kernel and seeing if it stays up, 
the user program could be added after the fact.


The kernel info, memory, CPU, and machine name can be gotten without 
privs, as can uptime. As far as how to install it, provide a script and 
put it in cron (system or user). So you can actually track so info on 
the system, like load. A week running while I was on vacation doesn't 
test much, a week running on a loaded server tests other things.


The use will depend on how easy it is to install, patch and build isn't 
easy. Crontab is. And I bet developers would be interested in how long 
it takes a new release to be used in production. There are lots of 
things you could add, but get it working first.


--
   -bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LSM root_plug module questions

[Chris Wright]

* David Härdeman ([EMAIL PROTECTED]) wrote:
> I'm currently playing around with the security/root_plug.c LSM module 
> and I have two questions:

you'll have better luck on the lsm list 

> 1) What's the recommended way of telling that someone is logging in to 
> the computer (via ssh, virtual console, serial console, X, whatever) 
> with LSM? Look for open() on /dev/pts?

logging in...this is really a userspace notion, so via PAM.  creating a
new process or changing credentials of a new process are the types of
things that lsm watches (and of course, opening of files).

> 2) root_plug currently scans the usb device tree looking for the 
> appropriate device each time it's needed. In the interest of making the 
> result of the lookup cached, it is possible for a module to register so 
> that it is notified when a usb device is added/removed?

I don't think that can be done in a race free manner.  Perhaps get the
device and check its state, but you'd have to ask usb folks.  ATM, it's
only checked during exec of root process.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] libata: add ATAPI module option

[Jeff Garzik]

Though DMA alignment, CDB interrupt, DMADIR, and PIO support issues
keep libata's ATAPI support turned off by default, as of 2.6.13-git1
PATA users with non-ancient CDROM and DVD drives can start testing
the ATAPI code.

I just checked the following patch into the 'upstream' branch of
libata-dev.git, to be sent to Linus in a few days.

To emphasize, however: DO NOT use libata ATAPI in a production setting.



 [libata] allow ATAPI to be enabled with new atapi_enabled module option

 ATAPI is getting close to being ready.  To increase exposure, we enable
 the code in the upstream kernel, but default it to off (present
 behavior).  Users must pass atapi_enabled=1 as a module option (if
 module) or on the kernel command line (if built in) to turn on
 discovery of their ATAPI devices.

diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -75,6 +75,10 @@ static void __ata_qc_complete(struct ata
 static unsigned int ata_unique_id = 1;
 static struct workqueue_struct *ata_wq;
 
+int atapi_enabled = 0;
+module_param(atapi_enabled, int, 0444);
+MODULE_PARM_DESC(atapi_enabled, "Enable discovery of ATAPI devices (0=off, 
1=on)");
+
 MODULE_AUTHOR("Jeff Garzik");
 MODULE_DESCRIPTION("Library module for ATA devices");
 MODULE_LICENSE("GPL");
diff --git a/drivers/scsi/libata-scsi.c b/drivers/scsi/libata-scsi.c
--- a/drivers/scsi/libata-scsi.c
+++ b/drivers/scsi/libata-scsi.c
@@ -1470,10 +1470,10 @@ ata_scsi_find_dev(struct ata_port *ap, s
if (unlikely(!ata_dev_present(dev)))
return NULL;
 
-#ifndef ATA_ENABLE_ATAPI
-   if (unlikely(dev->class == ATA_DEV_ATAPI))
-   return NULL;
-#endif
+   if (atapi_enabled) {
+   if (unlikely(dev->class == ATA_DEV_ATAPI))
+   return NULL;
+   }
 
return dev;
 }
diff --git a/drivers/scsi/libata.h b/drivers/scsi/libata.h
--- a/drivers/scsi/libata.h
+++ b/drivers/scsi/libata.h
@@ -38,6 +38,7 @@ struct ata_scsi_args {
 };
 
 /* libata-core.c */
+extern int atapi_enabled;
 extern struct ata_queued_cmd *ata_qc_new_init(struct ata_port *ap,
  struct ata_device *dev);
 extern void ata_qc_free(struct ata_queued_cmd *qc);
diff --git a/include/linux/libata.h b/include/linux/libata.h
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -40,7 +40,6 @@
 #undef ATA_VERBOSE_DEBUG   /* yet more debugging output */
 #undef ATA_IRQ_TRAP/* define to ack screaming irqs */
 #undef ATA_NDEBUG  /* define to disable quick runtime checks */
-#undef ATA_ENABLE_ATAPI/* define to enable ATAPI support */
 #undef ATA_ENABLE_PATA /* define to enable PATA support in some
 * low-level drivers */
 #undef ATAPI_ENABLE_DMADIR /* enables ATAPI DMADIR bridge support */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: As of 2.6.13-rc1 Fusion-MPT very slow

[tony . luck]

> This is alive and well in 2.6.13 (final) on ia64.

Or perhaps not.  When I went into the machine room to take
a look at this machine, I found that the disk drive in
question was making some very bad noises.  A few minutes
later it stopped responding at all.

Putting in a new drive, I see a consistent 51 MB/s on /dev/sdb

Sorry for the noise.

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

Re: Very strange Marvell/Yukon Gigabit NIC networking problems

[Steve Kieu]

--- Stephen Hemminger <[EMAIL PROTECTED]> wrote:

> You have a version of the Marvell Yukon that was
> affected
> by a fix in 2.6.13.
>   skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9
> 
> Both the skge and sk98lin driver were fixed to check
> for this.
> Without the fix, the chip will be in the wrong power
> mode.
> 
> The version of sk98lin driver from SysKonnect
> already had the
> fix, so if your distro used that one, it would have
> the reset
> the power mode as needed.

I am afraid not. The last time, I reproduced the
problem using the latest sk98lin driver from
SysKonnect  (run create patch and patch the kernel
2.6.13). Problem still there. The file I got from
sysconnect is:

install-8_23.tar.bz2

> 


S.KIEU






 
Do you Yahoo!? 
The New Yahoo! Movies: Check out the Latest Trailers, Premiere Photos and full 
Actor Database. 
http://au.movies.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/

Consulting Opportunity - Ph.D. Preferred

[Karene]

Dear Business Professional,
  
I’m writing you today because I’d like to invite you to list your CV or resume 
with our expert witness referral service. There are literally in excess of 2 
million litigation cases filed each year which require industry-specific 
expertise of individuals such as yourself who are in a position to provide 
support, advise counsel, and navigate through the volumes of information on 
which these cases are based – all at very lucrative hourly rates. Expert 
Witness Bank, the world’s premier referral service, actively markets your 
skills to legal industry and charges no fees upon engagement. Expert Witness 
Bank will notify you whenever a project becomes available which is suitably 
matched to your expertise. 
  
Please visit www.expertwitnessbank.com/info.html and learn more about the 
benefits of joining our premier network.
  
As an Expert Witness Bank member you will be able to upload your resume and 
list all areas of your expertise. You will also have the opportunity to upgrade 
to our Premium Membership program and receive weekly notifications of every 
active case for which we are currently seeking experts. For more information 
and to receive our special introductory rate for 1st-time members, visit 
www.expertwitnessbank.com/info.html. 
  
Please list with us only if you are a qualified expert in your field.  Your 
listing will be declined otherwise. As I have reached you directly however, I 
apologize in advance if I have misunderstood your area of expertise.
  
I hope that you choose to join our referral service.  If you have any questions 
or require assistance listing your resume with us, please don’t hesitate to 
email me directly at [EMAIL PROTECTED]
  
I sincerely look forward to working with you,
  
Karene
  


Karene France
Expert Witness Bank | [EMAIL PROTECTED] 
A Service of Micro Survivor, Inc.
Tel: 650-248-4831
Fax: 650-249-3557
www.ExpertWitnessBank.com 
Bridging Valuable Expertise with Opportunity
 
P.S. Please reply with "Exclude" in your email if you want to be excluded from 
well-paid expert witness opportunities.

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

LSM root_plug module questions

[David Härdeman]

Hi,

I'm currently playing around with the security/root_plug.c LSM module 
and I have two questions:


1) What's the recommended way of telling that someone is logging in to 
the computer (via ssh, virtual console, serial console, X, whatever) 
with LSM? Look for open() on /dev/pts?


2) root_plug currently scans the usb device tree looking for the 
appropriate device each time it's needed. In the interest of making the 
result of the lookup cached, it is possible for a module to register so 
that it is notified when a usb device is added/removed?


Regards,
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: [PATCH] crypto_free_tfm callers do not need to check for NULL

[Jesper Juhl]

On 8/30/05, Sridhar Samudrala <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-08-30 at 22:45 +0200, Jesper Juhl wrote:
> > Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
> > there's no longer any need for callers of that function to check for NULL.
> > This patch removes the redundant NULL checks and also a few similar checks
> > for NULL before calls to kfree() that I ran into while doing the
> > crypto_free_tfm bits.
> >
> > I've posted similar patches in the past, but was asked to first until the
> > short-circuit patch moved from -mm to mainline - and since it is now
> > firmly there in 2.6.13 I assume there's no problem there anymore.
> > I was also asked previously to make the patch against mainline and not -mm,
> > so this patch is against 2.6.13.
> >
> > Feedback, ACK, NACK, etc welcome.
> 
> sctp change looks fine.
> A similar check in sctp_endpoint_destroy() can also be removed.
> 
Thanks, I'll remember that and either update the patch or send a small
incremental one later.

-- 
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: Telecom Clock driver for MPCBL0010 ATCA compute blade.

[Jesper Juhl]

On 8/30/05, Mark Gross <[EMAIL PROTECTED]> wrote:
> On Tuesday 30 August 2005 13:31, Mark Gross wrote:
> > On Tuesday 30 August 2005 12:16, Marcelo Tosatti wrote:
> > >
> > > Mark,
> > >
> > > Please fix identation accordingly to CodingStyle and repost, it
> > > looks quite ugly at the moment.
> > >
> > Sorry about that.
> >
> 
> My email client is f-ing with me.  See attached.
> 

ok, a few small comments  : 


+/* sysFS interface definition:

Isn't it just called "sysfs" without the caps?

+Uppon loading the driver will create a sysfs directory under class/misc/tlclk.

s/Uppon/Upon/

+This directory exports the following interfaces.  There opperation is
documented

Line is longer than 80 chars - there are a few more such long lines,
not going to point them all out, just one example. Ohh, and
"opperation" should be "operation".

+All sysfs interaces are integers in hex format, i.e echo 99 > refalign

s/interaces/interfaces/

+#if CONFIG_DEBUG_KERNEL

I believe this should be "#ifdef CONFIG_DEBUG_KERNEL" or "#if
defined(CONFIG_DEBUG_KERNEL)" or you'll run afoul of the -Wundef
crowd.

+   int ret_val = 0;

There seems to be a preference for the name "retval" in the kernel source.

+   val = (unsigned char)arg;


That cast looks pointless.

+tlclk_read(struct file * filp, char __user * buf, size_t count, loff_t * f_pos)


tlclk_read(struct file *filp, char __user *buf, size_t count, loff_t *f_pos)
"*" next to the variable name is generally the preffered coding style
(several cases of this, only pointing out one).

+   val = (unsigned char)tmp;

pointless cast. Do take a look at all your casts and check if they are
really needed and remove them if not.

+ * This is also the probe opperation to avoid driver use on 

s/opperation/operation/

+/* switchover_timer.function = switchover_timeout; */

+/* switchover_timer.data = 0; */

Why submit a driver with commented out code? If this is not supposed
to be there, then just remove it. If it needs to be added later, then
submit a patch later to add it.
Some people may disagree with me here, but that's my oppinion.

+  out3:


labels belong at column 0 (zero).


-- 
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/

[PATCH] New SBC8360 watchdog driver (revised)

[Ian E. Morgan]

On Mon, 29 Aug 2005, [EMAIL PROTECTED] wrote:


The patch titled
watchdog: new SBC8360 driver
has been added to the -mm tree.  Its filename is
watchdog-new-sbc8360-driver.patch


On Mon, 29 Aug 2005, [EMAIL PROTECTED] wrote:


The patch titled
watchdog-new-sbc8360-driver-tidy
has been added to the -mm tree.  Its filename is
watchdog-new-sbc8360-driver-tidy.patch



Andrew,

Please find below a revised version of the SBC8360 watchdog driver patch
which incorporates a few cleanups (no code changes):

- integrates your above 'tidy' patch
- fixes typos in the documentation related to the ioports used
- removes some end-of-line trailing spaces
- run through scripts/Lindent

You may replace the above two patches with the one below. It patches cleanly
on 2.6.13.

Regards,
Ian Morgan

--
---
 Ian E. Morgan  Vice President & C.O.O.   Webcon, Inc.
 imorgan at webcon dot ca   PGP: #2DA40D07   www.webcon.ca
*  Customized Linux Network Solutions for your Business  *
---


diff -urN linux/drivers/char/watchdog/Kconfig~ 
linux/drivers/char/watchdog/Kconfig
--- linux/drivers/char/watchdog/Kconfig~2005-02-15 18:19:22.0 
-0500
+++ linux/drivers/char/watchdog/Kconfig 2005-02-15 18:19:22.0 -0500
@@ -224,6 +224,19 @@

  Most people will say N.

+config SBC8360_WDT
+   tristate "SBC8360 Watchdog Timer"
+   depends on WATCHDOG && X86
+   ---help---
+
+ This is the driver for the hardware watchdog on the SBC8360 Single
+ Board Computer produced by Axiomtek Co., Ltd. (www.axiomtek.com).
+
+ To compile this driver as a module, choose M here: the
+ module will be called sbc8360.ko.
+
+ Most people will say N.
+
 config WAFER_WDT
tristate "ICP Wafer 5823 Single Board Computer Watchdog"
depends on WATCHDOG && X86
diff -urN linux/drivers/char/watchdog/Makefile~ 
linux/drivers/char/watchdog/Makefile
--- linux/drivers/char/watchdog/Makefile~   2005-02-15 18:20:03.0 
-0500
+++ linux/drivers/char/watchdog/Makefile2005-02-15 18:20:03.0 
-0500
@@ -6,6 +6,7 @@
 obj-$(CONFIG_ACQUIRE_WDT) += acquirewdt.o
 obj-$(CONFIG_ADVANTECH_WDT) += advantechwdt.o
 obj-$(CONFIG_IB700_WDT) += ib700wdt.o
+obj-$(CONFIG_SBC8360_WDT) += sbc8360.o
 obj-$(CONFIG_MIXCOMWD) += mixcomwd.o
 obj-$(CONFIG_SCx200_WDT) += scx200_wdt.o
 obj-$(CONFIG_60XX_WDT) += sbc60xxwdt.o
diff -urN /dev/null linux/drivers/char/watchdog/sbc8360.c
--- /dev/null   2004-02-23 16:02:56.0 -0500
+++ linux/drivers/char/watchdog/sbc8360.c   2005-08-30 17:08:35.0 
-0400
@@ -0,0 +1,419 @@
+/*
+ * SBC8360 Watchdog driver
+ *
+ * (c) Copyright 2005 Webcon, Inc.
+ *
+ * Based on ib700wdt.c, which is based on advantechwdt.c which is based
+ *  on acquirewdt.c which is based on wdt.c.
+ *
+ * (c) Copyright 2001 Charles Howes <[EMAIL PROTECTED]>
+ *
+ *  Based on advantechwdt.c which is based on acquirewdt.c which
+ *   is based on wdt.c.
+ *
+ * (c) Copyright 2000-2001 Marek Michalkiewicz <[EMAIL PROTECTED]>
+ *
+ * Based on acquirewdt.c which is based on wdt.c.
+ * Original copyright messages:
+ *
+ * (c) Copyright 1996 Alan Cox <[EMAIL PROTECTED]>, All Rights Reserved.
+ * http://www.redhat.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Neither Alan Cox nor CymruNet Ltd. admit liability nor provide
+ * warranty for any of this software. This material is provided
+ * "AS-IS" and at no charge.
+ *
+ * (c) Copyright 1995Alan Cox <[EMAIL PROTECTED]>
+ *
+ *  14-Dec-2001 Matt Domsch <[EMAIL PROTECTED]>
+ *   Added nowayout module option to override CONFIG_WATCHDOG_NOWAYOUT
+ *   Added timeout module option to override default
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+static unsigned long sbc8360_is_open;
+static spinlock_t sbc8360_lock;
+static char expect_close;
+
+#define PFX "sbc8360: "
+
+/*
+ *
+ * Watchdog Timer Configuration
+ *
+ * The function of the watchdog timer is to reset the system automatically
+ * and is defined at I/O port 0120H and 0121H.  To enable the watchdog timer
+ * and allow the system to reset, write appropriate values from the table
+ * below to I/O port 0120H and 0121H.  To disable the timer, write a zero
+ * value to I/O port 0121H for the system to stop the watchdog function.
+ *
+ * The following describes how the timer should be 

Re: [PATCH 2.6] I2C: Drop I2C_DEVNAME and i2c_clientname

[Jean Delvare]

Hi Mauro,

> (...) it would be nice not to have a different I2C
> API for every single 2.6 version :-) It would be nice to change I2C
> API once and keep it stable for a while.

As nice as you seem to think it would be, I don't think it's not
realistic. For one thing, we don't necessarily know in advance what
changes will be needed. One month ago, I didn't even know that
I2C_DEVNAME and i2c_clientname were existing. For another, changes take
time to be dicussed, implemented and tested. Some changes depend on
others. We just can't buffer everything for a year and push everything
to Linus at once. Some of the changes, such as the i2c-isa killing or
the asynchronous i2c interface, are things some people really need, and
we can't ask them to wait for months or years.

The Linux 2.6 development model is designed around a relatively fast
move from -mm to Linus' tree, which implies incremental changes all the
time. I'm only doing that.

> > As time goes, the differences bwteen 2.4 and 2.6
> > will only increase. You seem to be trying to keep common driver code
> > across incompatible trees. I'm not surprised that it is a lot of
> > work. That's your choice, live with it.
>
> It is not just a matter of choice.

To me, it seems to be. No other part of the kernel does it as far as I
know. Or can you point me to other drivers that are part of the Linux
2.6 tree and include compatibility code for Linux 2.4? I am even
surprised that you are allowed to do it.

> (...) V4L stuff is mostly used by end
> users. There are a few professional users, like those working on CATV
> and video broadcasting. They don't have much knowledge and generally
> uses distro-provided kernels. It is not like I2C or PCI that most
> boards has something inside.
> Also: boards are country-specific. There are dozens of different analog
> standards. So, the same brand name (even the same model on some cases)
> have different tuners for different video standards.

I don't know what you are trying to demonstrate here, but all this is
completely unrelated with the decision of maintaining common driver code
rather than separate driver code. V4L is not different from other areas.
See how hard the framebuffer folks are struggling with the high number
of different graphics adapter setups for example. Same goes for SMBus
and hardware monitoring chips as far as I am concerned. Every mainboard
is different to some extent. And the list certainly doesn't stop there.
The difficulty to test the code on every existing piece of hardware
affects all driver authors and maintainers.

> For us to have people to test all variations, we need to provide
> backward support. Otherwise, we'll suffer a lot to test our patches,
> since nobody on V4L devel is currently payed for doing his job and
> don't have a lab with a bunch of cards and models.

Again, this ain't related with your decision to maintain a single set of
drivers for Linux 2.4 and Linux 2.6 rather than having different
drivers.

An example I know well is the lm_sensors project. As you may now, no
SMBus nor hardware monitoring driver is part of Linux 2.4. We are
maintaining drivers in a separate CVS repository. They are different
code from what we have in Linux 2.6. Still, we port the relevant changes
from one set of drivers to the other. Frankly, this ain't that
difficult, and works fine for over two years now. Maybe you should try.

I don't want to frighten you or anything, but there are changes to the
i2c subsystem which will affect compatibility in -mm, and these will hit
Linus' tree quite soon now. And I heard there are much much more in the
works, not even by me, that might go in 2.6.15.

> I have a question for you about I2C: why i2c_driver doesn't have a
> generic pointer to keep priv data (like i2c_adapter) ? 

It wouldn't make sense in the current i2c driver model (which is
probably broken, no need to argue.) i2c_driver holds the code (or
pointers to code) that is common to all chips using this driver. That
is, mostly administrative stuff. The instance-specific structure is
i2c_client. The common practice is to encapsulate the i2c_client
structure into a dedicated structure, and put all your private data in
this structure. See how this is done in drivers/hwmon/*.c.

Maybe it sounds strange to you because (I heard) the i2c subsystem
doesn't follow the usual driver model. But rest assured, I also heard
that some people wanted to fix that soon. I guess you (or others) can't
complain that the i2c subsystem is broken, and at the same time ask that
it be kept compatible with its current or even previous state.

> It would be nice to have such pointer (like have on other I2C
> structures), in order to support multiple tuners for each function.
> This is required for modern boards that have a TV analog tuner, a
> digital one and a radio chip, it would be nice to have such structure
> to keep a tuner table on it, and make easier to detect this.

I am most certainly wrong, but it looks to me like you are 

Re: [PATCH] crypto_free_tfm callers do not need to check for NULL

[Sridhar Samudrala]

On Tue, 2005-08-30 at 22:45 +0200, Jesper Juhl wrote:
> Since the patch to add a NULL short-circuit to crypto_free_tfm() went in, 
> there's no longer any need for callers of that function to check for NULL.
> This patch removes the redundant NULL checks and also a few similar checks
> for NULL before calls to kfree() that I ran into while doing the 
> crypto_free_tfm bits.
> 
> I've posted similar patches in the past, but was asked to first until the
> short-circuit patch moved from -mm to mainline - and since it is now 
> firmly there in 2.6.13 I assume there's no problem there anymore.
> I was also asked previously to make the patch against mainline and not -mm,
> so this patch is against 2.6.13.
> 
> Feedback, ACK, NACK, etc welcome. 

sctp change looks fine.
A similar check in sctp_endpoint_destroy() can also be removed.

Thanks
Sridhar

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

Re: Very strange Marvell/Yukon Gigabit NIC networking problems

[Stephen Hemminger]

You have a version of the Marvell Yukon that was affected
by a fix in 2.6.13.
skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9

Both the skge and sk98lin driver were fixed to check for this.
Without the fix, the chip will be in the wrong power mode.

The version of sk98lin driver from SysKonnect already had the
fix, so if your distro used that one, it would have the reset
the power mode as needed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ip_queue.c and TCP resets

[Michael Rash]

Attached is a patch against
linux-2.6.11.12/net/ipv4/netfilter/ip_queue.c to put Ethernet MAC
addresses directly into the indev_name and outdev_name portions of the
ipq_packet_msg struct.  This is a total kludge and I doubt anyone else
will find this useful, but for libipq IPS applications it allows TCP
resets and other response traffic to be sent out of the appropriate
physical ports when running as an Ethernet bridge.  I'm sure there are
better ways to do this, but it seems to work.

-- 
Michael Rash
Security Research Engineer
Enterasys Networks, Inc.
--- net/ipv4/netfilter/ip_queue.c	2005-05-27 01:06:46.0 -0400
+++ net/ipv4/netfilter/ip_queue.c.new	2005-06-13 12:19:17.495865712 -0400
@@ -33,7 +33,7 @@
 #include 
 #include 
 
-#define IPQ_QMAX_DEFAULT 1024
+#define IPQ_QMAX_DEFAULT 2048
 #define IPQ_PROC_FS_NAME "ip_queue"
 #define NET_IPQ_QMAX 2088
 #define NET_IPQ_QMAX_NAME "ip_queue_maxlen"
@@ -195,6 +195,8 @@
 	struct sk_buff *skb;
 	struct ipq_packet_msg *pmsg;
 	struct nlmsghdr *nlh;
+	struct ethhdr *eth;
+	unsigned short int eth_ctr, eth_dev_offset, intf_ctr, intf_dev_offset;
 
 	read_lock_bh(_lock);
 	
@@ -238,7 +240,7 @@
 	pmsg->mark= entry->skb->nfmark;
 	pmsg->hook= entry->info->hook;
 	pmsg->hw_protocol = entry->skb->protocol;
-	
+#if 0
 	if (entry->info->indev)
 		strcpy(pmsg->indev_name, entry->info->indev->name);
 	else
@@ -248,15 +250,105 @@
 		strcpy(pmsg->outdev_name, entry->info->outdev->name);
 	else
 		pmsg->outdev_name[0] = '\0';
+#endif
 	
 	if (entry->info->indev && entry->skb->dev) {
 		pmsg->hw_type = entry->skb->dev->type;
+#if 0
 		if (entry->skb->dev->hard_header_parse)
 			pmsg->hw_addrlen =
 entry->skb->dev->hard_header_parse(entry->skb,
    pmsg->hw_addr);
+#endif
 	}
-	
+
+	/* get the ethernet header */
+	eth = eth_hdr(entry->skb);
+
+	eth_dev_offset = 0;
+
+	/* NOTE: we copy the source and destination MAC addresses into the
+	 * indev_name portion of the ipq message struct, and we copy the
+	 * physical interface names in the outdev_name portion of the same
+	 * struct.  Yes, this is a major kludge! */
+
+	/* copy the source MAC address into indev_name (starting
+	 * at indev_name[0]) */
+	for (eth_ctr=0; eth_ctr < ETH_ALEN; eth_ctr++) {
+		/* deal with signed vs. unsigned char definition of indev_name
+		 * vs. h_source */
+		if (eth->h_source[eth_ctr] > 128)
+			pmsg->indev_name[eth_dev_offset] = eth->h_source[eth_ctr] - 255;
+		else
+			pmsg->indev_name[eth_dev_offset] = eth->h_source[eth_ctr];
+		eth_dev_offset++;
+	}
+
+	/* copy the destination MAC address into indev_name (starting
+	 * at indev_name[6]) */
+	for (eth_ctr=0; eth_ctr < ETH_ALEN; eth_ctr++) {
+		/* deal with signed vs. unsigned char definition of indev_name
+		 * vs. h_dest */
+		if (eth->h_dest[eth_ctr] > 128)
+			pmsg->indev_name[eth_dev_offset] = eth->h_dest[eth_ctr] - 255;
+		else
+			pmsg->indev_name[eth_dev_offset] = eth->h_dest[eth_ctr];
+		eth_dev_offset++;
+	}
+
+	/* copy the physical input device */
+	intf_dev_offset = 0;
+	for (intf_ctr=0; intf_ctr < IFNAMSIZ/2; intf_ctr++) {
+		pmsg->outdev_name[intf_dev_offset] =
+			entry->skb->nf_bridge->physindev->name[intf_ctr];
+		intf_dev_offset++;
+	}
+
+	/* copy the physical output device */
+	for (intf_ctr=0; intf_ctr < IFNAMSIZ/2; intf_ctr++) {
+		pmsg->outdev_name[intf_dev_offset] =
+			entry->skb->nf_bridge->physoutdev->name[intf_ctr];
+		intf_dev_offset++;
+	}
+
+	/*
+	 *
+	printk(KERN_INFO "source MAC: %x%x%x%x%x%x\n",
+			eth->h_source[0],
+			eth->h_source[1],
+			eth->h_source[2],
+			eth->h_source[3],
+			eth->h_source[4],
+			eth->h_source[5]);
+
+	printk(KERN_INFO "dest MAC: %x%x%x%x%x%x\n",
+			eth->h_dest[0],
+			eth->h_dest[1],
+			eth->h_dest[2],
+			eth->h_dest[3],
+			eth->h_dest[4],
+			eth->h_dest[5]);
+	*/
+
+	/*
+			entry->skb->mac.ethernet.h_dest[3],
+			entry->skb->mac.ethernet.h_dest[4],
+			entry->skb->mac.ethernet.h_dest[5]);
+	*/
+
+	/*
+	printk(KERN_INFO "physindev: %c%c%c%c\n",
+			entry->skb->nf_bridge->physindev->name[0],
+			entry->skb->nf_bridge->physindev->name[1],
+			entry->skb->nf_bridge->physindev->name[2],
+			entry->skb->nf_bridge->physindev->name[3]);
+	printk(KERN_INFO "physoutdev: %c%c%c%c\n",
+			entry->skb->nf_bridge->physoutdev->name[0],
+			entry->skb->nf_bridge->physoutdev->name[1],
+			entry->skb->nf_bridge->physoutdev->name[2],
+			entry->skb->nf_bridge->physoutdev->name[3]);
+	*/
+
 	if (data_len)
 		if (skb_copy_bits(entry->skb, 0, pmsg->payload, data_len))
 			BUG();

GDT initialization and location question.

[Pritesh Shah]

Hi,
I was wondering as to where is the GDT initialized during the boot
sequence? I will need the filename and the name of the routine that
does this. Any help would be greatly appreciated.
Thanks in advance,
Pritesh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jeff Garzik]

Brett Russ wrote:

This is the first public release of 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.


Even though its only PIO, if you feel this is stable, I would like to 
get it into upstream soon-ish.


Current version looks OK to me.

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/