* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-19 22:18 UTC (permalink / raw)
To: Pavel Machek
Cc: dean gaudet, Linus Torvalds, Dave Jones, Ingo Molnar,
linux-kernel
In-Reply-To: <20021218235327.GC705@elf.ucw.cz>
Pavel Machek wrote:
>>
>>don't many of the multi-CPU problems with tsc go away because you've got a
>>per-cpu physical page for the vsyscall?
>>
>>i.e. per-cpu tsc epoch and scaling can be set on that page.
>
> Problem is that cpu's can randomly drift +/- 100 clocks or so... Not
> nice at all.
>
±100 clocks is what... ±50 ns these days? You can't get that kind of
accuracy for anything outside the CPU core anyway...
-hpa
^ permalink raw reply
* Re: [PATCH/RFC] New module refcounting for net_proto_family
From: Max Krasnyansky @ 2002-12-19 22:17 UTC (permalink / raw)
To: David S. Miller, alan; +Cc: linux-kernel
In-Reply-To: <20021219.111221.115928165.davem@redhat.com>
At 11:12 AM 12/19/2002 -0800, David S. Miller wrote:
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Date: 19 Dec 2002 19:28:35 +0000
>
> On Thu, 2002-12-19 at 16:05, Max Krasnyansky wrote:
> > Hmm, no replies. Nobody is interested in this or what ?
> > I want to get this fixed otherwise I can't fix Bluetooth module
> > refcounting.
>
> Looks good to me, but its christmas so I wouldnt expect much to happen
> till the new year
Ah, Christmas time :)
>I just got back from a long snowboarding trip, I'll look at this
>over the weekend before I disappear for another similar trip :)
Ok. Drop me a note and I'll push this stuff to BK were you can pull from.
In the mean time I'll go bug other folks :). I want to do same kinda changes
for the TTY ldisc code.
Max
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Dan Kegel @ 2002-12-19 22:26 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <3E022E56.30509@inet.com>
Eli Carter wrote:
> But I see that starting from scratch is just the way you work:
> http://grabjohn.com/question.php?q=6
It gets worse:
http://grabjohn.com/question.php?q=9
--
Dan Kegel
Linux User #78045
http://www.kegel.com
^ permalink raw reply
* Re: drivers/base/fs/fs.h - needed?
From: Patrick Mochel @ 2002-12-19 21:49 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-kernel
In-Reply-To: <20021217200405.GA1191@mars.ravnborg.org>
On Tue, 17 Dec 2002, Sam Ravnborg wrote:
> In fs/partitions/check.c the following ugly include exists:
> #include <../drivers/base/fs/fs.h> /* Eeeeewwwww */
>
> It can be killed with no problem, the prototypes contained therein are
> not used by check.c.
>
> Is this preparations for furter device model changes?
> If thats the case, the fs.h file, or at least the content, shall be placed
> in include/linux for general access.
It can safely be removed.
Thanks
-pat
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-19 22:17 UTC (permalink / raw)
To: Pavel Machek
Cc: Alan Cox, Andre Hedrick, Linus Torvalds, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List
In-Reply-To: <20021218235546.GD705@elf.ucw.cz>
Pavel Machek wrote:
>>
>>Different thing - int 0x80 syscall not i/o port 80. I've done I/O port
>>80 (its very easy), but requires we set up some udelay constants with an
>>initial safety value right at boot (which we should do - we udelay
>>before it is initialised)
>
> Actually that would be nice -- I have leds on 0x80 too ;-).
> Pavel
We have tried before, and failed. Phoenix uses something like 0xe2, but
apparently some machines with non-Phoenix BIOSes actually use that port.
-hpa
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-19 22:16 UTC (permalink / raw)
To: Jamie Lokier
Cc: Linus Torvalds, bart, davej, terje.eggestad, drepper,
matti.aarnio, hugh, mingo, linux-kernel
In-Reply-To: <20021219221043.GA18562@bjl1.asuk.net>
Jamie Lokier wrote:
>
> Dynamic binaries or libraries can use the indirect call or relocate
> the calls at load time, or if they _really_ want a magic page at a
> position relative to the library, they can just _copy_ the magic page
> from 0xfffe0000. It is not all that magic.
>
That would make it impossible for the kernel to have kernel-controlled
data on that page|other page though...
I personally would like to see some better interface than mmap()
/proc/self/mem in order to alias pages, anyway. We could use a
MAP_ALIAS flag in mmap() for this (where the fd would be ignored, but
the offset would matter.)
-hpa
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Pavel Machek @ 2002-12-18 23:53 UTC (permalink / raw)
To: dean gaudet; +Cc: Linus Torvalds, Dave Jones, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.50.0212162241150.26163-100000@twinlark.arctic.org>
Hi!
> > It's not as good as a pure user-mode solution using tsc could be, but
> > we've seen the kinds of complexities that has with multi-CPU systems, and
> > they are so painful that I suspect the sysenter approach is a lot more
> > palatable even if it doesn't allow for the absolute best theoretical
> > numbers.
>
> don't many of the multi-CPU problems with tsc go away because you've got a
> per-cpu physical page for the vsyscall?
>
> i.e. per-cpu tsc epoch and scaling can be set on that page.
Problem is that cpu's can randomly drift +/- 100 clocks or so... Not
nice at all.
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Cold allocation so that swsusp works
From: Pavel Machek @ 2002-12-19 20:04 UTC (permalink / raw)
To: akpm, kernel list
Hi!
This is my try to make swsusp work... Does it look acceptable?
Pavel
--- clean/include/linux/gfp.h 2002-11-01 00:37:40.000000000 +0100
+++ linux-swsusp/include/linux/gfp.h 2002-12-19 20:35:47.000000000 +0100
@@ -18,6 +18,7 @@
#define __GFP_HIGHIO 0x80 /* Can start high mem physical IO? */
#define __GFP_FS 0x100 /* Can call down to low-level FS? */
#define __GFP_COLD 0x200 /* Cache-cold page required */
+#define __GFP_SWSUSP 0x400 /* We want page that used to be free, not some page from list */
#define GFP_NOHIGHIO ( __GFP_WAIT | __GFP_IO)
#define GFP_NOIO ( __GFP_WAIT)
--- clean/kernel/suspend.c 2002-12-18 22:21:13.000000000 +0100
+++ linux-swsusp/kernel/suspend.c 2002-12-19 20:39:26.000000000 +0100
@@ -547,7 +547,7 @@
pagedir_order = get_bitmask_order(SUSPEND_PD_PAGES(nr_copy_pages));
- p = pagedir = (suspend_pagedir_t *)__get_free_pages(GFP_ATOMIC | __GFP_COLD, pagedir_order);
+ p = pagedir = (suspend_pagedir_t *)__get_free_pages(GFP_ATOMIC | __GFP_SWSUSP, pagedir_order);
if(!pagedir)
return NULL;
@@ -556,7 +556,7 @@
SetPageNosave(page++);
while(nr_copy_pages--) {
- p->address = get_zeroed_page(GFP_ATOMIC | __GFP_COLD);
+ p->address = get_zeroed_page(GFP_ATOMIC | __GFP_SWSUSP);
if(!p->address) {
free_suspend_pagedir((unsigned long) pagedir);
return NULL;
--- clean/mm/page_alloc.c 2002-12-18 22:21:13.000000000 +0100
+++ linux-swsusp/mm/page_alloc.c 2002-12-19 20:51:59.000000000 +0100
@@ -389,10 +389,10 @@
unsigned long flags;
struct page *page = NULL;
- if (order == 0) {
+ if ((order == 0) && !(cold & __GFP_SWSUSP)) {
struct per_cpu_pages *pcp;
- pcp = &zone->pageset[get_cpu()].pcp[cold];
+ pcp = &zone->pageset[get_cpu()].pcp[!!cold];
local_irq_save(flags);
if (pcp->count <= pcp->low)
pcp->count += rmqueue_bulk(zone, 0,
@@ -444,15 +444,10 @@
struct zone **zones, *classzone;
struct page *page;
int i;
- int cold;
if (wait)
might_sleep();
- cold = 0;
- if (gfp_mask & __GFP_COLD)
- cold = 1;
-
zones = zonelist->zones; /* the list of zones suitable for gfp_mask */
classzone = zones[0];
if (classzone == NULL) /* no zones in the zonelist */
@@ -466,7 +461,7 @@
min += z->pages_low;
if (z->free_pages >= min ||
(!wait && z->free_pages >= z->pages_high)) {
- page = buffered_rmqueue(z, order, cold);
+ page = buffered_rmqueue(z, order, gfp_mask & (__GFP_COLD | __GFP_SWSUSP));
if (page)
return page;
}
@@ -489,7 +484,7 @@
min += local_min;
if (z->free_pages >= min ||
(!wait && z->free_pages >= z->pages_high)) {
- page = buffered_rmqueue(z, order, cold);
+ page = buffered_rmqueue(z, order, gfp_mask & (__GFP_COLD | __GFP_SWSUSP));
if (page)
return page;
}
@@ -504,7 +499,7 @@
for (i = 0; zones[i] != NULL; i++) {
struct zone *z = zones[i];
- page = buffered_rmqueue(z, order, cold);
+ page = buffered_rmqueue(z, order, gfp_mask & (__GFP_COLD | __GFP_SWSUSP));
if (page)
return page;
}
@@ -527,7 +522,7 @@
min += z->pages_min;
if (z->free_pages >= min ||
(!wait && z->free_pages >= z->pages_high)) {
- page = buffered_rmqueue(z, order, cold);
+ page = buffered_rmqueue(z, order, gfp_mask & (__GFP_COLD | __GFP_SWSUSP));
if (page)
return page;
}
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Pavel Machek @ 2002-12-18 23:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Ulrich Drepper, Nakajima, Jun, Matti Aarnio,
Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212172005500.1230-100000@home.transmeta.com>
Hi!
> Btw, on another tangent - Andrew Morton reports that APM is unhappy about
> the fact that the fast system call stuff required us to move the segments
> around a bit. That's probably because the APM code has the old APM segment
> numbers hardcoded somewhere, but I don't see where (I certainly knew about
> the segment number issue, and tried to update the cases I saw).
>
> Debugging help would be appreciated, especially from somebody who knows
> the APM code.
IIRC, segment 0x40 was special in BIOS days, and some APM bioses
blindly access 0x40 even from protected mode (windows have segment
0x40 with base 0x400....) Is that issue you are hitting?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Pavel Machek @ 2002-12-18 23:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.44.0212162140500.1644-100000@home.transmeta.com>
Hi!
> > (Modulo the missing syscall page I already mentioned and potential bugs
> > in the code itself, of course ;)
>
> Ok, I did the vsyscall page too, and tried to make it do the right thing
> (but I didn't bother to test it on a non-SEP machine).
>
> I'm pushing the changes out right now, but basically it boils down to the
> fact that with these changes, user space can instead of doing an
>
> int $0x80
>
> instruction for a system call just do a
>
> call 0xfffff000
>
> instead. The vsyscall page will be set up to use sysenter if the CPU
> supports it, and if it doesn't, it will just do the old "int $0x80"
> instead (and it could use the AMD syscall instruction if it wants to).
> User mode shouldn't know or care, the calling convention is the same as it
> ever was.
Perhaps it makes sense to define that gettimeofday is done by
call 0xfffff100,
NOW? So we can add vsyscalls later?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: [ISN] Music file flaws could threaten traders
From: Russell Coker @ 2002-12-19 22:07 UTC (permalink / raw)
To: selinux
In-Reply-To: <Pine.LNX.4.44.0212190257480.19905-100000@idle.curiosity.org>
This type of thing could affect Linux in the same way as it affects Windows.
Currently we have "risky" programs such as netscape, games, and IRC clients in
their own domains that have types for read-only and for read-write files (and
no ability to run gpg or other important programs).
The problem about doing the same for audio/video programs such as players for
avi, mp3, and vob files is that their typical use involves downloading files
from the net to play immediately so that denying them read access to
user_home_t files will give a large decrease in functionality. I believe
that there are two major categories of SE Linux users, those who will never
run such A/V programs on Linux, and those who won't use any security software
that gets in the way of their entertainment.
So I think that having a domain for A/V programs such as $1_av_t that has read
access to $1_home_t and can create files with the type $1_home_av_t may not
be as tightly secured as we might like, but the people who are concerned
about that won't use it anyway.
On Thu, 19 Dec 2002 09:58, InfoSec News wrote:
> http://news.com.com/2100-1001-978403.html?tag=fd_top
>
> By Robert Lemos
> Staff Writer, CNET News.com
> December 18, 2002, 5:12 PM PT
>
> A security firm on Wednesday warned that people using Windows XP or
> popular music player WinAmp could fall prey to a vulnerability,
> enabling a modified music file to take control of a person's PC.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Pavel Machek @ 2002-12-18 23:59 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: Linus Torvalds, Dave Jones, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <3DFF023E.6030401@redhat.com>
Hi!
> I've created a modified glibc which uses the syscall code for almost
> everything. There are a few int $0x80 left here and there but mostly it
> is a centralized change.
>
> The result: all works as expected. Nice.
>
> On my test machine your little test program performs the syscalls on
> roughly twice as fast (HT P4, pretty new). Your numbers are perhaps for
> the P4 Xeons. Anyway, when measuring some more involved code (I ran my
> thread benchmark) I got only about 3% performance increase. It's doing
> a fair amount of system calls. But again, the good news is your code
> survived even this stress test.
>
>
> The problem with the current solution is the instruction set of the x86.
> In your test code you simply use call 0xfffff000 and it magically work.
> But this is only the case because your program is linked statically.
>
> For the libc DSO I had to play some dirty tricks. The x86 CPU has no
> absolute call. The variant with an immediate parameter is a relative
> jump. Only when jumping through a register or memory location is it
> possible to jump to an absolute address. To be clear, if I have
>
> call 0xfffff000
>
> in a DSO which is loaded at address 0x80000000 the jumps ends at
> 0x7fffffff. The problem is that the static linker doesn't know the load
> address. We could of course have the dynamic linker fix up the
> addresses but this is plain stupid. It would mean fixing up a lot of
> places and making of those pages covered non-sharable.
Can't you do call far __SOME_CS, 0xfffff000?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Pavel Machek @ 2002-12-18 23:55 UTC (permalink / raw)
To: Alan Cox
Cc: Andre Hedrick, Linus Torvalds, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List, hpa
In-Reply-To: <1040137976.20018.3.camel@irongate.swansea.linux.org.uk>
Hi!
> > Are you serious about moving of the banging we currently do on 0x80?
> > If so, I have a P4 development board with leds to monitor all the lower io
> > ports and can decode for you.
>
> Different thing - int 0x80 syscall not i/o port 80. I've done I/O port
> 80 (its very easy), but requires we set up some udelay constants with an
> initial safety value right at boot (which we should do - we udelay
> before it is initialised)
Actually that would be nice -- I have leds on 0x80 too ;-).
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: parport_serial link order bug, NetMos support
From: Marek Michalkiewicz @ 2002-12-19 22:13 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.50.0212191049020.2159-100000@montezuma.mastecende.com>
> I have local patches which do the same and have been using them for about
> a year too (also at 115k). Regarding the parallel port aspect of the card,
> i have tested using shared IRQs by running an epat cdrom via said port and
> generating a high amount of serial i/o
Could you send me your local patches? (I use parport in polling mode.)
> 00:10.0 Communication controller: NetMos Technology 222N-2 I/O Card (2S+1P) (rev 01)
Actually, these PCI vendor:device IDs are not specific to any card,
they are hardwired inside the NM9835 chip. My no-name cards (made in
China) have an empty place instead of the the configuration EEPROM.
> Last time i posted regarding this, Tim Waugh says that the cards brought
> about a number of issues, of which i am unable to recollect.
Would be nice to know exactly what these issues are. My only issue with
these cards so far is that I have to patch the kernel to use them...
Thanks,
Marek
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Jamie Lokier @ 2002-12-19 22:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: bart, davej, hpa, terje.eggestad, drepper, matti.aarnio, hugh,
mingo, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212191134180.2731-100000@penguin.transmeta.com>
Linus Torvalds wrote:
> For _zero_ gain. The jump to the library address has to be indirect
> anyway, and glibc has several places to put the information without any
> mmap's or anything like that.
This is not true, (but your overall point is still correct).
The jump to the magic page can be direct in statically linked code, or
in the executable itself. The assembler and linker have no problem
with this, I have just tried it.
What people (not Linus) have said about static binaries is moot,
because a static binary is linked at an absolute address itself, and
so can use the standard "call relative" instruction directly to the
fixed magic page address.
Dynamic binaries or libraries can use the indirect call or relocate
the calls at load time, or if they _really_ want a magic page at a
position relative to the library, they can just _copy_ the magic page
from 0xfffe0000. It is not all that magic.
-- Jamie
^ permalink raw reply
* Re: Are working modules going to be in 2.6?
From: romieu @ 2002-12-19 22:04 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Linux-Kernel Mailing List
In-Reply-To: <Pine.LNX.3.96.1021219154713.29567A-100000@gatekeeper.tmr.com>
Bill Davidsen <davidsen@tmr.com> :
[...]
> I have downloaded any number of modutil this and init-mod that, built them
> static, rolled my own initrd files, and as far as I can tell it just
> doesn't work with 2.5.48+.
Here it worked with 2.5.50 + module-init-tools-0.9. No special magic.
In-kernel 3c59x + initrd + (really gory style) nfs root.
If you're interested, kernel .config is available at:
http://electric-eye.fr.zoreil.com/2.5.50/misc/config.gz
--
Ueimor
^ permalink raw reply
* Re: HT Benchmarks (was: /proc/cpuinfo and hyperthreading)
From: J.A. Magallon @ 2002-12-19 22:04 UTC (permalink / raw)
To: Andrew Burgess; +Cc: linux-kernel
In-Reply-To: <200212181756.gBIHuud27855@athlon.cichlid.com>
On 2002.12.18 Andrew Burgess wrote:
>>Number of threads Elapsed time User Time System Time
>>1 53:216 53:220 00:000
>>2 29:272 58:180 00:320
>>3 27:162 1:21:450 00:540
>>4 25:094 1:41:080 01:250
>
>>Elapsed is measured by the parent thread, that is not doing anything
>>but wait on a pthread_join. User and system times are the sum of
>>times for all the children threads, that do real work.
>
>>The jump from 1->2 threads is fine, the one from 2->4 is ridiculous...
>>I have my cpus doubled but each one has half the pipelining for floating
>>point...see the user cpu time increased due to 'worst' processors and
>>cache pollution on each package.
>
>>So, IMHO and for my apps, HyperThreading is just a bad joke.
>
>Why do you care about user time? The elapsed time went down by
>4 minutes (2->4 threads), if that's a joke I don't get it :-)
>
>New Intel Ad: "What are you going to do with your 4 minutes today?"
>
Of course I gain something. The problem is the price you pay for the
gain.
Prices in Spain: a P4 with 512Kb cache, 210 euros. Equal features (freq,
cache), but Xeon version, 320 euros. So you pay 50% more money for
10% more performance. Not too fair...
--
J.A. Magallon <jamagallon@able.es> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.20-jam2 (gcc 3.2 (Mandrake Linux 9.1 3.2-4mdk))
^ permalink raw reply
* An array failover driver
From: Qi, Yanling @ 2002-12-19 21:56 UTC (permalink / raw)
To: 'linux-scsi-reflector'
Hi All,
I am going to develop a multiple-pathing driver to support our storage array
hardware on Linux(2.4 and later). I prefer the driver sit on the top of HBA
drivers (fibre channel adapter drivers) and below middle level (the unifying
layer). In other words, insert my pseudo driver into middle level and lower
level drivers. The driver will take care of path failover. I am still in
research phase. Do you have any suggestions?
Thanks,
Yanling Qi
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Randy.Dunlap @ 2002-12-19 21:55 UTC (permalink / raw)
To: Eli Carter; +Cc: John Bradford, linux-kernel
In-Reply-To: <3E0240CA.4000502@inet.com>
On Thu, 19 Dec 2002, Eli Carter wrote:
| John Bradford wrote:
| >>| > I'm not trying to discourage you - just raising a potential gotcha.
| >>|
| >>| Overall, though, would you rather be presented with a list of
| >>| categories, or a list of people and what parts of the code they
| >>| maintain. Personally, I think that a list of people is more
| >>| intuitive, rather than an abstract list of categories, but I could be
| >>| wrong.
| >>
| >>Do we have anyone targeted for interrupt routing problems (PIC, IO APIC,
| >>ACPI, etc.)?
| >
| >
| > No. I nominate Alan :-).
| >
| > OK, I see your point, but no bug system will ever be perfect. Does
| > that mean there is no point in trying to make a better one? If
| > everybody really thinks it's a waste of time, I won't bother. It just
| > seemed to me that we need something less generic than Bugzilla. Maybe
| > I am wrong, I don't know.
|
| Don't get discouraged... Our flamethrowers are set to 'stun'. ;)
|
| Bug tracking can get much better (I _hope_!), but I expect it to take
| some beating on the problem. Keep beating on it.
I agree. I wasn't trying to discourage you. There's much room for
improvement IMO.
--
~Randy
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Eli Carter @ 2002-12-19 21:57 UTC (permalink / raw)
To: John Bradford; +Cc: Randy.Dunlap, linux-kernel
In-Reply-To: <200212192155.gBJLtV6k003254@darkstar.example.net>
John Bradford wrote:
>>| > I'm not trying to discourage you - just raising a potential gotcha.
>>|
>>| Overall, though, would you rather be presented with a list of
>>| categories, or a list of people and what parts of the code they
>>| maintain. Personally, I think that a list of people is more
>>| intuitive, rather than an abstract list of categories, but I could be
>>| wrong.
>>
>>Do we have anyone targeted for interrupt routing problems (PIC, IO APIC,
>>ACPI, etc.)?
>
>
> No. I nominate Alan :-).
>
> OK, I see your point, but no bug system will ever be perfect. Does
> that mean there is no point in trying to make a better one? If
> everybody really thinks it's a waste of time, I won't bother. It just
> seemed to me that we need something less generic than Bugzilla. Maybe
> I am wrong, I don't know.
Don't get discouraged... Our flamethrowers are set to 'stun'. ;)
Bug tracking can get much better (I _hope_!), but I expect it to take
some beating on the problem. Keep beating on it.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Dan Kegel @ 2002-12-19 22:05 UTC (permalink / raw)
To: Eli Carter; +Cc: John Bradford, linux-kernel
In-Reply-To: <3E022E56.30509@inet.com>
Eli Carter wrote:
> But I see that starting from scratch is just the way you work:
> http://grabjohn.com/question.php?q=6
Ah, he must have sipped the same kool-aid as djb :-)
That works only as long as you're incredibly talented,
and don't mind being a loner.
- Dan
--
Dan Kegel
Linux User #78045
http://www.kegel.com
^ permalink raw reply
* problem with 2.4.20 and OPTi Inc. 82C861 (rev 10) USB card
From: Folkert van Heusden @ 2002-12-19 21:56 UTC (permalink / raw)
To: linux-kernel
Hi,
I have a OPTi Inc. 82C861 (rev 10) USB card in my pentium 90 pc.
The output of lspci gives me this:
00:07.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI])
Subsystem: OPTi Inc. 82C861
Flags: medium devsel
Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
The driver should be the ohci, but when I modprobe that one, I
get the following error:
spider:/home/folkert# modprobe usb-ohci
/lib/modules/2.4.20/kernel/drivers/usb/usb-ohci.o: init_module: No such
device
Hint: insmod errors can be caused by incorrect module parameters, including
invalid IO or IRQ parameters
So I was wondering: can it be that the USB-driver is slightly
broken? :-)
(oh, all the other usb-drivers give the same errors)
^ permalink raw reply
* [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Con Kolivas @ 2002-12-19 21:50 UTC (permalink / raw)
To: linux kernel mailing list; +Cc: Robert Love
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
contest results, osdl hardware, scheduler tunable prio_bonus_ratio; default
value (2.5.52-mm1) is 25; these results are interesting.
noload:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [8] 39.7 180 0 0 1.10
pri_bon00 [3] 40.6 180 0 0 1.12
pri_bon10 [3] 40.2 180 0 0 1.11
pri_bon30 [3] 39.7 181 0 0 1.10
pri_bon50 [3] 40.0 179 0 0 1.10
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 36.9 194 0 0 1.02
pri_bon00 [3] 37.6 194 0 0 1.04
pri_bon10 [3] 37.2 194 0 0 1.03
pri_bon30 [3] 36.9 194 0 0 1.02
pri_bon50 [3] 36.7 195 0 0 1.01
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 49.0 144 10 50 1.35
pri_bon00 [3] 47.5 152 9 41 1.31
pri_bon10 [3] 48.2 147 10 47 1.33
pri_bon30 [3] 50.1 141 12 53 1.38
pri_bon50 [3] 46.2 154 8 39 1.28
Seems to subtly affect the balance here.
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 55.5 156 1 10 1.53
pri_bon00 [3] 44.6 165 0 5 1.23
pri_bon10 [3] 45.5 164 0 7 1.26
pri_bon30 [3] 52.0 154 1 10 1.44
pri_bon50 [3] 57.5 158 1 10 1.59
Seems to be a direct relationship; pb up, time up
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 77.4 122 1 8 2.14
pri_bon00 [3] 60.6 125 0 7 1.67
pri_bon10 [3] 61.7 125 1 8 1.70
pri_bon30 [3] 74.8 128 1 9 2.07
pri_bon50 [3] 74.5 130 1 8 2.06
when pb goes up, time goes up, but maxes out
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 80.5 108 10 19 2.22
pri_bon00 [3] 120.3 94 22 24 3.32
pri_bon10 [3] 123.6 91 20 23 3.41
pri_bon30 [3] 95.8 84 14 20 2.65
pri_bon50 [3] 76.8 114 11 21 2.12
when pb goes up, time goes down (large effect)
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 60.1 131 7 18 1.66
pri_bon00 [3] 142.8 94 27 26 3.94
pri_bon10 [3] 116.5 93 22 26 3.22
pri_bon30 [3] 72.8 115 8 19 2.01
pri_bon50 [3] 99.8 97 15 22 2.76
similar to io_load, not quite linear
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 49.9 149 5 6 1.38
pri_bon00 [3] 48.3 154 2 3 1.33
pri_bon10 [3] 49.5 150 5 6 1.37
pri_bon30 [3] 50.7 148 5 6 1.40
pri_bon50 [3] 49.8 149 5 6 1.38
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 43.8 167 0 9 1.21
pri_bon00 [3] 43.7 168 0 7 1.21
pri_bon10 [3] 44.0 167 0 8 1.22
pri_bon30 [3] 44.0 166 0 9 1.22
pri_bon50 [3] 43.8 167 0 9 1.21
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 71.1 123 36 2 1.96
pri_bon00 [3] 78.8 98 33 2 2.18
pri_bon10 [3] 94.0 82 35 2 2.60
pri_bon30 [3] 108.6 74 36 2 3.00
pri_bon50 [3] 106.2 75 36 2 2.93
in the opposite direction to io_load; as pb goes up, time goes up, but
mem_load achieves no more work.
Changing this tunable seems to shift the balance in either direction depending
on the load. Most of the disk writing loads have shorter times as pb goes up,
but under heavy mem_load the time goes up (without an increase in the amount
of work done by the mem_load itself). The effect is quite large.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE+Aj8nF6dfvkL3i1gRAuJOAKCYVUsr4tii1akA996c/XVqdCizuQCfQi+a
QtX8sg1Q1KA2VI6eY+X5GtM=
=QlX7
-----END PGP SIGNATURE-----
^ permalink raw reply
* RE: 2.5.52: PDC20268 failure - ACPI to blame !!!
From: Grover, Andrew @ 2002-12-19 21:47 UTC (permalink / raw)
To: 'Frank van de Pol', Alan Cox; +Cc: Linux Kernel Mailing List
> From: Frank van de Pol [mailto:fvdpol@home.nl]
> 2.5.52 with ACPI - Failure, IRQ troubles wrong IRQ assigned
> for promise
> boards, lockup of box during boot
> 2.5.52 no ACPI - OK !!!
>
> What information do I need to provide to fix this problem?
It's a known, relatively common problem... if you're willing, ping me next
year and we can try to work through things.
Regards -- Andy
PS the GOOD news is that this appears to be one of the last big bugs in
ACPI! (yay) <knock on wood>
^ permalink raw reply
* BUG: 2.5.52-bk4
From: Lukas Hejtmanek @ 2002-12-19 21:47 UTC (permalink / raw)
To: linux-kernel
Hello,
If I try to open (to view) /proc/net/tcp in midnight commander then
the midnight commander freezes in kernel (cannot be killed) with 99% CPU usage.
I do not see any disk_io line in /proc/stat although I have /dev/hda as primary
disk. Maybe because I'm using boot_off first and ide=reverse. So real /dev/hda
does not exist and /dev/hde is as /dev/hda.
--
Lukáš Hejtmánek
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.