Re: [Linux-cluster] Re: GFS, what's remaining
On Sat, Sep 03, 2005 at 02:42:36AM -0400, Daniel Phillips wrote: > On Friday 02 September 2005 20:16, Mark Fasheh wrote: > > As far as userspace dlm apis go, dlmfs already abstracts away a large part > > of the dlm interaction... > > Dumb question, why can't you use sysfs for this instead of rolling your own? because it's totally different. have a look at what it does. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > The main sticking point with FUSE remains the permission tricks around > > fuse_allow_task(). AFAIK it remains the case that nobody has come up with > > any better idea, so I'm inclined to merge the thing. > > Do you promise? I troll. What others think matters. But at this stage, objections would need to be substantial, IMO. We're rather deadlocked on the permission thing, but if we can't come up with anything better then I'm inclined to say what-the-hell. > I can do a resplit and submit to Linus, if that takes > some load off you. Nah, then I'd just have to check that everything is the same. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
On Fri Sep 02, 2005 at 10:53:19PM -0700, H. Peter Anvin wrote: > Erik Andersen wrote: > >On Fri Sep 02, 2005 at 10:22:20PM -0700, H. Peter Anvin wrote: > > > >>Exportable types need to be double-underscore types, because the header > >>files in user space that would include them can generally not include > >>. > > > > > >I'm not talking about kernel headers that have to worry about > >eventually being included in user space headers. Those nearly > >all live in include/asm. I'm talking about the kernel headers > >that define how userspace is supposed to interface with > >particular kernel drivers or hardware. Headers such as > >linux/cdrom.h and linux/loop.h and linux/fb.h. > > > > What are you going to do with them if you're not going to include them > in userspace?!!! > > If you're proposing one policy for linux/loop.h and one for sys/stat.h, > I would have to classify that as insane. Everything that gets exported > to userspace should behave the same way, please. That is certainly not what I was proposing. Why are you bringing sys/stat.h into this? The contents of sys/stat.h are entirely up to SUSv3 and the C library to worry about. Nobody has proposed mucking with that. I dunno about your C library, but mine doesn't include linux/* header files (not even sys/stat.h). And I'd really like to fix uClibc to not use any asm/* either, since much of it is entirely unsuitable for user space. I am proposing a single consistant policy for all of linux/* such that all linux/* headers that need integer types of a specific size shall #include unistd.h and use ISO C99 types rather that the ad-hoc kernel types they now use. The policy has _long_ been that user space must never include linux/* header files. Since we are now proposing a project to reverse this policy, the long standing policy making linux/* verboten now leaves us completely free to do pretty much anything with linux/*. And what I want is for linux/* to use the shiny ISO C99 types. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GFS, what's remaining
On Friday 02 September 2005 20:16, Mark Fasheh wrote: > As far as userspace dlm apis go, dlmfs already abstracts away a large part > of the dlm interaction... Dumb question, why can't you use sysfs for this instead of rolling your own? Side note: you seem to have deleted all the 2.6.12-rc4 patches. Perhaps you forgot that there are dozens of lkml archives pointing at them? Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hotswap support for libata
Lukasz Kosewski wrote: On a happier note, once the infrastructure is accepted, anyone with a hotswap-unsupported controller and some time on their hands will easily be able to integrate hotswap in; that is the whole goal of an infrastructure. So if your controller isn't supported, but you know something about it (or better yet, you yourself have docs), adding hotswap support to it should be too hard. Once the infrastructure is there, I'll probably add support for several controllers myself. Many controllers don't have an explicit hotplug interrupt, but rather we must examine the PhyRdy bit in the standard SError register for details. If the bit's state changes in any way (including two or more state changes), we (a) check for device presence, and (b) if device is present, initialize it (SET FEATURES - XFER MODE, etc.). Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GFS, what's remaining
On Saturday 03 September 2005 02:14, Arjan van de Ven wrote: > On Sat, 2005-09-03 at 13:18 +0800, David Teigland wrote: > > On Thu, Sep 01, 2005 at 01:21:04PM -0700, Andrew Morton wrote: > > > Alan Cox <[EMAIL PROTECTED]> wrote: > > > > > - Why GFS is better than OCFS2, or has functionality which > > > > > OCFS2 cannot possibly gain (or vice versa) > > > > > > > > > > - Relative merits of the two offerings > > > > > > > > You missed the important one - people actively use it and > > > > have been for some years. Same reason with have NTFS, HPFS, > > > > and all the others. On that alone it makes sense to include. > > > > > > Again, that's not a technical reason. It's _a_ reason, sure. > > > But what are the technical reasons for merging gfs[2], ocfs2, > > > both or neither? > > > > > > If one can be grown to encompass the capabilities of the other > > > then we're left with a bunch of legacy code and wasted effort. > > > > GFS is an established fs, it's not going away, you'd be hard > > pressed to find a more widely used cluster fs on Linux. GFS is > > about 10 years old and has been in use by customers in production > > environments for about 5 years. > > but you submitted GFS2 not GFS. I'd rather not step into the middle of this mess, but you clipped out a good portion that explains why he talks about GFS when he submitted GFS2. Let me quote the post you've pulled that partial paragraph from: "The latest development cycle (GFS2) has focused on improving performance, it's not a new file system -- the "2" indicates that it's not ondisk compatible with earlier versions." In other words he didn't submit the original, but the new version of it that is not compatable with the original GFS on disk format. While it is clear that GFS2 cannot claim the large installed user base or the proven capacity of the original (it is, after all, a new version that has incompatabilities) it can claim that as it's heritage and what it's aiming towards, the same as ext3 can (and does) claim the power and reliability of ext2. In this case I've been following this thread just for the hell of it and I've noticed that there are some people who seem to not want to even think of having GFS2 included in a mainline kernel for personal and not technical reasons. That does not describe most of the people on this list, many of whom have helped debug the code (among other things), but it does describe a few. I'll go back to being quiet now... DRH 0xA6992F96300F159086FF28208F8280BB8B00C32A.asc Description: application/pgp-keys pgp0QhxWOkyt5.pgp Description: PGP signature
Re: Hotswap support for libata
On a happier note, once the infrastructure is accepted, anyone with a hotswap-unsupported controller and some time on their hands will easily be able to integrate hotswap in; that is the whole goal of an infrastructure. So if your controller isn't supported, but you know something about it (or better yet, you yourself have docs), adding hotswap support to it should be too hard. Luke Kosewski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hotswap support for libata
On 9/2/05, Ravi Wijayaratne <[EMAIL PROTECTED]> wrote: > I was wandering whether you could direct me to > a place where I could find the most up to date > patches for libata hotplug support you authored. > > Has Jeff Garzik decided to integrate this code > to 2.6 libata ? Hey Ravi, You are on the money in one way; it's September, and I promised everyone I'd work on it come September. However, this is a loose timeline; specifically, I'll be available to work on them come the 6th of this month. So expect some more activity then :) First of all let me clarify something though; these patches are two parts: - a libata hotswap infrastructure that allows a driver which understands and properly handles hotplug interrupts to hotswap drives. - a specific implementation of this infrastructure in the Promise SATA150 and SATAII150 line of controllers. I've been getting quite a few emails offline from people excited with being able to arbitrarily hotswap all Serial ATA drives, and I should point out that unless people with the other controllers types (ie. nForce controllers, Sil controllers, etc.) actually add support for capturing hotswap interrupts and use the hotswap infrastructure, they will still not support hotplug. If you send me a controller and the docs for it, I will add the support and test the b'jesus out of it, but otherwise only the Promise controllers will have this support. Here's the current status for all to see: - I submitted initial patches near the end of July, which were heavily tested on UP machines and Promise SATA150/SATAII150 Tx4/Tx2 Plus controllers. They mostly work. - Jeff suggested some improvements that would make them work better, and these improvements work better for a general infrastructure (as opposed to a sata_promise-centric one). - I sent in patches implementing the improvements on the 1st of August. They weren't tested at all because I didn't have access to the hardware at that time, but I wanted some feedback. Those patches DO NOT WORK, however, they are very close to what I want (I need to add a workqueue and streamline error-handling a bit more). - Come the 6th, I'm going to a location where I'll have access to the controller, as well as UP boxes and an SMP box. So you can expect new patches, say, by the 10th or 11th that should be well tested and robust on UP and SMP machines for Jeff's perusal. So, if you really want hotswap now now now, you'll have to download my patches and fiddle with them. They're available in the kernel mailing list archives, if you search for 'hotswap libata', they will come up. Otherwise, I ask you to be patient for another wek or so and the good stuff will fall from the sky. Cheers, Luke Kosewski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm1: hangs during boot ...
Brown, Len wrote: Brown, Len wrote: [ 279.662960] [] wait_for_completion+0xa4/0x110 possibly a missing interrupt? CONFIG_ACPI=y any difference if booted with "acpi=off" or "acpi=noirq"? Yes. In both cases, the system appears to boot normally but I'm unable to login or connect via ssh. Also there's a "device not ready" message after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh. Please confirm that vanilla 2.6.13 has none of these symptoms. That's correct. 2.6.13 exhibits none of these symptoms. Please apply just the ACPI part of the 2.6.13-mm1 patch to see if these issues are caused by that or if they are caused by something else in the mm patch. http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/broken-out/git-acpi.patch OK. I'll get back to you shortly. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dynticks - implement no idle hz for x86
On Sat, 3 Sep 2005 02:56, Russell King wrote: > On Sat, Sep 03, 2005 at 01:43:57AM +1000, Con Kolivas wrote: > > Ok I've resynced all the patches with 2.6.13-mm1, made some cleanups and > > minor modifications. As pm timer is the only supported timer for dynticks > > I've also made it depend on it. > > > > A rollup patch against 2.6.13-mm1 is here: > > > > http://ck.kolivas.org/patches/dyn-ticks/2.6.13-mm1-dtck1.patch > > > > also available in the dyn-ticks directory are the older patches and these > > split out patches posted here. > > Are you guys going to sync your interfaces with what ARM has, or are > we going to have two differing dyntick interfaces in the kernel, one > for ARM and one for x86? > > I mentioned this before. I seem to be ignored. RMK Noone's ignoring you. What we need to do is ensure that dynamic ticks is working properly on x86 and worth including before anything else. If and when we confirm this it makes sense only then to try and merge code from the other 2 architectures to as much common code as possible as no doubt we'll be modifying other architectures we're less familiar with. At that stage we will definitely want to tread even more cautiously at that stage. 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: GFS, what's remaining
On Sat, 2005-09-03 at 13:18 +0800, David Teigland wrote: > On Thu, Sep 01, 2005 at 01:21:04PM -0700, Andrew Morton wrote: > > Alan Cox <[EMAIL PROTECTED]> wrote: > > > > - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot > > > > possibly gain (or vice versa) > > > > > > > > - Relative merits of the two offerings > > > > > > You missed the important one - people actively use it and have been for > > > some years. Same reason with have NTFS, HPFS, and all the others. On > > > that alone it makes sense to include. > > > > Again, that's not a technical reason. It's _a_ reason, sure. But what are > > the technical reasons for merging gfs[2], ocfs2, both or neither? > > > > If one can be grown to encompass the capabilities of the other then we're > > left with a bunch of legacy code and wasted effort. > > GFS is an established fs, it's not going away, you'd be hard pressed to > find a more widely used cluster fs on Linux. GFS is about 10 years old > and has been in use by customers in production environments for about 5 > years. but you submitted GFS2 not GFS. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
On Sep 3, 2005, at 01:57:26, H. Peter Anvin wrote: Kyle Moffett wrote: The world would be so much nicer a place if user space were free to #include linux/* header files rather than keeping a per-project private copy of all kernel structs of interest. Exactly! This is why I want to create kcore/* and kabi/* that define the appropriate types, then both userspace and the kernel could use whatever types fit their fancy, defined in terms of the __kcore_ and __kabi_ types, which could be _depended_ on to exist because they are guaranteed not to conflict with other namespaces Agreed. We should use well-defined namespaces that won't conflict. However, I think the __[us][0-9]+ namespace can be considered well-established. True, however, IMNSHO it would be much better if the kcore/kabi stuff had a _consistent_ namespace as well. If every macro begins with "__KABI_" and every type and function with "__kabi_" (With a few function-like macro exceptions, of course), then it is trivial to see where it originally came from and provides a standard naming scheme that external parties can kind of rely upon. It also means there are fewer exceptions to remember when coding. My thought for the __[us][0-9]+ types is that they should still be defined in linux/types.h for compatibility (outside of __KERNEL__) and based off the __kabi_* types. Cheers, Kyle Moffett -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
Kyle Moffett wrote: The world would be so much nicer a place if user space were free to #include linux/* header files rather than keeping a per-project private copy of all kernel structs of interest. Exactly! This is why I want to create kcore/* and kabi/* that define the appropriate types, then both userspace and the kernel could use whatever types fit their fancy, defined in terms of the __kcore_ and __kabi_ types, which could be _depended_ on to exist because they are guaranteed not to conflict with other namespaces Agreed. We should use well-defined namespaces that won't conflict. However, I think the __[us][0-9]+ namespace can be considered well-established. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
Erik Andersen wrote: On Fri Sep 02, 2005 at 10:22:20PM -0700, H. Peter Anvin wrote: Exportable types need to be double-underscore types, because the header files in user space that would include them can generally not include . I'm not talking about kernel headers that have to worry about eventually being included in user space headers. Those nearly all live in include/asm. I'm talking about the kernel headers that define how userspace is supposed to interface with particular kernel drivers or hardware. Headers such as linux/cdrom.h and linux/loop.h and linux/fb.h. What are you going to do with them if you're not going to include them in userspace?!!! If you're proposing one policy for linux/loop.h and one for sys/stat.h, I would have to classify that as insane. Everything that gets exported to userspace should behave the same way, please. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GFS, what's remaining
On Friday 02 September 2005 17:17, Andi Kleen wrote: > The only thing that should be probably resolved is a common API > for at least the clustered lock manager. Having multiple > incompatible user space APIs for that would be sad. The only current users of dlms are cluster filesystems. There are zero users of the userspace dlm api. Therefore, the (g)dlm userspace interface actually has nothing to do with the needs of gfs. It should be taken out the gfs patch and merged later, when or if user space applications emerge that need it. Maybe in the meantime it will be possible to come up with a userspace dlm api that isn't completely repulsive. Also, note that the only reason the two current dlms are in-kernel is because it supposedly cuts down on userspace-kernel communication with the cluster filesystems. Then why should a userspace application bother with a an awkward interface to an in-kernel dlm? This is obviously suboptimal. Why not have a userspace dlm for userspace apps, if indeed there are any userspace apps that would need to use dlm-style synchronization instead of more typical socket-based synchronization, or Posix locking, which is already exposed via a standard api? There is actually nothing wrong with having multiple, completely different dlms active at the same time. There is no urgent need to merge them into the one true dlm. It would be a lot better to let them evolve separately and pick the winner a year or two from now. Just think of the dlm as part of the cfs until then. What does have to be resolved is a common API for node management. It is not just cluster filesystems and their lock managers that have to interface to node management. Below the filesystem layer, cluster block devices and cluster volume management need to be coordinated by the same system, and above the filesystem layer, applications also need to be hooked into it. This work is, in a word, incomplete. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
On Sep 3, 2005, at 00:28:59, Erik Andersen wrote: Absolutely not. This would be a POSIX namespace violation; they *must* use double-underscore types. I assume you are worried about the stuff under asm that ends up being included by nearly every header file in the world. Of course asm must use double-underscore types. But the thing is, the vast majority of the kernel headers live under linux/include/linux/ and do not use double-underscore types, they use kernel specific, non-underscored types such as s8, u32, etc. My copy of IEEE 1003.1 and my copy of ISO/IEC 9899:1999 both fail to prohibit using the shiny new ISO C99 type for the various #include header files, which is what I was suggesting. Anything in linux/* that is included by userspace should not presume that stdint.h has already been included or include it on its own, because the userspace program may have already made its own definitions of uint32_t, or it may not want them defined at all. The world would be so much nicer a place if user space were free to #include linux/* header files rather than keeping a per-project private copy of all kernel structs of interest. Exactly! This is why I want to create kcore/* and kabi/* that define the appropriate types, then both userspace and the kernel could use whatever types fit their fancy, defined in terms of the __kcore_ and __kabi_ types, which could be _depended_ on to exist because they are guaranteed not to conflict with other namespaces Cheers, Kyle Moffett -- I have yet to see any problem, however complicated, which, when you looked at it in the right way, did not become still more complicated. -- Poul Anderson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
On Fri Sep 02, 2005 at 10:22:20PM -0700, H. Peter Anvin wrote: > Exportable types need to be double-underscore types, because the header > files in user space that would include them can generally not include > . I'm not talking about kernel headers that have to worry about eventually being included in user space headers. Those nearly all live in include/asm. I'm talking about the kernel headers that define how userspace is supposed to interface with particular kernel drivers or hardware. Headers such as linux/cdrom.h and linux/loop.h and linux/fb.h. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.13-mm1: hangs during boot ...
>Brown, Len wrote: [ 279.662960] [] wait_for_completion+0xa4/0x110 >> >> >> possibly a missing interrupt? >> >> >>>CONFIG_ACPI=y >> >> >> any difference if booted with "acpi=off" or "acpi=noirq"? > >Yes. In both cases, the system appears to boot normally but >I'm unable >to login or connect via ssh. Also there's a "device not >ready" message >after the scsi initialization which I don't normally see. >I've attached >the scsi initialization output. The PF_NETLINK error messages >after the >login prompt in this output are created whenever I try to log in or >connect via ssh. Please confirm that vanilla 2.6.13 has none of these symptoms. Please apply just the ACPI part of the 2.6.13-mm1 patch to see if these issues are caused by that or if they are caused by something else in the mm patch. http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/broken-out/git-acpi.patch thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GFS, what's remaining
On Fri, Sep 02, 2005 at 05:44:03PM +0800, David Teigland wrote:
> On Thu, Sep 01, 2005 at 01:35:23PM +0200, Arjan van de Ven wrote:
>
> > + gfs2_assert(gl->gl_sbd, atomic_read(&gl->gl_count) > 0,);
>
> > what is gfs2_assert() about anyway? please just use BUG_ON directly
> > everywhere
>
> When a machine has many gfs file systems mounted at once it can be useful
> to know which one failed. Does the following look ok?
>
> #define gfs2_assert(sdp, assertion) \
> do { \
> if (unlikely(!(assertion))) { \
> printk(KERN_ERR \
> "GFS2: fsid=%s: fatal: assertion \"%s\" failed\n" \
> "GFS2: fsid=%s: function = %s\n"\
> "GFS2: fsid=%s: file = %s, line = %u\n" \
> "GFS2: fsid=%s: time = %lu\n", \
> sdp->sd_fsname, # assertion, \
> sdp->sd_fsname, __FUNCTION__,\
> sdp->sd_fsname, __FILE__, __LINE__, \
> sdp->sd_fsname, get_seconds()); \
> BUG();\
You will already get the __FUNCTION__ (and hence the __FILE__ info)
directly from the BUG() dump, as well as the time from the syslog
message (turn on the printk timestamps if you want a more fine grain
timestamp), so the majority of this macro is redundant with the BUG()
macro...
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: SysFS, module names and .name
On Sat, Sep 03, 2005 at 12:17:57AM +0200, iSteve wrote: > Yes, I am rather interested -- could you please provide details about > this method? For PCI drivers, just add the line: .owner = THIS_MODULE, to their struct pci_driver definition and you will get the symlink created for you. USB drivers already do this. Hope this helps, 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: FUSE merging?
> Haven't thought about it all much. Have spent most of my time in the last > month admiring the contents of kernel bugzilla, and the ongoing attempts to > increase them. A penal system could be created, for example if someone is caught introducing a bug, he will have to choose three additional reports from bugzilla and analyze/fix them ;) > > - number of language bindings: 7 (native: C, java, python, perl, > > - C#, sh, TCL) 8 now, someone just sent a private mail about bindings for the Pliant (never heard of it) language. > I agree that lots of people would like the functionality. I regret that > although it appears that v9fs could provide it, I think you are wrong there. You don't appreciate all the complexity FUSE _lacks_ by not being network transparent. Just look at the error text to errno conversion muck that v9fs has. And their problems with trying to do generic uid/gid mappings. > there seems to be no interest in working on that. It would mean adding a plethora of extensions to the 9P protocol, that would take away all it's beauty. I think you should realize that these are different interfaces for different purposes. There may be some overlap, but not enough to warrant trying to massage them into one big ball. > The main sticking point with FUSE remains the permission tricks around > fuse_allow_task(). AFAIK it remains the case that nobody has come up with > any better idea, so I'm inclined to merge the thing. Do you promise? I can do a resplit and submit to Linus, if that takes some load off you. Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Updated dynamic tick patches - Fix lost tick calculation in timer_pm.c
On Sat, 2005-09-03 at 01:15 -0400, Parag Warudkar wrote: > Lee Revell wrote: > > > Are lost ticks really that common? If so, any idea what's disabling > > > >interrupts for so long (or if it's a hardware issue)? And if not, it > >seems like you'd need an artificial way to simulate lost ticks in order > >to test this stuff. > > > >Lee > > > > > Yes - I know many people with laptops who have this lost ticks problem. > So no simulation and/or > special efforts required. If anyone wants a test bed - my laptop is the > perfect instrument. > > In my case the rip is always as acpi_processor_idle now a days. Earlier > it used to be at acpi_ec_read. Ah, OK, I forgot about SMM traps. 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: 2.6.13-mm1: hangs during boot ...
Peter Williams <[EMAIL PROTECTED]> wrote: > > Brown, Len wrote: > >>>[ 279.662960] [] wait_for_completion+0xa4/0x110 > > > > > > possibly a missing interrupt? > > > > > >>CONFIG_ACPI=y > > > > > > any difference if booted with "acpi=off" or "acpi=noirq"? > > Yes. In both cases, the system appears to boot normally OK, we can pass this ball over to the ACPI team. > but I'm unable > to login or connect via ssh. Also there's a "device not ready" message > after the scsi initialization which I don't normally see. I've attached > the scsi initialization output. The PF_NETLINK error messages after the > login prompt in this output are created whenever I try to log in or > connect via ssh. Linus hit that too - it's an interaction between PAM and a modified netlink error code. Dave, where are we up to with the fix for that? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
Erik Andersen wrote: I assume you are worried about the stuff under asm that ends up being included by nearly every header file in the world. Of course asm must use double-underscore types. But the thing is, the vast majority of the kernel headers live under linux/include/linux/ and do not use double-underscore types, they use kernel specific, non-underscored types such as s8, u32, etc. My copy of IEEE 1003.1 and my copy of ISO/IEC 9899:1999 both fail to prohibit using the shiny new ISO C99 type for the various #include header files, which is what I was suggesting. The world would be so much nicer a place if user space were free to #include linux/* header files rather than keeping a per-project private copy of all kernel structs of interest. And where these kernel headers would #include stdint.h and define their stucts in terms of ISO C99 types. I see nothing at all in the standards preventing such a change, Exportable types need to be double-underscore types, because the header files in user space that would include them can generally not include . -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Updated dynamic tick patches - Fix lost tick calculation in timer_pm.c
On Sat, Sep 03, 2005 at 12:05:00AM -0400, Lee Revell wrote: > Are lost ticks really that common? If so, any idea what's disabling It becomes common with a patch like dynamic ticks, where we purposefully skip ticks when CPU is idle. When the CPU wakes up, we have to regain the lost/skipped ticks and thats where I ran into incorrect lost-tick calculation issues. > interrupts for so long (or if it's a hardware issue)? And if not, it > seems like you'd need an artificial way to simulate lost ticks in order > to test this stuff. Dyn-tick patch is enought to simulate these lost ticks! -- Thanks and Regards, Srivatsa Vaddagiri, Linux Technology Center, IBM Software Labs, Bangalore, INDIA - 560017 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Updated dynamic tick patches - Fix lost tick calculation in timer_pm.c
Lee Revell wrote: Are lost ticks really that common? If so, any idea what's disabling interrupts for so long (or if it's a hardware issue)? And if not, it seems like you'd need an artificial way to simulate lost ticks in order to test this stuff. Lee Yes - I know many people with laptops who have this lost ticks problem. So no simulation and/or special efforts required. If anyone wants a test bed - my laptop is the perfect instrument. In my case the rip is always as acpi_processor_idle now a days. Earlier it used to be at acpi_ec_read. Parag - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GFS, what's remaining
On Thu, Sep 01, 2005 at 01:21:04PM -0700, Andrew Morton wrote: > Alan Cox <[EMAIL PROTECTED]> wrote: > > > - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot > > > possibly gain (or vice versa) > > > > > > - Relative merits of the two offerings > > > > You missed the important one - people actively use it and have been for > > some years. Same reason with have NTFS, HPFS, and all the others. On > > that alone it makes sense to include. > > Again, that's not a technical reason. It's _a_ reason, sure. But what are > the technical reasons for merging gfs[2], ocfs2, both or neither? > > If one can be grown to encompass the capabilities of the other then we're > left with a bunch of legacy code and wasted effort. GFS is an established fs, it's not going away, you'd be hard pressed to find a more widely used cluster fs on Linux. GFS is about 10 years old and has been in use by customers in production environments for about 5 years. It is a mature, stable file system with many features that have been technically refined over years of experience and customer/user feedback. The latest development cycle (GFS2) has focussed on improving performance, it's not a new file system -- the "2" indicates that it's not ondisk compatible with earlier versions. OCFS2 is a new file system. I expect they'll want to optimize for their own unique goals. When OCFS appeared everyone I know accepted it would coexist with GFS, each in their niche like every other fs. That's good, OCFS and GFS help each other technically even though they may eventually compete in some areas (which can also be good.) Dave Here's a random summary of technical features: - cluster infrastructure: a lot of work, perhaps as much as gfs itself, has gone into the infrastructure surrounding and supporting gfs - cluster infrastructure allows for easy cooperation with CLVM - interchangable lock/cluster modules: gfs interacts with the external infrastructure, including lock manager, through an interchangable module allowing the fs to be adapted to different environments. - a "nolock" module can be plugged in to use gfs as a local fs (can be selected at mount time, so any fs can be mounted locally) - quotas, acls, cluster flocks, direct io, data journaling, ordered/writeback journaling modes -- all supported - gfs transparently switches to a different locking scheme for direct io allowing parallel non-allocating writes with no lock contention - posix locks -- supported, although it's being reworked for better performance right now - asynchronous locking, lock prefetching + read-ahead - coherent shared-writeable memory mappings across the cluster - nfs3 support (multiple nfs servers exporting one gfs is very common) - extend fs online, add journals online - full fs quiesce to allow for block level snapshot below gfs - read-only mount - "specatator" mount (like ro but no journal allocated for the mount, no fencing needed for failed node that was mounted as specatator) - infrastructure in place for live ondisk inode migration, fs shrink - stuffed dinodes, small files are stored in the disk inode block - tunable (fuzzy) atime updates - fast, nondisruptive stat on files during non-allocating direct-io - fast, nondisruptive statfs (df) even during heavy fs usage - friendly handling of io errors: shut down fs and withdraw from cluster - largest GFS cluster deployed was around 200 nodes, most are much smaller - use many GFS file systems at once on a node and in a cluster - customers use GFS for: scientific apps, HA, NFS serving, database, others I'm sure - graphical management tools for gfs, clvm, and the cluster infrastruture exist and are improving quickly - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] uml: share page bits handling between 2 and 3 level pagetables
On Fri, 2 Sep 2005, Jeff Dike wrote:
> On Wed, Aug 10, 2005 at 09:37:28PM +0200, Blaisorblade wrote:
> > Also look, on the "set_pte" theme, at the attached patch.
>
> + WARN_ON(!pte_young(*pte) || pte_write(*pte) && !pte_dirty(*pte));
>
> This one has been firing on me, and I decided to figure out why. The
> culprit is this code in do_no_page:
>
> if (pte_none(*page_table)) {
> if (!PageReserved(new_page))
> inc_mm_counter(mm, rss);
>
> flush_icache_page(vma, new_page);
> entry = mk_pte(new_page, vma->vm_page_prot);
> if (write_access)
> entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> set_pte_at(mm, address, page_table, entry);
>
> The first mk_pte immediately sets the pte to the protection limits of
> the VMA, regardless of the access type. So, if it's a read access on
> a writeable page, we get a writeable, but not dirty pte, since the
> mkdirty never happens. The exercises the warning you added.
>
> This seems somewhat bogus to me. If we set the pte protection to its
> limits, then the maybe_mkwrite is unneccesary.
>
> If we are the process in this address space, and we have a write
> access, then the maybe_mkwrite doesn't do anything because the pte is
> already writeable because the VMA has to be writeable, or we would
> have been faulted already.
Not at all. The private, COW areas. They may be writeable in the sense
that VM_WRITE is set, but pte_write permission cannot be in vm_page_prot,
or we'd never get the fault when to Copy On Write.
What is bogus, I think, are those places where we do the reverse:
like do_anonymous_page's pte_wrprotect of its mkpte of the ZERO_PAGE.
> If we are a debugger changing the process memory, then the vma may be
> read-only, and maybe_mkwrite is explicitly a no-op in this case.
>
> This doesn't seem to harm our dirty bit emulation. fix_range_common
> checks the dirty and accessed bits and disables read and write
> protection as appropriate.
>
> So, it seems like the warning could be dropped, or perhaps made more
> selective, like checking for is_write == 0 and VM_WRITE, but then the
> test is getting complicated.
>
> Heff
Jugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: www.linux1394.org - ???
On Fri, 2 Sep 2005 23:35:14 -0500 art wrote: > www.linux1394.org - is this server/project dead ? The server is known dead and being worked on or replaced. News on linux1394 mailing list indicates that it should be back soon (or should have been back soon)... Stefan Richter has tarballs of his svn checkouts here: http://me.in-berlin.de/~s5r6/linux1394/ --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm1: hangs during boot ...
Brown, Len wrote: [ 279.662960] [] wait_for_completion+0xa4/0x110 possibly a missing interrupt? CONFIG_ACPI=y any difference if booted with "acpi=off" or "acpi=noirq"? Yes. In both cases, the system appears to boot normally but I'm unable to login or connect via ssh. Also there's a "device not ready" message after the scsi initialization which I don't normally see. I've attached the scsi initialization output. The PF_NETLINK error messages after the login prompt in this output are created whenever I try to log in or connect via ssh. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce [8.345086] SCSI subsystem initialized [8.427503] sym0: <810a> rev 0x23 at pci :00:08.0 irq 16 [8.504636] sym0: No NVRAM, ID 7, Fast-10, SE, parity checking [8.588216] sym0: SCSI BUS has been reset. [8.642194] scsi0 : sym-2.2.1 [ 12.368622] Vendor: PIONEER Model: DVD-ROM DVD-303R Rev: 2.00 [ 12.450118] Type: CD-ROM ANSI SCSI revision:2[ 12.546506] target0:0:2: Beginning Domain Validation [ 12.613354] target0:0:2: asynchronous. [ 12.667699] target0:0:2: Domain Validation skipping write tests [ 12.747629] target0:0:2: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 8) [ 12.837395] target0:0:2: Ending Domain Validation [ 13.256875] Vendor: SONY Model: CD-RW CRX140SRev: 1.0e [ 13.338323] Type: CD-ROM ANSI SCSI revision:4[ 13.434891] target0:0:4: Beginning Domain Validation [ 13.503101] target0:0:4: asynchronous. [ 13.602931] target0:0:4: Domain Validation skipping write tests [ 13.683605] target0:0:4: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 8) [ 13.777934] target0:0:4: Ending Domain Validation [ 14.884703] Device not ready. [ 15.763312] kjournald starting. Commit interval 5 seconds [ 15.835612] EXT3-fs: mounted filesystem with ordered data mode. Fedora Core release 4 (Stentz) Kernel 2.6.13-mm1 on an i686 origma.pw.nest login: [ 101.886572] DEBUG: Failed to load PF_NETLINK protocol 9 [ 101.963572] DEBUG: Failed to load PF_NETLINK protocol 9
Re: [PATCH 1/3] Updated dynamic tick patches - Fix lost tick calculation in timer_pm.c
Lee Revell wrote: On Sat, 2005-09-03 at 14:18 +1000, Peter Williams wrote: In my experience, turning off DMA for IDE disks is a pretty good way to generate lost ticks :-) For this to "work" you have to unset "unmask IRQ" with hdparm, right? I'm not familiar with that method. When I've experienced this it's been due to me accidentally not configuring IDE DMA during configuration. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Updated dynamic tick patches - Fix lost tick calculation in timer_pm.c
On Sat, 2005-09-03 at 14:18 +1000, Peter Williams wrote: > In my experience, turning off DMA for IDE disks is a pretty good way to > generate lost ticks :-) For this to "work" you have to unset "unmask IRQ" with hdparm, right? 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: [RFC] Splitting out kernel<=>userspace ABI headers
On Sat Sep 03, 2005 at 12:07:58AM +, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Erik Andersen <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > > > That would be wonderful. > > > > > > It would be especially nice if everything targeting user space > > were to use only all the nice standard ISO C99 types as defined > > in include/stdint.h such as uint32_t and friends... > > > > Absolutely not. This would be a POSIX namespace violation; they > *must* use double-underscore types. I assume you are worried about the stuff under asm that ends up being included by nearly every header file in the world. Of course asm must use double-underscore types. But the thing is, the vast majority of the kernel headers live under linux/include/linux/ and do not use double-underscore types, they use kernel specific, non-underscored types such as s8, u32, etc. My copy of IEEE 1003.1 and my copy of ISO/IEC 9899:1999 both fail to prohibit using the shiny new ISO C99 type for the various #include header files, which is what I was suggesting. The world would be so much nicer a place if user space were free to #include linux/* header files rather than keeping a per-project private copy of all kernel structs of interest. And where these kernel headers would #include stdint.h and define their stucts in terms of ISO C99 types. I see nothing at all in the standards preventing such a change, -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.13-mm1: hangs during boot ...
> > [ 279.662960] [] wait_for_completion+0xa4/0x110 possibly a missing interrupt? > CONFIG_ACPI=y any difference if booted with "acpi=off" or "acpi=noirq"? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Updated dynamic tick patches - Fix lost tick calculation in timer_pm.c
Lee Revell wrote: On Wed, 2005-08-31 at 22:42 +0530, Srivatsa Vaddagiri wrote: With this patch, time had kept up really well on one particular machine (Intel 4way Pentium 3 box) overnight, while on another newer machine (Intel 4way Xeon with HT) it didnt do so well (time sped up after 3 or 4 hours). Hence I consider this particular patch will need more review/work. Are lost ticks really that common? If so, any idea what's disabling interrupts for so long (or if it's a hardware issue)? And if not, it seems like you'd need an artificial way to simulate lost ticks in order to test this stuff. In my experience, turning off DMA for IDE disks is a pretty good way to generate lost ticks :-) Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm1: hangs during boot ...
Peter Williams <[EMAIL PROTECTED]> wrote: > > Andrew Morton wrote: > > Peter Williams <[EMAIL PROTECTED]> wrote: > > > >>... at the the point indicated by the following output: > >> > >>[8.197224] Freeing unused kernel memory: 288k freed > >>[8.428217] SCSI subsystem initialized > >>[8.510376] sym0: <810a> rev 0x23 at pci :00:08.0 irq 11 > >>[8.587731] sym0: No NVRAM, ID 7, Fast-10, SE, parity checking > >>[8.671531] sym0: SCSI BUS has been reset. > >>[8.725530] scsi0 : sym-2.2.1 > >>[ 17.256480] 0:0:0:0: ABORT operation started. > >>[ 22.323534] 0:0:0:0: ABORT operation timed-out. > >>[ 22.384348] 0:0:0:0: DEVICE RESET operation started. > >>[ 27.458702] 0:0:0:0: DEVICE RESET operation timed-out. > >>[ 27.527544] 0:0:0:0: BUS RESET operation started. > >>[ 32.533775] 0:0:0:0: BUS RESET operation timed-out. > >>[ 32.599173] 0:0:0:0: HOST RESET operation started. > >>[ 32.669659] sym0: SCSI BUS has been reset. > >> > > > > > > Is there no response from sysrq-T? > > Now that I've tried it there is a response. I've attached the complete > output from the boot including the sysrq-T output in the hang.output > attachment to this e-mail. Thanks. > ... > [ 278.990398] Call Trace: > [ 279.024761] [] serio_thread+0xbf/0xf0 > [ 279.085573] [] kthread+0xa6/0xb0 > [ 279.140552] [] kernel_thread_helper+0x5/0xc > [ 279.208130] insmodD C171DCC0 0 227 1 232 > 70 )[ 279.309031] d7f33b04 d7f33ab8 d8836bb0 c171dcc0 1055 0fbf64f3 > d > [ 279.408678]e83b d7f33acc c01da354 d750e6ac d750e570 c130d160 > 0a9 > [ 279.518639]d7f32000 0a72aa15 0002 0246 c172de50 c172de50 > d7f > [ 279.628599] Call Trace: > [ 279.662960] [] wait_for_completion+0xa4/0x110 > [ 279.732934] [] blk_execute_rq+0x66/0xb0 > [ 279.796035] [] scsi_execute+0xb6/0xd0 [scsi_mod] > [ 279.869446] [] scsi_execute_req+0x7d/0xb0 [scsi_mod] > [ 279.947438] [] scsi_probe_lun+0xb6/0x1d0 [scsi_mod] > [ 280.024285] [] scsi_probe_and_add_lun+0xde/0x1e0 [scsi_mod] > [ 280.110295] [] scsi_scan_target+0xc9/0x140 [scsi_mod] > [ 280.189431] [] scsi_scan_channel+0x78/0x90 [scsi_mod] > [ 280.268569] [] scsi_scan_host_selected+0xc9/0x120 [scsi_mod] > [ 280.355722] [] scsi_scan_host+0x22/0x30 [scsi_mod] > [ 280.431425] [] sym2_probe+0xf5/0x120 [sym53c8xx] > [ 280.504835] [] pci_call_probe+0xd/0x10 > [ 280.566791] [] __pci_device_probe+0x49/0x60 > [ 280.634369] [] pci_device_probe+0x29/0x50 > [ 280.699657] [] driver_probe_device+0x3e/0xc0 > [ 280.768486] [] __driver_attach+0x5f/0x70 > [ 280.832628] [] bus_for_each_dev+0x43/0x70 > [ 280.897916] [] driver_attach+0x19/0x20 > [ 280.959770] [] bus_add_driver+0x7b/0xd0 > [ 281.022767] [] driver_register+0x42/0x50 > [ 281.086910] [] pci_register_driver+0x70/0x90 > [ 281.155635] [] sym2_init+0x2b/0x45 [sym53c8xx] > [ 281.226752] [] sys_init_module+0xec/0x230 > [ 281.292042] [] syscall_call+0x7/0xb > [ 281.350458] scsi_eh_0 D 0 232 1 > 227 )[ 281.451357] d7a51ea0 d7a51e64 1e62bb57 d7a5 1e62c494 > d > [ 281.551005]0106 d79b0ab0 c130d160 d79b0bec d79b0ab0 c130d160 > 9de > [ 281.660963]d7a5 9de05c44 0007 d7a5 d7a51ef4 d7a51ef0 > d7a > [ 281.770923] Call Trace: > [ 281.805288] [] wait_for_completion+0xa4/0x110 > [ 281.875159] [] sym_eh_handler+0x240/0x290 [sym53c8xx] > [ 281.954293] [] sym53c8xx_eh_host_reset_handler+0x2d/0x50 > [sym53c8][ 282.050611] [] scsi_try_host_reset+0x2b/0xa0 [scsi_mod] > [ 282.132041] [] scsi_eh_host_reset+0x1c/0xa0 [scsi_mod] > [ 282.212324] [] scsi_eh_ready_devs+0x57/0x70 [scsi_mod] > [ 282.292604] [] scsi_unjam_host+0x9f/0xc0 [scsi_mod] > [ 282.369451] [] scsi_error_handler+0xb9/0xe0 [scsi_mod] > [ 282.449734] [] kernel_thread_helper+0x5/0xc > scsi went ga-ga during insertion of the sym2 driver. Usual culprits cc'ed ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Updated dynamic tick patches - Fix lost tick calculation in timer_pm.c
On Wed, 2005-08-31 at 22:42 +0530, Srivatsa Vaddagiri wrote: > With this patch, time had kept up really well on one particular > machine (Intel 4way Pentium 3 box) overnight, while > on another newer machine (Intel 4way Xeon with HT) it didnt do so > well (time sped up after 3 or 4 hours). Hence I consider this > particular patch will need more review/work. > Are lost ticks really that common? If so, any idea what's disabling interrupts for so long (or if it's a hardware issue)? And if not, it seems like you'd need an artificial way to simulate lost ticks in order to test this stuff. 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: State of Linux graphics
Jon Smirl has written, > I've written an article that surveys the current State of Linux > graphics and proposes a possible path forward. This is a long article > containing a lot of detailed technical information as a guide to > future developers. Skip over the detailed parts if they aren't > relevant to your area of work. My idea is a windowing program with support for vertical synchronization interrupts. Hope this e-letter is threaded correctly. mihai -- a work-in-progress windowing program on svgalib at, http://sourceforge.net/projects/svgalib-windows (select browse cvs) __ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm1: hangs during boot ...
Andrew Morton wrote: Peter Williams <[EMAIL PROTECTED]> wrote: ... at the the point indicated by the following output: [8.197224] Freeing unused kernel memory: 288k freed [8.428217] SCSI subsystem initialized [8.510376] sym0: <810a> rev 0x23 at pci :00:08.0 irq 11 [8.587731] sym0: No NVRAM, ID 7, Fast-10, SE, parity checking [8.671531] sym0: SCSI BUS has been reset. [8.725530] scsi0 : sym-2.2.1 [ 17.256480] 0:0:0:0: ABORT operation started. [ 22.323534] 0:0:0:0: ABORT operation timed-out. [ 22.384348] 0:0:0:0: DEVICE RESET operation started. [ 27.458702] 0:0:0:0: DEVICE RESET operation timed-out. [ 27.527544] 0:0:0:0: BUS RESET operation started. [ 32.533775] 0:0:0:0: BUS RESET operation timed-out. [ 32.599173] 0:0:0:0: HOST RESET operation started. [ 32.669659] sym0: SCSI BUS has been reset. Is there no response from sysrq-T? Now that I've tried it there is a response. I've attached the complete output from the boot including the sysrq-T output in the hang.output attachment to this e-mail. Maybe adding initcall_debug to the boot command line will show extra info? The .config would be useful, thanks. Attached as origma.config. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce root (hd1,0) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-2.6.13-mm1 ro root=/dev/hdb2 psmouse.proto=imps console=ttyS0, 9600,n8 console=tty0 elevator=cfq initcall_debug [Linux-bzImage, setup=0x1c00, size=0x160a00] initrd /initrd-2.6.13-mm1.img [Linux-initrd @ 0x17ed, 0x10f799 bytes] [17179569.184000] Linux version 2.6.13-mm1 ([EMAIL PROTECTED]) (gcc version5[17179569.184000] BIOS-provided physical RAM map: [17179569.184000] BIOS-e820: - 0009fc00 (usable) [17179569.184000] BIOS-e820: 0009fc00 - 000a (reserved) [17179569.184000] BIOS-e820: 000f - 0010 (reserved) [17179569.184000] BIOS-e820: 0010 - 17ff (usable) [17179569.184000] BIOS-e820: 17ff - 17ff3000 (ACPI NVS) [17179569.184000] BIOS-e820: 17ff3000 - 1800 (ACPI data) [17179569.184000] BIOS-e820: fec0 - fec01000 (reserved) [17179569.184000] BIOS-e820: fee0 - fee01000 (reserved) [17179569.184000] BIOS-e820: - 0001 (reserved) [17179569.184000] 0MB HIGHMEM available. [17179569.184000] 383MB LOWMEM available. [17179569.184000] found SMP MP-table at 000f5b50 [17179569.184000] DMI 2.1 present. [17179569.184000] Using APIC driver default [17179569.184000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [17179569.184000] Processor #0 6:6 APIC version 17 [17179569.184000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [17179569.184000] Processor #1 6:6 APIC version 17 [17179569.184000] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [17179569.184000] IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23[17179569.184000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge) [17179569.184000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl) [17179569.184000] Enabling APIC mode: Flat. Using 1 I/O APICs [17179569.184000] Using ACPI (MADT) for SMP configuration information [17179569.184000] Allocating PCI resources starting at 1800 (gap: 1800:)[17179569.184000] Built 1 zonelists [17179569.184000] Initializing CPU#0 [17179569.184000] Kernel command line: ro root=/dev/hdb2 psmouse.proto=imps cog[17179569.184000] PID hash table entries: 2048 (order: 11, 32768 bytes) [0.00] Detected 498.852 MHz processor. [ 138.776886] Using tsc for high-res timesource [ 138.778122] Console: colour VGA+ 80x25 [ 141.445574] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 141.540255] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 141.691186] Memory: 383616k/393152k available (1890k kernel code, 8920k rese)[ 141.828739] Checking if this processor honours the WP bit even in supervisor.[ 142.013460] Calibrating delay using timer specific routine.. 999.15 BogoMIPS)[ 142.122666] Mount-cache hash table entries: 512 [ 142.182861] CPU: L1 I cache: 16K, L1 D cache: 16K [ 142.244915] CPU: L2 cache: 128K [ 142.286285] Intel machine check architecture supported. [ 142.355089] Intel machine check reporting enabled on CPU#0. [ 142.428541] mtrr: v2.0 (20020519) [ 142.472137] Enabling fast FPU save and restore... done. [ 142.541059] Checking 'hlt' instruction... OK. [ 142.623314] ACPI-0284: *** Error: Region SystemMemory(0) has no handler [ 142.715171] ACPI-0115: *** Error: acpi_load_tables: Could not load namesT[ 142.828766] ACPI-0123: *** Error: acpi_load_tables: Could not load tableT[ 142.938929] ACPI: Unable to load the System Description Tables [ 143.015900] CPU0: Intel Celeron (M
[PATCH] RT: Add raw_irqs_disabled to might_sleep
Add in raw_irqs_disabled() into the might sleep check.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
Index: linux-2.6.13/kernel/sched.c
===
--- linux-2.6.13.orig/kernel/sched.c2005-09-02 23:42:18.0 +
+++ linux-2.6.13/kernel/sched.c 2005-09-03 03:44:24.0 +
@@ -5914,7 +5914,7 @@ void __might_sleep(char *file, int line)
#if defined(in_atomic)
static unsigned long prev_jiffy;/* ratelimiting */
- if ((in_atomic() || irqs_disabled()) &&
+ if ((in_atomic() || irqs_disabled() || raw_irqs_disabled()) &&
system_state == SYSTEM_RUNNING && !oops_in_progress) {
if (debug_direct_keyboard && hardirq_count())
return;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] RT: trace_irqs_on in raw_local_irq_restore
Add trace_irqs_on() to raw_local_irq_restore() .
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
Index: linux-2.6.13/include/linux/rt_irq.h
===
--- linux-2.6.13.orig/include/linux/rt_irq.h2005-09-01 21:25:53.0
+
+++ linux-2.6.13/include/linux/rt_irq.h 2005-09-03 00:45:28.0 +
@@ -30,7 +30,8 @@ extern int irqs_disabled_flags(unsigned
# define raw_local_irq_disable() do { __raw_local_irq_disable();
trace_irqs_off(); } while (0)
# define raw_local_irq_save(flags) do { __raw_local_irq_save(flags);
trace_irqs_off(); } while (0)
# define raw_local_irq_restore(flags) \
- do { check_raw_flags(flags); __raw_local_irq_restore(flags); } while (0)
+ do { check_raw_flags(flags); if (!__raw_irqs_disabled_flags(flags)) {
trace_irqs_on(); } \
+ __raw_local_irq_restore(flags); } while (0)
# define raw_safe_halt() __raw_safe_halt()
#else
# define RAW_LOCAL_ILLEGAL_MASK0UL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Old ipw2200 code in 2.6.13-git3 and 2.6.13-mm1
The most recent IPW2200 release is 1.0.6. Now we have: #define IPW2200_VERSION "1.0.0" in 2.6.13-git2. Here, the version of firmware is set to the last release: ipw2200.c:#define IPW_FW_MAJOR_VERSION 2 ipw2200.c:#define IPW_FW_MINOR_VERSION 2 The most recent firmware release is 2.3. When I attempt to bring up the ipw2200 network connection to a wireless hub with WPA2 encrypted connection, I get the following error: WEXT auth param 7 value 0x1 - ioctl[SIOCSIWAUTH]: Operation not supported ioctl[SIOCSIWENCODEEXT]: Operation not supported ioctl[SIOCSIWENCODEEXT]: Operation not supported ioctl[SIOCSIWENCODEEXT]: Operation not supported ioctl[SIOCSIWENCODEEXT]: Operation not supported WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Operation not supported WEXT auth param 5 value 0x1 - ioctl[SIOCSIWAUTH]: Operation not supported Can we please get the latest IPW2200 code into the development kernels soon? Many thanks, Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86_64] Exception when using powernowd.
Thanx,Andrew, Written by Andrew Morton <[EMAIL PROTECTED]> at Fri, 2 Sep 2005 17:24:37 -0700 : Subject: Re: [x86_64] Exception when using powernowd. akpm> Kyuma Ohta <[EMAIL PROTECTED]> wrote: akpm> > akpm> > I'm using MSI K8T Neo2 (VIA K8T800 chipset) and Athlon64 3000+ akpm> > with linux x86_64 2.6.13 kernel and Debian/sid. akpm> > When enable powernow-k8 (i.e. using powernowd,cpudyn) to akpm> > saving power, some process is down by null protection and akpm> > system is unstable. akpm> > Then disabling powernow-k8,and reboot, system is very stable. akpm> > akpm> > I attach any log,please give me a advice. akpm> akpm> Did earlier kernels work OK? Can you identify the most recent 2.6 kernel akpm> which didn't have this bug? Without powernow! feature, works fine.(I tested every -rc kernel after 2.6.8 for x86_64). With powernow! feature,works bad at least after 2.6.11-rc*. I'm using xserver-xorg at debian,6.8.2-dfsg.1-5 happend OOPS at any process using X any older kernel, but update X to 6.8.2-6, any processes not/with using X got null exception and down when enable powernow! feature :-( What happened? Ohta. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bit Truncation in drivers/pci/probe.c on amd64
In the current git repository, on my amd64 machine I get the following warning on compile drivers/pci/probe.c: In function `pci_read_bases': drivers/pci/probe.c:166: warning: large integer implicitly truncated to unsigned type drivers/pci/probe.c:216: warning: large integer implicitly truncated to unsigned type I've tracked this down to pci_size, and two #define's in include/linux/pci.h #define PCI_BASE_ADDRESS_MEM_MASK (~0x0fUL) #define PCI_ROM_ADDRESS_MASK(~0x7ffUL) pci_size expects 3 u32 arguments,but from what I can tell, on 64 bit arch's the two above defines expand to 64bit values, and are truncated when being passed. I'm not sure how to go about fixing this, if pci_size should accept a u64 or if the defines should be changed. Is this bug dangerous? What should be done to fix it? -- Gabriel Devenyi [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.13: Filesystem capabilities 0.16
Or, has there been any communication between yourself and Nicholas Hans Simmonds, who posted his xattr-based fscaps patch in july (first posting july 2)? thanks, -serge Quoting Nix ([EMAIL PROTECTED]): > On 1 Sep 2005, Olaf Dietsche murmured woefully: > > This patch implements filesystem capabilities. It allows to run > > privileged executables without the need for suid root. > > Is there some reason why this doesn't keep its capability data in > xattrs? > > -- > `... published last year in a limited edition... In one of the > great tragedies of publishing, it was not a limited enough edition > and so I have read it.' --- James Nicoll > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] IrDA prototype fixes
Every file should #include the header files containing the prototypes of it's global functions. In this case this showed that the prototype of irlan_print_filter() was wrong which is also corrected in this patch. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- include/net/irda/irlan_filter.h |2 +- net/irda/irlan/irlan_filter.c |1 + net/irda/qos.c |1 + 3 files changed, 3 insertions(+), 1 deletion(-) --- linux-2.6.13-mm1-full/net/irda/qos.c.old2005-09-03 02:23:07.0 +0200 +++ linux-2.6.13-mm1-full/net/irda/qos.c2005-09-03 02:23:31.0 +0200 @@ -37,6 +37,7 @@ #include #include #include +#include /* * Maximum values of the baud rate we negociate with the other end. --- linux-2.6.13-mm1-full/include/net/irda/irlan_filter.h.old 2005-09-03 02:43:20.0 +0200 +++ linux-2.6.13-mm1-full/include/net/irda/irlan_filter.h 2005-09-03 02:43:29.0 +0200 @@ -28,6 +28,6 @@ void irlan_check_command_param(struct irlan_cb *self, char *param, char *value); void irlan_filter_request(struct irlan_cb *self, struct sk_buff *skb); -int irlan_print_filter(struct seq_file *seq, int filter_type); +void irlan_print_filter(struct seq_file *seq, int filter_type); #endif /* IRLAN_FILTER_H */ --- linux-2.6.13-mm1-full/net/irda/irlan/irlan_filter.c.old 2005-09-03 02:25:06.0 +0200 +++ linux-2.6.13-mm1-full/net/irda/irlan/irlan_filter.c 2005-09-03 02:25:24.0 +0200 @@ -27,6 +27,7 @@ #include #include +#include /* * Function irlan_filter_request (self, skb) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13] lockless pagecache 2/7
Alan Cox wrote: but I suspect that SMP isn't supported on those CPUs without ll/sc, and thus an atomic_cmpxchg could be emulated by disabling interrupts. It's obviously emulatable on any platform - the question is at what cost. For x86 it probably isn't a big problem as there are very very few people who need to build for 386 any more and there is already a big penalty for such chips. Thanks Alan, Dave, others. We'll see how things go. I'm fairly sure that for my usage it will be a win even if it is costly. It is replacing an atomic_inc_return, and a read_lock/read_unlock pair. But if it does one day get merged, and proves to be very costly on some architectures then we'll need to be careful about where it gets used. Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13] lockless pagecache 2/7
On Sat, 3 Sep 2005, Nick Piggin wrote: > Thanks Christoph, I think this will be required to support 386. > In the worst case, we could provide a fallback path and take > ->tree_lock in pagecache lookups if there is no atomic_cmpxchg, > however I would much prefer all architectures get an atomic_cmpxchg, > and I think it should turn out to be a generally useful primitive. > > I may trim this down to only provide what is needed for atomic_cmpxchg > if that is OK? Do not hesitate to do whatever you need to the patch. I took what I needed from you for this patch last year too. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] net/netfilter/nfnetlink*: make functions static
This patch makes needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
net/netfilter/nfnetlink.c |4 ++--
net/netfilter/nfnetlink_queue.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.13-mm1-full/net/netfilter/nfnetlink.c.old 2005-09-03
02:26:18.0 +0200
+++ linux-2.6.13-mm1-full/net/netfilter/nfnetlink.c 2005-09-03
02:27:21.0 +0200
@@ -344,14 +344,14 @@
} while(nfnl && nfnl->sk_receive_queue.qlen);
}
-void __exit nfnetlink_exit(void)
+static void __exit nfnetlink_exit(void)
{
printk("Removing netfilter NETLINK layer.\n");
sock_release(nfnl->sk_socket);
return;
}
-int __init nfnetlink_init(void)
+static int __init nfnetlink_init(void)
{
printk("Netfilter messages via NETLINK v%s.\n", nfversion);
--- linux-2.6.13-mm1-full/net/netfilter/nfnetlink_queue.c.old 2005-09-03
02:26:55.0 +0200
+++ linux-2.6.13-mm1-full/net/netfilter/nfnetlink_queue.c 2005-09-03
02:27:06.0 +0200
@@ -76,7 +76,7 @@
static DEFINE_RWLOCK(instances_lock);
-u_int64_t htonll(u_int64_t in)
+static u_int64_t htonll(u_int64_t in)
{
u_int64_t out;
int i;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] net/ipv4/ipconfig.c should #include
Every file should #include the header files containing the prototypes of it's global functions. nfs_fs.h contains the prototype of root_nfs_parse_addr(). Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.13-mm1-full/net/ipv4/ipconfig.c.old 2005-09-03 02:18:06.0 +0200 +++ linux-2.6.13-mm1-full/net/ipv4/ipconfig.c 2005-09-03 02:18:27.0 +0200 @@ -54,6 +54,7 @@ #include #include #include +#include #include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13 + IDE + MULTWRITE_EXT / DRQ Errors
I still get this error when the drive is on a Promise ATA/133 card.
I have the same setup in two separate machines, the results are the same
with kernel 2.6.13, ideas?
Should I just get more ATA/100 cards and stop trying to figure out what
the bug is? Keep in mind the Promise ATA/100 cards exhibit no such
errors or problems as below. I have not received any responses concerning
this bug.
According to:
http://www.ussg.iu.edu/hypermail/linux/kernel/0310.2/0693.html
Disabling PIO multiwrite fixes this problem, how do you do that?
As far as I can tell it is not enabled.
# hdparm -vi /dev/hde
/dev/hde:
multcount= 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
geometry = 48641/255/63, sectors = 781422768, start = 0
Model=ST3400832A, FwRev=3.01, SerialNo=3NF04YQK
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: device does not report version:
* signifies the current active mode
Another person states:
http://www.red-hat.com/archives/redhat-list/2000-June/msg00289.html
Hi
I've been gone for awhile but didn't see a response to this.
I solved the problem on one machine by changeing the
setting in bios from UDMA AUTO to DISABLED.
.I had another machine that periodically gave me this message
that just had the hard drive and mother board replaced by
the shop that built it because Seagate said that bios had
missed identified the drive geometry and had the head
sectors ect set wrong.
Linda
What is the real problem here?
Kernel .config attached for 2.6.13.
Please let me know, thanks.
Sep 2 20:48:05 p34 XFS mounting filesystem hde1
Sep 2 20:48:25 p34 hde: dma_timer_expiry: dma status == 0x20
Sep 2 20:48:25 p34 hde: DMA timeout retry
Sep 2 20:48:25 p34 PDC202XX: Primary channel reset.
Sep 2 20:48:25 p34 hde: timeout waiting for DMA
Sep 2 20:48:25 p34 hde: status error: status=0x58 {
Sep 2 20:48:25 p34 DriveReady
Sep 2 20:48:25 p34 SeekComplete
Sep 2 20:48:25 p34 DataRequest
Sep 2 20:48:25 p34 }
Sep 2 20:48:25 p34 ide: failed opcode was:
Sep 2 20:48:25 p34 unknown
Sep 2 20:48:25 p34 hde: drive not ready for command
Sep 2 20:48:26 p34 hde: status timeout: status=0xd0 {
Sep 2 20:48:26 p34 Busy
Sep 2 20:48:26 p34 }
Sep 2 20:48:26 p34 ide: failed opcode was:
Sep 2 20:48:26 p34 unknown
Sep 2 20:48:26 p34 PDC202XX: Primary channel reset.
Sep 2 20:48:26 p34 hde: no DRQ after issuing MULTWRITE_EXT
Sep 2 20:48:26 p34 ide2: reset:
Sep 2 20:48:26 p34 success
lspci output:
:03:06.0 Unknown mass storage controller: Promise Technology, Inc.
20269 (rev 02)
:03:07.0 Unknown mass storage controller: Promise Technology, Inc.
20269 (rev 02)
$ cat /proc/interrupts
CPU0 CPU1
0: 219088 0IO-APIC-edge timer
1: 9 0IO-APIC-edge i8042
9: 0 0 IO-APIC-level acpi
14: 3201 0IO-APIC-edge ide0
15: 12 0IO-APIC-edge ide1
16: 13893 0 IO-APIC-level eth0, libata, eth2
17:168 0 IO-APIC-level eth1
18:555 0 IO-APIC-level ide2
19:192 0 IO-APIC-level ide4, ide5
NMI: 0 0
LOC: 218910 218906
ERR: 0
MIS: 0
$ gcc -v
gcc version 4.0.1 (Debian 4.0.1-2)
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 3
model name : Intel(R) Pentium(R) 4 CPU 3.40GHz
stepping: 4
cpu MHz : 3409.857
cache size : 1024 KB
physical id : 0
siblings: 2
core id : 0
cpu cores : 1
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor
ds_cpl cid xtpr
bogomips: 6821.59
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 3
model name : Intel(R) Pentium(R) 4 CPU 3.40GHz
stepping: 4
cpu MHz : 3409.857
cache size : 1024 KB
physical id : 0
siblings: 2
core id : 0
cpu cores : 1
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags
Re: [RFC] Splitting out kernel<=>userspace ABI headers
On Sep 2, 2005, at 20:34:11, H. Peter Anvin wrote:
Kyle Moffett wrote:
I would actually be more inclined to provide and use types like
_kabi_{s,u}{8,16,32,64}, etc. Then the glibc/klibc/etc authors would
have the option of just doing "typedef _kabi_u32 uint32_t;" in their
header files.
They have to be *double-underscore*.
We have that. They're called __[su]{8,16,32,64}.
I realize this completely. The point of moving to kabi/* and kcore/*
would be to remove the dependence of userspace-accessible headers on
kernel-internal stuff. As I see it, part of that means exporting a
reasonably clean and straightforward API from kabi/kcore, including a
decent namespace prefix. The goal would be something that the kernel
headers could map to types useable in kernel code, that various *libc
in userspace could map to POSIX types, and that would have a nice
prefix to be namespace clean and avoid the risk of contamination.
Given this set of goals, I think that something like the below would
probably work and satisfy the needs of both *libc and the kernel:
/* kcore/types.h */
typedef unsigned char __kabi_u8;
typedef signed char __kabi_s8;
typedef [...]
/* linux/types.h */
#include
#ifndef __KERNEL__
# warning "Insert some kind of deprecation warning here
#endif
/* These for compatibility only. When the last ABI headers move
to kcore or kabi, these should go in __KERNEL__ */
typedef __kabi_u8 __u8;
typedef __kabi_s8 __s8;
[...]
#ifdef __KERNEL__
typedef __kabi_u8 u8;
typedef __kabi_s8 s8;
#endif
/* stdint.h */
#include
typedef __kabi_u8 uint8_t;
typedef __kabi_s8 int8_t;
[...]
Cheers,
Kyle Moffett
--
There is no way to make Linux robust with unreliable memory subsystems,
sorry. It would be like trying to make a human more robust with an
unreliable O2 supply. Memory just has to work.
-- Andi Kleen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13: Crash in Yenta initialization
As a follow-up to my previous mail, I collected a boot log of the working kernel 2.6.12-rc6 with Ivan's bridge initialization patches below. The crucial part seem to be the different bridge initialization sections: 2.6.12-rc6 + Ivan's patches: PCI: Bridge: :00:01.0 IO window: 2000-2fff MEM window: c810-c81f PREFETCH window: d000-d7ff PCI: Bridge: :00:1c.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: :00:1c.1 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bus 4, cardbus bridge: :03:05.0 IO window: 3000-3fff IO window: 4000-4fff PREFETCH window: 8000-81ff MEM window: 8800-89ff PCI: Bridge: :02:00.0 IO window: 3000-5fff MEM window: 8800-8aff PREFETCH window: 8000-81ff PCI: Bridge: :00:1c.2 IO window: 3000-5fff MEM window: 8800-8aff PREFETCH window: 8000-81ff PCI: Bus 7, cardbus bridge: :06:09.0 IO window: 6000-6fff IO window: 7000-7fff PREFETCH window: 8200-83ff MEM window: 8c00-8dff PCI: Bus 11, cardbus bridge: :06:09.1 IO window: 8000-8fff IO window: 9000-9fff PREFETCH window: 8400-85ff MEM window: 8e00-8fff PCI: Bus 15, cardbus bridge: :06:09.3 IO window: a000-afff IO window: b000-bfff PREFETCH window: 8600-87ff MEM window: 9000-91ff PCI: Bridge: :00:1e.0 IO window: 6000-bfff MEM window: c840-c84f PREFETCH window: 8200-87ff ... Versus the much shorter output from 2.6.13 PCI: Bridge: :00:01.0 IO window: 2000-2fff MEM window: c810-c81f PREFETCH window: d000-d7ff PCI: Bridge: :00:1c.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: :00:1c.1 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bus 4, cardbus bridge: :03:05.0 IO window: 3000-30ff IO window: 3400-34ff PREFETCH window: 8000-81ff MEM window: 8400-85ff PCI: Bridge: :02:00.0 IO window: 3000-3fff MEM window: 8400-86ff PREFETCH window: 8000-81ff PCI: Bridge: :00:1c.2 IO window: 3000-3fff MEM window: 8400-86ff PREFETCH window: 8000-81ff PCI: Bus 7, cardbus bridge: :06:09.0 IO window: 4000-40ff IO window: 4400-44ff PREFETCH window: 8200-83ff MEM window: 8800-89ff PCI: Bridge: :00:1e.0 IO window: 4000-4fff MEM window: c840-c84f PREFETCH window: 8200-83ff Below the full boot log for the working 2.6.12-rc6+IvanPatches I hope this additional info helps to bring this part of 2.6.13 up to the earlier capability. Andreas Koch Linux version 2.6.12-rc6 ([EMAIL PROTECTED]) (gcc version 3.3.5-20050130 (Gentoo Linux 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1)) #11 Sat Sep 3 01:09:47 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 7fe8 (usable) BIOS-e820: 7fe8 - 7fe89000 (ACPI data) BIOS-e820: 7fe89000 - 7ff0 (ACPI NVS) BIOS-e820: 7ff0 - 8000 (reserved) BIOS-e820: e000 - f0006000 (reserved) BIOS-e820: f0008000 - f000c000 (reserved) BIOS-e820: fed2 - fed9 (reserved) BIOS-e820: ff00 - 0001 (reserved) 1150MB HIGHMEM available. 896MB LOWMEM available. On node 0 totalpages: 523904 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 294528 pages, LIFO batch:31 DMI present. ACPI: RSDP (v000 PTLTD ) @ 0x000f68d0 ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x7fe80e14 ACPI: FADT (v001 INTEL ALVISO 0x0604 LOHR 0x005f) @ 0x7fe88e8a ACP
Re: 2.6.13: Crash in Yenta initialization
Andreas Koch <[EMAIL PROTECTED]> wrote: > > This does not happen in my current kernel (2.6.12-rc6 with Ivan's PCI bridge > patches applied). It is definitely localized in the Yenta code, since the > boot proceeds when I disable the Yenta config option. My hardware is an Acer > Travelmate 8104 with the external ezDock attached. > > I can provide more info if you let me know what to look for. > > ... > Yenta: CardBus bridge found at :06:09.1 [1025:0070] > Unable to handle kernel NULL pointer dereference at virtual address 004f > printing eip: > c03af658 > *pde = > Oops: [#1] > Modules linked in: > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010292 (2.6.13) > EIP is at yenta_config_init+0xd8/0x170 > eax: ebx: dfcb7000 ecx: edx: e0649000 > esi: dff75000 edi: 1000 ebp: dff75000 esp: dfd9fea8 > ds: 007b es: 007b ss: 0068 > Process swapper (pid: 1, threadinfo=dfd9e000 task=dfdc7a00) > Stack: dff7d880 0049 000d 00a8 c011f9d7 fff4 dfcb7000 > c03af810 >dfcb7000 dff750d8 1025 0070 c05abf20 ffed dff75000 > c05ac340 >c05ac36c c028927f dff75000 c05ac2d8 c05ac340 dff75000 dff75044 > c02892bf > Call Trace: > [] printk+0x17/0x20 > [] yenta_probe+0x120/0x280 > [] __pci_device_probe+0x5f/0x70 > [] pci_device_probe+0x2f/0x50 > [] driver_probe_device+0x38/0xb0 > [] __driver_attach+0x0/0x50 > [] __driver_attach+0x47/0x50 > [] bus_for_each_dev+0x69/0x80 > [] driver_attach+0x25/0x30 > [] __driver_attach+0x0/0x50 > [] bus_add_driver+0x8d/0xe0 > [] pci_register_driver+0x70/0x90 > [] yenta_socket_init+0xf/0x20 > [] do_initcalls+0x2b/0xc0 > [] init+0x0/0x110 > [] init+0x0/0x110 > [] init+0x2a/0x110 > [] kernel_thread_helper+0x0/0x18 > [] kernel_thread_helper+0x5/0x18 > Code: ed ff 8b 13 b9 a8 00 00 00 b8 0d 00 00 00 89 4c 24 0c 89 44 24 08 8b 42 > 20 89 44 24 04 8b 42 10 89 04 24 e8 bb 56 ed ff 8b 4e 14 <0f> b6 51 4f 0f b6 > 41 4e c1 e2 10 c1 e0 08 09 c2 0f b6 41 4d 8b > <0>Kernel panic - not syncing: Attempted to kill init! > I don't think any of the recent yenta changes would have caused this. The .config might help. Also, can you identify which line is going oops? Set CONFIG_DEBUG_INFO, retest, do gdb vmlinux (gdb) l *0xc03af658 (the EIP value) thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
Kyle Moffett wrote:
On Sep 2, 2005, at 20:07:58, H. Peter Anvin wrote:
Followup to: <[EMAIL PROTECTED]>
By author:Erik Andersen <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
That would be wonderful.
It would be especially nice if everything targeting user space
were to use only all the nice standard ISO C99 types as defined
in include/stdint.h such as uint32_t and friends...
Absolutely not. This would be a POSIX namespace violation; they
*must* use double-underscore types.
I would actually be more inclined to provide and use types like
_kabi_{s,u}{8,16,32,64}, etc. Then the glibc/klibc/etc authors would
have the option of just doing "typedef _kabi_u32 uint32_t;" in their
header files.
They have to be *double-underscore*.
We have that. They're called __[su]{8,16,32,64}.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
On Fri, 2005-09-02 at 15:34 -0700, Andrew Morton wrote: > Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > > Hi Andrew! > > > > Do you plan to send FUSE to Linus for 2.6.14? > i use fuse too, and i like it, it works good, and its quite fast and easy. it has given me no problems at all, i suggest merging, it harms nothing, and seems to be well maintained > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
On Sep 2, 2005, at 20:07:58, H. Peter Anvin wrote:
Followup to: <[EMAIL PROTECTED]>
By author:Erik Andersen <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
That would be wonderful.
It would be especially nice if everything targeting user space
were to use only all the nice standard ISO C99 types as defined
in include/stdint.h such as uint32_t and friends...
Absolutely not. This would be a POSIX namespace violation; they
*must* use double-underscore types.
I would actually be more inclined to provide and use types like
_kabi_{s,u}{8,16,32,64}, etc. Then the glibc/klibc/etc authors would
have the option of just doing "typedef _kabi_u32 uint32_t;" in their
header files.
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/
Re: Kernel 2.6.13 breaks libpcap (and tcpdump).
John McGowan <[EMAIL PROTECTED]> wrote: > > Kernel 2.6.13. Breaks libpcap. > > Fedora Core 2, gcc 3.3.3, Pentium III (933MHz) > > I had written about my dismay that traceproto and tcptraceroute > no longer worked and suspected that libnet was broken. > > It seems that it is libpcap that is broken by kernel 2.6.13 and > tcpdump itself no longer works. > Well, it works ... but not correctly. > > Capture data, then look for ICMP messages > (e.g. Time Exceeded errors as in a traceroute) > by filtering the file. > > tcpdump -w 1.cap > tcpdump -f "ip proto \icmp" -r 1.cap > > That works. > > > Filter incoming data, looking for ICMP messages: > > tcpdump -f "ip proto \icmp" > > Well, that catches nothing. > > > I tried recompiling (source RPM, Fedora Core 2) tcpdump > (libpcap, tcpdump, etc.) and reinstalling. That did not > fix the problem with tcpdump. > > It also broke a tethereal script I was using (which I changed > to capture all packets, which works as indicated above, and > then used a '-R', read, filter to display the one's I want). > (cc netdev) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86_64] Exception when using powernowd.
Kyuma Ohta <[EMAIL PROTECTED]> wrote: > > I'm using MSI K8T Neo2 (VIA K8T800 chipset) and Athlon64 3000+ > with linux x86_64 2.6.13 kernel and Debian/sid. > When enable powernow-k8 (i.e. using powernowd,cpudyn) to > saving power, some process is down by null protection and > system is unstable. > Then disabling powernow-k8,and reboot, system is very stable. > > I attach any log,please give me a advice. Did earlier kernels work OK? Can you identify the most recent 2.6 kernel which didn't have this bug? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (why I chose FUSE over v9fs)
On Friday 02 September 2005 15:34, Andrew Morton wrote: > Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > Hi Andrew! > > > > Do you plan to send FUSE to Linus for 2.6.14? ... > I agree that lots of people would like the functionality. I regret that > although it appears that v9fs could provide it, there seems to be no > interest in working on that. I evaluated both v9fs and FUSE for my project (I don't want to link to it until it does something actually useful ;) ) ... and it seemed that v9fs just wasn't UNIXy enough for my purposes -- the Plan9 way and the UNIX way were different enough to make me nervous. I don't remember the specific details (this was a few months ago), but I do remember that v9fs had no extended attribute support, which was a showstopper for me. Also, I couldn't find any userspace library for writing 9P servers. Others may have reached similar conclusions. Or maybe FUSE is just better-marketed. ;) Either way, I am a happy FUSE user. I think it offers things v9fs doesn't, and I'd like to see it in mainline. :) -- Josh -- Joshua J. Berry "I haven't lost my mind -- it's backed up on tape somewhere." -- /usr/games/fortune pgpeHwGWEoTRr.pgp Description: PGP signature
Re: UML x86_86 Multicast Patch
On Fri, Sep 02, 2005 at 07:52:02PM -0300, Alan Menegotto wrote: > In mcast_user.c from /usr/src/linux-2.6.13/arch/um/drivers when > multicast is enabled it cannot pass the "compile kernel" phase. The > following patch should fix the error. Please correct me if I'm wrong. > > > > > --- /tmp/mcast_user.c 2005-09-03 19:59:15.0 -0300 > +++ mcast_user.c2005-09-03 19:59:32.0 -0300 > @@ -13,7 +13,7 @@ > > #include > #include > -#include > +//#include > #include > #include > #include Well, it passes my compile kernel phase, otherwise it would have been fixed already. But eliminating that include doesn't break anything (as it can't, considering that inet.h is empty), so this is applied, thanks. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GFS, what's remaining
On Fri, Sep 02, 2005 at 11:17:08PM +0200, Andi Kleen wrote: > The only thing that should be probably resolved is a common API > for at least the clustered lock manager. Having multiple > incompatible user space APIs for that would be sad. As far as userspace dlm apis go, dlmfs already abstracts away a large part of the dlm interaction, so writing a module against another dlm looks like it wouldn't be too bad (startup of a lockspace is probably the most difficult part there). --Mark -- Mark Fasheh Senior Software Developer, Oracle [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.13-mm1
On Fri, 2 Sep 2005 14:45:52 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
>"J.A. Magallon" <[EMAIL PROTECTED]> wrote:
>>
[...]
>> Still the same result, system bocks starting udev...
>>
>
>OK, thanks. Nothing from sysrq-t? Does the below help?
>
>---
>devel/fs/sysfs/file.c~gregkh-driver-sysfs-strip_leading_trailing_whitespace-fix
>2005-09-02 04:01:40.0 -0700
>+++ devel-akpm/fs/sysfs/file.c 2005-09-02 04:05:02.0 -0700
>@@ -202,13 +202,14 @@ fill_write_buffer(struct sysfs_buffer *
> *passing the buffer that we acquired in fill_write_buffer().
> */
>
>-static int
>-flush_write_buffer(struct dentry * dentry, struct sysfs_buffer * buffer,
>size_t count)
>+static int flush_write_buffer(struct dentry *dentry,
>+ struct sysfs_buffer *buffer, size_t count_in)
> {
> struct attribute * attr = to_attr(dentry);
> struct kobject * kobj = to_kobj(dentry->d_parent);
> struct sysfs_ops * ops = buffer->ops;
> char *x;
>+ size_t count = count_in;
>
> /* locate trailing white space */
> while ((count > 0) && isspace(buffer->page[count - 1]))
>@@ -224,7 +225,8 @@ flush_write_buffer(struct dentry * dentr
> /* terminate the string */
> x[count] = '\0';
>
>- return ops->store(kobj, attr, x, count);
>+ ops->store(kobj, attr, x, count);
>+ return count_in;
> }
>
>
Hi Andrew,
Patch above fixes problem with sysfs writes to adm9240 driver
locking up console in last three -mm kernels.
Grant.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
Followup to: <[EMAIL PROTECTED]> By author:Erik Andersen <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > That would be wonderful. > > > It would be especially nice if everything targeting user space > were to use only all the nice standard ISO C99 types as defined > in include/stdint.h such as uint32_t and friends... > Absolutely not. This would be a POSIX namespace violation; they *must* use double-underscore types. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] pci: Block config access during BIST (resend)
On Sat, Sep 03, 2005 at 09:11:30AM +1000, Paul Mackerras wrote: > Think about it. Taking the lock ensures that we don't do the > assignment (dev->block_ucfg_access = 1) while any other cpu has the > pci_lock. In other words, the reason for taking the lock is so that > we wait until nobody else is doing an access, not to make others wait. The block_ucfg_access field is only used when making the choice to use saved state or call the PCI bus cfg accessor. I don't what problem waiting solves here since any CPU already accessing real cfg space will finish what they are doing anyway. ie they already made the choice to access real cfg space. We just need to make sure successive accesses to cfg space for this device only access the saved state. For that, a memory barrier around all uses of block_ucfg_access should be sufficient. Or do you think I'm still drinking the wrong color cool-aid? > > If you had: > > spin_lock_irqsave(&pci_lock, flags); > > pci_save_state(dev); > > dev->block_ucfg_access = 1; > > spin_unlock_irqrestore(&pci_lock, flags); > > > > Then I could buy your arguement since the flag now implies > > we need to atomically save state and set the flag. > > That's probably a good thing to do to. One needs to verify pci_lock isn't acquired in pci_save_state() (or some other obvious dead lock). It would make sense to block pci cfg *writes* to that device while we save the state. grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE HPA
On Fri, Sep 02, 2005 at 09:22:58PM +0100, Alan Cox wrote: > You installed it on Red Hat 7 ? I think 7, may have been 6.x or earlier. > This behaviour goes back pretty much to the creation of the ATA spec for > HPA. In fact if it was that long ago IBM shipped it with Windows so it > did have a partition table! FC3 happily ignored the HPA on IBM X31. FC4 did not. I won't vow about the original partitioning, but a "worked for just about everything" FC3 kickstart slightly updated to FC4 started breaking horribly after suspend. As in messed up filesystems since parts of the disk just vanished when you resumed. (FC3 could have been broken too, but CONFIG_IDE_STROKE or whatnot wasn't enabled, so it worked as expected). It probably didn't work as expected for people with broken bioses that didn't do >32GB ether, but those people required additional hacks for competing OS's too, so it wasn't such a biggie for them, I suppose. Some sort of BIOS bug, completely IBM's (or rather some subcontractor) fault, happens on one X31 laptop I know of, where the HPA just can't be disabled. At all. The BIOS setting gets ignored. On the one I personally use disabling it works, so losing the recovery Windows XP was enough to have a functional system. Not optimal, but I don't really need the recovery stuff for anything, so might as well use the entire disk. For the one where disabling the HPA just didn't work the solution was to manually partition, and just not using the area the HPA would appear on. There goes automatic kickstart installs, but at least the laptop now is usable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
On Fri Sep 02, 2005 at 04:51:49PM -0400, Kyle Moffett wrote: > On Sep 2, 2005, at 09:41:09, Erik Andersen wrote: > >Have you seen the linux-libc-headers: > >http://ep09.pld-linux.org/~mmazur/linux-libc-headers/ > >which, while not an official part of the kernel, do a pretty > >good job... > > Well, the eventual goal of this project would be to eliminate the > need for linux-libc-headers by making that task trivial (IE: Just copy > the kcore/ and kabi/ (or whatever they get called) directories into > /usr/include. That would be wonderful. It would be especially nice if everything targeting user space were to use only all the nice standard ISO C99 types as defined in include/stdint.h such as uint32_t and friends... -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
Followup to: <[EMAIL PROTECTED]> By author:Kyle Moffett <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > The kernel already needs those same optimized routines for its own > operation (EX: all the ASM alternative() statements). Since userspace > wants some of those as well, it would make sense to share them between > kernel and userspace and reduce the number of libraries you would need > to optimize when adding a new arch. I don't think that we should add > optimized assembly for things that _aren't_ needed in the kernel, but > it should share what code it does have. > > A side benefit of the vDSO method is that you would be able to take a > standard distro install and have the kernel automatically select the > correct vDSO image at runtime, simultaneously optimizing itself and > chunks of userspace. > First of all, a lot of these are inlines, and they derive a chunk of their benefit from being inline. Second, even if bundled with the kernel, which I'm not sure is wise, there is no reason they can't just be turned into libraries. *Some functions* you're right, can be optimized this way, but I'm not sure if that justifies compiling them into the kernel that way. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE HPA
On Gwe, 2005-09-02 at 17:14 -0400, Peter Jones wrote: > > You installed it on Red Hat 7 ? I think 7, may have been 6.x or earlier. > > You may be right -- it's likely that I shrank my windows partition on > some other OS or Distro that wasn't designed with to screw up the disk. If you shrink existing partitions it won't ever screw you up. The geometry data for the partition table spans only the non HPA area. > Yes, it did have a partition table -- but the partition table did (and > still does) not include partitions which overlap the HPA. Right now it > still appears as unused space. But they are also on the IBM I looked at are obvious because the geometry in the partition table does not span the HPA so the problem doesn't arise as confusion. > > Not really practical. You'd have to list most older PC systems. > > Most older PC systems use HPA? Really? Many of those "magic windows drive/bios fixup" type programs work by having the jumper on the drive set the HPA and the drive report a smaller size, then the windows magic driver undoes this. > Both of these suck. Have I missed something? I fear not. > So where would you envision this code to check the partition table, the > HPA/host default disk size, and guess how things should be set up? fdisk and friends already have to parse and process the existing partition tables. > they'll be screwing themselves by partitioning the entire disk, so we > really should be leaving HPA enabled if the protected area is indeed not > for consumption. Define "not for consumption". It should be *hard* to use it, and it should not occur by accident. Deliberately is a different matter. And that should be a run time not boot time action. > (as a side note, I know one user who, at OLS, noticed we fail to > re-initialize HPA after unsuspend, so on at least t40 the disk gets > smaller when you suspend. This may or may not be fixed, I haven't > checked. But it's one more sort of pain we get into by disabling it, > whether justified or not.) Known problem. ACPI provides the correct infrastructure for much of this but the IDE layer doesn't support it. Send patches to Bartlomiej. The core infrastructure is there because Andre saw the need for the ACPI taskfile support coming. The HPA restore is just another step in the state machine for resume and quite doable. Good little project for someone wanting to play with the IDE layer. > I think if we go the heuristic route, then the *safest* option is to > leave it enabled by default and let userland installers/initrd do fixups > by telling the kernel to change the state. Assuming we are talking about hda1/2/... then the partitions are already clipped by the OS to the volume size. We could conceivably make the size of the disk itself writable. We don't need to get into programming drive HPA when we can do it ourselves, and we can clip non HPA capable drives too should someone find a cause for it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
On Sep 2, 2005, at 19:24:22, H. Peter Anvin wrote: Kyle Moffett wrote: My far-into-the-future ideal for this is to have a generic vDSO-type library that is compiled into the kernel that provides a collection of architecture-optimized routines available in both kernelspace and userspace by mapping it into each process' address space. Such a library could effectively automatically provide correct and optimized assembly routines for the currently booted CPU/arch/subarch/etc, so that userspace tools could be compiled once and run on an entire family of CPUs without modification. On the other hand, for those applications that need every last ounce of speed (Including parts of the kernel), you could pass appropriate options to the compiler to tell it to inline the assembly routines (alternative) for a single CPU make/model. I don't see why this should be compiled into the kernel. The kernel already needs those same optimized routines for its own operation (EX: all the ASM alternative() statements). Since userspace wants some of those as well, it would make sense to share them between kernel and userspace and reduce the number of libraries you would need to optimize when adding a new arch. I don't think that we should add optimized assembly for things that _aren't_ needed in the kernel, but it should share what code it does have. A side benefit of the vDSO method is that you would be able to take a standard distro install and have the kernel automatically select the correct vDSO image at runtime, simultaneously optimizing itself and chunks of userspace. Cheers, Kyle Moffett -- Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.13: Crash in Yenta initialization
This does not happen in my current kernel (2.6.12-rc6 with Ivan's PCI bridge patches applied). It is definitely localized in the Yenta code, since the boot proceeds when I disable the Yenta config option. My hardware is an Acer Travelmate 8104 with the external ezDock attached. I can provide more info if you let me know what to look for. Andreas Koch Linux version 2.6.13 ([EMAIL PROTECTED]) (gcc version 3.3.5-20050130 (Gentoo Linux 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1)) #2 Fri Sep 2 23:34:19 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 7fe8 (usable) BIOS-e820: 7fe8 - 7fe89000 (ACPI data) BIOS-e820: 7fe89000 - 7ff0 (ACPI NVS) BIOS-e820: 7ff0 - 8000 (reserved) BIOS-e820: e000 - f0006000 (reserved) BIOS-e820: f0008000 - f000c000 (reserved) BIOS-e820: fed2 - fed9 (reserved) BIOS-e820: ff00 - 0001 (reserved) 1150MB HIGHMEM available. 896MB LOWMEM available. DMI present. ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:13 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23 ACPI: IOAPIC (id[0x02] address[0xfec2] gsi_base[24]) IOAPIC[1]: apic_id 2, version 32, address 0xfec2, GSI 24-47 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Enabling APIC mode: Flat. Using 2 I/O APICs ACPI: HPET id: 0x8086a201 base: 0x0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 8000 (gap: 8000:6000) Built 1 zonelists Kernel command line: root=/dev/ram0 lvm2root=/dev/vg0/root console=ttyS0 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 1995.744 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 2069152k/2095616k available (3513k kernel code, 25172k reserved, 1575k data, 212k init, 1178112k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 3995.10 BogoMIPS (lpj=1997552) Mount-cache hash table entries: 512 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 2048K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) CPU: Intel(R) Pentium(R) M processor 2.00GHz stepping 08 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=-1 checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 2061k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfd6ce, last bus=8 PCI: Using MMCONFIG ACPI: Subsystem revision 20050408 ACPI-0362: *** Error: Looking up [Z00G] in namespace, AE_NOT_FOUND search_node c20d9140 start_node c20d9140 return_node ACPI-0362: *** Error: Looking up [Z00G] in namespace, AE_NOT_FOUND search_node c20d9d80 start_node c20d9d80 return_node ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 PCI: Ignoring BAR0-3 of IDE controller :00:1f.2 PCI: PXH quirk detected, disabling MSI for SHPC device PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 *10 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 11 12 14 15) *10 ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 12 14 15) *11 ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 *11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 7 10 12 14 15) *11 ACPI: PCI Interrupt Link [LNKF] (IRQs 1 3 4 5 6 7 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 1 3 4 5 6 7 10 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 1 3 4 5 6 7 *11 12 14 15) ACPI: Embedded Controller [EC0] (gpe 29) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 12 devices SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report PCI: Cannot allocate resource region 7 of bridge :00:1c
Re: [PATCH 2.6.13] lockless pagecache 2/7
On Sad, 2005-09-03 at 07:22 +1000, Nick Piggin wrote: > > Actually we have cmpxchg on i386 these days - we don't support > > any SMP i386s so it's just done non atomically. > > Yes, I guess that's what Alan must have meant. Well I was thinking about things like pre-empt. Also the x86 cmpxchg() is defined for non i386 processors to allow certain things to use it (ACPI, DRM etc) which know they won't be on a 386. The implementation in this case will blow up on a 386 and the __HAVE_ARCH_CMPXCHG remains false. > but I suspect that SMP isn't supported on those CPUs without ll/sc, > and thus an atomic_cmpxchg could be emulated by disabling interrupts. It's obviously emulatable on any platform - the question is at what cost. For x86 it probably isn't a big problem as there are very very few people who need to build for 386 any more and there is already a big penalty for such chips. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] more of sparc32 dependencies fallout
On Fri, Sep 02, 2005 at 01:03:43PM -0700, David S. Miller wrote: > From: Alan Cox <[EMAIL PROTECTED]> > Subject: Re: [PATCH] more of sparc32 dependencies fallout > Date: Fri, 02 Sep 2005 21:24:08 +0100 > > > On Gwe, 2005-09-02 at 20:12 +0100, [EMAIL PROTECTED] wrote: > > > config MOXA_SMARTIO > > > tristate "Moxa SmartIO support" > > > - depends on SERIAL_NONSTANDARD > > > + depends on SERIAL_NONSTANDARD && (BROKEN || !SPARC32) > > > help > > > > > > Why mark it "BROKEN" and !SPARC32. Why not mark it (ISA || PCI) ? Its > > only available as a plugin card and its apparently working > > He marked it BROKEN "OR" !SPARC32, not "AND". > Also, SPARC32 supports PCI on Javastation machines. Actually, proper fix of that breakage is embarrassingly simple - it's yet another gratitious leftover include of asm/segment.h, so incremental to the previos would be removal of that BROKEN and removal of bogus include from mxser.c itself. diff -urN RC13-git3-base/drivers/char/Kconfig current/drivers/char/Kconfig --- RC13-git3-base/drivers/char/Kconfig 2005-09-02 14:16:04.0 -0400 +++ current/drivers/char/Kconfig2005-09-02 19:20:11.0 -0400 @@ -175,7 +175,7 @@ config MOXA_SMARTIO tristate "Moxa SmartIO support" - depends on SERIAL_NONSTANDARD && (BROKEN || !SPARC32) + depends on SERIAL_NONSTANDARD help Say Y here if you have a Moxa SmartIO multiport serial card. diff -urN RC13-git3-base/drivers/char/mxser.c current/drivers/char/mxser.c --- RC13-git3-base/drivers/char/mxser.c 2005-06-17 15:48:29.0 -0400 +++ current/drivers/char/mxser.c2005-09-02 19:20:05.0 -0400 @@ -63,7 +63,6 @@ #include #include #include -#include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/block/nbd.c: don't defer compile error to runtime
On Fri, Sep 02, 2005 at 07:20:47PM -0400, Adam Kropelin wrote:
> Adrian Bunk wrote:
> > If we can detect a problem at compile time, the compilation should
> > fail.
>
> [...]
>
> > if (sizeof(struct nbd_request) != 28) {
> > - printk(KERN_CRIT "nbd: sizeof nbd_request needs to be 28 in
> > order to work!\n" );
> > - return -EIO;
> > + extern void nbd_request_wrong_size(void);
> > + nbd_request_wrong_size();
>
> BUILD_BUG_ON(sizeof(struct nbd_request) != 28);
>
> ...perhaps?
Neat, I didn't know about this.
I didn't know about this.
> --Adam
cu
Adrian
<-- snip -->
If we can detect a problem at compile time, the compilation should fail.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.13-mm1-full/drivers/block/nbd.c.old 2005-09-02
23:48:27.0 +0200
+++ linux-2.6.13-mm1-full/drivers/block/nbd.c 2005-09-03 01:08:04.0
+0200
@@ -643,10 +643,7 @@
int err = -ENOMEM;
int i;
- if (sizeof(struct nbd_request) != 28) {
- printk(KERN_CRIT "nbd: sizeof nbd_request needs to be 28 in
order to work!\n" );
- return -EIO;
- }
+ BUILD_BUG_ON(sizeof(struct nbd_request) != 28);
if (nbds_max > MAX_NBD) {
printk(KERN_CRIT "nbd: cannot allocate more than %u nbds; %u
requested.\n", MAX_NBD,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
Kyle Moffett wrote: My far-into-the-future ideal for this is to have a generic vDSO-type library that is compiled into the kernel that provides a collection of architecture-optimized routines available in both kernelspace and userspace by mapping it into each process' address space. Such a library could effectively automatically provide correct and optimized assembly routines for the currently booted CPU/arch/subarch/etc, so that userspace tools could be compiled once and run on an entire family of CPUs without modification. On the other hand, for those applications that need every last ounce of speed (Including parts of the kernel), you could pass appropriate options to the compiler to tell it to inline the assembly routines (alternative) for a single CPU make/model. I don't see why this should be compiled into the kernel. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Inconsistent kallsyms data error near the end of make in the linux kernel-2.6.13
Thanks, that worked for this system. On 9/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Quoting Sabuj Pattanayek <[EMAIL PROTECTED]>: > > > Hi all, > > Hi, Sabuj > > > I'm posting a bug as directed by REPORTING-BUGS in the kernel sources. > > > > PROBLEM: Inconsistent kallsyms data error near the end of make in the linux > > kernel-2.6.13 . > > This is probably a known problem. > > Please check this thread: > > http://lkml.org/lkml/2005/8/31/129 > > and use the patch I posted there. > > I hope this helps, > > -- > Paulo Marques - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: agp_backend_initialize() failed on ServerWorks CNB20LE
On Fri, Sep 02, 2005 at 11:21:39PM +0200, Maciej Soltysiak wrote: > Hello, > > On a server with ServerWorks CNB20LE and CONFIG_AGP_SWORKS enabled > I get these upon bootup: > Linux agpgart interface v0.101 (c) Dave Jones > agpgart: unable to determine aperture size. > agpgart: agp_backend_initialize() failed. > agpgart-serverworks: probe of :00:00.0 failed with error -22 > agpgart: unable to determine aperture size. > agpgart: agp_backend_initialize() failed. > agpgart-serverworks: probe of :00:00.1 failed with error -22 Every time I've seen this reported so far, its turned out that the board doesn't actually have an AGP slot. Is this case here too ? Documentation on serverworks chipsets is as good as non-existant, so there's not a great deal we can do here. > The only problems I have that *may* be related to these messages is the > fact that when I boot into X and try to switch to a text console, the > screen gets garbled and freezes, the server works fine besides the > screen throwing trash at me. Likely completely unrelated. agpgart is used only for accelerated 3d. 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: [PATCH 1/2] pci: Block config access during BIST (resend)
Grant Grundler writes:
> On Fri, Sep 02, 2005 at 06:56:35PM -0500, Brian King wrote:
> > Andrew Morton wrote:
> > >Brian King <[EMAIL PROTECTED]> wrote:
> > >
> > >>+void pci_block_user_cfg_access(struct pci_dev *dev)
> > >>+{
> > >>+ unsigned long flags;
> > >>+
> > >>+ pci_save_state(dev);
> > >>+ spin_lock_irqsave(&pci_lock, flags);
> > >>+ dev->block_ucfg_access = 1;
> > >>+ spin_unlock_irqrestore(&pci_lock, flags);
> > >
> > >
> > >Are you sure the locking in here is meaningful? All it will really do is
> > >give you a couple of barriers.
> >
> > Actually, it is meaningful. It synchronizes the blocking of pci config
> > accesses with other pci config accesses that may be going on when this
> > function is called. Without the locking, the API cannot guarantee that
> > no further user initiated PCI config accesses will be initiated after
> > this function is called.
>
> I don't have the impression you understood what Andrew wrote.
> dev->block_ucfg_access = 1 is essentially an atomic operation.
> AFAIK, Use of the pci_lock doesn't solve any race conditions that mb()
> wouldn't solve.
Think about it. Taking the lock ensures that we don't do the
assignment (dev->block_ucfg_access = 1) while any other cpu has the
pci_lock. In other words, the reason for taking the lock is so that
we wait until nobody else is doing an access, not to make others wait.
> If you had:
> spin_lock_irqsave(&pci_lock, flags);
> pci_save_state(dev);
> dev->block_ucfg_access = 1;
> spin_unlock_irqrestore(&pci_lock, flags);
>
> Then I could buy your arguement since the flag now implies
> we need to atomically save state and set the flag.
That's probably a good thing to do to.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.13-git3 2/5] sis190: recent chipsets from SiS include a RGMII
Extracted from SiS's GPLed driver. From the few pdf available at SiS's,
it seems that the 965 and the 966 south bridge include this interface
whereas the 965L (and anything below) does not. It is expected to be a
sis191 related feature and should not hurt the existing sis190 driver.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN a/drivers/net/sis190.c~sis190-180 b/drivers/net/sis190.c
--- a/drivers/net/sis190.c~sis190-180 2005-09-02 23:27:35.912352373 +0200
+++ b/drivers/net/sis190.c 2005-09-02 23:27:35.917351565 +0200
@@ -279,6 +279,11 @@ enum sis190_eeprom_address {
EEPROMMACAddr = 0x03
};
+enum sis190_feature {
+ F_HAS_RGMII = 1,
+ F_PHY_88E = 2
+};
+
struct sis190_private {
void __iomem *mmio_addr;
struct pci_dev *pci_dev;
@@ -300,6 +305,7 @@ struct sis190_private {
u32 msg_enable;
struct mii_if_info mii_if;
struct list_head first_phy;
+ u32 features;
};
struct sis190_phy {
@@ -321,11 +327,12 @@ static struct mii_chip_info {
const char *name;
u16 id[2];
unsigned int type;
+ u32 feature;
} mii_chip_table[] = {
- { "Broadcom PHY BCM5461", { 0x0020, 0x60c0 }, LAN },
- { "Agere PHY ET1101B",{ 0x0282, 0xf010 }, LAN },
- { "Marvell PHY 88E", { 0x0141, 0x0cc0 }, LAN },
- { "Realtek PHY RTL8201", { 0x, 0x8200 }, LAN },
+ { "Broadcom PHY BCM5461", { 0x0020, 0x60c0 }, LAN, 0 },
+ { "Agere PHY ET1101B",{ 0x0282, 0xf010 }, LAN, 0 },
+ { "Marvell PHY 88E", { 0x0141, 0x0cc0 }, LAN, F_PHY_88E },
+ { "Realtek PHY RTL8201", { 0x, 0x8200 }, LAN, 0 },
{ NULL, }
};
@@ -1309,6 +1316,7 @@ static void sis190_init_phy(struct net_d
phy->type = (p->type == MIX) ?
((mii_status & (BMSR_100FULL | BMSR_100HALF)) ?
LAN : HOME) : p->type;
+ tp->features |= p->feature;
} else
phy->type = UNKNOWN;
@@ -1317,6 +1325,25 @@ static void sis190_init_phy(struct net_d
(phy->type == UNKNOWN) ? "Unknown PHY" : p->name, phy_id);
}
+static void sis190_mii_probe_88e_fixup(struct sis190_private *tp)
+{
+ if (tp->features & F_PHY_88E) {
+ void __iomem *ioaddr = tp->mmio_addr;
+ int phy_id = tp->mii_if.phy_id;
+ u16 reg[2][2] = {
+ { 0x808b, 0x0ce1 },
+ { 0x808f, 0x0c60 }
+ }, *p;
+
+ p = (tp->features & F_HAS_RGMII) ? reg[0] : reg[1];
+
+ mdio_write(ioaddr, phy_id, 0x1b, p[0]);
+ udelay(200);
+ mdio_write(ioaddr, phy_id, 0x14, p[1]);
+ udelay(200);
+ }
+}
+
/**
* sis190_mii_probe - Probe MII PHY for sis190
* @dev: the net device to probe for
@@ -1367,6 +1394,8 @@ static int __devinit sis190_mii_probe(st
/* Select default PHY for mac */
sis190_default_phy(dev);
+ sis190_mii_probe_88e_fixup(tp);
+
mii_if->dev = dev;
mii_if->mdio_read = __mdio_read;
mii_if->mdio_write = __mdio_write;
@@ -1506,6 +1535,11 @@ static void sis190_tx_timeout(struct net
netif_wake_queue(dev);
}
+static void sis190_set_rgmii(struct sis190_private *tp, u8 reg)
+{
+ tp->features |= (reg & 0x80) ? F_HAS_RGMII : 0;
+}
+
static int __devinit sis190_get_mac_addr_from_eeprom(struct pci_dev *pdev,
struct net_device *dev)
{
@@ -1533,6 +1567,8 @@ static int __devinit sis190_get_mac_addr
((u16 *)dev->dev_addr)[0] = le16_to_cpu(w);
}
+ sis190_set_rgmii(tp, sis190_read_eeprom(ioaddr, EEPROMInfo));
+
return 0;
}
@@ -1578,6 +1614,8 @@ static int __devinit sis190_get_mac_addr
outb(0x12, 0x78);
reg = inb(0x79);
+ sis190_set_rgmii(tp, reg);
+
/* Restore the value to ISA Bridge */
pci_write_config_byte(isa_bridge, 0x48, tmp8);
pci_dev_put(isa_bridge);
@@ -1800,6 +1838,9 @@ static int __devinit sis190_init_one(str
dev->dev_addr[2], dev->dev_addr[3],
dev->dev_addr[4], dev->dev_addr[5]);
+ net_probe(tp, KERN_INFO "%s: %s mode.\n", dev->name,
+ (tp->features & F_HAS_RGMII) ? "RGMII" : "GMII");
+
netif_carrier_off(dev);
sis190_set_speed_auto(dev);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.13-git3 1/5] sis190: unmask the link change events
link changes reporting does not work when the driver masks its irq event
Signed-off-by: Arnaud Patard <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN a/drivers/net/sis190.c~sis190-170 b/drivers/net/sis190.c
--- a/drivers/net/sis190.c~sis190-170 2005-09-02 23:27:18.621147267 +0200
+++ b/drivers/net/sis190.c 2005-09-02 23:27:18.643143712 +0200
@@ -360,7 +360,7 @@ MODULE_VERSION(DRV_VERSION);
MODULE_LICENSE("GPL");
static const u32 sis190_intr_mask =
- RxQEmpty | RxQInt | TxQ1Int | TxQ0Int | RxHalt | TxHalt;
+ RxQEmpty | RxQInt | TxQ1Int | TxQ0Int | RxHalt | TxHalt | LinkChange;
/*
* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
@@ -923,6 +923,7 @@ static void sis190_phy_task(void * data)
BMSR_ANEGCOMPLETE)) {
net_link(tp, KERN_WARNING "%s: PHY reset until link up.\n",
dev->name);
+ netif_carrier_off(dev);
mdio_write(ioaddr, phy_id, MII_BMCR, val | BMCR_RESET);
mod_timer(&tp->timer, jiffies + SIS190_PHY_TIMEOUT);
} else {
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.13-git3 5/5] sis190: basic sis191 support
The sis191 is the gigabit brother of the sis190. SiS's driver suggests
that the register set is backward compatible: this should hopefully
give a basic driver.
The device should allow the usual features from a modern ethernet
adapter (802.1q, SG, Jumbo frames, TSO, checksum offload). So far
the relevant register layout is not documented. SiS's driver does
not provide these features either (at least not for Linux).
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN a/drivers/net/sis190.c~sis190-210 b/drivers/net/sis190.c
--- a/drivers/net/sis190.c~sis190-210 2005-09-02 23:28:05.390587495 +0200
+++ b/drivers/net/sis190.c 2005-09-02 23:28:05.396586525 +0200
@@ -331,14 +331,14 @@ static struct mii_chip_info {
const static struct {
const char *name;
- u8 version; /* depend on docs */
- u32 RxConfigMask; /* clear the bits supported by this chip */
} sis_chip_info[] = {
- { DRV_NAME, 0x00, 0xff7e1880, },
+ { "SiS 190 PCI Fast Ethernet adapter" },
+ { "SiS 191 PCI Gigabit Ethernet adapter" },
};
static struct pci_device_id sis190_pci_tbl[] __devinitdata = {
{ PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 },
{ 0, },
};
diff -puN a/drivers/net/Kconfig~sis190-210 b/drivers/net/Kconfig
--- a/drivers/net/Kconfig~sis190-2102005-09-02 23:28:05.393587010 +0200
+++ b/drivers/net/Kconfig 2005-09-02 23:28:05.398586202 +0200
@@ -1924,12 +1924,15 @@ config R8169_VLAN
If in doubt, say Y.
config SIS190
- tristate "SiS190 gigabit ethernet support"
+ tristate "SiS190/SiS191 gigabit ethernet support"
depends on PCI
select CRC32
select MII
---help---
- Say Y here if you have a SiS 190 PCI Gigabit Ethernet adapter.
+ Say Y here if you have a SiS 190 PCI Fast Ethernet adapter or
+ a SiS 191 PCI Gigabit Ethernet adapter. Both are expected to
+ appear in lan on motherboard designs which are based on SiS 965
+ and SiS 966 south bridge.
To compile this driver as a module, choose M here: the module
will be called sis190. This is recommended.
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
Hi Alexey, On Sat, 3 Sep 2005, Alexey Kuznetsov wrote: Well, take a look at the double acks for 84439343, 84440447 and 84441059, they seem pretty much identical to me. It is just a little tcpdump glitch. 19:34:54.532271 < 10.2.20.246.33060 > 65.171.224.182.8700: . 44:44(0) ack 84439343 win 24544 (DF) (ttl 64, id 60946) 19:34:54.532432 < 10.2.20.246.33060 > 65.171.224.182.8700: . 44:44(0) ack 84439343 win 24544 (DF) (ttl 64, id 60946) It is one ACK (look at IP ID), shown twice. This happens sometimes with our packet socket. Ahh... ack. :) That explains it. I understood. I expect when 184*4, when you said 184. But minimum is still 730 (unscaled 1460*2). If you really saw values lower than 730 (unscaled 1460*2), there is another more severe problem and the suggested patch will not solve it. I really did see very small values. This one is plucked from one of today's streams, after a full day's worth of data had passed through it: 19:03:19.659454 10.1.12.11.8001 > 10.2.10.212.56690: P 3:6(3) ack 1 win 65529 (DF) 19:03:19.659462 10.2.10.212.56690 > 10.1.12.11.8001: . ack 6 win 181 (DF) 19:03:20.690719 10.1.12.11.8001 > 10.2.10.212.56690: P 6:9(3) ack 1 win 65529 (DF) 19:03:20.690727 10.2.10.212.56690 > 10.1.12.11.8001: . ack 9 win 181 (DF) 10.1.12.11 is the Win2k box, 10.2.10.212 is the Linux box. The socket buffer sizes are the defaults, so the scaling is most likely 2^2. The packets being exchanged at this point are just heartbeats. On Tuesday I can try to capture a full session from the very begining, if you think it would help. Thanks, -Ion - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GFS, what's remaining
I have to correct an error in perspective, or at least in the wording of it, in the following, because it affects how people see the big picture in trying to decide how the filesystem types in question fit into the world: >Shared storage can be more efficient than network file >systems like NFS because the storage access is often more efficient >than network access The shared storage access _is_ network access. In most cases, it's a fibre channel/FCP network. Nowadays, it's more and more common for it to be a TCP/IP network just like the one folks use for NFS (but carrying ISCSI instead of NFS). It's also been done with a handful of other TCP/IP-based block storage protocols. The reason the storage access is expected to be more efficient than the NFS access is because the block access network protocols are supposed to be more efficient than the file access network protocols. In reality, I'm not sure there really is such a difference in efficiency between the protocols. The demonstrated differences in efficiency, or at least in speed, are due to other things that are different between a given new shared block implementation and a given old shared file implementation. But there's another advantage to shared block over shared file that hasn't been mentioned yet: some people find it easier to manage a pool of blocks than a pool of filesystems. >it is more reliable because it doesn't have a >single point of failure in form of the NFS server. This advantage isn't because it's shared (block) storage, but because it's a distributed filesystem. There are shared storage filesystems (e.g. IBM SANFS, ADIC StorNext) that have a centralized metadata or locking server that makes them unreliable (or unscalable) in the same ways as an NFS server. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13-git3 4/5] sis190: RGMII Tx internal delay fiddling
Don't ask.
The patch is based on SiS's GPLed driver.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN a/drivers/net/sis190.c~sis190-200 b/drivers/net/sis190.c
--- a/drivers/net/sis190.c~sis190-200 2005-09-02 23:27:58.126761637 +0200
+++ b/drivers/net/sis190.c 2005-09-02 23:27:58.130760990 +0200
@@ -273,7 +273,8 @@ enum sis190_eeprom_address {
enum sis190_feature {
F_HAS_RGMII = 1,
- F_PHY_88E = 2
+ F_PHY_88E = 2,
+ F_PHY_BCM5461 = 4
};
struct sis190_private {
@@ -321,7 +322,7 @@ static struct mii_chip_info {
unsigned int type;
u32 feature;
} mii_chip_table[] = {
- { "Broadcom PHY BCM5461", { 0x0020, 0x60c0 }, LAN, 0 },
+ { "Broadcom PHY BCM5461", { 0x0020, 0x60c0 }, LAN, F_PHY_BCM5461 },
{ "Agere PHY ET1101B",{ 0x0282, 0xf010 }, LAN, 0 },
{ "Marvell PHY 88E", { 0x0141, 0x0cc0 }, LAN, F_PHY_88E },
{ "Realtek PHY RTL8201", { 0x, 0x8200 }, LAN, 0 },
@@ -960,8 +961,22 @@ static void sis190_phy_task(void * data)
p->ctl |= SIS_R32(StationControl) & ~0x0f001c00;
+ if ((tp->features & F_HAS_RGMII) &&
+ (tp->features & F_PHY_BCM5461)) {
+ // Set Tx Delay in RGMII mode.
+ mdio_write(ioaddr, phy_id, 0x18, 0xf1c7);
+ udelay(200);
+ mdio_write(ioaddr, phy_id, 0x1c, 0x8c00);
+ p->ctl |= 0x0300;
+ }
+
SIS_W32(StationControl, p->ctl);
+ if (tp->features & F_HAS_RGMII) {
+ SIS_W32(RGDelay, 0x0441);
+ SIS_W32(RGDelay, 0x0440);
+ }
+
net_link(tp, KERN_INFO "%s: link on %s mode.\n", dev->name,
p->msg);
netif_carrier_on(dev);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.13-git3 3/5] sis190: make 10Mbps the default when handling the StationControl register
This patch does three things:
- widen the access to the StationControl register (note the SIS_W16
versus SIS_W32 change);
- default to 10Mbps half duplex when the LPA can not be evaluated
(reg31->ctl is identical for both). It can be argued that it makes
sense as the lowest common denominator when everything else failed.
Btw it works better than the current code. :o)
- remove some enums: they do not document anymore.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN a/drivers/net/sis190.c~sis190-190 b/drivers/net/sis190.c
--- a/drivers/net/sis190.c~sis190-190 2005-09-02 23:27:44.715929373 +0200
+++ b/drivers/net/sis190.c 2005-09-02 23:27:44.741925171 +0200
@@ -179,14 +179,6 @@ enum sis190_register_content {
TxInterFrameGapShift= 24,
TxDMAShift = 8, /* DMA burst value (0-7) is shift this
many bits */
- /* StationControl */
- _1000bpsF = 0x1c00,
- _1000bpsH = 0x0c00,
- _100bpsF= 0x1800,
- _100bpsH= 0x0800,
- _10bpsF = 0x1400,
- _10bpsH = 0x0400,
-
LinkStatus = 0x02, // unused
FullDup = 0x01, // unused
@@ -886,11 +878,6 @@ static void sis190_hw_start(struct net_d
SIS_W32(IntrStatus, 0x);
SIS_W32(IntrMask, 0x0);
- /*
-* Default is 100Mbps.
-* A bit strange: 100Mbps is 0x1801 elsewhere -- FR 2005/06/09
-*/
- SIS_W16(StationControl, 0x1901);
SIS_W32(GMIIControl, 0x0);
SIS_W32(TxMacControl, 0x60);
SIS_W16(RxMacControl, 0x02);
@@ -937,29 +924,23 @@ static void sis190_phy_task(void * data)
/* Rejoice ! */
struct {
int val;
+ u32 ctl;
const char *msg;
- u16 ctl;
} reg31[] = {
- { LPA_1000XFULL | LPA_SLCT,
- "1000 Mbps Full Duplex",
- 0x01 | _1000bpsF },
- { LPA_1000XHALF | LPA_SLCT,
- "1000 Mbps Half Duplex",
- 0x01 | _1000bpsH },
- { LPA_100FULL,
- "100 Mbps Full Duplex",
- 0x01 | _100bpsF },
- { LPA_100HALF,
- "100 Mbps Half Duplex",
- 0x01 | _100bpsH },
- { LPA_10FULL,
- "10 Mbps Full Duplex",
- 0x01 | _10bpsF },
- { LPA_10HALF,
- "10 Mbps Half Duplex",
- 0x01 | _10bpsH },
- { 0, "unknown", 0x }
- }, *p;
+ { LPA_1000XFULL | LPA_SLCT, 0x07000c00 | 0x1000,
+ "1000 Mbps Full Duplex" },
+ { LPA_1000XHALF | LPA_SLCT, 0x07000c00,
+ "1000 Mbps Half Duplex" },
+ { LPA_100FULL, 0x04000800 | 0x1000,
+ "100 Mbps Full Duplex" },
+ { LPA_100HALF, 0x04000800,
+ "100 Mbps Half Duplex" },
+ { LPA_10FULL, 0x04000400 | 0x1000,
+ "10 Mbps Full Duplex" },
+ { LPA_10HALF, 0x04000400,
+ "10 Mbps Half Duplex" },
+ { 0, 0x04000400, "unknown" }
+ }, *p;
u16 adv;
val = mdio_read(ioaddr, phy_id, 0x1f);
@@ -972,12 +953,15 @@ static void sis190_phy_task(void * data)
val &= adv;
- for (p = reg31; p->ctl; p++) {
+ for (p = reg31; p->val; p++) {
if ((val & p->val) == p->val)
break;
}
- if (p->ctl)
- SIS_W16(StationControl, p->ctl);
+
+ p->ctl |= SIS_R32(StationControl) & ~0x0f001c00;
+
+ SIS_W32(StationControl, p->ctl);
+
net_link(tp, KERN_INFO "%s: link on %s mode.\n", dev->name,
p->msg);
netif_carrier_on(dev);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm1
On 09.02, Andrew Morton wrote:
> "J.A. Magallon" <[EMAIL PROTECTED]> wrote:
> >
> >
> > On 09.02, Andrew Morton wrote:
> > > "J.A. Magallon" <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > On 1/09/2005 10:58 a.m., Andrew Morton wrote:
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> > > > >
> > > > > - Included Alan's big tty layer buffering rewrite. This breaks the
> > > > > build on
> > > > > lots of more obscure character device drivers. Patches welcome
> > > > > (please cc
> > > > > Alan).
> > > > >
> > > >
> > > > I have problems with udev and latest -mm.
> > > > 2.6.13 boots fine, but 2.6.13-mm1 blocks when starting udev.
> > > > System is Mandriva Cooker. As cooker, things are changing fast
> > > > (initscripts,
> > > > udev, etc), but the fact is that with the same setup, plain .13 boots
> > > > and -mm1 blocks. Udev is 068 version.
> > > >
> > > > Any idea about what can be the reason ?
> > > >
> > >
> > > There's some suspect locking in the /proc/devices seq_file conversion
> > > code.
> > >
> > > Could you revert convert-proc-devices-to-use-seq_file-interface-fix.patch
> > > then convert-proc-devices-to-use-seq_file-interface.patch?
> > >
> >
> > Still the same result, system bocks starting udev...
> >
>
> OK, thanks. Nothing from sysrq-t? Does the below help?
>
> ---
> devel/fs/sysfs/file.c~gregkh-driver-sysfs-strip_leading_trailing_whitespace-fix
>2005-09-02 04:01:40.0 -0700
> +++ devel-akpm/fs/sysfs/file.c2005-09-02 04:05:02.0 -0700
> @@ -202,13 +202,14 @@ fill_write_buffer(struct sysfs_buffer *
> * passing the buffer that we acquired in fill_write_buffer().
> */
>
> -static int
> -flush_write_buffer(struct dentry * dentry, struct sysfs_buffer * buffer,
> size_t count)
> +static int flush_write_buffer(struct dentry *dentry,
> + struct sysfs_buffer *buffer, size_t count_in)
> {
> struct attribute * attr = to_attr(dentry);
> struct kobject * kobj = to_kobj(dentry->d_parent);
> struct sysfs_ops * ops = buffer->ops;
> char *x;
> + size_t count = count_in;
>
> /* locate trailing white space */
> while ((count > 0) && isspace(buffer->page[count - 1]))
> @@ -224,7 +225,8 @@ flush_write_buffer(struct dentry * dentr
> /* terminate the string */
> x[count] = '\0';
>
> - return ops->store(kobj, attr, x, count);
> + ops->store(kobj, attr, x, count);
> + return count_in;
> }
>
Bingo !.
That did the trink. Booting fine again.
I meant, just with this, without reverting the other 2 patches.
Thanks !
--
J.A. Magallon \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.13-jam2 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.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/
sis190/sis191 driver
A new patch-kit is available. o Fix link event reporting (Arnaud Patard). o Default to 10Mbps when nothing better can be detected (me). o Experimental sis191 support + small rgmii changes. Please report anything related to link management you are not satisfied with. You can report success as well. Testers for the sis191 part will be welcome too. I expect this part to appear on recent (?) SiS 96x based motherboard. Please send a complete lspci -vx if you own such a beast. The patch-kit for 2.6.13 is available at the URLs below. If you are working with a recent 2.6.13-git, you should start at sis190-170.patch since anything else is already merged. The patches against 2.6.13-git3 (hello Jeff) will be posted in the upcoming messages in a few minutes. Single file patch (for plain 2.6.13): http://www.zoreil.com/~romieu/sis190/20050902-2.6.13-sis190-test.patch Patch-kit (sic): http://www.zoreil.com/~romieu/sis190/20050902-2.6.13/patches Tarball (sic): http://www.zoreil.com/~romieu/sis190/20050902-2.6.13.tar.bz2 -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] drivers/block/nbd.c: don't defer compile error to runtime
Adrian Bunk wrote:
> If we can detect a problem at compile time, the compilation should
> fail.
[...]
> if (sizeof(struct nbd_request) != 28) {
> - printk(KERN_CRIT "nbd: sizeof nbd_request needs to be 28 in
> order to work!\n" );
> - return -EIO;
> + extern void nbd_request_wrong_size(void);
> + nbd_request_wrong_size();
BUILD_BUG_ON(sizeof(struct nbd_request) != 28);
...perhaps?
--Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] RT: Invert some TRACE_BUG_ON_LOCKED tests
On Fri, 2005-09-02 at 18:40 -0400, Steven Rostedt wrote:
> On Fri, 2005-09-02 at 13:08 -0700, Tom Rini wrote:
> > With 2.6.13-rt4 I had to do the following in order to get my paired down
> > config booting on my x86 whitebox (defconfig works fine, after I enable
> > enet/8250_console/nfsroot). Daniel Walker helped me trace this down.
>
>
> Ingo, I guess we need a TRACE_BUG_ON_LOCKED_SMP() macro.
Tom,
try this patch instead. It removes the tests of the spin_is_locked on
UP.
-- Steve
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Index: linux_realtime_goliath/kernel/rt.c
===
--- linux_realtime_goliath/kernel/rt.c (revision 315)
+++ linux_realtime_goliath/kernel/rt.c (working copy)
@@ -215,6 +215,16 @@
TRACE_BUG_LOCKED(); \
} while (0)
+#ifdef CONFIG_SMP
+# define TRACE_BUG_ON_LOCKED_SMP(c)\
+do { \
+ if (unlikely(c))\
+ TRACE_BUG_LOCKED(); \
+} while (0)
+#else
+# define TRACE_BUG_ON_LOCKED_SMP(c)do { } while (0)
+#endif
+
# define trace_local_irq_disable(ti) raw_local_irq_disable()
# define trace_local_irq_enable(ti)raw_local_irq_enable()
# define trace_local_irq_restore(flags, ti)raw_local_irq_restore(flags)
@@ -237,6 +247,7 @@
# define TRACE_WARN_ON_LOCKED(c) do { } while (0)
# define TRACE_OFF() do { } while (0)
# define TRACE_BUG_ON_LOCKED(c)do { } while (0)
+# define TRACE_BUG_ON_LOCKED_SMP(c)do { } while (0)
#endif /* CONFIG_RT_DEADLOCK_DETECT */
@@ -736,8 +747,8 @@
if (old_owner == new_owner)
return;
- TRACE_BUG_ON_LOCKED(!spin_is_locked(&old_owner->task->pi_lock));
- TRACE_BUG_ON_LOCKED(!spin_is_locked(&new_owner->task->pi_lock));
+ TRACE_BUG_ON_LOCKED_SMP(!spin_is_locked(&old_owner->task->pi_lock));
+ TRACE_BUG_ON_LOCKED_SMP(!spin_is_locked(&new_owner->task->pi_lock));
plist_for_each_safe(curr1, next1, &old_owner->task->pi_waiters) {
w = plist_entry(curr1, struct rt_mutex_waiter, pi_list);
if (w->lock == lock) {
@@ -770,8 +781,8 @@
return;
}
- TRACE_BUG_ON_LOCKED(!spin_is_locked(&lock->wait_lock));
- TRACE_BUG_ON_LOCKED(!spin_is_locked(&p->pi_lock));
+ TRACE_BUG_ON_LOCKED_SMP(!spin_is_locked(&lock->wait_lock));
+ TRACE_BUG_ON_LOCKED_SMP(!spin_is_locked(&p->pi_lock));
#ifdef CONFIG_RT_DEADLOCK_DETECT
pi_prio++;
if (p->policy != SCHED_NORMAL && prio > normal_prio(p)) {
@@ -967,8 +978,8 @@
/*
* Add SCHED_NORMAL tasks to the end of the waitqueue (FIFO):
*/
- TRACE_BUG_ON_LOCKED(!spin_is_locked(&task->pi_lock));
- TRACE_BUG_ON_LOCKED(!spin_is_locked(&lock->wait_lock));
+ TRACE_BUG_ON_LOCKED_SMP(!spin_is_locked(&task->pi_lock));
+ TRACE_BUG_ON_LOCKED_SMP(!spin_is_locked(&lock->wait_lock));
#if !ALL_TASKS_PI
if (!rt_task(task)) {
plist_add(&waiter->list, &lock->wait_list);
@@ -1070,7 +1081,7 @@
struct rt_mutex_waiter *waiter = NULL;
struct thread_info *new_owner;
- TRACE_BUG_ON_LOCKED(!spin_is_locked(&lock->wait_lock));
+ TRACE_BUG_ON_LOCKED_SMP(!spin_is_locked(&lock->wait_lock));
/*
* Get the highest prio one:
*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
UML x86_86 Multicast Patch
Just a silly error. In mcast_user.c from /usr/src/linux-2.6.13/arch/um/drivers when multicast is enabled it cannot pass the "compile kernel" phase. The following patch should fix the error. Please correct me if I'm wrong. --- /tmp/mcast_user.c 2005-09-03 19:59:15.0 -0300 +++ mcast_user.c2005-09-03 19:59:32.0 -0300 @@ -13,7 +13,7 @@ #include #include -#include +//#include #include #include #include -- Alan Menegotto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Splitting out kernel<=>userspace ABI headers
On Sep 2, 2005, at 17:55:54, H. Peter Anvin wrote:
UML really needs something like this, both 1 and 2. See
http://groups.google.com/group/fa.linux.kernel/browse_thread/
thread/34d3c02372861a5c/71816a3c7863ea2b?lnk=st&q=%22jeff+dike%
22&rnum=27&hl=en#71816a3c7863ea2b
for my take on system.h and ptrace.h when a change in the host
architecture broke the UML build.
UML takes most of its headers from the underlying arch. It
simplifies
things since most of the definitions are usable in UML. I don't have
to clone and maintain my versions of all the other arch headers.
OTOH, there are things in those headers which UML can't use, and
these
are eliminated in various ways (undefining them after the include of
the host arch header, redefining them before the include). But this
is a pain.
It has long been my opinion that splitting headers into userspace
usable and userspace unusable pieces is the right thing for UML.
Less
clear for the host arch.
Your post seems to indicate that there is a non-UML demand for
exactly
this.
There definitely is. The kernel needs to export its ABI in a way that
userspace (UML, various libcs, etc) can import in a sane manner. In
addition, the Linux kernel contains a fair bit of
architecture-specific support which go well beyond what one can
typically find in userspace, and it would be nice to have those.
The current linux-libc-headers aren't it, because they have a fair bit
of glibc-centric assumptions in those headers. That's part of why
klibc doesn't use them.
What I would try to do is package up as much architecture/abi knowledge
in one place as possible, the former in kcore/kern-core/whatever, the
latter in kabi/kern-abi/linux-abi/whatever. I would also try (as much
as possible), to make everything in those directories use some kind of
prefix guaranteed not to clash with other stuff, so list_add() for
example would become _kcore_list_add(). The linux kernel headers in
such a modified kernel would then just do this to make the kernel code
happy:
#ifdef __KERNEL__
# define list_add(x,y) _kcore_list_add(x,y)
/**/
#endif
My far-into-the-future ideal for this is to have a generic vDSO-type
library that is compiled into the kernel that provides a collection of
architecture-optimized routines available in both kernelspace and
userspace by mapping it into each process' address space. Such a
library could effectively automatically provide correct and optimized
assembly routines for the currently booted CPU/arch/subarch/etc, so
that userspace tools could be compiled once and run on an entire
family of CPUs without modification. On the other hand, for those
applications that need every last ounce of speed (Including parts of
the kernel), you could pass appropriate options to the compiler to
tell it to inline the assembly routines (alternative) for a single
CPU make/model.
Possibly some of the generic-arch stuff should be pushed back
upstream to GCC, maybe have __builtin_{s,u,i,f}{8,16,32,64,128} types,
etc, provided directly by GCC, so we don't have to mess with that
so much.
We should probably also consider the licensing of headers that are
meant to be included into userspace. Userspace still includes a fair
bit of GPL headers, which is technically not kosher.
I think that this is mostly a nonissue. The copyright holders of the
headers/inline assembly/etc should look at perhaps licensing those
as LGPL or providing an exception to allow glibc, klibc, etc to link
with them. On the other hand, were glibc to use the optimized
routines to provide the Standard C Library, programs using said
Standard C Library would not be infringing, because just like with
the "userspace <=syscall=> kernelspace" boundary, that does not imply
that the code is a derived work. IANAL, however, so if you know one
who is willing to contribute some time, this might be an interesting
issue. (Also: What procedure might be required to get some of the
stuff relicensed as LGPL? How do we find all significant copyright
holders/contributors from whom we need permission?)
Thanks for the encouraging posts! It's good to hear that others are
interested in the project, because maybe I won't need to do it _all_
myself :-D. I'll take a look at the patches mentioned, to get more
of an idea on the various technical issues.
Cheers,
Kyle Moffett
--
Simple things should be simple and complex things should be possible
-- Alan Kay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fix some warnings in sound
Some drivers don't control return values, that can fail.
Generated in 2.6.13-mm1 kernel version.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
ali5451/ali5451.c |3 ++-
cs46xx/cs46xx_lib.c |6 --
via82xx.c |8 +---
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/sound/pci/ali5451/ali5451.c b/sound/pci/ali5451/ali5451.c
--- a/sound/pci/ali5451/ali5451.c
+++ b/sound/pci/ali5451/ali5451.c
@@ -2067,7 +2067,8 @@ static int ali_resume(snd_card_t *card)
if (! im)
return 0;
- pci_enable_device(chip->pci);
+ if ((i = pci_enable_device(chip->pci)))
+ return i;
spin_lock_irq(&chip->reg_lock);
diff --git a/sound/pci/cs46xx/cs46xx_lib.c b/sound/pci/cs46xx/cs46xx_lib.c
--- a/sound/pci/cs46xx/cs46xx_lib.c
+++ b/sound/pci/cs46xx/cs46xx_lib.c
@@ -3722,9 +3722,11 @@ static int snd_cs46xx_suspend(snd_card_t
static int snd_cs46xx_resume(snd_card_t *card)
{
cs46xx_t *chip = card->pm_private_data;
- int amp_saved;
+ int amp_saved, err;
+
+ if ((err = pci_enable_device(chip->pci)))
+ return err;
- pci_enable_device(chip->pci);
pci_set_master(chip->pci);
amp_saved = chip->amplifier;
chip->amplifier = 0;
diff --git a/sound/pci/via82xx.c b/sound/pci/via82xx.c
--- a/sound/pci/via82xx.c
+++ b/sound/pci/via82xx.c
@@ -1977,7 +1977,8 @@ static int snd_via82xx_suspend(snd_card_
chip->capture_src_saved[1] = inb(chip->port +
VIA_REG_CAPTURE_CHANNEL + 0x10);
}
- pci_set_power_state(chip->pci, 3);
+ if ((i = pci_set_power_state(chip->pci, 3)))
+ return i;
pci_disable_device(chip->pci);
return 0;
}
@@ -1987,8 +1988,9 @@ static int snd_via82xx_resume(snd_card_t
via82xx_t *chip = card->pm_private_data;
int i;
- pci_enable_device(chip->pci);
- pci_set_power_state(chip->pci, 0);
+ if ((i = pci_enable_device(chip->pci)) ||
+ (i = pci_set_power_state(chip->pci, 0)))
+ return i;
snd_via82xx_chip_init(chip);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hotswap support for libata
Hi Luke I was wandering whether you could direct me to a place where I could find the most up to date patches for libata hotplug support you authored. Has Jeff Garzik decided to integrate this code to 2.6 libata ? Thanks Ravi -- Ravi Wijayaratne Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] RT: Invert some TRACE_BUG_ON_LOCKED tests
On Fri, 2005-09-02 at 13:08 -0700, Tom Rini wrote: > With 2.6.13-rt4 I had to do the following in order to get my paired down > config booting on my x86 whitebox (defconfig works fine, after I enable > enet/8250_console/nfsroot). Daniel Walker helped me trace this down. Tom, TRACE_BUG_ON_LOCKED(!spin_is_locked(&lock->wait_lock)); _is_ correct. Those locks must be locked at those cases. If it isn't then we wan't to trigger a bug. Hence the "BUG_ON" part. You can never guarantee that a lock will be unlock since another process on another CPU might have it. Now if you are getting a BUG, where as one of these places the lock is _not_ held, then that's a bug. Hmm, I wonder if these should be switched to __raw_spin_is_locked. Oh wait, is this a UP system? Shoot, spin_is_locked on UP is defined as zero so this _would_ trigger. Ouch! Ingo, I guess we need a TRACE_BUG_ON_LOCKED_SMP() macro. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] pci: Block config access during BIST (resend)
On Fri, Sep 02, 2005 at 06:56:35PM -0500, Brian King wrote:
> Andrew Morton wrote:
> >Brian King <[EMAIL PROTECTED]> wrote:
> >
> >>+void pci_block_user_cfg_access(struct pci_dev *dev)
> >>+{
> >>+ unsigned long flags;
> >>+
> >>+ pci_save_state(dev);
> >>+ spin_lock_irqsave(&pci_lock, flags);
> >>+ dev->block_ucfg_access = 1;
> >>+ spin_unlock_irqrestore(&pci_lock, flags);
> >
> >
> >Are you sure the locking in here is meaningful? All it will really do is
> >give you a couple of barriers.
>
> Actually, it is meaningful. It synchronizes the blocking of pci config
> accesses with other pci config accesses that may be going on when this
> function is called. Without the locking, the API cannot guarantee that
> no further user initiated PCI config accesses will be initiated after
> this function is called.
I don't have the impression you understood what Andrew wrote.
dev->block_ucfg_access = 1 is essentially an atomic operation.
AFAIK, Use of the pci_lock doesn't solve any race conditions that mb()
wouldn't solve.
If you had:
spin_lock_irqsave(&pci_lock, flags);
pci_save_state(dev);
dev->block_ucfg_access = 1;
spin_unlock_irqrestore(&pci_lock, flags);
Then I could buy your arguement since the flag now implies
we need to atomically save state and set the flag.
grant
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > Hi Andrew! > > Do you plan to send FUSE to Linus for 2.6.14? Haven't thought about it all much. Have spent most of my time in the last month admiring the contents of kernel bugzilla, and the ongoing attempts to increase them. > I know you have some doubts about usefulness, etc. Here are a couple > of facts, that I hope show that Linux should benefit from having FUSE: > > - total number of downloads from SF: ~25000 > > - number of downloads of last release (during 3 months): ~7000 > > - number of distros carrying official packages: 2 (debian, gentoo) > > - number of publicly available filesystems known: 27 > > - of which at least 2 are carried by debian (and maybe others) > > - number of language bindings: 7 (native: C, java, python, perl, C#, sh, TCL) > > - biggest known commercial user: ~110TB exported, total bandwidth: 1.5TB/s > > - mailing list traffic 100-200 messages/month > > - have been in -mm since 2005 january > I agree that lots of people would like the functionality. I regret that although it appears that v9fs could provide it, there seems to be no interest in working on that. The main sticking point with FUSE remains the permission tricks around fuse_allow_task(). AFAIK it remains the case that nobody has come up with any better idea, so I'm inclined to merge the thing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] arch-sh csum_partial_copy_generic() bugfix
Adrian Bunk wrote: On Fri, Sep 02, 2005 at 10:26:56AM -0700, Ollie Wild wrote: It's been about a week since I posted this bug report, and I haven't gotten any responses. Is there someone I should contact directly? Can someone please point me in the right direction? The MAINTAINERS file in the kernel sources contains the following contact information for the sh port: Thanks. Ollie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] arch-sh csum_partial_copy_generic() bugfix
On Fri, Sep 02, 2005 at 10:26:56AM -0700, Ollie Wild wrote: > It's been about a week since I posted this bug report, and I haven't > gotten any responses. Is there someone I should contact directly? Can > someone please point me in the right direction? The MAINTAINERS file in the kernel sources contains the following contact information for the sh port: SUPERH (sh) P: Paul Mundt M: [EMAIL PROTECTED] P: Kazumoto Kojima M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.linux-sh.org W: http://www.m17n.org/linux-sh/ W: http://www.rr.iij4u.or.jp/~kkojima/linux-sh4.html S: Maintained > Thanks, > Ollie >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] Documentation/arm/README: small update
On Sun, Aug 28, 2005 at 06:17:50PM +0100, Russell King wrote: > On Wed, Aug 24, 2005 at 12:36:53PM +0200, Adrian Bunk wrote: > > - egcs is not supported by kernel 2.6 > > Ok. > > > - Am I right to assume that gcc 2.95.3 is not worse than gcc 2.95.1? > > No idea - I've given up tracking what compilers work and don't work on > the grounds that I'm too scared to change my compiler! gcc 3.3 works > fine here which is the only version I use (until it's proven far too > buggy through local experience). > > That probably means we should say "at least GCC 3.3" though I'm not > sure if that's entirely accurate. > > Toolchains are just pure evil as far as stability on ARM goes. What about the patch below to simply recommend gcc 3.3? It doesn't imply other compilers weren't usable and removes the references to the older compilers. > Russell King cu Adrian <-- snip --> - egcs is not supported by kernel 2.6 - gcc 3.3 seems to be a good choice on ARM Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.13-mm1-full/Documentation/arm/README.old 2005-09-03 00:02:55.0 +0200 +++ linux-2.6.13-mm1-full/Documentation/arm/README 2005-09-03 00:03:51.0 +0200 @@ -8,10 +8,9 @@ - In order to compile ARM Linux, you will need a compiler capable of - generating ARM ELF code with GNU extensions. GCC 2.95.1, EGCS - 1.1.2, and GCC 3.3 are known to be good compilers. Fortunately, you - needn't guess. The kernel will report an error if your compiler is - a recognized offender. + generating ARM ELF code with GNU extensions. GCC 3.3 is known to be + a good compiler. Fortunately, you needn't guess. The kernel will report + an error if your compiler is a recognized offender. To build ARM Linux natively, you shouldn't have to alter the ARCH = line in the top level Makefile. However, if you don't have the ARM Linux ELF - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 07/11] memory hotplug: sysfs and add/remove functions
On Fri, 2005-09-02 at 15:13 -0700, Andrew Morton wrote:
> Dave Hansen <[EMAIL PROTECTED]> wrote:
> >
> > + for (i = 0; i < PAGES_PER_SECTION; i++) {
> > + if (PageReserved(first_page+i))
> > + continue;
>
> How intimate do these patches get with PageReserved()? Bear in mind that
> we're slowly working toward making PageReserved go away.
It's basically the same way that the init code uses it. When
initialized, a struct page has it set. In theory, an architecture could
decide to keep the bit set when it is doing online_pages(). However, I
don't think any do that today. Nobody would really notice if we killed
that. That check could probably instead be something like
page_is_ram().
-- 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/
