* Re: .reginfo and .mdebug section
From: Ralf Baechle @ 2002-12-17 13:39 UTC (permalink / raw)
To: Long Li; +Cc: linux-mips
In-Reply-To: <20021217084303.20121.qmail@web40407.mail.yahoo.com>
On Tue, Dec 17, 2002 at 12:43:03AM -0800, Long Li wrote:
> 1. I tried to compile some c code targetting mips4k,
> which is 32-bit ISA. However, the map file tells me
> that the compiled code are 64-bit, since the address
> are 64-bit.
>
> 2. When I compiled the c code, I found in the mapfile
> that there are some sections called .reginfo and
> .mdebug. What are those sections? I would like to get
> rid of them. However, they still exists even if I
> deleted the '-g' option for gcc. Is there a way I can
> avoid the .reginfo and .mdebug sections?
.reginfo is MIPS ABI mandated brain damage described the register usage of
a given object or shared object. I know of nothing that actually is using
these sections. It's always just 24 bytes so not really worth alot of fuzz
though. With some binutils versions you can remove this section with
objcopy --remove-section=.reginfo. Some binutils version however will just
create a new .reginfo section during objcopy so with those this won't work.
.mdebug is the MIPS ABI mdebug stuff, debug information. You should be
able to get rid of those with -g, at least my tools here don't create it
by default.
Ralf
^ permalink raw reply
* Re: Domain transition
From: Russell Coker @ 2002-12-17 13:31 UTC (permalink / raw)
To: Brian May; +Cc: SELinux
In-Reply-To: <20021217114203.GB5969@snoopy.apana.org.au>
On Tue, 17 Dec 2002 12:42, Brian May wrote:
> > Kerberos still isn't safe, proxying the telnet protocol and hijacking it
> > is not overly difficult...
>
> Do you have a reference?
Is one really needed?
Redirecting a port 23 connection to one on the local machine and then
establishing a new connection to the server is quite easy if you control a
router. Going from that to taking over an idle session is quite easy.
--
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: kmalloc and startup process
From: Joakim Tjernlund @ 2002-12-17 13:19 UTC (permalink / raw)
To: Pantelis Antoniou, linuxppc-embedded
In-Reply-To: <3DFF1DF4.8010005@intracom.gr>
Don't know when it's safe to call kmalloc, but maybe you
should avoid kmalloc? Is it possible to use
kmalloc when the microcode(8xx_io/micropatch.c) is loaded?
Jocke
>
>
> Hi
>
> I'm hacking now the 8xx hostalloc and dpalloc stuff,
> and I have a a question.
>
> At what point in the startup process is it OK to call
> kmalloc?
>
> I don't think it is safe at the setup_arch point.
>
> Is this correct?
>
> Thanks
>
> --
> Pantelis Antoniou
> INTRACOM S.A. Greece
>
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: netfilter digest, Vol 1 #472 - 8 msgs
From: Jerry Mercks @ 2002-12-17 13:19 UTC (permalink / raw)
To: netfilter
In-Reply-To: <20021217130002.12807.44638.Mailman@kashyyyk>
On Tue December 17 2002 07:00 am, netfilter-request@lists.netfilter.org wrote:
. > Send netfilter mailing list submissions to
> netfilter@lists.netfilter.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.netfilter.org/mailman/listinfo/netfilter
> or, via email, send a message with subject or body 'help' to
> netfilter-request@lists.netfilter.org
>
> You can reach the person managing the list at
> netfilter-admin@lists.netfilter.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of netfilter digest..."
>
>
> Today's Topics:
>
> 1. RE: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination Unreacha
> ble) (Rob Sterenborg)
> 2. Re: "iptables: Invalid argument" with kernel 2.4.20 (cees-bart)
> 3. Re: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination Unreachable)
> (hare ram) 4. QoS limitations .... (Raymond Leach)
> 5. Re: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination
> Unreachable) (Marcello Scacchetti)
> 6. Re: Help! ip traffic accounting and bidirection with iptables ??
> (Oskar Berggren)
>
> --__--__--
>
> Message: 1
> From: Rob Sterenborg <r.sterenborg@hsl-brabantzuid.nl>
> To: "'netfilter@lists.netfilter.org'" <netfilter@lists.netfilter.org>
> Subject: RE: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination Unreacha
> ble)
> Date: Tue, 17 Dec 2002 10:41:16 +0100
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_001_01C2A5B0.71B35340
> Content-Type: text/plain
>
> > Is it possible to use IPTables version 1.2.7a with Redhat
> > 7.3? RH 7.3 comes with a different version by default and I
> > wanted to upgrade to 1.2.7a. Is it possible?
>
> Yes, you can compile a brand new version for your own system.
> It's not that hard...
>
> > Also, do you know if any RPMs exist for IPTables version
> > 1.2.7a and RH 7.3?
>
> A Google search on "iptables 1.2.7a redhat rpm" returns results like
> http://www.haoli.org/rpm/redhat-7.x/RPMS/i386/.
> But I still think you'd better compile your own.
>
>
> Rob
>
> ------_=_NextPart_001_01C2A5B0.71B35340
> Content-Type: text/html
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dus-ascii">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 5.5.2653.12">
> <TITLE>RE: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination =
> Unreachable)</TITLE>
> </HEAD>
> <BODY>
>
> <P><FONT SIZE=3D2>> Is it possible to use IPTables version 1.2.7a =
> with Redhat </FONT>
> <BR><FONT SIZE=3D2>> 7.3? RH 7.3 comes with a different =
> version by default and I </FONT>
> <BR><FONT SIZE=3D2>> wanted to upgrade to 1.2.7a. Is it =
> possible?</FONT>
> </P>
>
> <P><FONT SIZE=3D2>Yes, you can compile a brand new version for your own =
> system.</FONT>
> <BR><FONT SIZE=3D2>It's not that hard...</FONT>
> </P>
>
> <P><FONT SIZE=3D2>> Also, do you know if any RPMs exist for IPTables =
> version </FONT>
> <BR><FONT SIZE=3D2>> 1.2.7a and RH 7.3?</FONT>
> </P>
>
> <P><FONT SIZE=3D2>A Google search on "iptables 1.2.7a redhat =
> rpm" returns results like <A =
> HREF=3D"http://www.haoli.org/rpm/redhat-7.x/RPMS/i386/" =
> TARGET=3D"_blank">http://www.haoli.org/rpm/redhat-7.x/RPMS/i386/</A>.</F=
> ONT>
> <BR><FONT SIZE=3D2>But I still think you'd better compile your =
> own.</FONT>
> </P>
> <BR>
>
> <P><FONT SIZE=3D2>Rob</FONT>
> </P>
>
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C2A5B0.71B35340--
>
>
> --__--__--
>
> Message: 2
> Date: Tue, 17 Dec 2002 10:55:33 +0100 (CET)
> From: cees-bart <ceesb@cs.kun.nl>
> To: netfilter@lists.netfilter.org
> Subject: Re: "iptables: Invalid argument" with kernel 2.4.20
>
> On Mon, 16 Dec 2002, Joel Newkirk wrote:
> > On Monday 16 December 2002 11:25 am, cees-bart wrote:
> > > hi all,
> > >
> > > -A OUTPUT -d MYMACHINE -p udp -m udp --dport 27960 -j DNAT \
> > > --to-destination OTHERMACHINE:30000
> > >
> > > this setup works fine on kernel 2.4.19 with iptables 1.2.6a.
> > >
> > > BUT, the last rule (OUTPUT) fails with message "iptables: Invalid
> > > argument" when running under 2.4.20.
> >
> > Have you tried manually creating the rule, or are you restoring from a
> > save made with the earlier version?
>
> i tried both, and i found my mistake:
>
> i forgot to enable CONFIG_IP_NF_NAT_LOCAL in the kernel.
> sorry for the trouble.
>
> bye,
> cees-bart
>
>
>
> --__--__--
>
> Message: 3
> Reply-To: "hare ram" <hareram@sol.net.in>
> From: "hare ram" <hareram@sol.net.in>
> To: "freedom" <freedom10@idemation.com>,
> "'Marcello Scacchetti'" <marcello.scacchetti@nextrem.it>,
> <netfilter@lists.netfilter.org>
> Subject: Re: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination
> Unreachable) Date: Tue, 17 Dec 2002 16:11:41 +0530
>
> hi
>
> yes you can patch up the kernel with new version
> but there is no Latest rpm availbale for 1.2.7a
>
> you need to use only 1.2.6a latest RPM with Redhat 8.0
> ----- Original Message -----
> From: "freedom" <freedom10@idemation.com>
> To: "'Marcello Scacchetti'" <marcello.scacchetti@nextrem.it>;
> <netfilter@lists.netfilter.org>
> Sent: Tuesday, December 17, 2002 9:23 AM
> Subject: RE: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination
> Unreachable)
>
> > Marcello,
> >
> > Sure...
> >
> > Is it possible to use IPTables version 1.2.7a with Redhat 7.3? RH 7.3
> > comes with a different version by default and I wanted to upgrade to
> > 1.2.7a. Is it possible?
> >
> > Also, do you know if any RPMs exist for IPTables version 1.2.7a and RH
> > 7.3?
> >
> > Thanks!
> > Kameron
> >
> > > -----Original Message-----
> > > From: netfilter-admin@lists.netfilter.org [mailto:netfilter-
> > > admin@lists.netfilter.org] On Behalf Of Marcello Scacchetti
> > > Sent: Monday, December 16, 2002 7:18 AM
> > > To: netfilter@lists.netfilter.org
> > > Subject: Re: ICMP Destination Unreachable
> > >
> > > Hi Kameron,
> > > can you be a little more verbose?
> > > What does "run" means? Unable to set rules? Unable to run iptables
> > > command? Unable to make rules work?
> > >
> > > Marcello
> > >
> > > Il ven, 2002-12-06 alle 16:09, Kameron ha scritto:
> > > > Hello Gurus,
> > > >
> > > > I have a couple of quick questions...
> > > >
> > > > 1) Does anybody know of any reason why I couldn't run IPTables
> >
> > 1.2.7a
> >
> > > > with RH7.3.
> > > >
> > > > 2) Are there any .rpm's for IPTables 1.2.7.a available? I attempted
> >
> > to
> >
> > > > compile my own, but didn't have any luck.
> > > >
> > > > Thanks!
> > > > Kameron
> > >
> > > --
> > > Marcello Scacchetti <marcello.scacchetti@nextrem.it>
>
> --__--__--
>
> Message: 4
> Subject: QoS limitations ....
> From: Raymond Leach <raymondl@knowledgefactory.co.za>
> Reply-To: raymondl@knowledgefactory.co.za
> To: Netfilter Mailing List <netfilter@lists.netfilter.org>
> Organization: Knowledge Factory
> Date: 17 Dec 2002 13:16:53 +0200
>
>
> --=-v0Q1ipdrgEbeJlI9Gfbs
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
>
> Hi all
>
> Does anyone know of a limit to the number of filters or classes that can
> be attached to a single qdisc (let's say CBQ or HTB)?
>
> I have a client that want to do bandwidth throttling per ip across 10
> class C subnets.
>
> What problems can I expect, and does anyone have any other suggestions
> on how to accomplish this?
>
> Ray
>
> --=20
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ( Raymond Leach )
> ) Knowledge Factory (
> ( )
> ) Tel: +27 11 445 8100 (
> ( Fax: +27 11 445 8101 )
> ) (
> ( http://www.knowledgefactory.co.za/ )
> ) http://www.saptg.co.za/ (
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> o o
> o o
> .--. .--.
>
> | o_o| |o_o |
> | \_:| |:_/ |
>
> / / \\ // \ \
> ( | |) (| | )
> /`\_ _/'\ /'\_ _/`\
> \___)=3D(___/ \___)=3D(___/
>
> --=-v0Q1ipdrgEbeJlI9Gfbs
> Content-Type: application/pgp-signature; name=signature.asc
> Content-Description: This is a digitally signed message part
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
>
> iD8DBQA9/wekh1fuR/Bv+ygRAqC1AKCGgs7sRhCOZfqaWlj/Z5+ryANHPACfQz5f
> P989v/Mb15P+IRCOiifmLng=
> =8R+h
> -----END PGP SIGNATURE-----
>
> --=-v0Q1ipdrgEbeJlI9Gfbs--
>
>
>
> --__--__--
>
> Message: 5
> Subject: Re: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination
> Unreachable)
> From: Marcello Scacchetti <marcello.scacchetti@nextrem.it>
> To: hare ram <hareram@sol.net.in>
> Cc: freedom <freedom10@idemation.com>, netfilter@lists.netfilter.org
> Organization:
> Date: 17 Dec 2002 11:01:56 +0100
>
> Try check here: http://www.haoli.org/rpm/redhat-7.x/RPMS/i386/
>
> Marcello
>
> Il mar, 2002-12-17 alle 11:41, hare ram ha scritto:
> > hi
> >
> > yes you can patch up the kernel with new version
> > but there is no Latest rpm availbale for 1.2.7a
> >
> > you need to use only 1.2.6a latest RPM with Redhat 8.0
> > ----- Original Message -----
> > From: "freedom" <freedom10@idemation.com>
> > To: "'Marcello Scacchetti'" <marcello.scacchetti@nextrem.it>;
> > <netfilter@lists.netfilter.org>
> > Sent: Tuesday, December 17, 2002 9:23 AM
> > Subject: RE: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination
> > Unreachable)
> >
> > > Marcello,
> > >
> > > Sure...
> > >
> > > Is it possible to use IPTables version 1.2.7a with Redhat 7.3? RH 7.3
> > > comes with a different version by default and I wanted to upgrade to
> > > 1.2.7a. Is it possible?
> > >
> > > Also, do you know if any RPMs exist for IPTables version 1.2.7a and RH
> > > 7.3?
> > >
> > > Thanks!
> > > Kameron
> > >
> > > > -----Original Message-----
> > > > From: netfilter-admin@lists.netfilter.org [mailto:netfilter-
> > > > admin@lists.netfilter.org] On Behalf Of Marcello Scacchetti
> > > > Sent: Monday, December 16, 2002 7:18 AM
> > > > To: netfilter@lists.netfilter.org
> > > > Subject: Re: ICMP Destination Unreachable
> > > >
> > > > Hi Kameron,
> > > > can you be a little more verbose?
> > > > What does "run" means? Unable to set rules? Unable to run iptables
> > > > command? Unable to make rules work?
> > > >
> > > > Marcello
> > > >
> > > > Il ven, 2002-12-06 alle 16:09, Kameron ha scritto:
> > > > > Hello Gurus,
> > > > >
> > > > > I have a couple of quick questions...
> > > > >
> > > > > 1) Does anybody know of any reason why I couldn't run IPTables
> > >
> > > 1.2.7a
> > >
> > > > > with RH7.3.
> > > > >
> > > > > 2) Are there any .rpm's for IPTables 1.2.7.a available? I
> > > > > attempted
> > >
> > > to
> > >
> > > > > compile my own, but didn't have any luck.
> > > > >
> > > > > Thanks!
> > > > > Kameron
> > > >
> > > > --
> > > > Marcello Scacchetti <marcello.scacchetti@nextrem.it>
--
Jerry Mercks, MCSE
Phone: 256 881 1492
Public key may be obtained from www.keyserver.net
Search for Mercks. Use Key ID 853422D
This private communication is intended for the named recipient(s) only.
If you have received this message in error please delete at once and notify
merckspub@comcast.net.
Please be advised that use, distribution, copying, reliance on or disclosure
of the contents of this message by anyone other than named recipient may
be inappropriate and may be in violation of laws relating to confidential
information.
^ permalink raw reply
* Re: Mailing list archive?
From: Ralf Baechle @ 2002-12-17 13:12 UTC (permalink / raw)
To: Colin.Helliwell; +Cc: linux-mips
In-Reply-To: <OFF84687E4.3C703F56-ON80256C92.003940E0@zarlink.com>
On Tue, Dec 17, 2002 at 10:28:05AM +0000, Colin.Helliwell@Zarlink.Com wrote:
> Where does the list archive live these days? The only pointer I could find
> to it is:
>
> ftp://ftp.linux-mips.org/pub/linux/mips/archives/linux-mips.org/linux-mips/
> but I get "permission denied"
Fixed. The filesystems didn't get mounted after the last reboot ...
Ralf
^ permalink raw reply
* Re: Notification hooks
From: Ben Collins @ 2002-12-17 13:18 UTC (permalink / raw)
To: David Woodhouse
Cc: Arjan van de Ven, Larry McVoy, Linus Torvalds, linux-kernel,
Larry McVoy
In-Reply-To: <14583.1040115907@passion.cambridge.redhat.com>
On Tue, Dec 17, 2002 at 09:05:07AM +0000, David Woodhouse wrote:
>
> bcollins@debian.org said:
> > Problem is that my changeset isn't even listed there. Not a very
> > dependable way to get that info.
>
> Isn't it? Why not? What changeset was it?
Not in my mbox. Don't know. 1.863.3.1, according to bkbits.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
^ permalink raw reply
* Re: 2.4.20 copy_from/to_user
From: Richard B. Johnson @ 2002-12-17 13:20 UTC (permalink / raw)
To: Gianni Tedesco; +Cc: Margit Schubert-While, linux-kernel
In-Reply-To: <1040129576.1768.14.camel@lemsip>
On 17 Dec 2002, Gianni Tedesco wrote:
> On Tue, 2002-12-17 at 10:42, Margit Schubert-While wrote:
> > Maybe talking through the top of my hat , however -
> > copy_from_user and copy_to_user are used all over the place and the
> > return tested to see if an EFAULT should be generated.
> > Looking at include/asm-i386/uaccess.h and arch/i386/lib/usercopy.c
> > I don't see how these return anything but the 3rd (length) param.
>
> Kernel glibly copies data until a exception occurs, when that happens it
> looks at the address of the faulting instruction and jumps to some fixup
> code, which somehow makes the function returns the truncated value.
>
> grep for ".section .fixup" and ".section .__ex_table." in those files.
>
The 'somehow' is that ecx contains the count which is decremented
until the exception occurs. So, the return value (in eax) is the
remaining count. If no exception occurs, then it will be zero.
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
* make install , or make modules error in 2.5.52
From: eric lin @ 2002-12-17 21:18 UTC (permalink / raw)
To: linux-kernel
Dear linux Kernel programmers:
I untar 2.5.52 and in its directory, make-kpkg (in debian platform)
it end with error
mv -f .tmp_version .version
/usr/bin/make -f scripts/Makefile.build obj=init
Generating include/linux/compile.h (updated)
gcc -Wp,-MD,init/.version.o.d -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=i686 -Iarch/i386/mach-generic
-fomit-frame-pointer -nostdinc -iwithprefix include
-DKBUILD_BASENAME=version -DKBUILD_MODNAME=version -c -o
init/version.o init/version.c
ld -m elf_i386 -r -o init/built-in.o init/main.o init/version.o
init/do_mounts.o init/initramfs.o
ld -m elf_i386 -e stext -T arch/i386/vmlinux.lds.s
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/built-in.o
--start-group usr/built-in.o arch/i386/kernel/built-in.o
arch/i386/mm/built-in.o arch/i386/mach-generic/built-in.o
kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
security/built-in.o crypto/built-in.o lib/lib.a arch/i386/lib/lib.a
drivers/built-in.o sound/built-in.o arch/i386/pci/built-in.o
net/built-in.o --end-group -o vmlinux
drivers/built-in.o(.text+0x16e3f): In function `kd_nosound':
: undefined reference to `input_event'
drivers/built-in.o(.text+0x16e58): In function `kd_nosound':
: undefined reference to `input_event'
drivers/built-in.o(.text+0x16ee8): In function `kd_mksound':
: undefined reference to `input_event'
drivers/built-in.o(.text+0x17a8a): In function `kbd_bh':
: undefined reference to `input_event'
drivers/built-in.o(.text+0x17a98): In function `kbd_bh':
: undefined reference to `input_event'
drivers/built-in.o(.text+0x17aa9): more undefined references to
`input_event' follow
drivers/built-in.o(.text+0x17ec3): In function `kbd_connect':
: undefined reference to `input_open_device'
drivers/built-in.o(.text+0x17edf): In function `kbd_disconnect':
: undefined reference to `input_close_device'
drivers/built-in.o(.init.text+0x1891): In function `kbd_init':
: undefined reference to `input_register_handler'
make[1]: *** [vmlinux] Error 1
make[1]: Leaving directory `/home/fsshl/linux-2.5.52'
make: *** [stamp-build] Error 2
Please nitfy and drop me a note if someone or someway to fix it
--
Sincere Eric
www.linuxspice.com
linux pc for sale
^ permalink raw reply
* Re: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination Unreachable)
From: Arnt Karlsen @ 2002-12-17 12:59 UTC (permalink / raw)
To: netfilter
In-Reply-To: <025b01c2a5b8$e2e7c200$13fcc5cb@nextto>
On Tue, 17 Dec 2002 16:11:41 +0530,
"hare ram" <hareram@sol.net.in> top-posted in
message <025b01c2a5b8$e2e7c200$13fcc5cb@nextto>:
> hi
>
> yes you can patch up the kernel with new version
> but there is no Latest rpm availbale for 1.2.7a
..no? 'rpmbuild -ta iptables-1.2.7a.tar.bz2' or somesuch.
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
^ permalink raw reply
* Re: Domain transition
From: Justin Smith @ 2002-12-17 12:52 UTC (permalink / raw)
To: SELinux
I think domain transition is one of the key security features of
SELinux:
The one domain with high privileges similar to the old root privileges
is the initrc_t domain. But transitions cause this domain to "cease to
exist" by the time Linux has completely booted.
--
--
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
* kmalloc and startup process
From: Pantelis Antoniou @ 2002-12-17 12:52 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I'm hacking now the 8xx hostalloc and dpalloc stuff,
and I have a a question.
At what point in the startup process is it OK to call
kmalloc?
I don't think it is safe at the setup_arch point.
Is this correct?
Thanks
--
Pantelis Antoniou
INTRACOM S.A. Greece
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Multithreaded coredump patch where?
From: Roberto Fichera @ 2002-12-17 12:51 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel
In-Reply-To: <1040126717.10064.2.camel@laptop.fenrus.com>
At 13.05 17/12/02 +0100, Arjan van de Ven wrote:
>On Tue, 2002-12-17 at 12:05, Roberto Fichera wrote:
> > At 13.21 16/12/02 -0800, mgross wrote:
> >
> > >I haven't rebased the patches I posted back in June for a while now.
> > >
> > >Attached is the patch I posted for the 2.4.18 vanilla kernel. Its a bit
> > >controversial, but it seems to work for a number of folks. Let me know if
> > >you have any troubles re-basing it.
> >
> > Only one hunk failed on include/asm-ia64/elf.h but fixed by hand.
> > Why do you say a bit controversial ?
>
>The design has theoretical (but probably in practice not trivial to
>trigger) deadlocks; by design it prevents processes that are sleeping
>from running, regardless whether those processes are in kernel space or
>not. If they are in kernel space, they can accidentally be holding a
>semaphore that something in the core dumping path will need to get (but
>can't because it never will be released). There are not that many of
>such semaphores (kmap semaphore is one, and filesystems can have several
>internally)
Ok! Now I see why! This problem should be avoided if the coredump algo
will permit to complete the kernel execution for all the threads that
need it, and just before to reenter in userspace, all the threads will
freeze in
a know point so the coredump can continue with the snapshot. Not easy ;-)!
Roberto Fichera.
______________________________________
E-mail protetta dal servizio antivirus di IsolaWeb Agency & ISP
http://wwww.isolaweb.it
^ permalink raw reply
* Re: 2.4.20 copy_from/to_user
From: Gianni Tedesco @ 2002-12-17 12:52 UTC (permalink / raw)
To: Margit Schubert-While; +Cc: linux-kernel
In-Reply-To: <4.3.2.7.2.20021217112614.00b55eb0@pop.t-online.de>
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
On Tue, 2002-12-17 at 10:42, Margit Schubert-While wrote:
> Maybe talking through the top of my hat , however -
> copy_from_user and copy_to_user are used all over the place and the
> return tested to see if an EFAULT should be generated.
> Looking at include/asm-i386/uaccess.h and arch/i386/lib/usercopy.c
> I don't see how these return anything but the 3rd (length) param.
Kernel glibly copies data until a exception occurs, when that happens it
looks at the address of the faulting instruction and jumps to some fixup
code, which somehow makes the function returns the truncated value.
grep for ".section .fixup" and ".section .__ex_table." in those files.
--
// Gianni Tedesco (gianni at ecsc dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* memory management bug??
From: Owen Green @ 2002-12-17 12:44 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <IGEFJKJNHJDCBKALBJLLEECEFIAA.joakim.tjernlund@lumentis.se>
[-- Attachment #1: Type: text/plain, Size: 467 bytes --]
Hi all,
I was making some tests in my linux box and I just
realized that when the system goes to a "low memory
state" kswapd gets almost all the cpu, I've got this
from top (see attached file). But the worst I guess is
that I can't see to where my memory has gone, top
output and /proc/meminfo seems to be "hidding" some
...
I'm using kernel 2.4.4 from Denx, is there memory leak
in this kernel version? How can I reduce kswapd cpu
usage?
Thanks in advance,
Owen.
[-- Attachment #2: memory_problems_output.txt --]
[-- Type: text/plain, Size: 1305 bytes --]
12:34am up 34 min, 0 users, load average: 1.37, 1.33, 0.89
9 processes: 7 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 7.2% user, 92.8% system, 0.0% nice, 0.0% idle
Mem: 14712K total, 13696K used, 1016K free, 6144K buffers
Swap: 0K total, 0K used, 0K free, 4812K cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
3 root 16 0 0 0 0 RW 78.4 0.0 12:20 kswapd
150 root 18 0 420 428 120 R 18.9 2.8 0:19 top
5 root 9 0 0 0 0 SW 2.9 0.0 0:28 bdflush
1 root 8 0 144 144 0 S 0.0 0.9 0:26 init
2 root 9 0 0 0 0 SW 0.0 0.0 0:00 keventd
4 root 9 0 0 0 0 SW 0.0 0.0 0:00 kreclaimd
6 root 9 0 0 0 0 SW 0.0 0.0 0:01 kupdated
21 root 9 0 212 212 0 S 0.0 1.4 0:11 sh
106 root 9 0 224 224 0 S 0.0 1.5 0:00 xinetd
# ps
PID Uid Stat Command
1 root S init
2 root S [keventd]
3 root R [kswapd]
4 root S [kreclaimd]
5 root S [bdflush]
6 root S [kupdated]
21 root S -sh
106 root S xinetd
151 root R ps
#
^ permalink raw reply
* compute_return_epc
From: Ralf Baechle @ 2002-12-17 12:43 UTC (permalink / raw)
To: linux-mips
The current kernel code is calling compute_return_epc() in most exception
handlers for skipping over the instruction. We're doing thins in practically
all cases. To my knowledge we're the only MIPS UNIX flavor doing that
which my result in software portabilitiy problems. It also means that
debuggers and signal handlers in such a case will only ever see the new
program counter but never a pointer to the actually faulting instruction.
So I'd like to apply the following patch which limits the use of
compute_return_epc to those cases where we actually did some sort of
instruction emulation. Comments?
Ralf
Index: arch/mips/kernel/traps.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/traps.c,v
retrieving revision 1.99.2.36
diff -u -r1.99.2.36 traps.c
--- arch/mips/kernel/traps.c 17 Dec 2002 01:43:05 -0000 1.99.2.36
+++ arch/mips/kernel/traps.c 17 Dec 2002 12:07:48 -0000
@@ -96,7 +96,7 @@
static struct task_struct *ll_task = NULL;
-static inline void simulate_ll(struct pt_regs *regp, unsigned int opcode)
+static inline void simulate_ll(struct pt_regs *regs, unsigned int opcode)
{
unsigned long value, *vaddr;
long offset;
@@ -112,32 +112,37 @@
offset <<= 16;
offset >>= 16;
- vaddr = (unsigned long *)((long)(regp->regs[(opcode & BASE) >> 21]) + offset);
+ vaddr = (unsigned long *)((long)(regs->regs[(opcode & BASE) >> 21]) + offset);
#ifdef CONFIG_PROC_FS
ll_ops++;
#endif
- if ((unsigned long)vaddr & 3)
+ if ((unsigned long)vaddr & 3) {
signal = SIGBUS;
- else if (get_user(value, vaddr))
+ goto sig;
+ }
+ if (get_user(value, vaddr)) {
signal = SIGSEGV;
- else {
- if (ll_task == NULL || ll_task == current) {
- ll_bit = 1;
- } else {
- ll_bit = 0;
- }
- ll_task = current;
- regp->regs[(opcode & RT) >> 16] = value;
+ goto sig;
}
- if (compute_return_epc(regp))
- return;
- if (signal)
- send_sig(signal, current, 1);
+
+ if (ll_task == NULL || ll_task == current) {
+ ll_bit = 1;
+ } else {
+ ll_bit = 0;
+ }
+ ll_task = current;
+ regs->regs[(opcode & RT) >> 16] = value;
+
+ compute_return_epc(regs);
+ return;
+
+sig:
+ send_sig(signal, current, 1);
}
-static inline void simulate_sc(struct pt_regs *regp, unsigned int opcode)
+static inline void simulate_sc(struct pt_regs *regs, unsigned int opcode)
{
unsigned long *vaddr, reg;
long offset;
@@ -153,25 +158,32 @@
offset <<= 16;
offset >>= 16;
- vaddr = (unsigned long *)((long)(regp->regs[(opcode & BASE) >> 21]) + offset);
+ vaddr = (unsigned long *)((long)(regs->regs[(opcode & BASE) >> 21]) + offset);
reg = (opcode & RT) >> 16;
#ifdef CONFIG_PROC_FS
sc_ops++;
#endif
- if ((unsigned long)vaddr & 3)
+ if ((unsigned long)vaddr & 3) {
signal = SIGBUS;
- else if (ll_bit == 0 || ll_task != current)
- regp->regs[reg] = 0;
- else if (put_user(regp->regs[reg], vaddr))
+ goto sig;
+ }
+ if (ll_bit == 0 || ll_task != current) {
+ regs->regs[reg] = 0;
+ goto sig;
+ }
+
+ if (put_user(regs->regs[reg], vaddr))
signal = SIGSEGV;
else
- regp->regs[reg] = 1;
- if (compute_return_epc(regp))
- return;
- if (signal)
- send_sig(signal, current, 1);
+ regs->regs[reg] = 1;
+
+ compute_return_epc(regs);
+ return;
+
+sig:
+ send_sig(signal, current, 1);
}
/*
@@ -489,9 +501,6 @@
{
siginfo_t info;
- if (compute_return_epc(regs))
- return;
-
info.si_code = FPE_INTOVF;
info.si_signo = SIGFPE;
info.si_errno = 0;
@@ -534,20 +543,11 @@
/* If something went wrong, signal */
if (sig)
- {
- /*
- * Return EPC is not calculated in the FPU emulator,
- * if a signal is being send. So we calculate it here.
- */
- compute_return_epc(regs);
force_sig(sig, current);
- }
return;
}
- if (compute_return_epc(regs))
- return;
force_sig(SIGFPE, current);
}
@@ -670,8 +670,6 @@
}
#endif /* CONFIG_CPU_HAS_LLSC */
- if (compute_return_epc(regs))
- return;
force_sig(SIGILL, current);
}
@@ -695,14 +693,8 @@
if (!(mips_cpu.options & MIPS_CPU_FPU)) {
int sig = fpu_emulator_cop1Handler(0, regs, ¤t->thread.fpu.soft);
- if (sig) {
- /*
- * Return EPC is not calculated in the FPU emulator, if
- * a signal is being send. So we calculate it here.
- */
- compute_return_epc(regs);
+ if (sig)
force_sig(sig, current);
- }
}
return;
@@ -716,7 +708,6 @@
return;
}
#endif
- compute_return_epc(regs);
force_sig(SIGILL, current);
}
@@ -823,28 +814,28 @@
*/
void ejtag_exception_handler(struct pt_regs *regs)
{
- unsigned long depc, old_epc;
- unsigned int debug;
+ unsigned long depc, old_epc;
+ unsigned int debug;
- printk("SDBBP EJTAG debug exception - not handled yet, just ignored!\n");
- depc = read_c0_depc();
- debug = read_c0_debug();
- printk("c0_depc = %08lx, DEBUG = %08x\n", depc, debug);
- if (debug & 0x80000000) {
- /*
- * In branch delay slot.
- * We cheat a little bit here and use EPC to calculate the
- * debug return address (DEPC). EPC is restored after the
- * calculation.
- */
- old_epc = regs->cp0_epc;
- regs->cp0_epc = depc;
- __compute_return_epc(regs);
- depc = regs->cp0_epc;
- regs->cp0_epc = old_epc;
- } else
- depc += 4;
- write_c0_depc(depc);
+ printk("SDBBP EJTAG debug exception - not handled yet, just ignored!\n");
+ depc = read_c0_depc();
+ debug = read_c0_debug();
+ printk("c0_depc = %08lx, DEBUG = %08x\n", depc, debug);
+ if (debug & 0x80000000) {
+ /*
+ * In branch delay slot.
+ * We cheat a little bit here and use EPC to calculate the
+ * debug return address (DEPC). EPC is restored after the
+ * calculation.
+ */
+ old_epc = regs->cp0_epc;
+ regs->cp0_epc = depc;
+ __compute_return_epc(regs);
+ depc = regs->cp0_epc;
+ regs->cp0_epc = old_epc;
+ } else
+ depc += 4;
+ write_c0_depc(depc);
#if 0
printk("\n\n----- Enable EJTAG single stepping ----\n\n");
Index: arch/mips/kernel/unaligned.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/unaligned.c,v
retrieving revision 1.15.2.9
diff -u -r1.15.2.9 unaligned.c
--- arch/mips/kernel/unaligned.c 7 Dec 2002 17:46:47 -0000 1.15.2.9
+++ arch/mips/kernel/unaligned.c 17 Dec 2002 12:07:48 -0000
@@ -88,6 +88,10 @@
#define STR(x) __STR(x)
#define __STR(x) #x
+#ifdef CONFIG_PROC_FS
+unsigned long unaligned_instructions;
+#endif
+
static inline int emulate_load_store_insn(struct pt_regs *regs,
unsigned long addr, unsigned long pc)
{
@@ -447,6 +451,13 @@
*/
goto sigill;
}
+
+ compute_return_epc(regs);
+
+#ifdef CONFIG_PROC_FS
+ unaligned_instructions++;
+#endif
+
return 0;
fault:
@@ -479,10 +490,6 @@
return 0;
}
-#ifdef CONFIG_PROC_FS
-unsigned long unaligned_instructions;
-#endif
-
asmlinkage void do_ade(struct pt_regs *regs)
{
unsigned long pc;
@@ -516,12 +523,7 @@
* Do branch emulation only if we didn't forward the exception.
* This is all so but ugly ...
*/
- if (!emulate_load_store_insn(regs, regs->cp0_badvaddr, pc))
- compute_return_epc(regs);
-
-#ifdef CONFIG_PROC_FS
- unaligned_instructions++;
-#endif
+ emulate_load_store_insn(regs, regs->cp0_badvaddr, pc);
return;
Index: arch/mips64/kernel/traps.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/traps.c,v
retrieving revision 1.30.2.39
diff -u -r1.30.2.39 traps.c
--- arch/mips64/kernel/traps.c 17 Dec 2002 01:43:05 -0000 1.30.2.39
+++ arch/mips64/kernel/traps.c 17 Dec 2002 12:07:49 -0000
@@ -400,9 +400,6 @@
{
siginfo_t info;
- if (compute_return_epc(regs))
- return;
-
info.si_code = FPE_INTOVF;
info.si_signo = SIGFPE;
info.si_errno = 0;
@@ -445,20 +442,11 @@
/* If something went wrong, signal */
if (sig)
- {
- /*
- * Return EPC is not calculated in the FPU emulator,
- * if a signal is being send. So we calculate it here.
- */
- compute_return_epc(regs);
force_sig(sig, current);
- }
return;
}
- if (compute_return_epc(regs))
- return;
force_sig(SIGFPE, current);
}
@@ -552,9 +540,6 @@
{
die_if_kernel("Reserved instruction in kernel code", regs);
- if (compute_return_epc(regs))
- return;
-
force_sig(SIGILL, current);
}
@@ -578,20 +563,13 @@
if (!(mips_cpu.options & MIPS_CPU_FPU)) {
int sig = fpu_emulator_cop1Handler(0, regs, ¤t->thread.fpu.soft);
- if (sig) {
- /*
- * Return EPC is not calculated in the FPU emulator, if
- * a signal is being send. So we calculate it here.
- */
- compute_return_epc(regs);
+ if (sig)
force_sig(sig, current);
- }
}
return;
bad_cid:
- compute_return_epc(regs);
force_sig(SIGILL, current);
}
Index: arch/mips64/kernel/unaligned.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/unaligned.c,v
retrieving revision 1.6.2.8
diff -u -r1.6.2.8 unaligned.c
--- arch/mips64/kernel/unaligned.c 7 Dec 2002 17:46:47 -0000 1.6.2.8
+++ arch/mips64/kernel/unaligned.c 17 Dec 2002 12:07:50 -0000
@@ -88,6 +88,10 @@
#define STR(x) __STR(x)
#define __STR(x) #x
+#ifdef CONFIG_PROC_FS
+unsigned long unaligned_instructions;
+#endif
+
static inline int emulate_load_store_insn(struct pt_regs *regs,
unsigned long addr, unsigned long pc)
{
@@ -447,6 +451,13 @@
*/
goto sigill;
}
+
+ compute_return_epc(regs);
+
+#ifdef CONFIG_PROC_FS
+ unaligned_instructions++;
+#endif
+
return 0;
fault:
@@ -479,10 +490,6 @@
return 0;
}
-#ifdef CONFIG_PROC_FS
-unsigned long unaligned_instructions;
-#endif
-
asmlinkage void do_ade(struct pt_regs *regs)
{
unsigned long pc;
@@ -516,12 +523,7 @@
* Do branch emulation only if we didn't forward the exception.
* This is all so but ugly ...
*/
- if (!emulate_load_store_insn(regs, regs->cp0_badvaddr, pc))
- compute_return_epc(regs);
-
-#ifdef CONFIG_PROC_FS
- unaligned_instructions++;
-#endif
+ emulate_load_store_insn(regs, regs->cp0_badvaddr, pc);
return;
^ permalink raw reply
* Re: [drm:drm_init] *ERROR* Cannot initialize the agpgart module.
From: Ed Tomlinson @ 2002-12-17 12:50 UTC (permalink / raw)
To: Paul P Komkoff Jr, linux-kernel, Dave Jones, Rusty Russell
In-Reply-To: <20021217080626.GE2496@stingr.net>
Paul P Komkoff Jr wrote:
> Replying to Ed Tomlinson:
>> I am getting the above message in 2.5.51, 52, and 52+bk current.
>> Pci info follows:
>> What else would help to debug this? The drm error above is all I find in
>> the logs...
>
> If you mount devfs somewhere you also don't find misc/agpgart inside ?
> :)))
>
> And nothing about agp aperture in dmesg?
Not normally. If I modprobe via-agp modprobe segfaults (a Rusty's bug),
but via_agp and agpgart get loaded (note that - changed to _ when the module
is loaded - it has dash in file in the directory). Doing it this time gets
an oops (52bk as of last night):
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA MVP3 chipset
Unable to handle kernel paging request at virtual address e0db9080
printing eip:
e0db9080
*pde = 1ed12067
*pte = 00000000
Oops: 0000
CPU: 0
EIP: 0060:[<e0db9080>] Not tainted
EFLAGS: 00010297
EIP is at 0xe0db9080
eax: 00000000 ebx: c15d5800 ecx: c0291b68 edx: 00000282
esi: 00000000 edi: c15d584c ebp: c15d5800 esp: d93e5f08
ds: 0068 es: 0068 ss: 0068
Process modprobe (pid: 19122, threadinfo=d93e4000 task=df09aca0)
Stack: e0de816f c15d5800 c15d5800 e0dc81a1 c15d5800 e0dc84a8 c019f5c8
c15d5800
e0dcd2ac c15d584c e0dc84a8 ffffffed e0dc84a8 e0dc8480 c01ac0af
c15d584c
c15d584c c15d5854 c02bd934 c01ac183 c15d584c e0dc84a8 c02bd840
e0dc83b8
Call Trace:
[<e0de816f>] agp_register_driver+0x27/0x9c [agpgart]
[<e0dc81a1>] agp_via_probe+0x35/0x3c [via_agp]
[<e0dc84a8>] agp_via_pci_driver+0x28/0xa0 [via_agp]
[<c019f5c8>] pci_device_probe+0x40/0x5c
[<e0dcd2ac>] agp_via_pci_table+0x0/0x38 [via_agp]
[<e0dc84a8>] agp_via_pci_driver+0x28/0xa0 [via_agp]
[<e0dc84a8>] agp_via_pci_driver+0x28/0xa0 [via_agp]
[<e0dc8480>] agp_via_pci_driver+0x0/0xa0 [via_agp]
[<c01ac0af>] bus_match+0x37/0x6c
[<c01ac183>] driver_attach+0x37/0x60
[<e0dc84a8>] agp_via_pci_driver+0x28/0xa0 [via_agp]
[<e0dc83b8>] __module_pci_device_size+0x10/0x18 [via_agp]
[<e0dc84a8>] agp_via_pci_driver+0x28/0xa0 [via_agp]
[<c01ac44c>] bus_add_driver+0xa4/0xc4
[<e0dc84a8>] agp_via_pci_driver+0x28/0xa0 [via_agp]
[<e0dc84c8>] agp_via_pci_driver+0x48/0xa0 [via_agp]
[<c01ac83c>] driver_register+0x34/0x38
[<e0dc84a8>] agp_via_pci_driver+0x28/0xa0 [via_agp]
[<c019f6c2>] pci_register_driver+0x42/0x50
[<e0dc84a8>] agp_via_pci_driver+0x28/0xa0 [via_agp]
[<e0dcd1af>] agp_via_init+0xb/0x44 [via_agp]
[<e0dc8480>] agp_via_pci_driver+0x0/0xa0 [via_agp]
[<c0125752>] sys_init_module+0x116/0x1a4
[<c0108937>] syscall_call+0x7/0xb
Code: Bad EIP value.
The module load occured after X was started.
Ed Tomlinson
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Dave Jones @ 2002-12-17 12:40 UTC (permalink / raw)
To: Andre Hedrick; +Cc: Linus Torvalds, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.10.10212170144030.31876-100000@master.linux-ide.org>
On Tue, Dec 17, 2002 at 01:45:52AM -0800, Andre Hedrick wrote:
> 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.
INT 0x80 != IO port 0x80
8-)
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: My cpu fuzzy problem was due to XMMS
From: Dave Jones @ 2002-12-17 12:38 UTC (permalink / raw)
To: Xavier LaRue; +Cc: linux-kernel
In-Reply-To: <20021217011600.08f8cd81.paxl@videotron.ca>
On Tue, Dec 17, 2002 at 01:16:00AM -0500, Xavier LaRue wrote:
> :).. I just found it out :)
>
> But now my real problem.. That probably slow down considerably my box,
> How to make my L2 cache reconized
> my dmesg is hosted here http://paxl.no-ip.org/~paxl/dmesg.txt
As I've pointed out twice to you now, 2.4.18 had a bug in the
CPU cache sizing routine that is fixed in 2.4.21pre1
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: [drm:drm_init] *ERROR* Cannot initialize the agpgart module.
From: Dave Jones @ 2002-12-17 12:33 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel, rusty
In-Reply-To: <200212162049.16039.tomlins@cam.org>
On Mon, Dec 16, 2002 at 08:49:16PM -0500, Ed Tomlinson wrote:
> I am getting the above message in 2.5.51, 52, and 52+bk current.
> Pci info follows:
>
> What else would help to debug this? The drm error above is all I find in the logs...
There are a bunch of pending fixes at bk://linux-dj.bkbits.net/agpgart,
but nothing that should be relevant to this problem.
Are you using agpgart as modules? Which ones loaded ?
I've a feeling agpgart.ko loaded here, but not via-agp.ko
What needs to happen is when agpgart.ko is loaded, all the
chipset drivers also get pulled in as dependancies.
Since the new module stuff went in, I'm not sure how this
works, if it works at all.[1]
Dave
[1] I'm yet another developer who has had a rough time with the
new modules stuff. I'll try it again soon.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* [BENCHMARK] 2.5.52 with contest
From: Con Kolivas @ 2002-12-17 12:23 UTC (permalink / raw)
To: linux kernel mailing list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks to the OSDL people I'm back online with their hardware.
Here are the latest contest results for 2.5.52:
UniProcessor:
noload:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 70.0 96 0 0 1.05
2.5.50 [5] 69.9 96 0 0 1.05
2.5.51 [2] 69.8 96 0 0 1.05
2.5.52 [3] 70.2 96 0 0 1.05
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 67.4 99 0 0 1.01
2.5.50 [5] 67.3 99 0 0 1.01
2.5.51 [2] 67.2 99 0 0 1.01
2.5.52 [3] 67.5 99 0 0 1.01
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 85.2 79 17 20 1.28
2.5.50 [5] 84.8 79 17 19 1.27
2.5.51 [2] 85.2 79 17 20 1.28
2.5.52 [3] 84.4 79 17 19 1.26
dbench_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 210.5 37 2 50 3.15
2.5.50 [5] 189.2 40 2 49 2.83
2.5.51 [12] 195.8 39 2 50 2.93
2.5.52 [3] 222.3 36 2 53 3.33
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 106.1 82 2 9 1.59
2.5.50 [5] 107.5 81 3 9 1.61
2.5.51 [7] 107.0 81 3 9 1.60
2.5.52 [3] 109.8 81 2 8 1.64
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 184.8 70 3 8 2.77
2.5.50 [5] 189.5 61 4 9 2.84
2.5.51 [7] 163.7 67 3 8 2.45
2.5.52 [3] 161.4 69 3 8 2.42
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 127.4 57 14 13 1.91
2.5.50 [5] 142.6 54 19 14 2.14
2.5.51 [7] 125.6 58 14 12 1.88
2.5.52 [7] 120.9 60 13 12 1.81
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 97.4 75 7 11 1.46
2.5.50 [5] 106.9 69 10 11 1.60
2.5.51 [7] 105.1 69 9 11 1.57
2.5.52 [7] 94.9 76 7 10 1.42
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 88.2 80 15 6 1.32
2.5.50 [5] 88.5 80 15 7 1.33
2.5.51 [2] 88.4 80 15 7 1.32
2.5.52 [3] 88.1 80 15 7 1.32
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 81.4 85 0 8 1.22
2.5.50 [5] 81.2 85 0 8 1.22
2.5.51 [2] 80.8 85 0 8 1.21
2.5.52 [3] 81.0 86 0 9 1.21
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 98.1 76 43 2 1.47
2.5.50 [5] 98.3 76 44 2 1.47
2.5.51 [7] 99.3 76 45 2 1.49
2.5.52 [3] 100.0 78 45 2 1.50
Slight decrease in time for the io writing loads - io_load, io_other and
xtar_load.
SMP:
noload:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [6] 39.3 181 0 0 1.09
2.5.50 [5] 39.3 180 0 0 1.09
2.5.51 [3] 39.6 180 0 0 1.09
2.5.52 [7] 39.3 181 0 0 1.09
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [6] 36.6 194 0 0 1.01
2.5.50 [5] 36.5 194 0 0 1.01
2.5.51 [3] 36.5 195 0 0 1.01
2.5.52 [7] 36.5 194 0 0 1.01
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [6] 50.0 141 11 52 1.38
2.5.50 [5] 47.8 148 10 46 1.32
2.5.51 [3] 50.5 139 12 54 1.39
2.5.52 [7] 48.7 144 10 49 1.34
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 53.8 161 1 10 1.49
2.5.50 [5] 54.6 157 1 10 1.51
2.5.51 [7] 58.2 158 1 10 1.61
2.5.52 [7] 56.1 161 1 10 1.55
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 72.9 132 1 10 2.01
2.5.50 [5] 116.2 103 2 10 3.21
2.5.51 [7] 104.8 124 2 10 2.89
2.5.52 [7] 83.1 138 1 9 2.29
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 75.5 110 9 18 2.09
2.5.50 [5] 87.6 102 14 22 2.42
2.5.51 [7] 84.6 102 13 21 2.34
2.5.52 [7] 73.1 111 10 19 2.02
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 64.2 130 8 19 1.77
2.5.50 [5] 59.3 139 7 18 1.64
2.5.51 [7] 64.5 134 7 18 1.78
2.5.52 [7] 75.1 120 10 21 2.07
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 49.1 152 5 7 1.36
2.5.50 [5] 49.3 151 5 7 1.36
2.5.51 [3] 48.5 154 5 7 1.34
2.5.52 [7] 49.4 151 5 7 1.36
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 43.4 167 0 8 1.20
2.5.50 [5] 43.4 167 0 8 1.20
2.5.51 [3] 43.5 167 0 8 1.20
2.5.52 [7] 43.2 167 0 9 1.19
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.49 [5] 62.5 145 35 3 1.73
2.5.50 [5] 63.3 141 36 3 1.75
2.5.51 [7] 62.6 148 38 3 1.73
2.5.52 [7] 63.5 148 38 3 1.75
Changes all over the place seem to occur only in SMP with much smaller changes
in the UP results. If you look at the detailed results you can see very large
variations in run times for the io based loads (io loads, tar loads). It was
so different that the dbench_load changes so much it's not worth doing them
or reporting them. I'm not sure why the io based loads vary so much more in
SMP mode.
Archived and detailed results can be found here:
http://www.osdl.org/projects/ctdevel/results/
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE9/xdWF6dfvkL3i1gRArJ2AKCaOE2BOo95XcGosilOpebq+sm+3wCeMMOV
FVKuU406l5tdAfSI9EmXYR8=
=+pg5
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Multithreaded coredump patch where?
From: Arjan van de Ven @ 2002-12-17 12:14 UTC (permalink / raw)
To: mgross; +Cc: Roberto Fichera, linux-kernel
In-Reply-To: <200212170015.gBH0FXP13878@unix-os.sc.intel.com>
[-- Attachment #1: Type: text/plain, Size: 262 bytes --]
On Mon, 2002-12-16 at 22:21, mgross wrote:
> I don't know if there is any plan to back port Ingo's version of this feature
> to 2.4.x
the current Red Hat Rawhide kernels have an attempt for a backport but
it's not fully working right yet unfortionatly
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Data-loss bug stings Linux
From: Arjan van de Ven @ 2002-12-17 12:08 UTC (permalink / raw)
To: arun4linux; +Cc: linux-kernel
In-Reply-To: <200212170729.MAA27138@WS0005.indiatimes.com>
[-- Attachment #1: Type: text/plain, Size: 204 bytes --]
On Tue, 2002-12-17 at 08:38, arun4linux wrote:
> Hello,
>
> I got an e-mail like this.
> Just want to get clarified as I'm using RedHat 8.0 (kernel 2.4.18-14)
2.4.18-14 does not have this bug.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Multithreaded coredump patch where?
From: Arjan van de Ven @ 2002-12-17 12:08 UTC (permalink / raw)
To: Roberto Fichera; +Cc: linux-kernel
In-Reply-To: <5.2.0.9.0.20021217105617.00aa31e0@mail.isolaweb.it>
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
On Tue, 2002-12-17 at 12:05, Roberto Fichera wrote:
> At 13.21 16/12/02 -0800, mgross wrote:
>
> >I haven't rebased the patches I posted back in June for a while now.
> >
> >Attached is the patch I posted for the 2.4.18 vanilla kernel. Its a bit
> >controversial, but it seems to work for a number of folks. Let me know if
> >you have any troubles re-basing it.
>
> Only one hunk failed on include/asm-ia64/elf.h but fixed by hand.
> Why do you say a bit controversial ?
The design has theoretical (but probably in practice not trivial to
trigger) deadlocks; by design it prevents processes that are sleeping
from running, regardless whether those processes are in kernel space or
not. If they are in kernel space, they can accidentally be holding a
semaphore that something in the core dumping path will need to get (
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Multithreaded coredump patch where?
From: Arjan van de Ven @ 2002-12-17 12:05 UTC (permalink / raw)
To: Roberto Fichera; +Cc: linux-kernel
In-Reply-To: <5.2.0.9.0.20021217105617.00aa31e0@mail.isolaweb.it>
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
On Tue, 2002-12-17 at 12:05, Roberto Fichera wrote:
> At 13.21 16/12/02 -0800, mgross wrote:
>
> >I haven't rebased the patches I posted back in June for a while now.
> >
> >Attached is the patch I posted for the 2.4.18 vanilla kernel. Its a bit
> >controversial, but it seems to work for a number of folks. Let me know if
> >you have any troubles re-basing it.
>
> Only one hunk failed on include/asm-ia64/elf.h but fixed by hand.
> Why do you say a bit controversial ?
The design has theoretical (but probably in practice not trivial to
trigger) deadlocks; by design it prevents processes that are sleeping
from running, regardless whether those processes are in kernel space or
not. If they are in kernel space, they can accidentally be holding a
semaphore that something in the core dumping path will need to get (but
can't because it never will be released). There are not that many of
such semaphores (kmap semaphore is one, and filesystems can have several
internally)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: buggy scsi_register behaviour in 2.5.51
From: Willem Riede @ 2002-12-17 11:47 UTC (permalink / raw)
To: dgilbert; +Cc: linux-scsi
In-Reply-To: <3DFE998E.1080103@interlog.com>
On 2002.12.16 22:27 Douglas Gilbert wrote:
> Willem,
> Can't fix all those problems but I did notice that
> idescsi_release() was missing a call to scsi_unregister().
> With this patch the ide-scsi entry remains dangling in
> sysfs (ide problem??) but the scsi host gets cleaned up
> after rmmod.
>
> The attachment is against lk 2.5.52 . The ide-scsi
> driver in lk 2.5.52 needs cleaning up in several
> areas. If no-one else wants to attack it then I
> will.
>
Thanks Doug.
I'll also see if I can find what the remaining problems are. I'd also be
prepared do do "cleaning up" of ide-scsi -- what in your opinion needs
taking care of?
Regards, Willem Riede.
^ 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.