Re: [PATCH] relayfs redux, part 4
On Wed, 9 Feb 2005 20:49:36 -0600, Tom Zanussi <[EMAIL PROTECTED]> wrote:
> +static int relayfs_create_entry(const char *name, struct dentry *parent,
> + int mode, struct rchan *chan,
> + struct dentry **dentry)
> +{
> + struct qstr qname;
> + struct dentry *d;
> + struct inode *inode;
> + int error = 0;
> +
> + BUG_ON(!(S_ISREG(mode) || S_ISDIR(mode)));
> +
> + error = simple_pin_fs("relayfs", _mount,
> _mount_count);
> + if (error) {
> + printk(KERN_ERR "Couldn't mount relayfs: errcode %d\n",
> error);
> + return error;
> + }
> +
> + qname.name = name;
> + qname.len = strlen(name);
> + qname.hash = full_name_hash(name, qname.len);
> +
> + if (!parent)
> + if (relayfs_mount && relayfs_mount->mnt_sb)
> + parent = relayfs_mount->mnt_sb->s_root;
Please move the nested if statement to the parent expression. The
!parent part is always evaluated first.
> +static struct inode *relayfs_alloc_inode(struct super_block *sb)
> +{
> + struct relayfs_inode_info *p;
> + p = (struct relayfs_inode_info
> *)kmem_cache_alloc(relayfs_inode_cachep,
> + SLAB_KERNEL);
Please drop the spurious cast from void *.
Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Spontaneous reboot with 2.6.10 and NFSD
I hit an obscure bug last night when trying to copy files from an nfs client to my nfs server. The server is a P3/800 with three IDE disks in software RAID5 running vanilla 2.6.10 and Debian Sarge. The network is local 100Mbit/s switched ethernet. The server exports a 220 gig partition which contains a lot of data. Oh, kernel configs and stuff from the server can be found from: http://www.holviala.com/~kimmy/crash/ Anyway, I mount the export to a Linux client (tried with a few with different 2.6 kernels and distros) and then start copying files from clients CDROM to the server through NFS. After copying a few small files, the first big one reboots the server. There are no log entries, and the server has no local console so I don't know what happens. This is reproduceable 100% of the time. To narrow down the problem, I've tried the following: - copied files from a different client running Gentoo: reboot - exported a non-raided partition (hdc9) and tried that: reboot - switched 2.6.10 to 2.6.11-rc3: reboot, but it took longer I hope it's just something that I've done, but this server has been in use for a long time now without any problems, and I haven't touched it for a while. So, if anyone knows what's wrong, or can tell me a way to debug the situation more I'd be grateful. The server is in a place where it's nearly impossible to have a local console - I could probably use a serial one if necessary for debugging. Kim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] relayfs redux, part 4
Hi Tom,
On Wed, 9 Feb 2005 20:49:36 -0600, Tom Zanussi <[EMAIL PROTECTED]> wrote:
> +static inline struct page **alloc_page_array(int size, int *page_count)
> +{
> + int n_pages;
> + struct page **page_array;
> +
> + size = PAGE_ALIGN(size);
> + n_pages = size >> PAGE_SHIFT;
> +
> + page_array = kcalloc(n_pages, sizeof(struct page *), GFP_KERNEL);
> + if (!page_array)
> + return NULL;
> + *page_count = n_pages;
> +
> + return page_array;
> +}
[snip]
> +static int populate_page_array(struct page **page_array, int page_count)
> +{
> + int i;
> +
> + for (i = 0; i < page_count; i++) {
> + page_array[i] = alloc_page(GFP_KERNEL);
> + if (unlikely(!page_array[i])) {
> + depopulate_page_array(page_array, i);
> + return -ENOMEM;
> + }
> + }
> + return 0;
> +}
> +
> +/**
> + * relay_alloc_rchan_buf - allocate a channel buffer
> + * @size: total size of the buffer
> + * @page_array: receives a pointer to the buffer's page array
> + * @page_count: receives the number of pages allocated
> + *
> + * Returns a pointer to the resulting buffer, NULL if unsuccessful
> + */
> +void *relay_alloc_rchan_buf(unsigned long size, struct page ***page_array,
> + int *page_count)
> +{
> + void *mem;
> +
> + *page_array = alloc_page_array(size, page_count);
> + if (!*page_array)
> + return NULL;
> +
> + if (populate_page_array(*page_array, *page_count)) {
> + kfree(*page_array);
> + *page_array = NULL;
> + return NULL;
> + }
[snip]
Please consider inlining alloc_page_array() and populate_page_array()
into relay_alloc_rchan_buf() as they're only used once. You'd get rid
of passing page_count as a pointer this way. If inlining is
unacceptable, please at least move the n_pages calculation to
relay_alloc_rchan_buf() to make the API more sane.
I think relay_alloc_rchan_buf also would benefit from goto-styled
error handling.
Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How to retrieve version from kernel source (the right way)?
Hi.
Sam Ravnborg wrote:
But... what is the right way to do this?
I think you are looking for:
make kernelrelease
[EMAIL PROTECTED] linux-2.6.10 $ make kernelrelease
make: *** No rule to make target `kernelrelease'. Stop.
[EMAIL PROTECTED] linux-2.6.10 $ cd ..
[EMAIL PROTECTED] src $ cd linux-2.4.28
[EMAIL PROTECTED] linux-2.4.28 $ make kernelrelease
make: *** No rule to make target `kernelrelease'. Stop.
[EMAIL PROTECTED] linux-2.4.28 $
I don't think this will help.
Including the kernel's Makefile also is no option, I think ("rulespace
pollution").
Bye, Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/8] lib/sort: turn off self-test
On Mon, 31 Jan 2005 09:03:44 -0800, Matt Mackall <[EMAIL PROTECTED]> wrote: > It's a nice self-contained unit test. It's here because I ran into a > strange regparm-related bug when developing the code in userspace and > I wanted to be sure that it was easy to diagnose in the field if a > similar bug appeared in the future. I actually think that more code > ought to have such tests, so long as they don't obscure the code in > question. Unit tests are nice and your approach is wrong. The test does not belong in the implementation for two reasons: it hurts readability of the actual code and the _commented out_ test will not be maintained (dead code never is). I don't know if the maintainers are interested in unit tests but a better solution would be to put your test in a separate file and make sure it is always compiled and executed when CONFIG_UNIT_TEST is enabled. P.S. If the test fails, it probably should do BUG(). Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Linux Kernel Subversion Howto
Nicolas Pitre <[EMAIL PROTECTED]> said: > On Wed, 9 Feb 2005, Larry McVoy wrote: > > On Wed, Feb 09, 2005 at 05:06:02AM -0200, Alexandre Oliva wrote: > > > So you've somehow managed to trick most kernel developers into > > > granting you power over not only the BK history > > It's exactly the same as a file system. If you put some files into a > > file system does the file system creator owe you the knowledge of how > > those files are maintained in the file system? > No, this is not a good analogy at all. It is just fine. > If I don't want to use a certain filesystem, I mount it and copy the > files over to another filesystem. What users are interested in are the > files themselves of course, and the efficiency with which the filesystem > handles those files. BK is the efficient filesystem here, but anyone > should be able to freely copy files over to another filesystem without > any need for the filesystem internals knowledge. If the target > filesystem is 8.3 without lowercase support then so be it and people > will need to use a separate file to hold the extra details that cannot > berepresented natively in the target filesystem. But absolutely 0% of > the information is lost. But what you want is not the files, but the whole history of the filesystem (what was written/changed/deleted when). > Again, the BK value is in the efficiency and reliability it has to > handle a tree like the Linux kernel, not in the Linux kernel tree. It's > not necessary for you to give away that value in order to provide the > simple information needed to reconstruct the Linux tree structure as > people are asking. linux-2.6.10.tar.bz2, and you even get the -bk patches! -- 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] relayfs redux, part 4
Maneesh Soni writes:
> On Wed, Feb 09, 2005 at 08:49:36PM -0600, Tom Zanussi wrote:
> [..]
> > + */
> > +struct dentry *relayfs_create_file(const char *name, struct dentry
> > *parent,
> > + int mode, struct rchan *chan)
> > +{
> > + struct dentry *dentry;
> > + int error;
> > +
> > + if (!mode)
> > + mode = S_IRUSR;
> > + mode = (mode & S_IALLUGO) | S_IFREG;
> > +
> > + error = relayfs_create_entry(name, parent, mode, chan, );
>
>
> I think you missed GregKH's suggesstion to have relayfs_create_entry()
> return pointer to struct dentry, and reduce one parameter.
Yes, you're right - somehow I missed that one.
> > +
> > + if (unlikely(relay_buf_full(buf))) {
> > + return 0;
> > + buf->chan->cb->buf_full(buf);
>
>
> Typo? statement after return !
Yikes! Obviously I haven't tested the buffer full condition yet ;-)
Thanks for pointing these out.
Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
fix watchdog link order.
Comment says that softdog has to go last. Make it so. Signed-off-by: Dave Jones <[EMAIL PROTECTED]> --- linux-2.6.10/drivers/char/watchdog/Makefile~2005-02-10 01:48:32.0 -0500 +++ linux-2.6.10/drivers/char/watchdog/Makefile 2005-02-10 01:49:39.0 -0500 @@ -2,11 +2,6 @@ # Makefile for the WatchDog device drivers. # -# Only one watchdog can succeed. We probe the hardware watchdog -# drivers first, then the softdog driver. This means if your hardware -# watchdog dies or is 'borrowed' for some reason the software watchdog -# still gives you some cover. - obj-$(CONFIG_PCWATCHDOG) += pcwd.o obj-$(CONFIG_ACQUIRE_WDT) += acquirewdt.o obj-$(CONFIG_ADVANTECH_WDT) += advantechwdt.o @@ -24,7 +19,6 @@ obj-$(CONFIG_SH_WDT) += shwdt.o obj-$(CONFIG_S3C2410_WATCHDOG) += s3c2410_wdt.o obj-$(CONFIG_SA1100_WATCHDOG) += sa1100_wdt.o obj-$(CONFIG_EUROTECH_WDT) += eurotechwdt.o -obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o obj-$(CONFIG_W83877F_WDT) += w83877f_wdt.o obj-$(CONFIG_W83627HF_WDT) += w83627hf_wdt.o obj-$(CONFIG_SC520_WDT) += sc520_wdt.o @@ -39,3 +33,11 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb. obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o obj-$(CONFIG_IXP2000_WATCHDOG) += ixp2000_wdt.o obj-$(CONFIG_8xx_WDT) += mpc8xx_wdt.o + + +# Only one watchdog can succeed. We probe the hardware watchdog +# drivers first, then the softdog driver. This means if your hardware +# watchdog dies or is 'borrowed' for some reason the software watchdog +# still gives you some cover. +obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o + - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] relayfs redux, part 4
On Wed, Feb 09, 2005 at 08:49:36PM -0600, Tom Zanussi wrote:
[..]
> + */
> +struct dentry *relayfs_create_file(const char *name, struct dentry *parent,
> +int mode, struct rchan *chan)
> +{
> + struct dentry *dentry;
> + int error;
> +
> + if (!mode)
> + mode = S_IRUSR;
> + mode = (mode & S_IALLUGO) | S_IFREG;
> +
> + error = relayfs_create_entry(name, parent, mode, chan, );
I think you missed GregKH's suggesstion to have relayfs_create_entry()
return pointer to struct dentry, and reduce one parameter.
> +unsigned relay_switch_subbuf(struct rchan_buf *buf, unsigned length)
> +{
> + int cur_subbuf, prev_subbuf, subbufs_produced;
> + unsigned start = 0, padding = buf->chan->subbuf_size - buf->offset;
> +
> + if (unlikely(relay_buf_full(buf)))
> + return 0;
> +
> + subbufs_produced = atomic_read(>subbufs_produced);
> + cur_subbuf = prev_subbuf = subbufs_produced % buf->chan->n_subbufs;
> + buf->padding[cur_subbuf] = padding;
> +
> + atomic_inc(>subbufs_produced);
> +
> + if (waitqueue_active(>read_wait)) {
> + PREPARE_WORK(>wake_readers, wakeup_readers, buf);
> + schedule_delayed_work(>wake_readers, 1);
> + }
> +
> + if (unlikely(relay_buf_full(buf))) {
> + return 0;
> + buf->chan->cb->buf_full(buf);
Typo? statement after return !
Thanks
Maneesh
--
Maneesh Soni
Linux Technology Center,
IBM India Software Labs,
Bangalore, India
email: [EMAIL PROTECTED]
Phone: 91-80-25044990
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Linux Kernel Subversion Howto
Roman, please give up on importing 100% of the history. There's no point arguing something if you already know what the other person's answer will be. Larry will not change his mind under any currently foreseeable circumstances. Yes, there is "meta-data lockin" whether anyone at BitMover will admit it or not, but no that will not change. Linux survived in the past without much history, and if a replacement arrives, people can make the switch even with a degraded history. In very little time that switchover would seem as remote as the pre-BK times are now. Right now I don't see why its necessary to track the Linux repo in 100% detail for SCM development; There are plenty of other big trees to test on if you need every detail. Time spent tracking Linux are probably better spent improving an alternative SCM, most of which have plenty of wishlist items awaiting developers. For kernel development, yes it's painful for SCM developers or purists, but you can still work just fine with patches. Maintainers certainly benefit from BK, but for developers on the leaves of the hierarchy there's not that much difference. - Jim Bruce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Linux Kernel Subversion Howto
While I agree with your overall sentiment, please compare apples to apples regarding the license. You said: Larry McVoy wrote: I don't come here every month and ask for the GPL to be removed from some driver, that's essentially what you are doing and I think pretty much everyone is sick of it. The GPL doesn't state that "You and anyone at your company are not allowed to work on any operating system software under any non-GPL license." While that would be a perfectly valid license (just like the BK one), obviously it would generate a fairly steady stream of complaints. It's not like people have stopped complaining about how the GPL forces them to release any code they link with it. The boundary of a license will always create friction. This will be especially true as in the BK license, which was expressly designed to be irritating to a certain class of people (who now whine about it). A more directly relevant example would be the following: What if a new version of CVS had a license with a clause stating the following: "Any repository touched by CVS 1.2 may not be imported into into BK, unless you first remove all checkin comments. This is because we don't help people who are competing with us." Sure, that's a 100% legitimate license, and binding due to standard copyright goodness, yet I would expect BitMover people to complain about it. What we have now is exactly the same thing in reverse. Get used to the complaints because your license is achieving exactly what you meant it to do. - 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: 2.6.11-rc3-bk5: XFS: fcron: could not write() buf to disk: Resource temporarily unavailable
On Wed, Feb 09, 2005 at 05:44:54PM +0300, Alexander Y. Fomichev wrote:
> On Wednesday 09 February 2005 04:29, Nathan Scott wrote:
> > Is that an O_SYNC write, do you know? Or a write to an inode
> > with the sync flag set?
>
> Yes, it is O_SYNC, as i can see from fcron sources, and, no, kernel
OK, thanks.
> > I'm chasing down a problem similar to this atm, so far looks like
> > something in the generic VM code below sync_page_range is giving
> > back EAGAIN, and that is getting passed back out to userspace by
> > XFS. Not sure where/why/how its been caused yet though ... I'll
> > let you know once I have a fix or have found the culprit change.
Turns out it was actually XFS giving back this EAGAIN, indirectly -
and some of the generic VM routines have been tweaked recently to
propogate more sync write errors out to userspace. Try this patch,
it will fix your problem - we're still discussing if this is the
ideal fix, so something else may be merged in the end.
cheers.
--
Nathan
Index: test/fs/xfs/linux-2.6/xfs_super.c
===
--- test.orig/fs/xfs/linux-2.6/xfs_super.c
+++ test/fs/xfs/linux-2.6/xfs_super.c
@@ -348,6 +348,12 @@
if (sync)
flags |= FLUSH_SYNC;
VOP_IFLUSH(vp, flags, error);
+ if (error == EAGAIN) {
+ if (sync)
+ VOP_IFLUSH(vp, flags | FLUSH_LOG, error);
+ else
+ error = 0;
+ }
}
return -error;
Index: test/fs/xfs/xfs_vnodeops.c
===
--- test.orig/fs/xfs/xfs_vnodeops.c
+++ test/fs/xfs/xfs_vnodeops.c
@@ -3681,27 +3681,27 @@
{
xfs_inode_t *ip;
xfs_mount_t *mp;
+ xfs_inode_log_item_t *iip;
int error = 0;
ip = XFS_BHVTOI(bdp);
mp = ip->i_mount;
+ iip = ip->i_itemp;
if (XFS_FORCED_SHUTDOWN(mp))
return XFS_ERROR(EIO);
- /* Bypass inodes which have already been cleaned by
+ /*
+* Bypass inodes which have already been cleaned by
* the inode flush clustering code inside xfs_iflush
*/
if ((ip->i_update_core == 0) &&
- ((ip->i_itemp == NULL) ||
-!(ip->i_itemp->ili_format.ilf_fields & XFS_ILOG_ALL)))
+ ((iip == NULL) || !(iip->ili_format.ilf_fields & XFS_ILOG_ALL)))
return 0;
if (flags & FLUSH_LOG) {
- xfs_inode_log_item_t *iip = ip->i_itemp;
-
if (iip && iip->ili_last_lsn) {
- xlog_t *log = mp->m_log;
+ xlog_t *log = mp->m_log;
xfs_lsn_t sync_lsn;
int s, log_flags = XFS_LOG_FORCE;
@@ -3714,12 +3714,14 @@
if (flags & FLUSH_SYNC)
log_flags |= XFS_LOG_SYNC;
- return xfs_log_force(mp, iip->ili_last_lsn,
- log_flags);
+ error = xfs_log_force(mp, iip->ili_last_lsn, log_flags);
+ if (error)
+ return error;
}
}
- /* We make this non-blocking if the inode is contended,
+ /*
+* We make this non-blocking if the inode is contended,
* return EAGAIN to indicate to the caller that they
* did not succeed. This prevents the flush path from
* blocking on inodes inside another operation right
@@ -3728,8 +3730,11 @@
if (flags & FLUSH_INODE) {
int flush_flags;
+ if (!(flags & FLUSH_LOG))
+ error = EAGAIN;
+
if (xfs_ipincount(ip))
- return EAGAIN;
+ return error;
if (flags & FLUSH_SYNC) {
xfs_ilock(ip, XFS_ILOCK_SHARED);
@@ -3737,10 +3742,10 @@
} else if (xfs_ilock_nowait(ip, XFS_ILOCK_SHARED)) {
if (xfs_ipincount(ip) || !xfs_iflock_nowait(ip)) {
xfs_iunlock(ip, XFS_ILOCK_SHARED);
- return EAGAIN;
+ return error;
}
} else {
- return EAGAIN;
+ return error;
}
if (flags & FLUSH_SYNC)
Index: test/fs/xfs/linux-2.6/xfs_lrw.c
===
--- test.orig/fs/xfs/linux-2.6/xfs_lrw.c
+++ test/fs/xfs/linux-2.6/xfs_lrw.c
@@ -962,9 +962,9 @@
xfs_trans_set_sync(tp);
error = xfs_trans_commit(tp, 0, NULL);
xfs_iunlock(xip,
Re: [PATCH] arp_queue: serializing unlink + kfree_skb
On Thu, Feb 10, 2005 at 01:23:04AM -0300, Werner Almesberger wrote:
>
> What happens if the operation could return a value, but the user
> ignores it ? E.g. if I don't like smp_mb__*, could I just use
>
> atomic_inc_and_test(foo);
>
> instead of
>
> smp_mb__before_atomic_inc();
> atomic_inc(foo);
> smp_mb__after_atomic_dec();
Yes you can.
> ? If yes, is this a good idea ?
Dave mentioned that on sparc64, atomic_inc_and_test is much more
expensive than the second variant.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] OProfile: ARM/XScale1 PMU support fix
Richard Purdie provided a patch to fix support for XScale1 processors
(this is the PMU version i never had access to initially), we weren't
clearing the overflow flags after an overflow interrupt had triggered
resulting in no additional interrupts occuring. Additionally i've added
basic power management support.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
= arch/arm/oprofile/op_arm_model.h 1.1 vs edited =
--- 1.1/arch/arm/oprofile/op_arm_model.h2004-04-12 11:55:34 -06:00
+++ edited/arch/arm/oprofile/op_arm_model.h 2005-02-08 23:02:20 -07:00
@@ -24,6 +24,6 @@ struct op_arm_model_spec {
extern struct op_arm_model_spec op_xscale_spec;
#endif
-extern int pmu_init(struct oprofile_operations **ops, struct op_arm_model_spec
*spec);
+extern int __init pmu_init(struct oprofile_operations *ops, struct
op_arm_model_spec *spec);
extern void pmu_exit(void);
#endif /* OP_ARM_MODEL_H */
= arch/arm/oprofile/common.c 1.3 vs edited =
--- 1.3/arch/arm/oprofile/common.c 2005-01-25 14:43:48 -07:00
+++ edited/arch/arm/oprofile/common.c 2005-02-08 23:00:50 -07:00
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "op_counter.h"
#include "op_arm_model.h"
@@ -25,6 +26,26 @@ static void pmu_stop(void);
static int pmu_create_files(struct super_block *, struct dentry *);
#ifdef CONFIG_PM
+static int pmu_suspend(struct sys_device *dev, u32 state)
+{
+ if (pmu_enabled)
+ pmu_stop();
+ return 0;
+}
+
+static int pmu_resume(struct sys_device *dev)
+{
+ if (pmu_enabled)
+ pmu_start();
+ return 0;
+}
+
+static struct sysdev_class oprofile_sysclass = {
+ set_kset_name("oprofile"),
+ .resume = pmu_resume,
+ .suspend= pmu_suspend,
+};
+
static struct sys_device device_oprofile = {
.id = 0,
.cls= _sysclass,
@@ -35,14 +56,14 @@ static int __init init_driverfs(void)
int ret;
if (!(ret = sysdev_class_register(_sysclass)))
- ret = sys_device_register(_oprofile);
+ ret = sysdev_register(_oprofile);
return ret;
}
-static void __exit exit_driverfs(void)
+static void exit_driverfs(void)
{
- sys_device_unregister(_oprofile);
+ sysdev_unregister(_oprofile);
sysdev_class_unregister(_sysclass);
}
#else
@@ -105,8 +126,7 @@ static void pmu_stop(void)
up(_sem);
}
-int __init
-pmu_init(struct oprofile_operations *ops, struct op_arm_model_spec *spec)
+int __init pmu_init(struct oprofile_operations *ops, struct op_arm_model_spec
*spec)
{
init_MUTEX(_sem);
= arch/arm/oprofile/op_model_xscale.c 1.7 vs edited =
--- 1.7/arch/arm/oprofile/op_model_xscale.c 2005-01-04 19:48:24 -07:00
+++ edited/arch/arm/oprofile/op_model_xscale.c 2005-02-09 21:50:49 -07:00
@@ -42,6 +42,9 @@
#ifdef CONFIG_ARCH_IOP331
#define XSCALE_PMU_IRQ IRQ_IOP331_CORE_PMU
#endif
+#ifdef CONFIG_ARCH_PXA
+#define XSCALE_PMU_IRQ IRQ_PMU
+#endif
/*
* Different types of events that can be counted by the XScale PMU
@@ -305,9 +308,9 @@ static void inline __xsc1_check_ctrs(voi
/* Overflow bit gets cleared. There's no workaround. */
/* Fixed in B stepping or later*/
- pmnc &= ~(PMU_ENABLE | pmu->cnt_ovf[PMN0] | pmu->cnt_ovf[PMN1] |
- pmu->cnt_ovf[CCNT]);
- write_pmnc(pmnc);
+ /* Write the value back to clear the overflow flags. Overflow */
+ /* flags remain in pmnc for use below */
+ write_pmnc(pmnc & ~PMU_ENABLE);
for (i = CCNT; i <= PMN1; i++) {
if (!(pmu->int_mask[i] & pmu->int_enable))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] distribute ppc64 EXPORT_SYMBOLs
Hi, This patch just moves aas many as possible EXPORT_SYMBOL()s from arch/ppc64/kernel/ppc_ksyms.c to where the symbols are defined. This has been compiled on pSeries, iSeries and pmac. Please apply. Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ diff -ruN linus-bk/arch/ppc64/kernel/LparData.c linus-bk.sfr.1/arch/ppc64/kernel/LparData.c --- linus-bk/arch/ppc64/kernel/LparData.c 2005-01-09 10:05:39.0 +1100 +++ linus-bk.sfr.1/arch/ppc64/kernel/LparData.c 2005-02-10 14:19:50.0 +1100 @@ -224,6 +224,7 @@ }; struct msChunks msChunks; +EXPORT_SYMBOL(msChunks); /* Depending on whether this is called from iSeries or pSeries setup * code, the location of the msChunks struct may or may not have diff -ruN linus-bk/arch/ppc64/kernel/cputable.c linus-bk.sfr.1/arch/ppc64/kernel/cputable.c --- linus-bk/arch/ppc64/kernel/cputable.c 2004-06-28 14:30:54.0 +1000 +++ linus-bk.sfr.1/arch/ppc64/kernel/cputable.c 2005-02-10 14:46:05.0 +1100 @@ -17,9 +17,12 @@ #include #include #include +#include + #include struct cpu_spec* cur_cpu_spec = NULL; +EXPORT_SYMBOL(cur_cpu_spec); /* NOTE: * Unlike ppc32, ppc64 will only call this once for the boot CPU, it's diff -ruN linus-bk/arch/ppc64/kernel/irq.c linus-bk.sfr.1/arch/ppc64/kernel/irq.c --- linus-bk/arch/ppc64/kernel/irq.c2005-01-22 06:09:00.0 +1100 +++ linus-bk.sfr.1/arch/ppc64/kernel/irq.c 2005-02-10 14:41:29.0 +1100 @@ -61,6 +61,7 @@ #endif extern irq_desc_t irq_desc[NR_IRQS]; +EXPORT_SYMBOL(irq_desc); int distribute_irqs = 1; int __irq_offset_value; diff -ruN linus-bk/arch/ppc64/kernel/pacaData.c linus-bk.sfr.1/arch/ppc64/kernel/pacaData.c --- linus-bk/arch/ppc64/kernel/pacaData.c 2005-01-12 16:05:22.0 +1100 +++ linus-bk.sfr.1/arch/ppc64/kernel/pacaData.c 2005-02-10 14:44:19.0 +1100 @@ -216,3 +216,4 @@ #endif #endif }; +EXPORT_SYMBOL(paca); diff -ruN linus-bk/arch/ppc64/kernel/pci.c linus-bk.sfr.1/arch/ppc64/kernel/pci.c --- linus-bk/arch/ppc64/kernel/pci.c2005-01-22 06:09:00.0 +1100 +++ linus-bk.sfr.1/arch/ppc64/kernel/pci.c 2005-02-10 11:58:17.0 +1100 @@ -63,7 +63,9 @@ * page is mapped and isa_io_limit prevents access to it. */ unsigned long isa_io_base; /* NULL if no ISA bus */ +EXPORT_SYMBOL(isa_io_base); unsigned long pci_io_base; +EXPORT_SYMBOL(pci_io_base); void iSeries_pcibios_init(void); diff -ruN linus-bk/arch/ppc64/kernel/ppc_ksyms.c linus-bk.sfr.1/arch/ppc64/kernel/ppc_ksyms.c --- linus-bk/arch/ppc64/kernel/ppc_ksyms.c 2005-01-12 16:05:22.0 +1100 +++ linus-bk.sfr.1/arch/ppc64/kernel/ppc_ksyms.c2005-02-10 15:08:06.0 +1100 @@ -8,49 +8,18 @@ */ #include #include -#include -#include -#include -#include #include -#include -#include #include -#include -#include -#include -#include -#include -#include +#include -#include -#include #include #include #include -#include -#include -#include -#include #include -#include -#include -#include -#include #include #include #include -#ifdef CONFIG_PPC_ISERIES #include -#include -#endif - -extern int do_signal(sigset_t *, struct pt_regs *); - -EXPORT_SYMBOL(do_signal); - -EXPORT_SYMBOL(isa_io_base); -EXPORT_SYMBOL(pci_io_base); EXPORT_SYMBOL(strcpy); EXPORT_SYMBOL(strncpy); @@ -65,10 +34,6 @@ EXPORT_SYMBOL(strcmp); EXPORT_SYMBOL(strncmp); -EXPORT_SYMBOL(__down_interruptible); -EXPORT_SYMBOL(__up); -EXPORT_SYMBOL(__down); - EXPORT_SYMBOL(csum_partial); EXPORT_SYMBOL(csum_partial_copy_generic); EXPORT_SYMBOL(ip_fast_csum); @@ -79,11 +44,6 @@ EXPORT_SYMBOL(__strncpy_from_user); EXPORT_SYMBOL(__strnlen_user); -EXPORT_SYMBOL(clear_user_page); - -#ifdef CONFIG_MSCHUNKS -EXPORT_SYMBOL(msChunks); -#endif EXPORT_SYMBOL(reloc_offset); #ifdef CONFIG_PPC_ISERIES @@ -107,11 +67,7 @@ EXPORT_SYMBOL(_outsw_ns); EXPORT_SYMBOL(_insl_ns); EXPORT_SYMBOL(_outsl_ns); -EXPORT_SYMBOL(ioremap); -EXPORT_SYMBOL(__ioremap); -EXPORT_SYMBOL(iounmap); -EXPORT_SYMBOL(start_thread); EXPORT_SYMBOL(kernel_thread); EXPORT_SYMBOL(giveup_fpu); @@ -119,8 +75,7 @@ EXPORT_SYMBOL(giveup_altivec); #endif EXPORT_SYMBOL(flush_icache_range); -EXPORT_SYMBOL(flush_icache_user_range); -EXPORT_SYMBOL(flush_dcache_page); + #ifdef CONFIG_SMP #ifdef CONFIG_PPC_ISERIES EXPORT_SYMBOL(local_get_flags); @@ -129,19 +84,6 @@ #endif #endif -EXPORT_SYMBOL(ppc_md); - -#ifdef CONFIG_PPC_MULTIPLATFORM -EXPORT_SYMBOL(find_devices); -EXPORT_SYMBOL(find_type_devices); -EXPORT_SYMBOL(find_compatible_devices); -EXPORT_SYMBOL(find_path_device); -EXPORT_SYMBOL(device_is_compatible); -EXPORT_SYMBOL(machine_is_compatible); -EXPORT_SYMBOL(find_all_nodes); -EXPORT_SYMBOL(get_property); -#endif - EXPORT_SYMBOL(memcpy); EXPORT_SYMBOL(memset); EXPORT_SYMBOL(memmove); @@ -150,10 +92,4 @@
Re: 2.6.11-rc3-mm1
On Wed, Feb 09, 2005 at 08:12:07PM -0800, Andrew Morton wrote: > (I understand that it's only a "proof of concept" patch, but I thought I'd > bitch anyway ;)) > > So. I'll keep the patch as-is in -mm for now. I've Cc'ed linux-acpi. > Perhaps the people there can absorb this and fix it up for real, please? I forgot to mention, this patch is known to break Alt-SysRq-O on at least some systems. See here: http://www.ussg.iu.edu/hypermail/linux/kernel/0501.3/0869.html -Barry K. Nathan <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arp_queue: serializing unlink + kfree_skb
David S. Miller wrote: > This document is intended to serve as a guide to Linux port > maintainers on how to implement atomic counter and bitops operations > properly. Finally, some light is shed into one of the most arcane areas of the kernel ;-) Thanks ! > Unlike the above routines, it is required that explicit memory > barriers are performed before and after the operation. It must > be done such that all memory operations before and after the > atomic operation calls are strongly ordered with respect to the > atomic operation itself. Hmm, given that this description will not only be read by implementers of atomic functions, but also by users, the "explicit memory barriers" may be confusing. Who does them, the atomic_* function, or the user ? In fact, I would call them "implicit", because they're hidden in the atomic_foo functions :-) > void smb_mb__before_atomic_dec(void); > void smb_mb__after_atomic_dec(void); > void smb_mb__before_atomic_inc(void); > void smb_mb__after_atomic_dec(void); s/smb_/smp/ :-) Do they also work for atomic_add and atomic_sub, or do we have to fall back to smb_mb or atomic_add_return (see below) there ? > With the memory barrier semantics required of the atomic_t > operations which return values, the above sequence of memory > visibility can never happen. What happens if the operation could return a value, but the user ignores it ? E.g. if I don't like smp_mb__*, could I just use atomic_inc_and_test(foo); instead of smp_mb__before_atomic_inc(); atomic_inc(foo); smp_mb__after_atomic_dec(); ? If yes, is this a good idea ? > These routines, like the atomic_t counter operations returning > values, require explicit memory barrier semantics around their > execution. Very confusing: the barriers aren't around the routines (that is something the user would be doing), but around whatever does the atomic stuff inside them. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.4.x kernel BUG at filemap.c:81
Marcelo Tosatti wrote: On Wed, Feb 09, 2005 at 03:47:28PM -0500, Todd Shetter wrote: Running slackware 10 and 10.1, with kernels 2.4.26, 2.4.27, 2.4.28, 2.4.29 with highmem 4GB, and highmem i/o support enabled, I get a system lockup. This happens in both X and console. Happens with and without my Nvidia drivers loaded. I cannot determine what makes this bug present it self besides highmem and high i/o support enabled. Im guessing the system is fine until highmem is actually used to some point and then it borks, but I really have no idea and so im just making a random guess. I ran memtest86 for a few hours a while ago thinking that it may be bad memory, but that did not seem to be the problem. If you need anymore information, or have questions, or wish me to test anything, PLEASE feel free to contact me, I would really like to see this bug resolved. =) -- Todd Shetter Feb 8 19:49:31 quark kernel: kernel BUG at filemap.c:81! Feb 8 19:49:31 quark kernel: invalid operand: Feb 8 19:49:31 quark kernel: CPU:0 Feb 8 19:49:31 quark kernel: EIP:0010:[]Tainted: P Hi Todd, Why is your kernel tainted ? I had the nvidia 1.0-6629 driver loaded when I got that error. I compiled the kernel using the slackware 10.1 config, enabled highmem 4GB support, highmem i/o, and then some kernel hacking options including debugging for highmen related things. I booted, loaded X with KDE, opened firefox a few times, and then started running hdparm because some newer 2.4.x kernels dont play nice with my SATA, ICH5, and DMA. hdparm segfaulted while running the drive read access portion of its tests, and things locked up from there in about 30secs. I've gotten the same error with the nvidia driver not loaded, so I dont think that is part of the problem. As I said, if you want me to test or try anything feel free to ask. =) Todd, Would be interesting to have the oops output without the kernel nvidia module. Do you have that saved? Sorry, it took me FOREVER to get this bug to appear again, and this time its a little different. Hum, both BUGs are due to a page with alive ->buffers mapping. Did it crashed right after hdparm now too? Can you boot your box without SATA drivers, configuring the interface to IDE mode ? Which problems are you facing with newer v2.4.x kernels and SATA? Im waiting for the system to crash, so I figured I might as well get on with the SATA problems Running 2.4.29 neither the CONFIG_BLK_DEV_IDE_SATA nor the CONFIG_SCSI_SATA are set currently and DMA is not enabled on either of my drives, hda: ST380013AS, hdb: WDC WD2500SD-01KCB0, hdc: Maxtor 94610U6. Setting DMA manually on the hard drives yields a HDIO_SET_DMA failed: Operation not permitted error. Using 2.4.26, DMA worked fine on the drives. Under 2.4.27, 2.4.28, and 2.4.29 using CONFIG_SCSI_SATA does not allow setting of DMA on the drives, yielding a HDIO_SET_DMA failed: Operation not permitted error, and the transfer speeds reported by hdparm are at about 3MB/s. Under 2.4.29 using CONFIG_BLK_DEV_IDE_SATA the DMA is set fine upon boot, and I get good transfers, hdparm reports 58MB/s on my Western Digital drive. I have not tested using CONFIG_BLK_DEV_IDE_SATA on any previous kernel versions. Well, still no crash yetAgain, anything else you want me to try or do just let me know. -- Todd Shetter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc3-mm1
"Marcos D. Marado Torres" <[EMAIL PROTECTED]> wrote:
>
> Please add to -mm the patch in attachment, since it solves the old
> acpi_power_off bug...
>
> ...
> diff -Nru -p1 linux-2.6.11-rc2-mm1/drivers/base/power/shutdown.c
> linux-2.6.11-rc2-mm1-mbn1/drivers/base/power/shutdown.c
> --- linux-2.6.11-rc2-mm1/drivers/base/power/shutdown.c 2004-12-24
> 22:35:01.0 +0100
> +++ linux-2.6.11-rc2-mm1-mbn1/drivers/base/power/shutdown.c 2005-01-26
> 00:26:54.0 +0100
> @@ -64,2 +64,9 @@ void device_shutdown(void)
>
> +#if 1
> +{
> +extern void do_acpi_power_off_prepare(void);
> +do_acpi_power_off_prepare();
> +}
> +#endif
> +
This of course doesn't compile if CONFIG_ACPI=n. I fixed that up.
Also, having acpi stuff in drivers/base/power/shutdown.c is quite
inappropriate.
Also, extern declarations should also not be placed in .c files - they
should go into header files which are shared by the definition and all
users of the symbol.
(I understand that it's only a "proof of concept" patch, but I thought I'd
bitch anyway ;))
So. I'll keep the patch as-is in -mm for now. I've Cc'ed linux-acpi.
Perhaps the people there can absorb this and fix it up for real, please?
From: "Marcos D. Marado Torres" <[EMAIL PROTECTED]>
From: "Barry K. Nathan" <[EMAIL PROTECTED]>
On Tue, Feb 08, 2005 at 08:54:06PM -0800, Andrew Morton wrote:
> "Marcos D. Marado Torres" <[EMAIL PROTECTED]> wrote:
> >
> > Please add to -mm the patch in attachment, since it solves the old
> > acpi_power_off bug...
>
> What acpi_power_off bug? And how does it solve it?
Here's the observed bug that the patch is trying to fix:
http://bugme.osdl.org/show_bug.cgi?id=4041
What Marcos posted is a typo-corrected version of Eric Biederman's
patch:
http://marc.theaimsgroup.com/?l=linux-kernel=110665542929525=2
In Eric's own words, the patch "needs some work before it goes into a
mainline kernel". AFAICT it's more of a proof-of-concept, just to see if
Eric's on the right track...
This is the motivation behind the patch:
http://marc.theaimsgroup.com/?l=linux-kernel=110665405402747=2
--- 25-alpha/drivers/acpi/sleep/poweroff.c~acpi_power_off-bug-fix
2005-02-09 19:55:05.0 -0800
+++ 25-alpha-akpm/drivers/acpi/sleep/poweroff.c 2005-02-09 19:55:05.0
-0800
@@ -7,18 +7,37 @@
#include
#include
+#include
#include
#include
#include "sleep.h"
static void
+acpi_power_off_prepare(void)
+{
+ if (system_state == SYSTEM_POWER_OFF) {
+ acpi_wakeup_gpe_poweroff_prepare();
+ acpi_enter_sleep_state_prep(ACPI_STATE_S5);
+ }
+}
+
+void
+do_acpi_power_off_prepare(void)
+{
+ if (!acpi_disabled) {
+ acpi_power_off_prepare();
+ }
+}
+
+
+static void
acpi_power_off (void)
{
printk("%s called\n",__FUNCTION__);
+#if 0 /* This should be made redundant by other patches.. */
/* Some SMP machines only can poweroff in boot CPU */
set_cpus_allowed(current, cpumask_of_cpu(0));
- acpi_wakeup_gpe_poweroff_prepare();
- acpi_enter_sleep_state_prep(ACPI_STATE_S5);
+#endif
ACPI_DISABLE_IRQS();
acpi_enter_sleep_state(ACPI_STATE_S5);
}
diff -puN drivers/base/power/shutdown.c~acpi_power_off-bug-fix
drivers/base/power/shutdown.c
--- 25-alpha/drivers/base/power/shutdown.c~acpi_power_off-bug-fix
2005-02-09 19:55:05.0 -0800
+++ 25-alpha-akpm/drivers/base/power/shutdown.c 2005-02-09 20:10:21.0
-0800
@@ -62,6 +62,13 @@ void device_shutdown(void)
}
up_write(_subsys.rwsem);
+#ifdef CONFIG_ACPI
+ {
+ extern void do_acpi_power_off_prepare(void);
+ do_acpi_power_off_prepare();
+ }
+#endif
+
sysdev_shutdown();
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Important Message
Re: Important Message FROM: Sgt. Michael Doherty Dear Sir Good day to you My name is Michael Doherty I am an American soldier, i am serving in the military of the 1st Armored Division in Iraq, we have just been posted to leave Iraq and go back to Germany. I am now in Kuwait at the mean time, I and my superior moved funds belonging to Saddam Hussein, the total is $25,000,000.00 (Twenty Five million US dollars) this money is being kept safe in a security company. Click on this link to read about even that took place here http://news.bbc.co.uk/2/hi/middle_east/2988455.stm Basically since we are working for the government we cannot keep these funds, but we want to transfer and move the funds to you, so that you can keep it for us in your safe account or an offshore account. We will divide the total funds in three ways, since we are 3 that is involved. This means that you will take 30%, I will take 30%, and my superior will take 30%. 10% will be kept aside for expenses. This business is confidential, and it should not be discussed with anyone. There is no risk involved whatsoever. If you are interested i will send you the full details, my job is to find a good partner that we can trust and that will assist us. Can i trust you? When you receive this letter, kindly send me an e-mail signifying your interest including your most confidential telephone/fax numbers for quick communication also your contact details. This business is risk free. Please reply me via this email: [EMAIL PROTECTED] Respectfully submitted Sgt. Michael Doherty - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 9/8] lib/sort: turn off self-test
Matt Mackall wrote: > It's a nice self-contained unit test. By the way, I think it would be useful if there was a more formalized frame for such unit tests, so that they could be used in automated kernel testing. To avoid false positives when grepping through the code, perhaps such tests could be placed in separate files, using a different extension, e.g. .ct for ".c test", or in some "test" directory. (That is, in case they're distributed along with the kernel code, which, IMHO, would help to avoid code drift.) Just an idea ... - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [0/8] orinoco driver updates
On Wed, Feb 09, 2005 at 10:07:08PM -0500, Jeff Garzik wrote: > David Gibson wrote: > >I'm now not entirely clear on whether you want patches against the > >netdev bk, or against Linus bk/snapshots. > > > Please send diff'd against vanilla Linus upstream. Ok, in that case do you want me to resend the things which are in netdev but not vanilla? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [0/8] orinoco driver updates
David Gibson wrote: I'm now not entirely clear on whether you want patches against the netdev bk, or against Linus bk/snapshots. Please send diff'd against vanilla Linus upstream. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [0/8] orinoco driver updates
On Tue, Feb 01, 2005 at 08:48:31PM -0500, Jeff Garzik wrote: > David Gibson wrote: > >Following are a bunch of patches which make a few more steps towards > >the long overdue merge of the CVS orinoco driver into mainline. These > >do make behavioural changes to the driver, but they should all be > >trivial and largely cosmetic. > > OK, the changes look good, but I was waiting for the previous stuff you > submitted to land in upstream. > > Could I convince you to rediff and resend against the latest 2.6.x snapshot? > > At the time you sent these, they conflicted with a previous cleanup you > had sent, and that I had applied. Ok, I'm a little confused. The last batch were all checked against the then-current netdev-2.6 bk tree, or was the conflict with something you'd applied between when I pulled the tree and you looked at the patches? As far as I can tell all the previous batch of patches I sent you are in netdev (plus a couple from this batch), but most are still not in upstream. I'm now not entirely clear on whether you want patches against the netdev bk, or against Linus bk/snapshots. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] relayfs redux, part 4
Hi, Here's the latest relayfs patch, incorporating the previous round of suggestions. Thanks to everyone who sent comments. Here's a list of the major changes: - replaced remap_page_range() and reserved bits with a nopage() handler. - buffers are now allocated/freed as part of inode alloc/destroy. - got rid of the automatic creation/teardown of directory hierarchies, and exported create/remove dir functions instead. - replaced the fileop callback with explicit map/unmap callbacks - these were the only fileops currently being used by anything, so I got rid of the other cases. - relay_write() and __relay_write() no longer return a value - it doesn't really make sense for clients to check a return value in the fast path anyway. - added a buf_full() callback to notify users that a buffer has become full and therefore events might be lost. - got rid of the 'helper' macros, which weren't helping much. - various other bits of code and comment cleanup. Also, there was some question as to whether or not the memcpy in relay_write() was being inlined properly - I looked at the generated assembly code, and it seems to be, but I'll be taking a closer look later. This is what the API now looks like: API functions: rchan *relay_open(base_filename, parent, subbuf_size, n_subbufs, flags, callbacks); void relay_close(chan); dentry *relayfs_create_dir(name, parent); int relayfs_remove_dir(dentry); void relay_reset(chan); void relay_write(chan, data, length); void __relay_write(chan, data, length); void *relay_reserve(chan, length); void relay_subbufs_consumed(chan, subbufs_consumed, cpu); void relay_commit(buf, subbuf_idx, count); callbacks: int subbuf_start(buf, subbuf, prev_subbuf_idx); int deliver(buffer, subbuf, subbuf_idx); void buf_mapped(buf, filp); void buf_unmapped(buf, filp); void buf_full(buf); As before, I've tested this code on a single proc machine using a hacked version of the kprobes network packet tracing module, which can be found here: http://prdownloads.sourceforge.net/dprobes/plog.tar.gz?download If people are more or less happy with the current version, I'll do some SMP testing and write some Documentation. Thanks, Tom Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]> fs/Kconfig | 12 fs/Makefile|1 fs/relayfs/Makefile|4 fs/relayfs/buffers.c | 119 fs/relayfs/buffers.h | 14 + fs/relayfs/inode.c | 447 fs/relayfs/relay.c | 616 + fs/relayfs/relay.h | 31 ++ include/linux/relayfs_fs.h | 253 ++ 9 files changed, 1497 insertions(+) diff -urpN -X dontdiff linux-2.6.10/fs/Kconfig linux-2.6.10-cur/fs/Kconfig --- linux-2.6.10/fs/Kconfig 2004-12-24 15:34:58.0 -0600 +++ linux-2.6.10-cur/fs/Kconfig 2005-01-31 21:49:27.0 -0600 @@ -972,6 +972,18 @@ config RAMFS To compile this as a module, choose M here: the module will be called ramfs. +config RELAYFS_FS + tristate "Relayfs file system support" + ---help--- + Relayfs is a high-speed data relay filesystem designed to provide + an efficient mechanism for tools and facilities to relay large + amounts of data from kernel space to user space. + + To compile this code as a module, choose M here: the module will be + called relayfs. + + If unsure, say N. + endmenu menu "Miscellaneous filesystems" diff -urpN -X dontdiff linux-2.6.10/fs/Makefile linux-2.6.10-cur/fs/Makefile --- linux-2.6.10/fs/Makefile2004-12-24 15:34:58.0 -0600 +++ linux-2.6.10-cur/fs/Makefile2005-01-31 21:49:27.0 -0600 @@ -94,3 +94,4 @@ obj-$(CONFIG_AFS_FS) += afs/ obj-$(CONFIG_BEFS_FS) += befs/ obj-$(CONFIG_HOSTFS) += hostfs/ obj-$(CONFIG_HPPFS)+= hppfs/ +obj-$(CONFIG_RELAYFS_FS) += relayfs/ diff -urpN -X dontdiff linux-2.6.10/fs/relayfs/Makefile linux-2.6.10-cur/fs/relayfs/Makefile --- linux-2.6.10/fs/relayfs/Makefile1969-12-31 18:00:00.0 -0600 +++ linux-2.6.10-cur/fs/relayfs/Makefile2005-02-03 06:34:11.0 -0600 @@ -0,0 +1,4 @@ +obj-$(CONFIG_RELAYFS_FS) += relayfs.o + +relayfs-y := relay.o buffers.o inode.o + diff -urpN -X dontdiff linux-2.6.10/fs/relayfs/buffers.c linux-2.6.10-cur/fs/relayfs/buffers.c --- linux-2.6.10/fs/relayfs/buffers.c 1969-12-31 18:00:00.0 -0600 +++ linux-2.6.10-cur/fs/relayfs/buffers.c 2005-02-03 08:16:39.0 -0600 @@ -0,0 +1,119 @@ +/* + * RelayFS buffer management code. + * + * Copyright (C) 2002, 2003 - Tom Zanussi ([EMAIL PROTECTED]), IBM Corp + * Copyright (C) 1999, 2000, 2001, 2002 - Karim Yaghmour ([EMAIL PROTECTED]) + * + * This file is released under the GPL. + */ + +#include +#include +#include +#include "buffers.h"
ToÌØËo ×ÌaÄeÌØÃaÍ îP LJ 4V, 4mV ÎeÄopoÇo ËapÔpÉÄÖÉ C39OOA opÉÇÉÎaÌØÎÙe
Ecть 2O кapтpиджeй бeз кopoбoк, в пoлиэтилeнe, нe pacпeчaтaнныx, opигинaл, k пpинmepy 4V, 4mV (С39OOA) пo 75 ye зa шт. T: 778~7823 Aлeкcaндp Ecли нe пo aдpecy, пpoшy пpoщeния. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
Two more of these sel_netif_lookup related BUGs were found with -RT-2.6.11-rc3-V0.7.38-06: BUG: sleeping function called from invalid context ksoftirqd/0(2) at kernel/rt.c:1448 in_atomic():1 [0001], irqs_disabled():0 [] dump_stack+0x23/0x30 (20) [] __might_sleep+0xd8/0xf0 (36) [] __spin_lock+0x38/0x60 (24) [] _spin_lock+0x1d/0x20 (16) [] kmem_cache_alloc+0x3f/0x140 (44) [] sel_netif_lookup+0x69/0x160 (40) [] sel_netif_sids+0x38/0xd0 (40) [] selinux_socket_sock_rcv_skb+0xc3/0x2a0 (152) [] udp_queue_rcv_skb+0xca/0x2d0 (40) [] udp_rcv+0x1c8/0x430 (96) [] ip_local_deliver+0x6c/0x210 (36) [] ip_rcv+0x239/0x430 (56) [] netif_receive_skb+0x147/0x180 (48) [] process_backlog+0x7f/0x110 (28) [] net_rx_action+0x7c/0x130 (32) [] ___do_softirq+0x57/0xf0 (40) [] _do_softirq+0x25/0x30 (8) [] ksoftirqd+0xa5/0x100 (28) [] kthread+0xa6/0xe0 (48) [] kernel_thread_helper+0x5/0xc (537116692) --- | preempt count: 0002 ] | 2-level deep critical section nesting: .. [] __do_IRQ+0xfb/0x1a0 .[] .. ( <= do_IRQ+0x6f/0xb0) .. [] print_traces+0x1b/0x60 .[] .. ( <= dump_stack+0x23/0x30) BUG: sleeping function called from invalid context ksoftirqd/0(2) at kernel/rt.c:1448 in_atomic():1 [0001], irqs_disabled():0 [] dump_stack+0x23/0x30 (20) [] __might_sleep+0xd8/0xf0 (36) [] __spin_lock+0x38/0x60 (24) [] _spin_lock+0x1d/0x20 (16) [] kmem_cache_alloc+0x3f/0x140 (44) [] sel_netif_lookup+0x69/0x160 (40) [] sel_netif_sids+0x38/0xd0 (40) [] selinux_socket_sock_rcv_skb+0xc3/0x2a0 (152) [] tcp_v4_rcv+0x502/0x950 (76) [] ip_local_deliver+0x6c/0x210 (36) [] ip_rcv+0x239/0x430 (56) [] netif_receive_skb+0x147/0x180 (48) [] process_backlog+0x7f/0x110 (28) [] net_rx_action+0x7c/0x130 (32) [] ___do_softirq+0x57/0xf0 (40) [] _do_softirq+0x25/0x30 (8) [] ksoftirqd+0xa5/0x100 (28) [] kthread+0xa6/0xe0 (48) [] kernel_thread_helper+0x5/0xc (537116692) --- | preempt count: 0002 ] | 2-level deep critical section nesting: .. [] __do_IRQ+0xfb/0x1a0 .[] .. ( <= do_IRQ+0x6f/0xb0) .. [] print_traces+0x1b/0x60 .[] .. ( <= dump_stack+0x23/0x30) Additional info about the system/kernel/config can be found at http://www.sysex.net/testing/ Best Regards, --William Weston On Wed, 9 Feb 2005, Stephen Smalley wrote: > On Tue, 2005-02-08 at 16:58, William Weston wrote: > > Hi Ingo, > > > > Great work on the -RT kernel! Here's a status report from my Athlon box > > w/ kernel -RT-2.6.11-rc3-V0.7.38-03, realtime-lsm-0.8.5, jack-0.99.48, > > alsa-1.0.8, and latencytest-0.5.5: > > > A couple BUGs are being logged (see below), but without any ill effect > > other than taking up space on my /var. > > > Network interface (via rhine) startup triggers these two BUGs: > > > > BUG: sleeping function called from invalid context ksoftirqd/0(2) at > > kernel/rt.c:1448 > > in_atomic():1 [0001], irqs_disabled():0 > > [] dump_stack+0x17/0x20 (12) > > [] __might_sleep+0xd9/0xf0 (40) > > [] __spin_lock+0x36/0x50 (24) > > [] kmem_cache_alloc+0x34/0x120 (44) > > [] sel_netif_lookup+0x63/0x150 (28) > > [] sel_netif_sids+0x2d/0xb0 (28) > > [] selinux_socket_sock_rcv_skb+0xac/0x230 (144) > > I'm not sure I understand, as sel_netif_lookup passes GFP_ATOMIC to > kmalloc. > > > [] udp_queue_rcv_skb+0xb8/0x280 (28) > > [] udp_rcv+0x192/0x3e0 (100) > > [] ip_local_deliver+0x64/0x1c0 (32) > > [] ip_rcv+0x215/0x3f0 (56) > > [] netif_receive_skb+0x12c/0x160 (40) > > [] process_backlog+0x7e/0x110 (32) > > [] net_rx_action+0x72/0x130 (24) > > [] ___do_softirq+0x48/0xd0 (40) > > [] _do_softirq+0x1b/0x30 (8) > > [] ksoftirqd+0xa0/0xf0 (28) > > [] kthread+0x8b/0xc0 (36) > > [] kernel_thread_helper+0x5/0x10 (537116692) > > --- > > | preempt count: 0002 ] > > | 2-level deep critical section nesting: > > > > .. [] __do_IRQ+0xef/0x180 > > .[] .. ( <= do_IRQ+0x56/0xa0) > > .. [] print_traces+0x10/0x40 > > .[] .. ( <= dump_stack+0x17/0x20) > > -- > Stephen Smalley <[EMAIL PROTECTED]> > National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
On Wed, 9 Feb 2005, Ingo Molnar wrote:
> > Running wmcube (an impractical, greedy, little CPU meter), even when
> > niced, causes lots of xruns. It may be good for worst-case-scenario
> > desktop load testing.
>
> this phenomenon is very weird.
>
> Firstly, make sure that all relevant threads (including the soundcard
> IRQ thread, jackd threads, jack client thread, etc.) have higher RT
> priority than any other, latency-irrelevant threads in the system.
Thanks for the tip. I have schedtool installed, and all audio/MIDI IRQ
threads, jack threads, and jack clients are now run with higher priorities
than everything else. Before I adjusted priorities, I was getting a bunch
of these when running latencytest (which have since disappeared):
rtc: lost some interrupts at 8192Hz.
bug in rtc_read(): called in state S_IDLE!
IRQ 8 (RTC) is still giving me some issues, even after adjusting
priorities:
`IRQ 8'[232] is being piggy. need_resched=0, cpu=0
Read missed before next interrupt
Should the RTC IRQ be given a new priority? If so, should it be lower,
higher, or equal to the audio/MIDI/jack priorities?
> If everything looks OK on the priority-administration side, could you
> enable wakeup-latency tracing via:
>
> CONFIG_WAKEUP_TIMING=y
> CONFIG_PREEMPT_TRACE=y
> # CONFIG_CRITICAL_PREEMPT_TIMING is not set
> # CONFIG_CRITICAL_IRQSOFF_TIMING is not set
> CONFIG_LATENCY_TIMING=y
> CONFIG_LATENCY_TRACE=y
> what is the longest wakeup latency the tracer shows? You can start the
> measurement anew via:
>
> echo 0 > /proc/sys/kernel/preempt_max_latency
Max latency is in the realm of 13-18 after runs of jack_test4.1.
> every new maximum-latency event will be logged by the kernel, and the
> trace of the latest worst-case latency path can be found under
> /proc/latency_trace.
>
> (If the trace is very long then most of the time it's OK to just send
> the first 25 and last 10 lines. Putting the trace up to a website is a
> good solution too.)
See http://www.sysex.net/testing/ for the all of the test results and
system info on a 2.6.11-rc3-RT-V0.7.38-06 kernel.
This is from my most recent run of jack_test4.1 with wmcube and kernel
compilation running (check /testing/dmesg for more):
(sshd-5940 |#0): new 4 s maximum-latency wakeup.
( IRQ 16-1803 |#0): new 5 s maximum-latency wakeup.
(make-28375|#0): new 6 s maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 6 s maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 7 s maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 8 s maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 8 s maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 9 s maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 10 s maximum-latency wakeup.
( ksoftirqd/0-2|#0): new 10 s maximum-latency wakeup.
( jackd-29348|#0): new 12 s maximum-latency wakeup.
( jackd-29348|#0): new 14 s maximum-latency wakeup.
( jackd-29348|#0): new 15 s maximum-latency wakeup.
> it should not matter how 'greedy' wmcube is. Does it do alot of graphics
> activity (perhaps 3D too?) - that could in theory cause hardware
> latencies - the latency traces will tell.
Wmcube displays a 3D spinning cube, which spins faster (actually performs
larger rotations between updates) when CPU usage goes up. When running
niced, wmcube uses about 1% to 4% of the CPU, adds about 1000 context
switches per second, and increases X load by 1% to 3% of the total CPU.
Now that the priorities are tuned, I get no xruns while running wmcube,
compiling a kernel, and running latencytest or jack_test4.1.
> > MIDI playback through any MPU-401 interface triggers the following
> > BUG, reported once for each outgoing MIDI event (non MPU-401 hw
> > interfaces and sw interfaces not affected):
>
> the patch below should fix this. (also included in -38-06 and later
> kernels.)
>
> Ingo
>
> --- linux/sound/drivers/mpu401/mpu401_uart.c.orig
> +++ linux/sound/drivers/mpu401/mpu401_uart.c
> @@ -316,12 +316,12 @@ static void snd_mpu401_uart_input_trigge
> /* read data in advance */
> /* prevent double enter via rawmidi->event callback */
> if (atomic_dec_and_test(>rx_loop)) {
> - local_irq_save(flags);
> + local_irq_save_nort(flags);
> if (spin_trylock(>input_lock)) {
> snd_mpu401_uart_input_read(mpu);
> spin_unlock(>input_lock);
> }
> - local_irq_restore(flags);
> + local_irq_restore_nort(flags);
> }
> atomic_inc(>rx_loop);
> } else {
> @@ -407,12 +407,12 @@ static void snd_mpu401_uart_output_trigg
> /* output pending data */
> /* prevent double enter via rawmidi->event callback */
> if (atomic_dec_and_test(>tx_loop)) {
> -
Re: [rfc][patch] ide: fix unneeded LBA48 taskfile registers access
Bartlomiej Zolnierkiewicz wrote: On Thu, 10 Feb 2005 09:52:25 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: Okay, another quick question. To fix the io_32bit race problem in ide_taskfile_ioctl() (and later ide_cmd_ioctl() too), it seems simplest to mark the taskfile with something like ATA_TFLAG_IO_16BIT flag and use the flag in task_in_intr(). However, ATA_TFLAG_* are used by libata, and I think that, although sharing hardware constants is good if the hardware is similar, sharing driver-specific flags isn't such a good idea. So, what do you think? 1. Add ATA_TFLAG_IO_16BIT to ata.h 2. Make ide's own set of task flags, maybe IDE_TFLAG_* (including IDE_TFLAG_LBA48) Please add it to (unless Jeff complains loudly), I have a patch converting ide_task_t to use struct ata_taskfile (except ->protocol for now). ACK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
JBD problems in linux 2.6.11 rc3
On a 12-way IA64, with ext3 filesystem on an Ramdisk, when attempting to run the disk I/O load of OSDL's aim-7 benchmark, I see an oops when the multiprogramming level reaches around 200. Turning on CONFIG_JBD_DEBUG shows: Assertion failure in __journal_file_buffer() at /home/dsw/LCA/linux-2.6.11-rc2/fs/jbd/transaction.c:1913: "jh->b_jlist < 9" kernel BUG at/home/dsw/LCA/linux-2.6.11-rc2/fs/jbd/transaction.c:1913! kjournald[1483]: bugcheck! 0 [1] Modules linked in: tg3 Pid: 1483, CPU 9, comm:kjournald psr : 101008026018 ifs : 8590 ip : []Not tainted ip is at __journal_file_buffer+0x380/0x6c0 unat: pfs : 0590 rsc : 0003 rnat: 0009804c8a70033f bsps: pr : 6941 ldrs: ccv : fpsr: 0009804c8a70033f csd : ssd : b0 : a001001d37c0 b6 : a001005f95e0 b7 : a0010041b1e0 f6 : 0fffbc8c0 f7 : 0ffd9a200 f8 : 08000 f9 : 10002a000 f10 : 0fffbc8c0 f11 : 1003e r1 : a00100a60ad0 r2 : 4000 r3 : 4000 r8 : 0048 r9 : 0001 r10 : r11 : a00100875e78 r12 : e040f0e97b10 r13 : e040f0e9 r14 : a001007b7b30 r15 : a00100875e50 r16 : a00100873bf8 r17 : r18 : a00100875e44 r19 : a001007b7b30 r20 : a00100860d38 r21 : 0001 r22 : cf019000 r23 : 0005 r24 : 0060 r25 : r26 : 1140 r27 : 001008026018 r28 : a001008a01ce r29 : 0001f05e r30 : r31 : a00100875e20 Call Trace: [] show_stack+0x80/0xa0 sp=e040f0e976d0 bsp=e040f0e910f0 [] show_regs+0x7e0/0x800 sp=e040f0e978a0 bsp=e040f0e91090 [] die+0x150/0x1c0 sp=e040f0e978b0 bsp=e040f0e91050 [] die_if_kernel+0x40/0x60 sp=e040f0e978b0 bsp=e040f0e91020 [] ia64_bad_break+0x220/0x340 sp=e040f0e978b0 bsp=e040f0e90ff0 [] ia64_leave_kernel+0x0/0x260 sp=e040f0e97940 bsp=e040f0e90ff0 [] __journal_file_buffer+0x380/0x6c0 sp=e040f0e97b10 bsp=e040f0e90f70 [] journal_commit_transaction+0x2df0/0x3220 sp=e040f0e97b10 bsp=e040f0e90e70 [] kjournald+0x270/0x760 sp=e040f0e97d80 bsp=e040f0e90e00 [] kernel_thread_helper+0xd0/0x100 sp=e040f0e97e30 bsp=e040f0e90dd0 [] start_kernel_thread+0x20/0x40 sp=e040f0e97e30 bsp=e040f0e90dd0 kernel BUG at /home/dsw/LCA/linux-2.6.11-rc2/kernel/timer.c:416! reaim[14320]: bugcheck! 0 [2] Modules linked in: tg3 Pid: 14320, CPU 11, comm:reaim psr : 101008022018 ifs : 848c ip : []Not tainted ip is at cascade+0xf0/0x100 unat: pfs : 048c rsc : 0003 rnat: eba873c37e00 bsps: 00010009 pr : 0010a1015966a9a5 ldrs: ccv : 0004 fpsr: 0009804c8a70033f csd : ssd : b0 : a0010009f010 b6 : a0013320 b7 : a001000bbd40 f6 : 1003e8080808080808081 f7 : 1003e0180 f8 : 1003e1200 f9 : 1003e23dc f10 : 1003e0e58 f11 : 1003e356f424c r1 : a00100a60ad0 r2 : r3 : 4000 r8 : 0041 r9 : a001007b7b30 r10 : a001007b7b30 r11 : 000b r12 : e000165afa70 r13 : e000165a8000 r14 : 0004 r15 : a001007b7b30 r16 : e000165a8d74 r17 : e0007ab67de8 r18 : r19 : 0014 r20 : r21 : 0004 r22 : 0004 r23 : 0004 r24 : 0004 r25 : 0001 r26 : 0001 r27 : r28 : r29 : 0004 r30 : e000165a8d70 r31 : e000165a802c Call Trace: [] show_stack+0x80/0xa0 sp=e000165af630 bsp=e000165a95c0 [] show_regs+0x7e0/0x800 sp=e000165af800 bsp=e000165a9560 [] die+0x150/0x1c0 sp=e000165af810
Re: [PATCH 01/04] Adding cipher mode context information to crypto_tfm
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote: > Because a tweak is different from an IV. There can be an arbitrary > number of tweaks. For instance, EME takes 1 tweak per 512 bytes. If you > have a 4k page to encrypt, you have to process 8 tweaks of whatever > size. > Therefore, you need 3 scatterlists: src, dst and the running along > tweak. The purpose of the scatterlists is to be able to process discontigous data at the page level. The tweak, as I understand it, is something which you generate, and it is not inherently likely to be page-level clumps of data. It does not ever need to be kmapped. What you really need to do is use an array for the tweak (or possibly a structure which maintains state about it if needed). - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/04] Adding cipher mode context information to crypto_tfm
Am Mittwoch, den 09.02.2005, 17:19 -0800 schrieb Andrew Morton: > > It must be > > possible to process more than 2 mappings in softirq context. > > Adding a few more fixmap slots wouldn't hurt anyone. But if you want an > arbitrarily large number of them then no, we cannot do that. > > Possibly one could arrange for the pages to not be in highmem at all. In the case of the LRW use in dm-crypt only plain- and ciphertext need to be accessible through struct page (both are addressed through BIO vectors). The LRW tweaks could simply be kmalloced. So instead of passing "struct scatterlist *tweaksg" we could just pass a "void *tweaksg". Some of the hard work on the generic scatterlist walker would be for nothing then. :( signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [rfc][patch] ide: fix unneeded LBA48 taskfile registers access
On Thu, 10 Feb 2005 09:52:25 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > > Okay, another quick question. > > To fix the io_32bit race problem in ide_taskfile_ioctl() (and later > ide_cmd_ioctl() too), it seems simplest to mark the taskfile with > something like ATA_TFLAG_IO_16BIT flag and use the flag in task_in_intr(). > > However, ATA_TFLAG_* are used by libata, and I think that, although > sharing hardware constants is good if the hardware is similar, sharing > driver-specific flags isn't such a good idea. So, what do you think? > > 1. Add ATA_TFLAG_IO_16BIT to ata.h > 2. Make ide's own set of task flags, maybe IDE_TFLAG_* (including > IDE_TFLAG_LBA48) Please add it to (unless Jeff complains loudly), I have a patch converting ide_task_t to use struct ata_taskfile (except ->protocol for now). Bartlomiej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 01/04] Adding cipher mode context information to crypto_tfm
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote: > > It must be > possible to process more than 2 mappings in softirq context. Adding a few more fixmap slots wouldn't hurt anyone. But if you want an arbitrarily large number of them then no, we cannot do that. Taking more than one sleeping kmap at a time within the same process is deadlocky, btw. You can end up with N such tasks all holding one kmap and waiting for someone else to release one. Possibly one could arrange for the pages to not be in highmem at all. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 01/04] Adding cipher mode context information to crypto_tfm
On Wed, 2005-02-09 at 19:30 -0500, James Morris wrote: > On Wed, 9 Feb 2005, Fruhwirth Clemens wrote: > > > I can't code for the case of two. Because, first, that's the idea of > > generic in the name "generic scatterwalk", second, I need at least 3 > > scatterlists in parallel for LRW. > > Can you explain why you need a third scatterlist for the LRW tweak? Because a tweak is different from an IV. There can be an arbitrary number of tweaks. For instance, EME takes 1 tweak per 512 bytes. If you have a 4k page to encrypt, you have to process 8 tweaks of whatever size. Therefore, you need 3 scatterlists: src, dst and the running along tweak. However, I don't want to limit the discussion to the specific needs of LRW or EME. I wanted to write something nice and generic for other people to use, thus scatterwalk_walk. There must be a solution to get an arbitrary number of kmappings in softirq problem. If it's possible for 2 pages, I can't see a reason why this ain't possible for more. The use of scratch buffers and constant switching of kmap_atomic mapping is just ridiculously stupid. > My understanding is that the tweak value is calculated from the disk > position of the plaintext block and and the secondary key. That's only partially correct. The tweak value _is_ the location on disk. The value which is XORed twice is computed from the tweak and the secondary key. In LRW, you need a tweak value per block. So, if you encode 256 blocks, you need 256 tweaks. That's what the additional scatterlist is for. > It would be useful to see the original patch (which seems to be > unavailable now), with dm-crypt integration, to see how the entire > mechanism works beyond the test vectors. Frankly, I don't see a point escalating this discussion. It must be possible to process more than 2 mappings in softirq context. If not, I feel emotionally offended. -- Fruhwirth Clemens <[EMAIL PROTECTED]> http://clemens.endorphin.org signature.asc Description: This is a digitally signed message part
Re: PCI Error reporting & recovery
On Tue, 2005-02-08 at 17:22 +0900, Hidetoshi Seto wrote: > Hi, Ben. > > How kind of you to remember. Well, mailing lists archives did remember for me :) > Now I have a rewrite of the previous "clear/read_pci_errors" patch. > The new one adopts iomap infrastructure, considering generality, > capability and so on. And the part of its implementation for IA64 is > now under test using converted SCSI/NIC drivers. Ok. I still wonder if we want something that works without the iomap stuff though... > Soon I'll post the patch to lkml(+IA64ML) with some explanation of the > change and the result of test, and will beg/hear comments. Ok, can you post what you have now so I can get an idea of where you are going ? > Interesting. > Actually I don't have enough knowledge about platforms other than IA32/64, > so it will be helpful if you could tell me practical matters about ppc64 > etc. Ok, so here's how things work on ppc64: There is usually one controlling bridge per slot (with individual error management at the slot level), though it's possible that several devices end up on the same segment (think cards with P2P bridges on them). When any error happens, the slot automatically isolates itself. That is reads return all 1's and writes get dropped. At this point, we can query the firmware for error informations. Currently, our IO accessors (readX/writeX) will do this "query" automatically when the IOs return all 1's, and will log an event that is treated later at task time by some error management. We have the possibility, via the firmware, of re-enabling IO (but not DMA) on the slot, to do, for example, diagnostic to the hardware, re-enabling DMA, or reset the slot (trigger the PCI reset). This means we can provide means of recovery for drivers who have a proper API to hook on that (which is what I'd like to define). It has to be an asynchronous API, that is all drivers on a given "isolated" segment (usually only one) get notifed of errors, and may be given a chance to react. I'm not sure at this point what is the best API to provide here since we may have more than one driver on the slot. I suppose we must ensure all drivers have ack'ed the isolation event before we allow one of them to re-enable IO operations or ask for a reset. And since several drivers have to "tell" what they can do before anything is actually done (IO re-enable, slot reset, ...), we need some kind of async interface, maybe via a new callback in the pci_driver structure. I think the case of devices sharing a segment is rare enough not to impact the design too much. One thing is the PCI layer must know a driver that is error management aware from one that is not (maybe by the presence of the new callback ?). Once the error occurs on the slot, and has been "detected" by a driver on the segment, we could then call their error callbacks mgmnt indicating the slot state (isolated, still enabled, been reset) depending on what the platform supports. The driver can then do whatever it needs and return a result code indicating that 0) - can proceed normally (did recover), 1) can't proceed in the current state (that is, needs IOs re-enabled if isolated, or need a reset). The system would then go through each step it's capable of, and call drivers with the state, until all drivers agree (or a driver gives up completely, in which case it's just left dead). For example, ppc64 would first call the callback with slot isolated. The driver would use this opportunity to cleanup stuff and typically return "1" (can't proceed in the current state) (or an error to "give up"). Then, we would turn back IOs on and call the driver again, which would then return either 0 (if it diagnosed & recovered fully) or "1 if it wants the slot to be reset, etc... I'm not sure what to do if one driver can recover (returns 0) at the "io enabled" stage but another can't (returns "1"). We could either give up on the second one, or reset the slot. In the end, a last message has to be sent telling to restart operations (this shouldn't be done as part of the "IO re-enabled" messages since because of the above another driver may have rejected the state and asked for a reset). Unless somebody has a better idea... Now, the actual error informations can be quite rich. We can get to the type of error (master abort, target abort, data parity, address parity, etc... and I think in some cases, we can know the address of the access that triggered the error. 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: [rfc][patch] ide: fix unneeded LBA48 taskfile registers access
Okay, another quick question. To fix the io_32bit race problem in ide_taskfile_ioctl() (and later ide_cmd_ioctl() too), it seems simplest to mark the taskfile with something like ATA_TFLAG_IO_16BIT flag and use the flag in task_in_intr(). However, ATA_TFLAG_* are used by libata, and I think that, although sharing hardware constants is good if the hardware is similar, sharing driver-specific flags isn't such a good idea. So, what do you think? 1. Add ATA_TFLAG_IO_16BIT to ata.h 2. Make ide's own set of task flags, maybe IDE_TFLAG_* (including IDE_TFLAG_LBA48) -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Linux Kernel Subversion Howto
On Thu, Feb 10, 2005 at 01:14:43AM +0100, Roman Zippel wrote: > [long explanation which is summarized as "it's hard"] > So doing the work is one thing, getting a result within my lifetime would > be nice too. I understand the complexity you are facing. This may be hard for you to believe but we have solved problems that are quite a bit more complex than what you are trying to do and then gave you the solution for free. This problem is nowhere near as hard as you are making it out to be but it is hard. But it's not that bad, we do this every time we do a CVS import, we have to intuit the changeset boundaries themselves, which is actually harder than what you are trying to do. Think about taking revision history without any changeset grouping and recreating the changesets (aka patches). We do that all the time, automatically. If we can do that then you can do this. Yeah, it's hard, though, I admit that. This is a bit of a cheap shot but you did say that this stuff was easy, remember? Yeah, you may hate me for making you realize it is hard but maybe you'll start to respect what it is we have given you. That would be cool. Anyway, you can do this. It will probably take you a couple of months of 80 hour weeks. Does that suck? Maybe. Bear in mind that we have given you *years* of 80 hour weeks. Years. Many of them unpaid. So suck it up and get to work, we did. You might have fun doing this, you know. These problems, while hard, have some very satisfying mathematical qualities and that's really fun coming from the kernel background where things are far less deterministic. You can actually write proofs about how things work for a change. -- --- Larry McVoylm at bitmover.com http://www.bitkeeper.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] string lib redundancy and whitespace clarity fixes
* Jonathan Ho ([EMAIL PROTECTED]) wrote:
> Fixed some weird whitespace, solved redundancies (applies to v2.6.10).
>
> Signed-off-by: Jonathan Ho <[EMAIL PROTECTED]>
>
> --- lib/string.cFri Dec 24 13:35:25 2004
> +++ \documents and settings\jonathan\desktop/string.cWed Feb 09
This won't apply nicely with -p1. Nor will it apply against
current -bk (which no longer has bcopy in it, for example).
> 16:21:28 2005
> @@ -38,7 +38,7 @@ int strnicmp(const char *s1, const char
> /* Yes, Virginia, it had better be unsigned */
> unsigned char c1, c2;
>
> -c1 = 0;c2 = 0;
> +c1 = c2 = 0;
> if (len) {
> do {
> c1 = *s1; c2 = *s2;
> @@ -253,12 +253,12 @@ EXPORT_SYMBOL(strncmp);
> * @s: The string to be searched
> * @c: The character to search for
> */
> -char * strchr(const char * s, int c)
> +char *strchr(const char * s, int c)
> {
> -for(; *s != (char) c; ++s)
> +for( ; *s != (char) c; s++)
> if (*s == '\0')
> return NULL;
> -return (char *) s;
> +return (char *)s;
For this kind of CodingStyle cleanup, I think it's probably not worth it.
Unless you have other changes and fixes planned in the area.
> }
> EXPORT_SYMBOL(strchr);
> #endif
> @@ -390,14 +390,14 @@ EXPORT_SYMBOL(strcspn);
> * @cs: The string to be searched
> * @ct: The characters to search for
> */
> -char * strpbrk(const char * cs,const char * ct)
> +char * strpbrk(const char *cs, const char *ct)
> {
> -const char *sc1,*sc2;
> +const char *sc1, *sc2;
>
> -for( sc1 = cs; *sc1 != '\0'; ++sc1) {
> -for( sc2 = ct; *sc2 != '\0'; ++sc2) {
> +for(sc1 = cs; *sc1 != '\0'; sc1++) {
> +for(sc2 = ct; *sc2 != '\0'; sc2++) {
Neither of these is CodingStyle compliant ;-) Take a look at what
Lindent does (not perfect, but good rule of thumb).
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Fix oops in alloc_zeroed_user_highpage() when page is NULL
On Wed, 9 Feb 2005, Michael Ellerman wrote: > The generic and IA-64 versions of alloc_zeroed_user_highpage() don't > check the return value from alloc_page_vma(). This can lead to an oops > if we're OOM. This fixes my oops on PPC64, but I haven't got an IA-64 > machine/compiler handy. Patch looks okay to me. These are the only occurences as far as I can tell after reviewing the alloc_zeroed_user_higpage implementations in include/asm-*/page.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] string lib redundancy and whitespace clarity fixes
Fixed some weird whitespace, solved redundancies (applies to v2.6.10).
Signed-off-by: Jonathan Ho <[EMAIL PROTECTED]>
--- lib/string.cFri Dec 24 13:35:25 2004
+++ \documents and settings\jonathan\desktop/string.cWed Feb 09
16:21:28 2005
@@ -38,7 +38,7 @@ int strnicmp(const char *s1, const char
/* Yes, Virginia, it had better be unsigned */
unsigned char c1, c2;
-c1 = 0;c2 = 0;
+c1 = c2 = 0;
if (len) {
do {
c1 = *s1; c2 = *s2;
@@ -253,12 +253,12 @@ EXPORT_SYMBOL(strncmp);
* @s: The string to be searched
* @c: The character to search for
*/
-char * strchr(const char * s, int c)
+char *strchr(const char * s, int c)
{
-for(; *s != (char) c; ++s)
+for( ; *s != (char) c; s++)
if (*s == '\0')
return NULL;
-return (char *) s;
+return (char *)s;
}
EXPORT_SYMBOL(strchr);
#endif
@@ -390,14 +390,14 @@ EXPORT_SYMBOL(strcspn);
* @cs: The string to be searched
* @ct: The characters to search for
*/
-char * strpbrk(const char * cs,const char * ct)
+char * strpbrk(const char *cs, const char *ct)
{
-const char *sc1,*sc2;
+const char *sc1, *sc2;
-for( sc1 = cs; *sc1 != '\0'; ++sc1) {
-for( sc2 = ct; *sc2 != '\0'; ++sc2) {
+for(sc1 = cs; *sc1 != '\0'; sc1++) {
+for(sc2 = ct; *sc2 != '\0'; sc2++) {
if (*sc1 == *sc2)
-return (char *) sc1;
+return (char *)sc1;
}
}
return NULL;
@@ -417,7 +417,7 @@ EXPORT_SYMBOL(strpbrk);
* of that name. In fact, it was stolen from glibc2 and de-fancy-fied.
* Same semantics, slimmer shape. ;)
*/
-char * strsep(char **s, const char *ct)
+char *strsep(char **s, const char *ct)
{
char *sbegin = *s, *end;
@@ -444,9 +444,9 @@ EXPORT_SYMBOL(strsep);
*
* Do not use memset() to access IO space, use memset_io() instead.
*/
-void * memset(void * s,int c,size_t count)
+void *memset(void *s, int c, size_t count)
{
-char *xs = (char *) s;
+char *xs = (char *)s;
while (count--)
*xs++ = c;
@@ -469,7 +469,7 @@ EXPORT_SYMBOL(memset);
* You should not use this function to access IO space, use memcpy_toio()
* or memcpy_fromio() instead.
*/
-void bcopy(const void * srcp, void * destp, size_t count)
+void bcopy(const void *srcp, void *destp, size_t count)
{
const char *src = srcp;
char *dest = destp;
@@ -490,7 +490,7 @@ EXPORT_SYMBOL(bcopy);
* You should not use this function to access IO space, use memcpy_toio()
* or memcpy_fromio() instead.
*/
-void * memcpy(void * dest,const void *src,size_t count)
+void *memcpy(void *dest, const void *src, size_t count)
{
char *tmp = (char *) dest, *s = (char *) src;
@@ -563,17 +563,17 @@ EXPORT_SYMBOL(memcmp);
* returns the address of the first occurrence of @c, or 1 byte past
* the area if @c is not found
*/
-void * memscan(void * addr, int c, size_t size)
+void *memscan(void *addr, int c, size_t size)
{
-unsigned char * p = (unsigned char *) addr;
+unsigned char *p = (unsigned char *)addr;
while (size) {
if (*p == c)
-return (void *) p;
+return (void *)p;
p++;
size--;
}
- return (void *) p;
+ return (void *)p;
}
EXPORT_SYMBOL(memscan);
#endif
@@ -584,18 +584,18 @@ EXPORT_SYMBOL(memscan);
* @s1: The string to be searched
* @s2: The string to search for
*/
-char * strstr(const char * s1,const char * s2)
+char *strstr(const char *s1, const char *s2)
{
int l1, l2;
l2 = strlen(s2);
if (!l2)
-return (char *) s1;
+return (char *)s1;
l1 = strlen(s1);
while (l1 >= l2) {
l1--;
-if (!memcmp(s1,s2,l2))
-return (char *) s1;
+if (!memcmp(s1, s2, l2))
+return (char *)s1;
s1++;
}
return NULL;
@@ -618,7 +618,7 @@ void *memchr(const void *s, int c, size_
const unsigned char *p = s;
while (n-- != 0) {
if ((unsigned char)c == *p++) {
-return (void *)(p-1);
+return (void *)(p - 1);
}
}
return NULL;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/04] Adding cipher mode context information to crypto_tfm
On Wed, 9 Feb 2005, Fruhwirth Clemens wrote: > I can't code for the case of two. Because, first, that's the idea of > generic in the name "generic scatterwalk", second, I need at least 3 > scatterlists in parallel for LRW. Can you explain why you need a third scatterlist for the LRW tweak? My understanding is that the tweak value is calculated from the disk position of the plaintext block and and the secondary key. It would be useful to see the original patch (which seems to be unavailable now), with dm-crypt integration, to see how the entire mechanism works beyond the test vectors. - James -- James Morris <[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: 2.6.10 devfs oops without devfs mounted at all
"Sergey S. Kostyliov" <[EMAIL PROTECTED]> wrote: > > Here is an oops I've just get on my smp system: > > Unable to handle kernel NULL pointer dereference at virtual address 001c > printing eip: > c01afe5b > *pde = > Oops: [#1] > PREEMPT SMP > Modules linked in: ipt_REJECT ipt_state ip_conntrack iptable_filter > CPU:2 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010286 (2.6.10) > EIP is at devfsd_close+0x1b/0xc8 > eax: f7440a00 ebx: ecx: c01afe40 edx: ed395280 > esi: edi: f7f17800 ebp: f74f96c8 esp: cdc70f84 > ds: 007b es: 007b ss: 0068 > Process megamgr.bin (pid: 12844, threadinfo=cdc7 task=dd81e520) > Stack: ed395280 ed395280 f7f17800 c0150c76 ee9e87f8 ed395280 >f1985c80 cdc7 c014f50f 0003 0003 080caa60 c01024df >0003 080cc700 bfffe4f8 080caa60 bfffe4fc 0006 007b > Call Trace: > [] __fput+0x106/0x120 > [] filp_close+0x4f/0x80 > [] syscall_call+0x7/0xb Can you work out what file is being closed? One way of doing that would be to work out how megamgr.bin is being invoked and to then run it by hand: strace -f -o log megamgr.bin and we can then use the strace output to work out the pathname of the offending file. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ide: fix unneeded LBA48 taskfile registers access
Hello Tejun,
On Thu, 10 Feb 2005 09:01:58 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hello, Bartlomiej. Happy new lunar year.
>
> Bartlomiej Zolnierkiewicz wrote:
> >
> > I would prefer to not teach do_rw_taskfile() about ->tf_{in,out}_flags
> > (and convert all users to use helpers) - it is much simpler this way,
> >
> > ->flags field in ide_task_t is needed anyway (32-bit I/O flag).
> >
>
> New lunar year day is one of the biggest holidays here, so I haven't
> got time to work for a few days. As it's over now, I began to work on
> ide drivers again. I applied your task->flags patch and am moving my
> patches over it.
>
> One problem is that, with ATA_TFLAG_LBA48, whether to use HOB
> registers or not cannot be determined separately for writing and
> reading. So, when initializing flush tasks, if WIN_FLUSH_CACHE_EXT is
> used, we need to turn on ATA_TFLAG_LBA48 to read error location
> properly, and we end up unnecessarily writing HOB registers.
Yep, good catch.
> I think we can...
>
> 1. Just leave it as it is. It's not that big a deal.
> 2. Use another flag(s) to control LBA48 reading/writing separately.
> 3. do my proposal. :-)
>
> I'm currently sticking to #1. Please let me know what you think.
agreed, #1 is a good choice, it is not that important to make things
more complicated
Thanks,
Bartlomiej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-rc3-mm1: softlockup and suspend/resume [update]
On Wednesday, 9 of February 2005 17:35, Rafael J. Wysocki wrote: > On Tuesday, 8 of February 2005 12:04, Ingo Molnar wrote: > > > > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > > > The warning is printed right after the image is restored (ie somewhere > > > around the local_irq_enable() above, but it goes before the "PM: Image > > > restored successfully." message that is printed as soon as the return > > > is executed). Definitely, less than 1 s passes between the resoring > > > of the image and the warining. > > > > > > BTW, I've also tried to put touch_softlockup_watchdog() before > > > device_power_up(), but it didn't change much. > > > > this is a single-CPU box, right? > > Yes. > > OK, I think I've sorted it out. The solution is to use your patch and the > following change against swsusp.c: Well, I was to quick with this, sorry. > --- linux-2.6.11-rc3-mm1-orig/kernel/power/swsusp.c 2005-02-08 > 18:16:34.0 +0100 > +++ new/kernel/power/swsusp.c 2005-02-09 17:31:16.0 +0100 > @@ -870,7 +870,9 @@ > /* Restore control flow magically appears here */ > restore_processor_state(); > restore_highmem(); > + touch_softlockup_watchdog(); > device_power_up(); > + touch_softlockup_watchdog(); > local_irq_enable(); > return error; > } The following patch (instead of the above) seems to work much better: --- linux-2.6.11-rc3-mm1-orig/kernel/power/swsusp.c 2005-02-08 18:16:34.0 +0100 +++ new/kernel/power/swsusp.c 2005-02-10 00:45:45.0 +0100 @@ -870,6 +870,7 @@ /* Restore control flow magically appears here */ restore_processor_state(); restore_highmem(); + touch_softlockup_watchdog(); device_power_up(); local_irq_enable(); return error; --- linux-2.6.11-rc3-mm1-orig/arch/x86_64/kernel/time.c 2005-02-05 20:49:26.0 +0100 +++ new/arch/x86_64/kernel/time.c 2005-02-10 00:46:48.0 +0100 @@ -988,6 +988,7 @@ write_sequnlock_irqrestore(_lock,flags); jiffies += sleep_length; wall_jiffies += sleep_length; + touch_softlockup_watchdog(); return 0; } --- linux-2.6.11-rc3-mm1-orig/arch/i386/kernel/time.c 2005-02-05 20:49:26.0 +0100 +++ new/arch/i386/kernel/time.c 2005-02-10 00:47:03.0 +0100 @@ -378,6 +378,7 @@ write_sequnlock_irqrestore(_lock, flags); jiffies += sleep_length; wall_jiffies += sleep_length; + touch_softlockup_watchdog(); return 0; } I tested it only on x86-64, so the change for i386 is a guess, albeit educated. ;-) 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: [RFC] Linux Kernel Subversion Howto
Hi, On Wed, 9 Feb 2005, Larry McVoy wrote: (I just sent a similiar mail in private and didn't immediately realize it didn't went to lkml, so sorry, who gets it twice.) > On Wed, Feb 09, 2005 at 03:13:48PM -0500, Nicolas Pitre wrote: > > I think what people want here is the tree structure representation in > > whatever form, not necessarily in the BK format. > > That's fine, they can do that. Get the patches and figure out how to > put them back together. These people do know how to use patch, right? > OK, then they are welcome to patch things in, when they don't work, find > a place they do work and create a branch, patch them, repeat. Haven't > they ever dealt with a patch reject before? It's not that hard. No, just impossible. As I mentioned already previously, the main problem is restoring the changeset information, so one actually knows how the kernel tree looked at a specific point. I also mentioned that it's not really possible to find for all changesets their parent changesets, e.g. changeset 1.889 has 416 branches which include 3560 changesets, that means some of the branches have over 3000 potential parents. Due to parallel changes to a file on multiple branches one can reduce that number, but it's likely still greater than one. Now for a while I hoped to at least find the end of branch, that means where two branches get merged again. The gnupatches contain some information of what they merge, so that one could use the log text to find the changeset. The problem is that even these gnupatches don't contain information to reliable find its parents. First, they don't include other merge logs, so there are again multiple potential parents if there are merge changeset near the changeset identified by the log text. Second, there are completely empty changesets with no log text and so no indication what they are merging, I currently have 171 of them and of these 13 are at a start of the branch (and therefore have no usable information at all of either parent). So why is this parent information so important? If the patches are not applied in the correct order, one simply gets the wrong kernel snapshot. What makes this more difficult are the merge changesets, as they don't contain the complete information of what has changed compared to one of the parents, they just contain the file conflicts. If one had the correct parent information this would not be a problem, repeating the merge is one of the smaller problems. But with fuzzy parent information one also only gets fuzzy merge results and if the parents have n potential parents that results in n^2 possible merge results in the worst case. Since the merge changeset only contains conflict information, that makes it rather likely one detects a problem (e.g. that a changeset doesn't apply) very late. So if one detects such problem after m merges, we have a worst case of n^(m+1). IOW the complexity of a bkweb export grows exponentially with the size of the repository! And there is still no guarantee to get a correct (that means only one) result. So doing the work is one thing, getting a result within my lifetime would be nice too. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Linux Kernel Subversion Howto
On Thu, Feb 10, 2005 at 12:22:39AM +0100, Roman Zippel wrote: > > You know, you could change all this. Instead of complaining that we > > are somehow hurting you, which virtually 100% of the readers know is > > nonsense, you could be producing an alternative answer which is better. > > Another smoke bomb. You already made it clear, that even if I did that, I > couldn't import the kernel history into it anyway. Sure you can. You can get every patch from bkbits.net. You can write a program which imports them. You can figure out a graph structure which allows all the imports reject free. Your complaint is that BK has already figured out one such graph that has those characteristics and you know that it would be easier if we told you what that is. Yes, I know that to be true, it would be easier for you. However, we're long past the pretense that this is so you can do your kernel engineering, we all know that this is so you can work on a clone of BK, whoops, a much better SCM system. No business will survive if they give away their advantage to their competitors, which is what you are asking us to do. Even if I wanted to do it I have a board that would promptly fire me if I did. OK, that's it for me, I have to go work on slides for a talk so have the big fun, I'm signing off on this thread. Cheers, -- --- Larry McVoylm at bitmover.com http://www.bitkeeper.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3TB disk hassles
On Thu, 16 Dec 2004 14:52:29 +, Neil Conway wrote: > Howdy... > > After much banging of heads on walls, I am throwing in the towel and > asking the experts ;-) ... To cut a long story short: > > Is it possible to make a 3TB disk work properly in Linux? > > Our "disk" is 12x300GB in RAID5 (with 1 hot-spare) on a 3ware 9500-S12, > so it's actually 2.7TiB ish. It's also /dev/sda - i.e., the one and > only disk in the system. > > Problems are arising due to the 32-bit-ness of normal partition tables. > I can use parted to make a 2.7TB partition (sda4), and > /proc/partitions looks fine until a reboot, whereupon the top bits are > lost and the big partition looks like a 700GB partition instead of a > 2.7TB one; this is a bad thing ;-) > > I've had my hopes raised by GPT, but after more reading it appears this > doesn't work on vanilla x86 PCs. > > Tips gratefully received. > > Neil > > PS: not on-list; I'll be reading the real-time archivers, but CCs of > any replies would be appreciated. > > > > > > ___ > ALL-NEW Yahoo! Messenger - all new features - even more fun! > http://uk.messenger.yahoo.com > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ Neil, I just set up a new file server a couple of weeks ago, which holds two RAIDs, making up 4.1 TB each. I'm not aware of any distributions that will do the partitioning for you. I was able to get the system configured by booting Knoppix and using parted for the partitioning. Fedora refused to install on this system after checking the GPT partition table. The latest Mandrake Linux warned me about the partitions, but at least it accepted going on with the install anyway. lilo is used as the bootloader and has no problem existing on the MBR of the RAID. My system is a dual 3.2 GHz Xeon system with 8GB RAM, two 3Ware 9500S RAID controllers, 12 400GB disks pr. RAID controller. Here's a df from the system: [EMAIL PROTECTED] ~]# df FilesystemSize Used Avail Use% Mounted on /dev/sda1 7.9G 1.1G 6.8G 14% / /dev/sda3 14G 3.4G 11G 25% /usr /dev/sda4 4.0T 232G 3.8T 6% /home /dev/sdb1 4.1T 24G 4.0T 1% /archive Good Luck! Regards Jan Lindheim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ide: fix unneeded LBA48 taskfile registers access
Hello, Bartlomiej. Happy new lunar year.
Bartlomiej Zolnierkiewicz wrote:
I would prefer to not teach do_rw_taskfile() about ->tf_{in,out}_flags
(and convert all users to use helpers) - it is much simpler this way,
->flags field in ide_task_t is needed anyway (32-bit I/O flag).
New lunar year day is one of the biggest holidays here, so I haven't
got time to work for a few days. As it's over now, I began to work on
ide drivers again. I applied your task->flags patch and am moving my
patches over it.
One problem is that, with ATA_TFLAG_LBA48, whether to use HOB
registers or not cannot be determined separately for writing and
reading. So, when initializing flush tasks, if WIN_FLUSH_CACHE_EXT is
used, we need to turn on ATA_TFLAG_LBA48 to read error location
properly, and we end up unnecessarily writing HOB registers.
I think we can...
1. Just leave it as it is. It's not that big a deal.
2. Use another flag(s) to control LBA48 reading/writing separately.
3. do my proposal. :-)
I'm currently sticking to #1. Please let me know what you think.
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 kprobes/jprobes panic
On Tue, 2005-02-08 at 21:07, Prasanna S Panchamukhi wrote:
> Hi Badri,
>
> > Hi,
> >
> > I ran into this while playing with jprobes in 2.6.10.
> >
> > I tried to install jprobe handler on a invalid address,
>
> User should prevent inserting jprobes on an invalid address.
Well, I was hoping register handler would do some basic
error checking to prevent user from panicking. For example,
I ran into it untentionally (I moved my code from ia32 to
x86-64, forgot to update the addresses).
>
> > I get OOPS. I was hoping for a error check and a graceful
> > exit rather than kernel Oops.
> >
>
> Error check and graceful exit can be done in the jprobe handler
> module. In the jprobe network packet logging patch, error check
> was taken care by using kallsyms_lookup_name() as shown below.
>
> nt->jp.kp.addr = (kprobe_opcode_t *)
> kallsyms_lookup_name(nt->funcname);
> if (nt->jp.kp.addr) {
> printk("plant jprobe at %s (%p), handler addr %p\n",
> nt->funcname, nt->jp.kp.addr, nt->jp.entry);
> register_jprobe(>jp);
> } else {
> printk("couldn't find %s to plant jprobe\n",
> nt->funcname);
> }.
>
I tried to do this earlier in my module, but I get
# insmod myprobe.ko
insmod: error inserting 'myprobe.ko': -1 Unknown symbol in module
myprobe: Unknown symbol kallsyms_lookup_name
How did you use it ? it looks like kallsyms_lookup_name()
is not exported. Thats the reason why I was hardcoding addresses.
# grep KALL .config
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
Thanks,
Badari
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PPC64] (resend) Functions to reserve performance monitor hardware
Andrew, here's a resend of this patch. My earlier version had a few
stupid errors which should be corrected in this one. Please apply.
The PPC64 interrupt code includes a hook to call when an exception
from the performance monitor unit occurs. However, there's no way of
reserving the hook properly, so if more than one bit of code tries to
use it things will get ugly. Currently oprofile is the only user, but
there are likely to be more in future e.g. perfctr, if and when it
reaches a fit state for merging.
This patch creates functions to reserve and release the performance
monitor hardware (including its interrupt), and makes oprofile use
them. It also creates a new arch/ppc64/kernel/pmc.c, in which we can
put any future helper functions for handling the performance monitor
counters.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/arch/ppc64/kernel/pmc.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ working-2.6/arch/ppc64/kernel/pmc.c 2005-02-10 10:50:16.639578008 +1100
@@ -0,0 +1,64 @@
+/*
+ * linux/arch/ppc64/kernel/pmc.c
+ *
+ * Copyright (C) 2004 David Gibson, IBM Corporation.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+
+/* Ensure exceptions are disabled */
+static void dummy_perf(struct pt_regs *regs)
+{
+ unsigned int mmcr0 = mfspr(SPRN_MMCR0);
+
+ mmcr0 &= ~(MMCR0_PMXE|MMCR0_PMAO);
+ mtspr(SPRN_MMCR0, mmcr0);
+}
+
+static spinlock_t pmc_owner_lock = SPIN_LOCK_UNLOCKED;
+static void *pmc_owner_caller; /* mostly for debugging */
+perf_irq_t perf_irq = dummy_perf;
+
+int reserve_pmc_hardware(perf_irq_t new_perf_irq)
+{
+ int err = 0;
+
+ spin_lock(_owner_lock);
+
+ if (pmc_owner_caller) {
+ printk(KERN_WARNING "reserve_pmc_hardware: "
+ "PMC hardware busy (reserved by caller %p)\n",
+ pmc_owner_caller);
+ err = -EBUSY;
+ goto out;
+ }
+
+ pmc_owner_caller = __builtin_return_address(0);
+ perf_irq = new_perf_irq ? : dummy_perf;
+
+ out:
+ spin_unlock(_owner_lock);
+ return err;
+}
+
+void release_pmc_hardware(void)
+{
+ spin_lock(_owner_lock);
+
+ WARN_ON(! pmc_owner_caller);
+
+ pmc_owner_caller = NULL;
+ perf_irq = dummy_perf;
+
+ spin_unlock(_owner_lock);
+}
Index: working-2.6/arch/ppc64/kernel/traps.c
===
--- working-2.6.orig/arch/ppc64/kernel/traps.c 2005-02-10 10:50:14.653478576
+1100
+++ working-2.6/arch/ppc64/kernel/traps.c 2005-02-10 10:50:16.640577856
+1100
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_DEBUGGER
int (*__debugger)(struct pt_regs *regs);
@@ -450,18 +451,7 @@
die("Unrecoverable VMX/Altivec Unavailable Exception", regs, SIGABRT);
}
-/* Ensure exceptions are disabled */
-static void dummy_perf(struct pt_regs *regs)
-{
- unsigned int mmcr0 = mfspr(SPRN_MMCR0);
-
- mmcr0 &= ~(MMCR0_PMXE|MMCR0_PMAO);
- mtspr(SPRN_MMCR0, mmcr0);
-}
-
-void (*perf_irq)(struct pt_regs *) = dummy_perf;
-
-EXPORT_SYMBOL(perf_irq);
+extern perf_irq_t perf_irq;
void performance_monitor_exception(struct pt_regs *regs)
{
Index: working-2.6/include/asm-ppc64/pmc.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ working-2.6/include/asm-ppc64/pmc.h 2005-02-10 10:50:16.641577704 +1100
@@ -0,0 +1,29 @@
+/*
+ * pmc.h
+ * Copyright (C) 2004 David Gibson, IBM Corporation
+ *
+ * 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
+ */
+#ifndef _PPC64_PMC_H
+#define _PPC64_PMC_H
+
+#include
+
+typedef void (*perf_irq_t)(struct pt_regs *);
+
+int reserve_pmc_hardware(perf_irq_t new_perf_irq);
+void release_pmc_hardware(void);
+
+#endif /* _PPC64_PMC_H */
Index: working-2.6/arch/ppc64/kernel/Makefile
===
---
Re: [RFC] Linux Kernel Subversion Howto
On Wed, Feb 09, 2005 at 03:13:48PM -0500, Nicolas Pitre wrote: > Are you saying that it is now OK to write scripts that would bit bang > on > the bkbits http interface to fetch patches/comments with the purpose > of > populating an alternate scm? Andreas tried that a while ago but you > threatened to shut the service down entirely if he was to continue. Go for it, if it becomes a problem we'll rate limit it. Our first concern is that the BK users can get at the trees so if you are eating up the bandwidth too much we'll slow down the web interface. > | What you could make available in the bkcvs export would be, for each > | changeset (both for the changesets and for the merged changesets), > | include three BKRevs: the changeset's one, the changeset's parent > one, > | and the changeset's merge parent one. > > Is the above actually part of the protected BK IP? Yes. > I think what people want here is the tree structure representation in > whatever form, not necessarily in the BK format. That's fine, they can do that. Get the patches and figure out how to put them back together. These people do know how to use patch, right? OK, then they are welcome to patch things in, when they don't work, find a place they do work and create a branch, patch them, repeat. Haven't they ever dealt with a patch reject before? It's not that hard. > You can't deny others access to the whole of the > Linux kernel development history even if their purpose is to import it > into a competing system (more on that below). I'm not denying anyone that. The history consists of the diffs and the checkin comments, you have that. > Again I wholeheartedly agree with you above. But that's not exactly the > point. You certainly have the right to protect your work. But please > admit that the Linux kernel developers own the right to move (100% not > 96%) of the development tree with all its branches _they_ produced. _They_ didn't produce the branching structure, BitKeeper did that. Go look, there isn't a way to type a command which produces a branch in BK. So claiming that metadata is property of the developers is nonsense, they didn't produce, it isn't physically possible for them to produce it. That's part of BK's design and power. 100% of what any developer produced is already available on the web, in the form that has been used for more than 10 years as the preferred form, a unified diff. And we added comments because those are useful and you typed them in. You guys have been importing patches for more than a decade, since when did that become a problem? > Now obviously enough some people will run away with that raw data and > try to import the Linux kernel source tree in their own scm of choice. > That's why I'm asking you "and so what?" That's fine if they want to do that, they have the patches. What they don't get is the tree structure that BK has because that gives them the ability to go back and forth and say "well, BK did it this way and it worked, why doesn't it work in our system?". > Note that if someone actually needs a big tree to test bench an > alternate scm there are alternatives to the kernel -- gcc is a good > example. So allowing the Linux kernel tree to be imported into another > scm is not really a requirement for developing on said scm. Indeed. I don't suppose there is any chance you could get people to go play with the gcc tree? > I'm just wondering why providing some additional info which would allow > for rebuilding the tree with all changeset relationships (into whatever > alternate inferior scm that's not the point) would uncover your IP. I think you are fishing for BK internal information and I'm not going to bite. The bottom line is that we laid out some rules, the BK users agreed to them, that's the deal. If you don't like the deal then go build an alternative. You can use all the patches you want from BK but you don't get to use BK's metadata. --lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Linux Kernel Subversion Howto
On Thu, 10 Feb 2005 00:31:05 +0100 (CET), Roman Zippel <[EMAIL PROTECTED]> wrote: > On Wed, 9 Feb 2005, Jon Smirl wrote: > > Larry has said, write up a proposal for changes you want in bk. Send > > it to him for a quote. Come up with the cash and he will do the work. > > Here is a simple one: restore the parent information in the gnupatch > option as they were about a year ago visible in the mails to bk-commits, > e.g.: > http://marc.theaimsgroup.com/?l=bk-commits-head=107558318022033=2 > > Now please go to Larry and see what you get. 1) I don't believe anyone considers a link to an email archive a serious proposal. 2) I don't care about what you and Larry come up with. I have no need to get to the kernel source from other tools. I was only pointing out that there was a solution on the table for achieving your goals and that you are ignoring it. Roman, You're the one that is complaining, write up your own proposal and get a quote. LKML is not the place for your continued whining that Larry should add features that only you want and that you don't want to pay for. You have been given a way to solve your problem, make use of it! -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Linux Kernel Subversion Howto
Hi, On Wed, 9 Feb 2005, Jon Smirl wrote: > Larry has said, write up a proposal for changes you want in bk. Send > it to him for a quote. Come up with the cash and he will do the work. Here is a simple one: restore the parent information in the gnupatch option as they were about a year ago visible in the mails to bk-commits, e.g.: http://marc.theaimsgroup.com/?l=bk-commits-head=107558318022033=2 Now please go to Larry and see what you get. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Linux Kernel Subversion Howto
Hi, On Tue, 8 Feb 2005, Larry McVoy wrote: Larry, it's interesting how you try to distract from the main problem (which you don't mention with a single word) and instead continues to badmouth me. Let's take a look. > Short version: let's violate a license. Wrong, if I wanted to violate the license, I could have done so already and I certainly wouldn't make such a fuss about it. To remind you the main problem was and is still, that the kernel history is locked into bk. At this point I'm not really sure, whether all bk user realize this, as you constantly try to distract them with random accusation against my person. > Our position is clear: we are trying to do the right thing for Linux, That's of course a noble goal, but what if such help is attached to conditions? Then it might of course happen that such help is rejected, the question is only where is the problem. For you it's of course clear it must be the potential receivers fault, looking critically at the conditions is out of question for you. > You know, you could change all this. Instead of complaining that we > are somehow hurting you, which virtually 100% of the readers know is > nonsense, you could be producing an alternative answer which is better. Another smoke bomb. You already made it clear, that even if I did that, I couldn't import the kernel history into it anyway. There are already possible alternatives, which should be able to store the kernel history as currently recorded in bk, but we will never know because any attempt to do so will be constructed as license violation. I skipped all the insults, which you use to further distract attention from the actual problem and instead try to descredit me personally. You must be getting quite desperate to start hitting that low. :( bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] iproute2 050209
Small update to iproute2 which adds: * infiniband address decode * reorganize source for netem distribution files into separate directory http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.10-050209.tar.gz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 collect and export low-level cpu usage statistics
On Wed, 2005-02-09 at 15:06 -0800, Andrew Morton wrote: > Paul Mackerras <[EMAIL PROTECTED]> wrote: > > > > POWER5 machines have a per-hardware-thread register which counts at a > > rate which is proportional to the percentage of cycles on which the > > cpu dispatches an instruction for this thread (if the thread gets all > > the dispatch cycles it counts at the same rate as the timebase > > register). This register is also context-switched by the hypervisor. > > Thus it gives a fine-grained measure of the actual cpu usage by the > > thread over time. > > > > This patch adds code to read this register every timer interrupt and > > on every context switch. > > fyi: This patch consumes another entry from thread_struct.pad[]. > ppc64-implement-a-vdso-and-use-it-for-signal-trampoline.patch consumes two > more entries, so with both patches, you have none left. Why couldn't we extend the structure ? That would at worse break modules binary compatibility, who cares ? :) Those pads are just stuff that aren't used any more, and back then, when removing them, we did care about modules binary compat... Anyways, I don't think there's anything to worry about at this point. Paul ? 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] PPC64 collect and export low-level cpu usage statistics
Paul Mackerras <[EMAIL PROTECTED]> wrote: > > POWER5 machines have a per-hardware-thread register which counts at a > rate which is proportional to the percentage of cycles on which the > cpu dispatches an instruction for this thread (if the thread gets all > the dispatch cycles it counts at the same rate as the timebase > register). This register is also context-switched by the hypervisor. > Thus it gives a fine-grained measure of the actual cpu usage by the > thread over time. > > This patch adds code to read this register every timer interrupt and > on every context switch. fyi: This patch consumes another entry from thread_struct.pad[]. ppc64-implement-a-vdso-and-use-it-for-signal-trampoline.patch consumes two more entries, so with both patches, you have none left. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swsusp logic error?
Hi! > I am trying to get swsusp working on a 2.6.10 Debian kernel > (2.6.10-1-686, custom compile, enabling only CONFIG_SOFTWARE_SUSPEND > and leaving CONFIG_PM_STD_PARTITION empty) on this Sony Vaio Z1RSP > Centrino 1.7 Pentium M laptop... without much success. Whenever > I enter swsusp mode, the kernel reports that it cannot find the swap > space and aborts. Try doing it on vanilla, just one swapfile, and pass resume=/dev/your_swapdevice. Oh, and cc me next time if you want faster reply... Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
tg3 broken in bk current?
Hey, I'm having problems w/ the tg3 driver on IBM x440 and x445 systems. It seems the link doesn't hold and constantly flickers on and off. Reverting this patch appears to have fixed the issue. http://linus.bkbits.net:8080/linux-2.5/cset%4042016512Q5lCWar_OBNu5GAr_sjOvA?nav=index.html|[EMAIL PROTECTED] Let me know if I can help test any alternative solutions. thanks -john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] Re: [PATCH 1/1] tpm: update tpm sysfs file ownership - updated version
* Kylene Hall ([EMAIL PROTECTED]) wrote:
> diff -uprN linux-2.6.10/drivers/char/tpm/tpm_atmel.c
> linux-2.6.10-tpm/drivers/char/tpm/tpm_atmel.c
> --- linux-2.6.10/drivers/char/tpm/tpm_atmel.c 2005-02-04 15:03:03.0
> -0600
> +++ linux-2.6.10-tpm/drivers/char/tpm/tpm_atmel.c 2005-02-09
> 14:12:30.711621784 -0600
> @@ -131,6 +131,7 @@ static struct tpm_vendor_specific tpm_at
> .req_complete_mask = ATML_STATUS_BUSY | ATML_STATUS_DATA_AVAIL,
> .req_complete_val = ATML_STATUS_DATA_AVAIL,
> .base = TPM_ATML_BASE,
> + .attr = TPM_DEVICE_ATTRS,
> .miscdev.fops = _ops,
> };
>
> diff -uprN linux-2.6.10/drivers/char/tpm/tpm.c
> linux-2.6.10-tpm/drivers/char/tpm/tpm.c
> --- linux-2.6.10/drivers/char/tpm/tpm.c 2005-02-04 15:03:03.0
> -0600
> +++ linux-2.6.10-tpm/drivers/char/tpm/tpm.c 2005-02-09 14:12:30.695624216
> -0600
> @@ -213,7 +213,7 @@ static u8 pcrread[] = {
> 0, 0, 0, 0 /* PCR index */
> };
>
> -static ssize_t show_pcrs(struct device *dev, char *buf)
> +ssize_t show_pcrs(struct device *dev, char *buf)
This is too generic a name for global namespace.
> {
> u8 data[READ_PCR_RESULT_SIZE];
> ssize_t len;
> @@ -245,8 +245,7 @@ static ssize_t show_pcrs(struct device *
> }
> return str - buf;
> }
> -
> -static DEVICE_ATTR(pcrs, S_IRUGO, show_pcrs, NULL);
> +EXPORT_SYMBOL_GPL(show_pcrs);
>
> #define READ_PUBEK_RESULT_SIZE 314
> static u8 readpubek[] = {
> @@ -255,7 +254,7 @@ static u8 readpubek[] = {
> 0, 0, 0, 124, /* TPM_ORD_ReadPubek */
> };
>
> -static ssize_t show_pubek(struct device *dev, char *buf)
> +ssize_t show_pubek(struct device *dev, char *buf)
same here
> {
> u8 data[READ_PUBEK_RESULT_SIZE];
> ssize_t len;
> @@ -308,7 +307,7 @@ static ssize_t show_pubek(struct device
> return str - buf;
> }
>
> -static DEVICE_ATTR(pubek, S_IRUGO, show_pubek, NULL);
> +EXPORT_SYMBOL_GPL(show_pubek);
>
> #define CAP_VER_RESULT_SIZE 18
> static u8 cap_version[] = {
> @@ -329,7 +328,7 @@ static u8 cap_manufacturer[] = {
> 0, 0, 1, 3
> };
>
> -static ssize_t show_caps(struct device *dev, char *buf)
> +ssize_t show_caps(struct device *dev, char *buf)
and here.
> {
> u8 data[READ_PUBEK_RESULT_SIZE];
> ssize_t len;
> @@ -362,7 +361,26 @@ static ssize_t show_caps(struct device *
> return str - buf;
> }
>
> -static DEVICE_ATTR(caps, S_IRUGO, show_caps, NULL);
> +EXPORT_SYMBOL_GPL(show_caps);
> +
> +ssize_t store_cancel(struct device *dev, const char *buf,
> + size_t count)
and here
> +{
> + struct tpm_chip *chip = dev_get_drvdata(dev);
> + if (chip == NULL)
> + return 0;
> +
Do you want any extra protection besides mode bits (S_IWUSR | S_IWGRP)?
How privileged should this operation be?
> + chip->vendor->cancel(chip);
> +
> + down(>timer_manipulation_mutex);
> + if (timer_pending(>device_timer))
> + mod_timer(>device_timer, jiffies);
> + up(>timer_manipulation_mutex);
> +
> + return count;
> +}
> +
> +EXPORT_SYMBOL_GPL(store_cancel);
>
> /*
> * Device file system interface to the TPM
> @@ -524,6 +542,7 @@ EXPORT_SYMBOL_GPL(tpm_read);
> void tpm_remove_hardware(struct device *dev)
> {
> struct tpm_chip *chip = dev_get_drvdata(dev);
> + int i;
>
> if (chip == NULL) {
> dev_err(dev, "No device data found\n");
> @@ -539,9 +558,8 @@ void tpm_remove_hardware(struct device *
> dev_set_drvdata(dev, NULL);
> misc_deregister(>vendor->miscdev);
>
> - device_remove_file(dev, _attr_pubek);
> - device_remove_file(dev, _attr_pcrs);
> - device_remove_file(dev, _attr_caps);
> + for ( i = 0; i < TPM_NUM_ATTR; i++ )
> + device_remove_file(dev, >vendor->attr[i]);
>
> dev_mask[chip->dev_num / 32] &= !(1 << (chip->dev_num % 32));
>
> @@ -663,10 +681,9 @@ dev_num_search_complete:
>
> list_add(>list, _chip_list);
>
> - device_create_file(dev, _attr_pubek);
> - device_create_file(dev, _attr_pcrs);
> - device_create_file(dev, _attr_caps);
> -
> + for ( i = 0; i < TPM_NUM_ATTR; i++ )
> + device_create_file(dev, >vendor->attr[i]);
> +
> return 0;
> }
>
> diff -uprN linux-2.6.10/drivers/char/tpm/tpm.h
> linux-2.6.10-tpm/drivers/char/tpm/tpm.h
> --- linux-2.6.10/drivers/char/tpm/tpm.h 2005-02-04 15:03:03.0
> -0600
> +++ linux-2.6.10-tpm/drivers/char/tpm/tpm.h 2005-02-09 14:12:30.702623152
> -0600
> @@ -25,11 +25,23 @@
> #include
>
> #define TPM_TIMEOUT msecs_to_jiffies(5)
> +#define TPM_NUM_ATTR 4
>
> /* TPM addresses */
> #define TPM_ADDR0x4E
> #define TPM_DATA0x4F
>
> +extern ssize_t show_pubek(struct device *, char *);
> +extern ssize_t show_pcrs(struct device *, char *);
> +extern ssize_t show_caps(struct device *, char *);
>
[PATCH] PPC64 collect and export low-level cpu usage statistics
POWER5 machines have a per-hardware-thread register which counts at a
rate which is proportional to the percentage of cycles on which the
cpu dispatches an instruction for this thread (if the thread gets all
the dispatch cycles it counts at the same rate as the timebase
register). This register is also context-switched by the hypervisor.
Thus it gives a fine-grained measure of the actual cpu usage by the
thread over time.
This patch adds code to read this register every timer interrupt and
on every context switch. The total over all virtual processors is
available through the existing /proc/ppc64/lparcfg file, giving a
way to measure the total cpu usage over the whole partition.
Andrew, this is relatively non-invasive, but nevertheless you may
prefer to put it in -mm until 2.6.11 is out.
Signed-off-by: Manish Ahuja <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.5/arch/ppc64/kernel/lparcfg.c test/arch/ppc64/kernel/lparcfg.c
--- linux-2.5/arch/ppc64/kernel/lparcfg.c 2005-01-06 13:13:08.0
+1100
+++ test/arch/ppc64/kernel/lparcfg.c2005-02-09 22:38:05.508190616 +1100
@@ -33,8 +33,9 @@
#include
#include
#include
+#include
-#define MODULE_VERS "1.5"
+#define MODULE_VERS "1.6"
#define MODULE_NAME "lparcfg"
/* #define LPARCFG_DEBUG */
@@ -214,13 +215,20 @@
}
static unsigned long get_purr(void);
-/* ToDo: get sum of purr across all processors. The purr collection code
- * is coming, but at this time is still problematic, so for now this
- * function will return 0.
- */
+
+/* Track sum of all purrs across all processors. This is used to further */
+/* calculate usage values by different applications */
+
static unsigned long get_purr(void)
{
unsigned long sum_purr = 0;
+ int cpu;
+ struct cpu_usage *cu;
+
+ for_each_cpu(cpu) {
+ cu = _cpu(cpu_usage_array, cpu);
+ sum_purr += cu->current_tb;
+ }
return sum_purr;
}
diff -urN linux-2.5/arch/ppc64/kernel/process.c test/arch/ppc64/kernel/process.c
--- linux-2.5/arch/ppc64/kernel/process.c 2005-01-29 09:58:49.0
+1100
+++ test/arch/ppc64/kernel/process.c2005-02-10 08:09:22.428216944 +1100
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#ifndef CONFIG_SMP
struct task_struct *last_task_used_math = NULL;
@@ -168,6 +169,8 @@
#endif /* CONFIG_ALTIVEC */
+DEFINE_PER_CPU(struct cpu_usage, cpu_usage_array);
+
struct task_struct *__switch_to(struct task_struct *prev,
struct task_struct *new)
{
@@ -206,6 +209,21 @@
new_thread = >thread;
old_thread = >thread;
+/* Collect purr utilization data per process and per processor wise */
+/* purr is nothing but processor time base */
+
+#if defined(CONFIG_PPC_PSERIES)
+ if (cur_cpu_spec->firmware_features & FW_FEATURE_SPLPAR) {
+ struct cpu_usage *cu = &__get_cpu_var(cpu_usage_array);
+ long unsigned start_tb, current_tb;
+ start_tb = old_thread->start_tb;
+ cu->current_tb = current_tb = mfspr(SPRN_PURR);
+ old_thread->accum_tb += (current_tb - start_tb);
+ new_thread->start_tb = current_tb;
+ }
+#endif
+
+
local_irq_save(flags);
last = _switch(old_thread, new_thread);
diff -urN linux-2.5/arch/ppc64/kernel/time.c test/arch/ppc64/kernel/time.c
--- linux-2.5/arch/ppc64/kernel/time.c 2005-01-22 09:25:41.0 +1100
+++ test/arch/ppc64/kernel/time.c 2005-02-10 08:09:34.412257896 +1100
@@ -334,6 +334,14 @@
}
#endif
+/* collect purr register values often, for accurate calculations */
+#if defined(CONFIG_PPC_PSERIES)
+ if (cur_cpu_spec->firmware_features & FW_FEATURE_SPLPAR) {
+ struct cpu_usage *cu = &__get_cpu_var(cpu_usage_array);
+ cu->current_tb = mfspr(SPRN_PURR);
+ }
+#endif
+
irq_exit();
return 1;
diff -urN linux-2.5/include/asm-ppc64/processor.h
test/include/asm-ppc64/processor.h
--- linux-2.5/include/asm-ppc64/processor.h 2005-01-17 08:47:37.0
+1100
+++ test/include/asm-ppc64/processor.h 2005-02-09 22:38:05.528187576 +1100
@@ -562,7 +562,9 @@
double fpr[32];/* Complete floating point set */
unsigned long fpscr; /* Floating point status (plus pad) */
unsigned long fpexc_mode; /* Floating-point exception mode */
- unsigned long pad[3]; /* was saved_msr, saved_softe */
+ unsigned long start_tb; /* Start purr when proc switched in */
+ unsigned long accum_tb; /* Total accumilated purr for process */
+ unsigned long pad;/* was saved_msr, saved_softe */
#ifdef CONFIG_ALTIVEC
/* Complete AltiVec register set */
vector128 vr[32] __attribute((aligned(16)));
diff -urN linux-2.5/include/asm-ppc64/time.h
Re: [RFC/RFT] [patch] Elo serial touchscreen driver
On Wed, 2005-02-09 21:10:32 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > On Wed, Feb 09, 2005 at 09:03:51PM +0100, Jan-Benedict Glaw wrote: > > The problematic part is that this needs to be done at a quite low level, > > since POS keyboards may send quite a lot more than make/break codes in > > "proper" order... > > I'll need some specific examples of protocols the keyboard use to judge > how to tackle that. I'll try to get some showkeys dumps for you tomorrow. This will be sent to you privately since it may contain real card data... MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier BÃrger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: [RFC/RFT] [patch] Elo serial touchscreen driver
On Wed, Feb 09, 2005 at 10:39:30PM +0100, Jan-Benedict Glaw wrote: > On Wed, 2005-02-09 20:51:43 +, Paulo Marques <[EMAIL PROTECTED]> > wrote in message <[EMAIL PROTECTED]>: > > Jan-Benedict Glaw wrote: > > >On Wed, 2005-02-09 18:08:10 +, Paulo Marques <[EMAIL PROTECTED]> > > >wrote in message <[EMAIL PROTECTED]>: > > >That's IMHO not brain-damaged, but pure physics: just consider scratches > > >or dust (or other substances) applied to the touch foil. This happens > > >all the time, so the touch screen gets out of calibration. This won't > > >happen on a screen used only twice a day. But think about a touch screen > > >that's tortured all the day with pencils, finger rings, dirty fingers, > > > > The brain-damaged part wasn't the calibration. It was the calibration > > being done in the touchscreen itself, instead of letting the PC handle > > it for them. We will always need calibration, of course. > > Again, you cannot map 0..\inf Ohm or 0..\inf nF to a given set > [0..0x] of coordinates. The physical characteristics of touchscreens > *can* change, so you need to recalibrate the A/D converter itself. Both 4-wire and 5-wire resistive touchscreens work as voltage dividers. Thus the chip doesn't have to care about the total resistance, it just applies voltage on two wires and the voltage on the other two corresponds proportionally to the position. That's one axis measurement. For the other axis, the role of the wires is simply swapped. For capacitive touch sensors it's very much different, and the controller usually is matched to the sensor, since the sensor usually has several electrodes, so the controller 'knows' about the sensor because they were manufactured together. Regarding surface wave sensors, I'm not completely sure about the need of calibration to get the range there. I'd assume that since they measure wave reflections from reflector fins, and they know the number of the fins (== number of reflections), that they'll be able to stretch the range properly as well. > > We let the touch screen send the widest range it can muster, so that we > > don't have quantization errors. We then calibrate in software as for any > > other touch screen, using the coordinates sent as "raw data". > > That cannot be done. Just hit a resistor-based touchscreen once with a > hammer. You'll probably see that you need a physical recalibration > then... Or flood it with water-solved citronic acid and let is on the > screen for some days. That's funny, but it's real life... You'll need a new touchscreen most likely. The hammer will break the glass if you hit it properly, and if the citric acid gets between the resistive layers, you get nonlinear distortion of the resistivity and that cannot be calibrated for. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to retrieve version from kernel source (the right way)?
> But... what is the right way to do this? I think you are looking for: make kernelrelease 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: [RFC/RFT] [patch] Elo serial touchscreen driver
On Wed, 2005-02-09 20:51:43 +, Paulo Marques <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Jan-Benedict Glaw wrote: > >On Wed, 2005-02-09 18:08:10 +, Paulo Marques <[EMAIL PROTECTED]> > >wrote in message <[EMAIL PROTECTED]>: > >That's IMHO not brain-damaged, but pure physics: just consider scratches > >or dust (or other substances) applied to the touch foil. This happens > >all the time, so the touch screen gets out of calibration. This won't > >happen on a screen used only twice a day. But think about a touch screen > >that's tortured all the day with pencils, finger rings, dirty fingers, > > The brain-damaged part wasn't the calibration. It was the calibration > being done in the touchscreen itself, instead of letting the PC handle > it for them. We will always need calibration, of course. Again, you cannot map 0..\inf Ohm or 0..\inf nF to a given set [0..0x] of coordinates. The physical characteristics of touchscreens *can* change, so you need to recalibrate the A/D converter itself. > >Min/Max values (as of protocol theory) is possibly not the very best you > >can do with the hardware. I more thing about submitting these (after > >physical calibration) to the kernel driver to supply them to it's users. > > You're missing my point completely... :( > > What I was suggesting was that we don't use physical calibration *at all*. But there *needs* to be a way to do that. I don't want to place this functionality into the kernel, but we need to have a program for that at some time. Current solutions are bad hacks and don't actually work reliably. > We let the touch screen send the widest range it can muster, so that we > don't have quantization errors. We then calibrate in software as for any > other touch screen, using the coordinates sent as "raw data". That cannot be done. Just hit a resistor-based touchscreen once with a hammer. You'll probably see that you need a physical recalibration then... Or flood it with water-solved citronic acid and let is on the screen for some days. That's funny, but it's real life... > >>Modern touchscreens just send the A/D data to the PC, and let the real > >>processor do the math (it can even do more complex calculations, like > >>compensate for rotation, etc.). IMHO calibration should be handled by > >>software. > > > >Is this done eg. by Elo, Mutouch, Fujitsu, T-Sharc (to only name the > >most common)? I don't think so... > > If you don't try to configure the "physical calibration" of a Elo, > MuTouch, etc, they send coordinates in a nice 0..2^N-1 format. That is > the best approach IMHO. It is -- as long as the physical characteristics don't change all that much. Unfortunately (at least for real-life POS usage) this happens frequently. > >[...] > >This only happens if you don't configurethe MSR properly :-) Most of > >them can be configured to send quite complex (as in: structured) init > >sequences that cannot be generated by a keyboard (ie multiple break > >codes without make codes and the like). > > Even if they can not be generated by a keyboard, if you don't handle > them in special way, you'll get a lot of rubbish. We do handle the > special sequences when available, but there still barcode scanners that > don't generate a nice sequence. > > There are even barcode scanners that generate things like Alt> without even > bothering to release the numeric keys, to generate ASCII code XYZ :P Which then either needs to be parsed by userspace (which needs access to raw make/break codes and be able to send data to the kbd) or we write keyboard-specific Input API drivers for them. However, a userspace library for that (if raw access to the keyboard is given) could do the same job. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier BÃrger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: [PATCH] Update to IPMI driver to support old DMI spec
Bukie Mabayoje wrote: Corey Minyard wrote: BTW, I'm also working with the person who had the trouble with the I2C non-blocking driver updates, but we haven't figured it out yet. Hopefully soon. (Though that has nothing to do with this patch.) Thanks, -Corey --- The 1999 version of the DMI spec had a different configuration than the newer versions for the IPMI configuration information. Are you referring to the System Management BIOS Reference Specification version 2.3.1 16 March 1999? Yes, that is correct. -Corey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
Bartlomiej Zolnierkiewicz wrote:
Thanks, I see that you did global replacement of __devinit
by __init and __devexit by __exit - it seems correct *only* if:
- there can be only one i2c controller in the system
- there can be only one host bridge in the system
- i2c core calls ->probe only once during driver init
and ->remove only once during driver exit
If all conditions are really true some comment about
this in the code would still be be nice.
You're right. The 'dev' is back except on the module_init/exit routines.
While at it more silly, minor nitpicking ;)
+static void
+mv64xxx_i2c_wait_for_completion(struct mv64xxx_i2c_data *drv_data)
+{
+ longflags, time_left;
'flags' are of 'unsigned long' not 'long' type
Fixed.
there is no need for explicit return in void functions
I can't find any definitive policy on this. I kind of like the explicit
return, I don't know why. I've had others make the same comment,
though, so I'll remove them since it obviously bothers people.
Attached is a replacement patch.
Thanks again, Bartlomiej.
Mark
--
Marvell makes a line of host bridge for PPC and MIPS systems. On those
bridges is an i2c controller. This patch adds the driver for that i2c
controller.
Please apply.
Depends on patch submitted by Jean Delvare:
http://archives.andrew.net.au/lm-sensors/msg29405.html
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-02-09 14:32:24 -07:00
+++ b/drivers/i2c/busses/Kconfig2005-02-09 14:32:24 -07:00
@@ -486,4 +486,14 @@
This driver can also be built as a module. If so, the module
will be called i2c-pca-isa.
+config I2C_MV64XXX
+ tristate "Marvell mv64xxx I2C Controller"
+ depends on I2C && MV64X60 && EXPERIMENTAL
+ help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mv64xxx.
+
endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile 2005-02-09 14:32:24 -07:00
+++ b/drivers/i2c/busses/Makefile 2005-02-09 14:32:24 -07:00
@@ -21,6 +21,7 @@
obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
obj-$(CONFIG_I2C_KEYWEST) += i2c-keywest.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
+obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o
obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o
obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/busses/i2c-mv64xxx.c 2005-02-09 14:32:24 -07:00
@@ -0,0 +1,596 @@
+/*
+ * drivers/i2c/busses/i2c-mv64xxx.c
+ *
+ * Driver for the i2c controller on the Marvell line of host bridges for MIPS
+ * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 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.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register defines */
+#defineMV64XXX_I2C_REG_SLAVE_ADDR 0x00
+#defineMV64XXX_I2C_REG_DATA0x04
+#defineMV64XXX_I2C_REG_CONTROL 0x08
+#defineMV64XXX_I2C_REG_STATUS 0x0c
+#defineMV64XXX_I2C_REG_BAUD0x0c
+#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
+#defineMV64XXX_I2C_REG_SOFT_RESET 0x1c
+
+#defineMV64XXX_I2C_REG_CONTROL_ACK 0x0004
+#defineMV64XXX_I2C_REG_CONTROL_IFLG0x0008
+#defineMV64XXX_I2C_REG_CONTROL_STOP0x0010
+#defineMV64XXX_I2C_REG_CONTROL_START 0x0020
+#defineMV64XXX_I2C_REG_CONTROL_TWSIEN 0x0040
+#defineMV64XXX_I2C_REG_CONTROL_INTEN 0x0080
+
+/* Ctlr status values */
+#defineMV64XXX_I2C_STATUS_BUS_ERR 0x00
+#defineMV64XXX_I2C_STATUS_MAST_START 0x08
+#defineMV64XXX_I2C_STATUS_MAST_REPEAT_START0x10
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK 0x20
+#defineMV64XXX_I2C_STATUS_MAST_WR_ACK 0x28
+#defineMV64XXX_I2C_STATUS_MAST_WR_NO_ACK 0x30
+#defineMV64XXX_I2C_STATUS_MAST_LOST_ARB
Re: 2.4.x kernel BUG at filemap.c:81
On Wed, Feb 09, 2005 at 03:47:28PM -0500, Todd Shetter wrote: > Running slackware 10 and 10.1, with kernels 2.4.26, 2.4.27, 2.4.28, > 2.4.29 with highmem 4GB, and highmem i/o support enabled, I get a > system lockup. This happens in both X and console. Happens with and > without my Nvidia drivers loaded. I cannot determine what makes this > bug present it self besides highmem and high i/o support enabled. Im > guessing the system is fine until highmem is actually used to some > point and then it borks, but I really have no idea and so im just > making a random guess. I ran memtest86 for a few hours a while ago > thinking that it may be bad memory, but that did not seem to be the > problem. > > If you need anymore information, or have questions, or wish me to test > anything, PLEASE feel free to contact me, I would really like to see > this bug resolved. =) > > -- > Todd Shetter > > > Feb 8 19:49:31 quark kernel: kernel BUG at filemap.c:81! > Feb 8 19:49:31 quark kernel: invalid operand: > Feb 8 19:49:31 quark kernel: CPU:0 > Feb 8 19:49:31 quark kernel: EIP:0010:[]Tainted: P > > > > > >>>Hi Todd, > >>> > >>>Why is your kernel tainted ? > >>> > >>I had the nvidia 1.0-6629 driver loaded when I got that error. I > >>compiled the kernel using the slackware 10.1 config, enabled highmem 4GB > >>support, highmem i/o, and then some kernel hacking options including > >>debugging for highmen related things. > >> > >>I booted, loaded X with KDE, opened firefox a few times, and then > >>started running hdparm because some newer 2.4.x kernels dont play nice > >>with my SATA, ICH5, and DMA. hdparm segfaulted while running the drive > >>read access portion of its tests, and things locked up from there in > >>about 30secs. > >> > >>I've gotten the same error with the nvidia driver not loaded, so I dont > >>think that is part of the problem. > >> > >>As I said, if you want me to test or try anything feel free to ask. =) > >> > > > >Todd, > > > >Would be interesting to have the oops output without the kernel nvidia > >module. > >Do you have that saved? > > > > > > > Sorry, it took me FOREVER to get this bug to appear again, and this time > its a little different. Hum, both BUGs are due to a page with alive ->buffers mapping. Did it crashed right after hdparm now too? Can you boot your box without SATA drivers, configuring the interface to IDE mode ? Which problems are you facing with newer v2.4.x kernels and SATA? > Feb 9 15:20:37 quark kernel: kernel BUG at page_alloc.c:142! > Feb 9 15:20:37 quark kernel: invalid operand: > Feb 9 15:20:37 quark kernel: CPU:0 > Feb 9 15:20:37 quark kernel: EIP:0010:[]Not tainted > Feb 9 15:20:37 quark kernel: EFLAGS: 00013206 > Feb 9 15:20:37 quark kernel: eax: 0114 ebx: c17e1160 ecx: > 4000 edx: > Feb 9 15:20:37 quark kernel: esi: edi: eea037f0 ebp: > f0f27f24 esp: f0f27ef0 > Feb 9 15:20:37 quark kernel: ds: 0018 es: 0018 ss: 0018 > Feb 9 15:20:37 quark kernel: Process X (pid: 2206, stackpage=f0f27000) > Feb 9 15:20:37 quark kernel: Stack: c0324d68 00037000 c120 c17e11c0 > c0324cb8 c1030020 c0324cf0 3207 > Feb 9 15:20:37 quark kernel:c17e1160 f0f27f24 2a05c067 001fc000 > eea037f0 f0f27f68 c012531c c17e1160 > Feb 9 15:20:37 quark kernel:c17e1160 01fd 002f 4980 > 496f f0eee494 4940 > Feb 9 15:20:37 quark kernel: Call Trace:[] [] > [] [] > Feb 9 15:20:37 quark kernel: > Feb 9 15:20:37 quark kernel: Code: 0f 0b 8e 00 bf 06 2e c0 8b 53 08 85 > d2 74 08 0f 0b 90 00 bf > Feb 9 15:30:41 quark kernel: <6>SysRq : SAK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Update to IPMI driver to support old DMI spec
Corey Minyard wrote:
> BTW, I'm also working with the person who had the trouble with the I2C
> non-blocking driver updates, but we haven't figured it out yet.
> Hopefully soon. (Though that has nothing to do with this patch.)
>
> Thanks,
>
> -Corey
>
>
> ---
> The 1999 version of the DMI spec had a different configuration
> than the newer versions for the IPMI configuration information.
Are you referring to the System Management BIOS Reference Specification
version 2.3.1 16 March 1999?
>
> This patch handles the differences between the two.
>
> Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
>
> Index: linux-2.6.11-rc3/drivers/char/ipmi/ipmi_si_intf.c
> ===
> --- linux-2.6.11-rc3.orig/drivers/char/ipmi/ipmi_si_intf.c
> +++ linux-2.6.11-rc3/drivers/char/ipmi/ipmi_si_intf.c
> @@ -1578,46 +1578,53 @@
> u8 *data = (u8 *)dm;
> unsigned long base_addr;
> u8 reg_spacing;
> + u8 len = dm->length;
> dmi_ipmi_data_t *ipmi_data = dmi_data+intf_num;
>
> ipmi_data->type = data[4];
>
> memcpy(_addr, data+8, sizeof(unsigned long));
> - if (base_addr & 1) {
> - /* I/O */
> - base_addr &= 0xFFFE;
> + if (len >= 0x11) {
> + if (base_addr & 1) {
> + /* I/O */
> + base_addr &= 0xFFFE;
> + ipmi_data->addr_space = IPMI_IO_ADDR_SPACE;
> + }
> + else {
> + /* Memory */
> + ipmi_data->addr_space = IPMI_MEM_ADDR_SPACE;
> + }
> + /* If bit 4 of byte 0x10 is set, then the lsb for the address
> + is odd. */
> + ipmi_data->base_addr = base_addr | ((data[0x10] & 0x10) >> 4);
> +
> + ipmi_data->irq = data[0x11];
> +
> + /* The top two bits of byte 0x10 hold the register spacing. */
> + reg_spacing = (data[0x10] & 0xC0) >> 6;
> + switch(reg_spacing){
> + case 0x00: /* Byte boundaries */
> + ipmi_data->offset = 1;
> + break;
> + case 0x01: /* 32-bit boundaries */
> + ipmi_data->offset = 4;
> + break;
> + case 0x02: /* 16-byte boundaries */
> + ipmi_data->offset = 16;
> + break;
> + default:
> + /* Some other interface, just ignore it. */
> + return -EIO;
> + }
> + } else {
> + /* Old DMI spec. */
> + ipmi_data->base_addr = base_addr;
> ipmi_data->addr_space = IPMI_IO_ADDR_SPACE;
> - }
> - else {
> - /* Memory */
> - ipmi_data->addr_space = IPMI_MEM_ADDR_SPACE;
> - }
> -
> - /* The top two bits of byte 0x10 hold the register spacing. */
> - reg_spacing = (data[0x10] & 0xC0) >> 6;
> - switch(reg_spacing){
> - case 0x00: /* Byte boundaries */
> ipmi_data->offset = 1;
> - break;
> - case 0x01: /* 32-bit boundaries */
> - ipmi_data->offset = 4;
> - break;
> - case 0x02: /* 16-byte boundaries */
> - ipmi_data->offset = 16;
> - break;
> - default:
> - /* Some other interface, just ignore it. */
> - return -EIO;
> }
>
> ipmi_data->slave_addr = data[6];
>
> - /* If bit 4 of byte 0x10 is set, then the lsb for the address
> - is odd. */
> - ipmi_data->base_addr = base_addr | ((data[0x10] & 0x10) >> 4);
> -
> - ipmi_data->irq = data[0x11];
> -
> if (is_new_interface(-1, ipmi_data->addr_space,ipmi_data->base_addr))
> {
> dmi_data_entries++;
> return 0;
-
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3
On Wed, 09 Feb 2005 21:42:39 +0100 Einar Lück <[EMAIL PROTECTED]> wrote: > We considered the routing case: in the routing case ip_route_input is called. > In this case we just select the first route in the cache which is always the > same > (we ensure that). Consequently, the routing behaviour is not changed in this > case and > remains in the way you like it. Indeed. You're right. Let me re-review your second patch with this new understanding in mind :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 / PCMCIA not working/panic on AVERATEC 3500
Hi, > Socket status: 0720 This looks strange. Socket status 0720 can't really be true -- I assume there is a problem with the resource allocation. Can you send me /proc/iomem /proc/ioport please? Thanks, Dominik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [SERIAL] add TP560 data/fax/modem support
On Tue, 2005-02-08 at 07:25 -0500, linux-os wrote: > On Mon, 7 Feb 2005, Bjorn Helgaas wrote: > > > On Mon, 2005-02-07 at 15:12 -0500, linux-os wrote: > >> I thought somebody promised to add a pci_route_irq(dev) or some > >> such so that the device didn't have to be enabled before > >> the IRQ was correct. > >> > >> I first reported this bad IRQ problem back in December of 2004. > >> Has the new function been added? > > > > That's a completely different problem. The point here is that > > the serial driver currently doesn't do anything with the TP560 > > (no pci_enable_device(), no pci_route_irq(), no nothing). Then > > when setserial comes along and force-feeds the driver with the > > IO and IRQ info, there's nothing at that point that does anything > > to enable the device or route its interrupt either. > > > > I did raise the idea of adding a pci_route_irq() interface, but > > to be honest, I was never convinced of its general usefulness. > > There have been two PCI drivers in the past three days where > users have reported that the IRQ was wrong. If you've got pointers to these two reports, please provide them. > One patch was > provided to enable the device before requesting the IRQ, this > being inherently dangerous. So, if you are the one who > re-wrote the PCI stuff so that the IRQ is wrong when the > device is claimed, then I think you have a duty to fix the > code that you have broken. Most drivers in the tree call pci_enable_device() before request_irq(). That was the case even before my changes. Dangerous? Maybe, but I didn't make it more so. > The correct way to fix the broken code is to make sure that > the IRQ, reported in the structure, is correct. Alternate > methods might be a pci_route_irq() function. Or perhaps, the IRQ could be routed in pci_setup_device(). But, by the principle of "if you don't use it, don't touch it", there *is* something to be said for the fact that the current code doesn't touch IRQ routing unless a driver actually claims the device. > The existing PCI code is broken. The fact that an invalid > IRQ is reported in the structure is PROOF that it is broken > and requires no further discussion. Then I'm sure your patch to fix it will be accepted without much dissent. > Many of us have to > use this stuff in a professional environment, we can't > enable devices without an interrupt handler in place > because it is not allowed in code that is subject to > peer review. We also can't use code when such problems > as invalid values in returned data are discovered. Nobody's forcing you to use "this stuff." > Two months ago I discovered this problem and reported it, hoping > that the person who broke existing code would fix it. It has > not been fixed. The fact is, yours is the only report of an issue with the structure of the new code. And it apparently only concerns an out-of-tree driver. Still, I agree that it might be good to do something about it. But you haven't provided pointers to the hardware specs or driver involved. So I'm not going to go too much out of my way to fix it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/RFT] [patch] Elo serial touchscreen driver
Jan-Benedict Glaw wrote: On Wed, 2005-02-09 18:08:10 +, Paulo Marques <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: [...] Touch screens doing this are severely brain-damaged. And yes, I've come across a few of them, but not lately. That's IMHO not brain-damaged, but pure physics: just consider scratches or dust (or other substances) applied to the touch foil. This happens all the time, so the touch screen gets out of calibration. This won't happen on a screen used only twice a day. But think about a touch screen that's tortured all the day with pencils, finger rings, dirty fingers, The brain-damaged part wasn't the calibration. It was the calibration being done in the touchscreen itself, instead of letting the PC handle it for them. We will always need calibration, of course. ... I would say that a tool to recover the touch screen into a "usable" state, by talking directly to the serial port, and "calibrating" it to max possible / min possible values would be the best way to deal with this. Min/Max values (as of protocol theory) is possibly not the very best you can do with the hardware. I more thing about submitting these (after physical calibration) to the kernel driver to supply them to it's users. You're missing my point completely... :( What I was suggesting was that we don't use physical calibration *at all*. We let the touch screen send the widest range it can muster, so that we don't have quantization errors. We then calibrate in software as for any other touch screen, using the coordinates sent as "raw data". Modern touchscreens just send the A/D data to the PC, and let the real processor do the math (it can even do more complex calculations, like compensate for rotation, etc.). IMHO calibration should be handled by software. Is this done eg. by Elo, Mutouch, Fujitsu, T-Sharc (to only name the most common)? I don't think so... If you don't try to configure the "physical calibration" of a Elo, MuTouch, etc, they send coordinates in a nice 0..2^N-1 format. That is the best approach IMHO. [...] This only happens if you don't configurethe MSR properly :-) Most of them can be configured to send quite complex (as in: structured) init sequences that cannot be generated by a keyboard (ie multiple break codes without make codes and the like). Even if they can not be generated by a keyboard, if you don't handle them in special way, you'll get a lot of rubbish. We do handle the special sequences when available, but there still barcode scanners that don't generate a nice sequence. There are even barcode scanners that generate things like without even bothering to release the numeric keys, to generate ASCII code XYZ :P -- 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.4.x kernel BUG at filemap.c:81
Marcelo Tosatti wrote: On Wed, Feb 09, 2005 at 11:30:05AM -0500, Todd Shetter wrote: Marcelo Tosatti wrote: On Wed, Feb 09, 2005 at 12:15:03AM -0500, Todd Shetter wrote: Running slackware 10 and 10.1, with kernels 2.4.26, 2.4.27, 2.4.28, 2.4.29 with highmem 4GB, and highmem i/o support enabled, I get a system lockup. This happens in both X and console. Happens with and without my Nvidia drivers loaded. I cannot determine what makes this bug present it self besides highmem and high i/o support enabled. Im guessing the system is fine until highmem is actually used to some point and then it borks, but I really have no idea and so im just making a random guess. I ran memtest86 for a few hours a while ago thinking that it may be bad memory, but that did not seem to be the problem. If you need anymore information, or have questions, or wish me to test anything, PLEASE feel free to contact me, I would really like to see this bug resolved. =) -- Todd Shetter Feb 8 19:49:31 quark kernel: kernel BUG at filemap.c:81! Feb 8 19:49:31 quark kernel: invalid operand: Feb 8 19:49:31 quark kernel: CPU:0 Feb 8 19:49:31 quark kernel: EIP:0010:[]Tainted: P Hi Todd, Why is your kernel tainted ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ I had the nvidia 1.0-6629 driver loaded when I got that error. I compiled the kernel using the slackware 10.1 config, enabled highmem 4GB support, highmem i/o, and then some kernel hacking options including debugging for highmen related things. I booted, loaded X with KDE, opened firefox a few times, and then started running hdparm because some newer 2.4.x kernels dont play nice with my SATA, ICH5, and DMA. hdparm segfaulted while running the drive read access portion of its tests, and things locked up from there in about 30secs. I've gotten the same error with the nvidia driver not loaded, so I dont think that is part of the problem. As I said, if you want me to test or try anything feel free to ask. =) Todd, Would be interesting to have the oops output without the kernel nvidia module. Do you have that saved? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Sorry, it took me FOREVER to get this bug to appear again, and this time its a little different. Feb 9 15:20:37 quark kernel: kernel BUG at page_alloc.c:142! Feb 9 15:20:37 quark kernel: invalid operand: Feb 9 15:20:37 quark kernel: CPU:0 Feb 9 15:20:37 quark kernel: EIP:0010:[]Not tainted Feb 9 15:20:37 quark kernel: EFLAGS: 00013206 Feb 9 15:20:37 quark kernel: eax: 0114 ebx: c17e1160 ecx: 4000 edx: Feb 9 15:20:37 quark kernel: esi: edi: eea037f0 ebp: f0f27f24 esp: f0f27ef0 Feb 9 15:20:37 quark kernel: ds: 0018 es: 0018 ss: 0018 Feb 9 15:20:37 quark kernel: Process X (pid: 2206, stackpage=f0f27000) Feb 9 15:20:37 quark kernel: Stack: c0324d68 00037000 c120 c17e11c0 c0324cb8 c1030020 c0324cf0 3207 Feb 9 15:20:37 quark kernel:c17e1160 f0f27f24 2a05c067 001fc000 eea037f0 f0f27f68 c012531c c17e1160 Feb 9 15:20:37 quark kernel:c17e1160 01fd 002f 4980 496f f0eee494 4940 Feb 9 15:20:37 quark kernel: Call Trace:[] [] [] [] Feb 9 15:20:37 quark kernel: Feb 9 15:20:37 quark kernel: Code: 0f 0b 8e 00 bf 06 2e c0 8b 53 08 85 d2 74 08 0f 0b 90 00 bf Feb 9 15:30:41 quark kernel: <6>SysRq : SAK 00:00.0 Host bridge: Intel Corp. 82875P Memory Controller Hub (rev 02) Subsystem: ABIT Computer Corp.: Unknown device 1014 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 Region 0: Memory at e800 (32-bit, prefetchable) [size=128M] Capabilities: [e4] #09 [2106] Capabilities: [a0] AGP version 3.0 Status: RQ=32 Iso- ArqSz=2 Cal=2 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8 Command: RQ=1 ArqSz=0 Cal=2 SBA+ AGP- GART64- 64bit- FW- Rate= 00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP Controller (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: f000-0fff Memory behind bridge: f800-faff Prefetchable memory behind bridge: f000-f7ff BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset-
Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3
David S. Miller wrote: This was brought up before. It's the case where the system is acting as a router, you have to consider that case and not just the one where the local system is where the connections are originating from. Your trick only works because of how routes are cached per-socket. Once you get into the realm of traffic going through the machine as a router, the trick stops to work. We considered the routing case: in the routing case ip_route_input is called. In this case we just select the first route in the cache which is always the same (we ensure that). Consequently, the routing behaviour is not changed in this case and remains in the way you like it. Regards, Einar. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] Re: [PATCH 1/1] tpm: update tpm sysfs file ownership - updated version
On Wed, 9 Feb 2005, Greg KH wrote:
> On Wed, Feb 09, 2005 at 12:05:42PM -0600, Kylene Hall wrote:
> > @@ -539,9 +551,8 @@ void tpm_remove_hardware(struct device *
> > dev_set_drvdata(dev, NULL);
> > misc_deregister(>vendor->miscdev);
> >
> > - device_remove_file(dev, _attr_pubek);
> > - device_remove_file(dev, _attr_pcrs);
> > - device_remove_file(dev, _attr_caps);
> > + for ( i = 0; i < TPM_ATTRS; i++ )
> > + device_remove_file(dev, >attr[i]);
> >
> > dev_mask[chip->dev_num / 32] &= !(1 << (chip->dev_num % 32));
> >
>
> This code works?
>
> > @@ -608,6 +619,11 @@ int tpm_register_hardware(struct device
> > struct tpm_chip *chip;
> > int i, j;
> >
> > + DEVICE_ATTR(pcrs, S_IRUGO, show_pcrs, NULL);
> > + DEVICE_ATTR(pubek, S_IRUGO, show_pubek, NULL);
> > + DEVICE_ATTR(caps, S_IRUGO, show_caps, NULL);
> > + DEVICE_ATTR(cancel, S_IWUSR | S_IWGRP, NULL, store_cancel);
> > +
> > /* Driver specific per-device data */
> > chip = kmalloc(sizeof(*chip), GFP_KERNEL);
> > if (chip == NULL)
>
> You do realize you just created those attributes on the stack? And then
> you try to remove them from within a different scope above?
>
I didn't realize their was a string in the structure that wouldn't get
copied when I made the copy to the kmalloc'd struct. Here is an alternate
implementation that pushes the initialization into the respective specific
drivers via a MACRO which has the added benefit of getting the owner field
right from the start.
> thanks,
>
> greg k-h
Signed-off-by: Kylene Hall <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.10/drivers/char/tpm/tpm_atmel.c
linux-2.6.10-tpm/drivers/char/tpm/tpm_atmel.c
--- linux-2.6.10/drivers/char/tpm/tpm_atmel.c 2005-02-04 15:03:03.0
-0600
+++ linux-2.6.10-tpm/drivers/char/tpm/tpm_atmel.c 2005-02-09
14:12:30.711621784 -0600
@@ -131,6 +131,7 @@ static struct tpm_vendor_specific tpm_at
.req_complete_mask = ATML_STATUS_BUSY | ATML_STATUS_DATA_AVAIL,
.req_complete_val = ATML_STATUS_DATA_AVAIL,
.base = TPM_ATML_BASE,
+ .attr = TPM_DEVICE_ATTRS,
.miscdev.fops = _ops,
};
diff -uprN linux-2.6.10/drivers/char/tpm/tpm.c
linux-2.6.10-tpm/drivers/char/tpm/tpm.c
--- linux-2.6.10/drivers/char/tpm/tpm.c 2005-02-04 15:03:03.0 -0600
+++ linux-2.6.10-tpm/drivers/char/tpm/tpm.c 2005-02-09 14:12:30.695624216
-0600
@@ -213,7 +213,7 @@ static u8 pcrread[] = {
0, 0, 0, 0 /* PCR index */
};
-static ssize_t show_pcrs(struct device *dev, char *buf)
+ssize_t show_pcrs(struct device *dev, char *buf)
{
u8 data[READ_PCR_RESULT_SIZE];
ssize_t len;
@@ -245,8 +245,7 @@ static ssize_t show_pcrs(struct device *
}
return str - buf;
}
-
-static DEVICE_ATTR(pcrs, S_IRUGO, show_pcrs, NULL);
+EXPORT_SYMBOL_GPL(show_pcrs);
#define READ_PUBEK_RESULT_SIZE 314
static u8 readpubek[] = {
@@ -255,7 +254,7 @@ static u8 readpubek[] = {
0, 0, 0, 124, /* TPM_ORD_ReadPubek */
};
-static ssize_t show_pubek(struct device *dev, char *buf)
+ssize_t show_pubek(struct device *dev, char *buf)
{
u8 data[READ_PUBEK_RESULT_SIZE];
ssize_t len;
@@ -308,7 +307,7 @@ static ssize_t show_pubek(struct device
return str - buf;
}
-static DEVICE_ATTR(pubek, S_IRUGO, show_pubek, NULL);
+EXPORT_SYMBOL_GPL(show_pubek);
#define CAP_VER_RESULT_SIZE 18
static u8 cap_version[] = {
@@ -329,7 +328,7 @@ static u8 cap_manufacturer[] = {
0, 0, 1, 3
};
-static ssize_t show_caps(struct device *dev, char *buf)
+ssize_t show_caps(struct device *dev, char *buf)
{
u8 data[READ_PUBEK_RESULT_SIZE];
ssize_t len;
@@ -362,7 +361,26 @@ static ssize_t show_caps(struct device *
return str - buf;
}
-static DEVICE_ATTR(caps, S_IRUGO, show_caps, NULL);
+EXPORT_SYMBOL_GPL(show_caps);
+
+ssize_t store_cancel(struct device *dev, const char *buf,
+ size_t count)
+{
+ struct tpm_chip *chip = dev_get_drvdata(dev);
+ if (chip == NULL)
+ return 0;
+
+ chip->vendor->cancel(chip);
+
+ down(>timer_manipulation_mutex);
+ if (timer_pending(>device_timer))
+ mod_timer(>device_timer, jiffies);
+ up(>timer_manipulation_mutex);
+
+ return count;
+}
+
+EXPORT_SYMBOL_GPL(store_cancel);
/*
* Device file system interface to the TPM
@@ -524,6 +542,7 @@ EXPORT_SYMBOL_GPL(tpm_read);
void tpm_remove_hardware(struct device *dev)
{
struct tpm_chip *chip = dev_get_drvdata(dev);
+ int i;
if (chip == NULL) {
dev_err(dev, "No device data found\n");
@@ -539,9 +558,8 @@ void tpm_remove_hardware(struct device *
dev_set_drvdata(dev, NULL);
misc_deregister(>vendor->miscdev);
- device_remove_file(dev, _attr_pubek);
- device_remove_file(dev, _attr_pcrs);
- device_remove_file(dev, _attr_caps);
+ for ( i = 0; i < TPM_NUM_ATTR;
Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3
On Wed, 09 Feb 2005 21:23:57 +0100 Einar Lück <[EMAIL PROTECTED]> wrote: > We do not want per-flow multipathing. We want per connection > multipathing with fast route lookups (that's why we have all routes in > the cache). That is exactly what we implemented. Our tests prove that > a connection keeps its route as long as it lives (the dstentry remains > associated with the socket). That's why I do not really understand why > our approach hurts long lasting connections in any way. Can you > explain your point more precisely? This was brought up before. It's the case where the system is acting as a router, you have to consider that case and not just the one where the local system is where the connections are originating from. Your trick only works because of how routes are cached per-socket. Once you get into the realm of traffic going through the machine as a router, the trick stops to work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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, BK] clean up and unify asm-*/resource.h files
On Wed, 9 Feb 2005 19:02:19 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > New patch below. ... > this patch does the final consolidation of asm-*/resource.h file, > without changing any of the rlimit definitions on any architecture. I'm fine with this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: latest version of /proc fs documentation
pranay pramod345678 wrote: Hi, i tried for the latest versionof the /proc fs document supposed to be available online at http://skaro.nightcrawler.com/~bb/Docs/Proc but couldn't get it. can i get some help in this regard ? > Hi, Try http://kernelnewbies.org/documents/kdoc/procfs-guide/lkprocfsguide.html or http://kernelnewbies.org/documents/seq_file_howto.txt or http://lwn.net/Articles/22355/ -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3
David S. Miller wrote: So essentially you want per-flow multipathing. Except that you're implementation is over-optimizing it to the point where it's only per-flow for your specific case where the connections are short lived and high rate. This hurts long lasting connections. So I'm pretty much against this change. Do it right by making it occur per-connection attempt, it's not my problem to figure out how to do that efficiently, it's your's :-) We do not want per-flow multipathing. We want per connection multipathing with fast route lookups (that's why we have all routes in the cache). That is exactly what we implemented. Our tests prove that a connection keeps its route as long as it lives (the dstentry remains associated with the socket). That's why I do not really understand why our approach hurts long lasting connections in any way. Can you explain your point more precisely? Regards, Einar. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Linux Kernel Subversion Howto
On Wed, 9 Feb 2005, Larry McVoy wrote: > On Wed, Feb 09, 2005 at 12:17:48PM -0500, Nicolas Pitre wrote: > > On Tue, 8 Feb 2005, Larry McVoy wrote: > > > You know, you could change all this. Instead of complaining that we > > > are somehow hurting you, which virtually 100% of the readers know is > > > nonsense, you could be producing an alternative answer which is better. > > > > IMHO something is flawed in this whole argument. Why would someone be > > interested into any alternative answer for working on the Linux kernel > > tree if the whole thing can't be imported into it with the same > > granularity as can be found in BK? IOW what's the point to alternatives > > if you can't retrieve the entire workset? > > Please explain to me where the data is being lost. 100% of the patches > are available on bkbits.net with no license agreement required. They > always have been. Are you saying that it is now OK to write scripts that would bit bang on the bkbits http interface to fetch patches/comments with the purpose of populating an alternate scm? Andreas tried that a while ago but you threatened to shut the service down entirely if he was to continue. > The problem is that you want us to tell you how BK manages those patches. > That was never part of the agreement, in fact we made it clear in the > license that that information was considered to be IP and could not be > distributed. How BK does that is our business, not yours. I completely agree here. But just to be on the same page, let me quote Stelian's proposal here again: On Tue, 8 Feb 2005, Stelian Pop wrote: | What you could make available in the bkcvs export would be, for each | changeset (both for the changesets and for the merged changesets), | include three BKRevs: the changeset's one, the changeset's parent one, | and the changeset's merge parent one. | | That information could be used to reconstruct the entire tree, | using either bk-commit-head (preferred) or bkbits, provided you | put the BKRev: tag into the bk-commit-head posts too. | | Technicaly speaking this should be very easy for you to implement. Is the above actually part of the protected BK IP? Can anyone run with such information and clone BK in a smooth breeze with that? I don't see how such info can tell how BK manages it. > If you want > to know how BK does it you must go figure it out without the benefit > of BK itself or metadata managed by BK. I think what people want here is the tree structure representation in whatever form, not necessarily in the BK format. One example of that was provided above. You can't deny others access to the whole of the Linux kernel development history even if their purpose is to import it into a competing system (more on that below). > While I understand that you don't like it, is there no sense of fairness > left? We did the hard work to create BK. Some of us worked for *years* > without pay to create this product. Some of us put our life savings > into the product. It's our IP, we paid heavily to create this, is it > so unreasonable of us to want to protect our work? I believe we are > within our legal rights, or so our legal team tells us, but that should > be beside the point. It's our work. We paid for it. We certainly > don't have any obligation to tell you how we did it and to us it seems > pretty unreasonable that you don't just go off and do the work yourself. Again I wholeheartedly agree with you above. But that's not exactly the point. You certainly have the right to protect your work. But please admit that the Linux kernel developers own the right to move (100% not 96%) of the development tree with all its branches _they_ produced. In other words, the product of the current Linux BK repository is the result of those Linux developers not yours. Of course BK is the indispensable tool that made it possible, but BK could have been developed even without the Linux BK repository. So what people are asking for again and again is a way to represent in alternate form to BK internal metadata the Linux development tree structure but without you to give away the BK IP, be that in XML, plain text, or just with BK refs attached to patches like suggested above. Unless I'm completely dumb, this won't reveal anything about BK itself and how you did it? Now obviously enough some people will run away with that raw data and try to import the Linux kernel source tree in their own scm of choice. That's why I'm asking you "and so what?" Granted all the efforts you put into BK as you say above, do you really expect the alternative scm to suddenly be as functional and scalable as BK in a single swoop just because they can import the Linux BK tree with the same patch granularity as BK does? If you worked so hard on BK for many years it means the competition should be far behind. Therefore what do you fear? Note that if someone actually needs a big tree to test bench an alternate scm there
[BUG] in copy_siginfo_to_user32 on ppc64 (and others?) in 2.6.9/2.6.10
I found a bug which has since been fixed, but I'm hoping to save others the problems that I had tracking it down. It was fairly confusing--the information in the siginfo_t struct was different based on whether I used a signal handler in the regular way, or blocked the signal and retrieved the information using sigtimedwait(). After much instrumentation of the kernel, I tracked it down. Until recently (Jan 5), ppc64 had its own version of compat_sys_rt_sigtimedwait, which simply called sys_rt_sigtimedwait() then copied the results to the userspace struct using copy_siginfo_to_user32(). Unfortunately, sys_rt_sigtimedwait() only copies the lower 16 bits of si_code, and the ppc64 version of copy_siginfo_to_user32() keyed on the upper 16 bits to decide what information to copy. Thus, it always ended up in the default case of the switch statement, and only ever copied si_pid and si_uid. Oops. 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: [RFC/RFT] [patch] Elo serial touchscreen driver
On Wed, Feb 09, 2005 at 09:03:51PM +0100, Jan-Benedict Glaw wrote: > > > It's even worse. Most keyboards don't separate the real keys from > > > magnetic stripe reader events, and just simulate key presses for MSR > > > data. They expect the software to be in a state where it is waiting for > > > that data, and will process it accordingly. > > > > In that case I'm not sure if the kernel should care at all what the data > > is. > > The problematic part is that this needs to be done at a quite low level, > since POS keyboards may send quite a lot more than make/break codes in > "proper" order... I'll need some specific examples of protocols the keyboard use to judge how to tackle that. > > > What we've done in our application is to use the timings and sequence of > > > key presses to distinguish between normal key presses and MSR data :P > > > > Yes, embedded and single purpose systems are often full of hacks like > > this. > > ...and especially this problem can be better solved by reprogramming the > MCR readers :-) -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc3: Kylix application no longer works?
On Wed, 9 Feb 2005, Daniel Jacobowitz wrote:
On Tue, Feb 08, 2005 at 06:10:18PM -0800, Andrew Morton wrote:
It's asking for a lot of unwritable zeroed space. See this:
LOAD 0x00 0x08048000 0x08048000 0xb7354 0x1b7354 R E 0x1000
LOAD 0x0b7354 0x08200354 0x08200354 0x1e3e4 0x1f648 RW 0x1000
clear_user's probably not the right way to provide the extra zeroing.
Indeed, clear_user() refuses to zero data when it's not writable
to the user process ...
unsigned long
clear_user(void __user *to, unsigned long n)
{
might_sleep();
if (access_ok(VERIFY_WRITE, to, n))
__do_clear_user(to, n);
return n;
}
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/RFT] [patch] Elo serial touchscreen driver
On Wed, 2005-02-09 19:54:04 +, Paulo Marques <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > >We could have a library that would do that and link applications against > >it. It could also handle things like tap-n-drag, etc, something we > >certainly don't want in the kernel. > > I really like this idea :) > > A libtouch library that handled calibration (this includes mirroring and > swapping the coordinates) and other goodies (like filtering out short > "touch release" events while dragging, etc.) would be a good standard > interface for all applications. > > Being in user space would also mean that the library could do things > like keeping a /etc/touch.conf file where it would read default > calibration data, etc. ...and for X11. Maybe we'd start talking about an API for this lib? At least, my employer is interested I guess. (But this is OT wrt. the Linux kernel, could you contact me at [EMAIL PROTECTED]) MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier BÃrger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
2.6.11-rcX / 2.6.10-ac9 kernel do not more boot SATA disk on amd64
Hello, I can not more boot any kernel >=2.6.11-rcX also >=2.6.10-ac9 and latest bk6. But I have here Alan Cox 2.6.10-ac8 and Cons 2.6.10-ck5 running and booting fine without any problems. But now all kernel versions after that failed (with the same config tried) with: mount: error 6 mounting ext3 ... umount /initrd/dev failed ... on my Fedora Core 3 x86_64. The Fedora devel kernel also failed booting (2.6.11-rcX-bkX included and badly the SCSI support and all other as modules configured, what a shame... ;) . I've tried compiling all needed drivers like libata, sata_nv, SCSI support, ext3 (my root / fs),... in the kernel and also the most as always as modules with an initrd. With and wo "noapic", direct device names to grub given and always no chance to get all at the top named kernel to boot. What was there changed in this time? Or can anybody tell me, what I'm doing here wrong? :-( Hardware: nForce3 250Gb MSI K8N Neo Mainboard, Samsung SATA 80GB disk, / fs on ext3, x86_64 kernel/Fedora and gcc 3.4.3. config: http://www.marcush.de/config-2.6.11-rc3 Greetings, Marcus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] kernel/fork.c: VM accounting bugfix (2.6.11-rc3-bk5)
Chris Wright wrote: You missed one subtle point. That failure case actually unaccts 0 pages (note the use of charge). Not the nicest, but I believe correct. Right. I did miss that. Thanks for the explanations, Chris and Hugh, I appreciate it. Mark F. Haigh [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/RFT] [patch] Elo serial touchscreen driver
On Wed, 2005-02-09 20:18:17 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > > I would say that a tool to recover the touch screen into a "usable" > > state, by talking directly to the serial port, and "calibrating" it to > > max possible / min possible values would be the best way to deal with this. > > I agree with that. It could possibly even be put into the inputattach > init routine for the specific touchscreen. At least, inputattach should only recalibrate if asked for that. POS *users* are not very computer-skilled (typically, at least over here) and even automated recalibration (ie. the cashier software forces it because it detects that the user presses besides the actual images) are kind of stress to them... > > It's even worse. Most keyboards don't separate the real keys from > > magnetic stripe reader events, and just simulate key presses for MSR > > data. They expect the software to be in a state where it is waiting for > > that data, and will process it accordingly. > > In that case I'm not sure if the kernel should care at all what the data > is. The problematic part is that this needs to be done at a quite low level, since POS keyboards may send quite a lot more than make/break codes in "proper" order... > > What we've done in our application is to use the timings and sequence of > > key presses to distinguish between normal key presses and MSR data :P > > Yes, embedded and single purpose systems are often full of hacks like > this. ...and especially this problem can be better solved by reprogramming the MCR readers :-) MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier BÃrger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: [rfc] keytables - the new keycode->keysym mapping
On Wed, Feb 09, 2005 at 06:19:21PM +0100, Jirka Bohac wrote:
> There are presently two ways around this, neither of them good enough
> 1) assigning one of the other modifier keysyms to the CapsLock key
>-- the LED will not work
True.
> But by adding two modifiers to almost every keyboard map, you would
> increase the space occupied by the keymaps four times. ... erm ... eight
> times, because there is also this "applkey" (application keypad) flag,
> that will be needed as another modifier.
But keymaps are allocated dynamically.
Any number of new modifiers does not cost anything until
one actually uses some particular modifier combination.
New modifiers are not expensive at all.
> - the proposed keyboard map file format is IMHO much much nicer
Keymap files live in user space. The layout of a keymap file
has no bearing on the kernel implementation of keymaps.
We want a map (keystroke,current_modifiers) -> keycode.
The present kernel code organizes things in maps, one for
each modifier combination that people want to use.
You want to organize things per keystroke.
I see no great advantages. Many small arrays allocated
by kmalloc() leads to more overhead - probably your version
would lead to larger memory usage, but I have not checked.
It looks like your code is larger.
It also looks like your code is slower, with a loop instead of
a table lookup.
(Not that those things are very important, but I do not see
significant advantages for your setup. Maybe you have numbers?)
Of more interest are the added features.
You come with a single big patch, but some parts are independent.
For example, I see
+struct kbdiacruc {
+ unsigned char diacr, base;
+ unsigned int result;/* UCS */
+};
Ten years ago we made the mistake of being too careful with memory.
Today it is a very bad idea to introduce new ioctls that act on
8-bit quantities. These must all be int's.
An ioctl somewhat in this style has been proposed several times,
and I have no serious objections. If you want it, separate it out
and make it a patch on its own.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3
On Wed, 09 Feb 2005 14:28:49 +0100 Einar Lück <[EMAIL PROTECTED]> wrote: > The scenarios we have in mind are setups in which a set of collaborating > servers steadly establish connections among each other with a very high rate. > This high rate requirement drove us to consider the inclusion of all > alternative routes into the routing cache because the corresponding delay > for each connection establishment is low and the load is balanced over all > available routes. That's why we did not consider a slow lookup in the fib > for each connection established. So essentially you want per-flow multipathing. Except that you're implementation is over-optimizing it to the point where it's only per-flow for your specific case where the connections are short lived and high rate. This hurts long lasting connections. So I'm pretty much against this change. Do it right by making it occur per-connection attempt, it's not my problem to figure out how to do that efficiently, it's your's :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/RFT] [patch] Elo serial touchscreen driver
On Wed, 2005-02-09 18:08:10 +, Paulo Marques <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > >>Additionally, there are two other things that need to be addressed (and > >>I'm willing to actually write code for this, but need input from other > >>parties, too:) > >> > >>- Touchscreen calibration > >>Basically all these touchscreens are capable of being > >>calibrated. It's not done with just pushing the X/Y > >>values the kernel receives into the Input API. These > >>beasts may get physically mis-calibrated and eg. report > >>things like (xmax - xmin) <= 20, so resolution would be > >>really bad and kernel reported min/max values were only > >>"theoretical" values, based on the protocol specs. > >>I think about a simple X11 program for this. Comments? > > Touch screens doing this are severely brain-damaged. And yes, I've come > across a few of them, but not lately. That's IMHO not brain-damaged, but pure physics: just consider scratches or dust (or other substances) applied to the touch foil. This happens all the time, so the touch screen gets out of calibration. This won't happen on a screen used only twice a day. But think about a touch screen that's tortured all the day with pencils, finger rings, dirty fingers, ... > I would say that a tool to recover the touch screen into a "usable" > state, by talking directly to the serial port, and "calibrating" it to > max possible / min possible values would be the best way to deal with this. Min/Max values (as of protocol theory) is possibly not the very best you can do with the hardware. I more thing about submitting these (after physical calibration) to the kernel driver to supply them to it's users. > Modern touchscreens just send the A/D data to the PC, and let the real > processor do the math (it can even do more complex calculations, like > compensate for rotation, etc.). IMHO calibration should be handled by > software. Is this done eg. by Elo, Mutouch, Fujitsu, T-Sharc (to only name the most common)? I don't think so... > >>- POS keyboards > >>These are real beasties. Next to LEDs and keycaps, they > >>can contain barcode scanners, magnetic card readers and > >>displays. Right now, there's no good API to pass > >>something as complex as "three-track magnetic stripe > >>data" or a whole scanned EAN barcode. Also, some > >>keyboards can be written to (change display contents, > >>switch on/off scanners, ...). > > > > > >We probably don't want magnetic stripe data to go through the input > >event stream (although it is possible to do that), so a new interface > >would be most likely necessary. > > It's even worse. Most keyboards don't separate the real keys from > magnetic stripe reader events, and just simulate key presses for MSR > data. They expect the software to be in a state where it is waiting for > that data, and will process it accordingly. This only happens if you don't configurethe MSR properly :-) Most of them can be configured to send quite complex (as in: structured) init sequences that cannot be generated by a keyboard (ie multiple break codes without make codes and the like). MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier BÃrger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
High Interrupt load crashes SMP Athlon MPs
Hello, After doing much research I have come to the conclusion that the kernel might be at fault (in conjuction with the mobo) for hard-locking my box. Please read below to see if you can help me. I am coming to wits end with this MSI K7D Master-L board. I have narrowed it down to find that anything that causes alot of interrupts will lock the box. By lock I mean a HARD lock, no ping, no mouse, no oops, no sysrq, no nothing. It is a sudden and TOTAL lockup. A ping -f and playing xmms at the same time will cause the box to lock in minutes while as if there is very little activity I can run for perhaps an hour or so maybe more (havent had the time or the patience to baby-sit an idle box for more than an hour. This is my main box.) When I ran this box as a single-cpu system with an athlon mp2400 it ran fine. Perhaps something with SMP is triggering a nasty bug. The motherboard was bought to replace another motherboard and so I could go SMP. The ram, powersupply,ALL cards, basically all the hardware are known good and have been used for months in another system. The LCD here is the mobo. I have googled extensivly and have tried many things to see if I can alleviate the problem, so far nothing. Does anyone have any ideas to see if this is a kernel problem? Is this a known problem? Is there a patch to fix this? I am trying to avoid replacing/returning such a beautiful and expensive motherboard. Here is excerpt from a Redhat mailing list >If your motherboard's using the AMD-768 chipset for the Southbridge, you >may have run afoul of a bug in interrupt masking which can hang the >system. The reports thus far on the linux kernel list imply that plugging >in a PS/2 mouse seems to work around the problem; it's worked for me (MSI >K7D Master board with dual Athlons), though I've only had a few days' >trial so far. So it seems to suggest something in the kernel has something in part to do with the lockup. Anyone have any suggestions? Any info I can provide? Here is a non-exhaustive unordered list of various things I've tried. -Combonations of noapic nolapic acpi=off -Increasing the vcore slightly -Downloading and compiling the latest kernel (see uname -a output) -Recompiled the kernel, ran make clean -turning DMA off in the bios -turning DMS off via hdparm -running without a PATA drive at all (all scsi) -Removing ALL unneccesary cards -Removing ALL unnecesary devices (to recude power consumption) -Disabling USB and removing USB support from the kernel -Installing sensors and making sure voltages/temps are nominal (they are) -installed and used irqbalance -Disable preempt -Try the onboard lan and a 64bit pci gigabit lan card mutually exclusively -Removed side-panel and verified heat is not an issue -Updated to latest BIOS version ---hardware and kernel specs-- [EMAIL PROTECTED] bot403 $ su Password: [EMAIL PROTECTED] >uname -a Linux eric 2.6.10-gentoo-r6 #2 SMP Tue Feb 8 17:12:59 CST 2005 i686 AMD Athlon(tm) MP 2600+ AuthenticAMD GNU/Linux [EMAIL PROTECTED] >lspci -v :00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System Controller (rev 11) Flags: bus master, 66Mhz, medium devsel, latency 32 Memory at e800 (32-bit, prefetchable) Memory at fd005000 (32-bit, prefetchable) [size=4K] I/O ports at ec00 [disabled] [size=4] Capabilities: [a0] AGP version 2.0 :00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 32 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 Memory behind bridge: f800-f9ff Prefetchable memory behind bridge: f000-f7ff :00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 05) Flags: bus master, 66Mhz, medium devsel, latency 0 :00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 04) (prog-if 8a [Master SecP PriP]) Subsystem: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE Flags: bus master, medium devsel, latency 32 I/O ports at e000 [size=16] :00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI (rev 03) Subsystem: Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI Flags: medium devsel :00:09.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI Adapter (rev 01) Subsystem: LSI Logic / Symbios Logic: Unknown device 1030 Flags: bus master, medium devsel, latency 72, IRQ 153 I/O ports at e400 Memory at fd006000 (64-bit, non-prefetchable) [size=1K] Memory at fd002000 (64-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 :00:09.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI Adapter (rev 01) Subsystem: LSI Logic / Symbios Logic: Unknown device 1030
Re: [RFC/RFT] [patch] Elo serial touchscreen driver
Vojtech Pavlik wrote: On Wed, Feb 09, 2005 at 06:08:10PM +, Paulo Marques wrote: [...] Touchscreens are one class of devices where the serial attachment is not dying. Very true. [...] We could parse a definition "string", like this: "SIZE:10,SYNC:0:8:85,SYNC:8:8:54,X:24:8:1,X:32:8:256,Y:40:8:1,Y:48:8:256,T:16:2:1" This string defines the touch driver for elotouch, 10 bytes packet (I didn't include the pressure reading, for simplification). I currently have 6 different "drivers" that would all fit into this model. The same goes for all 3 elotouch protocols that you implemented. Does this sound like a good idea? I don't think so. I don't think the saving of code is worth the obfuscation, after all, 6 drivers is still not so much. Also, direct code implementation can implement better synchronization methods and faster resynchronization in case of lost bytes. Agreed. A touch screen driver is pretty small already. The only advantage would actually be to support new touchscreens without actually changing the kernel, but if we write the code for the touchscreens we already know, we will probably not see that many "new" touchscreens with weird protocols. And then there are protocols like the Gunze one, which wouldn't be covered by this. Actually the string for the gunze touchscreen would be something like (constructed from interpreting the gunze.c source code): "SIZE:11, SYNC:0:5:80,SYNC:40:8:44,SYNC:80:8:13, X:12:4:1000,X:20:4:100,X:28:4:10,X:36:4:1, Y:52:4:3000,Y:60:4:300,Y:68:4:30,Y:76:4:3, T:2:1:1" Yes, it doesn't look good ;) And I agree that we would probably not be able to cover _all_ touchscreens. [...] We could have a library that would do that and link applications against it. It could also handle things like tap-n-drag, etc, something we certainly don't want in the kernel. I really like this idea :) A libtouch library that handled calibration (this includes mirroring and swapping the coordinates) and other goodies (like filtering out short "touch release" events while dragging, etc.) would be a good standard interface for all applications. Being in user space would also mean that the library could do things like keeping a /etc/touch.conf file where it would read default calibration data, etc. [...] I would say that a tool to recover the touch screen into a "usable" state, by talking directly to the serial port, and "calibrating" it to max possible / min possible values would be the best way to deal with this. I agree with that. It could possibly even be put into the inputattach init routine for the specific touchscreen. This certainly seems like a good place for it, yes. Modern touchscreens just send the A/D data to the PC, and let the real processor do the math (it can even do more complex calculations, like compensate for rotation, etc.). IMHO calibration should be handled by software. And this is something the kernel certainly won't do. Floating point math is possible in the kernel with some jumping through hoops, but avoiding it is usually the better option. We don't necessarily need floating point (even with 32 bits we have plenty of space for fixed point arithmetic), but I agree that this would be better handled in a library. -- 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/
latest version of /proc fs documentation
Hi, i tried for the latest versionof the /proc fs document supposed to be available online at http://skaro.nightcrawler.com/~bb/Docs/Proc but couldn't get it. can i get some help in this regard ? thanks. -pranay = Pranay Pramod Army Institute of Technology Dighi Hills Pune-15 __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] kernel/fork.c: VM accounting bugfix (2.6.11-rc3-bk5)
On Wed, 9 Feb 2005, Chris Wright wrote: > * Hugh Dickins ([EMAIL PROTECTED]) wrote: > > dup_mmap's charge starts out at 0 and gets added to each time around > > the loop through vmas; if security_vm_enough_memory fails at any point > > in that loop, we need to vm_unacct_memory the charge already accumulated. > > If that's the requirement, then it's broken as is, because there is > nothing accumulating. len is re-determined each pass, and charge is > reset each pass. You're right, it's me who's wrong, sorry. I was remembering how it was before 2.6.7, when Oleg pointed out that it was doubly unaccounting (and it's probably me who was guilty of that double unaccounting too). > But I think that it's ok, as we only care about the > last pass. If dup_mmap() fails part way through, the cleanup path should > call unaccount for the (potentially) accounted by not fully setup vma then > call exit_mmap() and clear all the vmas that got accounted for already. Yes, that was Oleg's point when he fixed it. > Either way, Mark's patch is not needed, and I don't think anything needs > patching in this area. Hugh, do you agree? Yes I agree - thanks for clearing that up, Chris. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Preempt Real-time for ARM
On Wed, Feb 09, 2005 at 09:41:10AM -0800, Daniel Walker wrote: > All I want to do is integrate the common IRQ threading code. To do that > I need things , from Russell, like per descriptor locks .. And I need > things , from Ingo, like pulling out the IRQ threading code.. I've said why per-IRQ locks are incorrect for the non-RT cases on ARM, but unfortunately just repeating the reasons why it's wrong isn't getting me anywhere either. So shrug, all I can to is explain why it's wrong, and if people choose not to listen there's nothing more I can do. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/fork.c: VM accounting bugfix (2.6.11-rc3-bk5)
* Hugh Dickins ([EMAIL PROTECTED]) wrote: > dup_mmap's charge starts out at 0 and gets added to each time around > the loop through vmas; if security_vm_enough_memory fails at any point > in that loop, we need to vm_unacct_memory the charge already accumulated. If that's the requirement, then it's broken as is, because there is nothing accumulating. len is re-determined each pass, and charge is reset each pass. But I think that it's ok, as we only care about the last pass. If dup_mmap() fails part way through, the cleanup path should call unaccount for the (potentially) accounted by not fully setup vma then call exit_mmap() and clear all the vmas that got accounted for already. Either way, Mark's patch is not needed, and I don't think anything needs patching in this area. Hugh, do you agree? thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/RFT] [patch] Elo serial touchscreen driver
On Wed, Feb 09, 2005 at 06:08:10PM +, Paulo Marques wrote: > >>>I want serious support for ALL touchscreens in Linux. > > I'm glad to hear it. I was just pointing out the "serial" part, because, > unlike USB and other interfaces, a serial port can not say "what" is > attached to it, so we need the "inputattach" method to explain to the > kernel what is there (and the irattach, pppd, etc.). Touchscreens are one class of devices where the serial attachment is not dying. > >>Maybe I'd write drivers for the T-Sharc and fujitsu controllers, too. > >>These are in a lot of POS hardware, too, and sometimes they're a pain to > >>use (esp. calibration). > > > >Well, if you write them, send them my way. :) > > I sometimes feel that we should have a "generic" touch screen driver > from looking at the code for the different brands. > > Almost all touch screen data goes something like this: > > - every packet is fixed size, N bytes long > > - the "header" bytes can be described by AND == > something expected > > - the X,Y,pressure,touch data can be described as "starting at bit B, > length N, multiply by Z". An array of these tokens should be able to > handle coordinates broken into several. > > If this information could be passed as a module parameter, new > touchscreens could be supported without any kernel modification. > > We could parse a definition "string", like this: > > "SIZE:10,SYNC:0:8:85,SYNC:8:8:54,X:24:8:1,X:32:8:256,Y:40:8:1,Y:48:8:256,T:16:2:1" > > This string defines the touch driver for elotouch, 10 bytes packet (I > didn't include the pressure reading, for simplification). > > I currently have 6 different "drivers" that would all fit into this > model. The same goes for all 3 elotouch protocols that you implemented. > > Does this sound like a good idea? I don't think so. I don't think the saving of code is worth the obfuscation, after all, 6 drivers is still not so much. Also, direct code implementation can implement better synchronization methods and faster resynchronization in case of lost bytes. And then there are protocols like the Gunze one, which wouldn't be covered by this. > >>>I don't believe the mirroring/flipping is kernel's job, since it tries > >>>to always pass the data with the least amount of transformation applied > >>>to achieve hardware abstraction. > > This is one argument that I don't quite understand. Doesn't hardware > abstraction mean that the application should receive the "same" data > regardless of the hardware. > > I would say that the kernel would do a good job in abstracting hardware, > if it always returned X,Y coordinates from [0..65535] (or something like > that) in always the same direction, regardless of the actual hardware > involved... I can understand that, however, when the only difference is in the actual _mounting_ of the hardware ... I'm not so sure. > >>ACK. Should be handled by XFree86's driver. > > Unfortunately, I don't use any X driver (The application runs over the > framebuffer), and I don't think it is a good idea to force people to use it. We could have a library that would do that and link applications against it. It could also handle things like tap-n-drag, etc, something we certainly don't want in the kernel. > >>Additionally, there are two other things that need to be addressed (and > >>I'm willing to actually write code for this, but need input from other > >>parties, too:) > >> > >>- Touchscreen calibration > >>Basically all these touchscreens are capable of being > >>calibrated. It's not done with just pushing the X/Y > >>values the kernel receives into the Input API. These > >>beasts may get physically mis-calibrated and eg. report > >>things like (xmax - xmin) <= 20, so resolution would be > >>really bad and kernel reported min/max values were only > >>"theoretical" values, based on the protocol specs. > >>I think about a simple X11 program for this. Comments? > > Touch screens doing this are severely brain-damaged. And yes, I've come > across a few of them, but not lately. > > I would say that a tool to recover the touch screen into a "usable" > state, by talking directly to the serial port, and "calibrating" it to > max possible / min possible values would be the best way to deal with this. I agree with that. It could possibly even be put into the inputattach init routine for the specific touchscreen. > Modern touchscreens just send the A/D data to the PC, and let the real > processor do the math (it can even do more complex calculations, like > compensate for rotation, etc.). IMHO calibration should be handled by > software. And this is something the kernel certainly won't do. Floating point math is possible in the kernel with some jumping through hoops, but avoiding it is usually the better option. > >We probably don't want magnetic stripe data to go through the input > >event
Re: [patch, BK] clean up and unify asm-*/resource.h files
* Ingo Molnar ([EMAIL PROTECTED]) wrote: > > * Chris Wright <[EMAIL PROTECTED]> wrote: > > > * Ingo Molnar ([EMAIL PROTECTED]) wrote: > > > this patch does the final consolidation of asm-*/resource.h file, > > > without changing any of the rlimit definitions on any architecture. > > > Primarily it removes the __ARCH_RLIMIT_ORDER method and replaces it with > > > a more compact and isolated one that allows architectures to define only > > > the offending rlimits. > > > > Heh, I did it this way first, then worried people might find it > > confusing to only have a subset of the block overwritten I backed it > > down to the __ARCH_RLIMIT_ORDER method. Anyway, I like this change. > > > > Acked-by: Chris Wright <[EMAIL PROTECTED]> > > the original reason i ended up doing this was when i introduced a new > rlimit and it needed changes in 5 include files. Now the new rlimit is > off the agenda but the cleanup remained :-) Hehehe, that's the same reason I did the last one ;-) cheers, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
