* Re: [PATCH]: for poor sools with old I2 & 64 bits kernel
From: Ralf Baechle @ 2002-12-20 2:44 UTC (permalink / raw)
To: Juan Quintela; +Cc: mipslist
In-Reply-To: <m2el8dixmr.fsf@demo.mitica>
On Thu, Dec 19, 2002 at 09:04:12PM +0100, Juan Quintela wrote:
> this small patch made possible to compile a 64bit kernel for
> people that have old proms that only accept ecoff. As usual
> stolen from the 32 bits version.
>
> The easiest way is creating the file in arch/mips/boot,
> otherwise we need to copy elf2ecoff.c to mips64.
Applied slightly modified. I removed two other unused targets.
Ralf
^ permalink raw reply
* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Andrew Morton @ 2002-12-20 2:48 UTC (permalink / raw)
To: Robert Love; +Cc: Con Kolivas, linux kernel mailing list
In-Reply-To: <1040352135.2645.97.camel@phantasy>
Robert Love wrote:
>
> On Thu, 2002-12-19 at 19:27, Andrew Morton wrote:
>
> > Prefixing all the names with "tune_" would suit, too.
>
> I have no problem with this. Keeping the names in all caps rings
> "preprocessor define" to me, which in fact they are - but only insomuch
> as they point to a real variable. So I dislike that.
Think of them as "runtime controllable constants" :)
> Personally I like them as normal variable names... don't you do the same
> in the VM code as well? But tune_foo is fine..
Convention there is to use sysctl_foo, which is fine. We haven't
been consistent in that, and it's a thing I regret. But not
enough to bother changing it.
^ permalink raw reply
* Re: [PATCH]: fix type of MAXMEM
From: Ralf Baechle @ 2002-12-20 2:37 UTC (permalink / raw)
To: Juan Quintela; +Cc: mipslist
In-Reply-To: <m28yylixhm.fsf@demo.mitica>
On Thu, Dec 19, 2002 at 09:07:17PM +0100, Juan Quintela wrote:
> I expect that the amount from where it is highmem to never be
> bigger that 4Giga Megabytes :) I.e. int should be enough.
No. The root cause of this problem is the type of the constant
HIGHMEM_START which should have been unsigned int but actually was
just int.
Ralf
^ permalink raw reply
* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Robert Love @ 2002-12-20 2:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: Con Kolivas, linux kernel mailing list
In-Reply-To: <3E0263EA.2BB9C89@digeo.com>
On Thu, 2002-12-19 at 19:27, Andrew Morton wrote:
> Prefixing all the names with "tune_" would suit, too.
I have no problem with this. Keeping the names in all caps rings
"preprocessor define" to me, which in fact they are - but only insomuch
as they point to a real variable. So I dislike that.
Personally I like them as normal variable names... don't you do the same
in the VM code as well? But tune_foo is fine..
Robert Love
^ permalink raw reply
* Re: [LARTC] Filter in HTB not working
From: Miguel Figueiredo @ 2002-12-20 2:31 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104029961502754@msgid-missing>
Em Qui, 2002-12-19 às 10:06, Nestor S A Melo escreveu:
Nestor,
First: If my english is poor, you can contact me direct by email in
portuguese since I`m Brazilian too :)
So, somebody correct me if I`m wrong ( Stef? ):
1 - I think you share more bandwidth than you have allocated.
2 - In sfq directive, you should write:
#tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
3 - You've marked packets with iptables -t mangle, but you're using u32
instead fw.I'm not sure if you did the correct u32 configuration too.
Probably you must use:
#tc filter add dev eth0 parent 1: protocol ip prio 100 handle 6 fw classid 1:10
The handle is the parameter that says to tc what mark you're using and
fw is the parameter that says to tc that you're using a firewall mark.
I hope I have helped you
Miguel Figueiredo
Linux Suport Analist
> I have a problem in setting up HTB.
>
> It appears filters doesn't work at all, besides "tc filter show" show it as
> being correctly configured.
>
> Class 1:10 never sent any traffic, but as iptables show below, it should be
> sending packets.
>
> The HTB version I'm using is 3.3, with kernel 2.4.17.
>
> The setup is as follows:
> ---------------------------------------------------------------
> tc qdisc del dev eth0 root
> tc qdisc add dev eth0 root handle 1 htb default 20 r2q 10
>
> tc class add dev eth0 parent 1: classid 1:2 htb rate 256kbit
>
> tc class add dev eth0 parent 1:2 classid 1:10 htb rate 26kbit ceil 128kbit
> prio
> 1
> tc qdisc add dev eth0 parent 1:10 handle 10 sfq perturb 10
> tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 23
> 0xffff classid 1:10
>
> tc class add dev eth0 parent 1:2 classid 1:20 htb rate 220kbit ceil 256kbit
> prio 2
> tc qdisc add dev eth0 parent 1:20 handle 20 sfq perturb 10
> ---------------------------------------------------------------
>
> The stats:
> ---------------------------------------------------------------
> [root@NL1000 htb]# tc -s -d qdisc show
> qdisc sfq 20: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 10sec
> Sent 5116 bytes 94 pkts (dropped 0, overlimits 0)
>
> qdisc sfq 10: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 10sec
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
>
> qdisc htb 1: dev eth0 r2q 10 default 20 direct_packets_stat 0 ver 3.6
> Sent 5116 bytes 94 pkts (dropped 0, overlimits 0)
>
> [root@NL1000 htb]# tc -s -d class show dev eth0
> class htb 1:10 parent 1:2 leaf 10: prio 1 quantum 1000 rate 26Kbit ceil
> 128Kbit
> burst 1632b/8 mpu 0b cburst 1762b/8 mpu 0b level 0
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
> lended: 0 borrowed: 0 giants: 0
> tokens: 401969 ctokens: 88149
>
> class htb 1:2 root rate 256Kbit ceil 256Kbit burst 1926b/8 mpu 0b cburst
> 1926b/8 mpu 0b level 7
> Sent 5116 bytes 94 pkts (dropped 0, overlimits 0)
> lended: 0 borrowed: 0 giants: 0
> tokens: 46975 ctokens: 46975
>
> class htb 1:20 parent 1:2 leaf 20: prio 2 quantum 2816 rate 220Kbit ceil
> 256Kbit burst 1880b/8 mpu 0b cburst 1926b/8 mpu 0b level 0
> Sent 5116 bytes 94 pkts (dropped 0, overlimits 0)
> lended: 94 borrowed: 0 giants: 0
> tokens: 53324 ctokens: 46975
>
> [root@NL1000 htb]# tc -s -d filter show dev eth0
> filter parent 1: protocol ip pref 100 u32
> filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800
> bkt
> 0 flowid 1:10
> match 00170000/ffff0000 at 20
>
> [root@NL1000 htb]# iptables -t mangle -L -nvx
> Chain PREROUTING (policy ACCEPT 3590 packets, 557751 bytes)
> pkts bytes target prot opt in out source
> destination
> 0 0 MARK tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:23 MARK set 0x6
> 146 12954 MARK tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp spt:23 MARK set 0x6
>
> Chain OUTPUT (policy ACCEPT 315 packets, 16936 bytes)
> pkts bytes target prot opt in out source
> destination
> ---------------------------------------------------------------
>
> So, what is going wrong?
>
> Thanks in advance,
> --
> _____________________
> Nestor S A Melo
> _______________________________________________
> 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
* Valgrind meets UML
From: Jeff Dike @ 2002-12-20 2:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Jeremy Fitzhardinge, Julian Seward
After some hacking on valgrind (and help from Jeremy Fitzhardinge and Julian
Seward), I got it to run the kernel, in the form of UML.
I don't have a long list of bugs to report because I'm still trying to drive
the noise level down by teaching valgrind about how the kernel does business.
As a result, I have some questions that I'd appreciate advice on.
You teach it things by putting declarations in the code about what level of
access is permitted for a region of memory. So,
VALGRIND_MAKE_WRITABLE(ptr, len);
VALGRIND_MAKE_READABLE(ptr, len);
tells valgrind that the region [ ptr, ptr + len ) is open for business, and
VALGRIND_MAKE_NOACCESS(ptr, len);
tells it that it's not.
First question - is sticking something (not necessarily the VALGRIND_* things)
in the code acceptable? I personally don't see a problem with it, although
I would do something like BUFFER_RW(ptr, len), which would expand into the
first pair of declarations if CONFIG_VALGRIND was enabled, and nothing if it's
not.
Which leads to the next question - where to put CONFIG_VALGRIND? UML is the
only form of the kernel which valgrind will deal with any time soon, so it's
reasonable for it to be in the UML config only. However, the memory access
declarations are going to be sprinkled around generic code, so that suggests
putting it in the generic config someplace, just conditional on UML (which
suggests putting it back in the UML-only config :-).
I think there would also need to be a CONFIG_VALGRIND_INCLUDE which points
to wherever the valgrind headers are installed.
I would also appreciate suggestions on what sort of memory access state table
to implement, and where best to put the declarations. What I'm not clear
on is what sort of access a buffer should have when it's in the care of
the allocator (i.e. it's free). If the allocator sticks information
temporarily in the buffer, then that needs to be stated.
There are also some non-obvious places where this could be used.
- VALGRIND_MAKE_READABLE could be used to enforce read-only data when an rwlock
is taken for reading
- it could also be used whenever there's an interface that hands out read-only
objects, and writing them is done under that interface.
So, it's not only the memory allocators that can make use of this. We'll get
the best use of this if other subsystem maintainers figure out what rules
they have and whether valgrind can be used to enforce them.
Jeff
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Daniel Jacobowitz @ 2002-12-20 2:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jamie Lokier, H. Peter Anvin, Terje Eggestad, Ulrich Drepper,
Matti Aarnio, Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212191746200.4545-100000@home.transmeta.com>
On Thu, Dec 19, 2002 at 05:47:55PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 19 Dec 2002, Daniel Jacobowitz wrote:
> > >
> > > (ptrace also doesn't actually allow you to look at the instruction
> > > contents in high memory, so gdb won't see the instructions in the
> > > user-mode fast system call trampoline even when it can single-step
> > > them, and I don't think I'll bother to fix it up).
> >
> > This worries me. I'm no x86 guru, but I assume the trampoline's setting of
> > the TF bit will kick in right around the following 'ret'. So the
> > application will stop and GDB won't be able to read the instruction at
> > PC. I bet that makes it unhappy.
>
> It doesn't make gdb all that unhappy, everything seems to work fine
> despite the fact that gdb decides it just can't display the instructions.
Yeah; sometimes it will generate that error in the middle of
single-stepping over something larger, though, and it breaks you out of
whatever you were doing.
> > Shouldn't be that hard to fix this up in ptrace, though.
>
> Or even in user space, since the high pages are all the same in all
> processes (so gdb doesn't even strictly need ptrace, it can just read it's
> _own_ codespace there). But yeah, we could make ptrace aware of the magic
> pages.
I need to get back to my scheduled ptrace cleanups. Meanwhile, here's
a patch to do this. Completely untested, like all good patches; but
it's pretty simple.
===== arch/i386/kernel/ptrace.c 1.17 vs edited =====
--- 1.17/arch/i386/kernel/ptrace.c Wed Nov 27 18:14:11 2002
+++ edited/arch/i386/kernel/ptrace.c Thu Dec 19 21:33:37 2002
@@ -21,6 +21,7 @@
#include <asm/processor.h>
#include <asm/i387.h>
#include <asm/debugreg.h>
+#include <asm/fixmap.h>
/*
* does not yet catch signals sent when the child dies.
@@ -196,6 +197,18 @@
case PTRACE_PEEKDATA: {
unsigned long tmp;
int copied;
+
+ /* Allow ptrace to read from the vsyscall page. */
+ if (addr >= FIXADDR_START && addr < FIXADDR_TOP &&
+ (addr & 3) == 0) {
+ int idx = virt_to_fix (addr);
+ if (idx == FIX_VSYSCALL) {
+ tmp = * (unsigned long *) addr;
+ ret = put_user (tmp, (unsigned long *) data);
+ break;
+ }
+ }
+
copied = access_process_vm(child, addr, &tmp, sizeof(tmp), 0);
ret = -EIO;
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply
* [Q]what is the net_ratelimit() ?
From: caster @ 2002-12-20 2:26 UTC (permalink / raw)
To: netfilter-devel
Must every printk messages in network BH use net_ratelimit?
is it effective when every traffic in netfilter rule needs printk message?
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Martin J. Bligh @ 2002-12-20 2:22 UTC (permalink / raw)
To: Hanna Linder; +Cc: Randy.Dunlap, linux-kernel
In-Reply-To: <73850000.1040350256@w-hlinder>
>> There are a bunch of categories that aren't really "owned" as such,
>> and default to khoa or myself. Those are really good candidates to
>> steal ... they'll be owned by bugme-janitors soon to make this more
>> obvious ...
>
> OK. Which categories are not owned? Anything with you or khoa as owners?
More or less, yes. There are a couple of categories I really own, eg
NUMA/discontigmem, and I'll probably look after ia32 specific bugs
unless Linus wants his category back ;-)
Will switch to bugme-janitors in a few days, then will all be much more
obvious
M.
^ permalink raw reply
* RE: [PATCH 2.5.52] Use __set_current_state() instead of current-> state = (take 1)
From: Alan Cox @ 2002-12-20 3:08 UTC (permalink / raw)
To: Perez-Gonzalez, Inaky; +Cc: 'Robert Love', Linux Kernel Mailing List
In-Reply-To: <A46BBDB345A7D5118EC90002A5072C7806CACA31@orsmsx116.jf.intel.com>
On Thu, 2002-12-19 at 19:04, Perez-Gonzalez, Inaky wrote:
>
> > > And that would now really work when CONFIG_X86_OOSTORE=1 is required
> > > [after all, it is a write, so it'd need the equivalent of a wmb() or
> > > xchg()].
> >
> > Is this a hint that your employer may have an x86 chip in the future
> > with weak ordering? :)
>
> Hmmm ... taking into account that there are some many thousands of
> employees in my company and that I know less than one hundred ...
> and that they are all software ... well, I don't think I am into
> the rumour mill :]
Also OOSTORE is there because other vendors already make weak store
order capable x86 processors. One example of this is the Winchip - where
turning off strict store ordering is worth 30% performance.
In addition you have to treat store ordering/locking carefully due to
the pentium pro store fencing errata. (Thats why our < PII kernel
generates lock movb to unlock when in theory the lock isnt needed).
Alan
^ permalink raw reply
* Re: PATCH 2.5.x disable BAR when sizing
From: David Mosberger @ 2002-12-20 2:27 UTC (permalink / raw)
To: Alan Cox; +Cc: Grant Grundler, mj, Linux Kernel Mailing List, turukawa
In-Reply-To: <1040352868.30778.12.camel@irongate.swansea.linux.org.uk>
>>>>> On 20 Dec 2002 02:54:28 +0000, Alan Cox <alan@lxorguk.ukuu.org.uk> said:
Alan> On Thu, 2002-12-19 at 21:37, Grant Grundler wrote:
>> Martin, In April 2002, turukawa@icc.melco.co.jp sent a 2.4.x
>> patch to disable BARs while the BARs were being sized. I've
>> "forward ported" this patch to 2.5.x (appended). turukawa's
>> excellent problem description and original posting are here:
>> https://lists.linuxia64.org/archives//linux-ia64/2002-April/003302.html
>>
>> David Mosberger agrees this is an "obvious fix". We've been
>> using this in the ia64 2.4 code stream since about August.
Alan> We've rejected this twice already from different people.
Alan> Nothing says your memory can't be behind the bridge and you
Alan> just turned memory access off. Whoops bang, game over.
Alan> And yes this happens on some PC class systems.
And yet it's OK to remap that memory? That seems unlikely.
--david
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Martin J. Bligh @ 2002-12-20 2:20 UTC (permalink / raw)
To: Hanna Linder, Jon Tollefson; +Cc: Eli Carter, Randy.Dunlap, linux-kernel
In-Reply-To: <71820000.1040349694@w-hlinder>
>> Anything in "OPEN" state isn't really assigned to anyone yet.
>> (the state would really better be named "NEW", but it's not).
>> People should move it to "ASSIGNED" if they're working on it.
>
> So the process is to query for all open bugs (but not
> assigned) then email each person to let them know you are
> working on it?
Sounds about right. If we had processes ;-)
>> Go to file a new bug, click on the link by the subcategories, and it'll
>> tell you (you'll have to pick the main category first).
>
> That is convoluted. You have to file a bug to find out who
> the subsystem maintainers are? Can you put it somewhere more
> obvious?
Well, you don't have to file one, you just pretend to. But it's
not nice, I agree. Jon, is there an easier way to do this, and get
all the information in one shot?
M.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Alan Cox @ 2002-12-20 3:05 UTC (permalink / raw)
To: Pavel Machek
Cc: Linus Torvalds, H. Peter Anvin, Ulrich Drepper, Nakajima, Jun,
Matti Aarnio, Hugh Dickins, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List
In-Reply-To: <20021218234512.GA705@elf.ucw.cz>
On Wed, 2002-12-18 at 23:45, Pavel Machek wrote:
> IIRC, segment 0x40 was special in BIOS days, and some APM bioses
> blindly access 0x40 even from protected mode (windows have segment
> 0x40 with base 0x400....) Is that issue you are hitting?
Well the spec says it is not special. Windows leaves it pointing to
0x400 and if you don't do that your APM doesn't work.
Alan
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Dan Kegel @ 2002-12-20 2:26 UTC (permalink / raw)
To: linux-kernel
Hanna Linder wrote:
> --On Thursday, December 19, 2002 06:59:30 PM -0500 Pete Zaitcev <zaitcev@redhat.com> wrote:
>
>>> Why are bugs automatically assigned to owners?
>>> If there was an unassigned category that would make it
>>> easy to query.
>>
>> Query for "NEW" status for a component and do not put anything
>> into "owner" fireld.
>
> If there was a NEW field that would be exactly what I was
> asking for. When I do a query the only options I see are: OPEN,
> ASSIGNED, RESOLVED, APPROVED, REJECTED, DEFERRED, CLOSED.
> Where is the NEW? Is there somewhere else to do queries?
When I first looked at the query form, I was overwhelmed by the
list of states. Clicking on the link above the list takes you to
http://bugzilla.kernel.org/queryhelp.cgi#status
which helps a bit. (I'm kind of used to a shorter list of states, e.g.
"new / assigned / verifyfix / closed", but bugzilla's list doesn't
look *too* complicated.)
--
Dan Kegel
Linux User #78045
http://www.kegel.com
^ permalink raw reply
* Re: PATCH 2.5.x disable BAR when sizing
From: Alan Cox @ 2002-12-20 2:54 UTC (permalink / raw)
To: Grant Grundler; +Cc: mj, Linux Kernel Mailing List, turukawa
In-Reply-To: <20021219213712.0518B12CB2@debian.cup.hp.com>
On Thu, 2002-12-19 at 21:37, Grant Grundler wrote:
>
> Martin,
> In April 2002, turukawa@icc.melco.co.jp sent a 2.4.x patch to disable
> BARs while the BARs were being sized. I've "forward ported" this patch
> to 2.5.x (appended). turukawa's excellent problem description and
> original posting are here:
> https://lists.linuxia64.org/archives//linux-ia64/2002-April/003302.html
>
> David Mosberger agrees this is an "obvious fix".
> We've been using this in the ia64 2.4 code stream since about August.
We've rejected this twice already from different people.
Nothing says your memory can't be behind the bridge and you just turned
memory access off. Whoops bang, game over.
And yes this happens on some PC class systems.
Alan
^ permalink raw reply
* RE: pb compiling cross gcc, binutils, glibc and so on ...
From: Liu Fred-a18596 @ 2002-12-20 1:57 UTC (permalink / raw)
To: BREUVART Jean-Charles, linuxppc-embedded
> 5. build gcc core 2.95.3 for powerpc cross compile, and install it in
> /opt/powerpc-linux/ :
> - cd /usr/src/gcc-2.95.3/
> - make clean
> - make distclean
> - CC=/usr/local/bin/gcc ./configure --target=powerpc-linux
> --enable-shared --enable-languages=c --with-newlib
> --prefix=/opt/powerpc-linux
> - add /opt/powerpc-linux at the end of $PATH, otherwise
> make doesn't
> find powerpc-linux-as, powerpc-linux-ld and so on
> - make
>
> Here is the trouble :
>
> choose-temp.c:29: stdio.h: Aucun fichier ou r?pertoire de ce type
> choose-temp.c:30: sys/types.h: Aucun fichier ou r?pertoire de ce type
> choose-temp.c:32: unistd.h: Aucun fichier ou r?pertoire de ce type
> choose-temp.c:35: stdlib.h: Aucun fichier ou r?pertoire de ce type
> choose-temp.c:38: sys/file.h: Aucun fichier ou r?pertoire de ce type
>
> there aren't any of those in /opt/powerpc-linux/ or its subdirs
>
It's true that there are no any of those files. They are in glibc which you have not compiled yet.
Some useful tips at: http://www.mock.com/receiver/tools/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH][2.4] generic cluster APIC support for systems with more than 8 CPUs
From: James Cleverdon @ 2002-12-20 2:04 UTC (permalink / raw)
To: Pallipadi, Venkatesh, Linux Kernel
Cc: Martin Bligh, John Stultz, Nakajima, Jun, Mallick, Asit K,
Saxena, Sunil
In-Reply-To: <C8C38546F90ABF408A5961FC01FDBF1912E18E@fmsmsx405.fm.intel.com>
On Wednesday 18 December 2002 02:36 pm, Pallipadi, Venkatesh wrote:
> 2.4.21-pre1 (i386) based patch to fix the issues with systems having more
> than 8 CPUs, in a generic way.
>
>
> Motivation:
> The current APIC destination mode ("Flat Logical") used in linux kernel has
> an upper limit of 8 CPUs. For more than 8 CPUs, either "Clustered Logical"
> or "Physical" mode has to be used.
> There is already some code in current kernel (2.4.21-pre1), to support such
> conditions. Specifically, IBM Summit, uses Physical mode, and IBM NUMAQ
> uses clustered mode. But, there are some issues too:
> - it is not generic enough to support any other more than 8 CPU system
> out of the box. Supporting different systems may need more hacks in the
> code. - clustered mode setup is tightly coupled with NUMA system. Whereas,
> in reality, we can as well have logical clusters in a non-NUMA system as
> well. - physical mode setup is somewhat tightly coupled with xAPIC. But,
> xAPIC doesn't necessarily imply physical mode. You can as well have
> clustered mode with xAPIC - APIC destination mode is selected based on
> particular OEM string.
>
> These reasons together led to panics on other OEM systems with > 8 CPUS.
> The patch tries to fix this issue in a generic way (in place of having
> multiple hacks for different OEMs). Note, the patch only intends to change
> the initialization of systems with more than 8 CPUs and it will not affect
> other systems (apart from possible bugs in my code itself).
Your goals are laudable and, in many ways, I share them. However, this is
2.4. Our goals for 2.4 have always been minimal changes and as little impact
as possible to the UP and flat SMP cases.
> Description:
> The basic idea is to use the number of processors detected on the system,
> to decide on which APIC destination mode is to be used. Once all the CPU
> info, is collected either from ACPI or MP table, we can check the total
> number of processors in the system.
> If the number of processors in less than equal to 8,
> then no change is required, and we can use the default, "Flat Logical"
> set up. If the number of processors is more than 8
> we can switch to clustered logical setup.
> The logical clusters set up as follows.
> Cluster 0 (CPU 0-3), Cluster 1 (CPU 4-7), Cluster 2 (CPU 8-11) and so
> on..
>
> The other things that are done in the patch include:
> - Separate out the NUMA specific stuff from APIC setup in cluster mode.
> Also, NUMA has its own way of setting up the clusters, and doesn't follow
> the logical cluster mapping defined above.
> - Separate out xAPIC stuff from APIC destination setup. And the
> availability of xAPIC support can actually be determined from the LAPIC
> version. - physical mode support _removed_, as we can use clustered logical
> setup to support can support upto a max of 60 CPUs. This is mainly because
> of the advantage of being able to setup IOAPICs in LowestPrio, when using
> clustered mode.
See my 2.5 patches for an example of using solely logical mode interrupts.
The patches submitted to 2.4 are those that have been in Alan's tree since
August and running in SuSE 8.0+ since 8.0's release.
> The whole stuff is protected by 'Clustered APIC (> 8 CPUs) support
> (CONFIG_X86_APIC_CLUSTER)' config option under Processor Type and Features.
> But going forward, we can actually make this as default, as this doesn't
> affect the systems with less than equal to 8 CPUs (Apart from minor
> increase in code size and couple of additional checks during boot up), but
> gives the default support to more than 8 CPU systems.
An x440 needs to use clustered APIC mode whenever more than two physical CPUs
are present. Consider scanning the list of physical APIC IDs to determine
whether clustered mode is necessary. (I had such code in my 2.5 patch, but
ripped it out when it falsely triggered on a couple oddball systems. You may
be able to write a more comprehensive analyzer.)
> Please let me know your comments/criticisms about this.
> I was able to test this successfully on an 8-way with HT(16 logical)
> CPU systems that I have access to. But, I haven't tested it on x440, or
> NUMAQ systems. Would love to hear about the effect of this patch on these
> systems.
>
> Thanks,
> -Venkatesh
A generic patch should also support Unisys' new box, the ES7000 or some such.
> > -----Original Message-----
> > From: Nakajima, Jun
> > Sent: Thursday, December 12, 2002 7:06 PM
> > To: jamesclv@us.ibm.com; Zwane Mwaikambo
> > Cc: Martin Bligh; John Stultz; Linux Kernel
> > Subject: RE: [PATCH][2.5][RFC] Using xAPIC apic address space
> > on !Summit
> >
> >
> > BTW, we are working on a xAPIC patch that supports more than
> > 8 CPUs in a
> > generic fashion (don't use hardcode OEM checking). We already
> > tested it on
> > two OEM systems with 16 CPUs.
> > - It uses clustered mode. We don't want to use physical mode
> > because it does
> > not support lowest priority delivery mode.
> > - We also check the version of the local APIC if it's xAPIC
> > or not. It's
> > possible that some other x86 architecture (other than P4P) uses xAPIC.
> >
> > Stay tuned.
> >
> > Jun
--
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Hanna Linder @ 2002-12-20 2:10 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Hanna Linder, Randy.Dunlap, linux-kernel
In-Reply-To: <50260000.1040348396@flay>
--On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh" <mbligh@aracnet.com> wrote:
> There are a bunch of categories that aren't really "owned" as such,
> and default to khoa or myself. Those are really good candidates to
> steal ... they'll be owned by bugme-janitors soon to make this more
> obvious ...
OK. Which categories are not owned? Anything with you or khoa as owners?
Do I have to pretend to file a bug to find out ;)
Hanna
^ permalink raw reply
* Re: 2.4.20: Broken AGP initialization for i845G chipset [patch]
From: Alan Cox @ 2002-12-20 2:43 UTC (permalink / raw)
To: Michael Milligan; +Cc: Linux Kernel Mailing List
In-Reply-To: <3E025858.4000404@acmeps.com>
On Thu, 2002-12-19 at 23:38, Michael Milligan wrote:
> Chipset detection for the new Intel i845G chipset was added into the AGPGART
> driver, but it appears to call the wrong initialization routine. Stock
> compile
Ok I sent one of those to Marcelo for 2.4.21pre2. I'm not sure if I got
both
^ permalink raw reply
* RE: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen val
From: Patil, Harish @ 2002-12-20 1:46 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805569@msgid-missing>
> From: David Mosberger [mailto:davidm@napali.hpl.hp.com]
> Sent: Thursday, December 19, 2002 3:19 PM
> To: Patil, Harish
> Cc: 'davidm@hpl.hp.com'; 'linux-ia64@linuxia64.org'
> Subject: Re: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen
> values
>
>
> >>>>> On Tue, 17 Dec 2002 08:33:38 -0800, "Patil, Harish"
> <harish.patil@intel.com> said:
>
> Harish> I have a RHAS kernel compiled with *gcc3.2*. Using a script
> Harish> based on readelf/objdmp I found out that there are 7
> Harish> instances in this kernel where 'rlen' may be wrong. The
> Harish> invariant the script is looking for is this: Sum(rlen for
> Harish> various regions) = Number of slots in the code range.
>
> Harish> The script found following violations of the invariant:
<stuff deleted>
>
> Harish> code_range= 0xe000000004b18000-0xe000000004b182b0
> Harish> lo = 4B18000 hi = 4B182B0
> Harish> sum_rlen = 130 no_slots = 129
> Harish> *******ERROR ***********
> Harish> sum_rlen: 130 != no_slots:129
>
> Do you know what code this is? The addresses are not terribly useful
> because they'll vary from one kernel to another.
Sorry, the procedure name somehow got lost.. I disassembled the image and
the relevant procedure is: <ia64_sigtramp>
> Is your script fully automatic? If so, perhaps we could add it to the
> kernel sources and run it as part of "make check". I'd love to have
> better unwind-info checking tools. Actually, it's even more important
> to use such tools to verify the correctness of the user-level unwind
> info.
Yes, the script is fully automatic and is included below (requires a
'readelf' that
understands "-u" option).
-Harish
<----------- BEGIN unwcheck.sh
#!/bin/sh
# Usage: unwcheck.sh <executable_file_name>
# Pre-requisite: readelf [from Gnu binutils package]
# Purpose: Check the following invariant
# For each code range in the input binary:
# Sum[ lengths of unwind regions] = Number of slots in code range.
# Author : Harish Patil
# First version: January 2002
# Modified : 2/13/2002
# Modified : 3/15/2002: duplicate detection
readelf -u $1 | gawk '\
function todec(hexstr){
dec = 0;
l = length(hexstr);
for (i = 1; i <= l; i++)
{
c = substr(hexstr, i, 1);
if (c = "A")
dec = dec*16 + 10;
else if (c = "B")
dec = dec*16 + 11;
else if (c = "C")
dec = dec*16 + 12;
else if (c = "D")
dec = dec*16 + 13;
else if (c = "E")
dec = dec*16 + 14;
else if (c = "F")
dec = dec*16 + 15;
else
dec = dec*16 + c;
}
return dec;
}
BEGIN { first = 1; sum_rlen = 0; no_slots = 0; errors=0; no_code_ranges=0;
}
{
if (NF=5 && $3="info")
{
no_code_ranges += 1;
if (first = 0)
{
if (sum_rlen != no_slots)
{
print full_code_range;
print " ", "lo = ", lo, " hi =", hi;
print " ", "sum_rlen = ", sum_rlen, "no_slots = "
no_slots;
print " "," ", "*******ERROR ***********";
print " "," ", "sum_rlen:", sum_rlen, " != no_slots:"
no_slots;
errors += 1;
}
sum_rlen = 0;
}
full_code_range = $0;
code_range = $2;
gsub("),", "", code_range);
gsub("^.", "", code_range);
split(code_range, addr, "-");
lo = toupper(addr[1]);
code_range_lo[no_code_ranges] = addr[1];
occurs[addr[1]] += 1;
full_range[addr[1]] = $0;
gsub("0X.[0]*", "", lo);
hi = toupper(addr[2]);
gsub("0X.[0]*", "", hi);
no_slots = (todec(hi) - todec(lo))/ 16*3
first = 0;
}
if (index($0,"rlen") > 0 )
{
rlen_str = substr($0, index($0,"rlen"));
rlen = rlen_str;
gsub("rlen=", "", rlen);
gsub(")", "", rlen);
sum_rlen = sum_rlen + rlen;
}
}
END {
if (first = 0)
{
if (sum_rlen != no_slots)
{
print "code_range=", code_range;
print " ", "lo = ", lo, " hi =", hi;
print " ", "sum_rlen = ", sum_rlen, "no_slots = "
no_slots;
print " "," ", "*******ERROR ***********";
print " "," ", "sum_rlen:", sum_rlen, " != no_slots:"
no_slots;
errors += 1;
}
}
no_duplicates = 0;
for (i=1; i<=no_code_ranges; i++)
{
cr = code_range_lo[i];
if (reported_cr[cr]=1) continue;
if ( occurs[cr] > 1)
{
reported_cr[cr] = 1;
print "Code range low ", code_range_lo[i], ":", full_range[cr],
" occurs: ", occurs[cr], " times.";
print " ";
no_duplicates++;
}
}
print "==================="
print "Total errors:", errors, "/", no_code_ranges, " duplicates:",
no_duplicates;
print "==================="
}
'
---> END unwcheck.sh [note the "'" (single quote) on the last line ]
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Hanna Linder @ 2002-12-20 2:01 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Hanna Linder, Eli Carter, Randy.Dunlap, linux-kernel
In-Reply-To: <50260000.1040348396@flay>
--On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh" <mbligh@aracnet.com> wrote:
>
> Anything in "OPEN" state isn't really assigned to anyone yet.
> (the state would really better be named "NEW", but it's not).
> People should move it to "ASSIGNED" if they're working on it.
So the process is to query for all open bugs (but not
assigned) then email each person to let them know you are
working on it?
>
> Go to file a new bug, click on the link by the subcategories, and it'll
> tell you (you'll have to pick the main category first).
That is convoluted. You have to file a bug to find out who
the subsystem maintainers are? Can you put it somewhere more
obvious?
Thanks.
Hanna
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Martin J. Bligh @ 2002-12-20 1:39 UTC (permalink / raw)
To: Hanna Linder; +Cc: Eli Carter, Randy.Dunlap, linux-kernel
In-Reply-To: <42790000.1040337942@w-hlinder>
>> Bug tracking can get much better (I _hope_!), but I expect it to take some beating on the problem. Keep beating on it.
>
> OK. Since we are on the topic. I have some (intending to be) constructive
> criticisms for the owners of the 2.5 kernel tracker site (not sure exactly
> who they are but I know mbligh is part of it).
>
> Why are bugs automatically assigned to owners?
> If there was an unassigned category that would make it
> easy to query.
The "default owner" is someone to dispostion the bug ... not necessarily
to fix it.
> How else are those of us who want to help stabilize the 2.5 kernel supposed
> to know which bugs are being worked on and which are not?
> (Please dont tell me "email". Am I really supposed to email every
> person who has a bug asking if they are really working on it or not?)
Anything in "OPEN" state isn't really assigned to anyone yet.
(the state would really better be named "NEW", but it's not).
People should move it to "ASSIGNED" if they're working on it.
> Could you make a list of all the people who have volunteered to be
> bugtracker maintainers and their respective kernel pieces.
Go to file a new bug, click on the link by the subcategories, and it'll
tell you (you'll have to pick the main category first).
> Also a list of people who arent maintainers but are available to help
> could be useful for the owners to assign bugs to.
Not sure the best way to work this to be honest ... it may work better
as a pull system ... pick something that looks interesting and grab it.
You won't have permission to just change the owner field, but you can
add comments to bugs, and / or email the owner in question.
There are a bunch of categories that aren't really "owned" as such,
and default to khoa or myself. Those are really good candidates to
steal ... they'll be owned by bugme-janitors soon to make this more
obvious ...
M.
^ permalink raw reply
* Apache virtualhost not working behind firewall.
From: Chip Upsal @ 2002-12-20 1:39 UTC (permalink / raw)
To: netfilter
I have a windows 2000 server running apache 2.0.43 with virtual hosts
behind an iptables firewall doing NAT.
I am running iptables v1.2.5 on a redhat 7.3 server.
My nat and fowarding rules look like:
INET_IP="216.184.9.5"
#HTTP_IP="216.184.9.6"
PWWEB_IP="216.184.9.30"
PWODBC_IP="216.184.9.29"
INET_IFACE="eth2"
LAN_IP="192.168.1.15"
LAN_IP_RANGE="192.168.1.0/24"
LAN_BCAST_ADRESS="192.168.1.255"
LAN_IFACE="eth0"
DMZ_PWWEB_IP="192.168.0.2"
DMZ_PWSQL_IP="192.168.0.3"
DMZ_PWODBC_IP="192.168.0.4"
DMZ_IP="192.168.0.1"
DMZ_IFACE="eth1"
$IPTABLES -A FORWARD -i $DMZ_IFACE -o $INET_IFACE -j ACCEPT
$IPTABLES -A FORWARD -i $INET_IFACE -o $DMZ_IFACE -m state \
--state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $LAN_IFACE -o $DMZ_IFACE -j ACCEPT
$IPTABLES -A FORWARD -i $DMZ_IFACE -o $LAN_IFACE -j ACCEPT
#
# PWWEB
#
$IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_PWWEB_IP \
--dport 80 -j allowed
$IPTABLES -A FORWARD -p ICMP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_PWWEB_IP \
-j icmp_packets
#
# PWODBC
#
$IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_PWODBC_IP \
--dport 80 -j allowed
$IPTABLES -A FORWARD -p ICMP -i $INET_IFACE -o $DMZ_IFACE -d
$DMZ_PWODBC_IP \
-j icmp_packets
#
# PWWEB
#
$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $PWWEB_IP
--dport 80 \
-j DNAT --to-destination $DMZ_PWWEB_IP
$IPTABLES -t nat -A PREROUTING -p ICMP -i $INET_IFACE -d $PWWEB_IP \
-j DNAT --to-destination $DMZ_PWWEB_IP
#
# PWODBC
#
$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $PWODBC_IP
--dport 80 \
-j DNAT --to-destination $DMZ_PWODBC_IP
$IPTABLES -t nat -A PREROUTING -p ICMP -i $INET_IFACE -d $PWODBC_IP \
-j DNAT --to-destination $DMZ_PWOBDC_IP
The problem....
When the server is connected directly to the internet all works well.
However, when it is behind the firewall the virtualhost are not working
(you can only access the default web site.
Furthermore i am getting the following errors when starting iptables;
[root@iptables init.d]# ./iptables restart
Flushing all current rules and user defined chains: [ OK ]
Clearing all current rules and user defined chains: [ OK ]
Applying iptables firewall rules: [ OK ]
iptables v1.2.5: Unknown arg `--to-destination'
Try `iptables -h' or 'iptables --help' for more information.
[ OK ]
Any ideas on a solution would be most appriciated.
Chip
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-20 1:47 UTC (permalink / raw)
To: Daniel Jacobowitz
Cc: Jamie Lokier, H. Peter Anvin, Terje Eggestad, Ulrich Drepper,
Matti Aarnio, Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel
In-Reply-To: <20021220005333.GA20227@nevyn.them.org>
On Thu, 19 Dec 2002, Daniel Jacobowitz wrote:
> >
> > (ptrace also doesn't actually allow you to look at the instruction
> > contents in high memory, so gdb won't see the instructions in the
> > user-mode fast system call trampoline even when it can single-step
> > them, and I don't think I'll bother to fix it up).
>
> This worries me. I'm no x86 guru, but I assume the trampoline's setting of
> the TF bit will kick in right around the following 'ret'. So the
> application will stop and GDB won't be able to read the instruction at
> PC. I bet that makes it unhappy.
It doesn't make gdb all that unhappy, everything seems to work fine
despite the fact that gdb decides it just can't display the instructions.
> Shouldn't be that hard to fix this up in ptrace, though.
Or even in user space, since the high pages are all the same in all
processes (so gdb doesn't even strictly need ptrace, it can just read it's
_own_ codespace there). But yeah, we could make ptrace aware of the magic
pages.
Linus
^ permalink raw reply
* Re: Horrible drive performance under concurrent i/o jobs (dlh problem?)
From: Nuno Silva @ 2002-12-20 1:47 UTC (permalink / raw)
To: Torben Frey; +Cc: linux kernel mailing list
In-Reply-To: <3E01D7D7.2070201@mailsammler.de>
Hello!
Torben Frey wrote:
[..snip..]
> watching "vmstat 1" in another window - and this is what surprised me:
> when I stopped the copy job, there were 22 more seconds when data was
> still written to the backup software raid. Is this a hint where the
> problem could be? I have the same "feature" when I write to my 3ware.
>
[..snip..]
AFAIK, this is because you have some GB of memory (RAM) that are beeing
used as disk-cache. It took 22 seconds for the cached writes-to-disk
being flushed to the device.
If 22 seconds is too much for the amount of cached disk-writes is
another story :)
Maybe 3ware controllers are slow with many disks? Try the same with only
3 disks to eliminate this variable.
Regards,
Nuno Silva
^ 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.