Re: maximum number of sockets
Lee Chin ([EMAIL PROTECTED]) wrote: > How do I increase the maximum number of socket connections I can have open > in the 2.4 series kernel? See http://www.kegel.com/c10k.html#limits.filehandles - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
bug report
hi all,
I hope it is the right mailing list!
Kernel version 2.2.5-15 and 2.2.10 (no other available)
The problem:
A consol-terminal connected to /dev/ttyS? cannot work with parity = odd.
error is in:
/usr/src/linux/drivers/serial.c
error resolving:
In fuction :
__initfunc(static int serial_console_setup(struct console *co, char
*options))
at line 3488:
wrong:
switch(parity) {
case 'o': case 'O':
cflag |= PARODD;
break;
case 'e': case 'E':
cflag |= PARENB;
break;
}
ok:
switch(parity) {
case 'o': case 'O':
cflag |= PARODD;
cflag |= PARENB;
break;
case 'e': case 'E':
cflag |= PARENB;
break;
}
best regards,
frank salomon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix queued SIGIO
Hello, On Tue, 19 Sep 2000, Robert H. de Vries wrote: > It would be better to change SI_SIGIO in all the > include/asm-*/siginfo.h files from -5 to __SI_CODE(__SI_SIGIO, -5) > __SI_SIGIO would become (6 << 16). This is not needed for SI_SIGIO. It is not generated from the kernel. It seems this interface is already obsoleted. > The code in arch/*/kernel/signal.c only copies the lower 16 bits to user > space. This means that the test SI_FROMKERNEL returns true and user space > still gets the same values as before. > > The same trick is indeed used also in my POSIX timer patch. Yes, for every code generated from kernel. The others are in __SI_KILL group. I see, __SI_CODE is fixed in your patch. Very good. There are some unused groups (__SI_RT) but I can't find descriptions or comments. Is it "Real Time" ? Hm. Regards -- Julian Anastasov <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __ucmpdi2
On Sep 19, 8:39am, Richard Henderson wrote:
>
> On Tue, Sep 19, 2000 at 12:22:41PM +0200, Andreas Schwab wrote:
> > IMHO it's a bug in gcc that it does not inline the comparison inside the
> > switch expression, since it already does it in all other places. Perhaps
> > some problem with the patterns in the machine description.
>
> Perhaps, but without a test case it's hard to know. My guess is that
> he's using gcc 2.7.2 or something decrepit like that; I couldn't reproduce
> the problem on current source with a simple test case.
haze 334% gcc -dumpversion
egcs-2.91.66
The code is:
uint64_t
user_of___ucmpdi2(uint64_t node, uint64_t port)
{
switch (node)
{
case 1:
if (node == port)
return 0;
break;
case 2: /* variation in either 59-48 or 23-0 to reflect port number */
/*
* 63-60, 47-0 same in node and port;
* 59-48 is 0 in node, port # in port
*/
if (node == (port & ~((uint64_t) 0xFFF << 48)))
return ((port >> 56) & 0xF) | ((port >> 44) & 0xFF0);
/*
* 63-24 same in node and port;
* 23-0 of port minus 23-0 of node is effective port number
*/
if ((node & (0xFF << 24)) == (port & (0xFF << 24)))
return (port - node) & 0x1FF;
break;
}
return port;
}
In reality, the switch does a 60 bit shift right, so I can cast to a
uint, which is the right thing to do on old architectures :-), solving
the problem. I had originally thought that the problem was in all the
masks, shifts, and compares, but they are all inlined.
jeremy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
Tom Rini wrote: > I wasn't arguing that (really) it's just that it really should have gone in > sooner. It's all really a moot point I understand, but still. major I understand your gripe but it couldn't be helped as it was. If more people stepped forward who really understood the mechanics and had the time to implement golden solutions we'd be happy little people. Until then we'll have to endure the schedule as it is. -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Re: [PATCH] Fix queued SIGIO
Hello,
On Tue, 19 Sep 2000, Chuck Lever wrote:
> also, the test at issue here (from line 363 of kernel/signal.c):
>
> /* If this was sent by a rt mechanism, try again. */
> if (info->si_code != SI_USER) {
> ret = -EAGAIN;
> goto out;
> }
Hm, I can't find this. It is may be already fixed in the latest
kernels.
> we just published a paper in the ALS proceedings describing our
> implementation of a new system call similar to sigtimedwait() that
> collects many events at once.
This is interesting. Let me know if this paper is
accessible from web.
Regards
--
Julian Anastasov <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: __ucmpdi2
> - Linux developers often do horribly stupid things, and use 64-bit >division etc instead of using a simple shift. Again, not linking >against libgcc finds those things early rather than late, because the >horribly stupid things end up requireing libgcc support. I would have thought that the compiler would generate a shift if it could (I'm presuming you're talking about shifting by a constant here -- or are you talking about code that always shifts by a computed power of two). > In the case of __ucmpdi2, it appears to be a combination of kernel and > compiler stupidity - there's no reason why __ucmpdi2 should not be done > inline by the compiler, but at the same time there is probably also > little reason to use a slow "long long" comparison in the kernel. Little reason or no reason? If there is a reason, and it doesn't work, then the coder is forced to rewrite using 32 bit variables, synthesizing the result. Then you have belabored C code as well as belabored machine code, and it doesn't automatically clean up when you move to a 64 bit machine. > So again, not linking libgcc showed a problem. Good for us. (Un)fortunately, it was only the switch that caused the problem. Other expressions using 64 bit variables work fine. So you can use: if ((uint64_t) x == (uint64_t) y) ... all you want. So what we've said is: 64 bit is okay, except in a switch statement, or other random expressions that might cause gcc to embed a call to similar libgcc function. If you run into that, figure out what caused it (presumably by disassembling and comparing with source), and then use a different construction (that may be more obtuse). If you can, change to 32 bits. And you may be forced to. > But yes, it is often much more convenient to not know about problems > like this. And some people don't think they are a big deal. I'd rather > nip them in the bud early than be "convenient", myself. > > Linus jeremy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 09:36:30PM -0700, David Ford wrote: > Tom Rini wrote: > > > >that. I see that 2.4 is getting all kinds of changes merged in > > >that should be going on with 2.5. The recent VM changes have left > > >us with deadlocks that we didn't have before. Shouldn't that have > > >gone into 2.5 not 2.4? > > Well, I think the bitterness comes from (partily anyways) it going into > > 2.4.0-test9-pre1, along with other seemingly large updates, which did need > > to go in but really don't sound right for a -test. I guess Linus didn't want > > to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like > > small stuff (maybe my memory just sucks tho). > > The VM work has been scheduled to go in for a while. If you check the TODO > emails from months back, it's always been there. I wasn't arguing that (really) it's just that it really should have gone in sooner. It's all really a moot point I understand, but still. major overhauls should get in before the -testX IMHO. This is the point I think Cort was going after. Sure it's been well tested. But it's a major rewrite and it has introduced deadlocks (I'm going to have to track one down myself I think, this weekend) that weren't there. I'm sure it also fixed some. -- 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] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.9.4: Fix Cardbus
Jeff Garzik writes: > Ok, it's time to get test9 running on my laptop, so I played the "what > code didn't get cut-n-pasted" game. > > With the attached tested patch against 2.4.0-test9-pre4, CardBus is > working again for me. This patch makes the logic match that of the > old code. What patch? 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] Please read the FAQ at http://www.tux.org/lkml/
PATCH 2.4.0.9.4: Fix Cardbus
Ok, it's time to get test9 running on my laptop, so I played the "what code didn't get cut-n-pasted" game. With the attached tested patch against 2.4.0-test9-pre4, CardBus is working again for me. This patch makes the logic match that of the old code. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.9.4: Fix Cardbus
Jeff Garzik wrote:
> With the attached tested patch against 2.4.0-test9-pre4, CardBus is
> working again for me. This patch makes the logic match that of the old
> code.
-ENOSLEEP. Here is the patch.
Index: drivers/pci/pci.c
===
RCS file: /g/cvslan/linux_2_3/drivers/pci/pci.c,v
retrieving revision 1.1.1.30
diff -u -r1.1.1.30 pci.c
--- drivers/pci/pci.c 2000/09/17 19:44:33 1.1.1.30
+++ drivers/pci/pci.c 2000/09/20 04:45:26
@@ -693,6 +693,10 @@
if (!is_cardbus) {
unsigned int cmax = pci_do_scan_bus(child);
if (cmax > max) max = cmax;
+ } else {
+ int i;
+ for (i = 0; i < 4; i++)
+ child->resource[i] =
+&dev->resource[PCI_BRIDGE_RESOURCES+i];
}
} else {
/*
@@ -718,12 +722,15 @@
/* Now we can scan all subordinate buses... */
max = pci_do_scan_bus(child);
} else {
+ int i;
/*
* For CardBus bridges, we leave 4 bus numbers
* as cards with a PCI-to-PCI bridge can be
* inserted later.
*/
max += 3;
+ for (i = 0; i < 4; i++)
+ child->resource[i] =
+&dev->resource[PCI_BRIDGE_RESOURCES+i];
}
/*
* Set the subordinate bus number to its real value.
Re: Linux-2.4.0-test9-pre2 (version numbering)
On Tue, Sep 19, 2000 at 09:26:44PM -0700, Barry K. Nathan wrote: > > to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like > > small stuff (maybe my memory just sucks tho). > > I don't think there ever were any 2.2.0-testX patches - my recollection is > that we went from 2.1.1xx to 2.2.0-preX, with no -testX in between like we > seem to be having now. Ah yes, oops. I also then think people are assuming (possibly wrongly) that 2.4.0-testX == 2.4.0-preX. -- 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Sep 19, 10:35am, Eric Youngdale wrote: > > OK, my guess is that we may need to do some tweaking to the Makefile. > The basic idea is that you need to probe for hosts in a specific order. > The reason for this is that some host adapters emulate other types of > hardware. For example, some Buslogic cards emulate Adaptec 1542. > Typically in such cases you want the Buslogic driver to handle the card and > not the 1542 driver (mainly for performance reasons - Leonard would probably > have more to say about this). There *may* be other instances where probing > for one type of card can screw up another type of card, but I haven't heard > of cases like this in some time now, > > There are a handful of others - the comments in the initializer in > hosts.c explain some of them. I hope there are not others which people > failed to document. > > A second potential gotcha - for compiled in drivers, I think that > low-level drivers should be initialized prior to upper level drivers. The > reason for this is that not all of the upper level drivers are capable of > resizing the arrays on the fly (disk and cdrom are the two exceptions). > Yes, cleaning this up is on the list of things to do (it got partly done for > 2.4), but fixing this is a nasty problem that reaches it's bony fingers all > the way up into some of the filesystems (essentially those stupid arrays in > ll_rw_blk which are read without any type of spinlock protection). The > CONFIG_SD_EXTRA_DEVS parameter is used to pre-allocate room in the arrays > for additional devices, so for systems with small numbers (< 40) of disks > things may just happen to work. > > For now, the trick should simply be to keep the upper level drivers at > the end of the list of objects to be linked in so the initializers run last. > Thus my gut tells me the correct link order should be: > > 1) SCSI core. > 2) low-level drivers (in same order as specified in hosts.c). > 3) upper level drivers. > > -Eric My system has both an Adaptec adapter and a Qlogic adapter. The number of disks on the Qlogic was variable (it was attached to a SAN). The boot disk is attached to the Adaptec. If the Qlogic was probed first, then linux could not find the root device, so I had to move the Adaptec 7xxx above the Qlogic in hosts.c. Is there another way to do this? If so, I'd like to know. If not, then we need the same configurability with the new scheme. jeremy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
Tom Rini wrote: > >that. I see that 2.4 is getting all kinds of changes merged in > >that should be going on with 2.5. The recent VM changes have left > >us with deadlocks that we didn't have before. Shouldn't that have > >gone into 2.5 not 2.4? > Well, I think the bitterness comes from (partily anyways) it going into > 2.4.0-test9-pre1, along with other seemingly large updates, which did need > to go in but really don't sound right for a -test. I guess Linus didn't want > to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like > small stuff (maybe my memory just sucks tho). The VM work has been scheduled to go in for a while. If you check the TODO emails from months back, it's always been there. The VM patch required a lot of work and naturally such a big thing is going to uncover or trigger other bugs as well as expose bugs of it's own. It's gone in so we can find all those bugs and fix them before 2.4 gets released. In it's previous state, 2.4 was really bad for VM handling, that would have looked great for -all- enthusiasts to say "well...sure, 2.2 has better handling, but 2.4 is out!" *blink* *blink* -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Re: Linux-2.4.0-test9-pre2 (version numbering)
> to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like > small stuff (maybe my memory just sucks tho). I don't think there ever were any 2.2.0-testX patches - my recollection is that we went from 2.1.1xx to 2.2.0-preX, with no -testX in between like we seem to be having now. In other words, if I understand things correctly, once we have Linux 2.4.0-test4294967296 ;) and 2.4 is stable enough for the last phase of testing before release, 2.4.0-pre1 will be next... -Barry K. Nathan <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha/Linux FP denormal processing
Date:Tue, 19 Sep 2000 19:23:42 -0700 From: Richard Henderson <[EMAIL PROTECTED]> Rather than fix the old udiv128 function, which was trying to do 128/128 bit division, I've pulled in a subroutine from libgcc that does 128/64 bit division, which is all we need here. So it should be a bit faster than the old routine, for what ever that's worth to someone who is already trapping into the kernel... Is this a serious patch submission or just a call for testing? If the former, I need to cook up the sparc bits once it gets in :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: networking todo, was Re: Linux-2.4.0-test9-pre2
Date:Wed, 20 Sep 2000 04:38:24 +0200 From: "Andi Kleen" <[EMAIL PROTECTED]> We must be talking about different things. It of course detects it on ACK input, but only for data it did send itself. Every TCP detects reordering automatically on the input with the sequence number check, but all we still do is to send an ACK immediately and go into quickack mode. Or did I miss something ? ... [I talked a lot with Andrea about this during OLS, and we couldn't figure out a good way] Nevermind, I've apparently got my directions reversed. :-) I'll think about this a bit. Just use __cacheline_aligned instead, like I did with the ip_local_data in the patch you just rejected. There is still the problem that generic SMP x86 kernels use a 32byte cacheline. Not a problem currently because the only x86 SMP is pII/pIII which has 32byte, but with Williamette/Athlon SMP it'll be a problem because these have 64byte and 128byte cache lines. With __cacheline_aligned it'll be easy though to pick up such changes. Ok, feel free to send me a patch which does only this. I may doctor it up a bit, be warned :-) On the other hand, the inetpeer code is only really exercised on machines that talk to lots and lots of destinations (=real servers), and 2.4 testing on such machines still has to begin. Given that 2.4 testing has not really begun yet I would guess that it is safer to remove it now @) True, but the following is what I'm really thinking about. Suppose a few weeks from now Alexey greets both of our mailboxes with a fabulous solution to the tw recycle masqeurading problem, wouldn't it be quite a pain in the ass to put back in and retest all the inetpeer code? Let's sit on this until Alexey gives a forecast about the possibilities of a solution in the near future ok? Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Bug and patch for md driver in 2.2.x. Could somebody please review?
Problem:
The md driver doesn't handle large physical blocks in 2.2.x
Pardon the long introduction, but it might be interesting to the non IBM
types.
I'm doing some work with Linux/S390 and need to access about 100GB of
disk. The 3390 drives I can use are about 2.3GB each and that comes out
to a lot of disks. I was hoping to use the MD driver to combine those
40+ volumes into something like 4 md volumes.
The IBM disk is somewhat unusual in that the actual physical disk blocks
can be virtually any size. (They call it Count Key Data for those not
familiar with it.) You can even mix sizes on a track!
Obviously this isn't too healthy for Unix I/O subsystems so the solution
is to support a small number of block sizes and keep them all fixed at
the same size for a given disk. This is indeed what the formatting tool
under Linux does. (512, 1024, 2048 and 4096 appear to be supported.)
When formatted correctly the disk is then presented to Linux as a fixed
block device of one of those sizes. The 4k block size yields about 31%
more usable disk space than the 1k block size, so it is very attractive.
The problem (after banging away at it for nearly 18 hours straight) is
that the md driver doesn't export the underlying hard sector size of the
real device (512 is pretty much assumed) and when ext2fs tries to do a
1k bread for the superblock of a disk with larger than 1k blocks the
DASD driver returns an error and the machine soon dies. Mount doesn't
return and it has the big kernel lock at that point so the system is
toast. The basic problem is that the hardsect_size variable used by the
get_hardblocksize() routine is not set up by the md driver.
A quick look at the 2.4pre code shows that this has been addressed so I
have taken a crack at adding a few similar lines of code to md.c in
order to get things working. I have to confess that except for a couple
of other trivial Linux patches I haven't done any OS programming since
my IBM/S370 days, so I'm somewhat uncomfortable at touching the I/O
subsystem. Still the Linux philosophy is if you need it and it doesn't
work go fix it, and I have tried.
I've tested this on Linux/S390 with different block sizes by filling the
md device with files with a known md5sum and then verifying that they
still match. It seems solid and I don't think I've done anything to
foul up other architectures, but as I said, I don't consider myself an
expert. I suspect somebody that knows this stuff could take a look and
tell me if I've done anything really stupid.
If that person(s) with some experience with the md driver and/or I/O
subsystem could review this, I'd sure appreciate it. Since it is useful
I'd like to submit it to Alan for inclusion in 2.2.1[89].
One more thing, I've always hated when folks post to a list but claim
they need email replies because they aren't on the list. Unfortunately
while I followed the list when I could get digests from vger the
hundreds of messages from the new non-digest list give my employer
heartburn. I have not yet gotten a workaround in place so I find myself
pleading for email responses. Sigh.
Anyway, here is the patch. If you have suggestions or can test it, I'd
sure appreciate it.
There is also one other small patch that is part of the S390 system.
You'll need to apply it first to keep the context the same (unless
you're running a S390 Linux system with the August patches) but it is
conditional on the 390 system and shouldn't have an effect on
anything else, except to get my patch to apply.
Thanks in advance!
Here is the IBM patch to md.c Apply first in the drivers/block
directory.
cut here --
diff -u -r --new-file linux-2.2.16/drivers/block/md.c
linux-2.2.16-s390/drivers/block/md.c
--- md.cWed Jun 7 23:26:42 2000
+++ md.cFri Jun 16 11:51:35 2000
@@ -445,8 +445,13 @@
}
factor = min = 1 << FACTOR_SHIFT(FACTOR((md_dev+minor)));
-
+
+#ifdef CONFIG_ARCH_S390
md_blocksizes[minor] <<= FACTOR_SHIFT(FACTOR((md_dev+minor)));
+ if ( md_blocksizes[minor] > PAGE_SIZE ) {
+ md_blocksizes[minor] = PAGE_SIZE;
+ }
+#endif
for (i=0; i md_hardsect_sizes[minor])
+ md_hardsect_sizes[minor] = get_hardblocksize(md_dev[minor].devices[i].dev);
}
+
+ if(md_blocksizes[minor] < md_hardsect_sizes[minor])
+ md_blocksizes[minor] = md_hardsect_sizes[minor];
/* Resize devices according to the factor. It is used to align
partitions size on a given chunk size. */
@@ -933,6 +940,7 @@
for(i=0;ihttp://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
On Tue, Sep 19, 2000 at 04:11:30PM -0700, David S. Miller wrote: > Unfortunately, gcc does not make inline functions as cheap as "macros > with type checking". There are extra costs and often the register > allocator cannot cope and stuff starts getting spilled to the stack. It is supposedly on the way to be fixed, if it isn't already done. I'm not completely positive it is in the requirements of gcc 3.0, but I think it is. It is already fixed for C++. Keywords to look for in the gcc MLs: tree-based inlining, function-at-a-time parsing. OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [User-mode-linux-user] Ptrace broken since 2.4.0-test8pre4?...
[EMAIL PROTECTED] said: > I tested vanilla test7 with ptrace() patch. It breaks uml exactly > like I see with any kernel > test7. > exec_user.c:29 ptrace(PTRACE_SYSCALL, 4901, 0, 0) = 0 > And voila, we got SIGSEGV instead of happy running child: > Child 4901 exited with signal 11 Yuri, I apologize for doubting you. That's about the best evidence possible that the test8 ptrace fix is what's breaking UML and not the thread group stuff. If anyone has any idea why that fix breaks PTRACE_SYSCALL, I'd love to know. I'm kind of short on time at the moment, so I'm not in a great position to delve into this at the moment. Until this is fixed, UML doesn't work on any host kernels beyond test7. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
inode_max in 2.4
Hello, I searched Documents and couldn't find what /proc/sys/fs/inode_max has been changed to... because after 800 simultaneous open socket connections I get a "Too many open files" EMFILE error Thanks, lee __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 05:14:39PM -0700, David S. Miller wrote: >Date: Tue, 19 Sep 2000 18:07:20 -0600 >From: Cort Dougan <[EMAIL PROTECTED]> > >Do you really think that's forcing people to concentrate of fixing >bugs? Tell me if you disagree, I'd like to understand how you see >that. I see that 2.4 is getting all kinds of changes merged in >that should be going on with 2.5. The recent VM changes have left >us with deadlocks that we didn't have before. Shouldn't that have >gone into 2.5 not 2.4? > > The VM performance in 2.4.x was a major regression from 2.2.x and is > required to be fixed for 2.4.0 release. Riel did the bulk of this > work, and it's now just dealing with a few remaining details on very > low memory systems. His changes fixed a major problem, and > structurally I believe his changes are completely sound and were > justifiably included in 2.4.x. > > So I think this was a bad example. Well, I think the bitterness comes from (partily anyways) it going into 2.4.0-test9-pre1, along with other seemingly large updates, which did need to go in but really don't sound right for a -test. I guess Linus didn't want to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like small stuff (maybe my memory just sucks tho). > I'll say this much, if 2.5.x existed I'd be spending most of my time > on a clean zero-copy TCP framework instead of walking over the net > stack and sparc64 code verifying things every day, that is for sure. > So yes, I am really thinking that it is forcing people to concentrate > on fixing bugs, because at least it is doing so for me. I know that > the faster 2.4.x happens the faster the "fun" 2.5.x stuff comes along. What Cort didn't mention is that at least some of this fun experimental stuff is things like better support for new machines, along with bug fixing for 2.4 (ie people can use all their PCI cards without resource conflicts again). -- 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] Please read the FAQ at http://www.tux.org/lkml/
maximum number of sockets
Hello, How do I increase the maximum number of socket connections I can have open in the 2.4 series kernel? Please let me know which list to post these types of questions to. Thanks, Lee __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: networking todo, was Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 06:54:30PM -0700, David S. Miller wrote: >Date: Wed, 20 Sep 2000 03:51:37 +0200 >From: "Andi Kleen" <[EMAIL PROTECTED]> > >>Receiver side SMP reordering is still there, but I'm not sure if it is >>fixable (but it'll surely hit people that cannot use Linux senders, I >>just see the reports) >> >> Reordering is a non-issue for ipv4/ipv6, all of the massive TCP input >> rewrite was strictly about dealing with this. No SMP reordering >> should cause any bogus fast retransmits etc. for example. > >You mean TCP output rewrite ? The fix was strictly sender side only >(I first thought one of the ack changes alexey did was an attempt at a >hackish receiver side solution, but he told me that was false) > >> What is the problem? Are you referering to the LAPB/X25 stuff? > >When you have a non linux 2.4 sender you lose. > > Alexey's changes detect reordering on the input side, regardless of > whether it is speaking to a Linux senders or not, to avoid false > retransmits. We must be talking about different things. It of course detects it on ACK input, but only for data it did send itself. Every TCP detects reordering automatically on the input with the sequence number check, but all we still do is to send an ACK immediately and go into quickack mode. Or did I miss something ? The only way to do true reordering handling on the receiver I can think of would be to use something like the soft-timers to do very very fast delayed acks even for rcv_mss sized packets and hope that you collect packets from all CPUs in the delay, but overall it could still cost you a lot by disturbing the ACK clock [I talked a lot with Andrea about this during OLS, and we couldn't figure out a good way] > Please show me (and even more importantly Alexey) an example of where > receive reordering detection is dependant upon Linux TCP sender > behavior, his code it is as generic as I can imagine it to be. In > fact, his code got lots of the testing on a web server serving almost > exclusively clients running windows :-) Web clients probably do not send enough data to make reordering a problem because the request fits into 1-2 packets and the 3way handshake is not reordering sensitive. (I haven't looked at SpecWeb that closely, but has it really any client sent data that is >packet size?) > Ok, linux_mib is obviously not exact but in that case I would argue > that the extra size needed (to get to the next a power of 2) would > outweight whatever instruction performance gain we'd get. > > As for the udp etc. case, how do we pick a "number" to make these > arrays as you say they should be? Just use __cacheline_aligned instead, like I did with the ip_local_data in the patch you just rejected. There is still the problem that generic SMP x86 kernels use a 32byte cacheline. Not a problem currently because the only x86 SMP is pII/pIII which has 32byte, but with Williamette/Athlon SMP it'll be a problem because these have 64byte and 128byte cache lines. With __cacheline_aligned it'll be easy though to pick up such changes. > I would only make these changes for the snmp mibs which are "smaller" > than this "number" we pick, the larger ones won't see much false > sharing at all. > > I think this is really a small and trite issue actually. I don't think so. There was so much pain to avoid cache line bouncing for fast paths, it would be a shame to add it again for silly statistics keeping. > Removing a lot of code also means undoing all the testing done so far > with that code present :-))) True. On the other hand, the inetpeer code is only really exercised on machines that talk to lots and lots of destinations (=real servers), and 2.4 testing on such machines still has to begin. Given that 2.4 testing has not really begun yet I would guess that it is safer to remove it now @) -Andi (who is off to bed now) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha/Linux FP denormal processing
On Tue, Sep 19, 2000 at 09:52:15AM -0700, Richard Henderson wrote:
> > Instead of *= 0.5, try /= 2.0
>
> Yes indeed you've found a bug in the kernel's FP emulation.
> I'll see about fixing it.
Rather than fix the old udiv128 function, which was trying to do
128/128 bit division, I've pulled in a subroutine from libgcc
that does 128/64 bit division, which is all we need here.
So it should be a bit faster than the old routine, for what ever
that's worth to someone who is already trapping into the kernel...
r~
diff -ruNp linux/arch/alpha/math-emu/Makefile 2.4.0-9-4/arch/alpha/math-emu/Makefile
--- linux/arch/alpha/math-emu/Makefile Thu Dec 2 15:28:54 1999
+++ 2.4.0-9-4/arch/alpha/math-emu/Makefile Tue Sep 19 18:45:17 2000
@@ -8,7 +8,7 @@
# Note 2! The CFLAGS definition is now in the main makefile...
O_TARGET := math-emu.o
-O_OBJS := math.o
+O_OBJS := math.o qrnnd.o
CFLAGS += -I. -I$(TOPDIR)/include/math-emu -w
ifeq ($(CONFIG_MATHEMU),m)
diff -ruNp linux/arch/alpha/math-emu/math.c 2.4.0-9-4/arch/alpha/math-emu/math.c
--- linux/arch/alpha/math-emu/math.cTue Mar 21 10:47:06 2000
+++ 2.4.0-9-4/arch/alpha/math-emu/math.cTue Sep 19 18:26:38 2000
@@ -84,66 +84,6 @@ void cleanup_module(void)
#endif /* MODULE */
-/* For 128-bit division. */
-
-void
-udiv128(unsigned long divisor_f0, unsigned long divisor_f1,
- unsigned long dividend_f0, unsigned long dividend_f1,
- unsigned long *quot, unsigned long *remd)
-{
- _FP_FRAC_DECL_2(quo);
- _FP_FRAC_DECL_2(rem);
- _FP_FRAC_DECL_2(tmp);
- unsigned long i, num_bits, bit;
-
- _FP_FRAC_SET_2(rem, _FP_ZEROFRAC_2);
- _FP_FRAC_SET_2(quo, _FP_ZEROFRAC_2);
-
- if (_FP_FRAC_ZEROP_2(divisor))
- goto out;
-
- if (_FP_FRAC_GT_2(divisor, dividend)) {
- _FP_FRAC_COPY_2(rem, dividend);
- goto out;
- }
-
- if (_FP_FRAC_EQ_2(divisor, dividend)) {
- __FP_FRAC_SET_2(quo, 0, 1);
- goto out;
- }
-
- num_bits = 128;
- while (1) {
- bit = _FP_FRAC_NEGP_2(dividend);
- _FP_FRAC_COPY_2(tmp, rem);
- _FP_FRAC_SLL_2(tmp, 1);
- _FP_FRAC_LOW_2(tmp) |= bit;
- if (! _FP_FRAC_GE_2(tmp, divisor))
- break;
- _FP_FRAC_COPY_2(rem, tmp);
- _FP_FRAC_SLL_2(dividend, 1);
- num_bits--;
- }
-
- for (i = 0; i < num_bits; i++) {
- bit = _FP_FRAC_NEGP_2(dividend);
- _FP_FRAC_SLL_2(rem, 1);
- _FP_FRAC_LOW_2(rem) |= bit;
- _FP_FRAC_SUB_2(tmp, rem, divisor);
- bit = _FP_FRAC_NEGP_2(tmp);
- _FP_FRAC_SLL_2(dividend, 1);
- _FP_FRAC_SLL_2(quo, 1);
- if (!bit) {
- _FP_FRAC_LOW_2(quo) |= 1;
- _FP_FRAC_COPY_2(rem, tmp);
- }
- }
-
-out:
- *quot = quo_f1;
- *remd = rem_f1;
- return;
-}
/*
* Emulate the floating point instruction at address PC. Returns 0 if
diff -ruNp linux/arch/alpha/math-emu/qrnnd.S 2.4.0-9-4/arch/alpha/math-emu/qrnnd.S
--- linux/arch/alpha/math-emu/qrnnd.S Wed Dec 31 16:00:00 1969
+++ 2.4.0-9-4/arch/alpha/math-emu/qrnnd.S Tue Sep 19 18:41:26 2000
@@ -0,0 +1,163 @@
+ # Alpha 21064 __udiv_qrnnd
+ # Copyright (C) 1992, 1994, 1995, 2000 Free Software Foundation, Inc.
+
+ # This file is part of GCC.
+
+ # The GNU MP Library is free software; you can redistribute it and/or modify
+ # it under the terms of the GNU General Public License as published by
+ # the Free Software Foundation; either version 2 of the License, or (at your
+ # option) any later version.
+
+ # In addition to the permissions in the GNU General Public License, the
+ # Free Software Foundation gives you unlimited permission to link the
+ # compiled version of this file with other programs, and to distribute
+ # those programs without any restriction coming from the use of this
+ # file. (The General Public License restrictions do apply in other
+ # respects; for example, they cover modification of the file, and
+ # distribution when not linked into another program.)
+
+ # This file is distributed in the hope that it will be useful, but
+ # WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ # or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public
+ # License for more details.
+
+ # You should have received a copy of the GNU General Public License
+ # along with GCC; see the file COPYING. If not, write to the
+ # Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ # MA 02111-1307, USA.
+
+.set noreorder
+.set noat
+
+ .text
+
+ .globl __udiv_qrnnd
+ .ent __udiv_qrnnd
+__udiv_qrnnd:
+ .frame $30,0,$26,0
+ .prologue 0
+
+#define cnt$2
+#define tmp$3
+#define rem_ptr$16
+#define n1
Re: networking todo, was Re: Linux-2.4.0-test9-pre2
Date: Wed, 20 Sep 2000 03:51:37 +0200 From: "Andi Kleen" <[EMAIL PROTECTED]> >Receiver side SMP reordering is still there, but I'm not sure if it is >fixable (but it'll surely hit people that cannot use Linux senders, I >just see the reports) > > Reordering is a non-issue for ipv4/ipv6, all of the massive TCP input > rewrite was strictly about dealing with this. No SMP reordering > should cause any bogus fast retransmits etc. for example. You mean TCP output rewrite ? The fix was strictly sender side only (I first thought one of the ack changes alexey did was an attempt at a hackish receiver side solution, but he told me that was false) > What is the problem? Are you referering to the LAPB/X25 stuff? When you have a non linux 2.4 sender you lose. Alexey's changes detect reordering on the input side, regardless of whether it is speaking to a Linux senders or not, to avoid false retransmits. Please show me (and even more importantly Alexey) an example of where receive reordering detection is dependant upon Linux TCP sender behavior, his code it is as generic as I can imagine it to be. In fact, his code got lots of the testing on a web server serving almost exclusively clients running windows :-) When I count correctly sizeof(udp_mib) is 16 bytes currently (lots of false sharing on 32/64byte cacheline sized architectures) and linux_mib is 288 bytes currently (does not make any sense at all) Ok, linux_mib is obviously not exact but in that case I would argue that the extra size needed (to get to the next a power of 2) would outweight whatever instruction performance gain we'd get. As for the udp etc. case, how do we pick a "number" to make these arrays as you say they should be? I would only make these changes for the snmp mibs which are "smaller" than this "number" we pick, the larger ones won't see much false sharing at all. I think this is really a small and trite issue actually. >UDP recvmsg error handling for csum errors is bogus (fix pending) > > Ok, send me a patch so I can see what the problem is. Appended. Applied. The "unknown gain" is just removing a lot of complexity => speed and less bugs. Removing a lot of code also means undoing all the testing done so far with that code present :-))) The only advantage I know left is saving pmtus for a bit longer, but I doubt it is worth the complexity. Neither of us are experts in this area, Alexey is. Do you have any specific plan for salvaging tw recycling ? Just keeping such an intrusive piece of code for benchmarks around looks wasteful to me. Nope, but this also requires Alexey's input. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] (long) network interface changes
On Wed, 20 Sep 2000, Henner Eisen wrote: [some suggestions for the next re-incarnation of the doc deleted] > > jamal> I have experimented with two schemes: one which samples the > jamal> queue via a timer and one which does it per-packet and > jamal> found that the per-packet sampler gave better results (more > jamal> samples, Shannon's theorem applies). It didnt matter > jamal> whether HZ was 100 or 1024 during the tests. The measure > jamal> of "better" was throughput. > > Nice. I think such a kind of fair input queueing would be an important > features because that allows to offer a highly reliable netif() to > slow links which are slow, but inefficient to handle congestion > (like X.25 LAPB datalink protocol). Network interfaces could trade > reliablilty for speed. > So i would prefer to leave this turned off. Infact i was hoping to take it off for the final code submission. If you insist, it could be left there and enabled during compile. There could be better ways to do it but experimentation is required. It will definetely help in the case of low and high speed devices. > Another issue: Some protocols designed for congestable links support > forward and/or backward congestion notification (e.g. frame relay, I thing > DECnet and IPV6 also can do so). Thus, it would be nice if those protocols > could easily access the congestion state such that congestion notification > bits can be set efficiently. IPV4 as well. In the case of V6 and V4 it is called ECN. causing quiet a bit of havoc right now ;-> I can see the netif_rx() feedback clearly fitting in the 'receive busy/not-ready' details you talked about earlier. I dont see the CN fit clearly. Maybe one way is to set the Frame Relay FECN bit after you return from netif_rx()? callbacks? nah, too complicated... > Seems there are lots of interesting problems to investigate and > to solve. Anyhow, no matter how the details will be in future, > What´s basically needed is a return value for netif_rx(). This is also > `nice` for symmetry reasons (in 2.4.x, dev_queue_xmit() returns an > int, too). > Good idea. There is some mapping e.g. NET_RX_SUCCESS maps to BLG_CNG_NONE NET_RX_DROP maps to BLG_CNG_DROP NET_*_POLICED and NET_*_BYPASS have no proper mapping in the receive path but we could define them as well Only difference i see are that we will need several NET_RX_CN defines because we have BLG_CNG_LOW, BLG_CNG_MOD and BLG_CNG_HIGH so a NET_RX_CN_LOW, NET_RX_CN_MOD and NET_RX_CN_HIGH would complete it. > Would it possibe to make the return sematics of the varios > layer-boundary-crossing methods conssitent ore are they just to > different? Doesnt sound like a bad idea. Maybe Davem and/or Alexey and/or Andi can comment. > There is currently no agreement among the different > protocol implementations. Many of them use a boolean return value for > reporting whether delivering to upper/lower layer was sucessful. > But there is unfortunatly no unique convention whether 1 means success > or failure. I think the initial idea with the transmit path (not sure how alive the idea is) was to propagate the return codes from the link layer all the way to the protocol layer. For example it would help TCP to know of NET_TXMIT_DROP to maybe doing something smarter than go into a FR or an RTO. > > I´ll be leaving for Linux-Kongress. Thus, I won´t be able to > further contribute to this thread for this week. What kind of Linux conference gives you no access to the internet? ;-> cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG] network problems in 2.4 series
Hello, I have a program that makes HTTP requests in a loop to a box runing Linux. It goes through another Linux box, which is using proxy ARP and is connected to the client and the web server using a cross over cable [CLIENT][PROXY][WEBSERVER] When the proxy machine uses 2.2 series kernel, I see a certain bit rate, call it X. X stays constant always, no matter how many times I run my workload. When I upgraded to 2.4-test8, I see the following behavior: Initial run (fresh boot) I see a speed greater than X (4X) subsequent runs, the bit rate keeps dropping and becomes 1/3X! The only way to get back the first bit rate is to reboot! Please some one tell me if this issue will be resolved. Thanks Lee __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NMI Watchdog detected LOCKUP on CPU1 (stext_lock)(2.4.0-test9-pre2)
Dave, I did a rpm -rebuild egcs rpm -rebuild glibc ldconfig ldconfig and it went away. I reinstalled a clean Open Linux 2.4 and just did ldconfig ldconfig without rebuilding and it went also went away, so I don't think rebuilding had much to do with it. I did spend any time looking further into it. One issue with this is that the jump into the spinning code will always be a long jump since these segments end up where ever the linker feels like emitting them. Inlinging the spining code to less than a 512 byte boundry would make the long jump into a short jump and speed things up. I've also noticed that the linker does not always align them on 16 bytes boudries (which is what Intel likes to see for speed). All assembler functions in NetWare are always preceeded with an 'align 16' directive and this does increase execution speed -- something to think about... :-) Jeff - Original Message - From: "David S. Miller" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, September 19, 2000 7:41 PM Subject: Re: NMI Watchdog detected LOCKUP on CPU1 (stext_lock)(2.4.0-test9-pre2) >Date: Tue, 19 Sep 2000 19:44:30 -0600 >From: "Jeff V. Merkey" <[EMAIL PROTECTED]> > >It does not seem to be saving any memory space doing it this way, >since I've noticed tons of these little segments all over the >place. > > None of them can be eliminated because each one branches back to a > unique PC. > > This independant of whatever linker bug you were running into. > > Later, > David S. Miller > [EMAIL PROTECTED] > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NMI Watchdog detected LOCKUP on CPU1 (stext_lock)(2.4.0-test9-pre2)
Date:Tue, 19 Sep 2000 19:44:30 -0600 From: "Jeff V. Merkey" <[EMAIL PROTECTED]> It does not seem to be saving any memory space doing it this way, since I've noticed tons of these little segments all over the place. None of them can be eliminated because each one branches back to a unique PC. This independant of whatever linker bug you were running into. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: networking todo, was Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 06:13:38PM -0700, David S. Miller wrote:
>Date: Wed, 20 Sep 2000 03:14:10 +0200
>From: "Andi Kleen" <[EMAIL PROTECTED]>
>
>The ipid handling is still fishy, it will break when you talk to
>more destinations than the inetpeer cache can take (I fixed it in
>my local tree with the appended patch)
>
> I don't like this change, please work with Alexey on this one.
What do you dislike ? Stateless ipid looks much nicer to me than stateful
one (and the "security" lost by not refetching the secret is minimal,
especially given the state of the random device on machines without diskio
and keyboard input)
>Receiver side SMP reordering is still there, but I'm not sure if it is
>fixable (but it'll surely hit people that cannot use Linux senders, I
>just see the reports)
>
> Reordering is a non-issue for ipv4/ipv6, all of the massive TCP input
> rewrite was strictly about dealing with this. No SMP reordering
> should cause any bogus fast retransmits etc. for example.
You mean TCP output rewrite ? The fix was strictly sender side only
(I first thought one of the ack changes alexey did was an attempt at a
hackish receiver side solution, but he told me that was false)
> What is the problem? Are you referering to the LAPB/X25 stuff?
When you have a non linux 2.4 sender you lose.
>The TCP connect running out of ports problem is still there (I
>fixed it locally, but the changes are probably far too extensive
>for 2.4.x now)
>
> I think people can change their ip_local_port_range and I really
> consider this a non-issue, at least, it's not a 2.4.x show stopper.
I agree.
>
>The TCP ISN computation is not SMP safe.
>
> "Big deal". So how much effort will you go to to get how much more
> protection and how much of it do we really need? How less secure are
> our TCP ISN's because of this? Not a show-stopper.
>
> I think you're reading too much tcp-impl :-)
No, it has nothing to do with tcp-impl ;), I discovered it while playing
with the ipids much earlier. With some bad luck could could get very similar
ISNs, which is probably bad (an easy fix is to do the secret hash with a
stack copy instead of the static)
(but it is not a show stopper I agree)
>
>include/linux/snmp.h is probably still not properly aligned for all
>cache line sizes.
>
> Read, and reread what Alexey tries to tell you over and over about
> this. It is not meant to be cache line aligned, it is meant to be a
> power of two and nothing more.
It has to be at least cache line aligned, otherwise the arrays wouldn't
make any sense at all, the power of two would just be a (imho misguided but
anyways) optimization.
When I count correctly sizeof(udp_mib) is 16 bytes currently (lots of
false sharing on 32/64byte cacheline sized architectures) and linux_mib
is 288 bytes currently (does not make any sense at all)
>UDP recvmsg error handling for csum errors is bogus (fix pending)
>
> Ok, send me a patch so I can see what the problem is.
Appended.
>
>I also would like to remove the inetpeer cache code before 2.4.0, now
>that nobody managed to salvage tw recycling and ipid can do without it.
>
> I would prefer not to, it seems to be too potentially destabilizing
> for questionable and unknown gain (ie. we don't know if tw recycling
> can be salvaged, so lets not take any changes).
The "unknown gain" is just removing a lot of complexity => speed and less
bugs.
The only advantage I know left is saving pmtus for a bit longer, but
I doubt it is worth the complexity.
Do you have any specific plan for salvaging tw recycling ? Just keeping
such an intrusive piece of code for benchmarks around looks wasteful
to me.
-Andi
Index: net/ipv4/udp.c
===
RCS file: /cvs/linux/net/ipv4/udp.c,v
retrieving revision 1.85
diff -u -u -d -r1.85 udp.c
--- net/ipv4/udp.c 2000/08/09 11:59:04 1.85
+++ net/ipv4/udp.c 2000/09/17 11:55:29
@@ -493,8 +493,6 @@
if (usin->sin_family != AF_INET) {
if (usin->sin_family != AF_UNSPEC)
return -EINVAL;
- if (net_ratelimit())
- printk("Remind Kuznetsov, he has to repair %s
eventually\n", current->comm);
}
ufh.daddr = usin->sin_addr.s_addr;
@@ -678,6 +676,8 @@
if (flags & MSG_ERRQUEUE)
return ip_recv_error(sk, msg, len);
+
+ retry:
/*
* From here the generic datagram does a lot of the work. Come
* the finished NET3, it will do _ALL_ the work!
@@ -733,26 +733,21 @@
csum_copy_err:
UDP_INC_STATS_BH(UdpInErrors);
- /* Clear queue. */
- if (flags&MSG_PEEK) {
- int clear = 0;
+ if (flags&(MSG_PEEK|MSG_DONTWAIT)) {
+ struct sk_buff *skb2;
+
spin_lock_irq(&sk->receive
Re: Question: Using floating point in the kernel
Hello, You cannot use MMX registers in the kernel either, since the kernel doesen't save and restore FX state (fxsave, fxrstor) either (just like (fsave/frstor). Best Wishes, Lyle ** Reply to message from "Richard B. Johnson" <[EMAIL PROTECTED]> on Tue, 19 Sep 2000 11:58:34 -0400 (EDT) >Tell the driver maintainer that you found a BUG. There is no floating- >point allowed in the kernel because the state of the FP Unit is >undefined in the kernel. If you 'define' it, i.e., `finit` then you >will mess up somebody who was using the FP Unit in user-mode. > >Also, the '386 FP emulation, which is still supported, can produce a >double-fault if you try to use it (at some places) in kernel-mode >code. > >Basically, there is nothing in the kernel that will ever require >floating point. Use fixed point if you need 'decimals' and stuff for >printing. What about MMX? It uses floating point registers, but it's not technically floating point. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NMI Watchdog detected LOCKUP on CPU1 (stext_lock)(2.4.0-test9-pre2)
Keith, I've seen a some problems with the way Linus (or whoever) did this. I had a bug I worked on for 5 weeks related to the buggy 2.7 gcc linker on Caldera Linux 2.4 that would for whatever reason fail to fixup all the .test.lock code sections in a file (probably because there were so many of them). It does not seem to be saving any memory space doing it this way, since I've noticed tons of these little segments all over the place. I've seen a bug related to glibc and gcc on Caldera 2.4 with this locking model, i.e. I saw 50+ references in a code section, with only 33 of them getting fixed up, so you might want to check if this person has mixed and matched gcc and glibc versions, and perhaps the linker is barfing or something. :-) Jeff Keith Owens wrote: > > On Tue, 19 Sep 2000 19:53:19 +0200, > Jorge Nerin <[EMAIL PROTECTED]> wrote: > >All the traces end up in stext_lock, so I think it' the same bug > >>>EIP; c01df3aa<= > >Trace; c015db32 > >Trace; c015dd03 > >Trace; c0136149 > >Trace; c01363fd > >Trace; c01079bb > >Code; c01df3aa > > <_EIP>: > >Code; c01df3aa<= > > 0: f3 90 repz nop<= > >Code; c01df3ac > > 2: 7e f5 jlefff9 <_EIP+0xfff9> > >c01df3a3 > >Code; c01df3ae > > 4: e9 a6 da f7 ffjmpfff7daaf <_EIP+0xfff7daaf> > >c015ce59 > > Just because the traces end up in stext_lock does not mean that they > are the same bug. Locks are optimized for pipeline performance, the > code for "got the lock" is in the main text section, the code for > "cannot get lock, need to wait" is moved to a separate text section. > That way only the failure case gets pipeline stalls. > > The downside of this optimization is that all code that is waiting for > a lock appears to be in the out of line section and the only label in > that section is right at the start. So all lock code appears to be in > stext_lock. What really matters is where the stext_lock code jumps > back to, that tells you which code is waiting for the lock. In this > case you have jumps back to blk_get_queue+9/60 so it is waiting on > io_request_lock. Now all you have to do is work out who is holding > onto io_request_lock. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops with K6-2 350, but not with other CPUs.
On Tue, 19 Sep 2000, Horst von Brand wrote: > Random crashes is usually a hardware problem: Bad RAM, overheated CPU, > overclocking, ... Yeah it probably is a dud CPU, but I'm just trying to be optimistic. :) I've tried two other CPUs and they work fine, so it's definitely the CPU that's the problem. I'll try a K6-2 500 this week just to make sure. The CPU runs just under 30C so heat isn't a problem, and it's not overclocked. I tried it at 392MHz a couple of years ago when I first got it, but that was unstable so it went back to 350MHz pretty quickly. I've run heaps of CPU intensive stuff with Win 95 since then, like Longbow II, with no crashes at all. Last week I ran memtest86 for a day with no errors at all, and on the weekend I ran a windows 95 based cpu tester (I forget the name) that ran for 20 hours no problems. It is strange that these things have no problems, yet idle linux crashes, that's the bit I don't understand. Thanks, Daniel. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NMI Watchdog detected LOCKUP on CPU1 (stext_lock)(2.4.0-test9-pre2)
On Tue, 19 Sep 2000 19:53:19 +0200, Jorge Nerin <[EMAIL PROTECTED]> wrote: >All the traces end up in stext_lock, so I think it' the same bug >>>EIP; c01df3aa<= >Trace; c015db32 >Trace; c015dd03 >Trace; c0136149 >Trace; c01363fd >Trace; c01079bb >Code; c01df3aa > <_EIP>: >Code; c01df3aa<= > 0: f3 90 repz nop<= >Code; c01df3ac > 2: 7e f5 jlefff9 <_EIP+0xfff9> >c01df3a3 >Code; c01df3ae > 4: e9 a6 da f7 ffjmpfff7daaf <_EIP+0xfff7daaf> >c015ce59 Just because the traces end up in stext_lock does not mean that they are the same bug. Locks are optimized for pipeline performance, the code for "got the lock" is in the main text section, the code for "cannot get lock, need to wait" is moved to a separate text section. That way only the failure case gets pipeline stalls. The downside of this optimization is that all code that is waiting for a lock appears to be in the out of line section and the only label in that section is right at the start. So all lock code appears to be in stext_lock. What really matters is where the stext_lock code jumps back to, that tells you which code is waiting for the lock. In this case you have jumps back to blk_get_queue+9/60 so it is waiting on io_request_lock. Now all you have to do is work out who is holding onto io_request_lock. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
remap_page_range, frame buffer, MIPS - mmap problem
Hello. I am trying to mmap a frame buffer device (which I wrote) and it doesn't seem to work. I verified the address - it appears OK. However, whatever I write out to the address from my userland program, the bits appear to go into the bit bucket. I am trying to figure out remap_page_range; what is the value of pgprot_t supposed to be? It appears to be set to: _PAGE_PRESENT | _PAGE_READ | _PAGE_WRITE | _CACHE_UNCACHED (printed value, 0x407). Any idea why this wouldn't work? I am not too familiar with MIPS so I don't know what a reasonable value should be for pgprot_t. Thanks, Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: networking todo, was Re: Linux-2.4.0-test9-pre2
Date: Wed, 20 Sep 2000 03:14:10 +0200 From: "Andi Kleen" <[EMAIL PROTECTED]> The ipid handling is still fishy, it will break when you talk to more destinations than the inetpeer cache can take (I fixed it in my local tree with the appended patch) I don't like this change, please work with Alexey on this one. Do not assume we are removing the inetpeer cache also, see below. Receiver side SMP reordering is still there, but I'm not sure if it is fixable (but it'll surely hit people that cannot use Linux senders, I just see the reports) Reordering is a non-issue for ipv4/ipv6, all of the massive TCP input rewrite was strictly about dealing with this. No SMP reordering should cause any bogus fast retransmits etc. for example. What is the problem? Are you referering to the LAPB/X25 stuff? The TCP connect running out of ports problem is still there (I fixed it locally, but the changes are probably far too extensive for 2.4.x now) I think people can change their ip_local_port_range and I really consider this a non-issue, at least, it's not a 2.4.x show stopper. The TCP ISN computation is not SMP safe. "Big deal". So how much effort will you go to to get how much more protection and how much of it do we really need? How less secure are our TCP ISN's because of this? Not a show-stopper. I think you're reading too much tcp-impl :-) include/linux/snmp.h is probably still not properly aligned for all cache line sizes. Read, and reread what Alexey tries to tell you over and over about this. It is not meant to be cache line aligned, it is meant to be a power of two and nothing more. Not a bug. UDP recvmsg error handling for csum errors is bogus (fix pending) Ok, send me a patch so I can see what the problem is. I also would like to remove the inetpeer cache code before 2.4.0, now that nobody managed to salvage tw recycling and ipid can do without it. I would prefer not to, it seems to be too potentially destabilizing for questionable and unknown gain (ie. we don't know if tw recycling can be salvaged, so lets not take any changes). Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
networking todo, was Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 05:14:39PM -0700, David S. Miller wrote:
> And hey, guess what, as a result of this right now my "non-driver
> caused" core/ipv4/ipv6 networking bug list is pretty much empty right
> now. Only a few netfilter glitches appear to remain.
Some items for your list:
The ipid handling is still fishy, it will break when you talk to more
destinations than the inetpeer cache can take (I fixed it in my local
tree with the appended patch)
Receiver side SMP reordering is still there, but I'm not sure if it is
fixable (but it'll surely hit people that cannot use Linux senders, I
just see the reports)
The TCP connect running out of ports problem is still there (I fixed it
locally, but the changes are probably far too extensive for 2.4.x now)
The TCP ISN computation is not SMP safe.
include/linux/snmp.h is probably still not properly aligned for all
cache line sizes.
UDP recvmsg error handling for csum errors is bogus (fix pending)
net/ipv6/route.c:struct rt6_info ip6_null_entry initialisation seems
to be out of date (fix pending)
I also would like to remove the inetpeer cache code before 2.4.0, now
that nobody managed to salvage tw recycling and ipid can do without it.
-Andi
Index: drivers/char/random.c
===
RCS file: /cvs/linux/drivers/char/random.c,v
retrieving revision 1.47
diff -u -u -d -r1.47 random.c
--- drivers/char/random.c 2000/07/26 01:03:56 1.47
+++ drivers/char/random.c 2000/09/17 11:55:03
@@ -1994,6 +1994,13 @@
#define REKEY_INTERVAL 300
#define HASH_BITS 24
+/* Most of the following procedures have SMP races, which are mostly harmless
+ (it is possible that you get duplicated ISNs/or non monotonic IDs with some bad
+ luck)
+ You should definitely make sure that only start sending packets _after_
+ the random pool has been restored from disk.
+*/
+
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
__u32 secure_tcpv6_sequence_number(__u32 *saddr, __u32 *daddr,
__u16 sport, __u16 dport)
@@ -2099,24 +2106,22 @@
#endif
return seq;
}
+__u16 ip_id_counter;
/* The code below is shamelessly stolen from secure_tcp_sequence_number().
* All blames to Andrey V. Savochkin <[EMAIL PROTECTED]>.
+ * Changed by Andi Kleen to never rekey (blames to him now)
+ * Should be inlined.
*/
__u32 secure_ip_id(__u32 daddr)
{
- static time_t rekey_time = 0;
- static __u32secret[12];
- time_t t;
-
- /*
-* Pick a random secret every REKEY_INTERVAL seconds.
-*/
- t = CURRENT_TIME;
- if (!rekey_time || (t - rekey_time) > REKEY_INTERVAL) {
- rekey_time = t;
- /* First word is overwritten below. */
- get_random_bytes(secret+1, sizeof(secret)-4);
+ static __u32 ip_id_secret[12];
+ static int init;
+
+ if (!init) {
+ get_random_bytes(ip_id_secret+1, sizeof(ip_id_secret)-4);
+ get_random_bytes(&ip_id_counter, 2);
+ init = 1;
}
/*
@@ -2127,9 +2132,9 @@
* hashing fixed data into it isn't going to improve anything,
* so we should get started with the variable data.
*/
- secret[0]=daddr;
+ ip_id_secret[0]=daddr;
- return halfMD4Transform(secret+8, secret);
+ return halfMD4Transform(ip_id_secret+8, ip_id_secret);
}
#ifdef CONFIG_SYN_COOKIES
Index: include/linux/random.h
===
RCS file: /cvs/linux/include/linux/random.h,v
retrieving revision 1.12
diff -u -u -d -r1.12 random.h
--- include/linux/random.h 2000/01/29 07:39:40 1.12
+++ include/linux/random.h 2000/09/17 11:55:09
@@ -56,6 +56,8 @@
extern void get_random_bytes(void *buf, int nbytes);
void generate_random_uuid(unsigned char uuid_out[16]);
+extern __u16 ip_id_counter;
+
extern __u32 secure_ip_id(__u32 daddr);
extern __u32 secure_tcp_sequence_number(__u32 saddr, __u32 daddr,
__u16 sport, __u16 dport);
Index: include/net/dst.h
===
RCS file: /cvs/linux/include/net/dst.h,v
retrieving revision 1.20
diff -u -u -d -r1.20 dst.h
--- include/net/dst.h 2000/08/09 11:59:03 1.20
+++ include/net/dst.h 2000/09/17 11:55:09
@@ -45,6 +45,7 @@
unsignedcwnd;
unsignedadvmss;
unsignedreordering;
+ unsignedidbase;
unsigned long rate_last; /* rate limiting for ICMP */
unsigned long rate_tokens;
Index: include/net/ip.h
===
RCS file: /cvs/linux/include/net/ip.h,v
retrieving revision 1.38
diff -u -u -d -r1.38 ip.h
--- include/net/ip.h2000/07/07 22:29:42 1.38
+++ include/
Re: Oops with K6-2 350, but not with other CPUs.
On Tue, 19 Sep 2000, Matthias Andree wrote: > Do you have the chance to borrow another of those K6-2s, possibly faster > ones (if your board supports those)? Is the case in a proper state (has > never been dropped, all perpendicular and so on)? A K6-2 500 has become available for me to try, won't be able to test it until Thursday night, but will definitely do that. > I finally found out that the PCI cards were not seated properly, so I > unmounted everything, straightened the case, and fitted everything back > in - never had any further difficulties since then. I reseated all the cards a few times during my initial testing, no difference. Also, when I tried the Cyrix CPUs, the only things that got changed were the CPU and jumper settings, and it all worked fine. The case and components have never been dropped or damaged. > Is there any third-party Kernel module involved? No. > ... I'm not a native speaker ... Your english is great. :) Thanks for the suggestions, Daniel. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: get_tty_baud_rate() on sparc64
Date:Tue, 19 Sep 2000 13:59:53 +0200 From: Florian Lohoff <[EMAIL PROTECTED]> while porting a serial multiport driver to sparc64 i disovered that the function get_tty_baud_rate() only returns 50 or 75 Baud for 57600 and 115200 which is *aehm* not what i expected. Is this something i made wrong when setting up something or is it another "Sparc[64] is different" issue ? There is a bug in the Sparc headerfiles for the baud rate ioctls, the kernel headers didn't match the userland headers under /usr/include/bits. Just fix the CBAUD etc. defines in /usr/include/bits/termios.h to match the include/asm-sparc/termios.h values and it should be fine. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Freezes with test9-pre4 + mmap002
"Juan J. Quintela" wrote: > > Hi > while I am running mmap002 in test9-pre4 I got the computer > frozen, it don't answer to my open windows anymore, it answers > only to pings. I have got the attached traces. The machine > is SMP with IDE disks. I run from command line. No X-windows. UP (= not SMP nor UP specific) with IDE disks. (got the same problem with test9-pre2, upgraded and retested) > > I had no additional/local patches applied. Me too. As I reported earlier it looks like pages are ping ponged between Active and inactive_dirty (the sum is always the same!) inactive_clean is zero (always) slab contains very few pages. Hope this info helps. /RogerL -- Home page: http://www.norran.net/nra02596/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
Date: Tue, 19 Sep 2000 18:07:20 -0600 From: Cort Dougan <[EMAIL PROTECTED]> Do you really think that's forcing people to concentrate of fixing bugs? Tell me if you disagree, I'd like to understand how you see that. I see that 2.4 is getting all kinds of changes merged in that should be going on with 2.5. The recent VM changes have left us with deadlocks that we didn't have before. Shouldn't that have gone into 2.5 not 2.4? The VM performance in 2.4.x was a major regression from 2.2.x and is required to be fixed for 2.4.0 release. Riel did the bulk of this work, and it's now just dealing with a few remaining details on very low memory systems. His changes fixed a major problem, and structurally I believe his changes are completely sound and were justifiably included in 2.4.x. So I think this was a bad example. I'll say this much, if 2.5.x existed I'd be spending most of my time on a clean zero-copy TCP framework instead of walking over the net stack and sparc64 code verifying things every day, that is for sure. So yes, I am really thinking that it is forcing people to concentrate on fixing bugs, because at least it is doing so for me. I know that the faster 2.4.x happens the faster the "fun" 2.5.x stuff comes along. And hey, guess what, as a result of this right now my "non-driver caused" core/ipv4/ipv6 networking bug list is pretty much empty right now. Only a few netfilter glitches appear to remain. And hey, if you want the real proof, believe that even Alexey Kuznetsov has not worked on a new feature in nearly 2 months. :-)) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
On Wed, Sep 20, 2000 at 01:58:32AM +0200, Martin Dalecki wrote:
> Andrea Arcangeli wrote:
> >
> > On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
> > > Better would be to use statement blocks like
> > > #define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
> >
> > Agreed.
>
> Not agreed. In this case older version of GCC will have
> almost exactly the same provlems as with functions.
If they had they wouldn't be able to compile the linux kernel
anyways (e.g. read asm-i386/uaccess.h)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
On Wed, Sep 20, 2000 at 01:55:58AM +0200, Martin Dalecki wrote: > The GCC manual doesn't lie on that ANY LONGER with respect to EGCS. > And we should adpat for the modern versions of the compiler instead > of dragging the *ugly* code with us until the earth stops spinning, iff > the only concern is performance. Check your facts. g++-current (3.0 to be) has a new early inliner which apparently generates better code for some stuff (and worse for other). The C frontend so far still does the inlining too late (in RTL instead of trees) which causes all the code generation problems. I don't know if the C frontend will gain the new inliner too before 3.0 (there seems to be some work on that), but gcc 3 is many months away so Linux kernel cannot count on it. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
}Date: Tue, 19 Sep 2000 16:49:00 -0600 }From: Cort Dougan <[EMAIL PROTECTED]> } }If anyone else wants access to the 2.5 tree we have as a place to }keep experimental changes I'm happy to open it up to the outside. } } Well, let's first step back for a second and really think about } what is being said here: } } 1) 2.4.x is taking too long } } 2) We have this backlog of new PPC features people are writing, }I can't put them into the 2.4.x tree, but I don't want to lose }them either. } } 3) So I've made a 2.5.x tree so the experimental stuff can occur }somewhere. My PPC guys want to change things. I can't stop them, but I can prevent them from screwing with 2.4 which needs to stay stable. If they don't wan to fix bugs in 2.4 then I can't force them to. They don't work for me, and I don't work for anyone who cares about PPC. So I'm not going to put a great deal of effort into forcing them to them to do something they don't want to. I've effectively kept them from making 2.4 unstable on PPC. That's a good thing, I think. I've also given them a place to do their experimentation before it becomes safe. Once it does, I can move it into 2.4 or wait for 2.5 if the changes don't become stable. } The _whole reason_ 2.5.x isn't started is so that people concentrate } on stabilizing 2.4.x instead of working on new stuff. Why not just } tell these people "why are you working on experimental stuff, put } together PPC stress test and kernel regression suites if you are } bored, because we know 2.4.x isn't read for prime time" Do you really think that's forcing people to concentrate of fixing bugs? Tell me if you disagree, I'd like to understand how you see that. I see that 2.4 is getting all kinds of changes merged in that should be going on with 2.5. The recent VM changes have left us with deadlocks that we didn't have before. Shouldn't that have gone into 2.5 not 2.4? I agree with the idea of getting people to concentrate on stabilizing 2.4. Some people want to work on other things, though. I'd like to give them a place to make their experimental changes outside of a stable tree. There's no place to do that. Instead, we get experimental changes in 2.4 and a buggy 2.4. } You cannot complain about 2.4.x not being timely if you are doing } things which directly encourage folks to not work on 2.4.x at all. } Right? What I've done has kept PPC-specific parts of 2.4 from becoming a mess of bugs. I've also allowed people to do their experimentation somewhere else, that won't break 2.4. Do you think that's wrong? Do you think I should have done it differently? If so, tell me how. I'm open to changing the way things work. If you'd suggest I just "make" people fix 2.4 then I suggest you do it, then tell me how. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
On Wed, Sep 20, 2000 at 01:58:32AM +0200, Martin Dalecki wrote: > Not agreed. In this case older version of GCC will have > almost exactly the same provlems as with functions. I guess the object was to remove the mistake-prone side effects anyway... Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
Date: Wed, 20 Sep 2000 01:58:32 +0200 From: Martin Dalecki <[EMAIL PROTECTED]> Andrea Arcangeli wrote: > Agreed. Not agreed. In this case older version of GCC will have almost exactly the same provlems as with functions. Care to show an example? I do not believe this is true. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
Andrea Arcangeli wrote:
>
> On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
> > Better would be to use statement blocks like
> > #define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
>
> Agreed.
Not agreed. In this case older version of GCC will have
almost exactly the same provlems as with functions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: An elevator algorithm (patch)
On Tue, Sep 19 2000, Andrea Arcangeli wrote: > > 7[3] 8[2] 9[1] 10[0] 3[3] 4[2] 5[1] 6[0] 1[3] 2[2] > p > With point `p' I mean the request after last barrier in the queue. Ah, I suspected we were talking past each other. > Then when we try to insert 99 it goes here: > > 100[0] 102[3] 103[3] 104[3] 99[3] > p > > So we have two low peaks in the not starving queue and we should move the p > to the latest on the right. Ok good, I've read Peter's patch now. Looks good, I've put it in my tree as well and will do some testing. > Also we should make different cases in function of what p->prev is > (barrier/head/real_head/normalreq). > > I don't think it's worthwhile (even with the current algorithm where it's easy > to account for p). I suspect you are right, it's marginal. -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
On Tue, 19 Sep 2000, Linus Torvalds wrote: > > > On Tue, 19 Sep 2000, David S. Miller wrote: > > > > Would you mind taking a look at the difference in code output when > > register pressure in a given function is moderate to high? :-) > > Immaterial. > > If somebody cares about performance, they'd just better create the proper > architecture-specific macros. > > Correctness first. Well, Andi's variant with statement expression looks like a decent compromise - it's gccism, indeed, but IIRC it was on the list of approved extensions. I would go with it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
Andi Kleen wrote:
>
> On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> > Nice spotting, but bad fix, IMO. swab...() stuff is a perfect example of
> > the dangerous use of macros. BTW, 2.4 has the same problem.
>
> inlines usually generate worse code than macros (the gcc manual lies on that),
> e.g. the register allocation is usually worse and CSE doesn't work that well.
> Normally it makes not that much difference, but these macros are rather
> performance critical.
The GCC manual doesn't lie on that ANY LONGER with respect to EGCS.
And we should adpat for the modern versions of the compiler instead
of dragging the *ugly* code with us until the earth stops spinning, iff
the only concern is performance.
>
> Better would be to use statement blocks like
> #define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
>
> I would prefer to fix the callers anyways, because it is clearer this way.
>
> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
- phone: +49 214 8656 283
- job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort:
ru_RU.KOI8-R
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.9.2: export ethtool interface
On Tue, 19 Sep 2000, Andrew Morton wrote: > > This patch, against 2.4.0-test9-pre2, moves ethtool.h from the private > > domain of the sparc ports into include/linux. This publishes an ... > This is good. It would be useful to have this in place ASAP so driver > authors have something to look at and to work against. You all know my opinion on this interface: it is bad. > * I added SUPPORTED_MAC_FLOWCTRL/ADVERTISED_MAC_FLOWCTRL for advertising > of 802.3x MAC-layer flow control. There are two elements of this: Rx and Tx flow control. We might support Rx flow control, but not generate flow control packets. Or perhaps the inverse. > * There don't seem to be enough port types and transceiver types. > 10base2? BNC? 100baseTx/100baseFX? 1Mbps HomePNA? 10Mbps HomePNA? (Check the control words for the PNA spec.) Various 802.11? 10Gb Ethernet? Have you looked at gigabit autonegotiation? If you are proposing a new interface (and obviously tossing the existing MII-MDIO emulation that has existed for a few years) you should at least support current hardware. Donald Becker [EMAIL PROTECTED] Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Beowulf-II Cluster Distribution Annapolis MD 21403 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Freezes with test9-pre4 + mmap002
Hi while I am running mmap002 in test9-pre4 I got the computer frozen, it don't answer to my open windows anymore, it answers only to pings. I have got the attached traces. The machine is SMP with IDE disks. I had no additional/local patches applied. This traces came form kdb, but when I run without kdb, SysRq + P shows always one EIP that is inside default_idle. I got that freeze in the first run of mmap002. (I have got the freeze in test8+riel patches. At that point they happened only sometimes and I was not able to reproduce without local patches applied, that is the reason that I haven't reported them here before. I reported then to Rik anyway). I am investigating further here, but any comment/patch is welcome :))) Later, Juan. EBP EIP Function(args) 0x0008e000 0xc010719d default_idle+0x2d kernel .text 0xc010 0xc0107170 0xc01071a4 0xc0107202 cpu_idle+0x3e kernel .text 0xc010 0xc01071c4 0xc0107218 and 0xc010719d default_idle+0x2d (0x0, 0x0) kernel .text 0xc010 0xc0107170 0xc01071a4 0xc0107202 cpu_idle+0x3e (0xc02b2d20, 0xc02c25e0, 0xc02a9800, 0x0, 0x 0) kernel .text 0xc010 0xc01071c4 0xc0107218 0xc01199bc do_softirq+0x5c kernel .text 0xc010 0xc0119960 0xc01199ec 0xc010ab75 do_IRQ+0xe5 kernel .text 0xc010 0xc010aa90 0xc010ab84 -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
Date:Tue, 19 Sep 2000 16:49:00 -0600 From: Cort Dougan <[EMAIL PROTECTED]> If anyone else wants access to the 2.5 tree we have as a place to keep experimental changes I'm happy to open it up to the outside. Well, let's first step back for a second and really think about what is being said here: 1) 2.4.x is taking too long 2) We have this backlog of new PPC features people are writing, I can't put them into the 2.4.x tree, but I don't want to lose them either. 3) So I've made a 2.5.x tree so the experimental stuff can occur somewhere. The _whole reason_ 2.5.x isn't started is so that people concentrate on stabilizing 2.4.x instead of working on new stuff. Why not just tell these people "why are you working on experimental stuff, put together PPC stress test and kernel regression suites if you are bored, because we know 2.4.x isn't read for prime time" You cannot complain about 2.4.x not being timely if you are doing things which directly encourage folks to not work on 2.4.x at all. Right? Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
On Wed, 20 Sep 2000, Andrea Arcangeli wrote:
> On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> > +static inline __u16 ___swab16(__u16 x)
> > +{
> > + return ((x & (__u16)0x00ffU) << 8) | ((x & (__u16)0xff00U) >> 8);
> > +}
> > +static inline __u32 ___swab16(__u32 x)
> ^
> > +{
> > + return ((x & (__u32)0x00ffUL) << 24) |
> > + ((x & (__u32)0xff00UL) << 8) |
> > + ((x & (__u32)0x00ffUL) >> 8) |
> > + ((x & (__u32)0xff00UL) >> 24);
> > +}
> > +static inline __u64 ___swab16(__u64 x)
Ouch!
Sorry about that, folks - ___swab32 and ___swab64, indeed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
On Wed, 20 Sep 2000, Andi Kleen wrote:
> On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> > Nice spotting, but bad fix, IMO. swab...() stuff is a perfect example of
> > the dangerous use of macros. BTW, 2.4 has the same problem.
>
> inlines usually generate worse code than macros (the gcc manual lies on that),
> e.g. the register allocation is usually worse and CSE doesn't work that well.
> Normally it makes not that much difference, but these macros are rather
> performance critical.
>
> Better would be to use statement blocks like
> #define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
Fine with me.
> I would prefer to fix the callers anyways, because it is clearer this way.
... and grep for that sort of stuff after every new release? That's
exactly the sort of bug that _will_ come back to haunt us, again and
again.
If it looks like a function - it should act like one. Every exception
turned out to be a source of recurring bugs. And it _does_ look like
a function - not even all-caps in the names of derived macros.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
> Better would be to use statement blocks like
> #define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
Agreed.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> +static inline __u16 ___swab16(__u16 x)
> +{
> + return ((x & (__u16)0x00ffU) << 8) | ((x & (__u16)0xff00U) >> 8);
> +}
> +static inline __u32 ___swab16(__u32 x)
^
> +{
> + return ((x & (__u32)0x00ffUL) << 24) |
> + ((x & (__u32)0xff00UL) << 8) |
> + ((x & (__u32)0x00ffUL) >> 8) |
> + ((x & (__u32)0xff00UL) >> 24);
> +}
> +static inline __u64 ___swab16(__u64 x)
^
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
} Cort Dougan writes: } > I've had to create a 2.5 for the PPC tree so we aren't stuck with either no } > experimentation or experimentation in the stable trees. } } Well, you're not alone. There's a lot going on in the ARM side of Linux } which looks very promising; yes it is true that ARM is not the fastest } or the most optimal processor that Linux runs on, but there is a lot of } people who want to run it, both from the individual and the commercial } circles. } } As such, the ARM hardware that Linux now runs on is, ahem, quite varied, } and new hardware is coming along at an astounding rate - currently its } about one a week for the past 4 months (looking at the rate at which the } requests for architecture numbers come into my automated system). } } So yes, you can say that I'm probably in the same boat as you are as an } architecture maintainer, albeit I've currently got a little more room } to move for the time being. } } Maybe someone ought to kick off a 2.5 kernel series now, so that there's } somewhere for all these features to go (and I don't mean a private 2.5 } tree). This can then be handed (maybe piecemeal) to Linus? Maybe we can } use a version number like 2.5.0-u1 upwards? (u for unofficial, or maybe } even "unoff")? } } The only problem I can see with this (which I believe has been aired before) } is that it will detract from the bug fixing exercise for 2.4, since people } will be more interested in the new features of 2.5 rather than the bugs with } 2.4, but then again, I'd like to be proven wrong. My opinion is that 2.4 bug fixes are less common than unnecessary rewrites of working code that brings about even more instability and delays for a real and stable 2.4. Bitterness leaks out... I have a start to the 2.5 tree for PPC. We're keeping up-to-date with 2.4 changes so when the official 2.5 does come out we can merge our changes into it without too much trouble. I'm only allowing bugfixes into our 2.4 tree now that we have some place to play. If anyone else wants access to the 2.5 tree we have as a place to keep experimental changes I'm happy to open it up to the outside. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
On Tue, 19 Sep 2000, David S. Miller wrote: > > Would you mind taking a look at the difference in code output when > register pressure in a given function is moderate to high? :-) Immaterial. If somebody cares about performance, they'd just better create the proper architecture-specific macros. Correctness first. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
Date:Tue, 19 Sep 2000 19:13:31 -0400 (EDT) From: Alexander Viro <[EMAIL PROTECTED]> Nice spotting, but bad fix, IMO. swab...() stuff is a perfect example of the dangerous use of macros. BTW, 2.4 has the same problem. Would you mind taking a look at the difference in code output when register pressure in a given function is moderate to high? :-) Unfortunately, gcc does not make inline functions as cheap as "macros with type checking". There are extra costs and often the register allocator cannot cope and stuff starts getting spilled to the stack. I agree with you totally from the "dangerous use" standpoint. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> Nice spotting, but bad fix, IMO. swab...() stuff is a perfect example of
> the dangerous use of macros. BTW, 2.4 has the same problem.
inlines usually generate worse code than macros (the gcc manual lies on that),
e.g. the register allocation is usually worse and CSE doesn't work that well.
Normally it makes not that much difference, but these macros are rather
performance critical.
Better would be to use statement blocks like
#define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
I would prefer to fix the callers anyways, because it is clearer this way.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] abuse of macros in swab.h
On Tue, 19 Sep 2000, David S. Miller wrote:
>Date: Wed, 20 Sep 2000 00:50:06 +0200
>From: "Andi Kleen" <[EMAIL PROTECTED]>
>
>This patch fixes an obvious bug introduced with the ext2 changes in
>2.2.18pre (look up the definition of le32_to_cpu on BE machines
>without a special assembler version for it and on machines that
>have it)
>
>--- linux-work/fs/ext2/inode.c-EXT2Fri Sep 15 02:06:16 2000
>+++ linux-work/fs/ext2/inode.c Wed Sep 20 00:47:36 2000
>
>
> Durr, this explains why small bits my home directory disk got
> corrupted while running 2.2.18pre, nice spotting Andi :-)
Nice spotting, but bad fix, IMO. swab...() stuff is a perfect example of
the dangerous use of macros. BTW, 2.4 has the same problem.
How about
--- include/linux/byteorder/swab.h Tue Sep 19 22:23:43 2000
+++ include/linux/byteorder/swab.h.new Tue Sep 19 22:29:07 2000
@@ -13,31 +13,35 @@
* See asm-i386/byteorder.h and suches for examples of how to provide
* architecture-dependent optimized versions
*
+ * They shouldn't be macros, damnit. AV, 2919
+ *
*/
/* casts are necessary for constants, because we never know how for sure
* how U/UL/ULL map to __u16, __u32, __u64. At least not in a portable way.
*/
-#define ___swab16(x) \
- ((__u16)( \
- (((__u16)(x) & (__u16)0x00ffU) << 8) | \
- (((__u16)(x) & (__u16)0xff00U) >> 8) ))
-#define ___swab32(x) \
- ((__u32)( \
- (((__u32)(x) & (__u32)0x00ffUL) << 24) | \
- (((__u32)(x) & (__u32)0xff00UL) << 8) | \
- (((__u32)(x) & (__u32)0x00ffUL) >> 8) | \
- (((__u32)(x) & (__u32)0xff00UL) >> 24) ))
-#define ___swab64(x) \
- ((__u64)( \
- (__u64)(((__u64)(x) & (__u64)0x00ffULL) << 56) | \
- (__u64)(((__u64)(x) & (__u64)0xff00ULL) << 40) | \
- (__u64)(((__u64)(x) & (__u64)0x00ffULL) << 24) | \
- (__u64)(((__u64)(x) & (__u64)0xff00ULL) << 8) | \
- (__u64)(((__u64)(x) & (__u64)0x00ffULL) >> 8) | \
- (__u64)(((__u64)(x) & (__u64)0xff00ULL) >> 24) | \
- (__u64)(((__u64)(x) & (__u64)0x00ffULL) >> 40) | \
- (__u64)(((__u64)(x) & (__u64)0xff00ULL) >> 56) ))
+static inline __u16 ___swab16(__u16 x)
+{
+ return ((x & (__u16)0x00ffU) << 8) | ((x & (__u16)0xff00U) >> 8);
+}
+static inline __u32 ___swab16(__u32 x)
+{
+ return ((x & (__u32)0x00ffUL) << 24) |
+ ((x & (__u32)0xff00UL) << 8) |
+ ((x & (__u32)0x00ffUL) >> 8) |
+ ((x & (__u32)0xff00UL) >> 24);
+}
+static inline __u64 ___swab16(__u64 x)
+{
+ return (__u64)((x & (__u64)0x00ffULL) << 56) |
+ (__u64)((x & (__u64)0xff00ULL) << 40) |
+ (__u64)((x & (__u64)0x00ffULL) << 24) |
+ (__u64)((x & (__u64)0xff00ULL) << 8) |
+ (__u64)((x & (__u64)0x00ffULL) >> 8) |
+ (__u64)((x & (__u64)0xff00ULL) >> 24) |
+ (__u64)((x & (__u64)0x00ffULL) >> 40) |
+ (__u64)((x & (__u64)0xff00ULL) >> 56);
+}
/*
* provide defaults when no architecture-specific optimization is detected
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix big endian ext2 bmap in 2.2.
On Wed, 20 Sep 2000, Andi Kleen wrote:
>
> This patch fixes an obvious bug introduced with the ext2 changes in 2.2.18pre
> (look up the definition of le32_to_cpu on BE machines without a special
> assembler version for it and on machines that have it)
>
> Patch against 2.2.18pre9
Wrong fix. swab32() is the guilty party here - it should be
static inline __u32 swab32(__u32 x)
{
return
((x & (__u32)0x00ffUL) << 24) |
((x & (__u32)0xff00UL) << 8) |
((x & (__u32)0x00ffUL) >> 8) |
((x & (__u32)0xff00UL) >> 24) );
}
Ditto for other stuff in linux/byteorder/swab.h
My fault - I didn't realize that the bloody thing was a macro (it
obviously shouldn't be, exactly due to problems with side effects).
Alan, what do you prefer? I think that fixing the macros in swab.h is the
Right Thing(tm).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix big endian ext2 bmap in 2.2.
Date:Wed, 20 Sep 2000 00:50:06 +0200 From: "Andi Kleen" <[EMAIL PROTECTED]> This patch fixes an obvious bug introduced with the ext2 changes in 2.2.18pre (look up the definition of le32_to_cpu on BE machines without a special assembler version for it and on machines that have it) --- linux-work/fs/ext2/inode.c-EXT2 Fri Sep 15 02:06:16 2000 +++ linux-work/fs/ext2/inode.c Wed Sep 20 00:47:36 2000 Durr, this explains why small bits my home directory disk got corrupted while running 2.2.18pre, nice spotting Andi :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Wed, 20 Sep 2000, Torben Mathiasen wrote: > > I can't seem to find a clean way of getting the drivers outside "drivers/scsi" > to link _after_ the other low-level drivers. My linux Makefile abilities is > limited though, so if someone with the knowledge would do what Eric requests > above please. We will probaly have to move some thing around, and that would be a > _bad_ move at this point I guess. Note that ordering requirements are usually bad requirements. In many cases it's probably best to just fix the problem that causes ordering requirements in the first place. So we don't need to do a "perfect" job on ordering. In fact, we probably want to avoid ordering as much as possible - I'd rather fix the problems that cause us to want to order thing than spending much time trying to order stuff. Some ordering is simple: making sure that newer drivers show up before older drivers that can catch on compatibility stuff. Some other cases are equally obvious: keeping the sort in pretty much the same order as the old hosts.c file just to avoid having peoples disks being re-ordered if somebody has multiple types of SCSI controllers. That's more of a "let's be polite" thing. But let's fix the real problems rather than hit our heads against the ordering wall.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix big endian ext2 bmap in 2.2.
This patch fixes an obvious bug introduced with the ext2 changes in 2.2.18pre (look up the definition of le32_to_cpu on BE machines without a special assembler version for it and on machines that have it) Patch against 2.2.18pre9 -Andi --- linux-work/fs/ext2/inode.c-EXT2 Fri Sep 15 02:06:16 2000 +++ linux-work/fs/ext2/inode.c Wed Sep 20 00:47:36 2000 @@ -215,7 +215,8 @@ bh = bread (inode->i_dev, i, inode->i_sb->s_blocksize); if (!bh) goto fail; - i = le32_to_cpu(((u32 *) bh->b_data)[*++p]); + ++p; + i = le32_to_cpu(((u32 *) bh->b_data)[*p]); brelse (bh); } return i; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
Cort Dougan writes: > I've had to create a 2.5 for the PPC tree so we aren't stuck with either no > experimentation or experimentation in the stable trees. Well, you're not alone. There's a lot going on in the ARM side of Linux which looks very promising; yes it is true that ARM is not the fastest or the most optimal processor that Linux runs on, but there is a lot of people who want to run it, both from the individual and the commercial circles. As such, the ARM hardware that Linux now runs on is, ahem, quite varied, and new hardware is coming along at an astounding rate - currently its about one a week for the past 4 months (looking at the rate at which the requests for architecture numbers come into my automated system). So yes, you can say that I'm probably in the same boat as you are as an architecture maintainer, albeit I've currently got a little more room to move for the time being. Maybe someone ought to kick off a 2.5 kernel series now, so that there's somewhere for all these features to go (and I don't mean a private 2.5 tree). This can then be handed (maybe piecemeal) to Linus? Maybe we can use a version number like 2.5.0-u1 upwards? (u for unofficial, or maybe even "unoff")? The only problem I can see with this (which I believe has been aired before) is that it will detract from the bug fixing exercise for 2.4, since people will be more interested in the new features of 2.5 rather than the bugs with 2.4, but then again, I'd like to be proven wrong. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Tue, Sep 19 2000, Eric Youngdale wrote: > 1) SCSI core. > 2) low-level drivers (in same order as specified in hosts.c). > 3) upper level drivers. > Okay, I've just spent a couple of hours browsing through the scsi code, compiling different configs, and trying to figure out what to do with the Makefile stuff. I can't seem to find a clean way of getting the drivers outside "drivers/scsi" to link _after_ the other low-level drivers. My linux Makefile abilities is limited though, so if someone with the knowledge would do what Eric requests above please. We will probaly have to move some thing around, and that would be a _bad_ move at this point I guess. Now as I see it we have a few things we also need to fix: DMA-POOL: Someone on lkm reported getting low on dma-pool memory when using scsi as builtin. Now Eric, how big is the difference between the two cases (module vs. builtin) in the old scsi code? We use the module case for allocating dma mem now. I guess the module case tries to alloc as little as possible in order to not hit fragmentated mem? INIT: The initialization routines needs to be looked at. Because we use the module stuff, some information gets printed wrong, like "scsi: 0 hosts" scrolling down the screen for each host. I begin to wonder if some of this _really_ is 2.5 stuff. If someone can come up with a clean solution to the Makefile issue, we might pull it off. If we need to move the other scsi drivers (i2o, etc.) around I think we should back off and do it nice and slow for 2.5. In this case we could revert to the point where sd/st/sr are modulized, and saving the core system for 2.5. This is just IMHO, let me know what you think. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Tue, 19 Sep 2000, David Howells <[EMAIL PROTECTED]> wrote: > Daniel Pittman <[EMAIL PROTECTED]> wrote: [...] >> Anyway, why did you see the need for the registry stubs in this case, >> if I may ask? > > Firstly, in wine the registry is handled by the wineserver process. > This means it can be shared between all the wine processes running for > a particular used. So when wine wants to access the registry, it has > to do an RPC call to the wineserver (sending a request across a UNIX > socket and then, I think, a bit of ptrace()'ing to get at the data). > This provides a hopefully more suitable RPC mechanism. *blink* I confess that I can't see that much of a requirement for the ptrace stuff, but I take your word for it. :) > Secondly, the client (wine) just has to issue a syscall that looks > exactly like a Win32 registry function, how it is handled is hidden by > the kernel. Not really something that I would have thought was needed - specifically, the userspace libraries that the process was dynamic linked to would have been the place to do that, I thought. > Thirdly, registry functions should issue system handles, as is done on > Windows. If system handles move into the kernel, then registry handles > should do too. This also means registry change notifications can be > implemented by system handles that WaitFor*() functions can deal with. That, however, is a convincing reason. >> Well... wont the GDI calls be RPC anyway - specifically, across the >> X11 pipe? > > Yes, but if I implement them to go to a GDI server, which then talks > X11 out the back, that's two lots of RPC calls. I can't, in honesty, see why you would want to do them as a GDI server. However, if you did, yes, there would be a high cost. That would be one of the reasons that I, personally, would have avoided that method. > However, what I said about system handles and the registry, may also > apply to GDI objects. IIRC there are not any waitable GHI objects, precisely because under Win32 the GDI is a userspace library that does most of the magic internally and then, finally, requests that the server does something. Like sockets, the GDI isn't actually a Win32 kernel thing, it's a Win32 userspace wrapper that makes the minimalist kernel support more palatable. [...] >> I can't see any sensible reason for implementing anything extra in >> the kernel to support it. Now, adding an X11 protocol extension to >> make some of the Win32 stuff work better... > > Now there's an idea... Have the local X server as an RPC server, > handling wine GDI calls directly *grin*. Then I could hide all the GDI > stuff behind syscall stubs in the same way. This would allow me to > implement a lot of the NT Native API. Well, that's a point of view thing. The native NT API isn't anything beyond kernel32, as such. Certainly, the GDI isn't part of the core API and, in some cases, MicroSoft do release or use the NT core without the GUI system, at the least. Anyhow, I am hardly an expert on the area, but... I would have avoided putting stubs into the kernel anywhere that it was possible and used the userspace dynamic Win32 libraries to do most of the work. OTOH, I would also have implemented the WaitFor* set as a wrapper over select, with the kernel module providing suitable file descriptors for adding to the set that you waited for. We have fairly different views on how this stuff would hang together and, in all likelyhood, mine are based on incorrect assumptions. :) Thanks for answering the questions, Daniel -- "Do you kids think you're going to live forever?" I shouted at the innocents. "Do you think life is some kind of holiday? You think that one day you'll stop being depressed! You won't ever stop being depressed! No matter how much sex you have!" -- Donald Antri, _New Yorker Magazine_, 21/6/1999 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Q: sock output serialization
> "jamal" == jamal <[EMAIL PROTECTED]> writes: jamal> Packets in flight? >> In the extreme case, there could still arrive up to the window >> size frames. jamal> Assuming this depends on path latency and not some bad jamal> programming Yes. Although the latter could also possible. jamal> BTW, earlier i lied: there is a way to tell if your packet jamal> will be dropped which is not very expensive: jamal> if (atomic_read(&netdev_dropping) /* packet will be jamal> dropped */ jamal> but even this is 99% accurate in SMP. Well, but better than knowing nothing about congestion state. We could at least document in the x25iface.txt kernel doc that driver authors should check this before acknowledging frames. Henner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] (long) network interface changes
> "jamal" == jamal <[EMAIL PROTECTED]> writes: [...] Nice introduction! jamal> The driver uses the feedback information to intelligently jamal> adjust its sending rate. (i.e reduce or increase calls to jamal> netif_rx() or send a congestion-experienced frame to its jamal> peer eg in X.25). In the sample tulip driver, dynamic Just a clarification (for the next version ;): it´s not really a congestion notification. It is just a `receiver' busy condition. LAPB is not designed for congestable links and cannot really report that congestion occured. It can only delay acknowledgement (and communicate rx_busy state to the peer). The retransmission was really only designed for occasionally recovering from transmission error caused by line noise. Once a packet has been lost, all packets (even those already arrived after the lost one) must be retransmitted. There is nothing like selcetive acknolegment. Thus, although LAPB can recover from packet loss caused by congestion, it will not react in a manner adapted to the congestion state. For minimizing possible confusion about the different X.25 layers, I´d suggest to eplicitly call it `LAPB datalink layer of X.25´ in future versions of the document. jamal> I have experimented with two schemes: one which samples the jamal> queue via a timer and one which does it per-packet and jamal> found that the per-packet sampler gave better results (more jamal> samples, Shannon's theorem applies). It didnt matter jamal> whether HZ was 100 or 1024 during the tests. The measure jamal> of "better" was throughput. Nice. I think such a kind of fair input queueing would be an important features because that allows to offer a highly reliable netif() to slow links which are slow, but inefficient to handle congestion (like X.25 LAPB datalink protocol). Network interfaces could trade reliablilty for speed. Another issue: Some protocols designed for congestable links support forward and/or backward congestion notification (e.g. frame relay, I thing DECnet and IPV6 also can do so). Thus, it would be nice if those protocols could easily access the congestion state such that congestion notification bits can be set efficiently. [...] Seems there are lots of interesting problems to investigate and to solve. Anyhow, no matter how the details will be in future, What´s basically needed is a return value for netif_rx(). This is also `nice` for symmetry reasons (in 2.4.x, dev_queue_xmit() returns an int, too). Would it possibe to make the return sematics of the varios layer-boundary-crossing methods conssitent ore are they just to different? There is currently no agreement among the different protocol implementations. Many of them use a boolean return value for reporting whether delivering to upper/lower layer was sucessful. But there is unfortunatly no unique convention whether 1 means success or failure. I´ll be leaving for Linux-Kongress. Thus, I won´t be able to further contribute to this thread for this week. Cheers, Henner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Bugreport kernel 2.4.0-test8
On 2000-09-19 8:33:49 Michael Zieger wrote: >I just found a big bug in kernel 2.4.0-test8 that leads to a major >crash because PID 4 [kupdate] dies. >I could reproduce the problem by doing this: >- Open StarOffice under KDE >- Create new textfile >- Try to save it under a via NFS mounted directory I experienced this same problem with 2.4.0-test9-pre4. The NFS server was a stock Red Hat 6.0 box running 2.2.5. My workstation is running Linux-Mandrake 7.2 beta 2 with 2.4.0.9.4 patched for ReiserFS 3.6.16, with all partitions formatted with ReiserFS 3.5.24. When I tried to save a StarOffice 5.2 file in .doc format to the NFS server, the workstation hung and did not respond for 10 minutes. I could not telnet to it, but it did respond to pings. I had to hit the big switch. Afterwards, the only lines in /var/log/messages (at the time of the problem) were: Sep 19 13:11:27 spc kernel: NFS: NFSv3 not supported. Sep 19 13:11:27 spc kernel: nfs warning: mount version older than kernel I experienced some file corruption. StarOffice would not run after reboot, complaining about missing configuration files. I hope this helps, Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops with K6-2 350, but not with other CPUs.
Daniel Grimwood <[EMAIL PROTECTED]> said: > am having many random fatal oopses with my K6-2 350. Can't find > anything related on the mailing list archive, so here it is. Also, I'm > not subscribed to the mailing list but do read it via NNTP, a CC: would > be much appreciated :). TIA. Random crashes is usually a hardware problem: Bad RAM, overheated CPU, overclocking, ... -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Rik's VM contains a deadlock somewhere
Hi,
I too tested to stress the new VM
Quintelas mmap002 "deadlocks" for me.
PPro, 96 MB, UP
active: 22337 (I think this varies, have too lock a 2nd time)
inactive_dirty: 324 varies
inactive_clean: 0
free: 288
... 1x 512 = 512 kB
... 2 x 16 + 1 x 32 + 1 x 64 = 640 kB
My feeling when looking at Alt-SysRq-M was
that pages was moved between Active and
idle_dirty - will look into this.
There is no 'if (current->need_resched) schedule()'
in this code - if kswapd starts too loop...
PS
Now I am back from my vacation period...
DS
Rik van Riel wrote:
>
> On Tue, 19 Sep 2000, Anton Petrusevich wrote:
>
> > please, check carefully Rik's VM patch, it definitly contains a
> > deadlock, which can be seen on low-memory computers. Try mem=8m. I
> > wasn't able to use any Rik patch since against -test8 (-t8-vmpatch{2,4},
> > -test9-pre{1,2}). It boots fine(mem=16m), but then stalls begin for some
> > time and for infinitive time at last. I told Rik about it, he tried to
> > fix but wasn't successful.
> >
> > With mem=8m it couldn't finish init scripts even.
>
> I /thought/ I had fixed this, since the system runs fine
> on my (SMP, SCSI) test machine when I boot it with mem=8m.
>
> Somebody on IRC suggested to me that this may be an UP-only
> bug ... I'm looking into this and hope to fix it soon, but
> I have to admit some help would be welcome ;)
>
> (I'm still at Linux Kongress and won't be back in the office
> for about a week)
>
> regards,
>
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>-- Miguel de Icaza, UKUUG 2000
>
> http://www.conectiva.com/ http://www.surriel.com/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
Home page:
http://www.norran.net/nra02596/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: An elevator algorithm
On Tue, Sep 19, 2000 at 11:09:47PM +0200, Peter Osterlund wrote: > So that leaves two choices: > > 1. Perfect elevator (CSCAN) without the O(1) optimization. (My second >patch.) We can try with 1. first. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: An elevator algorithm
Jens Axboe <[EMAIL PROTECTED]> writes: > > modification Peter suggested there can be more and we should track the one > > more on the back of the queue. I don't think it's worthwhile. > > Agree, I don't think the added complexity would be worth it. So that leaves two choices: 1. Perfect elevator (CSCAN) without the O(1) optimization. (My second patch.) 2. Suboptimal elevator with the O(1) optimization. (Andrea's suggested modification to my second patch.) Since the request queue can not be very long, minimizing disk head movements ought to be more important than saving a few CPU cycles, so I vote for the first alternative. -- Peter Österlund Email: [EMAIL PROTECTED] Sköndalsvägen 35[EMAIL PROTECTED] S-128 66 Sköndal Home page: http://home1.swipnet.se/~w-15919 Sweden Phone: +46 8 942647 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: An elevator algorithm (patch)
On Tue, Sep 19, 2000 at 10:38:52PM +0200, Jens Axboe wrote: > I haven't had a chance to really look at Peter's mods yet, but surely > the current elevator can have many entries with 0 sequence. As an > example, say the start sequence is 3 and we received request sector > 10...1 in descending order. The sorted order would then be > > 7[3] 8[2] 9[1] 10[0] 3[3] 4[2] 5[1] 6[0] 1[3] 2[2] p With point `p' I mean the request after last barrier in the queue. With the current algorithm we can trivially account for p each time we do elevator_sequence--. elevator_sequence can't go below zero and we never play with stuff before the last barrier. So the first time !--req->elevator_sequence is true we would know that req->next is the new p (if it's not real_head). Then we would insert at the left of p if the new req is lower than p. With the modification instead we could have this queue: 100[0] Then we insert 102 103 and 104: 100[0] 102[3] 103[3] 104[3] p Then when we try to insert 99 it goes here: 100[0] 102[3] 103[3] 104[3] 99[3] p So we have two low peaks in the not starving queue and we should move the p to the latest on the right. Also we should make different cases in function of what p->prev is (barrier/head/real_head/normalreq). I don't think it's worthwhile (even with the current algorithm where it's easy to account for p). Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
Linus Torvalds wrote:
In article <[EMAIL PROTECTED]>, Dag Bakke <[EMAIL PROTECTED]> wrote:
>Tigran Aivazian wrote:
>>
>> On Mon, 18 Sep 2000, Derek Wildstar wrote:
>>
>> > On 18 Sep 2000, Alex Romosan wrote:
>> >
>> > I get the same thing with a Xircon realport 10/100/modem card. Works
>> > great in test9-pre1 and test8.
[note: neither of these kernels worked for me]
>> >
>> > -dwild
>> >
>>
>> did you try this patch?
>>
>> --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
>> +++ work/drivers/pci/pci.c Mon Sep 18 13:12:20 2000
[snip]
> >I did.
> >Didn't work for me.
> >My Xircom is still being detected. But PCI resource allocation still fails.
> >I'll be happy to set up a remote debug session for anyone interested...
>
> There seem to be two potential problems with the new code. How about
> this instead:
>
> First off, it's doing the subordinate bus write with a byte write, which
> is, as far as I can tell, not legal. When you update the bus
> information, you have to update it all at the same time.
>
> Does it help if you change drivers/pci/pci.c pci_scan_bridge(), the line
> that says
>
> pci_write_config_byte(dev, PCI_SUBORDINATE_BUS, max);
>
> and you replace that with
>
> buses = (buses & 0xff00) | ((unsigned int)(child->subordinate) << 16);
> pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
>
> instead.
>
> Second, if the cardbus bridge is already allocated by the BIOS, the "max
> bus" logic looks bogus. It looks like
>
> if (!is_cardbus) {
> unsigned int cmax = pci_do_scan_bus(child);
> if (cmax > max) max = cmax;
> }
>
> and it _should_ probably have something like
>
> if (!is_cardbus) {
> .. same logic ..
> } else {
> unsigned int cmax = child->subordinate + 3;
> if (cmax > max) max = cmax;
> }
>
> because otherwise we'd completely ignore the cardbus "max" values as far
> as I can tell, and if the machine has another bus it might be given the
> same bus value as the already-configured cardbus bridge.
>
> Do the above two fixes help? If not, I suspect that we're better off
> just reverting the new PCI bus allocation until it's fixed.
>
> Linus
Nah. Didn't help:
Yenta IRQ list 0698, PCI irq11
Socket status: 3006
Yenta IRQ list 0698, PCI irq11
Socket status: 3020
cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003
PCI: Failed to allocate resource 0 for PCI device 115d:0003
PCI: Failed to allocate resource 1 for PCI device 115d:0003
PCI: Failed to allocate resource 2 for PCI device 115d:0003
PCI: Failed to allocate resource 6 for PCI device 115d:0003
PCI: Device 06:00.0 not available because of resource collisions
PCI: Failed to allocate resource 0 for PCI device 115d:0103
PCI: Failed to allocate resource 1 for PCI device 115d:0103
PCI: Failed to allocate resource 2 for PCI device 115d:0103
PCI: Failed to allocate resource 6 for PCI device 115d:0103
PCI: Device 06:00.1 not available because of resource collisions
With Tigran's fix, resource 0 is successfully allocated, and the message
is approximately:
Found 04:00 [115d/0003] 000200 00
PCI: Failed to allocate resource 1 for PCI device 115d:0003
PCI: Failed to allocate resource 2 for PCI device 115d:0003
PCI: Failed to allocate resource 6 for PCI device 115d:0003
PCI: Enabling device 04:00.0 ( -> 0003)
Found 04:01 [115d/0103] 000300 00
PCI: Failed to allocate resource 1 for PCI device 115d:0103
PCI: Failed to allocate resource 2 for PCI device 115d:0103
PCI: Failed to allocate resource 6 for PCI device 115d:0103
PCI: Enabling device 04:00.1 ( -> 0003)
But loading the driver reveals hw-addr == 0:0:0:0:0:0, and ifconfig'ing
the interface causes a hang.
If I parse the message from Martin Mares
(http://www.cs.helsinki.fi/linux/linux-kernel/2000-38/0532.html)
correctly, a fix is possibly needed in
./drivers/pcmcia/yenta.c , and not in ./drivers/pci/pci.c ?
I tried to grok it, but I never got very much beyond 'Hello World\n'
I notice that most devices in this laptop get IRQ 11. Is this an
indication of anything?
dagblap:~# lspci -v | grep -i irq
Flags: bus master, medium devsel, latency 168, IRQ 11
Flags: bus master, medium devsel, latency 168, IRQ 11
Flags: bus master, medium devsel, latency 32, IRQ 11
Flags: bus master, medium devsel, latency 32, IRQ 11
Flags: bus master, medium devsel, latency 32, IRQ 11
Flags: medium devsel, IRQ 5
Flags: medium devsel, IRQ 11
Flags: medium devsel, IRQ 11
dagblap:~# cat /proc/interrupts
CPU0
0: 92925 XT-PIC timer
1: 3 XT-PIC keyboard
2: 0 XT-PIC cascade
11:431 XT-PIC Texas Instruments PCI1225, Texas
Instruments PCI1225 (#2), eth0
12: 0 XT-PIC PS/2 Mouse
13: 0 XT-PIC fpu
14:874 XT-PIC ide0
15: 3 XT-PIC ide1
NMI: 0
ERR: 0
Dag B
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
Re: weird PCI problems...
On Tue, 19 Sep 2000, Martin Mares wrote: > Anyway, can you send me your /proc/ioports and /proc/iomem, please? Yes, sure: -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000d-000d0fff : Extension ROM 000d4000-000d47ff : Extension ROM 000f-000f : System ROM 0010-07fe : System RAM 0010-00246197 : Kernel code 00246198-0025cf37 : Kernel data 07ff-07ff : ACPI Tables 1000-1fff : Texas Instruments PCI1225 10001000-10001fff : Texas Instruments PCI1225 (#2) 100a-100f : reserved 1040-107f : PCI CardBus #03 1040-1041 : PCI device 10b7:5257 1080-10bf : PCI CardBus #03 1080-1080007f : PCI device 10b7:5257 10800080-108000ff : PCI device 10b7:5257 10c0-10ff : PCI CardBus #04 1100-113f : PCI CardBus #04 a000-afff : card services f000-f3ff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge f500-f5ff : PCI Bus #02 f600-f6ff : PCI Bus #01 fa00-fbff : PCI Bus #02 fae0-faef : Intel Corporation 82557 [Ethernet Pro 100] faffd000-faffdfff : Adaptec AIC-7880U faffe000-faffefff : Intel Corporation 82557 [Ethernet Pro 100] faffe000-faffefff : eepro100 fafff800-fafff87f : 3Com Corporation 3c905C-TX [Fast Etherlink] fafffc00-fafffcff : Realtek Semiconductor Co., Ltd. RTL-8139 fafffc00-fafffcff : eth2 fc00-feff : PCI Bus #01 fcfff000-fcff : ATI Technologies Inc 3D Rage P/M Mobility AGP 2x fd00-fdff : ATI Technologies Inc 3D Rage P/M Mobility AGP 2x ffe0- : reserved - -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial(set) 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0800-083f : Intel Corporation 82371AB PIIX4 ACPI 0840-085f : Intel Corporation 82371AB PIIX4 ACPI 0860-086f : Intel Corporation 82371AB PIIX4 IDE 0860-0867 : ide0 0868-086f : ide1 0cf8-0cff : PCI conf1 1000-10ff : PCI CardBus #03 1000-107f : PCI device 10b7:5257 1000-107f : eth3 1400-14ff : PCI CardBus #03 1800-18ff : PCI CardBus #04 1c00-1cff : PCI CardBus #04 d800-d8ff : ESS Technology ES1978 Maestro 2E d800-d8ff : ESS Maestro 2E dce0-dcff : Intel Corporation 82371AB PIIX4 USB e000-efff : PCI Bus #01 ec00-ecff : ATI Technologies Inc 3D Rage P/M Mobility AGP 2x f000- : PCI Bus #02 f000-f0ff : Adaptec AIC-7880U f800-f87f : 3Com Corporation 3c905C-TX [Fast Etherlink] f800-f87f : eth0 f880-f88f : CMD Technology Inc PCI0646 f880-f887 : ide2 f888-f88f : ide3 f898-f89b : CMD Technology Inc PCI0646 f8a0-f8a7 : CMD Technology Inc PCI0646 f8b0-f8b3 : CMD Technology Inc PCI0646 f8b8-f8bf : CMD Technology Inc PCI0646 f8c0-f8ff : Intel Corporation 82557 [Ethernet Pro 100] f8c0-f8ff : eepro100 fc00-fcff : Realtek Semiconductor Co., Ltd. RTL-8139 fc00-fcff : eth2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
} On Tue, Sep 19, 2000 at 09:53:41PM +0200, [EMAIL PROTECTED] wrote: } > } > } > >> Linus, } > > } > >> Where do architecture maintainers stand when they don't submit their } > >> problems to linux-kernel or the great Ted Bug List(tm)? } > > } > >Up against the wall so we can shoot them? } > > } > >:) } > } > So I am one of the guys who will be shot ... I wanted to do an update for } > the s/390 architecture since weeks but there was always something more } > important. I finally cut some hours out of my ribs and made a patch against } > linux-2.4.0-test8. The diff for files in arch/s390, include/asm-s390 and } > drivers/s390 is pretty big, about 1 MB. The diffs for non s/390 files is } > smaller, only 35 KB. } > The question is now do you want to have the patch or do we wait until 2.4.1 } > ? } } Well, I'm not Linus (thank $DEITY for that; in that case, Linux would've } been an operating-system for the C=64...), but imho it would be cool if } we for once managed to release a v2.4.0 which actually managed to build } at least for some configurations on each platform. Oh, and I do firmly } believe that the S390 would be pretty non-critical to change, as it's } a new platform anyway, and the userbase is probably not that large yet } (hopefully it will become!) } } As for me, I'm content as long as MCA-support and MPC7400 support works } properly for respectively x86 and PPC... The problem for getting a stable 2.4.0 out is not with the architectures, they've been stable mostly. I'm fighting a tidal wave of changes from the PPC guys that I can't let into 2.4 or 2.2 since they're both supposed to be stable. We have to endure VM rewrites but the architecture-specific code has been pretty stable. If we could get a damned 2.4 our then we could also have a 2.5 and there would be some place for these experimental changes to go instead of the two stable trees. I've had to create a 2.5 for the PPC tree so we aren't stuck with either no experimentation or experimentation in the stable trees. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
APIC errors on my dual celeron, 2.4.0-test7
Greetings everyone. I have been running Linux kernel 2.4.0-test7 for some time now on my dual celeron (BP6) system. I have an AGP video card, one ethernet card, one IDE sound card, ps/2 keyboard and mouse, and two IDE hard drives. (No floppy, no CD.) I get errors of this sort on a regular basis while in console mode; under X, I imagine they don't get written. APIC error on CPU1: 02(02) APIC error on CPU1: 02(08) The errors also occur on CPU0. (Or is it CPU2? :) I don't know if numbers other than 02 or 08 occur; I haven't kept good records. Sometimes I can go several minutes without errors, and other times the errors come once every few seconds. I am running very little in the way of i/o intensive programs -- setiathome is the most burdensome program I tend to run most of the time. Is this something I should be worried about? Is this something other people are familiar with and know how to fix? Is it something that should be fixed? :) Thanks all. Please CC me on responses. :) -- Seth Arnold | http://www.willamette.edu/~sarnold/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 09:53:41PM +0200, [EMAIL PROTECTED] wrote: > > > >> Linus, > > > >> Where do architecture maintainers stand when they don't submit their > >> problems to linux-kernel or the great Ted Bug List(tm)? > > > >Up against the wall so we can shoot them? > > > >:) > > So I am one of the guys who will be shot ... I wanted to do an update for > the s/390 architecture since weeks but there was always something more > important. I finally cut some hours out of my ribs and made a patch against > linux-2.4.0-test8. The diff for files in arch/s390, include/asm-s390 and > drivers/s390 is pretty big, about 1 MB. The diffs for non s/390 files is > smaller, only 35 KB. > The question is now do you want to have the patch or do we wait until 2.4.1 > ? Well, I'm not Linus (thank $DEITY for that; in that case, Linux would've been an operating-system for the C=64...), but imho it would be cool if we for once managed to release a v2.4.0 which actually managed to build at least for some configurations on each platform. Oh, and I do firmly believe that the S390 would be pretty non-critical to change, as it's a new platform anyway, and the userbase is probably not that large yet (hopefully it will become!) As for me, I'm content as long as MCA-support and MPC7400 support works properly for respectively x86 and PPC... /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: (reiserfs) Re: An elevator algorithm (patch)
On Tue, Sep 19 2000, Andrea Arcangeli wrote: > > I don't see any reason why there can't be multiple p points in the current > > elevator. > > Without the proposed modification after the last barrier in the queue all the > requests should be in order. I haven't had a chance to really look at Peter's mods yet, but surely the current elevator can have many entries with 0 sequence. As an example, say the start sequence is 3 and we received request sector 10...1 in descending order. The sorted order would then be 7[3] 8[2] 9[1] 10[0] 3[3] 4[2] 5[1] 6[0] 1[3] 2[2] (sector[sequence]) -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: GCC proposal for "@" asm constraint
On Tue, Sep 19, 2000 at 04:16:07PM -0400, John Wehle wrote: > Umm ... "miscompilation"? As in the compiler produced the wrong code > based on the input provided? That's not a gcc bug (gcc is doing the right thing). It's the kernel that should use the "memory" clobber in the spinlock implementation. The sad code generated was in reality the _right_ code. I was blind not noticing the missing $ (I missed it the first time in the first testcase I tried and I kept missing it, I was probably also biased assuming the current spinlocks was safe with the commonly used compilers, I was thinking to fix only a theorical bug). I'm sorry for that (and thanks again to Richard and Jamie). Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Retract - [PATCH] scsi_ioctl_send_command() shouldn't write SEND DIAGNOSTIC S reserved bits
Indeed, my copy of the SCSI 3 SPC-1 (ftp://ftp.t10.org/t10/drafts/spc/spc-r11a.pdf dated 21-Mar-1997) and SPC-2 (ftp://ftp.t10.org/t10/drafts/spc2/spc2r18.pdf dated 21-May-2000) show them differently. SPC-3 isn't available for download.Anyone have the "final" copy (if indeed it's not still in draft state)? SCSI1 - byte 1 bits 5-7 are the LUN address SCSI2 - byte 1 bits 5-7 are the LUN address SCSI3 SPC-1 - byte 1 bits 5-7 are marked "reserved" for all commands SCSI3 SPC-2 - byte 1 bits 5-7 are now used for self test codes for the SEND DIAGNOSTIC command, "reserved" for all other commands that I could see. Maybe the proper logic would be to switch ioctl_send_command() functions based on the version field in the INQUIRY data as you suggest, and then in the SCSI3 case, handle SEND_DIAGNOSTIC separately? I hereby retract my patch until a better solution is agreed upon that doesn't break SCSI backward compatability. Thanks, Matt -Original Message- From: Guest section DW [mailto:[EMAIL PROTECTED]] Sent: Monday, September 18, 2000 3:57 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PATCH] scsi_ioctl_send_command() shouldn't write SEND DIAGNOSTIC S reserved bits On Mon, Sep 18, 2000 at 11:31:09AM -0500, [EMAIL PROTECTED] wrote: > This patch prevents scsi_ioctl_send_command() from overwriting the SEND > DIAGNOSTICS (Drive Self Test) reserved bits in cmd[1], as found in SCSI-3. > Code provided by Michael Landrus of Dell. > > Comments are requested. If there are no objections, Linus and Alan please > apply. > Below are patches to kernels 2.2.18-pre8 and 2.4.0-test9-pre1. > -cmd[1] = ( cmd[1] & 0x1f ) | (dev->lun << 5); > +if ( cmd[0] != 0x1d ) // don't overwrite the SCSI-3 SEND DIAGNOSTICS > reserved bits > + cmd[1] = (cmd[1] & 0x1f) | (dev->lun << 5); I am a bit surprised: why only SEND DIAGNOSTICS? If I am not mistaken SCSI-1 used this 3-bit LUN field in all commands, and SCSI-2 still does, but the standard says: 7.2.2 Logical unit number ... NOTICE: The logical unit number field is included in the command descriptor block for compatibility with some SCSI-1 devices. This field may be reclaimed in SCSI-3. and SCSI-3 calls these bits "reserved", for all commands, also for SEND DIAGNOSTICS. So: (i) I don't see what is special with SEND DIAGNOSTICS. Maybe for SCSI-3 the lun should never be inserted. (ii) On the other hand, for SCSI-1 the lun should always be inserted. Once these bits really get used again (are there already examples of a new use?) I suppose we should introduce a new SCSI3_IOCTL_SEND_COMMAND instead of changing SCSI_IOCTL_SEND_COMMAND. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
Hi Linus, On Tue, 19 Sep 2000, Linus Torvalds wrote: > Do the above two fixes help? If not, I suspect that we're better off > just reverting the new PCI bus allocation until it's fixed. No, unfortunately they don't help at all, neither individually nor in pair. So far, the only working case was replacing !is_cardbus ->is_cardbus but, of course, this is not a fix because I don't understand it. :( I understand that simply treating cardbus bridges as PCI-PCI bridges does not work (and actually verified it by trying) but can't say more - I know nothing of cardbus bridges (or PCMCIA). It would be a shame to revert back to old ways because we have something working, we just don't understand why or what is the proper way to do it... Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
inlines [was Re: Linux-2.4.0-test9-pre2]
Linus Torvalds writes: > > >On Tue, 19 Sep 2000, Rogier Wolff wrote: >> >> If gcc starts shouting: >> >> somefile.c:1234: declared inline function 'serial_paranoia_check' is >> somefile.c:1234: larger than 1k. Declining to honor the inline directive. > >That's not what gcc does. > >Gcc silently just doesn't inline it. > >From the gcc-2.95.2 manual: `-Winline' Warn if a function can not be inlined, and either it was declared as inline, or else the `-finline-functions' option was given. Ralph. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: generic scsi gone in 2.4.0test9pre4
On Tue, Sep 19, 2000 at 12:48:14PM -0700, Christoph Lameter wrote: > On Tue, 19 Sep 2000, Marko Kreen wrote: > > On Tue, Sep 19, 2000 at 09:32:09AM -0700, Christoph Lameter wrote: > > > Tried burning a cd with pre4 and devfs. There is no /dev/sg0 and /dev/scsi > > > is empty. > > It 'moved'. Do a 'cd /dev/scsi; ln ../host0' for temporary workaround. > > > > Well, I 'tried to boot' from scsi, its even more fun... > > /dev/scsi is empty. > Uh, that's what I said. The /dev/scsi/host0 is at the moment /dev/host0, if you do a 'ln -s ../host0 /dev/scsi/host0' then it kinda works until someone with a clue fixes that :) -- marko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: GCC proposal for "@" asm constraint
> I see. So Jamie was right and we reproduced a case of miscompilation. Umm ... "miscompilation"? As in the compiler produced the wrong code based on the input provided? int * p; ... a = *p; movl p,%eax movl (%eax),%edx The assembly code appears to load the address stored at p (keep in mind that p is a pointer), then use that address to fetch the value which is placed in a. What do you believe should have been generated by the compiler? -- John - | Feith Systems | Voice: 1-215-646-8000 | Email: [EMAIL PROTECTED] | |John Wehle| Fax: 1-215-540-5495 | | - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: weird PCI problems...
Hi Tigran!
Sorry for the delay, I'm now finishing up for my final exams, so I get to
answering my mail once per day if I'm lucky.
> Yes, doing it like this works:
>
> --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
> +++ work/drivers/pci/pci.cMon Sep 18 13:12:20 2000
> @@ -714,7 +714,7 @@
>* We need to blast all three values with a single write.
>*/
> pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
> - if (!is_cardbus) {
> + if (is_cardbus) {
> /* Now we can scan all subordinate buses... */
> max = pci_do_scan_bus(child);
> } else {
> Martin, is this totally wrong? I.e. will it break the case of multiple
> peer PCI buses? Note that with the above I see absolutely all my devices,
> like this:
This fix is wrong -- the scanning of cardbus devices is done inside the cardbus
driver itself, the PCI layer should only allocate the bus. If you force the
scanning, it will work for devices present during system boot, but not if you
remove the card and insert it again.
Anyway, can you send me your /proc/ioports and /proc/iomem, please?
Have a nice fortnight
--
Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/
"People disagree with me. I just ignore them." -- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[OOPS] 2.2.18pre9 Oops on rmmod of mousedev.c
( This has been resend, [EMAIL PROTECTED] already got a copy as well as the usb-uhci
maintainer as listed in MAINTAINERS )
DISCLAIMER: This oops may very well be categorized in the 'user
shoots himself' department but I still thought it interesting enough
to post a bugreport and see if anything can be done against it.
So here goes.
Using kernel version 2.2.18pre9, use the following steps to get a
repeatable kernel oops:
1) Compile kernel with usb support: hid.c, mousedev.c, input.c et al.
2) Install kernel, insmod USB drivers.
3) Configure gpm to use /dev/input/mice and the attached M$ USB mouse.
(all is fine at this point, no problems whatsoever, the mouse works
like a charm)
4) rmmod mousedev.c (okay, stupid but heck I was playing around ;)
5) restart gpm
6) watch the nice oops message and laugh :)
So here it is.
Oops:
CPU:0
EIP:0010:[do_select+256/512]
EFLAGS: 00010282
eax: d00a1c40 ebx: ecx: 0145 edx: c71fe180
esi: edi: 0001 ebp: esp: c7367f1c
ds: 0018 es: 0018 ss: 0018
Process gpm (pid: 1652, process nr: 41, stackpage=c7367000)
Stack: cf174ef8 c7e99b34 0001 0011 c7366000 c7366000 0083c733
c6cd4000 000e 080580e0 0002 c012ffdd 0003 c7367f9c
c7367f98 c7366000 b898 bacc 0002 0001
Call Trace: [sys_select+881/1176] [system_call+52/56]
Code: 8b 40 10 85 c0 74 10 83 c4 f8 8b 4c 24 30 51 52 ff d0 89 c1
After running it through ksymoops:
ksymoops 2.3.4 on i686 2.2.18pre9. Options used
-V (specified)
-k /proc/ksyms (specified)
-l /proc/modules (specified)
-o /lib/modules/2.2.18pre9/ (specified)
-m /boot/System.map-2.2.18pre9 (specified)
Warning (compare_maps): ksyms_base symbol module_list_R__ver_module_list not found in
System.map. Ignoring ksyms_base entry
Oops:
CPU:0
EIP:0010:[do_select+256/512]
EFLAGS: 00010282
eax: d00a1c40 ebx: ecx: 0145 edx: c71fe180
esi: edi: 0001 ebp: esp: c7367f1c
ds: 0018 es: 0018 ss: 0018
Process gpm (pid: 1652, process nr: 41, stackpage=c7367000)
Stack: cf174ef8 c7e99b34 0001 0011 c7366000 c7366000 0083c733
c6cd4000 000e 080580e0 0002 c012ffdd 0003 c7367f9c
c7367f98 c7366000 b898 bacc 0002 0001
Call Trace: [sys_select+881/1176] [system_call+52/56]
Code: 8b 40 10 85 c0 74 10 83 c4 f8 8b 4c 24 30 51 52 ff d0 89 c1
Using defaults from ksymoops -t elf32-i386 -a i386
Code; Before first symbol
<_EIP>:
Code; Before first symbol
0: 8b 40 10 mov0x10(%eax),%eax
Code; 0003 Before first symbol
3: 85 c0 test %eax,%eax
Code; 0005 Before first symbol
5: 74 10 je 17 <_EIP+0x17> 0017 Before first symbol
Code; 0007 Before first symbol
7: 83 c4 f8 add$0xfff8,%esp
Code; 000a Before first symbol
a: 8b 4c 24 30 mov0x30(%esp,1),%ecx
Code; 000e Before first symbol
e: 51push %ecx
Code; 000f Before first symbol
f: 52push %edx
Code; 0010 Before first symbol
10: ff d0 call *%eax
Code; 0012 Before first symbol
12: 89 c1 mov%eax,%ecx
1 warning issued. Results may not be reliable.
How do I get rid of the warning anyway? I've never used ksymoops
before so I probably am doing something wrong here :)
And finally, for those who care to know every gory detail, here's the
syslog, including boot messages & oops. (Edited for brevity, and
probably not needed but I like to be on the safe side)
Sep 19 19:59:20 tobefree syslogd 1.3-3#33: restart.
Sep 19 19:59:20 tobefree kernel: klogd 1.3-3#33, log source = /proc/kmsg started.
Sep 19 19:59:20 tobefree kernel: Inspecting /boot/System.map-2.2.18pre9
Sep 19 19:59:20 tobefree kernel: Loaded 6269 symbols from /boot/System.map-2.2.18pre9.
Sep 19 19:59:20 tobefree kernel: Symbols match kernel version 2.2.18.
Sep 19 19:59:20 tobefree kernel: Loaded 482 symbols from 26 modules.
Sep 19 19:59:20 tobefree kernel: Linux version 2.2.18pre9 (root@tobefree) (gcc version
2.95.2 2220 (Debian GNU/Linux)) #1 Mon Sep 18 23:53:00 CEST 2000
Sep 19 19:59:20 tobefree kernel: Detected 434326 kHz processor.
Sep 19 19:59:20 tobefree kernel: Calibrating delay loop... 865.08 BogoMIPS
Sep 19 19:59:20 tobefree kernel: Memory: 257920k/262080k available (864k kernel code,
416k reserved, 2824k data, 56k init)
Sep 19 19:59:20 tobefree kernel: Dentry hash table entries: 32768 (order 6, 256k)
Sep 19 19:59:20 tobefree kernel: Buffer cache hash table entries: 262144 (order 8,
1024k)
Sep 19 19:59:20 tobefree kernel: Page cache hash table entries: 65536 (order 6, 256k)
Sep 19 19:59:20 tobefree kernel: Intel machine c
Re: [User-mode-linux-user] Ptrace broken since 2.4.0-test8pre4?...
Hello Jeff, I tested vanilla test7 with ptrace() patch. It breaks uml exactly like I see with any kernel > test7. Seems like the ORIG_EAX != -1 is needed to correctly restart syscall after PTRACE_SYSCALL, but I did not check this codepath thoroughly. Following what is going with uml, just for the very first exec: [lots of trap_user.c:228, trap_user.c:149 skipped] start_syscall(): process.c:181 ptrace(PTRACE_GETREGS, 4901, 0, 501242c0) = 0 finish_exec(): exec_user.c:26 ptrace(PTRACE_POKEUSER, 4901, UESP, bf7fff20) = 0 exec_user.c:27 ptrace(PTRACE_POKEUSER, 4901, EIP, 400019a0) = 0 exec_user.c:28 ptrace(PTRACE_POKEUSER, 4901, EDX, 0) = 0 exec_user.c:29 ptrace(PTRACE_SYSCALL, 4901, 0, 0) = 0 And voila, we got SIGSEGV instead of happy running child: Child 4901 exited with signal 11 > Have you tried putting that ptrace patch into test7 and seeing if UML stops > working with that as the host? > > test8 is a known bad platform for UML, so I'm going to consider that the > ptrace patch is OK unless it's possible to turn a good host into a bad one by > adding that ptrace fix. --- v2.4.0-test7/linux/arch/i386/kernel/ptrace.c Fri Jun 23 21:55:07 2000 +++ linux/arch/i386/kernel/ptrace.c Sat Sep 2 12:00:02 2000 @@ -99,6 +99,11 @@ case EFL: value &= FLAG_MASK; value |= get_stack_long(child, EFL_OFFSET) & ~FLAG_MASK; + break; + case EIP: + /* Mark us as not being in a system call, so that no restart +issues happen */ + put_stack_long(child, 4*ORIG_EAX - sizeof(struct pt_regs), -1); + break; } if (regno > GS*4) regno -= 2*4; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Posible bug in dmascc
Hello,all I use kernel 2.4.0-test8. When i load the dmascc module my monitor turn off(power save mode). It works well in 2.2.17. Any idea? Regards, Metod [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: An elevator algorithm (patch)
On Tue, Sep 19, 2000 at 09:41:17PM +0200, Jens Axboe wrote: > I don't see any reason why there can't be multiple p points in the current > elevator. Without the proposed modification after the last barrier in the queue all the requests should be in order. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
>> Linus, > >> Where do architecture maintainers stand when they don't submit their >> problems to linux-kernel or the great Ted Bug List(tm)? > >Up against the wall so we can shoot them? > >:) So I am one of the guys who will be shot ... I wanted to do an update for the s/390 architecture since weeks but there was always something more important. I finally cut some hours out of my ribs and made a patch against linux-2.4.0-test8. The diff for files in arch/s390, include/asm-s390 and drivers/s390 is pretty big, about 1 MB. The diffs for non s/390 files is smaller, only 35 KB. The question is now do you want to have the patch or do we wait until 2.4.1 ? blue skies, Martin Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247 E-Mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: generic scsi gone in 2.4.0test9pre4
On Tue, 19 Sep 2000, Marko Kreen wrote: > On Tue, Sep 19, 2000 at 09:32:09AM -0700, Christoph Lameter wrote: > > Tried burning a cd with pre4 and devfs. There is no /dev/sg0 and /dev/scsi > > is empty. > It 'moved'. Do a 'cd /dev/scsi; ln ../host0' for temporary workaround. > > Well, I 'tried to boot' from scsi, its even more fun... /dev/scsi is empty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: An elevator algorithm (patch)
On Tue, Sep 19 2000, Andrea Arcangeli wrote: > > But there may be several p points in the queue, how are you going > > to keep track of all of them? > > With the current elevator there should be only 1 p point, but with the I don't see any reason why there can't be multiple p points in the current elevator. > modification Peter suggested there can be more and we should track the one > more on the back of the queue. I don't think it's worthwhile. Agree, I don't think the added complexity would be worth it. -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: An elevator algorithm (patch)
On Tue, Sep 19, 2000 at 09:17:51PM +0200, Jens Axboe wrote: > But there may be several p points in the queue, how are you going > to keep track of all of them? With the current elevator there should be only 1 p point, but with the modification Peter suggested there can be more and we should track the one more on the back of the queue. I don't think it's worthwhile. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI scanning changes break RAID autorun
In article <[EMAIL PROTECTED]>, Linus Torvalds <[EMAIL PROTECTED]> wrote: > [ Btw, has autorun ever worked with non-scsi devices? Yes, with IDE disks at least. -- Shields. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
