* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 19:05 UTC (permalink / raw)
To: Jeff Dike; +Cc: Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <200212171839.NAA08357@ccure.karaya.com>
On Tue, 17 Dec 2002, Jeff Dike wrote:
>
> torvalds@transmeta.com said:
> > That also allows the kernel to move around the SYSINFO page at will,
> > and even makes it possible to avoid it altogether (ie this will solve
> > the inevitable problems with UML - UML just wouldn't set AT_SYSINFO,
> > so user level just wouldn't even _try_ to use it).
>
> Why shouldn't I just set it to where UML provides its own SYSINFO page?
Sure, that works fine too.
Linus
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Alan Cox @ 2002-12-17 19:44 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Linus Torvalds, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List, hpa
In-Reply-To: <3DFF717C.90006@redhat.com>
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
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 19:04 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Matti Aarnio, Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel,
hpa
In-Reply-To: <3DFF6D4B.3060107@redhat.com>
On Tue, 17 Dec 2002, Ulrich Drepper wrote:
>
> But it will eliminate the problem. Remember: the x86 (unlike x86-64)
> has no PC-relative data addressing mode. I.e., in a DSO to find a
> memory location with an address I need a base register which isn't
> available anymore at the time the call is made.
Actually, I see a more serious problem with the current "syscall"
interface: it doesn't allow six-argument system calls AT ALL, since it
needed %ebp to keep the stack pointer.
So a six-argument system call _has_ to use "int $0x80" anyway, which to
some degree simplifies your problem: you can only use the indirect call
approach for things where %ebp will be free for use anyway.
So then you can use %ebp as the indirection, and the code will look
something like
games, since that is guaranteed not to be ever used by a system call (it
wasn't guaranteed before, but since the sysenter really needs something to
hold the stack pointer I made %ebp do that, so there's no way we can ever
use %ebp for system calls on x86).
So you _can_ do something like this:
syscall_with_5_args:
pushl %ebx
pushl %esi
pushl %edi
pushl %ebp
movl syscall_ptr + GOT,%ebp // uses DSO ptr in %ebx or whatever
movl $__NR_xxxxxx,%eax
movl 20(%esp),%ebx
movl 24(%esp),%ecx
movl 28(%esp),%edx
movl 32(%esp),%esi
movl 36(%esp),%edi
call *%ebp
.. test for errno if needed ..
popl %ebp
popl %edi
popl %esi
popl %ebx
ret
> You have to assume that all the registers, including %ebp, are used at
> the time of the call.
See why this isn't possible right now anyway.
Hmm.. Which system calls have all six parameters? I'll have to see if I
can find any way to make those use the new interface too.
In the meantime, I do agree with you that the TLS approach should work
too, and might be better. It will allow all six arguments to be used if we
just find a good calling conventions (too bad sysenter is such a pig of an
instruction, it's really not very well designed since it loses
information).
Linus
^ permalink raw reply
* extensions/libipt_NETLINK.c doesn't get built
From: Marcel Pol @ 2002-12-17 18:51 UTC (permalink / raw)
To: netfilter, netfilter
Hello,
I have patched my 2.4.19-1mdk kernel with NETLINK, iplimit and string from
pom-cvs from yesterday.
For userspace iptables I use an unpatched 1.2.7a.
The problem I run into is that the NETLINK library doesn't get built. When I
run the testscript .NETLINK.test, it detects the .c file in my sourcetree, but
it doesn't get built when I run make. There's no build error, it just doesn't
try to compile it.
I'm not sure where it goes wrong.
The string and iplimit libraries get built fine.
It's listed as optional in the Makefile. I assume that if the test runs ok,
then it should get built. right? I'm not that good at reading Makefiles, but I
didn't think there was an option needed with running make. If there is, please
inform me :-)
I'm building it on an Alpha AXPpci 166 ev4.
Greetings,
--
Marcel Pol
Linux 2.4.20-0.4mdk.ringworld.1, up 10 days, 23:07
Registered User #163523
^ permalink raw reply
* 405LP EBC setup fix
From: Hollis Blanchard @ 2002-12-17 18:51 UTC (permalink / raw)
To: embedded list
[-- Attachment #1: Type: text/plain, Size: 275 bytes --]
EBC0_B0CR should be set as 16-bit; through an ifdef merging typo it is
currently set incorrectly as 8-bit. This prevents 405LP wakeup from
succeeding and needs to be fixed.
Please apply to _2_4_devel and 2.5.
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
[-- Attachment #2: 405LP-EBC0_B0CR-2.4.diff --]
[-- Type: text/plain, Size: 497 bytes --]
===== arch/ppc/platforms/beech.c 1.9 vs edited =====
--- 1.9/arch/ppc/platforms/beech.c Thu Dec 12 17:06:37 2002
+++ edited/arch/ppc/platforms/beech.c Tue Dec 17 11:29:58 2002
@@ -180,7 +180,7 @@
(mfdcri(DCRN_EBC0, BnCR(0)) & EBC0_BnCR_MASK);
cr.fields.bs = BEECH_BANK0_EBC_SIZE;
cr.fields.bu = EBC0_BnCR_BU_RW;
- cr.fields.bw = EBC0_BnCR_BW_8;
+ cr.fields.bw = EBC0_BnCR_BW_16;
mtdcri(DCRN_EBC0, BnCR(0), cr.reg);
ap.reg = mfdcri(DCRN_EBC0, BnAP(0)) & EBC0_BnAP_MASK;
[-- Attachment #3: 405LP-EBC0_B0CR-2.5.diff --]
[-- Type: text/plain, Size: 509 bytes --]
===== arch/ppc/platforms/4xx/beech.c 1.9 vs edited =====
--- 1.9/arch/ppc/platforms/4xx/beech.c Thu Dec 12 17:06:37 2002
+++ edited/arch/ppc/platforms/4xx/beech.c Tue Dec 17 11:29:58 2002
@@ -180,7 +180,7 @@
(mfdcri(DCRN_EBC0, BnCR(0)) & EBC0_BnCR_MASK);
cr.fields.bs = BEECH_BANK0_EBC_SIZE;
cr.fields.bu = EBC0_BnCR_BU_RW;
- cr.fields.bw = EBC0_BnCR_BW_8;
+ cr.fields.bw = EBC0_BnCR_BW_16;
mtdcri(DCRN_EBC0, BnCR(0), cr.reg);
ap.reg = mfdcri(DCRN_EBC0, BnAP(0)) & EBC0_BnAP_MASK;
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Ulrich Drepper @ 2002-12-17 18:57 UTC (permalink / raw)
To: Alan Cox
Cc: Linus Torvalds, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, Linux Kernel Mailing List, hpa
In-Reply-To: <1040153186.20780.11.camel@irongate.swansea.linux.org.uk>
Alan Cox wrote:
> getppid changes and so I think has to go to kernel (unless we go around
> patching user pages on process exit [ick]).
But this is exactly what I expect to happen. If you want to implement
gettimeofday() at user-level you need to modify the page. Some of the
information the kernel has to keep for the thread group can be stored in
this place and eventually be used by some uerlevel code executed by
jumping to 0xfffff000 or whatever the address is.
--
--------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
^ permalink raw reply
* 405LP RTC reset
From: Hollis Blanchard @ 2002-12-17 18:43 UTC (permalink / raw)
To: embedded list; +Cc: Todd Poynor
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
Here's the updated 405LP RTC reset diff (after David's move of the RTC
functions to ibm405lp.c). This patch
a) does a full RTC reset as specified in the docs
b) sets the RTC clock speed in RTC "Register A" DV bits, i.e. it does
not assume the firmware has done this correctly.
Please apply to _2_4_devel.
Before similar changes can be made to 2.5, the non-todc RTC code will
have to be ported there (which Todd says is on his list :).
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
[-- Attachment #2: 405LP-rtc-reset.diff --]
[-- Type: text/plain, Size: 2558 bytes --]
===== arch/ppc/platforms/ibm405lp.h 1.8 vs edited =====
--- 1.8/arch/ppc/platforms/ibm405lp.h Tue Dec 17 11:26:06 2002
+++ edited/arch/ppc/platforms/ibm405lp.h Tue Dec 17 11:52:10 2002
@@ -860,6 +860,11 @@
#define SLA0_SLPMD_MASK 0x07dfffff /* AND to clear all non-reserved fields */
+/* these defines are for the DV bits of RTC0_CR0 */
+#define RTC_DVBITS_4MHZ 0 /* 4.194304 MHz */
+#define RTC_DVBITS_1MHZ 1 /* 1.048576 MHz */
+#define RTC_DVBITS_33KHZ 2 /* 32.768 KHz */
+
/* Several direct-write DCRs on the 405LP have an interlock requirement,
implemented by a "valid" bit in the low-order bit. This routine handles the
handshaking for these registers, by
===== arch/ppc/platforms/ibm405lp.c 1.4 vs edited =====
--- 1.4/arch/ppc/platforms/ibm405lp.c Thu Dec 12 17:06:37 2002
+++ edited/arch/ppc/platforms/ibm405lp.c Tue Dec 17 11:50:01 2002
@@ -282,12 +282,16 @@
/* Make sure clocks are running */
if (not_initialized) {
- /* Reset the core and ensure it's enabled. We assume
- only that the BIOS has set the correct frequency. */
-
- mtdcr(DCRN_RTC0_WRAP, 0);
+ /* Reset the core and ensure it's enabled. */
+ mtdcr(DCRN_RTC0_WRAP, 0); /* toggle NRST & NMR */
mtdcr(DCRN_RTC0_WRAP, 3);
- mtdcr(DCRN_RTC0_CR1, mfdcr(DCRN_RTC0_CR1) & 0x7f);
+ mtdcr(DCRN_RTC0_CR0, 0x60); /* No divider chain, No square wave */
+ mtdcr(DCRN_RTC0_CR1, 0x80); /* Disable update cycles/interrupts*/
+ mtdcr(DCRN_RTC0_WRAP, 0); /* toggle NRST & NMR */
+ mtdcr(DCRN_RTC0_WRAP, 3);
+ mtdcr(DCRN_RTC0_CR0, (RTC_DVBITS & 0x7) << 4); /* input clock */
+ mtdcr(DCRN_RTC0_CR1, mfdcr(DCRN_RTC0_CR1) & 0x7f); /* allow updates */
+
not_initialized = 0;
}
===== arch/ppc/platforms/beech.h 1.7 vs edited =====
--- 1.7/arch/ppc/platforms/beech.h Thu Dec 12 17:10:24 2002
+++ edited/arch/ppc/platforms/beech.h Tue Dec 17 11:50:10 2002
@@ -181,6 +181,8 @@
#define PPC4xx_SERCLK_FREQ 11059200
#define BASE_BAUD (PPC4xx_SERCLK_FREQ / 16)
+#define RTC_DVBITS RTC_DVBITS_1MHZ /* 1MHz RTC */
+
#define PPC4xx_MACHINE_NAME "IBM 405LP Beech"
#define _IO_BASE isa_io_base
===== arch/ppc/platforms/arctic2.h 1.1 vs edited =====
--- 1.1/arch/ppc/platforms/arctic2.h Sun Dec 15 19:59:59 2002
+++ edited/arch/ppc/platforms/arctic2.h Tue Dec 17 11:50:18 2002
@@ -56,6 +56,8 @@
#define BASE_BAUD (PPC4xx_SERCLK_FREQ / 16)
+#define RTC_DVBITS RTC_DVBITS_33KHZ /* 33KHz RTC */
+
#define PPC4xx_MACHINE_NAME "IBM Arctic II"
#endif /* !__ASSEMBLY__ */
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Ulrich Drepper @ 2002-12-17 18:48 UTC (permalink / raw)
To: Alan Cox
Cc: Linus Torvalds, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List, hpa
In-Reply-To: <1040153030.20804.8.camel@irongate.swansea.linux.org.uk>
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...
--
--------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
^ permalink raw reply
* How Do I: Make My Own /root file system
From: James Don @ 2002-12-17 18:42 UTC (permalink / raw)
To: 'linuxppc-embedded@lists.linuxppc.org'
Hello,
I just finished getting a basic bash shell running on my embedded PPC
platform using a standard RAM file system from www.denx.de.
Are there any instructions on line as to how I would go about making my own
RAM FS? ... most online info seem to point to commercial distro's ... and I
wouldn't mind learning the do's and don'ts for my self.
In the mean time I will keep dogging for information.
Best Regards,
Jim
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [LARTC] what these packets means ?
From: Arindam Haldar @ 2002-12-17 18:41 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104014726501401@msgid-missing>
yes martin we do have a cisco bridge for wilreless ...
thanx so much .. :-)
want to know what does this means in the packet below...
............... 8001 root 8000 ...............
what doesn the above mean ??
A.H
Martin A. Brown wrote:
> Arindam,
>
> These are part of spanning tree protocol (STP) used in bridging (or
> bridged) environments.
>
> You must be using a bridge on your network.
>
> -Martin
>
> : hi all,
> : what the folowwing tcpdump messages mean ??...
> : 802.1d--does this packet related to wireless ??
> :
> : 23:11:47.946515 0:40:96:51:ef:74 1:80:c2:0:0:0 0026 60: 802.1d config
> : 8000.00:40:96:51:ef:74.8001 root 8000.00:40:96:51:ef:74 pathcost 0 age 0
> : max 20 hello 2 fdelay 15
> : 23:11:49.948042 0:40:96:51:ef:74 1:80:c2:0:0:0 0026 60: 802.1d config
> : 8000.00:40:96:51:ef:74.8001 root 8000.00:40:96:51:ef:74 pathcost 0 age 0
> : max 20 hello 2 fdelay 15
> :
> : thanking in advance...
> : A.H
> :
> : _______________________________________________
> : LARTC mailing list / LARTC@mailman.ds9a.nl
> : http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> :
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* RE: How to get the size of the block device ???? (Important)
From: Matt_Domsch @ 2002-12-17 18:49 UTC (permalink / raw)
To: nikberry, root, sanju93csd; +Cc: linux-kernel
> I think the question being asked is 'how do I find out how many block
> long the device is?'
You can use the BLKGETSIZE64 ioctl() too. I refer you to the GNU Parted
code (ftp.gnu.org/gnu/parted) in libparted/linux.c to see how it's done
there. It first tries BLKGETSIZE64, then if that fails, tries BLKGETSIZE
instead.
Thanks,
Matt
--
Matt Domsch
Sr. Software Engineer, Lead Engineer, Architect
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 18:49 UTC (permalink / raw)
To: Alan Cox
Cc: Ulrich Drepper, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List, hpa
In-Reply-To: <1040153030.20804.8.camel@irongate.swansea.linux.org.uk>
On 17 Dec 2002, 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 ?
Alan, the problem is that there _is_ no such instruction as a "call
absolute".
There is only a "call relative" or "call indirect-absolute". So you either
have to indirect through memory or a register, or you have to fix up the
call at link-time.
Yeah, I know it sounds strange, but it makes sense. Absolute calls are
actually very unusual, and using relative calls is _usually_ the right
thing to do. It's only in cases like this that we really want to call a
specific address.
Linus
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Alan Cox @ 2002-12-17 19:26 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Linus Torvalds, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, Linux Kernel Mailing List, hpa
In-Reply-To: <3DFF6D4B.3060107@redhat.com>
On Tue, 2002-12-17 at 18:30, Ulrich Drepper wrote:
> demultiplexing happens in the kernel. Do we want to do this at
> userlevel? This would allow almost no-cost determination of those
> syscalls which can be handled at userlevel (getpid, getppid, ...).
getppid changes and so I think has to go to kernel (unless we go around
patching user pages on process exit [ick]). getpid can already be done
by reading it once at startup time and caching the data.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Alan Cox @ 2002-12-17 19:23 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Linus Torvalds, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List, hpa
In-Reply-To: <3DFF6501.3080106@redhat.com>
On Tue, 2002-12-17 at 17:55, Ulrich Drepper wrote:
> But there is a way: if I'm using
>
> #define makesyscall(name) \
> movl $__NR_##name, $eax; \
> call 0xfffff000-__NR_##name($eax)
>
> and you'd put at address 0xfffff000 the address of the entry point the
> wrappers wouldn't have any problems finding it.
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 ?
^ permalink raw reply
* Re: MSN helper module
From: Carlos Fernandez Sanz @ 2002-12-17 18:35 UTC (permalink / raw)
To: netfilter-devel, Michael Richardson
In-Reply-To: <200212171647.gBHGkxmD003537@sandelman.ottawa.on.ca>
Yes, it needs some support for file tranmission, voice, etc. The protocol
works a lot like FTP when using PORT (active) connections. The initiator
client sends its IP address and a port number for the other end to connect
to. For basic messaging it doesn't need any special NAT support, though -
the reason being that all connections are outgoing and there are no related
children connections.
So it is not a lot of work but it needs to be done. I haven't found anything
about it so I'm assuming no one has started any work, so I'll do it myself.
Anyway it's pretty much a one man job.
----- Original Message -----
From: "Michael Richardson" <mcr@sandelman.ottawa.on.ca>
To: <netfilter-devel@lists.netfilter.org>
Sent: Tuesday, December 17, 2002 17:46
Subject: Re: MSN helper module
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> >>>>> "Patrick" == Patrick Schaaf <bof@bof.de> writes:
> Patrick> On Tue, Dec 17, 2002 at 12:57:35AM +0100, Carlos Fernandez
Sanz wrote:
> >>
> >> Is there a helper module for MSN? If not, is it being developed and
can I
> >> join the effort?
> >>
> >> If nothing is being done I'll just write the module myself before
not having
> >> full MSN support becomes a serious issue and starts going up...
>
> Patrick> Ahem - what would such a helper module have to do? As far as
I know,
> Patrick> MSN is an Internet Service Provider, and there is no network
protocol
> Patrick> called MSN. Did that change? Do they do the AOL, 10 years
later?
>
> I don't know, cause I've never been there, but I think that he means the
> MSN instant message protocol. There is even a possibility that this is
just
> IETF IMPP. (Embrace and extend...)
> I didn't think it needed NAT support.
>
> ] ON HUMILITY: to err is human. To moo, bovine. |
firewalls [
> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net
architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
driver[
> ] panic("Just another Debian GNU/Linux using, kernel hacking, security
guy"); [
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Finger me for keys
>
> iQCVAwUBPf9U/YqHRg3pndX9AQE8oAQA6QLDohf/d+Fi86FPQ2ONrk8LiSqgKmwI
> aiG+cL6pmH+R5lihxYBWMEJ/T+2MpMfeopP4Hc/mquzrkOpo6J64J8EmeqlcAm9c
> 7Rn/K/MvLK2VXFSkqzahZ7S2t5QmfeCQPtgp3QePKqy79AszWW+bxracQ9+ES7A6
> BAzsdtHuPhs=
> =v3E+
> -----END PGP SIGNATURE-----
>
^ permalink raw reply
* Unaligned Instruction Trap
From: David D. McCoach @ 2002-12-17 18:35 UTC (permalink / raw)
To: linux-mips
I have a problem with random "Unaligned Instruction Traps: during the boot
process. After rcS starts executing.
I am using as Flash file system through a MTD driver.
Does anyone have a thread for me pull on?
Thanks
^ permalink raw reply
* Unaligned Instruction Trap
From: David D. McCoach @ 2002-12-17 18:35 UTC (permalink / raw)
To: linux-mips
I have a problem with random "Unaligned Instruction Traps: during the boot
process. After rcS starts executing.
I am using as Flash file system through a MTD driver.
Does anyone have a thread for me pull on?
Thanks
^ permalink raw reply
* Re: make module_install
From: Wolfgang Denk @ 2002-12-17 18:33 UTC (permalink / raw)
To: Marius Groeger; +Cc: Ing.Gianfranco Morandi, LinuxPPC
In-Reply-To: <Pine.LNX.4.40.0212171909030.11803-100000@mag.devdep.sysgo.de>
In message <Pine.LNX.4.40.0212171909030.11803-100000@mag.devdep.sysgo.de> you wrote:
>
> > driver anyway. I will even go so far to say that if you need to run
> > "depmod" for your embedded system you should fix your system design
> > because you are doing something wrong.
>
> Someone might use loadable modules because he doesn't want to release
> his driver under the GPL. I wouldn't exactly consider this wrong.
I do not intend to comment on the issue of binary modules.
But even in such a situation the necessity to run depmod in an
embedded system is IMHO an indication of a potential design problem.
Things should be kept simple.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
No user-servicable parts inside. Refer to qualified service personnel.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* 2.4.21-pre1: cannot load af-packet as module on Athlon
From: Bruce Lowekamp @ 2002-12-17 18:41 UTC (permalink / raw)
To: linux-kernel
# insmod /lib/modules/2.4.21-pre1/kernel/net/packet/af_packet.o
/lib/modules/2.4.21-pre1/kernel/net/packet/af_packet.o: unresolved symbol
_mmx_memcpy
/lib/modules/2.4.21-pre1/kernel/net/packet/af_packet.o: unresolved symbol
sk_run_filter
Kernel is compiled for an Athlon SMP. Configuration available at
http://www.cs.wm.edu/~lowekamp/tmp/2.4.21-pre1-modules
Bruce
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Maciej W. Rozycki @ 2002-12-17 18:33 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Dominic Sweetman, Jun Sun, linux-mips
In-Reply-To: <20021217192344.A18364@linux-mips.org>
On Tue, 17 Dec 2002, Ralf Baechle wrote:
> > Alternatively, many MIPS systems have a hardware feature which enables
> > them to generate imitation-x86 interrupt acknowledge cycles, so you
> > can keep the 8259s in complete ignorance that they're not being
> > controlled by an x86.
>
> Unless the hardware is an RM200 where under special circumstances the
> hardware acknowledge feature may result in loss of some or all i8259
> interrupts until full-reinitialization of the i8259 ...
Can the hardware acknowledge be disabled? If so, my proposed code should
work just fine.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Maciej W. Rozycki @ 2002-12-17 18:27 UTC (permalink / raw)
To: Dominic Sweetman; +Cc: Jun Sun, Ralf Baechle, linux-mips
In-Reply-To: <15871.13866.515311.16388@arsenal.algor.co.uk>
On Tue, 17 Dec 2002, 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.
An EOI command (be it the specific or the non-specific version) is used
to clear a bit in the ISR (unless the AEOI mode is activated; I'm not sure
why Linux doesn't use it as some code could be trimmed down -- probably
due to a historical reason) to permit further interrupts from the
respective input. But a bit in the ISR is only copied from the IRR upon
an ACK. Otherwise the i8259A still considers the IRQ pending.
The EOI command has to arrive at the i8259A bus as a write cycle (i.e.
with both CS# and WR# active) -- for i8080 and x86 systems a write cycle
to a system-specific location in the I/O address space of these processors
is typically the most convenient way, but memory-mapping is just fine,
too. Also the i8080 has no "return from interrupt" instruction -- the
usual sequence is "ei; ret" (this is safe as "ei" defers enabling
interrupt acceptance until after the following instruction). It's
possible there were systems that incorporated additional glue logic for
detecting this sequence of instructions (I haven't met any) and doing
writes to an i8259A, but I wouldn't believe they would be capable of
sending specific EOIs. Non-specific ones -- certainly, but only for
systems with a single i8259A (you can have up to 9 i8259As per an
i8080/x86 system for 64 IRQ inputs without additional glue logic or
special arrangements).
> 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. You'd need to be reasonably knowledgeable about the Linux
> interrupt system to make this clean and compatible with the x86
> versions, but then these troubles would be over for ever and you'd be
> a Hero, First Class.
It shouldn't be necessary for our handling model (but wouldn't hurt
either, even for the i386). As we use almost unmodified code from the
i386 implementation, there is only a small window when interrupts are
marked "in service" by the i8259As -- mask_and_ack_8259A() sends an EOI to
the chips before dispatching handlers. As a result there are no masked
interrupts with their ISR bits set.
> Alternatively, many MIPS systems have a hardware feature which enables
> them to generate imitation-x86 interrupt acknowledge cycles, so you
> can keep the 8259s in complete ignorance that they're not being
> controlled by an x86.
Do they ever need to "know"?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Jeff Dike @ 2002-12-17 18:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ulrich Drepper, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.44.0212170948380.2702-100000@home.transmeta.com>
torvalds@transmeta.com said:
> That also allows the kernel to move around the SYSINFO page at will,
> and even makes it possible to avoid it altogether (ie this will solve
> the inevitable problems with UML - UML just wouldn't set AT_SYSINFO,
> so user level just wouldn't even _try_ to use it).
Why shouldn't I just set it to where UML provides its own SYSINFO page?
Jeff
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Ulrich Drepper @ 2002-12-17 18:33 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.0212171017590.2702-100000@home.transmeta.com>
Linus Torvalds wrote:
> Thus glibc startup should be able to just do
>
> ptr = default_int80_syscall;
> if (AT_SYSINFO entry found)
> ptr = value(AT_SYSINFO)
>
> and then you can just do a
>
> call *ptr
This won't work as I just wrote but something similar I can make work.
I think the use of the TCB is the best thing to do. Replicating the
info in all thread new thread's TCBs doesn't cost much and with NPTL
it's even lower cost since we reuse old TCBs.
--
--------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
^ permalink raw reply
* unresolved symbols in ipt_iplimit
From: Marcel Pol @ 2002-12-17 18:24 UTC (permalink / raw)
To: netfilter-devel
Hello,
I patched my 2.4.19-1mdk kernel with iplimit, string and NETLINK, and I'm
getting depmod errors on ipt_iplimit.
# depmod -ae
depmod: *** Unresolved symbols in
/lib/modules/2.4.19-1mdk-inferno2/kernel/net/ipv4/netfilter/ipt_iplimit.o
depmod: ip_conntrack_find_get
This happened both with the last release of pom, and with the cvs version of
yesterday.
I compiled it with gcc 3.2 and binutils-2.13.90.0.10-1mdk.
It's on an Alpha AXPpci 166 ev4.
If there is more information needed, I'm willing to give that.
Greetings,
--
Marcel Pol
Linux 2.4.20-0.4mdk.ringworld.1, up 10 days, 23:07
Registered User #163523
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Ralf Baechle @ 2002-12-17 18:23 UTC (permalink / raw)
To: Dominic Sweetman; +Cc: Maciej W. Rozycki, Jun Sun, linux-mips
In-Reply-To: <15871.13866.515311.16388@arsenal.algor.co.uk>
On Tue, Dec 17, 2002 at 02:35:22PM +0000, Dominic Sweetman wrote:
> Alternatively, many MIPS systems have a hardware feature which enables
> them to generate imitation-x86 interrupt acknowledge cycles, so you
> can keep the 8259s in complete ignorance that they're not being
> controlled by an x86.
Unless the hardware is an RM200 where under special circumstances the
hardware acknowledge feature may result in loss of some or all i8259
interrupts until full-reinitialization of the i8259 ...
Bugs, bugs ...
Ralf
^ 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.