Re: Resetting a PCI device
Not generally. Systems that support hot-plug PCI also have the ability to reset individual PCI slots (ISTR that it's a requirement). Sadly, this facility is not generally available on "normal" systems. Tim On Fri, Apr 27, 2001 at 10:52:20AM +0100, [EMAIL PROTECTED] wrote: > Is there any way of issuing a PCI reset (safely) without rebooting? I am > developing a peripheral device (using a pci card with an FPGA and a plx9080 > pci interface), and find that its local bus is prone to hanging up. It > would be nice if I could just reset the entire device via the PCI reset, > without having to go through the hassle of a reboot. Is this wishful > thinking? > > - Dave > > - > Dave Fraser > Development Engineer > BAE Systems, Ferry Road, > Edinburgh, EH5 2XS > Tel: +44 131 3434729 > Fax: +44 131 3434124 > - > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Resetting a PCI device
Not generally. Systems that support hot-plug PCI also have the ability to reset individual PCI slots (ISTR that it's a requirement). Sadly, this facility is not generally available on normal systems. Tim On Fri, Apr 27, 2001 at 10:52:20AM +0100, [EMAIL PROTECTED] wrote: Is there any way of issuing a PCI reset (safely) without rebooting? I am developing a peripheral device (using a pci card with an FPGA and a plx9080 pci interface), and find that its local bus is prone to hanging up. It would be nice if I could just reset the entire device via the PCI reset, without having to go through the hassle of a reboot. Is this wishful thinking? - Dave - Dave Fraser Development Engineer BAE Systems, Ferry Road, Edinburgh, EH5 2XS Tel: +44 131 3434729 Fax: +44 131 3434124 - - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ Nobody ever said I was charming, they said Rimmer, you're a git! RD VI - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with i810_audio driver
On Mon, Apr 23, 2001 at 10:54:35PM -0400, Doug Ledford wrote: [...] > > Both B and C are cases of the whole chip acting flat busted. I would suspect > that possibly Win2k drivers set this thing up some way that we don't recover > from. H... quite possible. It's certainly true that a soft reboot from win2k leaves the cs42xx stuff screwed on my Thinkpad T20 so it wouldn't be surprising to hear of issues with other sound chips. I need to get around to dumping the registers in the good and bad case to determine what on earth it futzed with and undo it. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with i810_audio driver
On Mon, Apr 23, 2001 at 10:54:35PM -0400, Doug Ledford wrote: [...] Both B and C are cases of the whole chip acting flat busted. I would suspect that possibly Win2k drivers set this thing up some way that we don't recover from. H... quite possible. It's certainly true that a soft reboot from win2k leaves the cs42xx stuff screwed on my Thinkpad T20 so it wouldn't be surprising to hear of issues with other sound chips. I need to get around to dumping the registers in the good and bad case to determine what on earth it futzed with and undo it. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ Nobody ever said I was charming, they said Rimmer, you're a git! RD VI - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.5 Workshop RealVideo streams -- next time, please get better audio.
So grab and install dsproxy (http://freshmeat.net/projects/dsproxy/), and capture the output. Than feed to e.g. XMMS which already has an AGC plugin. t On Wed, Apr 18, 2001 at 01:44:32PM +0100, Alan Cox wrote: > > So my question is, what would it take to get some automatic software > > volume correction going. This looks like it would be the easiest fix > > of all. > > Unfortunately its encoded in a proprietary format otherwise it would have > been perhaps half an hours work to write an AGC filter for the data. > > Alan > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.5 Workshop RealVideo streams -- next time, please get better audio.
So grab and install dsproxy (http://freshmeat.net/projects/dsproxy/), and capture the output. Than feed to e.g. XMMS which already has an AGC plugin. t On Wed, Apr 18, 2001 at 01:44:32PM +0100, Alan Cox wrote: So my question is, what would it take to get some automatic software volume correction going. This looks like it would be the easiest fix of all. Unfortunately its encoded in a proprietary format otherwise it would have been perhaps half an hours work to write an AGC filter for the data. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 rw_semaphores fix
Sequent Symmetry machinses supported SMP on i486 and even i386 going back to the original 16MHz 386 processors. You could put up to 30 in a system. I do not, however, envisage anyone porting Linux to these any time soon. The hardware is just too "unusual" for it to be feasible. The later Symmetry 5000 machines might be slightly more practical, but I'm not sure if you'd have room in your new house for one. You could probably do without central heating if we did send you one :-) Tim On Tue, Apr 10, 2001 at 10:57:09PM +0100, Alan Cox wrote: > > That's no problem if we make this SMP-specific - I doubt anybody actually > > uses SMP on i486's even if the machines exist, as I think they all had > > They do. There are two (total world wide) 486 SMP users I know about and they > mostly do it to be awkward ;) > > > special glue logic that Linux would have trouble with anyway. But the > > The Compaqs were custom, the non Compaq ones included several using Intel > MP 1.1. > > Alan > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 rw_semaphores fix
Sequent Symmetry machinses supported SMP on i486 and even i386 going back to the original 16MHz 386 processors. You could put up to 30 in a system. I do not, however, envisage anyone porting Linux to these any time soon. The hardware is just too "unusual" for it to be feasible. The later Symmetry 5000 machines might be slightly more practical, but I'm not sure if you'd have room in your new house for one. You could probably do without central heating if we did send you one :-) Tim On Tue, Apr 10, 2001 at 10:57:09PM +0100, Alan Cox wrote: That's no problem if we make this SMP-specific - I doubt anybody actually uses SMP on i486's even if the machines exist, as I think they all had They do. There are two (total world wide) 486 SMP users I know about and they mostly do it to be awkward ;) special glue logic that Linux would have trouble with anyway. But the The Compaqs were custom, the non Compaq ones included several using Intel MP 1.1. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: uninteruptable sleep (D state => load_avrg++)
On Wed, Apr 04, 2001 at 02:13:49PM +0200, christophe barbe wrote: > The sleep should certainly be interruptible and I that's what I said to the GFS guy. > But what the reason to increment the load average for each D process ? > OK, the Unix history goes something like this. Synchronization was achieved using two primitives, sleep() and wakeup(). These guys rendezvous'd on a wait channel, which was simply an 'int', and by convention was actually the address of a data structure (yes I know int and pointers aren't the same, this is a long time ago, OK ? :-). Anyway, when you called sleep, you also had an associated priority. Priority values less than PZERO were "high" priority, and >= PZERO were "low" priority. sleeping above PZERO was interruptible, and processes sleeping at this priority did not count towards the load. The idea was to use this for events that potentially might never happen. Sleeping at a priority < PZERO was intended to be used for things that are absolutely 100% guaranteed to happen, preferably sometime very soon. Disk I/O (real disks, not NFS) fell into this category, and hence it counts towards the load since this could be deemed a "fast wait" state, and the process is nominally runnable. All a bit hand-wavy I know, but it worked well enough. The really important part of all this is that you should never sleep uninterruptibly for anything that you cannot absolutely guarantee will happen, otherwise you wind up with a stuck process. Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a quest for a better scheduler
On Wed, Apr 04, 2001 at 03:23:34PM +0200, Ingo Molnar wrote: > > On Wed, 4 Apr 2001, Hubertus Franke wrote: > > > I understand the dilemma that the Linux scheduler is in, namely > > satisfy the low end at all cost. [...] > > nope. The goal is to satisfy runnable processes in the range of NR_CPUS. > You are playing word games by suggesting that the current behavior prefers > 'low end'. 'thousands of runnable processes' is not 'high end' at all, > it's 'broken end'. Thousands of runnable processes are the sign of a > broken application design, and 'fixing' the scheduler to perform better in > that case is just fixing the symptom. [changing the scheduler to perform > better in such situations is possible too, but all solutions proposed so > far had strings attached.] > Ingo, you continue to assert this without giving much evidence to back it up. All the world is not a web server. If I'm running a large OLTP database with thousands of clients, it's not at all unreasonable to expect periods where several hundred (forget the thousands) want to be serviced by the database engine. That sounds like hundreds of schedulable entities be they processes or threads or whatever. This sort of load is regularly run on machine with 16-64 CPUs. Now I will admit that it is conceivable that you can design an application that finds out how many CPUs are available, creates threads to match that number and tries to divvy up the work between them using some combination of polling and asynchronous I/O etc. There are, however a number of problems with this approach: 1) It assumes that this is the only workload on the machine. If not it quickly becomes sub-optimal due to interactions between the workloads. This is a problem that the kernel scheduler does not suffer from. 2) It requires *every* application designer to design an effective scheduler into their application. I would submit that an effective scheduler is better situated in the operating system. 3) It is not a familiar programming paradigm to many Unix/Linux/POSIX programmers, so you have a sort of impedance mismatch going on. Since the proposed scheduler changes being talked about here have been shown to not hurt the "low end" and to dramatically improve the "high end", I fail to understand the hostility to the changes. I can understand that you do not feel that this is the correct way to architect an application, but if the changes don't hurt you, why sabotage changes that also allow a different method to work. There isn't one true way to do anything in computing. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a quest for a better scheduler
On Wed, Apr 04, 2001 at 03:23:34PM +0200, Ingo Molnar wrote: On Wed, 4 Apr 2001, Hubertus Franke wrote: I understand the dilemma that the Linux scheduler is in, namely satisfy the low end at all cost. [...] nope. The goal is to satisfy runnable processes in the range of NR_CPUS. You are playing word games by suggesting that the current behavior prefers 'low end'. 'thousands of runnable processes' is not 'high end' at all, it's 'broken end'. Thousands of runnable processes are the sign of a broken application design, and 'fixing' the scheduler to perform better in that case is just fixing the symptom. [changing the scheduler to perform better in such situations is possible too, but all solutions proposed so far had strings attached.] Ingo, you continue to assert this without giving much evidence to back it up. All the world is not a web server. If I'm running a large OLTP database with thousands of clients, it's not at all unreasonable to expect periods where several hundred (forget the thousands) want to be serviced by the database engine. That sounds like hundreds of schedulable entities be they processes or threads or whatever. This sort of load is regularly run on machine with 16-64 CPUs. Now I will admit that it is conceivable that you can design an application that finds out how many CPUs are available, creates threads to match that number and tries to divvy up the work between them using some combination of polling and asynchronous I/O etc. There are, however a number of problems with this approach: 1) It assumes that this is the only workload on the machine. If not it quickly becomes sub-optimal due to interactions between the workloads. This is a problem that the kernel scheduler does not suffer from. 2) It requires *every* application designer to design an effective scheduler into their application. I would submit that an effective scheduler is better situated in the operating system. 3) It is not a familiar programming paradigm to many Unix/Linux/POSIX programmers, so you have a sort of impedance mismatch going on. Since the proposed scheduler changes being talked about here have been shown to not hurt the "low end" and to dramatically improve the "high end", I fail to understand the hostility to the changes. I can understand that you do not feel that this is the correct way to architect an application, but if the changes don't hurt you, why sabotage changes that also allow a different method to work. There isn't one true way to do anything in computing. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: uninteruptable sleep (D state = load_avrg++)
On Wed, Apr 04, 2001 at 02:13:49PM +0200, christophe barbe wrote: The sleep should certainly be interruptible and I that's what I said to the GFS guy. But what the reason to increment the load average for each D process ? OK, the Unix history goes something like this. Synchronization was achieved using two primitives, sleep() and wakeup(). These guys rendezvous'd on a wait channel, which was simply an 'int', and by convention was actually the address of a data structure (yes I know int and pointers aren't the same, this is a long time ago, OK ? :-). Anyway, when you called sleep, you also had an associated priority. Priority values less than PZERO were "high" priority, and = PZERO were "low" priority. sleeping above PZERO was interruptible, and processes sleeping at this priority did not count towards the load. The idea was to use this for events that potentially might never happen. Sleeping at a priority PZERO was intended to be used for things that are absolutely 100% guaranteed to happen, preferably sometime very soon. Disk I/O (real disks, not NFS) fell into this category, and hence it counts towards the load since this could be deemed a "fast wait" state, and the process is nominally runnable. All a bit hand-wavy I know, but it worked well enough. The really important part of all this is that you should never sleep uninterruptibly for anything that you cannot absolutely guarantee will happen, otherwise you wind up with a stuck process. Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
On Tue, Apr 03, 2001 at 02:20:24PM +0200, Ingo Oeser wrote: > On Tue, Apr 03, 2001 at 01:06:33PM +0100, Alan Cox wrote: > > Device numbers/names have to be constant in order to detect > > disk layout changes across boots. > > Names stay constant, but why the NUMBERS? The names should stay > constant and represent the actual layout on each busses (say: > sane hierachic enumeration) of course. > This ignores the issue that in some cases you cannot give a physical location. Take the case of fibre-channel connected disks, potentially using multi-path I/O. There is no "actual layout" since you don't have a fixed physical path. At that point you have to have a more sophisticated naming scheme than the physical location of the disk, since physical location loses its meaning. You absolutely must avoid device name slippage. Whether this involves major and minor numbers is pretty much orthogonal. Major and minor numbers provided a nice and simple way for the kernel to map a device open into a driver and an argument to said driver. There are obviously other (more complex ways) of achieving the same thing. An obvious answer for hard disks is some form of labelling. Equally obviously, this does not solve the problem of e.g. fibre-channel connected tape drives. Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
On Tue, Apr 03, 2001 at 02:20:24PM +0200, Ingo Oeser wrote: On Tue, Apr 03, 2001 at 01:06:33PM +0100, Alan Cox wrote: Device numbers/names have to be constant in order to detect disk layout changes across boots. Names stay constant, but why the NUMBERS? The names should stay constant and represent the actual layout on each busses (say: sane hierachic enumeration) of course. This ignores the issue that in some cases you cannot give a physical location. Take the case of fibre-channel connected disks, potentially using multi-path I/O. There is no "actual layout" since you don't have a fixed physical path. At that point you have to have a more sophisticated naming scheme than the physical location of the disk, since physical location loses its meaning. You absolutely must avoid device name slippage. Whether this involves major and minor numbers is pretty much orthogonal. Major and minor numbers provided a nice and simple way for the kernel to map a device open into a driver and an argument to said driver. There are obviously other (more complex ways) of achieving the same thing. An obvious answer for hard disks is some form of labelling. Equally obviously, this does not solve the problem of e.g. fibre-channel connected tape drives. Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unistd.h and 'extern's and 'syscall' "standard(?)"
And furthermore, it's been around in Unix and unix-like systems for a very long time. Sounds like the lack of man page is an oversight. Anybody want to write one ? Tim On Sun, Apr 01, 2001 at 09:38:24PM +0100, Philip Blundell wrote: > >of action to take. Seeing as you work for suse, would you know > >where this 'syscall(3)' interface should be documented? Is it > >supposed to be present in all distro's? > > It's documented in the glibc manual. Yes, it should be present in all glibc > based distributions. > > p. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unistd.h and 'extern's and 'syscall' standard(?)
And furthermore, it's been around in Unix and unix-like systems for a very long time. Sounds like the lack of man page is an oversight. Anybody want to write one ? Tim On Sun, Apr 01, 2001 at 09:38:24PM +0100, Philip Blundell wrote: of action to take. Seeing as you work for suse, would you know where this 'syscall(3)' interface should be documented? Is it supposed to be present in all distro's? It's documented in the glibc manual. Yes, it should be present in all glibc based distributions. p. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in the file attributes ?
On Thu, Mar 29, 2001 at 10:51:18AM -0800, Justin Carlson wrote: > You don't need write perms on a file to remove it, you need write perms on the > directory. If you've got write permissions on the directory, you can remove > any file in the directory, regardless of the permissions. > > -Justin Except when the "sticky" bit is set. This is useful for shared temporary directories. Files can be created by anyone, but they can only be unlinked by the owner or by the superuser. Take a look at the permissions of /var/tmp. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in the file attributes ?
On Thu, Mar 29, 2001 at 10:51:18AM -0800, Justin Carlson wrote: You don't need write perms on a file to remove it, you need write perms on the directory. If you've got write permissions on the directory, you can remove any file in the directory, regardless of the permissions. -Justin Except when the "sticky" bit is set. This is useful for shared temporary directories. Files can be created by anyone, but they can only be unlinked by the owner or by the superuser. Take a look at the permissions of /var/tmp. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 and APM (standby) incompatibility on thinkpad T21?
Rebuild your kernel and make sure CONFIG_APM_ALLOW_INTS is set to "Y".
Tim
On Wed, Mar 28, 2001 at 12:52:05PM -0500, D. Sen wrote:
> Attempting to 'standby' the machine generates the following
> syslog messages:
>
> Mar 27 23:58:56 localhost kernel: ide_dmaproc: chipset supported
> ide_dma_lostirq func only: 13
> Mar 27 23:58:56 localhost kernel: hda: lost interrupt
>
> This seems to corrupt the filesystem..
>
> Kernel: 2.4.2
>
> hdparm -i /dev/hda:
> /dev/hda:
> multcount= 16 (on)
> I/O support = 1 (32-bit)
> unmaskirq= 1 (on)
> using_dma= 1 (on)
> keepsettings = 1 (on)
> nowerr = 0 (off)
> readonly = 0 (off)
> readahead= 8 (on)
> geometry = 4134/240/63, sectors = 62506080, start = 0
>
> Model=IBM-DJSA-232, FwRev=JS8IAD1A, SerialNo=48YBWLA6226
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=16383/15/63, TrkSize=0, SectSize=0, ECCbytes=4
> BuffType=DualPortCache, BuffSize=1874kB, MaxMultSect=16, MultSect=16
> CurCHS=16383/15/63, CurSects=1011810540, LBA=yes, LBAsects=62506080
> 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 udma0 udma1 *udma2 udma3 udma4
> AdvancedPM=yes: mode=0x9F (159)
> Drive Supports : ATA/ATAPI-5 T13 1321D revision 1 : ATA-2 ATA-3 ATA-4
> ATA-5
>
> Please CC any responses to [EMAIL PROTECTED]
>
> DS
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Oops from gpm.c
On Tue, Mar 27, 2001 at 08:01:15AM -0500, [EMAIL PROTECTED] wrote: > I am having oops reported from my slackware-current install with the 2.4.3-pre7 >kernel I can't seem to find the actual oops txt in any of my logs. > > So, here's what I have. > > >From my logs: > gpm [122]: Oops() invoked from gpm.c [962] > gpm [122]: /dev/mouse: no such file or directory > > I have devfs enabled and my mouse is USB (IMPS/2) so I didn't actually have a >/dev/mouse. > the rc.gpm incorrectly pointed gpm to /dev/mouse. When I fixed it, the oops went >away. > > If anyone can tell me where the default slackware puts oops info, I'll gladly put it >here. > It's not a kernel oops. The author of gpm decided to use the term 'oops' in their userland code. Personally, I think that's unwise. You don't have a kernel problem. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops from gpm.c
On Tue, Mar 27, 2001 at 08:01:15AM -0500, [EMAIL PROTECTED] wrote: I am having oops reported from my slackware-current install with the 2.4.3-pre7 kernel I can't seem to find the actual oops txt in any of my logs. So, here's what I have. From my logs: gpm [122]: Oops() invoked from gpm.c [962] gpm [122]: /dev/mouse: no such file or directory I have devfs enabled and my mouse is USB (IMPS/2) so I didn't actually have a /dev/mouse. the rc.gpm incorrectly pointed gpm to /dev/mouse. When I fixed it, the oops went away. If anyone can tell me where the default slackware puts oops info, I'll gladly put it here. It's not a kernel oops. The author of gpm decided to use the term 'oops' in their userland code. Personally, I think that's unwise. You don't have a kernel problem. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 and APM (standby) incompatibility on thinkpad T21?
Rebuild your kernel and make sure CONFIG_APM_ALLOW_INTS is set to "Y".
Tim
On Wed, Mar 28, 2001 at 12:52:05PM -0500, D. Sen wrote:
Attempting to 'standby' the machine generates the following
syslog messages:
Mar 27 23:58:56 localhost kernel: ide_dmaproc: chipset supported
ide_dma_lostirq func only: 13
Mar 27 23:58:56 localhost kernel: hda: lost interrupt
This seems to corrupt the filesystem..
Kernel: 2.4.2
hdparm -i /dev/hda:
/dev/hda:
multcount= 16 (on)
I/O support = 1 (32-bit)
unmaskirq= 1 (on)
using_dma= 1 (on)
keepsettings = 1 (on)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 4134/240/63, sectors = 62506080, start = 0
Model=IBM-DJSA-232, FwRev=JS8IAD1A, SerialNo=48YBWLA6226
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
RawCHS=16383/15/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=1874kB, MaxMultSect=16, MultSect=16
CurCHS=16383/15/63, CurSects=1011810540, LBA=yes, LBAsects=62506080
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 udma0 udma1 *udma2 udma3 udma4
AdvancedPM=yes: mode=0x9F (159)
Drive Supports : ATA/ATAPI-5 T13 1321D revision 1 : ATA-2 ATA-3 ATA-4
ATA-5
Please CC any responses to [EMAIL PROTECTED]
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] gcc-3.0 warnings
On Fri, Mar 23, 2001 at 05:16:26PM -0800, Stephen Satchell wrote:
[...]
> Really? I have a "cleanup" function that can be called during failure
> cases (and success cases -- but you didn't mention that) so that the cost
> is very low and I don't have to code ANY labels.
>
> But then again, I'm a double-pipe abuser, in that I tend to code "atomic"
> sequences as
>
> if ((a) || (b) || (c) || (d) || (e) || (f) || (g) || ... ) { something
> failed} else {it all worked!}
>
> and make sure that the failure value is non-zero for each a, b, c, d, and
> so forth.
>
Sorry, my example was too simplistic. Replace simple allocations with e.g.
allocate();
grab lock;
set flag;
allocate();
or something similar. Yes it's possible to code a state variable to remember
where you got to, or to e.g. add an extra boolean variable to indicate that
you grabbed the lock, but I'd argue that this obfuscates the code as well as
making it less efficient. It's no good looking to see if the lock has been
grabbed - if you failed at the first stage, it may still be locked by a
different CPU.
Tim
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] gcc-3.0 warnings
On Fri, Mar 23, 2001 at 05:16:26PM -0800, Stephen Satchell wrote:
[...]
Really? I have a "cleanup" function that can be called during failure
cases (and success cases -- but you didn't mention that) so that the cost
is very low and I don't have to code ANY labels.
But then again, I'm a double-pipe abuser, in that I tend to code "atomic"
sequences as
if ((a) || (b) || (c) || (d) || (e) || (f) || (g) || ... ) { something
failed} else {it all worked!}
and make sure that the failure value is non-zero for each a, b, c, d, and
so forth.
Sorry, my example was too simplistic. Replace simple allocations with e.g.
allocate();
grab lock;
set flag;
allocate();
or something similar. Yes it's possible to code a state variable to remember
where you got to, or to e.g. add an extra boolean variable to indicate that
you grabbed the lock, but I'd argue that this obfuscates the code as well as
making it less efficient. It's no good looking to see if the lock has been
grabbed - if you failed at the first stage, it may still be locked by a
different CPU.
Tim
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 comments in
Micro patchlet :-)
In wandering around the kernel recently, I found that
contains stale comments at the head of the file relating to the old static
timers which were deleted for 2.4.
So, here's a trivial patch to try to bring things back in sync.
Regards,
Tim
--- timer.h.2.4.2 Fri Mar 23 13:57:51 2001
+++ timer.h Fri Mar 23 14:07:00 2001
@@ -5,17 +5,13 @@
#include
/*
- * This is completely separate from the above, and is the
- * "new and improved" way of handling timers more dynamically.
- * Hopefully efficient and general enough for most things.
+ * In Linux 2.4, static timers have been removed from the kernel.
+ * Timers may be dynamically created and destroyed, and should be initialized
+ * by a call to init_timer() upon creation.
*
- * The "hardcoded" timers above are still useful for well-
- * defined problems, but the timer-list is probably better
- * when you need multiple outstanding timers or similar.
- *
- * The "data" field is in case you want to use the same
- * timeout function for several timeouts. You can use this
- * to distinguish between the different invocations.
+ * The "data" field enables use of a common timeout function for several
+ * timeouts. You can use this field to distinguish between the different
+ * invocations.
*/
struct timer_list {
struct list_head list;
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
Hmmm... you don't really give enough information to make much of a guess. I'd do the following: Grab at least 2.2.18, or even better, get Alan's 2.2.19pre (which is almost 2.2.19 now, I believe), and build and install that kernel. Now, if you run into the same problems, record the crash details, especially if the kernels oopses, and then send the information (kernel version, output of ksymoops if there is an oops, kernel .config used etc.) to the mailing list. Tim On Sat, Mar 24, 2001 at 05:34:39AM +0530, dhar wrote: > Hi, > > I am not a member of either of these lists and would appreciate if you could send >your replies to me personally. > > Now the problem: > > I have an IBM Netfinity X330 server. Dual Processor (PIII 800). I compiled kernel >2.2.14 with SMP support. NFS was however compiled as a module. > > Now the problem is as follows: > > Most of the times the machine just works fine. > But whenever there is heavy disk write activity it just hangs/crashes. Also this is >when the SMP kernel is used. If I use the normal kernel then there is no problem. > > Could any one tell me what has to be done to prevent this from happening? > > Any help in this regard will be very much appreciated. > > Once again, kindly reply to me personally as I am not a member of either of these >lists. > > Regards > Dhar > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
On Fri, Mar 23, 2001 at 06:38:37PM +, Alan Cox wrote: > > infinite storage. After all, earlier Unix flavours did not need > > an OOM killer either, and my editor was not killed under Unix V6 > > on 64k when I started some other process. > > You were lucky. Its quite possible for V6 to kill processes when you run out > of swap > It was actually worse than that. Grab your copy of "Lions", and check lines 4375-4377 in function xswap(). A failure to allocate space in the swapmap caused a panic. Same problem in xalloc(). Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: use the kernel to change an irq?
They're sharing an IRQ because they're attached to the same interrupt line on the motherboard. Nothing you can do in software is ever going to change this. For most BX chipset motherboards I've seen, the AGP slot shares the same interrupt as the first (i.e. physically closest) PCI slot. If you change the IRQ for one, you just changed it for the other. If you don't want it to share, you can't have anything in the other slot. Sounds like you're out of luck :-( Tim On Thu, Mar 22, 2001 at 11:10:28PM -0800, Jacob Luna Lundberg wrote: > > Oh Great Gurus: > > I have an agp video card that seems quite picky about interrupts, and a > bios that is insisting on sharing the video card's interrupt with whatever > is in the first pci slot. So my question is, is there any way for the > kernel to more or less say ``screw you'' to the bios and pick the irq for > the video card itself? I have a spare irq I'd love for it to use... > > Oh, almost forgot: Yes, I'd just vacate the pci slot below the video > card, but sadly all my pci slots are in use. :( > > Ok, I'll admit the card is an nVidia card and I'm trying to use the (evil) > binary drivers. But note I'm *not* asking for help with that directly. > I'm merely asking if there's a way to avoid sharing the interrupt... > > Thanks Muchly, > -Jacob > -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] gcc-3.0 warnings
On Fri, Mar 23, 2001 at 11:59:09PM +0100, J . A . Magallon wrote:
>
> On 03.23 Linus Torvalds wrote:
> >
> > I agree. I'd much prefer that syntax also.
> >
> > Or just remove the "default:" altogether, when it doesn't make any
> > difference.
> >
>
> Well, at last some sense. The same is with that ugly out: at the end
> of the function. Just change all that 'goto out' for a return.
> It does not matter, -O2 is going to do what it wants.
>
This has nothing to do with fastpathing and object code optimization. C
doesn't have exception handling, so you either have to remember to undo
allocations etc. in failure cases all through the code, or you stick your
undo code at the end of the function and have all failure cases jump to the
relevant label. It's not pretty, but it's much less error-prone e.g.
func()
{
error = 0;
a = alloc_something();
if (some failure) {
error = XXX;
goto out;
}
b = alloc_something_else();
if (some other failure) {
error = YYY;
goto out1;
}
...
out1:
dealloc(b);
out:
dealloc(a);
return(error);
}
This is arguably easier to follow and less likely to get broken than the
alternative of embedding all the unwind code at each error point.
Tim
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
Netscape 4 has some very nasty habits like suddenly consuming ~80MB of memory. Disabling java support seems to eradicate most occurences of this particularly obnoxious behaviour. Under these circumstances, the OOM killer is doing exactly the right thing i.e. killing a runaway app. Tim On Fri, Mar 23, 2001 at 03:20:41PM -0500, Tom Diehl wrote: > On Fri, 23 Mar 2001, Rik van Riel wrote: > > > Well, in that case you'll have to live with the current OOM > > killer. Martin wrote down a pretty detailed description of > > what's wrong with my algorithm, if it really bothers him he > > should be able to come up with something better. > > > > Personally, I think there is more important VM code to look > > after, since OOM is a pretty rare occurrance anyway. > > Well actually it is not that rare at least for me. Every 3 or 4 days I run > into it (It happened again this morning). The machine has 128 Megs of ram > and 256 Megs of swap. It is my desktop machine and I keep 3 or 4 netscape > windows running all of the time. Well I try to at least. Every 3 or 4 days > the OOM Killer kills netscape, it happened this morning. If I could fix it > I would but alas I do not have the knowledge. The best I can do is test. :( > > This is NOT a complaint I just bring this up as another data point. > It used to lock the machine so things are getting better. fwiw, I am > currently running 2.4.2-ac18. The old ac kernels (do not remember exactly > which ones but it was single digits) would allow the machine to start > thrashing. I could usually see that it was running out of memory and if I > was fast enough could kill Netscape b4 the machine locked. If I was not > fast enough it would lock hard. Nothing in the logs. > > HTH, > > -- > ..Tom ATA100 is another testimony to the fact that pigs can be > [EMAIL PROTECTED]made to fly given sufficient thrust (to borrow an RFC) > Alan Cox lkml 11 Jan 01 > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
Netscape 4 has some very nasty habits like suddenly consuming ~80MB of memory. Disabling java support seems to eradicate most occurences of this particularly obnoxious behaviour. Under these circumstances, the OOM killer is doing exactly the right thing i.e. killing a runaway app. Tim On Fri, Mar 23, 2001 at 03:20:41PM -0500, Tom Diehl wrote: On Fri, 23 Mar 2001, Rik van Riel wrote: Well, in that case you'll have to live with the current OOM killer. Martin wrote down a pretty detailed description of what's wrong with my algorithm, if it really bothers him he should be able to come up with something better. Personally, I think there is more important VM code to look after, since OOM is a pretty rare occurrance anyway. Well actually it is not that rare at least for me. Every 3 or 4 days I run into it (It happened again this morning). The machine has 128 Megs of ram and 256 Megs of swap. It is my desktop machine and I keep 3 or 4 netscape windows running all of the time. Well I try to at least. Every 3 or 4 days the OOM Killer kills netscape, it happened this morning. If I could fix it I would but alas I do not have the knowledge. The best I can do is test. :( This is NOT a complaint I just bring this up as another data point. It used to lock the machine so things are getting better. fwiw, I am currently running 2.4.2-ac18. The old ac kernels (do not remember exactly which ones but it was single digits) would allow the machine to start thrashing. I could usually see that it was running out of memory and if I was fast enough could kill Netscape b4 the machine locked. If I was not fast enough it would lock hard. Nothing in the logs. HTH, -- ..Tom ATA100 is another testimony to the fact that pigs can be [EMAIL PROTECTED]made to fly given sufficient thrust (to borrow an RFC) Alan Cox lkml 11 Jan 01 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] gcc-3.0 warnings
On Fri, Mar 23, 2001 at 11:59:09PM +0100, J . A . Magallon wrote:
On 03.23 Linus Torvalds wrote:
I agree. I'd much prefer that syntax also.
Or just remove the "default:" altogether, when it doesn't make any
difference.
Well, at last some sense. The same is with that ugly out: at the end
of the function. Just change all that 'goto out' for a return.
It does not matter, -O2 is going to do what it wants.
This has nothing to do with fastpathing and object code optimization. C
doesn't have exception handling, so you either have to remember to undo
allocations etc. in failure cases all through the code, or you stick your
undo code at the end of the function and have all failure cases jump to the
relevant label. It's not pretty, but it's much less error-prone e.g.
func()
{
error = 0;
a = alloc_something();
if (some failure) {
error = XXX;
goto out;
}
b = alloc_something_else();
if (some other failure) {
error = YYY;
goto out1;
}
...
out1:
dealloc(b);
out:
dealloc(a);
return(error);
}
This is arguably easier to follow and less likely to get broken than the
alternative of embedding all the unwind code at each error point.
Tim
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
On Fri, Mar 23, 2001 at 06:38:37PM +, Alan Cox wrote: infinite storage. After all, earlier Unix flavours did not need an OOM killer either, and my editor was not killed under Unix V6 on 64k when I started some other process. You were lucky. Its quite possible for V6 to kill processes when you run out of swap It was actually worse than that. Grab your copy of "Lions", and check lines 4375-4377 in function xswap(). A failure to allocate space in the swapmap caused a panic. Same problem in xalloc(). Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: use the kernel to change an irq?
They're sharing an IRQ because they're attached to the same interrupt line on the motherboard. Nothing you can do in software is ever going to change this. For most BX chipset motherboards I've seen, the AGP slot shares the same interrupt as the first (i.e. physically closest) PCI slot. If you change the IRQ for one, you just changed it for the other. If you don't want it to share, you can't have anything in the other slot. Sounds like you're out of luck :-( Tim On Thu, Mar 22, 2001 at 11:10:28PM -0800, Jacob Luna Lundberg wrote: Oh Great Gurus: I have an agp video card that seems quite picky about interrupts, and a bios that is insisting on sharing the video card's interrupt with whatever is in the first pci slot. So my question is, is there any way for the kernel to more or less say ``screw you'' to the bios and pick the irq for the video card itself? I have a spare irq I'd love for it to use... Oh, almost forgot: Yes, I'd just vacate the pci slot below the video card, but sadly all my pci slots are in use. :( Ok, I'll admit the card is an nVidia card and I'm trying to use the (evil) binary drivers. But note I'm *not* asking for help with that directly. I'm merely asking if there's a way to avoid sharing the interrupt... Thanks Muchly, -Jacob -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
Hmmm... you don't really give enough information to make much of a guess. I'd do the following: Grab at least 2.2.18, or even better, get Alan's 2.2.19pre (which is almost 2.2.19 now, I believe), and build and install that kernel. Now, if you run into the same problems, record the crash details, especially if the kernels oopses, and then send the information (kernel version, output of ksymoops if there is an oops, kernel .config used etc.) to the mailing list. Tim On Sat, Mar 24, 2001 at 05:34:39AM +0530, dhar wrote: Hi, I am not a member of either of these lists and would appreciate if you could send your replies to me personally. Now the problem: I have an IBM Netfinity X330 server. Dual Processor (PIII 800). I compiled kernel 2.2.14 with SMP support. NFS was however compiled as a module. Now the problem is as follows: Most of the times the machine just works fine. But whenever there is heavy disk write activity it just hangs/crashes. Also this is when the SMP kernel is used. If I use the normal kernel then there is no problem. Could any one tell me what has to be done to prevent this from happening? Any help in this regard will be very much appreciated. Once again, kindly reply to me personally as I am not a member of either of these lists. Regards Dhar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 comments in linux/timer.h
Micro patchlet :-)
In wandering around the kernel recently, I found that linux/timer.h
contains stale comments at the head of the file relating to the old static
timers which were deleted for 2.4.
So, here's a trivial patch to try to bring things back in sync.
Regards,
Tim
--- timer.h.2.4.2 Fri Mar 23 13:57:51 2001
+++ timer.h Fri Mar 23 14:07:00 2001
@@ -5,17 +5,13 @@
#include linux/list.h
/*
- * This is completely separate from the above, and is the
- * "new and improved" way of handling timers more dynamically.
- * Hopefully efficient and general enough for most things.
+ * In Linux 2.4, static timers have been removed from the kernel.
+ * Timers may be dynamically created and destroyed, and should be initialized
+ * by a call to init_timer() upon creation.
*
- * The "hardcoded" timers above are still useful for well-
- * defined problems, but the timer-list is probably better
- * when you need multiple outstanding timers or similar.
- *
- * The "data" field is in case you want to use the same
- * timeout function for several timeouts. You can use this
- * to distinguish between the different invocations.
+ * The "data" field enables use of a common timeout function for several
+ * timeouts. You can use this field to distinguish between the different
+ * invocations.
*/
struct timer_list {
struct list_head list;
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Incorrect mdelay() results on Power Managed Machines x86
If it's a 500MHz Thinkpad, then I'm guessing it's something like a 600X. That doesn't have Speedstep. The speed changes are done by some circuitry in the laptop. I can try to find out more if this would help. The newer machines are using Speedstep. Tim On Thu, Mar 22, 2001 at 11:37:43PM +, Alan Cox wrote: > > thanks, i just tested the "notsc" option (.config has CONFIG_X86_TSC > > enabled=y, but CONFIG_M586TSC is not enabled.. if that's ok), but this time > ... > > boot and stay on battery power exclusively. did anyone else expect this > > behaviour? > > Errmm no.. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Incorrect mdelay() results on Power Managed Machines x86
If it's a 500MHz Thinkpad, then I'm guessing it's something like a 600X. That doesn't have Speedstep. The speed changes are done by some circuitry in the laptop. I can try to find out more if this would help. The newer machines are using Speedstep. Tim On Thu, Mar 22, 2001 at 11:37:43PM +, Alan Cox wrote: thanks, i just tested the "notsc" option (.config has CONFIG_X86_TSC enabled=y, but CONFIG_M586TSC is not enabled.. if that's ok), but this time ... boot and stay on battery power exclusively. did anyone else expect this behaviour? Errmm no.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
Not necessarily. For a write to a disk file, it would be an error to return a short write except in an error situation. For devices, the rules are looser. Quoting Stevens APUE p.406, "Some devices, notably terminals, networks, and any SVR4 streams devices have the following two properties. ... 2 A write operation can also return less that we specified. This may be caused by flow control constraints by downstream modules, for example. Again it's not an error, and we should continue writing the remainder of the data. (Normally this short return from a write only occurs with a nonblocking descriptor or if a signal is caught." So, whilst I personally find drivers that return a short write without O_NONBLOCK set to be rather obnoxious, it's not illegal, and you have to code accordingly :-) Tim On Tue, Mar 20, 2001 at 03:19:37PM -0500, Doug Ledford wrote: > David Ford wrote: > > > > Actually you probably upgraded to a non-broken version of esd. Stock esd -still- > > writes to the socket without regard to return value. If the write only accepted > > 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at > > 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. > > > > I posted my last patch for esd here and to other places in June of 2000. All it > > does is check for return value and adjust the writes accordingly. For reference, > > the patch is at http://stuph.org/esound-audio.c.patch. > > Why would esd get a short write() unless it is opening the file in non > blocking mode (which I didn't see when I was working on the i810 sound > driver)? If esd is writing to a file in blocking mode and that write is > returning short, then that sounds like a driver bug to me. > > -- > > Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford > Please check my web site for aic7xxx updates/answers before > e-mailing me about problems > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: esound (esd), 2.4.[12] chopped up sound -- solved
Not necessarily. For a write to a disk file, it would be an error to return a short write except in an error situation. For devices, the rules are looser. Quoting Stevens APUE p.406, "Some devices, notably terminals, networks, and any SVR4 streams devices have the following two properties. ... 2 A write operation can also return less that we specified. This may be caused by flow control constraints by downstream modules, for example. Again it's not an error, and we should continue writing the remainder of the data. (Normally this short return from a write only occurs with a nonblocking descriptor or if a signal is caught." So, whilst I personally find drivers that return a short write without O_NONBLOCK set to be rather obnoxious, it's not illegal, and you have to code accordingly :-) Tim On Tue, Mar 20, 2001 at 03:19:37PM -0500, Doug Ledford wrote: David Ford wrote: Actually you probably upgraded to a non-broken version of esd. Stock esd -still- writes to the socket without regard to return value. If the write only accepted 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. I posted my last patch for esd here and to other places in June of 2000. All it does is check for return value and adjust the writes accordingly. For reference, the patch is at http://stuph.org/esound-audio.c.patch. Why would esd get a short write() unless it is opening the file in non blocking mode (which I didn't see when I was working on the i810 sound driver)? If esd is writing to a file in blocking mode and that write is returning short, then that sounds like a driver bug to me. -- Doug Ledford [EMAIL PROTECTED] http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 10:15:26AM -0800, Greg KH wrote: [My ramblings on device naming database deleted] > This comes up a lot with regards to USB devices too. One of the > usb-serial drivers (the edgeport driver) did something like this by > looking at the topology of the USB bus and where a specific device was > (it was also helped by unique serial numbers) and allowed the devices to > be assigned device nodes based on the topology and a small user space > program. I'm going to try to do this for all usb-serial devices in 2.5 > > I can see a scheme like this being very useful for all USB, FireWire, > scsi, etc type of devices. > > And no, I don't think that having some type of device naming "database" > is overkill and will eventually make it into parts of the kernel (the > "database" living outside of the kernel of course...) > Well, if it sounds useful, I can look into putting up the design documentation (yes, shock, horror, there is some :-). It's pretty thorough and covers most of the issues involved, and hence might be a good talking point, even if we chose to implement quite differently. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 10:36:40AM -0500, John Jasen wrote: > > The problem: > [ Device name slippage ] > > Possible solutions(?): > > Solaris uses an /etc/path_to_inst file, to keep track of device ordering, > et al. > > Maybe we should consider something similar, where a physical device to > logical device map is kept and used to keep things consistent on > kernel/driver changes; device addition/removal, and so forth ... > > I am, of course, open to better solutions. > This would currently be massive overkill for Linux, but DYNIX/ptx avoids this problem entirely by keeping a device naming database. This became necessary when we added support for multi-path fibre-channel connected disks. Most device-naming conventions rely on "physical" addresses i.e. this disk at the end of this bus connected to this controller in this PCI slot is /dev/sdd. The Solaris scheme mentioned above is no different in that respect. Unfortunately, it doesn't work with multi-path FC-connected devices. Very briefly, devices that are "id-able" i.e. already have a unique id are simply entered into the database (SCSI drives have a unique id that you can read at autoconf time). For elements that are not "id-able", we establish a derived id by recording their relation to "id-able" elements. At boot time, we scan (in parallel) the system and compare what we find to the database. That way, you get consistent naming for devices, and, at least in the case of the SCSI (or FC) drives, the name doesn't change, even if you pull a drive from one bus and plug it into a different bus entirely. As I say, this would be massive overkill for Linux, but it's a rather thorough solution :-) Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 10:36:40AM -0500, John Jasen wrote: The problem: [ Device name slippage ] Possible solutions(?): Solaris uses an /etc/path_to_inst file, to keep track of device ordering, et al. Maybe we should consider something similar, where a physical device to logical device map is kept and used to keep things consistent on kernel/driver changes; device addition/removal, and so forth ... I am, of course, open to better solutions. This would currently be massive overkill for Linux, but DYNIX/ptx avoids this problem entirely by keeping a device naming database. This became necessary when we added support for multi-path fibre-channel connected disks. Most device-naming conventions rely on "physical" addresses i.e. this disk at the end of this bus connected to this controller in this PCI slot is /dev/sdd. The Solaris scheme mentioned above is no different in that respect. Unfortunately, it doesn't work with multi-path FC-connected devices. Very briefly, devices that are "id-able" i.e. already have a unique id are simply entered into the database (SCSI drives have a unique id that you can read at autoconf time). For elements that are not "id-able", we establish a derived id by recording their relation to "id-able" elements. At boot time, we scan (in parallel) the system and compare what we find to the database. That way, you get consistent naming for devices, and, at least in the case of the SCSI (or FC) drives, the name doesn't change, even if you pull a drive from one bus and plug it into a different bus entirely. As I say, this would be massive overkill for Linux, but it's a rather thorough solution :-) Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 10:15:26AM -0800, Greg KH wrote: [My ramblings on device naming database deleted] This comes up a lot with regards to USB devices too. One of the usb-serial drivers (the edgeport driver) did something like this by looking at the topology of the USB bus and where a specific device was (it was also helped by unique serial numbers) and allowed the devices to be assigned device nodes based on the topology and a small user space program. I'm going to try to do this for all usb-serial devices in 2.5 I can see a scheme like this being very useful for all USB, FireWire, scsi, etc type of devices. And no, I don't think that having some type of device naming "database" is overkill and will eventually make it into parts of the kernel (the "database" living outside of the kernel of course...) Well, if it sounds useful, I can look into putting up the design documentation (yes, shock, horror, there is some :-). It's pretty thorough and covers most of the issues involved, and hence might be a good talking point, even if we chose to implement quite differently. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x: Netfinity 4500 SMP freezes without any trace
Sorry for quoting the whole message. Obviously I need some fresh air :-) Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac20
On Tue, Mar 13, 2001 at 02:24:54PM -0500, Nathan Walp wrote: > David Balazic wrote: > > > > SCSI adapters are enumerated randomly(*) , relying on certain numbering > > will get you into trouble, sooner or later. > > There is no commonly accepted solution, AFAIK. > > The same thing can happent to disk enumeration ( sdb becomes sdc ) > > or partition enumeration ( hda6 becomes hda5 ). > > > > * - theoreticaly no, but practicaly yes ( most of the time ) > > SCSI adapters are given host numbers in a random order? Even with no > hardware changes? Does this make less than sense to anyone else? Every > kernel EVER up till now has had the real scsi cards (in some particular > order) then ide-scsi. Have I just been lucky??? > No, it's not truly random. That would be insane. And, no, if you don't change the kernel or the hardware, then they won't jump around. But, yes, if you change the hardware, or someone changes the probe order in the kernel, you can suffer from device name slippage. This is a minor problem on a small home system, and a massive PITA on a large server. You can at least mandate the probe order on a 2.4 system (see the scsihosts parameter). Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x: Netfinity 4500 SMP freezes without any trace
STICK is not set > # CONFIG_QIC02_TAPE is not set > > # > # Watchdog Cards > # > # CONFIG_WATCHDOG is not set > # CONFIG_INTEL_RNG is not set > # CONFIG_NVRAM is not set > # CONFIG_RTC is not set > # CONFIG_DTLK is not set > # CONFIG_R3964 is not set > # CONFIG_APPLICOM is not set > > # > # Ftape, the floppy tape device driver > # > # CONFIG_FTAPE is not set > # CONFIG_AGP is not set > # CONFIG_DRM is not set > > # > # Multimedia devices > # > # CONFIG_VIDEO_DEV is not set > > # > # File systems > # > # CONFIG_QUOTA is not set > # CONFIG_AUTOFS_FS is not set > # CONFIG_AUTOFS4_FS is not set > # CONFIG_REISERFS_FS is not set > # CONFIG_REISERFS_CHECK is not set > # CONFIG_ADFS_FS is not set > # CONFIG_ADFS_FS_RW is not set > # CONFIG_AFFS_FS is not set > # CONFIG_HFS_FS is not set > # CONFIG_BFS_FS is not set > CONFIG_FAT_FS=m > # CONFIG_MSDOS_FS is not set > # CONFIG_UMSDOS_FS is not set > CONFIG_VFAT_FS=m > # CONFIG_EFS_FS is not set > # CONFIG_JFFS_FS is not set > # CONFIG_CRAMFS is not set > # CONFIG_RAMFS is not set > CONFIG_ISO9660_FS=y > # CONFIG_JOLIET is not set > # CONFIG_MINIX_FS is not set > # CONFIG_NTFS_FS is not set > # CONFIG_NTFS_RW is not set > # CONFIG_HPFS_FS is not set > CONFIG_PROC_FS=y > # CONFIG_DEVFS_FS is not set > # CONFIG_DEVFS_MOUNT is not set > # CONFIG_DEVFS_DEBUG is not set > CONFIG_DEVPTS_FS=y > # CONFIG_QNX4FS_FS is not set > # CONFIG_QNX4FS_RW is not set > # CONFIG_ROMFS_FS is not set > CONFIG_EXT2_FS=y > # CONFIG_SYSV_FS is not set > # CONFIG_SYSV_FS_WRITE is not set > # CONFIG_UDF_FS is not set > # CONFIG_UDF_RW is not set > # CONFIG_UFS_FS is not set > # CONFIG_UFS_FS_WRITE is not set > > # > # Network File Systems > # > # CONFIG_CODA_FS is not set > CONFIG_NFS_FS=y > CONFIG_NFS_V3=y > # CONFIG_ROOT_NFS is not set > CONFIG_NFSD=y > CONFIG_NFSD_V3=y > CONFIG_SUNRPC=y > CONFIG_LOCKD=y > CONFIG_LOCKD_V4=y > # CONFIG_SMB_FS is not set > # CONFIG_NCP_FS is not set > # CONFIG_NCPFS_PACKET_SIGNING is not set > # CONFIG_NCPFS_IOCTL_LOCKING is not set > # CONFIG_NCPFS_STRONG is not set > # CONFIG_NCPFS_NFS_NS is not set > # CONFIG_NCPFS_OS2_NS is not set > # CONFIG_NCPFS_SMALLDOS is not set > # CONFIG_NCPFS_NLS is not set > # CONFIG_NCPFS_EXTRAS is not set > > # > # Partition Types > # > # CONFIG_PARTITION_ADVANCED is not set > CONFIG_MSDOS_PARTITION=y > # CONFIG_SMB_NLS is not set > CONFIG_NLS=y > > # > # Native Language Support > # > CONFIG_NLS_DEFAULT="cp437" > # CONFIG_NLS_CODEPAGE_437 is not set > # CONFIG_NLS_CODEPAGE_737 is not set > # CONFIG_NLS_CODEPAGE_775 is not set > CONFIG_NLS_CODEPAGE_850=m > # CONFIG_NLS_CODEPAGE_852 is not set > # CONFIG_NLS_CODEPAGE_855 is not set > # CONFIG_NLS_CODEPAGE_857 is not set > # CONFIG_NLS_CODEPAGE_860 is not set > # CONFIG_NLS_CODEPAGE_861 is not set > # CONFIG_NLS_CODEPAGE_862 is not set > # CONFIG_NLS_CODEPAGE_863 is not set > # CONFIG_NLS_CODEPAGE_864 is not set > # CONFIG_NLS_CODEPAGE_865 is not set > # CONFIG_NLS_CODEPAGE_866 is not set > # CONFIG_NLS_CODEPAGE_869 is not set > # CONFIG_NLS_CODEPAGE_874 is not set > # CONFIG_NLS_CODEPAGE_932 is not set > # CONFIG_NLS_CODEPAGE_936 is not set > # CONFIG_NLS_CODEPAGE_949 is not set > # CONFIG_NLS_CODEPAGE_950 is not set > CONFIG_NLS_ISO8859_1=y > # CONFIG_NLS_ISO8859_2 is not set > # CONFIG_NLS_ISO8859_3 is not set > # CONFIG_NLS_ISO8859_4 is not set > # CONFIG_NLS_ISO8859_5 is not set > # CONFIG_NLS_ISO8859_6 is not set > # CONFIG_NLS_ISO8859_7 is not set > # CONFIG_NLS_ISO8859_8 is not set > # CONFIG_NLS_ISO8859_9 is not set > # CONFIG_NLS_ISO8859_14 is not set > # CONFIG_NLS_ISO8859_15 is not set > # CONFIG_NLS_KOI8_R is not set > # CONFIG_NLS_UTF8 is not set > > # > # Console drivers > # > CONFIG_VGA_CONSOLE=y > # CONFIG_VIDEO_SELECT is not set > # CONFIG_MDA_CONSOLE is not set > > # > # Frame-buffer support > # > # CONFIG_FB is not set > > # > # Sound > # > # CONFIG_SOUND is not set > > # > # USB support > # > # CONFIG_USB is not set > > # > # Kernel hacking > # > # CONFIG_MAGIC_SYSRQ is not set > > > > Regards > > Hartmut > > -- > Hartmut Holz > zweitwerk GmbH - ein Unternehmen der Media Bild Imaging AG > Stahltwiete 16 > 22761 Hamburg > > Tel: 040 / 853756-14 > Fax: 040 / 853756-50 > email: [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/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x: Netfinity 4500 SMP freezes without any trace
e floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_FAT_FS=m # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=y # CONFIG_JOLIET is not set # CONFIG_MINIX_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_SYSV_FS_WRITE is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_ROOT_NFS is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_SMB_NLS is not set CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="cp437" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_950 is not set CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # CONFIG_VGA_CONSOLE=y # CONFIG_VIDEO_SELECT is not set # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # # CONFIG_FB is not set # # Sound # # CONFIG_SOUND is not set # # USB support # # CONFIG_USB is not set # # Kernel hacking # # CONFIG_MAGIC_SYSRQ is not set Regards Hartmut -- Hartmut Holz zweitwerk GmbH - ein Unternehmen der Media Bild Imaging AG Stahltwiete 16 22761 Hamburg Tel: 040 / 853756-14 Fax: 040 / 853756-50 email: [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/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac20
On Tue, Mar 13, 2001 at 02:24:54PM -0500, Nathan Walp wrote: David Balazic wrote: SCSI adapters are enumerated randomly(*) , relying on certain numbering will get you into trouble, sooner or later. There is no commonly accepted solution, AFAIK. The same thing can happent to disk enumeration ( sdb becomes sdc ) or partition enumeration ( hda6 becomes hda5 ). * - theoreticaly no, but practicaly yes ( most of the time ) SCSI adapters are given host numbers in a random order? Even with no hardware changes? Does this make less than sense to anyone else? Every kernel EVER up till now has had the real scsi cards (in some particular order) then ide-scsi. Have I just been lucky??? No, it's not truly random. That would be insane. And, no, if you don't change the kernel or the hardware, then they won't jump around. But, yes, if you change the hardware, or someone changes the probe order in the kernel, you can suffer from device name slippage. This is a minor problem on a small home system, and a massive PITA on a large server. You can at least mandate the probe order on a 2.4 system (see the scsihosts parameter). Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x: Netfinity 4500 SMP freezes without any trace
Sorry for quoting the whole message. Obviously I need some fresh air :-) Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 lock contention and scalability
On Tue, Mar 06, 2001 at 10:12:17PM -0500, Jeff Dike wrote: > [EMAIL PROTECTED] said: > > If you're a UP system, it never makes sense to spin in userland, since > > you'll just burn up a timeslice and prevent the lock holder from > > running. I haven't looked, but assume that their code only uses > > spinlocks on SMP. If you're an SMP system, then you shouldn't be using > > a spinlock unless the critical section is "short", in which case the > > waiters should simply spin in userland rather than making system calls > > which is simply overhead. > > This is a problem that UML is going to have when I turn SMP back on. > Emulating a multiprocessor box on a UP host with the existing locking > primitives is going to result in exactly this problem. > Yes. On a uniprocessor system, a simple fallback is to just use a semaphore instead of a spinlock, since you can guarantee that there's no point in scheduling the current task until the holder of the "lock" releases it. Otherwise, the spin calling sched_yield() each iteration isn't too horrible. > > Actually, what's really needed here is an efficient form of > > dynamically marking a process as non-preemptible so that when > > acquiring a spinlock the process can ensure that it exits the critical > > section as fast as possible, when it would relinquish its > > non-preemptible privilege. > > That sounds like a pretty fundamental (and abusable) mechanism. > It would be if it were generally available. The implementation on DYNIX/ptx requires a privilege (PRIV_SCHED IIRC), to be able to use it. It was added for a database to prevent preemption during critical sections. > I had a suggestion from an IBM guy at ALS last year to make UML "spin"-locks > actually sleep in the host (this doesn't make them sleep locks in userspace > because they don't call schedule), which sounds reasonable. This gives the > lock-holder an opportunity to run immediately. It's unclear to me what the > wake-up mechanism would be, though. > Hmmm.. depends what you mean by sleep i.e sleep(3) vs. making a system call that sleeps. I would have thought the latter, and use semaphores again. > Another thought I had was to raise the priority of a thread holding a > spinlock. This would reduce the chance that it would be preempted by a thread > that will waste a timeslice spinning on that lock. I don't know whether this > is a good idea either. > That's basically a weaker version of the no-preempt. Not a bad idea, but less than optimal :-) Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interesting fs corruption story
On Tue, Mar 06, 2001 at 08:10:10PM -0500, Ettore Perazzoli wrote: > On 06 Mar 2001 17:01:02 -0800, Tim Wright wrote: [...] > > The fix for me was to rebuild the kernel and make sure CONFIG_APM_ALLOW_INTS > > was enabled. So, do you ever use power management and is this similar, or do > > you have a completely different problem ? > > Wow, this sounds like this might be the problem. I just checked my > `.config' and indeed `CONFIG_APM_ALLOW_INTS' is not enabled. And indeed > I have been suspending/resuming the machine a few times before the > partition got corrupted. > > So, does DMA work correctly on your system after setting this option? Yes, it does. I have the drive running in UDMA mode 2, and get ~16MB/s from 'hdparm -t -T'. I have the "use DMA automatically" option turned on in the kernel, so I inherit the BIOS settings which are correct. I've used standby and hibernation with complete success since. Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interesting fs corruption story
On Tue, Mar 06, 2001 at 08:10:10PM -0500, Ettore Perazzoli wrote: On 06 Mar 2001 17:01:02 -0800, Tim Wright wrote: [...] The fix for me was to rebuild the kernel and make sure CONFIG_APM_ALLOW_INTS was enabled. So, do you ever use power management and is this similar, or do you have a completely different problem ? Wow, this sounds like this might be the problem. I just checked my `.config' and indeed `CONFIG_APM_ALLOW_INTS' is not enabled. And indeed I have been suspending/resuming the machine a few times before the partition got corrupted. So, does DMA work correctly on your system after setting this option? Yes, it does. I have the drive running in UDMA mode 2, and get ~16MB/s from 'hdparm -t -T'. I have the "use DMA automatically" option turned on in the kernel, so I inherit the BIOS settings which are correct. I've used standby and hibernation with complete success since. Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 lock contention and scalability
On Tue, Mar 06, 2001 at 10:12:17PM -0500, Jeff Dike wrote: [EMAIL PROTECTED] said: If you're a UP system, it never makes sense to spin in userland, since you'll just burn up a timeslice and prevent the lock holder from running. I haven't looked, but assume that their code only uses spinlocks on SMP. If you're an SMP system, then you shouldn't be using a spinlock unless the critical section is "short", in which case the waiters should simply spin in userland rather than making system calls which is simply overhead. This is a problem that UML is going to have when I turn SMP back on. Emulating a multiprocessor box on a UP host with the existing locking primitives is going to result in exactly this problem. Yes. On a uniprocessor system, a simple fallback is to just use a semaphore instead of a spinlock, since you can guarantee that there's no point in scheduling the current task until the holder of the "lock" releases it. Otherwise, the spin calling sched_yield() each iteration isn't too horrible. Actually, what's really needed here is an efficient form of dynamically marking a process as non-preemptible so that when acquiring a spinlock the process can ensure that it exits the critical section as fast as possible, when it would relinquish its non-preemptible privilege. That sounds like a pretty fundamental (and abusable) mechanism. It would be if it were generally available. The implementation on DYNIX/ptx requires a privilege (PRIV_SCHED IIRC), to be able to use it. It was added for a database to prevent preemption during critical sections. I had a suggestion from an IBM guy at ALS last year to make UML "spin"-locks actually sleep in the host (this doesn't make them sleep locks in userspace because they don't call schedule), which sounds reasonable. This gives the lock-holder an opportunity to run immediately. It's unclear to me what the wake-up mechanism would be, though. Hmmm.. depends what you mean by sleep i.e sleep(3) vs. making a system call that sleeps. I would have thought the latter, and use semaphores again. Another thought I had was to raise the priority of a thread holding a spinlock. This would reduce the chance that it would be preempted by a thread that will waste a timeslice spinning on that lock. I don't know whether this is a good idea either. That's basically a weaker version of the no-preempt. Not a bad idea, but less than optimal :-) Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interesting fs corruption story
Hi Ettore, I have no idea if this is related to your problem since you didn't mention that key part, but with the same drive, I managed to trash my root partition incredibly badly by trying to use DMA and then do APM suspend or hibernate. On wakeup, I'd get an 'hda: lost interrupt' but then things would appear to carry on. The fix for me was to rebuild the kernel and make sure CONFIG_APM_ALLOW_INTS was enabled. So, do you ever use power management and is this similar, or do you have a completely different problem ? Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 lock contention and scalability
On Tue, Mar 06, 2001 at 11:39:17PM +, Matthew Kirkwood wrote:
> On Tue, 6 Mar 2001, Jonathan Lahr wrote:
>
> [ sorry to reply over another reply, but I don't have
> the original of this ]
>
> > > Tridge and I tried out the postgresql benchmark you used here and this
> > > contention is due to a bug in postgres. From a quick strace, we found
> > > the threads do a load of select(0, NULL, NULL, NULL, {0,0}).
>
> I can shed some light on this (though I'm far from a PG hacker).
>
> Postgres can use either of two locking methods -- SysV semaphores
> (which it tries to avoid, asusming that they'll be too heavy) or
> userspace spinlocks (via inline assembler on platforms which support
> it).
>
> In the slow path of a spinlock_acquire they busy wait for a few
> cycles, and then call schedule with a zero timeout assuming that
> it'll basically do the same as a sched_yield() but more portably.
>
Ugh !
I had a nasty feeling that might be what they were up to. The reason for
the "ugh" is as follows. If you're a UP system, it never makes sense to
spin in userland, since you'll just burn up a timeslice and prevent the
lock holder from running. I haven't looked, but assume that their code only
uses spinlocks on SMP. If you're an SMP system, then you shouldn't be
using a spinlock unless the critical section is "short", in which case the
waiters should simply spin in userland rather than making system calls which
is simply overhead. If the argument is that the "spinners" take too much
useful time away from other processes, then it sounds like the contention is
too high, or that the critical section is sufficiently long that semaphores
would be a better choice.
Actually, what's really needed here is an efficient form of dynamically
marking a process as non-preemptible so that when acquiring a spinlock the
process can ensure that it exits the critical section as fast as possible,
when it would relinquish its non-preemptible privilege.
Another synchronization method popular with database peeps is "post/wait"
for which SGI have a patch available for Linux. I understand that this is
relatively "light weight" and might be a better choice for PG.
Tim
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 lock contention and scalability
On Tue, Mar 06, 2001 at 11:39:17PM +, Matthew Kirkwood wrote:
On Tue, 6 Mar 2001, Jonathan Lahr wrote:
[ sorry to reply over another reply, but I don't have
the original of this ]
Tridge and I tried out the postgresql benchmark you used here and this
contention is due to a bug in postgres. From a quick strace, we found
the threads do a load of select(0, NULL, NULL, NULL, {0,0}).
I can shed some light on this (though I'm far from a PG hacker).
Postgres can use either of two locking methods -- SysV semaphores
(which it tries to avoid, asusming that they'll be too heavy) or
userspace spinlocks (via inline assembler on platforms which support
it).
In the slow path of a spinlock_acquire they busy wait for a few
cycles, and then call schedule with a zero timeout assuming that
it'll basically do the same as a sched_yield() but more portably.
Ugh !
I had a nasty feeling that might be what they were up to. The reason for
the "ugh" is as follows. If you're a UP system, it never makes sense to
spin in userland, since you'll just burn up a timeslice and prevent the
lock holder from running. I haven't looked, but assume that their code only
uses spinlocks on SMP. If you're an SMP system, then you shouldn't be
using a spinlock unless the critical section is "short", in which case the
waiters should simply spin in userland rather than making system calls which
is simply overhead. If the argument is that the "spinners" take too much
useful time away from other processes, then it sounds like the contention is
too high, or that the critical section is sufficiently long that semaphores
would be a better choice.
Actually, what's really needed here is an efficient form of dynamically
marking a process as non-preemptible so that when acquiring a spinlock the
process can ensure that it exits the critical section as fast as possible,
when it would relinquish its non-preemptible privilege.
Another synchronization method popular with database peeps is "post/wait"
for which SGI have a patch available for Linux. I understand that this is
relatively "light weight" and might be a better choice for PG.
Tim
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Interesting fs corruption story
Hi Ettore, I have no idea if this is related to your problem since you didn't mention that key part, but with the same drive, I managed to trash my root partition incredibly badly by trying to use DMA and then do APM suspend or hibernate. On wakeup, I'd get an 'hda: lost interrupt' but then things would appear to carry on. The fix for me was to rebuild the kernel and make sure CONFIG_APM_ALLOW_INTS was enabled. So, do you ever use power management and is this similar, or do you have a completely different problem ? Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.4.2-acX does not recognize any bus on Intel Serverworks based motherboard
This has come up before a few times. The concensus seems to be that the PCI
fixup code for Serverworks chipsets is currently broken (and it's less simple to
fix than it should be due to lack of documentation - there have been some
educated guesses but it would be nicer to know for sure). The suggestion was
to simply kill the fixup code and believe the BIOS (i.e. kill the relevant
lines in the pcibios_fixups[] array in arch/i386/kernel/pci-pc.c). That has
worked on the systems I'm using that use the Serverworks chipset.
Tim
On Fri, Mar 02, 2001 at 07:34:44PM +0100, Petr Vandrovec wrote:
> Hi Martin,
> what's idea behind 'pcibios_last_bus >= 0xff' ? On friend's STL2 Intel
> motherboard Serverworks bridge contains 0x01 in reg. 0x44 (first bus behind
> bridge) and 0xFF in reg. 0x45 (last bus behind bridge).
> This sets pcibios_last_bus to 0xFF in serverworks fixup code. After this
> pcibios_fixup_peer_bridges() refuses to do anything, so devices connected
> to secondary bus are not visible to system.
> With patch below system sees all devices again - patch is for 2.4.2-ac9.
> Thanks,
> Petr Vandrovec
> [EMAIL PROTECTED]
>
>
> diff -urdN linux/arch/i386/kernel/pci-pc.c linux/arch/i386/kernel/pci-pc.c
> --- linux/arch/i386/kernel/pci-pc.c Fri Mar 2 17:55:05 2001
> +++ linux/arch/i386/kernel/pci-pc.c Fri Mar 2 17:56:50 2001
> @@ -784,7 +784,7 @@
> struct pci_dev dev;
> u16 l;
>
> - if (pcibios_last_bus <= 0 || pcibios_last_bus >= 0xff)
> + if (pcibios_last_bus <= 0 || pcibios_last_bus > 0xff)
> return;
> DBG("PCI: Peer bridge fixup\n");
> for (n=0; n <= pcibios_last_bus; n++) {
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Another rsync over ssh hang (repeatable, with 2.4.1 on both ends)
On Fri, Mar 02, 2001 at 10:12:36AM +, Russell King wrote: > On Thu, Mar 01, 2001 at 04:41:01PM -0800, Scott Laird wrote: > > I have a fairly repeatable rsync over ssh stall that I'm seeing between > > two Linux boxes, both running identical 2.4.1 kernels. The stall is > > fairly easy to repeat in our environment -- it can happen up to several > > times per minute, and usually happens at least once per minute. It > > doesn't really seem to be data-sensitive. The stall will last until the > > session times out *unless* I take one of two steps to "unstall" it. The > > easiest way to do this is to run 'strace -p $PID' against the sending ssh > > process. As soon as the strace is started, rsync starts working again, > > but will stall again (even with strace still running) after a short period > > of time. > >... > > According to 'ps l', the ssh process is waiting in 'sock_wait_for_wmem'. > > I've also reported this recently, and got told that it was because I was > running 2.2.15pre13 on one end. Thanks for confirming that 2.2.15pre13 > is not the cause. > Be very careful here. He did nothing of the sort. He merely indicated that there is at least one problem running rsync over ssh between 2.4.1 systems. There is no guarantee that your problem and his are identical. As Alexey pointed out, there are bad bugs in 2.2.15 which can cause a TCP connection to get stuck. Given that you are running 2.2.15, you'd need a tcpdump to determine whether you hit one of these or not. I've been bitten too many times assuming something was one big problem only to find out later it was actually several smaller ones. Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hashing and directories
On Fri, Mar 02, 2001 at 10:04:10AM +0100, Pavel Machek wrote: > > xargs is very ugly. I want to rm 12*. Just plain "rm 12*". *Not* "find > . -name "12*" | xargs rm, which has terrible issues with files names > > "xyzzy" > "bla" > "xyzzy bla" > "12 xyzzy bla" > Getting a bit OffTopic(TM) here, but that's why the GNU versions of the tools wisely added options to output '\0' rather than '\n' as a separator for the data i.e. find . -name '12*' -print0 | xargs -0 rm does exactly what you want it to - no surprises. The point about arbitrary limits, is, however well taken. The fact that the space for exec args and environment historically was static and of a fixed size is not a good reason to perpetuate the limitation. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hashing and directories
On Fri, Mar 02, 2001 at 10:04:10AM +0100, Pavel Machek wrote: xargs is very ugly. I want to rm 12*. Just plain "rm 12*". *Not* "find . -name "12*" | xargs rm, which has terrible issues with files names "xyzzy" "bla" "xyzzy bla" "12 xyzzy bla" Getting a bit OffTopic(TM) here, but that's why the GNU versions of the tools wisely added options to output '\0' rather than '\n' as a separator for the data i.e. find . -name '12*' -print0 | xargs -0 rm does exactly what you want it to - no surprises. The point about arbitrary limits, is, however well taken. The fact that the space for exec args and environment historically was static and of a fixed size is not a good reason to perpetuate the limitation. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Another rsync over ssh hang (repeatable, with 2.4.1 on both ends)
On Fri, Mar 02, 2001 at 10:12:36AM +, Russell King wrote: On Thu, Mar 01, 2001 at 04:41:01PM -0800, Scott Laird wrote: I have a fairly repeatable rsync over ssh stall that I'm seeing between two Linux boxes, both running identical 2.4.1 kernels. The stall is fairly easy to repeat in our environment -- it can happen up to several times per minute, and usually happens at least once per minute. It doesn't really seem to be data-sensitive. The stall will last until the session times out *unless* I take one of two steps to "unstall" it. The easiest way to do this is to run 'strace -p $PID' against the sending ssh process. As soon as the strace is started, rsync starts working again, but will stall again (even with strace still running) after a short period of time. ... According to 'ps l', the ssh process is waiting in 'sock_wait_for_wmem'. I've also reported this recently, and got told that it was because I was running 2.2.15pre13 on one end. Thanks for confirming that 2.2.15pre13 is not the cause. Be very careful here. He did nothing of the sort. He merely indicated that there is at least one problem running rsync over ssh between 2.4.1 systems. There is no guarantee that your problem and his are identical. As Alexey pointed out, there are bad bugs in 2.2.15 which can cause a TCP connection to get stuck. Given that you are running 2.2.15, you'd need a tcpdump to determine whether you hit one of these or not. I've been bitten too many times assuming something was one big problem only to find out later it was actually several smaller ones. Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.4.2-acX does not recognize any bus on Intel Serverworks based motherboard
This has come up before a few times. The concensus seems to be that the PCI
fixup code for Serverworks chipsets is currently broken (and it's less simple to
fix than it should be due to lack of documentation - there have been some
educated guesses but it would be nicer to know for sure). The suggestion was
to simply kill the fixup code and believe the BIOS (i.e. kill the relevant
lines in the pcibios_fixups[] array in arch/i386/kernel/pci-pc.c). That has
worked on the systems I'm using that use the Serverworks chipset.
Tim
On Fri, Mar 02, 2001 at 07:34:44PM +0100, Petr Vandrovec wrote:
Hi Martin,
what's idea behind 'pcibios_last_bus = 0xff' ? On friend's STL2 Intel
motherboard Serverworks bridge contains 0x01 in reg. 0x44 (first bus behind
bridge) and 0xFF in reg. 0x45 (last bus behind bridge).
This sets pcibios_last_bus to 0xFF in serverworks fixup code. After this
pcibios_fixup_peer_bridges() refuses to do anything, so devices connected
to secondary bus are not visible to system.
With patch below system sees all devices again - patch is for 2.4.2-ac9.
Thanks,
Petr Vandrovec
[EMAIL PROTECTED]
diff -urdN linux/arch/i386/kernel/pci-pc.c linux/arch/i386/kernel/pci-pc.c
--- linux/arch/i386/kernel/pci-pc.c Fri Mar 2 17:55:05 2001
+++ linux/arch/i386/kernel/pci-pc.c Fri Mar 2 17:56:50 2001
@@ -784,7 +784,7 @@
struct pci_dev dev;
u16 l;
- if (pcibios_last_bus = 0 || pcibios_last_bus = 0xff)
+ if (pcibios_last_bus = 0 || pcibios_last_bus 0xff)
return;
DBG("PCI: Peer bridge fixup\n");
for (n=0; n = pcibios_last_bus; n++) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x very unstable on 8-way IBM 8500R
On Thu, Mar 01, 2001 at 05:04:09PM -0800, Dr. Kelsey Hudson wrote: > On Thu, 1 Mar 2001, Matilainen Panu (NRC/Helsinki) wrote: > > > I've been playing around with 8-way IBM8500R (8x700MHz Xeon) with 4.5GB > > memory & AIC7xxx SCSI-controller. It's perfectly stable with 2.2-kernel > > (from Red Hat 7) but very erratic on all 2.4-kernels I've tried it with > > (2.4.[012], compiled both with egcs and RH7's gcc-2.96, both share the > > Under redhat 7 you should use kgcc to compile the kernel, since gcc2.96 is > inherently broken(*). > For the umpteenth time, no it isn't. There are serious bugs in the shipped version of gcc in RedHat 7.0, but they are fixed by applying the update. The reason for supplying kgcc is to allow building a 2.2 kernel, because of bugs in the kernel, NOT the compiler. > > same symptoms). It did have a ServeRAID controller too but IBM suggested > > we take it out since 4500R also had problems with it on 2.4 but it didn't > > make any difference at all. Also tried to turn off highmem support but > > didn't make difference either. > > (*) redhat chose to ship an experimental compiler with this release of > the distribution that has a great many bugs. to ensure proper kernel > compillation another proven version of gcc was included, but called > kgcc instead. You should always use this to compile your kernels > under redhat 7 until the newer version of gcc is released. > No. Provided you grab the update, you can build the 2.4 kernel perfectly happily using the RedHat gcc snapshot. I'm running it successfully on a number of machines. The issue with 2.4 on certain Netfinities is a bad interaction between the NMI watchdog code and the systems management card. Changing compilers makes no difference. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x very unstable on 8-way IBM 8500R
Just FYI, I am chasing this problem. There appears to be an unpleasant interaction between the Advanced Systems Management card and the NMI watchdog code. Ripping the card out of the machine also eradicates the problem, but is less desirable. I'll let people know when there's a better solution. Tim On Thu, Mar 01, 2001 at 03:30:56PM +0200, Matilainen Panu (NRC/Helsinki) wrote: > On Thu, 1 Mar 2001, ext Andrew Morton wrote: > > "Matilainen Panu (NRC/Helsinki)" wrote: > > > On Thu, 1 Mar 2001, ext Andrew Morton wrote: > > > > > > > > Is it stable with `nmi_watchdog=0'? > > > > > > If the default value for nmi_watchdog is 0 then no - I added the > > > nmi_watchdog=1 just to see if that makes any difference. If it's on by > > > default then I'll need to test it that way. > > > > Default for nmi_watchdog is `enabled'. > > > > Several people have reported that turning it off with > > the `nmi_watchdog=0' LILO option makes systems stable. > > Nobody knows why. > > > > (If nmi_watchdog _does_ make the achine stable, please > > tell linux-kernel.). > > It's too early to say for sure but that seems to have fixed it. Uptime now > nearly an hour under loads of 20-30 which is way more than it has been > able to stay up before. I'll let you know whether its still up tomorrow. > > Million thanks for the tip! > > - Panu - > -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Will Mosix go into the standard kernel?
On Thu, Mar 01, 2001 at 04:02:11PM +0100, Tor Arntsen wrote: > Daniel Ridge <[EMAIL PROTECTED]> writes: > [...] > >Compare this total volume to the thousands of lines of patches that > >RedHat or VA add to their kernel RPMS before shipping. I just don't see > [...] > > What's good about that? The first thing I do is to rip out the RedHat > kernel and compile and install a pure kernel from ftp.kernel.org. What's good is the added value that their customers gain. If you don't feel there is any, then you're probably running the wrong distribution. The nice thing with Linux is that you are free to go and grab your own kernel if you wish to do so. > It's *bad* that those vendors deliver hacked kernels. It's not > something that should be recommended as a *goal*! No it isn't. You seem to assume that your requirements match everybody elses. This is highly unlikely. A particular vendor will have a number of requirements for their distribution (hopefully driven by customer demand). At the time that they create a distribution, it's quite possible that no current pure kernel meets those requirements. It's perfectly reasonable for a vendor to make changes to meet those requirements, provided they abide by the licensing demands. For instance, one major change in Red Hat 7.0 is that the kernel supports USB. At the time, 2.4 wasn't ready and 2.2 didn't have support. What do you suggest they should have done ? The source code to the kernel that Red Hat ships is readily available, so I fail to see why shipping a modified kernel is such a big issue. > When I need a new kernel version I can't sit back and hope with > crossed fingers that RedHat (or whatever vendor) comes out with a > new, hacked version of Linus' latest. > Commercial customers rarely "require a new kernel version". They may encounter problems that require fixing the kernel, but otherwise, they frequently couldn't care less about the kernel. In such cases, they need some form of support. There's nothing to suggest that a vendor-modified kernel is inherently harder to support, provided that it doesn't diverge too radically. Most people buy computers to run applications, not an operating system. Those of us who do work on OS's are in the distinct minority. Given that Linus works on the development kernel, wanting to run on "Linus' latest" implies you're not using Linux in production or that you're very brave :-) Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Will Mosix go into the standard kernel?
On Thu, Mar 01, 2001 at 04:02:11PM +0100, Tor Arntsen wrote: Daniel Ridge [EMAIL PROTECTED] writes: [...] Compare this total volume to the thousands of lines of patches that RedHat or VA add to their kernel RPMS before shipping. I just don't see [...] What's good about that? The first thing I do is to rip out the RedHat kernel and compile and install a pure kernel from ftp.kernel.org. What's good is the added value that their customers gain. If you don't feel there is any, then you're probably running the wrong distribution. The nice thing with Linux is that you are free to go and grab your own kernel if you wish to do so. It's *bad* that those vendors deliver hacked kernels. It's not something that should be recommended as a *goal*! No it isn't. You seem to assume that your requirements match everybody elses. This is highly unlikely. A particular vendor will have a number of requirements for their distribution (hopefully driven by customer demand). At the time that they create a distribution, it's quite possible that no current pure kernel meets those requirements. It's perfectly reasonable for a vendor to make changes to meet those requirements, provided they abide by the licensing demands. For instance, one major change in Red Hat 7.0 is that the kernel supports USB. At the time, 2.4 wasn't ready and 2.2 didn't have support. What do you suggest they should have done ? The source code to the kernel that Red Hat ships is readily available, so I fail to see why shipping a modified kernel is such a big issue. When I need a new kernel version I can't sit back and hope with crossed fingers that RedHat (or whatever vendor) comes out with a new, hacked version of Linus' latest. Commercial customers rarely "require a new kernel version". They may encounter problems that require fixing the kernel, but otherwise, they frequently couldn't care less about the kernel. In such cases, they need some form of support. There's nothing to suggest that a vendor-modified kernel is inherently harder to support, provided that it doesn't diverge too radically. Most people buy computers to run applications, not an operating system. Those of us who do work on OS's are in the distinct minority. Given that Linus works on the development kernel, wanting to run on "Linus' latest" implies you're not using Linux in production or that you're very brave :-) Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x very unstable on 8-way IBM 8500R
Just FYI, I am chasing this problem. There appears to be an unpleasant interaction between the Advanced Systems Management card and the NMI watchdog code. Ripping the card out of the machine also eradicates the problem, but is less desirable. I'll let people know when there's a better solution. Tim On Thu, Mar 01, 2001 at 03:30:56PM +0200, Matilainen Panu (NRC/Helsinki) wrote: On Thu, 1 Mar 2001, ext Andrew Morton wrote: "Matilainen Panu (NRC/Helsinki)" wrote: On Thu, 1 Mar 2001, ext Andrew Morton wrote: Is it stable with `nmi_watchdog=0'? If the default value for nmi_watchdog is 0 then no - I added the nmi_watchdog=1 just to see if that makes any difference. If it's on by default then I'll need to test it that way. Default for nmi_watchdog is `enabled'. Several people have reported that turning it off with the `nmi_watchdog=0' LILO option makes systems stable. Nobody knows why. (If nmi_watchdog _does_ make the achine stable, please tell linux-kernel.). It's too early to say for sure but that seems to have fixed it. Uptime now nearly an hour under loads of 20-30 which is way more than it has been able to stay up before. I'll let you know whether its still up tomorrow. Million thanks for the tip! - Panu - -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x very unstable on 8-way IBM 8500R
On Thu, Mar 01, 2001 at 05:04:09PM -0800, Dr. Kelsey Hudson wrote: On Thu, 1 Mar 2001, Matilainen Panu (NRC/Helsinki) wrote: I've been playing around with 8-way IBM8500R (8x700MHz Xeon) with 4.5GB memory AIC7xxx SCSI-controller. It's perfectly stable with 2.2-kernel (from Red Hat 7) but very erratic on all 2.4-kernels I've tried it with (2.4.[012], compiled both with egcs and RH7's gcc-2.96, both share the Under redhat 7 you should use kgcc to compile the kernel, since gcc2.96 is inherently broken(*). For the umpteenth time, no it isn't. There are serious bugs in the shipped version of gcc in RedHat 7.0, but they are fixed by applying the update. The reason for supplying kgcc is to allow building a 2.2 kernel, because of bugs in the kernel, NOT the compiler. same symptoms). It did have a ServeRAID controller too but IBM suggested we take it out since 4500R also had problems with it on 2.4 but it didn't make any difference at all. Also tried to turn off highmem support but didn't make difference either. (*) redhat chose to ship an experimental compiler with this release of the distribution that has a great many bugs. to ensure proper kernel compillation another proven version of gcc was included, but called kgcc instead. You should always use this to compile your kernels under redhat 7 until the newer version of gcc is released. No. Provided you grab the update, you can build the 2.4 kernel perfectly happily using the RedHat gcc snapshot. I'm running it successfully on a number of machines. The issue with 2.4 on certain Netfinities is a bad interaction between the NMI watchdog code and the systems management card. Changing compilers makes no difference. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Wrong data [was Re: Incorrect module init message..]
There's nothing wrong with the mailing list. Pavel, please set your clock correctly :-) Tim On Thu, Feb 22, 2001 at 04:45:15AM -0500, Mike A. Harris wrote: > On Sat, 1 Jan 2000, Pavel Machek wrote: > > >Date: Sat, 1 Jan 2000 05:06:12 + > >From: Pavel Machek <[EMAIL PROTECTED]> > >To: Mike A. Harris <[EMAIL PROTECTED]> > >Cc: Linux Kernel mailing list <[EMAIL PROTECTED]> > >Content-Type: text/plain; charset=us-ascii > >Subject: Re: Incorrect module init message.. > > [...] > > Umm... WTF? I just received this message again from Jan 1.. > Something is awry with lkml... -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Wrong data [was Re: Incorrect module init message..]
There's nothing wrong with the mailing list. Pavel, please set your clock correctly :-) Tim On Thu, Feb 22, 2001 at 04:45:15AM -0500, Mike A. Harris wrote: On Sat, 1 Jan 2000, Pavel Machek wrote: Date: Sat, 1 Jan 2000 05:06:12 + From: Pavel Machek [EMAIL PROTECTED] To: Mike A. Harris [EMAIL PROTECTED] Cc: Linux Kernel mailing list [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: Incorrect module init message.. [...] Umm... WTF? I just received this message again from Jan 1.. Something is awry with lkml... -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux OS boilerplate
On Mon, Feb 19, 2001 at 03:07:33AM -0700, Eric W. Biederman wrote: > With linux-2.4 able to do a complete PCI bus setup it isn't as bad it used > to be, but it's still pretty significant. For an incomplete subset of chipsets. Serverworks doesn't work correctly for a start (see the threads relating to having to kill the Serverworks fixup code and rely on the BIOS to see all the PCI busses on larger systems). Of course, this is due to Serverworks refusal to release documentation (yes, I've heard the excuses regarding protection of IP), and it's a worrisome. What else are we potentially failing to setup on this chipset ? Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: had: lost interrupt...
You didn't give the (likely more) important part of your .config, but I'll bet that you have CONFIG_APM_ALLOW_INTS disabled. Turn it on, rebuild and reboot. At least on a Thinkpad T20, trying to use UDMA, and APM without APM_ALLOW_INTS enabled gives an 'hda: lost interrupt'. Even worse, I didn't hang, but was able to go on and trash my hard drive :-( With CONFIG_APM_ALLOW_INTS turned on, everything behaves nicely. Tim On Sat, Feb 17, 2001 at 10:08:21AM +0100, Fons Rademakers wrote: > Hi, > >in my laptop (HP 4150B) I upgraded from a 12GB IBM Travelstar to an > 20GB IBM Travelstar (both 4200rpm). After the upgrade I moved also to > 2.4.2-pre3 and reiserfs. However, the problem I now have is that after > resume I get the message "hda: lost interrupt" and the only thing to do > is to reset the machine (in the only good thing is that reiserfs saved > me a lot of fsck time). > > Any idea what the problem might be? Is the larger disk not supported by > the BIOS (it is recognized properly). People mentioned not to use DMA > anymore? > > With 2.2.18 and the 12GB disk there were never problems (except that the > disk got bad blocks ;-(). > > My IDE setup in .config is below. > > > Cheers, Fons. > [IDE config elided] -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: had: lost interrupt...
You didn't give the (likely more) important part of your .config, but I'll bet that you have CONFIG_APM_ALLOW_INTS disabled. Turn it on, rebuild and reboot. At least on a Thinkpad T20, trying to use UDMA, and APM without APM_ALLOW_INTS enabled gives an 'hda: lost interrupt'. Even worse, I didn't hang, but was able to go on and trash my hard drive :-( With CONFIG_APM_ALLOW_INTS turned on, everything behaves nicely. Tim On Sat, Feb 17, 2001 at 10:08:21AM +0100, Fons Rademakers wrote: Hi, in my laptop (HP 4150B) I upgraded from a 12GB IBM Travelstar to an 20GB IBM Travelstar (both 4200rpm). After the upgrade I moved also to 2.4.2-pre3 and reiserfs. However, the problem I now have is that after resume I get the message "hda: lost interrupt" and the only thing to do is to reset the machine (in the only good thing is that reiserfs saved me a lot of fsck time). Any idea what the problem might be? Is the larger disk not supported by the BIOS (it is recognized properly). People mentioned not to use DMA anymore? With 2.2.18 and the 12GB disk there were never problems (except that the disk got bad blocks ;-(). My IDE setup in .config is below. Cheers, Fons. [IDE config elided] -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux OS boilerplate
On Mon, Feb 19, 2001 at 03:07:33AM -0700, Eric W. Biederman wrote: With linux-2.4 able to do a complete PCI bus setup it isn't as bad it used to be, but it's still pretty significant. For an incomplete subset of chipsets. Serverworks doesn't work correctly for a start (see the threads relating to having to kill the Serverworks fixup code and rely on the BIOS to see all the PCI busses on larger systems). Of course, this is due to Serverworks refusal to release documentation (yes, I've heard the excuses regarding protection of IP), and it's a worrisome. What else are we potentially failing to setup on this chipset ? Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: finding Tekram SCSI dc395U linux patch driver:
I asked Kurt why it was not submitted to the mainstream kernel. He said that some people are still experiencing problems with the card/driver and he doesn't feel it's stable enough to go in. I'm personally using it with no issues, but I'm only driving a CD-RW - not exactly stressing things. It sounds like the people having issues need to debug the problems, or maybe it could go in under CONFIG_EXPERIMENTAL ? Tim On Thu, Feb 15, 2001 at 10:46:22PM +0100, Juergen Schoew wrote: > Hi, > On 15-Feb-01 Thomas Lau wrote: > > hey, I found this driver on mandrake kernel sources, it's ac3, but I > > need ac14 code, also, why still not port this driver into kernel? > > the patch file already released 1 years ago > > Have you checked http://www.garloff.de/kurt/linux/dc395/index.html > there ist a driver Version 1.32 (2000-12-02). > > Regards > > Juergen Schoew > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: finding Tekram SCSI dc395U linux patch driver:
I asked Kurt why it was not submitted to the mainstream kernel. He said that some people are still experiencing problems with the card/driver and he doesn't feel it's stable enough to go in. I'm personally using it with no issues, but I'm only driving a CD-RW - not exactly stressing things. It sounds like the people having issues need to debug the problems, or maybe it could go in under CONFIG_EXPERIMENTAL ? Tim On Thu, Feb 15, 2001 at 10:46:22PM +0100, Juergen Schoew wrote: Hi, On 15-Feb-01 Thomas Lau wrote: hey, I found this driver on mandrake kernel sources, it's ac3, but I need ac14 code, also, why still not port this driver into kernel? the patch file already released 1 years ago Have you checked http://www.garloff.de/kurt/linux/dc395/index.html there ist a driver Version 1.32 (2000-12-02). Regards Juergen Schoew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Will the IBM OMNI printer driver be making its way into the kernel tree?
Maybe I'm missing your point, but why would it go into the kernel tree ? This is all stuff that gets done in userland under Linux. The Omni drivers plugin with Ghostscript and generate output appropriate to the printer. There's no kernel relevance here. Tim On Tue, Feb 13, 2001 at 01:42:27PM -0800, Miles Lane wrote: > http://oss.software.ibm.com/developer/opensource/linux/projects/omni/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI bridge handling 2.4.0-test10 -> 2.4.2-pre3
I believe that, in general, we want working fixup routines so the we don't have to rely on the BIOS. That said, it's apparent that the ServerWorks routines are broken. Fixing them is going to be troublesome, given ServerWorks attitude towards releasing specs. It's on my list of things to try to sort out, since some of the Netfinities I use are ServerWorks based. Tim On Tue, Feb 13, 2001 at 03:41:37PM +0100, Adam Lackorzynski wrote: > On Tue Feb 13, 2001 at 12:20:14 +0100, Jan-Benedict Glaw wrote: > > On Tue, Feb 13, 2001 at 12:38:15AM +0100, Adam Lackorzynski wrote: > > > On Mon Feb 12, 2001 at 14:04:20 +0100, Jan-Benedict Glaw wrote: > > > > I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID > > > > controller. The mainboard is ServerWorks based and however, 2.4.2-pre3 > > > > fails to find the RAID controller. I think there's a problem at > > > > scanning PCI busses behind PCI bridges. Here's the PCI bus layout as > > > > 2.4.0-test10 recognizes it: > > > > > > --- pci-pc.c.orig Tue Feb 13 00:02:50 2001 > > > +++ pci-pc.cTue Feb 13 00:19:29 2001 > > > @@ -953,9 +953,6 @@ > > [Removal of serverworks fixup routines] > > > > That patch cured the problem; the box is up'n'running again. Thanks! > > Ok, fine. > > Since this patch works for Jan, Dan and me I'd suggest putting it into > the kernel and thus removing the fixup routines (Anyone know the reason > why they're there?). > > Comments?! > > > Adam > -- > Adam [EMAIL PROTECTED] > Lackorzynski http://a.home.dhs.org -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI bridge handling 2.4.0-test10 - 2.4.2-pre3
I believe that, in general, we want working fixup routines so the we don't have to rely on the BIOS. That said, it's apparent that the ServerWorks routines are broken. Fixing them is going to be troublesome, given ServerWorks attitude towards releasing specs. It's on my list of things to try to sort out, since some of the Netfinities I use are ServerWorks based. Tim On Tue, Feb 13, 2001 at 03:41:37PM +0100, Adam Lackorzynski wrote: On Tue Feb 13, 2001 at 12:20:14 +0100, Jan-Benedict Glaw wrote: On Tue, Feb 13, 2001 at 12:38:15AM +0100, Adam Lackorzynski wrote: On Mon Feb 12, 2001 at 14:04:20 +0100, Jan-Benedict Glaw wrote: I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID controller. The mainboard is ServerWorks based and however, 2.4.2-pre3 fails to find the RAID controller. I think there's a problem at scanning PCI busses behind PCI bridges. Here's the PCI bus layout as 2.4.0-test10 recognizes it: --- pci-pc.c.orig Tue Feb 13 00:02:50 2001 +++ pci-pc.cTue Feb 13 00:19:29 2001 @@ -953,9 +953,6 @@ [Removal of serverworks fixup routines] That patch cured the problem; the box is up'n'running again. Thanks! Ok, fine. Since this patch works for Jan, Dan and me I'd suggest putting it into the kernel and thus removing the fixup routines (Anyone know the reason why they're there?). Comments?! Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://a.home.dhs.org -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Will the IBM OMNI printer driver be making its way into the kernel tree?
Maybe I'm missing your point, but why would it go into the kernel tree ? This is all stuff that gets done in userland under Linux. The Omni drivers plugin with Ghostscript and generate output appropriate to the printer. There's no kernel relevance here. Tim On Tue, Feb 13, 2001 at 01:42:27PM -0800, Miles Lane wrote: http://oss.software.ibm.com/developer/opensource/linux/projects/omni/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LILO and serial speeds over 9600
Yup, those who fail to learn from TCP are doomed to re-invent it, badly, at the wrong level . Seriously, the console subsystem on the Sequent (now IBM) NUMA-Q systems originally used UDP. It wound up as a serious mess. We changed to TCP. I'll admit that the NUMA-Q console subsystem does more than what is being proposed here currently, but it's likely to grow. In general UDP is only appropriate if you *can* afford to drop data. Did RDP ever get anywhere ? Regards, Tim On Tue, Feb 13, 2001 at 12:11:01AM +, Alan Cox wrote: > > I'm sure you can. That doesn't mean it's the right solution. > > And the UDP proposal will be at least as big if it does retransmits, and if > it doesnt , its junk. It will also need as much buffering, if not the same > packing trick > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://vger.kernel.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: TRM-S1040/DC395 Driver?
Well, it's back up again now. I've been using the patches for a couple of months with no problems. This is on a 4-processor P6 box, so the SMP support seems sound. I only have a CDRW attached on this SCSI bus so I can't comment on disk support etc. Kurt, have you submitted this driver to be included into the mainstream kernel ? It seems solid enough to me. Regards, Tim On Sat, Feb 10, 2001 at 11:22:19AM -0500, Nick Papadonis wrote: > Hi, > > Anyone know where the kernel patches for the DC395U with the Tekram TRM-S1040 > chip are? > > http://www.garloff.de/ appears to be down. > > Will these be included in the 2.4.x kernel tree? > > Thanks. > > -- > - Nick > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: TRM-S1040/DC395 Driver?
Well, it's back up again now. I've been using the patches for a couple of months with no problems. This is on a 4-processor P6 box, so the SMP support seems sound. I only have a CDRW attached on this SCSI bus so I can't comment on disk support etc. Kurt, have you submitted this driver to be included into the mainstream kernel ? It seems solid enough to me. Regards, Tim On Sat, Feb 10, 2001 at 11:22:19AM -0500, Nick Papadonis wrote: Hi, Anyone know where the kernel patches for the DC395U with the Tekram TRM-S1040 chip are? http://www.garloff.de/ appears to be down. Will these be included in the 2.4.x kernel tree? Thanks. -- - Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: LILO and serial speeds over 9600
Yup, those who fail to learn from TCP are doomed to re-invent it, badly, at the wrong level GRIN. Seriously, the console subsystem on the Sequent (now IBM) NUMA-Q systems originally used UDP. It wound up as a serious mess. We changed to TCP. I'll admit that the NUMA-Q console subsystem does more than what is being proposed here currently, but it's likely to grow. In general UDP is only appropriate if you *can* afford to drop data. Did RDP ever get anywhere ? Regards, Tim On Tue, Feb 13, 2001 at 12:11:01AM +, Alan Cox wrote: I'm sure you can. That doesn't mean it's the right solution. And the UDP proposal will be at least as big if it does retransmits, and if it doesnt , its junk. It will also need as much buffering, if not the same packing trick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: [OT] Re: PCI-SCI Drivers v1.1-7 released
Umm, I don't know what compiler you've got etc. Jeff, but I just tried gcc-2.96 (-69) here, and '#ident' is supported and works perfectly. The only way to even get a warning is to use '-ansi -pedantic' which yields: junk.c:1:2: warning: ISO C does not allow #ident I don't think the problem is with gcc, at least not the Red Hat 7.0 version. Tim On Wed, Feb 07, 2001 at 11:31:47AM -0700, Jeff V. Merkey wrote: > On Wed, Feb 07, 2001 at 12:32:13PM -0500, Jakub Jelinek wrote: > > On Wed, Feb 07, 2001 at 11:08:52AM -0700, Jeff V. Merkey wrote: > > > Not supporting #ident for CVS managed code bases would see to > > > me, at first glance, to be a show stopper to shipping a release > > > of anything, since many folks need CVS support. > > > > Could you please explain what you mean by not supporting #ident? > > It works just fine for me in all our gcc packages I've checked. > > > > Jakub > > It returns an "unknown keyword" error message from the sci source base. > Offending source line is in /src/IRM/drv/src/prolog.h in version > 1.1-7. > > Jeff > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Enabling ACPI and APM at same time?
>From /usr/src/linux-2.4.X/Documentation/pm.txt: "No sorry, you can not have both ACPI and APM enabled and running at once. Some people with broken ACPI or broken APM implementations would like to use both to get a full set of working features, but you simply can not mix and match the two. Only one power management interface can be in control of the machine at once. Think about it.." Sorry :-( Tim On Wed, Feb 07, 2001 at 11:57:38AM +0100, Pavel Machek wrote: > Hi! > > Is it possible to have _both_ ACPI and APM enabled? > > I really need APM on my notebook (so that machine suspends when it > runs out of batteries, not powers off), but having /proc/power/* > information would be *very* handy. > Pavel > -- > I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." > Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hotplugging with regular PCI cards
Hi Adam, I saw the same demo. It's not the machine as such that's interesting. The hotplug is achieved because of the chipset support. In fact the Compaq chipset that supports hotplug PCI is used in quite a few of the IBM Netfinity machines, and, I'm sure, many other servers. I'm going to be testing their code on the Netfinities that I have access to shortly, but see no reason to believe that it shouldn't work. In fact it would be good if anybody with machines using the Compaq hotplug PCI chips would test the code. As you mention, there is driver work needed, both the change you mention and to make sure that all the drivers are using the newer 2.4 PCI infrastructure in the first place (the hotplug support relies on this). Regards, Tim On Tue, Feb 06, 2001 at 10:08:06PM -0800, Adam J. Richter wrote: > I saw an interesting demonstration at LinuxWorld last week. > Compaq had a machine that did hot plugging with regular PCI cards (not > Compact PCI). If anyone out there is familiar with this machine, > I would be interested in knowing what the status is on getting > the support for that backplain integrated into the stock kernels. > > When that occurs, that will be yet another reason to treat all > new style PCI drivers as potentially hot pluggable, even if those cards > are not currently available in a CardBus or CompactPCI form, and in > particular to change all of the xxx_pci_tbl declarations in PCI > drivers that are currently marked as __initdata back to __devinitdata. > > Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 > [EMAIL PROTECTED] \ / San Jose, California 95129-1034 > +1 408 261-6630 | g g d r a s i l United States of America > fax +1 408 261-6631 "Free Software For The Rest Of Us." > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hotplugging with regular PCI cards
Hi Adam, I saw the same demo. It's not the machine as such that's interesting. The hotplug is achieved because of the chipset support. In fact the Compaq chipset that supports hotplug PCI is used in quite a few of the IBM Netfinity machines, and, I'm sure, many other servers. I'm going to be testing their code on the Netfinities that I have access to shortly, but see no reason to believe that it shouldn't work. In fact it would be good if anybody with machines using the Compaq hotplug PCI chips would test the code. As you mention, there is driver work needed, both the change you mention and to make sure that all the drivers are using the newer 2.4 PCI infrastructure in the first place (the hotplug support relies on this). Regards, Tim On Tue, Feb 06, 2001 at 10:08:06PM -0800, Adam J. Richter wrote: I saw an interesting demonstration at LinuxWorld last week. Compaq had a machine that did hot plugging with regular PCI cards (not Compact PCI). If anyone out there is familiar with this machine, I would be interested in knowing what the status is on getting the support for that backplain integrated into the stock kernels. When that occurs, that will be yet another reason to treat all new style PCI drivers as potentially hot pluggable, even if those cards are not currently available in a CardBus or CompactPCI form, and in particular to change all of the xxx_pci_tbl declarations in PCI drivers that are currently marked as __initdata back to __devinitdata. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Enabling ACPI and APM at same time?
From /usr/src/linux-2.4.X/Documentation/pm.txt: "No sorry, you can not have both ACPI and APM enabled and running at once. Some people with broken ACPI or broken APM implementations would like to use both to get a full set of working features, but you simply can not mix and match the two. Only one power management interface can be in control of the machine at once. Think about it.." Sorry :-( Tim On Wed, Feb 07, 2001 at 11:57:38AM +0100, Pavel Machek wrote: Hi! Is it possible to have _both_ ACPI and APM enabled? I really need APM on my notebook (so that machine suspends when it runs out of batteries, not powers off), but having /proc/power/* information would be *very* handy. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: PCI-SCI Drivers v1.1-7 released
Umm, I don't know what compiler you've got etc. Jeff, but I just tried gcc-2.96 (-69) here, and '#ident' is supported and works perfectly. The only way to even get a warning is to use '-ansi -pedantic' which yields: junk.c:1:2: warning: ISO C does not allow #ident I don't think the problem is with gcc, at least not the Red Hat 7.0 version. Tim On Wed, Feb 07, 2001 at 11:31:47AM -0700, Jeff V. Merkey wrote: On Wed, Feb 07, 2001 at 12:32:13PM -0500, Jakub Jelinek wrote: On Wed, Feb 07, 2001 at 11:08:52AM -0700, Jeff V. Merkey wrote: Not supporting #ident for CVS managed code bases would see to me, at first glance, to be a show stopper to shipping a release of anything, since many folks need CVS support. Could you please explain what you mean by not supporting #ident? It works just fine for me in all our gcc packages I've checked. Jakub It returns an "unknown keyword" error message from the sci source base. Offending source line is in /src/IRM/drv/src/prolog.h in version 1.1-7. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Mainboard with Serverworks HE Chipset
Thanks, this seems to confirm my suspicion that there's some incompatibility between the NMI watchdog code and the Serverworks chipset. Still trying to find out exactly what's wrong... Tim On Sat, Jan 20, 2001 at 12:26:37PM +0100, Matthias Schniedermeyer wrote: > > You could try booting with 'nmi_watchdog=0' and see what happens. > > Since i "append"ed it into the lilo-confi i haven't had a lockup. :-)) > > > > Bis denn > > -- > Real Programmers consider "what you see is what you get" to be just as > bad a concept in Text Editors as it is in women. No, the Real Programmer > wants a "you asked for it, you got it" text editor -- complicated, > cryptic, powerful, unforgiving, dangerous. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Mainboard with Serverworks HE Chipset
Thanks, this seems to confirm my suspicion that there's some incompatibility between the NMI watchdog code and the Serverworks chipset. Still trying to find out exactly what's wrong... Tim On Sat, Jan 20, 2001 at 12:26:37PM +0100, Matthias Schniedermeyer wrote: You could try booting with 'nmi_watchdog=0' and see what happens. Since i "append"ed it into the lilo-confi i haven't had a lockup. :-)) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: multi-queue scheduler update
ads > > > was less than the number of processors. I'll give the tests a try > > > with a smaller number of threads. I'm also open to suggestions for > > > what benchmarks/test methods I could use for scheduler testing. If > > > you remember what people have used in the past, please let me know. > > > > > > -- > > > Mike Kravetz [EMAIL PROTECTED] > > > IBM Linux Technology Center > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" > > in > > > the body of a message to [EMAIL PROTECTED] > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > > ___ > > Lse-tech mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/lse-tech > > > > > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > ___ > Lse-tech mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/lse-tech -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: multi-queue scheduler update
e.net/lists/listinfo/lse-tech -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Mainboard with Serverworks HE Chipset
On Wed, Jan 17, 2001 at 12:33:09AM +0100, Matthias Schniedermeyer wrote: > #include > > > > I got a "Tyan Thunder HE-SL"-Mainboard today, which has a "Severworks > ServerSet III HE"-Chipset. (2xPIII 933, 2x512MB PC133 ECC-Registered > SDRAM) > > And i have one problem and one question. > > First the question. I have an uptime of phenomenal 29minutes and "cat > /proc/interrupts" tells me this > > NMI: 175819 175819 > LOC: 175829 175828 > > Should i be worried? Or can i ignore it. With my former Mainboard NMI was > (AFAIR) always 0. > > Now my problem. > > The Graphic-Card is a Geforce 2, Xfree is 4.02 (compiled under 2.2.17). > > When i start X, everything is fine. When i go back to text-console and > wait "some time" and then switch back to X the computer locks solid and i > have to press the Big-Red Button. (Switching back to X after a "short" > periode of time, at the text-console, works "normaly") > > If anyone needs more information, i will happily provide them. > You could try booting with 'nmi_watchdog=0' and see what happens. What you describe sounds like the problem I have seen on a few boxes, and disabling the NMI watchdog makes the huge numbers of NMIs and the system hang go away. Still unclear why this is happening. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Mainboard with Serverworks HE Chipset
On Wed, Jan 17, 2001 at 12:33:09AM +0100, Matthias Schniedermeyer wrote: #include hallo.h I got a "Tyan Thunder HE-SL"-Mainboard today, which has a "Severworks ServerSet III HE"-Chipset. (2xPIII 933, 2x512MB PC133 ECC-Registered SDRAM) And i have one problem and one question. First the question. I have an uptime of phenomenal 29minutes and "cat /proc/interrupts" tells me this NMI: 175819 175819 LOC: 175829 175828 Should i be worried? Or can i ignore it. With my former Mainboard NMI was (AFAIR) always 0. Now my problem. The Graphic-Card is a Geforce 2, Xfree is 4.02 (compiled under 2.2.17). When i start X, everything is fine. When i go back to text-console and wait "some time" and then switch back to X the computer locks solid and i have to press the Big-Red Button. (Switching back to X after a "short" periode of time, at the text-console, works "normaly") If anyone needs more information, i will happily provide them. You could try booting with 'nmi_watchdog=0' and see what happens. What you describe sounds like the problem I have seen on a few boxes, and disabling the NMI watchdog makes the huge numbers of NMIs and the system hang go away. Still unclear why this is happening. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0
On Sat, Jan 13, 2001 at 12:01:04PM +1100, Andrew Morton wrote:
> Tim Wright wrote:
[...]
> > p_lock(lock);
> > retry:
> > ...
> > if (condition where we need to sleep) {
> > p_sema_v_lock(sema, lock);
> > /* we got woken up */
> > p_lock(lock);
> > goto retry;
> > }
> > ...
>
> That's an interesting concept. How could this actually be used
> to protect a particular resource? Do all users of that
> resource have to claim both the lock and the semaphore before
> they may access it?
>
Ahh, I thought I might have been a tad terse in my explanation. No, the
idea here is that the spinlock guards the access to the data structure we're
concerned about. The sort of code I was thinking about would be where we need
to allocate a data structure. We attempt to grab it from the freelist, and if
successful, then everything is fine. Otherwise, we need to sleep waiting for
some resources to be freed up. So we atomically drop the lock and sleep on
the allocation semaphore. The freeing-up path is also protected by the same
lock, and would do something like 'if (there are sleepers) wake(sleepers)'.
This wakes up the sleeper who grabs the spinlock and retries the alloc. The
result is no races, but we don't spin or hold the lock for a long time.
It doesn't have to be an allocation. The same idea works for e.g. protecting
access to "buffer cache" (not necessarily Linux) data, and then atomically
releasing the lock and sleeping waiting for an I/O to happen.
>
> There are a number of locks (such as pagecache_lock) which in the
> great majority of cases are held for a short period, but are
> occasionally held for a long period. So these locks are not
> a performance problem, they are not a scalability problem but
> they *are* a worst-case-latency problem.
>
Understood. Whether the above metaphor works depends on whether or not the
"holding for a long time" case fits this pattern i.e. at this stage,
I'm not sufficiently familiar with the Linux VM code. I'm in the process
of rectifying that problem :-)
Regards,
Tim
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0
On Sat, Jan 13, 2001 at 12:01:04PM +1100, Andrew Morton wrote:
Tim Wright wrote:
[...]
p_lock(lock);
retry:
...
if (condition where we need to sleep) {
p_sema_v_lock(sema, lock);
/* we got woken up */
p_lock(lock);
goto retry;
}
...
That's an interesting concept. How could this actually be used
to protect a particular resource? Do all users of that
resource have to claim both the lock and the semaphore before
they may access it?
Ahh, I thought I might have been a tad terse in my explanation. No, the
idea here is that the spinlock guards the access to the data structure we're
concerned about. The sort of code I was thinking about would be where we need
to allocate a data structure. We attempt to grab it from the freelist, and if
successful, then everything is fine. Otherwise, we need to sleep waiting for
some resources to be freed up. So we atomically drop the lock and sleep on
the allocation semaphore. The freeing-up path is also protected by the same
lock, and would do something like 'if (there are sleepers) wake(sleepers)'.
This wakes up the sleeper who grabs the spinlock and retries the alloc. The
result is no races, but we don't spin or hold the lock for a long time.
It doesn't have to be an allocation. The same idea works for e.g. protecting
access to "buffer cache" (not necessarily Linux) data, and then atomically
releasing the lock and sleeping waiting for an I/O to happen.
There are a number of locks (such as pagecache_lock) which in the
great majority of cases are held for a short period, but are
occasionally held for a long period. So these locks are not
a performance problem, they are not a scalability problem but
they *are* a worst-case-latency problem.
Understood. Whether the above metaphor works depends on whether or not the
"holding for a long time" case fits this pattern i.e. at this stage,
I'm not sufficiently familiar with the Linux VM code. I'm in the process
of rectifying that problem :-)
Regards,
Tim
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
