2.6.13-rc3 udev/hotplug use memory after free
2.6.13-rc3 + kdb (which does not touch udev/hotplug) on IA64 (Altix). gcc version 3.3.3 (SuSE Linux). Compiled with DEBUG_SLAB, DEBUG_PREEMPT, DEBUG_SPINLOCK, DEBUG_SPINLOCK_SLEEP, DEBUG_KOBJECT. There is a use after free somewhere above class_device_attr_show. <7>fill_kobj_path: path = '/class/vc/vcs13' <7>kobject_hotplug: /sbin/hotplug vc seq=1377 HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=remove DEVPATH=/class/vc/vcs13 SUBSYSTEM=vc <7>kobject vcs13: cleaning up <7>kobject_hotplug <7>fill_kobj_path: path = '/class/vc/vcsa13' <1>Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b6b <4>udev[13708]: Oops 8813272891392 [1] <7>kobject_hotplug: /sbin/hotplug vc seq=1378 HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=remove DEVPATH=/class/vc/vcsa13 SUBSYSTEM=vc <4>Modules linked in: md5 ipv6 usbcore raid0 md_mod nls_iso8859_1 nls_cp437 dm_mod sg st osst <4> <4>Pid: 13708, CPU 0, comm: udev <4>psr : 101008126038 ifs : 8308 ip : [] Not tainted <4>ip is at class_device_attr_show+0x50/0xa0 The offending code is [0]kdb> id class_device_attr_show 0xa001004c8e80 class_device_attr_show[MII] alloc r36=ar.pfs,8,6,0 0xa001004c8e86 class_device_attr_show+0x6mov r8=r0;; 0xa001004c8e8c class_device_attr_show+0xcadds r2=24,r33 0xa001004c8e90 class_device_attr_show+0x10[MMI] mov r37=r1 0xa001004c8e96 class_device_attr_show+0x16mov r39=r34 0xa001004c8e9c class_device_attr_show+0x1cadds r38=-16,r32 0xa001004c8ea0 class_device_attr_show+0x20[MII] nop.m 0x0 0xa001004c8ea6 class_device_attr_show+0x26mov r35=b0;; 0xa001004c8eac class_device_attr_show+0x2cmov.i ar.pfs=r36 0xa001004c8eb0 class_device_attr_show+0x30[MII] ld8 r33=[r2] 0xa001004c8eb6 class_device_attr_show+0x36mov b0=r35;; 0xa001004c8ebc class_device_attr_show+0x3ccmp.eq p8,p9=0,r33 0xa001004c8ec0 class_device_attr_show+0x40[MBB] nop.m 0x0 0xa001004c8ec6 class_device_attr_show+0x46 (p09) br.cond.dpnt.few 0xa001004c8ed0 class_device_attr_show+0x50 0xa001004c8ecc class_device_attr_show+0x4cbr.ret.sptk.many b0 0xa001004c8ed0 class_device_attr_show+0x50[MMI] ld8 r8=[r33],8;; 0xa001004c8ed6 class_device_attr_show+0x56ld8 r1=[r33],-8 0xa001004c8edc class_device_attr_show+0x5cmov b7=r8 At the oops, r33 has been loaded from [r2], r33 contains 0x6b6b6b6b6b6b6b6b. IOW, use after free. [0]kdb> r psr: 0x101008126038 ifs: 0x8308ip: 0xa001004c8ed0 unat: 0x pfs: 0x0711 rsc: 0x0003 rnat: 0xe0b47a429e78 bsps: 0xe0b00bf5d320pr: 0x00155659 ldrs: 0x ccv: 0x fpsr: 0x0009804c0270033f b0: 0xa001001fc830b6: 0xa001f4e0b7: 0xa001004c8e80 r1: 0xa00100d31900r2: 0xe03473de5080r3: 0xe03008f78da4 r8: 0xr9: 0xa00100b4b818 r10: 0xe0b07727 r11: 0x02c1dc9c r12: 0xe03008f7fe20 r13: 0xe03008f78000 r14: 0xa001004c8e80 r15: 0xe0b07727 r16: 0x6db6db6db6db6db7 r17: 0x9a684220 r18: 0xa0007fff62138000 r19: 0xe0b003031318 r20: 0xe0b003030080 r21: 0x0001 r22: 0xa00100b4b818 r23: 0xa00100d23100 r24: 0x134d0844 r25: 0x9a684220 r26: 0xa001008732d8 r27: 0xe03004fe8188 r28: 0xe0b003030080 r29: 0xa00100d23120 r30: 0x0004 r31: 0x0100 [0]kdb> r s r32: e034714fbb30 r33: 6b6b6b6b6b6b6b6b r34: e0b07727 r35: a001001fc830 r36: 0711 r37: a00100d31900 r38: e034714fbb20 r39: e0b07727 Dumping where r2 points, the area has been reused by the time that the oops occurred. Again, use after free. [0]kdb> mds 0xe03473de5080-24 0xe03473de5068 2d646c2f62696c2f /lib/ld- 0xe03473de5070 61692d78756e696c linux-ia 0xe03473de5078 322e6f732e3436 64.so.2. 0xe03473de5080 5a5a5a5a5a5a5a5a 0xe03473de5088 5a5a5a5a5a5a5a5a 0xe03473de5090 5a5a5a5a5a5a5a5a 0xe03473de5098 5a5a5a5a5a5a5a5a 0xe03473de50a0 a55a5a5a5a5a5a5a ZZZ. ps. Handy things, kernel debuggers ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 22/82] remove linux/version.h from drivers/message/fus ion
On Tuesday, July 19, 2005 9:12 PM, Matt Domsch wrote: What you illustrated above is not going to work. If your doing #ifndef around a function, such as scsi_device_online, it's not going to compile when scsi_device_online is already implemented in the kernel tree. The routine scsi_device_online is a function, not a define. For a define this would work. Sure it does, function names are defined symbols. No its not compiling for me. I'm currently building drivers for the DELL DKMS kit. Trying to add support for SLES9 SP2 support ( -191 kernel). My driver compiles for SLES9 Base(-97) and SP2(-139) but fails for SP2. Between SP1 and SP2, they added msleep. Here is the make.log output that you will find in /var/lib/dkms/mptlinux/3.02.52/build when it fails to compile. Also attached is linux_compat.h with the changes you have suggested. linux_compat.h Description: Binary data make.log Description: Binary data
Re: Interbench real time benchmark results
On Wed, 2005-07-20 at 08:16 +1000, Con Kolivas wrote: > As a data point I went back to a 2.6.10 kernel which predates some > latency fixes that went into mainline. > I think most of the important ones had already gone in by then. It would be more interesting to compare it with 2.6.8. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (2/9)
On Tue, Jul 19, 2005 at 11:48:43PM +0200, Jean Delvare wrote:
> Convert i2c-isa from a dumb i2c_adapter into a pseudo i2c-core for ISA
> hardware monitoring drivers. The isa i2c_adapter is no more registered
> with i2c-core, drivers have to explicitely connect to it using the new
> i2c_isa_{add,del}_driver interface.
Ick, when I did this originally it was a hack, and it's still a hack.
It's sad to see it spreading around, but that's proably my fault...
Anyway, what are your plans for after this? How long will this code
stay around? What do you want to do next?
I don't have any real objections to this patch series at all, just very
curious as to your proposed roadmap after this.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (1/9)
On Tue, Jul 19, 2005 at 11:45:40PM +0200, Jean Delvare wrote: > +/* Next four are needed by i2c-isa */ > +EXPORT_SYMBOL(i2c_adapter_dev_release); > +EXPORT_SYMBOL(i2c_adapter_driver); > +EXPORT_SYMBOL(i2c_adapter_class); > +EXPORT_SYMBOL(i2c_bus_type); EXPORT_SYMBOL_GPL() instead? As these were, core, GPL only symbols before you exported them. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13rc3: crypto horribly broken on all 64bit archs
On Sun, Jul 17, 2005 at 02:20:21PM +0200, Andreas Steinmetz wrote:
> from include/linux/kernel.h:
>
> #define ALIGN(x,a) (((x)+(a)-1)&~((a)-1))
>
> from crypto/cipher.c:
>
> unsigned int alignmask = ...
> u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
The type foolery you suggested is un-obvious, especially at review time.
How about the following instead?
-andy
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID ff4d8285dcb581b8340b133c22780c4fcc0dabb3
# Parent 2b0b2208676a22741fc3b1681ca9dd555ca40dfd
Add new PTR_ALIGN macro to encapsulate necessary casting, and use it in
the places where ALIGN was used on pointers.
Signed-Off-By: Andy Isaacson <[EMAIL PROTECTED]>
diff -r 2b0b2208676a -r ff4d8285dcb5 crypto/cipher.c
--- a/crypto/cipher.c Sun Jul 17 03:06:51 2005
+++ b/crypto/cipher.c Tue Jul 19 18:51:11 2005
@@ -43,7 +43,7 @@
{
unsigned int alignmask = crypto_tfm_alg_alignmask(desc->tfm);
u8 buffer[bsize * 2 + alignmask];
- u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
+ u8 *src = PTR_ALIGN(buffer, alignmask + 1);
u8 *dst = src + bsize;
unsigned int n;
@@ -166,7 +166,7 @@
if (unlikely(((unsigned long)iv & alignmask))) {
unsigned int ivsize = tfm->crt_cipher.cit_ivsize;
u8 buffer[ivsize + alignmask];
- u8 *tmp = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
+ u8 *tmp = PTR_ALIGN(buffer, alignmask + 1);
int err;
desc->info = memcpy(tmp, iv, ivsize);
diff -r 2b0b2208676a -r ff4d8285dcb5 drivers/crypto/padlock-aes.c
--- a/drivers/crypto/padlock-aes.c Sun Jul 17 03:06:51 2005
+++ b/drivers/crypto/padlock-aes.c Tue Jul 19 18:51:11 2005
@@ -287,7 +287,7 @@
static inline struct aes_ctx *aes_ctx(void *ctx)
{
- return (struct aes_ctx *)ALIGN((unsigned long)ctx, PADLOCK_ALIGNMENT);
+ return PTR_ALIGN(ctx, PADLOCK_ALIGNMENT);
}
static int
diff -r 2b0b2208676a -r ff4d8285dcb5 include/linux/kernel.h
--- a/include/linux/kernel.hSun Jul 17 03:06:51 2005
+++ b/include/linux/kernel.hTue Jul 19 18:51:11 2005
@@ -29,6 +29,8 @@
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
#define ALIGN(x,a) (((x)+(a)-1)&~((a)-1))
+#define PTR_ALIGN(p,a) \
+ ((void *)(((unsigned long)(p)+(a)-1)&~(((unsigned long)(a)-1
#defineKERN_EMERG "<0>" /* system is unusable
*/
#defineKERN_ALERT "<1>" /* action must be taken immediately
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: amd64 Interbench Results
On Wed, 20 Jul 2005 12:46 pm, Gabriel Devenyi wrote: > I've been using the the -ck patchset for a very long time, and I recently > switched to a amd64 arch. I found that while my throughput improved, my > system responsiveness has "felt" much lower than it did on my old x86 > machine. > > Now that interbench is around, I have some quantitative results. Attached > is my interbench results with *nothing* running other than agetty and a > single bash console. My system is an AMD Athlon(tm) 64 Processor 3200+, > with 1gig DDR400 RAM. Also attached is my kernel config. > > Seems to me there are some pretty high latencies for such a powerful > system, is there anything I can do to improve this? Thanks for all your > help. Those results don't look too bad to me. Absolute numbers don't mean much in their own right unless you compare them to something else. Try a vanilla kernel and then compare the results side by side. Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 22/82] remove linux/version.h from drivers/message/fus ion
On Tue, 19 Jul 2005 22:12:49 -0500 Matt Domsch <[EMAIL PROTECTED]> wrote: > > Sure it does, function names are defined symbols. > > I'm doing exactly this in my backport of the openipmi drivers to RHEL4 > and SLES9. I missed the smiley, right :-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpZdM3iQWHwM.pgp Description: PGP signature
Re: [Linux-cluster] [RFC] nodemanager, ocfs2, dlm
On Tue, Jul 19, 2005 at 05:48:26PM -0700, Mark Fasheh wrote:
> For OCFS2 that would mean that an ocfs2_nodemanager would still exist,
> but as a much smaller module sitting on top of 'nodemanager'.
Yep, factoring out the common bits.
> So no port attribute. The OCFS2 network code normally takes port from the
> node manager in order to determine how to talk to a given node. We'll have
> to figure out how to resolve that. The easiest would be to add 'port' back,
> but I think that might be problematic if we have multiple cluster network
> infrastructures as we do today.
The port is specific to the component using it (ocfs2, dlm, etc), so
defining port as a node property doesn't make sense if nodemanager is
providing node info to multiple components.
> Another way to handle this would be to have userspace symlink to the node
> items as an attribute on an ocfs2_tcp item. We could store 'port' as a
> second attribute. This would have the added benefit of pinning node
> information while OCFS2 uses it.
I expect each component will probably use another per-node configfs object
for component-specific attributes, using the common bits from the
nodemanager object.
> > + charnd_name[NODEMANAGER_MAX_NAME_LEN+1];
> An accessor function for this would be nice for pretty prints - maybe strcpy
> into a passed string.
ok
> > + int nd_nodeid;
> This definitely won't work with OCFS2... Nodeid (what used to be called
> node_num) needs to be unsigned. Otherwise this will break all our nodemap
> stuff which uses a bitmap to represent cluster state.
ok
> > + struct list_headnd_status_list;
> What are these two for? They don't seem to be referenced elsewhere...
Missed ripping them out with the other ocfs-specific stuff.
> > + if (!tmp && cluster->cl_has_local &&
> > + cluster->cl_local_node == node->nd_nodeid) {
> > + cluster->cl_local_node = 0;
> I think we might want to be setting cl_local_node to NODEMANAGER_MAX_NODES
> here. It seems that ocfs2_nodemanager also does this so we might have just
> caught a bug you inherited :)
yep
> You removed o2nm_configured_node_map but we need some sort of method for
> enumerating over the set of configured nodes.
>
> Also we need a method for querying the existence of a node.
> The OCFS2 code usually uses o2nm_get_node_by_num(..) != NULL for this but a
> simple boolean api call would be cleaner and would avoid exposing the node
> structure.
Right, those should be on the TODO.
Thanks,
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel guide to space
On Jul 13, 2005, at 21:12:08, [EMAIL PROTECTED] wrote: I don't think there's a strict 80 column rule anymore. It's 2005... Think again. There are a lot of people who use 80 column windows so that we can see two code windows side-by-side. Agreed. If you're having trouble with width, it's a sign that the code needs to be refactored. Also, my personal rule is if that a source file exceeds 1000 lines, start looking for a way to split it. It can go longer (indeed, there is little reason to split the fs/nls/nls_cp9??.c files), but (I will refrain from discussing drivers/scsi/advansys.c) A simple set of code refactoring rules that I try to abide by: 1) If a function is more than a few 25 or 40 line screens, it's likely too big (unless a big switch statement or a list of initialization calls or something). If necessary, use static inline functions to factor out repetitive behavior. 2) If a file is more than 30-40 functions, it's likely too big, and you should try to split it. It's _ok_ to have 4 source files implementing code for manipulating a single struct. 3) If a normal line of code is more than 80 characters, one of the following is probably true: you need to break the line up and use temps for clarity, or your function is so big that you're tabbing over too far. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+ ++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Synaptics and TrackPoint problems in 2.6.12
Dimitry, I have been receiving a lot of complaints that TrackPoints on Synaptics pass-thru ports stopped working with 2.6.12. I retested 2.6.9 and 2.6.11-rc3 successfully, I believe 2.6.11.7 may also work but that is unconfirmed at this point. The behavior is always the same .. after sending the read secondary ID command, the TrackPoint seems to be disabled from that point forward. Any ideas? -- Stephen Evanchik http://stephen.evanchik.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: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
On Tue, Jul 19, 2005 at 05:52:14PM +0200, Lars Marowsky-Bree wrote: > The nodeid, I thought, was relative to a given DLM namespace, no? This > concept seems to be missing here, or are you suggesting the nodeid to be > global across namespaces? I'm not sure I understand what you mean. A node would have the same nodeid across different dlm locking-domains, assuming, of course, those dlm domains were in the context of the same cluster. The dlm only uses nodemanager to look up node addresses, though. > Also, eventually we obviously need to have state for the nodes - up/down > et cetera. I think the node manager also ought to track this. We don't have a need for that information yet; I'm hoping we won't ever need it in the kernel, but we'll see. > How would kernel components use this and be notified about changes to > the configuration / membership state? "Nodemanager" is perhaps a poor name; at the moment its only substantial purpose is to communicate node address/id associations in a way that's independent of a specific driver or fs. Changes to cluster configuration/membership happen in user space, of course. Those general events will have specific consequences to a given component (fs, lock manager, etc). These consequences vary quite widely depending on the component you're looking at. There are at least two ways to handle this: 1. Pass cluster events and data into the kernel (this sounds like what you're talking about above), notify the effected kernel components, each kernel component takes the cluster data and does whatever it needs to with it (internal adjustments, recovery, etc). 2. Each kernel component "foo-kernel" has an associated user space component "foo-user". Cluster events (from userland clustering infrastructure) are passed to foo-user -- not into the kernel. foo-user determines what the specific consequences are for foo-kernel. foo-user then manipulates foo-kernel accordingly, through user/kernel hooks (sysfs, configfs, etc). These control hooks would largely be specific to foo. We're following option 2 with the dlm and gfs and have been for quite a while, which means we don't need 1. I think ocfs2 is moving that way, too. Someone could still try 1, of course, but it would be of no use or interest to me. I'm not aware of any actual projects pushing forward with something like 1, so the persistent reference to it is somewhat baffling. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clarify KALLSYMS_ALL help text
Clarify the KALLSYMS_ALL help text slightly. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- init/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) --- linux-2.6.13-rc3-mm1-orig/init/Kconfig 2005-07-17 04:40:00.0 +0200 +++ linux-2.6.13-rc3-mm1/init/Kconfig 2005-07-20 05:39:20.0 +0200 @@ -366,8 +366,8 @@ help Normally kallsyms only contains the symbols of functions, for nicer OOPS messages. Some debuggers can use kallsyms for other - symbols too: say Y here to include all symbols, and you - don't care about adding 300k to the size of your kernel. + symbols too: say Y here to include all symbols, if you need them + and you don't care about adding 300k to the size of your kernel. Say N. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 22/82] remove linux/version.h from drivers/message/fus ion
On Tue, Jul 19, 2005 at 06:07:41PM -0600, Moore, Eric Dean wrote:
> On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
> > In general, this construct:
> >
> > > > -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> > > > -static int inline scsi_device_online(struct scsi_device *sdev)
> > > > -{
> > > > - return sdev->online;
> > > > -}
> > > > -#endif
> >
> > is better tested as:
> >
> > #ifndef scsi_device_inline
> > static int inline scsi_device_online(struct scsi_device *sdev)
> > {
> > return sdev->online;
> > }
> > #endif
> >
> > when you can. It cleanly eliminates the version test, and tests for
> > exactly what you're looking for - is this function defined.
> >
>
> What you illustrated above is not going to work.
> If your doing #ifndef around a function, such as scsi_device_online, it's
> not going to compile
> when scsi_device_online is already implemented in the kernel tree.
> The routine scsi_device_online is a function, not a define. For a define
> this would work.
Sure it does, function names are defined symbols.
I'm doing exactly this in my backport of the openipmi drivers to RHEL4
and SLES9.
> I'm trying your example around msleep, msleep_interruptible, and
> msecs_to_jiffies, and
> my code simply won't compile in SLES9 SP2(-191). In SLES9 SP1(-139), these
> three routines were not implemented and
> your suggestion works. I won't be able to to a linux version check as this
> change occurred between service packs
> of the 2.6.5 kernel suse tree. Anybody on the linux forums have any ideas?
>
> Example:
>
> #ifdef msleep
#ifndef you mean.
> static void inline msleep(unsigned long msecs)
> {
> set_current_state(TASK_UNINTERRUPTIBLE);
> schedule_timeout(msecs_to_jiffies(msecs) + 1);
> }
> #endif
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] QLogic SCSI driver Kconfig fixes
The problem in a nutshell is that the tristate `config SCSI_QLA2XXX' does not have a name and thus does not show up in menuconfig and similar. This coupled with the fact that it defaults to `y' when config PCI and config SCSI is selected results in people (like me) who need PCI and SCSI support but have no need of the QLogic drivers end up with the following warnings at build time (and a superfluous kernel .ko file), since there's no way to disable SCSI_QLA2XXX : Building modules, stage 2. MODPOST *** Warning: "request_firmware" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined! *** Warning: "release_firmware" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined! In addition to that, SCSI_QLA2XXX has no help text entry. Below I've included 3 patches to fix the problem in various ways (yes, I know there should only be one patch pr email normally, but it seemed silly to send 3 emails with 3 different suggested patches for the same problem). The third patch is my personal favorite, but I present all 3 to let you choose which one you like best. This patch just adds a name to the option so people can at least deselect it if they don't need it, and it adds a help text. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/scsi/qla2xxx/Kconfig |6 +- 1 files changed, 5 insertions(+), 1 deletion(-) --- linux-2.6.13-rc3-mm1-orig/drivers/scsi/qla2xxx/Kconfig 2005-07-17 04:39:52.0 +0200 +++ linux-2.6.13-rc3-mm1/drivers/scsi/qla2xxx/Kconfig 2005-07-20 04:59:47.0 +0200 @@ -1,8 +1,12 @@ config SCSI_QLA2XXX - tristate + tristate "QLogic ISP2XXX SCSI host adapter family support" default (SCSI && PCI) depends on SCSI && PCI select SCSI_FC_ATTRS + ---help--- + Support the QLogic 2XXX (ISP2XXX) family of host bus adapters. + In addition to this option you should select the specific HBAs + you want to support from the submenu items. config SCSI_QLA21XX tristate "QLogic ISP2100 host adapter family support" This patch adds a name to the option so it can be deselected if not needed, adds a help entry and also adds the selection of config FW_LOADER if this option is selected, so it'll build without problems for people who select it without them having to go hunt for config FW_LOADER themselves. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/scsi/qla2xxx/Kconfig |7 ++- 1 files changed, 6 insertions(+), 1 deletion(-) --- linux-2.6.13-rc3-mm1-orig/drivers/scsi/qla2xxx/Kconfig 2005-07-17 04:39:52.0 +0200 +++ linux-2.6.13-rc3-mm1/drivers/scsi/qla2xxx/Kconfig 2005-07-20 05:00:57.0 +0200 @@ -1,8 +1,13 @@ config SCSI_QLA2XXX - tristate + tristate "QLogic ISP2XXX SCSI host adapter family support" default (SCSI && PCI) depends on SCSI && PCI select SCSI_FC_ATTRS + select FW_LOADER + ---help--- + Support the QLogic 2XXX (ISP2XXX) family of host bus adapters. + In addition to this option you should select the specific HBAs + you want to support from the submenu items. config SCSI_QLA21XX tristate "QLogic ISP2100 host adapter family support" This patch adds a name to the option so it can be deselected if not needed, it also adds a help text and selection of config FW_LOADER if this option is selected, so it'll build without problems for people who select it without them having to go hunt for config FW_LOADER themselves, and finally it makes the option default to `n' since I don't see a point in having any specific SCSI drivers be default enabled - surely people who actually need the option can select it by themselves (especially now that it'll cause the automatic selection of FW_LOADER). Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/scsi/qla2xxx/Kconfig |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) --- linux-2.6.13-rc3-mm1-orig/drivers/scsi/qla2xxx/Kconfig 2005-07-17 04:39:52.0 +0200 +++ linux-2.6.13-rc3-mm1/drivers/scsi/qla2xxx/Kconfig 2005-07-20 05:02:50.0 +0200 @@ -1,8 +1,13 @@ config SCSI_QLA2XXX - tristate - default (SCSI && PCI) + tristate "QLogic ISP2XXX SCSI host adapter family support" + default n depends on SCSI && PCI select SCSI_FC_ATTRS + select FW_LOADER + ---help--- + Support the QLogic 2XXX (ISP2XXX) family of host bus adapters. + In addition to this option you should select the specific HBAs + you want to support from the submenu items. config SCSI_QLA21XX tristate "QLogic ISP2100 host adapter family support" Feel free to pick the patch you believe fix the problem best. :-) Kind regards, Jesper Juhl <[EMAIL PROTECTED]> PS. Please keep me on CC if you do not reply directly to me or to linux-kernel, since I'm not subscribed to linux-scsi. - To unsubscribe from this list: send the line "unsubscribe linux-kernel"
amd64 Interbench Results
I've been using the the -ck patchset for a very long time, and I recently switched to a amd64 arch. I found that while my throughput improved, my system responsiveness has "felt" much lower than it did on my old x86 machine. Now that interbench is around, I have some quantitative results. Attached is my interbench results with *nothing* running other than agetty and a single bash console. My system is an AMD Athlon(tm) 64 Processor 3200+, with 1gig DDR400 RAM. Also attached is my kernel config. Seems to me there are some pretty high latencies for such a powerful system, is there anything I can do to improve this? Thanks for all your help. -- Gabriel Devenyi [EMAIL PROTECTED] Using 1047120 loops per ms, running every load for 30 seconds Benchmarking kernel 2.6.12-ck3-r1 at datestamp 200507192216 --- Benchmarking Audio in the presence of loads --- Latency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0 +/- 0 0 100 95.3 Video 0.003 +/- 0.0227 0.246 100 95.3 X Using 1047120 loops per ms, running every load for 30 seconds Benchmarking kernel 2.6.12-ck3-r1 at datestamp 200507192218 --- Benchmarking Audio in the presence of loads --- Latency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0 +/- 0 0 100 95.3 Video 0.089 +/- 0.172 0.796 100 95.3 X 1.88 +/- 2.81 9.7 100 95.3 Burn 0.199 +/- 1.1 9.2 100 95.3 Write 0.021 +/- 0.2684.9 100 95.3 Read 0 +/- 0 0 100 95.3 Compile 0.378 +/- 1.06 100 100 94.8 Memload 0.354 +/- 0.359200 100 94.8 --- Benchmarking Video in the presence of loads --- Latency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0.001 +/- 0.001330.003 100 95.3 X 4.02 +/- 3.5122.6 100 86.2 Burn 0.206 +/- 0.813 16.7 100 94.8 Write 0.058 +/- 0.534 16.7 100 95.2 Read 0.009 +/- 0.0854 1.43 100 95.3 Compile 0.281 +/- 1.2 16.7 100 94.8 Memload 0.086 +/- 0.29 50 100 95 --- Benchmarking X in the presence of loads --- Latency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met None 0.013 +/- 0.013 2 100 94.3 Video 11.8 +/- 11.8 66 100 60.7 Burn 0.013 +/- 0.013 2 100 94.3 Write 0.024 +/- 0.024 2 100 93.7 Read 0.013 +/- 0.013 2 100 94.3 Compile 0.013 +/- 0.013 2 100 94 Memload 0.029 +/- 0.0968 3 100 94.7 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-ck3-r1 # Tue Jul 19 20:47:45 2005 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set # # Processor type and features # CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_HPET_TIMER=y CONFIG_X86_PM_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_GART_IOMMU is not set CONFIG_DUMMY_IOMMU=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set # CONFIG_SECCOMP is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y
Re: [PATCH] Convert refrigerator() to try_to_freeze()
Hi.
On Tue, 2005-07-19 at 23:54, Pavel Machek wrote:
> Hi!
>
> > This patch removes the few remaining direct invocations of the
> > refrigerator in 2.6.13-rc3. In drivers/media/video/msp3400.c, it also
> > shifts the call to after the remove_wait_queue; this seems to be the
> > more appropriate place.
>
>
> > diff -ruNp 230-refrigerator-to-try_to_freeze.patch-old/fs/jbd/journal.c
> > 230-refrigerator-to-try_to_freeze.patch-new/fs/jbd/journal.c
> > --- 230-refrigerator-to-try_to_freeze.patch-old/fs/jbd/journal.c
> > 2005-07-18 06:36:59.0 +1000
> > +++ 230-refrigerator-to-try_to_freeze.patch-new/fs/jbd/journal.c
> > 2005-07-18 13:54:47.0 +1000
> > @@ -175,7 +175,7 @@ loop:
> > */
> > jbd_debug(1, "Now suspending kjournald\n");
> > spin_unlock(>j_state_lock);
> > - refrigerator();
> > + try_to_freeze();
> > spin_lock(>j_state_lock);
> > } else {
> > /*
>
> They probably tested it before, why test again?
>
> > diff -ruNp 230-refrigerator-to-try_to_freeze.patch-old/fs/jfs/jfs_logmgr.c
> > 230-refrigerator-to-try_to_freeze.patch-new/fs/jfs/jfs_logmgr.c
> > --- 230-refrigerator-to-try_to_freeze.patch-old/fs/jfs/jfs_logmgr.c
> > 2005-07-18 06:36:59.0 +1000
> > +++ 230-refrigerator-to-try_to_freeze.patch-new/fs/jfs/jfs_logmgr.c
> > 2005-07-18 13:54:47.0 +1000
> > @@ -2361,7 +2361,7 @@ int jfsIOWait(void *arg)
> > }
> > if (freezing(current)) {
>
> > spin_unlock_irq(_redrive_lock);
> > - refrigerator();
> > + try_to_freeze();
> > } else {
> > add_wait_queue(_IO_thread_wait, );
> > set_current_state(TASK_INTERRUPTIBLE);
>
> See? You are needlessly testing condition twice.
True. I was just concerned that things are messy and inconsistent as
they stand (sometimes we use try_to_freeze and implicitly call
refrigerator(), sometimes we call freezing() and refrigerator). *shrug*
Regards,
Nigel
--
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Interbench real time benchmark results
On Wed, 20 Jul 2005 11:31 am, Jesper Juhl wrote: > On 7/20/05, Daniel Walker <[EMAIL PROTECTED]> wrote: > > On Wed, 2005-07-20 at 11:04 +1000, Con Kolivas wrote: > > > On Wed, 20 Jul 2005 10:23 am, Daniel Walker wrote: > > > > On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote: > > > > > - networking is another frequent source of latencies - it might > > > > > make sense to add a workload doing lots of socket IO. (localhost > > > > > might be enough, but not for everything) > > > > > > > > The Gnutella test? > > > > > > I've seen some massive latencies on mainline when throwing network > > > loads from outside, but with my limited knowledge I haven't found a way > > > to implement such a thing locally. I'll look at this gnutella test at > > > some stage to see what it is and if I can adopt the load within > > > interbench. Thanks for the suggestion. > > > > There isn't actually a test called "The Gnutella test" , but I think > > Gnutella clients put lots of network load on a system (Lee was talking > > about that not to long ago). I was thinking that type of load may have > > been what Ingo was talking about. > > If you want to generate a lot of network related interrupts, wouldn't > a much simpler way to do that be a simple > > ping -f targetbox > > from a host connected to `targetbox' via a crosswired ethernet cable > or a fast switch..? > > Also easy to modify the size of the ping packets if you want to. Well that load works very well, but once again it isn't really something that can be done locally on one box running init 1. Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interbench real time benchmark results
On 7/20/05, Daniel Walker <[EMAIL PROTECTED]> wrote: > On Wed, 2005-07-20 at 11:04 +1000, Con Kolivas wrote: > > On Wed, 20 Jul 2005 10:23 am, Daniel Walker wrote: > > > On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote: > > > > - networking is another frequent source of latencies - it might make > > > >sense to add a workload doing lots of socket IO. (localhost might be > > > >enough, but not for everything) > > > > > > The Gnutella test? > > > > I've seen some massive latencies on mainline when throwing network loads > > from > > outside, but with my limited knowledge I haven't found a way to implement > > such a thing locally. I'll look at this gnutella test at some stage to see > > what it is and if I can adopt the load within interbench. Thanks for the > > suggestion. > > There isn't actually a test called "The Gnutella test" , but I think > Gnutella clients put lots of network load on a system (Lee was talking > about that not to long ago). I was thinking that type of load may have > been what Ingo was talking about. > If you want to generate a lot of network related interrupts, wouldn't a much simpler way to do that be a simple ping -f targetbox from a host connected to `targetbox' via a crosswired ethernet cable or a fast switch..? Also easy to modify the size of the ping packets if you want to. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interbench real time benchmark results
On Wed, 2005-07-20 at 11:04 +1000, Con Kolivas wrote: > On Wed, 20 Jul 2005 10:23 am, Daniel Walker wrote: > > On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote: > > > - networking is another frequent source of latencies - it might make > > >sense to add a workload doing lots of socket IO. (localhost might be > > >enough, but not for everything) > > > > The Gnutella test? > > I've seen some massive latencies on mainline when throwing network loads from > outside, but with my limited knowledge I haven't found a way to implement > such a thing locally. I'll look at this gnutella test at some stage to see > what it is and if I can adopt the load within interbench. Thanks for the > suggestion. There isn't actually a test called "The Gnutella test" , but I think Gnutella clients put lots of network load on a system (Lee was talking about that not to long ago). I was thinking that type of load may have been what Ingo was talking about. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interbench real time benchmark results
On Wed, 20 Jul 2005 10:23 am, Daniel Walker wrote: > On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote: > > - networking is another frequent source of latencies - it might make > >sense to add a workload doing lots of socket IO. (localhost might be > >enough, but not for everything) > > The Gnutella test? I've seen some massive latencies on mainline when throwing network loads from outside, but with my limited knowledge I haven't found a way to implement such a thing locally. I'll look at this gnutella test at some stage to see what it is and if I can adopt the load within interbench. Thanks for the suggestion. Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] [RFC] nodemanager, ocfs2, dlm
Hi David,
On Mon, Jul 18, 2005 at 02:15:53PM +0800, David Teigland wrote:
> Some of the comments about the dlm concerned how it's configured (from
> user space.) In particular, there was interest in seeing the dlm and
> ocfs2 use common methods for their configuration.
>
> The first area I'm looking at is how we get addresses/ids of other nodes.
Right. So this doesn't take into account other parts of node management
(communication, heartbeat, etc). OCFS2 and dlm would still be handling that
stuff on their own for now. For OCFS2 that would mean that an
ocfs2_nodemanager would still exist, but as a much smaller module sitting on
top of 'nodemanager'.
> I've taken a stab at generalizing ocfs2_nodemanager so the dlm could use
> it (removing ocfs-specific stuff). It still needs some work, but I'd like
> to know if this appeals to the ocfs group and to others who were
> interested in seeing some similarity in dlm/ocfs configuration.
While I agree that some things look like they still need a bit of work, I
like the direction this is taking - thanks for getting this ball rolling. My
questions and comments below:
> +enum {
> + NM_NODE_ATTR_NODEID = 0,
> + NM_NODE_ATTR_ADDRESS,
> + NM_NODE_ATTR_LOCAL,
> +};
So no port attribute. The OCFS2 network code normally takes port from the
node manager in order to determine how to talk to a given node. We'll have
to figure out how to resolve that. The easiest would be to add 'port' back,
but I think that might be problematic if we have multiple cluster network
infrastructures as we do today.
Another way to handle this would be to have userspace symlink to the node
items as an attribute on an ocfs2_tcp item. We could store 'port' as a
second attribute. This would have the added benefit of pinning node
information while OCFS2 uses it.
> +struct node {
> + spinlock_t nd_lock;
> + struct config_item nd_item;
> + charnd_name[NODEMANAGER_MAX_NAME_LEN+1];
An accessor function for this would be nice for pretty prints - maybe strcpy
into a passed string.
> + int nd_nodeid;
This definitely won't work with OCFS2... Nodeid (what used to be called
node_num) needs to be unsigned. Otherwise this will break all our nodemap
stuff which uses a bitmap to represent cluster state.
> + u32 nd_ipv4_address;
> + struct rb_node nd_ip_node;
> + int nd_local;
> + unsigned long nd_set_attributes;
> + struct idr nd_status_idr;
> + struct list_headnd_status_list;
What are these two for? They don't seem to be referenced elsewhere...
> +static ssize_t node_local_write(struct node *node, const char *page,
> + size_t count)
> +{
> + struct cluster *cluster = node_to_cluster(node);
> + unsigned long tmp;
> + char *p = (char *)page;
> +
> + tmp = simple_strtoul(p, , 0);
> + if (!p || (*p && (*p != '\n')))
> + return -EINVAL;
> +
> + tmp = !!tmp; /* boolean of whether this node wants to be local */
> +
> + /* the only failure case is trying to set a new local node
> + * when a different one is already set */
> +
> + if (tmp && tmp == cluster->cl_has_local &&
> + cluster->cl_local_node != node->nd_nodeid)
> + return -EBUSY;
> +
> + if (!tmp && cluster->cl_has_local &&
> + cluster->cl_local_node == node->nd_nodeid) {
> + cluster->cl_local_node = 0;
I think we might want to be setting cl_local_node to NODEMANAGER_MAX_NODES
here. It seems that ocfs2_nodemanager also does this so we might have just
caught a bug you inherited :)
> diff -urN a/drivers/nodemanager/nodemanager.h
> b/drivers/nodemanager/nodemanager.h
> --- a/drivers/nodemanager/nodemanager.h 1970-01-01 07:30:00.0
> +0730
> +++ b/drivers/nodemanager/nodemanager.h 2005-07-18 13:41:35.377583200
> +0800
> @@ -0,0 +1,37 @@
> +/*
> + * nodemanager.h
> + *
> + * Copyright (C) 2004 Oracle. All rights reserved.
> + * Copyright (C) 2005 Red Hat, Inc. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 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 021110-1307, USA.
> + *
> + */
> +
> +#ifndef NODEMANAGER_H
> +#define NODEMANAGER_H
> +
> +#define
Re: how to be (SAFE) a kernel developer ?
On 7/19/05, Brian O'Mahoney <[EMAIL PROTECTED]> wrote: > > To: unlisted-recipients:; (no To-header on input) ^^^ That's a bad habbit - makes it impossible to send a proper reply back to all the recipients. LKML is a public list, please use To: and CC: so it's possible to reply to the proper people, and don't trim the CC: list please. > Jesper Juhl wrote: ... > > much useful advice, almost all of which I agree with _BUT_ > > please do NOT debug kernel mods on your 'main-box', where your > filesystems live. unless you like to live dangerously and make > perfect backups you don't mind spending lots of hours restoring, > You are right. A sacrificial box or at least proper backups of any important stuff is important. I didn't write that since I figured it to be obvious, but I guess I should have spelled it out anyway. Thank you for making that bit clear :-) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interbench real time benchmark results
On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote: > > - networking is another frequent source of latencies - it might make >sense to add a workload doing lots of socket IO. (localhost might be >enough, but not for everything) The Gnutella test? Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interbench real time benchmark results
On Wed, 2005-07-20 at 08:16 +1000, Con Kolivas wrote: > Interestingly the average latencies are slightly higher (in the miniscule > <2us > range), but the maximum latencies are excellently bound to 25us. > > The results are quite reproducible. I would guess that the average latencies are tunable .. In this case if any of the benchmarks are dependent on specific interrupts , or ksoftirqd, you can tune the priority of the associate IRQ threads , or ksoftirqd, to get similar averages to 2.6.12 .. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 22/82] remove linux/version.h from drivers/message/fus ion
On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
> In general, this construct:
>
> > > -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> > > -static int inline scsi_device_online(struct scsi_device *sdev)
> > > -{
> > > - return sdev->online;
> > > -}
> > > -#endif
>
> is better tested as:
>
> #ifndef scsi_device_inline
> static int inline scsi_device_online(struct scsi_device *sdev)
> {
> return sdev->online;
> }
> #endif
>
> when you can. It cleanly eliminates the version test, and tests for
> exactly what you're looking for - is this function defined.
>
What you illustrated above is not going to work.
If your doing #ifndef around a function, such as scsi_device_online, it's
not going to compile
when scsi_device_online is already implemented in the kernel tree.
The routine scsi_device_online is a function, not a define. For a define
this would work.
I'm trying your example around msleep, msleep_interruptible, and
msecs_to_jiffies, and
my code simply won't compile in SLES9 SP2(-191). In SLES9 SP1(-139), these
three routines were not implemented and
your suggestion works. I won't be able to to a linux version check as this
change occurred between service packs
of the 2.6.5 kernel suse tree. Anybody on the linux forums have any ideas?
Example:
#ifdef msleep
static void inline msleep(unsigned long msecs)
{
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(msecs_to_jiffies(msecs) + 1);
}
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: how to be (SAFE) a kernel developer ?
On 7/19/05, Brian O'Mahoney <[EMAIL PROTECTED]> wrote: > > sacrifical system, and, for example NFS mount everything, on > it from your main box, otherwise use a cheap local disk just > for your fs stuff > > then when you blow it there is no FS damage and you don't need > to wait for FSCK, or Journal Replay, when your fs works you > can live more dangerously ;-) > Or try qemu/bochs for your laptop, Xen for your desktop and z/VM for your mainframe ;) Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Am Dienstag, 19. Juli 2005 17:19 schrieb Gene Heskett: > On Tuesday 19 July 2005 09:57, Ingo Molnar wrote: > >* Karsten Wiese <[EMAIL PROTECTED]> wrote: > >> > Found another error: > >> > the ioapic cache isn't fully initialized in -51-31's > >> > ioapic_cache_init(). > >> > >> and another: some NULL-pointers are used in -51-31 instead of > >> ioapic_data[0]. Please apply attached patch on top of -51-31. It > >> includes yesterday's fix. > > > >thanks, i've applied it and released -32. > > And this fixed ntpd (in mode 4) right up. But now Im seeing some > fussing from Xprint when its started, from my logs: > > Jul 19 10:59:58 coyote rc: Starting xprint: succeeded > Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 > Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 > Jul 19 10:59:59 coyote Xprt_33: lpstat: Unable to connect to server: > Connection refused > Jul 19 10:59:59 coyote Xprt_33: No matching visual for __GLcontextMode with > visual class = 0 (32775), nplanes = > 8 > Jul 19 11:00:00 coyote kernel: set_rtc_mmss: can't update from 7 to 59 > > The font path stuff I snipped has been there since forever. > And, I didn't get the set_rtc_mmss messages when I did a service xprint > restart. > And then it "xprinted" right away just fine? > Is this even connected to Xprint, that looks like something from maybe ntp? > "set_rtc_mmss: can't update from 7 to 59" is printk()ed from here: linux-2.6.12-RT/include/asm-i386/mach-default/mach_time.h /* * In order to set the CMOS clock precisely, set_rtc_mmss has to be * called 500 ms after the second nowtime has started, because when * nowtime is written into the registers of the CMOS clock, it will * jump to the next second precisely 500 ms later. Check the Motorola * MC146818A or Dallas DS12887 data sheet for details. * * BUG: This routine does not handle hour overflow properly; it just * sets the minutes. Usually you'll only notice that after reboot! */ static inline int mach_set_rtc_mmss(unsigned long nowtime) so its a rtc timingrelated. which PREEMPT_RT / mode 4 was the last one to do it on the fly ? > And of course in mode 4, tvtime has a blue screen. But you knew that. :) > what is tvtime supposed to do, is it a wine thing as in "bleu screen"? Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (9/9)
Move the definitions of i2c_is_isa_client and i2c_is_isa_adapter from i2c.h to i2c-isa.h. Only hybrid drivers still need them. include/linux/i2c-isa.h |7 +++ include/linux/i2c.h |7 --- 2 files changed, 7 insertions(+), 7 deletions(-) --- linux-2.6.13-rc3.orig/include/linux/i2c-isa.h 2005-07-16 18:46:37.0 +0200 +++ linux-2.6.13-rc3/include/linux/i2c-isa.h2005-07-17 16:45:22.0 +0200 @@ -26,4 +26,11 @@ extern int i2c_isa_add_driver(struct i2c_driver *driver); extern int i2c_isa_del_driver(struct i2c_driver *driver); +/* Detect whether we are on the isa bus. This is only useful to hybrid + (i2c+isa) drivers. */ +#define i2c_is_isa_client(clientptr) \ +((clientptr)->adapter->algo->id == I2C_ALGO_ISA) +#define i2c_is_isa_adapter(adapptr) \ +((adapptr)->algo->id == I2C_ALGO_ISA) + #endif /* _LINUX_I2C_ISA_H */ --- linux-2.6.13-rc3.orig/include/linux/i2c.h 2005-07-17 15:26:30.0 +0200 +++ linux-2.6.13-rc3/include/linux/i2c.h2005-07-17 16:44:40.0 +0200 @@ -575,11 +575,4 @@ .force =force, \ } -/* Detect whether we are on the isa bus. If this returns true, all i2c - access will fail! */ -#define i2c_is_isa_client(clientptr) \ -((clientptr)->adapter->algo->id == I2C_ALGO_ISA) -#define i2c_is_isa_adapter(adapptr) \ -((adapptr)->algo->id == I2C_ALGO_ISA) - #endif /* _LINUX_I2C_H */ -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: page allocation/attributes question (i386/x86_64 specific)
there's one problem with the patch: it breaks things that need the low 1MB executable (e.g. APM bios32 calls). It would at a minimum be needed to exclude the BIOS area in 0xd-0xf. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (8/9)
Kill all uses of i2c_is_isa_adapter except for the hybrid drivers (it87,
lm78, w83781d). The i2c-isa adapter not being registered with the i2c
core anymore, drivers don't have to fear being erroneously attached to
it.
Documentation/i2c/writing-clients | 11 +--
drivers/hwmon/adm1021.c |9 -
drivers/hwmon/asb100.c|8
drivers/hwmon/lm75.c | 10 --
drivers/hwmon/lm85.c |5 -
5 files changed, 5 insertions(+), 38 deletions(-)
--- linux-2.6.13-rc3.orig/Documentation/i2c/writing-clients 2005-07-17
15:20:30.0 +0200
+++ linux-2.6.13-rc3/Documentation/i2c/writing-clients 2005-07-17
15:45:47.0 +0200
@@ -315,11 +315,10 @@
const char *type_name = "";
int is_isa = i2c_is_isa_adapter(adapter);
-if (is_isa) {
+/* Do this only if the chip can additionally be found on the ISA bus
+ (hybrid chip). */
- /* If this client can't be on the ISA bus at all, we can stop now
- (call `goto ERROR0'). But for kicks, we will assume it is all
- right. */
+if (is_isa) {
/* Discard immediately if this ISA range is already used */
if (check_region(address,FOO_EXTENT))
@@ -495,10 +494,10 @@
return err;
}
-/* SENSORS ONLY START */
+/* HYBRID SENSORS CHIP ONLY START */
if i2c_is_isa_client(client)
release_region(client->addr,LM78_EXTENT);
-/* SENSORS ONLY END */
+/* HYBRID SENSORS CHIP ONLY END */
kfree(client); /* Frees client data too, if allocated at the same time */
return 0;
--- linux-2.6.13-rc3.orig/drivers/hwmon/adm1021.c 2005-07-17
15:13:16.0 +0200
+++ linux-2.6.13-rc3/drivers/hwmon/adm1021.c2005-07-17 16:06:34.0
+0200
@@ -198,15 +198,6 @@
int err = 0;
const char *type_name = "";
- /* Make sure we aren't probing the ISA bus!! This is just a safety check
- at this moment; i2c_detect really won't call us. */
-#ifdef DEBUG
- if (i2c_is_isa_adapter(adapter)) {
- dev_dbg(>dev, "adm1021_detect called for an ISA bus
adapter?!?\n");
- return 0;
- }
-#endif
-
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA))
goto error0;
--- linux-2.6.13-rc3.orig/drivers/hwmon/asb100.c2005-07-17
15:12:52.0 +0200
+++ linux-2.6.13-rc3/drivers/hwmon/asb100.c 2005-07-17 16:06:23.0
+0200
@@ -714,14 +714,6 @@
struct i2c_client *new_client;
struct asb100_data *data;
- /* asb100 is SMBus only */
- if (i2c_is_isa_adapter(adapter)) {
- pr_debug("asb100.o: detect failed, "
- "cannot attach to legacy adapter!\n");
- err = -ENODEV;
- goto ERROR0;
- }
-
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
pr_debug("asb100.o: detect failed, "
"smbus byte data not supported!\n");
--- linux-2.6.13-rc3.orig/drivers/hwmon/lm75.c 2005-07-17 15:11:52.0
+0200
+++ linux-2.6.13-rc3/drivers/hwmon/lm75.c 2005-07-17 16:05:51.0
+0200
@@ -121,16 +121,6 @@
int err = 0;
const char *name = "";
- /* Make sure we aren't probing the ISA bus!! This is just a safety check
- at this moment; i2c_detect really won't call us. */
-#ifdef DEBUG
- if (i2c_is_isa_adapter(adapter)) {
- dev_dbg(>dev,
- "lm75_detect called for an ISA bus adapter?!?\n");
- goto exit;
- }
-#endif
-
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA |
I2C_FUNC_SMBUS_WORD_DATA))
goto exit;
--- linux-2.6.13-rc3.orig/drivers/hwmon/lm85.c 2005-07-17 15:11:12.0
+0200
+++ linux-2.6.13-rc3/drivers/hwmon/lm85.c 2005-07-17 16:05:43.0
+0200
@@ -1033,11 +1033,6 @@
int err = 0;
const char *type_name = "";
- if (i2c_is_isa_adapter(adapter)) {
- /* This chip has no ISA interface */
- goto ERROR0 ;
- };
-
if (!i2c_check_functionality(adapter,
I2C_FUNC_SMBUS_BYTE_DATA)) {
/* We need to be able to do byte I/O */
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (7/9)
Kill normal_isa in header files, documentation and all chip drivers, as it is no more used. normal_i2c could be renamed to normal, but I decided not to do so at the moment, so as to limit the number of changes. This might be done later as part of the i2c_probe/i2c_detect merge. Documentation/i2c/porting-clients |7 --- Documentation/i2c/writing-clients | 35 +++ drivers/hwmon/adm1021.c |1 - drivers/hwmon/adm1025.c |1 - drivers/hwmon/adm1026.c |1 - drivers/hwmon/adm1031.c |1 - drivers/hwmon/adm9240.c |2 -- drivers/hwmon/asb100.c|3 --- drivers/hwmon/atxp1.c |1 - drivers/hwmon/ds1621.c|1 - drivers/hwmon/fscher.c|1 - drivers/hwmon/fscpos.c|1 - drivers/hwmon/gl518sm.c |1 - drivers/hwmon/gl520sm.c |1 - drivers/hwmon/it87.c |1 - drivers/hwmon/lm63.c |1 - drivers/hwmon/lm75.c |1 - drivers/hwmon/lm77.c |1 - drivers/hwmon/lm78.c |1 - drivers/hwmon/lm80.c |1 - drivers/hwmon/lm83.c |1 - drivers/hwmon/lm85.c |1 - drivers/hwmon/lm87.c |1 - drivers/hwmon/lm90.c |1 - drivers/hwmon/lm92.c |1 - drivers/hwmon/max1619.c |1 - drivers/hwmon/w83781d.c |1 - drivers/hwmon/w83l785ts.c |1 - drivers/i2c/chips/ds1337.c|1 - drivers/i2c/chips/eeprom.c|1 - drivers/i2c/chips/max6875.c |1 - drivers/i2c/chips/pca9539.c |1 - drivers/i2c/chips/pcf8574.c |1 - drivers/i2c/chips/pcf8591.c |1 - include/linux/i2c-sensor.h| 36 +++- include/linux/i2c.h |8 ++-- 36 files changed, 36 insertions(+), 85 deletions(-) --- linux-2.6.13-rc3.orig/Documentation/i2c/writing-clients 2005-07-13 23:34:03.0 +0200 +++ linux-2.6.13-rc3/Documentation/i2c/writing-clients 2005-07-17 16:40:39.0 +0200 @@ -195,31 +195,28 @@ - If you write a `sensors' driver, you use a slightly different interface. -As well as I2C addresses, we have to cope with ISA addresses. Also, we -use a enum of chip types. Don't forget to include `sensors.h'. +Also, we use a enum of chip types. Don't forget to include `sensors.h'. The following lists are used internally. They are all lists of integers. - normal_i2c: filled in by the module writer. Terminated by SENSORS_I2C_END. + normal_i2c: filled in by the module writer. Terminated by I2C_CLIENT_END. A list of I2C addresses which should normally be examined. - normal_isa: filled in by the module writer. Terminated by SENSORS_ISA_END. - A list of ISA addresses which should normally be examined. - probe: insmod parameter. Initialize this list with SENSORS_I2C_END values. - A list of pairs. The first value is a bus number (SENSORS_ISA_BUS for - the ISA bus, -1 for any I2C bus), the second is the address. These - addresses are also probed, as if they were in the 'normal' list. - ignore: insmod parameter. Initialize this list with SENSORS_I2C_END values. - A list of pairs. The first value is a bus number (SENSORS_ISA_BUS for - the ISA bus, -1 for any I2C bus), the second is the I2C address. These - addresses are never probed. This parameter overrules 'normal' and - 'probe', but not the 'force' lists. + probe: insmod parameter. Initialize this list with I2C_CLIENT_END values. + A list of pairs. The first value is a bus number (ANY_I2C_BUS for any + I2C bus), the second is the address. These addresses are also probed, + as if they were in the 'normal' list. + ignore: insmod parameter. Initialize this list with I2C_CLIENT_END values. + A list of pairs. The first value is a bus number (ANY_I2C_BUS for any + I2C bus), the second is the I2C address. These addresses are never + probed. This parameter overrules 'normal' and 'probe', but not the + 'force' lists. Also used is a list of pointers to sensors_force_data structures: force_data: insmod parameters. A list, ending with an element of which the force field is NULL. Each element contains the type of chip and a list of pairs. - The first value is a bus number (SENSORS_ISA_BUS for the ISA bus, - -1 for any I2C bus), the second is the address. + The first value is a bus number (ANY_I2C_BUS for any I2C bus), the + second is the address. These are automatically translated to insmod variables of the form force_foo. @@ -227,13 +224,11 @@ `force_CHIPNAME'. Fortunately, as a module writer, you just have to define the `normal_i2c' -and `normal_isa' parameters, and define what chip names are used. -The complete declaration
[PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (6/9)
Kill all isa-related stuff from i2c_detect, it's not used anymore.
This is one major step in the directiom of merging i2c_probe and
i2c_detect. The last obstacle I can think of is the different way forced
addresses work between sensors and non-sensors i2c drivers. I'll deal
with that in a later patchset.
drivers/i2c/i2c-sensor-detect.c | 45 +++-
1 files changed, 13 insertions(+), 32 deletions(-)
--- linux-2.6.13-rc3.orig/drivers/i2c/i2c-sensor-detect.c 2005-06-18
09:32:15.0 +0200
+++ linux-2.6.13-rc3/drivers/i2c/i2c-sensor-detect.c2005-07-17
14:27:26.0 +0200
@@ -25,42 +25,34 @@
#include
static unsigned short empty[] = {I2C_CLIENT_END};
-static unsigned int empty_isa[] = {I2C_CLIENT_ISA_END};
-/* Very inefficient for ISA detects, and won't work for 10-bit addresses! */
+/* Won't work for 10-bit addresses! */
int i2c_detect(struct i2c_adapter *adapter,
struct i2c_address_data *address_data,
int (*found_proc) (struct i2c_adapter *, int, int))
{
int addr, i, found, j, err;
struct i2c_force_data *this_force;
- int is_isa = i2c_is_isa_adapter(adapter);
- int adapter_id =
- is_isa ? ANY_I2C_ISA_BUS : i2c_adapter_id(adapter);
+ int adapter_id = i2c_adapter_id(adapter);
unsigned short *normal_i2c;
- unsigned int *normal_isa;
unsigned short *probe;
unsigned short *ignore;
/* Forget it if we can't probe using SMBUS_QUICK */
- if ((!is_isa) &&
- !i2c_check_functionality(adapter, I2C_FUNC_SMBUS_QUICK))
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_QUICK))
return -1;
/* Use default "empty" list if the adapter doesn't specify any */
normal_i2c = probe = ignore = empty;
- normal_isa = empty_isa;
if (address_data->normal_i2c)
normal_i2c = address_data->normal_i2c;
- if (address_data->normal_isa)
- normal_isa = address_data->normal_isa;
if (address_data->probe)
probe = address_data->probe;
if (address_data->ignore)
ignore = address_data->ignore;
- for (addr = 0x00; addr <= (is_isa ? 0x : 0x7f); addr++) {
- if (!is_isa && i2c_check_addr(adapter, addr))
+ for (addr = 0x00; addr <= 0x7f; addr++) {
+ if (i2c_check_addr(adapter, addr))
continue;
/* If it is in one of the force entries, we don't do any
@@ -69,7 +61,7 @@
for (i = 0; !found && (this_force = address_data->forces + i,
this_force->force); i++) {
for (j = 0; !found && (this_force->force[j] !=
I2C_CLIENT_END); j += 2) {
if ( ((adapter_id == this_force->force[j]) ||
- ((this_force->force[j] == ANY_I2C_BUS) &&
!is_isa)) &&
+ (this_force->force[j] == ANY_I2C_BUS)) &&
(addr == this_force->force[j + 1]) ) {
dev_dbg(>dev, "found force
parameter for adapter %d, addr %04x\n", adapter_id, addr);
if ((err = found_proc(adapter, addr,
this_force->kind)))
@@ -85,8 +77,7 @@
right now */
for (i = 0; !found && (ignore[i] != I2C_CLIENT_END); i += 2) {
if ( ((adapter_id == ignore[i]) ||
- ((ignore[i] == ANY_I2C_BUS) &&
- !is_isa)) &&
+ (ignore[i] == ANY_I2C_BUS)) &&
(addr == ignore[i + 1])) {
dev_dbg(>dev, "found ignore parameter
for adapter %d, addr %04x\n", adapter_id, addr);
found = 1;
@@ -97,19 +88,10 @@
/* Now, we will do a detection, but only if it is in the normal
or
probe entries */
- if (is_isa) {
- for (i = 0; !found && (normal_isa[i] !=
I2C_CLIENT_ISA_END); i += 1) {
- if (addr == normal_isa[i]) {
- dev_dbg(>dev, "found normal
isa entry for adapter %d, addr %04x\n", adapter_id, addr);
- found = 1;
- }
- }
- } else {
- for (i = 0; !found && (normal_i2c[i] !=
I2C_CLIENT_END); i += 1) {
- if (addr == normal_i2c[i]) {
- found = 1;
- dev_dbg(>dev, "found normal
i2c entry for adapter %d, addr %02x\n", adapter_id, addr);
- }
+ for (i = 0; !found && (normal_i2c[i] != I2C_CLIENT_END); i +=
1) {
+ if (addr ==
[PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (5/9)
Call the ISA chip drivers detection function directly instead of relying
on i2c_detect. The net effect is that address lists won't be handled
anymore, but they were mostly useless in the ISA case anyway (pc87360,
smsc47m1, smsc47b397 had already dropped them).
We don't need to handle multiple devices, all we may need is a way to
force a given address instead of the original one (some drivers already
do: sis5595, via686a, w83627hf), and, for drivers supporting multiple
chips, a way to force one given kind. All this may be added later on
demand, but I actually don't think there will be much demand.
drivers/hwmon/it87.c | 16 ++
drivers/hwmon/lm78.c | 11 --
drivers/hwmon/pc87360.c| 38 --
drivers/hwmon/sis5595.c| 41 -
drivers/hwmon/smsc47b397.c | 48 +++-
drivers/hwmon/smsc47m1.c | 42 --
drivers/hwmon/via686a.c| 41 +++--
drivers/hwmon/w83627ehf.c | 35
drivers/hwmon/w83627hf.c | 49 +++--
drivers/hwmon/w83781d.c| 12 +--
10 files changed, 98 insertions(+), 235 deletions(-)
--- linux-2.6.13-rc3.orig/drivers/hwmon/pc87360.c 2005-07-16
21:26:53.0 +0200
+++ linux-2.6.13-rc3/drivers/hwmon/pc87360.c2005-07-17 12:47:11.0
+0200
@@ -39,25 +39,17 @@
#include
#include
#include
-#include
#include
#include
#include
#include
-static unsigned short normal_i2c[] = { I2C_CLIENT_END };
-static unsigned int normal_isa[] = { 0, I2C_CLIENT_ISA_END };
-static struct i2c_force_data forces[] = {{ NULL }};
static u8 devid;
-static unsigned int extra_isa[3];
+static unsigned short address;
+static unsigned short extra_isa[3];
static u8 confreg[4];
enum chips { any_chip, pc87360, pc87363, pc87364, pc87365, pc87366 };
-static struct i2c_address_data addr_data = {
- .normal_i2c = normal_i2c,
- .normal_isa = normal_isa,
- .forces = forces,
-};
static int init = 1;
module_param(init, int, 0);
@@ -228,8 +220,7 @@
* Functions declaration
*/
-static int pc87360_attach_adapter(struct i2c_adapter *adapter);
-static int pc87360_detect(struct i2c_adapter *adapter, int address, int kind);
+static int pc87360_detect(struct i2c_adapter *adapter);
static int pc87360_detach_client(struct i2c_client *client);
static int pc87360_read_value(struct pc87360_data *data, u8 ldi, u8 bank,
@@ -246,8 +237,7 @@
static struct i2c_driver pc87360_driver = {
.owner = THIS_MODULE,
.name = "pc87360",
- .flags = I2C_DF_NOTIFY,
- .attach_adapter = pc87360_attach_adapter,
+ .attach_adapter = pc87360_detect,
.detach_client = pc87360_detach_client,
};
@@ -636,12 +626,7 @@
* Device detection, registration and update
*/
-static int pc87360_attach_adapter(struct i2c_adapter *adapter)
-{
- return i2c_detect(adapter, _data, pc87360_detect);
-}
-
-static int pc87360_find(int sioaddr, u8 *devid, int *address)
+static int pc87360_find(int sioaddr, u8 *devid, unsigned short *addresses)
{
u16 val;
int i;
@@ -687,7 +672,7 @@
continue;
}
- address[i] = val;
+ addresses[i] = val;
if (i==0) { /* Fans */
confreg[0] = superio_inb(sioaddr, 0xF0);
@@ -731,9 +716,7 @@
return 0;
}
-/* We don't really care about the address.
- Read from extra_isa instead. */
-int pc87360_detect(struct i2c_adapter *adapter, int address, int kind)
+static int pc87360_detect(struct i2c_adapter *adapter)
{
int i;
struct i2c_client *new_client;
@@ -742,9 +725,6 @@
const char *name = "pc87360";
int use_thermistors = 0;
- if (!i2c_is_isa_adapter(adapter))
- return -ENODEV;
-
if (!(data = kmalloc(sizeof(struct pc87360_data), GFP_KERNEL)))
return -ENOMEM;
memset(data, 0x00, sizeof(struct pc87360_data));
@@ -1334,12 +1314,12 @@
/* Arbitrarily pick one of the addresses */
for (i = 0; i < 3; i++) {
if (extra_isa[i] != 0x) {
- normal_isa[0] = extra_isa[i];
+ address = extra_isa[i];
break;
}
}
- if (normal_isa[0] == 0x) {
+ if (address == 0x) {
printk(KERN_WARNING "pc87360: No active logical device, "
"module not inserted.\n");
return -ENODEV;
--- linux-2.6.13-rc3.orig/drivers/hwmon/sis5595.c 2005-07-16
21:26:53.0 +0200
+++ linux-2.6.13-rc3/drivers/hwmon/sis5595.c2005-07-17 10:11:17.0
+0200
@@ -71,14 +71,10 @@
[PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (4/9)
All ISA hardware monitoring drivers (including hybrid drivers) now have a hard dependency on i2c-isa, so they must select I2C_ISA. As a result, CONFIG_I2C_ISA doesn't need to be left visible to the user. The good thing here is that users will stop complaining that some driver doesn't work just because they forgot to compile or load i2c-isa. At this point, all drivers are working again and the cleanup phase can begin. drivers/hwmon/Kconfig |3 +++ drivers/i2c/busses/Kconfig |8 +--- 2 files changed, 4 insertions(+), 7 deletions(-) --- linux-2.6.13-rc3.orig/drivers/hwmon/Kconfig 2005-07-16 09:53:08.0 +0200 +++ linux-2.6.13-rc3/drivers/hwmon/Kconfig 2005-07-16 20:33:50.0 +0200 @@ -160,6 +160,7 @@ tristate "ITE IT87xx and compatibles" depends on HWMON && I2C select I2C_SENSOR + select I2C_ISA help If you say yes here you get support for ITE IT87xx sensor chips and clones: SiS960. @@ -211,6 +212,7 @@ tristate "National Semiconductor LM78 and compatibles" depends on HWMON && I2C && EXPERIMENTAL select I2C_SENSOR + select I2C_ISA help If you say yes here you get support for National Semiconductor LM78, LM78-J and LM79. @@ -366,6 +368,7 @@ tristate "Winbond W83781D, W83782D, W83783S, W83627HF, Asus AS99127F" depends on HWMON && I2C select I2C_SENSOR + select I2C_ISA help If you say yes here you get support for the Winbond W8378x series of sensor chips: the W83781D, W83782D, W83783S and W83627HF, --- linux-2.6.13-rc3.orig/drivers/i2c/busses/Kconfig2005-07-13 23:34:12.0 +0200 +++ linux-2.6.13-rc3/drivers/i2c/busses/Kconfig 2005-07-16 20:34:31.0 +0200 @@ -182,14 +182,8 @@ will be called i2c-iop3xx. config I2C_ISA - tristate "ISA Bus support" + tristate depends on I2C - help - If you say yes to this option, support will be included for i2c - interfaces that are on the ISA bus. - - This driver can also be built as a module. If so, the module - will be called i2c-isa. config I2C_ITE tristate "ITE I2C Adapter" -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] FAT robustness
Etienne Lorrain <[EMAIL PROTECTED]> wrote: > > I'd like to have a discussion about FAT robustness. > > Please give your thought, comments and related issues. > What I would like is to treat completely differently writing to > FAT (writing to a removeable drive) which need a complete "mount", > and just reading quickly a file (a standard use of removeable devices). Sounds like a job for mtools(1). -- 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/
how to be (SAFE) a kernel developer ?
Jesper Juhl wrote: ... much useful advice, almost all of which I agree with _BUT_ please do NOT debug kernel mods on your 'main-box', where your filesystems live. unless you like to live dangerously and make perfect backups you don't mind spending lots of hours restoring, unless you want to specialise in file systems, but maybe do want to work on device drivers use a --- sacrifical system, and, for example NFS mount everything, on it from your main box, otherwise use a cheap local disk just for your fs stuff then when you blow it there is no FS damage and you don't need to wait for FSCK, or Journal Replay, when your fs works you can live more dangerously ;-) You will also need a main system, and serial X-over cable, if you want to use some of the increasing number of tools, kdb, kgdb, kprobes that assume a 2 box setup Finally, Linus personally dislikes debuggers, ... 'read the source Luke' so patches to the mm or mainstream should be grounded an source code analysis, not it works or xxx has 0x1234 in it. -- mit freundlichen Grüßen, Brian. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (3/9)
Convert the 10 ISA hardware monitoring drivers (it87, lm78, pc87360,
sis5595, smsc47b397, smsc47m1, via686a, w83627hf, w83627ehf, w83781d) to
explicitely register with i2c-isa. For hybrid drivers (it87, lm78,
w83781d), we now have two separate instances of i2c_driver, one for the
I2C interface of the chip, and one for ISA interface. In the long run,
the one for ISA will be replaced with a different driver type.
At this point, all drivers are working again, except for missing
dependencies in Kconfig.
drivers/hwmon/it87.c | 29 +
drivers/hwmon/lm78.c | 29 ++---
drivers/hwmon/pc87360.c|5 +++--
drivers/hwmon/sis5595.c|5 +++--
drivers/hwmon/smsc47b397.c |5 +++--
drivers/hwmon/smsc47m1.c |5 +++--
drivers/hwmon/via686a.c|5 +++--
drivers/hwmon/w83627ehf.c |5 +++--
drivers/hwmon/w83627hf.c |5 +++--
drivers/hwmon/w83781d.c| 28 +---
10 files changed, 97 insertions(+), 24 deletions(-)
--- linux-2.6.13-rc3.orig/drivers/hwmon/it87.c 2005-07-16 09:53:09.0
+0200
+++ linux-2.6.13-rc3/drivers/hwmon/it87.c 2005-07-16 20:15:39.0
+0200
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -242,6 +243,14 @@
.detach_client = it87_detach_client,
};
+static struct i2c_driver it87_isa_driver = {
+ .owner = THIS_MODULE,
+ .name = "it87-isa",
+ .attach_adapter = it87_attach_adapter,
+ .detach_client = it87_detach_client,
+};
+
+
static ssize_t show_in(struct device *dev, struct device_attribute *attr,
char *buf)
{
@@ -741,7 +750,7 @@
/* Reserve the ISA region */
if (is_isa)
- if (!request_region(address, IT87_EXTENT, it87_driver.name))
+ if (!request_region(address, IT87_EXTENT, it87_isa_driver.name))
goto ERROR0;
/* Probe whether there is anything available on this address. Already
@@ -787,7 +796,7 @@
i2c_set_clientdata(new_client, data);
new_client->addr = address;
new_client->adapter = adapter;
- new_client->driver = _driver;
+ new_client->driver = is_isa ? _isa_driver : _driver;
new_client->flags = 0;
/* Now, we do the remaining detection. */
@@ -1172,16 +1181,28 @@
static int __init sm_it87_init(void)
{
- int addr;
+ int addr, res;
if (!it87_find()) {
normal_isa[0] = addr;
}
- return i2c_add_driver(_driver);
+
+ res = i2c_add_driver(_driver);
+ if (res)
+ return res;
+
+ res = i2c_isa_add_driver(_isa_driver);
+ if (res) {
+ i2c_del_driver(_driver);
+ return res;
+ }
+
+ return 0;
}
static void __exit sm_it87_exit(void)
{
+ i2c_isa_del_driver(_isa_driver);
i2c_del_driver(_driver);
}
--- linux-2.6.13-rc3.orig/drivers/hwmon/lm78.c 2005-07-16 09:53:09.0
+0200
+++ linux-2.6.13-rc3/drivers/hwmon/lm78.c 2005-07-16 20:17:04.0
+0200
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -177,6 +178,14 @@
.detach_client = lm78_detach_client,
};
+static struct i2c_driver lm78_isa_driver = {
+ .owner = THIS_MODULE,
+ .name = "lm78-isa",
+ .attach_adapter = lm78_attach_adapter,
+ .detach_client = lm78_detach_client,
+};
+
+
/* 7 Voltages */
static ssize_t show_in(struct device *dev, char *buf, int nr)
{
@@ -488,7 +497,8 @@
/* Reserve the ISA region */
if (is_isa)
- if (!request_region(address, LM78_EXTENT, lm78_driver.name)) {
+ if (!request_region(address, LM78_EXTENT,
+ lm78_isa_driver.name)) {
err = -EBUSY;
goto ERROR0;
}
@@ -543,7 +553,7 @@
i2c_set_clientdata(new_client, data);
new_client->addr = address;
new_client->adapter = adapter;
- new_client->driver = _driver;
+ new_client->driver = is_isa ? _isa_driver : _driver;
new_client->flags = 0;
/* Now, we do the remaining detection. */
@@ -791,11 +801,24 @@
static int __init sm_lm78_init(void)
{
- return i2c_add_driver(_driver);
+ int res;
+
+ res = i2c_add_driver(_driver);
+ if (res)
+ return res;
+
+ res = i2c_isa_add_driver(_isa_driver);
+ if (res) {
+ i2c_del_driver(_driver);
+ return res;
+ }
+
+ return 0;
}
static void __exit sm_lm78_exit(void)
{
+ i2c_isa_del_driver(_isa_driver);
i2c_del_driver(_driver);
}
--- linux-2.6.13-rc3.orig/drivers/hwmon/pc87360.c 2005-07-16
09:53:15.0 +0200
+++ linux-2.6.13-rc3/drivers/hwmon/pc87360.c2005-07-16
[PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (2/9)
Convert i2c-isa from a dumb i2c_adapter into a pseudo i2c-core for ISA
hardware monitoring drivers. The isa i2c_adapter is no more registered
with i2c-core, drivers have to explicitely connect to it using the new
i2c_isa_{add,del}_driver interface.
At this point, all ISA chip drivers are useless, because they still
register with i2c-core in the hope i2c-isa is registered there as well,
but it isn't anymore.
The fake bus will be named i2c-9191 in sysfs. This is the number it
already had internally in various places, so it's not exactly new,
except that now the number is seen in userspace as well. This shouldn't
be a problem until someone really has 9192 I2C busses in a given system
;)
The fake bus will no more show in "i2cdetect -l", as it won't be seen by
i2c-dev anymore (not being registered with i2c-core), which is a good
thing, as i2cdetect/i2cdump/i2cset cannot operate on this fake bus
anyway.
drivers/i2c/busses/i2c-isa.c | 158 ---
include/linux/i2c-isa.h | 29 +++
2 files changed, 177 insertions(+), 10 deletions(-)
--- linux-2.6.13-rc3.orig/drivers/i2c/busses/i2c-isa.c 2005-07-13
23:34:12.0 +0200
+++ linux-2.6.13-rc3/drivers/i2c/busses/i2c-isa.c 2005-07-16
21:06:14.0 +0200
@@ -1,6 +1,8 @@
/*
-i2c-isa.c - Part of lm_sensors, Linux kernel modules for hardware
-monitoring
+i2c-isa.c - an i2c-core-like thing for ISA hardware monitoring chips
+Copyright (C) 2005 Jean Delvare <[EMAIL PROTECTED]>
+
+Based on the i2c-isa pseudo-adapter from the lm_sensors project
Copyright (c) 1998, 1999 Frodo Looijaard <[EMAIL PROTECTED]>
This program is free software; you can redistribute it and/or modify
@@ -18,17 +20,24 @@
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-/* This implements an i2c algorithm/adapter for ISA bus. Not that this is
- on first sight very useful; almost no functionality is preserved.
- Except that it makes writing drivers for chips which can be on both
- the SMBus and the ISA bus very much easier. See lm78.c for an example
- of this. */
+/* This implements an i2c-core-like thing for ISA hardware monitoring
+ chips. Such chips are linked to the i2c subsystem for historical
+ reasons (because the early ISA hardware monitoring chips such as the
+ LM78 had both an I2C and an ISA interface). They used to be
+ registered with the main i2c-core, but as a first step in the
+ direction of a clean separation between I2C and ISA chip drivers,
+ we now have this separate core for ISA ones. It is significantly
+ more simple than the real one, of course, because we don't have to
+ handle multiple busses: there is only one (fake) ISA adapter.
+ It is worth noting that we still rely on i2c-core for some things
+ at the moment - but hopefully this won't last. */
#include
#include
#include
#include
#include
+#include
static u32 isa_func(struct i2c_adapter *adapter);
@@ -53,17 +62,146 @@
return 0;
}
+
+/* Copied from i2c-core */
+static ssize_t show_adapter_name(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct i2c_adapter *adap = dev_to_i2c_adapter(dev);
+ return sprintf(buf, "%s\n", adap->name);
+}
+static DEVICE_ATTR(name, S_IRUGO, show_adapter_name, NULL);
+
+static int i2c_isa_device_probe(struct device *dev)
+{
+ return -ENODEV;
+}
+
+static int i2c_isa_device_remove(struct device *dev)
+{
+ return 0;
+}
+
+
+/* We implement an interface which resembles i2c_{add,del}_driver,
+ but for i2c-isa drivers. We don't have to remember and handle lists
+ of drivers and adapters so this is much more simple, of course. */
+
+int i2c_isa_add_driver(struct i2c_driver *driver)
+{
+ int res;
+
+ /* Add the driver to the list of i2c drivers in the driver core */
+ driver->driver.name = driver->name;
+ driver->driver.bus = _bus_type;
+ driver->driver.probe = i2c_isa_device_probe;
+ driver->driver.remove = i2c_isa_device_remove;
+ res = driver_register(>driver);
+ if (res)
+ return res;
+ dev_dbg(_adapter.dev, "Driver %s registered\n", driver->name);
+
+ /* Now look for clients */
+ driver->attach_adapter(_adapter);
+
+ return 0;
+}
+
+int i2c_isa_del_driver(struct i2c_driver *driver)
+{
+ struct list_head *item, *_n;
+ struct i2c_client *client;
+ int res;
+
+ /* Detach all clients belonging to this one driver */
+ list_for_each_safe(item, _n, _adapter.clients) {
+ client = list_entry(item, struct i2c_client, list);
+ if (client->driver != driver)
+ continue;
+ dev_dbg(_adapter.dev, "Detaching client %s at 0x%x\n",
+ client->name, client->addr);
+ if ((res = driver->detach_client(client))) {
+ dev_err(_adapter.dev,
[PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (1/9)
Temporarily export a few structures and functions from i2c-core, because
we will soon need them in i2c-isa.
drivers/i2c/i2c-core.c | 14 ++
include/linux/i2c.h|7 +++
2 files changed, 17 insertions(+), 4 deletions(-)
--- linux-2.6.13-rc3.orig/drivers/i2c/i2c-core.c2005-07-13
23:34:12.0 +0200
+++ linux-2.6.13-rc3/drivers/i2c/i2c-core.c 2005-07-16 18:37:09.0
+0200
@@ -61,7 +61,7 @@
return rc;
}
-static struct bus_type i2c_bus_type = {
+struct bus_type i2c_bus_type = {
.name = "i2c",
.match =i2c_device_match,
.suspend = i2c_bus_suspend,
@@ -78,13 +78,13 @@
return 0;
}
-static void i2c_adapter_dev_release(struct device *dev)
+void i2c_adapter_dev_release(struct device *dev)
{
struct i2c_adapter *adap = dev_to_i2c_adapter(dev);
complete(>dev_released);
}
-static struct device_driver i2c_adapter_driver = {
+struct device_driver i2c_adapter_driver = {
.name = "i2c_adapter",
.bus = _bus_type,
.probe = i2c_device_probe,
@@ -97,7 +97,7 @@
complete(>class_dev_released);
}
-static struct class i2c_adapter_class = {
+struct class i2c_adapter_class = {
.name = "i2c-adapter",
.release = _adapter_class_dev_release,
};
@@ -1171,6 +1171,12 @@
}
+/* Next four are needed by i2c-isa */
+EXPORT_SYMBOL(i2c_adapter_dev_release);
+EXPORT_SYMBOL(i2c_adapter_driver);
+EXPORT_SYMBOL(i2c_adapter_class);
+EXPORT_SYMBOL(i2c_bus_type);
+
EXPORT_SYMBOL(i2c_add_adapter);
EXPORT_SYMBOL(i2c_del_adapter);
EXPORT_SYMBOL(i2c_add_driver);
--- linux-2.6.13-rc3.orig/include/linux/i2c.h 2005-07-13 23:34:37.0
+0200
+++ linux-2.6.13-rc3/include/linux/i2c.h2005-07-16 18:34:02.0
+0200
@@ -34,6 +34,13 @@
#include /* for struct device */
#include
+/* --- For i2c-isa */
+
+extern void i2c_adapter_dev_release(struct device *dev);
+extern struct device_driver i2c_adapter_driver;
+extern struct class i2c_adapter_class;
+extern struct bus_type i2c_bus_type;
+
/* --- General options
*/
struct i2c_msg;
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (0/9)
Hi all, This is a set of patches for review and comments. The aim is to start separating a number of hardware monitoring drivers from the i2c subsystem. Hardware monitoring (or sensors) have a long history of being registered with the i2c subsystem even when they are not I2C (nor SMBus) devices. This adds artificial dependencies between various kernel drivers, is reponsible for some weird code, and prevents us from cleaning up some code in the i2c subsystem. For all these reasons, I would like to separate non-I2C hardware monitoring drivers from the i2c core. This will be a multistep process, as we need to keep all the drivers working and to preserve user-space compatibility (most notably with libsensors) while cleaning up the various parts which need be. This patchset constitutes the first big step, and is made up of 9 patches, to be applied in order. Individual patches follow, each with comments and diffstat. Andrew, please don't pick this for -mm yet. It'll hopefully come to you through Greg's i2c tree when it is ready. Additional notes: * Stats (debugging disabled) before afterdiff # I2C-only drivers drivers/hwmon/adm1021.ko 16855 16820 -35 drivers/hwmon/adm1025.ko 21677 21642 -35 drivers/hwmon/adm1026.ko 41379 41344 -35 drivers/hwmon/adm1031.ko 23071 23036 -35 drivers/hwmon/adm9240.ko 21338 21303 -35 drivers/hwmon/asb100.ko27512 27445 -67 drivers/hwmon/atxp1.ko 10410 10375 -35 drivers/hwmon/ds1621.ko 99709903 -67 drivers/hwmon/fscher.ko19333 19298 -35 drivers/hwmon/fscpos.ko19192 19157 -35 drivers/hwmon/gl518sm.ko 21011 20976 -35 drivers/hwmon/gl520sm.ko 23552 23517 -35 drivers/hwmon/lm63.ko 12532 12497 -35 drivers/hwmon/lm75.ko 93829347 -35 drivers/hwmon/lm77.ko 11666 11631 -35 drivers/hwmon/lm80.ko 22552 22517 -35 drivers/hwmon/lm83.ko 10146 10111 -35 drivers/hwmon/lm85.ko 41069 41034 -35 drivers/hwmon/lm87.ko 25868 25833 -35 drivers/hwmon/lm90.ko 15511 15458 -53 drivers/hwmon/lm92.ko 12072 12037 -35 drivers/hwmon/max1619.ko 10995 10960 -35 drivers/hwmon/w83l785ts.ko 85138478 -35 drivers/i2c/chips/ds1337.ko 88008765 -35 drivers/i2c/chips/eeprom.ko 83318296 -35 drivers/i2c/chips/max6875.ko 10460 10425 -35 drivers/i2c/chips/pca9539.ko79817946 -35 drivers/i2c/chips/pcf8574.ko82608225 -35 drivers/i2c/chips/pcf8591.ko97989763 -35 # hybrid drivers drivers/hwmon/it87.ko 25924 26563+639 drivers/hwmon/lm78.ko 21781 22420+639 drivers/hwmon/w83781d.ko 39132 39745+613 # ISA-only drivers drivers/hwmon/pc87360.ko 48007 47734-273 drivers/hwmon/sis5595.ko 20257 17401 -2856 drivers/hwmon/smsc47b397.ko 74227122-300 drivers/hwmon/smsc47m1.ko 11330 11080-250 drivers/hwmon/via686a.ko 22922 20066 -2856 drivers/hwmon/w83627ehf.ko 19155 16255 -2900 drivers/hwmon/w83627hf.ko 35861 30955 -4906 # core modules drivers/i2c/busses/i2c-isa.ko 29915685 +2694 drivers/i2c/i2c-core.ko21257 21805+548 drivers/i2c/i2c-sensor.ko 40573767-290 total -10595 Documentation/i2c/porting-clients |7 - Documentation/i2c/writing-clients | 46 --- drivers/hwmon/Kconfig |3 drivers/hwmon/adm1021.c | 10 -- drivers/hwmon/adm1025.c |1 drivers/hwmon/adm1026.c |1 drivers/hwmon/adm1031.c |1 drivers/hwmon/adm9240.c |2 drivers/hwmon/asb100.c| 11 -- drivers/hwmon/atxp1.c |1 drivers/hwmon/ds1621.c|1 drivers/hwmon/fscher.c|1 drivers/hwmon/fscpos.c|1 drivers/hwmon/gl518sm.c |1 drivers/hwmon/gl520sm.c |1 drivers/hwmon/it87.c | 42 -- drivers/hwmon/lm63.c |1 drivers/hwmon/lm75.c | 11 -- drivers/hwmon/lm77.c |1 drivers/hwmon/lm78.c | 37 +++- drivers/hwmon/lm80.c |1 drivers/hwmon/lm83.c
Re: [announce] 'patchview' script
randy_dunlap wrote:
Hi,
Someone asked me about a tool like this and I didn't know of one,
so I made this little script.
'patchview' merges a patch file and a source tree to a set of
temporary modified files. This enables better patch (re)viewing
and more viewable context. (hopefully)
Are there already other tools that do something similar to this?
(other than SCMs)
The patchview script is here:
http://www.xenotime.net/linux/scripts/patchview
usage: patchview [-f] patchfile srctree
-f : force tkdiff even if 'patch' has errors
It uses (requires) lsdiff (from patchutils) and tkdiff.
patchutils: http://cyberelk.net/tim/patchutils/
tkdiff: http://sourceforge.net/projects/tkdiff/
---
~Randy
Randy,
As Nick already pointed out, mktemp fails if the parent dir doesn't
exist. The attached patch tries to create the parent if it doesn't
exist. It also accepts a [-s] argument to bring up a single viewer at a
time. Otherwise, if there are many different files being touched by the
patch it dies a horrible death on my machine. Nice utility, btw.
--
kr
--- patchview.orig 2005-07-19 16:08:21.0 -0500
+++ patchview 2005-07-19 16:30:07.0 -0500
@@ -3,7 +3,6 @@
# License: GPL v2.
#
# uses patchutils (lsdiff) and tkdiff
-
# returns 'base'
function strip_filename()
{
@@ -25,20 +24,55 @@
}
force=0
-patchfile=$1
-srctree=$2
+single=0
VIEWER="tkdiff"
# or maybe "sh -c colordiff" would work
-if [ "$patchfile" == "-f" ]; then
- force=1
- patchfile=$2
- srctree=$3
-fi
+while [ -n "$1" ]
+do
+ case $1 in
+ -f)
+ force=1
+ ;;
+
+ -s)
+ single=1
+ ;;
+ -*)
+ if [ "${1#-}" = '?' ]
+ then
+ echo "usage: patchview [-f] [-s] patchfile srctree"
+ echo " -f : force tkdiff even if 'patch' has errors"
+ echo " -s : single tkdiff even if 'patch' contains
multiple files"
+ exit 0
+ fi
+ ;;
+
+ *)
+ # Accept filename or report a warning
+ if [ -z "${patchfile}" ]
+ then
+ patchfile=$1
+ srctree=$2
+ break
+ else
+ echo "usage: patchview [-f] [-s] patchfile srctree"
+ echo " -f : force tkdiff even if 'patch' has errors"
+ echo " -s : single tkdiff even if 'patch' contains
multiple files"
+ exit 0
+ fi
+ ;;
+ esac
+
+ # Shift argument 2 into argument 1's slot. Loop to check the argument.
+ shift
+done
+
if [ "$patchfile" = "" -o "$srctree" = "" ]; then
echo "usage: patchview [-f] patchfile srctree"
echo " -f : force tkdiff even if 'patch' has errors"
+ echo " -s : single tkdiff even if 'patch' contains multiple files"
exit 1
fi
@@ -48,6 +82,10 @@
else
TMPDIR=/tmp
fi
+if [ ! -d ${TMPDIR}/XX ];then
+ mkdir ${TMPDIR}/XX || echo "failed mktemp for patch files dir."
+fi
+
WORKDIR=`mktemp -d -p ${TMPDIR}/XX` || echo "failed mktemp for patch files
dir."
pfiles=`lsdiff --strip 1 $patchfile`
@@ -73,8 +111,13 @@
for pf in $pfiles ; do
$VIEWER $WORKDIR/$pf.orig $WORKDIR/$pf &
+ if [ ${single} -eq 1 ];then
+ wait # for viewer to exit
+ fi
done
-wait # for all viewers to exit
+if [ ${single} -eq 0 ];then
+ wait # for all viewers to exit
+fi
rm -rf $WORKDIR
Re: amd64-agp vs. swsusp
Andreas Steinmetz wrote: Michal Schmidt wrote: Does resuming from swsuspend work for anyone with amd64-agp loaded? On my system when I suspend with amd64-agp loaded, I get a spontaneous reboot on resume. It reboots immediately after reading the saved image from disk. This is 100% reproducible. Athlon 64 FX-53, Asus A8V Deluxe, Linux 2.6.13-rc3-mm1. AMD Athlon(tm) 64 Processor 3000+, Acer Aspire Linux gringo 2.6.13-rc3-gringo #36 Sun Jul 17 15:57:17 CEST 2005 x86_64 unknown unknown GNU/Linux CONFIG_AGP=y CONFIG_AGP_AMD64=y swsusp works for me. Could it be mm, agp as a module or some speciality ^^^ That seems to be the problem! of your hardware? I have rebuilt agpgart and amd64-agp into the kernel and now it has resumed successfully for the first time. Thank you for the hint! But I still wonder, why that makes a difference. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: page allocation/attributes question (i386/x86_64 specific)
Andi Kleen wrote:
> I personally wouldn't like doing this NX cleanup very late like you did but
> instead directly after the early NX setup.
I've thought about it more, and come up with another patch. All it does is
sets up the PTEs correctly from the beginning, breaking up large pages if
necessary so that only pages that are actually executable kernel code will be
executable.
With this patch, no changes are required for change_page_attr() to work. The
disadvantages to this patch are (1) it still relies on the fact that
change_page_attr() won't revert small pages to a large page if the page
containing the PTEs is reserved, and (2) if any init code is in a large page
that contains no non-init code, those PTEs won't be reverted to a large page
when the init memory is freed (though they will be changed to non-executable).
Once this patch is in place, it wouldn't take much to modify change_page_attr()
to use the new page_refprot() function to determine the "normal" setting for
pages. That could eliminate the need for it to ignore reserved pages, but I
wanted to keep this patch simple.
Anyway, comments appreciated!
Stuart
--- 2.6.12-a/arch/i386/mm/init.c2005-07-19 14:41:14.0 -0500
+++ 2.6.12-b/arch/i386/mm/init.c2005-07-19 14:40:22.0 -0500
@@ -128,12 +128,7 @@ static void __init page_table_range_init
}
}
-static inline int is_kernel_text(unsigned long addr)
-{
- if (addr >= PAGE_OFFSET && addr <= (unsigned long)__init_end)
- return 1;
- return 0;
-}
+static pgprot_t page_refprot(unsigned int);
/*
* This maps the physical memory to kernel virtual address space, a total
@@ -158,25 +153,18 @@ static void __init kernel_physical_mappi
continue;
for (pmd_idx = 0; pmd_idx < PTRS_PER_PMD && pfn < max_low_pfn;
pmd++, pmd_idx++) {
unsigned int address = pfn * PAGE_SIZE + PAGE_OFFSET;
+ pgprot_t ref_prot = page_refprot(address);
/* Map with big pages if possible, otherwise create
normal page tables. */
- if (cpu_has_pse) {
- unsigned int address2 = (pfn + PTRS_PER_PTE -
1) * PAGE_SIZE + PAGE_OFFSET + PAGE_SIZE-1;
-
- if (is_kernel_text(address) ||
is_kernel_text(address2))
- set_pmd(pmd, pfn_pmd(pfn,
PAGE_KERNEL_LARGE_EXEC));
- else
- set_pmd(pmd, pfn_pmd(pfn,
PAGE_KERNEL_LARGE));
+ if (pgprot_val(ref_prot) & _PAGE_PSE) {
+ set_pmd(pmd, pfn_pmd(pfn, ref_prot));
pfn += PTRS_PER_PTE;
} else {
pte = one_page_table_init(pmd);
- for (pte_ofs = 0; pte_ofs < PTRS_PER_PTE && pfn
< max_low_pfn; pte++, pfn++, pte_ofs++) {
- if (is_kernel_text(address))
- set_pte(pte,
pfn_pte(pfn, PAGE_KERNEL_EXEC));
- else
- set_pte(pte,
pfn_pte(pfn, PAGE_KERNEL));
- }
+ for (pte_ofs = 0; pte_ofs < PTRS_PER_PTE && pfn
< max_low_pfn;
+address += PAGE_SIZE, pte++, pfn++,
pte_ofs++)
+ set_pte(pte, pfn_pte(pfn,
page_refprot(address)));
}
}
}
@@ -229,6 +217,56 @@ static inline int page_is_ram(unsigned l
return 0;
}
+/*
+ * page_refprot() returns PTE attributes used to set up the page tables
+ */
+
+static inline int is_kernel_text (unsigned int addr, unsigned int mask)
+{
+ addr &= mask;
+ if ((addr >= ((unsigned int)_text & mask)) &&
+ (addr <= ((unsigned int)_etext)))
+ return 1;
+ return 0;
+}
+
+static inline int is_kernel_inittext (unsigned int addr, unsigned int mask)
+{
+ addr &= mask;
+ if ((addr >= ((unsigned int)_sinittext & mask)) &&
+ (addr <= ((unsigned int)_einittext)))
+ return 1;
+ return 0;
+}
+
+static pgprot_t page_refprot(unsigned int addr)
+{
+ if (nx_enabled &&
+ (is_kernel_text(addr, LARGE_PAGE_MASK) ||
+(is_kernel_inittext(addr, LARGE_PAGE_MASK)) ||
+((addr & LARGE_PAGE_MASK) == 0))) {
+ /* big page area has executable stuff in it--use small pages */
+ if (is_kernel_text(addr, PAGE_MASK) ||
+ (is_kernel_inittext(addr, PAGE_MASK)) ||
+ ((__pa(addr) <= 0xf) && !page_is_ram(__pa(addr) >>
PAGE_SHIFT)))
+ return PAGE_KERNEL_EXEC;
+ else
+
Re: [2.6 patch] NETCONSOLE must depend on INET
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Tue, 19 Jul 2005 20:29:19 +0200 > NETCONSOLE=y and INET=n results in the following compile error: Also applied, thanks Adrian. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: amd64-agp vs. swsusp
Michal Schmidt wrote: > Hello, > > Does resuming from swsuspend work for anyone with amd64-agp loaded? > > On my system when I suspend with amd64-agp loaded, I get a spontaneous > reboot on resume. It reboots immediately after reading the saved image > from disk. > This is 100% reproducible. > > Athlon 64 FX-53, Asus A8V Deluxe, Linux 2.6.13-rc3-mm1. AMD Athlon(tm) 64 Processor 3000+, Acer Aspire Linux gringo 2.6.13-rc3-gringo #36 Sun Jul 17 15:57:17 CEST 2005 x86_64 unknown unknown GNU/Linux CONFIG_AGP=y CONFIG_AGP_AMD64=y swsusp works for me. Could it be mm, agp as a module or some speciality of your hardware? -- Andreas Steinmetz SPAMmers use [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 patch] BRIDGE_EBT_ARPREPLY must depend on INET
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Tue, 19 Jul 2005 15:55:29 +0200 > BRIDGE_EBT_ARPREPLY=y and INET=n results in the following compile error: Applied, thanks Adrian. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
amd64-agp vs. swsusp
Hello, Does resuming from swsuspend work for anyone with amd64-agp loaded? On my system when I suspend with amd64-agp loaded, I get a spontaneous reboot on resume. It reboots immediately after reading the saved image from disk. This is 100% reproducible. Athlon 64 FX-53, Asus A8V Deluxe, Linux 2.6.13-rc3-mm1. Regards, Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] sound drivers select'ing ISAPNP must depend on PNP && ISA
On Tue, 19 Jul 2005, Adrian Bunk wrote: > On Sun, Jul 17, 2005 at 05:07:48PM +0200, Bodo Eggert wrote: > > In sound/isa/Kconfig, select ISAPNP and depend on ISAPNP are intermixed, > > resulting in funny behaviour. (Soundcarts get selectable if other > > soundcards are selected). > > > > This patch changes the "depend on ISAPNP"s to select. > >... > > I like the idea of this patch, but it brings to more drivers to a > violation of the "if you select something, you have to ensure that the > dependencies of what you select are fulfilled" rule causing link errors > with invalid .config's. That should be mentioned in kconfig-language.txt. OTOH, the build system should automatically propagate the dependencies. I asume that should be easy, except for having the time to implement that. BTW: How can you select something to be at least a module? BTW2: In bool options, depending on FOO seems to be equal to depending on FOO!=n. Is this assumption correct? -- Top 100 things you don't want the sysadmin to say: 49. What's this switch for anyways...? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird USB errors on HD
On Tue, Jul 19, 2005 at 04:16:55PM -0400, Lee Revell wrote: > On Tue, 2005-07-19 at 15:29 -0400, Greg KH wrote: > > Ugh, you have a bad device or power supply, or aren't giving it enough > > power to drive the thing. Nothing we can do in Linux for that, sorry. > > Buy a wall-powered usb hub, that usually helps. > > > > I get the same messages on boot from a bus with no devices connected to > it (hub 4). I have not connected the motherboard header because I don't > use that bus, could this be related? Yes, it's probably just not grounded properly because the header is not connected. It's harmless and you can just ignore it. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sharp Zaurus sl-5500 broken in 2.6.12
On Tue, 2005-07-19 at 21:21 +0200, Pavel Machek wrote:
> Hi!
>
> > ...and that's well known; but now I did some back tracking, and
> > 2.6.12-rc1 works, 2.6.12-rc2 does *not* and 2.6.12-rc2 with arm
> > changes reverted works. I'll play a bit more.
>
> This fixes at least one break-the-boot bug in -rc2...
>
> Pavel
>
> --- linux-z11.rc2bad/arch/arm/mach-sa1100/collie.c2005-07-19
> 20:49:07.0 +0200
> +++ linux-z11/arch/arm/mach-sa1100/collie.c 2005-07-19 21:05:54.0
> +0200
> @@ -235,7 +235,7 @@
> sa11x0_set_flash_data(_flash_data, collie_flash_resources,
> ARRAY_SIZE(collie_flash_resources));
>
> - sharpsl_save_param();
> +// sharpsl_save_param();
> }
>
> static struct map_desc collie_io_desc[] __initdata = {
Could you check this wasn't caused by this typo please:
http://www.rpsys.net/openzaurus/patches/collie_typofix-r0.patch
(this has been fixed in recent kernels)
Cheers,
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [announce] 'patchview' script
>Hi, > >Someone asked me about a tool like this and I didn't know of one, >so I made this little script. > >'patchview' merges a patch file and a source tree to a set of >temporary modified files. This enables better patch (re)viewing >and more viewable context. (hopefully) > >Are there already other tools that do something similar to this? >(other than SCMs) I use unionfs for this purpose because it avoids copying around the full kernel tree. This is also good for applying or rediffing in general, since after you unmount the union, the "delta directory" contains only modified files and you can use diff -Pdpru 2.6.13-rc1 deltadir to get a PGP - a pretty good patchfile. :) Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Noob question. Why is the for-pentium4 kernel built with -march=i686 ?
On Tue, 2005-07-19 at 22:15 +0200, Jan Engelhardt wrote: > >AFAIK it's not possible to use SSE and MME in kernel mode, since these > >registers aren't preserved (it would be expensive). > > Floating point is anyway a no-no in the kernel. However, there are a few exceptions like mmx_memcpy. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird USB errors on HD
On Tue, 2005-07-19 at 15:29 -0400, Greg KH wrote: > Ugh, you have a bad device or power supply, or aren't giving it enough > power to drive the thing. Nothing we can do in Linux for that, sorry. > Buy a wall-powered usb hub, that usually helps. > I get the same messages on boot from a bus with no devices connected to it (hub 4). I have not connected the motherboard header because I don't use that bus, could this be related? PCI0 USB0 USB1 USB2 USB3 USB4 USB5 USB6 LAN0 AC97 MC97 usbcore: registered new driver usbfs usbcore: registered new driver hub USB Universal Host Controller Interface driver v2.2 uhci_hcd :00:10.0: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller uhci_hcd :00:10.0: new USB bus registered, assigned bus number 1 uhci_hcd :00:10.0: irq 11, io base 0xd400 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected uhci_hcd :00:10.1: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (#2) uhci_hcd :00:10.1: new USB bus registered, assigned bus number 2 uhci_hcd :00:10.1: irq 10, io base 0xd800 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected uhci_hcd :00:10.2: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (#3) uhci_hcd :00:10.2: new USB bus registered, assigned bus number 3 uhci_hcd :00:10.2: irq 12, io base 0xdc00 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ehci_hcd :00:10.3: VIA Technologies, Inc. USB 2.0 ehci_hcd :00:10.3: new USB bus registered, assigned bus number 4 ehci_hcd :00:10.3: irq 14, io mem 0xea004000 ehci_hcd :00:10.3: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 hub 4-0:1.0: USB hub found hub 4-0:1.0: 6 ports detected hub 4-0:1.0: over-current change on port 5 hub 4-0:1.0: over-current change on port 6 usb 2-2: new low speed USB device using uhci_hcd and address 2 input: USB HID v1.00 Mouse [Microsoft Microsoft Trackball Optical®] on usb-:00:10.1-2 usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.01:USB HID core driver Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Noob question. Why is the for-pentium4 kernel built with -march=i686 ?
>AFAIK it's not possible to use SSE and MME in kernel mode, since these >registers aren't preserved (it would be expensive). Floating point is anyway a no-no in the kernel. Jan Engelhardt -- | Alphagate Systems, http://alphagate.hopto.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Noob question. Why is the for-pentium4 kernel built with -march=i686 ?
Ivan Yosifov <[EMAIL PROTECTED]> wrote: > -march implies -mtune and also implies thing like -msse2 for the > instruction set where applicable. > I think -march=pentium4 is equivalent to -mmmx -msse -msse2 > -mtune=pentium4 ( if I have not fogotten anything ). > Pentium4 supports things like sse2 and mmx which AFAIK plain i686 does > not. AFAIK it's not possible to use SSE and MME in kernel mode, since these registers aren't preserved (it would be expensive). -- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 do you accurately determine a process' RAM usage?
Hi, On 7/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > OK, please let us know how it goes. > > It went very well. I could find no problems at all. > I've updated my script to use the new method, so please merge smaps :) > http://www.pixelbeat.org/scripts/ps_mem.py > > Usually the shared mem reported by /proc/$$/statm > is the same as summing all the shared values in in /proc/$$/smaps > but there can be large discrepancies. Have you checked how the statm shared is calculated? I guess it does something like: shared = mm->rss - mm->anon_rss But in smaps output you can have anonymous area like: b6e0e000-b6e13000 rw-p Size:20 KB Rss: 4 KB Shared_Clean: 0 KB Shared_Dirty: 4 KB Private_Clean:0 KB Private_Dirty:0 KB Look that it presents 4 KB of shared value in area considered anonymous. ANDREW: anon_rss is the rss for anonymous area, right? > In the real world you can see this with a newly started apache. > On my system statm reported that apache was using 35MB, > whereas smaps reported the correct amount of 11MB. How dou you know that 11MB is the correct shared value and the 35MB is the wrong value? BR, Mauricio Lin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [announce] 'patchview' script
On Tue, Jul 19, 2005 at 11:51:03AM -0700, randy_dunlap wrote:
>
> Hi,
>
> Someone asked me about a tool like this and I didn't know of one,
> so I made this little script.
>
> 'patchview' merges a patch file and a source tree to a set of
> temporary modified files. This enables better patch (re)viewing
> and more viewable context. (hopefully)
>
> Are there already other tools that do something similar to this?
> (other than SCMs)
>
>
> The patchview script is here:
> http://www.xenotime.net/linux/scripts/patchview
Hey Randy,
The mktemp command fails for me, but patchview keeps on going.
[EMAIL PROTECTED] ~/tmp]$ patchview mypatch.patch linux-2.6.13-rc3
mktemp: cannot make temp dir /home/njw/tmp/XX/tmp.xV1xRT: No such file or
directory
failed mktemp for patch files dir.
mkdir: cannot create directory `/fs': Permission denied
cp: cannot create regular file `/fs/Kconfig': No such file or directory
mkdir: cannot create directory `/fs': Permission denied
cp: cannot create regular file `/fs/Makefile': No such file or directory
[ ... ]
This patch makes mktemp work correctly for me and causes patchview to exit
if it happens to fail.
Thanks,
Nick Wilson
--- patchview.orig 2005-07-19 12:50:20.0 -0700
+++ patchview 2005-07-19 13:07:12.0 -0700
@@ -48,7 +48,7 @@
else
TMPDIR=/tmp
fi
-WORKDIR=`mktemp -d -p ${TMPDIR}/XX` || echo "failed mktemp for patch files
dir."
+WORKDIR=`mktemp -d -p ${TMPDIR} XX` || { echo "failed mktemp for patch
files dir."; exit 1; }
pfiles=`lsdiff --strip 1 $patchfile`
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] drivers/pnp/pnpbios/rsparser.c: fix compile error wit PCI=n
This patch fixes the following compile error with CONFIG_PCI=n:
<-- snip -->
...
CC drivers/pnp/pnpbios/rsparser.o
drivers/pnp/pnpbios/rsparser.c: In function
'pnpbios_parse_allocated_irqresource':
drivers/pnp/pnpbios/rsparser.c:67: error: too many arguments to function
'pcibios_penalize_isa_irq'
make[3]: *** [drivers/pnp/pnpbios/rsparser.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.13-rc3-mm1-full/drivers/pnp/pnpbios/rsparser.c.old
2005-07-19 20:26:45.0 +0200
+++ linux-2.6.13-rc3-mm1-full/drivers/pnp/pnpbios/rsparser.c2005-07-19
20:36:03.0 +0200
@@ -11,7 +11,7 @@
#ifdef CONFIG_PCI
#include
#else
-inline void pcibios_penalize_isa_irq(int irq) {}
+inline void pcibios_penalize_isa_irq(int irq, int active) {}
#endif /* CONFIG_PCI */
#include "pnpbios.h"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Weird USB errors on HD
On Tue, Jul 19, 2005 at 03:27:18PM -0400, Karim Yaghmour wrote: > > That being said, shouldn't there be a way for the kernel to refuse to > use this hd if it's not getting enough power. I don't know enough about > USB to say, but isn't there something more elegant that could be done in > software? Nope, it's a hardware/electrical issue :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird USB errors on HD
Greg KH wrote: > Ugh, you have a bad device or power supply, or aren't giving it enough > power to drive the thing. Nothing we can do in Linux for that, sorry. > Buy a wall-powered usb hub, that usually helps. I have one. I naively thought I could just plug the drive directly to the laptop without using the wall-powered hub. I'll try that instead. Thanks. That being said, shouldn't there be a way for the kernel to refuse to use this hd if it's not getting enough power. I don't know enough about USB to say, but isn't there something more elegant that could be done in software? Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird USB errors on HD
On Tue, Jul 19, 2005 at 12:47:32PM -0400, Karim Yaghmour wrote: > > I have a usb-attached HD that I use from time to time. When it's connected > to my desktop through a hub it works flawlessly. When connected to my Dell > D600 Laptop, however, it sometimes randomly exhibits a loud click (as if the > heads went berzerk) and the device goes unrecognized (i.e. the USB layer drops > the device and then redetects it again; meanwhile there is FS corruption.) > > The same behavior happens with 2.4.x and 2.6.x > > In /var/log/messages I see something like: > hub 3-0:1.0: over-current change on port 1 > hub 1-0:1.0: over-current change on port 3 > ... > usb 1-3: USB disconnect, address 2 > usb 1-3: new high speed USB device using ehci_hcd and address 3 Ugh, you have a bad device or power supply, or aren't giving it enough power to drive the thing. Nothing we can do in Linux for that, sorry. Buy a wall-powered usb hub, that usually helps. Good luck, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Dual-core with kernel 2.4 (Red Hat EL 3)
Hallo, Linux folks! (first post here) I am trying to find out whether I can start using dual-core cpus with a 2.4 kernel (Red Hat EL 3). Three questions below - please answer if you have any insight. - The first update to EL 4 announced "support" for dual core cpus both from AMD and Intel, but doesn't say what that support means. I would think with the right BIOS, the OS might distribute all tasks among all cores right out of the box, as long as you don't need any special parallel computing capabilities. Or will the kernel just not recognize the second core? - The most recent update to EL 3 (which is what I am using) does not say anything about dual-core. Does that mean there is no chance it will run on a dual-core chip, because it has kernel 2.4? - My application is multi process server type stuff. I'd like to use Intel dual chip boards. Are there any Intel dual chip dual-core solutions you can buy? I haven't found one yet. Cheers Hubert Schwarthoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 debouncing?
On Tue, 19 Jul 2005 18:24:25 +0200, DervishD <[EMAIL PROTECTED]> wrote: > I have a new MP3 player, and when I disconnect it from the USB > port, my logs says: > > <30>Jul 19 18:11:05 kernel: usb.c: USB disconnect on device 00:07.3-1 > address 2 > <27>Jul 19 18:11:06 kernel: hub.c: connect-debounce failed, port 1 > disabled > > What is that 'connect-debounce' for? Is the port damaged? Am I > doing anything wrong? The ports are not getting completely disabled. The wording is poor. If you plug something else, hub gets a connect change, khubd will allow another debounce cycle and accept whatever happens. In this case, when you're pulling the plug the hub receives a momentary reconnect, so the software things something else was plugged. I think perhaps the resistor harness is not good in the device, or perhaps something is wrong with the connector. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sharp Zaurus sl-5500 broken in 2.6.12
Hi!
> ...and that's well known; but now I did some back tracking, and
> 2.6.12-rc1 works, 2.6.12-rc2 does *not* and 2.6.12-rc2 with arm
> changes reverted works. I'll play a bit more.
This fixes at least one break-the-boot bug in -rc2...
Pavel
--- linux-z11.rc2bad/arch/arm/mach-sa1100/collie.c 2005-07-19
20:49:07.0 +0200
+++ linux-z11/arch/arm/mach-sa1100/collie.c 2005-07-19 21:05:54.0
+0200
@@ -235,7 +235,7 @@
sa11x0_set_flash_data(_flash_data, collie_flash_resources,
ARRAY_SIZE(collie_flash_resources));
- sharpsl_save_param();
+// sharpsl_save_param();
}
static struct map_desc collie_io_desc[] __initdata = {
--
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Oops in hidinput_hid_event
On Mon, Jul 18, 2005 at 02:16:37PM -0700, Pete Zaitcev wrote:
> I think this patch is rather obvious, so maybe I should ask Andrew to
> apply it to -mm for now, to get some testing. Would that help to verify
> it for acceptance?
Your patch is perfectly OK, my NULL check was indeed completely wrong.
I need to find out how there can be an input event happening without its
associated input structure, though, since the oops actually reveals a
deeper problem.
So that's why I didn't apply the patch yet.
> Begin forwarded message:
>
> Date: Tue, 28 Jun 2005 15:00:23 -0700
> From: Pete Zaitcev <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net
> Subject: Oops in hidinput_hid_event
>
> Hi, Vojtech:
>
> Someone reported a bug in Fedora, which runs a largely unmodified upstream
> kernel in this area. Whenever the user hits a key which switches LED,
> the system oopses. Here's a trace:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00c8
> EFLAGS: 00010006 (2.6.11-1.1369_FC4smp)
> EIP is at hidinput_hid_event+0x2d/0x292
> Call Trace:
> [] hid_process_event+0x57/0x5f
> [] hid_input_field+0x2a2/0x2ac
> [] hid_input_report+0x9e/0xb8
> [] hid_ctrl+0x14c/0x151
> [] uhci_destroy_urb_priv+0xb5/0x10a [uhci_hcd]
> [] usb_hcd_giveback_urb+0x24/0x67
> [] uhci_finish_urb+0x2d/0x38 [uhci_hcd]
> [] uhci_finish_completion+0x44/0x56 [uhci_hcd]
> [] uhci_scan_schedule+0xaa/0x13a [uhci_hcd]
> [] i8042_interrupt+0x121/0x234
> [] uhci_irq+0x47/0x10d [uhci_hcd]
>
> Full trace at
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160709
>
> Any ideas?
>
> By the way, it seems that I see a bug in hidinput_hid_event.
> The check for NULL can never work, becaue >input
> is nonzero at all times. How about this?
>
> --- linux-2.6.12/drivers/usb/input/hid-input.c2005-06-21
> 12:58:47.0 -0700
> +++ linux-2.6.12-lem/drivers/usb/input/hid-input.c2005-06-28
> 14:57:22.0 -0700
> @@ -397,11 +397,12 @@
>
> void hidinput_hid_event(struct hid_device *hid, struct hid_field *field,
> struct hid_usage *usage, __s32 value, struct pt_regs *regs)
> {
> - struct input_dev *input = >hidinput->input;
> + struct input_dev *input;
> int *quirks = >quirks;
>
> - if (!input)
> + if (!field->hidinput)
> return;
> + input = >hidinput->input;
>
> input_regs(input, regs);
>
>
> -- Pete
>
--
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: [PATCH] ramfs: pretend dirent sizes
On Tue, Jul 19, 2005 at 09:14:04PM +0200, Jan Blunck wrote: > >So you can seek to m*+ to access an offset into > >something at depth m? > > > > Yes. Hos does that work if offset >= m? > I disagree. Where is the information value of i_size if we always > could return 0? Directories clearly can't have zero size, so 0 means 'special'. Anything other than zero *might* be a real value. > IMO it should be at least an upper bound for the "number" of > informations that could actually be read (in terms of a seek offset) > like it is in the case of regular files. Why? And what should that upper bound be? > Better, if it is a strict upper bound so that you can seek to every > value smaller than i_size. For this purpose the i_size of > directories doesn't need to reflect any unit. lseek talks about bytes --- yes, it means for files specifically but I still don't see why we need to define more counter-intuitive semantics for directories when we don't need them. Also, how is lseek + readdir supposed to work in general? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ramfs: pretend dirent sizes
Chris Wedgwood wrote: So the size you want to reflect is n* i take it? Where in this case n is 20? So you can seek to m*+ to access an offset into something at depth m? Yes. The i_size of a directory isn't covered by the POSIX standard. IMO, it should be possible to seek in the range of i_size and a following readdir() on the directory should succeed. With what defined semantics? What if an entry is added in between seek and readdir? You have the same problem with regular files. This is a user and not a kernel problem. Why? It seems perfectly reasonable that we can return 0 in such cases. Zero seems to make more sense as 'magical/unknown' than say any other arbitrary value. I disagree. Where is the information value of i_size if we always could return 0? IMO it should be at least an upper bound for the "number" of informations that could actually be read (in terms of a seek offset) like it is in the case of regular files. Better, if it is a strict upper bound so that you can seek to every value smaller than i_size. For this purpose the i_size of directories doesn't need to reflect any unit. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] jsm driver - Linux-2.6.12.3
I am using RHEL4.0-U1 as the distro. Here is the info on gcc version is 3.4.3-22.1 Thanks for your feed-back. Ananda Krishnan On Tue, 2005-07-19 at 22:47 +0400, Alexey Dobriyan wrote: > On Tue, Jul 19, 2005 at 12:53:20PM -0500, V. ANANDA KRISHNAN wrote: > > This patch takes care of (1) compiler warnings which displays the mixing > > of declarations and code > > With what gcc version and what CFLAGS? > > > (2) dynamic allocation of major device number > > instead of the static number 253 (3) the version update to reflect the > > changes in the patch. > > > --- linux-2.6.12.3.orig/drivers/serial/jsm/jsm_driver.c > > +++ linux-2.6.12.3.new/drivers/serial/jsm/jsm_driver.c > > > + * CHANGE LOG: > > + * Jul 18, 2005: Changed the major number changed to 0 to use the dynamic > > + * allocation of major number by OS. > > + * > > ChangeLog maintenance is the job of SCM. Don't add useless comments. > > > --- linux-2.6.12.3.orig/drivers/serial/jsm/jsm_neo.c > > +++ linux-2.6.12.3.new/drivers/serial/jsm/jsm_neo.c > > > - u8 ier = readb(>ch_neo_uart->ier); > > - u8 efr = readb(>ch_neo_uart->efr); > > + u8 ier, efr; > > + ier = readb(>ch_neo_uart->ier); > > + efr = readb(>ch_neo_uart->efr); > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] jsm driver - Linux-2.6.12.3
On Tue, Jul 19, 2005 at 12:53:20PM -0500, V. ANANDA KRISHNAN wrote: > This patch takes care of (1) compiler warnings which displays the mixing > of declarations and code With what gcc version and what CFLAGS? > (2) dynamic allocation of major device number > instead of the static number 253 (3) the version update to reflect the > changes in the patch. > --- linux-2.6.12.3.orig/drivers/serial/jsm/jsm_driver.c > +++ linux-2.6.12.3.new/drivers/serial/jsm/jsm_driver.c > + * CHANGE LOG: > + * Jul 18, 2005: Changed the major number changed to 0 to use the dynamic > + * allocation of major number by OS. > + * ChangeLog maintenance is the job of SCM. Don't add useless comments. > --- linux-2.6.12.3.orig/drivers/serial/jsm/jsm_neo.c > +++ linux-2.6.12.3.new/drivers/serial/jsm/jsm_neo.c > - u8 ier = readb(>ch_neo_uart->ier); > - u8 efr = readb(>ch_neo_uart->efr); > + u8 ier, efr; > + ier = readb(>ch_neo_uart->ier); > + efr = readb(>ch_neo_uart->efr); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Noob question. Why is the for-pentium4 kernel built with -march=i686 ?
On Tue, 2005-07-19 at 19:52 +0200, Jan Engelhardt wrote: > >Hello, > > > >If I set the CPU type to be amd64 in kernel config, the kernel is built > >with -march=k8. If I set it to be k6, the kernel is built with > >-march=k6. If I set the CPU type to be Pentium4, the kernel is built > >with -march=i686 -mtune=pentium4. Why is not the for-P4 kernel built > >with -march=pentium4 ? > >I tried building the kernel with -march=pentium4 for the sake of > >experiment and got no ill effects. > > -march= specifies the instruction set, -mcpu= / -mtune= the tuning factor. > Maybe it is that the instruction set is the same on i686 and > pentium4. cmov for example is not present in k6, and k8 is something > completely different at all. > > > Jan Engelhardt -march implies -mtune and also implies thing like -msse2 for the instruction set where applicable. I think -march=pentium4 is equivalent to -mmmx -msse -msse2 -mtune=pentium4 ( if I have not fogotten anything ). Pentium4 supports things like sse2 and mmx which AFAIK plain i686 does not. I first thought that maybe the kernel was destabilized by such optimizations, but k8 has all of them and more ( sse3 ). So, if it is ok to build the k8 kernel with -march=k8 why is it not ok to built the p4 kernel with -march=pentium4 ? I may be wrong, but any way I think of it it looks like a performance hit to build a p4 kernel with -march=i686. Ivan Yosifov. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ramfs: pretend dirent sizes
On Tue, Jul 19, 2005 at 08:22:26PM +0200, Jan Blunck wrote: > Since these "arranged" values are also used as the offsets in the > return dirent IMO it is quite clean. So the size you want to reflect is n* i take it? Where in this case n is 20? So you can seek to m*+ to access an offset into something at depth m? > Nope. This value is kind of traditional: tmpfs is using it > (http://marc.theaimsgroup.com/?l=linux-kernel=103208296515378=2). I > think a better value would be 1 (one) since this is also used as the > dirent offset by dcache_readdir(). I really don't know why tmpfs is doing this. > The i_size of a directory isn't covered by the POSIX standard. IMO, > it should be possible to seek in the range of i_size and a following > readdir() on the directory should succeed. With what defined semantics? What if an entry is added in between seek and readdir? > But this isn't possible even not with real file systems like ext2. I'm not sure how expecting a meaningful offset into a directory can have consistent bahvior. > But keeping the i_size bound to zero even if the directory contains > entries does not make sense at all. Why? It seems perfectly reasonable that we can return 0 in such cases. Zero seems to make more sense as 'magical/unknown' than say any other arbitrary value. It's also possible a regular filesystem could return an arbitrary value such as 20 (not that this directly matters except it becomes confusing potentially): [EMAIL PROTECTED]:~$ mkdir foobar [EMAIL PROTECTED]:~$ ls -ld foobar drwxr-xr-x 2 cw cw 6 Jul 19 11:29 foobar [EMAIL PROTECTED]:~$ mkdir foobar/1234567 [EMAIL PROTECTED]:~$ ls -ld foobar drwxr-xr-x 3 cw cw 20 Jul 19 11:30 foobar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] NETCONSOLE must depend on INET
NETCONSOLE=y and INET=n results in the following compile error: <-- snip --> ... LD .tmp_vmlinux1 net/built-in.o: In function `netpoll_parse_options': : undefined reference to `in_aton' net/built-in.o: In function `netpoll_parse_options': : undefined reference to `in_aton' make: *** [.tmp_vmlinux1] Error 1 <-- snip --> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.13-rc3/drivers/net/Kconfig.old2005-07-19 19:29:25.0 +0200 +++ linux-2.6.13-rc3/drivers/net/Kconfig2005-07-19 19:29:37.0 +0200 @@ -2544,7 +2544,7 @@ config NETCONSOLE tristate "Network console logging support (EXPERIMENTAL)" - depends on NETDEVICES && EXPERIMENTAL + depends on NETDEVICES && INET && EXPERIMENTAL ---help--- If you want to log kernel messages over the network, enable this. See for details. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ramfs: pretend dirent sizes
Chris Wedgwood wrote: I'm using the i_size of directories in my patches. When reading from a union directory, I'm using the i_size to seek to the right offset in the union stack. Ick. That'a a bit of a hack. Don't think so: 1st dir: [X] f_pos=0 f_pos=i_size(1st) 2nd dir: [XXX|-] f_pos=i_size(1st) f_pos=i_size(1st+2nd) ^ | f_pos=i_size(1st)+offset Since these "arranged" values are also used as the offsets in the return dirent IMO it is quite clean. Hence the value of 20 I guess --- assuming nothing will stack this high? Nope. This value is kind of traditional: tmpfs is using it (http://marc.theaimsgroup.com/?l=linux-kernel=103208296515378=2). I think a better value would be 1 (one) since this is also used as the dirent offset by dcache_readdir(). I personally would prefer that to be honest or some other way that doesn't change i_size. The i_size of a directory isn't covered by the POSIX standard. IMO, it should be possible to seek in the range of i_size and a following readdir() on the directory should succeed. But this isn't possible even not with real file systems like ext2. But keeping the i_size bound to zero even if the directory contains entries does not make sense at all. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Sharp Zaurus sl-5500 broken in 2.6.12
Hi! ...and that's well known; but now I did some back tracking, and 2.6.12-rc1 works, 2.6.12-rc2 does *not* and 2.6.12-rc2 with arm changes reverted works. I'll play a bit more. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.6.12 and 2.6.13 hangs for a while on boot
Hi all, I'm having little hangs while booting with kernels 2.6.12 and 2.6.13-rc1, rc2 and rc3. It is strange that 2.6.12-rc1 booted ok without hangs. I saw a post of Alan Cox on rc-1 release notes: "Old ISA/VESA systems sometimes put tertiary IDE controllers at addresses 0x1e8, 0x168, 0x1e0 or 0x160. Linux thus probes these addresses on x86 systems. Unfortunately some PCI systems now use these addresses for other purposes which leads to users seeing minute plus hangs during boot or even crashes." I thought this could be my problem, but it still hangs on boot. Hangs appears just before mounting filesystems message and before configuring system to use udev. I'm using Gentoo with vanilla-sources. I already asked on gentoo lists and nobody saw this behaviour. I tried google with no luck too. So my last resource which could give me some light is here. I'm using 2.6.13 on a Gateway laptop. Do you know of something about this? Have you seen this problem? Where could I look for more information about that in my system? I saw logs but they don't say anything. Also, besides this hangs on boot, system seems to work perfectly, but I'd like to remove this hangs from boot. For while, I'm using 2.6.11.10 which is working ok. Thanks in advance. -- Regards, Francisco Figueiredo Jr. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] jsm driver - Linux-2.6.12.3
Hi All,
Here is a patch to the jsm driver in the Linux (drivers/serial/jsm).
This patch takes care of (1) compiler warnings which displays the mixing
of declarations and code (2) dynamic allocation of major device number
instead of the static number 253 (3) the version update to reflect the
changes in the patch.
Please CC me your comments. Thanks.
Signed-off-by: V. Ananda Krishnan
diff -Nuar linux-2.6.12.3.orig/drivers/serial/jsm/jsm_driver.c linux-2.6.12.3.new/drivers/serial/jsm/jsm_driver.c
--- linux-2.6.12.3.orig/drivers/serial/jsm/jsm_driver.c 2005-07-19 15:16:20.0 -0500
+++ linux-2.6.12.3.new/drivers/serial/jsm/jsm_driver.c 2005-07-19 15:18:57.0 -0500
@@ -22,6 +22,10 @@
* Scott H Kilau <[EMAIL PROTECTED]>
* Wendy Xiong <[EMAIL PROTECTED]>
*
+ * CHANGE LOG:
+ * Jul 18, 2005: Changed the major number changed to 0 to use the dynamic
+ * allocation of major number by OS.
+ *
***/
#include
#include
@@ -42,7 +46,7 @@
.owner = THIS_MODULE,
.driver_name = JSM_DRIVER_NAME,
.dev_name = "ttyn",
- .major = 253,
+ .major = 0,
.minor = JSM_MINOR_START,
.nr = NR_PORTS,
};
diff -Nuar linux-2.6.12.3.orig/drivers/serial/jsm/jsm.h linux-2.6.12.3.new/drivers/serial/jsm/jsm.h
--- linux-2.6.12.3.orig/drivers/serial/jsm/jsm.h 2005-07-19 15:16:21.0 -0500
+++ linux-2.6.12.3.new/drivers/serial/jsm/jsm.h 2005-07-19 15:18:58.0 -0500
@@ -22,6 +22,9 @@
* Scott H Kilau <[EMAIL PROTECTED]>
* Wendy Xiong <[EMAIL PROTECTED]>
*
+ * CHANGE LOG:
+ * Jul 18, 2005: Changed the JSM_VERSION to "jsm: 1.2-1-INKERNEL"
+ *
***/
#ifndef __JSM_DRIVER_H
@@ -90,7 +93,7 @@
#define WRITEBUFLEN ((4096) + 4)
#define MYFLIPLEN N_TTY_BUF_SIZE
-#define JSM_VERSION "jsm: 1.1-1-INKERNEL"
+#define JSM_VERSION "jsm: 1.2-1-INKERNEL"
#define JSM_PARTNUM "40002438_A-INKERNEL"
struct jsm_board;
diff -Nuar linux-2.6.12.3.orig/drivers/serial/jsm/jsm_neo.c linux-2.6.12.3.new/drivers/serial/jsm/jsm_neo.c
--- linux-2.6.12.3.orig/drivers/serial/jsm/jsm_neo.c 2005-07-19 15:16:22.0 -0500
+++ linux-2.6.12.3.new/drivers/serial/jsm/jsm_neo.c 2005-07-19 15:19:00.0 -0500
@@ -22,6 +22,9 @@
* Scott H Kilau <[EMAIL PROTECTED]>
* Wendy Xiong <[EMAIL PROTECTED]>
*
+ * CHANGE LOG:
+ * Jul 18, 2005: separated the mixed declarations and code.
+ *
***/
#include /* For udelay */
#include /* For the various UART offsets */
@@ -48,8 +51,9 @@
static void neo_set_cts_flow_control(struct jsm_channel *ch)
{
- u8 ier = readb(>ch_neo_uart->ier);
- u8 efr = readb(>ch_neo_uart->efr);
+ u8 ier, efr;
+ ier = readb(>ch_neo_uart->ier);
+ efr = readb(>ch_neo_uart->efr);
jsm_printk(PARAM, INFO, >ch_bd->pci_dev, "Setting CTSFLOW\n");
@@ -78,8 +82,9 @@
static void neo_set_rts_flow_control(struct jsm_channel *ch)
{
- u8 ier = readb(>ch_neo_uart->ier);
- u8 efr = readb(>ch_neo_uart->efr);
+ u8 ier, efr;
+ ier = readb(>ch_neo_uart->ier);
+ efr = readb(>ch_neo_uart->efr);
jsm_printk(PARAM, INFO, >ch_bd->pci_dev, "Setting RTSFLOW\n");
@@ -117,8 +122,9 @@
static void neo_set_ixon_flow_control(struct jsm_channel *ch)
{
- u8 ier = readb(>ch_neo_uart->ier);
- u8 efr = readb(>ch_neo_uart->efr);
+ u8 ier, efr;
+ ier = readb(>ch_neo_uart->ier);
+ efr = readb(>ch_neo_uart->efr);
jsm_printk(PARAM, INFO, >ch_bd->pci_dev, "Setting IXON FLOW\n");
@@ -153,8 +159,9 @@
static void neo_set_ixoff_flow_control(struct jsm_channel *ch)
{
- u8 ier = readb(>ch_neo_uart->ier);
- u8 efr = readb(>ch_neo_uart->efr);
+ u8 ier, efr;
+ ier = readb(>ch_neo_uart->ier);
+ efr = readb(>ch_neo_uart->efr);
jsm_printk(PARAM, INFO, >ch_bd->pci_dev, "Setting IXOFF FLOW\n");
@@ -190,8 +197,9 @@
static void neo_set_no_input_flow_control(struct jsm_channel *ch)
{
- u8 ier = readb(>ch_neo_uart->ier);
- u8 efr = readb(>ch_neo_uart->efr);
+ u8 ier, efr;
+ ier = readb(>ch_neo_uart->ier);
+ efr = readb(>ch_neo_uart->efr);
jsm_printk(PARAM, INFO, >ch_bd->pci_dev, "Unsetting Input FLOW\n");
@@ -228,8 +236,9 @@
static void neo_set_no_output_flow_control(struct jsm_channel *ch)
{
- u8 ier = readb(>ch_neo_uart->ier);
- u8 efr = readb(>ch_neo_uart->efr);
+ u8 ier, efr;
+ ier = readb(>ch_neo_uart->ier);
+ efr = readb(>ch_neo_uart->efr);
jsm_printk(PARAM, INFO, >ch_bd->pci_dev, "Unsetting Output FLOW\n");
Re: Noob question. Why is the for-pentium4 kernel built with -march=i686 ?
>Hello, > >If I set the CPU type to be amd64 in kernel config, the kernel is built >with -march=k8. If I set it to be k6, the kernel is built with >-march=k6. If I set the CPU type to be Pentium4, the kernel is built >with -march=i686 -mtune=pentium4. Why is not the for-P4 kernel built >with -march=pentium4 ? >I tried building the kernel with -march=pentium4 for the sake of >experiment and got no ill effects. -march= specifies the instruction set, -mcpu= / -mtune= the tuning factor. Maybe it is that the instruction set is the same on i686 and pentium4. cmov for example is not present in k6, and k8 is something completely different at all. Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: files_lock deadlock?
> I noticed that files_lock is only protected with spin_lock() > (file_list_lock(), > include/linux/fs.h). Is it possible that this should be changed to > spin_lock_irq()) or spin_lock_irqsave()? Or am I misssing something obvious? I'm probably stabbing in the dark, but I've seen ipt_owner of netfilter to talk about spin_lock_bh() wrt. files->file_lock. Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: assignment of major number to serial driver -2.6.x kernels
>Hi All, > > I would like to know whether the usage of 253 as major (device) number >in serial port drivers is restricted in 2.6.x kernels. I am asking this >question, though the documentation tells the driver developers that 253 >is a reserved major number, 2.6.x Linux kernels can accommodate more >than 255. Majors 240 - 254 are reserved for private use, e.g. [EMAIL PROTECTED]; nothing to be seen in mainline drivers. As for majors >255, you should at best try :) The dev number handling is there - I am able to mknod blah c 1234 0. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Suddenly getting APIC errors on SMP system using 2.4.20-8smp, mobo dying?
>http://lkml.org/lkml/2003/5/18/64 (the problem we are having) >on it's way out. Try running with 'noapic' to see if it's the IOAPIC or >local APICs (my bet is on the IOAPIC which would be on your motherboard >chipset)" I have the same problem, throughout 2.6.11 to 2.6.13-rc1, maybe before. It pops up when CONFIG_ACPI=y (CONFIG_X86_UP_APIC,IO_APIC or UP_IO_APIC does not affect this!) && when my ISDN card is active, e.g. I'm online. If it's not online, everything is fine. APIC error on CPU0: 02(02) This only shows if I run `klogconsole -l8`, which means this message is printed with KERN_DEBUG. I do live on UP, though. Everytime I get this message, the ERR counter increases. lspci: :00:0a.0 Network controller: Tiger Jet Network Inc. Tiger3XX Modem/ISDN interface Need more info? Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Possible GPL violation by PQI
Precise name of the product: PQI mPack P800 The firmware uses a modified version of the Sigma Designs uClinux 2.4.17-uc0 kernel (available here: http://www.uclinux.org/pub/uClinux/ports/arm/EM8500/). In my previous encounters with similar devices, they have kept the portions of code that dealt with the EM85XX chipset in a seperate binary module loaded at run-time (this is the case with my Bravo D1). This is not the case with this firmware. All the EM85XX-specific modifications are embedded directly into the linux.bin kernel image, with no source available to reproduce the kernel. I contacted PQI a week ago through their "Contact Engineer" web form, but have received no response. How the license was violated: -copyright notice of the copyright holder is not preserved -source code is completely missing, requests for source code ignored -no written offer for source or copy of the license included Firmware can be downloaded here: http://www.pqi.com.tw/download.asp?filetype=3D5 The firmware is a modified romfs filesystem (it has a nonstandard header that you must strip before being able to use it with normal romfs tools). -Ryan Baumann (My apologies if this reaches the list multiple times, I tried sending this message from my GMail account but it never appeared on the list) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] [RFC] nodemanager, ocfs2, dlm
On Monday 18 July 2005 16:15, David Teigland wrote: > I've taken a stab at generalizing ocfs2_nodemanager so the dlm could use > it (removing ocfs-specific stuff). It still needs some work, but I'd > like to know if this appeals to the ocfs group and to others who were > interested in seeing some similarity in dlm/ocfs configuration. Let me get this straight. The proposal is to expose cluster membership as a virtual filesystem and use that as the primary membership interface? So that, e.g., a server on the cluster does a getdents to find out what nodes are in the cluster or uses inotify to learn about membership changes, instead of subscribing for and receiving membership events directly from the cluster membership manager? Or what is this about, just providing a nice friendly view of the cluster to the administrator, not intended to be used by cluster infrastructure components? Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Noob question. Why is the for-pentium4 kernel built with -march=i686 ?
Hello, If I set the CPU type to be amd64 in kernel config, the kernel is built with -march=k8. If I set it to be k6, the kernel is built with -march=k6. If I set the CPU type to be Pentium4, the kernel is built with -march=i686 -mtune=pentium4. Why is not the for-P4 kernel built with -march=pentium4 ? I tried building the kernel with -march=pentium4 for the sake of experiment and got no ill effects. Thanks, Ivan Yosifov. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFD] FAT robustness
> I'd like to have a discussion about FAT robustness. > Please give your thought, comments and related issues. What I would like is to treat completely differently writing to FAT (writing to a removeable drive) which need a complete "mount", and just reading quickly a file (a standard use of removeable devices). Basically, to read you would not need to mount the partition, just read /readfs/fd1 which uses two or three functions accessing /dev/fd1 in raw mode to read the filesystem descriptor and the root directory. Same for /readfs/cdrom and /readfs/sda4 (USB drive). The only cache would be the one provided by /dev/fd1 - a kind of mount read-only at each file opening. This system would be disabled if the partition is already mounted read/write somewhere - but as long as you do not try to write to a removeable disk you can extract it at any time. The two or three function I am talking of are located in Gujin "fs.c" file to access read-only FAT12/16/32, EXT2/3 and ISOFS ( http://gujin.org ). Just few kilobytes - and some source modifications for that use. Etienne. ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.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/
Weird USB errors on HD
I have a usb-attached HD that I use from time to time. When it's connected to my desktop through a hub it works flawlessly. When connected to my Dell D600 Laptop, however, it sometimes randomly exhibits a loud click (as if the heads went berzerk) and the device goes unrecognized (i.e. the USB layer drops the device and then redetects it again; meanwhile there is FS corruption.) The same behavior happens with 2.4.x and 2.6.x In /var/log/messages I see something like: hub 3-0:1.0: over-current change on port 1 hub 1-0:1.0: over-current change on port 3 ... usb 1-3: USB disconnect, address 2 usb 1-3: new high speed USB device using ehci_hcd and address 3 ... usb-storage: device found at 3 usb-storage: waiting for device to settle before scanning This doesn't seem too good. Here's the complete passage from /var/log/messages: SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 384296 SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 384296 SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 384296 SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 384296 EXT3-fs error (device sda): ext3_free_branches: Read failure, inode=1046532, block=48037 Aborting journal on device sda. SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 4176 printk: 813 messages suppressed. Buffer I/O error on device sda, logical block 522 lost page write due to I/O error on sda SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 lost page write due to I/O error on sda EXT3-fs error (device sda) in ext3_reserve_inode_write: Journal has aborted SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 lost page write due to I/O error on sda EXT3-fs error (device sda) in ext3_reserve_inode_write: Journal has aborted SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 lost page write due to I/O error on sda EXT3-fs error (device sda) in ext3_orphan_del: Journal has aborted SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 lost page write due to I/O error on sda EXT3-fs error (device sda) in ext3_truncate: Journal has aborted SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 lost page write due to I/O error on sda ext3_abort called. EXT3-fs error (device sda): ext3_journal_start_sb: Detected aborted journal Remounting filesystem read-only SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 3254080 hub 3-0:1.0: over-current change on port 1 hub 1-0:1.0: over-current change on port 3 SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 3254088 SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 3254096 SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 3254104 SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 3254088 SCSI error : <0 0 0 0> return code = 0x7 end_request: I/O error, dev sda, sector 3254088 usb 1-3: USB disconnect, address 2 scsi0 (0:0): rejecting I/O to device being removed Buffer I/O error on device sda, logical block 458754 lost page write due to I/O error on sda scsi0 (0:0): rejecting I/O to device being removed Buffer I/O error on device sda, logical block 517070 lost page write due to I/O error on sda scsi0 (0:0): rejecting I/O to device being removed Buffer I/O error on device sda, logical block 1 lost page write due to I/O error on sda scsi0 (0:0): rejecting I/O to device being removed Buffer I/O error on device sda, logical block 393218 lost page write due to I/O error on sda scsi0 (0:0): rejecting I/O to device being removed scsi0 (0:0): rejecting I/O to device being removed scsi0 (0:0): rejecting I/O to device being removed scsi0 (0:0): rejecting I/O to device being removed scsi0 (0:0): rejecting I/O to device being removed scsi0 (0:0): rejecting I/O to dead device EXT3-fs error (device sda): ext3_find_entry: reading directory #228929 offset 0 scsi0 (0:0): rejecting I/O to dead device EXT3-fs error (device sda): ext3_find_entry: reading directory #1046529 offset 0 usb 1-3: new high speed USB device using ehci_hcd and address 3 scsi1 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 3 usb-storage: waiting for device to settle before scanning scsi0 (0:0): rejecting I/O to dead device EXT3-fs error (device sda): ext3_find_entry: reading directory #196225 offset 0 scsi0 (0:0): rejecting I/O to dead device EXT3-fs error (device sda): ext3_find_entry: reading
[PATCH] fork support
Here's a patch to linux kernel to enable fork() support for infiniband uverbs (userspace i/o initiator). Please Cc me with comments. --- This patch adds PROT_DONTCOPY to mmap and mprotect, to set VM_DONTCOPY on vma. This is needed for infiniband userspace i/o, where we need to protect against - the child process accessing the parent hardware page - the parent registered address (on which the driver did get_user_pages) getting remapped to another page by COW One can imagine other uses, e.g. combined with mlock for real-time or security. Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]> Index: linux-2.6.12.2/include/asm-ppc64/mman.h === --- linux-2.6.12.2.orig/include/asm-ppc64/mman.h +++ linux-2.6.12.2/include/asm-ppc64/mman.h @@ -15,6 +15,7 @@ #define PROT_NONE 0x0 /* page can not be accessed */ #define PROT_GROWSDOWN 0x0100 /* mprotect flag: extend change to start of growsdown vma */ #define PROT_GROWSUP 0x0200 /* mprotect flag: extend change to end of growsup vma */ +#define PROT_DONTCOPY 0x0400 /* dont copy to child on fork */ #define MAP_SHARED 0x01/* Share changes */ #define MAP_PRIVATE0x02/* Changes are private */ Index: linux-2.6.12.2/include/asm-cris/mman.h === --- linux-2.6.12.2.orig/include/asm-cris/mman.h +++ linux-2.6.12.2/include/asm-cris/mman.h @@ -10,6 +10,7 @@ #define PROT_NONE 0x0 /* page can not be accessed */ #define PROT_GROWSDOWN 0x0100 /* mprotect flag: extend change to start of growsdown vma */ #define PROT_GROWSUP 0x0200 /* mprotect flag: extend change to end of growsup vma */ +#define PROT_DONTCOPY 0x0400 /* dont copy to child on fork */ #define MAP_SHARED 0x01/* Share changes */ #define MAP_PRIVATE0x02/* Changes are private */ Index: linux-2.6.12.2/include/asm-arm26/mman.h === --- linux-2.6.12.2.orig/include/asm-arm26/mman.h +++ linux-2.6.12.2/include/asm-arm26/mman.h @@ -8,6 +8,7 @@ #define PROT_NONE 0x0 /* page can not be accessed */ #define PROT_GROWSDOWN 0x0100 /* mprotect flag: extend change to start of growsdown vma */ #define PROT_GROWSUP 0x0200 /* mprotect flag: extend change to end of growsup vma */ +#define PROT_DONTCOPY 0x0400 /* dont copy to child on fork */ #define MAP_SHARED 0x01/* Share changes */ #define MAP_PRIVATE0x02/* Changes are private */ Index: linux-2.6.12.2/include/asm-alpha/mman.h === --- linux-2.6.12.2.orig/include/asm-alpha/mman.h +++ linux-2.6.12.2/include/asm-alpha/mman.h @@ -8,6 +8,7 @@ #define PROT_NONE 0x0 /* page can not be accessed */ #define PROT_GROWSDOWN 0x0100 /* mprotect flag: extend change to start of growsdown vma */ #define PROT_GROWSUP 0x0200 /* mprotect flag: extend change to end of growsup vma */ +#define PROT_DONTCOPY 0x0400 /* dont copy to child on fork */ #define MAP_SHARED 0x01/* Share changes */ #define MAP_PRIVATE0x02/* Changes are private */ Index: linux-2.6.12.2/include/asm-m68k/mman.h === --- linux-2.6.12.2.orig/include/asm-m68k/mman.h +++ linux-2.6.12.2/include/asm-m68k/mman.h @@ -8,6 +8,7 @@ #define PROT_NONE 0x0 /* page can not be accessed */ #define PROT_GROWSDOWN 0x0100 /* mprotect flag: extend change to start of growsdown vma */ #define PROT_GROWSUP 0x0200 /* mprotect flag: extend change to end of growsup vma */ +#define PROT_DONTCOPY 0x0400 /* dont copy to child on fork */ #define MAP_SHARED 0x01/* Share changes */ #define MAP_PRIVATE0x02/* Changes are private */ Index: linux-2.6.12.2/include/asm-mips/mman.h === --- linux-2.6.12.2.orig/include/asm-mips/mman.h +++ linux-2.6.12.2/include/asm-mips/mman.h @@ -22,6 +22,7 @@ #define PROT_SEM 0x10/* page may be used for atomic ops */ #define PROT_GROWSDOWN 0x0100 /* mprotect flag: extend change to start of growsdown vma */ #define PROT_GROWSUP 0x0200 /* mprotect flag: extend change to end of growsup vma */ +#define PROT_DONTCOPY 0x0400 /* dont copy to child on fork */ /* * Flags for mmap Index: linux-2.6.12.2/include/asm-sparc64/mman.h === --- linux-2.6.12.2.orig/include/asm-sparc64/mman.h +++ linux-2.6.12.2/include/asm-sparc64/mman.h @@ -11,6 +11,7 @@ #define PROT_NONE 0x0 /* page can not be accessed */ #define
files_lock deadlock?
Hello, I apologize in advance if this is a dummy question. My web search turned up nothing, so I'm trying it here. We came across the following error message: Kernelpanic - not syncing: fs/proc/ Generic.c:521: spin_lock(fs/file_table.c:80420280) Already locked by fs/file_table.c/204 This shows a locking problem with the files_lock on a UP kernel with spinlock debugging enabled. I noticed that files_lock is only protected with spin_lock() (file_list_lock(), include/linux/fs.h). Is it possible that this should be changed to spin_lock_irq()) or spin_lock_irqsave()? Or am I misssing something obvious? Thanks Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] sound drivers select'ing ISAPNP must depend on PNP && ISA
On Sun, Jul 17, 2005 at 05:07:48PM +0200, Bodo Eggert wrote: > In sound/isa/Kconfig, select ISAPNP and depend on ISAPNP are intermixed, > resulting in funny behaviour. (Soundcarts get selectable if other > soundcards are selected). > > This patch changes the "depend on ISAPNP"s to select. >... I like the idea of this patch, but it brings to more drivers to a violation of the "if you select something, you have to ensure that the dependencies of what you select are fulfilled" rule causing link errors with invalid .config's. This patch (on top of your patch) fixes this problem. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- sound/isa/Kconfig | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) --- linux-2.6.13-rc3-mm1-full/sound/isa/Kconfig.old 2005-07-19 18:27:21.0 +0200 +++ linux-2.6.13-rc3-mm1-full/sound/isa/Kconfig 2005-07-19 18:28:44.0 +0200 @@ -15,7 +15,7 @@ config SND_AD1816A tristate "Analog Devices SoundPort AD1816A" - depends on SND + depends on SND && PNP && ISA select ISAPNP select SND_OPL3_LIB select SND_MPU401_UART @@ -81,7 +81,7 @@ config SND_ES968 tristate "Generic ESS ES968 driver" - depends on SND + depends on SND && PNP && ISA select ISAPNP select SND_MPU401_UART select SND_PCM @@ -162,7 +162,7 @@ config SND_INTERWAVE tristate "AMD InterWave, Gravis UltraSound PnP" - depends on SND + depends on SND && PNP && ISA select SND_RAWMIDI select SND_CS4231_LIB select SND_GUS_SYNTH @@ -177,7 +177,7 @@ config SND_INTERWAVE_STB tristate "AMD InterWave + TEA6330T (UltraSound 32-Pro)" - depends on SND + depends on SND && PNP && ISA select SND_RAWMIDI select SND_CS4231_LIB select SND_GUS_SYNTH @@ -293,7 +293,7 @@ config SND_ALS100 tristate "Avance Logic ALS100/ALS120" - depends on SND + depends on SND && PNP && ISA select ISAPNP select SND_OPL3_LIB select SND_MPU401_UART @@ -307,7 +307,7 @@ config SND_AZT2320 tristate "Aztech Systems AZT2320" - depends on SND + depends on SND && PNP && ISA select ISAPNP select SND_OPL3_LIB select SND_MPU401_UART @@ -332,7 +332,7 @@ config SND_DT019X tristate "Diamond Technologies DT-019X, Avance Logic ALS-007" - depends on SND + depends on SND && PNP && ISA select ISAPNP select SND_OPL3_LIB select SND_MPU401_UART - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Ihre Mail an / Your message to : [EMAIL PROTECTED]
Folgende Nachricht wurde fuer Sie hinterlassen: Please find below a message for you: Escibi a [EMAIL PROTECTED] , esta direccion esta en desuso. Saludos Mariano -- +++ GMX - die erste Adresse für Mail, Message, More +++ e-mail und supergünstige DSL-Tarife unter http://www.gmx.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: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
On 2005-07-18T14:15:53, David Teigland <[EMAIL PROTECTED]> wrote: > Some of the comments about the dlm concerned how it's configured (from > user space.) In particular, there was interest in seeing the dlm and > ocfs2 use common methods for their configuration. > > The first area I'm looking at is how we get addresses/ids of other nodes. > Currently, the dlm uses an ioctl on a misc device and ocfs2 uses a > separate kernel module called "ocfs2_nodemanager" that's based on > configfs. > > I've taken a stab at generalizing ocfs2_nodemanager so the dlm could use > it (removing ocfs-specific stuff). It still needs some work, but I'd like > to know if this appeals to the ocfs group and to others who were > interested in seeing some similarity in dlm/ocfs configuration. Hi Dave, I finally found time to read through this. Yes, I most definetely like where this is going! > +/* TODO: > + - generic addresses (IPV4/6) > + - multiple addresses per node The nodeid, I thought, was relative to a given DLM namespace, no? This concept seems to be missing here, or are you suggesting the nodeid to be global across namespaces? Also, eventually we obviously need to have state for the nodes - up/down et cetera. I think the node manager also ought to track this. How would kernel components use this and be notified about changes to the configuration / membership state? Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci_find_device --> pci_get_device
Am Dienstag, 19. Juli 2005 17:44 schrieb Jiri Slaby:
>Rolf Eike Beer napsal(a):
>>Jiri Slaby wrote:
>>>Kernel version: 2.6.13-rc3-git4
>>>
>>>* This patch removes from kernel tree pci_find_device and changes
>>>it with pci_get_device. Next, it adds pci_dev_put, to decrease reference
>>>count of the variable.
>>>* Next, there are some (about 10 or so) gcc warning problems (i. e.
>>>variable may be unitialized) solutions, which were around code with old
>>>pci_find_device.
>>
>>Is this the reason why you initialize members of static structs? If this is
>>uninitialized it will end in the bss section and will be zeroed before the
>>kernel uses is. If you do it will go into data section and add more bloat
>> to the binary. At least this is the explanation I got once why not to do
>> this.
>
>I can't find now changes of initialization static variables, but i have
>deleted section
>dealing up with gcc warning from patch, it would go on a queue later.
Sorry, I misread the diff. That are static functions with the variables in
them, not static structs.
Your patch to arch/sparc64/kernel/ebus.c is broken, the removed and added
parts do not match in behaviour.
If you add braces after if's please add the '{' in the same line as the if
itself. This will make the diff bigger, but then this matches
Documentation/Coding-style.
Eike
pgpgUYjXrd3Ny.pgp
Description: PGP signature
Re: [2.6.12-git8] ACPI shutdown fails to power off machine
On Tuesday, 19 July 2005, at 04:41:26 -0600, Eric W. Biederman wrote: > Thanks. Before I forget I want to ack this. I think you are correct > and I have a hunch on what might be done to fix this but I haven't found > the couple of hours needed to handle that. > ACK. Just for the record, there seems to be several people out there with the same problem, and using different motherboards/BIOSes. Check: http://marc.theaimsgroup.com/?t=11214729101=1=2 Greetings, -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.13-rc2) signature.asc Description: Digital signature
Re: [PATCH] ramfs: pretend dirent sizes
On Tue, Jul 19, 2005 at 11:28:10AM +0200, Jan Blunck wrote: > I'm using the i_size of directories in my patches. When reading > from a union directory, I'm using the i_size to seek to the right > offset in the union stack. Ick. That'a a bit of a hack. > Therefore I need values of dirent->d_off which are smaller than the > i_size of the directory. Hence the value of 20 I guess --- assuming nothing will stack this high? > Altogether, it doesn't make sense to me to seek to an offset which > is greater than the i_size and let the dirent read succeed. I personally would prefer that to be honest or some other way that doesn't change i_size. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci_find_device --> pci_get_device
Rolf Eike Beer napsal(a): Jiri Slaby wrote: Kernel version: 2.6.13-rc3-git4 * This patch removes from kernel tree pci_find_device and changes it with pci_get_device. Next, it adds pci_dev_put, to decrease reference count of the variable. * Next, there are some (about 10 or so) gcc warning problems (i. e. variable may be unitialized) solutions, which were around code with old pci_find_device. Is this the reason why you initialize members of static structs? If this is uninitialized it will end in the bss section and will be zeroed before the kernel uses is. If you do it will go into data section and add more bloat to the binary. At least this is the explanation I got once why not to do this. I can't find now changes of initialization static variables, but i have deleted section dealing up with gcc warning from patch, it would go on a queue later. Many of the callers of pci_find_device() look like they are not ported to the 2.6 driver API and do the scanning for devices themself. I think it would be a good idea to try to convert them to the new driver model instead of replacing this. When you mark this deprecated and they still use the old function everyone using this will see that there is some work to do. I don't know now the difference between API accurately, but I'll study it in a few days and delete this sections from patch, alternatively rewrite the code. * Some code was unpretty, or ugly, so the patch provides more readable code, in some cases. If you try to beautify code then please use for_each_pci_dev() macro from include/linux/pci.h where possible. Done. When you want something of this getting included you have to split that into pieces. Use extra patches for changes in coding style and functionality. Yeah, the patch now provides only changes of pci_find problems. [Gcc will be discussed later, after doing more changes and completing patch against gcc 4, where are more warnings...] OK. The new patch is: http://www.fi.muni.cz/~xslaby/lnx/lnx-pci_find-2.6.13-r3g4_1.patch and bzipped http://www.fi.muni.cz/~xslaby/lnx/lnx-pci_find-2.6.13-r3g4_1.patch.bz2 [Kernel version is the same (2.6.13-rc3-git4)] And the patch now contains only: * This patch removes from kernel tree pci_find_device and changes it with pci_get_device. Next, it adds pci_dev_put, to decrease reference count of the variable. * Some code was unpretty, or ugly, so the patch provides more readable code, in some cases. * Marks the function (pci_find_device) as deprecated in pci.h -- Jiri Slaby www.fi.muni.cz/~xslaby ~\-/~ [EMAIL PROTECTED] ~\-/~ 241B347EC88228DE51EE A49C4A73A25004CB2A10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
tx queue start entry x dirty entry y (was 8139too PCI IRQ issues)
Hi, I'm getting similar results to Nick Warne, in that when my ethernet is stressed at all (for instance by NFS), I end up with nfs: server. not responding, still trying nfs: server OK With a realtec card, I get errors in /var/spool/messages along the lines of: Jul 3 14:31:13 localhost kernel: eth1: Transmit timeout, status 0c 0005 c07f media 00. Jul 3 14:31:13 localhost kernel: eth1: Tx queue start entry 1160 dirty entry 1156. Jul 3 14:31:13 localhost kernel: eth1: Tx descriptor 0 is 0008a03c. (queue head) I have no TPM (as far as I can find) Hence I dont think this is the same problem, but it's manifestation is identical. I was using a realtec card, using the 8139too driver, hence I first suspected that. As a test, I have an even older 3com509B, using that gives exactly the same results (though it doens't seem to be kind enough to output anything to /var/log/debug, so all you get are the "server not responding" messages under heavy NFS load. lsmod however, shows both modules loaded I'm running debian, and recently got a recent kernel image /proc/version gives: Linux version 2.6.11-1-386 ([EMAIL PROTECTED]) (gcc version 3.3.6 (Debian 1:3.3.6-6)) #1 Mon Jun 20 20:53:17 MDT 2005 Im not a kernel expert at all, any help sorting this problem would be appreciated, but Its only worth fixing if it's a general problem -- if' I'm on my own, I'll fix it with a band-aid :-) Cheers Mark. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Re: RFC: IOMMU bypass
Hi again,
On Fri, 15 Jul 2005 13:09:33 +1000 Stephen Rothwell <[EMAIL PROTECTED]> wrote:
>
> We (Anton Blanchard and others) have been trying to figure out the best
> (or any) way to allow for IOMMU bypass when setting up DMA mappings on
> particular devices. Our current idea is to hang a structure of pointers
> to DMA mapping operations off the struct device and inherit it from the
> device's parent. This would allow for per-bus (rather than per-bus_type)
> mapping operations and also allow a driver to override the bus's
> operations for a particular device.
>
> Does this make sense? Comments (hopefully consructive) please.
>
> Is there a better/simpler/more sensible way to do this?
Just to give you all something concrete to attack^Wcomment on, here is a
preliminary patch with the generic work and PPC64 converted. It actually
helps ppc64 more than some others because we already have two different
"busses": pci and vio.
This has been built on both pSeries and iSeries ppc64 but not tested, yet.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
diff -ruN linus/arch/ppc64/kernel/Makefile
linus-dma_bypass.3/arch/ppc64/kernel/Makefile
--- linus/arch/ppc64/kernel/Makefile2005-06-27 16:08:00.0 +1000
+++ linus-dma_bypass.3/arch/ppc64/kernel/Makefile 2005-06-27
17:41:10.0 +1000
@@ -5,7 +5,7 @@
EXTRA_CFLAGS += -mno-minimal-toc
extra-y:= head.o vmlinux.lds
-obj-y := setup.o entry.o traps.o irq.o idle.o dma.o \
+obj-y := setup.o entry.o traps.o irq.o idle.o \
time.o process.o signal.o syscalls.o misc.o ptrace.o \
align.o semaphore.o bitops.o pacaData.o \
udbg.o binfmt_elf32.o sys_ppc32.o ioctl32.o \
diff -ruN linus/arch/ppc64/kernel/bpa_iommu.c
linus-dma_bypass.3/arch/ppc64/kernel/bpa_iommu.c
--- linus/arch/ppc64/kernel/bpa_iommu.c 2005-06-27 16:08:00.0 +1000
+++ linus-dma_bypass.3/arch/ppc64/kernel/bpa_iommu.c2005-07-19
14:25:11.0 +1000
@@ -359,6 +359,11 @@
return mask < 0x1ull;
}
+static int bpa_direct_set_dma_mask(struct device *dev, u64 mask)
+{
+ return pci_set_dma_mask(to_pci_dev(dev), mask);
+}
+
void bpa_init_iommu(void)
{
bpa_map_iommu();
@@ -374,4 +379,5 @@
pci_dma_ops.map_sg = bpa_map_sg;
pci_dma_ops.unmap_sg = bpa_unmap_sg;
pci_dma_ops.dma_supported = bpa_dma_supported;
+ pci_dma_ops.set_dma_mask = bpa_set_dma_mask;
}
diff -ruN linus/arch/ppc64/kernel/dma.c
linus-dma_bypass.3/arch/ppc64/kernel/dma.c
--- linus/arch/ppc64/kernel/dma.c 2005-06-27 16:08:00.0 +1000
+++ linus-dma_bypass.3/arch/ppc64/kernel/dma.c 1970-01-01 10:00:00.0
+1000
@@ -1,151 +0,0 @@
-/*
- * Copyright (C) 2004 IBM Corporation
- *
- * Implements the generic device dma API for ppc64. Handles
- * the pci and vio busses
- */
-
-#include
-#include
-/* Include the busses we support */
-#include
-#include
-#include
-#include
-
-static struct dma_mapping_ops *get_dma_ops(struct device *dev)
-{
-#ifdef CONFIG_PCI
- if (dev->bus == _bus_type)
- return _dma_ops;
-#endif
-#ifdef CONFIG_IBMVIO
- if (dev->bus == _bus_type)
- return _dma_ops;
-#endif
- return NULL;
-}
-
-int dma_supported(struct device *dev, u64 mask)
-{
- struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
-
- if (dma_ops)
- return dma_ops->dma_supported(dev, mask);
- BUG();
- return 0;
-}
-EXPORT_SYMBOL(dma_supported);
-
-int dma_set_mask(struct device *dev, u64 dma_mask)
-{
-#ifdef CONFIG_PCI
- if (dev->bus == _bus_type)
- return pci_set_dma_mask(to_pci_dev(dev), dma_mask);
-#endif
-#ifdef CONFIG_IBMVIO
- if (dev->bus == _bus_type)
- return -EIO;
-#endif /* CONFIG_IBMVIO */
- BUG();
- return 0;
-}
-EXPORT_SYMBOL(dma_set_mask);
-
-void *dma_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t *dma_handle, unsigned int __nocast flag)
-{
- struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
-
- if (dma_ops)
- return dma_ops->alloc_coherent(dev, size, dma_handle, flag);
- BUG();
- return NULL;
-}
-EXPORT_SYMBOL(dma_alloc_coherent);
-
-void dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
- dma_addr_t dma_handle)
-{
- struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
-
- if (dma_ops)
- dma_ops->free_coherent(dev, size, cpu_addr, dma_handle);
- else
- BUG();
-}
-EXPORT_SYMBOL(dma_free_coherent);
-
-dma_addr_t dma_map_single(struct device *dev, void *cpu_addr, size_t size,
- enum dma_data_direction direction)
-{
- struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
-
- if (dma_ops)
- return dma_ops->map_single(dev, cpu_addr, size, direction);
- BUG();
Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help
Hi again, I have scanned IHC errata for this Rocky stuff. First, lspi -vvv said that Rocky has 82820. Hmm... I have a phy look at the card and see 82801. OK. I went to the Intel site, and downloaded the spec updates for it. http://www.intel.com/design/chipsets/mobile/documentation845.htm#specupdates Intel (R) 82801CAM I/O Controller Hub 3 (ICH3-M) Specification Update -- -- -- Errata 22. IDE Hang Issue Problem: An arbitration deadlock in the ICH3-M may occur if IDE traffic is combined with heavy graphic traffic and internal/external PCI Bus Master traffic to memory. Implication: This issue may lockup the IDE bus master causing a system hang. This issue was found during ongoing internal validation using a synthetic test environment and there have been no failures reported by customers. Workaround: BIOS needs to set configuration register (Device 31, Function 0, offset FCh, bit 23) to prevent the arbitration deadlock. Contact your local Intel Field representative if you require more detailed BIOS workaround information. -- -- -- Errata 24. DWORD I/O Cycle Native Mode IDE Issue Problem: An I/O read crossing a DWORD boundary being sent from processor to the ICH3-M may not complete correctly. The ICH3-M will treat such a transaction as two single DWORD I/O accesses. If native mode IDE addressing is enabled, the ICH3-M will return the first I/O cycle completion request to the MCH but the second I/O cycle may get decoded to the IDE controller instead of its intended address. Implication: System may hang while processor waits for return of I/O cycle. Workaround: Disable Native Mode IDE in BIOS. See ICH3-M BIOS Specification Update for more details. -- -- -- There are A LOT of other issues, but the aboves may be relevant. I am going to try them. Can you guide me where can I place the mentioned workarounds? Also - how can I check that we are REALLY facing this chipset? Are the PCI ID's enough? (btw. lspci makes me fool) Also, disabling IDE DMA caused an other side effect. At a Poisson distributed moment - my interrupt from the SGA155D simply can not get thru. It is a known issue for me. SGA1GED dual gigabit ethernet (monitor) card produced the same on a brand new PC (blue lights from the power supply, etc... :-). Since the chipset is so new - no IDE DMA in 2.4.18 for this. It is not a real problem since we have a 3ware raid in place. Now it is 14 days up, and cca. 160 Giga of headers were captured. (students are on their holliday - that is why so few data) The workaround was QED. The capture task reads AMCC S5933 when the IT count is stalled for a while. That rearms the IT logic - and the show goes on. Unfortunatelly, for the POS stuff this trick cannot be used. Precise timing for TX schedule is vital. So I have to dig further. Best regards Gyuri - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Realtime Preemption, 2.6.12, Beginners Guide?
On Tuesday 19 July 2005 09:57, Ingo Molnar wrote: >* Karsten Wiese <[EMAIL PROTECTED]> wrote: >> > Found another error: >> > the ioapic cache isn't fully initialized in -51-31's >> > ioapic_cache_init(). >> >> and another: some NULL-pointers are used in -51-31 instead of >> ioapic_data[0]. Please apply attached patch on top of -51-31. It >> includes yesterday's fix. > >thanks, i've applied it and released -32. And this fixed ntpd (in mode 4) right up. But now Im seeing some fussing from Xprint when its started, from my logs: Jul 19 10:59:58 coyote rc: Starting xprint: succeeded Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 Jul 19 10:59:59 coyote Xprt_33: lpstat: Unable to connect to server: Connection refused Jul 19 10:59:59 coyote Xprt_33: No matching visual for __GLcontextMode with visual class = 0 (32775), nplanes = 8 Jul 19 11:00:00 coyote kernel: set_rtc_mmss: can't update from 7 to 59 The font path stuff I snipped has been there since forever. And, I didn't get the set_rtc_mmss messages when I did a service xprint restart. Is this even connected to Xprint, that looks like something from maybe ntp? And of course in mode 4, tvtime has a blue screen. But you knew that. :) > Ingo >- >To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] FAT robustness
Hiroyuki Machida <[EMAIL PROTECTED]> writes: > We currently plan to add following features to address FAT corruption. > > - Utilize standard 2.6 features as much as possible > - Implement as options of fat, vfat and uvfat What is the uvfat? typo (xvfat)? Why is this an option (does it have the big demerit)? > - Utilize noop elevator to cancel unexpected operation reordering Why don't you use the barrier? > - Coordinate order of operations so that update data first, meta >data later with transaction control Is this meaning the SoftUpdates? What does this guarantee? How does this handle the rename(), and cyclic dependency of updates? > - With O_SYNC, close() make flush all related data and >meta-data, then wait completion of I/O What is this meaning? Why does O_SYNC only flush at close()? Almost things in your email is needing the detail. I'm thinking the SoftUpdates is best solution for now. Could you tell the detail of your solution? -- OGAWA Hirofumi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
