Re: [PATCH] aoe: add documentation for udev users

2005-01-31 Thread Greg KH
On Wed, Jan 19, 2005 at 04:10:35PM -0500, Ed L Cashin wrote:
> Hi.  This patch was generated against block-2.6 but should apply
> easily in other trees, since it touches only documentation.
> 
> 
> add documentation for udev users
> 
> Signed-off-by: Ed L. Cashin <[EMAIL PROTECTED]>

Applied, thanks.

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


Re: [PATCH block-2.6] aoe status.sh: handle sysfs not in /etc/mtab

2005-01-31 Thread Greg KH
On Wed, Jan 26, 2005 at 04:02:02PM -0500, Ed L Cashin wrote:
> Suse 9.1 Pro doesn't put /sys in /etc/mtab.  This patch makes the
> example aoe status.sh script work when sysfs is mounted but `mount`
> doesn't mention sysfs.
> 
> 
> aoe status.sh: handle sysfs not in /etc/mtab
> Signed-off-by: Ed L. Cashin <[EMAIL PROTECTED]>

Applied, thanks.

greg k-h

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


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

2005-01-31 Thread Greg KH
On Fri, Jan 28, 2005 at 08:35:46AM -0600, Brian King wrote:
> +#define PCI_USER_READ_CONFIG(size,type)  \
> +int pci_user_read_config_##size  \
> + (struct pci_dev *dev, int pos, type *val)   \
> +{\
> + unsigned long flags;\
> + int ret = 0;\
> + u32 data = -1;  \
> + if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER;   \
> + spin_lock_irqsave(_lock, flags);\
> + if (likely(!dev->block_ucfg_access))\
> + ret = dev->bus->ops->read(dev->bus, dev->devfn, pos, 
> sizeof(type), ); \
> + else if (pos < sizeof(dev->saved_config_space)) \
> + data = 
> dev->saved_config_space[pos/sizeof(dev->saved_config_space[0])]; \
> + spin_unlock_irqrestore(_lock, flags);   \
> + *val = (type)data;  \
> + return ret; \
> +}
> +
> +#define PCI_USER_WRITE_CONFIG(size,type) \
> +int pci_user_write_config_##size \
> + (struct pci_dev *dev, int pos, type val)\
> +{\
> + unsigned long flags;\
> + int ret = 0;\
> + if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER;   \
> + spin_lock_irqsave(_lock, flags);\
> + if (likely(!dev->block_ucfg_access))
> \
> + ret = dev->bus->ops->write(dev->bus, dev->devfn, pos, 
> sizeof(type), val); \
> + spin_unlock_irqrestore(_lock, flags);   \
> + return ret; \
> +}
> +
> +PCI_USER_READ_CONFIG(byte, u8)
> +PCI_USER_READ_CONFIG(word, u16)
> +PCI_USER_READ_CONFIG(dword, u32)
> +PCI_USER_WRITE_CONFIG(byte, u8)
> +PCI_USER_WRITE_CONFIG(word, u16)
> +PCI_USER_WRITE_CONFIG(dword, u32)

Global but not exported?  If so, they are local to the pci core, right?
And if so, please put them in the drivers/pci/pci.h file and not the
include/linux/pci.h file.


> +/**
> + * pci_block_user_cfg_access - Block userspace PCI config reads/writes
> + * @dev: pci device struct
> + *
> + * This function blocks any userspace PCI config accesses from occurring.
> + * When blocked, any writes will return -EBUSY and reads will return the
> + * data saved using pci_save_state for the first 64 bytes of config
> + * space and return -EBUSY for all other config reads.
> + *
> + * Return value:
> + *   nothing

We know the return value is not needed by the way the function is
defined, these two lines are unneeded.

> +void pci_block_user_cfg_access(struct pci_dev *dev)
> +{
> + unsigned long flags;
> +
> + pci_save_state(dev);
> + spin_lock_irqsave(_lock, flags);
> + dev->block_ucfg_access = 1;
> + spin_unlock_irqrestore(_lock, flags);
> +}
> +EXPORT_SYMBOL(pci_block_user_cfg_access);

EXPORT_SYMBOL_GPL() please?

> +/**
> + * pci_unblock_user_cfg_access - Unblock userspace PCI config reads/writes
> + * @dev: pci device struct
> + *
> + * This function allows userspace PCI config accesses to resume.
> + *
> + * Return value:
> + *   nothing

Same here as above.

> +void pci_unblock_user_cfg_access(struct pci_dev *dev)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(_lock, flags);
> + dev->block_ucfg_access = 0;
> + spin_unlock_irqrestore(_lock, flags);
> +}
> +EXPORT_SYMBOL(pci_unblock_user_cfg_access);

Same as above.

> @@ -896,6 +904,8 @@ extern void pci_disable_msix(struct pci_
>  extern void msi_remove_pci_irq_vectors(struct pci_dev *dev);
>  #endif
>  
> +extern void pci_block_user_cfg_access(struct pci_dev *dev);
> +extern void pci_unblock_user_cfg_access(struct pci_dev *dev);
>  #endif /* CONFIG_PCI */

Don't need empty functions for these if CONFIG_PCI is not enabled?  Who
would be calling these functions, drivers?  If so, please create the
empty functions.

Also, please CC the linux-pci mailing list for pci specific patches like
this.

thanks,

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


Re: Fwd: Patch to control VGA bus routing and active VGA device.

2005-01-31 Thread Greg KH
On Thu, Jan 27, 2005 at 04:59:45AM -0500, Jon Smirl wrote:
> On Mon, 24 Jan 2005 20:24:59 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > This can be done today in the bus specific match functions.  And because
> > of that, I would argue that this belongs in the bus specific code, and
> > not in the driver core, as it's up to the bus to know what the different
> > types of "matches" that can happen, and what the priority is.
> 
> Here's a version of the VGA control code that actually works. It helps
> if I pci_enable() the device before using it. There was nothing wrong
> with the routing code.
> 
> I can also control multiple cards on the same bus by turning on/off
> their response to IO space and then enabling VGA via the standard
> ports. I can use this to move my console from card to card.
> 
> I have this code in drivers/pci because it needs to know add/remove
> from hotplug. Is there a better way to structure it? Note that this is
> not a VGA device, it is just a mechanism for controlling which VGA
> device is active.
> 
> Another item I need to add is generating an initial hotplug event for
> each secondary card. This event has to happen even if there is a card
> specific driver loaded. The event will be used to run the reset
> program needed by secondary cards.

Ick, patch wasn't inline for me to comment on it :(

Anyway, get rid of the ifdefs in the kernel .c code to start with.

thanks,

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


Re: [PATCH] PCI: add PCI Express Port Bus Driver subsystem

2005-01-31 Thread Greg KH
On Mon, Jan 24, 2005 at 12:10:25PM -0800, long wrote:
> On Tuesday, January 18, 2005 5:03 PM Greg KH wrote:
> >> >
> >> >That would be great, but it doesn't show up that way on my box.  All
> >> >of
> >> >the portX devices are in /sys/devices/ which is what I don't think
> >> >you
> >> >want.  I would love for them to have the parent of the pci_dev
> >> >structure
> >> >:)
> >> 
> >> Agree. Thanks for your inputs. The patch below include the changes
> >> based on your previous post.
> >
> >Hm, that seems like a pretty big patch just to add a pointer to a parent
> >device :)
> >
> >What really does this patch do?  What does the sysfs tree now look like?
> 
> Before changes:
> 
> The patch makes the parent of the device pointing to the pci_dev
> structure. The parents portX devices are in /sys/devices which
> should be removed based on your suggestions. Below is /sys/devices
> before any changes made.
> 
> /sys/devices
>   |
>   __ ide0 
>   |
>   __ pci:00
>   |
>   __ pnp0
>   |
>   __ port1
>   |   |
>   |   __ port1.00
>   |   |
>   |   __ port1.01
>   |   .
>   |   .
>   |   .
>   |
>   __ port2
>   |
>   __ port3
>   |
>   __ system
> 
> After changes:
> 
> The parents portX devices are no longer necessary because port1.00
> and port1.01 devices shoud have the parent of the pci_dev structure
> (based on your suggestion). The patch does the following changes:
> 
> - remove code creating and handling the parent portX devices.
> - rename portX.YZ to pcieYZ (for example port1.00 renamed to pcie00)
>   since portX is no longer needed.
> - make pcieYZ have the parent of the pci_dev structure.
> 
> Below is /sys/devices after changes made to the patch.
> 
> /sys/devices
>   |
>   __ ide0 
>   |
>   __ pci:00
>   |   |
>   |   __ :00:00.0
>   |   |
>   |   __ :00:04.0
>   |   |   |
>   |   .   __ class
>   |   .   |
>   |   .   __ pcie00
>   |   |
>   |   __ pcie01
>   |   .
>   |   .   
>   |   .
>   |
>   __ platform
>   |
>   __ pnp0
>   |
>   __ system
> 
> 
> Please let me know what you think of the changes.

Ok, that makes more sense now.  I've applied your patch, thanks.

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


Re: pci: Arch hook to determine config space size

2005-01-31 Thread Grant Grundler
On Mon, Jan 31, 2005 at 01:40:04PM -0600, Brian King wrote:
> CC'ing the linux-pci mailing list...

thanks...

> > This patch adds an arch hook so
> > that individual archs can indicate if the underlying system supports
> > expanded config space accesses or not.

> >@@ -653,6 +653,8 @@ static int pci_cfg_space_size(struct pci
> > goto fail;
> > }
> > 
> >+if (!pcibios_exp_cfg_space(dev))
> >+goto fail;
> > if (pci_read_config_dword(dev, 256, ) != PCIBIOS_SUCCESSFUL)
> > goto fail;

pci_read_config_dword lands in arch specific code.
See drivers/pci/access.c:PCI_OP_READ() macro.

I'm missing what pcibios_exp_cfg_space() does that can't be handled by
the bus_ops supplied by pci_scan_bus().

I would expect the pci_read_config_dword to fail for being out of bounds.
Is that wrong?
Or is bus_ops not feasible in this case because pcibios needs access
to pci_dev?

If it's feasible, maybe the right place to add this hook is to
pci_read_config_dword which is also handed the pci_dev. And add
another function pointer to bus_ops (which could be NULL) to check
chipset support for Expanded Config space before calling
pci_bus_read_config_dword. Thats cleaner than adding a hook
before each use of pci_read_config_dword.

hth,
grant


Re: Patch to add usbmon

2005-01-31 Thread Greg KH
On Mon, Jan 31, 2005 at 09:29:03PM -0800, Pete Zaitcev wrote:
> This patch adds so-called "usbmon", or USB monitoring framework, similar
> to what tcpdump provides for Ethernet. This is an initial version, but
> it should be safe and useful. It adds an overhead of an if () statement
> into submission and giveback paths even when not monitoring, but this
> was deemed a lesser evil than stealth manipulation of function pointers.

Few minor comments on the code:

First off, why make usbmon a module?  You aren't allowing it to happen,
so just take out the parts of the patch that allow it.

>  
>  /* host controllers we manage */
>  LIST_HEAD (usb_bus_list);
> +EXPORT_SYMBOL_GPL (usb_bus_list);

Not needed if not a module.

>  /* used when allocating bus numbers */
>  #define USB_MAXBUS   64
> @@ -96,6 +97,7 @@ static struct usb_busmap busmap;
>  
>  /* used when updating list of hcds */
>  DECLARE_MUTEX (usb_bus_list_lock);   /* exported only for usbfs */
> +EXPORT_SYMBOL_GPL (usb_bus_list_lock);

Not needed if not a module.

>  
>  /* used when updating hcd data */
>  static DEFINE_SPINLOCK(hcd_data_lock);
> @@ -103,6 +105,10 @@ static DEFINE_SPINLOCK(hcd_data_lock);
>  /* wait queue for synchronous unlinks */
>  DECLARE_WAIT_QUEUE_HEAD(usb_kill_urb_queue);
>  
> +#if defined(CONFIG_USB_MON) || defined(CONFIG_USB_MON_MODULE)
> +struct usb_mon_operations *mon_ops;
> +#endif /* CONFIG_USB_MON */

Not needed at all, as you create it down below.  Ah, the .h files, no
wait, you refer to it there too, so removing it here should be fine.

> @@ -1103,8 +1110,6 @@ static int hcd_submit_urb (struct urb *u
>* valid and usb_buffer_{sync,unmap}() not be needed, since
>* they could clobber root hub response data.
>*/
> - urb->transfer_flags |= (URB_NO_TRANSFER_DMA_MAP
> - | URB_NO_SETUP_DMA_MAP);
>   status = rh_urb_enqueue (hcd, urb);
>   goto done;
>   }

Why remove that statment?  What does that have to do with usbmon?

>  void usb_hcd_giveback_urb (struct usb_hcd *hcd, struct urb *urb, struct 
> pt_regs *regs)
>  {
> - urb_unlink (urb);
> + int at_root_hub;
>  
> - // NOTE:  a generic device/urb monitoring hook would go here.
> - // hcd_monitor_hook(MONITOR_URB_FINISH, urb, dev)
> - // It would catch exit/unlink paths for all urbs.
> + at_root_hub = (urb->dev == hcd->self.root_hub);
> + urb_unlink (urb);
>  
>   /* lower level hcd code should use *_dma exclusively */
> - if (hcd->self.controller->dma_mask) {
> + if (hcd->self.controller->dma_mask && !at_root_hub) {
>   if (usb_pipecontrol (urb->pipe)
>   && !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP))
>   dma_unmap_single (hcd->self.controller, urb->setup_dma,

You change the logic here a bit too.  Why?


> diff -urpN -X dontdiff linux-2.6.11-rc2/drivers/usb/core/hcd.h 
> linux-2.6.11-rc2-lem/drivers/usb/core/hcd.h
> --- linux-2.6.11-rc2/drivers/usb/core/hcd.h   2005-01-22 14:54:24.0 
> -0800
> +++ linux-2.6.11-rc2-lem/drivers/usb/core/hcd.h   2005-01-23 
> 17:19:43.0 -0800
> @@ -411,6 +411,63 @@ static inline void usbfs_cleanup(void) {
>  
>  /*-*/
>  
> +#if defined(CONFIG_USB_MON) || defined(CONFIG_USB_MON_MODULE)
> +
> +struct usb_mon_operations {
> + void (*urb_submit)(struct usb_bus *bus, struct urb *urb);
> + void (*urb_submit_error)(struct usb_bus *bus, struct urb *urb, int err);
> + void (*urb_complete)(struct usb_bus *bus, struct urb *urb);
> + /* void (*urb_unlink)(struct usb_bus *bus, struct urb *urb); */
> + void (*bus_add)(struct usb_bus *bus);
> + void (*bus_remove)(struct usb_bus *bus);
> +};
> +
> +extern struct usb_mon_operations *mon_ops;
> +
> +#define usbmon_urb_submit(bus, urb)  \

Can you make these inlines?  That makes the code nicer as we get
typechecking and everything :)

> +#else
> +
> +#define usbmon_urb_submit(bus, urb)  /* */
> +#define usbmon_urb_submit(bus, urb, error)   /* */
> +#define usbmon_urb_complete(bus, urb)/* */
> +#define usbmon_notify_bus_add(bus)   /* */
> +#define usbmon_notify_bus_remove(bus)/* */

static inlines for these too if you can.

thanks,

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


Re: [PATCH 2/3] buffer writes to sysfs

2005-01-31 Thread Greg KH
On Tue, Jan 25, 2005 at 03:39:00PM -0800, Mitch Williams wrote:
> 
> 
> On Mon, 24 Jan 2005, Greg KH wrote:
> >
> > Who is trying to send > 1K to a sysfs file?  Remember, sysfs files are
> > for 1 value only.  If you consider > 1K a "single value" please point me
> > to that part of the kernel that does that.
> >
> > > To the typical user, there's really no difference in behavior, unless
> > you
> > > are writing a ton of data into the file.  Of course, there's the
> > obvious
> > > question of why you'd want to do so...
> >
> > Exactly, you should not be doing that anyway.  So, because of that, I
> > really don't want/like this patch.
> 
> 
> OK, I've had a day to think about this, and I think I have a good answer
> now.
> 
> Leaving aside the issue of how big a 'single object' is, we still have to
> consider the possibility that a user _will_ indeed someday try to write 4K
> (or more) to a sysfs file.  It's just going to happen.  And right now, the
> kernel's behavior in that event is unpredictable, because we don't know
> how the c library is going to buffer this write.

That's your C library, probably not mine :)

Anyway, sure, I can see that we want to handle this in a sane manner.

> diff -urpN -X dontdiff linux-2.6.11-clean/fs/sysfs/file.c 
> linux-2.6.11/fs/sysfs/file.c
> --- linux-2.6.11-clean/fs/sysfs/file.c2004-12-24 13:33:50.0 
> -0800
> +++ linux-2.6.11/fs/sysfs/file.c  2005-01-25 10:47:15.0 -0800
> @@ -232,6 +232,8 @@ sysfs_write_file(struct file *file, cons
>  {
>   struct sysfs_buffer * buffer = file->private_data;
> 
> +if (*ppos > 0)
> +return -EIO;
>   down(>sem);
>   count = fill_write_buffer(buffer,buf,count);
>   if (count > 0)

You are using spaces instead of tabs :(

Care to redo it?

thanks,

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


Re: I2C algorithm IDs

2005-01-31 Thread Greg KH
On Sat, Jan 22, 2005 at 05:47:18PM +, Russell King wrote:
> Greg,
> 
> Are I2C algorithm IDs supposed to be unique?  Do they have any meaning in
> reality at all?  If the answer is yes to either of these questions, the
> following should probably be resolved:

Yes, they are used in some places, and yes they do need to be unique.

> #define I2C_ALGO_PCA0x15/* PCA 9564 style adapters  */
> #define I2C_ALGO_SIBYTE 0x15/* Broadcom SiByte SOCs */

Thanks for pointing this out, I've gone and fixed this up and will send
the patch upward.

thanks,

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


Re: question on symbol exports

2005-01-31 Thread Arjan van de Ven
On Mon, 2005-01-31 at 18:15 -0600, Chris Friesen wrote:
> It appears that in 2.6.9 the ppc64 version of flush_tlb_page() depends 
> on two symbols which are not currently exported: the function 
> __flush_tlb_pending(), and the per-cpu variable ppc64_tlb_batch.
> 
> Is there any particular reason why modules should not be allowed to 
> flush the tlb, or is this an oversight?

can you point at the url to your module source? I suspect modules doing
tlb flushes is the wrong thing, but without seeing the source it's hard
to tell.


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


[PATCH] 2.6.11-rc2-mm2 can't insmod modules correctly!

2005-01-31 Thread Zhonglin Zhang
Hi,

When I update to the 2.6.11-rc2-mm2, I couldn't insmod any module
successfully.

And I traced the module insert procedure. I got the stop_machine_run()
is defined as do-nothing function when CONFIG_STOP_MACHINE is undefined.
So __link_module can't be called at all.


My little patch is below:


--- kernel/module.c.original2005-01-31 16:44:37.0 +0800
+++ kernel/module.c 2005-02-01 15:01:49.0 +0800
@@ -1761,7 +1761,7 @@ static struct module *load_module(void _
  * link the module with the whole machine is stopped with interrupts
off
  * - this defends against kallsyms not taking locks
  */
-static int __link_module(void *_mod)
+static inline int __link_module(void *_mod)
{
struct module *mod = _mod;
list_add(>list, );
@@ -1802,7 +1802,9 @@ sys_init_module(void __user *umod,

/* Now sew it into the lists.  They won't access us, since
strong_try_module_get() will fail. */
-   stop_machine_run(__link_module, mod, NR_CPUS);
+   spin_lock_irq(_lock);
+   __link_module(mod);
+   spin_unlock_irq(_lock);

-- 
Zhonglin Zhang <[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: [RFC] shared subtrees

2005-01-31 Thread Mike Waychison
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ram wrote:
> On Fri, 2005-01-28 at 14:31, Mike Waychison wrote:
> 
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA1
>>
>>Al Viro wrote:
>>
>>
>>>OK, here comes the first draft of proposed semantics for subtree
>>>sharing.  What we want is being able to propagate events between
>>>the parts of mount trees.  Below is a description of what I think
>>>might be a workable semantics; it does *NOT* describe the data
>>>structures I would consider final and there are considerable
>>>areas where we still need to figure out the right behaviour.
>>>
>>
>>Okay, I'm not convinced that shared subtrees as proposed will work well
>>with autofs.
>>
>>The idea discussed off-line was this:
>>
>>When you install an autofs mountpoint, on say /home, a daemon is started
>>to service the requests.  As far as the admin is concerned, an fs is
>>mounted in the current namespace, call it namespaceA.  The daemon
>>actually runs in it's one private namespace: call it namespaceB.
>>namespaceB receives a new autofs filesystem: call it autofsB.  autofsB
>>is in it's own p-node.  namespaceA gets an autofsA on /home as well, and
>>autofsA is 'owned' by autofsB's p-node.
> 
> 
> Mike, multiple parsing through the problem definition, still did not
> make the problem clear. What problem is autofs trying to solve using
> namespaces?
> 
> My guess is you dont want to see a automount taking place in namespaceA,
> when a automount takes place in namespaceB, even though
> the automount-point is in a shared subtree?
> 
> Sorry don't understand automount's requirement in the first place,
> RP

The major concern for automounting is that currently, if you start an
automount daemon in the primary namespace, and some process clones off
into a new namespace with clone(CLONE_NS), then there is no way for the
daemon running in the first namespace to automount (let alone expire)
any mounts in the second namespace.  There doesn't exist a way for the
daemon to mount(2) nor umount(2) across namespaces.

The proposed solution for this is to use shared and private subtrees to
have the daemon run in it's own namespace, with the primary and any
derivative namespaces inheriting the automounts.  I'm not convinced that
it'd work though.

Does this clarify?

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice

~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB/ymFdQs4kOxk3/MRAjuWAKCJfX+jZMUlm9ncM199Q0nJpxwPKQCgjQFE
VTNmwXtmKOLVlrqBd2AzfYk=
=tESv
-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] ppc64: Implement a vDSO and use it for signal trampoline

2005-01-31 Thread Benjamin Herrenschmidt

> Right hand side is evaluated only when left hand side is used.
> Also very usefull. Example just mocked up:
> cmd_vdso32_cc = $(CC) -T $^ -o $@
> 
> Doing late evaluation will cause correct replacement of $^ and $@ when
> used. When cmd_vdso_32 is defined make does not know the desired values
> for $^ and $@ - this is only known when cmd_vdso_32 is actually used.
> 
> Hope this clarifies it.

Definitely, thanks.

Ben.


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


possible performance issue in 4-level page tables

2005-01-31 Thread Zou Nan hai

There is a performance regression of lmbench
lat_proc fork result on ia64.

in 
2.6.10 

I got 
Process fork+exit:164.8438 microseconds.

in 2.6.11-rc2
Process fork+exit:183.8621 microseconds.

I believe this regression was caused by 
the 4-level page tables change.

Since most of the kernel time spend in lat_proc fork is copy_page_range
in fork path and clear_page_range in the exit path. Now they are 1 level
deeper.

Though pud and pgd is same on IA64, there is still some overhead
introduced I think.
 
Are any other architectures seeing the same sort of results?

Zou Nan hai

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


kernel crash using XFS over raid5 partition

2005-01-31 Thread Giuseppe Sacco
Hi all,
I am facing a kernel bug[1] that completely crashes my machines. During
the last days I tried to fine tune the problem and I am now inclined for
a bug in libata/sata_sil or device mapper code.

I activated the DEBUG messages in raid5 source module, but I cannot find
a way to do the same with libata. Is there any #define I may use?

Thanks,
Giuseppe

[1]http://bugme.osdl.org/show_bug.cgi?id=3968

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] ppc64: Implement a vDSO and use it for signal trampoline #2

2005-01-31 Thread Sam Ravnborg
On Tue, Feb 01, 2005 at 12:49:44PM +1100, Benjamin Herrenschmidt wrote:
  core-y+= arch/ppc64/kernel/
> +core-y   += arch/ppc64/kernel/vdso32/
> +core-y   += arch/ppc64/kernel/vdso64/

Please include your previous change to reflect this in
arch/ppc64/kernel/Makefile
It is much more obvious to look up this in the Makefile like we do for
the rest of the kernel.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] ppc64: Implement a vDSO and use it for signal trampoline

2005-01-31 Thread Sam Ravnborg
On Tue, Feb 01, 2005 at 11:38:02AM +1100, Benjamin Herrenschmidt wrote:
> 
> > Also notice that ':=' uses all over. No need to use late evaluation when
> > no dynamic references are used ($ $@ etc.).
> 
> Hrm... Rusty tells me that you got it backward ;) Anyway, I'll stick
> to := for now, it's not really an issue.

:=
Right hand side is evaluated when encountered.
Often what you want. So for example
CC := cc
here CC is assigned the value cc when seen.

=
Right hand side is evaluated only when left hand side is used.
Also very usefull. Example just mocked up:
cmd_vdso32_cc = $(CC) -T $^ -o $@

Doing late evaluation will cause correct replacement of $^ and $@ when
used. When cmd_vdso_32 is defined make does not know the desired values
for $^ and $@ - this is only known when cmd_vdso_32 is actually used.

Hope this clarifies it.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 to add usbmon

2005-01-31 Thread Pete Zaitcev
This patch adds so-called "usbmon", or USB monitoring framework, similar
to what tcpdump provides for Ethernet. This is an initial version, but
it should be safe and useful. It adds an overhead of an if () statement
into submission and giveback paths even when not monitoring, but this
was deemed a lesser evil than stealth manipulation of function pointers.

The patch makes two changes to hcd.c which make usbmon more useful:
 - Change the way we determine that DMA should not be mapped for root
   hubs, so that usbmon knows easily when it's safe to capture data.
 - Return exports of usb_bus_list and usb_bus_list_lock for those who
   wish to build usbmon as a module.

Signed-off-by: Pete Zaitcev

diff -urpN -X dontdiff linux-2.6.11-rc2/drivers/usb/core/hcd.c 
linux-2.6.11-rc2-lem/drivers/usb/core/hcd.c
--- linux-2.6.11-rc2/drivers/usb/core/hcd.c 2005-01-22 14:54:24.0 
-0800
+++ linux-2.6.11-rc2-lem/drivers/usb/core/hcd.c 2005-01-23 17:19:18.0 
-0800
@@ -86,6 +86,7 @@
 
 /* host controllers we manage */
 LIST_HEAD (usb_bus_list);
+EXPORT_SYMBOL_GPL (usb_bus_list);
 
 /* used when allocating bus numbers */
 #define USB_MAXBUS 64
@@ -96,6 +97,7 @@ static struct usb_busmap busmap;
 
 /* used when updating list of hcds */
 DECLARE_MUTEX (usb_bus_list_lock); /* exported only for usbfs */
+EXPORT_SYMBOL_GPL (usb_bus_list_lock);
 
 /* used when updating hcd data */
 static DEFINE_SPINLOCK(hcd_data_lock);
@@ -103,6 +105,10 @@ static DEFINE_SPINLOCK(hcd_data_lock);
 /* wait queue for synchronous unlinks */
 DECLARE_WAIT_QUEUE_HEAD(usb_kill_urb_queue);
 
+#if defined(CONFIG_USB_MON) || defined(CONFIG_USB_MON_MODULE)
+struct usb_mon_operations *mon_ops;
+#endif /* CONFIG_USB_MON */
+
 /*-*/
 
 /*
@@ -746,6 +752,7 @@ int usb_register_bus(struct usb_bus *bus
up (_bus_list_lock);
 
usbfs_add_bus (bus);
+   usbmon_notify_bus_add (bus);
 
dev_info (bus->controller, "new USB bus registered, assigned bus number 
%d\n", bus->busnum);
return 0;
@@ -773,6 +780,7 @@ void usb_deregister_bus (struct usb_bus 
list_del (>bus_list);
up (_bus_list_lock);
 
+   usbmon_notify_bus_remove (bus);
usbfs_remove_bus (bus);
 
clear_bit (bus->busnum, busmap.busmap);
@@ -1058,9 +1066,7 @@ static int hcd_submit_urb (struct urb *u
 * as simple as possible.
 */
 
-   // NOTE:  a generic device/urb monitoring hook would go here.
-   // hcd_monitor_hook(MONITOR_URB_SUBMIT, urb)
-   // It would catch submission paths for all urbs.
+   usbmon_urb_submit(>self, urb);
 
/*
 * Atomically queue the urb,  first to our records, then to the HCD.
@@ -1087,6 +1093,7 @@ static int hcd_submit_urb (struct urb *u
spin_unlock_irqrestore (_data_lock, flags);
if (status) {
INIT_LIST_HEAD (>urb_list);
+   usbmon_urb_submit_error(>self, urb, status);
return status;
}
 
@@ -1103,8 +1110,6 @@ static int hcd_submit_urb (struct urb *u
 * valid and usb_buffer_{sync,unmap}() not be needed, since
 * they could clobber root hub response data.
 */
-   urb->transfer_flags |= (URB_NO_TRANSFER_DMA_MAP
-   | URB_NO_SETUP_DMA_MAP);
status = rh_urb_enqueue (hcd, urb);
goto done;
}
@@ -1139,6 +1144,7 @@ done:
if (urb->reject)
wake_up (_kill_urb_queue);
usb_put_urb (urb);
+   usbmon_urb_submit_error(>self, urb, status);
}
return status;
 }
@@ -1461,14 +1467,13 @@ static struct usb_operations usb_hcd_ope
  */
 void usb_hcd_giveback_urb (struct usb_hcd *hcd, struct urb *urb, struct 
pt_regs *regs)
 {
-   urb_unlink (urb);
+   int at_root_hub;
 
-   // NOTE:  a generic device/urb monitoring hook would go here.
-   // hcd_monitor_hook(MONITOR_URB_FINISH, urb, dev)
-   // It would catch exit/unlink paths for all urbs.
+   at_root_hub = (urb->dev == hcd->self.root_hub);
+   urb_unlink (urb);
 
/* lower level hcd code should use *_dma exclusively */
-   if (hcd->self.controller->dma_mask) {
+   if (hcd->self.controller->dma_mask && !at_root_hub) {
if (usb_pipecontrol (urb->pipe)
&& !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP))
dma_unmap_single (hcd->self.controller, urb->setup_dma,
@@ -1484,6 +1489,7 @@ void usb_hcd_giveback_urb (struct usb_hc
: DMA_TO_DEVICE);
}
 
+   usbmon_urb_complete (>self, urb);
/* pass ownership to the completion handler */
urb->complete (urb, regs);
atomic_dec (>use_count);
@@ -1591,3 +1597,43 @@ void usb_put_hcd (struct usb_hcd *hcd)
usb_bus_put(>self);
 }
 

[PATCH] NFS ACL build fix, POSIX ACL config tidy

2005-01-31 Thread Matt Mackall
Apologies if I've sent this twice:

Build fix for NFS ACLs and cleanup of POSIX ACL config.

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

Index: mm2/fs/Kconfig
===
--- mm2.orig/fs/Kconfig 2005-01-30 21:26:27.0 -0800
+++ mm2/fs/Kconfig  2005-01-30 21:32:26.0 -0800
@@ -29,6 +29,7 @@
 config EXT2_FS_POSIX_ACL
bool "Ext2 POSIX Access Control Lists"
depends on EXT2_FS_XATTR
+   select FS_POSIX_ACL
help
  Posix Access Control Lists (ACLs) support permissions for users and
  groups beyond the owner/group/world scheme.
@@ -97,6 +98,7 @@
 config EXT3_FS_POSIX_ACL
bool "Ext3 POSIX Access Control Lists"
depends on EXT3_FS_XATTR
+   select FS_POSIX_ACL
help
  Posix Access Control Lists (ACLs) support permissions for users and
  groups beyond the owner/group/world scheme.
@@ -226,6 +228,7 @@
 config REISERFS_FS_POSIX_ACL
bool "ReiserFS POSIX Access Control Lists"
depends on REISERFS_FS_XATTR
+   select FS_POSIX_ACL
help
  Posix Access Control Lists (ACLs) support permissions for users and
  groups beyond the owner/group/world scheme.
@@ -259,6 +262,7 @@
 config JFS_POSIX_ACL
bool "JFS POSIX Access Control Lists"
depends on JFS_FS
+   select FS_POSIX_ACL
help
  Posix Access Control Lists (ACLs) support permissions for users and
  groups beyond the owner/group/world scheme.
@@ -303,8 +307,7 @@
 #  Never use this symbol for ifdefs.
 #
bool
-   depends on EXT2_FS_POSIX_ACL || EXT3_FS_POSIX_ACL || JFS_POSIX_ACL || 
REISERFS_FS_POSIX_ACL || NFSD_V4
-   default y
+   default n
 
 source "fs/xfs/Kconfig"
 
@@ -1426,6 +1429,7 @@
bool "NFS_ACL protocol extension"
depends on NFS_V3
select QSORT
+   select FS_POSIX_ACL
help
  Implement the NFS_ACL protocol extension for manipulating POSIX
  Access Control Lists.  The server must also implement the NFS_ACL


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


Re: Touchpad problems with 2.6.11-rc2

2005-01-31 Thread Dmitry Torokhov
On Tuesday 01 February 2005 00:06, Pete Zaitcev wrote:
> On Mon, 31 Jan 2005 22:40:35 -0500, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> 
> > > Suddenly, touchpad motions started to cause wild movements in it became
> > > impossible to do anything due to a focus loss (of course, I had plenty of
> > > modified files open :-)
> 
> > > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> > > psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> > > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> > > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> > > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> > > psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> 
> > 1. Have you tried using external PS/2 mouse?
> > 2. Have you plugged/unplugged into a port replicator?
> 
> I have Dell Latitude D600, which does not have an external PS/2 port.
> 
> But actually, I was caught away from home, working from a library, so I did
> not have either PS/2 or USB mouse. I moved the cursor persistently for a
> few minutes until I managed to raise a window in such way that it got the
> focus, then I saved all files and closed all windows from the keyboard,
> so no harm done, no problem.
> 
> The kernel was running without resetafter set, unfortunately.
> 
> If you have a patch which prints offending data from pktbuffer, I can
> run that next time.
> 

No I don't but by the looks of it (constant stream of bad data) it looks
like somehow the touhcpad was reset back into PS/2 compatibility mode.
resetafter would catch it and reinitialize touchpad restoring proper
protocol.

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


Re: Touchpad problems with 2.6.11-rc2

2005-01-31 Thread Pete Zaitcev
On Mon, 31 Jan 2005 22:40:35 -0500, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:

> > Suddenly, touchpad motions started to cause wild movements in it became
> > impossible to do anything due to a focus loss (of course, I had plenty of
> > modified files open :-)

> > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> > psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> > psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.

> 1. Have you tried using external PS/2 mouse?
> 2. Have you plugged/unplugged into a port replicator?

I have Dell Latitude D600, which does not have an external PS/2 port.

But actually, I was caught away from home, working from a library, so I did
not have either PS/2 or USB mouse. I moved the cursor persistently for a
few minutes until I managed to raise a window in such way that it got the
focus, then I saved all files and closed all windows from the keyboard,
so no harm done, no problem.

The kernel was running without resetafter set, unfortunately.

If you have a patch which prints offending data from pktbuffer, I can
run that next time.

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


Re: pci: Arch hook to determine config space size

2005-01-31 Thread Benjamin Herrenschmidt
On Mon, 2005-01-31 at 22:52 -0600, Brian King wrote:

> Assuming I am reading the spec correctly, this is only a property of the 
> PHB, so I could move it into the pci_controller struct instead.

Note that Arnd seems to imply the opposite ...

BTW. I'm thinking about moving all those PCI/VIO related fields out of
struct device_node to their own structure and keep only a pointer to
that structure in device_node. That way, we avoid the bloat for every
single non-pci node in the system, and we can have different structures
for different bus types (along with proper iommu function pointers and
that sort-of-thing).

So if you think you really need a per-device info here, feel free to
add it to device_node for now, and I'll move it to the new structure
along with the rest of the stuff once I find time to do this patch.

Ben.




Re: pci: Arch hook to determine config space size

2005-01-31 Thread Brian King
Benjamin Herrenschmidt wrote:
On Mon, 2005-01-31 at 16:43 -0600, Brian King wrote:

diff -puN include/asm-ppc64/prom.h~ppc64_pcix_mode2_cfg include/asm-ppc64/prom.h
--- linux-2.6.11-rc2-bk9/include/asm-ppc64/prom.h~ppc64_pcix_mode2_cfg  
2005-01-31 14:32:01.0 -0600
+++ linux-2.6.11-rc2-bk9-bjking1/include/asm-ppc64/prom.h   2005-01-31 
14:32:01.0 -0600
@@ -137,6 +137,7 @@ struct device_node {
int devfn;  /* for pci devices */
int eeh_mode;   /* See eeh.h for possible EEH_MODEs */
int eeh_config_addr;
+   int pci_ext_config_space;   /* for phb's or bridges */
struct  pci_controller *phb;/* for pci devices */
struct  iommu_table *iommu_table;   /* for phb's or bridges */

Grrr... more crap added to the device-node, I don't like that ...
This is a PHB only field, can't it be in struct pci_controller instead ?
Assuming I am reading the spec correctly, this is only a property of the 
PHB, so I could move it into the pci_controller struct instead.

--
Brian King
eServer Storage I/O
IBM Linux Technology Center

When working with a PCI-X Mode 2 adapter on a PCI-X Mode 1 PPC64
system, the current code used to determine the config space size
of a device results in a PCI Master abort and an EEH error, resulting
in the device being taken offline. This patch checks OF to see if
the PCI bridge supports PCI-X Mode 2 and fails config accesses beyond
256 bytes if it does not.


---

 linux-2.6.11-rc2-bk9-bjking1/arch/ppc64/kernel/pSeries_pci.c |   31 ++-
 linux-2.6.11-rc2-bk9-bjking1/include/asm-ppc64/pci-bridge.h  |1 
 2 files changed, 30 insertions(+), 2 deletions(-)

diff -puN arch/ppc64/kernel/pSeries_pci.c~ppc64_pcix_mode2_cfg 
arch/ppc64/kernel/pSeries_pci.c
--- linux-2.6.11-rc2-bk9/arch/ppc64/kernel/pSeries_pci.c~ppc64_pcix_mode2_cfg   
2005-01-31 22:27:49.0 -0600
+++ linux-2.6.11-rc2-bk9-bjking1/arch/ppc64/kernel/pSeries_pci.c
2005-01-31 22:31:04.0 -0600
@@ -52,6 +52,16 @@ static int s7a_workaround;
 
 extern struct mpic *pSeries_mpic;
 
+static int config_access_valid(struct device_node *dn, int where)
+{
+   if (where < 256)
+   return 1;
+   if (where < 4096 && dn->phb->pci_ext_config_space)
+   return 1;
+
+   return 0;
+}
+
 static int rtas_read_config(struct device_node *dn, int where, int size, u32 
*val)
 {
int returnval = -1;
@@ -62,8 +72,11 @@ static int rtas_read_config(struct devic
return PCIBIOS_DEVICE_NOT_FOUND;
if (where & (size - 1))
return PCIBIOS_BAD_REGISTER_NUMBER;
+   if (!config_access_valid(dn, where))
+   return PCIBIOS_BAD_REGISTER_NUMBER;
 
-   addr = (dn->busno << 16) | (dn->devfn << 8) | where;
+   addr = ((where & 0xf00) << 20) | (dn->busno << 16) |
+   (dn->devfn << 8) | (where & 0xff);
buid = dn->phb->buid;
if (buid) {
ret = rtas_call(ibm_read_pci_config, 4, 2, ,
@@ -110,8 +123,11 @@ static int rtas_write_config(struct devi
return PCIBIOS_DEVICE_NOT_FOUND;
if (where & (size - 1))
return PCIBIOS_BAD_REGISTER_NUMBER;
+   if (!config_access_valid(dn, where))
+   return PCIBIOS_BAD_REGISTER_NUMBER;
 
-   addr = (dn->busno << 16) | (dn->devfn << 8) | where;
+   addr = ((where & 0xf00) << 20) | (dn->busno << 16) |
+   (dn->devfn << 8) | (where & 0xff);
buid = dn->phb->buid;
if (buid) {
ret = rtas_call(ibm_write_pci_config, 5, 1, NULL, addr, buid >> 
32, buid & 0x, size, (ulong) val);
@@ -270,6 +286,16 @@ static int phb_set_bus_ranges(struct dev
return 0;
 }
 
+static char __devinit get_phb_config_space_type(struct pci_controller *phb)
+{
+   int *type = (int *)get_property(phb->arch_data,
+   "ibm,pci-config-space-type", NULL);
+
+   if (type && *type == 1)
+   return 1;
+   return 0;
+}
+
 static int __devinit setup_phb(struct device_node *dev,
   struct pci_controller *phb,
   unsigned int addr_size_words)
@@ -285,6 +311,7 @@ static int __devinit setup_phb(struct de
phb->arch_data = dev;
phb->ops = _pci_ops;
phb->buid = get_phb_buid(dev);
+   phb->pci_ext_config_space = get_phb_config_space_type(phb);
 
return 0;
 }
diff -puN include/asm-ppc64/pci-bridge.h~ppc64_pcix_mode2_cfg 
include/asm-ppc64/pci-bridge.h
--- linux-2.6.11-rc2-bk9/include/asm-ppc64/pci-bridge.h~ppc64_pcix_mode2_cfg
2005-01-31 22:27:49.0 -0600
+++ linux-2.6.11-rc2-bk9-bjking1/include/asm-ppc64/pci-bridge.h 2005-01-31 
22:27:49.0 -0600
@@ -17,6 +17,7 @@
 struct pci_controller {
struct pci_bus *bus;
char is_dynamic;
+   char pci_ext_config_space;
void *arch_data;
struct list_head list_node;
 

_


[ANNOUNCE] quilt.el minor mode for emacs

2005-01-31 Thread Matt Mackall
I've created a minor mode for using quilt in Emacs. I've made it
available at:

http://selenic.com/quilt/

It automatically detects files that are in a quilt hierarchy and
enables itself.

To prevent a common class of screw-up with quilt, it attempts to
determine which files are part of currently applied patches and
toggles the buffer read-only flag appropriately. It also prompts to
save quilted files for various operations so that all changes are
properly picked up.

Comments, suggestions, and additions welcome. This is essentially my
first attempt at doing anything non-trivial in elisp, so go easy on
the flames.

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


Re: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

2005-01-31 Thread Jack O'Quin
Con Kolivas <[EMAIL PROTECTED]> writes:

> Good work. Looks like you're probably right about the accounting. It
> may be as simple as the fact that it is on the timer tick that we're
> getting rescheduled and this ends up being accounted as more since the
> accounting happens only at the scheduler tick. A test run setting
> iso_cpu at 100% should tell you if it's accounting related - however
> the RLIMIT_RT_CPU patch is accounted in a similar way so I'm not sure
> there isn't another bug hanging around. 

> I'm afraid on my hardware it has been behaving just like SCHED_FIFO
> for some time which is why I've been hanging on your results. 

My guess is that most of this test fits inside that huge cache of
yours, making it run much faster than on my system.  You probably need
to increase the number of clients to get comparable results.

When you say just like SCHED_FIFO, do you mean completely clean?  Or
are you still getting unexplained xruns?  If that's the case, we need
to figure out why and eliminate them.

The reason I can measure an effect here is that the test is heavy
enough to stress my system and the system is RT-clean enough for
SCHED_FIFO to work properly.  (That's no surprise, I've been running
it that way for years.)

> You're not obliged to do anything (obviously), but the 100% run
> should help discriminate where the problem is.

I don't mind.  It's the main way I can help.  I just get busy some of
the time.

It did work better.  On the first run, there were a couple of real bad
xruns starting up.  But, the other two runs look fairly clean.

  http://www.joq.us/jack/benchmarks/sched-iso-fix.100

With a compile running, bad xruns and really long delays become a
serious problem again.

  http://www.joq.us/jack/benchmarks/sched-iso-fix.100+compile

Comparing the summary statistics with the 90% run, suggests that the
same problems occur in both cases, but not as often at 100%.

  http://www.joq.us/jack/benchmarks/.SUMMARY

With these latency demands, the system can't ever pick the wrong
thread on exit from even a single interrupt, or we're screwed.  I am
pretty well convinced this is not happening reliably (except with
SCHED_FIFO).
-- 
  joq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2.6] 6/7 replace net_sysctl_strdup by kstrdup

2005-01-31 Thread David S. Miller
On Tue,  1 Feb 2005 03:28:39 +
"" <[EMAIL PROTECTED]> wrote:

> This patch removes a strdup implmentation in the networking layer
> (net_sysctl_strdup), and updates it to use the kstrdup library function.
> 
> Signed-off-by: Paulo Marques <[EMAIL PROTECTED]>

If kstrdup() does in, I'm fine with this change.
net_sysctl_strdup() only exists because kstrdup() did
not.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/8] base-small: CONFIG_BASE_SMALL for small systems

2005-01-31 Thread Matt Mackall
On Mon, Jan 31, 2005 at 09:55:32PM -0300, Horst von Brand wrote:
> Matt Mackall <[EMAIL PROTECTED]> said:
> > This patch series introduced a new pair of CONFIG_EMBEDDED options call
> > CONFIG_BASE_FULL/CONFIG_BASE_SMALL. Disabling CONFIG_BASE_FULL sets
> > the boolean CONFIG_BASE_SMALL to 1 and it is used to shrink a number
> > of core data structures. The space savings for the current batch is
> > around 14k.
> 
> Why _two_ config options?

Um, Andrew made me do it?

One option is an int and is used thusly:

#define FOO (CONFIG_BASE_SMALL ? 1 : 1000)

But it's also sometimes useful to have two opposing options so that
you can use:

obj-(CONFIG_OBJ_A) += a.obj obj-(CONFIG_OBJ_B) += b.obj

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


Re: page fault scalability patch V16 [3/4]: Drop page_table_lock in handle_mm_fault

2005-01-31 Thread Nick Piggin
Christoph Lameter wrote:
The page fault handler attempts to use the page_table_lock only for short
time periods. It repeatedly drops and reacquires the lock. When the lock
is reacquired, checks are made if the underlying pte has changed before
replacing the pte value. These locations are a good fit for the use of
ptep_cmpxchg.
The following patch allows to remove the first time the page_table_lock is
acquired and uses atomic operations on the page table instead. A section
using atomic pte operations is begun with
page_table_atomic_start(struct mm_struct *)
and ends with
page_table_atomic_stop(struct mm_struct *)
Hmm, this is moving toward the direction my patches take.
I think it may be the right way to go if you're lifting the ptl
from some core things, because some architectures won't want to
audit and stuff, and some may need the lock.
Naturally I prefer the complete replacement that is made with
my patch - however this of course means one has to move
*everything* over to be pte_cmpxchg safe, which runs against
your goal of getting the low hanging fruit with as little fuss
as possible for the moment.

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


Re: page fault scalability patch V16 [3/4]: Drop page_table_lock in handle_mm_fault

2005-01-31 Thread Nick Piggin
Christoph Lameter wrote:
Slightly OT: are you still planning to move the update_mem_hiwater and
friends crud out of these fastpaths? It looks like at least that function
is unsafe to be lockless.
@@ -1316,21 +1318,27 @@ static int do_wp_page(struct mm_struct *
flush_cache_page(vma, address);
entry = maybe_mkwrite(pte_mkyoung(pte_mkdirty(pte)),
  vma);
-   ptep_set_access_flags(vma, address, page_table, entry, 
1);
-   update_mmu_cache(vma, address, entry);
+   /*
+* If the bits are not updated then another fault
+* will be generated with another chance of updating.
+*/
+   if (ptep_cmpxchg(page_table, pte, entry))
+   update_mmu_cache(vma, address, entry);
+   else
+   inc_page_state(cmpxchg_fail_flag_reuse);
pte_unmap(page_table);
-   spin_unlock(>page_table_lock);
+   page_table_atomic_stop(mm);
return VM_FAULT_MINOR;
}
}
pte_unmap(page_table);
+   page_table_atomic_stop(mm);
/*
 * Ok, we need to copy. Oh, well..
 */
if (!PageReserved(old_page))
page_cache_get(old_page);
-   spin_unlock(>page_table_lock);
I don't think you can do this unless you have done something funky that I
missed. And that kind of shoots down your lockless COW too, although it
looks like you can safely have the second part of do_wp_page without the
lock. Basically - your lockless COW patch itself seems like it should be
OK, but this hunk does not.
I would be very interested if you are seeing performance gains with your
lockless COW patches, BTW.
Basically, getting a reference on a struct page was the only thing I found
I wasn't able to do lockless with pte cmpxchg. Because it can race with
unmapping in rmap.c and reclaim and reuse, which probably isn't too good.
That means: the only operations you are able to do lockless is when there
is no backing page (ie. the anonymous unpopulated->populated case).
A per-pte lock is sufficient for this case, of course, which is why the
pte-locked system is completely free of the page table lock.
Although I may have some fact fundamentally wrong?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/8] base-small: CONFIG_BASE_SMALL for small systems

2005-01-31 Thread Horst von Brand
Matt Mackall <[EMAIL PROTECTED]> said:
> This patch series introduced a new pair of CONFIG_EMBEDDED options call
> CONFIG_BASE_FULL/CONFIG_BASE_SMALL. Disabling CONFIG_BASE_FULL sets
> the boolean CONFIG_BASE_SMALL to 1 and it is used to shrink a number
> of core data structures. The space savings for the current batch is
> around 14k.

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


Re: [PATCH 1/8] lib/sort: Heapsort implementation of sort()

2005-01-31 Thread Horst von Brand
Matt Mackall <[EMAIL PROTECTED]> said:
> This patch adds a generic array sorting library routine. This is meant
> to replace qsort, which has two problem areas for kernel use.

Another problem is the GPL license. It will certainly be wanted from
non-GPL (e.g., binary) modules. Please just EXPORT_SYMBOL it.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


PATCH: SysV semaphore race vs SIGSTOP

2005-01-31 Thread Ove Kaaven
As I mentioned in an earlier mail, there is a race when SIGSTOP-ing a
process waiting for a SysV semaphore, where if a process holding a
semaphore suspends another process waiting on the semaphore and then
releases the semaphore, the suspended process might still get the
semaphore, resulting in a deadlock. My sample test program is at
http://www.ping.uio.no/~ovehk/sembug.c

Now I've written a patch for this which seems to work for me. It is
against 2.4.27, but the semaphore code doesn't seem to change often. And
please Cc me on any questions or comments, since I'm not subscribed.
Here is the patch:

--- ipc/sem.c.original  2005-01-31 18:17:17.0 -0500
+++ ipc/sem.c   2005-01-31 18:17:34.0 -0500
@@ -307,6 +307,18 @@
return result;
 }
 
+static int is_stopping(struct task_struct *t)
+{
+   if (t->state == TASK_STOPPED) {
+   /* shouldn't happen */
+   return 1;
+   }
+   if (sigismember(>pending.signal, SIGSTOP)) {
+   return 1;
+   }
+   return 0;
+}
+
 /* Go through the pending queue for the indicated semaphore
  * looking for tasks that can be completed.
  */
@@ -961,6 +973,12 @@
error = -EIDRM;
goto out_free;
}
+
+   if (is_stopping(current))
+   /* Could either EINTR out or continue.
+* Currently I've chosen to continue */
+   continue;
+
/*
 * If queue.status == 1 we where woken up and
 * have to retry else we simply return.

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


Re: Touchpad problems with 2.6.11-rc2

2005-01-31 Thread Dmitry Torokhov
On Monday 31 January 2005 18:15, Pete Zaitcev wrote:
> Hello, Peter:
> 
> The keyboard seems to work now, but I stepped on a very strange condition.
> Suddenly, touchpad motions started to cause wild movements in it became
> impossible to do anything due to a focus loss (of course, I had plenty of
> modified files open :-)
> 
> The dmesg looked like this:
> 
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> 

1. Have you tried using external PS/2 mouse?
2. Have you plugged/unplugged into a port replicator?

2nd can be cured with psmouse.resetafter=3 (at least until we get
dock support in ACPI as pluggin/unplugging resets keyboard controller
and all devices without telling anyone), first one seems to be hopeless.
External device in Dells (at least in my Inspiron 8100) completely
shadows touchpad.

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


[PATCH 2.6] 5/7 use kstrdup library function in net/sunrpc/svcauth_unix.c

2005-01-31 Thread

This patch removes a private strdup in net/sunrpc/svcauth_unix.c, and updates it
to use the kstrdup library function.

Signed-off-by: Paulo Marques <[EMAIL PROTECTED]>

--
Paulo Marques - www.grupopie.com
 
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
--- vanilla-2.6.11-rc2-bk9/net/sunrpc/svcauth_unix.c	2005-01-31 20:05:34.0 +
+++ linux-2.6.11-rc2-bk9/net/sunrpc/svcauth_unix.c	2005-01-31 20:36:28.536400791 +
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define RPCDBG_FACILITY	RPCDBG_AUTH
 
@@ -20,14 +21,6 @@
  */
 
 
-static char *strdup(char *s)
-{
-	char *rv = kmalloc(strlen(s)+1, GFP_KERNEL);
-	if (rv)
-		strcpy(rv, s);
-	return rv;
-}
-
 struct unix_domain {
 	struct auth_domain	h;
 	int	addr_changes;
@@ -55,7 +48,7 @@ struct auth_domain *unix_domain_find(cha
 	if (new == NULL)
 		return NULL;
 	cache_init(>h.h);
-	new->h.name = strdup(name);
+	new->h.name = kstrdup(name, GFP_KERNEL);
 	new->h.flavour = RPC_AUTH_UNIX;
 	new->addr_changes = 0;
 	new->h.h.expiry_time = NEVER;


[PATCH 2.6] 2/7 use kstrdup library function in dm-ioctl.c

2005-01-31 Thread

This patch removes a private strdup in dm-ioctl.c, and updates it to use the
kstrdup library function.

Signed-off-by: Paulo Marques <[EMAIL PROTECTED]>

--
Paulo Marques - www.grupopie.com
 
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
--- linux-2.6.10/drivers/md/dm-ioctl.c.orig	2005-01-31 19:33:26.631039967 +
+++ linux-2.6.10/drivers/md/dm-ioctl.c	2005-01-31 19:34:08.488784182 +
@@ -122,14 +122,6 @@ static struct hash_cell *__get_uuid_cell
 /*-
  * Inserting, removing and renaming a device.
  *---*/
-static inline char *kstrdup(const char *str)
-{
-	char *r = kmalloc(strlen(str) + 1, GFP_KERNEL);
-	if (r)
-		strcpy(r, str);
-	return r;
-}
-
 static struct hash_cell *alloc_cell(const char *name, const char *uuid,
 struct mapped_device *md)
 {
@@ -139,7 +131,7 @@ static struct hash_cell *alloc_cell(cons
 	if (!hc)
 		return NULL;
 
-	hc->name = kstrdup(name);
+	hc->name = kstrdup(name, GFP_KERNEL);
 	if (!hc->name) {
 		kfree(hc);
 		return NULL;
@@ -149,7 +141,7 @@ static struct hash_cell *alloc_cell(cons
 		hc->uuid = NULL;
 
 	else {
-		hc->uuid = kstrdup(uuid);
+		hc->uuid = kstrdup(uuid, GFP_KERNEL);
 		if (!hc->uuid) {
 			kfree(hc->name);
 			kfree(hc);
@@ -273,7 +265,7 @@ static int dm_hash_rename(const char *ol
 	/*
 	 * duplicate new.
 	 */
-	new_name = kstrdup(new);
+	new_name = kstrdup(new, GFP_KERNEL);
 	if (!new_name)
 		return -ENOMEM;
 


[PATCH 2.6] 6/7 replace net_sysctl_strdup by kstrdup

2005-01-31 Thread

This patch removes a strdup implmentation in the networking layer
(net_sysctl_strdup), and updates it to use the kstrdup library function.

Signed-off-by: Paulo Marques <[EMAIL PROTECTED]>

--
Paulo Marques - www.grupopie.com
 
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
diff -uprN -X dontdiff vanilla-2.6.11-rc2-bk9/include/linux/netdevice.h linux-2.6.11-rc2-bk9/include/linux/netdevice.h
--- vanilla-2.6.11-rc2-bk9/include/linux/netdevice.h	2005-01-31 20:05:37.0 +
+++ linux-2.6.11-rc2-bk9/include/linux/netdevice.h	2005-01-31 23:52:04.0 +
@@ -929,10 +929,6 @@ extern int skb_checksum_help(struct sk_b
 extern void		net_enable_timestamp(void);
 extern void		net_disable_timestamp(void);
 
-#ifdef CONFIG_SYSCTL
-extern char *net_sysctl_strdup(const char *s);
-#endif
-
 #endif /* __KERNEL__ */
 
 #endif	/* _LINUX_DEV_H */
diff -uprN -X dontdiff vanilla-2.6.11-rc2-bk9/net/core/sysctl_net_core.c linux-2.6.11-rc2-bk9/net/core/sysctl_net_core.c
--- vanilla-2.6.11-rc2-bk9/net/core/sysctl_net_core.c	2004-12-24 21:34:31.0 +
+++ linux-2.6.11-rc2-bk9/net/core/sysctl_net_core.c	2005-01-31 23:53:05.0 +
@@ -35,19 +35,6 @@ extern int sysctl_somaxconn;
 extern char sysctl_divert_version[];
 #endif /* CONFIG_NET_DIVERT */
 
-/*
- * This strdup() is used for creating copies of network 
- * device names to be handed over to sysctl.
- */
- 
-char *net_sysctl_strdup(const char *s)
-{
-	char *rv = kmalloc(strlen(s)+1, GFP_KERNEL);
-	if (rv)
-		strcpy(rv, s);
-	return rv;
-}
-
 ctl_table core_table[] = {
 #ifdef CONFIG_NET
 	{
@@ -177,6 +164,4 @@ ctl_table core_table[] = {
 	{ .ctl_name = 0 }
 };
 
-EXPORT_SYMBOL(net_sysctl_strdup);
-
 #endif
diff -uprN -X dontdiff vanilla-2.6.11-rc2-bk9/net/ipv4/devinet.c linux-2.6.11-rc2-bk9/net/ipv4/devinet.c
--- vanilla-2.6.11-rc2-bk9/net/ipv4/devinet.c	2005-01-31 20:05:34.0 +
+++ linux-2.6.11-rc2-bk9/net/ipv4/devinet.c	2005-01-31 23:58:35.0 +
@@ -1438,7 +1438,7 @@ static void devinet_sysctl_register(stru
 	 * by sysctl and we wouldn't want anyone to change it under our feet
 	 * (see SIOCSIFNAME).
 	 */	
-	dev_name = net_sysctl_strdup(dev_name);
+	dev_name = kstrdup(dev_name, GFP_KERNEL);
 	if (!dev_name)
 	goto free;
 
diff -uprN -X dontdiff vanilla-2.6.11-rc2-bk9/net/ipv6/addrconf.c linux-2.6.11-rc2-bk9/net/ipv6/addrconf.c
--- vanilla-2.6.11-rc2-bk9/net/ipv6/addrconf.c	2005-01-31 20:05:34.0 +
+++ linux-2.6.11-rc2-bk9/net/ipv6/addrconf.c	2005-01-31 23:58:56.0 +
@@ -57,6 +57,7 @@
 #endif
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -3361,7 +3362,7 @@ static void addrconf_sysctl_register(str
 	 * by sysctl and we wouldn't want anyone to change it under our feet
 	 * (see SIOCSIFNAME).
 	 */	
-	dev_name = net_sysctl_strdup(dev_name);
+	dev_name = kstrdup(dev_name, GFP_KERNEL);
 	if (!dev_name)
 	goto free;

diff -uprN -X dontdiff vanilla-2.6.11-rc2-bk9/net/core/neighbour.c linux-2.6.11-rc2-bk9/net/core/neighbour.c
--- vanilla-2.6.11-rc2-bk9/net/core/neighbour.c	2005-01-31 20:05:37.0 +
+++ linux-2.6.11-rc2-bk9/net/core/neighbour.c	2005-02-01 02:09:26.975638604 +
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 

 #define NEIGH_DEBUG 1

@@ -2239,7 +2240,7 @@ int neigh_sysctl_register(struct net_dev
 		t->neigh_vars[15].data = (int *)(p + 1) + 3;
 	}

-	dev_name = net_sysctl_strdup(dev_name_source);
+	dev_name = kstrdup(dev_name_source, GFP_KERNEL);
 	if (!dev_name) {
 		err = -ENOBUFS;
 		goto free;


[PATCH 2.6] 7/7 replace snd_kmalloc_strdup by kstrdup

2005-01-31 Thread

This patch removes the strdup implementation from the sound core
(snd_kmalloc_strdup), and updates it to use the kstrdup library function.

Signed-off-by: Paulo Marques <[EMAIL PROTECTED]>

--
Paulo Marques - www.grupopie.com
 
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
diff -uprN -X dontdiff vanilla-2.6.11-rc2-bk9/include/sound/core.h linux-2.6.11-rc2-bk9/include/sound/core.h
--- vanilla-2.6.11-rc2-bk9/include/sound/core.h	2005-01-31 20:05:33.0 +
+++ linux-2.6.11-rc2-bk9/include/sound/core.h	2005-01-31 21:31:54.0 +
@@ -310,7 +310,6 @@ void snd_hidden_vfree(void *obj);
 #define kfree_nocheck(obj) kfree(obj)
 #define vfree_nocheck(obj) vfree(obj)
 #endif
-char *snd_kmalloc_strdup(const char *string, int flags);
 int copy_to_user_fromio(void __user *dst, const volatile void __iomem *src, size_t count);
 int copy_from_user_toio(volatile void __iomem *dst, const void __user *src, size_t count);
 
diff -uprN -X dontdiff vanilla-2.6.11-rc2-bk9/sound/core/info.c linux-2.6.11-rc2-bk9/sound/core/info.c
--- vanilla-2.6.11-rc2-bk9/sound/core/info.c	2005-01-31 20:05:34.0 +
+++ linux-2.6.11-rc2-bk9/sound/core/info.c	2005-01-31 21:31:02.0 +
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -755,7 +756,7 @@ static snd_info_entry_t *snd_info_create
 	entry = kcalloc(1, sizeof(*entry), GFP_KERNEL);
 	if (entry == NULL)
 		return NULL;
-	entry->name = snd_kmalloc_strdup(name, GFP_KERNEL);
+	entry->name = kstrdup(name, GFP_KERNEL);
 	if (entry->name == NULL) {
 		kfree(entry);
 		return NULL;
diff -uprN -X dontdiff vanilla-2.6.11-rc2-bk9/sound/core/info_oss.c linux-2.6.11-rc2-bk9/sound/core/info_oss.c
--- vanilla-2.6.11-rc2-bk9/sound/core/info_oss.c	2004-12-24 21:34:01.0 +
+++ linux-2.6.11-rc2-bk9/sound/core/info_oss.c	2005-01-31 21:30:35.0 +
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if defined(CONFIG_SND_OSSEMUL) && defined(CONFIG_PROC_FS)
 
@@ -51,7 +52,7 @@ int snd_oss_info_register(int dev, int n
 			x = NULL;
 		}
 	} else {
-		x = snd_kmalloc_strdup(string, GFP_KERNEL);
+		x = kstrdup(string, GFP_KERNEL);
 		if (x == NULL) {
 			up();
 			return -ENOMEM;
diff -uprN -X dontdiff vanilla-2.6.11-rc2-bk9/sound/core/memory.c linux-2.6.11-rc2-bk9/sound/core/memory.c
--- vanilla-2.6.11-rc2-bk9/sound/core/memory.c	2005-01-31 20:05:34.0 +
+++ linux-2.6.11-rc2-bk9/sound/core/memory.c	2005-01-31 21:30:07.0 +
@@ -221,29 +221,6 @@ int __exit snd_memory_info_done(void)
 #endif /* CONFIG_SND_DEBUG_MEMORY */
 
 /**
- * snd_kmalloc_strdup - copy the string
- * @string: the original string
- * @flags: allocation conditions, GFP_XXX
- *
- * Allocates a memory chunk via kmalloc() and copies the string to it.
- *
- * Returns the pointer, or NULL if no enoguh memory.
- */
-char *snd_kmalloc_strdup(const char *string, int flags)
-{
-	size_t len;
-	char *ptr;
-
-	if (!string)
-		return NULL;
-	len = strlen(string) + 1;
-	ptr = _snd_kmalloc(len, flags);
-	if (ptr)
-		memcpy(ptr, string, len);
-	return ptr;
-}
-
-/**
  * copy_to_user_fromio - copy data from mmio-space to user-space
  * @dst: the destination pointer on user-space
  * @src: the source pointer on mmio
diff -uprN -X dontdiff vanilla-2.6.11-rc2-bk9/sound/core/oss/mixer_oss.c linux-2.6.11-rc2-bk9/sound/core/oss/mixer_oss.c
--- vanilla-2.6.11-rc2-bk9/sound/core/oss/mixer_oss.c	2005-01-31 20:05:34.0 +
+++ linux-2.6.11-rc2-bk9/sound/core/oss/mixer_oss.c	2005-01-31 21:30:19.0 +
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1122,7 +1123,7 @@ static void snd_mixer_oss_proc_write(snd
 			goto __unlock;
 		}
 		tbl->oss_id = ch;
-		tbl->name = snd_kmalloc_strdup(str, GFP_KERNEL);
+		tbl->name = kstrdup(str, GFP_KERNEL);
 		if (! tbl->name) {
 			kfree(tbl);
 			goto __unlock;
diff -uprN -X dontdiff vanilla-2.6.11-rc2-bk9/sound/core/oss/pcm_oss.c linux-2.6.11-rc2-bk9/sound/core/oss/pcm_oss.c
--- vanilla-2.6.11-rc2-bk9/sound/core/oss/pcm_oss.c	2005-01-31 20:05:34.0 +
+++ linux-2.6.11-rc2-bk9/sound/core/oss/pcm_oss.c	2005-01-31 21:30:24.0 +
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2349,7 +2350,7 @@ static void snd_pcm_oss_proc_write(snd_i
 	for (setup1 = pstr->oss.setup_list; setup1->next; setup1 = setup1->next);
 	setup1->next = setup;
 }
-template.task_name = snd_kmalloc_strdup(task_name, GFP_KERNEL);
+template.task_name = kstrdup(task_name, GFP_KERNEL);
 			} else {
 buffer->error = -ENOMEM;
 			}
diff -uprN -X dontdiff vanilla-2.6.11-rc2-bk9/sound/core/sound.c linux-2.6.11-rc2-bk9/sound/core/sound.c
--- vanilla-2.6.11-rc2-bk9/sound/core/sound.c	2005-01-31 20:05:34.0 +
+++ linux-2.6.11-rc2-bk9/sound/core/sound.c	2005-01-31 21:30:47.0 +
@@ -401,7 +401,6 @@ 

[PATCH 2.6] 4/7 replace uml_strdup by kstrdup

2005-01-31 Thread

This patch removes the strdup implementation in the UML architecture
(uml_strdup), and updates it to use the kstrdup library function.

Signed-off-by: Paulo Marques <[EMAIL PROTECTED]>

--
Paulo Marques - www.grupopie.com
 
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
diff -buprN -X dontdiff vanilla-2.6.11-rc2-bk9/arch/um/drivers/cow_sys.h linux-2.6.11-rc2-bk9/arch/um/drivers/cow_sys.h
--- vanilla-2.6.11-rc2-bk9/arch/um/drivers/cow_sys.h	2005-01-31 20:05:17.0 +
+++ linux-2.6.11-rc2-bk9/arch/um/drivers/cow_sys.h	2005-01-31 20:40:01.713782823 +
@@ -18,11 +18,6 @@ static inline void cow_free(void *ptr)
 
 #define cow_printf printk
 
-static inline char *cow_strdup(char *str)
-{
-	return(uml_strdup(str));
-}
-
 static inline int cow_seek_file(int fd, unsigned long long offset)
 {
 	return(os_seek_file(fd, offset));
diff -buprN -X dontdiff vanilla-2.6.11-rc2-bk9/arch/um/drivers/cow_user.c linux-2.6.11-rc2-bk9/arch/um/drivers/cow_user.c
--- vanilla-2.6.11-rc2-bk9/arch/um/drivers/cow_user.c	2005-01-31 20:05:17.0 +
+++ linux-2.6.11-rc2-bk9/arch/um/drivers/cow_user.c	2005-01-31 20:39:08.587154730 +
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "os.h"
 
@@ -313,7 +314,7 @@ int read_cow_header(int (*reader)(__u64,
 		goto out;
 	}
 	err = -ENOMEM;
-	*backing_file_out = cow_strdup(file);
+	*backing_file_out = kstrdup(file, GFP_KERNEL);
 	if(*backing_file_out == NULL){
 		cow_printf("read_cow_header - failed to allocate backing "
 			   "file\n");
diff -buprN -X dontdiff vanilla-2.6.11-rc2-bk9/arch/um/drivers/line.c linux-2.6.11-rc2-bk9/arch/um/drivers/line.c
--- vanilla-2.6.11-rc2-bk9/arch/um/drivers/line.c	2005-01-31 20:05:17.0 +
+++ linux-2.6.11-rc2-bk9/arch/um/drivers/line.c	2005-01-31 20:39:08.587154730 +
@@ -9,6 +9,7 @@
 #include "linux/kd.h"
 #include "linux/interrupt.h"
 #include "linux/devfs_fs_kernel.h"
+#include "linux/string.h"
 #include "asm/uaccess.h"
 #include "chan_kern.h"
 #include "irq_user.h"
@@ -445,10 +446,10 @@ int line_setup(struct line *lines, int n
 
 int line_config(struct line *lines, int num, char *str)
 {
-	char *new = uml_strdup(str);
+	char *new = kstrdup(str, GFP_KERNEL);
 
 	if(new == NULL){
-		printk("line_config - uml_strdup failed\n");
+		printk("line_config - kstrdup failed\n");
 		return(-ENOMEM);
 	}
 	return(!line_setup(lines, num, new, 0));
@@ -555,9 +556,9 @@ void lines_init(struct line *lines, int 
 		INIT_LIST_HEAD(>chan_list);
 		sema_init(>sem, 1);
 		if(line->init_str != NULL){
-			line->init_str = uml_strdup(line->init_str);
+			line->init_str = kstrdup(line->init_str, GFP_KERNEL);
 			if(line->init_str == NULL)
-printk("lines_init - uml_strdup returned "
+printk("lines_init - kstrdup returned "
    "NULL\n");
 		}
 	}
diff -buprN -X dontdiff vanilla-2.6.11-rc2-bk9/arch/um/drivers/mconsole_kern.c linux-2.6.11-rc2-bk9/arch/um/drivers/mconsole_kern.c
--- vanilla-2.6.11-rc2-bk9/arch/um/drivers/mconsole_kern.c	2005-01-31 20:05:17.0 +
+++ linux-2.6.11-rc2-bk9/arch/um/drivers/mconsole_kern.c	2005-01-31 20:39:08.588154554 +
@@ -20,6 +20,7 @@
 #include "linux/namei.h"
 #include "linux/proc_fs.h"
 #include "linux/syscalls.h"
+#include "linux/string.h"
 #include "asm/irq.h"
 #include "asm/uaccess.h"
 #include "user_util.h"
@@ -483,7 +484,7 @@ int mconsole_init(void)
 	}
 
 	if(notify_socket != NULL){
-		notify_socket = uml_strdup(notify_socket);
+		notify_socket = kstrdup(notify_socket, GFP_KERNEL);
 		if(notify_socket != NULL)
 			mconsole_notify(notify_socket, MCONSOLE_SOCKET,
 	mconsole_socket_name, 
diff -buprN -X dontdiff vanilla-2.6.11-rc2-bk9/arch/um/drivers/net_kern.c linux-2.6.11-rc2-bk9/arch/um/drivers/net_kern.c
--- vanilla-2.6.11-rc2-bk9/arch/um/drivers/net_kern.c	2005-01-31 20:05:17.0 +
+++ linux-2.6.11-rc2-bk9/arch/um/drivers/net_kern.c	2005-01-31 20:39:08.589154377 +
@@ -20,6 +20,7 @@
 #include "linux/ctype.h"
 #include "linux/bootmem.h"
 #include "linux/ethtool.h"
+#include "linux/string.h"
 #include "asm/uaccess.h"
 #include "user_util.h"
 #include "kern_util.h"
@@ -602,7 +603,7 @@ static int net_config(char *str)
 	err = eth_parse(str, , );
 	if(err) return(err);
 
-	str = uml_strdup(str);
+	str = kstrdup(str, GFP_KERNEL);
 	if(str == NULL){
 		printk(KERN_ERR "net_config failed to strdup string\n");
 		return(-1);
diff -buprN -X dontdiff vanilla-2.6.11-rc2-bk9/arch/um/drivers/ubd_kern.c linux-2.6.11-rc2-bk9/arch/um/drivers/ubd_kern.c
--- vanilla-2.6.11-rc2-bk9/arch/um/drivers/ubd_kern.c	2005-01-31 20:05:17.0 +
+++ linux-2.6.11-rc2-bk9/arch/um/drivers/ubd_kern.c	2005-01-31 20:39:08.589154377 +
@@ -35,6 +35,7 @@
 #include "linux/blkpg.h"
 #include "linux/genhd.h"
 #include "linux/spinlock.h"
+#include "linux/string.h"
 #include "asm/segment.h"
 #include "asm/uaccess.h"
 #include "asm/irq.h"
@@ -722,7 +723,7 @@ static int ubd_config(char *str)
 {
 	int n, err;
 
-	str 

[PATCH 2.6] 3/7 use kstrdup library function in parport/probe.c

2005-01-31 Thread

This patch removes a private strdup in parport/probe.c, and updates it to use
the kstrdup library function.

Signed-off-by: Paulo Marques <[EMAIL PROTECTED]>

--
Paulo Marques - www.grupopie.com
 
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
--- linux-2.6.10/drivers/parport/probe.c.orig	2005-01-31 19:35:06.460734972 +
+++ linux-2.6.10/drivers/parport/probe.c	2005-01-31 19:36:04.450682501 +
@@ -48,14 +48,6 @@ static void pretty_print(struct parport 
 	printk("\n");
 }
 
-static char *strdup(char *str)
-{
-	int n = strlen(str)+1;
-	char *s = kmalloc(n, GFP_KERNEL);
-	if (!s) return NULL;
-	return strcpy(s, str);
-}
-
 static void parse_data(struct parport *port, int device, char *str)
 {
 	char *txt = kmalloc(strlen(str)+1, GFP_KERNEL);
@@ -88,16 +80,16 @@ static void parse_data(struct parport *p
 			if (!strcmp(p, "MFG") || !strcmp(p, "MANUFACTURER")) {
 if (info->mfr)
 	kfree (info->mfr);
-info->mfr = strdup(sep);
+info->mfr = kstrdup(sep, GFP_KERNEL);
 			} else if (!strcmp(p, "MDL") || !strcmp(p, "MODEL")) {
 if (info->model)
 	kfree (info->model);
-info->model = strdup(sep);
+info->model = kstrdup(sep, GFP_KERNEL);
 			} else if (!strcmp(p, "CLS") || !strcmp(p, "CLASS")) {
 int i;
 if (info->class_name)
 	kfree (info->class_name);
-info->class_name = strdup(sep);
+info->class_name = kstrdup(sep, GFP_KERNEL);
 for (u = sep; *u; u++)
 	*u = toupper(*u);
 for (i = 0; classes[i].token; i++) {
@@ -112,7 +104,7 @@ static void parse_data(struct parport *p
    !strcmp(p, "COMMAND SET")) {
 if (info->cmdset)
 	kfree (info->cmdset);
-info->cmdset = strdup(sep);
+info->cmdset = kstrdup(sep, GFP_KERNEL);
 /* if it speaks printer language, it's
    probably a printer */
 if (strstr(sep, "PJL") || strstr(sep, "PCL"))
@@ -120,7 +112,7 @@ static void parse_data(struct parport *p
 			} else if (!strcmp(p, "DES") || !strcmp(p, "DESCRIPTION")) {
 if (info->description)
 	kfree (info->description);
-info->description = strdup(sep);
+info->description = kstrdup(sep, GFP_KERNEL);
 			}
 		}
 	rock_on:


[PATCH 2.6] 1/7 create kstrdup library function

2005-01-31 Thread

This patch creates the kstrdup library function so that it doesn't have to be
reimplemented (or even EXPORT'ed) by every user that needs it.

Signed-off-by: Paulo Marques <[EMAIL PROTECTED]>

--
Paulo Marques - www.grupopie.com
 
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
diff -buprN -X dontdiff vanilla-2.6.11-rc2-bk9/include/linux/string.h linux-2.6.11-rc2-bk9/include/linux/string.h
--- vanilla-2.6.11-rc2-bk9/include/linux/string.h	2004-12-24 21:34:31.0 +
+++ linux-2.6.11-rc2-bk9/include/linux/string.h	2005-01-31 19:31:12.0 +
@@ -88,6 +88,8 @@ extern int memcmp(const void *,const voi
 extern void * memchr(const void *,int,__kernel_size_t);
 #endif

+extern char *kstrdup(const char *s, int gfp);
+
 #ifdef __cplusplus
 }
 #endif
diff -buprN -X dontdiff vanilla-2.6.11-rc2-bk9/lib/string.c linux-2.6.11-rc2-bk9/lib/string.c
--- vanilla-2.6.11-rc2-bk9/lib/string.c	2005-01-31 20:05:37.0 +
+++ linux-2.6.11-rc2-bk9/lib/string.c	2005-01-31 20:00:31.0 +
@@ -599,3 +599,23 @@ void *memchr(const void *s, int c, size_
 }
 EXPORT_SYMBOL(memchr);
 #endif
+
+/*
+ * kstrdup - allocate space for and copy an existing string
+ *
+ * @s: the string to duplicate
+ * @gfp: the GFP mask used in the kmalloc() call when allocating memory
+ */
+char *kstrdup(const char *s, int gfp)
+{
+	int len;
+	char *buf;
+
+	if (!s) return NULL;
+
+	len = strlen(s) + 1;
+	buf = kmalloc(len, gfp);
+	if (buf)
+		memcpy(buf, s, len);
+	return buf;
+}
+
+EXPORT_SYMBOL(kstrdup);


[PATCH 2.6] 0/7 make kstrdup a library function

2005-01-31 Thread

This series of patches create a "char *kstrdup(const char *s, int gfp)" library
function, and remove all the "private" strdup implementations in the kernel
tree.

1 - create a kstrdup library function
2 - remove private strdup from drivers/md/dm-ioctl.c
3 - remove private strdup from drivers/parport/probe.c
4 - remove uml_strdup (UML architecture)
5 - remove private strdup from net/sunrpc/svcauth_unix.c
6 - remove net_sysctl_strdup (networking)
7 - remove snd_kmalloc_strdup (sound)

This is just a cleanup to allow reusing the strdup code, and to prevent bugs in
future duplications of strdup.

These patches were built against 2.6.11-rc2-bk9. Patch 1/7 is similar to a patch
sent by Rusty Russell (although not quite the same), and 2/7 is also similar to
another patch sent today by Matt Domsch. So these should go over a vanilla
kernel without any of those patches.

All the patches depend on the first patch, but are otherwise independent.

Signed-off-by: Paulo Marques <[EMAIL PROTECTED]>

--
Paulo Marques - www.grupopie.com
 
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.11-rc2-mm2 (& bk9) - rowdy little warn in drivers/usb/input/hid-input.c

2005-01-31 Thread Jim Nelson
Cal wrote:
With 2.6.11-rc2-mm2 & 2.6.11-rc2-bk9 and usb mouse, the warn("event 
field not found") in drivers/usb/input/hid-input.c is hyperactive 
whenever the mouse moves.

hihone kernel: drivers/usb/input/hid-input.c: event field not found
hihone last message repeated 619 times
hihone last message repeated 919 times
hihone last message repeated 1325 times
hihone last message repeated 1045 times
On the deviant case, both type and code appear to have the value 4 (if 
that helps).  The mouse reports as
hihone kernel: input: USB HID v1.00 Mouse [Microsoft Microsoft 
IntelliMouse Optical] on usb-:00:07.2-2

cheers, Cal
(not subscribed, pls cc if needed)

I'm seeing the same thing on 2.6.11-rc2-mm2 with a Logitech USB mouse - every time 
the mouse moves, it throws these messages.

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


Re: USB ioctl problem in 2.4.28

2005-01-31 Thread Pete Zaitcev
On Wed, 1 Dec 2004 14:57:41 +0200 (EET), Kaupo Arulo <[EMAIL PROTECTED]> wrote:

> We can use a macro, if it is really necessary

No, I prefer it explicit. See the attached patch. I changed Sergey's patch
just a little, so the invalid ioctls are detected outside the lock.

> IMHO it is correct to return -ENOIOCTLCMD right away, not waiting for 
> freeing a mutex.

Returning ENOIOCTLCMD is never correct, BTW, so I fixed that too.

Someone please test this patch with modem_run and let me know if it works.
I think it should be correct, but I would prefer a confirmation before
this goes to Marcelo.

Thank you in advance,
-- Pete

diff -urp -X dontdiff linux-2.4.29/drivers/usb/devio.c 
linux-2.4.29-usb/drivers/usb/devio.c
--- linux-2.4.29/drivers/usb/devio.c2004-11-22 23:04:18.0 -0800
+++ linux-2.4.29-usb/drivers/usb/devio.c2005-01-31 17:57:45.342576912 
-0800
@@ -1132,6 +1132,8 @@ static int proc_ioctl (struct dev_state 
/* ifno might usefully be passed ... */
retval = driver->ioctl (ps->dev, ctrl.ioctl_code, buf);
/* size = min_t(int, size, retval)? */
+   if (retval == -ENOIOCTLCMD)
+   retval = -ENOTTY;
}
}
 
@@ -1146,24 +1148,10 @@ static int proc_ioctl (struct dev_state 
return retval;
 }
 
-static int usbdev_ioctl(struct inode *inode, struct file *file, unsigned int 
cmd, unsigned long arg)
+static int usbdev_ioctl_exclusive(struct dev_state *ps, struct inode *inode,
+ unsigned int cmd, unsigned long arg)
 {
-   struct dev_state *ps = (struct dev_state *)file->private_data;
-   int ret = -ENOIOCTLCMD;
-
-   if (!(file->f_mode & FMODE_WRITE))
-   return -EPERM;
-   down_read(>devsem);
-   if (!ps->dev) {
-   up_read(>devsem);
-   return -ENODEV;
-   }
-
-   /*
-* grab device's exclusive_access mutex to prevent its driver from
-* using this device while it is being accessed by us.
-*/
-   down(>dev->exclusive_access);
+   int ret;
 
switch (cmd) {
case USBDEVFS_CONTROL:
@@ -1194,14 +1182,6 @@ static int usbdev_ioctl(struct inode *in
inode->i_mtime = CURRENT_TIME;
break;
 
-   case USBDEVFS_GETDRIVER:
-   ret = proc_getdriver(ps, (void *)arg);
-   break;
-
-   case USBDEVFS_CONNECTINFO:
-   ret = proc_connectinfo(ps, (void *)arg);
-   break;
-
case USBDEVFS_SETINTERFACE:
ret = proc_setintf(ps, (void *)arg);
break;
@@ -1220,6 +1200,53 @@ static int usbdev_ioctl(struct inode *in
ret = proc_unlinkurb(ps, (void *)arg);
break;
 
+   case USBDEVFS_CLAIMINTERFACE:
+   ret = proc_claiminterface(ps, (void *)arg);
+   break;
+
+   case USBDEVFS_RELEASEINTERFACE:
+   ret = proc_releaseinterface(ps, (void *)arg);
+   break;
+
+   case USBDEVFS_IOCTL:
+   ret = proc_ioctl(ps, (void *) arg);
+   break;
+
+   default:
+   ret = -ENOTTY;
+   }
+   return ret;
+}
+
+static int usbdev_ioctl(struct inode *inode, struct file *file,
+   unsigned int cmd, unsigned long arg)
+{
+   struct dev_state *ps = file->private_data;
+   int ret;
+
+   if (!(file->f_mode & FMODE_WRITE))
+   return -EPERM;
+   down_read(>devsem);
+   if (!ps->dev) {
+   up_read(>devsem);
+   return -ENODEV;
+   }
+
+   /*
+* Some ioctls don't touch the device and can be called without
+* grabbing its exclusive_access mutex; they are handled in this
+* switch.  Other ioctls which need exclusive_access are handled in
+* usbdev_ioctl_exclusive().
+*/
+   switch (cmd) {
+   case USBDEVFS_GETDRIVER:
+   ret = proc_getdriver(ps, (void *)arg);
+   break;
+
+   case USBDEVFS_CONNECTINFO:
+   ret = proc_connectinfo(ps, (void *)arg);
+   break;
+
case USBDEVFS_REAPURB:
ret = proc_reapurb(ps, (void *)arg);
break;
@@ -1232,19 +1259,28 @@ static int usbdev_ioctl(struct inode *in
ret = proc_disconnectsignal(ps, (void *)arg);
break;
 
+   case USBDEVFS_CONTROL:
+   case USBDEVFS_BULK:
+   case USBDEVFS_RESETEP:
+   case USBDEVFS_RESET:
+   case USBDEVFS_CLEAR_HALT:
+   case USBDEVFS_SETINTERFACE:
+   case USBDEVFS_SETCONFIGURATION:
+   case USBDEVFS_SUBMITURB:
+   case USBDEVFS_DISCARDURB:
case USBDEVFS_CLAIMINTERFACE:
-   ret = proc_claiminterface(ps, (void *)arg);
-   break;
-
case USBDEVFS_RELEASEINTERFACE:
-   ret = proc_releaseinterface(ps, (void 

Re: pci: Arch hook to determine config space size

2005-01-31 Thread Benjamin Herrenschmidt
On Mon, 2005-01-31 at 16:43 -0600, Brian King wrote:

> diff -puN include/asm-ppc64/prom.h~ppc64_pcix_mode2_cfg 
> include/asm-ppc64/prom.h
> --- linux-2.6.11-rc2-bk9/include/asm-ppc64/prom.h~ppc64_pcix_mode2_cfg
> 2005-01-31 14:32:01.0 -0600
> +++ linux-2.6.11-rc2-bk9-bjking1/include/asm-ppc64/prom.h 2005-01-31 
> 14:32:01.0 -0600
> @@ -137,6 +137,7 @@ struct device_node {
>   int devfn;  /* for pci devices */
>   int eeh_mode;   /* See eeh.h for possible EEH_MODEs */
>   int eeh_config_addr;
> + int pci_ext_config_space;   /* for phb's or bridges */
>   struct  pci_controller *phb;/* for pci devices */
>   struct  iommu_table *iommu_table;   /* for phb's or bridges */

Grrr... more crap added to the device-node, I don't like that ...

This is a PHB only field, can't it be in struct pci_controller instead ?

Ben.




Patch for CIFS vfs

2005-01-31 Thread Nitin Gupta
This is the patch for CIFS ver 1.22 (included with linux-2.6.8). This 
improves cifs vfs client file read performance by 10-15%.

Changes were made only to a single file in cifs tree 
(/usr/src/linux/fs/cifs/file.c)

The function cifs_readpages() is modifed and cifs_readpages_threadfn() has 
been added.

Current implementation sends a read request to server and waits for data to 
arrive before sending the next read request.
This has been modified to implement sending back-to-back multiple read 
requests using single connection stream.
It is implemented by starting multiple threads with each one sending a read 
request for different parts of file.

Still to do --
-- submit multiple read requests in parallel using _multiple connections_
-- dynamically control no. of threads operating depending on server response 
time

I have tested it to be quite stable with good performance gain.
Please give test results and comments to --
[EMAIL PROTECTED]
Nitin Gupta
Thanks
_
Manage information better. Optimise your tasks. 
http://www.microsoft.com/india/office/experience/  Experience MS Office 
System.
--- linux/fs/cifs/file.c2005-01-16 17:50:00.081086264 +0530
+++ /home/temp/file-en.c2005-01-16 17:48:49.441825064 +0530
@@ -1,4 +1,8 @@
-/*
+/*  
+ *  modified function cifs_readpages()
+ *  added function cifs_readpages_threadfn()
+ *
+ *
 *   fs/cifs/file.c
 *
 *   vfs operations that deal with files
@@ -35,6 +39,38 @@
#include "cifs_debug.h"
#include "cifs_fs_sb.h"
+#include 
+#include 
+#include 
+
+#define FIN_WAIT 1
+#define FIN_ERR  3
+
+struct per_thread_data {
+   int interrupted;
+   wait_queue_head_t wq_h;
+
+   int xid, rsize_in_pages;
+   struct file *file;
+   struct address_space *mapping;
+   struct list_head *page_list;
+   struct pagevec lru_pvec;
+   struct cifsFileInfo * open_file;
+   struct cifs_sb_info *cifs_sb;
+   struct cifsTconInfo *pTcon;
+
+   spinlock_t sl_page_pool;
+   spinlock_t sl_cache_lock;
+   struct semaphore threadsem;
+   volatile struct list_head *page_pool;
+
+   atomic_t pages_left;
+   atomic_t read_state;
+   atomic_t thread_count;
+   atomic_t threads_required;
+};
+
+
int
cifs_open(struct inode *inode, struct file *file)
{
@@ -1093,49 +1129,109 @@ static void cifs_copy_cache_pages(struct
}
-static int
-cifs_readpages(struct file *file, struct address_space *mapping,
-   struct list_head *page_list, unsigned num_pages)
+int cifs_readpages_threadfn (void *data)
{
-   int rc = -EACCES;
-   int xid;
-   loff_t offset;
-   struct page * page;
-   struct cifs_sb_info *cifs_sb;
-   struct cifsTconInfo *pTcon;
-   int bytes_read = 0;
-   unsigned int read_size,i;
-   char * smb_read_data = NULL;
-   struct smb_com_read_rsp * pSMBr;
-   struct pagevec lru_pvec;
-   struct cifsFileInfo * open_file;
-	xid = GetXid();
-	if (file->private_data == NULL) {
-		FreeXid(xid);
-		return -EBADF;
+int i, rc;
+unsigned num_pages;
+char *smb_read_data = NULL;
+struct page *page;
+
+struct list_head page_list_head;
+struct list_head *page_list;
+
+
+struct per_thread_data *t = (struct per_thread_data *)data;
+
+while ( atomic_read(>pages_left) > 0 )
+{
+
+	INIT_LIST_HEAD(_list_head);
+
+	if (atomic_read(>read_state) == FIN_ERR || (t->interrupted == 1)) 
break;
+
+
+spin_lock(>sl_page_pool);
+
+	if (atomic_read(>threads_required) < atomic_read(>thread_count)) {
+		spin_unlock(>sl_page_pool);
+		atomic_dec(>thread_count);
+		return 0;
+	}
+
+	if (atomic_read(>read_state) == FIN_ERR) /* if error */ {
+		spin_unlock(>sl_page_pool);
+		break;
	}
-	open_file = (struct cifsFileInfo *)file->private_data;
-	cifs_sb = CIFS_SB(file->f_dentry->d_sb);
-	pTcon = cifs_sb->tcon;
+	/*	if(atomic_read(>thread_count)<=1) {
+			atomic_dec(>thread_count);
+			up(>threadsem);
+			return 0;
+		} else {
+			atomic_dec(>thread_count);
+			return 0;
+		}
+	}*/
+
+	if (atomic_read(>read_state) == FIN_WAIT) { /* endwait state */
+		if (atomic_read(>thread_count) <= 1) {
+			spin_unlock(>sl_page_pool);
+			atomic_dec(>thread_count);
+			up(>threadsem);
+			return 0;
+		} else {
+			atomic_dec(>thread_count);
+			spin_unlock(>sl_page_pool);
+			return 0;
+		}
+	}
+
+	//printk("\npages_left = %d\n", atomic_read(>pages_left));
+
+	if (atomic_read(>pages_left) >= t->rsize_in_pages) {
+		num_pages = t->rsize_in_pages;
+	} else {
+		num_pages = atomic_read(>pages_left);
+	}
+
+	//num_pages = 1;
+	atomic_sub(num_pages, >pages_left);
+
+	for (i=0; i
+		page = list_entry(t->page_pool, struct page, lru);
+		t->page_pool = t->page_pool->prev;
+		list_del(>lru);
+		list_add(>lru, _list_head);
+	}
+
+	//printk("\npages_left now = %d\n", atomic_read(>pages_left));
+
+	if ( atomic_read(>pages_left) <= 0 )
+		atomic_set(>read_state, FIN_WAIT); /* set endwait state */

-   pagevec_init(_pvec, 0);

Re: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

2005-01-31 Thread Con Kolivas
Jack O'Quin wrote:
The fact that the results did improve with the 90% setting suggests
that there may be a bug in your throttling or time accounting.  The
DSP load for this test should hover around 50% when things are working
properly.  It should never hit a 70% limit, not even momentarily.  The
background compile should not affect that, either.
Something seems to be causing scheduling delays when the sound card
interrupt causes jackd to become runnable.  Ingo's nice(-20) patches
seem to have the same problem, but his RLIMIT_RT_CPU version does not.
Good work. Looks like you're probably right about the accounting. It may 
be as simple as the fact that it is on the timer tick that we're getting 
rescheduled and this ends up being accounted as more since the 
accounting happens only at the scheduler tick. A test run setting 
iso_cpu at 100% should tell you if it's accounting related - however the 
RLIMIT_RT_CPU patch is accounted in a similar way so I'm not sure there 
isn't another bug hanging around. I'm afraid on my hardware it has been 
behaving just like SCHED_FIFO for some time which is why I've been 
hanging on your results. You're not obliged to do anything (obviously), 
but the 100% run should help discriminate where the problem is.

Since I've come this far with the code I'll have another look for any 
other obvious bugs.

Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] shared subtrees

2005-01-31 Thread Ram
On Fri, 2005-01-28 at 14:31, Mike Waychison wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Al Viro wrote:
> 
> > OK, here comes the first draft of proposed semantics for subtree
> > sharing.  What we want is being able to propagate events between
> > the parts of mount trees.  Below is a description of what I think
> > might be a workable semantics; it does *NOT* describe the data
> > structures I would consider final and there are considerable
> > areas where we still need to figure out the right behaviour.
> > 
> 
> Okay, I'm not convinced that shared subtrees as proposed will work well
> with autofs.
> 
> The idea discussed off-line was this:
> 
> When you install an autofs mountpoint, on say /home, a daemon is started
> to service the requests.  As far as the admin is concerned, an fs is
> mounted in the current namespace, call it namespaceA.  The daemon
> actually runs in it's one private namespace: call it namespaceB.
> namespaceB receives a new autofs filesystem: call it autofsB.  autofsB
> is in it's own p-node.  namespaceA gets an autofsA on /home as well, and
> autofsA is 'owned' by autofsB's p-node.

Mike, multiple parsing through the problem definition, still did not
make the problem clear. What problem is autofs trying to solve using
namespaces?

My guess is you dont want to see a automount taking place in namespaceA,
when a automount takes place in namespaceB, even though
the automount-point is in a shared subtree?

Sorry don't understand automount's requirement in the first place,
RP

> 
> So:
 ..snip...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] sched - Implement priority and fifo support for SCHED_ISO

2005-01-31 Thread Jack O'Quin
> Jack O'Quin wrote:
>> The corrected version works noticeably better, but still nowhere near
>> as well as SCHED_FIFO.  The first run had a cluster of really bad
>> xruns.  The second and third were much better, but still with numerous
>> small xruns.
>>
>>   http://www.joq.us/jack/benchmarks/sched-iso-fix/
>>
>> With a compile running in the background it was a complete failure.
>> Some kind of big xrun storm triggered a collapse on every attempt.
>>
>>   http://www.joq.us/jack/benchmarks/sched-iso-fix+compile/
>>
>> The summary statistics are mixed.  The delay_max is noticeably better
>> than before, but still much worse than SCHED_FIFO.  But, the xruns are
>> really bad news...

Con Kolivas <[EMAIL PROTECTED]> writes:
> Believe it or not these look like good results to me. Your XRUNS are
> happening when the DSP load is >70% which is the iso_cpu % cutoff. Try
> setting the iso_cpu to 90%
>
> echo 90 > /proc/sys/kernel/iso_cpu

I ran them again with that setting.  But, don't forget the large
number of xruns before, even running without the compiles in the
background.  There are still way too many of those, although the third
run was clean.  If you can get them all to work like that, we'll
really have something.

  http://www.joq.us/jack/benchmarks/sched-iso-fix.90

With a compile running in the background, the entire run did not fail
completely as it had at 70%.  But there are still way too many xruns.

  http://www.joq.us/jack/benchmarks/sched-iso-fix.90+compile

I moved a bunch of directories testing older prototypes to a .old
subdirectory, they no longer clutter up the summary statistics.

  http://www.joq.us/jack/benchmarks/.SUMMARY

The fact that the results did improve with the 90% setting suggests
that there may be a bug in your throttling or time accounting.  The
DSP load for this test should hover around 50% when things are working
properly.  It should never hit a 70% limit, not even momentarily.  The
background compile should not affect that, either.

Something seems to be causing scheduling delays when the sound card
interrupt causes jackd to become runnable.  Ingo's nice(-20) patches
seem to have the same problem, but his RLIMIT_RT_CPU version does not.

This is still not working well enough for JACK users.  Long and
variable trigger latencies after hardware interrupts are deadly to any
serious realtime application.
-- 
  joq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Prevent NMI oopser

2005-01-31 Thread Marcelo Tosatti
On Tue, Jan 25, 2005 at 11:00:22AM +0300, Vasily Averin wrote:
> cc: Andrey Melnikov <[EMAIL PROTECTED]>
> cc: linux-kernel@vger.kernel.org
> 
> Marcello, Andrey
> 
> I believe this patch is wrong.
> First, it prevent nothing: NMI watchdog is a signal that you wait too
> long with disabled interrupts. Your controller was not answered too
> long, obviously it is a hardware issue.
> Second, you could not call schedule() with io_request_lock spinlock taken.
> 
> You should unlock io_request_lock before msleep, like in latest versions
> of megaraid2 drivers.
> 
> Please fix it.

Andrey, 

Can you please update your patch to unlock io_request_lock before sleeping
and locking after coming back? 

What the driver is doing is indeed wrong.

Thank you.

Is there anybody out there at LSI? 

> Thank you,
>   Vasily Averin, SWSoft Linux Kernel Team
> 
> # ChangeSet
> #   2005/01/19 14:16:32-02:00 [EMAIL PROTECTED]
> #   [PATCH] Prevent NMI oopser from triggering when megaraid2 waits
> #   for abort/reset cmd completion
> #
> #   > We should backport msleep() in 2.4.29-pre1.
> #
> #   Ok, msleep() backported, but driver isn't fixed. This patch
> #   acceptable?
> #
> #   Prevent NMI oopser kill kernel thread when megaraid2 driver waiting
> #   abort or reset command completion.
> #
> #   Signed-off-by: Andrey Melnikov <[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: Kernel bug: mm/rmap.c:483 and related {now 2.6.8}

2005-01-31 Thread Jay Roplekar
>Thanks for giving that a thorough run, memory seems exonerated... yet I
>don't trust this machine at all: have you tried manufacturer diagnostics?

Ouch, that hurts. This is a machine I built myself over three years ago. Ran 
very stably with 2.4.*.  may be  it is the age of the machine.  The  recent 
hardware changes are additions of a dvd writer, a hdd and a pci wireless 
card. Which  seem to work ok until recently. What other diagnostics would 
make sense? 

>> Jan 29 08:25:02 Bad page state at prep_new_page ('X', page c1251ae0)
>> Jan 29 08:25:02 flags:0x2004 mapping:6a00 mapcount:0 count:0

>Again, something I've not seen reported before: mapping:6a00, when
>mapping should be NULL (or at least a pointer into kernel memory).  You
>say message reappeared twice with identical addresses: was that mapping
>the same each time?

Hmm, it is different one time, as shown below.. I guess should have looked 
carefully. Although  it means nothing to me..  FWIW, please  note that in all 
these cases  ndiswrapper (windows driver loader) is being used. Thanks, Jay

Jan 29 08:27:03 localhost kernel: Bad page state at prep_new_page (in process 
'X', page c1253a60)
Jan 29 08:27:03 localhost kernel: flags:0x2004 mapping:6a00 mapcount:0 
count:0

Jan 29 08:27:08 localhost kernel: Bad page state at prep_new_page (in process 
'X', page c12965e0)
Jan 29 08:27:08 localhost kernel: flags:0x2004 mapping:6600 mapcount:0 
count:0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


www.Lotion4you.com now links to you

2005-01-31 Thread Zen Wyoming
Dear Linux Kernel,

I visited your site today and think that the content could be of use to 
some of my customers. I am looking for reputable websites to send my 
visitors to, and was wondering if you would like to exchange links with 
me.Us linking to each other would increase where we stand with the 
search engines, and in addition it would be benificial because of the 
traffic we would be sending each other. The best part is that it would 
be free traffic.

I am currently looking to expand my catagories to 10 sites. I will do 
this by adding the first responses I get. If you are interested in 
trading with me, email me the retorical url where my site is placed. I 
will then add your url within 24 hours. Please email me any catagory 
name you want your link to be placed in. If its not already on my site, 
I will create it for you. Please contact me if you have any other 
busieness suggestions or ideas on how we could make a partnership 
between our businesses. 

http://www.Lotion4you.com

Indoor Tanning Lotion

Free Shipping. All Indoor Tanning Lotion is 50-75% Under Retail.

Please email me the link once you have linked to my site. 

Best regards, 

Zen Wyoming
www.Lotion4you.com


Phone: (316)516.4642







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


Re: [ACPI] [BKPATCH] ACPI for 2.4

2005-01-31 Thread Sergio Monteiro Basto
Hi, cool 

May I suggest a little more debug with this 2nd version of the patch in
attach ?.

I get dmesg | grep -i via 
1. Disabling VIA memory write queue (PCI ID 0305, rev 80): [55] 3c & 1f -> 1c
2. PCI: Via IRQ fixup
3. Applying quirk_via_acpi.
4. Applying VIA southbridge workaround. (VIA Apollo KT133 needs PCI latency 
patch, applying quirk_vialatency).
5. PCI: Disabling Via external APIC routing

agpgart: Detected Via Apollo Pro KT133 chipset
VP_IDE: VIA vt82c686b (rev 42) IDE UDMA100 controller on pci00:07.1
parport_pc: Via 686A parallel port: io=0x378

1- the north bridge patch on arch/i386/kernel/pci-pc.c
2- the new patch
3- If ISA doesn't support PCI_INTERRUPT_LINE  ?
* FIXME: it is questionable that quirk_via_acpi
* is needed.  It shows up as an ISA bridge, and does not
* support the PCI_INTERRUPT_LINE register at all.  Therefore
* it seems like setting the pci_dev's 'irq' to the
* value of the ACPI SCI interrupt is only done for convenience.
*  -jgarzik

4- The general quirk, quirks all devices. Don't try to disable it, it
can damage the computer.
5- has a
/* TODO: When we have device-specific interrupt routers,
* this code will go away from quirks.
*/
but only with CONFIG_X86_IO_APIC, looks to me with no sense because, I
suppose I don't have any IO_APIC just one local apic.


thanks,


On Mon, 2005-01-31 at 03:32 -0500, Len Brown wrote:
> Hi Marcelo, please do a 
> 
>   bk pull bk://linux-acpi.bkbits.net/to-marcelo
> 
> thanks,
> -Len
> 
> ps. a plain patch is also available here:
> ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.4.29/acpi-20040326-2.4.29.diff.gz
> 
> This will update the following files:
> 
>  arch/i386/kernel/pci-irq.c   |4 ++--
>  arch/x86_64/kernel/pci-irq.c |4 ++--
>  drivers/acpi/pci_irq.c   |4 
>  drivers/pci/quirks.c |   30 +-
>  4 files changed, 13 insertions(+), 29 deletions(-)
> 
> through these ChangeSets:
> 
> <[EMAIL PROTECTED]> (05/01/26 1.1499.5.2)
>[ACPI] via interrupt quirk fix from 2.6
>http://bugzilla.kernel.org/show_bug.cgi?id=3319
>
>Signed-off-by: David Shaohua Li <[EMAIL PROTECTED]>
>Signed-off-by: Len Brown <[EMAIL PROTECTED]
> 
> 
> 
> 
> 
> 
> ---
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> ___
> Acpi-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
-- 
Sérgio M.B.
--- a/arch/i386/kernel/pci-irq.c	2005-01-31 03:29:46 -05:00
+++ b/arch/i386/kernel/pci-irq.c	2005-01-31 03:29:46 -05:00
@@ -1120,7 +1120,7 @@
 void pcibios_enable_irq(struct pci_dev *dev)
 {
 	u8 pin;
-	extern int interrupt_line_quirk;
+	extern int via_interrupt_line_quirk;
  	struct pci_dev *temp_dev;
 	
 	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
@@ -1173,7 +1173,7 @@
 	}
 	/* VIA bridges use interrupt line for apic/pci steering across
 	   the V-Link */
-	else if (interrupt_line_quirk)
+	else if (via_interrupt_line_quirk)
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq & 15);
 		
 }
--- a/arch/x86_64/kernel/pci-irq.c	2005-01-31 03:29:46 -05:00
+++ b/arch/x86_64/kernel/pci-irq.c	2005-01-31 03:29:46 -05:00
@@ -742,7 +742,7 @@
 void pcibios_enable_irq(struct pci_dev *dev)
 {
 		u8 pin;
-	extern int interrupt_line_quirk;
+	extern int via_interrupt_line_quirk;
 
 		pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
 	if (pin && !pcibios_lookup_irq(dev, 1) && !dev->irq) {
@@ -762,6 +762,6 @@
 	}
 	/* VIA bridges use interrupt line for apic/pci steering across
 	   the V-Link */
-	else if (interrupt_line_quirk)
+	else if (via_interrupt_line_quirk)
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
 }
--- a/drivers/acpi/pci_irq.c	2005-01-31 03:29:46 -05:00
+++ b/drivers/acpi/pci_irq.c	2005-01-31 03:29:46 -05:00
@@ -335,6 +335,7 @@
 {
 	int			irq = 0;
 	u8			pin = 0;
+	extern int via_interrupt_line_quirk;
 
 	ACPI_FUNCTION_TRACE("acpi_pci_irq_enable");
 
@@ -382,6 +383,9 @@
 			return_VALUE(0);
 		}
  	}
+
+	if (via_interrupt_line_quirk)
+		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
 
 	dev->irq = irq;
 
--- linux-2.4.29f/drivers/pci/quirks.c.orig	2005-02-01 00:42:25.0 +
+++ linux-2.4.29f/drivers/pci/quirks.c	2005-02-01 00:59:26.0 +
@@ -143,7 +143,7 @@
 	busarb &= ~(1<<5);
 	busarb |= (1<<4);
 	pci_write_config_byte(dev, 0x76, busarb);
-	printk(KERN_INFO "Applying VIA southbridge workaround.\n");
+	printk(KERN_INFO "Applying VIA southbridge workaround. (VIA Apollo KT133 needs PCI latency patch, applying quirk_vialatency).\n");
 }
 
 /*
@@ -207,6 +207,7 @@
 	struct resource *r = >resource[0];
 
 	if ((r->start & 0x3ff) || r->end != r->start + 

Re: [RFC] shared subtrees

2005-01-31 Thread Ian Kent
On Mon, 31 Jan 2005, Mike Waychison wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Sorry for the bad quoting below:
> 
> [EMAIL PROTECTED] wrote:
> > On Fri, 28 Jan 2005, Mike Waychison wrote:
> > 
> > Al Viro wrote:
> > 
>  OK, here comes the first draft of proposed semantics for subtree
>  sharing.  What we want is being able to propagate events between
>  the parts of mount trees.  Below is a description of what I think
>  might be a workable semantics; it does *NOT* describe the data
>  structures I would consider final and there are considerable
>  areas where we still need to figure out the right behaviour.
> 
> > 
> > Okay, I'm not convinced that shared subtrees as proposed will work well
> > with autofs.
> > 
> > 
> >> OK. I've read the thread but haven't digested it so you'll have to put
> >> up with some stupid questions.
> > 
> > 
> > The idea discussed off-line was this:
> > 
> > When you install an autofs mountpoint, on say /home, a daemon is started
> > to service the requests.  As far as the admin is concerned, an fs is
> > mounted in the current namespace, call it namespaceA.  The daemon
> > actually runs in it's one private namespace: call it namespaceB.
> > namespaceB receives a new autofs filesystem: call it autofsB.  autofsB
> > is in it's own p-node.  namespaceA gets an autofsA on /home as well, and
> > autofsA is 'owned' by autofsB's p-node.
> > 
> > So:
> > 
> > autofsB -> autofsB
> > and
> > autofsB -> autofsA
> > 
> > Effectively, namespaceA has a private instance of autofsB in its tree.
> > 
> > The problem is this:
> > 
> > Assume /home/mikew is accessed in namespaceA.  The daemon running in
> > namespaceB gets the event, and mounts an nfs vfsmount on autofsB.  This
> > event is propagated back to autofsA.
> > 
> > 
> >> Which condition (or action) in the definition implies
> > 
> >> autofsB -> autofsA
> > 
> 
> autofsB -> autofsA indicates that mount events are propagated from
> autofsB to autofsA.
> 
> Eg: if you have two mounts (A, B) in the same p-node, then
> 
> A -> B
> and
> B -> A
> 
> By definition, a mountpoint (A) alone in a one element p-node has the
> property:
> 
> A -> A
> 
> Which doesn't mean much, other than to show that A is in a p-node.
> 
> If you have a p-node p' owned by p-node p, then all mountpoints i' in p'
> will have the following relationship with all mountpoints i in p:
> 
> i -> i'
> 
> but not the reverse (one-way relationship).

Sorry guys.

I've gota spend some time to get into this.
It is really important.

> 
> > 
> > (Problem 1: how do you block access to /home/mikew in namespaceA?)
> > 
> > Next, a CLONE_NS is done in namespaceA, creating namespaceA'.  the
> > homedir on /home/mikew is also copied.
> > 
> > Now, in namespaceA', what happens when a user umount's /home/mikew?  We
> > haven't yet determined how to handle umount event propagation, but it
> > appears likely that it will be *a hard thing to do*.
> > 
> > 
> >> No I haven't spent enough time on the RFC buy into this one.
> >> So I'll just say it looks like something is missing in this argument.
> > 
> >> Perhaps the later is namespaceC?
> > 
> 
> Sure, it doesn't matter, namespaceA' is an arbitrary name.
> 
> HTH,
> 
> - --
> Mike Waychison
> Sun Microsystems, Inc.
> 1 (650) 352-5299 voice
> 1 (416) 202-8336 voice
> 
> ~~
> NOTICE:  The opinions expressed in this email are held by me,
> and may not represent the views of Sun Microsystems, Inc.
> ~~
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFB/miHdQs4kOxk3/MRArCsAJ9PxyxE7crSRk4R0OMB4yppH10wpQCfeQO8
> qk6kcExaN7rzJOi4KoRyXoY=
> =VvFb
> -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: 2.6.11-rc2-mm2

2005-01-31 Thread Jim Nelson
Laurent Riffard wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 31.01.2005 22:15, Andre Eisenbach a écrit :
| Andrew,
|
| My PCMCIA slot (yenta_socket) doesn't work anymore with
| 2.6.11-rc2-m2. See the dmesg output below. It works fine with
| 2.6.11-rc1-mm1.
|
| Let me know if you need any additional information.
|
| Thanks,
| Andre
|
| --- snipp ---
|
| Linux Kernel Card Services
|   options:  [pci] [cardbus] [pm]
| kobject_register failed for pcmcia_core (-17)
|  [] kobject_register+0x5b/0x70
|  [] mod_sysfs_setup+0x50/0xb0
|  [] load_module+0x959/0xaa0
|  [] sys_init_module+0x5b/0x1a0
|  [] sysenter_past_esp+0x52/0x75
| rsrc_nonstatic: Unknown symbol release_cis_mem
| rsrc_nonstatic: Unknown symbol pcmcia_socket_list
| rsrc_nonstatic: Unknown symbol pccard_validate_cis
| rsrc_nonstatic: Unknown symbol destroy_cis_cache
| rsrc_nonstatic: Unknown symbol pcmcia_socket_list_rwsem
| yenta_socket: Unknown symbol dead_socket
| yenta_socket: Unknown symbol pcmcia_register_socket
| yenta_socket: Unknown symbol pcmcia_socket_dev_resume
| yenta_socket: Unknown symbol pcmcia_parse_events
| yenta_socket: Unknown symbol pcmcia_socket_dev_suspend
| yenta_socket: Unknown symbol pccard_nonstatic_ops
| yenta_socket: Unknown symbol pcmcia_unregister_socket
| kobject_register failed for pcmcia_core (-17)
|  [] kobject_register+0x5b/0x70
|  [] mod_sysfs_setup+0x50/0xb0
|  [] load_module+0x959/0xaa0
|  [] sys_init_module+0x5b/0x1a0
|  [] sysenter_past_esp+0x52/0x75
| pcmcia: Unknown symbol pcmcia_get_socket
| pcmcia: Unknown symbol pcmcia_get_window
| pcmcia: Unknown symbol pcmcia_suspend_card
| pcmcia: Unknown symbol pcmcia_replace_cis
[snip]
I had the same type of problem while loading modules.
Fixed this evening by the following patch :
http://marc.theaimsgroup.com/?l=linux-kernel=110715631504335
- --
laurent
I can confirm that patch took care of a similar kobject_register failure in tulip 
on my test machine.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] mm/rmap.c: update the email address of Rik van Riel

2005-01-31 Thread Adrian Bunk
This patch updates the email address of Rik van Riel in mm/rmap.c from a 
bouncing address to his current address.

This patch was already ACK'ed by Rik van Riel.

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

--- linux-2.6.11-rc2-mm2-full/mm/rmap.c.old 2005-01-31 22:47:25.0 
+0100
+++ linux-2.6.11-rc2-mm2-full/mm/rmap.c 2005-01-31 22:48:13.0 +0100
@@ -1,7 +1,7 @@
 /*
  * mm/rmap.c - physical to virtual reverse mappings
  *
- * Copyright 2001, Rik van Riel <[EMAIL PROTECTED]>
+ * Copyright 2001, Rik van Riel <[EMAIL PROTECTED]>
  * Released under the General Public License (GPL).
  *
  * Simple, low overhead reverse mapping scheme.
@@ -11,7 +11,7 @@
  * the anon methods track anonymous pages, and
  * the file methods track pages belonging to an inode.
  *
- * Original design by Rik van Riel <[EMAIL PROTECTED]> 2001
+ * Original design by Rik van Riel <[EMAIL PROTECTED]> 2001
  * File methods by Dave McCracken <[EMAIL PROTECTED]> 2003, 2004
  * Anonymous methods by Andrea Arcangeli <[EMAIL PROTECTED]> 2004
  * Contributions by Hugh Dickins <[EMAIL PROTECTED]> 2003, 2004


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.11-rc2] vmlinux: add SETUP_DESC() to describe __setup() options

2005-01-31 Thread Rusty Russell
On Mon, 2005-01-31 at 17:50 -0600, Matt Domsch wrote:
> __setup() options are traditionally documented in
> Documentation/kernel-parameters.txt.  However, it would be nice if
> they could be documented alongside the implementation, similar to
> MODULE_PARM_DESC() fields for modules, and if 'modinfo vmlinux' could
> report such.
> 
> Patch below adds a new macro, SETUP_DESC(), which can be used to
> document the use cases of __setup() options.  A usage example in
> kernel/audit.c is provided as well.

I don't want to encourage the proliferation of __setup, and prefer
module_parm() for new code.  __setup() is good for certain fundamentals,
but the namespace and parsing help given by module_parm() usually makes
it a better choice.

That said, I don't have a particular issue with this.
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] bio-set patch on latest bk source tree

2005-01-31 Thread Dave Olien

Hi, Jens,

I sent you a patch for review about a week ago.  Here is that same
patch, applied to the latest bk kernel.  Thanks in advance for the review

Dave Olien


= drivers/md/dm.c 1.61 vs edited =
--- 1.61/drivers/md/dm.c2005-01-25 13:50:21 -08:00
+++ edited/drivers/md/dm.c  2005-01-31 11:37:27 -08:00
@@ -96,10 +96,16 @@ struct mapped_device {
 static kmem_cache_t *_io_cache;
 static kmem_cache_t *_tio_cache;
 
+static struct bio_set *dm_set;
+
 static int __init local_init(void)
 {
int r;
 
+   dm_set = bioset_create(512, 512, 1);
+   if (!dm_set)
+   return -ENOMEM;
+
/* allocate a slab for the dm_ios */
_io_cache = kmem_cache_create("dm_io",
  sizeof(struct dm_io), 0, 0, NULL, NULL);
@@ -133,6 +139,8 @@ static void local_exit(void)
kmem_cache_destroy(_tio_cache);
kmem_cache_destroy(_io_cache);
 
+   bioset_free(dm_set);
+   
if (unregister_blkdev(_major, _name) < 0)
DMERR("devfs_unregister_blkdev failed");
 
@@ -393,7 +401,7 @@ static struct bio *split_bvec(struct bio
struct bio *clone;
struct bio_vec *bv = bio->bi_io_vec + idx;
 
-   clone = bio_alloc(GFP_NOIO, 1);
+   clone = bio_alloc_bs(GFP_NOIO, 1, dm_set);
*clone->bi_io_vec = *bv;
 
clone->bi_sector = sector;
= drivers/md/dm-io.c 1.4 vs edited =
--- 1.4/drivers/md/dm-io.c  2005-01-25 13:50:21 -08:00
+++ edited/drivers/md/dm-io.c   2005-01-31 11:45:42 -08:00
@@ -12,191 +12,7 @@
 #include 
 #include 
 
-#define BIO_POOL_SIZE 256
-
-
-/*-
- * Bio set, move this to bio.c
- *---*/
-#define BV_NAME_SIZE 16
-struct biovec_pool {
-   int nr_vecs;
-   char name[BV_NAME_SIZE];
-   kmem_cache_t *slab;
-   mempool_t *pool;
-   atomic_t allocated; /* FIXME: debug */
-};
-
-#define BIOVEC_NR_POOLS 6
-struct bio_set {
-   char name[BV_NAME_SIZE];
-   kmem_cache_t *bio_slab;
-   mempool_t *bio_pool;
-   struct biovec_pool pools[BIOVEC_NR_POOLS];
-};
-
-static void bio_set_exit(struct bio_set *bs)
-{
-   unsigned i;
-   struct biovec_pool *bp;
-
-   if (bs->bio_pool)
-   mempool_destroy(bs->bio_pool);
-
-   if (bs->bio_slab)
-   kmem_cache_destroy(bs->bio_slab);
-
-   for (i = 0; i < BIOVEC_NR_POOLS; i++) {
-   bp = bs->pools + i;
-   if (bp->pool)
-   mempool_destroy(bp->pool);
-
-   if (bp->slab)
-   kmem_cache_destroy(bp->slab);
-   }
-}
-
-static void mk_name(char *str, size_t len, const char *prefix, unsigned count)
-{
-   snprintf(str, len, "%s-%u", prefix, count);
-}
-
-static int bio_set_init(struct bio_set *bs, const char *slab_prefix,
-unsigned pool_entries, unsigned scale)
-{
-   /* FIXME: this must match bvec_index(), why not go the
-* whole hog and have a pool per power of 2 ? */
-   static unsigned _vec_lengths[BIOVEC_NR_POOLS] = {
-   1, 4, 16, 64, 128, BIO_MAX_PAGES
-   };
-
-
-   unsigned i, size;
-   struct biovec_pool *bp;
-
-   /* zero the bs so we can tear down properly on error */
-   memset(bs, 0, sizeof(*bs));
-
-   /*
-* Set up the bio pool.
-*/
-   snprintf(bs->name, sizeof(bs->name), "%s-bio", slab_prefix);
-
-   bs->bio_slab = kmem_cache_create(bs->name, sizeof(struct bio), 0,
-SLAB_HWCACHE_ALIGN, NULL, NULL);
-   if (!bs->bio_slab) {
-   DMWARN("can't init bio slab");
-   goto bad;
-   }
-
-   bs->bio_pool = mempool_create(pool_entries, mempool_alloc_slab,
- mempool_free_slab, bs->bio_slab);
-   if (!bs->bio_pool) {
-   DMWARN("can't init bio pool");
-   goto bad;
-   }
-
-   /*
-* Set up the biovec pools.
-*/
-   for (i = 0; i < BIOVEC_NR_POOLS; i++) {
-   bp = bs->pools + i;
-   bp->nr_vecs = _vec_lengths[i];
-   atomic_set(>allocated, 1); /* FIXME: debug */
-
-
-   size = bp->nr_vecs * sizeof(struct bio_vec);
-
-   mk_name(bp->name, sizeof(bp->name), slab_prefix, i);
-   bp->slab = kmem_cache_create(bp->name, size, 0,
-SLAB_HWCACHE_ALIGN, NULL, NULL);
-   if (!bp->slab) {
-   DMWARN("can't init biovec slab cache");
-   goto bad;
-   }
-
-   if (i >= scale)
-   pool_entries >>= 1;
-
-   bp->pool = mempool_create(pool_entries, mempool_alloc_slab,
- mempool_free_slab, bp->slab);
-   if (!bp->pool) {
-  

Re: CONFIG_THERM_PM72 is missing from .config from recent kernels (2.6.10, 2.6.11)

2005-01-31 Thread Maurice Volaski
Maurice Volaski wrote:
CONFIG_THERM_PM72 is required for thermal management in at least 
Macs, most notably the PowerMac G5. Without it, the computer will 
run its fans at the max and is very loud.

It's missing from .config in at least a few releases of recent 
kernels (2.6.10, 2.6.11).

Does anyone know why?
Did you enable/select it?
It's not on by default (in 2.6.11-rc2).
First you need to enable this one:
config I2C_KEYWEST
tristate "Powermac Keywest I2C interface"
depends on I2C && PPC_PMAC
and then this one:
config THERM_PM72
tristate "Support for thermal management on PowerMac G5"
depends on I2C && I2C_KEYWEST && PPC_PMAC64
Thanks.
This is probably something for the config program designers, but 
options like these shouldn't never be hidden. They should always be 
available. If their prerequisites are not met, then it should reject 
change and throw up an explanation message, namely, the above.
--

Maurice Volaski, [EMAIL PROTECTED]
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] IDE: remove WAIT_READY dependency on APM

2005-01-31 Thread Adrian Bunk
On the one hand APM isn't enabled on all laptops.
On the other hand, this also affects regular PCs with APM support (or
using a distribution kernel with APM support).

The time for the !APM case was already increased from 30msec in 2.4 .
Isn't there a timeout that is suitable for all cases?

Alan Cox answered:
> The five seconds should be just fine for all cases. The smaller value
> with no
> power manglement should help speed up recovery however. It probably
> doesn't belong CONFIG_APM now ACPI and friends are involved either.

Until someone has a real good solution (consider e.g. that most PC users 
might have ACPI support enabled), this patch unconditionally sets 
WAIT_READY to 5 seconds.

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

---

This patch as already sent on:
- 11 Dec 2004
- 17 Jan 2005

--- linux-2.6.10-rc2-mm4-full/include/linux/ide.h.old   2004-12-11 
18:11:20.0 +0100
+++ linux-2.6.10-rc2-mm4-full/include/linux/ide.h   2004-12-11 
18:11:32.0 +0100
@@ -187,11 +187,7 @@
  * Timeouts for various operations:
  */
 #define WAIT_DRQ   (HZ/10) /* 100msec - spec allows up to 20ms */
-#if defined(CONFIG_APM) || defined(CONFIG_APM_MODULE)
 #define WAIT_READY (5*HZ)  /* 5sec - some laptops are very slow */
-#else
-#define WAIT_READY (HZ/10) /* 100msec - should be instantaneous */
-#endif /* CONFIG_APM || CONFIG_APM_MODULE */
 #define WAIT_PIDENTIFY (10*HZ) /* 10sec  - should be less than 3ms (?), if all 
ATAPI CD is closed at boot */
 #define WAIT_WORSTCASE (30*HZ) /* 30sec  - worst case when spinning up */
 #define WAIT_CMD   (10*HZ) /* 10sec  - maximum wait for an IRQ to happen */

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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][I2C] Marvell mv64xxx i2c driver

2005-01-31 Thread Greg KH
On Mon, Jan 31, 2005 at 11:41:28AM -0700, Mark A. Greer wrote:
> Greg KH wrote:
> 
> >On Tue, Jan 25, 2005 at 06:26:45PM -0700, Mark A. Greer wrote:
> > 
> >
> >>+static inline void
> >>+mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status)
> >>   
> >>
> >
> >This is a much too big of a function to be "inline".  Please change it.
> >Same for your other inline functions, that's not really needed, right?
> >
> > 
> >
> >>+{
> >>+   pr_debug("mv64xxx_i2c_fsm: ENTER--state: %d, status: 0x%x\n",
> >>+   drv_data->state, status);
> >>   
> >>
> >
> >Please use the dev_* calls instead.  It gives you an accurate
> >description of the specific device that emits the messages.  Also use it
> >for all of the printk() calls in the driver too.
> >
> >thanks,
> >
> >greg k-h
> >
> 
> Certainly.  I already posted this [incremental] patch based on your 
> previous comments, 
> http://www.ussg.iu.edu/hypermail/linux/kernel/0501.3/0941.html.  Is that 
> better?

How about a whole new patch that I could apply?  That would be better :)

thanks,

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


[PATCH][PPC32] Add PPC440SP and Luan ref board support

2005-01-31 Thread Matt Porter
Adds support for the IBM/AMCC PPC440SP SoC. Also adds support for
the Luan reference board that has a 440SP on it.

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

diff -Nru a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
--- a/arch/ppc/boot/simple/Makefile 2005-01-31 17:03:53 -07:00
+++ b/arch/ppc/boot/simple/Makefile 2005-01-31 17:03:53 -07:00
@@ -66,6 +66,12 @@
  end-$(CONFIG_EBONY)   := ebony
   entrypoint-$(CONFIG_EBONY)   := 0x0100
 
+  zimage-$(CONFIG_LUAN):= zImage-TREE
+zimageinitrd-$(CONFIG_LUAN):= zImage.initrd-TREE
+ end-$(CONFIG_LUAN):= luan
+  entrypoint-$(CONFIG_LUAN):= 0x0100
+ extra.o-$(CONFIG_LUAN):= pibs.o
+
   zimage-$(CONFIG_OCOTEA)  := zImage-TREE
 zimageinitrd-$(CONFIG_OCOTEA)  := zImage.initrd-TREE
  end-$(CONFIG_OCOTEA)  := ocotea
diff -Nru a/arch/ppc/boot/simple/pibs.c b/arch/ppc/boot/simple/pibs.c
--- a/arch/ppc/boot/simple/pibs.c   2005-01-31 17:03:54 -07:00
+++ b/arch/ppc/boot/simple/pibs.c   2005-01-31 17:03:54 -07:00
@@ -1,5 +1,5 @@
 /*
- * 2004 (c) MontaVista, Software, Inc.  This file is licensed under
+ * 2004-2005 (c) MontaVista, Software, Inc.  This file is licensed under
  * the terms of the GNU General Public License version 2.  This program
  * is licensed "as is" without any warranty of any kind, whether express
  * or implied.
@@ -10,7 +10,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 extern unsigned long decompress_kernel(unsigned long load_addr, int num_words,
   unsigned long cksum);
@@ -89,13 +89,15 @@
 
decompress_kernel(load_addr, num_words, cksum);
 
-   mac64 = simple_strtoull((char *)OCOTEA_PIBS_MAC_BASE, 0, 16);
+   mac64 = simple_strtoull((char *)PIBS_MAC_BASE, 0, 16);
memcpy(hold_residual->bi_enetaddr, (char *)+2, 6);
-   mac64 = simple_strtoull((char 
*)(OCOTEA_PIBS_MAC_BASE+OCOTEA_PIBS_MAC_OFFSET), 0, 16);
+#ifdef CONFIG_440GX
+   mac64 = simple_strtoull((char *)(PIBS_MAC_BASE+PIBS_MAC_OFFSET), 0, 16);
memcpy(hold_residual->bi_enet1addr, (char *)+2, 6);
-   mac64 = simple_strtoull((char 
*)(OCOTEA_PIBS_MAC_BASE+OCOTEA_PIBS_MAC_OFFSET*2), 0, 16);
+   mac64 = simple_strtoull((char *)(PIBS_MAC_BASE+PIBS_MAC_OFFSET*2), 0, 
16);
memcpy(hold_residual->bi_enet2addr, (char *)+2, 6);
-   mac64 = simple_strtoull((char 
*)(OCOTEA_PIBS_MAC_BASE+OCOTEA_PIBS_MAC_OFFSET*3), 0, 16);
+   mac64 = simple_strtoull((char *)(PIBS_MAC_BASE+PIBS_MAC_OFFSET*3), 0, 
16);
memcpy(hold_residual->bi_enet3addr, (char *)+2, 6);
+#endif
return (void *)hold_residual;
 }
diff -Nru a/arch/ppc/configs/luan_defconfig b/arch/ppc/configs/luan_defconfig
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/configs/luan_defconfig   2005-01-31 17:03:54 -07:00
@@ -0,0 +1,668 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.11-rc2
+# Mon Jan 31 16:26:31 2005
+#
+CONFIG_MMU=y
+CONFIG_GENERIC_HARDIRQS=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_HAVE_DEC_LOCK=y
+CONFIG_PPC=y
+CONFIG_PPC32=y
+CONFIG_GENERIC_NVRAM=y
+
+#
+# Code maturity level options
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_CLEAN_COMPILE=y
+CONFIG_BROKEN_ON_SMP=y
+
+#
+# General setup
+#
+CONFIG_LOCALVERSION=""
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+# CONFIG_POSIX_MQUEUE is not set
+# CONFIG_BSD_PROCESS_ACCT is not set
+CONFIG_SYSCTL=y
+# CONFIG_AUDIT is not set
+CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_HOTPLUG is not set
+CONFIG_KOBJECT_UEVENT=y
+# CONFIG_IKCONFIG is not set
+CONFIG_EMBEDDED=y
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_FUTEX=y
+CONFIG_EPOLL=y
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_SHMEM=y
+CONFIG_CC_ALIGN_FUNCTIONS=0
+CONFIG_CC_ALIGN_LABELS=0
+CONFIG_CC_ALIGN_LOOPS=0
+CONFIG_CC_ALIGN_JUMPS=0
+# CONFIG_TINY_SHMEM is not set
+
+#
+# Loadable module support
+#
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+CONFIG_OBSOLETE_MODPARM=y
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_KMOD=y
+
+#
+# Processor
+#
+# CONFIG_6xx is not set
+# CONFIG_40x is not set
+CONFIG_44x=y
+# CONFIG_POWER3 is not set
+# CONFIG_POWER4 is not set
+# CONFIG_8xx is not set
+# CONFIG_E500 is not set
+CONFIG_BOOKE=y
+CONFIG_PTE_64BIT=y
+CONFIG_PHYS_64BIT=y
+# CONFIG_MATH_EMULATION is not set
+# CONFIG_CPU_FREQ is not set
+CONFIG_4xx=y
+
+#
+# IBM 4xx options
+#
+# CONFIG_EBONY is not set
+CONFIG_LUAN=y
+# CONFIG_OCOTEA is not set
+CONFIG_440SP=y
+CONFIG_440=y
+CONFIG_IBM_OCP=y
+CONFIG_IBM_EMAC4=y
+# CONFIG_PPC4xx_DMA is not set
+CONFIG_PPC_GEN550=y
+# CONFIG_PM is not set
+CONFIG_NOT_COHERENT_CACHE=y
+
+#
+# Platform options
+#
+# CONFIG_PC_KEYBOARD is not set
+# CONFIG_SMP is not set
+# CONFIG_PREEMPT is not set
+# CONFIG_HIGHMEM is not set

Re: 2.6.11-rc1-mm2

2005-01-31 Thread Ed Tomlinson
On Thursday 20 January 2005 00:38, Andrew Morton wrote:
> - This kernel isn't particularly well-tested, sorry.  I've been a bit tied
>   up with other stuff.

I recently switched my main box to a x86_64 box and installed the unofficial
debian 'true64' port on it.  I have been running 11-rc2 (with the aa oom 
patches)
with no real problems.  I decided to try 11-rc2-mm2. 

The first time (with a serial console active) it ended with a panic.  When I 
enabled
a serial console it stalled.  I used alt+sysrq+T and then rebooted.  Here is 
the 
log.  There are no extra patches on top of mm2.  I compiled using gcc 3.4, with
a .config based on 11-rc2 using oldconfig.

Ed Tomlinson

Bootdata ok (command line is root=/dev/hda3 ro console=tty0 console=ttyS0,38400)
Linux version 2.6.11-rc2-mm2 ([EMAIL PROTECTED]) (gcc version 3.4.4 20041218 
(prerelease) (Debian 3.4.3-7)) #1 Sun Jan 30 09:18:40 EST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f800 (usable)
 BIOS-e820: 0009f800 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 1fff (usable)
 BIOS-e820: 1fff - 1fff3000 (ACPI NVS)
 BIOS-e820: 1fff3000 - 2000 (ACPI data)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fef0 (reserved)
 BIOS-e820: fefffc00 - ff00 (reserved)
 BIOS-e820:  - 0001 (reserved)
Nvidia board detected. Ignoring ACPI timer override.
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Checking aperture...
CPU 0: aperture @ e000 size 128 MB
Built 1 zonelists
Initializing CPU#0
Kernel command line: root=/dev/hda3 ro console=tty0 console=ttyS0,38400
PID hash table entries: 2048 (order: 11, 65536 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 1808.838 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Memory: 510272k/524224k available (2163k kernel code, 13180k reserved, 1393k 
data, 140k init)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 256 (order: 0, 4096 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: AMD Athlon(tm) 64 Processor 2800+ stepping 0a
Using local APIC NMI watchdog using perfctr0
Using local APIC timer interrupts.
Detected 12.561 MHz APIC timer.
NET: Registered protocol family 16
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050125
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Power Resource [ISAV] (on)
ACPI: PCI Interrupt Link [LNK1] (IRQs<7>Losing some ticks... checking if CPU 
frequency changed.
 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 6 *7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBA] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LUBB] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LUB2] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSID] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [APC1] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APC2] (IRQs *17), disabled.
ACPI: PCI Interrupt Link [APC3] (IRQs *18), disabled.
ACPI: PCI Interrupt Link [APC4] (IRQs *19), 

Re: [PATCH] Fix SERIAL_TXX9 dependencies

2005-01-31 Thread Atsushi Nemoto
> On Mon, 31 Jan 2005 21:23:10 +0100, Arnd Bergmann <[EMAIL PROTECTED]> 
> said:
arnd> I just found that the version in -mm2 does not add the Makefile
arnd> change, so you need this patchlet on top. If you haven't redone
arnd> the patch yet, it might be better still to rename the file to
arnd> txx9.o, as serial/serial_* is a bit redundant.

Thank you for Makefile fix.

As for renaming, I think serial/serial_* is not so bad.  If you rename
it and compile as a module, then the module will be called "txx9.ko"
which seems too ambiguous.

---
Atsushi Nemoto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/5] resource: core changes to update u64 to unsigned long

2005-01-31 Thread Greg KH
On Fri, Jan 14, 2005 at 01:32:50PM -0800, Dave Jiang wrote:
> Here's the prink's with the proper cast I think. Should only be change
> in core and driver. The arch patches are fine.

Thanks, I've applied this one, and the other 4 to my bk trees, and they
will show up in the next -mm releases.  After 2.6.11 is out, I'll send
them off to Linus.

Thanks again.

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


question on symbol exports

2005-01-31 Thread Chris Friesen
It appears that in 2.6.9 the ppc64 version of flush_tlb_page() depends 
on two symbols which are not currently exported: the function 
__flush_tlb_pending(), and the per-cpu variable ppc64_tlb_batch.

Is there any particular reason why modules should not be allowed to 
flush the tlb, or is this an oversight?

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


Re: [PATCH] ppc64: Implement a vDSO and use it for signal trampoline

2005-01-31 Thread Benjamin Herrenschmidt

> Also notice that ':=' uses all over. No need to use late evaluation when
> no dynamic references are used ($ $@ etc.).

Hrm... Rusty tells me that you got it backward ;) Anyway, I'll stick
to := for now, it's not really an issue.

Ben.


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


Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

2005-01-31 Thread hui
On Mon, Jan 31, 2005 at 05:29:10PM -0500, Bill Davidsen wrote:
> The problem hasn't changed in a few decades, neither has the urge of 
> developers to make their app look good at the expense of the rest of the 
> system. Been there and done that myself.
> 
> "Back when" we had no good tools except to raise priority and drop 
> timeslice if a process blocked for i/o and vice-versa if it used the 
> whole timeslice. The amzing thing is that it worked reasonably well as 
> long as no one was there who knew how to cook the books the scheduler 
> used. And the user could hold off interrupts for up to 16ms, just to 
> make it worse.

A lot of this scheduling policy work is going to have to be redone as
badly written apps start getting their crap together and as this patch
is more and more pervasive in the general Linux community. What's
happening now is only the beginning of things to come and it'll require
a solid sample application with even more hooks into the kernel before
we'll see the real benefits of this patch. SCHED_FIFO will have to do
until more development happens with QoS style policies.
 
bill

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


Re: [PATCH] sysfs: export the vfs release call of binary attribute

2005-01-31 Thread Greg KH
On Thu, Jan 27, 2005 at 09:34:10PM +0100, Kay Sievers wrote:
> On Thu, Jan 27, 2005 at 09:19:23PM +0100, Kay Sievers wrote:
> > Initialize the allocated bin_attribute structure, otherwise unused fields
> > are pointing to random places.
> 
> Sorry, wrong place for the inititalization.
> 
> Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>

Applied, thanks.

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


Re: [PATCH] pci_proc_domain

2005-01-31 Thread Greg KH
On Mon, Jan 17, 2005 at 07:23:35PM +, Matthew Wilcox wrote:
> 
> There's no need for the architectures to know how to name busses,
> so replace pci_name_bus with pci_proc_domain -- a predicate to allow
> architectures to choose whether domains are included in /proc/bus/pci
> or not.  I've converted all architectures but only tested ia64 and a
> CONFIG_PCI_DOMAINS=n build.

Applied, thanks.

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


[2.6 patch] remove dp83840.h

2005-01-31 Thread Adrian Bunk
On Mon, Jan 31, 2005 at 03:46:07PM -0800, David S. Miller wrote:
> On Tue, 1 Feb 2005 00:41:58 +0100
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
> 
> > dp83840.h is included once but none of the definitions it contains is
> > actually used.
> > 
> > Ralf Baechle wants that it stays as documentation, so this patch moves 
> > it under Documentation/ .
> 
> No, let's kill this thing altogether.  The only driver in the world
> using the CSCONFIG_* defines in there is the sunhme driver and it
> defines it's own macros in drivers/net/sunhme.h  This header is more
> than useless these days.
> 
> The header still exists in older trees and the revision history.
> So people can still get to it there.

OK, patch below

cu
Adrian


<--  snip  -->


dp83840.h is included once but none of the definitions it contains is
actually used.

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

---

 drivers/net/ioc3-eth.c   |1 
 include/linux/dp83840.h  |   41 ---
 2 files changed, 42 deletions(-)

--- linux-2.6.10-rc2-mm3-full/drivers/net/ioc3-eth.c.old2004-11-29 
12:14:25.0 +0100
+++ linux-2.6.10-rc2-mm3-full/drivers/net/ioc3-eth.c2004-11-29 
12:14:34.0 +0100
@@ -56,7 +56,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
--- linux-2.6.10-rc2-mm3-full/include/linux/dp83840.h   2004-10-18 
23:54:32.0 +0200
+++ /dev/null   2004-11-25 03:16:25.0 +0100
@@ -1,41 +0,0 @@
-/*
- * linux/dp83840.h: definitions for DP83840 MII-compatible transceivers
- *
- * Copyright (C) 1996, 1999 David S. Miller (davem@redhat.com)
- */
-#ifndef __LINUX_DP83840_H
-#define __LINUX_DP83840_H
-
-#include 
-
-/*
- * Data sheets and programming docs for the DP83840 are available at
- * from http://www.national.com/
- *
- * The DP83840 is capable of both 10 and 100Mbps ethernet, in both
- * half and full duplex mode.  It also supports auto negotiation.
- *
- * But THIS THING IS A PAIN IN THE ASS TO PROGRAM!
- * Debugging eeprom burnt code is more fun than programming this chip!
- */
-
-/* First, the MII register numbers (actually DP83840 register numbers). */
-#define MII_CSCONFIG0x17/* CS configuration*/
-
-/* The Carrier Sense config register. */
-#define CSCONFIG_RESV1  0x0001  /* Unused...   */
-#define CSCONFIG_LED4   0x0002  /* Pin for full-dplx LED4  */
-#define CSCONFIG_LED1   0x0004  /* Pin for conn-status LED1*/
-#define CSCONFIG_RESV2  0x0008  /* Unused...   */
-#define CSCONFIG_TCVDISAB   0x0010  /* Turns off the transceiver   */
-#define CSCONFIG_DFBYPASS   0x0020  /* Bypass disconnect function  */
-#define CSCONFIG_GLFORCE0x0040  /* Good link force for 100mbps */
-#define CSCONFIG_CLKTRISTATE0x0080  /* Tristate 25m clock  */
-#define CSCONFIG_RESV3  0x0700  /* Unused...   */
-#define CSCONFIG_ENCODE 0x0800  /* 1=MLT-3, 0=binary   */
-#define CSCONFIG_RENABLE0x1000  /* Repeater mode enable*/
-#define CSCONFIG_TCDISABLE  0x2000  /* Disable timeout counter */
-#define CSCONFIG_RESV4  0x4000  /* Unused...   */
-#define CSCONFIG_NDISABLE   0x8000  /* Disable NRZI*/
-
-#endif /* __LINUX_DP83840_H */

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


Re: [PATCH 1/1] pci: Add Citrine quirk

2005-01-31 Thread Greg KH
On Fri, Jan 28, 2005 at 08:53:47AM -0600, [EMAIL PROTECTED] wrote:
> 
> The IBM Citrine chipset has a feature that if PCI config register
> 0xA0 is read while DMAs are being performed to it, there is the possiblity
> that the parity will be wrong on the PCI bus, causing a parity error and
> a master abort. On this chipset, this register is simply a debug register
> for the chip developers and the registers after it are not defined.
> Patch sets cfg_size to 0xA0 to prevent this problem from being seen.
> 
> Signed-off-by: Brian King <[EMAIL PROTECTED]>

Applied, thanks.

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


Re: [RFC] "biological parent" pid

2005-01-31 Thread Bernd Eckenfels
In article <[EMAIL PROTECTED]> you wrote:
> I am not aware of concepts in Linux or other unices that apply to this
> case.

Normal process accounting.

If you want to keep the pid of the bio-parent, you also need to keep the
start-time to make it unique. Better would be to have a all-time-unqiue
process handle. But I think it is better to not have that field, but use
audit logs. That is especially needed if you want to track chains, because
it doesnt help you to know the bio parent if you have no idea what that was.

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


Re: 2.6.10-ac11 announcement?

2005-01-31 Thread Alan Cox
On Llu, 2005-01-31 at 23:19, Dave Jones wrote:
> I see this happening too. It seems to go away when I back out
> this chunk..

Yep will stick up an -ac12 tomorrow pm with that and a couple of other
dumb
bugs fixed


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] move dp83840.h to Documentation/

2005-01-31 Thread Adrian Bunk
dp83840.h is included once but none of the definitions it contains is
actually used.

Ralf Baechle wants that it stays as documentation, so this patch moves 
it under Documentation/ .

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

---

 Documentation/networking/00-INDEX|2 +
 Documentation/networking/dp83840.txt |   41 +++
 drivers/net/ioc3-eth.c   |1 
 include/linux/dp83840.h  |   41 ---
 4 files changed, 43 insertions(+), 42 deletions(-)


This patch was already sent on:
- 29 Nov 2004

--- linux-2.6.10-rc2-mm3-full/drivers/net/ioc3-eth.c.old2004-11-29 
12:14:25.0 +0100
+++ linux-2.6.10-rc2-mm3-full/drivers/net/ioc3-eth.c2004-11-29 
12:14:34.0 +0100
@@ -56,7 +56,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
--- linux-2.6.10-rc2-mm3-full/include/linux/dp83840.h   2004-10-18 
23:54:32.0 +0200
+++ /dev/null   2004-11-25 03:16:25.0 +0100
@@ -1,41 +0,0 @@
-/*
- * linux/dp83840.h: definitions for DP83840 MII-compatible transceivers
- *
- * Copyright (C) 1996, 1999 David S. Miller (davem@redhat.com)
- */
-#ifndef __LINUX_DP83840_H
-#define __LINUX_DP83840_H
-
-#include 
-
-/*
- * Data sheets and programming docs for the DP83840 are available at
- * from http://www.national.com/
- *
- * The DP83840 is capable of both 10 and 100Mbps ethernet, in both
- * half and full duplex mode.  It also supports auto negotiation.
- *
- * But THIS THING IS A PAIN IN THE ASS TO PROGRAM!
- * Debugging eeprom burnt code is more fun than programming this chip!
- */
-
-/* First, the MII register numbers (actually DP83840 register numbers). */
-#define MII_CSCONFIG0x17/* CS configuration*/
-
-/* The Carrier Sense config register. */
-#define CSCONFIG_RESV1  0x0001  /* Unused...   */
-#define CSCONFIG_LED4   0x0002  /* Pin for full-dplx LED4  */
-#define CSCONFIG_LED1   0x0004  /* Pin for conn-status LED1*/
-#define CSCONFIG_RESV2  0x0008  /* Unused...   */
-#define CSCONFIG_TCVDISAB   0x0010  /* Turns off the transceiver   */
-#define CSCONFIG_DFBYPASS   0x0020  /* Bypass disconnect function  */
-#define CSCONFIG_GLFORCE0x0040  /* Good link force for 100mbps */
-#define CSCONFIG_CLKTRISTATE0x0080  /* Tristate 25m clock  */
-#define CSCONFIG_RESV3  0x0700  /* Unused...   */
-#define CSCONFIG_ENCODE 0x0800  /* 1=MLT-3, 0=binary   */
-#define CSCONFIG_RENABLE0x1000  /* Repeater mode enable*/
-#define CSCONFIG_TCDISABLE  0x2000  /* Disable timeout counter */
-#define CSCONFIG_RESV4  0x4000  /* Unused...   */
-#define CSCONFIG_NDISABLE   0x8000  /* Disable NRZI*/
-
-#endif /* __LINUX_DP83840_H */
--- /dev/null   2004-11-25 03:16:25.0 +0100
+++ linux-2.6.10-rc2-mm3-full/Documentation/networking/dp83840.txt  
2004-11-29 16:29:54.0 +0100
@@ -0,0 +1,41 @@
+/*
+ * linux/dp83840.h: definitions for DP83840 MII-compatible transceivers
+ *
+ * Copyright (C) 1996, 1999 David S. Miller (davem@redhat.com)
+ */
+#ifndef __LINUX_DP83840_H
+#define __LINUX_DP83840_H
+
+#include 
+
+/*
+ * Data sheets and programming docs for the DP83840 are available at
+ * from http://www.national.com/
+ *
+ * The DP83840 is capable of both 10 and 100Mbps ethernet, in both
+ * half and full duplex mode.  It also supports auto negotiation.
+ *
+ * But THIS THING IS A PAIN IN THE ASS TO PROGRAM!
+ * Debugging eeprom burnt code is more fun than programming this chip!
+ */
+
+/* First, the MII register numbers (actually DP83840 register numbers). */
+#define MII_CSCONFIG0x17/* CS configuration*/
+
+/* The Carrier Sense config register. */
+#define CSCONFIG_RESV1  0x0001  /* Unused...   */
+#define CSCONFIG_LED4   0x0002  /* Pin for full-dplx LED4  */
+#define CSCONFIG_LED1   0x0004  /* Pin for conn-status LED1*/
+#define CSCONFIG_RESV2  0x0008  /* Unused...   */
+#define CSCONFIG_TCVDISAB   0x0010  /* Turns off the transceiver   */
+#define CSCONFIG_DFBYPASS   0x0020  /* Bypass disconnect function  */
+#define CSCONFIG_GLFORCE0x0040  /* Good link force for 100mbps */
+#define CSCONFIG_CLKTRISTATE0x0080  /* Tristate 25m clock  */
+#define CSCONFIG_RESV3  0x0700  /* Unused...   */
+#define CSCONFIG_ENCODE 0x0800  /* 1=MLT-3, 0=binary   */
+#define CSCONFIG_RENABLE0x1000  /* Repeater mode enable*/
+#define CSCONFIG_TCDISABLE  0x2000  /* Disable timeout counter */
+#define CSCONFIG_RESV4  0x4000  /* Unused...   */
+#define CSCONFIG_NDISABLE   0x8000  /* Disable NRZI*/
+
+#endif /* __LINUX_DP83840_H */
--- 

[2.6 patch] kernel/sysctl.c: misc cleanups

2005-01-31 Thread Adrian Bunk
This patch makes some needlessly global code static and removes the 
unneeded EXPORT_SYMBOL(proc_doulonglongvec_minmax).

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

---

 include/linux/sysctl.h |7 --
 kernel/sysctl.c|   96 -
 2 files changed, 49 insertions(+), 54 deletions(-)

This patch was already sent on:
- 12 Dec 2004

--- linux-2.6.10-rc2-mm4-full/include/linux/sysctl.h.old2004-12-12 
03:19:59.0 +0100
+++ linux-2.6.10-rc2-mm4-full/include/linux/sysctl.h2004-12-12 
03:21:40.0 +0100
@@ -787,8 +787,6 @@
 void __user *, size_t *, loff_t *);
 extern int proc_dointvec(ctl_table *, int, struct file *,
 void __user *, size_t *, loff_t *);
-extern int proc_dointvec_bset(ctl_table *, int, struct file *,
- void __user *, size_t *, loff_t *);
 extern int proc_dointvec_minmax(ctl_table *, int, struct file *,
void __user *, size_t *, loff_t *);
 extern int proc_dointvec_jiffies(ctl_table *, int, struct file *,
@@ -806,11 +804,6 @@
  void __user *oldval, size_t __user *oldlenp,
  void __user *newval, size_t newlen);
 
-extern int do_sysctl_strategy (ctl_table *table, 
-  int __user *name, int nlen,
-  void __user *oldval, size_t __user *oldlenp,
-  void __user *newval, size_t newlen, void ** 
context);
-
 extern ctl_handler sysctl_string;
 extern ctl_handler sysctl_intvec;
 extern ctl_handler sysctl_jiffies;
--- linux-2.6.10-rc2-mm4-full/kernel/sysctl.c.old   2004-12-12 
03:20:14.0 +0100
+++ linux-2.6.10-rc2-mm4-full/kernel/sysctl.c   2004-12-12 03:24:58.0 
+0100
@@ -157,8 +157,10 @@
 static ssize_t proc_readsys(struct file *, char __user *, size_t, loff_t *);
 static ssize_t proc_writesys(struct file *, const char __user *, size_t, 
loff_t *);
 static int proc_opensys(struct inode *, struct file *);
+static int proc_dointvec_bset(ctl_table *table, int write, struct file *filp,
+ void __user *buffer, size_t *lenp, loff_t *ppos);
 
-struct file_operations proc_sys_file_operations = {
+static struct file_operations proc_sys_file_operations = {
.open   = proc_opensys,
.read   = proc_readsys,
.write  = proc_writesys,
@@ -1030,50 +1032,12 @@
return test_perm(table->mode, op);
 }
 
-static int parse_table(int __user *name, int nlen,
-  void __user *oldval, size_t __user *oldlenp,
-  void __user *newval, size_t newlen,
-  ctl_table *table, void **context)
-{
-   int n;
-repeat:
-   if (!nlen)
-   return -ENOTDIR;
-   if (get_user(n, name))
-   return -EFAULT;
-   for ( ; table->ctl_name; table++) {
-   if (n == table->ctl_name || table->ctl_name == CTL_ANY) {
-   int error;
-   if (table->child) {
-   if (ctl_perm(table, 001))
-   return -EPERM;
-   if (table->strategy) {
-   error = table->strategy(
-   table, name, nlen,
-   oldval, oldlenp,
-   newval, newlen, context);
-   if (error)
-   return error;
-   }
-   name++;
-   nlen--;
-   table = table->child;
-   goto repeat;
-   }
-   error = do_sysctl_strategy(table, name, nlen,
-  oldval, oldlenp,
-  newval, newlen, context);
-   return error;
-   }
-   }
-   return -ENOTDIR;
-}
-
 /* Perform the actual read/write of a sysctl table entry. */
-int do_sysctl_strategy (ctl_table *table, 
-   int __user *name, int nlen,
-   void __user *oldval, size_t __user *oldlenp,
-   void __user *newval, size_t newlen, void **context)
+static int do_sysctl_strategy (ctl_table *table, 
+  int __user *name, int nlen,
+  void __user *oldval, size_t __user *oldlenp,
+  void __user *newval, size_t newlen,
+  void **context)
 {
int op = 0, rc;
size_t len;
@@ -1120,6 +1084,45 @@
return 0;
 }
 
+static int parse_table(int __user *name, int nlen,
+  void __user *oldval, 

Re: [RFC] "biological parent" pid

2005-01-31 Thread Tim Schmielau
On Mon, 31 Jan 2005, Michael Buesch wrote:

> Quoting Tim Schmielau <[EMAIL PROTECTED]>:
> > The ppid of a process is not really helpful if I want to reconstruct the 
> > real history of processes on a machine, since it may become 1 when the
> > parent dies and the process is reparented to init.
> > 
> > I am not aware of concepts in Linux or other unices that apply to this
> > case. So I made up the "biological parent pid" bioppid (in contrast to the
> > adoptive parents pid) that just never changes.
> > Any user of it must of course remember that it doesn't need to be a valid 
> > pid anymore or might even belong to a different process that was forked in 
> > the meantime. bioppid only had to be a valid pid at time btime (it's
> > a (btime, pid) pair that unambiguously identifies a process).
> > 
> > Comments? (other that I just broke /proc/nnn/status parsing once again :-)
> 
> Eh, I can't see how this bioppid would be useful.
> Help me. Examples?

I'm trying to reconstruct the complete history of processes from the 
BSD accounting records. However, this is not very useful if a large 
fraction of the processes look as if they were started by init.

The following program will print the history in a form vaguely resembling
pstree output from the accounting file:

Tim


/* treeacct.c: use ac_pid and ac_ppid fields of struct acct_v3 to
 * build a tree of the process history.
 *
 * $Id: treeacct.c,v 0.8 2005/01/31 23:34:51 tim Exp tim $
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 


#define TIME_FUZZ 4

void *alloc(size_t size)
{
void *mem;

mem = malloc(size);
if (mem==NULL) {
fprintf(stderr, "out of memory.\n");
exit(5);
}
return mem;
}

/*
 * For each pid the acct records are organized in a singly linked list
 * named task_struct that is sorted by process start time (btime).
 *
 * They also form a tree according to their family relations.
 */
 
struct task_struct {
/* struct task_struct *prev;  seems to be superfluous  */
struct task_struct *next, *parent, *children, *siblings;
struct acct_v3 *acct;
   };


struct pid_struct {
struct pid_struct *next;
struct task_struct *tasklist;
   };

/*
 * The task_structs are stored in a hash array of singly linked pid_struct
 * lists sorted by pid.
 */

#define PID_HASH_MASK 0xf

struct pid_struct *pid_hash[PID_HASH_MASK + 1];

/*
 * List of tasks without parents.
 */

struct task_struct *orphans=NULL;

/*
 * Find the task that is uniquely determined by it's pid and the
 * time when the pid was valid.
 * If create!=0 and the task doesn't exist yet, create it.
 */

struct task_struct *get_task(__u32 pid, __u32 time, int create)
{
struct task_struct **task, *newtask;
struct pid_struct **pidlist, *newpid;

pidlist = _hash[pid & PID_HASH_MASK];
while (*pidlist!=NULL && (*pidlist)->tasklist->acct->ac_pid > pid)
pidlist = &((*pidlist)->next);
if (*pidlist==NULL || (*pidlist)->tasklist->acct->ac_pid < pid) {
/* this pid doesn't exist */
if (create!=0) {
/* so create task */
newtask = alloc(sizeof(struct task_struct));
newtask->next = NULL;
/* as well as a pidlist for it*/
newpid = alloc(sizeof(struct pid_struct));
newpid->next = *pidlist;
newpid->tasklist = newtask;
*pidlist = newpid;
return newtask;
} else {
return NULL;
}
} else {
/* find task on pidlist */ 
task = &((*pidlist)->tasklist);
while (*task!=NULL
   && (*task)->acct->ac_btime < time)
task = &((*task)->next);
if (*task!=NULL
 && (*task)->acct->ac_btime <= time+TIME_FUZZ
 && (*task)->acct->ac_btime
 + (__u32)((*task)->acct->ac_etime+1)
>= time-TIME_FUZZ) {
/* process found */
if (create!=0) {
fprintf(stderr,
"warning: pid %lu, occurs twice"
" at time $lu.",
pid, time);
} else {
return *task;
}
}
if (create!=0) {
newtask = alloc(sizeof(struct task_struct));
newtask->next = *task;
*task = newtask;
return newtask;

} else {
  

[2.6 patch] remove the unused OSS maestro_tables.h

2005-01-31 Thread Adrian Bunk
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 sound/oss/maestro_tables.h |  333 --
 1 files changed, 333 deletions(-)

This patch was already sent on:
- 26 Dec 2004

diff -L sound/oss/maestro_tables.h -puN 
sound/oss/maestro_tables.h~remove_file-sound_oss_maestro_tables.h /dev/null
--- kj/sound/oss/maestro_tables.h
+++ /dev/null   2004-12-24 01:21:08.0 +0100
@@ -1,333 +0,0 @@
-/* 
- * Set up data block for the ESS soundblaster emulation. This is like
- * the example code from ftp.esstech.com.tw  (104T31.ZIP)
- */
-
-u16 asp_block_0[]= {
-   0x7980, 0x003a, 0x7980, 0x007d, 0xbe3a, 0x8b00, 0xbe3a, 0x8b00, 
-   0xbe3a, 0x8b00, 0xbe3a, 0x8b00, 0xbe3a, 0x8b00, 0xbe3a, 0x8b00, 
-   0x7980, 0x0be6, 0x7980, 0x0069, 0xbe3a, 0x8b00, 0x8048, 0x6945, 
-   0xb801, 0x9045, 0x6941, 0xe388, 0x0031, 0x6944, 0xba50, 0xe38c, 
-   0x0031, 0x8b88, 0x6942, 0x304a, 0xe308, 0x0028, 0x6949, 0x9042, 
-   0x0042, 0xafa0, 0x8000, 0xafa0, 0x8000, 0x8042, 0x6944, 0xb801, 
-   0x9044, 0x0048, 0xbe3a, 0x, 0x, 0x, 0x, 0x, 
-   0x, 0x, 0xbe41, 0xbf80, 0x0101, 0x8806, 0x8804, 0xb912, 
-   0x8807, 0xbc26, 0xbe40, 0xb92f, 0x9001, 0x9002, 0x003b, 0x0122, 
-   0x7a88, 0x0055, 0x003a, 0x013c, 0x7a88, 0x0055, 0x4902, 0xe100, 
-   0x0800, 0x0c02, 0xa000, 0x7980, 0x004e, 0xb908, 0x8809, 0xbec6, 
-   0x0067, 0x4a80, 0xe200, 0x0065, 0x4880, 0xe200, 0x0063, 0xb97f, 
-   0x6e80, 0x7980, 0x0066, 0x1089, 0x9088, 0xb900, 0x90a9, 0x8ba8, 
-   0xef00, 0x803d, 0x0003, 0x1007, 0x881f, 0x8b88, 0xbb0f, 0xada0, 
-   0x0810, 0x9003, 0x4903, 0xe200, 0x007b, 0x9002, 0x6a05, 0x6d04, 
-   0x9803, 0x9804, 0x9005, 0x003d, 0xbe3a, 0xaf06, 0x, 0x803d, 
-   0x8b88, 0x6906, 0x8810, 0xaf06, 0x0001, 0xbfb0, 0x00ff, 0xbaf5, 
-   0xe3cc, 0x009a, 0x5e06, 0x003f, 0xbf80, 0x0080, 0x4a06, 0xe200, 
-   0x0095, 0x6e80, 0x6d06, 0x7980, 0x009b, 0x9080, 0x0810, 0xba46, 
-   0x8810, 0x8b00, 0x1006, 0x9080, 0x003d, 0xbe3a, 0x1024, 0x2009, 
-   0x8810, 0x8b88, 0x8b00, 0x1089, 0xbfb0, 0x000e, 0xbe0a, 0x880d, 
-   0x903e, 0x1038, 0x2008, 0x8810, 0x1037, 0x2008, 0x8811, 0x5f3e, 
-   0x, 0x8b00, 0xf500, 0x5e80, 0xfffe, 0x1039, 0x2008, 0x8815, 
-   0x8b8d, 0x0231, 0x0333, 0x108a, 0x90ad, 0x1025, 0x200a, 0x8815, 
-   0x0605, 0xb91f, 0x8809, 0x4f16, 0x1080, 0xf600, 0xbfb0, 
-   0x0003, 0xbfb0, 0x0007, 0x9089, 0xbe47, 0xbe43, 0xbec6, 
-   0x00f6, 0x4f8b, 0x14a8, 0xe500, 0x6380, 0x8b89, 0x4e8a, 
-   0xbfe3, 0xe500, 0x2480, 0xbe46, 0x8b9d, 0xbfe7, 0xbfb0, 
-   0x00ff, 0x288c, 0x2026, 0x8814, 0xbe47, 0x8b00, 0x738f, 
-   0x54aa, 0xbe03, 0xbe0a, 0x2fa8, 0x988a, 0x8da9, 0xbe03, 
-   0x4d8e, 0xbfe1, 0xf500, 0x6180, 0x9880, 0x8ba9, 0xbe03, 
-   0x4c8e, 0xbfe1, 0xf500, 0x6180, 0x9880, 0x8ba9, 0xbe42, 
-   0x1039, 0x2008, 0x8815, 0x8b8d, 0x8b00, 0x8d8a, 0x7980, 
-   0x0bcf};
-
-u16 asp_block_1[]={
-   0x0005, 0xb900, 0x9008, 0x9009, 0x900a, 0xbb3f, 0x90a0,
-   0x001a, 0x011b, 0x021c, 0x0323, 0x1089, 0x9015, 0x108a,
-   0x9016, 0x108b, 0x9017, 0x1088, 0x9018, 0x0137, 0x0524, 
-   0x8b8d, 0x4f16, 0xe200, 0x0827, 0x4f15, 0xe200, 0x0827, 
-   0x7a80, 0x08e6, 0x102c, 0xb802, 0x8813, 0x8b8b, 0xb900, 
-   0x90a0, 0x908d, 0x7980, 0x0833, 0x7a80, 0x0913, 0x7803, 
-   0x7a80, 0x0913, 0x102c, 0xb802, 0x8813, 0x8b8b, 0xb903, 
-   0x90a0, 0x908d, 0x7c02, 0x4f16, 0xe200, 0x0845, 0x4e15, 
-   0xe200, 0x0845, 0x7a80, 0x08e6, 0x102c, 0xb806, 0x8813, 
-   0x8b8b, 0xb901, 0x90a0, 0x908d, 0x7980, 0x0851, 0x7a80, 
-   0x0913, 0x7803, 0x7a80, 0x0913, 0x102c, 0xb806, 0x8813, 
-   0x8b8b, 0xb904, 0x90a0, 0x908d, 0x7c02, 0x4f16, 0xe200, 
-   0x0863, 0x4d15, 0xe200, 0x0863, 0x7a80, 0x08e6, 0x102c, 
-   0xb80a, 0x8813, 0x8b8b, 0xb902, 0x90a0, 0x908d, 0x7980, 
-   0x086f, 0x7a80, 0x0913, 0x7803, 0x7a80, 0x0913, 0x102c, 
-   0xb80a, 0x8813, 0x8b8b, 0xb905, 0x90a0, 0x908d, 0x7801, 
-   0x7a80, 0x0913, 0x7801, 0x7a80, 0x0913, 0x7801, 0x7a80, 
-   0x0913, 0x1024, 0xbf90, 0x0100, 0x8815, 0x4f16, 0xe200, 
-   0x088e, 0x4c15, 0xe200, 0x088e, 0x7a80, 0x08e6, 0x102c, 
-   0xb814, 0x8813, 0x8b8b, 0xbf80, 0x0100, 0x90a0, 0x908d, 
-   0x7980, 0x089b, 0x7a80, 0x0913, 0x7803, 0x7a80, 0x0913, 
-   0x102c, 0xb814, 0x8813, 0x8b8b, 0xbf80, 0x0103, 0x90a0, 
-   0x908d, 0x7c02, 0x4f16, 0xe200, 0x08ae, 0x4b15, 0xe200, 
-   0x08ae, 0x7a80, 0x08e6, 0x102c, 0xb818, 0x8813, 0x8b8b, 
-   0xbf80, 0x0101, 0x90a0, 0x908d, 0x7980, 0x08bb, 0x7a80, 
-   0x0913, 0x7803, 0x7a80, 0x0913, 0x102c, 0xb818, 0x8813, 
-   0x8b8b, 0xbf80, 0x0104, 0x90a0, 0x908d, 0x7c02, 0x4f16, 
-   0xe200, 0x08ce, 0x4a15, 0xe200, 0x08ce, 0x7a80, 0x08e6, 
-   0x102c, 0xb81c, 0x8813, 0x8b8b, 0xbf80, 0x0102, 0x90a0, 
-   0x908d, 0x7980, 0x08db, 0x7a80, 0x0913, 0x7803, 0x7a80, 
-   0x0913, 

[RFC][PATCH 2.6.11-rc2] vmlinux: put built-in module parameter info in vmlinux

2005-01-31 Thread Matt Domsch
Module parameter descriptions are added to loadable modules, but is
omitted from objects built into the kernel itself.  It would be nice
if you could get the list of parameters usable on the kernel command
line by looking at vmlinux.

$ modinfo vmlinux | grep parm:
parm:   thermal.tzp:Thermal zone polling frequency, in 1/10 seconds.
parm:   drm.drm_debug:Enable debug output
parm:   drm.drm_cards_limit:Maximum number of graphics cards
parm:   i8042.debug:Turn i8042 debugging mode on and off
parm:   i8042.noacpi:Do not use ACPI to detect controller settings
parm:   i8042.dumbkbd:Disable the AUX Loopback command while probing 
for the AUX port
parm:   i8042.dumbkbd:Pretend that controller can only read data from 
keyboard
parm:   i8042.direct:Put keyboard port into non-translated mode.
parm:   i8042.reset:Reset controller during init and cleanup.
parm:   i8042.unlock:Ignore keyboard lock.
parm:   i8042.nomux:Do not check whether an active multiplexing 
conrtoller is present.
parm:   i8042.noaux:Do not probe or use AUX (mouse) port.
parm:   8250.probe_rsa:Probe I/O ports for RSA
parm:   8250.share_irqs:Share IRQs with other non-8250/16x50 devices 
(unsafe)
parm:   rd.rd_blocksize:Blocksize of each RAM disk in bytes.
parm:   rd.rd_size:Size of each RAM disk in kbytes.
parm:   usbcore.use_both_schemes:try the other device initialization 
scheme if the first one fails
parm:   usbcore.old_scheme_first:start with the old device 
initialization scheme
parm:   usbcore.blinkenlights:true to cycle leds on hubs
parm:   usbcore.usbfs_snoop:true to log all usbfs traffic
parm:   mousedev.tap_time:Tap time for touchpads in absolute mode 
(msecs)
parm:   mousedev.yres:Vertical screen resolution
parm:   mousedev.xres:Horizontal screen resolution
parm:   atkbd.extra:Enable extra LEDs and keys on IBM RapidAcces, EzKey 
and similar keyboards
parm:   atkbd.scroll:Enable scroll-wheel on MS Office and similar 
keyboards
parm:   atkbd.softraw:Use software generated rawmode
parm:   atkbd.softrepeat:Use software keyboard repeat
parm:   atkbd.reset:Reset keyboard during initialization
parm:   atkbd.set:Select keyboard code set (2 = default, 3 = PS/2 
native)
parm:   psmouse.resetafter:Reset device after so many bad packets (0 = 
never).
parm:   psmouse.smartscroll:Logitech Smartscroll autorepeat, 1 = 
enabled (default), 0 = disabled.
parm:   psmouse.rate:Report rate, in reports per second.
parm:   psmouse.resolution:Resolution, in dpi.
parm:   psmouse.proto:Highest protocol extension to probe (bare, imps, 
exps). Useful for KVM switches.

Patch below implements such.  It also emits modulename.version fields
should they exist, but omits license, author, and description fields,
as I'm not sure how interesting those fields are when built-in.

Feedback requested prior to submission for inclusion.

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

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

= include/linux/module.h 1.92 vs edited =
--- 1.92/include/linux/module.h 2005-01-10 13:28:15 -06:00
+++ edited/include/linux/module.h   2005-01-31 17:59:23 -06:00
@@ -76,14 +79,27 @@
 
 extern struct subsystem module_subsys;
 
+/* You can override this manually, but generally this should match the
+   module name. */
 #ifdef MODULE
+#define MODULE_PARAM_PREFIX /* empty */
+#else
+#define MODULE_PARAM_PREFIX __stringify(KBUILD_MODNAME) "."
+#endif
+
 #define ___module_cat(a,b) __mod_ ## a ## b
 #define __module_cat(a,b) ___module_cat(a,b)
 #define __MODULE_INFO(tag, name, info)   \
 static const char __module_cat(name,__LINE__)[]
  \
   __attribute_used__ \
-  __attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info
+  __attribute__((section(".modinfo"),unused)) = MODULE_PARAM_PREFIX 
__stringify(tag) "=" info
+
+#define ___MODULE_INFO(tag, name, info)
  \
+static const char __module_cat(name,__LINE__)[]
  \
+  __attribute_used__ \
+  __attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" 
MODULE_PARAM_PREFIX info
 
+#ifdef MODULE
 #define MODULE_GENERIC_TABLE(gtype,name)   \
 extern const struct gtype##_id __mod_##gtype##_table   \
   __attribute__ ((unused, alias(__stringify(name
@@ -94,7 +110,6 @@
 #else  /* !MODULE */
 
 #define MODULE_GENERIC_TABLE(gtype,name)
-#define __MODULE_INFO(tag, name, info)
 #define THIS_MODULE ((struct module *)0)
 #endif
 
@@ -130,6 

Re: [2.6 patch] move dp83840.h to Documentation/

2005-01-31 Thread Ralf Baechle
On Tue, Feb 01, 2005 at 12:41:58AM +0100, Adrian Bunk wrote:

> 
> dp83840.h is included once but none of the definitions it contains is
> actually used.
> 
> Ralf Baechle wants that it stays as documentation, so this patch moves 
> it under Documentation/ .

Under Documentation is certainly not the right place for a piece of code,
so let's do it as David says.

  Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] non-PC parport config change

2005-01-31 Thread Adrian Bunk
This patch adds a config option PARPORT_NOT_PC (and removes the 
PARPORT_OTHER option) that get's selected if any non-PC hardware was 
chosen.

This way, the mega #if in parport.h is gone now.

Additionally, it removes the unneeded PARPORT_NEED_GENERIC_OPS #define.

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

---

 include/linux/parport.h |   12 +---
 drivers/parport/Kconfig |   20 +---
 drivers/usb/Kconfig |1 +
 3 files changed, 15 insertions(+), 18 deletions(-)

This patch was already sent on:
- 20 Jan 2005

--- linux-2.6.10-rc2-mm4-full/include/linux/parport.h.old   2004-12-09 
04:50:26.0 +0100
+++ linux-2.6.10-rc2-mm4-full/include/linux/parport.h   2004-12-09 
12:59:06.0 +0100
@@ -105,8 +105,6 @@
 #include 
 #include 
 
-#define PARPORT_NEED_GENERIC_OPS
-
 /* Define this later. */
 struct parport;
 struct pardevice;
@@ -520,9 +518,8 @@
 extern int parport_device_proc_unregister(struct pardevice *device);
 
 /* If PC hardware is the only type supported, we can optimise a bit.  */
-#if (defined(CONFIG_PARPORT_PC) || defined(CONFIG_PARPORT_PC_MODULE)) && 
!(defined(CONFIG_PARPORT_ARC) || defined(CONFIG_PARPORT_ARC_MODULE)) && 
!(defined(CONFIG_PARPORT_AMIGA) || defined(CONFIG_PARPORT_AMIGA_MODULE)) && 
!(defined(CONFIG_PARPORT_MFC3) || defined(CONFIG_PARPORT_MFC3_MODULE)) && 
!(defined(CONFIG_PARPORT_ATARI) || defined(CONFIG_PARPORT_ATARI_MODULE)) && 
!(defined(CONFIG_USB_USS720) || defined(CONFIG_USB_USS720_MODULE)) && 
!(defined(CONFIG_PARPORT_SUNBPP) || defined(CONFIG_PARPORT_SUNBPP_MODULE)) && 
!defined(CONFIG_PARPORT_OTHER)
+#if !defined(CONFIG_PARPORT_NOT_PC)
 
-#undef PARPORT_NEED_GENERIC_OPS
 #include 
 #define parport_write_data(p,x)parport_pc_write_data(p,x)
 #define parport_read_data(p)   parport_pc_read_data(p)
@@ -534,9 +531,9 @@
 #define parport_disable_irq(p) parport_pc_disable_irq(p)
 #define parport_data_forward(p)parport_pc_data_forward(p)
 #define parport_data_reverse(p)parport_pc_data_reverse(p)
-#endif
 
-#ifdef PARPORT_NEED_GENERIC_OPS
+#else  /*  !CONFIG_PARPORT_NOT_PC  */
+
 /* Generic operations vector through the dispatch table. */
 #define parport_write_data(p,x)(p)->ops->write_data(p,x)
 #define parport_read_data(p)   (p)->ops->read_data(p)
@@ -548,7 +545,8 @@
 #define parport_disable_irq(p) (p)->ops->disable_irq(p)
 #define parport_data_forward(p)(p)->ops->data_forward(p)
 #define parport_data_reverse(p)(p)->ops->data_reverse(p)
-#endif
+
+#endif /*  !CONFIG_PARPORT_NOT_PC  */
 
 #endif /* __KERNEL__ */
 #endif /* _PARPORT_H_ */
--- linux-2.6.11-rc1-mm2-full/drivers/parport/Kconfig.old   2005-01-20 
17:45:13.0 +0100
+++ linux-2.6.11-rc1-mm2-full/drivers/parport/Kconfig   2005-01-20 
17:46:39.0 +0100
@@ -88,13 +88,18 @@
  Say Y here if you need PCMCIA support for your PC-style parallel
  ports. If unsure, say N.
 
+config PARPORT_NOT_PC
+   bool
+
 config PARPORT_ARC
tristate "Archimedes hardware"
depends on ARM && PARPORT
+   select PARPORT_NOT_PC
 
 config PARPORT_AMIGA
tristate "Amiga builtin port"
depends on AMIGA && PARPORT
+   select PARPORT_NOT_PC
help
  Say Y here if you need support for the parallel port hardware on
  Amiga machines. This code is also available as a module (say M),
@@ -103,6 +108,7 @@
 config PARPORT_MFC3
tristate "Multiface III parallel port"
depends on ZORRO && PARPORT
+   select PARPORT_NOT_PC
help
  Say Y here if you need parallel port support for the MFC3 card.
  This code is also available as a module (say M), called
@@ -111,6 +117,7 @@
 config PARPORT_ATARI
tristate "Atari hardware"
depends on ATARI && PARPORT
+   select PARPORT_NOT_PC
help
  Say Y here if you need support for the parallel port hardware on
  Atari machines. This code is also available as a module (say M),
@@ -123,22 +130,13 @@
 
 config PARPORT_SUNBPP
tristate "Sparc hardware (EXPERIMENTAL)"
-   depends on SBUS && EXPERIMENTAL && PARPORT
+   depends on SBUS && PARPORT && EXPERIMENTAL
+   select PARPORT_NOT_PC
help
  This driver provides support for the bidirectional parallel port
  found on many Sun machines. Note that many of the newer Ultras
  actually have pc style hardware instead.
 
-# If exactly one hardware type is selected then parport will optimise away
-# support for loading any others.  Defeat this if the user is keen.
-config PARPORT_OTHER
-   bool "Support foreign hardware"
-   depends on PARPORT
-   help
- Say Y here if you want to be able to load driver modules to support
- other non-standard types of parallel ports. This causes a
- performance loss, so most people say N.
-
 config PARPORT_1284
bool "IEEE 

[PATCH 2.6.11-rc2-mm2] serial: add NEC VR4100 series serial support

2005-01-31 Thread Yoichi Yuasa
This patch adds serial driver for NEC VR4100 series serial interface unit.

Yoichi

Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>

diff -urN -X dontdiff a-orig/Documentation/devices.txt 
a/Documentation/devices.txt
--- a-orig/Documentation/devices.txtMon Jan 31 00:42:18 2005
+++ a/Documentation/devices.txt Tue Feb  1 08:23:40 2005
@@ -2755,6 +2755,8 @@
 50 = /dev/ttyIOC40 Altix serial card
...
 81 = /dev/ttyIOC431Altix serial card
+82 = /dev/ttyVR0   NEC VR4100 series SIU
+83 = /dev/ttyVR1   NEC VR4100 series DSIU
 
 205 char   Low-density serial ports (alternate device)
  0 = /dev/culu0Callout device for ttyLU0
@@ -2789,6 +2791,8 @@
 50 = /dev/cuioc40  Callout device for ttyIOC40
...
 81 = /dev/cuioc431 Callout device for ttyIOC431
+82 = /dev/cuvr0Callout device for ttyVR0
+83 = /dev/cuvr1Callout device for ttyVR1
 
 
 206 char   OnStream SC-x0 tape devices
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/cmu.c 
a/arch/mips/vr41xx/common/cmu.c
--- a-orig/arch/mips/vr41xx/common/cmu.cSat Jan 22 10:47:33 2005
+++ a/arch/mips/vr41xx/common/cmu.c Tue Feb  1 08:18:31 2005
@@ -160,7 +160,7 @@
current_cpu_data.cputype == CPU_VR4121) {
cmuclkmsk &= ~MSKDSIU;
} else {
-   if (cmuclkmsk & MSKSIU)
+   if (cmuclkmsk & MSKSSIU)
cmuclkmsk &= ~MSKDSIU;
else
cmuclkmsk &= ~(MSKSIU | MSKDSIU);
diff -urN -X dontdiff a-orig/drivers/serial/Kconfig a/drivers/serial/Kconfig
--- a-orig/drivers/serial/Kconfig   Mon Jan 31 00:42:34 2005
+++ a/drivers/serial/KconfigTue Feb  1 08:18:31 2005
@@ -806,4 +806,21 @@
bool "TX39XX/49XX SIO act as standard serial"
depends on !SERIAL_8250 && SERIAL_TXX9
 
+config SERIAL_VR41XX
+   tristate "NEC VR4100 series Serial Interface Unit support"
+   depends on CPU_VR41XX
+   select SERIAL_CORE
+   help
+ If you have a NEC VR4100 series processor and you want to use
+ Serial Interface Unit(SIU) or Debug Serial Interface Unit(DSIU)
+ (not include VR4111/VR4121 DSIU), say Y.  Otherwise, say N.
+
+config SERIAL_VR41XX_CONSOLE
+   bool "Enable NEC VR4100 series Serial Interface Unit console"
+   depends on SERIAL_VR41XX
+   select SERIAL_CORE_CONSOLE
+   help
+ If you have a NEC VR4100 series processor and you want to use
+ a console on a serial port, say Y.  Otherwise, say N.
+
 endmenu
diff -urN -X dontdiff a-orig/drivers/serial/Makefile a/drivers/serial/Makefile
--- a-orig/drivers/serial/Makefile  Sat Jan 22 10:48:01 2005
+++ a/drivers/serial/Makefile   Tue Feb  1 08:19:46 2005
@@ -48,3 +48,4 @@
 obj-$(CONFIG_SERIAL_M32R_SIO) += m32r_sio.o
 obj-$(CONFIG_SERIAL_MPSC) += mpsc.o
 obj-$(CONFIG_ETRAX_SERIAL) += crisv10.o
+obj-$(CONFIG_SERIAL_VR41XX) += vr41xx_siu.o
diff -urN -X dontdiff a-orig/drivers/serial/vr41xx_siu.c 
a/drivers/serial/vr41xx_siu.c
--- a-orig/drivers/serial/vr41xx_siu.c  Thu Jan  1 09:00:00 1970
+++ a/drivers/serial/vr41xx_siu.c   Tue Feb  1 08:24:03 2005
@@ -0,0 +1,1009 @@
+/*
+ *  Driver for NEC VR4100 series Serial Interface Unit.
+ *
+ *  Copyright (C) 2004-2005  Yoichi Yuasa <[EMAIL PROTECTED]>
+ *
+ *  Based on drivers/serial/8250.c, by Russell King.
+ *
+ *  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.  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#include 
+
+#if defined(CONFIG_SERIAL_VR41XX_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define SIU_PORTS_MAX  2
+#define SIU_BAUD_BASE  1152000
+#define SIU_MAJOR  204
+#define SIU_MINOR_BASE 82
+
+#define RX_MAX_COUNT   256
+#define TX_MAX_COUNT   15
+
+struct siu_port {
+   unsigned int type;
+   unsigned int irq;
+   unsigned long start;
+   uint8_t flags;
+};
+

Re: [2.6 patch] move dp83840.h to Documentation/

2005-01-31 Thread Jeff Garzik
David S. Miller wrote:
On Tue, 1 Feb 2005 00:41:58 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:

dp83840.h is included once but none of the definitions it contains is
actually used.
Ralf Baechle wants that it stays as documentation, so this patch moves 
it under Documentation/ .

No, let's kill this thing altogether.  The only driver in the world
using the CSCONFIG_* defines in there is the sunhme driver and it
defines it's own macros in drivers/net/sunhme.h  This header is more
than useless these days.
The header still exists in older trees and the revision history.
So people can still get to it there.

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


Re: [2.6 patch] move dp83840.h to Documentation/

2005-01-31 Thread David S. Miller
On Tue, 1 Feb 2005 00:41:58 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:

> dp83840.h is included once but none of the definitions it contains is
> actually used.
> 
> Ralf Baechle wants that it stays as documentation, so this patch moves 
> it under Documentation/ .

No, let's kill this thing altogether.  The only driver in the world
using the CSCONFIG_* defines in there is the sunhme driver and it
defines it's own macros in drivers/net/sunhme.h  This header is more
than useless these days.

The header still exists in older trees and the revision history.
So people can still get to it 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 2.6.11-rc2] vmlinux: add SETUP_DESC() to describe __setup() options

2005-01-31 Thread Matt Domsch
__setup() options are traditionally documented in
Documentation/kernel-parameters.txt.  However, it would be nice if
they could be documented alongside the implementation, similar to
MODULE_PARM_DESC() fields for modules, and if 'modinfo vmlinux' could
report such.

Patch below adds a new macro, SETUP_DESC(), which can be used to
document the use cases of __setup() options.  A usage example in
kernel/audit.c is provided as well.

$ modinfo vmlinux | grep setup_param
setup_param:audit:0 = disable, 1 = enable (kernel/audit.c)

Feedback requested.

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

= include/linux/init.h 1.35 vs edited =
--- 1.35/include/linux/init.h   2005-01-04 20:48:02 -06:00
+++ edited/include/linux/init.h 2005-01-31 17:22:41 -06:00
@@ -127,6 +127,15 @@
__attribute__((aligned((sizeof(long)\
= { __setup_str_##unique_id, fn, early }
 
+#define __setup_cat(a) __setup_str_ ## a
+#define __SETUP_INFO(tag, name, info)\
+static const char __setup_cat(name)[]\
+  __attribute_used__ \
+  __attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info " (" 
__FILE__ ")"
+
+#define SETUP_DESC(_parm, desc) \
+__SETUP_INFO(setup_param, _parm, #_parm ":" desc)
+
 #define __setup_null_param(str, unique_id) \
__setup_param(str, unique_id, NULL, 0)
 
@@ -202,6 +211,7 @@
 #define __setup_null_param(str, unique_id) /* nothing */
 #define __setup(str, func) /* nothing */
 #define __obsolete_setup(str)  /* nothing */
+#define SETUP_DESC(_parm, desc)/* nothing */
 #endif
 
 /* Data marked not to be saved by software_suspend() */



= kernel/audit.c 1.6 vs edited =
--- 1.6/kernel/audit.c  2005-01-20 22:56:04 -06:00
+++ edited/kernel/audit.c   2005-01-31 15:55:43 -06:00
@@ -617,7 +617,7 @@
 }
 
 __setup("audit=", audit_enable);
-
+SETUP_DESC(audit, "0 = disable, 1 = enable");
 
 /* Obtain an audit buffer.  This routine does locking to obtain the
  * audit buffer, but then no locking is required for calls to
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Bug: audio playing broke with my SCSI CD and DVD drives in 2.6.11-rc2-bk7 and beyond.

2005-01-31 Thread Jesper Juhl
On Mon, 31 Jan 2005, James Bottomley wrote:

> On Tue, 2005-02-01 at 00:22 +0100, Jesper Juhl wrote:
> > audio
> Could you try the attached?
> James
> 
I applied the patch to 2.6.11-rc2-bk9, rebuild, rebooted and now 
everything is just fine. 
Thank you.

-- 
Jesper Juhl


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] fs/hfsplus/: misc cleanups

2005-01-31 Thread Adrian Bunk
This patch contains the following cleanups:
- make needlessly global code static
- bnode.c: remove the unused global functions hfsplus_lock_bnode
   and hfsplus_unlock_bnode

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

---

 fs/hfsplus/bnode.c  |   11 ---
 fs/hfsplus/brec.c   |   10 +++---
 fs/hfsplus/dir.c|   23 +--
 fs/hfsplus/extents.c|9 +
 fs/hfsplus/hfsplus_fs.h |7 ---
 fs/hfsplus/inode.c  |6 +++---
 fs/hfsplus/super.c  |4 ++--
 7 files changed, 30 insertions(+), 40 deletions(-)

This patch was already sent on:
- 8 Jan 2005

--- linux-2.6.10-mm2-full/fs/hfsplus/bnode.c.old2005-01-07 
00:37:53.0 +0100
+++ linux-2.6.10-mm2-full/fs/hfsplus/bnode.c2005-01-08 02:18:20.0 
+0100
@@ -648,14 +648,3 @@
}
 }
 
-void hfsplus_lock_bnode(struct hfs_bnode *node)
-{
-   wait_event(node->lock_wq, !test_and_set_bit(HFS_BNODE_LOCK, 
>flags));
-}
-
-void hfsplus_unlock_bnode(struct hfs_bnode *node)
-{
-   clear_bit(HFS_BNODE_LOCK, >flags);
-   if (waitqueue_active(>lock_wq))
-   wake_up(>lock_wq);
-}
--- linux-2.6.10-mm2-full/fs/hfsplus/hfsplus_fs.h.old   2005-01-07 
00:39:41.0 +0100
+++ linux-2.6.10-mm2-full/fs/hfsplus/hfsplus_fs.h   2005-01-08 
02:18:20.0 +0100
@@ -230,9 +230,6 @@
 #define hfs_brec_keylen hfsplus_brec_keylen
 #define hfs_brec_insert hfsplus_brec_insert
 #define hfs_brec_remove hfsplus_brec_remove
-#define hfs_bnode_split hfsplus_bnode_split
-#define hfs_brec_update_parent hfsplus_brec_update_parent
-#define hfs_btree_inc_height hfsplus_btree_inc_height
 #define hfs_find_init hfsplus_find_init
 #define hfs_find_exit hfsplus_find_exit
 #define __hfs_brec_find __hplusfs_brec_find
@@ -297,9 +294,6 @@
 u16 hfs_brec_keylen(struct hfs_bnode *, u16);
 int hfs_brec_insert(struct hfs_find_data *, void *, int);
 int hfs_brec_remove(struct hfs_find_data *);
-struct hfs_bnode *hfs_bnode_split(struct hfs_find_data *);
-int hfs_brec_update_parent(struct hfs_find_data *);
-int hfs_btree_inc_height(struct hfs_btree *);
 
 /* bfind.c */
 int hfs_find_init(struct hfs_btree *, struct hfs_find_data *);
@@ -320,7 +314,6 @@
 
 /* extents.c */
 int hfsplus_ext_cmp_key(hfsplus_btree_key *, hfsplus_btree_key *);
-void hfsplus_ext_build_key(hfsplus_btree_key *, u32, u32, u8);
 void hfsplus_ext_write_extent(struct inode *);
 int hfsplus_get_block(struct inode *, sector_t, struct buffer_head *, int);
 int hfsplus_free_fork(struct super_block *, u32, struct hfsplus_fork_raw *, 
int);
--- linux-2.6.10-mm2-full/fs/hfsplus/brec.c.old 2005-01-07 00:40:46.0 
+0100
+++ linux-2.6.10-mm2-full/fs/hfsplus/brec.c 2005-01-08 02:19:47.0 
+0100
@@ -11,6 +11,10 @@
 #include "hfsplus_fs.h"
 #include "hfsplus_raw.h"
 
+static struct hfs_bnode *hfs_bnode_split(struct hfs_find_data *fd);
+static int hfs_brec_update_parent(struct hfs_find_data *fd);
+static int hfs_btree_inc_height(struct hfs_btree *);
+
 /* Get the length and offset of the given record in the given node */
 u16 hfs_brec_lenoff(struct hfs_bnode *node, u16 rec, u16 *off)
 {
@@ -209,7 +213,7 @@
return 0;
 }
 
-struct hfs_bnode *hfs_bnode_split(struct hfs_find_data *fd)
+static struct hfs_bnode *hfs_bnode_split(struct hfs_find_data *fd)
 {
struct hfs_btree *tree;
struct hfs_bnode *node, *new_node;
@@ -318,7 +322,7 @@
return new_node;
 }
 
-int hfs_brec_update_parent(struct hfs_find_data *fd)
+static int hfs_brec_update_parent(struct hfs_find_data *fd)
 {
struct hfs_btree *tree;
struct hfs_bnode *node, *new_node, *parent;
@@ -414,7 +418,7 @@
return 0;
 }
 
-int hfs_btree_inc_height(struct hfs_btree *tree)
+static int hfs_btree_inc_height(struct hfs_btree *tree)
 {
struct hfs_bnode *node, *new_node;
struct hfs_bnode_desc node_desc;
--- linux-2.6.10-mm2-full/fs/hfsplus/dir.c.old  2005-01-07 00:44:00.0 
+0100
+++ linux-2.6.10-mm2-full/fs/hfsplus/dir.c  2005-01-08 02:18:20.0 
+0100
@@ -228,8 +228,8 @@
return 0;
 }
 
-int hfsplus_create(struct inode *dir, struct dentry *dentry, int mode,
-  struct nameidata *nd)
+static int hfsplus_create(struct inode *dir, struct dentry *dentry, int mode,
+ struct nameidata *nd)
 {
struct inode *inode;
int res;
@@ -250,7 +250,8 @@
return 0;
 }
 
-int hfsplus_link(struct dentry *src_dentry, struct inode *dst_dir, struct 
dentry *dst_dentry)
+static int hfsplus_link(struct dentry *src_dentry, struct inode *dst_dir, 
+   struct dentry *dst_dentry)
 {
struct super_block *sb = dst_dir->i_sb;
struct inode *inode = src_dentry->d_inode;
@@ -302,7 +303,7 @@
return 0;
 }
 
-int hfsplus_unlink(struct inode *dir, struct dentry *dentry)
+static int hfsplus_unlink(struct inode *dir, struct dentry *dentry)
 {
struct super_block *sb = dir->i_sb;
struct inode 

[2.6 patch] small partitions/msdos cleanups

2005-01-31 Thread Adrian Bunk
This patch makes the following changes to the msdos partition code:
- remove CONFIG_NEC98_PARTITION leftovers
- make parse_bsd static

This patch was already ACK'ed by Andries Brouwer.

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

---

diffstat output:
 fs/partitions/Makefile |1 -
 fs/partitions/check.c  |3 ---
 fs/partitions/check.h  |4 
 fs/partitions/msdos.c  |4 ++--
 4 files changed, 2 insertions(+), 10 deletions(-)

This patch was already sent on:
- 30 Oct 2004
- 7 Dec 2004
- 14 Dec 2004
- 7 Jan 2005

--- linux-2.6.10-rc1-mm2-full/fs/partitions/Makefile.old2004-10-30 
14:42:03.0 +0200
+++ linux-2.6.10-rc1-mm2-full//fs/partitions/Makefile   2004-10-30 
14:42:13.0 +0200
@@ -17,4 +17,3 @@
 obj-$(CONFIG_ULTRIX_PARTITION) += ultrix.o
 obj-$(CONFIG_IBM_PARTITION) += ibm.o
 obj-$(CONFIG_EFI_PARTITION) += efi.o
-obj-$(CONFIG_NEC98_PARTITION) += nec98.o msdos.o
--- linux-2.6.10-rc1-mm2-full/fs/partitions/check.h.old 2004-10-30 
14:40:20.0 +0200
+++ linux-2.6.10-rc1-mm2-full//fs/partitions/check.h2004-10-30 
14:40:41.0 +0200
@@ -30,7 +30,3 @@
 
 extern int warn_no_part;
 
-extern void parse_bsd(struct parsed_partitions *state,
-   struct block_device *bdev, u32 offset, u32 size,
-   int origin, char *flavour, int max_partitions);
-
--- linux-2.6.10-rc1-mm2-full/fs/partitions/check.c.old 2004-10-30 
14:41:32.0 +0200
+++ linux-2.6.10-rc1-mm2-full//fs/partitions/check.c2004-10-30 
14:41:43.0 +0200
@@ -76,9 +76,6 @@
 #ifdef CONFIG_LDM_PARTITION
ldm_partition,  /* this must come before msdos */
 #endif
-#ifdef CONFIG_NEC98_PARTITION
-   nec98_partition,/* must be come before `msdos_partition' */
-#endif
 #ifdef CONFIG_MSDOS_PARTITION
msdos_partition,
 #endif
--- linux-2.6.10-rc1-mm2-full/fs/partitions/msdos.c.old 2004-10-30 
14:38:38.0 +0200
+++ linux-2.6.10-rc1-mm2-full//fs/partitions/msdos.c2004-10-30 
14:41:57.0 +0200
@@ -202,12 +202,12 @@
 #endif
 }
 
-#if defined(CONFIG_BSD_DISKLABEL) || defined(CONFIG_NEC98_PARTITION)
+#if defined(CONFIG_BSD_DISKLABEL)
 /* 
  * Create devices for BSD partitions listed in a disklabel, under a
  * dos-like partition. See parse_extended() for more information.
  */
-void
+static void
 parse_bsd(struct parsed_partitions *state, struct block_device *bdev,
u32 offset, u32 size, int origin, char *flavour,
int max_partitions)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] fs/hpfs/: make some code static

2005-01-31 Thread Adrian Bunk
This patch makes some needlessly global code static.

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

---

 fs/hpfs/alloc.c   |4 +++-
 fs/hpfs/dentry.c  |6 +++---
 fs/hpfs/dnode.c   |   14 --
 fs/hpfs/hpfs_fn.h |4 
 fs/hpfs/inode.c   |2 +-
 fs/hpfs/name.c|4 ++--
 fs/hpfs/super.c   |6 +++---
 7 files changed, 20 insertions(+), 20 deletions(-)

This patch was already sent on:
- 7 Jan 2005

--- linux-2.6.10-mm2-full/fs/hpfs/hpfs_fn.h.old 2005-01-07 00:49:31.0 
+0100
+++ linux-2.6.10-mm2-full/fs/hpfs/hpfs_fn.h 2005-01-07 00:52:55.0 
+0100
@@ -202,7 +202,6 @@
 
 int hpfs_chk_sectors(struct super_block *, secno, int, char *);
 secno hpfs_alloc_sector(struct super_block *, secno, unsigned, int, int);
-int hpfs_alloc_if_possible_nolock(struct super_block *, secno);
 int hpfs_alloc_if_possible(struct super_block *, secno);
 void hpfs_free_sectors(struct super_block *, secno, unsigned);
 int hpfs_check_free_dnodes(struct super_block *, int);
@@ -247,8 +246,6 @@
 void hpfs_add_pos(struct inode *, loff_t *);
 void hpfs_del_pos(struct inode *, loff_t *);
 struct hpfs_dirent *hpfs_add_de(struct super_block *, struct dnode *, unsigned 
char *, unsigned, secno);
-void hpfs_delete_de(struct super_block *, struct dnode *, struct hpfs_dirent 
*);
-int hpfs_add_to_dnode(struct inode *, dnode_secno, unsigned char *, unsigned, 
struct hpfs_dirent *, dnode_secno);
 int hpfs_add_dirent(struct inode *, unsigned char *, unsigned, struct 
hpfs_dirent *, int);
 int hpfs_remove_dirent(struct inode *, dnode_secno, struct hpfs_dirent *, 
struct quad_buffer_head *, int);
 void hpfs_count_dnodes(struct super_block *, dnode_secno, int *, int *, int *);
@@ -276,7 +273,6 @@
 
 void hpfs_init_inode(struct inode *);
 void hpfs_read_inode(struct inode *);
-void hpfs_write_inode_ea(struct inode *, struct fnode *);
 void hpfs_write_inode(struct inode *);
 void hpfs_write_inode_nolock(struct inode *);
 int hpfs_notify_change(struct dentry *, struct iattr *);
--- linux-2.6.10-mm2-full/fs/hpfs/alloc.c.old   2005-01-07 00:49:42.0 
+0100
+++ linux-2.6.10-mm2-full/fs/hpfs/alloc.c   2005-01-07 00:50:06.0 
+0100
@@ -8,6 +8,8 @@
 
 #include "hpfs_fn.h"
 
+static int hpfs_alloc_if_possible_nolock(struct super_block *s, secno sec);
+
 /*
  * Check if a sector is allocated in bitmap
  * This is really slow. Turned on only if chk==2
@@ -243,7 +245,7 @@
 
 /* Alloc sector if it's free */
 
-int hpfs_alloc_if_possible_nolock(struct super_block *s, secno sec)
+static int hpfs_alloc_if_possible_nolock(struct super_block *s, secno sec)
 {
struct quad_buffer_head qbh;
unsigned *bmp;
--- linux-2.6.10-mm2-full/fs/hpfs/dentry.c.old  2005-01-07 00:50:19.0 
+0100
+++ linux-2.6.10-mm2-full/fs/hpfs/dentry.c  2005-01-07 00:50:57.0 
+0100
@@ -12,7 +12,7 @@
  * Note: the dentry argument is the parent dentry.
  */
 
-int hpfs_hash_dentry(struct dentry *dentry, struct qstr *qstr)
+static int hpfs_hash_dentry(struct dentry *dentry, struct qstr *qstr)
 {
unsigned longhash;
int  i;
@@ -34,7 +34,7 @@
return 0;
 }
 
-int hpfs_compare_dentry(struct dentry *dentry, struct qstr *a, struct qstr *b)
+static int hpfs_compare_dentry(struct dentry *dentry, struct qstr *a, struct 
qstr *b)
 {
unsigned al=a->len;
unsigned bl=b->len;
@@ -49,7 +49,7 @@
return 0;
 }
 
-struct dentry_operations hpfs_dentry_operations = {
+static struct dentry_operations hpfs_dentry_operations = {
.d_hash = hpfs_hash_dentry,
.d_compare  = hpfs_compare_dentry,
 };
--- linux-2.6.10-mm2-full/fs/hpfs/dnode.c.old   2005-01-07 00:51:23.0 
+0100
+++ linux-2.6.10-mm2-full/fs/hpfs/dnode.c   2005-01-07 00:52:44.0 
+0100
@@ -78,7 +78,7 @@
return;
 }
 
-void hpfs_pos_subst(loff_t *p, loff_t f, loff_t t)
+static void hpfs_pos_subst(loff_t *p, loff_t f, loff_t t)
 {
if (*p == f) *p = t;
 }
@@ -88,7 +88,7 @@
if ((*p & ~0x3f) == (f & ~0x3f)) *p = (t & ~0x3f) | (*p & 0x3f);
 }*/
 
-void hpfs_pos_ins(loff_t *p, loff_t d, loff_t c)
+static void hpfs_pos_ins(loff_t *p, loff_t d, loff_t c)
 {
if ((*p & ~0x3f) == (d & ~0x3f) && (*p & 0x3f) >= (d & 0x3f)) {
int n = (*p & 0x3f) + c;
@@ -97,7 +97,7 @@
}
 }
 
-void hpfs_pos_del(loff_t *p, loff_t d, loff_t c)
+static void hpfs_pos_del(loff_t *p, loff_t d, loff_t c)
 {
if ((*p & ~0x3f) == (d & ~0x3f) && (*p & 0x3f) >= (d & 0x3f)) {
int n = (*p & 0x3f) - c;
@@ -189,7 +189,8 @@
 
 /* Delete dirent and don't care about its subtree */
 
-void hpfs_delete_de(struct super_block *s, struct dnode *d, struct hpfs_dirent 
*de)
+static void hpfs_delete_de(struct super_block *s, struct dnode *d,
+  struct hpfs_dirent *de)
 {
if (de->last) {
hpfs_error(s, "attempt to delete last dirent in dnode %08x", 
d->self);
@@ -221,8 +222,9 @@
 
 /* Add an 

[2.6 patch] fs/hfs/: misc cleanups

2005-01-31 Thread Adrian Bunk
This patch contains the following cleanups:
- make needlessly global code static
- super.c: remove the unused global variable hfs_version

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

---

 fs/hfs/brec.c|   10 +++---
 fs/hfs/btree.h   |3 ---
 fs/hfs/catalog.c |2 +-
 fs/hfs/dir.c |   20 ++--
 fs/hfs/extent.c  |4 ++--
 fs/hfs/hfs_fs.h  |   10 --
 fs/hfs/inode.c   |   13 -
 fs/hfs/super.c   |4 +---
 8 files changed, 29 insertions(+), 37 deletions(-)

This patch was already sent on:
- 7 Jan 2005

--- linux-2.6.10-mm2-full/fs/hfs/btree.h.old2005-01-07 00:09:58.0 
+0100
+++ linux-2.6.10-mm2-full/fs/hfs/btree.h2005-01-07 00:11:29.0 
+0100
@@ -111,9 +111,6 @@
 extern u16 hfs_brec_keylen(struct hfs_bnode *, u16);
 extern int hfs_brec_insert(struct hfs_find_data *, void *, int);
 extern int hfs_brec_remove(struct hfs_find_data *);
-extern struct hfs_bnode *hfs_bnode_split(struct hfs_find_data *);
-extern int hfs_brec_update_parent(struct hfs_find_data *);
-extern int hfs_btree_inc_height(struct hfs_btree *);
 
 /* bfind.c */
 extern int hfs_find_init(struct hfs_btree *, struct hfs_find_data *);
--- linux-2.6.10-mm2-full/fs/hfs/brec.c.old 2005-01-07 00:10:19.0 
+0100
+++ linux-2.6.10-mm2-full/fs/hfs/brec.c 2005-01-07 00:11:49.0 +0100
@@ -10,6 +10,10 @@
 
 #include "btree.h"
 
+static struct hfs_bnode *hfs_bnode_split(struct hfs_find_data *fd);
+static int hfs_brec_update_parent(struct hfs_find_data *fd);
+static int hfs_btree_inc_height(struct hfs_btree *tree);
+
 /* Get the length and offset of the given record in the given node */
 u16 hfs_brec_lenoff(struct hfs_bnode *node, u16 rec, u16 *off)
 {
@@ -211,7 +215,7 @@
return 0;
 }
 
-struct hfs_bnode *hfs_bnode_split(struct hfs_find_data *fd)
+static struct hfs_bnode *hfs_bnode_split(struct hfs_find_data *fd)
 {
struct hfs_btree *tree;
struct hfs_bnode *node, *new_node;
@@ -320,7 +324,7 @@
return new_node;
 }
 
-int hfs_brec_update_parent(struct hfs_find_data *fd)
+static int hfs_brec_update_parent(struct hfs_find_data *fd)
 {
struct hfs_btree *tree;
struct hfs_bnode *node, *new_node, *parent;
@@ -418,7 +422,7 @@
return 0;
 }
 
-int hfs_btree_inc_height(struct hfs_btree *tree)
+static int hfs_btree_inc_height(struct hfs_btree *tree)
 {
struct hfs_bnode *node, *new_node;
struct hfs_bnode_desc node_desc;
--- linux-2.6.10-mm2-full/fs/hfs/catalog.c.old  2005-01-07 00:12:05.0 
+0100
+++ linux-2.6.10-mm2-full/fs/hfs/catalog.c  2005-01-07 00:12:13.0 
+0100
@@ -33,7 +33,7 @@
}
 }
 
-int hfs_cat_build_record(hfs_cat_rec *rec, u32 cnid, struct inode *inode)
+static int hfs_cat_build_record(hfs_cat_rec *rec, u32 cnid, struct inode 
*inode)
 {
__be32 mtime = hfs_mtime();
 
--- linux-2.6.10-mm2-full/fs/hfs/dir.c.old  2005-01-07 00:12:28.0 
+0100
+++ linux-2.6.10-mm2-full/fs/hfs/dir.c  2005-01-07 00:14:20.0 +0100
@@ -17,8 +17,8 @@
 /*
  * hfs_lookup()
  */
-struct dentry *hfs_lookup(struct inode *dir, struct dentry *dentry,
- struct nameidata *nd)
+static struct dentry *hfs_lookup(struct inode *dir, struct dentry *dentry,
+struct nameidata *nd)
 {
hfs_cat_rec rec;
struct hfs_find_data fd;
@@ -51,7 +51,7 @@
 /*
  * hfs_readdir
  */
-int hfs_readdir(struct file *filp, void *dirent, filldir_t filldir)
+static int hfs_readdir(struct file *filp, void *dirent, filldir_t filldir)
 {
struct inode *inode = filp->f_dentry->d_inode;
struct super_block *sb = inode->i_sb;
@@ -177,8 +177,8 @@
  * a directory and return a corresponding inode, given the inode for
  * the directory and the name (and its length) of the new file.
  */
-int hfs_create(struct inode *dir, struct dentry *dentry, int mode,
-  struct nameidata *nd)
+static int hfs_create(struct inode *dir, struct dentry *dentry, int mode,
+ struct nameidata *nd)
 {
struct inode *inode;
int res;
@@ -207,7 +207,7 @@
  * in a directory, given the inode for the parent directory and the
  * name (and its length) of the new directory.
  */
-int hfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
+static int hfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
 {
struct inode *inode;
int res;
@@ -236,7 +236,7 @@
  * file, given the inode for the parent directory and the name
  * (and its length) of the existing file.
  */
-int hfs_unlink(struct inode *dir, struct dentry *dentry)
+static int hfs_unlink(struct inode *dir, struct dentry *dentry)
 {
struct inode *inode;
int res;
@@ -262,7 +262,7 @@
  * directory, given the inode for the parent directory and the name
  * (and its length) of the existing directory.
  */
-int hfs_rmdir(struct inode *dir, struct dentry *dentry)
+static int hfs_rmdir(struct inode *dir, struct 

[2.6 patch] i386/math-emu/: misc cleanups

2005-01-31 Thread Adrian Bunk
This patch contains the following cleanups:
- make needlessly global code static
- #if 0 unused code

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

---

 arch/i386/math-emu/errors.c   |2 ++
 arch/i386/math-emu/fpu_aux.c  |2 +-
 arch/i386/math-emu/fpu_proto.h|2 --
 arch/i386/math-emu/load_store.c   |2 +-
 arch/i386/math-emu/reg_constant.c |   10 ++
 arch/i386/math-emu/reg_constant.h |6 --
 6 files changed, 10 insertions(+), 14 deletions(-)

This patch was already sent on:
- 16 Jan 2005

--- linux-2.6.11-rc1-mm1-full/arch/i386/math-emu/fpu_proto.h.old
2005-01-16 05:43:39.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/math-emu/fpu_proto.h2005-01-16 
05:44:22.0 +0100
@@ -2,7 +2,6 @@
 #define _FPU_PROTO_H
 
 /* errors.c */
-extern void Un_impl(void);
 extern void FPU_illegal(void);
 extern void FPU_printall(void);
 asmlinkage void FPU_exception(int n);
@@ -41,7 +40,6 @@
 extern void fdivrp(void);
 extern void fdivp_(void);
 /* fpu_aux.c */
-extern void fclex(void);
 extern void finit(void);
 extern void finit_(void);
 extern void fstsw_(void);
--- linux-2.6.11-rc1-mm1-full/arch/i386/math-emu/errors.c.old   2005-01-16 
05:43:53.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/math-emu/errors.c   2005-01-16 
05:44:07.0 +0100
@@ -34,6 +34,7 @@
 /* */
 
 
+#if 0
 void Un_impl(void)
 {
   u_char byte1, FPU_modrm;
@@ -69,6 +70,7 @@
   EXCEPTION(EX_Invalid);
 
 }
+#endif  /*  0  */
 
 
 /*
--- linux-2.6.11-rc1-mm1-full/arch/i386/math-emu/fpu_aux.c.old  2005-01-16 
05:44:30.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/math-emu/fpu_aux.c  2005-01-16 
05:44:35.0 +0100
@@ -21,7 +21,7 @@
 {
 }
 
-void fclex(void)
+static void fclex(void)
 {
   partial_status &= ~(SW_Backward|SW_Summary|SW_Stack_Fault|SW_Precision|
   SW_Underflow|SW_Overflow|SW_Zero_Div|SW_Denorm_Op|
--- linux-2.6.11-rc1-mm1-full/arch/i386/math-emu/load_store.c.old   
2005-01-16 05:44:50.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/math-emu/load_store.c   2005-01-16 
05:45:08.0 +0100
@@ -53,7 +53,7 @@
   14, 0, 94, 10,  2, 10,  2,  8
 };
 
-u_char const data_sizes_32[32] = {
+static u_char const data_sizes_32[32] = {
   4,  4,  8,  2,  0,  0,  0,  0,
   4,  4,  8,  2,  4,  4,  8,  2,
   28, 0,108, 10,  2, 10,  0,  8,  
--- linux-2.6.11-rc1-mm1-full/arch/i386/math-emu/reg_constant.h.old 
2005-01-16 05:45:27.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/math-emu/reg_constant.h 2005-01-16 
05:47:03.0 +0100
@@ -12,16 +12,10 @@
 #include "fpu_emu.h"
 
 extern FPU_REG const CONST_1;
-extern FPU_REG const CONST_2;
-extern FPU_REG const CONST_HALF;
-extern FPU_REG const CONST_L2T;
-extern FPU_REG const CONST_L2E;
 extern FPU_REG const CONST_PI;
 extern FPU_REG const CONST_PI2;
 extern FPU_REG const CONST_PI2extra;
 extern FPU_REG const CONST_PI4;
-extern FPU_REG const CONST_LG2;
-extern FPU_REG const CONST_LN2;
 extern FPU_REG const CONST_Z;
 extern FPU_REG const CONST_PINF;
 extern FPU_REG const CONST_INF;
--- linux-2.6.11-rc1-mm1-full/arch/i386/math-emu/reg_constant.c.old 
2005-01-16 05:45:41.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/math-emu/reg_constant.c 2005-01-16 
05:47:20.0 +0100
@@ -21,15 +21,17 @@
 ((EXTENDED_Ebias+(e)) | ((SIGN_##s != 0)*0x8000)) }
 
 FPU_REG const CONST_1= MAKE_REG(POS, 0, 0x, 0x8000);
+#if 0
 FPU_REG const CONST_2= MAKE_REG(POS, 1, 0x, 0x8000);
 FPU_REG const CONST_HALF = MAKE_REG(POS, -1, 0x, 0x8000);
-FPU_REG const CONST_L2T  = MAKE_REG(POS, 1, 0xcd1b8afe, 0xd49a784b);
-FPU_REG const CONST_L2E  = MAKE_REG(POS, 0, 0x5c17f0bc, 0xb8aa3b29);
+#endif  /*  0  */
+static FPU_REG const CONST_L2T  = MAKE_REG(POS, 1, 0xcd1b8afe, 0xd49a784b);
+static FPU_REG const CONST_L2E  = MAKE_REG(POS, 0, 0x5c17f0bc, 0xb8aa3b29);
 FPU_REG const CONST_PI   = MAKE_REG(POS, 1, 0x2168c235, 0xc90fdaa2);
 FPU_REG const CONST_PI2  = MAKE_REG(POS, 0, 0x2168c235, 0xc90fdaa2);
 FPU_REG const CONST_PI4  = MAKE_REG(POS, -1, 0x2168c235, 0xc90fdaa2);
-FPU_REG const CONST_LG2  = MAKE_REG(POS, -2, 0xfbcff799, 0x9a209a84);
-FPU_REG const CONST_LN2  = MAKE_REG(POS, -1, 0xd1cf79ac, 0xb17217f7);
+static FPU_REG const CONST_LG2  = MAKE_REG(POS, -2, 0xfbcff799, 0x9a209a84);
+static FPU_REG const CONST_LN2  = MAKE_REG(POS, -1, 0xd1cf79ac, 0xb17217f7);
 
 /* Extra bits to take pi/2 to more than 128 bits precision. */
 FPU_REG const CONST_PI2extra = MAKE_REG(NEG, -66,

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] kernel/timer.c: make two variables static

2005-01-31 Thread Adrian Bunk
This patch makes two needlessly global variables static.

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

---

diffstat output:
 include/linux/timex.h |2 --
 kernel/timer.c|4 ++--
 2 files changed, 2 insertions(+), 4 deletions(-)

This patch was already sent on:
- 12 Dec 2004

--- linux-2.6.10-rc2-mm4-full/include/linux/timex.h.old 2004-12-12 
03:32:15.0 +0100
+++ linux-2.6.10-rc2-mm4-full/include/linux/timex.h 2004-12-12 
03:32:54.0 +0100
@@ -240,9 +240,7 @@
 extern long time_maxerror; /* maximum error */
 extern long time_esterror; /* estimated error */
 
-extern long time_phase;/* phase offset (scaled us) */
 extern long time_freq; /* frequency offset (scaled ppm) */
-extern long time_adj;  /* tick adjust (scaled 1 / HZ) */
 extern long time_reftime;  /* time at last adjustment (s) */
 
 extern long time_adjust;   /* The amount of adjtime left */
--- linux-2.6.10-rc2-mm4-full/kernel/timer.c.old2004-12-12 
03:33:02.0 +0100
+++ linux-2.6.10-rc2-mm4-full/kernel/timer.c2004-12-12 03:33:20.0 
+0100
@@ -631,10 +631,10 @@
 long time_precision = 1;   /* clock precision (us) */
 long time_maxerror = NTP_PHASE_LIMIT;  /* maximum error (us)   */
 long time_esterror = NTP_PHASE_LIMIT;  /* estimated error (us) */
-long time_phase;   /* phase offset (scaled us) */
+static long time_phase;/* phase offset (scaled us) 
*/
 long time_freq = (((NSEC_PER_SEC + HZ/2) % HZ - HZ/2) << SHIFT_USEC) / 
NSEC_PER_USEC;
/* frequency offset (scaled ppm)*/
-long time_adj; /* tick adjust (scaled 1 / HZ)  */
+static long time_adj;  /* tick adjust (scaled 1 / HZ)  */
 long time_reftime; /* time at last adjustment (s)  */
 long time_adjust;
 long time_next_adjust;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] i386/x86_64 process.c: make hlt_counter static

2005-01-31 Thread Adrian Bunk
This patch makes a needlessly global variable static.

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

---

 arch/i386/kernel/process.c   |2 +-
 arch/x86_64/kernel/process.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

This patch was alread sent on:
- 16 Jan 2005

--- linux-2.6.10-rc2-mm4-full/arch/i386/kernel/process.c.old2004-12-06 
01:25:27.0 +0100
+++ linux-2.6.10-rc2-mm4-full/arch/i386/kernel/process.c2004-12-06 
01:25:38.0 +0100
@@ -60,7 +60,7 @@
 
 asmlinkage void ret_from_fork(void) __asm__("ret_from_fork");
 
-int hlt_counter;
+static int hlt_counter;
 
 unsigned long boot_option_idle_override = 0;
 EXPORT_SYMBOL(boot_option_idle_override);
--- linux-2.6.10-rc2-mm4-full/arch/x86_64/kernel/process.c.old  2004-12-06 
01:26:17.0 +0100
+++ linux-2.6.10-rc2-mm4-full/arch/x86_64/kernel/process.c  2004-12-06 
01:26:28.0 +0100
@@ -53,7 +53,7 @@
 
 unsigned long kernel_thread_flags = CLONE_VM | CLONE_UNTRACED;
 
-atomic_t hlt_counter = ATOMIC_INIT(0);
+static atomic_t hlt_counter = ATOMIC_INIT(0);
 
 unsigned long boot_option_idle_override = 0;
 EXPORT_SYMBOL(boot_option_idle_override);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] i386/mach-default/topology.c: make cpu_devices static

2005-01-31 Thread Adrian Bunk
This patch makes a needlessly global struct static.

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

---

 arch/i386/mach-default/topology.c |2 +-
 include/asm-i386/cpu.h|1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

This patch was already sent on:
- 16 Jan 2005

--- linux-2.6.11-rc1-mm1-full/include/asm-i386/cpu.h.old2005-01-16 
05:41:55.0 +0100
+++ linux-2.6.11-rc1-mm1-full/include/asm-i386/cpu.h2005-01-16 
05:42:09.0 +0100
@@ -12,7 +12,6 @@
 struct i386_cpu {
struct cpu cpu;
 };
-extern struct i386_cpu cpu_devices[NR_CPUS];
 extern int arch_register_cpu(int num);
 #ifdef CONFIG_HOTPLUG_CPU
 extern void arch_unregister_cpu(int);
--- linux-2.6.11-rc1-mm1-full/arch/i386/mach-default/topology.c.old 
2005-01-16 05:42:18.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/mach-default/topology.c 2005-01-16 
05:42:43.0 +0100
@@ -30,7 +30,7 @@
 #include 
 #include 
 
-struct i386_cpu cpu_devices[NR_CPUS];
+static struct i386_cpu cpu_devices[NR_CPUS];
 
 int arch_register_cpu(int num){
struct node *parent = 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: Bug: audio playing broke with my SCSI CD and DVD drives in 2.6.11-rc2-bk7 and beyond.

2005-01-31 Thread James Bottomley
On Tue, 2005-02-01 at 00:22 +0100, Jesper Juhl wrote:
> audio

Could you try the attached?

James

--- Begin Message ---
Jens Axboe wrote:
On Mon, Jan 31 2005, Douglas Gilbert wrote:
Jens Axboe wrote:
On Mon, Jan 31 2005, Fabio Coatti wrote:

Alle 09:00, lunedì 31 gennaio 2005, Jens Axboe ha scritto:

At this point k3b is stuck in D stat, needs reboot.
I was able to replicate this with a USB burner.
My system didn't need a reboot. The "D" state was locked
on "blk_execute_rq". The burner was still accessible via
sg.
The most likely suspect is the REQ_BLOCK_PC scsi changes. Can you try
2.6.11-rc2-mm1 with bk-scsi backed out? (attached)
just tried, right guess :)
backing out that patch the problem disappears.
Let me know if you need to narrow further that issue.

Doug, it looks like your REQ_BLOCK_PC changes are buggy. Let me know if
you cannot find the full post and I'll forward it to you.
Jens,
Hmm. Found the thread on lkml. I got an almost identical
lock up in k3b with a USB external cd/dvd drive recently.
My laptop didn't need rebooting (probably since the root
fs is one an ide disk).
That is a quite large patch that you referenced. I'll
try and replicate and report back.

My guess would be the scsi_lib changes, I would suggest you start there.
Indeed. I'm not sure what I was thinking in
scsi_io_completion(). This small reversion
fixes my k3b problem; tested with a USB external
burner.
Signed-off-by: Douglas Gilbert <[EMAIL PROTECTED]>


--- linux/drivers/scsi/scsi_lib.c	2005-01-31 17:46:31.0 +1000
+++ linux/drivers/scsi/scsi_lib.c2611r2b8_k3b	2005-01-31 22:46:04.0 +1000
@@ -692,6 +692,7 @@
 	int this_count = cmd->bufflen;
 	request_queue_t *q = cmd->device->request_queue;
 	struct request *req = cmd->request;
+	int clear_errors = 1;
 	struct scsi_sense_hdr sshdr;
 	int sense_valid = 0;
 	int sense_deferred = 0;
@@ -721,6 +722,7 @@
 	if (blk_pc_request(req)) { /* SG_IO ioctl from block level */
 		req->errors = result;
 		if (result) {
+			clear_errors = 0;
 			if (sense_valid) {
 /*
  * SG_IO wants current and deferred errors
@@ -745,11 +747,6 @@
 	cmd->request_buffer = NULL;
 	cmd->request_bufflen = 0;
 
-	if (blk_pc_request(req)) { /* SG_IO ioctl from block level */
-		scsi_end_request(cmd, 1, good_bytes, 0);
-		return;
-	}
-
 	/*
 	 * Next deal with any sectors which we were able to correctly
 	 * handle.
@@ -759,7 +756,8 @@
 	  req->nr_sectors, good_bytes));
 		SCSI_LOG_HLCOMPLETE(1, printk("use_sg is %d\n", cmd->use_sg));
 
-		req->errors = 0;
+		if (clear_errors)
+			req->errors = 0;
 		/*
 		 * If multiple sectors are requested in one buffer, then
 		 * they will have been finished off by the first command.
--- End Message ---


2.6.11-rc2-mm2 (& bk9) - rowdy little warn in drivers/usb/input/hid-input.c

2005-01-31 Thread Cal
With 2.6.11-rc2-mm2 & 2.6.11-rc2-bk9 and usb mouse, the warn("event 
field not found") in drivers/usb/input/hid-input.c is hyperactive 
whenever the mouse moves.

hihone kernel: drivers/usb/input/hid-input.c: event field not found
hihone last message repeated 619 times
hihone last message repeated 919 times
hihone last message repeated 1325 times
hihone last message repeated 1045 times
On the deviant case, both type and code appear to have the value 4 (if 
that helps).  The mouse reports as
hihone kernel: input: USB HID v1.00 Mouse [Microsoft Microsoft 
IntelliMouse Optical] on usb-:00:07.2-2

cheers, Cal
(not subscribed, pls cc if 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/


Re: [RFC][PATCH] swsusp: do not use higher order memory allocations [update]

2005-01-31 Thread Rafael J. Wysocki
Hi,

On Monday, 31 of January 2005 00:19, Rafael J. Wysocki wrote:
> Hi,
> 
> The following patch is (yet) an(other) attempt to eliminate the need for 
> using higher
> order memory allocations on resume.  It accomplishes this by replacing the 
> array
> of page backup entries with a list, so it is only necessary to allocate 
> individual
> memory pages.  This approach makes it possible to avoid relocating many memory
> pages on resume (as a result, much less memory is used) and to simplify
> the assembly code that restores the image.
> 
> The patch is a complement to the patch that I sent some time ago as "swsusp: 
> do not
> use higher order memory allocations on suspend".  It is against 2.6.11-rc2 - 
> on top
> of the previous patch and on top of the "x86_64: Speed up suspend" patch 
> which are
> availble at:
> http://www.sisk.pl/kernel/patches/2.6.11-rc2/swsusp-use-list-suspend-v2.patch
> and at:
> http://www.sisk.pl/kernel/patches/2.6.11-rc2/x86_64-Speed-up-suspend.patch
> respectively.  The patch itself is available at:
> http://www.sisk.pl/kernel/patches/2.6.11-rc2/swsusp-use-list-resume-v1.patch
> and there is a consolidated patch against 2.6.11-rc2 at:
> http://www.sisk.pl/kernel/patches/2.6.11-rc2/2.6.11-rc2-swsusp-use-list.patch

I have updated the patches to include a bugfix from Pavel Machek (thanks, 
Pavel!).
Affected are the "suspend" patch and the "consolidated" patch.  The updated 
patches
are available at:
http://www.sisk.pl/kernel/patches/2.6.11-rc2/swsusp-use-list-suspend-v3.patch
http://www.sisk.pl/kernel/patches/2.6.11-rc2/2.6.11-rc2-swsusp-use-list-v2.patch
respectively.  The other patches remain unchanged.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] OpenBSD Networking-related randomization port

2005-01-31 Thread linux
> could you please also react to this feedback:
>
>   http://marc.theaimsgroup.com/?l=linux-kernel=110698371131630=2
> 
> to quote a couple of key points from that very detailed security
> analysis:
> 
> " I'm not sure how the OpenBSD code is better in any way.  (Notice that
>   it uses the same "half_md4_transform" as Linux; you just added another
>   copy.) Is there a design note on how the design was chosen? "

Just note that, in addition to the security aspects, there are also a
whole set of multiprocessor issues.  OpenBSD added SMP support in June
2004, and it looks like this code dates back to before that.  It might
be worth looking at what OpenBSD does now.

Note that I have NOT looked at the patch other than the TCP ISN
generation.  However, given the condition of the ISN code, I am inclined
to take a "guilty until proven innocent" view of the rest of it.
Don't merge it until someone has really grokked it, not just kibitzed
about code style issues.

(The homebrew 15-bit block cipher in this code does show how much the
world needs a small block cipher for some of these applications.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() && irqs_disabled()

2005-01-31 Thread Parag Warudkar
Forgot to attach ohci.h diff which is affected by this change as well.
Meanwhile, David Brownell suggested it would be much simpler to move the 
dma allocations to _probe and  deallocations to _remove.
I am working on it and so far haven't got it to work.

Andrew - What do you think? If you too feel allocating pci_pool for the 
legacy contexts (only disadvantage I see is that the pool will be 
allocated even if it is not used, that is if ISO_LISTEN_CHANNEL isn't 
called any time)  in _probe an removing it in _remove is a better thing 
to do, I will concentrate on getting that to work and we can forget 
about this patch. I feel there might be some reason why the current code 
treats the legacy IR and IT DMA ctxs differently (on-demand  
allocation).. Ben?

Parag
Parag Warudkar wrote:
Attached is the reworked patch to take care of Andrew's suggestions -
1) Allocate the work struct dynamically in struct ti_ohci during  
device probe, free it during device remove
2) In ohci1394_pci_remove, ensure queued work, if any, is flushed 
before the device is removed (As I understand, this should work for 
both device removal cases as well as module removal - correct?)
3) Rework the free_dma_rcv_ctx  - It is called in multiple contexts by 
different callers - teach it to free the dma according to caller's 
wish - either direct free where caller determines the context is safe 
to sleep OR delayed via schedule_work when caller wants to call it 
from a context where it cannot sleep.  So it now takes 2 extra 
arguments - method to free - direct or delayed and if it is to be  
freed delayed, an appropriate work_struct.

Andrew - flush_scheduled_work does not touch work which isn't 
shceduled - so I don't think INIT_WORK in setup is necessary. Let me 
know if I am missing something here. (I tried INIT_WORK in 
ochi1394_pci_probe and putting flush_scheduled_work in 
ohci1394_pci_remove - It did not result in calling the work function 
after I did rmmod, since it wasn't scheduled.)

Parag

--- drivers/ieee1394/ohci1394.c.orig2004-12-24 16:35:25.0 -0500
+++ drivers/ieee1394/ohci1394.c 2005-01-30 20:00:42.0 -0500
@@ -99,6 +99,7 @@
#include 
#include 
#include 
+#include 
#include 
#include 
@@ -161,6 +162,10 @@
#define PRINT(level, fmt, args...) \
printk(level "%s: fw-host%d: " fmt "\n" , OHCI1394_DRIVER_NAME, ohci->host->id 
, ## args)
+/* Instruct free_dma_rcv_ctx how to free dma pools */
+#define OHCI_FREE_DMA_CTX_DIRECT 0
+#define OHCI_FREE_DMA_CTX_DELAYED 1
+
static char version[] __devinitdata =
"$Rev: 1223 $ Ben Collins <[EMAIL PROTECTED]>";
@@ -176,7 +181,8 @@
 enum context_type type, int ctx, int num_desc,
 int buf_size, int split_buf_size, int 
context_base);
static void stop_dma_rcv_ctx(struct dma_rcv_ctx *d);
-static void free_dma_rcv_ctx(struct dma_rcv_ctx *d);
+static void free_dma_rcv_ctx(struct dma_rcv_ctx *d , int method,
+struct work_struct* work);
static int alloc_dma_trm_ctx(struct ti_ohci *ohci, struct dma_trm_ctx *d,
 enum context_type type, int ctx, int num_desc,
@@ -184,6 +190,8 @@
static void ohci1394_pci_remove(struct pci_dev *pdev);
+static void ohci_free_irlc_pci_pool(void* data);
+
#ifndef __LITTLE_ENDIAN
static unsigned hdr_sizes[] =
{
@@ -1117,7 +1125,8 @@
if (ohci->ir_legacy_channels == 0) {
stop_dma_rcv_ctx(>ir_legacy_context);
-   free_dma_rcv_ctx(>ir_legacy_context);
+   INIT_WORK(ohci->irlc_free_dma, ohci_free_irlc_pci_pool, 
ohci->ir_legacy_context.prg_pool);
+   free_dma_rcv_ctx(>ir_legacy_context, 
OHCI_FREE_DMA_CTX_DELAYED, ohci->irlc_free_dma);
DBGMSG("ISO receive legacy context deactivated");
}
break;
@@ -2876,7 +2885,8 @@
}
-static void free_dma_rcv_ctx(struct dma_rcv_ctx *d)
+static void free_dma_rcv_ctx(struct dma_rcv_ctx *d, int method,
+   struct work_struct* work)
{
int i;
struct ti_ohci *ohci = d->ohci;
@@ -2903,8 +2913,20 @@
pci_pool_free(d->prg_pool, d->prg_cpu[i], 
d->prg_bus[i]);
OHCI_DMA_FREE("consistent dma_rcv prg[%d]", i);
}
-   pci_pool_destroy(d->prg_pool);
-   OHCI_DMA_FREE("dma_rcv prg pool");
+   if(method == OHCI_FREE_DMA_CTX_DIRECT)
+   {
+   pci_pool_destroy(d->prg_pool);
+   OHCI_DMA_FREE("dma_rcv prg pool");
+   }
+   
+   else if(method == OHCI_FREE_DMA_CTX_DELAYED)
+   {
+   schedule_work(work);
+   }
+
+   else
+   PRINT(KERN_ERR, "Invalid method passed - %d", method);
+

Re: 2.6.10-ac11 announcement?

2005-01-31 Thread Dave Jones
On Tue, Feb 01, 2005 at 12:02:49AM +0100, Rafael J. Wysocki wrote:

 > > Nothing terribly exciting here security wise but various bugs for problems
 > > people have been hitting that are now fixed upstream, and also the ULi
 > > tulip variant should now work. If you are running IPv6 you may well want
 > > the networking fixes.
 > 
 > Is there a broken-out version of the patch available?  It reboots at startup
 > (before it mounts the root fs) on my dual-Opteron box (SuSE 9.2), but -ac10
 > works fine, evidently.  I could check which changeset actually caused this to
 > happen, but I'd need to separate them.

I see this happening too. It seems to go away when I back out
this chunk..

Dave

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.10/mm/mmap.c linux-2.6.10/mm/mmap.c
--- linux.vanilla-2.6.10/mm/mmap.c  2004-12-25 21:15:46.0 +
+++ linux-2.6.10/mm/mmap.c  2005-01-13 17:24:50.0 +
@@ -1346,7 +1346,12 @@
address += 4 + PAGE_SIZE - 1;
address &= PAGE_MASK;
grow = (address - vma->vm_end) >> PAGE_SHIFT;
-
+   
+   /* Someone beat us to it */
+   if (grow <= 0) {
+   anon_vma_unlock(vma);
+   return 0;
+   }
/* Overcommit.. */
if (security_vm_enough_memory(grow)) {
anon_vma_unlock(vma);
@@ -1409,6 +1421,11 @@
address &= PAGE_MASK;
grow = (vma->vm_start - address) >> PAGE_SHIFT;
 
+   /* Someone beat us to it */
+   if (grow <= 0) {
+   anon_vma_unlock(vma);
+   return 0;
+   }
/* Overcommit.. */
if (security_vm_enough_memory(grow)) {
anon_vma_unlock(vma);

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


Re: Fw: Re: 2.6.11-rc2-mm2

2005-01-31 Thread Benjamin Herrenschmidt
On Mon, 2005-01-31 at 09:23 +, Sean Neakums wrote:

> Not to worry.  I only ended up with modular radeonfb when I was trying
> to narrow down the cause of the boot hang.
> 
> [...]
> > radeonfb built-in operations seem to be ok on my PowerBook3,5 (ATI M9
> > based), I'll try on a PowerBook5,4 (same as yours) tomorrow hopefully.
> >
> > Does the machine hang with the screen completely cleared ? Do you see
> > the penguin logo ? Did you try just using pmac_defconfig ?
> 
> I seem some openpic messages and then the screen is cleared
> completely.  Alas, I have the logo disabled in my configuration.  I'll
> give pmac_defconfig a go this evening.
> 
> I forgot to mention, after radeonfb failed to load as above, I fired
> up X.  The display was unreadably corrupted, although the hardware
> cursor was fine and I could launch programs.  Killing the X server did
> not return me to the console.  I neglected to check if the machine was
> still accessible via the network.

X tend to be upset on macs if radeonfb hasn't pre-initialized the chip.
I think I fixed all of these problems in Xorg CVS tho.

Ben.


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


  1   2   3   4   5   6   >