Re: [2.4.3] PPP errors
On Wed, 4 Apr 2001, Manfred H. Winter wrote: > Apr 4 02:05:21 marvin pppd[1227]: Couldn't set tty to PPP discipline: Invalid a > rgument > Apr 4 02:05:21 marvin pppd[1227]: Exit. Did you load the 'ppp_async.o' module? Regards, Cesar Suga <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to make ramdisk based system?
Just like Steffen Grunewald, an infinite number of monkeys can type this: > I'm trying to figure out how to make a primaryly ram-disk based > Linux system (which should then be able to access "real" storage, > but that is really the last step). > initrd??? /usr/src/linux/Documentation/initrd.txt -- ___ /~~lintux at | . __ ___ \/ /~ \/ | | http://www. |_ | | | | |_| /\ o \_ /\ | | Webmaster at http://www.algoritme.nl/__/ ~|---|~ |_cook but how the figure to a http_| ~~~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2048 byte/sector problems with kernel 2.4
On Tue, 3 Apr 2001, Harvey Fishman wrote: >On Tue, 3 Apr 2001, Alan Cox wrote: > >> > I also tried it with 2.2.18 there it works but it seems to be >utterly >> > slow. I'm using kernel 2.4.2(XFS version to be precise). >> >>M/O disks are slow. At a minimum make sure you are using a physical >block >>size of 2048 bytes when using 2048 byte media and plenty of memory to >> >cache stuff when reading. Seek times on M/O media are pretty poor > >Another thing making for the snailicity of MO drives is that writing is >a >two pass operation. It is very like core memory; first you write the >spot >to a known state, and then you write the data. So you have an average >latency of 25 mS. for write operations and 8.33 mS. for read >operations. >There WERE direct overwrite media for a while that would, in theory, be >able to write the data directly, but a combination of high cost, >limited >sources, and strong questions about the permanence of the recorded data >severely limited the demand for these and I think that they have been >withdrawn. > >Harvey No, direct overwrite disks are expensive, but they are still available. I do not know of any, and have not heard of any problems related to direct overwrite technology. For some reason M/O never really caught on in the US, and the high price of direct overwrite disks is what seems to be killing them off. I have a bunch I use for backup and have never had any problems. Slow is a relative term. Compared to a Seagate X15? Yes, a M/O drive is probably slower. Compared to an 8X CD burner? No, my 640MB and 1.3GB M/O drives are quite a bit faster, particularly for random writes. For most applications, M/O is designed to compete with the latter, rather than the former. People need to remember that M/O drives are meant to compete with CD-R or CD-RW as a moderate capacity, highly robust storage medium for archiving and backup. But it is somewhat annoying that 2.4.x doesn't (yet) support their 2K sector sizes correctly. - John _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a quest for a better scheduler
I was actually suspecting that the extra lines in your patch were there for a reason :) A few questions: What is the real impact of a (slight) change in scheduling semantics? Under which situation one should notice a difference? As you state in your papers the global decision comes with a cost, is it worth it? Could you make a port of your thing on recent kernels? I tried and I failed and I don't have enough time to figure out why, that should be trivial for you though. TIA, ciao, - Fabio Mike Kravetz wrote: > On Tue, Apr 03, 2001 at 05:18:03PM -0700, Fabio Riccardi wrote: > > > > I have measured the HP and not the "scalability" patch because the two do more > > or less the same thing and give me the same performance advantages, but the > > former is a lot simpler and I could port it with no effort on any recent > > kernel. > > Actually, there is a significant difference between the HP patch and > the one I developed. In the HP patch, if there is a schedulable task > on the 'local' (current CPU) runqueue it will ignore runnable tasks on > other (remote) runqueues. In the multi-queue patch I developed, the > scheduler always attempts to make the same global scheduling decisions > as the current scheduler. > > -- > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Can't boot with the 2.4.3 kernel.
:: I configured and build it, and all looked OK. Did you select the right CPU type in the configuration? -- Juha - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Can't boot with the 2.4.3 kernel.
Hello all, I'm using slackware 7.1 with the 2.2.16 kernel, And I'm trying to install the 2.4.3 kernel. I configured and build it, and all looked OK. But when I'm trying to load the new kernel from LILO, It uncompressing the kernel, then says Ok, now booting the kernel gives some dots, and the it gets stucked... nothing happens. Does anyone knows what can cause this? I'm not a member of this mailing list, so please respond to my personal mail([EMAIL PROTECTED]). Thanks allot! -Amir. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 Tue, Apr 03, 2001 at 05:18:03PM -0700, Fabio Riccardi wrote: > > I have measured the HP and not the "scalability" patch because the two do more > or less the same thing and give me the same performance advantages, but the > former is a lot simpler and I could port it with no effort on any recent > kernel. Actually, there is a significant difference between the HP patch and the one I developed. In the HP patch, if there is a schedulable task on the 'local' (current CPU) runqueue it will ignore runnable tasks on other (remote) runqueues. In the multi-queue patch I developed, the scheduler always attempts to make the same global scheduling decisions as the current scheduler. -- 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] 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.3-ac2
In article <9ae3qj$pc9$[EMAIL PROTECTED]>, I wrote: >It's still done manually, and now with the 2.4.3 series we >have to adjust the scripts a bit. Scripts adjusted, time for some sleep ;-) Danny -- Holland Hosting www.hoho.nl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.3-ac2
Miles Lane <[EMAIL PROTECTED]> wrote: >You still have the URL for www.bzimage.org in this announcement, >but there are no incremental patches there for either 2.4.3-ac1 >or 2.4.3-ac2. They're made as i type ;-) It's still done manually, and now with the 2.4.3 series we have to adjust the scripts a bit. For now look at the "overview" link and follow the 2.4.3 link. Regards, Danny -- Holland Hosting www.hoho.nl [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/
Multicast tunneling in 2.4
I am trying to set up a tunnel from my linux machine to the MBone. My kernel (2.4.2) supports multicasting and advanced routing: CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MROUTE=y I have read http://www.linuxdoc.org/HOWTO/Multicast-HOWTO.html and http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html. Unfortunately, Section 7 of the Advanced Routing HOWTO (Multicast routing) says: "FIXME: Editor Vacancy! (somebody is working on it, though)" Suppose I know the IP address of a nearby multicast router and would like to set up a tunnel from my machine to that router (a tunnel to the MBone), so that I may receive multicast datagrams in spite of the fact that intervening routers are ignorant of multicast routing protocols. Is this possible with the 2.4.2 kernel? I cannot find documentation to this effect, but the existence of (which contains some structs previously defined in mrouted) makes me think that it is possible. -- Dave Bailey [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3 freeze under heavy writing + open rxvt
On Tue, 3 Apr 2001, Simon Kirby wrote: > Three times now I've had 2.4.3 freeze on my dual CPU box while doing a > "dd if=/dev/zero of=/dev/hdc bs=1024k" (a drive to be RMA'd :)). I got > bored and opened an rxvt, and as the machine was swapping in (I assume), > everything froze. The mouse still moved for about 5 seconds before the > freeze, and the window was visible as it was attempting to start tcsh. > > I'm guessing that what's happening is something is waiting on a lock and > blocking interrupts (?) for five seconds while it is swapping in, and the > NMI lockup detector is kicking in and really breaking it. I've noticed the same thing. I was doing a rather sadistic test, checking a memory chip. one window: make -j in 2.4.2 src; and in another, dd if=/dev/hda of=/dev/null bs=4096k. The third window was running top, and froze. A fourth window wouldn't get past login: -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.3 freeze under heavy writing + open rxvt
> Three times now I've had 2.4.3 freeze on my dual CPU box while doing a > "dd if=/dev/zero of=/dev/hdc bs=1024k" (a drive to be RMA'd :)). I got Does it happen if you boot with < 900Mb of ram ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.3 freeze under heavy writing + open rxvt
Three times now I've had 2.4.3 freeze on my dual CPU box while doing a "dd if=/dev/zero of=/dev/hdc bs=1024k" (a drive to be RMA'd :)). I got bored and opened an rxvt, and as the machine was swapping in (I assume), everything froze. The mouse still moved for about 5 seconds before the freeze, and the window was visible as it was attempting to start tcsh. I'm guessing that what's happening is something is waiting on a lock and blocking interrupts (?) for five seconds while it is swapping in, and the NMI lockup detector is kicking in and really breaking it. I have my serial console plugged in and minicom actually capturing now, so I'll see if I can get a trace of some sort. Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nfsd vfs.c does not seems to fsync() with file overwrite, whenit have to.
On Tuesday April 3, [EMAIL PROTECTED] wrote:
> NB> Whenever you write to a file you change the inode - by changing the
> NB> modify time at least. Look at generic_file_write in mm/filemap.c.
> NB> Notice the code:
> NB>if (count) {
> NB> remove_suid(inode);
> inode-> i_ctime = inode->i_mtime = CURRENT_TIME;
> NB> mark_inode_dirty_sync(inode);
> NB> }
>
> ! I see
>
> Well, actually I found three question here.
>
>
> 1st:
>
> Doesn't "calling write with size 0" should cause
> i_mtime = CURRENT_TIME;
> ?
Does it matter? Ask POSIX, or SUS or some other standard...
>
>
> 2nd:
> At where will the inode be written to storage in generic_file_write()?
>
> According to very end of this function it says:
>
> /* For now, when the user asks for O_SYNC, we'll actually
>* provide O_DSYNC. */
> if ((status >= 0) && (file->f_flags & O_SYNC))
> status = generic_osync_inode(inode, 1); /* 1 means datasync */
>
> This means write() does not write inode here. So it must be written
> somewhere before.
Probably not. I think it gets written after. Possibly not until
memory pressure or a regular sync() flushes it out.
This is probably not ideal, but I think that O_SYNC handling is still
a work-in-progress.
>
>
> 3rd:
> Is it really good idea to rely on write() for SYNCRONOUS write,
> rather than relying on fsync()??
>
> At least, if we use fsync(), we can assume that all updates of
> current nfsd will be held on file cache on memory. But not only,
> we can "WISH" for some "write" request that comes from different
> nfsd, or from different process, could be applied too, especially
> in case of SMP world.
>
> By calling fsync() all these will be updated to storage at once.
> And this can be held without waiting even jiffie.
> Yes we can do GATHER WRITE without any waiting tricks.
>
>
> Semantically, calling SYNCRONOUS write() and calling fsync() is
> equivalent.
>
> Then, isn't it better to choose 'better chanced' case? I mean,
> instead of switching write() option, isn't it better to call
> fsync()?
You are probably right. In practice, fsync is probably better than
O_SYNC, though in theory they should be the same.
But then in practice, almost everybody uses gathered writes, so fsync
is actually used.
>
> # It should make code more simple too, for even if you call
> # fsync(), if filesystem is being mounted "sync", fsunc()
> # have nothing to do, and will come back quickly anyway.
> # All we need to do is check ( status != UNSTABLE ) and
> # call nfsd_sync() right away.
>
>
> I know that relying to fsync() is bad, if there's known bug in
> fsync(), especially about ext2. But I never heard of one. Is there?
>
Well, fsync in ext2 in 2.2 is really slow on large files, but that is
an issue of fading significance.
However I am not sure that there is any guarantee that filesystems
will support fsync. I note that sys_fsync allows for the possibility
that fsync is supported on the file. NFSd should too.
I would prefer to wait for O_SYNC to be implemented properly than to
change nfsd to always use fsync, but I don't feel very strongly about
it.
>
>
> >> P.S. I don't really think we should wait for 10msec At point of
> >> Gathered writes. I don't think this will be of any help.
> >> It's because fsync() have locking of it's own.
> NB> The theory is that you might get 4 write requests inside 10msec.
>
> I know, but if those were all syncronous requiests, all those 4
> nfsds will stop for 10msec. And that means performance of nfs server
> have to pay 10msec each which means all 4 clients have to pay extra
> 10msec, even if writing to disk became less.
>
> We're really loosing 40msec with overlaps as total
If they were synchronous, then nfsd_write wouldn't notice concurrent
writes and wouldn't pause the 10msec.
I suggest that you do some benchmarking. Choose a test. See how fast
it runs. Change the code. See what difference it makes. I would
definately be interested in those sorts of results.
>
>
> Instead, all we need to do GATHER WRITE is to do
>
>asyncronous write()
>fsync()
>
> in this order. Because write() and fsync() contains locking, if
> write request is being held in such a quick speed, fsync() will be
> stopped by other process(CPU)'s write() request being queued at
> entry point of write().
I suspect that in most cases the async write would be quite quick, and
the fsync would start before the async write of the next request. But
try it and tell us what happens.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BTTV problems in 2.4.3
diff -urN linux-2.4.3/arch/i386/kernel/pci-pc.c
linux/arch/i386/kernel/pci-pc.c
--- linux-2.4.3/arch/i386/kernel/pci-pc.c Sat Mar 31 00:12:41 2001
+++ linux/arch/i386/kernel/pci-pc.c Thu Mar 29 05:00:04 2001
@@ -1035,7 +1035,7 @@
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C686_4, pci_fixup_via_acpi },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_8363_0, pci_fixup_vt8363 },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C691, pci_fixup_via691 },
- { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C598_1, pci_fixup_via691_2 },
+// { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C598_1, pci_fixup_via691_2 },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82371AB_3, pci_fixup_piix4_acpi },
{ 0 }
};
I had the same problem. This change solved it for me.
Marcus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ack() and end() in hw_irq_controller
I am trying to adopt the new irq.c under arch/i386/kernel to a MIPS board and hopefully to MIPS common code in general. This is in the anticipation that the irq.c file will be moved to common kernel directory in 2.5. While the rest look pretty self-explanatory, I do have a couple of questions about ack() and end(). 1. It seems to me that in ack() we need to clear any latched, edge triggerred interrupt AND disable the irq. True? 2. Similarly end() should re-enable the irq. 3. I don't quite understand the comment about end(). Any explanation? Does that imply we should check if it is disable before we re-enable the irq? However, it seems such complication can only happen on a SMP, right? /* * The ->end() handler has to deal with interrupts which got * disabled while the handler was running. */ Thanks in advance. Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 Tuesday, April 03, 2001 18:17:30 -0700 Fabio Riccardi <[EMAIL PROTECTED]> wrote: > Alan Cox wrote: > Indeed, I'm using RT sigio/sigwait event scheduling, bare clone threads > and zero-copy io. Fabio, I'm working on a similar solution, although I'm experimenting with SGI's KAIO patch to see what it can do. I've had to patch the kernel to implement POSIX style signal dispatch symantics (so that the thread which posted an I/O request doesn't have to be the one which catches the signal). Are you taking a similar approach, or is the lack of this behavior the reason you are using so many threads? --Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: goodbye
This would be a shame, as he has been a valuable resource.. Why has the list become more restrictive? I think that this is one list where we have to keep the ability to post from individuals separate from the need to make sure that their ISP or company is compliant to a set a of rules.. The LKML can't toe the strictest of lines, without loosing some possibly valuable contributors.. On 03 Apr 2001 18:01:42 -0300, Rik van Riel wrote: > Hi, > > this will be my last email to linux-kernel for a while since > davem and matti are using DUL on vger.kernel.org > > If you need to know something, don't count on me posting > anything here. For memory management things, please use > [EMAIL PROTECTED] instead. > > Rik > -- > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ > http://www.conectiva.com/ http://distro.conectiva.com.br/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- "Catch the Magic of Linux..." Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
Alan Cox wrote: > > for the "normal case" performance see my other message. > > I did - and with a lot of interest thanks! :) > > I agree that a better threading model would surely help in a web server, but to > > me this is not an excuse to live up with a broken scheduler. > > The problem has always been - alternative scheduler, crappier performance for > 2 tasks running (which is most boxes). If your numbers are right then the > HP patch is working as well for 1 or 2 tasks too Please verify them if you have a couple of spare hours. BTW: I measured similar results for the "scalability" patches on a 2.4.1 kernel, it would be worth the effort to seriously compare them from an architectural point of view, but I don't have the time right now... > > Unless we want to maintain the position tha the only way to achieve good > > performance is to embed server applications in the kernel, some minimal help > > should be provided to goodwilling user applications :) > > Indeed. I'd love to see you beat tux entirely in userspace. It proves the > rest of the API for the kernel is right Indeed, I'm using RT sigio/sigwait event scheduling, bare clone threads and zero-copy io. If only I had a really asynchronous sendfile, or a smarter madvise that wouldn't require to map files :) My server cannot execute dynamic stuff yet, it relies on Apache for that. Running X15 and TUX in the same conditions (i.e. dynamic code in Apache) I get exactly the same score in both cases. I'm adding a TUX-like dynamic interface, I hope to get it to work by next week, then I'll make a real confrontation. Regards, ciao, - Fabio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.3-ac2
Hi Alan, You still have the URL for www.bzimage.org in this announcement, but there are no incremental patches there for either 2.4.3-ac1 or 2.4.3-ac2. Miles Alan Cox wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ > > Intermediate diffs are available from > > http://www.bzimage.org > > (Note that the cmsfs port to 2.4 is a work in progress) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sandisk flashcard reader on 2.4.2. It works. Sort of.
On Tuesday 03 April 2001 19:16, Tim Waugh wrote: > > On Tue, Apr 03, 2001 at 02:08:13AM +0200, Stefan Linnemann wrote: > > the necessary features. I copied .config from the 2.2.17, superficially > > checked the config, and remade and rebooted. > > This was where I noted, that the parport, paride, epat and pd modules > > didn't get installed as modules at all. I haven't dug into the why of > > that, let those familiar with the processes and Makefiles do that. > It'll be because of the block device directory reorganisation I > expect, or something similar. Double-check your config. Config is fine, it's just make modules_install that's ignoring them. > > So I reconfigured to get those into the kernel, and remade and > > rebooted. No dice, so I succesfully again applied the same patch, > > configured it into the kernel and remade and rebooted. No > > SanDisk. For some reason or another I rebooted again, and lo and > > behold, we have a SanDisk. > So the kernel you run which can see the SanDisk is with, or without, > the C7/8 patch? With both 2.2.17 and 2.4.2, only with the patch, and it reports a c7 chip. The only times it did get recognized the 16 Mb SanDisk CompactFlash card (EC-16CF) was in the reader. Though even that now doesn't seem to help anymore. One clue only remains to be told: ever since installing the patch I get one error message lots of time: "invalid character 46 in exportstr for pd.drive0". It's even printed at bootup from almost every init script. > > I mount it ok, cd > > /sandisk/dir/, mv * elsewhere, my system hangs. Reset. > Enable magic-sysrq and see if Alt-SysRq-B reboots the machine or not. > Or, even better, jot down what Alt-SysRq-T says. It is in, and was in, I only had completely forgotten about that, never having had a need for it yet. > > So the message is: Yes, it could work, but with the patch from > > http://www.electricgod.net/~moomonk/epat/ it's slightly better working > > than without it. > This patch is in the queue, but behind the bug-fixes. That, I figured. Which is why I bothered the mailing list in the first place, so you know there are some issues with the patch as it is. > You might want to try fiddling with the BIOS options for the parallel > port and see if that makes any difference. The only options I get in BIOS for my parallel port are Output-Only, Bi-Directional, EPP and ECP. ECP was the setting, and changing that to EPP and Bi_Directional only removed some of the protocols reported by the OS, so I'm back to ECP now. I'll include a dmesg diff between one time he did recognize the thing and the current one: *** dmesg Wed Apr 4 02:03:56 2001 --- dmesg.sandisk Fri Mar 30 16:45:40 2001 *** *** 9,17 zone(0): 4096 pages. zone(1): 36864 pages. zone(2): 0 pages. ! Kernel command line: BOOT_IMAGE=linux ro root=301 hisax=3,2,10,0x180,HiSax opl3sa2=0x370,5,0,3,0x530,0x330 pd.drive0=0x378 Initializing CPU#0 ! Detected 233.290 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 465.30 BogoMIPS Memory: 158892k/163840k available (1118k kernel code, 4560k reserved, 374k data, 84k init, 0k highmem) --- 9,17 zone(0): 4096 pages. zone(1): 36864 pages. zone(2): 0 pages. ! Kernel command line: auto BOOT_IMAGE=linux ro root=301 hisax=3,2,10,0x180,HiSax opl3sa2=0x370,5,0,3,0x530,0x330 pd.drive0=0x378 Initializing CPU#0 ! Detected 233.294 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 465.30 BogoMIPS Memory: 158892k/163840k available (1118k kernel code, 4560k reserved, 374k data, 84k init, 0k highmem) *** *** 72,79 hdc: hdc1 hdc2 paride: epat registered as protocol 0 pd: pd version 1.05, major 45, cluster 64, nice 0 ! epat_init_protopda: Autoprobe failed ! pd: no valid drive found Floppy drive(s): fd0 is 1.44M FDC 0 is a National Semiconductor PC87306 Serial driver version 5.02 (2000-08-09) with MANY_PORTS MULTIPORT SHARE_IRQ ISAPNP enabled --- 72,81 hdc: hdc1 hdc2 paride: epat registered as protocol 0 pd: pd version 1.05, major 45, cluster 64, nice 0 ! epat_init_protopda: Sharing parport0 at 0x378 ! pda: epat 1.02, Shuttle EPAT chip c7 at 0x378, mode 2 (8-bit), delay 1 ! pda: SanDisk SDCFB-, master, 31360 blocks [15M], (490/2/32), removable media ! pda: pda1 Floppy drive(s): fd0 is 1.44M FDC 0 is a National Semiconductor PC87306 Serial driver version 5.02 (2000-08-09) with MANY_PORTS MULTIPORT SHARE_IRQ ISAPNP enabled Thanks for the reply, anyway, Stefan. -- Stefan Linnemannhttp://www.xs4all.nl/~mazur/ Systeem programmeur Unix ICQ: 25314387 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.3-ac2
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org (Note that the cmsfs port to 2.4 is a work in progress) 2.4.3-ac2 o Add the VIA C3 to the mtrr/setup code (Dave Jones) o Report PAE mode oopses better (Ingo Molnar) o Fix zap_low_mappings on PAE (Hugh Dickins) o Tidy up parport resource handling, fix bug (Tim Waugh) o Add series 6 backpack driver support(Tim Waugh) o Make lockd use daemonize() (Paul Mundt) o Fix aicasm to specify -I flags needed on some (Mads Jørgensen) distributions o Add docbook manual on bus independant I/O (Matthew Wilcox) | + a few additional notes I added o Make the VIA superIO driver honour the (Tim Waugh) irq/dma settings passed o Update mpt fusion drivers (Steve Ralston) o Add reiserfs maintainer entries (Steven Cole) o Experimental driver for communcation class USB (Brad Hards) | eg Broadcom and Ericsson USB cable modems o I2O updates, report SMART errors on i2o_block (Boji Kannanthanam) o Fix shm locking, races on swapping, accounting (Stephen Tweedie) and swapout of already mapped pages o Clean up REPORTING-BUGS (Steven Cole) o Fix ACM handling of CLOCAL (Vojtech Pavlik) o Fix sparc64 module_map/vfree bug(Hugh Dickins) o Fix scsi race on requeued requests (Mark Hemment) o Tulip driver update (Jeff Garzik) o Update bmac and gmac driver (Cort Dougan) o Winbond w9966cf webcam parport driver (Jakob Kemi) 2.4.3-ac1 o Merge Linus 2.4.3 final, diff versus 2.4.3 (me) 2.4.2-ac28 o Fix another modules race(me) o Add basic PM hooks to agpgart (me) o Update new xircom_cb driver (Arjan van de Ven) o Fix missing lock_kernel on truncate path(Al Viro) o Update klsi usb ethernet ids(Brad Hards) o Fix missing permission check in shm code(Matthew Klahn) o Add extra doupdate() calls to menuconfig(Moritz Schulte) o Update wireless extensions (Jean Tourrilhes) o Fix cdda reading problem(Jens Axboe) o Fix potential oops in usb-uhci (David Brownell) 2.4.2-ac27 o Rely on BIOS to setup apic bits on OSB4 (me) o Disable events when unloading cardbus yenta (me) | Fixes shared irq unload hang o Fix x86 IPI replay problems (Stephen Tweedie) o Add ALS100 gameport support (Vojtech Pavlik) o Fix wrong path in comment in vesafb (Andres Salomon) o Allow slab caches to force alignment always (Ingo Molnar) and thus fix PAE+ slab poisoning o Fix problems in faulting raw I/O pages (Stephen Tweedie) o Fix rawio error handling for raw I/O(Stephen Tweedie) | + other oddments o Change default max printer ports to 8 (Tim Waugh) o Parport soft control state fixes(Tim Waugh) o Fix cpu info compile(Constantine Gavrilov) o Set warning levels on reiserfs warn etc (Paul Mundt) o Fix duplicate IOVIRT debug config help (Steven Cole) o Revert mmap change that broke assumptions (and (Martin Diehl) it seems SuS) o Clean up fpu emu warnings on gcc 3.0cvs a bit (me) 2.4.2-ac26 o Fix es1370 build bug(me) o Fix sbpcd compile warnings (me) o Update usbnet driver(Oleg Drokin) o Update Alpha to pre8 vm changes (Ivan Kokshaysky) o Fix radeonfb config selections (Chris Lawrence) o Fix vmalloc mismerge(Various) o Fix n_r3964 console panic (Andrew Morton) o Update ibm camera drivers o Support 701b toshoboe fir o New xircom_cb driver(Arjan van de Ven, Jeff Garzik, Don Becker, Doug Ledford) o Fix procfs mount point for binfmt_misc (Al Viro) o Update hpt366 ide blacklist o Further ide blacklist updates o Smooth vm balancing (Marcelo Tosatti) o Fix irda assert (Arjan van de Ven) o Keep contrack cache sizes sane (Ben LaHaise) o Fix possible file truncate/write race (Ben
Re: a quest for a better scheduler
> for the "normal case" performance see my other message. I did - and with a lot of interest > I agree that a better threading model would surely help in a web server, but to > me this is not an excuse to live up with a broken scheduler. The problem has always been - alternative scheduler, crappier performance for 2 tasks running (which is most boxes). If your numbers are right then the HP patch is working as well for 1 or 2 tasks too > Unless we want to maintain the position tha the only way to achieve good > performance is to embed server applications in the kernel, some minimal help > should be provided to goodwilling user applications :) Indeed. I'd love to see you beat tux entirely in userspace. It proves the rest of the API for the kernel is right - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
Alan, for the "normal case" performance see my other message. I agree that a better threading model would surely help in a web server, but to me this is not an excuse to live up with a broken scheduler. The X15 server I'm working on now is a sort of user-space TUX, it uses only 8 threads per CPU and it achieves the same level of performance of the kernel space TUX. Even in this case the performance advantage of the multiqueue scheduler is remarkable, especially on a multi-CPU (> 2) architecture. To achieve some decent disk/CPU/network overlapping with the current linux blocking disk IO limitations there is no way to avoid a "bunch of server threads". I've (experimentally) figured out that 8-16 threads per CPU can assure some reasonable overlapping, depending on the memory size and disk subsystem speed. On a 8-way machine this means 64-128 active tasks, a total disaster with the current scheduler. Unless we want to maintain the position tha the only way to achieve good performance is to embed server applications in the kernel, some minimal help should be provided to goodwilling user applications :) TIA, ciao, - Fabio Alan Cox wrote: > > Is there any special reason why any of those patches didn't make it to > > the mainstream kernel code? > > All of them are worse for the normal case. Also 1500 running apache's isnt > a remotely useful situation, you are thrashing the cache even if you are now > not thrashing the scheduler. Use an httpd designed for that situation. Then > you can also downgrade to a cheap pentium class box for the task ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.4.3] PPP errors
Hi! I still get from time to time the following errors when trying to use ppp: Apr 4 02:05:21 marvin pppd[1227]: Plugin /usr/lib/passwordfd.so loaded. Apr 4 02:05:21 marvin pppd[1227]: pppd 2.4.0 started by mahowi, uid 500 Apr 4 02:05:21 marvin pppd[1227]: Perms of /dev/ttyS0 are ok, no 'mesg n' necce sary. Apr 4 02:05:21 marvin pppd[1227]: Couldn't set tty to PPP discipline: Invalid a rgument Apr 4 02:05:21 marvin pppd[1227]: Exit. +++ ver_linux output: Linux marvin 2.4.3 #3 Sun Apr 1 19:01:20 CEST 2001 i686 unknown Gnu C 2.95.2 Gnu make 3.79.1 binutils 2.10.0.33 util-linux 2.10s modutils 2.4.2 e2fsprogs 1.19 reiserfsprogs 3.x.0j PPP2.4.0 Linux C Libraryx1 root root 1382179 Jan 19 07:14 /lib/libc.so.6 Dynamic linker (ldd) 2.2 Procps 2.0.7 Net-tools 1.57 Kbd1.02 Sh-utils 2.0 Modules Loaded serial sb sb_lib uart401 isa-pnp NVdriver opl3 sound soundcore ipt_MASQUERADE iptable_nat ip_conntrack ppp_generic slhc iptable_filter ip_tables af_packet khttpd autofs4 unix 8139too ide-scsi aic7xxx scsi_mod +++ I didn't change my ppp configuration for months so I think it's a kernel problem. Bye, Manfred -- /"\| PGP-Key available at Public Key Servers \ / ASCII ribbon campaign | or at "http://www.mahowi.de/" X against HTML mail | RSA: 0xC05BC0F5 * DSS: 0x4613B5CA / \ and postings | GPG: 0x88BC3576 * ICQ: 61597169 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: memory size detection problem on 2.3.16+ and 2.4.x
> the bios will set the carry flag on the return from the call should > there be an error. However, the BIOS on my PC doesnt do this- infact > it seems to simply return from the call without changing any registers. Your BIOS is faulty. No new suprises. > meme801: > + xorl%edx, %edx # Clear regs to work around > + xorl%ecx, %ecx # flakey BIOSes which don't > + # use carry bit correctly > + # This way we get 0MB ram on > + # call failure Wouldn't setting the carry flag be clearer ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
Dear all,
I've spent my afternoon running some benchmarks to see if MQ patches would
degrade performance in the "normal case".
To measure performance I've used the latest lmbench and I have mesured the
kernel compile times on a dual pentium III box runing at 1GHz with an 133MHz
bus.
Results (attached) show that there is no measurable difference in performace
between a vanilla scheduler and a multiqueue scheduler when running only few
processes (the compilation benchmark runs essentially two processes, one per
CPU).
I have measured the HP and not the "scalability" patch because the two do more
or less the same thing and give me the same performance advantages, but the
former is a lot simpler and I could port it with no effort on any recent
kernel. It is indeed interesting to see that this patch was originally designed
for a 2.4.0-test10 kernel, and still works fine on the latest kernels, only a
minor change (one line) was required. A version of the patch for the 2.4.2-ac26
kernel is attached to this message.
Given the zero impact on "normal case" performance and the huge positive impact
(> 20%) in the heavy load case (70-80 runnable processess on a load of about
1400 total) I don't see why such a thing shouldn't be accepted in the
mainstream scheduler.
- Fabio
--- sched.c.origTue Mar 27 17:30:58 2001
+++ sched.c Tue Apr 3 16:45:21 2001
@@ -34,6 +34,7 @@
extern void timer_bh(void);
extern void tqueue_bh(void);
extern void immediate_bh(void);
+static inline void hop_queues(struct task_struct *, int);
/*
* scheduler variables
@@ -90,7 +91,8 @@
spinlock_t runqueue_lock __cacheline_aligned = SPIN_LOCK_UNLOCKED; /* inner */
rwlock_t tasklist_lock __cacheline_aligned = RW_LOCK_UNLOCKED; /* outer */
-static LIST_HEAD(runqueue_head);
+static struct list_head runqueue_head[NR_CPUS] = {
+LIST_HEAD_INIT((runqueue_head[0]))};
+static LIST_HEAD(rt_queue_head);
/*
* We align per-CPU scheduling data on cacheline boundaries,
@@ -100,12 +102,15 @@
struct schedule_data {
struct task_struct * curr;
cycles_t last_schedule;
+ struct list_head runqueue_head;
} schedule_data;
char __pad [SMP_CACHE_BYTES];
-} aligned_data [NR_CPUS] __cacheline_aligned = { {{_task,0}}};
+} aligned_data [NR_CPUS] __cacheline_aligned = { {{_task,0,
+ LIST_HEAD_INIT((aligned_data[0].schedule_data.runqueue_head))}}};
#define cpu_curr(cpu) aligned_data[(cpu)].schedule_data.curr
#define last_schedule(cpu) aligned_data[(cpu)].schedule_data.last_schedule
+#define cpu_rq(cpu) (aligned_data[(cpu)].schedule_data.runqueue_head)
struct kernel_stat kstat;
@@ -199,6 +204,33 @@
return goodness(p, cpu, prev->active_mm) - goodness(prev, cpu,
prev->active_mm);
}
+
+static inline int other_goodness(struct task_struct * p, int this_cpu, struct
+mm_struct *this_mm)
+{
+ int weight;
+
+ /*
+* select the current process after every other
+* runnable process, but before the idle thread.
+* Also, dont trigger a counter recalculation.
+*
+* Give the process a first-approximation goodness value
+* according to the number of clock-ticks it has left.
+*
+* Don't do any other calculations if the time slice is
+* over..
+*/
+ weight = p->counter;
+ if (!weight)
+ goto out2;
+
+ /* .. and a slight advantage to the current MM */
+ if (p->mm == this_mm || !p->mm)
+ weight += 1;
+ weight += 20 - p->nice;
+out2:
+ return weight;
+}
/*
* This is ugly, but reschedule_idle() is very timing-critical.
* We are called with the runqueue spinlock held and we must
@@ -266,6 +298,10 @@
} else {
if (oldest_idle == -1ULL) {
int prio = preemption_goodness(tsk, p, cpu);
+ /*
+* this will never be true for < 400 HZ non
+* realtime. optimize this? SAR
+*/
if (prio > max_prio) {
max_prio = prio;
@@ -277,6 +313,10 @@
tsk = target_tsk;
if (tsk) {
if (oldest_idle != -1ULL) {
+ /* push onto best queue */
+ if (p->policy == SCHED_OTHER){
+ hop_queues(p, tsk->processor);
+ }
best_cpu = tsk->processor;
goto send_now_idle;
}
@@ -306,20 +346,28 @@
*/
static inline void add_to_runqueue(struct task_struct * p)
{
- list_add(>run_list, _head);
+ if (p->policy == SCHED_OTHER){
+ list_add(>run_list, _rq(p->processor));
+ } else list_add(>run_list, _queue_head);
nr_running++;
}
-static inline
Linux 2.2.19 release notes
The master copy of this file is at http://www.linux.org.uk. Check there for updates and errata Linux 2.2.19 Release Notes Platforms:Alpha, M68K, PowerPC, S/390, Sparc, X86 Introduction Linux 2.2.19 is the latest update to the Linux kernel tree. The out of the box tree supports the Alpha, PPC, S/390, Sparc and X86 platforms. MIPS and ARM are mostly merged but you should obtain the platform specific tree. Compilers This code is intended to build with gcc 2.7.2 and egcs 1.1.2. gcc 2.95.2 and Red Hat gcc 2.96-79 are believed to build the tree correctly. As yet we have no detailed information on gcc 2.95.3 but it seems to build the tree correctly. Binary Compatibility Linux 2.2.19 should on the whole be fully binary compatible with old modules. In general you should not assume binary compatibility between kernel object modules in Linux. Security Notes Linux 2.2.19 contains significant security fixes as a result of third party testing and auditing. We are very grateful to those who contributed work and reports to this effort, in particular to OpenWall and to Chris Evans. Architecture Updates Alpha + Remove a bogus printk in the OSF syscall error path. + Fix ASN reuse races on Alpha SMP + Fix read_unlock races on Alpha SMP + Show registers across CPU's on SMP Alpha oops + Fix bottom half races on Alpha SMP + Use our own IRQ routing table for Ruffian boards + Remove bogus printk from Alpha exception tables ARM The ARM tree has been partially synchronized with the ARM working tree for 2.2 + Fix ptrace races on ARM + Miscellaneous ARM updates + Fix NFS alignment problems with ARM i386 + Fix CyrixIII panic on boot in some cases + Walk the top 8K not the top 4K of the stack on error dumps + Fix further CMOS locking + Correct microcode driver feature checking + Use E820 memory sizing + Handle E820 problems when run with IBM thinkpad + Speed up irq/fault paths by avoiding xchg() + Tighten up K6 bug check + The DMI check for APM could end up running after APM started + Updated A20 handler to 2.4 code. Fixes hangs on some obscure kit. + Watch for timers being reset to 18Hz by firmware bugs PowerPC + Fix power off during IDE pmac init + Update atyfb128 and serial for pmac + Add workarounds for firmware bugs on early iMac + Fix oops on resume on some pmac machines + Fix problems in the Macintosh HID driver and input driver + Fix the pci syscall on the PowerMac machines S/390 + General fix ups for S/390 problems + Add keventd to S/390 for drivers + Update DASD driver + Add support for over 4K of partitions in procfs + Update S/390 to support new official ELF id + Update hwc, ctc and iucv + Fix a problem in the FPU emulator Sparc + Add support for quad sbus sunhme + Update NFS compatibility syscalls + Add watchdog driver support + Update sparc64 syscall tables + Fix NETCTL_GETFD on sparc64 Security Updates binfmt_misc binfmt_misc touched user pages directly and could be exploited. CPIA driver An off by one buffer check in the CPIA driver allowed users to scribble into kernel memory CPUID and MSR drivers Unloading and reloading these could cause a crash due to missing unregister calls. Normally not exploitable but if set to autoload and unload they could be abused. Classifier Fix a possible hang in the classifier code. get/setsockopt Mishandling of sign bits in setsockopt and getsockopt allowed local DoS and other attacks. Ptrace/exec race Ptrace and exec as well as ptrace/suid races existed that could give a local user privileges. Sockfilter Boundary cases in sockfilter could be abused. It is not clear if these are actually exploitable strnlen_user Several problems with the implementation have been cured. SYS5 shared memory A code path existed where the shm code would scribble on very recently freed memory. It is not clear that this was actually exploitable. sysctl Mishandling of sign bits in sysctl allowed local users to scribble on kernel memory. Tighten packet length checks The masquerading code checks were
RE: md driver doesn't notice disk going out
I forgot to say, we're running kernel 2.4.3 + Sistina LVM patch 0.9.1b6.
> -Original Message-
> From: Michael S. Fischer
> Sent: Tuesday, April 03, 2001 5:09 PM
> To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> Subject: md driver doesn't notice disk going out
>
>
> Hello,
>
> We're testing lvm over md (RAID 1) for a database
> application. Part of our tests include simulating failure.
> So, we pulled the power on one of the drives, and the kernel
> reported...
>
> hdd: status error: status=0x00 { }
> hdd: drive not ready for command
> ...
> ide1: reset timed-out, status=0x80
> hdd: lost interrupt
> hdd: lost interrupt
> hdd: lost interrupt
> ...
>
> However, /proc/mdstat still reports:
>
> Personalities : [linear] [raid0] [raid1] [raid5]
> read_ahead 1024 sectors
> md1 : active raid1 hdd[1] hdb[0]
> 19925760 blocks [2/2] [UU]
>
> md0 : active raid1 hdc[1] hda[0]
> 19925760 blocks [2/2] [UU]
>
> It appears the md driver just didn't bother to notice -- and
> now all writes to the filesystem are blocked.
>
> In case it matters, here's our lvm config:
>
> --- Volume group ---
> VG Name data0_vg
> VG Access read/write
> VG Status available/resizable
> VG # 0
> MAX LV256
> Cur LV1
> Open LV 1
> MAX LV Size 255.99 GB
> Max PV256
> Cur PV2
> Act PV2
> VG Size 38 GB
> PE Size 4 MB
> Total PE 9728
> Alloc PE / Size 7680 / 30 GB
> Free PE / Size 2048 / 8 GB
> VG UUID 6XH7Nq-JL9u-cbjw-rUoP-Kx9o-hlZN-LPhdmj
>
> --- Logical volume ---
> LV Name/dev/data0_vg/data0_lv
> VG Namedata0_vg
> LV Write Accessread/write
> LV Status available
> LV # 1
> # open 1
> LV Size30 GB
> Current LE 7680
> Allocated LE 7680
> Stripes 2
> Stripe size (KByte) 16
> Allocation next free
> Read ahead sectors 120
> Block device 58:0
>
>
> --- Physical volumes ---
> PV Name (#) /dev/md0 (1)
> PV Status available / allocatable
> Total PE / Free PE4864 / 1024
>
> PV Name (#) /dev/md1 (2)
> PV Status available / allocatable
> Total PE / Free PE4864 / 1024
>
> Please CC: me on replies. Thanks.
>
> --
> Michael S. Fischer / michael at auctionwatch.com /
http://www.auctionwatch.com
Systems Engineer, AuctionWatch.com Inc. / Phone: +1 650 808 5842
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
md driver doesn't notice disk going out
Hello,
We're testing lvm over md (RAID 1) for a database application. Part of our
tests include simulating failure. So, we pulled the power on one of the
drives, and the kernel reported...
hdd: status error: status=0x00 { }
hdd: drive not ready for command
...
ide1: reset timed-out, status=0x80
hdd: lost interrupt
hdd: lost interrupt
hdd: lost interrupt
...
However, /proc/mdstat still reports:
Personalities : [linear] [raid0] [raid1] [raid5]
read_ahead 1024 sectors
md1 : active raid1 hdd[1] hdb[0]
19925760 blocks [2/2] [UU]
md0 : active raid1 hdc[1] hda[0]
19925760 blocks [2/2] [UU]
It appears the md driver just didn't bother to notice -- and now all writes
to the filesystem are blocked.
In case it matters, here's our lvm config:
--- Volume group ---
VG Name data0_vg
VG Access read/write
VG Status available/resizable
VG # 0
MAX LV256
Cur LV1
Open LV 1
MAX LV Size 255.99 GB
Max PV256
Cur PV2
Act PV2
VG Size 38 GB
PE Size 4 MB
Total PE 9728
Alloc PE / Size 7680 / 30 GB
Free PE / Size 2048 / 8 GB
VG UUID 6XH7Nq-JL9u-cbjw-rUoP-Kx9o-hlZN-LPhdmj
--- Logical volume ---
LV Name/dev/data0_vg/data0_lv
VG Namedata0_vg
LV Write Accessread/write
LV Status available
LV # 1
# open 1
LV Size30 GB
Current LE 7680
Allocated LE 7680
Stripes 2
Stripe size (KByte) 16
Allocation next free
Read ahead sectors 120
Block device 58:0
--- Physical volumes ---
PV Name (#) /dev/md0 (1)
PV Status available / allocatable
Total PE / Free PE4864 / 1024
PV Name (#) /dev/md1 (2)
PV Status available / allocatable
Total PE / Free PE4864 / 1024
Please CC: me on replies. Thanks.
--
Michael S. Fischer / michael at auctionwatch.com /
http://www.auctionwatch.com
Systems Engineer, AuctionWatch.com Inc. / Phone: +1 650 808 5842
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
memory size detection problem on 2.3.16+ and 2.4.x
Hi, summary: e801 memory size detection call failure, but bios doesnt set carry flag on error and hence get an incorrect memory size. Since the 2.3.16 kernel, my PC has been unable to run any newer kernels (>2.3.16 or 2.4.x) without using the mem=64M command line parameter. This was when the new bigmem support was added which changed the memory detection routines somewhat. I have traced this down to a problem with the way in which the kernel calls the e801 memory size detection bios call. The kernel assumes that the bios will set the carry flag on the return from the call should there be an error. However, the BIOS on my PC doesnt do this- infact it seems to simply return from the call without changing any registers. As a result, my memory size being used is approx 1GB which is derived from the values in the CX and DX registers before the call. My BIOS does not clear them (CX or DX) nor does it set the carry flag. I have included a pretty harmless patch below (taken against 2.4.2) for arch/i386/boot/setup.S which works around this buggy BIOS issue. The patch clears CX and DX before the call to the e801 routine. This should be harmless for any machines which currently work correctly. Please could this patch be included in the next 2.4.x kernel source tree, as I would guess that it is not only me affected by this... Many thanks. Michael Miller --- linux-2.4.2-orig/arch/i386/boot/setup.S Sat Jan 27 18:51:35 2001 +++ linux/arch/i386/boot/setup.SWed Apr 4 00:13:52 2001 @@ -32,6 +32,10 @@ * * Transcribed from Intel (as86) -> AT (gas) by Chris Noe, May 1999. * <[EMAIL PROTECTED]> + * + * Workaround flakey BIOSes for e801 call - which don't use carry flag + * on errors. Michael Miller ([EMAIL PROTECTED]), April 2001 + * */ #define __ASSEMBLY__ @@ -341,6 +345,11 @@ # to write everything into the same place.) meme801: + xorl%edx, %edx # Clear regs to work around + xorl%ecx, %ecx # flakey BIOSes which don't + # use carry bit correctly + # This way we get 0MB ram on + # call failure movw$0xe801, %ax int $0x15 jc mem88 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel v2.4.3 segfault on any network send
Please cc me the messages, i'm not subscribed...
Hey,
I just upgraded to kernel 2.4.3 on a k6 (233 mhz) with the processor
type set accordingly, all the proper drivers compiled in and I get
this big disgusting error message (my friend said that means i f***ed
up) Sorry I don't have it, but I'll try to get it, because i'd have
to write it down... I can't telnet-and-copy/paste for obvious reasons.
If I boot to kernel 2.4.2, it won't do that, so I know that lynx
isn't the problem (and ftp has it too).
Pi
PS:
The SysRq key is a little funky in all kernels since 2.4.0... it
doesn't accept help with the letter H, i have to hit the spacebar,
and the log levels only change with the number pad...
Pi
--
use begin;
begin::signature;
Anthony "3.14159" Martinez
AIM name - LittleManTheGeek
---PERL-SIGNATURE---
#! /usr/bin/perl -w
while () {
my $sig1;
my $sig2;
my $name;
$sig1="What we have here is a failure to deallocate";
$sig2="This file provides programmers with information
proving that it was really a hardware problem";
$name="Anthony \"3.14159 iMacTinez\" Martinez"
}
=pod
ALL YOUR BASE ARE BELONG TO US! ALL YOUR BASE ARE BELONG TO US! ALL
YOUR BASE ARE BELONG TO US! ALL YOUR BASE ARE BELONG TO US! ALL YOUR
BASE ARE BELONG TO US! ALL YOUR BASE ARE BELONG TO US! ALL YOUR BASE
ARE BELONG TO US! ALL YOUR BASE ARE BELONG TO US! ALL YOUR BASE ARE
BELONG TO US! ALL YOUR BASE ARE BELONG TO US! ALL YOUR BASE ARE
BELONG TO US! ALL YOUR BASE ARE BELONG TO US! ALL YOUR BASE ARE
BELONG TO US! ALL YOUR BASE ARE BELONG TO US! ALL YOUR BASE ARE
BELONG TO US! ALL YOUR BASE ARE BELONG TO US! ALL YOUR BASE ARE
BELONG TO US! ALL YOUR BASE ARE BELONG TO US! ALL YOUR BASE ARE
BELONG TO US! ALL YOUR BASE ARE BELONG TO US!
Pi
=cut
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Digital DS21143 in Compaq & kernel 2.4.2
Hi, I tried to install redhat 7.0 on a compaq presario 5685 with onboard networkcard. According to the linux-kernel this card needs drivers for the Digital DS21143 card. But when loaded, this card wouldn't work. So i tried a diverent version of the kernel by trying to install redhat rawhide. The driver complains it cannot found the MII transever. Because I need this networkcard to install to install the distribution from the internet. I would really like to know how to get this working. I hope anyone had this problem before and can provide me with a solution. If more information is required, just let me know. Best Regards, Olaf Woudenberg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: [PATCH] 2.4.3 and SysRq over serial console
On Tue, Apr 03, 2001 at 09:07:44PM +0100, Russell King wrote: > On Sat, Mar 31, 2001 at 04:38:08PM -0700, Tom Rini wrote: > > Hello all. Without the attached patch, SysRq doesn't work over a serial > > console here. Has anyone else seen this problem? > > It is handled at the serial port driver level, not the tty level. You need > to turn on CONFIG_SERIAL_CONSOLE and CONFIG_MAGIC_SYSRQ, and issue a break > followed by the relevent character within 5 seconds on the serial TTY being > used as the kernel console. After talking with the person who originally did the patch, yeah, that does make sense (and the serial driver we're using needs to be fixed). Thanks. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
> Did you compile sysrq into your kernel? I haven't yet. I'll enable it and see if I can trigger it next time I reboot again. > ps -eo pid,stat,pcpu,nwchan,wchan=WIDE-WCHAN-COLUMN -o args 1230 D 0.0 105cc1 down_write_failed /home/data/mozilla/obj/dist/bin/mozilla-bin Hopefully that helps a bit more. -Trev - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about SysRq
You write: > Can you anyhow find something in your logs/console/serial console messages > like 13.13.2000 kernel : Sysrq: Emergency Sync (this should be present - is > written within keyboard handler, not after shedule) and what's next logs ? > We could determine, if the bdflush thread got scheduled and called emergency > syncing routine indeed. It sounds like the kernel is stuck somewhere in a tight loop, so nothing is being rescheduled. If you have an SMP system (or an APIC) you may be able to see where it is stuck with the NMI watchdog timer. > Quick help against those corruptions, which comes on my mind, is use > the reiserfs. I have no real experiences with that and its reliability, > also as aj followed some of messages in this list about resierfs - it has > some problems too - but in definition it shoudn't get corrupted by not- > syncing reboot. Actually, this is not true. Reiserfs will only prevent corruption of the filesystem metadata. It does not guarantee that the file contents are valid if they are being changed when the system crashes. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2048 byte/sector problems with kernel 2.4
On Tue, 3 Apr 2001, Alan Cox wrote: > > I also tried it with 2.2.18 there it works but it seems to be utterly > > slow. I'm using kernel 2.4.2(XFS version to be precise). > > M/O disks are slow. At a minimum make sure you are using a physical block size > of 2048 bytes when using 2048 byte media and plenty of memory to cache stuff > when reading. Seek times on M/O media are pretty poor Another thing making for the snailicity of MO drives is that writing is a two pass operation. It is very like core memory; first you write the spot to a known state, and then you write the data. So you have an average latency of 25 mS. for write operations and 8.33 mS. for read operations. There WERE direct overwrite media for a while that would, in theory, be able to write the data directly, but a combination of high cost, limited sources, and strong questions about the permanence of the recorded data severely limited the demand for these and I think that they have been withdrawn. Harvey Harvey Fishman | [EMAIL PROTECTED] | A little heresy is good for the soul. 718-258-7276| - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 Tue, Apr 03, 2001 at 08:47:52PM +0200, Ingo Molnar wrote: > > this restriction (independence of the priority from the previous process) > is a fundamentally bad property, scheduling is nonlinear and affinity > decisions depend on the previous context. [i had a priority-queue SMP > scheduler running 2-3 years ago but dropped the idea due to this issue.] > IMO it's more important to have a generic and flexible scheduler, and > arbitrary, nonnatural restrictions tend to bite us later on. It seems like we may be talking about two different things. Our 'priority queue' implementation uses almost the same goodness function as the current scheduler. The main difference between our 'priority queue' scheduler and the current scheduler is the structure of the runqueue. We break up the single runqueue into a set of priority based runqueues. The 'goodness' of a task determines what sub-queue a task is placed in. Tasks with higher goodness values are placed in higher priority queues than tasks with lower goodness values. This allows us to limit the scan of runnable tasks to the highest priority sub-queue, as opposed to the entire runquue. When scanning the highest priority sub-queue we use almost the same goodness function as that which is used today (it does take CPU affinity into account). In fact, if we used the same goodness function I'm pretty sure we would exactly match the behavior of the existing scheduler. Hopefully, Hubertus Franke will speak up and provide more details, as he is much more familiar with this implementation than I am. In any case, I think we have almost reached the conclusion that our priority queue implementation may not be acceptable due to the extra overhead in low thread counts. > one issue regarding multiqueues is the ability of interactive processes to > preempt other, lower priority processes on other CPUs. These sort of > things tend to happen while using X. In a system where process priorities > are different, scheduling decisions cannot be localized per-CPU > (unfortunately), and 'the right to run' as such is a global thing. Agreed. This is why our multi-queue scheduler always attempts to make global decisions. It will preempt lower priority tasks on other CPUs. This implementation tends to make 'more localized' scheduling decisions as contention on the runqueue locks increase. However, at this point one could argue that we have moved away from a 'realistic' low task count system load. > lmbench's lat_ctx for example, and other tools in lmbench trigger various > scheduler workloads as well. Thanks, I'll add these to our list. -- 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] 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.3 and SysRq over serial console
On Tue, Apr 03, 2001 at 09:07:44PM +0100, Russell King wrote: > On Sat, Mar 31, 2001 at 04:38:08PM -0700, Tom Rini wrote: > > Hello all. Without the attached patch, SysRq doesn't work over a serial > > console here. Has anyone else seen this problem? > > It is handled at the serial port driver level, not the tty level. You need > to turn on CONFIG_SERIAL_CONSOLE and CONFIG_MAGIC_SYSRQ, and issue a break > followed by the relevent character within 5 seconds on the serial TTY being > used as the kernel console. That wasn't working here however. Unless minicom isn't sending the proper break. Doing the keycombo which slips my mind to send a break, followed by 'h' in minicom does nothing. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Repeatable hang in 2.4.3 with 4 ide drives.
I'm trying to make 3 copies of a 40 gig IBM deskstar IDE drive. I've got red hat 7 booted into single user mode, doing the following: cat /dev/hda | count | tee /dev/hdb | tee /dev/hdc > /dev/hdd The copy seems to work fine if I never let the console blank. I copied 2 gigs worth of data (at about 1.5 megabytes/second) by hitting the shift key every few minutes. It never even paused. It also hasn't been having problems copying just hda to hdb. It's adding hdc and hdd into the mix that triggers the hang. I suspect the two IDE controllers are fighting somehow. Unblanking the screen locks it solid semi-reliably, 3 of the 4 times I've let it do that. (Perhaps console blanking/unblanking causes a latency spike? The console unblanks but the red hard drive writing light goes off instantly and the progress display "count" gives you stops moving. The kernel's still there, num-lock changes the keyboard light, but I can't ctrl-c out of the process.) The one time it continued writing after unblanking it hung again a minute or so later, unblocked itself after thirty seconds or so, and then hung again and stayed that way for five minutes until I turned it off. It was not happy. "count" is a ten-line program I wrote to read data from stdin and write it back to stdout with a progress indicator going to stderr. (fprintf(stderr,"%lld bytes\r",bytecount); In a loop. Woo.)) The chipset is sis 5513. The 4 IBM deskstars are ata66 drive with an ata66 cable but the 2.4.3 unconditionally refuses to allow me to switch on DMA on any of them. (hdparm -d1 /dev/hda goes operation not permitted.) I left it off for this test cause I just want to get it to work at the moment. I have tried it with -c1 and without -c1, it hangs either way. Rob (Yes, I'm copying the mounted drive's block device out from under it. It's a bit impolite to the system, but I've done this lots of times. That's why I boot into single user mode and sync beforehand. Yes, the new drive fscks on the way back up, but since nothing's actually changing the data it's fine. This is a seperate issue, even if I was copying hosed data it still shouldn't be hanging.) Update: back to the ide0 only master-to-slave copy. "cat /dev/hda | count > /dev/hdb". It's done 3 gigs so far with no complaints, and I let it blank and unblank twice now and it didn't even pause. Also, the single controller copy is going significantly faster (about twice as fast) even though the two drives still share the same cable. Are the two ide controllers sharing some kind of lock? (The data SHOULD be able to go in paralell, but it doesn't look like it was... I thought the google guys had a patch for that back at ALS...?) __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SOLVED]Re: 2.2.19 && ppa: total lockup. No problem with 2.2.17
Tim Waugh escribió: > > On Sat, Mar 31, 2001 at 01:59:39AM +0200, Juan Piernas Canovas wrote: > > > Yes!!!. It works. I am happy now :-) > > Unfortunately, the problem isn't solved, merely worked around. We > need to figure out why this is happening in the first place. :-( > > To recap, the system hangs completely when you load the ppa module. Right > > Are you using any special parport/ppa parameters? Is this an SMP or a > uniprocessor machine? Come to that, which architecture is it? > I have the same problem in two different machines but they both are UP. However, my kernel configuration has SMP support enabled. My modules.conf file is: alias scsi_hostadapter ppa alias parport_lowlevel parport_pc options parport_pc io=0x378 irq=7 > Are there any messages displayed to the console when the hang happens? > If you could scatter some printks around (KERN_CRIT so they show up on > the console) to figure out the example point at which it's hanging, > that would be great. I stop klogd and syslogd services (that causes to display all kernel messages on screen, doesn't it? and, when I load the ppa modules, the machine simply hangs: no messages, no sysreq key anymore. Bye! Juan. -- D. Juan Piernas Cánovas Departamento de Ingeniería y Tecnología de Computadores Facultad de Informática. Universidad de Murcia Campus de Espinardo - 30080 Murcia (SPAIN) Tel.: +34968367657Fax: +34968364151 email: [EMAIL PROTECTED] PGP public key: http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.es=index - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about SysRq
Unfortunately, > the only one that responds is sysrq-b, which boots the box without > syncing or unmounting the disks. Not only does that piss me off but it's > led to some fs corruption as well (which pisses me off even more). sysrq-b > is the *only* combination I can get working when this happens. I looked a bit at the source of sysrq handling. I've found there is rather big difference between sysrq+b and other killers handling. Sysrq+b is just called with pretty straitforward fashion - stops other processors on SMP and reboots directly (hardware impulse or triple fault) or through the bios - so it just calls for the corruptions. On the other side sysrq+s marks a single variable, which will be tested next cycle in the bdflush kernel threads' main loop, and adds bdflush to scheduler runqueue list. So it gets possibility to check for emergency sync onle when gets next scheduled. Does it ? Can you anyhow find something in your logs/console/serial console messages like 13.13.2000 kernel : Sysrq: Emergency Sync (this should be present - is written within keyboard handler, not after shedule) and what's next logs ? We could determine, if the bdflush thread got scheduled and called emergency syncing routine indeed. As you wrote no of your processes does respond - probably telnet will not help. You may try to write experimental programme, that only log say current time every n seconds, and see, if it just stopped to log messages after lockup-time. If not - it doesn't get scheduled. If continues - there's problem with syncing. Again - try, as far as i understand, log kernel messages to serial console or alike, because the messages should not get written to logfiles - syslogd can't be woken up eg. Quick help against those corruptions, which comes on my mind, is use the reiserfs. I have no real experiences with that and its reliability, also as aj followed some of messages in this list about resierfs - it has some problems too - but in definition it shoudn't get corrupted by not- syncing reboot. But i see this not much helpfull ,cause if you really would depend on big reliability, you wouldn't intall 2.3.x-pre kernel :) There go also occasionally discussions about watchdogs - it may be helpfull - but none of the two really solve the problem. LW: today a got ugly lockup with dosemu and experimental execution of virtual pool ;). Neither Sysrq+b functioned. But that's probably another story. Root or privilege suid processes (X server among them) need really just a 1-bit error to corrupt near what they like. The least fsck sessions and nice day B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Goodbye
On Tue, 3 Apr 2001 16:56:57 -0500, Matthew Fredrickson <[EMAIL PROTECTED]> wrote: > > I have decided to leave lkml because everybody else is doing it too. I have decided to switch to Windows because everybody else is doing it too. Oh, wait.. wrong mailing list. It's not hosted on aol.com. :-) Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ReiserFS? How reliable is it? Is this the future?
I've had 0, Ziltch problems with ReiserFS at the moment. It's solid for me. On Tue, 3 Apr 2001, Harald Dunkel wrote: > Hi folks, > > If I get the DVD stuff working, then I won't need NT anymore, i.e. > I will have an empty disk. > > What is your impression about ReiserFS? Does it work? Is it stable > enough for my daily work, or is it something to try out and watch > carefully? Do you use ReiserFS for your boot partition? > > Or should I try ext3 instead? > > > Regards > > Harri > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Minor 2.4.3 Adaptec Driver Problems
>Volume labels dont help for all cases. Its a bug in the 6.1.5 adaptec driver >which (to save Justin pointing it out) is fixed in 6.1.8 Actually, there is a component of this related to link order which is fixed in the upcoming 6.1.9 driver release. The 7895, channel B primary issue, is fixed in 6..1.8. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Goodbye
I have decided to leave lkml because everybody else is doing it too. Matthew Fredrickson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2048 byte/sector problems with kernel 2.4
> MO disks which have normal 512 bytes/sector it all works flawlessly but > as soon > as a put in a 1.3GB disk which uses the 2048 bytes/sector format it all > goes > wrong. As soon as I write something to the disk by issuing a cp command It will. Linux 2.4.x still hasn't had the scsi disk block size bugs fixed. Stick to 2.2.19. > I also tried it with 2.2.18 there it works but it seems to be utterly > slow. I'm using kernel 2.4.2(XFS version to be precise). M/O disks are slow. At a minimum make sure you are using a physical block size of 2048 bytes when using 2048 byte media and plenty of memory to cache stuff when reading. Seek times on M/O media are pretty poor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Minor 2.4.3 Adaptec Driver Problems
> > I just got 2.4.3 up a running (on Abit BP6 Dual Celeron ) and > > it reorderd my SCSI id's. Take a look. I don't like that my ZIP drive > > becomes sda because if I ever remove it then I'll @#$% my harddrive dev > > mappings again and have to change them again. Adaptec Driver 6.1.5 > > :-( > > That's what ext2 volume labels are for. Volume labels dont help for all cases. Its a bug in the 6.1.5 adaptec driver which (to save Justin pointing it out) is fixed in 6.1.8 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2048 byte/sector problems with kernel 2.4
Hi, I recently acquired a 1.3GB MO drive. When I use small (230MB and 540MB) MO disks which have normal 512 bytes/sector it all works flawlessly but as soon as a put in a 1.3GB disk which uses the 2048 bytes/sector format it all goes wrong. As soon as I write something to the disk by issuing a cp command the command just eats 99% CPU time and does not write a single byte to disk (it seems). Is this a known problem? When I check the kernel logs it seems that the sector size is correctly identified. The problems occurs with both the ext2 and fat filesystems. I also tried it with 2.2.18 there it works but it seems to be utterly slow. I'm using kernel 2.4.2(XFS version to be precise). Any solution to this problem? Greetings, Jurgen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.3 irq routing conflict (VIA chipset)
I know there was a thread on this previously and I was thinking it had been resolved (or was that only for a specific mobo mfg?). When I finally got my VIA chipset machine up to date with a 2.4.3 kernel I noticed the following on boot up: PCI: Found IRQ 11 for device 00:0a.0 IRQ routing conflict in pirq table for device 00:0a.0 The only device on irq 11 is an agp voodoo3 card. I don't seem to see any negative effects (unless what I believe is an unrelated scsi error is tied to this somehow). Should I just disregard this message and assume it's a mobo quirk? The mobo in question is an AOpen AX59Pro with the current bios. I can run any test code or send futher system info if desired... Tim -- * tpepper@linuxninja dot org * Venimus, Vidimus, * * http://www.linuxninja.org/~tpepper * Dolavimus * - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: Re: [PATCH][RFC] appling preasure to icache and dcache
-- Forwarded Message --
Subject: Re: [PATCH][RFC] appling preasure to icache and dcache
Date: Tue, 3 Apr 2001 17:22:10 -0400
From: Ed Tomlinson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: l
On Tuesday 03 April 2001 11:03, Benjamin Redelings I wrote:
> Hi, I'm glad somebody is working on this! VM-time seems like a pretty
> useful concept.
Think it might be useful for detecting trashing too. If vmtime is made
to directly relate to the page allocation rate then you can do something
like this. Let K be a number intially representing 25% of ram pages.
Because vmtime is directly releated to allocation rates its meanful to
subtract K from the current vmtime. For each swapped out page, record
the current vmtime. Now if the recorded vmtime of the page you are
swapping in is greater than vmtime-K increment A otherwise increment B.
If A>B we are thrashing. We decay A and B via kswapd. We adjust K
depending on the swapping rate. Thoughts?
> I think you have a bug in your patch here:
>
> + if (base > pages) /* If the cache shrunk reset base, The
> cache
> + base = pages;* growing applies preasure as does
> expanding
> + if (free > old) * free space - even if later shrinks */
> + base -= (base>free-old) ? free-old : base;
>
> It looks like you unintentionally commented out two lines of code?
Geez. That will teach me to add comments _after_ testing the code...
The patch as it stands, will not apply pressure as the caches expands.
Good catch. Thanks.
> I have been successfully running your patch. But I think it needs
> benchmarks. At the very least, compile the kernel twice w/o and twice
> w/ your patch and see how it changes the times. I do not think I will
> have time to do it myself anytime soon unfortunately.
> I have a 64Mb RAM machine, and the patch makes the system feel a little
> bit slower when hitting the disk. BUt that is subjective...
Where I see a difference is with backups. With the patch applied they take
about 2:20 or so, and use over 60K inodes/dentries, without the patch they
take 2:35 (plus or minus 5 mins) and use over 190K inodes/dentries. On a box
with lots of memory pressure (ie with 64M) I doubt that the calls to shrink
the caches get triggered often from my code - expect that you are usually
shrinking via do_try_to_free_pages. What might cause your subjective
difference may be the change in:
refill_inactive_scan(DEF_PRIORITY, delta);
You might want to try replacing this delta with 0 (in kswapd). If this
improves things for you I have to do a little rethinking...
Corrected patch follows:
---
diff -u -r --exclude-from=ex.txt linux.ac28/mm/page_alloc.c
linux/mm/page_alloc.c --- linux.ac28/mm/page_alloc.c Sun Apr 1 18:52:22
2001
+++ linux/mm/page_alloc.c Mon Apr 2 07:54:05 2001
@@ -138,11 +138,9 @@
/*
* We don't want to protect this variable from race conditions
-* since it's nothing important, but we do want to make sure
-* it never gets negative.
+* since it's nothing important.
*/
- if (memory_pressure > NR_CPUS)
- memory_pressure--;
+ inactivate_pressure++;
}
#define MARK_USED(index, order, area) \
diff -u -r --exclude-from=ex.txt linux.ac28/mm/swap.c linux/mm/swap.c
--- linux.ac28/mm/swap.cMon Jan 22 16:30:21 2001
+++ linux/mm/swap.c Thu Mar 29 11:37:47 2001
@@ -47,10 +47,12 @@
* many inactive pages we should have.
*
* In reclaim_page and __alloc_pages: memory_pressure++
- * In __free_pages_ok: memory_pressure--
+ * In __free_pages_ok: inactivate_pressure++
+ * In invalidate_pages_scan: inactivate_pressure++
* In recalculate_vm_stats the value is decayed (once a second)
*/
int memory_pressure;
+int inactivate_pressure;
/* We track the number of pages currently being asynchronously swapped
out, so that we don't try to swap TOO many pages out at once */
@@ -287,6 +289,7 @@
* memory_pressure.
*/
memory_pressure -= (memory_pressure >> INACTIVE_SHIFT);
+ inactivate_pressure -= (inactivate_pressure >> INACTIVE_SHIFT);
}
/*
diff -u -r --exclude-from=ex.txt linux.ac28/mm/vmscan.c linux/mm/vmscan.c
--- linux.ac28/mm/vmscan.c Sun Apr 1 18:52:22 2001
+++ linux/mm/vmscan.c Mon Apr 2 07:42:55 2001
@@ -759,6 +791,8 @@
}
spin_unlock(_lru_lock);
+ inactivate_pressure += nr_deactivated;
+
return nr_deactivated;
}
@@ -937,6 +971,76 @@
return ret;
}
+/*
+ * Try to shrink the dcache if either its size or free space
+ * has grown, and it looks like we might get the required pages.
+ * This function would simplify if the caches tracked how
+ * many _pages_ were freeable.
+ */
+int try_shrinking_dcache(int goal, unsigned int gfp_mask)
+{
+
+ /* base - projects the threshold above which we can free pages */
+
+ static int base, free = 0;
+ int pages, old, ret;
+
+
Re: /proc/config idea
J . A . Magallon wrote: > On 04.03 Ben Ford wrote: > >> J . A . Magallon wrote: >> >>> If this has not been done for System.map, that is a much more important >>> info for debug and oops, and the de facto standard is to put it aside >>> kernel with some standadr naming, lets use the same method for config. >>> >> That would be great and all, but can you tell me how to do it when I >> have 3 or 4 different compiles of the same kernel version? >> > > Just like the Alan Cox for 2.4 or Andrea Arcangeli for 2.2. Lets say you > have 2.4.2-ac27. For each of your compiles, set EXTRAVERSION to -ac27-bf1, > -ac27-bf2, etc. Your files will be: > vmlinuz-2.4.2-ac27-bfX > System.map-2.4.2-ac27-bfX > config-2.4.2-ac27-bfX > Many thanks, I didn't know that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Minor 2.4.3 Adaptec Driver Problems
Giuliano Pochini wrote: >> I just got 2.4.3 up a running (on Abit BP6 Dual Celeron ) and >> it reorderd my SCSI id's. Take a look. I don't like that my ZIP drive >> becomes sda because if I ever remove it then I'll @#$% my harddrive dev >> mappings again and have to change them again. Adaptec Driver 6.1.5 >> :-( > > > That's what ext2 volume labels are for. > > > Bye. > If you use ext2 . . . . - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.2,3 nbd problem, works OK in 2.4.2-ac20,28
On Tue, Apr 03, 2001 at 04:16:04PM +0400, Vladimir Serov wrote: > Unfortunately the details of handling these requests aren't clear for me > and it's not simple to use Alan Cox patches on ARM cause there not > supported by Russell King and other people in ARM community (I mean no > patches again -acxx kernels) and i'm already overloaded by various beta > and alpha software. I'll look into the possibility of rooting out the fix in the -ac tree (if any) tomorrow and dropping it into the next ARM tree. _ |_| - ---+---+- | |Russell King [EMAIL PROTECTED] --- --- | | | |http://www.arm.linux.org.uk// / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.3ac1
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org (Note that the cmsfs port to 2.4 is a work in progress) The 2.4.3ac1 release is intended simply as a synchronization point and so I know what bugs if any first appear with the 2.4.3 merge. 2.4.3-ac1 o Merge Linus 2.4.3 final, diff versus 2.4.3 (me) 2.4.2-ac28 o Fix another modules race(me) o Add basic PM hooks to agpgart (me) o Update new xircom_cb driver (Arjan van de Ven) o Fix missing lock_kernel on truncate path(Al Viro) o Update klsi usb ethernet ids(Brad Hards) o Fix missing permission check in shm code(Matthew Klahn) o Add extra doupdate() calls to menuconfig(Moritz Schulte) o Update wireless extensions (Jean Tourrilhes) o Fix cdda reading problem(Jens Axboe) o Fix potential oops in usb-uhci (David Brownell) 2.4.2-ac27 o Rely on BIOS to setup apic bits on OSB4 (me) o Disable events when unloading cardbus yenta (me) | Fixes shared irq unload hang o Fix x86 IPI replay problems (Stephen Tweedie) o Add ALS100 gameport support (Vojtech Pavlik) o Fix wrong path in comment in vesafb (Andres Salomon) o Allow slab caches to force alignment always (Ingo Molnar) and thus fix PAE+ slab poisoning o Fix problems in faulting raw I/O pages (Stephen Tweedie) o Fix rawio error handling for raw I/O(Stephen Tweedie) | + other oddments o Change default max printer ports to 8 (Tim Waugh) o Parport soft control state fixes(Tim Waugh) o Fix cpu info compile(Constantine Gavrilov) o Set warning levels on reiserfs warn etc (Paul Mundt) o Fix duplicate IOVIRT debug config help (Steven Cole) o Revert mmap change that broke assumptions (and (Martin Diehl) it seems SuS) o Clean up fpu emu warnings on gcc 3.0cvs a bit (me) 2.4.2-ac26 o Fix es1370 build bug(me) o Fix sbpcd compile warnings (me) o Update usbnet driver(Oleg Drokin) o Update Alpha to pre8 vm changes (Ivan Kokshaysky) o Fix radeonfb config selections (Chris Lawrence) o Fix vmalloc mismerge(Various) o Fix n_r3964 console panic (Andrew Morton) o Update ibm camera drivers o Support 701b toshoboe fir o New xircom_cb driver(Arjan van de Ven, Jeff Garzik, Don Becker, Doug Ledford) o Fix procfs mount point for binfmt_misc (Al Viro) o Update hpt366 ide blacklist o Further ide blacklist updates o Smooth vm balancing (Marcelo Tosatti) o Fix irda assert (Arjan van de Ven) o Keep contrack cache sizes sane (Ben LaHaise) o Fix possible file truncate/write race (Ben LaHaise) o Make bootmem panic sanely on out of memory (Ben LaHaise) o Fix unload crash in pci_socket (me) o Revert previous wrong bootmem change(Ben LaHaise) 2.4.2-ac25 o Handle PCI/ISA simple MP tables via ELCR(John William) o Fix get_sb_single (Al Viro) o Update es1370, es1371,esssolo (Thomas Sailer, Tjeerd Mulder, Nathanial Daw) o Update orinoco_cs (Jean Tourilhes) o Fix races found in the new kbd/console code (Andrew Morton) o Remove dead timer.h docs(Tim Wright) o Update ppc to new generic mm changes(Paul Mackerras) o Clean up mdacon (Paul Gortmaker) o Remove duplicate configure.help texts (Steven Cole) o Fix symbol export for shm_file_open (Keith Owens) o First batch of pointer reference bug fixes (Andrew Morton) from Stanford report o Fix de4x5 oops on Alpha XP1000 (George France) o Chipsfb update (Paul Mackerras) o Fix higmem block_prepare_write crash(Stephen Tweedie) o Bring PAE36 back up to date, handle x86 errata (Ingo Molnar) o Fix ov511 crash if opened while loading (Pete Zaitcev) o Merge Linus
Re: [PATCH] 2.4.3 and SysRq over serial console
On Sat, Mar 31, 2001 at 04:38:08PM -0700, Tom Rini wrote: > Hello all. Without the attached patch, SysRq doesn't work over a serial > console here. Has anyone else seen this problem? It is handled at the serial port driver level, not the tty level. You need to turn on CONFIG_SERIAL_CONSOLE and CONFIG_MAGIC_SYSRQ, and issue a break followed by the relevent character within 5 seconds on the serial TTY being used as the kernel console. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] smbfs: caching problems
On Sun, 1 Apr 2001, Xuan Baldauf wrote: > Hello, > > there is something wrong with smbfs caching which makes my > applications fail. The behaviour happens with > linux-2.4.3-pre4 and linux-2.4.3-final. Any version you know it doesn't happen with? (including 2.2 versions) > Consider following shell script: (where /mnt/n is a > smbmounted smb share from a Win98SE box) Reproducible, but so far only with win98 (SE?). NT4, samba are testing ok with the sizes I have tried, not sure what that means. Thanks a lot for providing a testcase. I have started looking but right now a lot of non-linux things are calling for attention. If it isn't trivial I may need some time to get around to it. (insanely early morning flights to Stockholm and late evening return flights, work, easter holiday preparations, local community stuff ... and that was just today. Sorry, I'm tired and felt like complaining to someone. Pay no attention to me :) You may want to consider looking into it yourself, if you need it fixed quickly. 'tail -f' has previously been depending on smb_revalidate_inode to update inode information properly (I suspect that one right now, will check tomorrow. Possibly that smb open/close changes modification times ... and/or some win95 bug workaround is causing this?) Enabling verbose debug (select parts perhaps) can be useful. Adding debug printouts on inode mtime+size. /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS client code slow in 2.4.3
> " " == Caleb Epstein <[EMAIL PROTECTED]> writes: > On Tue, Apr 03, 2001 at 02:56:15PM -0400, Caleb Epstein wrote: >> I am having problems with timeouts and generaly throughput in >> the 2.4.3 NFS client side code which are not present in the >> 2.4.2 kernel running in the same configuraiton on the same >> hardware. The machines are on a 100 Mbit switched local >> network with essentially no other trafic. > On second thought, it looks like 2.4.2 may also exhibit the > same behaviro after a little while. Now that the machine has > been up for a half hour or so, NFS traffic has become slow on > my 2.4.2 client again. I am seeing messages like this in my > kernel log: > Apr 3 15:01:54 hagrid kernel: nfs: server tela not responding, > still trying Apr 3 15:01:54 hagrid kernel: nfs: server tela OK The above is a generic message that simply is stating that NFS traffic is congested because the server isn't responding for whatever reason. In 99% of all cases, this means that the server is not seeing all the packets that the client is sending it. This forces the client to throttle back the number of requests it can have on the fly, and then to wait until the given packet times out, and then to resend. Try checking whether or not the server is seeing all the packets that the client is sending by comparing the output of tcpdump/ethereal between the client and the server. If the packet loss is large, try fiddling with the hardware: typically stuff such as overriding the NIC autoconfiguration, swapping the NIC, checking for noisy cables,... If you're unable to trace the problem, try playing around with rsize/wsize, timeo and retrans (man 5 nfs). The smaller the packet, the less the chances are of UDP fragments getting lost. You might also want to try out the NFS ping patch from http://www.fys.uio.no/~trondmy/src/2.4.2 Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 Tue, 3 Apr 2001, Mike Kravetz wrote: > [...] Currently, in this implementation we only deviate from the > current scheduler in a small number of cases where tasks get a boost > due to having the same memory map. thread-thread-affinity pretty much makes it impossible to use a priority queue. This 'small number of cases' is actually a fundamental issue: can the 'goodness()' function be an arbitrary function of: goodness(process_prev,process_next) := f(process_prev,process_next) , or is the queue design restricting the choice of goodness() functions? Priority queues for example restrict the choice of the goodness() function to subset of functions: goodness(process_prev,process_next) := f(process_next); this restriction (independence of the priority from the previous process) is a fundamentally bad property, scheduling is nonlinear and affinity decisions depend on the previous context. [i had a priority-queue SMP scheduler running 2-3 years ago but dropped the idea due to this issue.] IMO it's more important to have a generic and flexible scheduler, and arbitrary, nonnatural restrictions tend to bite us later on. one issue regarding multiqueues is the ability of interactive processes to preempt other, lower priority processes on other CPUs. These sort of things tend to happen while using X. In a system where process priorities are different, scheduling decisions cannot be localized per-CPU (unfortunately), and 'the right to run' as such is a global thing. > Can someone tell me what a good workload/benchmark would be to examine > 'low thread count' performance? [...] lmbench's lat_ctx for example, and other tools in lmbench trigger various scheduler workloads as well. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MLPPP in kernels 2.2.x w/ PPP v2.4.1
Oops, I forgot to add the most important part from README.linux: ... The 2.2 series kernels contain an older version of the kernel PPP driver, one which doesn't support multilink. If you want multilink, you need to run the latest 2.4 series kernel. The kernel PPP driver was completely rewritten for the 2.4 series kernels to support multilink and to allow it to operate over diverse kinds of communication medium (the 2.2 driver only operates over serial ports and devices which look like serial ports, such as pseudo-ttys). ... Koral Koral Ilgun wrote: > > These are excerpts from ppp 2.4.1 README.linux file: > > ... > > The Linux PPP implementation includes both kernel and user-level > parts. This package contains the user-level part, which consists of > the PPP daemon (pppd) and associated utilities. In the past this > package has contained updated kernel drivers. This is no longer > necessary, as the current 2.2 and 2.4 kernel sources contain > up-to-date drivers. > > ... > > 2.1 Kernel driver > > Assuming you are running a recent 2.2 or 2.4 (or later) series kernel, > the kernel source code will contain an up-to-date kernel PPP driver. > If the PPP driver was included in your kernel configuration when your > kernel was built, then you only need to install the user-level > programs. Otherwise you will need to get the source tree for your > kernel version, configure it with PPP included, and recompile. Most > Linux distribution vendors ship kernels with PPP included in the > configuration. > > ... > > Hope this helps, > > Koral > > Ivan Passos wrote: > > > > Hello, everyone, > > > > The quick question: if I install PPP 2.4.1 in a Linux box w/ kernel 2.2.x, > > will I have support to MLPPP?? > > > > Now, the explanation for my doubt. I've seen several (actually 3) > > different MLPPP implementations for older versions of PPP/pppd (namely > > 2.3.5 and 2.3.11). I'd like to know if once I install PPP 2.4.1 in a > > system w/ kernel 2.2.x, I kill my need for these kind of patches in order > > to support MLPPP. Or would I still need some kind of patch, even for PPP > > 2.4.1, to have MLPPP support in kernels 2.2.x?? > > > > I know that for kernels 2.4.x these patches are not needed. > > > > Thanks in advance for your help! > > > > Later, > > Ivan > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-ppp" in > > the body of a message to [EMAIL PROTECTED] > > -- > Koral Ilgun > Software Engineer > Occam Networks, Inc. -- Koral Ilgun Software Engineer Occam Networks, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: configuring net interfaces
Francois Romieu <[EMAIL PROTECTED]> writes:
> > I think we should separate two things there:
> > - the place (files) where SIOCxxx values are defined
> > - the way we use ioctl call.
>
> (1) and (2) may be related:
> no sub-ioctl (2) + scattered files (1) = *ouch*
Sure.
> Variant:
> struct sub_req sub;
>
> sub.fr_protocol.t391 = 20;
> sub.fr_protocol.n293 = 5;
> sub.sub_ioctl = SIOC_SET_FR_PROTO_PARAMETERS;
> ifreq.name = "qwe0";
> ifreq.data =
> ioctl(s, SIOC_FR_PROTO, );
Yes, it's a little nicer than my second variant. But it's still more
complicated than the first one and I'm not sure if doing that is worth it
> struc sub_req {
> int sub_ioctl;
... as we lose 4 bytes here (currently the union of structs in ifreq
is limited to 16 bytes)
> union {
> struct fr_protocol fr_prot;
> ...
> struct xx_protocol xx_prot;
> }
> }
What might be actually better than my first variant, is a variable-length
data:
struct ifreq {
char name[16];
union {
...
struct {
int sub_command;
int data_length;
void *data;
}
}ifru;
}
... while "data" would be fr_protocol, eth_physical etc.
It's (of course) more complicated, but there is a gain:
- we can have different size requests (from 0 bytes to, say, 100KB)
- we split SIOC namespace into domains
- the core ioctl handler can still "verify" data area for the underlying
driver
--
Krzysztof Halasa
Network Administrator
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: MLPPP in kernels 2.2.x w/ PPP v2.4.1
These are excerpts from ppp 2.4.1 README.linux file: ... The Linux PPP implementation includes both kernel and user-level parts. This package contains the user-level part, which consists of the PPP daemon (pppd) and associated utilities. In the past this package has contained updated kernel drivers. This is no longer necessary, as the current 2.2 and 2.4 kernel sources contain up-to-date drivers. ... 2.1 Kernel driver Assuming you are running a recent 2.2 or 2.4 (or later) series kernel, the kernel source code will contain an up-to-date kernel PPP driver. If the PPP driver was included in your kernel configuration when your kernel was built, then you only need to install the user-level programs. Otherwise you will need to get the source tree for your kernel version, configure it with PPP included, and recompile. Most Linux distribution vendors ship kernels with PPP included in the configuration. ... Hope this helps, Koral Ivan Passos wrote: > > Hello, everyone, > > The quick question: if I install PPP 2.4.1 in a Linux box w/ kernel 2.2.x, > will I have support to MLPPP?? > > Now, the explanation for my doubt. I've seen several (actually 3) > different MLPPP implementations for older versions of PPP/pppd (namely > 2.3.5 and 2.3.11). I'd like to know if once I install PPP 2.4.1 in a > system w/ kernel 2.2.x, I kill my need for these kind of patches in order > to support MLPPP. Or would I still need some kind of patch, even for PPP > 2.4.1, to have MLPPP support in kernels 2.2.x?? > > I know that for kernels 2.4.x these patches are not needed. > > Thanks in advance for your help! > > Later, > Ivan > > - > To unsubscribe from this list: send the line "unsubscribe linux-ppp" in > the body of a message to [EMAIL PROTECTED] -- Koral Ilgun Software Engineer Occam Networks, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/config idea
On Tue, Apr 03, 2001 at 09:12:18PM +0200, J . A . Magallon wrote: > Just like the Alan Cox for 2.4 or Andrea Arcangeli for 2.2. Lets say you > have 2.4.2-ac27. For each of your compiles, set EXTRAVERSION to -ac27-bf1, > -ac27-bf2, etc. Your files will be: Some patches, such as the RAID patches, sets up EXTRAVERSION to a specific value. I do with the make file also had a USERVERSION that would be hands off for anyone but the builder. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Promise 20267 "working" but no UDMA
On Tue, 3 Apr 2001, Ruth Ivimey-Cook wrote: > At 04:57 PM 4/3/01, you wrote: > >I have no choice since the motherboard has the chip on-board and with > >FastTrack BIOS. > > Ahh. I understand. > > I didn't know these MBs had the FastTrak BIOS built in; I was assuming you > were using the PCI card. There are projects on the net which have modified Asus A7V BIOS so that 20265 works with FastTrack BIOS (it's same chip as 20267). Maybe that could be done in reverse. For example check http://www.tweakhardware.com/guide/a7v-raid/ Juhani -- Juhani Rautiainen [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a quest for a better scheduler
On Tue, Apr 03, 2001 at 10:55:12AM +0200, Ingo Molnar wrote: > > you can easily make the scheduler fast in the many-processes case by > sacrificing functionality in the much more realistic, few-processes case. > None of the patch i've seen so far maintained the current scheduler's > few-processes logic. But i invite you to improve the current scheduler's > many-processes behavior, without hurting its behavior in the few-processes > case. > Maintaining the current scheduler's logic is exactly what we are trying to do in the projects at: http://lse.sourceforge.net/scheduling/ A common design goal for the the two alternative scheduler implementations at this site is to maintain the current scheduler's behavior/scheduling decisions. In the case of the priority queue scheduler, we have actually used a copy of the existing scheduler running in parallel (in the same kernel) to determine if we are making the same scheduling decisions. Currently, in this implementation we only deviate from the current scheduler in a small number of cases where tasks get a boost due to having the same memory map. The multi-queue implementation is more interesting. It is also designed to maintain the behavior of the current scheduler. However, as the runqueues get longer (and we start getting contention on the runqueue locks) it starts to deviate from existing scheduler behavior and make more local scheduling decisions. Ideally, this implementation will exhibit the behavior of the current scheduler at low thread counts and make more localized decisions as pressure on the scheduler is increased. Neither of these implementations are at a point where I would advocate their adoption; yet. Can someone tell me what a good workload/benchmark would be to examine 'low thread count' performance? In the past people have used the 'spinning on sched_yield' benchmark. However, this now makes little sense with the sched_yield optimizations introduced in 2.4. In addition, such a benchmark mostly ignores the 'reschedule_idle' component of the scheduler. We have developed a 'token passing' benchmark which attempts to address these issues (called reflex at the above site). However, I would really like to get a pointer to a community acceptable workload/benchmark for these low thread cases. -- 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/config idea
> That would be great and all, but can you tell me how to do it when I > have 3 or 4 different compiles of the same kernel version? Each compile you do already gets assigned a version #, if thats not enough then add your own id string - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/config idea
On 04.03 Ben Ford wrote: > J . A . Magallon wrote: > > > > If this has not been done for System.map, that is a much more important > > info for debug and oops, and the de facto standard is to put it aside > > kernel with some standadr naming, lets use the same method for config. > > > That would be great and all, but can you tell me how to do it when I > have 3 or 4 different compiles of the same kernel version? > Just like the Alan Cox for 2.4 or Andrea Arcangeli for 2.2. Lets say you have 2.4.2-ac27. For each of your compiles, set EXTRAVERSION to -ac27-bf1, -ac27-bf2, etc. Your files will be: vmlinuz-2.4.2-ac27-bfX System.map-2.4.2-ac27-bfX config-2.4.2-ac27-bfX -- J.A. Magallon # Let the source mailto:[EMAIL PROTECTED] # be with you, Luke... Linux werewolf 2.4.3 #2 SMP Fri Mar 30 15:42:05 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS client code slow in 2.4.3
On Tue, Apr 03, 2001 at 02:56:15PM -0400, Caleb Epstein wrote: > I am having problems with timeouts and generaly throughput in > the 2.4.3 NFS client side code which are not present in the 2.4.2 > kernel running in the same configuraiton on the same hardware. The > machines are on a 100 Mbit switched local network with essentially > no other trafic. On second thought, it looks like 2.4.2 may also exhibit the same behaviro after a little while. Now that the machine has been up for a half hour or so, NFS traffic has become slow on my 2.4.2 client again. I am seeing messages like this in my kernel log: Apr 3 15:01:54 hagrid kernel: nfs: server tela not responding, still trying Apr 3 15:01:54 hagrid kernel: nfs: server tela OK The machines are *not* having any connectivity problems, at least judging from TCP sessions I have open between them. So it would seem that NFS performace degrades over a very short window in 2.4.2+. It seems to fairly fly when the machine is freshly booted, but after 30 minutes or less, the performance is severely degraded. Is anyone using 2.4.2+ as a NFS server/client with success? Am I missing something? -- cae at bklyn dot org | Caleb Epstein | bklyn . org | Brooklyn Dust Bunny Mfg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Contacts within AMD? AMD-756 USB host-controller blacklisted due to
> David Brownell recently added this check to the usb-ohci driver > since noone has gotten information from AMD for the workaround, > which is rumored to exist, for this bug. > > Do any of you have contacts within AMD who might be able to > get an explanation of the workaround to David Brownell? We are working on that currently via the Red Hat contact. > value given varies. Rereading NDP seems to give a valid value. > I am not really clear why we don't simply read the value twice > whenever the host-controller is detected to be an AMD-756. because we dont know the full scope of the problem yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NFS client code slow in 2.4.3
I am having problems with timeouts and generaly throughput in the 2.4.3 NFS client side code which are not present in the 2.4.2 kernel running in the same configuraiton on the same hardware. The machines are on a 100 Mbit switched local network with essentially no other trafic. In both cases, testing against a 2.4.3 NFS server (using knfsd). My tests involved using "dd" to read a large file on an NFS mounted directory and running the "connectathon" NFS test suite. When I boot my client machine with 2.4.3, reading a 327 Mbyte file over NFS takes on the order of 5-6 minutes to complete. If I run the same command witrh the client running kernel 2.4.2, the command completes in about 1 minute. Running the "cthon01" test suite, the 2.4.3 client machine basically hangs in the "read + write" test section and I didn't bother waiting for it to finish. Again, when switching back to 2.4.2, the client runs through the tests quite quickly. From my tests I'm pretty convinced that something in either the NFS client code or the networking layer has changed which has drastically reduced NFS client speeds in 2.4.3. Is this a known problem? Can I provide any additional information to help debug it? -- cae at bklyn dot org | Caleb Epstein | bklyn . org | Brooklyn Dust Bunny Mfg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/config idea
J . A . Magallon wrote: > On 04.03 David Lang wrote: > >> if the distro/sysadmin _always_ installs the kernel the 'right way' then >> the difference isn't nessasarily that large, but if you want reliability >> on any system it may be worth loosing a page or so of memory (hasn't >> someone said that the data can be compressed to <1K?) make it so that you >> need a common external tool to use the data and deliver it from the kernel >> in compressed form and you don't even need to put the decompression >> routine in the kernel (cat /proc/sys/kernel/config |gunzip >config) >> > > Just my 2 cents... > > If this has not been done for System.map, that is a much more important > info for debug and oops, and the de facto standard is to put it aside > kernel with some standadr naming, lets use the same method for config. > That would be great and all, but can you tell me how to do it when I have 3 or 4 different compiles of the same kernel version? -b - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
On Wed, 28 Mar 2001, Paul Cassella wrote:
> Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
I've been running -ac27 for over 5 days, and it's been fine, so this seems
to have been fixed.
--
Paul Cassella
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Contacts within AMD? AMD-756 USB host-controller blacklisted due to erratum #4.
Running 2.4.2-ac28, I get the following error: usb-ohci.c: 00:07.4 (Advanced Micro Devices [AMD] AMD-756 [Viper] USB): blacklisted, erratum #4 David Brownell recently added this check to the usb-ohci driver since noone has gotten information from AMD for the workaround, which is rumored to exist, for this bug. Do any of you have contacts within AMD who might be able to get an explanation of the workaround to David Brownell? The bug is that the NDP value sent by the AMD-756 is sometimes bogus. The following examples, collected before the chip was blacklisted, show the failure. As you can see, the bogus value given varies. Rereading NDP seems to give a valid value. I am not really clear why we don't simply read the value twice whenever the host-controller is detected to be an AMD-756. Mar 4 17:20:52 aerie kernel: usb-ohci.c: bogus NDP=128 for OHCI usb-00:07.4 Mar 4 17:20:52 aerie kernel: usb-ohci.c: rereads as NDP=4 Mar 4 17:50:29 aerie kernel: usb-ohci.c: bogus NDP=245 for OHCI usb-00:07.4 Mar 4 17:50:29 aerie kernel: usb-ohci.c: rereads as NDP=4 Mar 6 21:11:07 aerie kernel: usb-ohci.c: bogus NDP=210 for OHCI usb-00:07.4 Mar 6 21:11:07 aerie kernel: usb-ohci.c: rereads as NDP=4 Thanks, Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ReiserFS? How reliable is it? Is this the future?
I use reiserfs on a) P3(450) machine 440BX/ZX Chipset 82371AB PIIX4 IDE UDMA33 b) athlon(1100) VIA KT133 something IDE UDMA33 On both of them i have spurious small file garbage problems during compiling. There was no situation with real trouble, no permanent damage, restarting the job solved the problem all the time. I could not find a real corrupt file on disk. It seems to me like the corruption happens in memory only. (just an impression) The machine with less memory triggers it more likely. On 2.4.3-pre6 a file that has not been changed for months was sometimes not found. I have no problems on the ext2 partitions. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcnet32 (maybe more) hosed in 2.4.3
Carsten,
seems your pcnet32 changes which made it into 2.4.3 are causing trouble
on i386 machines. Can you try to solve that problem?
On Sat, Mar 31, 2001 at 03:58:11PM +0200, Szabolcs Szakacsits wrote:
> On Fri, 30 Mar 2001, Scott G. Miller wrote:
>
> > Linux 2.4.3, Debian Woody. 2.4.2 works without problems. However, in
> > 2.4.3, pcnet32 loads, gives an error message:
>
> 2.4.3 (and -ac's) are also broken as guest in VMWware due to the pcnet32
> changes [doing 32 bit IO on 16 bit regs on the 79C970A controller].
> Reverting this part of patch-2.4.3 below made things work again.
>
> Szaka
>
> @@ -528,11 +535,13 @@
> pcnet32_dwio_reset(ioaddr);
> pcnet32_wio_reset(ioaddr);
>
> -if (pcnet32_wio_read_csr (ioaddr, 0) == 4 && pcnet32_wio_check (ioaddr)) {
> - a = _wio;
> +/* Important to do the check for dwio mode first. */
> +if (pcnet32_dwio_read_csr(ioaddr, 0) == 4 && pcnet32_dwio_check(ioaddr)) {
> +a = _dwio;
> } else {
> - if (pcnet32_dwio_read_csr (ioaddr, 0) == 4 && pcnet32_dwio_check(ioaddr)) {
> - a = _dwio;
> +if (pcnet32_wio_read_csr(ioaddr, 0) == 4 &&
> + pcnet32_wio_check(ioaddr)) {
> + a = _wio;
> } else
> return -ENODEV;
> }
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
gigabit bonding
hi - I have 2 dell power edge 6300 boxes, each with 4 processors and 2 intel 717037 ethernet cards running rh 6.2, kernel 2.2.14-6.1.1smp. I have installed the latest intel nic driver that I could find - v3.0.7. The machines are identical except for the scsi controllers. On one machine, I could bond the cards to one ip and all was well - on the other, the cards worked if brought up singly, but bonding never set the mac of the 2nd card to that of the 1st, although ifenslave doesn't report errors. I can change the mac with ifconfig and the card(s) work fine. I tried swapping the 2 pairs of cards from one machine to the other - now neither pair will bond, although all 4 still work singly. Any guesses as to where I can go next? john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: uninteruptable sleep
Trevor Nichols wrote: > > Its a kernel bug if it gets stuck like this. You need to provide more info > > though - what file system, what devices, how much memory. Also ps can give you > > the wait address of a process stuck in 'D' state which is valuable for debug > > ps xl: > F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTYTIME COMMAND > 040 1000 1230 1 9 0 243204 down_w D? 0:00 >/home/data/mozilla/obj/dist/bin/mozi > > [I'm not exactly sure how to get the wait address if it isn't shown above] > Try this: ps -eo pid,stat,pcpu,nwchan,wchan=WIDE-WCHAN-COLUMN -o args cu Jup - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
MLPPP in kernels 2.2.x w/ PPP v2.4.1
Hello, everyone, The quick question: if I install PPP 2.4.1 in a Linux box w/ kernel 2.2.x, will I have support to MLPPP?? Now, the explanation for my doubt. I've seen several (actually 3) different MLPPP implementations for older versions of PPP/pppd (namely 2.3.5 and 2.3.11). I'd like to know if once I install PPP 2.4.1 in a system w/ kernel 2.2.x, I kill my need for these kind of patches in order to support MLPPP. Or would I still need some kind of patch, even for PPP 2.4.1, to have MLPPP support in kernels 2.2.x?? I know that for kernels 2.4.x these patches are not needed. Thanks in advance for your help! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The 53c400a
> a) my 53c400 card must be initialized first by DOS driver to be detected by Linux >kernel Ok I've not needed that for mine. Must be a variant init function is used on yours. > b) The scanner initialization lasts about 4 minutes. And scanning is very slow > even if I increase the kernel buffer to the max. as described in the SANE doc. That sounds like a bug - takes about 9 seconds for me > c) Using an adaptec SCSI adapter works just fine: scanner initializes > immediately, card is recognized even without DOS and the scanning is much > faster. Yes - I keep meaning to move mine to a real scsi controller - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The 53c400a
On Mon, Apr 02, 2001 at 10:15:28PM +0100, Alan Cox wrote: > Not in the near future. Never mind. I realized three things: a) my 53c400 card must be initialized first by DOS driver to be detected by Linux kernel b) The scanner initialization lasts about 4 minutes. And scanning is very slow even if I increase the kernel buffer to the max. as described in the SANE doc. c) Using an adaptec SCSI adapter works just fine: scanner initializes immediately, card is recognized even without DOS and the scanning is much faster. -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.3 SMP: nfs stale handle, fb dualhead hardlock, G400/450 misnaming
Elmer Joandi wrote: > 2. Hard lockup: > G450, I set con2fb, switch consoles some times and there it comes. > swithc between X and single console is OK. Did you boot with 'video=scrollback:0' ? You must ;-) > 3. seems that I have G450 and linux shows it as G400. > bash-2.04$ /sbin/lspci: > 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev >82) > /proc/pci: > VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 130). rev < 128 => G400, rev >= 128 => G450. Ask Matrox why they did so stupid thing. > G400 drivers also work, but matroxset aint switching second head > to monitor output, neither does anything else. It remains blank. Secondary output on G400 is in monitor mode by default. Are you sure that you insmodded all needed modules to kernel? i2c-matrox, matroxfb_maven, matroxfb_crtc2, ... If you do not know which ones, just build everything into kernel - and do not forget about i2c bit-banging as documented in documentation... Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: [lkml]Re: [lkml]Re: Matrox G400 Dualhead
James Simmons wrote: > >A very neat trick. X can now be ended correctly. Unfortunately, any > >scrolling on any VT afterwards gives me a corrupted screen - parts of > >the screen from other VT's are inserted below, or over the cursor > >position, and at 'half-line' intervals. In typing this email, I've seen > >it 5 times already. > >I'm willing to test anything - but the corruption is alway gone after I > >switch VT's. So getting a screendump is not easy. > > I never have seen this problem before. Petr do you know what it could be? If you are still running X with enabled DRI, then it is known problem. When DRI is enabled in X, mga driver randomly reprograms some Matrox acceleration registers (color depth, screen width, byte ordering) - so you must use same depth and resolution in both X and on console if you are using DRI. I believe that it is problem which thunder7 sees. I never got reported that matroxfb just decided itself in the middle of screen to do something else, it was always tracked to X running on (invisible) background, but still playing with accelerator. Petr P.S.: You can try 'fbset -accel false', but fixing X is better. Unfortunately, nobody cares... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: what is pci=biosirq
xcp wrote: > Here is the output of lspci -vx -s 0:f.0 > > 00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c1) > (prog-if 8a [Master SecP PriP]) > Flags: bus master, medium devsel, latency 32 > I/O ports at b000 [size=16] > 00: b9 10 29 52 05 00 80 02 c1 8a 01 01 00 20 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 01 b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 02 04 > > I'm not sure what to make of it. At this time I am unable to > append="pci=biosirq" as I don't use lilo. Is there a way to put this > arguement directly into the kernel image? You probably can modify pci code to do that, but there is no reason for you to do it. Just ignore that message - your M5229 IDE reports that it needs some interrupt allocated to INTA. Fortunately IDE driver decided that it should use IRQ 14 & 15 for this interface. So as long as it works, do not pay any attention to biosirq message. Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sandisk flashcard reader on 2.4.2. It works. Sort of.
On Tue, Apr 03, 2001 at 02:08:13AM +0200, Stefan Linnemann wrote: > the necessary features. I copied .config from the 2.2.17, superficially > checked the config, and remade and rebooted. > > This was where I noted, that the parport, paride, epat and pd modules didn't > get installed as modules at all. I havnet dug into the why of that, let > those familiar with the processes and Makefiles do that. It'll be because of the block device directory reorganisation I expect, or something similar. Double-check your config. > So I reconfigured to get those into the kernel, and remade and > rebooted. No dice, so I succesfully again applied the same patch, > configured it into the kernel and remade and rebooted. No > SanDisk. For some reason or another I rebooted again, and lo and > behold, we have a SanDisk. So the kernel you run which can see the SanDisk is with, or without, the C7/8 patch? > I mount it ok, cd > /sandisk/dir/, mv * elsewhere, my system hangs. Reset. Enable magic-sysrq and see if Alt-SysRq-B reboots the machine or not. Or, even better, jot down what Alt-SysRq-T says. > So the message is: Yes, it could work, but with the patch from > http://www.electricgod.net/~moomonk/epat/ it's slightly better working than > without it. This patch is in the queue, but behind the bug-fixes. You might want to try fiddling with the BIOS options for the parallel port and see if that makes any difference. Tim. */ PGP signature
Re: Strange problems with 2.4.3.
German Gomez Garcia wrote: > > ... > eth1: transmit timed out, tx_status 82 status e605. > diagnostics: net 04d8 media 8880 dma 00ba. > eth1: Interrupt posted but not delivered IRQ blocked by another device? If this happens immediately after startup then possibly the PCI initialisation has got itself broken. If it happens after some time of correct operation then it's just the usual APIC bug. Add the `noapic' option to your LILO boot command line or use a -ac kernel. Which is it? > > And finally after some time up the system just hangs up, the time > is between 5 and 12 hours. No console activity, no SysRQ, nothing on the > logs, just hanged up. Dunno about this. It may be related, maybe not. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EATA driver with DPT SmartRAID V
On Wednesday 04 April 2001 00:10, Alan Cox wrote: > > Is there any other way to make it working under 2.4.x? Only working > > drivers are up to 2.2.16. I tried to compile them for 2.2.17 from RH 6.2 > > updates, but they hang up PC. > > DPT (now Adaptec) posted beta drivers for the card. I've asked them to make > a few more changes for me but their change making cycle seems very slow and > I'm waiting for the next round. Is it possible to get this beta somewhere? I'd like to try it. -- Sincerely Yours, Denis Perchine -- E-Mail: [EMAIL PROTECTED] HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI: S1 working for someone?
Hi! (beware: I wrongly used vger.rutgers.edu in to, so some care is required to reply to previous message) > Hi! > > Does S1 going back from S1 work for you? As soon as hit power button > in S1, machine powers off... It should just continue where it > started. 2.4.3 on toshiba satelite 4030cdt. > Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EATA driver with DPT SmartRAID V
> Is there any other way to make it working under 2.4.x? Only working drivers > are up to 2.2.16. I tried to compile them for 2.2.17 from RH 6.2 updates, but > they hang up PC. DPT (now Adaptec) posted beta drivers for the card. I've asked them to make a few more changes for me but their change making cycle seems very slow and I'm waiting for the next round. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 database braindump from the kernel summit
Oliver Xymoron wrote: > > On Mon, 2 Apr 2001, Tom Leete wrote: > > > Oliver Xymoron wrote: > > > > > > On Sun, 1 Apr 2001, Jeff Garzik wrote: > > > > > > > On Sun, 1 Apr 2001, David Lang wrote: > > > > > if we want to get the .config as part of the report then we need to make > > > > > it part of the kernel in some standard way (the old /proc/config flamewar) > > > > > it's difficult enough sometimes for the sysadmin of a box to know what > > > > > kernel is running on it, let alone a bug reporting script. > > > > > > > > Let's hope it's not a flamewar, but here goes :) > > > > > > > > We -need- .config, but /proc/config seems like pure bloat. > > > > > > As a former proponent of /proc/config (I wrote one of the much-debated > > > patches), I tend to agree. Debian's make-kpkg does the right thing, namely > > > treating .config the same way it treats System-map, putting it in the > > > package and eventually installing it in /boot/config-x.y.z. If Redhat's > > > kernel-install script did the same it would rapidly become a non-issue. > > > > How about /lib/modules/$(uname -r)/build/.config ? It's already there. > > It'd be great if we got away from the config being hidden too. How about adding a config tag that gets spit out along an OOPS message. We could add a flag to ksymoops that would cause that flag to be read and the corresponding .config info to get looked up (mechanism to be determined). This might reduce the chances of "new kernel tester" reporting an OOPS but sending in the wrong .config data. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
Alan Cox writes: > > However, a large number of people run devfs on small to large systems, > > and these "races" aren't causing problems. People tell me it's quite > > They dont have users actively trying to exploit them. I don't > consider it a big problem for development trees though. devfs has a > maintainer at least Agreed. If I were a sysadmin where I had users I didn't trust, then I'd be worried. Actually, I'd simply not enable module autoloading. In fact, I don't run autoloading because I don't like it personally. And I'm lucky that I have users on my network that I feel I can trust. Besides, I know where they live, or at least where they store their data/theses :-) Regards, Richard Permanent: [EMAIL PROTECTED] Current: [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/
How to make ramdisk based system?
Please forgive me that this is not exactly a kernel question. I'm trying to figure out how to make a primaryly ram-disk based Linux system (which should then be able to access "real" storage, but that is really the last step). Could some kind soul please point me to a HOWTO or cookbook how to build such a system (there are boot/root floppy systems around, but I cannot figure out how to create them or something similar, and "live filesystem" CDs seem to be no longer en vogue)? Many thanks, Steffen -- Steffen Grunewald | GFZ | PB 2.2 | Telegrafenberg E3 | D-14473 Potsdam » email: steffen(at)gfz-potsdam.de | fax/fon: +49-331-288-1266/-1245 « Warning: .signature not found! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EATA driver with DPT SmartRAID V
On Tuesday 03 April 2001 23:59, Alan Cox wrote: > > Bus 1, device 1, function 0: > > PCI bridge: Distributed Processing Technology PCI Bridge (rev 2). > > Master Capable. Latency=64. Min Gnt=3. > > Bus 1, device 1, function 1: > > I2O: Distributed Processing Technology SmartRAID V Controller (rev > > 2). > > This card isnt supported by the eata driver. Is there any other way to make it working under 2.4.x? Only working drivers are up to 2.2.16. I tried to compile them for 2.2.17 from RH 6.2 updates, but they hang up PC. -- Sincerely Yours, Denis Perchine -- E-Mail: [EMAIL PROTECTED] HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
Alexander Viro writes: > > > On Tue, 3 Apr 2001, Richard Gooch wrote: > > > However, a large number of people run devfs on small to large systems, > > and these "races" aren't causing problems. People tell me it's quite > > stable. I run devfs on my systems, and not once have I had a problem > > due to devfs "races". So I feel it's quite unfair to paint such a dire > > picture (I'm referring to Martin's comments here, not Alan's). > > And _that_ approach is the reason why I absolutely refuse to run > your code on any of my boxen. Sorry. If devfs (without serious > cleanup) will become mandatory I'll fork the tree - better > backporting patches to Linus' one than depending on current devfs. Al, I've told you that the races will be fixed. Calm down. I know you take a very theoretical and hard-line approach. All I said was that the races aren't causing problems for people in real life. That's why some vendors are using it. I never disagreed with you about the existence of the races. Peace, OK? > You've been sitting on known (and easily fixable) bugs and asking to > leave fixing them to you for what, 10 months already? Furrfu... Yeah, 10 months during which I've gone to 7 conferences/workshops, written 2 papers, moved house twice, took two holidays (sorry, I have a life), moved/split/unsplit our lab network twice, caught the flu at least once, and sundry other distractions. Pardon me for being busy. > You are maintainer of that code. You keep insisting on having > everything and a kitchen sink in the devfs and refuse to split the > functionality into reasonable pieces. Essentially you are saying > that it's all or nothing deal. Fine with me - out of these options > I certainly prefer the latter. The claim that splitting it into pieces will be an improvement is just hand-waving. I've not seen a solid argument that shows how it will help. Especially not after I remove the FS database code in devfs and just use the dcache to store my tree. That will trim the code by 50% or more. I'm going to wait and see how my next versions of devfs turn out before I make any hard claims. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EATA driver with DPT SmartRAID V
> Bus 1, device 1, function 0: > PCI bridge: Distributed Processing Technology PCI Bridge (rev 2). > Master Capable. Latency=64. Min Gnt=3. > Bus 1, device 1, function 1: > I2O: Distributed Processing Technology SmartRAID V Controller (rev 2). This card isnt supported by the eata driver. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ReiserFS? How reliable is it? Is this the future?
> The bad (2.2 kernels) > > * Nothing I can think of Security exploit according to bugtraq, but Im pretty sure it wont take Chris Mason and friends long to fix that. > The bad (2.4.x kernels): > > * Some corruption problems with various 2.4.x kernels, but > people are reporting ext2 problems, too, so this is > probably due at least in part to IDE/PCI chipset issues With the latest tail fixes Im fairly sure the remaining corruptions are not reiserfs specific - but not yet 100% confident. > * Some corruption problems if an application > uses an nfs-mounted reiserfs partition during > an unexpected shutdown of the nfs server (You want the NFS patches too) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ACPI: S1 working for someone?
Hi! Does S1 going back from S1 work for you? As soon as hit power button in S1, machine powers off... It should just continue where it started. 2.4.3 on toshiba satelite 4030cdt. Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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
> However, a large number of people run devfs on small to large systems, > and these "races" aren't causing problems. People tell me it's quite They dont have users actively trying to exploit them. I don't consider it a big problem for development trees though. devfs has a maintainer at least 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/
Re: uninteruptable sleep
> ps xl: > F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND > 040 1000 1230 1 9 0 24320 4 down_w D ? 0:00 > /home/data/mozilla/obj/dist/bin/mozi > down_w Perhaps down_write_failed()? 2.4.3 converted the mmap semaphore to a rw-sem. Did you compile sysrq into your kernel? Then enable it with #echo 1 > /proc/sys/kernel/sysrq and press ++'t' It prints the complete back trace, not just one function name -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SOLVED]Re: 2.2.19 && ppa: total lockup. No problem with 2.2.17
On Sat, Mar 31, 2001 at 01:59:39AM +0200, Juan Piernas Canovas wrote: > Yes!!!. It works. I am happy now :-) Unfortunately, the problem isn't solved, merely worked around. We need to figure out why this is happening in the first place. To recap, the system hangs completely when you load the ppa module. Are you using any special parport/ppa parameters? Is this an SMP or a uniprocessor machine? Come to that, which architecture is it? Are there any messages displayed to the console when the hang happens? If you could scatter some printks around (KERN_CRIT so they show up on the console) to figure out the example point at which it's hanging, that would be great. Thanks, Tim. */ PGP signature
