* Re: 2.5.52-mjb1 (scalability / NUMA patchset)
From: Martin J. Bligh @ 2002-12-17 19:31 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: linux-kernel
In-Reply-To: <20021217174958.GY2690@holomorphy.com>
>> The patchset contains mainly scalability and NUMA stuff, and
>> anything else that stops things from irritating me. It's meant
>> to be pretty stable, not so much a testing ground for new stuff.
>> I'd be very interested in feedback from other people running
>> large SMP or NUMA boxes.
>> http://www.aracnet.com/~fletch/linux/2.5.52/patch-2.5.52-mjb1.bz2
>
> pfn_to_nid() got lots of icache misses. Try using a macro.
How much difference does this make?
M.
^ permalink raw reply
* Re: Kernel for Pentium 4 hyperthreading?
From: Bill Davidsen @ 2002-12-17 19:39 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux-Kernel Mailing List
In-Reply-To: <20021215155819.GC20335@suse.de>
On Sun, 15 Dec 2002, Dave Jones wrote:
> On Sun, Dec 15, 2002 at 04:47:39PM +0100, Vergoz Michael (SYSDOOR) wrote:
> > Hi,
> >
> > It's possible to enable HT on any pentium 4, you just have to patch the bios
> > :P
>
> A rumour perpetuated by many, and achieved by none to my knowledge.
If W2k can tell if I enable HT or not, I assume it's really on.
Particularly if it then tells me I have more than two CPUs, my license
doesn't cover that, and it doesn't love me anymore.
Actually, 2.5.recent can get this right using APCI and will also work.
Guess the rumor is true, although I would say "many P4" rather than "all
P4" because I believe Intel disables one sibling at the bonding step
(based on information elsewhere) for some CPUs.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 19:44 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ulrich Drepper, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, linux-kernel
In-Reply-To: <3DFF7BCD.9040901@transmeta.com>
On Tue, 17 Dec 2002, H. Peter Anvin wrote:
>
> What one can also do is that a sixth argument, if one exists, is passed
> on the stack (i.e. in (%ebp), since %ebp contains the stack pointer.)
I like this. I will make it so. It will allow the old calling conventions
and has none of the stack size issues that my "memory block" approach had.
Also since this will all be done inside the wrapper and is thus entirely
invisible to the caller. Good, this solves the six-arg case nicely.
Linus
^ permalink raw reply
* Re: alsasound init script (Re: possible problems with rc6 aplay )
From: Fernando Pablo Lopez-Lezcano @ 2002-12-17 19:36 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Mark Knecht, Paul Davis, Alsa-Devel
In-Reply-To: <s5hpts0sy4k.wl@alsa2.suse.de>
On Tue, 2002-12-17 at 03:06, Takashi Iwai wrote:
> At 16 Dec 2002 19:46:55 -0800,
> Mark Knecht wrote:
> > On Mon, 2002-12-16 at 18:51, Paul Davis wrote:
> > > i think it would something like this:
> > >
> > > options snd-hdsp snd_index=0
> > > options snd-usb-foo snd_index=1
> > >
> > > i'm sure that takashi or jaroslav will correct me if i got this wrong.
> >
> > This makes perfect sense, and it isn't what I did. (!!)
> >
> > The PlanetCCRMA has a Nano-HOWTO on how to install the MidiMan 2X2 by
> > hand. It's a little USB-based MIDI interface (not a sound card) that is
> > not recognized by alsaconf, so we do a bit of editing by hand.
>
> the behavior depends on the order of booting.
> if the hotplug service is booted before the alsasound init script,
> hotplug will start the snd-usbaudio module, which will be assigned as
> the first empty device, i.e. device #0, unless you specify the index
> option. and afterwards, the alsasound script is started, and it
> results in the confliction of devices.
>
> setting an index option is one of the solutions.
> in this case, the first usb-audio/midi device will be forced to be
> assigned to #1. so, it's safe to start it beforehand.
>
> but, when we take a deeper look at this, we find another problem.
> the alsasound init script checks whether the ALSA was already started
> by checking the existence of /proc/asound directory. and, if hotplug
> started the usb-audio/midi before alsasound, this directory would be
> also created because the alsa core was started without help of
> alsasound init script, too. this leads to the skip of loading of any
> other soundcards, because alsasound will quit immediately.
>
> after all, a simple solution for this is to make sure that alsasound
> starts before hotplug. then, even the index option for snd-usbaudio
> wouldn't be necessary (in theory).
I think that in RedHat hotplug is not started as a service so we cannot
make sure that alsasound starts first (at least not easily - I have to
check again on the startup scripts to see what is done and when).
It would be better to make the alsasound script more robust (and
independent of the startup order) and able to deal with partially loaded
modules, so instead of just checking for the /proc/asound directory it
would actually see what modules are already loaded and only load those
that are not. It does not look too easy, it seems that /proc/asound does
not provide a list of loaded modules (rather a list of cards that are
not associated with module names).
> in the above scenario, anyway, cards_limit must be changed. and i
> think it's a bit annoying.
>
> the attached patch will change the handling of cards_limit option.
> with the patch, the alsa won't restrict the number of cards per
> cards_limit option, but only limits the auto-probing via kmod.
> i.e. you can load more card modules even with cards_limit=1.
That sounds reasonable.
-- Fernando
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-17 19:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ulrich Drepper, Alan Cox, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212171132530.1095-100000@home.transmeta.com>
Linus Torvalds wrote:
>
> The thing is, gettimeofday() isn't _that_ special. It's just not worth a
> vsyscall of it's own, I feel. Where do you stop? Do we do getpid() too?
> Just because we can?
>
getpid() could be implemented in userspace, but not via vsyscalls
(instead it could be passed in the ELF data area at process start.)
"Because we can and it's relatively easy" is a pretty good argument in
my opinion.
> This is especially true since the people who _really_ might care about
> gettimeofday() are exactly the people who wouldn't be able to use the fast
> user-space-only version.
>
> How much do you think gettimeofday() really matters on a desktop? Sure, X
> apps do gettimeofday() calls, but they do a whole lot more of _other_
> calls, and gettimeofday() is really far far down in the noise for them.
> The people who really call for gettimeofday() as a performance thing seem
> to be database people who want it as a timestamp. But those are the same
> people who also want NUMA machines which don't necessarily have
> synchronized clocks.
>
I think this is really an overstatement. Timestamping etc. (and heck,
even databases) are actually perfectly usable even on smaller machines
these days. Sure, DB vendors like to boast of their 128-way NUMA
machines, but I suspect the bulk of them run on single- and
dual-processor machines (by count, not necessarily by data volume.)
-hpa
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Dave Jones @ 2002-12-17 19:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ulrich Drepper, Alan Cox, Matti Aarnio, Hugh Dickins, Ingo Molnar,
Linux Kernel Mailing List, hpa
In-Reply-To: <Pine.LNX.4.44.0212171106210.1095-100000@home.transmeta.com>
On Tue, Dec 17, 2002 at 11:10:20AM -0800, Linus Torvalds wrote:
> Intel will fix the stupidities that cause the P4 to be slow at kernel
> entry. Somebody already mentioned that apparently the newer P4 cores are
> actually faster at system calls than mine is).
My HT Northwood returns slightly better results than your xeon,
but the syscall stuff still completely trounces it.
(19:38:46:davej@tetrachloride:davej)$ ./a.out
440.107164 cycles
1152.596084 cycles
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Richard B. Johnson @ 2002-12-17 19:52 UTC (permalink / raw)
To: Alan Cox
Cc: Ulrich Drepper, Linus Torvalds, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List, hpa
In-Reply-To: <1040154273.20804.13.camel@irongate.swansea.linux.org.uk>
On 17 Dec 2002, Alan Cox wrote:
> On Tue, 2002-12-17 at 18:48, Ulrich Drepper wrote:
> > Alan Cox wrote:
> >
> > > Is there any reason you can't just keep the linker out of the entire
> > > mess by generating
> > >
> > > .byte whatever
> > > .dword 0xFFFF0000
> > >
> > > instead of call ?
> >
> > There is no such instruction. Unless you know about some secret
> > undocumented opcode...
>
> No I'd forgotten how broken x86 was
>
You can call intersegment with a full pointer. I don't know how
expensive that is. Since USER_CS is a fixed value in Linux, it
can be hard-coded
.byte 0x9a
.dword 0xfffff000
.word USER_CS
No. I didn't try this, I'm just looking at the manual. I don't know
what the USER_CS is (didn't look in the kernel) The book says the
pointer is 16:32 which means that it's a dword, followed by a word.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* [PATCH] 2.4.21pre1 cpqfc
From: White, Charles @ 2002-12-17 19:50 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel
This patch fixes two minor bugs in cpqfc and makes it version 2.1.2.
diff -urN linux-2.4.21-pre1.orig/drivers/scsi/cpqfc.Readme
linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfc.Readme
--- linux-2.4.21-pre1.orig/drivers/scsi/cpqfc.Readme Thu Oct 25
16:53:50 2001
+++ linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfc.Readme Tue Dec
17 09:33:18 2002
@@ -22,6 +22,9 @@
* Makefile changes to bring cpqfc into line w/ rest of SCSI drivers
(thanks to Keith Owens)
+Ver 2.1.2 Jul 22, 2002
+ * initialize DumCmnd.lun (used as LUN index in fcFindLoggedInPort())
+
Ver 2.0.5 Aug 06, 2001
* Reject non-existent luns in the driver rather than letting the
hardware do it. (some HW behaves differently than others in this
area.)
diff -urN linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSinit.c
linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSinit.c
--- linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSinit.c Tue Dec 17
09:25:01 2002
+++ linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSinit.c Tue Dec
17 13:18:20 2002
@@ -64,7 +64,7 @@
/* Embedded module documentation macros - see module.h */
MODULE_AUTHOR("Compaq Computer Corporation");
-MODULE_DESCRIPTION("Driver for Compaq 64-bit/66Mhz PCI Fibre Channel
HBA v. 2.1.1");
+MODULE_DESCRIPTION("Driver for Compaq 64-bit/66Mhz PCI Fibre Channel
HBA v. 2.1.2");
MODULE_LICENSE("GPL");
int cpqfcTS_TargetDeviceReset(Scsi_Device * ScsiDev, unsigned int
reset_flags);
@@ -411,6 +411,7 @@
// can we find an FC device mapping to this SCSI target?
DumCmnd.channel = ScsiDev->channel; // For searching
DumCmnd.target = ScsiDev->id;
+ DumCmnd.lun = ScsiDev->lun;
pLoggedInPort = fcFindLoggedInPort(fcChip, &DumCmnd, //
search Scsi Nexus
0, // DON'T search linked
list for FC port id
NULL, // DON'T search
linked list for FC WWN
diff -urN linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSstructs.h
linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSstructs.h
--- linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSstructs.h Tue Dec
17 09:25:01 2002
+++ linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSstructs.h Tue Dec
17 09:33:18 2002
@@ -35,7 +35,7 @@
/* don't forget to also change MODULE_DESCRIPTION in cpqfcTSinit.c */
#define VER_MAJOR 2
#define VER_MINOR 1
-#define VER_SUBMINOR 1
+#define VER_SUBMINOR 2
/*
* Macros for kernel (esp. SMP) tracing using a PCI analyzer
diff -urN linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSworker.c
linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSworker.c
--- linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSworker.c Tue Dec 17
09:25:01 2002
+++ linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSworker.c Tue Dec
17 09:41:11 2002
@@ -2706,6 +2706,10 @@
// Report Luns command
if
(pLoggedInPort->ScsiNexus.LunMasking == 1) {
// we KNOW all the valid
LUNs... 0xFF is invalid!
+ if (Cmnd->lun >
sizeof(pLoggedInPort->ScsiNexus.lun)){
+ // printk("
cpqfcTS FATAL: Invalid LUN index !!!!\n ");
+ return NULL;
+ }
Cmnd->SCp.have_data_in =
pLoggedInPort->ScsiNexus.lun[Cmnd->lun];
if
(pLoggedInPort->ScsiNexus.lun[Cmnd->lun] == 0xFF)
return NULL;
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Ulrich Drepper @ 2002-12-17 19:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matti Aarnio, Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel,
hpa
In-Reply-To: <Pine.LNX.4.44.0212171115450.1095-100000@home.transmeta.com>
Linus Torvalds wrote:
>
> The only ones I found from a quick grep are
> - sys_recvfrom
> - sys_sendto
> - sys_mmap2()
> - sys_ipc()
All but mmap2 do not use 6 parameters. They are implemented via the
sys_ipc multiplexer which takes the stack pointer as an argument which
then helps to locate the parameters.
--
--------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-17 19:54 UTC (permalink / raw)
To: root
Cc: Alan Cox, Ulrich Drepper, Linus Torvalds, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.3.95.1021217144308.26554A-100000@chaos.analogic.com>
Richard B. Johnson wrote:
>
> You can call intersegment with a full pointer. I don't know how
> expensive that is. Since USER_CS is a fixed value in Linux, it
> can be hard-coded
>
> .byte 0x9a
> .dword 0xfffff000
> .word USER_CS
>
> No. I didn't try this, I'm just looking at the manual. I don't know
> what the USER_CS is (didn't look in the kernel) The book says the
> pointer is 16:32 which means that it's a dword, followed by a word.
>
It's quite expensive (not as expensive as INT, but not that far from
it), and you also push CS onto the stack.
-hpa
^ permalink raw reply
* Re: [PATCH] 2.4.21pre1 cpqfc
From: Marcelo Tosatti @ 2002-12-17 16:58 UTC (permalink / raw)
To: White, Charles; +Cc: lkml
In-Reply-To: <A2C35BB97A9A384CA2816D24522A53BB039917AD@cceexc18.americas.cpqcorp.net>
Could you make a short list of the fixed bugs?
On Tue, 17 Dec 2002, White, Charles wrote:
> This patch fixes two minor bugs in cpqfc and makes it version 2.1.2.
>
> diff -urN linux-2.4.21-pre1.orig/drivers/scsi/cpqfc.Readme
> linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfc.Readme
> --- linux-2.4.21-pre1.orig/drivers/scsi/cpqfc.Readme Thu Oct 25
> 16:53:50 2001
> +++ linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfc.Readme Tue Dec
> 17 09:33:18 2002
> @@ -22,6 +22,9 @@
> * Makefile changes to bring cpqfc into line w/ rest of SCSI drivers
> (thanks to Keith Owens)
>
> +Ver 2.1.2 Jul 22, 2002
> + * initialize DumCmnd.lun (used as LUN index in fcFindLoggedInPort())
> +
> Ver 2.0.5 Aug 06, 2001
> * Reject non-existent luns in the driver rather than letting the
> hardware do it. (some HW behaves differently than others in this
> area.)
> diff -urN linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSinit.c
> linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSinit.c
> --- linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSinit.c Tue Dec 17
> 09:25:01 2002
> +++ linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSinit.c Tue Dec
> 17 13:18:20 2002
> @@ -64,7 +64,7 @@
>
> /* Embedded module documentation macros - see module.h */
> MODULE_AUTHOR("Compaq Computer Corporation");
> -MODULE_DESCRIPTION("Driver for Compaq 64-bit/66Mhz PCI Fibre Channel
> HBA v. 2.1.1");
> +MODULE_DESCRIPTION("Driver for Compaq 64-bit/66Mhz PCI Fibre Channel
> HBA v. 2.1.2");
> MODULE_LICENSE("GPL");
>
> int cpqfcTS_TargetDeviceReset(Scsi_Device * ScsiDev, unsigned int
> reset_flags);
> @@ -411,6 +411,7 @@
> // can we find an FC device mapping to this SCSI target?
> DumCmnd.channel = ScsiDev->channel; // For searching
> DumCmnd.target = ScsiDev->id;
> + DumCmnd.lun = ScsiDev->lun;
> pLoggedInPort = fcFindLoggedInPort(fcChip, &DumCmnd, //
> search Scsi Nexus
> 0, // DON'T search linked
> list for FC port id
> NULL, // DON'T search
> linked list for FC WWN
> diff -urN linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSstructs.h
> linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSstructs.h
> --- linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSstructs.h Tue Dec
> 17 09:25:01 2002
> +++ linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSstructs.h Tue Dec
> 17 09:33:18 2002
> @@ -35,7 +35,7 @@
> /* don't forget to also change MODULE_DESCRIPTION in cpqfcTSinit.c */
> #define VER_MAJOR 2
> #define VER_MINOR 1
> -#define VER_SUBMINOR 1
> +#define VER_SUBMINOR 2
>
> /*
> * Macros for kernel (esp. SMP) tracing using a PCI analyzer
> diff -urN linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSworker.c
> linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSworker.c
> --- linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSworker.c Tue Dec 17
> 09:25:01 2002
> +++ linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSworker.c Tue Dec
> 17 09:41:11 2002
> @@ -2706,6 +2706,10 @@
> // Report Luns command
> if
> (pLoggedInPort->ScsiNexus.LunMasking == 1) {
> // we KNOW all the valid
> LUNs... 0xFF is invalid!
> + if (Cmnd->lun >
> sizeof(pLoggedInPort->ScsiNexus.lun)){
> + // printk("
> cpqfcTS FATAL: Invalid LUN index !!!!\n ");
> + return NULL;
> + }
> Cmnd->SCp.have_data_in =
> pLoggedInPort->ScsiNexus.lun[Cmnd->lun];
> if
> (pLoggedInPort->ScsiNexus.lun[Cmnd->lun] == 0xFF)
> return NULL;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 19:58 UTC (permalink / raw)
To: Richard B. Johnson
Cc: Alan Cox, Ulrich Drepper, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List, hpa
In-Reply-To: <Pine.LNX.3.95.1021217144308.26554A-100000@chaos.analogic.com>
On Tue, 17 Dec 2002, Richard B. Johnson wrote:
>
> You can call intersegment with a full pointer. I don't know how
> expensive that is.
It's so expensive as to not be worth it, it's cheaper to load a register
or something, i eyou can do
pushl $0xfffff000
call *(%esp)
faster than doing a far call.
Linus
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Matti Aarnio @ 2002-12-17 19:59 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Ulrich Drepper, Alan Cox, Matti Aarnio,
Hugh Dickins, Dave Jones, Ingo Molnar, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212171132530.1095-100000@home.transmeta.com>
On Tue, Dec 17, 2002 at 11:37:04AM -0800, Linus Torvalds wrote:
> On Tue, 17 Dec 2002, H. Peter Anvin wrote:
> > Let's see... it works fine on UP and on *most* SMP, and on the ones
> > where it doesn't work you just fill in a system call into the vsyscall
> > slot. It just means that gettimeofday() needs a different vsyscall slot.
>
> The thing is, gettimeofday() isn't _that_ special. It's just not worth a
> vsyscall of it's own, I feel. Where do you stop? Do we do getpid() too?
> Just because we can?
clone() -- which doesn't really like anybody using stack-pointer ?
(I do use gettimeofday() a _lot_, but I have my own userspace
mapped shared segment thingamajingie doing it.. And I write
code that runs on lots of systems, not only at Linux. )
> Linus
/Matti Aarnio
^ permalink raw reply
* Re: Alcatel speedtouch USB driver and SMP.
From: Max Krasnyansky @ 2002-12-17 19:59 UTC (permalink / raw)
To: Colin Paul Adams, linux-kernel
In-Reply-To: <m3adj6gwus.fsf@colina.demon.co.uk>
At 09:02 AM 12/16/2002 +0000, Colin Paul Adams wrote:
>>>>>> "Greg" == Greg KH <greg@kroah.com> writes:
> >> drivers/usb/misc/speedtouch.c
>
> Greg> Ah good, you're using one that the source is available for
> Greg> :) I think the developer has said it will work on SMP
> Greg> machines, but what problems are you having, and have you
> Greg> asked the author of the code?
>
>I haven't any problems yet, as I haven't bought the modem yet. I don't
>want to if it is going to give me problems.
>
>The 1.4 version of the driver (before integration into 2.5 series
>kernel), is supposed to not work with SMP kernels (that's why I asked
>in the first place). So I contacted the author (Johan Verrept) to ask on the status,
>and he said he thought it was probably OK now, as it was in the 2.5
>kernel.
>
>So I grabbed the 2.5.51 sources and looked at the see, and could see
>no mention of a change to fix SMP. So I then contacted Richard Purdie,
>who was the last person to make a change to the source. He said he
>didn't know.
>
>So, is anyone using it on SMP?
I was, until I got Bluetooth DSL access point :).
I used to have PPPoE setup with Speedtouch modem on my Dual Athlon box. It was running
2.4.18 at that time. Most of the SMP problems were in the ATM code. I fixed some of them
and my patches went into 2.4.19. I did some hack to the driver itself but those
were minor.
Max
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 20:01 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Matti Aarnio, Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel,
hpa
In-Reply-To: <3DFF80BC.2020709@redhat.com>
How about this diff? It does both the 6-parameter thing _and_ the
AT_SYSINFO addition. Untested, since I have to run off and watch my kids
do their winter program ;)
Linus
-----
===== arch/i386/kernel/entry.S 1.42 vs edited =====
--- 1.42/arch/i386/kernel/entry.S Mon Dec 16 21:39:04 2002
+++ edited/arch/i386/kernel/entry.S Tue Dec 17 11:59:13 2002
@@ -232,7 +232,7 @@
#endif
/* Points to after the "sysenter" instruction in the vsyscall page */
-#define SYSENTER_RETURN 0xfffff007
+#define SYSENTER_RETURN 0xffffe007
# sysenter call handler stub
ALIGN
@@ -243,6 +243,21 @@
pushfl
pushl $(__USER_CS)
pushl $SYSENTER_RETURN
+
+/*
+ * Load the potential sixth argument from user stack.
+ * Careful about security.
+ */
+ cmpl $0xc0000000,%ebp
+ jae syscall_badsys
+1: movl (%ebp),%ebp
+.section .fixup,"ax"
+2: xorl %ebp,%ebp
+.previous
+.section __ex_table,"a"
+ .align 4
+ .long 1b,2b
+.previous
pushl %eax
SAVE_ALL
===== arch/i386/kernel/sysenter.c 1.1 vs edited =====
--- 1.1/arch/i386/kernel/sysenter.c Mon Dec 16 21:39:04 2002
+++ edited/arch/i386/kernel/sysenter.c Tue Dec 17 11:39:39 2002
@@ -48,14 +48,14 @@
0xc3 /* ret */
};
static const char sysent[] = {
- 0x55, /* push %ebp */
0x51, /* push %ecx */
0x52, /* push %edx */
+ 0x55, /* push %ebp */
0x89, 0xe5, /* movl %esp,%ebp */
0x0f, 0x34, /* sysenter */
+ 0x5d, /* pop %ebp */
0x5a, /* pop %edx */
0x59, /* pop %ecx */
- 0x5d, /* pop %ebp */
0xc3 /* ret */
};
unsigned long page = get_zeroed_page(GFP_ATOMIC);
===== include/asm-i386/elf.h 1.3 vs edited =====
--- 1.3/include/asm-i386/elf.h Thu Oct 17 00:48:55 2002
+++ edited/include/asm-i386/elf.h Tue Dec 17 10:12:58 2002
@@ -100,6 +100,12 @@
#define ELF_PLATFORM (system_utsname.machine)
+/*
+ * Architecture-neutral AT_ values in 0-17, leave some room
+ * for more of them, start the x86-specific ones at 32.
+ */
+#define AT_SYSINFO 32
+
#ifdef __KERNEL__
#define SET_PERSONALITY(ex, ibcs2) set_personality((ibcs2)?PER_SVR4:PER_LINUX)
@@ -115,6 +121,11 @@
extern void dump_smp_unlazy_fpu(void);
#define ELF_CORE_SYNC dump_smp_unlazy_fpu
#endif
+
+#define ARCH_DLINFO \
+do { \
+ NEW_AUX_ENT(AT_SYSINFO, 0xffffe000); \
+} while (0)
#endif
===== include/asm-i386/fixmap.h 1.9 vs edited =====
--- 1.9/include/asm-i386/fixmap.h Mon Dec 16 21:39:04 2002
+++ edited/include/asm-i386/fixmap.h Tue Dec 17 10:11:31 2002
@@ -42,8 +42,8 @@
* task switches.
*/
enum fixed_addresses {
- FIX_VSYSCALL,
FIX_HOLE,
+ FIX_VSYSCALL,
#ifdef CONFIG_X86_LOCAL_APIC
FIX_APIC_BASE, /* local (CPU) APIC) -- required for SMP or not */
#endif
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Jun Sun @ 2002-12-17 19:54 UTC (permalink / raw)
To: Dominic Sweetman; +Cc: Maciej W. Rozycki, Ralf Baechle, linux-mips, jsun
In-Reply-To: <15871.13866.515311.16388@arsenal.algor.co.uk>
On Tue, Dec 17, 2002 at 02:35:22PM +0000, Dominic Sweetman wrote:
>
> > The i8259A doesn't work this way. With your proposed code the IRR
> > is never cleared (which is a problem for edge-triggered interrupts
> > -- such an interrupt gets signalled again once it's unmasked, until
> > deasserted by a device). The i8259A only clears a bit in the IRR
> > when it receives an ACK (it then copies the bit to the corresponding
> > bit of the ISR) or when an interrupt goes away (a device deasserts
> > it).
>
> Just a few comments on the hardware:
>
> As I recall, you can clear a stored edge-triggered interrupt using a
> "specific EOI". In the 8080 microprocessor for which the 8259 was
> designed, this command was magically communicated to the 8259 when the
> CPU ran its "return from interrupt" instruction. I think even in the
> 8086 this had to be replaced with an explicit I/O cycle.
>
> People not using x86 CPUs should consider putting the i8259 into
> "special mask mode". Then it behaves simply and predictably,
> providing an interrupt on any active unmasked input. You lose the
> i8259 interrupt priority stuff, but this is only one of the
> advantages.
This sounds a lot like the doc I read when I did the programming. Does
anybody know *the doc* I am talking about? I can't seem to find it anymore.
Meanwhile I find myself cannot answer Maciej's question as to when IRR
bit is cleared under edge triggering case. Perhaps the hardware does it
automatically when IRQ is generated?
I will probe further and reply to you later.
Jun
^ permalink raw reply
* drivers/base/fs/fs.h - needed?
From: Sam Ravnborg @ 2002-12-17 20:04 UTC (permalink / raw)
To: mochel, linux-kernel
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.
Here is a patch to remove the said include statement.
Sam
===== fs/partitions/check.c 1.90 vs edited =====
--- 1.90/fs/partitions/check.c Thu Dec 5 20:01:25 2002
+++ edited/fs/partitions/check.c Tue Dec 17 20:57:02 2002
@@ -19,7 +19,6 @@
#include <linux/blk.h>
#include <linux/kmod.h>
#include <linux/ctype.h>
-#include <../drivers/base/fs/fs.h> /* Eeeeewwwww */
#include "check.h"
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Ulrich Drepper @ 2002-12-17 20:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Alan Cox, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212171132530.1095-100000@home.transmeta.com>
Linus Torvalds wrote:
> The thing is, gettimeofday() isn't _that_ special. It's just not worth a
> vsyscall of it's own, I feel. Where do you stop? Do we do getpid() too?
This is why I'd say mkae no distinction at all. Have the first
nr_syscalls * 8 bytes starting at 0xfffff000 as a jump table. We can
transfer to a different slot for each syscall. Each slot then could be
a PC-relative jump to the common sysenter code or to some special code
sequence which is also in the global page.
If we don't do this now and it seems desirable in future we wither have
to introduce a second ABI for the vsyscall stuff (ugly!) or you'll have
to do the demultiplexing yourself in the code starting at 0xfffff000.
--
--------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Matti Aarnio @ 2002-12-17 20:07 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <3DFF7E7D.1080900@transmeta.com>
(cutting down To:/Cc:)
On Tue, Dec 17, 2002 at 11:43:57AM -0800, H. Peter Anvin wrote:
> Linus Torvalds wrote:
> > The thing is, gettimeofday() isn't _that_ special. It's just not worth a
> > vsyscall of it's own, I feel. Where do you stop? Do we do getpid() too?
> > Just because we can?
>
> getpid() could be implemented in userspace, but not via vsyscalls
> (instead it could be passed in the ELF data area at process start.)
After fork() or clone() ?
If we had only spawn(), and some separate way to start threads...
...
> -hpa
/Matti Aarnio
^ permalink raw reply
* MIPS64 kernel cross-compiling
From: Julian Scheel @ 2002-12-17 20:00 UTC (permalink / raw)
To: linux-mips
Hi,
we're trying to compile a kernel for an embedded system with a
MIPS64-processor on it.
We tried first with your CVS-sources, but there we get this error:
-----
Generating include/linux/version.h (unchanged)
make[1]: Nothing to be done for `__build'.
SPLIT include/linux/autoconf.h -> include/config/*
make -f scripts/Makefile.build obj=arch/mips64/kernel
arch/mips64/kernel/offset.s
make[1]: `arch/mips64/kernel/offset.s' is up to date.
/bin/sh: arch/mips64/kernel/offset.s: Datei oder Verzeichnis nicht gefunden
-----
Afterwards we changed to the 2.4.20 stock kernel, there we have managed to get
the kernel compiling the first steps. We're using the algor SDE-Toolchain and
on make vmlinux, we get masses of parse-errors.
Our point of view is, that the compiler tries to link to include/asm instead
of include/asm-mips64, but doing a dirty simlink from asm to asm-mips64
didn't really improve our situation.
Here are some of the errors we get:
----
sde-gcc -D__KERNEL__ -I/usr/src/linux-2.4.20/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer
-mips64 -I /usr/src/linux-2.4.20/include/asm-mips64/gcc -mabi=64 -G 0
-mno-abicalls -fno-pic -Wa,--trap -pipe -DKBUILD_BASENAME=main -c -o
init/main.o init/main.c
In file included from /usr/src/linux-2.4.20/include/asm/system.h:14,
from /usr/src/linux-2.4.20/include/asm/processor.h:36,
from /usr/src/linux-2.4.20/include/linux/prefetch.h:13,
from /usr/src/linux-2.4.20/include/linux/list.h:6,
from /usr/src/linux-2.4.20/include/linux/wait.h:14,
from /usr/src/linux-2.4.20/include/linux/fs.h:12,
from /usr/src/linux-2.4.20/include/linux/capability.h:17,
from /usr/src/linux-2.4.20/include/linux/binfmts.h:5,
from /usr/src/linux-2.4.20/include/linux/sched.h:9,
from /usr/src/linux-2.4.20/include/linux/mm.h:4,
from /usr/src/linux-2.4.20/include/linux/slab.h:14,
from /usr/src/linux-2.4.20/include/linux/proc_fs.h:5,
from init/main.c:15:
/usr/src/linux-2.4.20/include/asm/sgidefs.h:18:39: #error Use a Linux compiler
or give up.
[...]
In file included from /usr/src/linux-2.4.20/include/linux/pagemap.h:16,
from /usr/src/linux-2.4.20/include/linux/locks.h:8,
from /usr/src/linux-2.4.20/include/linux/blk.h:5,
from init/main.c:25:
/usr/src/linux-2.4.20/include/linux/highmem.h: In function `kmap':
/usr/src/linux-2.4.20/include/linux/highmem.h:68: `PAGE_OFFSET' undeclared
(first use in this function)
/usr/src/linux-2.4.20/include/linux/highmem.h:68: warning: control reaches end
of non-void function
init/main.c: In function `start_kernel':
init/main.c:383: `PAGE_OFFSET' undeclared (first use in this function)
make: *** [init/main.o] Error 1
----
hoping for a bit of help (c:
--
Grüße,
Julian, Paco
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Alan Cox @ 2002-12-17 20:49 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List
In-Reply-To: <3DFF772E.2050107@transmeta.com>
On Tue, 2002-12-17 at 19:12, H. Peter Anvin wrote:
> The complexity only applies to nonsynchronized TSCs though, I would
> assume. I believe x86-64 uses a vsyscall using the TSC when it can
> provide synchronized TSCs, and if it can't it puts a normal system call
> inside the vsyscall in question.
For x86-64 there is the hpet timer, which is a lot saner but I don't
think we can mmap it
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-17 20:10 UTC (permalink / raw)
To: Matti Aarnio; +Cc: Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <20021217200749.GB32122@mea-ext.zmailer.org>
Matti Aarnio wrote:
> (cutting down To:/Cc:)
>
> On Tue, Dec 17, 2002 at 11:43:57AM -0800, H. Peter Anvin wrote:
>
>>Linus Torvalds wrote:
>>
>>>The thing is, gettimeofday() isn't _that_ special. It's just not worth a
>>>vsyscall of it's own, I feel. Where do you stop? Do we do getpid() too?
>>>Just because we can?
>>
>>getpid() could be implemented in userspace, but not via vsyscalls
>>(instead it could be passed in the ELF data area at process start.)
>
>
> After fork() or clone() ?
> If we had only spawn(), and some separate way to start threads...
>
fork() and clone() would have to return the self-pid as an auxilliary
return value. This, of course, is getting rather fuggly.
Anything that cares caches getpid() anyway.
-hpa
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Alan Cox @ 2002-12-17 20:51 UTC (permalink / raw)
To: Martin J. Bligh
Cc: H. Peter Anvin, Linus Torvalds, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List
In-Reply-To: <160470000.1040153210@flay>
On Tue, 2002-12-17 at 19:26, Martin J. Bligh wrote:
> >> It's not as good as a pure user-mode solution using tsc could be, but
> You can't use the TSC to do gettimeofday on boxes where they aren't
> syncronised anyway though. That's nothing to do with vsyscalls, you just
> need a different time source (eg the legacy stuff or HPET/cyclone).
Ditto all the laptops and the like. With code provided by the kernel we
can cheat however. If we know the fastest the CPU can go (ie full speed
on spudstop/powernow etc) we can tell the tsc value at which we have to
query the kernel to get time to any given accuracy, so allowing limited
caching
Ditto by knowing the worst case drift on summit
Alan
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-17 20:12 UTC (permalink / raw)
To: Alan Cox; +Cc: Linus Torvalds, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List
In-Reply-To: <1040158171.20765.23.camel@irongate.swansea.linux.org.uk>
Alan Cox wrote:
> On Tue, 2002-12-17 at 19:12, H. Peter Anvin wrote:
>
>>The complexity only applies to nonsynchronized TSCs though, I would
>>assume. I believe x86-64 uses a vsyscall using the TSC when it can
>>provide synchronized TSCs, and if it can't it puts a normal system call
>>inside the vsyscall in question.
>
>
> For x86-64 there is the hpet timer, which is a lot saner but I don't
> think we can mmap it
>
It's only necessary, though, when TSC isn't usable. TSC is psycho fast
when it's available. Just about anything is saner than the old 8042 or
whatever it is called timer chip, though...
-hpa
^ permalink raw reply
* mac address change on an eth alias
From: Petre Bandac @ 2002-12-17 20:07 UTC (permalink / raw)
To: linux-newbie
root@k:~# ifconfig eth0:1 123.123.123.123 netmask 255.255.255.0 hw ether
00:E0:7D:02:C6:0C
SIOCSIFHWADDR: Device or resource busy
root@k:~#
am I trying to do something impossible or is it only my NIC (Realtek 8139)
that can't do it ?
I want to have 2 ip's on the same interface - but with 2 different macs ...
why? because this is my testing server and, among others (dhcp, bind,
sendmail/postfix, asterisk, etc) I want to actually see how a mac address can
be changed ... if it's possible
thank you for you patience,
petre
--
22:01:49 up 5:31, 1 user, load average: 0.04, 0.11, 0.14
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ 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.