Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
On Tue, 19 Sep 2000, Tigran Aivazian wrote:
> On Mon, 18 Sep 2000, Horst von Brand wrote:
>
> > Tigran Aivazian <[EMAIL PROTECTED]> said:
> >
> > [...]
> >
> > > did you try this patch?
> > >
> > > --- 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 {
> >
> > No changes, same:
>
> ok, my "plan b)" didn't work for you, then :) we'll have to actually
> _understand_ what's going on then...
Your "plan b" worked for me...on test9-pre4 my Xircom is working with that
patch, and gets the same old "pci allocation" error without.
-dwild
-
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] Useless inode semaphore locking in 2.4.0-test8
On Tue, 19 Sep 2000, Jeff V. Merkey wrote: > > This will break NWFS and require I put back in all the locks Al Viro > told me to remove. This will also break _every_ writable filesystem in tree and outside. Case closed. Author of suggestion took it back about a week ago, IIRC. BTW, Linus, congrats on combing through your mailbox - wish I had time to do the same ;-) - 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
Linus Torvalds writes: > [ Btw, has autorun ever worked with non-scsi devices? They've mostly had > the new initialization order for a long time.. ] Hmm, I hope it will do, since a 2.2.17 kernel with Ingos RAID patches works, and it'd be a shame to break all those RAID root filesystems out there for 2.4. (says me who only got Ingo raid running on 2.2.17 a couple of days ago on ARM). ;) _ |_| - ---+---+- | | 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: An elevator algorithm (patch)
On Tue, Sep 19, 2000 at 08:30:05PM +0200, Peter Osterlund wrote: > It is however possible to decide in O(1) time if the correct insertion > point is at the end of the queue. We have to keep track of the point, Right. > [..] How long > can the request queue be? Does it have a fixed upper size, or is it It have a fixed upper size (it's a #define). > [..] Note that the worst case > complexity is still O(n) for all algorithms discussed so far. Right. 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: (reiserfs) Re: An elevator algorithm (patch)
On Tue, Sep 19 2000, Peter Osterlund wrote:
> > 2) the block number is smaller than head (or head->next
> >if the current request is unplugged)
>
> The second condition is not so simple in the case of latency control.
> Consider the following queue:
>
> sector: 100 200 300 400 10 20 30
> sequence: 1 1 1 1 0 1 1
>
> In this case it would be correct to insert 150 at the end even though
> it is >100, because no more requests are allowed to pass the "10"
> request.
>
> It is however possible to decide in O(1) time if the correct insertion
> point is at the end of the queue. We have to keep track of the point,
> p, where no more requests may pass. (10 in the example above.) The logic
> would then be:
>
> int insert_at_tail = 0;
> if (IN_ORDER(p, last)) {
> if (IN_ORDER(last, req) || IN_ORDER(req, p))
> insert_at_tail = 1;
> } else {
> if (IN_ORDER(last, req) && IN_ORDER(req, p))
> insert_at_tail = 1;
> }
> if (insert_at_tail) {
> /* Do it in O(1) */
> } else {
> /* Do normal O(n) scan and update latencies */
> }
But there may be several p points in the queue, how are you going
to keep track of all of them?
> The question is if this is worth the extra code complexity. How long
> can the request queue be? Does it have a fixed upper size, or is it
> limited only by available memory? If the request queue is always
> short, the O(n) complexity shouldn't matter. Note that the worst case
> complexity is still O(n) for all algorithms discussed so far.
See QUEUE_NR_REQUESTS in blkdev.h -- the standard size is 256 requests
per queue.
--
* 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, Rik van Riel wrote: > This is a bug in Andrea's idea. The request should only > be inserted at the end of the list if: > > 1) the block numbre is bigger than head->prev (which you >already have) Of course. > 2) the block number is smaller than head (or head->next >if the current request is unplugged) Not necessarily, that's what we have the sequencing numbers for. It still allows sorting, as long as we are allowed to pass the request. And note that it is only head->next when the queue is unplugged with an active head. -- * 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] Useless inode semaphore locking in 2.4.0-test8
This will break NWFS and require I put back in all the locks Al Viro told me to remove. Jeff Linus Torvalds wrote: > > In article <[EMAIL PROTECTED]>, > Eric PAIRE <[EMAIL PROTECTED]> wrote: > > > >In open.c:do_truncate(), the call to notify_change() is protected by > >the inode->i_sem, which seems to me useless, and thus can be removed. > > And exactly how do you now protect against the race of another process > doing a write() at the same time, and in particular the updates of > "inode->i_size"? > > As far as I can tell, you removing the semaphore means that _nothing_ > protects inode->i_size any more, and you can get basically random > values. That would be bad. > > 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/ - 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
Linus Torvalds wrote: > > I'd love to link against libgcc, but for the fact that > > - gcc developers have sometimes done horribly stupid things, and NOT >linking against libgcc has been an excellent way of not getting >bitten by it. Things like the exception handling etc, where not >linking against libgcc caused the kernel to not link - where that was >the RIGHT thing to do, because gcc had inserted completely bogus >exception handling into the code. > >Proper fix: -fno-exceptions > > - 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. > > 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. > > So again, not linking libgcc showed a problem. Good for us. > > 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 > - Linus, You forgot to mention that some folks also code with C++ in these user libs -- result, new and constructor/destructor operations will create all kinds of hidden memory allocations all over the place that the C++ compiler hides from the coder and that impact performance. NetWare uses a model close to yours with a pico-kernel-lib for the kernel proper and all the other lib crap goes up in the user environment -- the kernel does not link to any commercial libs either for the reasons you stated, and the problems with C++ code in kernel. C++ let's programmers get sloppy and lets them create convoluted code that is so unreadable and unmaintainable it assures job security. I sometimes believe this is why C++ was created to begin with. Alot of the W2K kernel is C++, which explains why it's such a pig. Structured exception handling is nice, but the hidden memory allocations can really bite on performance. :-) 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: /dev/f1
On Tue, 19 Sep 2000, Daniel Lange wrote: > Hi all, > I don't know how relevant to this list my question is, as I'm a quite > new subscriber, but I was perusing the linux kernel (2.2.16) Makefiles and > ran into this in /usr/src/linux/net/ethernet/Makefile: > >tar -cvf /dev/f1 . > I think you found an old remanent of something that's not used anymore. It exists even in 2.2.15: ./net/unix/Makefile:tar: ./net/802/Makefile:tar: ./net/appletalk/Makefile:tar: ./net/ax25/Makefile:tar: ./net/core/Makefile:tar: ./net/ethernet/Makefile:tar: ./net/ipv4/Makefile:tar: ./net/ipx/Makefile:tar: ./net/netrom/Makefile:tar: ./net/bridge/Makefile:tar: ./net/lapb/Makefile:tar: ./net/x25/Makefile:tar: ./net/rose/Makefile:tar: ./net/wanrouter/Makefile:tar: ./net/irda/Makefile:tar: ./net/irda/compressors/Makefile:tar: ./net/irda/ircomm/Makefile:tar: ./net/irda/irlan/Makefile:tar: `make -C $dir tar` is never executed from the top Makefile so it will never happen. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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] Useless inode semaphore locking in 2.4.0-test8
In article <[EMAIL PROTECTED]>, Eric PAIRE <[EMAIL PROTECTED]> wrote: > >In open.c:do_truncate(), the call to notify_change() is protected by >the inode->i_sem, which seems to me useless, and thus can be removed. And exactly how do you now protect against the race of another process doing a write() at the same time, and in particular the updates of "inode->i_size"? As far as I can tell, you removing the semaphore means that _nothing_ protects inode->i_size any more, and you can get basically random values. That would be bad. 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: __ucmpdi2
In article <[EMAIL PROTECTED]>, Richard Henderson <[EMAIL PROTECTED]> 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. > >That said, I also think it is a bug that the kernel does not link >against libgcc. I'd love to link against libgcc, but for the fact that - gcc developers have sometimes done horribly stupid things, and NOT linking against libgcc has been an excellent way of not getting bitten by it. Things like the exception handling etc, where not linking against libgcc caused the kernel to not link - where that was the RIGHT thing to do, because gcc had inserted completely bogus exception handling into the code. Proper fix: -fno-exceptions - 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. 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. So again, not linking libgcc showed a problem. Good for us. 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 - 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/
Linux kernel 2.2.17 appears not support >512M RAM Disk
On Linux kernel 2.2.17 running on an intel PIII system with 1GB RAM I cannot successfully create a ramdisk of greater than 512MB. The relevant kernel parameter (CONFIG_BLK_DEV_RAM_SIZE) was set to 737280 before rebuilding the kernel. So I do the following from the command line: dd bs=1024 if=/dev/zero of=/dev/ram0 count=737280 mke2fs /dev/ram0 524288 mount /dev/ram0 /ramdisk This works, but if I increase the size passed to mke2fs beyond 524288 (like to 700 megs or so... or anything in between), mke2fs succeeds, but mount does not! This happens even after a clean reboot. mount returns an error on the console of: EXT2-fs: Magic mismatch, very weird! mount: wrong fs type, bad option, bad superblock on /dev/ram0, or too many mounted file systems. /proc/meminfo indicates that a huge chunk of RAM has been set aside for buffers, but mount can't apparently make anything of what's there. I can try and provide more info if anybody would like. I'm rather stuck. Can anybody offer some insight as to a solution? Also, if I'm sending this to the wrong place, please redirect me. Thanks Ryan Tokarek Unix SysAdmin Wolfram Research (not speaking for my employer) - 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
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.
>> >
>> > -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
>> @@ -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 {
>>
>
>
>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
-
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/
/dev/f1
Hi all, I don't know how relevant to this list my question is, as I'm a quite new subscriber, but I was perusing the linux kernel (2.2.16) Makefiles and ran into this in /usr/src/linux/net/ethernet/Makefile: tar -cvf /dev/f1 . Since I do all my compiling for the i386 tree, I don't know if this line is ever executed, but I can't seem to find any documentation on /dev/f1. I've looked in /usr/src/linux/Documentation/devices.txt, and it's not in there. So what is this "f1" device? It almost sounds like it should be a floppy device, but I can't be sure of that. Thanks for the info. Dan Lange - 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 (patch)
Rik van Riel <[EMAIL PROTECTED]> writes:
> This is a bug in Andrea's idea. The request should only
> be inserted at the end of the list if:
>
> 1) the block numbre is bigger than head->prev (which you
>already have)
>
> AND
>
> 2) the block number is smaller than head (or head->next
>if the current request is unplugged)
The second condition is not so simple in the case of latency control.
Consider the following queue:
sector: 100 200 300 400 10 20 30
sequence: 1 1 1 1 0 1 1
In this case it would be correct to insert 150 at the end even though
it is >100, because no more requests are allowed to pass the "10"
request.
It is however possible to decide in O(1) time if the correct insertion
point is at the end of the queue. We have to keep track of the point,
p, where no more requests may pass. (10 in the example above.) The logic
would then be:
int insert_at_tail = 0;
if (IN_ORDER(p, last)) {
if (IN_ORDER(last, req) || IN_ORDER(req, p))
insert_at_tail = 1;
} else {
if (IN_ORDER(last, req) && IN_ORDER(req, p))
insert_at_tail = 1;
}
if (insert_at_tail) {
/* Do it in O(1) */
} else {
/* Do normal O(n) scan and update latencies */
}
The question is if this is worth the extra code complexity. How long
can the request queue be? Does it have a fixed upper size, or is it
limited only by available memory? If the request queue is always
short, the O(n) complexity shouldn't matter. Note that the worst case
complexity is still O(n) for all algorithms discussed so far.
--
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: GCC proposal for "@" asm constraint
On Tue, Sep 19, 2000 at 07:22:48PM +0200, Jamie Lokier wrote: > That instruction loads the _value_ of p. I.e. reads the memory from > location 0x80495a4 into %eax. The source instruction was: > >movl p,%eax > > The instructions that you're thinking of, that load fixed addresses, > look like these: > >mov $0x80495a4,%eax >lea 0x80495a4,%eax > > or in source form: > >movl $p,%eax >leal p,%eax Thanks for noticing my error. 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: stuck on TLB IPI wait (CPU#0) at 2.2.17+reiserfs+ide+raid
Thanks, Chris Mason, > > few weeks ago, I installed a PROMISE Ultra66 IDE card into my SMP Linux > > box. But my box sometimes hang up at high load average with "stuck on TLB > > IPI wait (CPU#0)" messages. > > My kernel is linux-2.2.17 with following patches. > > linux-2.2.17-reiserfs-3.5.25-patch.gz > > ide.2.2.17.all.2904.patch.bz2 > > raid-2.2.17-A0 > This is a known issue with the way reiserfs uses the scheduler task queue. > The following patch from Andi Kleen should take care of it for you: > > --- linux/kernel/sched.c-oWed Feb 9 14:27:20 2000 > +++ linux/kernel/sched.c Wed Mar 29 12:53:41 2000 > @@ -803,6 +803,7 @@ > goto handle_bh_back; > > handle_tq_scheduler: > + __sti(); > run_task_queue(&tq_scheduler); > goto tq_scheduler_back; After using this patch, My linux box work very well with high load average and heavy disk access application like encoding MP3s. Thank you very much and best regards, -- W [EMAIL PROTECTED] |O-O| Hisaaki Shibata @ Fukuoka-shi JAPAN 0(mmm)0 P-mail: 070-5419-3233IRC: #luky ~http://his.luky.org/ last update:2000.3.12 - 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 10:23:05AM -0700, Richard Henderson wrote: > On Tue, Sep 19, 2000 at 04:32:16PM +0200, Andrea Arcangeli wrote: > > Wrong: it's really loading the _address_. > [...] > > 80483f5: a1 a4 95 04 08 mov0x80495a4,%eax > >^^^ ^ > > No, that's an absolute memory load. If we were loading > the address, there'd be a '$' before that number. I see. So Jamie was right and we reproduced a case of miscompilation. 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] Fix queued SIGIO
On Mon, 18 Sep 2000, Alan Cox wrote: >> The problem is really that SI_SIGIO is negative, but it should be positive >> to make SI_FROMUSER return false on it. >> >> Changing it would unfortunately break binary compatibility. This patch > 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). 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. Robert -- Robert de Vries [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: 2.4.0-test9-pre3 boots, 2.4.0-test9-pre4 doesn't (SCSI)
On Tue, 19 Sep 2000, Andries Brouwer wrote: > > The same here. However, reverting the 1-line change in > linux/drivers/scsi/Makefile makes things work again. Yes, the SCSI layer is fragile wrt some initialization ordering. The devfs setup in particular, but there might be other things there too. The one-liner changes the ordering slightly, but there are some other issues too, like the fact that we should order the linking to match the old detection order in hosts.c etc. Torben is working on it.. 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/
NMI Watchdog detected LOCKUP on CPU1 (stext_lock)(2.4.0-test9-pre2)
Hello, using 2.4.0-test9-pre2 and thinking that there are no major bugs I found this again, I have observed what I think it's the same bug since 2.4.0-test7. All the traces end up in stext_lock, so I think it' the same bug, this time it happened when I was about to use the iomega parport zip with autofs. The modprobe of ppa failed but it was inserted (???) because of the rename of sd.o back again to sd_mod.o ksymoops 2.3.4 on i586 2.4.0-test9-pre2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test9-pre2/ (default) -m /boot/System.map-2.4.0-test9-pre2 (specified) cpu: 0, clocks: 668188, slice: 222729 cpu: 1, clocks: 668188, slice: 222729 NMI Watchdog detected LOCKUP on CPU1, registers: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 0082 eax: 0306 ebx: 0246 ecx: 0006 edx: 0041b1cb esi: 0306 edi: 000c ebp: 5864 esp: c583ded8 ds: 0018 es: 0018 ss: 0018 Process syslogd (pid: 389, stackpage=c583d000) Stack: c28aaf80 0002 c015db32 0306 c28aaf80 0001 c28aaf80 0006 c015dd03 0001 c28aaf80 c28aad40 c10e7878 c38ee8bc 0400 c01256b5 0001 0001 c583df30 c1054460 c28aaf80 c012576e Call Trace: [] [] [] [] [] [] [] [] [] Code: f3 90 7e f5 e9 a6 da f7 ff 80 3d 90 e7 21 c0 00 f3 90 7e f5 >>EIP; c01df3aa<= Trace; c015db32 Trace; c015dd03 Trace; c01256b5 Trace; c012576e Trace; c01257cd Trace; c0125680 Trace; c0150c6d Trace; c0133526 Trace; c01094b7 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 Code; c01df3b3 9: 80 3d 90 e7 21 c0 00 cmpb $0x0,0xc021e790 Code; c01df3ba 10: f3 90 repz nop Code; c01df3bc 12: 7e f5 jle9 <_EIP+0x9> c01df3b3 NMI Watchdog detected LOCKUP on CPU0, registers: CPU:0 EIP:0010:[] EFLAGS: 0082 eax: 0306 ebx: 0246 ecx: 0006 edx: 0041b1cb esi: 0306 edi: 000c ebp: 801e esp: c5fb1f74 ds: 0018 es: 0018 ss: 0018 Process kflushd (pid: 5, stackpage=c5fb1000) Stack: c5edeaa0 0002 c015db32 0306 c5edeaa0 0001 c5edeaa0 0006 c015dd03 0001 c5edeaa0 0007 c14e2260 0001 c5fb 0400 c0136149 0001 0001 c5fb1fd8 0001 c5fb 0ad0 Call Trace: [] [] [] [] [] Code: f3 90 7e f5 e9 a6 da f7 ff 80 3d 90 e7 21 c0 00 f3 90 7e f5 >>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 Code; c01df3b3 9: 80 3d 90 e7 21 c0 00 cmpb $0x0,0xc021e790 Code; c01df3ba 10: f3 90 repz nop Code; c01df3bc 12: 7e f5 jle9 <_EIP+0x9> c01df3b3 -- Jorge Nerin <[EMAIL PROTECTED]> <[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, 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... -- 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: Question: Using floating point in the kernel
** 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/
Re: GCC proposal for "@" asm constraint
On Tue, Sep 19, 2000 at 04:32:16PM +0200, Andrea Arcangeli wrote: > Wrong: it's really loading the _address_. [...] > 80483f5: a1 a4 95 04 08 mov0x80495a4,%eax >^^^ ^ No, that's an absolute memory load. If we were loading the address, there'd be a '$' before that number. 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: Question: Using floating point in the kernel
[EMAIL PROTECTED] (Michael Vines) writes:
> I was just wondering if you can use floating point while servicing a
> syscall in the kernel? Doing a
> find -name \*.c -exec grep float {} \; -print
> turned up a couple drivers that seem to be using fp. Are there any
> known issues that I should to be aware off?
You can not use floating point in the kernel, for the reasons
Richard gave you.
That said, after some checking I actually did find two offenders that
generate floating point instructions in 2.4.0-test6.
These are:
drivers/video/sgivwfb.c and
drivers/video/sisfb.c
(authors cc:ed)
//Marcus
--
---+---
Marcus Sundberg| Phone: +46 707 452062
Embedded Systems Consultant | Email: [EMAIL PROTECTED]
Cendio Systems AB | http://www.cendio.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: 2.4.0-test9-pre3 boots, 2.4.0-test9-pre4 doesn't (SCSI)
On Tue, Sep 19 2000, Andries Brouwer wrote: > On Tue, Sep 19, 2000 at 11:29:31AM -0400, Simon Kirby wrote: > > Hello, > > > > 2.4.0-test9-pre3 seems to boot and work fine, but 2.4.0-test9-pre4 with > > the same .config doesn't. It stops here: > > The same here. However, reverting the 1-line change in > linux/drivers/scsi/Makefile makes things work again. > I'm doing a patch to fix the link order of scsi. This will hopefully fix most problems. Stay tuned... -- 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: SCSI scanning changes break RAID autorun
On Tue, 19 Sep 2000, Linus Torvalds wrote:
> > moving the software RAID drivers into drivers/md/,
> Make it so.
OK. Apply the attached diff and then:
$ mv drivers/block/{md,raid{0,1,5},xor}.c drivers/md/
and all might be well.
The Config.in should probably move at some stage too.
I'm not very au-fait with the kernel build system (nor
makefiles in general) so I'm not sure it's 100% correct,
but it build and linked with my .config, so it can't be
all bad.
Matthew.
diff -ruN linux-2.4.0-test8/Makefile linux/Makefile
--- linux-2.4.0-test8/Makefile Sun Sep 10 12:36:04 2000
+++ linux/Makefile Tue Sep 19 17:40:20 2000
@@ -176,6 +176,7 @@
DRIVERS-$(CONFIG_I2C) += drivers/i2c/i2c.o
DRIVERS-$(CONFIG_PHONE) += drivers/telephony/telephony.a
DRIVERS-$(CONFIG_ACPI_INTERPRETER) += drivers/acpi/acpi.o
+DRIVERS-$(CONFIG_BLK_DEV_MD) += drivers/md/mddev.o
DRIVERS += $(DRIVERS-y)
diff -ruN linux-2.4.0-test8/drivers/Makefile linux/drivers/Makefile
--- linux-2.4.0-test8/drivers/Makefile Sun Sep 3 19:35:31 2000
+++ linux/drivers/Makefile Tue Sep 19 17:16:40 2000
@@ -12,7 +12,7 @@
ALL_SUB_DIRS := $(SUB_DIRS) pci sgi ide scsi sbus cdrom isdn pnp i2o \
ieee1394 macintosh video dio zorro fc4 \
usb nubus tc atm pcmcia i2c telephony \
- acpi mtd input
+ acpi mtd input md
ifdef CONFIG_DIO
SUB_DIRS += dio
@@ -128,6 +128,15 @@
else
ifeq ($(CONFIG_SCSI),m)
MOD_SUB_DIRS += scsi
+ endif
+endif
+
+ifeq ($(CONFIG_BLK_DEV_MD),y)
+SUB_DIRS += md
+MOD_SUB_DIRS += md
+else
+ ifeq ($(CONFIG_BLK_DEV_MD),m)
+ MOD_SUB_DIRS += md
endif
endif
diff -ruN linux-2.4.0-test8/drivers/block/Makefile linux/drivers/block/Makefile
--- linux-2.4.0-test8/drivers/block/MakefileSun Sep 3 19:35:02 2000
+++ linux/drivers/block/MakefileTue Sep 19 17:45:30 2000
@@ -14,7 +14,7 @@
O_TARGET := block.o
-export-objs:= ll_rw_blk.o blkpg.o loop.o DAC960.o md.o xor.o
+export-objs:= ll_rw_blk.o blkpg.o loop.o DAC960.o
list-multi := lvm-mod.o
lvm-mod-objs := lvm.o lvm-snap.o
@@ -35,12 +35,6 @@
obj-$(CONFIG_BLK_CPQ_DA) += cpqarray.o
obj-$(CONFIG_BLK_DEV_DAC960) += DAC960.o
obj-$(CONFIG_BLK_DEV_LVM) += lvm-mod.o
-
-obj-$(CONFIG_BLK_DEV_MD) += md.o
-obj-$(CONFIG_MD_LINEAR)+= linear.o
-obj-$(CONFIG_MD_RAID0) += raid0.o
-obj-$(CONFIG_MD_RAID1) += raid1.o
-obj-$(CONFIG_MD_RAID5) += raid5.o xor.o
obj-$(CONFIG_BLK_DEV_NBD) += nbd.o
diff -ruN linux-2.4.0-test8/drivers/md/Makefile linux/drivers/md/Makefile
--- linux-2.4.0-test8/drivers/md/Makefile Thu Jan 1 01:00:00 1970
+++ linux/drivers/md/Makefile Tue Sep 19 17:45:22 2000
@@ -0,0 +1,29 @@
+#
+# Makefile for the kernel software RAID drivers.
+#
+
+O_TARGET := mddev.o
+SUB_DIRS :=
+ALL_SUB_DIRS :=
+MOD_SUB_DIRS :=
+
+export-objs:= md.o xor.o
+
+obj-y :=
+obj-m :=
+obj-n :=
+obj- :=
+
+obj-$(CONFIG_BLK_DEV_MD) += md.o
+obj-$(CONFIG_MD_LINEAR)+= linear.o
+obj-$(CONFIG_MD_RAID0) += raid0.o
+obj-$(CONFIG_MD_RAID1) += raid1.o
+obj-$(CONFIG_MD_RAID5) += raid5.o xor.o
+
+# Translate to Rules.make lists.
+O_OBJS := $(filter-out $(export-objs), $(obj-y))
+OX_OBJS:= $(filter $(export-objs), $(obj-y))
+M_OBJS := $(sort $(filter-out $(export-objs), $(obj-m)))
+MX_OBJS:= $(sort $(filter $(export-objs), $(obj-m)))
+
+include $(TOPDIR)/Rules.make
Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 07:50:05AM -0700, Linus Torvalds wrote: > > > 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. Unless you define -Winline I always wondered why it isn't the default in the kernel source, I use it regularly. -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: relocation truncated to fit: R_386_PC32
Keith Owens wrote:
>
> Sections marked __exit get discarded when the code is linked into the
> kernel, they are kept when the code is a module. But the spin lock
> code is kept (in another section) and relocation from .text.lock back
> to .text.exit fails. Possible fixes:
>
> Use RTC as a module.
> Remove __exit from rtc_exit.
> Compile rtc_exit conditional on not being a module.
> Remove the spin locks.
... or
5) Delete paranoia check altogether.
Thanks,
Paul.
--- drivers/char/rtc.c~ Sun Jul 23 03:39:15 2000
+++ drivers/char/rtc.c Tue Sep 19 11:08:47 2000
@@ -723,17 +723,6 @@
static void __exit rtc_exit (void)
{
- /* interrupts and maybe timer disabled at this point by rtc_release */
- /* FIXME: Maybe??? */
-
- if (rtc_status & RTC_TIMER_ON) {
- spin_lock_irq (&rtc_lock);
- rtc_status &= ~RTC_TIMER_ON;
- del_timer(&rtc_irq_timer);
- spin_unlock_irq (&rtc_lock);
-
- printk(KERN_WARNING "rtc_exit(), and timer still running.\n");
- }
remove_proc_entry ("driver/rtc", NULL);
misc_deregister(&rtc_dev);
__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.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: 2.4.0-test9-pre3 boots, 2.4.0-test9-pre4 doesn't (SCSI)
On Tue, Sep 19, 2000 at 11:29:31AM -0400, Simon Kirby wrote: > Hello, > > 2.4.0-test9-pre3 seems to boot and work fine, but 2.4.0-test9-pre4 with > the same .config doesn't. It stops here: The same here. However, reverting the 1-line change in linux/drivers/scsi/Makefile makes things work again. 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: kernel governance
On Tue, 19 Sep 2000, Riley Williams wrote: > Additional comments from other developers should be cc'd to Tony as I > don't think he's on this list. However, I am on the list, so there is > no need to CC to me... > > > any hints? > > Well, I'm not even sure what you mean by "kernel governance" but the > way to get your code into the kernel is well documented. Here's a > basic summary of the procedure: > > 1. Subscribe to the Linux-Kernel mailing list. This is where > ALL issues relating to the ENTIRE Linux kernel are thrown > open for discussion. Some issues are _hardware_ specific. Quite often these don't make it to this list until after resolution on that _hardware_ list. For example, S390 bogomips are being discussed on the S390 list, but so far, there is no mention of that here. Later, Matt Unix is best described as an old, sturdy tree. It is well structured, always growing, and has passed the test of time. - 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/
generic scsi gone in 2.4.0test9pre4
Tried burning a cd with pre4 and devfs. There is no /dev/sg0 and /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: The INN/mmap bug
Daniel Phillips wrote: > Alexander Viro wrote: > > On Tue, 19 Sep 2000, Daniel Phillips wrote: > > > > > !Mapped, !Uptodate, Dirty: pending map and write > > > > Wrong. It's an instant BUG at line 711 in ll_rw_blk.c - remember these > > reports? Yes, correct, this state should not escape from prepare_write, though that's only a limitation of the current code. Here's the corrected, corrected table: Mapped, Uptodate, Dirty: pending write !Mapped, Uptodate, Dirty: not possible Mapped, !Uptodate, Dirty: not possible !Mapped, !Uptodate, Dirty: not possible Mapped, Uptodate, !Dirty: regular block !Mapped, Uptodate, !Dirty: hole of zeroes Mapped, !Uptodate, !Dirty: unread !Mapped, !Uptodate, !Dirty: pending map And here's the punchline: why not have 5 states instead of 3 bits and set the state with a single function call, instead of the mutiple bit sets we see now. -- 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: 2.2.17: set_rtc_mmss: can't update from 53 to 4
It looks like the reason for this error was that my hardware real time clock was not functioning properly. I ran the server's hardware diagnostics and that seems to have fixed the problem. >Date: Wed, 13 Sep 2000 17:04:02 -0700 >To: [EMAIL PROTECTED] >From: Kamlesh Bans <[EMAIL PROTECTED]> >Subject: 2.2.17: set_rtc_mmss: can't update from 53 to 4 > >On my system, in ./arch/i386/kernel/time.c, set_rtc_mmss is outputting the >messages > >Sep 13 15:40:04 newton kernel: set_rtc_mmss: can't update from 57 to 10 >Sep 13 15:41:05 newton kernel: set_rtc_mmss: can't update from 57 to 11 >Sep 13 16:04:08 newton kernel: set_rtc_mmss: can't update from 53 to 4 >Sep 13 16:05:09 newton kernel: set_rtc_mmss: can't update from 53 to 5 > >Any ideas on what the problem might be? I'm running kernel 2.2.17 with a >Debian 2.2 distribution on an HP NetServer 5/133 LS2 with dual Pentium >133's, 128 MB RAM, SCSI drives, no IDE, using an SMP kernel. > >Thanks, >Kamlesh Bans >Corsair Communications >Irvine, CA, USA >+1-949-838-3107 - 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, Alan Cox wrote: > > 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. > > You need to get the i2o scsi driver run last afte the low level and before > the high level drivers despite being in drivers/i2o. There are some other > drivers which arent in drivers/scsi too > Did anyone start to cook up a patch for this? Otherwise I'll take look tonight. (which is now, BTW.) -- 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: test9-pre4 bugs
On Tue, Sep 19 2000, Marko Kreen wrote: > Tried running pre4, here notes: > > 1) scsi devfs: /dev/scsi/host0 is now /dev/host0, /dev/scsi exist >but is empty. > 2) lots of messages: Warning - running *really* short on DMA buffers >No oops yet. > Probaly because we used the module part of dma pool allocation. I'll take a look at it. -- 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: Question: Using floating point in the kernel
On Tue, 19 Sep 2000, Michael Vines wrote:
> I was just wondering if you can use floating point while servicing a
> syscall in the kernel? Doing a
> find -name \*.c -exec grep float {} \; -print
> turned up a couple drivers that seem to be using fp. Are there any
> known issues that I should to be aware off?
>
> Thanks,
> Mike
>
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.
Note that many of the drivers, such as
../linux/drivers/net/hamradio/soundmodem, have programs which execute
during compile-time to generate tables of integer values. These programs,
which execute in user-mode during compile, can (and do) use any math that
they want including floating-point.
So a `grep` of the sources doesn't give you enough information. Also
there are some floating-point operations to be executed by the compiler,
the result being an integer constant such as:
long int radians = (long) (2.0 * 3.141592654 * (float) HZ);
You really need to look at the source to see if floating-point is
being used in the kernel. It should not be. Sometimes, there are
little bits that sneak through. This usually doesn't hurt anybody
because it occurs once during the startup code of a driver. Now
that drivers can be modules, that can be inserted at any time, it
is particularly important to make sure FP operations are not occurring
to print some simple sign-on string.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
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: The INN/mmap bug
Alexander Viro wrote: > > On Tue, 19 Sep 2000, Daniel Phillips wrote: > > > The more I think about it the less clear and ambiguous I find it. > > When you add the dirty bit into the pot you get: > > > >Mapped, Uptodate, Dirty: not possible > > Sure, it is possible - that's how the write happens > > > !Mapped, Uptodate, Dirty: not possible > >Mapped, !Uptodate, Dirty: pending write > > s/pending write/obvious bug/, damnit. Daniel, just think for a second: we > have the buffer read to be picked by bdflush and written to disk, while > the _contents_ _is_ _not_ _uptodate_. Just what can you expect when write > succeeds? Junk on disk, right? You know, GIGO queue - garbage in, garbage > out... > > > !Mapped, !Uptodate, Dirty: pending map and write > > Wrong. It's an instant BUG at line 711 in ll_rw_blk.c - remember these > reports? It wasn't a conceptual error, it was a typo: here's the corrected table with the wrongly tagged states you noticed interchanged: Mapped, Uptodate, Dirty: pending write !Mapped, Uptodate, Dirty: not possible Mapped, !Uptodate, Dirty: not possible !Mapped, !Uptodate, Dirty: pending map and write Mapped, Uptodate, !Dirty: regular block !Mapped, Uptodate, !Dirty: hole of zeroes Mapped, !Uptodate, !Dirty: unread !Mapped, !Uptodate, !Dirty: pending map > Sure, the dirty bit is not orthogonal to the rest. You don't need to do > any complex analysis - it's as simple as > * if I don't know _where_ to write the data - I'ld better not feed > the request to ll_rw_block(), or it may get PO'd > * if I know that data is junk - I don't want it hitting the disk. > > Dirty bit == request fed into the funnel and can be on disk any moment now. > Locked == already in IO subsystem. > > That's it - completely independent from the rest, except that you don't > want the whole write mechanism applied to non-uptodate or non-mapped > pieces. Right, two obvious bugs, which is the same thing as saying two uneeded states. Now, I'm just trying to be tidy and fit this all into a nice regular model that I can represent with state transition diagrams. I don't know for sure why it's good to do that, but it seems good. I like to imagine that if I could just get them all down on paper in a regular form some possible optimizations would just jump right out at me. Mind you, this is not necessary for the filesystem work I'm doing, this is more like a side interest. I get along just fine with the existing mechanism. > Think about IO as a memory bus - cache controller deals with writing the > cache line to RAM, but you don't want it to try that on lines that don't > have PA already calculated or have invalid contents. "mark dirty" == point > the write-behind mechanism to it and let it decide when the thing must be > written. I'd also like it to be able to decide on its own when to map the block. If I'm fully replacing the contents of a buffer on a page I would like to be able to just mark the buffer dirty without mapping it and let bdflush map it later. Right now it doesn't work because bdflush tries to feed a null block to ll_rw_block, but a small change would fix that: the flush daemon just has to notice the buffer is on a page, then it can call get_block to map it. Does this accomplish anything useful? I *think* so but I'm not sure. It seems to me that if you handled this properly you could have, for example, a temporary file written, read back and deleted, all without ever touching the disk, or even going into get_block to check for mappings, let alone fussing around with the allocation bitmaps. I'm also trying to determine if a 'don't know' mapping state would be useful for optimizing certain I/O paths. > Think how to make the cache indexed by virtual address (not by > physical, as in case of x86) work correctly. That's what pagecache is - > software MMU with cache-by-VA architecture. -- 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: __ucmpdi2
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. That said, I also think it is a bug that the kernel does not link against libgcc. 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: News gateway not working
Followup to: <[EMAIL PROTECTED]> By author:"Chris Swiedler" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > I didn't want to post to the list with this, but [EMAIL PROTECTED] > didn't get a reply. > > The NNTP gateway hasn't been working for two weeks-- the last list message > was 9/2/2000. Maybe this is common knowledge on the list (since I'm not > subscribed, I obviously wouldn't know...) but it's a little discouraging to > get absolute silence on fa.linux.kernel. If the problem is known, then > someone should post directly to the newsgroup and let us know when it might > be fixed. I know there were some massive changes when the list switched to > new servers, and hopefully that's the reason and it can be fixed soon. > > For many people, the newsgroup is a much easier way to read the list, and > furthermore it reduces the load on vger, because otherwise we'd have to > subscribe. So please...look kindly on us. > You'd have to talk to the administrator of that gateway. Unfortunately, the centralized gateway (linux.dev.kernel) was shut down by decree due to someone's idea that doing so would stop spam, so everyone has been running their own little hacks with various levels of success. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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/
2.4.0-test9-pre3 boots, 2.4.0-test9-pre4 doesn't (SCSI)
Hello, 2.4.0-test9-pre3 seems to boot and work fine, but 2.4.0-test9-pre4 with the same .config doesn't. It stops here: agpgart: AGP aperture is 64M @ 0xe400 aha152x: processing commandline: ok aha152x: BIOS test: passed, detected 1 controller(s) aha152x: resetting bus... aha152x0: vital data: rev=1, io=0x140 (0x140/0x140), irq=9, scsiid=7, reconnect=enabled, parity=enabled, synchronous=enabled, delay=100, extended translation=disabled aha152x0: trying software interrupt, ok. scsi0 : Adaptec 152x SCSI driver; $Revision: 2.0 $ scsi : 1 host. (Nothing more.) Pressing sysreq-p gives me always the same EIP, c01088ed. System.map: c01088c0 t default_idle c01088f4 t poll_idle This is a dual CPU machine. Both aha152x and aic7xxx are compiled in, but I only compiled aha152x in as of test9-pre2 as it seemed to break when used as a module then (it would loop endlessly detecting my scanner over and over again infinitely -- it got up to sg50something and I rebooted). Perhaps something else is broken that's just showing up differently now, as the test9-pre3 to test9-pre4 diff is pretty small and I don't see anything obviously broken. On test9-pre3, the next lines are: (scsi1) found at PCI 0/6/0 (scsi1) Wide Channel, SCSI ID=7, 32/255 SCBs (scsi1) Downloading sequencer code... 392 instructions downloaded ...etc. .config.gz attached. Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] config.gz
Re: SCSI scanning changes break RAID autorun
On Tue, 19 Sep 2000, Matthew Kirkwood wrote: > > It's probably solely an init-order thing but, short of > moving the software RAID drivers into drivers/md/, I > can't see an easy way to fix it. That would probably not be a bad fix - especially as some people want to split up xor.c into multiple files and I'd hate to clutter up drivers/block any more than necessary anyway. Make it so. [ Btw, has autorun ever worked with non-scsi devices? They've mostly had the new initialization order for a long time.. ] 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: [RFC] Wine speedup through kernel module
Daniel Pittman <[EMAIL PROTECTED]> wrote: > Hrm. It would seem more sensible to me that the registry, like the GDI, > live outside the kernel. This would have some cost in terms of > performance, I admit, but I don't think it's significant enough to care. > > This is, I confess, based on my personal experience with Win32 > development and may not represent the real state of affairs for all > developers. > > Having registry access be performance critical or for large data is also > against the MicroSoft best practice for software, which makes the costs > lower - no multiple calls to ship large quantities of data. :) > > 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. 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. 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. > 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. However, what I said about system handles and the registry, may also apply to GDI objects. > In any case, I would have expected (personally, from assumptions) that > the GDI would live inside the process space and pay the same cost as > existing X11 applications to do it's display. Yes, that is my current plan. > 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. David Howells - 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-pre3: sit tunnel problems
GM> ifconfig sit0 up tunnel ::206.123.31.102 GM> SIOCSIFDSTADDR: No buffer space available Tunnel (or smth. like that) support is missing from the kernel. Load the module or recompile kernel. It has helped me with the same message with ipip tunnels for multicast routing. -- Meelis Roos ([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: GCC proposal for "@" asm constraint
On Tue, Sep 19, 2000 at 04:01:26PM +0100, David Howells wrote: > I can't remember exactly what it was now, but I think it was either something > to do with spinlocks or bitops. I'll re-investigate tonight and see if I can > come back with some benchmarks/code-snippets tomorrow. Yes you should tell us which is the inlined function that generated different asm (if you post the two differnt asm or the two different .o we can probably find it ourself). I seen the rw_spin_locks are silly requesting the address of the spinlock to be in the register eax when the address of the spinlock isn't a constant (while it should instead at least use "r" and not "a") and I was going to fix it, however that's not changed between test7 and test8... 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/
Question: Using floating point in the kernel
I was just wondering if you can use floating point while servicing a
syscall in the kernel? Doing a
find -name \*.c -exec grep float {} \; -print
turned up a couple drivers that seem to be using fp. Are there any
known issues that I should to be aware off?
Thanks,
Mike
-
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've been writing a kernel module and I've noticed a measurable performance drop between the same code compiled against linux-2.4.0-test7 and against test8. I disassembled the code to try and work out what was going on and I saw the following happen: * [test8] One of the atomic memory access primitives supplied by the kernel was putting immediate data into a register outside of the inline-asm instruction group and then using the register inside. * [test7] The immediate data was passed directly to the inline-asm instruction. In test8, of course, this means that the compiler has to scratch up a spare register, which is totally unnecessary, as the immediate data could be attached directly to the instruction opcode as was done in test7. This had the effect of making the compiler have to push the old contents of the register into a slot on the stack (I think it held a local variable at the time), which had the further effects of using more stack memory, introducing more register rearrangement (the code ended up longer), and burning up more CPU cycles. I can't remember exactly what it was now, but I think it was either something to do with spinlocks or bitops. I'll re-investigate tonight and see if I can come back with some benchmarks/code-snippets tomorrow. David Howells - 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:58:48AM -0300, Rik van Riel wrote: > One of the issues which seems to be affecting performance > is the elevator starvation bug, though, so I'm not sure how You are contraddicting yourself. If you decrease the latency (so if you fix the starvation) the global disk throughput can only decrease. > Once the elevator problem has been solved, we should be able I'm tired of you screwing up the VM and then complaining the elevator. At least try to vary and choose something else to complain. At test1 time you may been right, but now we're so permissive in the default settings exactly to be sure the elevator isn't hurting performance. 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
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. And the error message you get is ld: undefined function 'serial_paranoia_check' which is not exactly helpful. That, together with the fact that gcc's notion of "large" is completely undefined (for a while, it had absolutely nothing to do with size, but with what kinds of things the function did, like having the address of a label taken) means that it's basically not useful for what you suggest anyway.. 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] Re: SCSI scanning
> 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. You need to get the i2o scsi driver run last afte the low level and before the high level drivers despite being in drivers/i2o. There are some other drivers which arent in drivers/scsi too - 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: Very aggressive swapping after 2 hours rest
On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote: > what I wanted to do in the new VM, except that I didn't > see why we would want to restrict it to swap pages only? You _must_ do that _only_ for the swap_cache, that's a specific issue of the swap_cache during swapout (notenote: not during swapin!). 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/
Warning - Running *really* short on DMA buffers with test9-pre4
Hi all!! I just compiled 2.4.0-test9-pre4 and get the following error in my syslog: Warning - Running really short on DMA buffers. I dont have any ISA-devices installed and no device is in /proc/dma. I always thought that DMA buffers are only for "old" DMA on ISA bus ... The system runs stable (so far ...) Any idea?? Cheers Markus - 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
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 - Original Message - From: "Linus Torvalds" <[EMAIL PROTECTED]> To: "Torben Mathiasen" <[EMAIL PROTECTED]>; "Russell King" <[EMAIL PROTECTED]> Cc: "Eric Youngdale" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, September 18, 2000 6:58 PM Subject: Re: [PATCH] Re: SCSI scanning > > Ok, there's a test9-pre3 there now.. > > The SCSI stuff is pretty straightforward, and it works for me (and I also > built a kernel with all regular x86-capable SCSI drivers included, so the > others got at least that level of testing). But there are some non-x86 > scsi drivers out there etc, so give it a whirl. > > Basic approach: remove all #ifdef MODULE, and get rid of the hosts.c > hardcoded listing of SCSI devices - let SCSI controller drivers do their > own initialization. > > Linus > > > - pre1: > - USB: OHCI controller unlink and bandwidth reclamation fixes > - USB: storage update > - sparc64: register window race. Non-deadlock rwlocks. > - name clash in hamradio/pi2.c and hamradio/pt.c > - epic100 credits, 8139too driver update, sr.c initcalls > - acenic update > - NFS sillyrename fixups > - mktime(). Do it just once - not 16 times. > - misc small fixes to random drivers by Tigran > - IDE driver picks up master/slave relationships on its own. > - truncate unmapped/uptodate case handled correctly > - don't do notifier locking at low level: higher levels do (or > should do) this already. > - ACPI interpreter updates (and file renames - making this part big) > - SysKonnect gigabit driver update > - 3c59x driver update > - pcmcia debounce logic. Ugh. > - MM balancing (Rik Riel) > - pre2: > - "extern inline" -> "static inline". It doesn't matter right now, > but it's proactive for future gcc versions. > - various net drvr updates and fixes > - more initcall updates > - PPC updates (including PPC-related drivers etc) > - disallow re-mounting same filesystem in same place multiple times. > Too confusing. And /etc/mtab gets strange. > - Riel VM update > - sparc updates > - PCI bridge scanning fix: assign numbers properly > - network updates > - scsi fixes > - pre3: > - uninitialized == zero. Remove extra initializers. > - block_prepare_write and block_truncate_page: if the page is > up-to-date, then so are the buffer heads inside it once they > are mapped.. > - SCSI initialization - move over to the modular case. No more > double initialization. > - Sync up with Alans 2.2.x driver changes > - networking updates (iipv6 works non-modular etc) > - netfilter update > - adfs correct dentry operations > - ARM update (including ARM drivers) > - acenic driver update > - floppy: we'd better hold the io_request_lock when playing with "CURRENT". > - NFS cache coherency across file locking fix > - NFS over TCP - handle TCP socket writability right.. > - USB updates > - To unsubscribe from this list: send the line "unsubscrib
new MM and shared memory
Hi Rik et al. As stated before the new mm does break shm swapping. Under the ipctst program driving my machine into swap I get the appended console output. After this it locked up. I can make it run longer by giving mem= with less memory. Greetings Christoph -- LILO boot: test Loading testLinux version 2.4.0-test9 (root@ls3016) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #5 SMP Mon Sep 18 15:28:34 CEST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009dc00 @ (usable) BIOS-e820: 2400 @ 0009dc00 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: 03ef8000 @ 0010 (usable) BIOS-e820: 7c00 @ 03ff8000 (ACPI data) BIOS-e820: 0400 @ 03fffc00 (ACPI NVS) BIOS-e820: ec00 @ 0400 (usable) BIOS-e820: 0140 @ fec0 (reserved) BIOS-e820: 00011000 @ 0001 (usable) Warning only 896MB will be used. Use a PAE enabled kernel. Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000f65e0 hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. hm, page 0009d000 reserved twice. hm, page 0009e000 reserved twice. On node 0 totalpages: 229376 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: INTELProduct ID: OCPRF100 APIC at: 0xFEE0 Processor #7 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Bootup CPU Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Processor #1 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Processor #2 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Processor #3 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Processor #4 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Processor #5 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Processor #6 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Bus #0 is PCI Bus #1 is PCI Bus #2 is PCI Bus #3 is PCI Bus #4 is ISA I/O APIC #8 Version 19 at 0xFEC0. Int: type 3, pol 1, trig 1, bus 4, IRQ 00, APIC ID 8, APIC INT 00 Int: type 0, pol 1, trig 1, bus 4, IRQ 01, APIC ID 8, APIC INT 01 Int: type 0, pol 1, trig 1, bus 4, IRQ 00, APIC ID 8, APIC INT 02 Int: type 0, pol 1, trig 1, bus 4, IRQ 03, APIC ID 8, APIC INT 03 Int: type 0, pol 1, trig 1, bus 4, IRQ 04, APIC ID 8, APIC INT 04 Int: type 0, pol 3, trig 3, bus 0, IRQ 28, APIC ID 8, APIC INT 3a Int: type 0, pol 1, trig 1, bus 4, IRQ 06, APIC ID 8, APIC INT 06 Int: type 0, pol 1, trig 1, bus 4, IRQ 07, APIC ID 8, APIC INT 07 Int: type 0, pol 3, trig 1, bus 4, IRQ 08, APIC ID 8, APIC INT 08 Int: type 0, pol 1, trig 1, bus 4, IRQ 09, APIC ID 8, APIC INT 09 Int: type 0, pol 3, trig 3, bus 0, IRQ 00, APIC ID 8, APIC INT 3b Int: type 0, pol 3, trig 3, bus 0, IRQ 29, APIC ID 8, APIC INT 12 Int: type 0, pol 1, trig 1, bus 4, IRQ 0c, APIC ID 8, APIC INT 0c Int: type 0, pol 1, trig 1, bus 4, IRQ 0d, APIC ID 8, APIC INT 0d Int: type 0, pol 1, trig 1, bus 4, IRQ 0e, APIC ID 8, APIC INT 0e Int: type 0, pol 3, trig 3, bus 1, IRQ 1c, APIC ID 8, APIC INT 24 Int: type 0, pol 3, trig 3, bus 0, IRQ 30, APIC ID 8, APIC INT 30 Int: type 0, pol 3, trig 3, bus 0, IRQ 3f, APIC ID 8, APIC INT 31 Int: type 0, pol 3, trig 3, bus 1, IRQ 00, APIC ID 8, APIC INT 3b Int: type 0, pol 3, trig 3, bus 2, IRQ 00, APIC ID 8, APIC INT 3b Int: type 0, pol 3, trig 3, bus 3, IRQ 00, APIC ID 8, APIC INT 3b Lint: type 3, pol 1, trig 1, bus 4, IRQ 00, APIC ID ff, APIC LINT 00 Lint: type 1, pol 1, trig 1, bus 0, IRQ 00, APIC ID ff, APIC LINT 01 Processors: 8 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) Kernel command line: auto BOOT_IMAGE=test ro root=801 console=tty0 console=ttyS0,38400n8 Initializing CPU#0 Detected 550070964 Hz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1097.73 BogoMIPS Memory: 899124k/
Re: GCC proposal for "@" asm constraint
On Mon, Sep 18, 2000 at 09:37:43PM -0400, John Wehle wrote:
> It's perhaps not optimal, however I'm not sure that it's wrong. In
It's not "wrong" in the sense that something breaks but it's definitely
suboptimal. There's no reason to reload a value that can't change because it's
embedded into the opcodes of the asm and set a static linking time.
> any case if you can supply a small standalone test case (i.e. preprocessed
> source code) I'll take a quick look at things. I take it that you haven't
> tried the current gcc sources?
The first testcase is the current spinlock implementation, the second testcase
adds the "memory" clobber and it generates the _spurious_ reload of `p'. You
should be able to compile with `gcc -O2 -S p-*.i`.
Andrea
# 1 "p.c"
# 1 "/home/andrea/kernel/devel/2.2.18pre9aa1/include/linux/spinlock.h" 1
# 1 "/usr/include/asm/spinlock.h" 1 3
# 134 "/usr/include/asm/spinlock.h" 3
typedef struct {
volatile unsigned int lock;
} spinlock_t;
typedef struct { unsigned long a[100]; } __dummy_lock_t;
# 169 "/usr/include/asm/spinlock.h" 3
typedef struct {
volatile unsigned int lock;
unsigned long previous;
} rwlock_t;
# 231 "/usr/include/asm/spinlock.h" 3
# 249 "/usr/include/asm/spinlock.h" 3
# 3 "/home/andrea/kernel/devel/2.2.18pre9aa1/include/linux/spinlock.h" 2
# 1 "p.c" 2
int * p;
spinlock_t lock = (spinlock_t) { 0 } ;
void dummy(int x , int y) {}
main() {
int a, b;
__asm__ __volatile__( "\n1:\t" "lock ; btsl $0,%0\n\t" "jc 2f\n" ".section
.text.lock,\"ax\"\n" "2:\t" "testb $1,%0\n\t" "jne 2b\n\t" "jmp 1b\n" ".previous"
:"=m" ((*(__dummy_lock_t *)( &lock )) )) ;
a = *p;
__asm__ __volatile__( "lock ; btrl $0,%0" :"=m" ((*(__dummy_lock_t *)( &lock
)) )) ;
__asm__ __volatile__( "\n1:\t" "lock ; btsl $0,%0\n\t" "jc 2f\n" ".section
.text.lock,\"ax\"\n" "2:\t" "testb $1,%0\n\t" "jne 2b\n\t" "jmp 1b\n" ".previous"
:"=m" ((*(__dummy_lock_t *)( &lock )) )) ;
b = *p;
__asm__ __volatile__( "lock ; btrl $0,%0" :"=m" ((*(__dummy_lock_t *)( &lock
)) )) ;
dummy(a,b);
}
# 1 "p.c"
# 1 "/home/andrea/kernel/devel/2.2.18pre9aa1/include/linux/spinlock.h" 1
# 1 "/usr/include/asm/spinlock.h" 1 3
# 134 "/usr/include/asm/spinlock.h" 3
typedef struct {
volatile unsigned int lock;
} spinlock_t;
typedef struct { unsigned long a[100]; } __dummy_lock_t;
# 169 "/usr/include/asm/spinlock.h" 3
typedef struct {
volatile unsigned int lock;
unsigned long previous;
} rwlock_t;
# 231 "/usr/include/asm/spinlock.h" 3
# 249 "/usr/include/asm/spinlock.h" 3
# 3 "/home/andrea/kernel/devel/2.2.18pre9aa1/include/linux/spinlock.h" 2
# 1 "p.c" 2
int * p;
spinlock_t lock = (spinlock_t) { 0 } ;
void dummy(int x , int y) {}
main() {
int a, b;
__asm__ __volatile__( "\n1:\t" "lock ; btsl $0,%0\n\t" "jc 2f\n" ".section
.text.lock,\"ax\"\n" "2:\t" "testb $1,%0\n\t" "jne 2b\n\t" "jmp 1b\n" ".previous"
:"=m" ((*(__dummy_lock_t *)( &lock )) ) : : "memory") ;
a = *p;
__asm__ __volatile__( "lock ; btrl $0,%0" :"=m" ((*(__dummy_lock_t *)( &lock
)) ) : : "memory") ;
__asm__ __volatile__( "\n1:\t" "lock ; btsl $0,%0\n\t" "jc 2f\n" ".section
.text.lock,\"ax\"\n" "2:\t" "testb $1,%0\n\t" "jne 2b\n\t" "jmp 1b\n" ".previous"
:"=m" ((*(__dummy_lock_t *)( &lock )) ) : : "memory") ;
b = *p;
__asm__ __volatile__( "lock ; btrl $0,%0" :"=m" ((*(__dummy_lock_t *)( &lock
)) ) : : "memory") ;
dummy(a,b);
}
Re: The INN/mmap bug
On Tue, 19 Sep 2000, Daniel Phillips wrote: > The more I think about it the less clear and ambiguous I find it. > When you add the dirty bit into the pot you get: > >Mapped, Uptodate, Dirty: not possible Sure, it is possible - that's how the write happens > !Mapped, Uptodate, Dirty: not possible >Mapped, !Uptodate, Dirty: pending write s/pending write/obvious bug/, damnit. Daniel, just think for a second: we have the buffer read to be picked by bdflush and written to disk, while the _contents_ _is_ _not_ _uptodate_. Just what can you expect when write succeeds? Junk on disk, right? You know, GIGO queue - garbage in, garbage out... > !Mapped, !Uptodate, Dirty: pending map and write Wrong. It's an instant BUG at line 711 in ll_rw_blk.c - remember these reports? >Mapped, Uptodate, !Dirty: regular block > !Mapped, Uptodate, !Dirty: hole of zeroes >Mapped, !Uptodate, !Dirty: unread > !Mapped, !Uptodate, !Dirty: pending map > Those two 'not possible' states bother me, they show that the three > bits are not orthogonal. We can make arbitrary assignments of meaning > to them as you did with !Mapped, !Uptodate (pending map) but in that > case why not just enumerate all the states we need and lose the bit > assignments? I think the deep problem here is trying to look at this > as a bit-flipping problem instead of a state-transition problem. Sure, the dirty bit is not orthogonal to the rest. You don't need to do any complex analysis - it's as simple as * if I don't know _where_ to write the data - I'ld better not feed the request to ll_rw_block(), or it may get PO'd * if I know that data is junk - I don't want it hitting the disk. Dirty bit == request fed into the funnel and can be on disk any moment now. Locked == already in IO subsystem. That's it - completely independent from the rest, except that you don't want the whole write mechanism applied to non-uptodate or non-mapped pieces. Think about IO as a memory bus - cache controller deals with writing the cache line to RAM, but you don't want it to try that on lines that don't have PA already calculated or have invalid contents. "mark dirty" == point the write-behind mechanism to it and let it decide when the thing must be written. Think how to make the cache indexed by virtual address (not by physical, as in case of x86) work correctly. That's what pagecache is - software MMU with cache-by-VA architecture. - 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 (patch)
On Tue, Sep 19, 2000 at 07:17:42AM -0300, Rik van Riel wrote: > This is a bug in Andrea's idea. The request should only > be inserted at the end of the list if: > > 1) the block numbre is bigger than head->prev (which you >already have) If you read the code you'll see that in his previous patch he wasn't doing that. That's what I suggested to change to return in O(1) behaviour. > 2) the block number is smaller than head (or head->next >if the current request is unplugged) You're wrong. While the queue is unplugged there are peaks in the queue caused by the latency control and head->next is not guarnateed to be the lower block in the queue. 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 (patch)
On Tue, Sep 19, 2000 at 04:50:26AM -0300, Rik van Riel wrote: > When the latency gets above 10 minutes, I'd call it starvation ;) Me too, no argument about that. > Not average latency no, but the starvation issue should be > fixed... 2.2.18pre9aa1 delivers acceptable latency for me with the same latency control logic of 2.4.x. I will check test9 soon. 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/
nfsv3 lockd causes kernel oops
Hi,
Ever since the introduction of the new file locking code in 2.4.x,
NFS locking has been seriously broken. A preliminary look seems to
indicate that the problems might lie in the generic locking code: when
running the connectathon tests against another server I get crap like
panic("Attempting to free lock with active wait queue")
This occurs regularly when running the various child process/parent
process locking tests (essentially those tests which activate the lock
blocking).
This needs to be fixed before we release the final 2.4.0. I'll see
if I can't find time to look into it myself in the course of the week,
however I'm trying hard not to get too distracted from writing up my
thesis. It would therefore be nice if Willy and/or others familiar
with the file locking could take a look too.
In the meantime, perhaps Ted could put this issue into his TODO
list?
Cheers,
Trond
> " " == Christian Brandes <[EMAIL PROTECTED]> writes:
> Hi!
> I've been trying to setup an NFSv3 server that supports
> nfs_lock.
> So I installed RedHat 7.0beta (6.9.5) and built a 2.4.0-test7
> kernel. During boot up I noticed that the launching of
> nfslockd did not succed, might be that I do not have the right
> nfs-tools. I use the ones that are provided with the distrib
> (nfs-utils-0.1.9.1-5).
> I did try out what happens when I lock a file by nfs. I started
> my little test program twice on a client machine:
> #include include include include
> # include include
> #include include
> int main (void) {
> int fd; int rc; printf ("\n"); fd = open("./t1", O_RDWR); rc
> = flock(fd, LOCK_EX ); printf ("rc: %d\n", rc); sleep (30);
> printf ("exit\n");
> }
> And the result was a kernel Oops on the server:
> locks_insert_block: removing duplicated lock (pid=59714
> 0-9223372036854775807 type=1) Unable to handle kernel NULL
> pointer dereference at virtual address 0004
> printing eip:
> c013b88e *pde = Oops: 0002 CPU: 0 EIP:
> 0010:[locks_delete_block+14/48] EFLAGS: 00010286 eax: c586f86c
> ebx: ecx: c586f878 edx: esi: c586f878 edi:
> cfe1a9f0 ebp: cfe1a9f0 esp: c581def8 ds: 0018 es: 0018 ss: 0018
> Process lockd (pid: 2368, stackpage=c581d000) Stack: c586f86c
> c013b8e7 c586f86c c0224e60 e942
>7fff 0001 cfcbcc08 cfcbc81c c586f800 c013ce4d
>cfe1a9f0 c586f86c c016d7cd cfe1a9f0 c586f86c c586f800
>c0171c69 c5983400 c581df58 cfcbc7d0
> Call Trace: [locks_insert_block+55/112] [tvecs+18936/114884]
> [posix_block_lock+13/16] [nlmsvc_lock+685/720]
> [nlm4svc_retrieve_args+169/240] [nlm4svc_proc_lock+149/224]
> [svc_process+729/1248]
>[lockd+423/576] [lockd+0/576] [kernel_thread+43/64]
> Code: 89 5a 04 89 13 89 48 0c 89 48 10 8d 48 04 8b 59 04 8b 50
> 04
> I would be glad if you could tell me what went wrong and how I
> could solve the problem.
> Thanx a lot
> Christian Brandes
> --
> C H R I S T I A N B R A N D E S
> CAxOPEN product development technology GmbH
> Sauerwiesen 2, D-67661 Kaiserslautern
> E-Mail: [EMAIL PROTECTED]
> Tel.: +49 6301 70919 0 Fax: +49 6301 70919 59
> --
-
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: The INN/mmap bug
Linus Torvalds wrote: > > On Mon, 18 Sep 2000, Alexander Viro wrote: > > * we have several bh state components and the thing is a big, > > fscking mess. If we look at the areas outside of the page lock we have: > > It's not a mess at all. > > I don't see why you call things "first stage" etc. It's perfectly > straightforward. There are two bits that matter: > - buffer uptodate > - buffer mapped. > > And the state is very clear and unambiguous: > > Mapped, Uptodate: regular block > !Mapped, Uptodate: hole of zeroes > Mapped, !Uptodate: unread > !Mapped, !Uptodate: "pending map" > > No "several states" at all. The more I think about it the less clear and ambiguous I find it. When you add the dirty bit into the pot you get: Mapped, Uptodate, Dirty: not possible !Mapped, Uptodate, Dirty: not possible Mapped, !Uptodate, Dirty: pending write !Mapped, !Uptodate, Dirty: pending map and write Mapped, Uptodate, !Dirty: regular block !Mapped, Uptodate, !Dirty: hole of zeroes Mapped, !Uptodate, !Dirty: unread !Mapped, !Uptodate, !Dirty: pending map Those two 'not possible' states bother me, they show that the three bits are not orthogonal. We can make arbitrary assignments of meaning to them as you did with !Mapped, !Uptodate (pending map) but in that case why not just enumerate all the states we need and lose the bit assignments? I think the deep problem here is trying to look at this as a bit-flipping problem instead of a state-transition problem. I'm not saying that the current design can't be made to work. It can, it's practically working now - it's just confusing as Al said, and there are reasons for that. It gets more confusing when you add in the less-than-simple relationship between buffers and pages and then try to make sense of the combination of the two sets of states. The motivation for making this less confusing is to be able to think about optimization possibilities instead of just making it work. -- 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: [PATCH] Fix queued SIGIO
On Tue, 19 Sep 2000, Julian Anastasov wrote:
> On Mon, 18 Sep 2000, Andi Kleen wrote:
>
> > > SI_SIGIO is not generated from kernel. The same is for the
> > > other SI_ consts < 0 not defined with __SI_CODE.
> >
> > Ok, then you have already broken binary compatibility between 2.2 and 2.4
>
> Looking in the old kernels, it seems the binary compatibility
> was broken in 2.3.21 when si_code returns POLL_xxx events just like
> mentioned in "The Single UNIX ® Specification, Version 2",
> xsh/signal.h.html and not SI_SIGIO.
>
> SI_SIGIO in si_code for 2.2 does not return any information
> about the events. I even see that Redhat maintains patch against 2.2
> to backport the POLL_xxx events from 2.3. Not sure after the changes
> in 2.4.0-test1. Anyway, 2.2 looks unusable for me and I don't see other
> way this problem to be fixed. The binary compatibility is impossible
> to exist. The applications can support the both ways: the old SI_SIGIO
> and the new POLL_xxx events (recompiled after test1) in si_code.
because the 2.2 kernels are already "broken" in this regard, i can't see
how binary compatibility between 2.2 and 2.4 could even be an
issue. applications can't use this stuff in 2.2 without at least the
RedHat patch.
unless there's a problem implementing a glibc that runs on both 2.2 and
2.4, perhaps this should be revisited.
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;
}
has always been unclear as to its intent. it seems like there is
overloading going on here -- if the real intent is to prevent users
without credentials from sending "kernel-only" signals, then that should
be the logic here.
> The next step is somebody to implement event merging and to
> allow receiving of many events with one call. For the next 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.
- Chuck Lever
--
corporate: <[EMAIL PROTECTED]>
personal: <[EMAIL PROTECTED]>
The Linux Scalability project:
http://www.citi.umich.edu/projects/linux-scalability/
-
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/
2.4.0-test9-pre4 OOPS
I don't see the oops in my logs and couldn't copy it down because I was on my way to class. Looked like swapper barfed. The file mentioned was buffer.c I think. Sorry I couldn't grab more details. I'll be sure to try if it happens again. Anyone else seeing anythign similar? -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [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: Hardware performance counter overflow
On Mon, 18 Sep 2000, John Rafferty Zedlewski wrote: > Hi, I've noticed that there are quite a few hardware performance counter > patches (which allow access to things like the Pentium Model Specific > Registers for gathering profiling info) floating around, including Rabbit > (http://www.scl.ameslab.gov/Projects/Rabbit/), Richard Gooch's patches, and > PAPI (very cool and portable, IMHO). But I haven't seen any of these that > supports delivering interrupts when counters overflow (the last version of > PAPI that I saw provides high-level emulation of this on Linux/x86, but > it's not really accurate enough for serious work). > Is there any other patch that supports overflows on Linux/x86, or is it > work that still needs to be done? Monitoring these overflows is the trick > behind large parts of Intel's VTune and SGI's SpeedShop, and I'd love to > see a profiler like this come to Linux. Basically, I'm a student and I > think it would be an interesting project, but I don't want to re-invent the > wheel unnecessarily. > Thanks a lot! > --JRZ It is on its way. I just have to get the profiler I've written through the university's administration, and it will be available under the GPL. The approach taken is similar to DCPI, but with some differences. It still needs some work however, but will prove to be useful I think. Ask if you want more info. thanks john -- "I bet the human brain is a kludge." - Marvin Minsky - 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: experimental, non-production bits.
Alexander Viro wrote: > ??? You had explicitly enabled the code that was marked "experimental". If > the warning from make config was not enough, how the hell would runtime > warning be more useful? Yeah, you see, If you have about 100 Linux servers to maintain, part your own, part installed by someone else, part standard installation, then this question does make sense too, but is still irrelevant to outcome which is needed "now, after few counted hours and for sure". In such a situation you just want that feature, however principially wrong the whole setup of the question and path of your own actions might be. elmer. - 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/
News gateway not working
I didn't want to post to the list with this, but [EMAIL PROTECTED] didn't get a reply. The NNTP gateway hasn't been working for two weeks-- the last list message was 9/2/2000. Maybe this is common knowledge on the list (since I'm not subscribed, I obviously wouldn't know...) but it's a little discouraging to get absolute silence on fa.linux.kernel. If the problem is known, then someone should post directly to the newsgroup and let us know when it might be fixed. I know there were some massive changes when the list switched to new servers, and hopefully that's the reason and it can be fixed soon. For many people, the newsgroup is a much easier way to read the list, and furthermore it reduces the load on vger, because otherwise we'd have to subscribe. So please...look kindly on us. chris - 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
Jeff Garzik 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
> existing interface, and has been discussed before. (search past lkml
> subject headers for "media tool" and "ethtool")
>
> This updated patch should take some of the past threads into account.
> The differences from the current sparc ethtool.h are:
>
> * bitmask for advertising as well as supported media types
> * interrupt mitigation hints max{tx,rx}pkt (Jes suggestion)
> * four reserved u32 slots for future expansion
> * assigned an ioctl: SIOCETHTOOL (0x8944)
>
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.
I've made some edits (revised patch attached here).
* With this interface I don't see a way in which one can force some
settings but leave others unforced. Suppose, for example, that I wish
to force 10mbps but to leave the setting of the transceiver type,
duplex, etc alone (ie: up to the driver/hardware to determine the value
of these).
If you do an ETHTOOL_SSET/modify/ETHTOOL_SGET on the interface you'll
end up *forcing* all these settings into whatever state they happened to
be in when you did the read, no?
So I added the `force_mask' which should be tested by the ETHTOOL_SSET
handler to decide which fields are actually being forced.
When the driver receives a ETHTOOL_SGET it should populate `force_mask'
to indicate to the caller which fields are currently forced.
* I added SUPPORTED_MAC_FLOWCTRL/ADVERTISED_MAC_FLOWCTRL for advertising
of 802.3x MAC-layer flow control.
* I added the `flow_ctrl' field to say whether we want to enable/disable
this.
Other comments:
* There don't seem to be enough port types and transceiver types.
10base2? BNC? 100baseTx/100baseFX?
* Regarding the ADVERTISED bits. Are these designed to read back what
we're currently advertising, or are they designed to allow us to force
what is to be advertised? Both, I guess.
* maxtxpkt and maxrxpkt seem highly specific to particular hardware and
particular drivers. Plus there are a large range of other
driver-specific performance tunables which are typically controlled by
module parms. Why pick these two?
It may be better to bury this sort of thing into a device-specific
anonymous field. Shrug - don't bother: I wouldn't expect anyone to
really use these things because it's such a PITA to tear down all the
driver data structures and rebuild them.
* Are you really, really sure about the alignment issues with struct
ethtool_cmd? It strikes me that burying a short and five chars in among
a bunch of longs is asking for trouble. Suppose the caller is using a
different compiler? If you're not sure, make 'em all u32 :)
On a related topic, it offends me that when you unplug the RJ45 from a
win2k machine it pops up a little box telling you your network has
disappeared. We can't do that.
At present, SIOCGIFFLAGS returns an amalgam of __LINK_STATE_START and
__LINK_STATE_NOCARRIER in IFF_RUNNING. We need to separate these out so
applications can query __LINK_STATE_NOCARRIER independently. We also
need a select()able interface so changes in carrier can be monitored.
The users of a select()able carrier detect would be desktop UIs and the
high-availability guys. The latter is a guess - I don't really know if
people who are concerned about failover would find a carrier-lost
indication useful. TBD.
--- linux-2.4.0-test9-pre4/include/linux/ethtool.h Thu Jan 1 10:00:00 1970
+++ linux-akpm/include/linux/ethtool.h Tue Sep 19 23:09:38 2000
@@ -0,0 +1,114 @@
+/* $Id: ethtool.h,v 1.1.186.1 2000/09/16 20:13:14 jgarzik Exp $
+ * ethtool.h: Defines for Linux ethtool.
+ *
+ * Copyright (C) 1998 David S. Miller ([EMAIL PROTECTED])
+ */
+
+#ifndef _LINUX_ETHTOOL_H
+#define _LINUX_ETHTOOL_H
+
+/* This should work for both 32 and 64 bit userland. */
+struct ethtool_cmd {
+ u32 cmd;
+ u32 force_mask; /* Which fieldswe wish to force */
+ u32 supported; /* Features this interface supports */
+ u32 advertising;/* Features this interface advertises */
+ u16 speed; /* The forced speed, 10Mb, 100Mb, gigabit */
+ u8 duplex; /* Duplex, half or full */
+ u8 flow_ctrl; /* 802.3x flow control */
+ u8 port; /* Which connector port */
+ u8 phy_address;
+ u8 transceiver;/* Which tranceiver to use */
+ u8 autoneg;/* Enable or disable autonegotiation */
+ u32 maxtxpkt; /* Tx pkts before generating tx int */
+ u32 maxrxpkt; /* Rx pkts before generating rx int */
+ u32 reserved[4];
+};
+
+
+/* CMDs currently supported */
+#define ETHTOOL_GSET 0x0001 /* Get settings, non-privileged. */
+#define ETHTOOL_SSET 0x0002 /* Set settings, privileged. */
+
+/* compatibilit
Re: kernel governance
Hi Tony. > sorry for the cold call - i've been trying to find a statement > about 'kernel governance' and how new code is accepted into the > kernel... To help anybody else wondering about these issues, I've cc'd my reply to the Linux-Kernel mailing list for comments. However, please note that the comments herein are expressions of my own opinions, and may not reflect those of other developers. Additional comments from other developers should be cc'd to Tony as I don't think he's on this list. However, I am on the list, so there is no need to CC to me... > any hints? Well, I'm not even sure what you mean by "kernel governance" but the way to get your code into the kernel is well documented. Here's a basic summary of the procedure: 1. Subscribe to the Linux-Kernel mailing list. This is where ALL issues relating to the ENTIRE Linux kernel are thrown open for discussion. I will warn you in advance that this is a VERY active list and it is not unusual to get 300+ emails a day in that one list. My personal record from the Linux-Kernel list alone is 793 emails in one day. Make sure you can handle emails in that sort of volume first. 2. Monitor the list for AT LEAST 15 DAYS to see what issues are being discussed at the moment. In particular, watch out for ANY emails from "Linus Torvalds" or "Alan Cox" which mention such things as "Feature Freeze". 3. When you are satisfied with your understanding of the dynamics of the Linux-Kernel mailing list, post an email (sent using "Plain Text" mode - HTML emails are IGNORED by MANY of the kernel developers simply because of the volume of mail on the list. This email should contain a description of the purpose of your code, and should have attached to it (in MIME format) a PATCH against the relevant CURRENT kernel source tree that is in UNIFIED DIFF FORMAT. This format is generated by applying the -u4 parameter to the diff command. Note that the patch should NOT be embedded in the text of the email as doing so will almost certainly make the patch useless - it will either get munged by your email sending software or by the recipients mail reading software. Either the subject line or the descriptive text MUST state which kernel the patch file was generated against, and the email MUST have a subject line, preferably with the word PATCH in upper case together with a short (less than 40 character) description of what issue the patch deals with. Note that the current kernels can normally be determined by pointing your web browser to http://www.kernel.org and scrolling down to the bottom of the page. 4. Watch out for comments on your patch, and DEAL WITH THEM. Some people just ignore any comments, apparently on the assumption that they know what the kernel needs better than those who have been working on it far longer than they have, and after a while, the developers just stop reading their emails. You will also receive comments from people who have either just plain misunderstood your post, or who operate on the basis that their code is sacrosanct and your patch against it isn't worth considering as a result. Again, you will have to find a way of dealing with them. One basic rule here though: NEVER FLAME ANYBODY - NOT EVEN IN RESPONSE TO A FLAME. You'll only get yourself a bad name and reputation by doing so. The following are common reasons for patches posted to the Linux Kernel Developers mailing list being rejected: a. The patch is too complex. A patch that deals with too many issues will be rejected simply because of its size, as those who are responsible for the relevant part(s) of the kernel just don't have time to go through them. If you have dealt with several issues and the patches for each issue do not overlap, send the relevant patch for each issue in a separate email dealing just with that issue. If you have dealt with several issues and the patches overlap, you basically have two choices: 1. If the patch dealing just with the issues that overlap is not too large (say less than 50 lines in length), send a combined patch dealing just with the issues that overlap, and enumerate precicely which issues are dealt with, emphasising that they overlap. 2. If the patch is too large, decide which of the issues is "most important" and send a patch dealing just with that issue. Wait to see what happens to that patch, then send a patch against the result dealing with the next most important issue. Note that in this context, where there are three or more patches overlapping, the "most important" patch is often the one that has the result of de-overlapping most of the other patches. Note that "patches overlap" in the above means tha
Re: experimental, non-production bits.
On Tue, 19 Sep 2000, Elmer Joandi wrote: > Alexander Viro wrote: > > > How about syslog? > > Well, I read syslog a lot at home and servers, but customer on-site > production computer deep reconfiguration , > there is another paradigm - it either works 100% or I dont care. That's nice, but I don't know anyone who could fix problems just by "it called ufs_error() for some reason, no, I don't remember the error message". > Looks from general talk here, that some kernel people should try > servicing some customers on-site with house full of people waiting > their stable results within 24 hours and their ass being kicked if they > do not succeed. WTF? BTDT, didn't put beta quality code on production boxen. > It is a bit more generic. Just to get an automatic warning for each module > which is marked experimental, so that I could rely on that, so I dont need to > dig back 100 versions of source code. ??? You had explicitly enabled the code that was marked "experimental". If the warning from make config was not enough, how the hell would runtime warning be more useful? - 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_tty_baud_rate() on sparc64
Hi, 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 ? Flo -- Florian Lohoff [EMAIL PROTECTED] +49-5201-669912 "Write only memory - Oops. Time for my medication again ..." - 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/
experimental, non-production bits.
Alexander Viro wrote: > How about syslog? Well, I read syslog a lot at home and servers, but customer on-site production computer deep reconfiguration , there is another paradigm - it either works 100% or I dont care. Looks from general talk here, that some kernel people should try servicing some customers on-site with house full of people waiting their stable results within 24 hours and their ass being kicked if they do not succeed. > > and non-production modules. > > So after a year someone would not try to use that stuff on production system. > > Well, the better way is to fix the bloody thing... It is a bit more generic. Just to get an automatic warning for each module which is marked experimental, so that I could rely on that, so I dont need to dig back 100 versions of source code. Another idea: experimental bit. Kernel would have two bits: non-production and experimental. Whenever such a subsystem is activated, those bits remain on until reboot. elmer. - 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: The INN/mmap bug
On Tue, 19 Sep 2000, Rik van Riel wrote:
> IMHO it would be really nice if this problem was solved
> on the /PAGE/ level, so it will work for non-buffer
> filesystems as well ;)
It would be nice if we separated the buffer-cache storage pages from the
pagecache buffer-using ones and from the swap ones - logics is seriously
different and using the same code for all of them... Not good. We can
distinguish between them just by looking at ->mapping, AFAICS.
BTW, I suspect that combination of partial block_flushpage() with
block_truncate_page() should be address_space method (different for NFS,
etc., indeed). Then truncate_inode_pages() would become much simpler
("get rid of pages that went off-limits" rather than "... and do some part
of the work on the partial page". Oh, and block_flushpage() would
be simpler that way.
-
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: /proc/sys/vm/freepages not writable.
On Tue, Sep 19, 2000 at 04:52:25AM -0300, Rik van Riel wrote: > > I don't like self tuning algorithms for this case, because they > > tend to cause a disruption on the first spike (e.g. causing lots > > of packets dropped first until the VM can adapt). When the admin > > says "I don't care if 10MB are wasted, I want it this way" > > explicitely he should get his will. > > Indeed, you are right. I'll add this feature shortly. It would be nice if you could do it via freepages again, then documentation would not need to be rewriten. Even if some of the numbers are meaningless now, e.g. the middle number could give a goal for the VM. -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] Useless inode semaphore locking in 2.4.0-test8
On Tue, 19 Sep 2000, Stephen C. Tweedie wrote: > > ? > > I'm afraid that I've lost you here - what do you mean? > > loop does a bmap() and then submits block IO. You don't want > truncate() to revoke blocks in between the bmap and the IO completion. It used to do bmap(), but unless somebody restored that bogosity it shouldn't do that anymore. It gets page, locks it, does prepare_write(), copies the data, does commit_write() and unlocks the page - same as generic_file_write(). So that shouldn't be a problem - truncate would have to wait until the page gets unlocked. - 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] test9pre2 / sb
Marko Kreen <[EMAIL PROTECTED]> wrote:
>Reproducible oops: 'gmix -i --sm-disable' on test9-pre2.
The fix exists but it seems it isn't merged yet.
>--
--- soundcard.c.origTue Sep 19 12:37:52 2000
+++ soundcard.c Tue Sep 19 12:38:45 2000
@@ -267,6 +267,7 @@
DEB(printk("sound_release(dev=%d)\n", dev));
switch (dev & 0x0f) {
case SND_DEV_CTL:
+ dev >>= 4;
if (mixer_devs[dev]->owner)
__MOD_DEC_USE_COUNT (mixer_devs[dev]->owner);
break;
>--
--
_ x___ [EMAIL PROTECTED] (Peter Steiner)
/ \_/_\_ /,--' Linux User #55148 (http://counter.li.org/)
\/>'//
\_/ perl -e'while(<>){s/=\n//g;s/=([\dA-F]{2})/chr(hex($1))/eg;print;}'
-
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] Useless inode semaphore locking in 2.4.0-test8
On Tue, Sep 19, 2000 at 06:45:43AM -0400, Alexander Viro wrote: > > > On Tue, 19 Sep 2000, Stephen C. Tweedie wrote: > > > > ? > > > I'm afraid that I've lost you here - what do you mean? > > > > loop does a bmap() and then submits block IO. You don't want > > truncate() to revoke blocks in between the bmap and the IO completion. > > It used to do bmap(), but unless somebody restored that bogosity it > shouldn't do that anymore. It gets page, locks it, does prepare_write(), > copies the data, does commit_write() and unlocks the page - same as > generic_file_write(). So that shouldn't be a problem - truncate would have > to wait until the page gets unlocked. The new async loop device I'm playing with requires it again. -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-2.4.0-test9-pre4] file_table.c cleanup
Hi Linus,
a) in fget, file=NULL is not needed
b) removing _fput and __fput makes fput() code a lot more readable because
on their own _fput/__fput are meaningless and not used at all.
Please consider this patch. Fully tested under 2.4.0-test9-pre4.
Regards,
Tigran
--- linux/fs/file_table.c Fri Jul 28 09:58:59 2000
+++ work/fs/file_table.cTue Sep 19 11:29:13 2000
@@ -98,48 +98,35 @@
return 0;
}
-/*
- * Called when retiring the last use of a file pointer.
- */
-static void __fput(struct file *filp)
+void fput(struct file * file)
{
- struct dentry * dentry = filp->f_dentry;
- struct vfsmount * mnt = filp->f_vfsmnt;
+ struct dentry * dentry = file->f_dentry;
+ struct vfsmount * mnt = file->f_vfsmnt;
struct inode * inode = dentry->d_inode;
- if (filp->f_op && filp->f_op->release)
- filp->f_op->release(inode, filp);
- fops_put(filp->f_op);
- filp->f_dentry = NULL;
- filp->f_vfsmnt = NULL;
- if (filp->f_mode & FMODE_WRITE)
- put_write_access(inode);
- dput(dentry);
- if (mnt)
- mntput(mnt);
-}
-
-static void _fput(struct file *file)
-{
- locks_remove_flock(file);
- __fput(file);
-
- file_list_lock();
- list_del(&file->f_list);
- list_add(&file->f_list, &free_list);
- files_stat.nr_free_files++;
- file_list_unlock();
-}
-
-void fput(struct file * file)
-{
- if (atomic_dec_and_test(&file->f_count))
- _fput(file);
+ if (atomic_dec_and_test(&file->f_count)) {
+ locks_remove_flock(file);
+ if (file->f_op && file->f_op->release)
+ file->f_op->release(inode, file);
+ fops_put(file->f_op);
+ file->f_dentry = NULL;
+ file->f_vfsmnt = NULL;
+ if (file->f_mode & FMODE_WRITE)
+ put_write_access(inode);
+ dput(dentry);
+ if (mnt)
+ mntput(mnt);
+ file_list_lock();
+ list_del(&file->f_list);
+ list_add(&file->f_list, &free_list);
+ files_stat.nr_free_files++;
+ file_list_unlock();
+ }
}
struct file * fget(unsigned int fd)
{
- struct file * file = NULL;
+ struct file * file;
struct files_struct *files = current->files;
read_lock(&files->file_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/
Re: [PATCH] Useless inode semaphore locking in 2.4.0-test8
Hi, On Fri, Sep 15, 2000 at 08:31:43AM -0400, Alexander Viro wrote: > > Also truncate inode locking is needed to get a halfway reliable loopback > > device (unlike the current one) > > ? > I'm afraid that I've lost you here - what do you mean? loop does a bmap() and then submits block IO. You don't want truncate() to revoke blocks in between the bmap and the IO completion. Cheers, Stephen - 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, 1:08pm, Matti Aarnio wrote: > > On Tue, Sep 19, 2000 at 02:58:01AM -0700, Jeremy Higdon wrote: > > Hello, > > > > I'm using a 64 bit variable in a switch statement. Gcc is generating code > > which make calls to __ucmpdi2, a function defined in libgcc. I figured > > out that it was the switch statement from examining the generated code. > > > > The question is whether I should change C code to avoid constructions > > which make calls to this routine (a little hard to determine a priori) > > or if there is an appropriate way to add this to the kernel. > > Yes do change it. > > Is the value-space for the case's a LONG LONG, or > mere set of INTs or LONGs ? As it turns out, the values do fit into a 32 bit space, since they are a result of shifts and truncates. Perhaps a simple cast in the switch statement is all I need. > Can you simply (and reliably) cast the variable > into e.g. 'long' ? Or should you use if / else if / .. > chains ? I think either will work. Is there a little FAQ of C constructions you should not use if you are writing kernel code? It took a little doing to figure out that it was the switch that was causing trouble and not the shifts and arithmetic operations, and I'd like to avoid that in the future :-). > /Matti Aarnio > >-- End of excerpt from Matti Aarnio thanks 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: Rik's VM contains a deadlock somewhere
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/
Re: __ucmpdi2
Matti Aarnio <[EMAIL PROTECTED]> writes: |> On Tue, Sep 19, 2000 at 02:58:01AM -0700, Jeremy Higdon wrote: |> > Hello, |> > |> > I'm using a 64 bit variable in a switch statement. Gcc is generating code |> > which make calls to __ucmpdi2, a function defined in libgcc. I figured |> > out that it was the switch statement from examining the generated code. |> > |> > The question is whether I should change C code to avoid constructions |> > which make calls to this routine (a little hard to determine a priori) |> > or if there is an appropriate way to add this to the kernel. |> |> Yes do change it. |> |> Is the value-space for the case's a LONG LONG, or |> mere set of INTs or LONGs ? 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. Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg - 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 (patch)
On 18 Sep 2000, Peter Osterlund wrote: > Andrea Arcangeli <[EMAIL PROTECTED]> writes: > > > > The only disadvantage I can see is that the new patch doesn't handle > > > consecutive insertions in O(1) time, but then again, the pre-latency > > > > We can still do that by trivially fixing a bit your code. You should first > > check if the new inserted request is over the last in the current queue before > > entering the tmp1/tmp2 logic. > > Yes this can be done, but it will affect where requests are inserted. > Suppose the queue currently contains: > > 100 200 300 400 10 20 30 > > If request 150 is to be inserted, then with my previous patch it > will be inserted between 100 and 200, but with the proposed > change it will instead be inserted at the end. This is a bug in Andrea's idea. The request should only be inserted at the end of the list if: 1) the block numbre is bigger than head->prev (which you already have) AND 2) the block number is smaller than head (or head->next if the current request is unplugged) 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/
Re: uid
On Mon, 18 Sep 2000, Christopher Allen Wing wrote: .. snipped .. > tar should work okay, I think; by default it uses textual user names > instead of numeric UIDs. Not true. All the kernels I download from a certain local mirror are owned by the local user 'tarabas' since the uid happens to be the same with those on the mirror site. So numeric uids. - 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/
test9-pre4 bugs
Tried running pre4, here notes: 1) scsi devfs: /dev/scsi/host0 is now /dev/host0, /dev/scsi exist but is empty. 2) lots of messages: Warning - running *really* short on DMA buffers No oops yet. -- 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: __ucmpdi2
On Tue, Sep 19, 2000 at 02:58:01AM -0700, Jeremy Higdon wrote: > Hello, > > I'm using a 64 bit variable in a switch statement. Gcc is generating code > which make calls to __ucmpdi2, a function defined in libgcc. I figured > out that it was the switch statement from examining the generated code. > > The question is whether I should change C code to avoid constructions > which make calls to this routine (a little hard to determine a priori) > or if there is an appropriate way to add this to the kernel. Yes do change it. Is the value-space for the case's a LONG LONG, or mere set of INTs or LONGs ? Can you simply (and reliably) cast the variable into e.g. 'long' ? Or should you use if / else if / .. chains ? > Best I can tell, __ucmpdi2 takes two 64 bit unsigned args, returning > 0 if the 1st arg is less than the 2nd, 2 if greater, 1 if equal. For > now, I have defined the function in my driver with those semantics. > For obvious reasons, I don't consider this a viable long term option. > > thanks > jeremy /Matti Aarnio - 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/
__ucmpdi2
Hello, I'm using a 64 bit variable in a switch statement. Gcc is generating code which make calls to __ucmpdi2, a function defined in libgcc. I figured out that it was the switch statement from examining the generated code. The question is whether I should change C code to avoid constructions which make calls to this routine (a little hard to determine a priori) or if there is an appropriate way to add this to the kernel. Best I can tell, __ucmpdi2 takes two 64 bit unsigned args, returning 0 if the 1st arg is less than the 2nd, 2 if greater, 1 if equal. For now, I have defined the function in my driver with those semantics. For obvious reasons, I don't consider this a viable long term option. thanks 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: Oops with K6-2 350, but not with other CPUs.
On Tue, 19 Sep 2000, Daniel Grimwood wrote: > 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. 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)? I had a case that I needed to straighten the case because the machine would randomly lock the machine up, when reading the CMOS clock, or in any other operation, just freezing, no SysRq or anything. 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. Is there any third-party Kernel module involved? Please apologize if "to straighten" is not the proper word in the context, I'm not a native speaker and don't have a technical dictionary at hand. I mean bending the case until the mainboard can rest plane, on a level that all PCI, AGP, ISA cards are entirely inserted into their slots without rotation, bending and so on. -- Matthias Andree - 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/
SCSI scanning changes break RAID autorun
Hi, It would appear that the changes in pre3 and pre4 break RAID autorun. This is rather bothersome for those who have RAIDed root filesystems. It's probably solely an init-order thing but, short of moving the software RAID drivers into drivers/md/, I can't see an easy way to fix it. cheers, Matthew. - 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: Very aggressive swapping after 2 hours rest
On Mon, 18 Sep 2000, Byron Stanoszek wrote: > I've finally had a chance to test out the new VM patch on my 32mb system. > > It runs much, much better than the previous test8, and the > pages->swap change is actually much smoother than I had expected > it to be considering the recent talk about making it more > gradual. I'm against having the swap more gradual because of the > low amount of available memory and the high amount of memory > actually taken up by processes required for normal operation. > So, please take my opinions into consideration when/if you > redesign the swap mechanism. Oh I will. The "more smooth" swap code I am testing right now concentrates on swapping from processes that have been sleeping for longer than cache size / inactive_target seconds. I think this might actually help with the performance of low-memory systems, but I need to test this a bit before I know for sure ;) 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/
Re: [PATCH] Re: SCSI scanning
Jeff Garzik wrote: > Helge Hafting wrote: > > > > Rogier Wolff wrote: > > [...] > > > No, that's not it. They parse /proc/pci or the output of lspci to > > > determine which module to insert. > > > > Faster, and fine for pci-scsi. I believe you still need > > to testload modules for isa-scsi. > > When PCI probing fails, the user is often presented with a list of > possible drivers, and given the option of manually selecting their > driver (including possible autoprobing). Indeed. If I remember correctly an "autoprobe" for a CDROM device was able to tickle a network card into jamming the ethernet (BNC era). Stuff like that. Jamming as in: no packet comes through! Imagine that happening every time someone tries to install Linux. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - 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
Helge Hafting wrote: > > Rogier Wolff wrote: > [...] > > No, that's not it. They parse /proc/pci or the output of lspci to > > determine which module to insert. > > Faster, and fine for pci-scsi. I believe you still need > to testload modules for isa-scsi. When PCI probing fails, the user is often presented with a list of possible drivers, and given the option of manually selecting their driver (including possible autoprobing). 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: The INN/mmap bug
On Mon, 18 Sep 2000, Alexander Viro wrote: > On Sun, 17 Sep 2000, Linus Torvalds wrote: > > > And as we've seen, simplifying this area would not necessarily be a bad > > thing ;) > > > > Right now I'll just do the minimal fix, though, I think. > > Fine with me. I'll do the full analysis tonight, anyway, and try > to write down the rules for that stuff. One thing that makes me > seriously uneasy is the fact that VM knows about ->buffers - This doesn't make me happy either. It doesn't work for network-based filesystems, won't work with KIOBUF and will mean extra difficulties with filesystems that have write ordering constraints IMHO it would be really nice if this problem was solved on the /PAGE/ level, so it will work for non-buffer filesystems as well ;) (at least, for those problems which aren't specific to the disk-based filesystems only) > I'm not proposing it for immediate inclusion, but I don't feel > good about all this code - current rules are too complex and > rely on details of VM/buffer interaction too much for my taste. > It may be correct, but it's not obviously correct... Indeed... 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/
Re: [PATCH] Re: SCSI scanning
Rogier Wolff wrote: [...] > No, that's not it. They parse /proc/pci or the output of lspci to > determine which module to insert. Faster, and fine for pci-scsi. I believe you still need to testload modules for isa-scsi. Helge Hafting - 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: Very aggressive swapping after 2 hours rest
Byron Stanoszek wrote: > > I've finally had a chance to test out the new VM patch on my 32mb system. > > It runs much, much better than the previous test8, and the pages->swap change > is actually much smoother than I had expected it to be considering the recent > talk about making it more gradual. I'm against having the swap more gradual > because of the low amount of available memory and the high amount of memory > actually taken up by processes required for normal operation. > > At the moment, there's only room for about 5-6 meg of cache. If a gradual swap > goes into effect, then I'm afraid that the processes that actually 'need' to > stay in memory will start swapping out and thrashing, even when there's 6 meg > still available for use. This was precisely the problem with the old VM on my > machine, only the system wanted to keep 16 meg free for cache (*gag*). I hope we can have a swap mechanism that gradually writes stuff into swap early on, but don't actually unmap the memory. So we get clean pages that are still available but may be dropped quickly if needed. This will smooth things a bit without degrading performance. Some memory should be kept around for cache (if the processes do any io at all) or you'll get io trashing: the same stuff read over and over from files instead of from cache. And a read before every write that isn't a complete block. Almost all processes have some pages they don't use much, such as startup initialization. Swapping out that doesn't hurt. Helge Hafting - 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 Sun, 17 Sep 2000, Mark Orr wrote: > Has anyone else tried 240-test9-pre2 on low-memory systems? > > I compiled 240t9p2, bzlilo'ed it, and rebooted. During > boot it tripped up on e2fsck -- it was at maximum mount count > and it stopped during the check. > Sys: pentium 100, 16Mb RAM + 17 Mb swap This is interesting to hear. I'm doing tests booting my system with mem=8m and am busy trying to fix the performance of low-memory systems. One of the issues which seems to be affecting performance is the elevator starvation bug, though, so I'm not sure how much of the problem is a VM issue. (my test machine is SCSI and has a decent size queue in hardware so the elevator algorithm problem doesn't hit ... my workstation, with 192MB RAM and an IDE disk, is seeing the starvation though) Once the elevator problem has been solved, we should be able to see if there is still a big VM problem left, but the tests with low memory on my SCSI-based test box seem to suggest that it may well be an elevator related problem... 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/
Bugreport kernel 2.4.0-test8
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 Here are the two kernel oopses that occured on both tests: - kernel BUG at ll_rw_blk.c:711! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 001f ebx: cb4e5cc0 ecx: 001f edx: 0002 esi: cb4e5cc0 edi: cff3f298 ebp: 0001 esp: cff4bf34 ds: 0018 es: 0018 ss: 0018 Process kupdate (pid: 4, stackpage=cff4b000) Stack: c02876a5 c0287982 02c7 cb4e5cc0 0001 0020 001e8480 cff3f2b0 cff3f2a8 0008 c0187fef 00fe c0188c2d cff3f298 0001 cb4e5cc0 cb4e5cc0 0001 cff4bfd0 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 a0 de 35 c0 - kernel BUG at ll_rw_blk.c:711! invalid operand: CPU:1 EIP:0010:[] EFLAGS: 00010286 eax: 001f ebx: cf1152c0 ecx: 0097 edx: 0100 esi: cf1152c0 edi: cff3f298 ebp: 0001 esp: cff4bf34 ds: 0018 es: 0018 ss: 0018 Process kupdate (pid: 4, stackpage=cff4b000) Stack: c02876a5 c0287982 02c7 cf1152c0 0001 0020 001e8480 cff3f2b0 cff3f2a8 0008 c0187fef 00fe c0188c2d cff3f298 0001 cf1152c0 cf1152c0 0001 cff4bfd0 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 a0 de 35 c0 - After this, you StarOffice dies and can't even be killed via kill -9. On shutdown, the system hangs. After reboot, the /tmp filesystem was corrupted requiring manual fsck, which moves a file to lost+found (a temporary file from StarOffice). My system is otherwise rock solid, I switched back to kernel 2.4.0-test5 which is OK for me. I hope this helps, and please don't hurt me if this bug has already been reportet, but I don't read this list 'cause I'm not a developer. If you need to know more, feel free to contact me. greets, and go on with The Good Work mike -- // Ing. Michael Zieger, BSc. ---Zieger Michael EDV-Lösungen // http://www.zmi.at Linux 2.2.15 SMP // // May those who love us, love us. // And for those who don't love us, may the good Lord turn their hearts. // And if He can't turn their hearts, may He turn their ankles // So we'll know them by their limping. - 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
Andrea Arcangeli wrote: > int * p; > [...] > spin_lock(&lock); > a = *p; > spin_unlock(&lock); > > spin_lock(&lock); > b = *p; > spin_unlock(&lock); > [With "memory" clobber"] the [second] reload of the address of `p' > isn't necessary and gcc is wrong in generating it. Wrong, GCC is behaving correctly. > p is a constant embedded into the .text section and set at link time, p is a variable. The _address_ of p is constant, but the reload is not loading the address of p, it's loading the _value_. That value can be changed by other threads. In fact, you have demonstrated why the "memory" clobber is necessary for spinlocks. A perfect test case! In your first example, without the clobber, the asm code is incorrect. A parallel thread can change the value of p between the first spin_unlock and the second spin_lock, and the GCC-generated code does not notice. > The above reload are just wasted CPU cycles that we're little worried > to waste. Here, the saved cycle is a kernel bug. -- Jamie - 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/
Boot fails
Hello, Trying kernel 2.4.0-test9-pre3 and 2.4.0-test9-pre4 results in kernel panic with AIC-7890... Regards -- Angel Luis Uruñuela <> Unix Systems Administrator "You can't change the past, but you can ruin the present by worrying over the future" - 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
Linus Torvalds wrote: > > Maybe nobody ever insmod'ed a module for a scsi device they don't > > have? > > No, that's not it - the way most distributions do SCSI auto-detection is > to load modules until they succeed. > At least I _think_ that's what they do. That's what I'd do if I were a > distribution maker. No, that's not it. They parse /proc/pci or the output of lspci to determine which module to insert. At least I _think_ that's what they do. Not that I'd do it differently from you if I were a distribution maker. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - 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: Very aggressive swapping after 2 hours rest
On Sun, 17 Sep 2000, Andrea Arcangeli wrote: > I don't know the internals of other OSes so I've no idea if that > was a generic problem or not (guess why I started playing with > linux: just to finally see the internals of an OS :) thus I > don't know if this problem is generic or not. Please take the time to work on your background knowledge, it would be a good thing for you and for Linux. You're a smart guy and it's a shame to see you waste your time reinventing the wheel. > Just to make sure if we're talking about the same thing, do you > remeber when I told about the bigger problem under swap in > 2.4.x? I remeber I explained this to you, SCT and Alexey. Remember when I explained to you that this was exactly what I wanted to do in the new VM, except that I didn't see why we would want to restrict it to swap pages only? > If you fixed it I'm very happy and I thank you. If you have the time, please read the source of the new VM code. It would be nice to have your input on it too. 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/
[oops] test9pre2 / sb
Reproducible oops: 'gmix -i --sm-disable' on test9-pre2. Loaded sound modules: sb, gus (in this order) Oops itself: ksymoops 2.3.4 on i686 2.4.0-test9. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test9/ (default) -m /boot/System.map-2.4.0-test9 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel NULL pointer dereference at virtual address c88798c0 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010212 eax: ebx: c6b23c80 ecx: c8884fd8 edx: 0080 esi: c13eef40 edi: c7a0e6e0 ebp: c7a0d120 esp: c612fdfc ds: 0018 es: 0018 ss: 0018 Process gmix (pid: 325, stackpage=c612f000) Stack: c012d77b c7a0e6e0 c6b23c80 c6b23c80 c7fe4d40 0001 c012d7f9 c6b23c80 c6b23c80 c6b23c80 c012d83a c6b23c80 c012cb52 c6b23c80 c7fe4d40 0001 0006 c0119cf8 c6b23c80 c7fe4d40 c13dd620 c612e000 000b Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 00 85 c0 74 48 ff 48 10 8b 04 0a 8b 00 80 48 14 08 eb 3a >>EIP; c88798c0 <[sound]sound_release+28/7c> <= Trace; c012d77b <__fput+23/90> Trace; c012d7f9 <_fput+11/40> Trace; c012d83a Trace; c012cb52 Trace; c0119cf8 Trace; c011a30e Trace; c010951e Trace; c01122c7 Trace; c01f62fe Trace; c012e59f Trace; c0109184 Trace; c8884fd8 <[sound]mixer_devs+0/14> Trace; c88798c0 <[sound]sound_release+28/7c> Trace; c012d77b <__fput+23/90> Trace; c012d7f9 <_fput+11/40> Trace; c012d83a Trace; c012cb52 Trace; c012cb9f Trace; c010906f Code; c88798c0 <[sound]sound_release+28/7c> <_EIP>: Code; c88798c0 <[sound]sound_release+28/7c> <= 0: 8b 00 mov(%eax),%eax <= Code; c88798c2 <[sound]sound_release+2a/7c> 2: 85 c0 test %eax,%eax Code; c88798c4 <[sound]sound_release+2c/7c> 4: 74 48 je 4e <_EIP+0x4e> c887990e <[sound]sound_release+76/7c> Code; c88798c6 <[sound]sound_release+2e/7c> 6: ff 48 10 decl 0x10(%eax) Code; c88798c9 <[sound]sound_release+31/7c> 9: 8b 04 0a mov(%edx,%ecx,1),%eax Code; c88798cc <[sound]sound_release+34/7c> c: 8b 00 mov(%eax),%eax Code; c88798ce <[sound]sound_release+36/7c> e: 80 48 14 08 orb$0x8,0x14(%eax) Code; c88798d2 <[sound]sound_release+3a/7c> 12: eb 3a jmp4e <_EIP+0x4e> c887990e <[sound]sound_release+76/7c> 1 warning issued. Results may not be reliable. - 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/
